Ciberseguridad y seguridad de la información

Registro de PowerShell: cómo identificar actividad sospechosa

7 min de lecturaPublicado: 5 de agosto de 2026
Ilustración visual profesional sobre el registro de PowerShell en el campo de Windows e Identity
Respuesta rápida

El registro de PowerShell requiere la lectura del evento completo y no solo del ID de evento: tiempo, ordenador, usuario, ID de inicio de sesión, proceso, origen de red y contexto organizacional. La conclusión se crea a partir de la correlación entre varias fuentes.

La investigación de Windows e Identity se basa en una combinación de eventos de autenticación, creación de procesos, cambios de permisos, telemetría de Sysmon y contexto organizacional. Un solo evento casi nunca proporciona una conclusión completa. Este artículo se centra en el registro de PowerShell y está dirigido a analistas de SOC e investigadores de Windows. El objetivo es proporcionar un método de trabajo que se pueda aplicar en la práctica, en una entrevista profesional y en un entorno de trabajo, sin limitarse a una definición de diccionario.

El principal desafío es que los datos casi siempre están incompletos. Event 4104 Script Block Logging, Event 4103 Module Logging, Operational channel pueden indicar una dirección, pero su significado depende del tiempo, el activo, el usuario y la actividad esperada. Por lo tanto, construiremos la prueba en torno a una pregunta de investigación, la evidencia requerida y un criterio claro para la finalización.

El escenario práctico de este artículo es: investigar un script simulado que descarga un archivo en un laboratorio. Todos los ejemplos son datos de laboratorio o descripciones de procesos. Cuando se trata de Penetration Testing, Web o Cloud, solo se debe trabajar con autorización explícita, un alcance definido y la capacidad de detener la prueba.

Registro operativo de PowerShell

El tema 'Registro operativo de PowerShell' es una parte central del trabajo sobre el registro de PowerShell. Se recomienda dividirlo en tres preguntas: ¿cuál es la entrada, qué decisión se quiere tomar y qué evidencia es suficiente para justificarla? Estas preguntas evitan el uso automático de la herramienta sin comprender el propósito.

En la práctica, registre Event 4104 Script Block Logging, Event 4103 Module Logging, Operational channel, Command line y parent process, AMSI/EDR context, compare con el comportamiento esperado y defina al menos un Pivot. El resultado debe ser verificable por otro analista, incluidas las limitaciones y los próximos pasos.

Registro de bloques de scripts y módulos

En esta etapa se define qué evidencia es necesaria para responder a la pregunta de investigación. Para el registro de PowerShell, los puntos base son el ID de evento y el proveedor, el equipo, el usuario y el ID de inicio de sesión, el proceso, el padre y la línea de comandos, la IP de origen, la estación de trabajo y el tipo de inicio de sesión. Para cada fuente, se documenta el propietario, el rango de retención, la zona horaria, el retraso de ingesta y los campos que pueden faltar.

La calidad de la recopilación no se mide por si el registro 'llega'. Se debe verificar la integridad, la latencia, el análisis, los eventos duplicados y la sincronización horaria. Una prueba Canary o un evento de laboratorio conocido permite verificar que la acción apareció en la fuente, pasó por la Pipeline y se puede buscar en los campos correctos.

Transcripción y 4688/Sysmon

El tema 'Transcripción y 4688/Sysmon' es una parte central del trabajo sobre el registro de PowerShell. Se recomienda dividirlo en tres preguntas: ¿cuál es la entrada, qué decisión se quiere tomar y qué evidencia es suficiente para justificarla? Estas preguntas evitan el uso automático de la herramienta sin comprender el propósito.

En la práctica, registre Event 4104 Script Block Logging, Event 4103 Module Logging, Operational channel, Command line y parent process, AMSI/EDR context, compare con el comportamiento esperado y defina al menos un Pivot. El resultado debe ser verificable por otro analista, incluidas las limitaciones y los próximos pasos.

Patrones de investigación

