cuentas compartidas AD: atribuir los inicios de sesión

Qué debe establecer la atribución de cuentas compartidas AD

La atribución de cuentas compartidas AD empieza con una distinción: una cuenta de directorio es un principal de seguridad, mientras que un operador es la persona que la utiliza. Una cuenta llamada shared-support puede merecer una revisión, pero su nombre no demuestra que varias personas conozcan sus credenciales. Un inicio de sesión con esa cuenta puede establecer su uso sin identificar a la persona que está detrás.

Trate un hallazgo basado en el nombre como una cola de investigaciones. Para cada cuenta seleccionada, establezca su propietario, finalidad real, usuarios autorizados, sistemas dependientes y pruebas de inicio de sesión disponibles. Mantenga la observación del directorio, las pruebas de autenticación y la atribución humana como conclusiones separadas. Una dependencia legítima de un servicio y una sesión humana sin atribución requieren respuestas diferentes, aunque utilicen el mismo nombre de cuenta.

Nuestra revisión de clasificación, propiedad y caducidad de cuentas explica cómo aclarar los nombres genéricos y la finalidad de las cuentas. Esta guía añade los requisitos de prueba para atribuir actividad: qué identidad describe cada evento de Windows, dónde correlacionarla y qué sigue sin conocerse antes de retirar la cuenta.

Cómo funciona el proceso de evaluación

1. Crear un expediente para cada cuenta

Registre el dominio de la cuenta, su nombre SAM, SID, estado actual de habilitación, momento de recopilación, propietario responsable y uso previsto. Enumere los servicios, tareas programadas, aplicaciones, procedimientos administrativos y requisitos de recuperación conocidos. El propietario es responsable de resolver el caso; la propiedad por sí sola no establece quién realizó un inicio de sesión concreto.

Pregunte al propietario qué personas pueden obtener o utilizar las credenciales y por qué vías de acceso. Separe la autorización documentada del uso observado. Si el propietario afirma que solo una persona utiliza la cuenta, conserve esa declaración como una afirmación que debe contrastarse con las pruebas. Si nadie puede identificar al propietario, mantenga el caso abierto con una persona identificada como responsable del siguiente paso de investigación.

Revise también las cuentas deshabilitadas. El detector incluye usuarios deshabilitados cuyos nombres coinciden, por lo que su recuento no es un recuento de sesiones compartidas activas. Preserve las pruebas históricas disponibles y verifique las dependencias antes de decidir si puede retirarse un objeto deshabilitado. El estado actual del directorio no establece lo ocurrido durante un intervalo de investigación anterior.

2. Definir el alcance de las pruebas antes de buscar

Identifique las estaciones de trabajo o equipos de administración iniciadores, los servidores de destino y el intervalo de tiempo pertinente. Verifique cuáles de esos sistemas generan y reenvían los eventos Security necesarios. Ambas páginas de eventos los sitúan bajo Audit Logon. La recopilación únicamente desde controladores de dominio no establece la cobertura de todas las sesiones de destino o procesos iniciadores.

Para el inventario más amplio de directivas de auditoría y eventos, consulte nuestra guía de eventos y recopilación para la supervisión de Active Directory. En este caso, la pregunta operativa es más concreta: ¿puede el equipo recuperar las pruebas de esta cuenta, en estos equipos, durante este intervalo, conservando los campos de identidad?

Documente la retención local, las lagunas de reenvío, el comportamiento del analizador, las limitaciones de acceso y la sincronización de los relojes antes de extraer una conclusión negativa. Preserve el XML original del evento o un registro equivalente sin pérdida junto con los campos normalizados. Una columna del SIEM llamada Account puede ocultar si el analizador seleccionó Subject o Target; valide esa correspondencia con el propio evento.

Detección: separar las identidades de 4624 y 4648

3. Leer la sesión correcta en el destino

La referencia de Microsoft del evento 4624 lo define como la creación de una sesión de inicio de sesión en el equipo al que se accede. Subject describe la cuenta que informa del inicio de sesión o lo invoca; New Logon describe la cuenta para la que se creó la sesión. No atribuya la sesión a una persona leyendo únicamente Subject.

Mantenga separados estos campos del evento en el expediente:

Por ejemplo, Logon Type 3 describe un inicio de sesión de red, 4 uno por lotes, 5 uno de servicio y 10 uno interactivo remoto. Estas descripciones ayudan a comprobar si el uso observado se ajusta a la finalidad declarada por el propietario. No son veredictos de atribución humana: una sesión de red puede iniciarse mediante automatización, y una sesión de servicio no identifica a la persona que la configuró.

