Análisis y detección de Hoaxshell "¿una la shell indetectable?"

Hoaxshell proporciona de forma client-side una shell inversa que por el momento Microsoft Defender y posiblemente otros motores de AVs no están detectando ya que se basa únicamente en el tráfico http y https, según nos comenta su desarrollador. Aunque más adelante veremos como esto puede ser detectado a nivel de eventos de Windows y no por eventos producidos en la red.

Hoaxshell: obteniendo una shell remota

Nos descargamos el repositorio e instalamos el requirements.txt de python.

git clone https://github.com/t3l3machus/hoaxshell

cd ./hoaxshell

sudo pip3 install -r requirements.txt

chmod +x hoaxshell.py

Existen principalmente dos modos de ejecutar Hoaxshell o bien de forma normal donde hace uso del puerto 8080/http o bien usando un canal cifrado SSL usando el puerto 443/https, para este segundo es necesario generar un certificado auto firmado.

sudo python3 hoaxshell.py -s <your_ip>

Figura 1: Ejecución de hoaxshell obteniendo una shell inversa.

Buscando indicadores de compromiso para la detección de Hoaxshell

Analizando el tráfico de red

Si analizamos la comunicación de red una vez hemos lanzado el ataque de ejecución de la shell sin cifrar (8080/http) se monta un servidor web apache con una URI generada aleatoriamente donde la máquina víctima descargará el payload automáticamente cuando lo ejecute. Este es posible a través del llamada Invoke-WebRequest incluido en el payload codificado en base64 que veremos descodificado más adelante.

Figura 2: Hoaxshell sin cifrar - Detección de tráfico de red.

En el caso de lanzar el ataque con un certificado auto firmado vía 443/https en la captura de tráfico vemos el establecimiento de conexión Client Hello de TLS y el intercambio de claves en el handshake entre cliente/servidor. Por otro lado esto también nos genera un evento en el provider de Powershell en el cual vemos texto claro la decodificación del payload que se ejecutó en base64.

Figura 3: Hoaxshell cifrando - Detección de tráfico de red.

Analizando los eventos de Windows

En este parte ha colaborado el compañero @noloseconseguridad el cual ha podido identificar y crear los indicadores de compromiso para la detección de Hoaxshell.

En un primer momento revisamos de forma manual en el visor de eventos a ver que logs se están registrando relacionados con el provider de Powershell. 

Ejecutando con Hoaxshell una shell sin una comunicación cifrada encontramos en el registro "Microsft-Windows-Powershell/Operational" un evento con Id. 4103 en el que vemos un CommandInvocation seguido de un Invoke-Expression donde tenemos un parámetro con el nombre name="Command" que tiene un valor: whoami;split-path $pwd'\0x00'. 

Podemos saber gracias a esto, el comando ejecutado y tenemos una string la cual podemos utilizar para crear una expresión regular y generar un IOC.

;split-path $pwd'\0x00'

Figura 4: Event Id. 4103 de Powershell generado por la ejecución de Hoaxshell sin comunicación cifrada.

El payload de Hoaxshell se genera codificado en base64 tanto para obtener una shell sin cifrar como cifrada, en el caso de lanzar una shell cifrada lógicamente el tamaño del payload será más largo. Decodificando este payload podemos ver lo que está haciendo para poder invocar la shell inversa que después se nos proporciona.

Figura 5: Decodificando payload de Hoaxshell en base64.

Lanzando el ataque en su modo de comunicación cifrada vemos que nos genera en el provider de Powershell los eventos Id. 4103 e Id. 4104 mostrando en texto claro las instrucciones del scriptblock de Powershell y que coincide con la decodificación vista anteriormente en la figura 5.

Figura 6: Event Id. 4103 y 4104 de Powershell generado por la ejecución de Hoaxshell con comunicación cifrada.

Creando IOC y reglas de detección en Wazuh

En este escenario vamos a utilizar Wazuh como SIEM para la creación de los indicadores de compromiso y generar una regla de detección cuando se registre un evento relacionado con un posible ataque de Hoaxshell. Lógicamente esto puede ser exportable a otros formatos de reglas compatibles para otros sistemas de monitorización de eventos de seguridad.

En el caso de Wazuh añadimos al fichero agent.conf el provider de registro de Powershell indicando la recolección de este tipo de eventos.

Figura 7: Añadir el provider de registro Powershell/Operational.

En el fichero local_rules.xml creamos las reglas para su detección, la última regla será la que realmente nos registre el posible ataque indicando el eventID 4103 y los posibles IOCs vistos anteriormente. 

 <rule id="100535" level="0">

  <if_sid>60009</if_sid>

  <field name="win.system.providerName">^Microsoft-Windows-PowerShell$</field>

  <group>powershell,</group>

  <description>Powershell Information EventLog</description>

</rule>

<rule id="100536" level="0">

  <if_sid>60010</if_sid>

  <field name="win.system.providerName">^Microsoft-Windows-PowerShell$</field>

  <group>powershell,</group>

  <description>Powershell Warning EventLog</description>

</rule>

<rule id="100537" level="0">

  <field name="win.system.providerName">^Microsoft-Windows-PowerShell$</field>

  <field name="win.system.severityValue">^ERROR$</field>

  <group>powershell,</group>

  <description>Powershell Error EventLog</description>

</rule>

<rule id="100538" level="0">

  <if_sid>60012</if_sid>

  <field name="win.system.providerName">^Microsoft-Windows-PowerShell$</field>

  <group>powershell,</group>

  <description>Powershell Critical EventLog</description>

</rule>

  

<rule id="100540" level="12">

  <if_sid>100535</if_sid>

  <field name="win.system.eventID">4103</field>

  <field name="win.system.message" type="pcre2">(?i)powershell.exe.*-e</field>

  <field name="win.system.message" type="pcre2">(?i)Command.*;split-path.\$pwd.\\0x00</field>

  <field name="win.system.message" type="pcre2">(?i)Invoke-Expression</field>

  <description>Powershell hoaxshell detected</description>

</rule>

Por lo que se pudo comprobar y dado los indicadores de compromiso encontrados la detección es exitosa tanto si se ejecuta Hoaxshell en un modo de payload sin cifrar como con una comunicación cifrada.

Figura 8: Creación de reglas de detección e IOCs de Hoaxshell.

Con la regla guarda, ejecutamos de nuevo Hoaxshell y... bingo! vemos como nos está detectando la ejecución y generación de sesión de este tipo de shell en Powershell.

Figura 9: Alerta en la ejecución de un "Powershell hoaxshell detected"

Conclusiones

Podemos decir entonces que "esa shell indetectable" quizás no lo es tanto. Si bien es cierto que actualmente no está siendo detectada automáticamente por Microsoft Defender como protección por defecto en un sistema Windows y es posible que otros motores de antivirus tampoco lo estén haciendo hay que saber que estableciendo unas políticas de auditoría habilitadas en las máquinas, prácticamente todo deja un rastro que se acaba traduciendo en un evento o registro de log del sistema.

Sobre el tipo de payload cifrado o sin cifrar que podemos generar con Hoaxshell vemos que a nivel de evento de sistema es detectable, sin embargo a nivel de comunicación de red es realmente donde está su ventaja ya que en una comunicación sin cifrar podemos identificar la URI que genera pero en una comunicación cifrada la comunicación es TLS y no podría ser leída en un primer intento de detección.

Personalmente me resulta curioso que MS Defender no esté detectando una simple ofuscación codificada en base64 a través de Powershell y que su vez no haga un monitoreo continuo de los eventos registrados donde se encuentran decodificados. Aunque estoy seguro de que Microsoft no tardará mucho en poner solución a esto y más con el revuelo que está habiendo actualmente con Hoaxshell y su facilidad de uso.

Con la colaboración de @noloseconseguridad.

Saludos!

Detectar, alertar y bloquear intentos de conexión por fuerza bruta a escritorio remoto RDP

Antes de nada comentar que es una muy mala práctica y está totalmente desaconsejado publicar hacia internet servicios de escritorio remoto. RDP es de los servicios más comprometidos por atacantes externos, con más intentos de ataques y que facilitan un vector de entrada directo a la red de una empresa si el acceso se configura de esta forma.

En el caso de tener que publicar RDP a internet -sin una VPN o una conexión intermedia hacia un equipo bastión- aunque sea de una manera temporal, hay que hacerlo de la forma "más segura" posible.

Hardening o bastionado en servicios de Escritorio remoto RDP

Lista de acceso de usuarios mediante NLA y privilegios

