SOC Investigation Workbook Series - Volume 8

Investigando el abuso de cuentas privilegiadas como un analista de SOC

Un libro de trabajo de campo para las alertas con el radio de impacto más grande en tu entorno. Escrito por un gerente de ingeniería de ciberseguridad que revisa estás investigaciones por trabajo.

Dentro: la tabla de trucos de eventos privilegiados, la bifurcación de robado o mal utilizado, el radio de impacto, la contención por ruta confiable, un paquete de consultas listo para ejecutar, simulacros de escenarios, un recorrido completo y páginas de notas para el analista que puedes completar.

Jbird | jbirdcyber.gumroad.com

---

Qué hay en este libro de trabajo

• Sección 1: Descripción del ataque - Por qué el privilegio es todo el juego
• Sección 2: La alerta llega - Ejemplo de alerta, eventos e indicadores
• Sección 3: El flujo de trabajo de la investigación - ¿Robado o mal utilizado?
• Sección 4: Recopilación de evidencia - La tabla de trucos de eventos privilegiados
• Sección 5: Tomando la decisión - ¿Robado, mal utilizado, indocumentado o de emergencia (break-glass)?
• Sección 6: Recorrido completo de la investigación - El admin de puerta trasera
• Sección 7: Notas del analista - Tus páginas de investigación para completar
• Sección 8: Referencia rápida - La versión de una sola página
• Bonus: Cómo aparece el abuso de privilegios en tu entrevista

CÓMO USAR ESTE LIBRO DE TRABAJO: Lee las Secciones 1 a 6 una vez, de principio a fin. Mantén abierta la Sección 8 durante tu turno y utiliza la Sección 7 para documentar tus primeras investigaciones reales de privilegios. Las alertas de privilegios son de bajo volumen y máximo riesgo: la mayoría de los días no verás ninguna, y el día que veas una real, será el ticket más importante del edificio. La preparación que haces ahora es para ese día.

Una palabra antes de empezar

Me encuentro en el lado de la contratación para roles de SOC e ingeniería. Los escenarios de abuso de privilegios son donde pongo a prueba si un candidato entiende el radio de impacto: la diferencia entre una cuenta que puede leer un solo buzón de correo y una cuenta que puede leer todos los buzones de correo, generar credenciales, cambiar políticas y borrar sus propios rastros.

Los candidatos que tratan una alerta de Domain Admin con el mismo ritmo que un ticket de phishing aún no han internalizado lo que significa el privilegio. Este volumen existe para construir ese instinto antes del día en que lo necesites.

Para quién es este libro

• Aspirantes y analistas de SOC junior que verán una alerta de cambio de rol y necesitarán saber en segundos si es rutinaria o el peor día del trimestre.
• Personal de help desk y sysadmins que se están desplazando hacía la seguridad, quienes poseen privilegios delegados y saben exactamente qué tan poco supervisados suelen estar.
• Estudiantes y pasantes de ciberseguridad que conocen la frase “mínimo privilegio” pero nunca han leído un evento 4728.
• Cualquier persona con una entrevista de SOC en el calendario. La sección bonus al final está diseñada para ti.

Los ejemplos cubren tanto Active Directory (eventos de seguridad de Windows) como Entra ID (asignaciones de roles en la nube), porque el abuso de privilegios vive en ambos mundos y la mayoría de ustedes defenderán una combinación de los dos.

---

Sección 1 - Descripción del ataque

Por qué el privilegio es todo el juego

Buenas tardes, amigos. Cada cadena de ataque en está serie hasta ahora ha estado escalando hacía la misma cima. El atacante de robo de credenciales quería credenciales. El ataque de spray quería un punto de apoyo. La sesión de VPN quería alcance interno. Todo es un medio para un fin: el privilegio, porque el privilegio es lo que convierte el acceso en control.

Un atacante con el buzón de correo de un usuario puede leer el correo de ese usuario. Un atacante con Domain Admin o Global Admin puede leer el correo de todos, restablecer todas las contraseñas, cambiar todas las políticas, desactivar todas las defensas y eliminar los registros que te habrían informado al respecto. El privilegio no es otro activo a proteger. Es el activo, y las alertas en este volumen son las que lo custodian.

Qué cuenta como privilegiado (más de lo que piensas)

• El nivel obvio: Domain Admins, Enterprise Admins, Global Administrator y sus primos en la nube (Privileged Role Admin, Security Admin, Exchange Admin). Llaves para todo.
• El nivel operativo: administradores de servidores, administradores de bases de datos, operadores de respaldo, administradores de hipervisores, administradores de dispositivos de red. Cada uno posee un reino lo suficientemente grande como para importar, y los operadores de respaldo en particular pueden leer todo lo que contienen los respaldos.
• El nivel delegado: derechos de helpdesk para restablecer contraseñas y acceder a buzones de correo, administradores de aplicaciones, propietarios de grupos que controlan la membresía. El nivel más abusado en la práctica, porque es el más numeroso y el menos vigilado.
• Cuentas de servicio con privilegios: el problema de los Volúmenes 2 y 6 potenciado. Contraseñas antiguas, sin MFA, derechos amplios y nadie recuerda para qué sirven. Cuando una de estás inicia sesión de forma interactiva, es uno de los indicios más claros en toda la seguridad.
• Cuentas de emergencia (break-glass): cuentas de acceso de emergencia deliberadamente exentas de los controles normales. Su uso debe ser raro, ruidoso e instantáneamente verificable frente a una emergencia. Cualquier uso es una alerta; cualquier uso no explicado es un incidente.

Los dos caminos hacia el abuso de privilegios

Cada caso real en está clase de alertas llega por uno de estos dos caminos, y tu investigación se bifurca en cuál es:

• Camino 1 - Privilegio robado. Un atacante externo captura credenciales privilegiadas, mediante phishing de un admin (Volumen 3), robo de un admin en su estación de trabajo (Volumen 5), volcado de credenciales de la memoria en un servidor al que llegaron (el punto de apoyo de VPN del Volumen 6 aprovechando el acceso), o abusando de una cuenta de servicio privilegiada. Luego usan o extienden ese privilegio: nuevas cuentas de admin, concesiones de roles, cambios de políticas, creación de credenciales. Este es el estado tardío de una intrusión externa, y generalmente significa que las etapas anteriores fueron omitidas.
• Camino 2 - Privilegio mal utilizado. El titular de un privilegio legítimo lo usa fuera de su propósito: el técnico de helpdesk leyendo buzones de correo ejecutivos, el sysadmin otorgándose acceso a carpetas compartidas de RR.HH., el admin que se va creando una cuenta de puerta trasera personal. Este es el problema interno del Volumen 7 usando llaves de admin, y cada disciplina de ese volumen (priorizar el compromiso, nunca alertar al sujeto, solo hechos, RR.HH. y legal en la línea) aplica con los riesgos multiplicados.

Por qué estas investigaciones son diferentes en su naturaleza