La referencia de 4624 también explica que la disponibilidad de dirección, puerto y estación de trabajo depende del contexto y el protocolo de autenticación. Un campo de origen vacío debe permanecer vacío en el registro de pruebas; no lo complete a partir de otro evento solo porque coincida el nombre de cuenta. El SID de la cuenta compartida identifica ese principal, no cuál de sus posibles usuarios actuó.

4. Leer las credenciales explícitas sin intercambiar las identidades

La referencia de Microsoft del evento 4648 describe un proceso que intenta iniciar sesión con credenciales proporcionadas explícitamente. Esto también ocurre durante actividades habituales, incluidas las tareas programadas y RUNAS. Subject es la cuenta solicitante; Account Whose Credentials Were Used es la identidad de las credenciales. Pueden ser cuentas diferentes.

Un registro 4648 con un Subject nominativo y un Target compartido constituye una prueba útil de que ese contexto de seguridad nominativo solicita utilizar las credenciales compartidas. No establece por sí solo quién controla ese contexto. También describe un intento; no lo convierta en un inicio de sesión correcto en el destino sin pruebas que lo sustenten. El XML del evento incluye el nombre, dominio y GUID del destino; no suponga que proporciona un SID de destino solo porque un esquema normalizado tenga una columna para él.

5. Correlacionar en el equipo y la sesión correctos

Parta del equipo, la marca de tiempo y la sección de identidad pertinentes. Las indicaciones de Microsoft para correlacionar Logon ID limitan su unicidad a un equipo entre reinicios. Mantenga las uniones por Logon ID dentro de ese equipo y ese intervalo entre arranques, sin extenderlas a todo el dominio. Para un 4648 iniciador, busque la sesión 4624 local correspondiente utilizando el contexto de inicio de sesión de Subject de 4648 y el contexto de New Logon de 4624. Unir Subject con Subject indiscriminadamente responde a otra pregunta.

Conserve los dos GUID de 4648. Las referencias de Microsoft describen la correlación 4624/4648 en el mismo equipo cuando está disponible el GUID pertinente. No debe seleccionarse automáticamente ni un GUID de Subject ni uno de credenciales solo porque un analizador haya renombrado ambos como un único campo genérico. Establezca qué sesión representa la coincidencia propuesta y conserve el fundamento de esa decisión.

Un GUID que contiene solo ceros es una prueba no disponible, no una sesión común a todos los registros que contienen ceros. Entre los equipos iniciadores y de destino, construya una cronología con cuenta y dominio, equipo de destino, contexto de origen disponible y marcas de tiempo. Etiquete esa asociación como contextual cuando no exista un vínculo fiable de sesión. Nunca equipare Logon ID hexadecimales idénticos en dos equipos.

6. Registrar la confianza y las explicaciones contradictorias

Utilice categorías explícitas de confianza como convención de revisión, no como un sistema de puntuación de Microsoft. Puede confirmarse el uso de la cuenta mientras la atribución humana sigue sin resolverse. Mantenga columnas separadas para esas conclusiones en lugar de asignar una única puntuación tranquilizadora a todo el caso.

Las pruebas independientes podrían ser un registro de una pasarela de acceso con autenticación individual o de retirada de credenciales, si la organización dispone de él y pueden verificarse sus marcas de tiempo e identidades. Una lista de personas, una dirección IP o únicamente los recuerdos del propietario son pruebas más débiles. Registre alternativas como una automatización programada u otra persona que controle la sesión iniciadora; documente por qué la explicación retenida está mejor sustentada.

Esto es un procedimiento de investigación, no una consulta presentada como ejecutada. No se realizó ninguna prueba en equipos ni en un SIEM para esta guía. Valide las correspondencias de campos y las correlaciones con actividad controlada y autorizada antes de utilizarlas operativamente.

Restablecer la responsabilidad antes de retirar la cuenta (Remediation)

7. Sustituir el acceso humano compartido por acceso nominativo

Para los procedimientos humanos, planifique el acceso mediante identidades individuales de operadores y verifique que los registros conservan la identidad individual hasta la acción privilegiada. Cambiar shared-support por un nombre de apariencia personal no crea responsabilidad atribuible. Confirme quién puede obtener las credenciales, cómo se aprueba el acceso y cómo puede retirarse cuando cambia la función de una persona.

Para la automatización, documente la carga de trabajo y su propietario por separado de los operadores humanos. Revise las opciones de migración con el equipo de aplicaciones en lugar de imponer a un servicio un diseño de identidad interactiva. El objetivo es eliminar el uso compartido innecesario de credenciales, conservando las dependencias legítimas y un rastro de acceso que pueda revisarse.