Una investigación de registro de PowerShell comienza con la formulación de una hipótesis: qué comportamiento explica el hallazgo y qué evidencia lo confirmará o refutará. Luego se amplía la ventana de tiempo, se verifican las entidades y se busca una secuencia antes y después del evento.

Una buena correlación combina al menos dos tipos de información de Event 4104 Script Block Logging, Event 4103 Module Logging, Operational channel, Command line y parent process, AMSI/EDR context. Para cada hallazgo, se especifica qué demuestra, qué no demuestra y cuál es el siguiente paso. Si los datos no son suficientes, se marca como Desconocido y la ausencia de evidencia no se convierte en evidencia de ausencia.

Ajuste para actividad de administrador

La mejora del registro de PowerShell debe comenzar con una línea de base. Se mide el volumen, la tasa de casos útiles, el tiempo de investigación, las fuentes faltantes y el motivo del cierre. Un cambio que reduce las alertas pero oculta la actividad real no es un éxito.

Las opciones de ajuste incluyen un umbral, una ventana de tiempo, una lista de permitidos específica, el contexto del activo, la supresión y una excepción basada en un proceso aprobado. Cada excepción debe tener un propietario, una validez y una condición de cancelación. Después del cambio, se ejecuta un corpus de prueba y se compara antes/después.

Puntos de prueba únicos

En este tema, se recomienda construir de antemano un mapa de evidencia enfocado. Los puntos de prueba centrales son: Event 4104 Script Block Logging, Event 4103 Module Logging, Operational channel, Command line y parent process, AMSI/EDR context. La lista no es una lista de verificación automática; cada elemento se elige porque puede vincular una entidad, una acción y un tiempo o explicar un comportamiento legítimo.

  • Event 4104 Script Block Logging: Defina cuál es el valor esperado, qué se consideraría una excepción y qué otra fuente verificará el hallazgo.
  • Event 4103 Module Logging: Defina cuál es el valor esperado, qué se consideraría una excepción y qué otra fuente verificará el hallazgo.
  • Operational channel: Defina cuál es el valor esperado, qué se consideraría una excepción y qué otra fuente verificará el hallazgo.
  • Command line y parent process: Defina cuál es el valor esperado, qué se consideraría una excepción y qué otra fuente verificará el hallazgo.
  • AMSI/EDR context: Defina cuál es el valor esperado, qué se consideraría una excepción y qué otra fuente verificará el hallazgo.

Cuando uno de los puntos no está disponible, se debe documentar la brecha y elegir una alternativa. Por ejemplo, si el identificador de proceso no es estable, se puede usar el tiempo, el Host, el Usuario y el Padre; si la carga útil está cifrada, se usan los metadatos, el volumen, la frecuencia y el contexto TLS/DNS.

Proceso de trabajo recomendado

  1. Defina el alcance y una pregunta de trabajo sobre el registro de PowerShell.
  2. Registre las fuentes de datos y la evidencia necesaria: Event 4104 Script Block Logging, Event 4103 Module Logging, Operational channel, Command line y parent process.
  3. Cree una línea de base corta de comportamiento normal o resultado esperado.
  4. Realice la prueba mínima en un entorno de laboratorio y guarde el tiempo, la entrada y la salida.
  5. Cree una línea de tiempo o una tabla de comparación y separe los hechos de la interpretación.
  6. Realice un pivote a una fuente adicional para confirmar o refutar la explicación inicial.
  7. Resuma la decisión, las limitaciones, la acción recomendada y los criterios de reevaluación.

Escenario práctico

El escenario elegido es la investigación de un script simulado que descarga un archivo en un laboratorio. El propósito del ejercicio no es demostrar la capacidad de ataque, sino practicar la recopilación, comparación y documentación de forma segura. Antes de comenzar el trabajo, se definen datos simulados, una ventana de tiempo y un resultado esperado.

Al finalizar el ejercicio, se debe presentar un producto que otro analista o evaluador pueda criticar: una captura de pantalla o una exportación de la evidencia, una línea de tiempo corta, una hipótesis inicial, evidencia de verificación, una limitación y una recomendación. Cuando no hay evidencia suficiente, la conclusión correcta es que el escenario no fue probado.

