User and Machine Accounts

User accounts se crean tanto en sistemas locales (no unidos a AD) como en Active Directory para darle a una persona o a un programa (como un servicio del sistema) la capacidad de iniciar sesión en un computador y acceder a recursos basados en sus derechos. Cuando un usuario inicia sesión, el sistema verifica su contraseña y crea un access token. Este token describe el contenido de seguridad de un proceso o thread e incluye la identidad de seguridad del usuario y la pertenencia a grupos. Siempre que un usuario interactúa con un proceso, este token se presenta. User accounts se utilizan para permitir a empleados/contratistas iniciar sesión en un computador y acceder a recursos, ejecutar programas o servicios bajo un contexto de seguridad específico (es decir, ejecutando como un usuario con altos privilegios en lugar de una network service account), y para gestionar el acceso a objetos y sus propiedades, como network file shares, archivos, aplicaciones, etc. Los usuarios pueden ser asignados a grupos que pueden contener uno o más miembros. Estos grupos también se pueden utilizar para controlar el acceso a recursos. Puede ser más fácil para un administrador asignar privilegios una vez a un grupo (que todos los miembros del grupo heredan) en lugar de muchas veces a cada usuario individual. Esto ayuda a simplificar la administración y facilita otorgar y revocar los derechos de los usuarios.

La capacidad de provisionar y gestionar user accounts es uno de los elementos centrales de Active Directory. Típicamente, cada empresa que encontramos tendrá al menos una AD user account provisionada por usuario. Algunos usuarios pueden tener dos o más accounts provisionadas según su rol laboral (por ejemplo, un IT admin o miembro del Help Desk). Además de las standard user y admin accounts vinculadas a un usuario específico, a menudo veremos muchas service accounts utilizadas para ejecutar una aplicación o servicio en particular en segundo plano o realizar otras funciones vitales dentro del entorno del dominio. ¡Una organización con 1,000 empleados podría tener 1,200 active user accounts o más! También podemos ver organizaciones con cientos de disabled accounts de exempleados, empleados temporales/estacionales, pasantes, etc. Algunas empresas deben conservar registros de estas cuentas para fines de auditoría, por lo que las desactivarán (y con suerte eliminarán todos los privilegios) una vez que se termine la relación laboral, pero no las eliminarán. Es común ver una OU como FORMER EMPLOYEES que contendrá muchas cuentas desactivadas.

Como veremos más adelante en este módulo, los user accounts pueden ser provisionados con muchos derechos en Active Directory. Pueden configurarse como usuarios básicamente de solo lectura que tienen acceso de lectura a la mayoría del entorno (que son los permisos que recibe un standard Domain User) hasta Enterprise Admin (con control total sobre todos los objetos en el dominio) y una innumerable cantidad de combinaciones intermedias. Debido a que los usuarios pueden tener tantos derechos asignados, también pueden estar mal configurados con relativa facilidad y otorgar derechos no deseados que un atacante o un penetration tester puede aprovechar. Los user accounts presentan una enorme superficie de ataque y suelen ser un enfoque clave para obtener un punto de apoyo durante un penetration test. Los usuarios suelen ser el eslabón más débil en cualquier organización. Es difícil gestionar el comportamiento humano y tener en cuenta que cada usuario elija contraseñas débiles o compartidas, instale software no autorizado, o que los administradores cometan errores descuidados o sean demasiado permisivos con la gestión de cuentas. Para combatir esto, una organización debe tener políticas y procedimientos para enfrentar los problemas que pueden surgir alrededor de los user accounts y debe tener defense in depth para mitigar el riesgo inherente que los usuarios traen al dominio.

Los detalles sobre las malas configuraciones y ataques relacionados con usuarios están fuera del alcance de este módulo. Aun así, es importante comprender el gran impacto que los usuarios pueden tener dentro de cualquier Active Directory network y comprender las diferencias entre los diferentes tipos de usuarios/accounts que podemos encontrar.

Local Accounts