• El radio de impacto es total. Una cuenta privilegiada puede tocar todo, lo que significa que el alcance no puede detenerse en “qué accedieron”. Debe preguntar “¿qué podrían haber cambiado, creado o plantado?”, incluyendo cambios que otorguen acceso futuro.
• El atacante puede controlar tus controles. Un intruso a nivel de admin puede leer tus canales de investigación, desactivar tu EDR, alterar registros y observar el trabajo del SOC. La planificación de la contención debe asumir que las herramientas mismas pueden estar comprometidas, razón por la cual existe la contención por ruta confiable.
• La auto-eliminación está en juego. El privilegio incluye el poder de borrar los registros de eventos y eliminar las pistas de auditoría. Los vacíos en el registro alrededor de la actividad privilegiada son en sí mismos evidencia, y el reenvío de registros a un SIEM al que la cuenta no pueda llegar es la defensa que hace posibles las investigaciones de este volumen.

NOTA DEL GERENTE DE CONTRATACIÓN: La frase única que me dice que un candidato entiende está clase de alerta es: “asume que el atacante puede verte”. Los candidatos que planean la contención a través de los canales de admin normales, con las cuentas de admin normales, contra un adversario que puede tener Domain Admin, están describiendo cómo las respuestas son observadas y contrarrestadas. Los que recurren a cuentas de emergencia, comunicación fuera de banda y dispositivos confiables están pensando en el nivel de altitud correcto.

Dónde se sitúa esto en MITRE ATT&CK

Fase que observas	ID de Técnica	Qué significa
Uso de credenciales de admin robadas	T1078.002/.004	Cuentas válidas: Cuentas de Dominio / Nube
Concesión de roles y adición de miembros	T1098	Manipulación de cuentas: Adición de roles en la nube / adiciones a grupos
Creación de cuentas de puerta trasera	T1136	Creación de cuenta: Cuenta de Dominio / Nube
Volcado de credenciales a escala	T1003.001/.006	Volcado de credenciales del SO: LSASS / DCSync
Manipulación de políticas y confianza	T1484	Modificación de política de Dominio o Tenant (GPO, federación)
Ocultar rastros	T1070.001	Eliminación de indicadores: Borrar registros de eventos de Windows

Forma del ataque en el mundo real

Un patrón en el que he trabajado personalmente: una alerta el martes a las 23:40 por un nuevo miembro añadido a Domain Admins. La cuenta añadida se llamaba svc-monitor2, creada once minutos antes, y la cuenta que realizó la adición era un administrador de sistemas real.

La lectura fácil fue “admin haciendo mantenimiento nocturno”, y el calendario de cambios incluso tenía una ventana de parcheo de servidores vagamente redactada esa noche. Lo que rompió la lectura fácil: la cuenta del admin se había autenticado desde un servidor en el que no tenía ninguna tarea, el EDR de su estación de trabajo mostró un evento de acceso a LSASS dos horas antes, y el verdadero svc-monitor (uno, no dos) pertenecía a un producto de monitoreo que nunca crea cuentas.

La cadena subyacente: un punto de apoyo de semanas anteriores finalmente alcanzó las credenciales en caché de un admin, y svc-monitor2 era el atacante comprando permanencia. La alerta que lo hizo surgir fue un solo evento de membresía de grupo. La investigación que siguió es la Sección 6, y la razón por la que terminó bien es que nadie trató un cambio en Domain Admins como algo rutinario, incluso con una historia de cobertura plausible en el calendario de cambios.

---

Sección 2 - La alerta llega

Lo que ves realmente en la cola

A continuación se presenta el par de alertas representativo: el analítico del SIEM y el evento de seguridad de Windows puro. Aprende el evento puro, porque el analítico es solo un adorno sobre él.

ALERT: Member added to high-privilege group
Severity: High
Tactic: Persistence (TA0003)
Group: CONTOSO\Domain Admins
Member added: CONTOSO\svc-monitor2 (created 23:29, 11 min prior)
Performed by: CONTOSO\jh-admin
From host: SQL-PRD-04
Time: 2026-06-16 23:40 UTC
Change record: none matching
Detection source: SIEM analytic on Security event 4728

Security Event 4728: A member was added to a security-enabled global group
Subject: CONTOSO\jh-admin   Logon ID: 0x8F2A41
Group: Domain Admins       Member: CN=svc-monitor2,...
Computer: DC-01
Related: 4720 (account created) 23:29 same subject, host SQL-PRD-04
Related: 4672 (special privileges assigned) for jh-admin on SQL-PRD-04

Las cinco preguntas que esta alerta debe responder en el triaje

• ¿Qué privilegio se movió? Domain Admins es la cima de la montaña. Una adición a un grupo de helpdesk es una conversación diferente. La severidad escala con el grupo, y deberías conocer de memoria los cinco grupos principales de tu entorno.
• ¿Quién lo realizó? Un admin nombrado, una cuenta de servicio (las cuentas de servicio esencialmente nunca deberían realizar adiciones a grupos), o una cuenta que nunca has escuchado. Cada una apunta a algún lugar diferente.
• ¿Desde dónde? El host de la sesión ejecutante importa enormemente. Los admins trabajan desde estaciones de trabajo de admin y hosts de salto. Una adición de grupo realizada DESDE un servidor SQL es una sesión de admin viviendo en algún lugar donde no debería estar.
• ¿Hay un registro de cambio? El único diferenciador más rápido en toda está clase de alertas. Un ticket específico que coincida disuelve la mayoría de estás en dos minutos. Ninguno que coincida significa que la investigación está activa.
• ¿Quién fue añadido y qué tan antiguo es? Una cuenta de once minutos de antigüedad entrando en Domain Admins es una cuenta creada para un propósito, y el propósito rara vez es bueno. La antigüedad de la cuenta más el mimetismo del patrón de nombre (svc-monitor2 junto al real svc-monitor) es una firma de puerta trasera.

El gemelo en la nube de esta alerta

Entra ID Audit Log
Activity: Add member to role
Role: Global Administrator
Target: ext-support@consultant-tenant.com (guest)
Initiated by: m.osei@contoso.com via session: token claim,
              IP 102.89.33.0/24 (hosting ASN)
Time: 03:12 UTC
PIM activation: none (permanent assignment)

Mismas cinco preguntas, vocabulario en la nube: el rol (Global Administrator), el ejecutor y la calidad de su sesión (una sesión de token-claim desde infraestructura de hosting realizando concesiones de roles es el stack del Volumen 1 sosteniendo llaves de admin), el objetivo (una cuenta de invitado recibiendo una asignación permanente de Global Admin es una firma de toma de control del tenant), y la ausencia de registro de cambio y de activación de PIM.

Si tu organización utiliza la gestión de identidades privilegiadas, las asignaciones permanentes fuera de ella son hallazgos por definición.

PATRÓN A MEMORIZAR: Las alertas de privilegio se responden con cinco hechos: qué privilegio, realizado por quién, desde dónde, contra qué registro de cambio, otorgado a qué cuenta. Captura los cinco en la primera lectura. Dos minutos de lectura disciplinada separan al admin que hace mantenimiento el martes del atacante que compra permanencia, y se ven casi idénticos hasta que revisas.

---

Sección 3 - El flujo de trabajo de la investigación

Cinco fases, con la bifurcación del Volumen 7 afilada para mayores riesgos: privilegio robado (un atacante externo tiene las llaves) o privilegio mal utilizado (el titular de la llave es el problema). Y una regla por encima de todo: hasta que se responda la bifurcación, planifica como si el atacante pudiera verte.

