Publicar inteligencia de amenazas sin un humano revisando cada línea

En ransomware.mx publicamos inteligencia diaria sobre grupos de ransomware activos contra organizaciones mexicanas: quién fue víctima esta semana, qué grupo lo reclama, y cómo recuperar archivos por familia. Puedes verla en el monitor en vivo y en la serie diaria de intel. Buena parte de ese contenido lo genera una máquina, todos los días, sin que un humano lea cada línea antes de publicarla.

El problema de hacer eso es editorial. Una máquina que se equivoca puede afirmar que una empresa fue hackeada cuando no lo fue, prometer una recuperación imposible, o citar una fuente que no existe. Las tres son problemas legales, no bugs. Este texto es sobre la compuerta que construimos para evitarlas, y sobre un error de datos que nos enseñó a desconfiar de la fuente misma.

Qué reemplazó a la revisión humana

Antes teníamos la regla clásica: borrador, revisión humana, publicar. No escala. Nadie revisa una guía de recuperación a las cuatro de la mañana. Así que reemplazamos al revisor con una compuerta, y le pusimos una regla dura: todo el contenido pasa por la compuerta antes de volverse público, y no hay ninguna otra ruta para publicar.

En el código, solo dos funciones pueden marcar un contenido como publicado, y las dos se niegan a hacerlo sin un veredicto cuyo hash sha256 cubra exactamente los bytes que se van a escribir. Sin ese veredicto escriben "borrador" y lo reportan. Para asegurarnos de que nadie agregue una tercera ruta por descuido, una prueba recorre el árbol de sintaxis de cada módulo del worker y falla la build si encuentra otra forma de publicar. La regla no depende de que el programador se acuerde de ella.

Tres jueces, una pregunta cada uno

La compuerta tiene dos niveles. El primero son reglas puras y gratuitas: formato, estructura, longitud. El segundo son tres llamadas independientes a un modelo grande, cada una con una sola lente: seguridad, citas y lenguaje. Usamos tres llamadas separadas en vez de un solo prompt porque un prompt que pregunta "¿está bien esto?" reparte mal la atención, y tres jueces con una pregunta cada uno son más difíciles de engañar.

Hay un detalle que sorprende. El nivel de reglas no busca promesas de recuperación, y lo dejamos así a propósito. Una regla de palabras clave puntúa este caso al revés: nuestra página que compara empresas de recuperación dice "recuperación garantizada" cuatro veces, siempre para advertir al lector en contra, mientras que una página que sí promete recuperación puede hacerlo sin usar ninguna de esas palabras. Detectar la promesa requiere entender la frase, así que es trabajo del juez y no de la regla. Dos pruebas mantienen al nivel de reglas fuera de ese terreno.

Una página que ya está viva no se sobreescribe con una reescritura que falla la compuerta. Solo baja si un segundo juez, al que le pedimos que argumente que el hallazgo está equivocado, no logra refutarlo. Un hallazgo consultivo nunca toca una página en vivo.

El campo "país" del feed no es confiable

El error más útil no vino del modelo. Vino de creerle a la fuente.

Nuestra fuente de víctimas son los sitios de filtración de los propios grupos, agregados por un feed de terceros. Ese feed trae un campo country, y al principio lo tratamos como verdad. No lo es. El feed de México nos devolvió organizaciones ecuatorianas, argentinas y estadounidenses. A una la marcó como mexicana porque el nombre de la víctima contenía "New Mexico". El país es una adivinanza del agregador, y nada más en los datos lleva geografía.

La corrección fue verificar la geografía antes de escribir. Cada víctima nueva marcada como mexicana se re-verifica: primero con una lectura gratuita del dominio de nivel de país, y si eso no basta, con un geocodificador con modelo. Solo un veredicto confiable de "no es México" la degrada a contexto regional. Un modelo inseguro o una API caída dejan el dato como está, en vez de silenciar el feed. El veredicto se guarda una sola vez y no se vuelve a preguntar. Esto es lo que saca a una organización extranjera del monitor público y de las estadísticas por grupo. Si construyes sobre un feed que no controlas, cada campo que asumes verdadero es un lugar donde tu máquina puede publicar una mentira con total confianza.

Un día sin publicar es la compuerta funcionando

La verificación de hechos por búsqueda web es el único control sobre la publicación no atendida del feed diario. Por eso "verificado" tiene que significar que una búsqueda ocurrió de verdad, no solo que la llamada a la API no lanzó una excepción. Contamos las búsquedas desde los bloques de resultados en la respuesta, exigimos que la respuesta no venga truncada, y que el modelo haya devuelto un número real en lugar de una negativa.

El efecto es que si el verificador deja de buscar, el feed se queda en borradores en vez de publicar sin verificar. Un día bloqueado es una posibilidad real, y el registro de trabajos lo muestra. Preferimos un día sin publicar a un día publicando algo que nadie confirmó.

Pruébalo

Construimos ransomware.mx para las organizaciones mexicanas que necesitan responder a un ataque y no saben por dónde empezar. Es público y gratuito, y lo puedes usar ahora.

Si te cifraron archivos, el identificador reconoce con qué familia estás tratando a partir de la nota de rescate o de un archivo cifrado, y te enlaza a la guía de recuperación que corresponde. El monitor muestra qué grupos están activos contra víctimas en México esta semana, y el intel diario es la serie que pasa por la compuerta que describí arriba.

Si trabajas en seguridad o respuesta a incidentes en México, nos sirve tu opinión. Dinos si el identificador acertó, si la guía sirvió, qué familia o grupo nos falta cubrir. Escríbenos a hola@ransomware.mx.