• Habilitar autenticación a nivel de red NLA (Network Level Authentication) por defecto ya lo está en servidores.
• Añadir solo a los usuarios permitidos en el grupo "Usuarios de escritorio remoto".
• Establecer contraseñas largas y robustas para los usuarios que se les permita autenticarse.
• Restringir el inicio de sesión a través de RDP a usuarios Administradores y permitirlo solamente a usuarios específicos.
• Estos usuarios no deben de ser Administradores locales o dominio. En caso de necesitar elevar privilegios hacer uso de UAC una vez iniciada la sesión en los binarios o aplicaciones que necesitemos ejecutar en dicho contexto de integridad.
• Establecer un port forwarding en otro puerto que no sea el 3389 RDP por defecto.

Bloqueo de cuenta por intentos fallidos de inicio de sesión

• Vía directiva de grupo GPO.
• A través del registro de Windows.
• Establecer un umbral de tiempo de desbloqueo considerable para evitar ataques de fuerza bruta automatizados y repetitivos en cortos intervalos de tiempo.

Otras medidas de seguridad adicionales para un bastionado en servicios RDP

• Establecer límite de tiempo para sesiones activas, pero en inactividad.
• No permitir que se guarden las contraseñas.
• Solicitar la contraseña siempre al conectar.
• Requerir comunicación RPC segura.
• Requerir el uso de un nivel de seguridad específico para conexiones remotas (RDP).
• Habilitar el nivel de cifrado "Alto".
• Permitir solo determinadas un ámbito de direcciones IPs remotas en el Firewall del servidor RDP.
• No permitir redirecciones de componentes:
• No permitir redirección de unidades.
• No permitir redirección portapapeles.
• No permitir redirección COM. 
• No permitir redirección LPT.
• No permitir redirección dispositivos Plug and Play.
• No permitir redirección dispositivos USB RemoteFX.
• No permitir redirección de impresoras de red.

Este artículo no se centra en la identificación, investigación y seguimiento de los eventos relacionados con el servicio RDP, para eso dejo esta buena referencia de estudio sobre logs RDP. Al igual que unas diapositivas que representan los diagramas de flujo de conexiones RDP. 

Está enfocado especialmente a los intentos de conexión originados desde máquinas externas hacia servicios RDP expuestos de forma pública a internet, aunque también es aplicable a conexiones de equipos remotos entre redes internas.

Detectar evento de intento de conexión TCP hacia RDP

Cuando se realiza un intento de conexión RDP hacia un equipo y este tiene la autenticación NLA habilitada lo primero que se genera son eventos de conexión de red, después de autenticación y finalmente un login satisfactorio, fallido o reconexiones de sesión.

Haciendo referencia al conjunto de diapositivas anteriores de diagramas de flujo de conexiones RDP. Se destacan principalmente dos eventos del ProviderName "Microsoft-Windows-TerminalServices-RemoteConnectionManager" el event ID 261 y 1149.

• Event ID 261: Se trata del primer evento que se produce indicando que el puerto RDP-Tcp que estaba escuchando recibió una conexión.
• Event ID 1149: NO indica una autenticación exitosa a un objetivo, simplemente una conexión de red RDP exitosa.

Figura 1: Event ID 261 y 1149.

El evento 1149 es interesante ya que nos muestra el login de usuario empleado en el intento de conexión hacia los servicios RDP, pero ninguno de estos eventos nos da información sobre la IP origen remota que realizó esta conexión al intentar autenticarse.

En el siguiente flujograma se puede observar que con NLA habilitado el primer evento de conexión de red que se genera es el event ID 131 correspondiente al ProviderName "Microsoft-Windows-RemoteDesktopServices-RdpCoreTS".

Figura 2: Flujograma de alerta de eventos y bloqueo de una conexión RDP (fuente imagen).

El event ID 131 ya nos aporta la dirección IP remota y puerto TCP origen que realizó la solicitud de conexión a los servicios de escritorio remoto. Teniendo esta información ya podremos automatizar una detección, generar una alerta y bloquear la conexión localmente en el Firewall de Windows como veremos más adelante.

Figura 3: Detectando evento de conexión TCP hacia RDP (event id 131).

Automatizar las detecciones y crear alertas de los intentos de conexión RDP

Para detectar este evento de forma automática y alertarnos de ello, primero se creará un fichero por lotes .bat el cual simplemente se usará para realizar la llamada al script Powershell a través de la acción de la tarea programada que se creará más adelante.

Script .bat.

powershell.exe -ExecutionPolicy Bypass -File "C:\Users\adrian\Tools\Scripts\RDPBruteForce\Hunting_RDPBruteForce.ps1"

Comentaré dos formas para generar las notificaciones de alerta: vía Slack o correo Gmail y aunque se trate de una cuenta sin importancia y dedicada a ello tenemos que intentar no hardcodear passwords en texto plano en los scripts por lo que crearemos una password cifrada y almacenada en un fichero que solo podrá ser leída desde el equipo local que la creó.

"MiPassword" | ConvertTo-SecureString -AsPlainText -Force | ConvertFrom-SecureString | Out-File "C:\Users\adrian\Tools\Scripts\RDPBruteForce\email.pass"

El siguiente script Powershell enviará una alerta de email notificando un nuevo intento de conexión correspondiente al event ID 131.

$PSDefaultParameterValues['*:Encoding'] = 'utf8'

$usuarioEmail = "EMAIL@gmail.com" 

$passwdEmailFile = "C:\PATH\email.pass"

$secPasswdEmail = Get-Content $passwdEmailFile | ConvertTo-SecureString

$credencialesEmail = New-Object System.Management.Automation.PSCredential ($usuarioEmail, $secPasswdEMail)

$asuntoEmail = "Intento de conexión RDP"

$cuerpoEmail = Get-WinEvent -ProviderName "Microsoft-Windows-RemoteDesktopServices-RdpCoreTS" | Where-Object {$_.Id -eq "131"} | Format-List | Select -First 3 | Out-String

Send-MailMessage -From $usuarioEmail -To $usuarioEmail -Subject "$asuntoEmail - $fechaHoraActual" -Body "$cuerpoEmail" -SmtpServer smtp.gmail.com -UseSsl -Credential $credencialesEmail

Creamos un filtro indicando el ID de evento 131 a partir de ahí adjuntamos este filtro personalizado a una nueva tarea programada de modo que la tarea se ejecutará solamente cuando se produzca dicho evento. 

Figura 4: Crear tarea programada a partir de un filtro personalizado.

Cargar el fichero de llamada .bat. Es opcional pero recomiendo especificar el path absoluto donde inicia el script.

Figura 5: Iniciar el script .bat de llamada al script Powershell en la acción de la tarea programada. 

En las opciones de seguridad la tarea se ejecutará tanto si el usuario inició sesión somo si no.

Figura 6: Tipo de usuario para la ejecución de la tarea programada.

Notificación de alertas de intentos de conexión RDP

Configuración de alertas vía Gmail

Una vez se genere un nuevo evento 131 se ejecutará la tarea y el script asociado que disparará la alerta de correo. Para el envío de alerta por correo vía Gmail a través del script Powershell es necesario activar el acceso a "Aplicaciones menos seguras" en la cuenta de Google. Por seguridad se debería crear una cuenta específica para esta finalidad.

Figura 7: Ejemplo de notificación de alerta vía Gmail alerta intento de conexión RDP.

Configuración de alertas vía Slack

Creación de una nueva app para Slack y configuración de incoming webhook URL.

Figura 8: Crear canal, app y añadir nuevo Webhook a Slack. 

Sustituiríamos el anterior script Powershell de notificaciones vía email Gmail por este otro siendo este al que llamaría el fichero .bat en la tarea programada.

$eventRdp = Get-WinEvent -ProviderName "Microsoft-Windows-RemoteDesktopServices-RdpCoreTS" | Where-Object {$_.Id -eq "131"} | Format-List | Select -First 3 | Out-String

$uriSlack = "Webhook_URI"

$menssage = ConvertTo-Json @{ 

    text = $eventRdp

}