Fase 1 - Triaje y los cinco hechos (primeros 10 minutos)

• Captura los cinco hechos: privilegio movido, ejecutor, host y sesión ejecutante, estado del registro de cambio y la cuenta receptora con su antigüedad y nombre.
• Verifica el calendario de cambios y los tickets con especificidad. Una ventana de parcheo vaga no cubre un cambio de membresía de grupo; el registro debe describir Está acción. El trabajo de admin sancionado pero indocumentado es el falso positivo dominante aquí, y la cura es una pregunta específica a través de los canales de gestión de admins, no un encogimiento de hombros.
• Califica el privilegio sin flaquear. Domain Admins, Global Admin, cambios de federación y GPO, y el uso de break-glass reciben atención de nivel de incidente inmediatamente. Los niveles más bajos reciben las mismas preguntas a un ritmo más calmado.
• Mira un salto hacía atrás inmediatamente: ¿qué sesión realizó la acción, desde qué host, cómo se autenticó? La sesión ejecutante es donde reside la respuesta de robado o mal utilizado.

Fase 2 - Validación y la bifurcación de Robado o Mal Utilizado

• Ejecuta el conjunto del Volumen 1 en las sesiones recientes de la cuenta ejecutante: infraestructura de origen, dispositivo, calidad de MFA, ajuste de línea base. Una cuenta de admin realizando acciones privilegiadas desde un ASN de hosting en sesiones de token-claim es robada hasta que se demuestre lo contrario.
• Verifica la salud del host ejecutor: señales de EDR, eventos de acceso a LSASS, indicadores de volcado de credenciales, procesos inusuales alrededor del momento de la acción. El privilegio robado suele dejar un rastro en la máquina donde se tomaron o usaron las credenciales.
• Si las sesiones son limpias y el host es limpio, es posible que estés en la ruta 2 (mal uso) o mirando un trabajo legítimo indocumentado. Las disciplinas del Volumen 7 se activan AHORA: no contactes al ejecutor directamente, verifica a través de los canales de gestión de admins, solo hechos, distribución mínima.
• Para el uso de break-glass: verifica contra una emergencia declarada a través de los canales de liderazgo inmediatamente. Break-glass sin una emergencia es un incidente por definición, quienquiera que lo haya usado.

LA BIFURCACIÓN DECIDE EN QUIÉN PUEDES CONFIAR: El privilegio robado significa que un externo puede estar leyendo tu chat, tu correo y tu SIEM. El privilegio mal utilizado significa que un colega puede hacerlo. En cualquier caso, en el momento en que la bifurcación se aleje del trabajo legítimo documentado, tu comunicación sobre el caso se mueve a canales fuera de banda y solo a personas nombradas. Esto es la regla de discreción del Volumen 7 con el radio de impacto aumentado.

Fase 3 - Alcance (radio de impacto, no solo huellas)

El alcance de privilegios hace una pregunta más grande que cualquier volumen anterior: no solo “qué tocaron”, sino “qué podrían hacer ahora que no podían antes”, y “¿qué plantaron?”. Trabaja la lista:

• Todo lo que hizo la sesión privilegiada. Reconstrucción completa de actividad para la cuenta ejecutante y la cuenta receptora: inicios de sesión (dónde), comandos, cambios, lecturas. Los eventos 4672 mapean dónde viajó el privilegio.
• Concesiones y cuentas. Cada asignación de rol, adición a grupo, creación de cuenta y cambio de permisos por estás cuentas en la ventana de búsqueda. Cada uno es persistencia potencial y va a la lista de reversión.
• Exposición de credenciales. ¿Tocaron controladores de dominio? Verifica si hay firmas de DCSync (Evento 4662 con GUIDs de replicación desde cuentas que no son de DC) y acceso a LSASS en servidores a los que llegaron. Si las credenciales se volcaron a escala, el alcance del incidente es cada credencial en el dominio, y esa frase debe ir en tu escalación verbatim.
• Manipulación de políticas y confianza. Cambios de GPO, ediciones de acceso condicional, ajustes de federación, consentimientos de aplicaciones con permisos amplios, delegaciones de buzón. Estas son las puertas traseras silenciosas que sobreviven a los reinicios de contraseña.
• Integridad de los registros. Evento 1102 (registro de auditoría borrado), vacíos en el volumen de registros esperado, agentes desactivados. Los intentos de borrado son tanto evidencia como un límite de alcance: trata los vacíos como territorio hostil, no como ausencia de actividad.
• El camino de llegada. Camina hacía atrás hasta cómo se obtuvo el privilegio: el admin que fue víctima de phishing, la estación de trabajo volcada, la cuenta de servicio. El incidente de volumen anterior es parte del alcance de este incidente.

Fase 4 - Escalación

El abuso de privilegios de nivel superior es lo más cercano que tiene está serie a una escalación automática: la actividad confirmada de Domain Admin o Global Admin es un incidente liderado por IR, visible para el liderazgo, desde el momento en que se confirma, sin más.

Tu paquete: los cinco hechos, el veredicto de la bifurcación con evidencia de sesión y host, el inventario del radio de impacto (viaje de privilegios, concesiones, cuentas, cambios de política, exposición de credenciales), la lista de reversión, y el camino de llegada. Y entrégalo fuera de banda si la bifurcación dice robado: el canal de escalación es parte del plan de respuesta, no una ocurrencia posterior.

Fase 5 - Consideraciones de contención (el problema de la ruta confiable)

• Planifica en terreno confiable. La contención de un intruso a nivel de admin se ejecuta desde dispositivos conocidos como limpios, con credenciales de emergencia o recién emitidas, coordinada a través de canales fuera de banda. Usar posiblemente cuentas de admin robadas para luchar contra un atacante que tiene admin es darle el guion de la jugada y ser contrarrestado.
• Desactiva y revoca en el orden correcto: las cuentas de puerta trasera y receptoras primero (sesiones revocadas, cuentas desactivadas), luego la cuenta ejecutante comprometida (revocar, restablecer, re-credencializar), luego revierte cada concesión y cambio en la lista de reversión, verificando cada uno.
• Rota lo que el radio de impacto dice que fue expuesto. Tocar un DC más indicadores de volcado significa conversaciones de rotación de credenciales en todo el dominio, incluyendo el reinicio de la cuenta KRBTGT (dos veces, espaciadas correctamente) que invalida tickets de Kerberos falsificados. Esa decisión pertenece a IR e ingeniería; tu trabajo es hacer que la evidencia para ello sea innegable.
• Verifica tu visibilidad antes de confiar en tu verificación. Reactiva y confirma los agentes y el reenvío que el atacante desactivó, luego vuelve a ejecutar las consultas de alcance; lo que encontraste antes de restaurar la visibilidad fue el suelo, no el techo.
• Para la ruta 2 (mal uso): la contención es la suspensión del acceso coordinada con RR.HH. y legal según el Volumen 7, con la urgencia añadida de que el sujeto puede causar daños a escala de dominio entre el aviso y la acción. La secuenciación del cambio de acceso y la conversación se convierte en una decisión de personas nombradas en la misma hora.
• Corrige el camino de entrada. Higiene de estaciones de trabajo de admin, PIM/elevación justo a tiempo, MFA en cada cuenta privilegiada, bloqueo de cuentas de servicio, y alertas sobre los eventos exactos que capturaron este caso. La nota de cierre nombra la brecha y al propietario.