Local accounts se almacenan localmente en un servidor o workstation en particular. Estas cuentas pueden ser asignadas derechos en ese host ya sea individualmente o a través de la pertenencia a grupos. Cualquier derecho asignado solo se puede otorgar a ese host específico y no funcionará en todo el dominio. Local user accounts se consideran security principals, pero solo pueden gestionar el acceso y proteger los recursos en un host independiente. Hay varias default local user accounts que se crean en un sistema Windows:

Administrator: esta cuenta tiene el SID S-1-5-domain-500 y es la primera cuenta creada con una nueva instalación de Windows. Tiene control total sobre casi todos los recursos del sistema. No se puede eliminar ni bloquear, pero se puede desactivar o renombrar. Los hosts de Windows 10 y Server 2016 desactivan la cuenta de administrador incorporada por defecto y crean otra local account en el grupo de administradores locales durante la configuración.
Guest: esta cuenta está desactivada por defecto. El propósito de esta cuenta es permitir que los usuarios sin una cuenta en el computador inicien sesión temporalmente con derechos de acceso limitados. Por defecto, tiene una contraseña en blanco y generalmente se recomienda dejarla desactivada debido al riesgo de seguridad que representa permitir el acceso anónimo a un host.
SYSTEM: La cuenta SYSTEM (o NT AUTHORITY\SYSTEM) en un host Windows es la cuenta predeterminada instalada y utilizada por el sistema operativo para realizar muchas de sus funciones internas. A diferencia de la cuenta Root en Linux, SYSTEM es una service account y no se ejecuta completamente en el mismo contexto que un usuario regular. Muchos de los procesos y servicios que se ejecutan en un host se ejecutan bajo el contexto de SYSTEM. Una cosa a tener en cuenta con esta cuenta es que no existe un perfil para ella, pero tendrá permisos sobre casi todo en el host. No aparece en el User Manager y no se puede agregar a ningún grupo. Una cuenta SYSTEM es el nivel de permiso más alto que se puede lograr en un host Windows y, por defecto, se le otorgan permisos de Full Control sobre todos los archivos en un sistema Windows.
Network Service: Esta es una predefined local account utilizada por el Service Control Manager (SCM) para ejecutar servicios de Windows. Cuando un servicio se ejecuta en el contexto de esta cuenta en particular, presentará credenciales a servicios remotos.
Local Service: Esta es otra predefined local account utilizada por el Service Control Manager (SCM) para ejecutar servicios de Windows. Está configurada con privilegios mínimos en el computador y presenta credenciales anónimas a la red.

Vale la pena estudiar la documentación de Microsoft sobre local default accounts en profundidad para comprender mejor cómo las diferentes cuentas trabajan juntas en un sistema Windows individual y en una red de dominio. Tómate un tiempo para revisarlas y comprender las diferencias entre ellas.

Domain Users

Domain users se diferencian de los local users en que se les otorgan derechos desde el dominio para acceder a recursos como file servers, impresoras, hosts de intranet y otros objetos según los permisos otorgados a su user account o al grupo del cual esa cuenta es miembro. Las domain user accounts pueden iniciar sesión en cualquier host del dominio, a diferencia de los local users. Para obtener más información sobre los diferentes tipos de Active Directory account, consulta este enlace. Sin embargo, hay que tener en cuenta una cuenta en particular: la cuenta KRBTGT. Esta es un tipo de local account incorporada en la infraestructura de AD. Esta cuenta actúa como una service account para el Key Distribution Service, proporcionando autenticación y acceso a recursos del dominio. Esta cuenta es un objetivo común de muchos atacantes, ya que obtener control o acceso permitirá a un atacante tener acceso sin restricciones al dominio. Puede ser aprovechada para escalación de privilegios y persistencia en un dominio a través de ataques como el Golden Ticket.

User Naming Attributes

La seguridad en Active Directory puede mejorarse utilizando un conjunto de user naming attributes para ayudar a identificar objetos de usuario como logon name o ID. A continuación se muestran algunos Naming Attributes importantes en AD:


`UserPrincipalName` (UPN)	Este es el primary logon name del usuario. Por convención, el UPN utiliza la dirección de correo electrónico del usuario.
`ObjectGUID`	Este es un identificador único del usuario. En AD, el nombre del atributo ObjectGUID nunca cambia y permanece único incluso si el usuario es eliminado.
`SAMAccountName`	Este es un logon name que admite la versión anterior de clientes y servidores de Windows.
`objectSID`	El Security Identifier (SID) del usuario. Este atributo identifica a un usuario y sus pertenencias a grupos durante las interacciones de seguridad con el servidor.
`sIDHistory`	Esto contiene SIDs anteriores para el objeto de usuario si se trasladó desde otro dominio y se ve típicamente en escenarios de migración de dominio a dominio. Después de que ocurre una migración, el último SID se agregará a la propiedad `sIDHistory` y el nuevo SID se convertirá en su `objectSID`.

Common User Attributes

PS C:\htb Get-ADUser -Identity htb-student

DistinguishedName : CN=htb student,CN=Users,DC=INLANEFREIGHT,DC=LOCAL
Enabled           : True
Given

Name         : htb
Name              : htb student
ObjectClass       : user
ObjectGUID        : aa799587-c641-4c23-a2f7-75850b4dd7e3
SamAccountName    : htb-student
SID               : S-1-5-21-3842939050-3880317879-2865463114-1111
Surname           : student
UserPrincipalName : htb-student@INLANEFREIGHT.LOCAL

Para una visión más profunda de los atributos de objetos de usuario, consulta esta página. Se pueden configurar muchos atributos para cualquier objeto en AD. Muchos objetos nunca se utilizarán o no son relevantes para nosotros como profesionales de seguridad. Aun así, es esencial familiarizarnos con los más comunes y los más oscuros que pueden contener datos sensibles o ayudar a montar un ataque.

Domain-joined vs. Non-Domain-joined Machines

Cuando se trata de recursos informáticos, hay varias formas en que generalmente se gestionan. A continuación, discutiremos las diferencias entre un host unido a un dominio y un host que solo está en un workgroup.

`Domain joined`

Los hosts unidos a un dominio tienen mayor facilidad para compartir información dentro de la empresa y un punto de gestión central (el DC) para reunir recursos, políticas y actualizaciones. Un host unido a un dominio adquirirá cualquier configuración o cambio necesario a través del Group Policy del dominio. El beneficio aquí es que un usuario en el dominio puede iniciar sesión y acceder a recursos desde cualquier host unido al dominio, no solo desde el que trabaja. Esta es la configuración típica que verás en entornos empresariales.

`Non-domain joined`

Las computadoras no unidas al dominio o las computadoras en un workgroup no están gestionadas por la política de dominio. Con eso en mente, compartir recursos fuera de tu red local es mucho más complicado de lo que sería en un dominio. Esto está bien para computadoras destinadas al uso doméstico o pequeños clusters empresariales en la misma LAN. La ventaja de esta configuración es que los usuarios individuales están a cargo de cualquier cambio que deseen realizar en su host. Cualquier user account en una computadora de workgroup solo existe en ese host, y los perfiles no se migran a otros hosts dentro del workgroup.

Es importante señalar que una machine account (NT AUTHORITY\SYSTEM nivel de acceso) en un entorno de AD tendrá la mayoría de los mismos derechos que una standard domain user account. Esto es importante porque no siempre necesitamos obtener un conjunto de credenciales válidas para la cuenta de un usuario individual para comenzar a enumerar y atacar un dominio (como veremos en módulos posteriores). Podemos obtener acceso a nivel SYSTEM a un host Windows unido a un dominio a través de un exploit de remote code execution exitoso o escalando privilegios en un host. Este acceso a menudo se pasa por alto como solo útil para saquear datos sensibles (por ejemplo, contraseñas, claves SSH, archivos sensibles, etc.) en un host en particular. En realidad, el acceso en el contexto de la cuenta SYSTEM nos permitirá tener acceso de lectura a gran parte de los datos dentro del dominio y es un gran punto de partida para reunir la mayor cantidad de información posible sobre el dominio antes de proceder con ataques relacionados con AD.