try {

    Invoke-RestMethod -uri $uriSlack -Method Post -body $menssage -ContentType 'application/json' | Out-Null

} catch {

    Write-Warning "Notification to Slack went wrong."

Figura 9: Ejemplo de notificación vía Slack alerta intento de conexión RDP.

Bloqueo de IPs externas en intentos de fuerza bruta a RDP

Al tener el servicio de RDP activo en WFAS (Windows Defender Firewall con seguridad avanzada) podemos encontrar habilitada la regla por defecto de Escritorio remoto (TCP de entrada) permitiendo la conexión por el puerto 3389/tcp por defecto. 

Figura 10: Regla por defecto RDP puerto TCP 3389.

Manualmente creamos una nueva regla pero esta vez en un modo de acción de "Bloquear la conexión". Las reglas de bloquear conexión o denegación tendrán un orden de preferencia frente a las reglas de permitir conexión.

Figura 11: Crear nueva regla de bloqueo de conexión.

Para este caso no se han cambiando los puertos por defecto por lo que el protocolo y puerto será el mismo que la regla por defecto 3389/tcp.

Figura 12: Regla de bloqueo de conexión protocolo TCP y puerto local 3389.

Una vez conocemos la dirección IP remota (pública en este caso) vamos agregando estas direcciones IP en el ámbito específico de "Dirección IP remota" estas se refieren a direcciones IP remotas dentro de la misma red o direcciones IP públicas-externas. Las direcciones IP locales se refieren a las propias de la máquina en caso de tener múltiples interfaces de red.

Al estar esta regla en un modo de acción de bloqueo de conexión denegará para esa IP origen el intento de conexión TCP hacia el servicio RDP no permitiendo la conexión inicial desde el primer intento.

Figura 13: Ámbito de regla - incluir IPs remotas de intento de conexión a bloquear.
 

Publicar escritorio remoto RDP de una forma más segura

Por lo general los servicios RDP suelen estar publicados en equipos servidores o máquinas que ofrecen uno o varios servicios y que remotamente necesitan gestionarse, por definición un servidor no debería de disponer de acceso a internet. Sino se disponen de tecnologías de control de seguridad SIEM o HIPS que puedan alertarnos de estos accesos, ni de arquitecturas más avanzadas y seguras para conectarse a una infraestructura interna como puedan ser servicios del tipo RD-Gateway, VDI o una VPN bien configurada con protocolos seguros, perfiles definidos y segmentación entre redes internas. 

Pero es necesario publicar el servicio RDP de una máquina interna de forma temporal, podemos hacerlo de una forma mucho más económica, sencilla de implementar y un poco más segura que tenerlo expuesto a través de un port forwarding local de puertos entre el router o firewall frontera hacia la IP del servidor interno.

1. Crear una máquina puente o bastión. Adquirir un servicio en cloud (AWS, Azure, GCP) y creamos una nueva máquina limpia con una dirección IP pública fija (esto es importante) y únicamente con el servicio de SSH disponible de forma pública. Por defecto la forma de conexión SSH a este tipo de máquinas cloud se realiza mediante clave pública-privada.
2. En la configuración avanzada del firewall de Windows editamos la regla RDP del propio servidor. En el ámbito de conexión del rango de IPs internas añadimos el rango de red interno (en el caso de que también queramos permitir conexiones de los equipos internos de la red).
3. Agregamos también la dirección IP pública asignada a la máquina bastión creada en el primer punto.
4. Para conectarnos si usamos una máquina Windows como cliente:
1. Agregar la clave privada de la conexión SSH de la máquina bastión.
2. Desde un cliente SSH como PuTTY establecemos una nueva conexión SSH port forwarding local.
5. Para conectarnos si usamos una máquina Linux como cliente:
1. Agregar la clave privada de la conexión SSH de la máquina bastión.
2. ssh -L LOCAL_IP:LOCAL_PORT:DESTINATION:DESTINATION_PORT USER@SSH_SERVER
3. Ejemplo: ssh -L 127.0.0.1:9999:192.168.1.10:3389 user@90.80.60.34

Estos recursos son económicos pero tampoco es una solución a largo plazo, lo ideal sería no exponer ningún servicio RDP ni SSH aunque se autentique con una PKI. Pero si por el momento no se disponen de otras implementaciones alternativas, hacerlo de este modo será más seguro que tenerlo expuesto directamente.

Saludos!

Active Directory: Auditar creación y cambios en cuentas de usuario (ID de eventos)

Para poder auditar la creación y cambios de cuentas de usuarios de Active Directory debemos establecer esta política a nivel de dominio en la plantilla "Default Domain Controllers Policy" situada en Objetos de directiva de grupo.

La editamos y configuramos:

Configuración del equipo > Directivas > Configuración de Windows > Configuración de seguridad > Directivas locales > Directiva de auditoría

Habilitamos "Auditar la administración de cuentas" en intentos "Correcto" y "Error".

Figura 1: Habilitar la auditoría de administración de cuentas en la plantilla "Default Domain Controllers Policy".

Si también queremos que se realice auditoría de la administración de cuentas locales en cualquier equipo unido al dominio, que no sean cuentas Active Directory. Debemos aplicar esta política a nivel de dominio dentro de la plantilla "Default Domain Policy".

Los ID de eventos que nos interesan para este caso son sobre la creación de nuevas cuentas de usuarios de Active Directory.

• ID de evento 4720: Se creó una cuenta de usuario.
• ID de evento 4722: Se habilitó una cuenta de usuario.
• ID de evento 4724: Se intentó restablecer la contraseña de una cuenta.
• ID de evento 4738: Se cambió una cuenta de usuario.

En el visor de eventos (eventvwr.msc) de un controlador de dominio, registros de Windows > Seguridad.

Creamos un filtro por los ID que nos interesen, separado por comas si queremos buscar más de un número de ID distinto.

En la siguiente captura se puede ver un ejemplo de un ID 4722, como se habilitó una nueva cuenta en Active Directory, más arriba tendríamos el ID 4720 donde se creó dicha cuenta.

Figura 2: Filtrar por ID de eventos para encontrar la creación de nuevas cuentas de usuario de Active Directory.

Saludos!

Auditar inicios de sesión erróneos ID 4625 y notificarlos vía email

Una forma de auditar los errores de accesos de inicio de sesión o login a un sistema Windows ya sean accesos físicos, en remoto mediante RDP, recursos compartidos CIFS o llamadas a procedimientos remotos RPC como pueden ser el acceso a consolas msc de equipos remotos. Se considerarán inicios de sesión en una máquina Windows.

Este artículo se centrará en la auditoria de todos los accesos erróneos de login a un sistema pero en especial irá enfocado a los intentos de inicios de sesión RDP desde equipos remotos y la notificación de este evento vía un mensaje de correo electrónico de forma automática.

Para ello será necesario habilitar en el equipo la directiva local de auditoria de eventos de inicio de sesión a través de la consola gpedit.msc.

Configuración del equipo > Configuración de Windows > Configuración de seguridad > Directivas locales > Directiva de auditoria > Auditar eventos de inicio de sesión > Habilitar inicios erróneos.

Figura 1: gpedit.msc - Auditar eventos de inicio de sesión erróneos.

Abrimos el visor de eventos (eventvwr.msc), registros de Windows, Seguridad. El evento con Id. 4625 registra las auditorias por inicio de sesión erróneos.

Creamos una tarea programada desde cualquier evento con ese Id. y establecemos un fichero .bat que llamará a otro fichero Powershell .ps1 que será el que realice el envío de email y lo filtre con una consulta para que nos devuelva el último evento registrado. Este punto lo veremos más adelante.

Figura 2: eventvwr.msc - Creación de tarea programada de un evento con un Id. concreto.

En el programador de tareas (taskschd.msc) vemos que se crea una nueva sección para las tareas creadas a través del visor de eventos.

Esta tarea debe ejecutarse con un usuario que forma parte del grupo de administradores locales del sistema ya que para poder consultar un evento de auditoria del tipo de "Seguridad" como es un evento con Id. 4625 es necesario un usuario privilegiado.

Figura 3: taskschd.msc - Tarea programada creada automáticamente a partir del evento de seguridad con Id. 4625.

Comentar que podemos también optar por crear y configurar la tarea programada manualmente. Como desencadenador elegimos iniciar la tarea al producirse un evento del tipo de registro "Seguridad" e indicamos el Id. del evento 4625.

Figura 4: Desencadenador de la tarea programda al producirse un evento del tipo seguridad con Id. 4625.

wevtutil (Windows Event Utility) es la utilidad en línea de comandos que nos mostrará la información de los eventos registrados de Windows.

Para mostrar el último evento registrado del tipo Seguridad con un Id. específico, en este caso 4625. Haremos la siguiente consulta:

wevtutil query-events Security /count:1 /rd:true /format:text /q:"Event[System[(EventID=4625)]]"

La siguiente línea corresponderá al fichero "call-ps1-eventvwr-id_4625.bat" que hará la llamada al fichero Powershell "id_4625.ps1". Este fichero bat será el la acción de la tarea programada.

powershell.exe -file "C:\scripts\envio_emails_eventvwr\id_4625.ps1"

El script Powershell id_4625.ps1 sería el siguiente, modificamos con nuestros valores los campos myEmail, myPassword y pathTempWevtutil será el path en el que se creará un fichero temporal con la salida de la consulta del evento, después se borrará.

$usuarioEmail = "myEmail@gmail.com"
$passwdEmail = "myPassword"
$pathTempWevtutil = "C:\temp\temp_wevtutil"
$secPasswdEmail = ConvertTo-SecureString $passwdEmail -AsPlainText -Force
$credencialesEmail = New-Object System.Management.Automation.PSCredential ($usuarioEmail, $secPasswdEMail)
$asuntoEmail = "ID 4625: Inicio de sesion incorrecto"
$wevtutil = wevtutil query-events Security /count:1 /rd:true /format:text /q:"Event[System[(EventID=4625)]]" | findstr /V "puerto" | findstr "cuenta: trabajo: Direcci" > "$pathTempWevtutil"
$cuerpoEmail = Get-Content "$pathTempWevtutil" -Tail 5 | Out-String

Send-MailMessage -From $usuarioEmail -To $usuarioEmail -Subject "$asuntoEmail" -Body "$cuerpoEmail" -SmtpServer "smtp.gmail.com" -Port "587" -UseSsl -Credential $credencialesEmail
Remove-Item -Path "$pathTempWevtutil" -Force
exit

Para habilitar el envío de correos SMTP a través de una cuenta con dominio Gmail será necesario habilitar el "Acceso de aplicaciones poco seguras". https://myaccount.google.com/lesssecureapps.

Esto tiene ciertos riesgos de seguridad, aconsejo crear una nueva cuenta de correo específica destinada para este uso y la realización de esta tarea.

En la siguiente captura se muestra un ejemplo del asunto y cuerpo del correo para la notificación de estos eventos. Mostrando el nombre de la cuenta desde la que se intentando iniciar sesión, el dominio o hostname, hacia que dirección IP se inicio sesión (sería la máquina local donde se registra el evento de seguridad) y desde que dirección origen ya sea una dirección IP privada o pública.

Figura 5: Ejemplo de mensaje de correo del evento de seguridad Id. 4625.

Repositorio Github: https://github.com/adrianlois/Auditar-inicios-sesion-erroneos-RDP-envio-email-PowerShell

Saludos!

Permisos NTFS: ACLs en cuentas de usuarios y grupos en Windows

Modificar permisos a usuarios y a grupos sobre objetos, privilegios a cuentas de usuarios y administradores en Windows.

Tenía pensado dividir este artículo en varias partes, ya que es extenso, pero para no tener comentarios en unas entradas y otras sobre el mismo tema, he decido incluir todo lo relacionado en el mismo post. A parte, a la hora de buscar en buscadores y en el blog se reflejará toda la información en un mismo artículo.

Como dije, este artículo es bastante extenso y completo. Por eso, cito un índice con los diferentes apartados o secciones de este post, un índice con enlaces internos (a esta página) que hacen referencia a todos los diferentes apartados.

Índice

• 1) Definiciones y conceptos.
• 1.A) Acceso a los archivos y directorios.
• 1.B) Tipos de cuentas de usuarios y grupos por defecto en Windows y sus SID.
• 2) Habilitar o deshabilitar cuenta de Administrador.
• 2.A) De manera gráfica.
• 2.B) Con la consola de comandos (CMD), Shell de Windows.
• 3) Modificar permisos o privilegios de usuarios o grupos locales.
• 3.A) Modificar permisos desde la sesión Administrador.
• 3.B) Modificar permisos desde la sesión "Usuario raso" (Propietarios de objetos).
• 3.C) Conflictos en permisos para un mismo usuario: Permitir y denegar.
• 3.D) Permisos heredables de objetos primarios.
• 4) Cambiar el tipo de cuenta: Usuarios o Administrador.
• 5) Habilitar y conceder permisos de Administrador, mediante la Shell de Windows (consola o símbolo de sistema CMD).
• 6) UAC (User Account Control "Control de cuentas de usuario").