EL ORDEN IMPORTA: Puertas traseras primero, cuenta de origen segunda, reversiones terceras (verificadas), rotación según lo que el radio de impacto dicte, visibilidad verificada en todo momento, todo desde terreno confiable. Restablecer la contraseña del admin mientras la cuenta de puerta trasera del atacante permanece en Domain Admins es la versión privilegiada de restablecer una contraseña sin revocar sesiones, y falla de la misma manera, a un costo cien veces mayor.

---

El Paquete de Consultas - Búsquedas que hacen el trabajo

Escrito en KQL para Microsoft Sentinel sobre las tablas SecurityEvent (AD) y Entra ID, porque el par híbrido es la realidad más común. Las mismas preguntas se traducen a cualquier SIEM.

1. Todos los cambios de grupos privilegiados, con ejecutor y origen

SecurityEvent
| where EventID in (4728, 4732, 4756, 4729, 4733, 4757)
| where TargetUserName in ("Domain Admins","Enterprise Admins",
                           "Administrators","Account Operators","Backup Operators")
| project TimeGenerated, EventID, TargetUserName, MemberName,
          SubjectUserName, Computer

2. Asignaciones de roles en la nube y omisiones de PIM

AuditLogs
| where OperationName in ("Add member to role", "Add eligible member to role")
| extend Role = tostring(TargetResources[0].modifiedProperties)
| project TimeGenerated, OperationName, InitiatedBy, TargetResources, Result

3. Cuentas de servicio iniciando sesión de forma interactiva (el indicio claro)

SecurityEvent
| where EventID == 4624 and LogonType in (2, 10)
| where TargetUserName startswith "svc-" or TargetUserName has "service"
| project TimeGenerated, TargetUserName, Computer, IpAddress, LogonType

4. ¿A dónde viajó el privilegio? - 4672 mapeado por cuenta y host

SecurityEvent
| where EventID == 4672
| where AccountName in ("jh-admin","svc-monitor2")
| summarize Sessions=count(), FirstSeen=min(TimeGenerated),
            LastSeen=max(TimeGenerated) by AccountName, Computer
| sort by FirstSeen asc

5. Firmas de DCSync y borrado de registros

SecurityEvent
| where (EventID == 4662 and ObjectType has "domainDNS"
         and Properties has "1131f6aa")  // replication GUID
       or EventID == 1102
| project TimeGenerated, EventID, SubjectUserName, Computer

La 1 a la 5 te dan cada movimiento de privilegio, el gemelo en la nube, el indicio de cuenta de servicio, el mapa de viaje de privilegios y las dos firmas catastróficas (replicación de credenciales por cuentas que no son de DC y registros de auditoría borrados). Ejecútalas en un horario, no solo durante incidentes: está clase de alertas recompensa al analista que ya sabe cómo es lo normal.

---

Sección 4 - Recopilación de evidencia

Dónde reside la evidencia

Fuente	Qué te da	Plataforma típica
Eventos de seguridad de AD	Cambios de grupo, creación de cuentas, inicios de sesión privilegiados, la verdad pura del dominio	Registros de seguridad de DC reenviados al SIEM
Registros de auditoría de Entra	Asignaciones de roles, actividad de PIM, consentimientos de aplicaciones, cambios de federación	Registro de auditoría de Entra ID + registros de inicio de sesión
Plataforma PAM / PIM	Registros de elevación sancionados: quién solicitó qué privilegio, cuándo	PIM, CyberArk, Delinea
Registros de cambio	El diferenciador más rápido: un ticket específico que coincida con la acción específica	ITSM / Calendario de cambios
EDR en hosts de admin	Señales de volcado de credenciales, acceso a LSASS, herramientas en el host ejecutor	Defender, CrowdStrike, SentinelOne
Registros de inicio de sesión	La calidad de la sesión detrás de cada acción privilegiada: la evidencia de robado o mal utilizado	Registros de inicio de sesión de Entra ID, registros de federación
Historial de GPO / política	Manipulación de políticas y confianza: las puertas traseras silenciosas que sobreviven a los reinicios de contraseña	Versionado de GPO, gestión de configuración

La tabla de trucos de eventos privilegiados

Estos IDs de evento son el vocabulario de toda está clase de alertas. Apréndelos de la misma manera que aprendiste los códigos de error en el Volumen 2:

Evento	Qué significa	Por qué te importa
4728 / 4732 / 4756	Miembro añadido a un grupo de seguridad global / local / universal	El acto principal. Las adiciones a grupos privilegiados son el núcleo de las alertas de este volumen.
4720	Cuenta de usuario creada	Emparejado con una adición a grupo minutos después, la firma de puerta trasera.
4672	Privilegios especiales asignados en el inicio de sesión	Mapea dónde viajaron las cuentas privilegiadas. Tu trazador de radio de impacto.
4624 tipo 2 / 10	Inicio de sesión interactivo / remoto interactivo	Las cuentas de servicio que hacen esto son uno de los indicios más limpios en seguridad.
4662 + GUIDs de replicación	Acceso a replicación de directorio por una cuenta que no es de DC	La firma de DCSync: todas las credenciales del dominio potencialmente robadas.
4769	Solicitud de ticket de servicio de Kerberos	Los patrones de volumen revelan Kerberoasting de cuentas de servicio privilegiadas con contraseñas débiles.
1102	Registro de auditoría borrado	Auto-eliminación. Tanto evidencia como una campana de alarma por sí misma.
4670 / ediciones de GPO	Cambios de permisos y políticas	Las puertas traseras silenciosas que sobreviven a los reinicios de contraseña.

Los registros reenviados son todo el juego

Cada evento en está tabla solo es útil si reside en algún lugar que la cuenta privilegiada no pueda borrar. El reenvío de registros a un SIEM, con el reenvío mismo monitoreado, es el control que hace posibles las investigaciones de privilegios. Si tu empresa no reenvía los registros de seguridad de DC, esa es la primera recomendación de cada nota de cierre que escribas en está clase de alertas hasta que cambie.

Preguntas que impulsan la búsqueda de evidencia

• ¿Qué privilegio se movió, realizado por quién, desde dónde, contra qué registro de cambio, otorgado a quién?
• ¿Cuál es la calidad de la sesión de la cuenta ejecutante: el stack del Volumen 1 o una línea base limpia?
• ¿Es el host ejecutor saludable, o muestra EDR señales de volcado alrededor del momento de la acción?
• ¿Qué hicieron las cuentas privilegiadas en la ventana: inicios de sesión, concesiones, creaciones, cambios, lecturas?
• ¿Tocó algo los controladores de dominio, y hay firmas de DCSync o Kerberoasting?
• ¿Se cambiaron políticas, confianza, federación o consentimientos? ¿Qué está en la lista de reversión?
• ¿Están intactos los registros: algún 1102, vacíos, o anomalías de volumen?
• ¿Cuál fue el camino de entrada, y qué incidente de volumen anterior está debajo?