Si no es posible sustituir el acceso de inmediato, documente una excepción temporal con propietario, finalidad aprobada, usuarios autorizados, equipos permitidos, pruebas compensatorias, caducidad y un hito de migración. Una excepción sin un rastro utilizable de atribución debe indicarlo explícitamente. Una caducidad futura no hace atribuible la sesión ambigua de hoy.

8. Deshabilitar solo una identidad revisada

Antes de retirar la cuenta, obtenga la evaluación de dependencias del propietario, compruebe las disposiciones de recuperación, preserve los registros de investigación y acuerde las responsabilidades de validación y reversión. Decida por separado si las pruebas justifican una respuesta a un compromiso. Un hallazgo basado únicamente en el nombre no establece un compromiso ni justifica una operación sobre credenciales en todo el entorno.

Para una cuenta ordinaria cuya retirada se haya aprobado, el siguiente ejemplo adapta los parámetros documentados de Disable-ADAccount. El DN y el controlador de dominio de escritura son ilustrativos; verifique ambos antes de usarlos. Estos ejemplos requieren el módulo ActiveDirectory y permisos en el directorio, y no se ejecutaron para este artículo.

Disable-ADAccount -Identity 'CN=shared-support,OU=Users,DC=contoso,DC=com' -Server 'dc01.contoso.com' -WhatIf

-WhatIf muestra una vista previa de la operación; no comprueba si una aplicación dejará de funcionar. Después de revisar las dependencias y en la ventana de cambio aprobada, la acción dirigida correspondiente es:

Disable-ADAccount -Identity 'CN=shared-support,OU=Users,DC=contoso,DC=com' -Server 'dc01.contoso.com' -Confirm

No canalice todas las coincidencias de nombre hacia una operación de deshabilitación. Verifique el estado resultante del directorio y los procedimientos dependientes después del cambio aprobado. La eliminación requiere una decisión separada sobre retención y recuperación; ni un recuento bajo del detector ni un intervalo sin eventos proporcionan esa autorización.

9. Cerrar con la decisión que sustentan las pruebas

Responda tres preguntas para cada cuenta: qué equipos y directivas de auditoría aportaron las pruebas necesarias; si existe una identidad nominativa independiente de operador; y qué dependencias requieren una excepción temporal antes de la eliminación. Si falta una respuesta, conserve la pregunta pendiente, el propietario responsable y la fecha de la próxima revisión.

Cierre con un resultado concreto: acceso humano sustituido, dependencia de carga de trabajo migrada, identidad innecesaria deshabilitada o excepción temporal mantenida. Adjunte la justificación de la confianza y las lagunas de pruebas. Una revisión completada debe explicar tanto la decisión operativa como los límites de cualquier afirmación sobre atribución histórica.

Cómo detecta EtcSec este caso

El control SHARED_ACCOUNT de etc-collector es un hallazgo de gravedad media en Accounts. En el commit del colector 0423094759d50002457031317098417993e19510, Detect() en public/internal/audit/detectors/ad/accounts/patterns/shared-account.go:45 compara el SAMAccountName de los usuarios recopilados con cuatro prefijos sin distinguir mayúsculas y minúsculas:

(?i)^shared
(?i)^common
(?i)^generic
(?i)^guest-

Son heurísticas del producto basadas en nombres. shared-support y CommonDesk coinciden; my-shared-support no coincide con ^shared porque el prefijo está anclado al principio. El control no incluye los prefijos service/svc, no examina quién conoce la contraseña ni determina cuántas personas utilizan una cuenta.

Cada usuario coincidente se añade una vez y después se detiene el bucle interno de patrones. Count es el número de usuarios recopilados coincidentes, incluidas las cuentas deshabilitadas: no hay filtro por estado de habilitación. Cuando se solicitan detalles y existen coincidencias, el hallazgo incluye las entidades de usuario afectadas. La función devuelve un hallazgo incluso cuando Count es cero.

El proveedor LDAP aporta usuarios y atributos del directorio, no el historial de eventos 4624/4648 ni una identidad de operador. Este Detect no correlaciona sesiones, demuestra el uso compartido de credenciales, evalúa registros independientes de atribución ni verifica una retirada aprobada. Un resultado positivo abre el proceso de evaluación anterior; un recuento cero solo establece que ningún nombre recopilado coincidía con esas expresiones, no que todo uso de cuentas sea atribuible.