Lecturas recomendables

• http://support.microsoft.com/kb/981949/es
• http://support.microsoft.com/kb/308419/es
• http://support.microsoft.com/kb/983628/es

El último enlace al que hago referencia, está muy completo ya que nos dice como modificar permisos de archivos o carpetas a usuarios, y es algo muy parecido a lo que voy comentar posteriormente en este artículo.

1) Definiciones y conceptos

1.A) Acceso a los archivos y directorios

Todo el tema de permisos que aquí muestro y explico se dan gracias al sistema de ficheros: NTFS (New Technology File System), uno de los sistemas de ficheros de Microsoft Windows, que permite un gran avance de seguridad en cuanto a las concesiones de permisos o privilegios de usuarios en Windows.

Herencia: La herencia permite la propagación de ACL posicionadas en objetos contenedores padres a sus hijos. Al crear una ACE, es posible precisar si se va aplicar al objeto, sólo a sus hijos (indicador de herencia solamente o Inherit Only) o al objeto en sí y a sus hijos.

Objetos: Un objeto es simplemente un elemento que puede asegurarse y protegerse mediante permisos. Puede tratarse de un archivo, un directorio, una clave de registro o un objeto de sistema, como una canalización con nombre, un socket, un proceso, un subproceso, etc.

ACL (Access Control List): Es una lista de control de acceso que regula los permisos de acceso a los objetos del sistem. Está compuesta por entradas de controles de acceso ACE

ACE (Access Control Entry): Una entrada de control de acceso es un elemento de una ACL. Una ACE está compuesta por un SID, una máscara de acceso que define los permisos concedidos al SID (ya sean: Lectura, escritura, etc.), un indicador que determina el tipo de ACE y otro indicador que determina a que objetos se refieren estos permisos.
Hay tres tipos de ACE: Acceso concedido, acceso denegado y Audit (para auditar la seguridad del sistema).

SD (Security Descriptor): Un descriptor de seguridad es la estructura vinculada a todo objeto al que se le puede aplicar seguridad que contiene el SID del propietario del objeto, su grupo primario y las dos listas de ACL: DACL y SACL.

DACL (Discretionary Access Control List): Una lista de control de acceso discrecional es la que está controlada por el propietario del objeto. Especifica quién tiene permiso y quién no para acceder a dicho objeto.

SACL (System Access Control List): Una lista de control de acceso de sistema es la que controla la generación de mensajes de auditoría durante los intentos de acceder a un objeto seguro. (Es necesario tener privilegios SE_SECURITY_NAME para modificar una SACL).

SDDL (Security Descriptor Definition Language): Un lenguaje de definición descriptor de seguridad que permite definir y transportar datos almacenados en un descriptor de seguridad en formato de texto.
Por ejemplo, el comando "sc sdshow" muestra el descriptor de seguridad ligado al servicio en formato SDDL.

El orden de interpretación de los permisos es o debería ser el siguiente:
- Accesos denegados explícitos (DENY ONLY).
- Accesos autorizados explícitos (ALLOW ONLY).
- Accesos denegados heredados.
- Accesos autorizados heredados.

Resumen

Un descriptor de seguridad de un recurso contiene el SID del propietario y varias listas de control de acceso. Una ACL es una lista de entradas de control de ACEs, cada una de las cuales identifica una confianza y unos permisos permitidos o denegados.

Las ACLs pueden ser de dos tipos: DACL (Discretionary ACL) o SACL (System ACL). 

• DACL especifican permisos de acceso -permitidos o denegados- que el propietario del recurso especifica discrecionalmente. 
• SACL especifican las acciones de confianza que el sistema debe auditar (intentos fallidos o exitosos de acceso según su tipo).

Cada recurso, además de poder incluir sus propias ACLs (ACLs explícitas), puede marcarse para que herede las ACLs de sus recursos antecesores (se indica separadamente para DACL y SACL).

Para determinar si debe concederse un permiso a una confianza del sistema primero ordena las ACEs de las distintas listas. Después las evalúa una a una y cuando encuentra una que se corresponde ya no evalúa el resto.

Si un recurso no tiene DACLs se concede el permiso. Si tiene DACL pero no tiene ACEs se deniega el permiso.

Para ordenar las ACEs el algoritmo tiene en cuenta lo siguiente:

• Dentro de una lista, las ACEs que deniegan tienen prioridad sobre las que permiten.
• Las ACLs explícitas tienen prioridad sobre las heredadas.
• Las ACLs de los padres tienen prioridad sobre las de los abuelos.

Por otra parte:

• Al anular la herencia el sistema nos permite elegir entre quitar todos los permisos heredados o copiarlos como explícitos.
• Cuando se crea un nuevo recurso éste hereda todos los permisos (todas las ACLs) de su padre (tanto heredados como explícitos).
• Al copiar un recurso (o moverlo a otro volumen) creamos un nuevo recurso.
• Al mover un recurso dentro de un volumen se mantienen los permisos.

1.B) Tipos de cuentas de usuarios (NT AUTHORITY), grupos por defecto en Windows y sus SID

Trusted Installer (Instalador de confianza): No es una cuenta de usuario propiamente dicha, sino que una cuenta de servicio. Su SID (Security Identifier) comienza por S-1-5-80, que corresponde a SECURTIY_SERVICE_ID_BASE_RID. Sirve para ejecutar el servicio que instala los componentes Windows, los hotfixes y los paquetes MSI (Microsoft Installer).