Artefactos a capturar sobre la marcha

• Los cinco hechos, registrados verbatim de los eventos puros, no del resumen del analítico.
• La evidencia de sesión y host detrás del veredicto de la bifurcación.
• El inventario del radio de impacto: mapa de viaje de privilegios, concesiones, creaciones, cambios de política.
• La lista de reversión con el estado de verificación para cada ítem.
• Hallazgos de integridad de registros, incluyendo resultados limpios explícitos.
• El camino de llegada, acciones tomadas con marcas de tiempo, y el plan de ruta confiable para cualquier cosa que aún no se haya hecho.

---

Sección 5 - Tomando la decisión

Las investigaciones de privilegios terminan en uno de cuatro veredictos. Dos son incidentes, uno es el falso positivo dominante, y uno es un control de proceso que siempre debe completarse.

Veredicto 1 - Privilegio robado (atacante externo sosteniendo las llaves)

• Las sesiones de la cuenta ejecutante muestran el stack del Volumen 1: infraestructura extranjera, autenticación solo por token, dispositivos no registrados, todo fuera de la línea base.
• El host ejecutor muestra señales de compromiso: acceso a LSASS, herramientas de volcado, el rastro del punto de apoyo.
• Las acciones construyen valor para el atacante: cuentas de puerta trasera, concesiones de roles, debilitamiento de políticas, replicación de credenciales.
• Respuesta: contención por ruta confiable, la secuencia completa de la Fase 5, liderado por IR desde la confirmación.

Veredicto 2 - Privilegio mal utilizado (el titular de la llave es el problema)

• Las sesiones y el host coinciden con los del titular; el compromiso queda descartado por escrito.
• Las acciones sirven a la persona, no al rol: autoconcesiones, espionaje, puertas traseras personales, acceso a datos fuera de cualquier deber.
• Ninguna historia sancionada sobrevive al chequeo específico a través de los canales de gestión de admins.
• Respuesta: las vías del Volumen 7 (RR.HH., legal, nunca alertar, solo hechos) con decisiones de secuenciación en la misma hora porque el sujeto puede causar daños a escala de dominio entre el aviso y la acción.

Veredicto 3 - Trabajo de admin sancionado pero indocumentado (el falso positivo dominante)

• Un admin real, en una estación de trabajo de admin saludable, haciendo trabajo que la gestión de admins confirma como suyo, sin ticket o con uno vago.
• Cierra la alerta, mantén el hallazgo: los cambios privilegiados indocumentados son una falla de proceso que está clase de alertas existe para detectar. La nota de cierre recomienda el requisito de documentación con un propietario, de manera amable y firme.
• Vigila tu propio sesgo: confirmación a través de canales, no solo a través de lo que diga el ejecutor, porque los casos del veredicto 2 se describen a sí mismos como del veredicto 3 cada una de las veces.

Veredicto 4 - Uso de emergencia (break-glass) o de emergencia (verificar, siempre)

• Uso de break-glass durante una emergencia declarada, confirmada a través de los canales de liderazgo, documentada después del hecho según la política: legítimo, registrado, cerrado.
• Uso de break-glass sin una emergencia que alguien declare: un incidente por definición, bifurcálo como cualquier otra acción privilegiada.
• En cualquier caso, la cuenta se re-credencializa después del uso y el uso se registra por escrito. Las emergencias no eximen las llaves de la rendición de cuentas.

Comparación de señales

Señal	Robado	Mal utilizado	Indocumentado
Sesiones	Stack del Volumen 1	Propias del titular	Propias del titular, línea base
Host ejecutor	Señales de compromiso	Limpio	Estación de trabajo de admin saludable
Las acciones sirven a	El atacante (persistencia)	La persona	La tarea documentada después
Chequeo de canal	N/A	Ninguna historia sobrevive	La gestión confirma
Respuesta	Contención por ruta confiable	Vías del Volumen 7	Cierre + hallazgo de proceso

NINGUNA SEÑAL DECIDE POR SÍ SOLA: Un cambio de Domain Admins a las 2 AM sin ticket es el falso positivo dominante Y la firma de puerta trasera, que es exactamente por lo que los cinco hechos más la bifurcación existen. El chequeo del registro de cambio resuelve la mayoría de los casos en minutos; la evidencia de sesión y host resuelve el resto. Nunca cierres basándote solo en la plausibilidad del ejecutor, y nunca escales basándote solo en la marca de tiempo.

Simulacro - Tres alertas, tú tomas la decisión

Lee cada escenario, decide tu veredicto y tu siguiente paso, luego verifica la respuesta. Estos son compuestos de investigaciones reales y mapean directamente con preguntas de escenarios en entrevistas.

Escenario A

Domingo 02:30, alerta: un miembro añadido al grupo de Administradores en seis servidores de producción en diez minutos. Ejecutor: un administrador de infraestructura nombrado, desde el host de salto designado, MFA fresco en su estación de trabajo registrada una hora antes, EDR limpio. Sin ticket de cambio. Un mensaje a través de los canales de gestión de admins recibe una respuesta en veinte minutos: una matriz de almacenamiento falló, está en medio de la recuperación, el registro de cambio de emergencia se está archivando ahora, y su gerente confirma la interrupción de forma independiente.

Veredicto: Sancionado pero indocumentado (veredicto 3), con el hallazgo de proceso mantenido. Sesiones limpias, host limpio, origen confiable, emergencia confirmada por la gestión: ciérralo. Pero el hallazgo permanece: los cambios privilegiados durante emergencias aún necesitan registros contemporáneos, porque este mismo patrón (concesiones fuera de horario, sin ticket) es también la firma de puerta trasera, y cada caso legítimo indocumentado entrena al SOC para reaccionar menos ante el real. La nota de cierre recomienda un camino rápido para cambios de emergencia con un propietario. Amable, firmemente, cada vez.

Escenario B

Se dispara una alerta por acceso a buzón de correo: una técnica de helpdesk con derechos delegados para buzones de correo ha abierto los buzones del CFO, del jefe de RR.HH. y dos asistentes de la junta directiva durante tres semanas, 41 accesos en total, sin tickets que hagan referencia a esos usuarios, todos desde su propia estación de trabajo con sus propias sesiones limpias. Los accesos se agrupan alrededor de la hora posterior a que aparezcan reuniones ejecutivas en el calendario público de la empresa.

Veredicto: Privilegio mal utilizado (veredicto 2), vías del Volumen 7 inmediatamente. El compromiso queda descartado por las sesiones limpias, ninguna historia sancionada es plausible con ese patrón, y la correlación de tiempo sugiere un espionaje deliberado. No la contactes, no menciones el caso a su equipo. Paquete de solo hechos (el inventario de acceso con marcas de tiempo y el chequeo de ausencia de tickets), RR.HH. y legal convocados, evidencia hasheada, distribución nombrada. La decisión de la misma hora es necesaria para la secuenciación de la suspensión del acceso porque ella retiene los derechos mientras el caso se desarrolla.

Escenario C

