← Artículos
Investigación

PromptLock y el riesgo real de scripts maliciosos generados en local

4 min de lectura admin

Cuando un malware invoca un modelo local para generar lógica en caliente, los indicadores estáticos pierden parte de su valor. El binario puede verse “simple” mientras el comportamiento útil nace después de la ejecución.

El EDR sigue siendo útil si prioriza comportamiento: creación de scripts temporales, spawns de intérpretes inusuales, cifrado masivo y llamadas a APIs locales de inferencia. Lo que deja de bastar es firmar solo el dropper inicial.

Por qué el EDR no está obsoleto

El EDR sigue siendo útil si prioriza comportamiento: creación de scripts temporales, spawns de intérpretes inusuales, cifrado masivo y llamadas a APIs locales de inferencia. Lo que deja de bastar es firmar solo el dropper inicial.

Gobernanza de runtimes de modelos

Inventarien quién puede instalar Ollama u otros runtimes en endpoints y servidores. Una GPU de “laboratorio” sin dueño es superficie. Aíslen workloads de ML y limiten acceso a sockets locales de API.

Purple team adaptable

Incluyan payloads que mutan post-compromiso. Si solo prueban binarios fijos, miden ayer. Combinen allowlisting de intérpretes con playbooks que asumen código generado en runtime.

  • Inventario de runtimes ML
  • Alertas por script temp + cifrado
  • Aislamiento de GPUs de lab
  • Respuesta a mutación post-acceso

La respuesta práctica combina controles de ejecución, aislamiento de ML y detección orientada a comportamiento. No esperen una firma mágica “PromptLock”; esperen variantes.

Contexto para equipos en LatAm y España

Muchas organizaciones de la región comparten patrones: exposición histórica de servicios de acceso remoto, dependencia de proveedores con madurez desigual y presión por cumplir auditorías sin necesariamente mejorar detecciones operativas. Ese contexto hace que los temas de moda —agentes ofensivos, phishing generativo, botnets de consumo— se vuelvan relevantes más rápido de lo que sugiere el tamaño del equipo de seguridad.

La recomendación práctica es construir un backlog trimestral corto: tres controles medibles, un ejercicio purple team y una mejora de telemetría. Eviten planes de doce iniciativas que nadie termina. La amenaza acelerada castiga la dispersión.

Métricas que sí explican progreso

Sustituyan KPIs de vanidad (número de alertas, número de artículos leídos por el equipo) por indicadores de reducción de exposición: porcentaje de cuentas privilegiadas con MFA resistente a phishing, tiempo mediano de invalidación de sesiones, cobertura de inventario en activos internet-facing y tasa de reporte útil de phishing simulado de alta calidad.

Cuando el board pregunte por “IA en ciberseguridad”, respondan con esas métricas. Es la forma más honesta de conectar narrativa externa con riesgo interno. Si una inversión en tooling no mueve al menos una métrica en 90 días, reconsideren el gasto.

Errores comunes al interpretar research público

Las piezas de The Hacker News, Krebs on Security y papers sobre explotación asistida por modelos son útiles como sensores de tendencia, no como runbooks literales. Copiar IOCs sin contexto, comprar el producto mencionado en un párrafo promocional o asumir que un PoC de laboratorio se traduce a su red son fallos frecuentes.

Lean research preguntando siempre: ¿qué prerrequisito de acceso necesita el atacante? ¿qué control habría cortado la cadena antes? ¿podemos emular una versión segura en nuestro lab esta semana? Esa lectura crítica convierte headlines en trabajo accionable para red team, blue team y AppSec.

En Codefend usamos ese filtro cuando diseñamos evaluaciones y programas de hardening: menos teatro, más evidencia. Si su organización necesita ayuda para priorizar, el punto de partida suele ser un mapa de exposición y un ejercicio controlado—no una lista infinita de herramientas.