Este SID posee los permisos para todos los archivos de sistema que le permiten actualizar el sistema operativo. TrustedInstaller es un usuario del sistema de "Protección de Recursos de Windows" (WRP Windows Resource Protection), asume el control propietario de ciertos ficheros, carpetas o ciertas claves de registro de Windows para su correcto funcionamiento. No instala programas como tal, como pueda parecer, trabaja bajo el servicio de Windows "Instalador de módulos de Windows" controlado en la clave de registro "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\TrustedInstaller", este habilita la instalación, modificación y eliminación de actualizaciones (Windows Update) y componenetes opciones de Windows, su path físico está en: C:\Windows\servicing\TrustedInstaller.exe.

Tiene acceso completo a los directorios Windows, System32 y Archivos de Programas (Program Files), lo que le confiere permisos necesarios para reemplazar un archivo del sistema cuando ni siquiera los administradores tienen acceso en escritura. De la misma manera, están accesibles en escritura muchas claves del registro que definen clases y objetos COM únicamente en el servicio Trusted Installer. Cuando se llama, el servicio de instalación a MsiExec (fichero que lee la instalación MSI y lanza el asistente).

Creator Group: Utilizado por el subsistema POSIX únicamente, este SID genérico es sustituido durante la evaluación por el grupo principal del propietario del objeto. Concede control total o lo establecidos explícitamente en "permisos especiales" a un objeto sobre un grupo concreto. Esto está más detallado en el apartado: 3.B) Modificar permisos desde la sesión "Usuario raso" (Propietarios de objetos). En la sección de "Propietarios de un objeto".

Creator Owner (SID: S-1-3-0): Este SID genérico es reemplazado por el SID del propietario del objeto durante la evaluación de los permisos. Al igual que el anterior, concede control total o lo establecidos explícitamente en "permisos especiales" a un objeto sobre un grupo concreto. Esto está más detallado en el apartado: 3.B) Modificar permisos desde la sesión "Usuario raso" (Propietarios de objetos). En la sección de "Propietarios de un objeto".

Owner Rights (Derechos del propietario): Es una nueva cuenta (nuevo SID) de Windows Vista y 7. En Windows XP, pero también en Windows 7, el creador de un objeto posee implícitamente el derecho de modificar las ACL en su posible prohibir el acceso a un objeto (un archivo o una clave de registro, entre otros) a un administrador. El administrador tiene derecho a cambiar las ACL para otorgarse los permisos necesarios, como por ejemplo un control total.

A un usuario estándar o raso, ser propietario de un objeto le confiere un control total sobre el objeto e impide que se le pueda restringir el acceso, porque puede manejar y modificar sus ACLs. Un administrador que desee restringir el acceso a un propietario de un objeto deberá, en primer lugar, cambiar el propietario y luego ajustar las ACL del objeto de conformidad con lo deseado.

Windows Vista y Windows 7 introducen, por tanto, un nuevo SID que corresponde a "Derechos del Propietario" (no se corresponde con una nueva cuenta de usuario con la cual es posible iniciar sesión), que puede utilizarse para limitar los derechos del propietario del objeto. Cuando este SID no está en una ACL, se aplica la lógica habitual: el propietario posee los derechos para modificar las ACL de ese objeto. Sin embargo, cuando está presente, el propietario recibe los permisos asociados a este SID.

Se utiliza normalmente para restringir los permisos de los propietarios de forma sencilla y eficaz. Por ejemplo, situando en un directorio los permisos Lectura en el SID derechos del Propietario y lectura/escritura en un grupo dado, el grupo puede crear archivos y directorios que serán de sólo lectura una vez creados, porque el usuario recibirá los derechos del propietario.

Imaginemos que un usuario cambia de servicio, antes podía crear archivos y acceder a ellos en un directorio mediante la pertenencia a un grupo que le daba un control total sobre un directorio dado. Al abandonar el servicio, se le retira de este grupo. Sin embargo, sigue siendo propietario de sus objetos, es decir, de los archivos que creó, y puede, según las ACL establecidas en el directorio, seguir accediendo y modificando las ACL de sus archivos para devolverse a si mismo el control. Si se establece una denegación (DENY) WRITE_DAC en el SID Derechos del Propietario en el directorio raíz, los propietarios ya no pueden cambiar las ACL en los objetos que han creado. Para terminar, cuando un administrador cambia el propietario de un objeto, se deshabilitamos permisos asociados al SID Derechos del Propietario para que un administrador pierda definitivamente el control de un objeto.

Más detalle y un ejemplo en el apartado: 3.B) Modificar permisos desde la sesión "Usuario raso" (Propietarios de objetos). En la parte de "Propietarios de un objeto".

Ahora comentaré un poco los usuarios NT AUTHORITY, son usuarios usados por el sistema para operaciones de privilegios concretos en determinadas funcionalidades, estos usuarios el sistema hace uso de ellos de forma transparente al usuario final.

Figura 1: Usuarios NT AUTHORITY utilizados por Windows 7.

Usuarios autentificados (SID: S-1-5-11): Son Usuarios que pertenecen o forman parte de Active Directory de una red de dominio.

Anonymous Logon (SID: S-1-5-7): Son usuarios que no disponen de una cuenta de usuario en Servicios de dominio de Active Directory, pero que pueden recibir una invitación para participar de forma remota en una conferencia local.

IUSR (SID: S-1-5-17): Este grupo sirve para dar permisos a las cuentas de servicio encargadas de ejecutar los pools de aplicación del servidor Web IIS (Internet Information Services).

Interactive (SID: S-1-5-4): Representa a los usuarios que han abierto sesión localmente en la máquina y que no acceden a un recurso de la máquina a través de la red.

Local Service (SID: S-1-5-19): Los miembros de este grupo tienen permiso para leer el registro de eventos del equipo local.

Dialup (SID: S-1-5-1): Son usuarios conectados a través de una conexión de acceso remoto.

Network (SID: S-1-5-2): Son los usuarios que acceden a un recurso de la máquina a través de la red, a diferencia de los usuarios que han abierto una sesión localmente para acceder a los recursos. No incluye a los usuarios que inicien sesión mediante una sesión de Escritorio remoto (mstsc-Miscroft Terminal Service Connection).

Service (SID: S-1-5-6): Son los usuarios que inician sesión como servicio.

Network service (SID: S-1-5-20): "Servicio de red" es una cuenta utilizada por los servicios que necesitan acceder a recursos en la red bajo la identidad de la cuenta máquina en la cual se ejecutan. Tiene menos privilegios y permisos localmente que el "System Local".

Local service (SID: S-1-5-19): Es una cuenta utilizada por los servicios que necesitan acceder a recursos locales y no por red (se identifica anónimamente en la red). La diferencia entre Local Service y System Local reside en que System Local posee permisos sobre la red (los mismos que Network Service), mientras que Local Service se autentifica anónimamente en la red.
Network Service y System Local se autentifican en Kerberos utilizando la cuenta máquina del equipo definida en el servicio de Active Directory. Muchos servicios de Windows 7 que no necesitan acceder a la red se ejecutan bajo la identidad de Local Service. Este funcionamiento es el que siempre ha existido en los sistemas Microsoft. Con Windows y 2008, nuevas directivas de grupos permiten a la cuenta Local System autentificarse en NTLM en la red, y no de forma anónima. Este comportamiento no está activo de forma predeterminada, sino que es necesario activarlo.

System (SID: S-1-5-18): Representa el sistema operativo. Permite asignar permisos específicos al sistema. Se llama también Sistema Local (Local System). Es la cuenta que tiene más derechos y privilegios en la máquina.

Batch (SID: S-1-5-3): Son las cuentas utilizadas para ejecutar tareas programadas (Control Schedtasks).

Terminal Server User (SID: S-1-5-13): Son los usuario que abren una sesión de terminal server en la máquina.

Remote Interactive Logon (SID: S-1-5-14): Son los usuarios conectados mediante un inicio de sesión de escritorio remoto.

Otros usuarios del sistema para realizar otras funciones determinadas:

Usuarios de Operadores de cifrado: Como sería lógico, los miembros de este grupo tienen permisos para realizar operaciones de cifrado.

Usuarios de Operadores de copia de seguridad: Encargados de realizar las copias de seguridad del equipo programadas o automáticas de Windows o lo que se le hubiese establecido.

Usuarios del monitor de rendimiento: Los miembros de este grupo pueden acceder a los datos del Monitor de rendimiento (perfmon.exe) localmente y en remoto.

Usuarios del registro de rendimiento: Los miembros de este grupo pueden programar el registro de los monitores de rendimiento, activar los proveedores de seguimiento y recoger el seguimiento de eventos simultáneamente de forma local y a través de un acceso a este equipo.

Añado una nota sobre los SID de los usuarios:

• Administrador: SID: S-1-5-500
• Invitado: SID: S-1-5-501
• El resto de usuarios locales, empezarán ordenadamente a partir del siguiente SID: S-1-5-1000, S-1-5-1002 , S-1-5-1003, etc. y así sucesivamente por cada usuario local creado.

Existen muchos más grupos de usuarios predeterminados en Windows, aquí menciono los que para mi son los más usados y relevantes.