Martes 14:20, alerta: Evento 4662 con GUIDs de replicación de directorio, cuenta de origen svc-backup, host de origen un servidor de archivos, no un controlador de dominio. Línea base de svc-backup: inicios de sesión por lotes solo al sistema de respaldo. Hoy: un inicio de sesión interactivo (4624 tipo 10) al servidor de archivos hace dos horas desde una IP interna que se rastrea a una sesión de VPN, y ahora solicitudes de replicación contra DC-01.

Veredicto: Privilegio robado, DCSync en progreso, peor caso hasta que se demuestre lo contrario. Una cuenta de servicio iniciando sesión de forma interactiva es el indicio claro; esa cuenta luego solicitando replicación de directorio desde un no-DC es la firma de DCSync, lo que significa que cada credencial en el dominio se está cosechando en este momento. Esto es una escalación inmediata, fuera de banda, liderada por IR: corta la sesión de VPN y las sesiones de la cuenta desde terreno confiable, aísla el servidor de archivos y comienza la conversación sobre la rotación en todo el dominio incluyendo KRBTGT. El camino de llegada (VPN, Volumen 6) va en el paquete. Los minutos importan aquí más que en cualquier otro lugar en este volumen.

---

Sección 6 - Recorrido completo de la investigación

Trabajemos la alerta de la Sección 2 de principio a fin, exactamente como yo esperaría que un analista sólido la ejecute. Los tiempos son el tiempo transcurrido en la investigación.

00:00 a 00:10 - Triaje y los cinco hechos

Los cinco hechos de los eventos puros:

• Privilegio movido: Membresía de Domain Admins
• Ejecutor: jh-admin
• Host ejecutor: SQL-PRD-04, que NO es una estación de trabajo de admin ni un host de salto
• El chequeo del registro de cambio encuentra solo una ventana de parcheo de servidores vaga sin mención de cuentas o grupos
• La cuenta receptora svc-monitor2, once minutos de antigüedad, nombre mimetizando al real svc-monitor

Tres de cinco hechos tienen una forma incorrecta (host, especificidad del registro, cuenta receptora), por lo que se trata como un probable incidente en el minuto diez, y según la regla de la bifurcación, la comunicación del caso se mueve a un canal nombrado fuera de banda ahora, antes de la validación, porque si este es un privilegio robado el atacante tiene Domain Admin y puede estar observándote.

00:10 a 00:25 - Validación y la bifurcación

Sesiones de jh-admin (conjunto del Volumen 1):

• Su estación de trabajo registrada todo el día hasta las 21:00
• Luego un inicio de sesión de red a las 23:31 en SQL-PRD-04 originado desde otro servidor en el que no tiene tareas
• Sin MFA fresco en ninguna parte de esa cadena

EDR en su estación de trabajo: un evento de acceso a LSASS a las 21:47 desde un proceso camuflado como un controlador de impresora. La cadena se lee claramente: su estación de trabajo fue comprometida, sus credenciales en caché fueron volcadas a las 21:47, y el atacante ha estado moviéndose como él desde entonces.

Veredicto de la bifurcación: privilegio robado, camino 1, registrado con la evidencia. El jh-admin en sí mismo es una víctima, anotado explícitamente para que el humano sea exonerado incluso mientras su cuenta se trata como hostil.

00:25 a 01:00 - Alcance - Radio de impacto

• La consulta cuatro mapea el viaje de privilegios: eventos 4672 de jh-admin en su estación de trabajo (normal), luego en SQL-PRD-04, luego en DC-01 a las 23:38, dos minutos antes de la adición al grupo.
• La consulta uno encuentra el conjunto completo de concesiones: svc-monitor2 creado (4720) y añadido a Domain Admins (4728), más una segunda adición más silenciosa de svc-monitor2 a Backup Operators.
• Consulta cinco: no hay firmas de DCSync, no hay 1102, y el reenvío de registros se confirma intacto, lo que delimita el daño significativamente y se registra como un resultado limpio explícito.
• Historial de GPO y auditoría de Entra: no hay ediciones de políticas, no hay concesiones de roles en la nube, no hay cambios de federación, no hay consentimientos.

La lista de reversión es, por lo tanto, dos ítems (ambas membresías de grupo) más una eliminación de cuenta, y la evaluación de exposición de credenciales es que las credenciales de jh-admin ciertamente, las credenciales en todo el dominio probablemente no (sin replicación, contacto con DC limitado y contabilizado para todas las acciones). El camino de llegada en la estación de trabajo de jh-admin se rastrea hasta una utilidad trojanizada instalada nueve días antes, el incidente del Volumen 5 subyacente. Todo se exportó y hasheó.

01:00 a 01:40 - Escalación y contención por ruta confiable

IR convocado fuera de banda con el paquete; liderazgo informado porque se movió Domain Admins. Contención desde una estación de trabajo de respuesta limpia con credenciales de emergencia, en orden:

• Sesiones de svc-monitor2 revocadas, cuenta desactivada, ambas membresías de grupo eliminadas y verificadas (la lista de reversión, chequeada con marcas de tiempo)
• Sesiones de jh-admin revocadas en todas partes, cuenta desactivada pendiente de re-credencialización, su estación de trabajo aislada para forense
• SQL-PRD-04 y el servidor intermedio aislados y barridos
• El hash de la utilidad trojanizada y el C2 bloqueados y buscados en toda la flota (dos estaciones de trabajo más teníanla, ninguna escaló a robo de credenciales, ambas reimágenes)
• La rotación de KRBTGT se evalúa con ingeniería y se difiere con justificación escrita: no hay DCSync, el contacto con DC está limitado y contabilizado, y el propietario de la decisión nombrado en el registro
• El monitoreo se intensifica sobre los patrones exactos de este caso mientras el entorno se asienta

Causa raíz y cierre

Cadena: una utilidad trojanizada en una estación de trabajo de admin (Volumen 5), volcado de credenciales a las 21:47, movimiento lateral como el admin (músculos del Volumen 6, dentro de la red), y una cuenta de admin de puerta trasera para comprar permanencia, capturada por un solo analítico 4728 once minutos después de que la cuenta naciera.

La nota de cierre documenta la cadena, el radio de impacto delimitado con los resultados limpios explícitos y las correcciones sistémicas con propietarios: estaciones de trabajo de acceso privilegiado para cuentas de admin (la exposición de credenciales en caché es la raíz), elevación justo a tiempo vía PIM para que el Domain Admin permanente se reduzca hacía cero, MFA en el camino de elevación, bloqueo de cuentas de servicio privilegiadas, reenvío de registros de DC a algún lugar al que los admins no puedan llegar, y alertas sobre los eventos exactos en está tabla de trucos.

La alerta funcionó; la disciplina de rechazar la historia de cobertura plausible es lo que hizo que importara.

LO QUE HIZO BUENA Está INVESTIGACIÓN: Cinco hechos capturados en bruto, la historia de cobertura plausible probada en lugar de confiada, el veredicto de la bifurcación con evidencia de sesión y host, la comunicación se movió fuera de banda antes de terminar la validación, el radio de impacto se alcanzó con concesiones y políticas en lugar de solo huellas, los resultados limpios se registraron tan explícitamente como los hallazgos, la contención se ejecutó desde terreno confiable en el orden correcto, y el admin víctima fue exonerado en la escritura mientras su cuenta era tratada como hostil. Cada uno de esos hábitos es una pregunta que hago en las entrevistas.

