EXPEDIENTE 2
PowerShell codificado y tarea programada
¿Cuándo deja de bastar el nombre de un proceso o de una ruta para juzgar una alerta?
Caso sintético con fines educativos. No es telemetría real ni una auditoría.
Contexto
Dos escenarios independientes del banco de detecciones: un proceso PowerShell con un comando codificado lanzado bajo una macro de Office, y la creación de una tarea programada que apunta a una carpeta de escritura pública. Los dos comparten el mismo problema de fondo: el indicador más visible también aparece en actividad legítima del mismo conjunto.
Evidencia citada
Cada cita apunta a un registro concreto de un conjunto de datos versionado. Puedes abrirlo en su laboratorio y ver lo mismo.
-
Banco de detecciones ·
powershell· versión 1.0 ·PS-01Evento etiquetado como malicioso: PowerShell con un fragmento codificado, lanzado por WINWORD.EXE.
-
Banco de detecciones ·
powershell· versión 1.0 ·PS-05Variante del mismo patrón con pwsh.exe (PowerShell 7): una regla anclada al nombre powershell.exe no la alcanza.
-
Banco de detecciones ·
powershell· versión 1.0 ·PS-02Evento benigno con el mismo proceso (powershell.exe) pero proceso padre distinto (explorer.exe) y uso administrativo documentado.
-
Banco de detecciones ·
scheduled-task· versión 1.0 ·TASK-01Evento etiquetado como malicioso: creación de tarea (EventID 4698) apuntando a una carpeta de escritura pública.
-
Banco de detecciones ·
scheduled-task· versión 1.0 ·TASK-03Variante del mismo incidente con una carpeta distinta: una regla anclada a una sola ruta no la cubre.
-
Banco de detecciones ·
scheduled-task· versión 1.0 ·TASK-04Evento benigno que usa la misma familia de ruta de escritura pública en una demostración de formación autorizada.
Razonamiento
-
El evento PS-01 muestra powershell.exe con un argumento codificado (-enc), lanzado por WINWORD.EXE: la cadena de proceso es el dato más informativo, no el fragmento en sí.
Se apoya en: cita 1
-
El evento PS-02 usa el mismo binario (powershell.exe) de forma benigna, lanzado desde explorer.exe por un administrador con un cambio documentado: el nombre del proceso por sí solo no distingue los dos casos.
Se apoya en: cita 3
-
El evento PS-05 repite el mismo patrón (macro seguida de PowerShell codificado) pero con pwsh.exe: una regla que busque literalmente "powershell.exe" pierde esta variante.
Se apoya en: cita 2
-
El evento TASK-01 registra la creación de una tarea programada (EventID 4698) cuya acción apunta a una carpeta de escritura pública, un patrón de persistencia habitual tras la ejecución inicial.
Se apoya en: cita 4
-
El evento TASK-03 documenta el mismo tipo de persistencia con una carpeta distinta: el mismo incidente no se resume en una sola ruta.
Se apoya en: cita 5
-
El evento TASK-04 usa esa misma familia de ruta en una demostración de formación autorizada: la ruta, igual que el nombre del proceso en PowerShell, tampoco discrimina por sí sola.
Se apoya en: cita 6
Alternativas que descarté
Una investigación honesta enseña también lo que podría haber sido y por qué no lo fue.
- El proceso powershell.exe también aparece en un evento benigno lanzado desde explorer.exe, y la carpeta de escritura pública también aparece en una demostración legítima de formación; cada indicador, aislado, podría parecer suficiente para alertar.
- Descartada por: En el evento benigno de PowerShell, el proceso padre es explorer.exe y el usuario es un administrador con un cambio documentado, no WINWORD.EXE; en la tarea de formación, el sujeto es el propio formador en una acción de formación registrada, no el incidente. El indicador aislado no basta sin el proceso padre o sin el sujeto y el contexto de la acción.
Decisión
Investigar · confianza media
Los dos escenarios confirman que el nombre de un proceso o de una ruta no separa por sí solo lo malicioso de lo legítimo; hace falta el proceso padre o el contenido de la tarea, y aun así quedan huecos (una variante con pwsh.exe, una carpeta distinta de persistencia) que piden revisión humana antes de dar por buena una regla.
La detección que construí
Exige que el proceso sea powershell.exe Y que su proceso padre sea WINWORD.EXE, en vez de marcar cualquier PowerShell.
| Verdaderos positivos | Falsos positivos | Verdaderos negativos | Falsos negativos |
|---|---|---|---|
| 2 | 0 | 3 | 1 |
Añadir el proceso padre elimina los dos falsos positivos del administrador (precisión 50%->100%), pero la regla sigue sin cubrir la variante con pwsh.exe (la exhaustividad se mantiene en 66,7%): anclarse al nombre del binario no generaliza entre versiones del intérprete. Sobre el escenario de tarea programada, añadir solo la carpeta de escritura pública no ayuda tanto: sigue marcando la demostración del formador y además deja de detectar la variante que usa otra carpeta.
MITRE ATT&CK
Qué NO demuestra este expediente
- Los eventos de PowerShell y de tarea programada son sintéticos y pertenecen a dos escenarios independientes del banco de pruebas; no son telemetría de un incidente único ni de un mismo host.
- Que los dos escenarios usen un nombre de usuario parecido (ana) no implica que sea la misma persona, el mismo host o el mismo incidente: son ejercicios independientes de ajuste de reglas, no un caso correlacionado.
- Solo se evaluó y verificó una regla, sobre el escenario de PowerShell; la comparación con el escenario de tarea programada es una lectura del mismo banco, no una métrica verificada en este expediente.
Reprodúcelo tú mismo
Los mismos datos, en su laboratorio. No hace falta registrarse.