Más información sobre los SID (Identificadores de seguridad): http://support.microsoft.com/kb/243330/es

Intentaré explicar de manera clara y sencilla, para que sea entendible por cualquier tipo de usuario: Como modificar ya sea, para conceder o denegar permisos en Windows y como configurar cuentas de usuarios y administradores de Windows.

Existen muchas formas de realizar esto, ya sea por la shell (consola de comandos CMD) de Windows, como de manera gráfica en el sistema. Mencionaré las dos formas de hacerlo, para cada uno de los casos.

Nota: El nombre de usuario que utilizaré para este tutorial será Administrador (por defecto del sistema) y loiswin7 que correrán bajo una máquina virtual con Windows 7 Ultimate.

2) Habilitar o deshabilitar cuenta de Administrador

2.A) De manera gráfica.

[1] - Nos vamos a: Inicio > botón derecho en "Equipo" > Administrar.
Nos aparecerá la ventana de "Administración de equipos".

[2] - Nos vamos a: Usuarios y grupos locales > Usuarios > Administrador > botón derecho "Propiedades".

Se nos mostrará la ventana de "Propiedades: Administrador".
[3] - En la pestaña "General" desmarcamos (para activar la cuenta, en caso contrario marcaríamos el checkbox) el checkbox que dice: "La cuenta está deshabilitada", Aplicamos los cambios y Aceptamos.

[4] - Cerramos la ventana "Administrador de equipos" y cerramos sesión para poder entrar como Administrador al sistema.

Figura 2: Habilitar o deshabilitar cuenta administrador desde lusrmgr.msc.

2.B) Con la consola de comandos (CMD), Shell de Windows

[1] - Nos vamos a: Inicio > escribimos: CMD > esperamos a la búsqueda > botón derecho sobre: cmd.exe > Ejecutar como administrador. Se nos abrirá la Shell de Windows (CMD).

[2] - Aquí tipearémos o escribirémos la siguiente linea de comandos:

net user administrador /active:yes
(para activar la cuenta administrador del sistema)

net user administrador /active:no
(para desactivar la cuenta administrador del sistema)

[3] - Pulsamos Enter y cerramos la consola con el comando Exit, o simplemente cerrando la ventana.

[4] - Cerramos sesión para poder entrar como Administrador al sistema.

Figura 3: Habilitar o deshabilitar cuenta administrador a través de consola, cmd.exe.

En algunos casos, puede dar errores. Uno muy frecuente es:

Error de Sistema 5 (System error 5):
Se refiere a que no tenemos los permisos adecuados.
Soluciones:

• Comprobar los permisos de la cuenta.
• Realizar un logueo en la maquina remota, para que las credencias queden el cache (un error muy típico).
• Comprobar que el servicio netlogon este corriendo.

Estas dos maneras que mencioné, tanto gráficamente como mediante comandos con la Shell de Windows, son válidas. Aclaro que esto solamente es para activar o desactivar la cuenta Administrador del sistema.

3) Modificar permisos o privilegios de usuarios o grupos locales

3.A) Modificar permisos desde la sesión Administrador.

En cualquiera de los dos casos que hubiésemos realizado anteriormente.
Cuando cerramos sesión, veremos ya habilitada la cuenta Administrador, entramos como Administrador al sistema.

Figura 4: Inicio de sesión como administrador.

Una vez iniciada la sesión como Administrador:

[1] - Nos vamos al "Explorador de Windows" (Tecla Win + E) o doble clic en Equipo.

[2] - Hacemos clic derecho sobre el disco local C: (que por defecto en la mayoría de los casos suele ser la asignación de letra de unidad C:) > Propiedades.

Figura 5: Acceder a las propiedades de %systemdrive% para configurar la seguridad de permisos.

[3] - En ventana de "Propiedades: Disco local (C:)". Nos vamos a:

Seguridad > Editar... > (Se nos abrirá la ventana: "Permisos de Disco local (C:)") ahí seleccionamos el grupo "Usuarios" o "Administradores" y concedemos (en este caso) o denegamos privilegios o permisos a dichos grupos, marcando los checkbox que deseemos o simplemente si queremos conceder o denegar todos, marcamos el checkbox de "Control total".

Si no vemos la opción de Seguridad en una solapa o pestaña de esta ventana. Deberemos activar lo siguiente:

En la "Barra de Herramientas" de 'Mi PC' o 'Explorador de Windows' (Pulsamos F10 o 'Alt') > Herramientas > Opciones de carpeta > Ver > buscamos 'Utilizar uso compartido simple de archivos' y desmarcamos este checkbox > Aceptar. Ahora ya podremos ver la ficha de Seguridad.

[4] - Aplicamos los cambios, se nos mostrará una ventana en la que nos dice si estamos seguros de la operación, le decimos que si. Y aceptamos.
Veremos como después de aplicar la operación en la ventana "Propiedades: Disco local (C:)" se nos muestran todos los tics en "Permitir" en el grupo que seleccionáramos (Usuarios o Administradores).

Figura 6: Edición de permisos para "Usuarios" y otros.

3.B) Modificar permisos desde la sesión de un "Usuario raso" (Propietarios de objetos)

En este caso, omitiríamos desde el principio de este post hasta este apartado los pasos y las diferentes maneras de hacerlo sin necesidad de habilitar la cuenta Administrador.

Dentro de nuestra sesión de usuario normal:

[1] - Nos vamos al "Explorador de Windows" (Tecla Win + E) o doble clic en Equipo.

[2] - Hacemos clic derecho sobre el disco local C: (que por defecto en la mayoría de los casos suele ser la asignación de letra de unidad C:) > Propiedades.

[3] - En ventana de "Propiedades: Disco local (C:)" nos vamos a:
Seguridad > Opciones avanzadas.

 
[4] - Se nos mostrará la ventana: "Configuración de seguridad avanzada para Disco local (C:)". Nos vamos a: Propietario > Editar....

En la ficha propietario el usuario tendría que estar en el "Grupo de Administradores" locales para poder realizar algunas de estas funciones: 

Cuando un fichero o carpeta tiene a un administrador local como propietario en este fichero y/o carpeta no podremos eliminar, modificar, mover, cambiar permisos, etc., es debido a que quizás ese administrador NO esté como propietario del fichero o carpeta, ya que puede que ni siquiera esté en el grupo administradores, y sea simplemente un usuario normal-raso.

Si conseguimos añadir el usuario que queramos en la ficha de Propietario de un fichero/carpeta y remplazamos el que ya está (que esto nos lo permite si el que actualmente está es administrador pero pese a eso no nos permite borrar el fichero por decirlo de algún modo) añadiendo otro user con privilegios y reemplazando la propiedad del fichero conseguiremos realizar todo tipo de acciones sobre dicho fichero/carpeta como por ejemplo borrar esos ficheros o carpetas que Windows en ocasiones bloquea.

Es importante que después de seleccionarlo y aplicar nos fijemos de que donde aparece "Propietario actual", en la casilla de texto de abajo esté asignado o establecido el correspondiente usuario que queremos hacer propietario. (Ya que "en ocasiones" pasa que seleccionas y los cambios parece que surgen efecto y en realidad no es así).

Tendremos también que marcar los checkbox para "incluir todos los permisos heredables del objeto primario de este objeto".

Figura 7: Cambiando propietario, algo importante para la manipulación total de un objeto.

Se nos abrirá otra ventana en la que:

[5] - Seleccionamos el usuario del sistema con el que tenemos iniciada sesión (es decir, el usuario normal).

 
[6] - Marcamos el checkbox que dice: "Reemplazar propietarios en subcontenedores y objetos". Aplicamos y Aceptamos.
Cuando apliquemos se nos mostrará una ventana en la que realizará las operaciones necesarias, esperamos a que acaben de realizarse.

Que me ofrece ser propietario de un objeto?

Hacer un usuario propietario de un objeto o de los siguientes objetos (subcontenedores) no hace que tenga control total sobre dicho objeto sino, que pueda tener control para CAMBIAR los permisos de dicho objeto a su antojo, y de ese modo poderse dar así mismo más permisos. Esta es básicamente la única característica de ser propietario o no de un objeto.
Aunque veremos como aprovechar esto y ponerlo en práctica, en un próximo ejemplo de un posible escenario como funciona el ser propietario de un objeto usando los usuarios por defecto de Windows (Owners) y como afectan a sus ACEs en futuros objetos creados por dichos usuarios.

Figura 8: Reemplazando propietario en subcontenedores y objetos.

Si tenemos el siguiente escenario:

Los usuarios "Pepe" y "Lili" forman parte del grupo "Empleados" y a este grupo se le da permisos especiales de crear y solo lectura sobre los objetos carpeta y ficheros, este grupo solo va poder crear y leer estos ficheros. Pero sin embargo añadimos el usuario por defecto de Windows "Creator Owner" y a este le damos control total sobre los objetos carpetas y ficheros, quiere decir que el usuario, "Lili" por ejemplo, cree dicho objeto tendrá control total sobre este independiente de si forma parte del grupo de creación y solo lectura (empleados) ya que al crear dicho objeto a este usuario se le establecen las ACLs del "Creator Owner", con esto conseguimos que un objeto solo sea manipulable desde su creador y que solo lo puedan leer desde otros usuarios del sistema, esto es gracias a las ACLs establecidas en el grupo "Empleados" y a las del "Creator Owner".

 
Lo mismo pasaría con el "Creator Group" pero en ese caso orientado a un grupo en concreto en vez de a un usuario.

Figura 9: Añadiendo "Creator Owner" a un objeto.

Figura 10: Editando permisos especiales de solo carpeta y archivos al "Creator Owner".

Cuando acabe el proceso, volveremos a la ventana anterior. Pero esta vez nos vamos a:

 
[7] - La ficha de "Permisos" > seleccionamos nuestro usuario > Cambiar permisos... > (se nos abrirá otra ventana) seleccionamos nuestro usuario nuevamente > Editar...

Figura 11: Modificación de permisos de usuarios.

Se nos abrirá una la ventana: "Entrada de permiso para Disco local (C:)".

[8] - En el menú desplegable "Aplicar a" Seleccionamos la opción: "Esta carpeta, subcarpetas y archivos" (Esta opción está marcada por defecto, pero nos aseguramos de que esté seleccionada).

[9] - Después simplemente nos queda Permitir o Denegar privilegios o permisos al usuario, en este caso permitimos y concedemos los privilegios al usuario seleccionado anteriormente. Marcamos el checkbox Control total en permitir, para directamente seleccionar todos los campos. Sería lo mismo para la denegación, pero lógicamente marcando el checkbox contrario (en la columna de "Denegar").

[10] - Pulsamos Aceptar, se nos mostrará una ventana realizando las operaciones necesarias para efectuar los cambios en el sistema, esperamos y Aceptamos una ventana que se mostrará al terminar dicho proceso.
Aceptamos también todas las ventanas abiertas. Reiniciamos. Y listo!

Figura 12: Modificación de permisos de usuarios de forma avanzada.

Ahora tendremos el control total del sistema y podremos conceder y denegar privilegios a otros usuarios de manera normal. Como se muestra en la sección de este post "3.A) - Modificar permisos como Administrador"

No voy a pararme a explicar que hacen o deja de hacer cada uno de los permisos ya que para eso las propias webs a las que hice referencia al principio de esta guía, las cuales Microsoft las detalla como los artículos: KB-981949 y KB-308419. Explican perfectamente para que valen y que hacen cada una de las características de los permisos.

3.C) Conflictos en permisos para un mismo usuario: Permitir y denegar

Abro un pequeño apartado explicativo sobre esta cuestión. Planteo el siguiente escenario:
Si tenemos un usuario "pepe" y otros usuarios del que forma parte del grupo "empleados" y un objeto (carpeta compartida) común para almacenar información personal. Si se le da permisos de SOLO LECTURA al grupo empleados del que forma parte pepe, pero sin embargo explícitamente se le dan permisos de ESCRITURA a pepe sobre ese contenedor este va poder leer y escribir, pero el resto de usuarios que forman parte del grupo empleados solo van poder leer.

Por lo que podemos entender de que si a un un usuario que pertenece a un grupo le das unos permisos y después a ese usuario de forma independiente le añades otros permisos, el sistema de permisos NTFS de Windows da prioridad a los permisos explícitos a ese usuario en concreto y no al establecido en el grupo del que también forma parte dicho usuario.

3.D) Permisos heredables de objetos primarios

Destacar también que tenemos las opciones de "Incluir permisos heredables del objeto primario al objeto actual", esto nos dice que si tenemos una: CarpetaA con X permisos y dentro de esta creamos una CarpetaB, la CarpetaB tendrá por defecto los mismos permisos que tiene la carpeta padre-raíz (objeto primario).

Pero si quiero que la CarpetaB no herede dichos permisos solamente para esa carpeta y sus objetos ya existentes tendremos que desmarcar y agregar los permisos heredables para que esto no se aplique a las siguientes subcarpetas y/o ficheros.

Nos puede pasar que queramos eliminar de un objeto (carpeta o fichero) el grupo de "usuarios" o "usuarios autentificados" y no podamos hacerlo, así como intentar agregar o quitar otros usuarios y grupos por defecto del sistema. Esto es debido a que los permisos son heredados de los objetos padres, por lo que tenemos que desheredar dichos permisos y después proceder a eliminar esos grupos de ese objeto en cuestión.

Si desmarcamos el checkbox (que está marcado por defecto) de "Incluir todos los permisos del objeto primario de este objeto", aparecerá un cuadro de advertencia en el que se nos dice si queremos "Agregar" o "Quitar" esta herencia.

Agregar: Nos mantiene los mismos usuarios y grupos pero quita la herencia del objeto primario padre.

Quitar: Quita todos los usuarios y grupos del objeto, de modo que no quede ninguno asignado a dicho objeto, eso conlleva a que también se elimine la herencia. 

Figura 13: Permisos heredables del objeto primario de este ojeto

Microsoft nos dice lo siguiente:

"Incluir todos los permisos heredables del objeto primario de este objeto":
Si se selecciona, cada objeto secundario tendrá permisos heredados de su objeto primario.
Si se anula la selección, los permisos aplicados al objeto primario no se aplicarán a su objeto u objetos secundarios.

"Reemplazar todos los permisos heredables existentes en todos los descendientes con permisos heredables de este objeto":
Si se selecciona, los permisos de este objeto primario reemplazarán los de los objetos descendientes.
Si se anula la selección, los permisos de cada objeto (tanto de los primarios como de sus descendientes) pueden ser únicos.

Ahora, a modo de comentario detallo un poco para completar la información sobre las dos fichas que quedan restantes: Permisos efectivos y Auditoría.

En la ficha o pestaña "Permisos efectivos" nos servirá sencillamente para visualizar o mostrar los permisos por un usuario específico o grupo de usuarios. Pero no es más que ver los permisos que se permiten o deniegan en la ventana de edición de permisos de un objeto como la que se muestra anteriormente.
En el caso de la imagen que vemos a continuación podemos ver el usuario "pepeprueba" (un usuario raso dentro del grupo "Usuarios locales"), los concesión de permisos que tiene.

Figura 14: Visualización de permisos aplicados al usuario seleccionado.

En la ficha o pestaña "Auditoría", pues creo que está claro que es para poder auditar los objetos y el acceso a ellos para un usuario específico o un grupo de usuarios.

Figura 15: Auditando acceso o modificación a objetos a un usuario específico.

Lo cual para poder hacer esto y poder examinar o ver el Visor de eventos (eventvwr.msc) de Windows Vista/7, tendremos que tener habilitada una directiva en el "Editor de directivas de grupo local" (gpedit.msc). La cual nos permite auditar el acceso correcto o erróneo a objetos, esta se encuentra en:

Configuración de equipo > Configuración de Windows > Configuración de seguridad > Directivas locales > Directiva de auditoría.

Figura 16: Aplicando la GPO para auditar objetos en gpedit.msc.

4) Cambiar el tipo de cuenta: Usuarios o Administrador

Si queremos omitir el apartado de este post "2) - Habilitar o deshabilitar cuenta de Administrador" y el "3.B) - Modificar permisos desde la sesión "Usuario raso"  (Propietarios de objetos).

Directamente podemos asignar el "Grupo Administradores" la cuenta de usuario que estemos utilizando o deseemos, de manera muy sencilla. De este modo concederemos o denegaremos permisos de manera normal (siendo Administrador) como se muestra en la sección de este post "3.A) - Modificar permisos desde la sesión Administrador" (pero sin necesidad de entrar en la sesión de Administrador, ya que lo haremos todo desde la sesión usuario).

[1] - Nos vamos a: Inicio > Panel de control > Cuentas de usuario y protección infantil > Cuentas de usuario > Seleccionamos nuestra cuenta de usuario (o la que deseemos) > cambiar el tipo de cuenta > Administrador > pulsamos en el botón que dice: "Cambiar el tipo de cuenta".

Figura 17: Cambiando el tipo de cuenta de un usuario de forma gráfica. 

De este modo la cuenta seleccionada pasará a ser parte del "Grupo Administradores" y ya seremos Administrador del sistema, con lo cual tendremos los privilegios para conceder o denegar permisos a otros usuarios. En el apartado de este post "3.A) - Modificar permisos desde la sesión Administrador" veremos como modificar los permisos, pero sin necesidad de entrar en la sesión de Administrador, ya que lo haremos todo desde la sesión de la cuenta de usuario que estemos usando en Windows.