El único hábito que definió este caso

Este caso dependió de negarse a dejar que la plausibilidad lo cerrara. Un admin real, una ventana de mantenimiento real, un nombre con forma de cuenta de servicio: cada detalle superficial invitaba al cierre de treinta segundos, y el analista en cambio pasó dos minutos verificando los cinco hechos contra los eventos puros, donde tres de cinco tenían una forma incorrecta.

Las alertas de privilegios son lo suficientemente raras como para que cada una merezca esos dos minutos, y la asimetría no podría ser más grande: el costo del chequeo es de dos minutos de la noche de un analista, y el costo de la omisión es un atacante sosteniendo Domain Admin con una puerta trasera permanente, que es la escena inicial de cada post-mortem de ransomware jamás escrito.

En está clase de alertas, la disciplina ES la habilidad. Las consultas son fáciles. Negarse al cierre fácil es el trabajo.

Tres frases para evitar en este volumen

1. Cada alerta de privilegios se responde con cinco hechos antes de que se responda con un veredicto.
2. La identidad del ejecutor es la pregunta, no la respuesta, porque las credenciales robadas actúan como el admin real.
3. En el momento en que un atacante puede tener admin, respondes desde terreno confiable y asumes que pueden verte, porque probablemente pueden.

---

Sección 7 - Notas del analista

Imprime estás o recréalas en tu herramienta de tickets. Complétalas durante tu próxima investigación real de privilegios. La estructura a continuación es el paquete de escalación de la Sección 3, fase 4.

Lista de verificación de triaje (ejecuta antes que cualquier otra cosa)

• Cinco hechos capturados en bruto: privilegio / ejecutor / host de origen / registro de cambio / receptor
• Privilegio calificado: el nivel superior recibe ritmo de incidente inmediatamente
• Registro de cambio verificado para ESPECIFICIDAD, no solo existencia
• Antigüedad de la cuenta receptora y nombre verificados (firma de puerta trasera)
• Sesión ejecutante validada: el conjunto del Volumen 1 sobre el ejecutor
• Salud del host ejecutor verificada: EDR, acceso a LSASS, señales de volcado
• Veredicto de la bifurcación en la escritura: robado / mal utilizado / indocumentado / de emergencia (break-glass)
• Comms del caso movidas fuera de banda en el momento en que la bifurcación se aleja del veredicto 3
• Radio de impacto alcanzado: viaje de privilegios (4672), concesiones, creaciones, políticas, consentimientos
• Firmas de DCSync y Kerberoasting verificadas; resultados limpios registrados
• Integridad de registros verificada: 1102, vacíos, estado de agentes
• Lista de reversión construida con estado de verificación por ítem
• Camino de llegada identificado: qué incidente anterior está debajo
• Casos de ruta 2: vías del Volumen 7 activas (sin contacto, RR.HH., legal, evidencia hasheada)

CONSEJO DE CAMPO: Si solo recuerdas una cosa de este volumen, son los cinco hechos. Que tres de cinco tuvieran una “forma incorrecta” fue el único indicio que distinguió una puerta trasera real de un mantenimiento rutinario en el recorrido de la Sección 6. Captúralos en bruto, antes de que formes una hipótesis, porque los revisores y (potencialmente) los abogados de la contraparte verificarán lo que viste frente a lo que asumiste.

Qué contiene un paquete de escalación completo

• Los cinco hechos verbatim de los eventos puros, con el analítico como puntero únicamente.
• El veredicto de la bifurcación con la evidencia de sesión y host que lo respalda.
• El inventario del radio de impacto: mapa de viaje, concesiones, creaciones, cambios de política, evaluación de exposición de credenciales.
• La lista de reversión con estado de verificación por ítem.
• Hallazgos de integridad de registros, incluyendo resultados limpios explícitos.
• El camino de llegada, acciones tomadas con marcas de tiempo, y el plan de ruta confiable para cualquier cosa que aún no se haya hecho.

Investigación 1

Campo	Valor
Encabezado de la investigación	ID del caso: ____________ Fecha/hora de apertura: ____________
Privilegio	____________
Ejecutor	____________
Host de origen	____________
Registro de cambio	____________
Receptor / antigüedad	____________
Bifurcación	S / M / U / BG

Hallazgos (calidad de sesión, salud del host, evidencia de la bifurcación)

Campo	Valor
Inventario del radio de impacto y línea de tiempo (viaje / concesiones / políticas / registros)
Lista de reversión (ítem / revertido por / verificado a las)
Camino de llegada y causa raíz
Acciones tomadas	Marcas de tiempo, notas de ruta confiable, aprobador donde sea requerido
Recomendaciones y retroalimentación de detección

Investigación 2

Campo	Valor
Encabezado de la investigación	ID del caso: ____________ Fecha/hora de apertura: ____________
Privilegio	____________
Ejecutor	____________
Host de origen	____________
Registro de cambio	____________
Receptor / antigüedad	____________
Bifurcación	S / M / U / BG

Hallazgos (calidad de sesión, salud del host, evidencia de la bifurcación)

Campo	Valor
Inventario del radio de impacto y línea de tiempo (viaje / concesiones / políticas / registros)
Lista de reversión (ítem / revertido por / verificado a las)
Camino de llegada y causa raíz
Acciones tomadas	Marcas de tiempo, notas de ruta confiable, aprobador donde sea requerido
Recomendaciones y retroalimentación de detección

Glosario - Términos que encontrarás en el turno

Término	Definición
Cuenta privilegiada	Cualquier identidad cuyos derechos excedan el radio de impacto de un usuario estándar: admins de dominio y nube, admins operativos, derechos de helpdesk delegados, cuentas de servicio privilegiadas, break-glass.
Radio de impacto	Todo lo que una cuenta puede leer, cambiar, crear o destruir. La unidad de alcance de todo este volumen.
Cuenta de puerta trasera	Una cuenta creada por un atacante, a menudo mimetizando nombres reales, otorgada con privilegios para sobrevivir a la pérdida de credenciales robadas.
Los cinco hechos	Privilegio movido, ejecutor, host de origen, estado del registro de cambio, receptor y antigüedad. El esqueleto de triaje de cada alerta de privilegios.
PIM / elevación justo a tiempo	Gestión de Identidades Privilegiadas: privilegio otorgado temporalmente bajo solicitud en lugar de ser sostenido permanentemente. Las asignaciones permanentes fuera de él son hallazgos.
Cuenta de emergencia (break-glass)	Acceso de emergencia deliberadamente exento de los controles normales. Cualquier uso es una alerta; cualquier uso no explicado es un incidente; cada uso termina con una re-credencialización.
DCSync	Abuso de derechos de replicación de directorio para solicitar cada hash de credencial en el dominio. El Evento 4662 con GUIDs de replicación desde una cuenta que no es de DC es su firma.
Kerberoasting	Solicitud de tickets de servicio (4769) para cuentas con contraseñas débiles y crackeo de las mismas fuera de línea. Las cuentas de servicio privilegiadas son el premio.
Acceso a LSASS	Lectura del proceso de Windows que contiene las credenciales en caché. La firma del volcado de credenciales en un host comprometido.
KRBTGT	La cuenta cuyo secreto firma todos los tickets de Kerberos. Rotada dos veces, espaciadas correctamente, para invalidar tickets de Kerberos falsificados después de un compromiso profundo.
Respuesta por ruta confiable	Contención ejecutada desde dispositivos conocidos como limpios con credenciales de emergencia o recién emitidas, sobre canales fuera de banda, porque el atacante puede controlar los canales normales.
Lista de reversión	Cada concesión, cuenta y cambio que el abuso creó, cada uno revertido y verificado. La persistencia vive en los ítems que olvidas.
Evento 1102	Registro de auditoría borrado. Auto-eliminación: tanto evidencia como una campana de alarma por sí misma.
Estación de trabajo de acceso privilegiado	Una máquina endurecida y dedicada para trabajo de admin, de modo que las credenciales de admin nunca se almacenen en caché donde los robadores rondan.