EtapaQué se realizaProducto
PreparaciónDefina el alcance, el tiempo y el objetivo. Registre qué campos o evidencias de Event 4104 Script Block Logging, Event 4103 Module Logging, Operational channel se espera que aparezcan.Plan de prueba corto
Creación de datosRealice una acción segura y simulada relacionada con el registro de PowerShell, sin información real o impacto en un sistema de producción.Evento/Solicitud/Flujo controlado
RecopilaciónRecopile la evidencia bruta y el contexto de una fuente adicional. Asegúrese de la zona horaria, los identificadores y la integridad.Dos evidencias vinculadas
AnálisisEscriba qué demuestra cada evidencia, qué no demuestra y cuál es la posible explicación legítima.Conclusión provisional
FinalizaciónElija cierre, escalada, hallazgo o ajuste; añada una recomendación y reevaluación.Producto documentado

Lista de verificación práctica

  • Verifique y documente: ID de evento y proveedor.
  • Verifique y documente: Ordenador, usuario y ID de inicio de sesión.
  • Verifique y documente: Proceso, padre y línea de comandos.
  • Verifique y documente: IP de origen, estación de trabajo y tipo de inicio de sesión.
  • Verifique y documente: Cambios de grupo/privilegios.
  • Verifique y documente: Sysmon ProcessGuid o SessionGuid.
  • Indique la zona horaria, la versión de la herramienta y la hora de recopilación.
  • Guarde los datos sin procesar antes de filtrar o modificar.
  • Escriba qué demuestra el hallazgo y qué aún se desconoce.
  • Defina el propietario y la acción de seguimiento con una fecha límite.

Errores comunes

  • Depender del ID de evento sin campos.
  • Confundir el inicio de sesión con la fuente del ataque.
  • Ignorar el tipo de inicio de sesión.
  • Vincular procesos solo por PID.
  • Asumir que todo PowerShell es malicioso.
  • Cerrar un evento sin verificar el controlador de dominio.

Resumen y CTA

El registro de PowerShell: cómo identificar actividad sospechosa es un tema que combina el conocimiento técnico con la disciplina laboral. Comience con una pregunta, recopile solo evidencia relevante, mantenga el contexto y el tiempo, y elija una acción que se pueda justificar y volver a probar.

En el curso de Cybersecurity & AI de HPI, estos principios se practican utilizando sistemas, registros y laboratorios. El siguiente paso natural es pasar a los artículos relacionados, realizar el ejercicio de laboratorio y guardar el producto como parte de una cartera de trabajo profesional.

Preguntas frecuentes

¿El registro de PowerShell por sí solo prueba un ataque o una debilidad?

No. Proporciona una señal o un hallazgo que necesita contexto, verificación y una fuente adicional. Una conclusión profesional se basa en una secuencia de evidencia y en la coincidencia con el comportamiento esperado.

¿Qué hacer cuando faltan algunos datos?

Documente lo que falta, verifique una fuente alternativa y reduzca el nivel de confianza. No complete campos con conjeturas ni presente lo Desconocido como válido.

¿Cuánto tiempo se debe conservar la evidencia?

El tiempo depende de la política, la regulación, el costo y el tipo de evento. Es importante definir de antemano la retención, la retención legal y la capacidad de exportar evidencia en un formato verificable.

¿Cómo se practica sin poner en riesgo un sistema real?

Utilice máquinas virtuales, datos simulados, CTF o un laboratorio dedicado. En pruebas autorizadas, defina el alcance, las condiciones de detención y la copia de seguridad antes de comenzar el trabajo.

¿Quieres comprobar si este itinerario es para ti?

Deja tus datos y un asesor de HPI te llamará para una breve charla de orientación, sin compromiso.

Tus datos se guardan de forma segura.

Para estudios de SOC y ciberseguridad en el programa Cybersecurity & AI

¿Quieres los detalles del programa? Déjanos tus datos y te contactaremos.

Artículos relacionados