Esto anterior es la manera elegante que nos proporciona Windows de hacer de la manera tradicional y que personalmente siempre uso ya es exactamente los mismo.
Se trata de administrar y gestionar esto desde una consola de Microsft "MSC" (MicroSoft Console). Como es el caso del fichero de consola: Inicio > Ejecutar: lusrmgr.msc (Editor de usuarios y grupos locales).

Aquí podemos realizar lo mismo e incluso más funciones ya que podremos ver todos los usuarios y grupos creados en nuestro sistema, modificar así como crearlos y borrar otros (aunque tener cuidado cuales se borran ya que algunos hace uso Windows de ellos). Esta consola nos permite visualizarlo las cuentas y grupos de usuario de un modo digamos ordenado y claro, a mi parecer, más detallado, completo, igual de eficaz y a la vez hacerlo de forma rápida y sencilla.

Figura 18: La "forma más correcta" de cambiar la pertenencia de usuarios a grupos.

5) Habilitar y conceder permisos de Administrador mediante la Shell de Windows (CMD)

En este apartado, omitiremos todo lo mencionado desde el principio de este post hasta esta sección, excepto la sección "4) - Cambiar el tipo de cuenta: Usuarios o Administrador".

En esta parte, explicaré como modificar (conceder o denegar) permisos (en este caso conceder) de control total en el sistema al grupo Administradores del equipo. Mediante dos simples lineas de comandos, que escribiremos en en la consola o símbolo del sistema CMD de Windows.

[1] - Si ya cambiamos el tipo de cuenta a Administrador, abrimos la Shell de Windows como Administrador (ya que para ejecutar las siguientes instrucciones de comandos necesitamos privilegios de una cuenta del tipo Administrador), para ello, nos vamos a:
Inicio > Todos los programas > Accesorios > botón derecho sobre Símbolo de Sistema > botón derecho sobre ejecutar como Administrador
Se nos abrirá la shell de Windows CMD.

[2] - Aquí escribimos los siguiente.

takeown /F "%SYSTEMDRIVE%\*" /R /D S

Pulsamos Enter. y esperaremos a que el sistema realice todo el proceso necesario (tendría que terminar con una lista extensa, poniendo en todas las líneas que fue procesando: "CORRECTO").

[3] - A continuación, escribimos esta otra línea de comandos:

icacls "%SYSTEMDRIVE%\*" /grant Administradores:(D,WDAC) /T

Pulsamos Enter, y esperamos a que el sistema termine el proceso.

[4] - Si todo lo procesado salió correctamente, salimos de la consola, escribiendo exit y reiniciamos el equipo.

• takeown: es para indicar el propietario.
• icacls: es para indicar los permisos del propietario que pusimos en takeown.

Ahora el análisis de las propiedades o atributos de las dos líneas de comandos:

takeown /F "%SYSTEMDRIVE%\*" /R /D S

/F: Indica el archivo/carpeta al que queremos cambiar el propietario (en este caso es %SYSTEMDRIVE%).
%SYSTEMDRIVE%: Es la variable de entorno del disco duro principal desde donde se ejecuta Windows, es decir "C:\" (por defecto, lo más común).
*: Con el símbolo asterisco indicamos todos los archivos de esa carpeta (Archivos, no carpetas, pero combinado con /R es igual a: Todos los archivos de todas las carpetas del disco duro (en este caso)).
/R: Realiza el cambio de propietario en los subdirectorios (En este caso sería en todo el disco duro).
/D S: En algunas carpetas puede surgir una pregunta al intentar indicar el propietario donde dice que si quieres darle permisos, pues "/D S" lo único que hacen en este caso es contestar "Si" automáticamente a esa pregunta, para no tener que hacerlo manualmente.

icacls "%SYSTEMDRIVE%\*" /grant Administradores:(D,WDAC) /T

%SYSTEMDRIVE%: Como ya dijimos anteriormente, "C:\" (En este caso). 

* > (símbolo asterisco) Todos los archivos de esa carpeta (Archivos, no carpetas, pero combinado con /T es igual a: Todos los archivos de todas las carpetas del disco duro).
/T: Realiza el cambio de permisos en los subdirectorios (En este caso sería en todo el disco duro).
/grant: Es la opción para indicar que se le quieren conceder permisos a un usuario. (Lo que quiero decir, es que en vez de /Grant se podria usar /Deny para denegar permisos por ejemplo.)
Administradores: El grupo de usuarios (en este caso), (Administrador).

(D,WDAC): Los permisos a conceder. (en este caso "D" y "WDAC").

Algunos permisos importantes:
D: acceso de eliminación
WDAC: escribir DAC
F: acceso total
M: acceso de modificación
RX: acceso de lectura y ejecución

Un ejemplo de sintaxis básica de ICACLS:

icacls [PATH] [/grant|/deny] [grupo|usuario]:(herencia2)(herencia1)(permiso1,permiso2,) [otros_argumentos /?]

icacls c:\carpetapublica /inheritance:r /grant wuser:(OI)(CI)(F) /grant todos:(OI)(CI)(AD,RX)  /Q

Para ICACLS una lista de permisos simples:

• N - sin acceso
• F - acceso total
• M - acceso de modificación
• RX - acceso de lectura y ejecución
• R - acceso de solo lectura
• W - acceso de solo escritura
• D - acceso de eliminación

Una lista de permisos más específica:

• DE - eliminar
• RC - control de lectura
• WDAC - escribir DAC
• WO - escribir propietario
• S - sincronizar
• AS - acceso al sistema de seguridad
• MA - máximo permitido
• GR - lectura genérica
• GW - escritura genérica
• GE - ejecución genérica
• GA - todo genérico
• RD - leer datos/lista de directorio
• WD - escribir datos/agregar archivo
• AD - anexar datos/agregar subdirectorio
• REA - leer atributos extendidos
• WEA - escribir atributos extendidos
• X - ejecutar/atravesar
• DC - eliminar secundario
• RA - leer atributos
• WA - escribir atributos

Lista de herencias:

• (OI) - herencia de objeto
• (CI) - herencia de contenedor
• (IO) - solo herencia
• (NP) - no propagar herencia
• (I) - permiso heredado del contenedor principal

Lista de parámetros aplicables para las herencias de objetos (OI IO CI) con ICALCS (explicado):

• OI: (Object Inherit) Afecta a carpeta que se gestiona y ficheros que tiene dentro.
• CI: (Container Inherit) Afecta a carpeta y subcarpetas (no a ficheros).
• IO: (Inherit Only) NO AFECTA a fichero o carpeta que se gestiona sólo los que están dentro (solo subcarpetas).

• OI CI: Afecta a carpeta, subcarpeta y ficheros. (suele ser la herencia de permisos por defecto y habitual)
• CI IO: Sólo afecta a subcarpetas.
• OI IO: Sólo afecta a los ficheros contenidos en la carpeta que se gestiona.
• CI IO OI: Afecta a los ficheros que tiene dentro y a las subcarpetas.

Para más información de las propiedades de estos dos comandos consultar la ayuda de los mismos. Escribir en una consola CMD:

Takeown /?
Icacls /?

6) UAC (User Account Control "Control de cuentas de usuario")

No tiene que ver con privilegios establecidos en un objeto o permisos ni tipos de cuentas. La relación está en que si eres administrador el sistema ya no te sobresaltará tanto con las típicas ventanas de Windows. Me refiero, aquellas que en el momento de instalar alguna aplicación o realizar alguna otra operación en el sistema, aparecen unas ventanas de advertencia, del estilo: Estas seguro que quieres ejecutar xxx? Se requieren permisos de Administrador... (Aceptar o Cancelar) o introducir el usuario y su contraseña con privilegios más altos del sistema.

Pues con el UAC deshabilitado del todo (en su nivel más bajo de seguridad) lo que se consigue es que siendo un usuario normal sin apenas privilegios en el sistema, dichas ventanas no sobresalten. Esto siempre y cuando el dicho usuario esté incluido en el grupo administradores locales del sistema. Si se trata desde otra sesión de usuario en el grupo usuarios por ejemplo la ventana de UAC seguirá mostrándose para elevar dichos privilegios. Como ya dije esto no tiene que ver con permisos (escritura, lectura, ejecución, modificación, etc.).

El UAC básicamente es una tecnología que nos notifica con advertencias de una elevación de privilegios necesaria para la ejecución de algo. Aunque lo podremos configurar el UAC mediante distintos niveles de seguridad indicando como se tiene que comportar ante ciertas advertencias informativas.

Por seguridad es muy recomendado tenerlo en su nivel más alto de seguridad "notificar siempre".

Finalmente, recomiendo este hilo del foro oficial de soporte de Microsoft (social.technet.microsoft.com), en el que Jose Manuel Tella Llop da respuesta a algunos problemas de los usuarios:
http://social.technet.microsoft.com/Forums/es-ES/wcvistaes/thread/95da492a-13bd-405d-a782-e2daffa4b893

Saludos!