---

Sección 8 - Referencia rápida

La versión de una sola página. Mantén esto abierto en el turno.

Primeros diez minutos

• Captura los cinco hechos en bruto: privilegio, ejecutor, host de origen, registro de cambio, receptor y antigüedad.
• Verifica el registro de cambio para ESPECIFICIDAD. Las ventanas vagas no cubren las adiciones a grupos.
• Califica el privilegio: Domain Admins, Global Admin, GPO, federación, break-glass reciben ritmo de incidente inmediatamente.
• Mira un salto hacía atrás: la sesión ejecutante y el host contienen la respuesta de la bifurcación.

La bifurcación

• Robado: Stack del Volumen 1 detrás del ejecutor, señales de volcado en el host. Planifica como si te vieran; ve fuera de banda.
• Mal utilizado: sesiones propias del titular, acciones que sirven a la persona, ninguna historia sobrevive al chequeo de canal. Vías del Volumen 7.
• Indocumentado: la gestión confirma a través de canales. Cierra, mantén el hallazgo de proceso.
• Break-glass: verifica la emergencia a través del liderazgo; re-credencializa después de cada uso sin importar nada.

Si es robado

• Solo terreno confiable: dispositivo limpio, credenciales de emergencia o frescas, comunicaciones fuera de banda.
• Orden: puertas traseras primero, cuenta de origen segunda, reversiones terceras (verificadas), rotación según lo que el radio de impacto dicte.
• Verifica las firmas catastróficas: DCSync (4662 + GUIDs), borrado de registros (1102). Registra los resultados limpios explícitamente.
• Encuentra el camino de llegada; el incidente anterior está en el alcance.

SIEMPRE: Niega el cierre plausible. Dos minutos de disciplina de cinco hechos contra el costo de una puerta trasera omitida. El indicio de una cuenta de servicio iniciando sesión de forma interactiva es un indicio por sí mismo; trátalo de esa manera. Cada nota de cierre privilegiada nombra una brecha y un propietario: PAW, PIM, MFA en la elevación, bloqueo de cuentas de servicio privilegiadas, reenvío de registros de DC a algún lugar al que los admins no puedan llegar, y alertas sobre los eventos exactos en está tabla de trucos.

---

Bonus - Cómo aparece el abuso de privilegios en tu entrevista

Yo realizo entrevistas técnicas para roles de analista e ingeniería, y los escenarios de privilegios son donde pongo a prueba la altitud: ¿entiende el candidato el radio de impacto, el problema de la respuesta observada y la disciplina que está clase de alertas demanda? Cinco preguntas en la forma exacta en que las hago, con lo que una respuesta sólida cubre. Cada respuesta es una sección de este libro de trabajo dicha en voz alta.

Preguntas de entrevista

Pregunta 1: Una alerta muestra una cuenta nueva añadida a Domain Admins a las 2 AM. Explícame cómo la investigarías.

Los cinco hechos, en orden, desde los eventos puros: qué privilegio, quién lo realizó, desde qué host, contra qué registro de cambio, otorgado a qué cuenta y qué tan antigua es. Los candidatos fuertes mencionan la firma de puerta trasera (cuenta nueva, nombre mimetizado, sin registro específico) y el falso positivo dominante (trabajo de admin indocumentado) al mismo tiempo, porque la disciplina consiste en diferenciarlos basándose en la evidencia en lugar de en las sensaciones.

Pregunta 2: La cuenta ejecutante pertenece a un admin real. ¿Eso lo resuelve?

No: la bifurca. Valida las sesiones del admin y la salud de su estación de trabajo, porque las credenciales de admin robadas realizan acciones COMO el admin real. Las sesiones limpias y el host limpio te mueven hacía el mal uso o el trabajo indocumentado; el stack del Volumen 1 o las señales de volcado significan que el admin es una víctima y un atacante externo sostiene las llaves. Los candidatos que tratan la identidad del ejecutor como la respuesta en lugar de la pregunta pierden toda está clase de alertas.

Pregunta 3: Confirmas que un atacante tiene Domain Admin. ¿Cómo cambia eso tu respuesta?

Todo se mueve a terreno confiable: dispositivos limpios, credenciales de emergencia o recién emitidas, comunicación fuera de banda, porque el atacante puede leer los canales normales y desactivar las herramientas normales. Luego el orden: sus puertas traseras primero, la cuenta robada segunda, reversiones verificadas terceras, rotación según lo que la evidencia dicte. La frase “asume que el atacante puede verte”, dicha temprano, es lo que estoy escuchando.

Pregunta 4: ¿Qué es DCSync y por qué un ID de evento importa tanto?

Abuso de derechos de replicación de directorio para solicitar cada hash de credencial en el dominio, visible como Evento 4662 con GUIDs de replicación desde una cuenta que no es de controlador de dominio. Importa porque su presencia rescopa el incidente a cada credencial que tienes, incluyendo la conversación sobre KRBTGT. Los candidatos que conocen la firma y lo que implica han estudiado bien; los candidatos que también mencionan registrar su ABSENCIA como un hallazgo explícito han hecho el trabajo.

Pregunta 5: ¿Cómo reducirías toda está clase de riesgo estructuralmente?

Reduce el privilegio permanente hacía cero con elevación justo a tiempo, pon el trabajo de admin en estaciones de trabajo de acceso privilegiado para que las credenciales dejen de almacenarse en caché donde los robadores rondan, MFA en el camino de elevación, bloquea e inventaria las cuentas de servicio privilegiadas, reenvía los registros de DC a algún lugar al que los admins no puedan llegar, y alerta sobre los eventos exactos en está tabla de trucos de este volumen. La respuesta ganadora trata el privilegio como una cantidad a minimizar, no como un activo a monitorear.

Ese es el libro de trabajo, amigos. Cinco hechos, la bifurcación, el radio de impacto, el terreno confiable y el rechazo al cierre fácil. Las alertas de privilegios son raras; el día que una sea real, está disciplina es la diferencia entre una puerta trasera de once minutos y una brecha en todo el dominio. Otros volúmenes en está serie cubren las otras alertas con las que vivirás en el turno.

Jbird, jbirdcyber.gumroad.com