Security Posts
Key Takeaways from Our Latest Global Threat Landscape Report
Fortinet announced the findings of the latest quarterly Global Threat Landscape Report. The research reveals that cybercriminals continue to evolve the sophistication of their attack methods, from tailored ransomware and custom coding for some attacks, to utilizing pre-installed tools or established infrastructure to maximize efficiency for their opportunities.
Categories: Security Posts
PowerShell Empire: Cómo pasar sesiones entre máquinas con HTTP Foreign #penstest #pentesting
Quizá PowerShell Empire ha sido una de las herramientas más populares de los últimos años en lo que a Ethical Hacking se refiere, y especialmente en el mundo del Pentesting con PowerShell. Es un proyecto con aire fresco que ha proporcionado alternativas a la post-explotación con Metasploit. El año pasado tuve la suerte de estar por Ekoparty, en Argentina, hablando de Empire y de nuestro iBombShell.
Figura 1: PowerShell Empire.
"Cómo pasar sesiones entre máquinas con HTTP Foreign"
También hemos ido hablando de diferentes acciones de PowerShell Empire y de sus listeners y las posibilidades que éstos ofrecen. Por ejemplo, hemos visto como es su funcionamiento básico en el pentesting en ataques Pass the Hash, hemos trabajado con canales encubiertos para gestionar los agentes con Dropbox, cómo utilizar saltos intermedios entre el agente y el listener y, también, hemos visto cómo integrar herramientas como Metasploit en el uso del Empire y sus listeners.
Figura 2: Pentesting con PowerShell 2ª Edición
Sin duda, una herramienta con bastantes opciones y con más de 300 módulos de acciones disponibles. Hoy vamos a continuar con los listeners en PowerShell Empire, y haciendo algunas demostraciones prácticas con él.
HTTP Foreing
HTTP Foreign es un tipo de listener que permite pasar una sesión de una máquina a otra. El término ‘Session Pass’ es conocido para referirse a esto. Con Empire podemos imaginar un escenario en el que una máquina quiere traspasar una sesión a otra. El concepto clave en este punto es el uso de la misma clave de sesión o Session Key con la que se cifra la comunicación de los agentes con los listeners.
Figura 3: Sesión Pass con HTTP Foreign
Para este artículo podemos pensar en el siguiente escenario:
• Una máquina comprometida, por ejemplo, vía inyección de DLL generada con Empire y apuntando a nuestro listener. La máquina comprometida será un Windows 7, aunque puede ser cualquier otra versión de Windows, por ejemplo, un 10. La llamaremos V.• Una máquina con un listener que recibe la conexión desde la máquina Windows. Esta máquina será un Kali Linux. La llamaremos M1.• Una máquina con Kali Linux y Empire instalado. Se generará un listener a la escucha, el cual debe tener el mismo Session Key que el listener de la máquina anterior. La llamaremos M2.El punto de partida es la sesión creada entre el agente ejecutado en Windows y el listener que está a la escucha en la máquina Kali Linux, la más a la izquierda que se ve en la imagen anterior.
Obteniendo la primera sesión: de V a M1
Vamos a ver la configuración básica del listener HTTP clásico de PowerShell Empire. Con el comando uselistener cargamos el módulo http. No hay mucho que configurar, podemos dejar la conexión a la escucha en el puerto 80 y la dirección IP de la máquina.
Figura 4: Configuración de listener http en PowerShell Empire
Una vez que se obtiene la sesión en la máquina M1, ya se puede interactuar con el agente. Ahora queremos pasar la sesión de M1 a M2. Más que pasarla es compartir la máquina V.
Para realizar la siguiente acción se debe configurar en M1 un listener denominado http_foreign. Este listener tiene algo importante y es que el atributo host debe apuntar a la máquina M2 y no a la máquina M1. Es decir, cuando el agente que se está ejecutando en la máquina V se conecte al listener http_foreign será redireccionado a la máquina M2.
Figura 5: Sesión obtenida en máquina M1 y configuración de http foreing
En otras palabras, tenemos que configurar el atributo host, en este caso para apuntar a http://10.0.0.31:80. Es importante quedarse con el valor del StagingKey o lo que antes hemos llamado Session Key. Esto es algo fundamental para que la redirección de sesión funcione.
Session Pass: Llegando a la máquina M2
Ahora debemos colocarnos en la máquina M2, en este segundo Empire que estamos utilizando. De algún modo debemos pasarnos el StagingKey utilizado en la máquina M1 a la máquina M2. Una vez copiado, se debe ejecutar la instrucción set StagingKey [Valor]. Esto dentro del listener cargado. El listener que debemos utilizar en la máquina M2 es un listener http clásico.
Figura 6: Configurando StagingKey
Una vez configurado el listener en M2 se debe ejecutar y lo tendríamos listo y visible si ejecutamos el comando listeners. A continuación, se muestra la imagen de la configuración del listener y de la configuración del StagingKey.
¿Cómo conseguimos el Session Pass?
Esto es sencillo. Desde la máquina M1 podemos interactuar con el agente a través del comando interact. Desde esa sesión podemos ejecutar el comando spawn. Este comando permite generar una nueva instancia de un agente sobre la máquina V, en este caso.
El detalle es que queremos que la nueva instancia de un agente apunte al listener http_foreign. ¿Por qué? Sencillo, porque cuando la nueva instancia del agente de Empire se conecte al listener http_foreign, éste redirigirá a la M2. En este punto hay que acordarse de la configuración del atributo host en el listener http_foreign.
Figura 7: Comando spawn http_foreign
Cuando se ejecute el comando spawn podemos ver que un módulo es cargado y que éste tiene diferentes opciones. Se puede echar un ojo a lo que se pueda modificar, por ejemplo, la arquitectura. Cuando obtenemos el mensaje de “Agent spawned to http_foreign” sabemos que la nueva instancia de un agente de Empire se está ejecutando.
Figura 8: Instancia de Empire ejecutándose
Si analizásemos con un analizador de tráfico lo que ocurre en la máquina M1 podríamos ver la primera conexión del nuevo agente contra el listener http_foreign.
Si visualizamos lo que ocurre en la máquina M2 veríamos que ha llegado una nueva sesión, la cual viene de la máquina V. La funcionalidad Session Pass ha funcionado y ahora ambas máquinas, tanto M1 como M2, pueden interactuar con la máquina V, cada una desde su agente.
Figura 9: Sesión pasada de M1 a M2
Como se puede ver PowerShell Empire tiene muchas formas de interactuar a través de sus diversos listeners. Una herramienta cada vez más utilizada en el Ethical Hacking y que merece estudiarla y ver todas sus posibilidades. Una herramienta que no debemos quitar de nuestra mochila de pentesting.
Más Referencias de PowerShell Empire
- PowerShell Empire: Postexplotación++ en redes Windows
- PowerShell Empire: El imperio contraataca
- PowerShell Empire: Trabajando el PtH ("Pass the Hassh") con Mimikatz
- PowerShell Empire: Usar Dropbox como canal de hacking en post-explotación
- PowerShell Empire: 'Hop' en Empire para meter saltos en agentes de post-explotación
- PowerShell Empire: Cómo integrar Empire Project con Metasploit
- PowerShell Empire GUI: Un interfaz gráfico al más puro estilo Armitage
Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root" y “Pentesting con Powershell”, Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDO de Telefónica.
Sigue Un informático en el lado del mal - Google+ RSS 0xWord
Figura 1: PowerShell Empire.
"Cómo pasar sesiones entre máquinas con HTTP Foreign"
También hemos ido hablando de diferentes acciones de PowerShell Empire y de sus listeners y las posibilidades que éstos ofrecen. Por ejemplo, hemos visto como es su funcionamiento básico en el pentesting en ataques Pass the Hash, hemos trabajado con canales encubiertos para gestionar los agentes con Dropbox, cómo utilizar saltos intermedios entre el agente y el listener y, también, hemos visto cómo integrar herramientas como Metasploit en el uso del Empire y sus listeners.
Figura 2: Pentesting con PowerShell 2ª Edición
Sin duda, una herramienta con bastantes opciones y con más de 300 módulos de acciones disponibles. Hoy vamos a continuar con los listeners en PowerShell Empire, y haciendo algunas demostraciones prácticas con él.
HTTP Foreing
HTTP Foreign es un tipo de listener que permite pasar una sesión de una máquina a otra. El término ‘Session Pass’ es conocido para referirse a esto. Con Empire podemos imaginar un escenario en el que una máquina quiere traspasar una sesión a otra. El concepto clave en este punto es el uso de la misma clave de sesión o Session Key con la que se cifra la comunicación de los agentes con los listeners.
Figura 3: Sesión Pass con HTTP Foreign
Para este artículo podemos pensar en el siguiente escenario:
• Una máquina comprometida, por ejemplo, vía inyección de DLL generada con Empire y apuntando a nuestro listener. La máquina comprometida será un Windows 7, aunque puede ser cualquier otra versión de Windows, por ejemplo, un 10. La llamaremos V.• Una máquina con un listener que recibe la conexión desde la máquina Windows. Esta máquina será un Kali Linux. La llamaremos M1.• Una máquina con Kali Linux y Empire instalado. Se generará un listener a la escucha, el cual debe tener el mismo Session Key que el listener de la máquina anterior. La llamaremos M2.El punto de partida es la sesión creada entre el agente ejecutado en Windows y el listener que está a la escucha en la máquina Kali Linux, la más a la izquierda que se ve en la imagen anterior.
Obteniendo la primera sesión: de V a M1
Vamos a ver la configuración básica del listener HTTP clásico de PowerShell Empire. Con el comando uselistener cargamos el módulo http. No hay mucho que configurar, podemos dejar la conexión a la escucha en el puerto 80 y la dirección IP de la máquina.
Figura 4: Configuración de listener http en PowerShell Empire
Una vez que se obtiene la sesión en la máquina M1, ya se puede interactuar con el agente. Ahora queremos pasar la sesión de M1 a M2. Más que pasarla es compartir la máquina V.
Para realizar la siguiente acción se debe configurar en M1 un listener denominado http_foreign. Este listener tiene algo importante y es que el atributo host debe apuntar a la máquina M2 y no a la máquina M1. Es decir, cuando el agente que se está ejecutando en la máquina V se conecte al listener http_foreign será redireccionado a la máquina M2.
Figura 5: Sesión obtenida en máquina M1 y configuración de http foreing
En otras palabras, tenemos que configurar el atributo host, en este caso para apuntar a http://10.0.0.31:80. Es importante quedarse con el valor del StagingKey o lo que antes hemos llamado Session Key. Esto es algo fundamental para que la redirección de sesión funcione.
Session Pass: Llegando a la máquina M2
Ahora debemos colocarnos en la máquina M2, en este segundo Empire que estamos utilizando. De algún modo debemos pasarnos el StagingKey utilizado en la máquina M1 a la máquina M2. Una vez copiado, se debe ejecutar la instrucción set StagingKey [Valor]. Esto dentro del listener cargado. El listener que debemos utilizar en la máquina M2 es un listener http clásico.
Figura 6: Configurando StagingKey
Una vez configurado el listener en M2 se debe ejecutar y lo tendríamos listo y visible si ejecutamos el comando listeners. A continuación, se muestra la imagen de la configuración del listener y de la configuración del StagingKey.
¿Cómo conseguimos el Session Pass?
Esto es sencillo. Desde la máquina M1 podemos interactuar con el agente a través del comando interact. Desde esa sesión podemos ejecutar el comando spawn. Este comando permite generar una nueva instancia de un agente sobre la máquina V, en este caso.
El detalle es que queremos que la nueva instancia de un agente apunte al listener http_foreign. ¿Por qué? Sencillo, porque cuando la nueva instancia del agente de Empire se conecte al listener http_foreign, éste redirigirá a la M2. En este punto hay que acordarse de la configuración del atributo host en el listener http_foreign.
Figura 7: Comando spawn http_foreign
Cuando se ejecute el comando spawn podemos ver que un módulo es cargado y que éste tiene diferentes opciones. Se puede echar un ojo a lo que se pueda modificar, por ejemplo, la arquitectura. Cuando obtenemos el mensaje de “Agent spawned to http_foreign” sabemos que la nueva instancia de un agente de Empire se está ejecutando.
Figura 8: Instancia de Empire ejecutándose
Si analizásemos con un analizador de tráfico lo que ocurre en la máquina M1 podríamos ver la primera conexión del nuevo agente contra el listener http_foreign.
Si visualizamos lo que ocurre en la máquina M2 veríamos que ha llegado una nueva sesión, la cual viene de la máquina V. La funcionalidad Session Pass ha funcionado y ahora ambas máquinas, tanto M1 como M2, pueden interactuar con la máquina V, cada una desde su agente.
Figura 9: Sesión pasada de M1 a M2
Como se puede ver PowerShell Empire tiene muchas formas de interactuar a través de sus diversos listeners. Una herramienta cada vez más utilizada en el Ethical Hacking y que merece estudiarla y ver todas sus posibilidades. Una herramienta que no debemos quitar de nuestra mochila de pentesting.
Más Referencias de PowerShell Empire
- PowerShell Empire: Postexplotación++ en redes Windows
- PowerShell Empire: El imperio contraataca
- PowerShell Empire: Trabajando el PtH ("Pass the Hassh") con Mimikatz
- PowerShell Empire: Usar Dropbox como canal de hacking en post-explotación
- PowerShell Empire: 'Hop' en Empire para meter saltos en agentes de post-explotación
- PowerShell Empire: Cómo integrar Empire Project con Metasploit
- PowerShell Empire GUI: Un interfaz gráfico al más puro estilo Armitage
Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root" y “Pentesting con Powershell”, Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDO de Telefónica.
Sigue Un informático en el lado del mal - Google+ RSS 0xWord
Categories: Security Posts
WebDAV, NTLM & Responder
I was trying to create a capture file with NTLM authenticated WebDAV traffic, using Responder: I couldn’t get it to work. There was WebDAV traffic, but no NTLMSSP headers.
Long story short: there’s a bug in Responder version 2.3.3.9. It manifests itself when the WebDAV client sends a request with just headers, and “Content-Length: 0”, like this:
The code in Responder “sees” just “Content-Length” and waits for more packets:
I made a quick & dirty fix: break out of the loop when we see “Content-Length: 0” (servers/HTTP.py):
And now I have NTLMSSP headers:
I just start my modified version of Responder:
Generate WebDAV traffic from a Windows 7 client:
And Responder participates in the challenge:
This can of course be cracked (if the password is not too complex), with John The Ripper for example:
I also have a blog post with more details about WebDAV traffic from Windows clients.
Once I got Responder to work, I searched on Laurent’s Responder repository, and found a pull-request to fix issues with “Content-Length: 0” requests (this PR has not been merged yet). Hence I’m not going to do my own PR.
You can find the capture file here:
webdav-ntlm-responder.zip (https)
MD5: A427DDBDAF090E93BB75B7A8DE696826
SHA256: 2F92CDD7382DD3622AC1F8769CF9D065C60C235DEF764E6709C32E2C4A7554A8
MD5: A427DDBDAF090E93BB75B7A8DE696826
SHA256: 2F92CDD7382DD3622AC1F8769CF9D065C60C235DEF764E6709C32E2C4A7554A8
Categories: Security Posts
Getting in the Zone: dumping Active Directory DNS using adidnsdump
Zone transfers are a classical way of performing reconnaissance in networks (or even from the internet). They require an insecurely configured DNS server that allows anonymous users to transfer all records and gather information about host in the network. What not many people know however is that if Active Directory integrated DNS is used, any user can query all the DNS records by default. This blog introduces a tool to do this and describes a method to do this even for records normal users don’t have read rights for.
Knowing where you are and where to go
Personally whenever I arrive at a new pentest or red team assignment I want to learn about the layout of the network, the software in use and where the interesting data is. If a company has non-descriptive server names or descriptions, tools like BloodHound or ldapdomaindump are not going to help much since SRV00001.company.local still doesn’t tell me what runs on this host. Running discovery tools like EyeWitness on a large range of IP addresses often returns a lot of default Apache/IIS pages, since most sites are configured to listen on a DNS name and not on the IP address. Knowing that gitlab.company.local also points to the same IP as SRV00001.company.local tells me that this is an interesting server if I’m after source code. Having access to DNS entries for AD is thus in my opinion quite valuable. Thus I wrote this small tool that can dump those records. You can either run it directly from a host within the network, or through a SOCKS tunnel using your favourite implant.
Prior work
This started when I was looking at Active Directory DNS, mostly inspired by Kevin Robertson’s work on ADIDNS. I tried to figure out how AD uses zones in LDAP for storing DNS records as I pulled up ADSI Edit and suddenly saw an overview of all the DNS records in the domain, using only a limited regular user. As I shared my surprise, Kevin pointed out to me that mubix already wrote about this back in 2013. So there was already a PowerShell script that could do this, but it didn’t do exactly what I wanted, so I decided to write a version in Python and add some options to enumerate more records than possible by default.
The “hidden” DNS records
The most obvious way to query for DNS records in LDAP would be to perform a query selecting all objects of the class dnsNode, which represent entries in the DNS zone. When I performed a query with the filter (objectClass=dnsNode), this returned quite limited results, even though I could see several more records when manually browsing to the DNS zone:
As visible on the image above, for several objects the objectClass is not visible. This is because of the default permissions on computer DNS records (and I think on other records not created via the AD DNS gui as well), which don’t allow all users to see the contents. Since the IP addresses are actually stored as a property of this object, it isn’t possible to view the IP address for these records either.
But like any user can create new DNS records by default, any user can also list the child objects of a DNS zone by default. So we know a records is there, we just can’t query it using LDAP.
Once we know a records exists by enumerating with LDAP, we can however query for it using DNS directly (since performing regular DNS queries doesn’t require privileges). This way we can resolve all records in the zone.
Querying records with adidnsdump
With adidnsdump, which you can get from my GitHub, it is possible to enumerate all records in the DNS zone. To get started, first display the zones in the domain where you are currently in with --print-zones. This will show which zones are present. Not all zones are interesting, for example forward, cache and stub zones don’t contain all the records for that domain. If you find these zones, it’s better to query the domain to which they actually belong. The output below shows that my test domain has only the default zones:
user@localhost:~/adidnsdump$ adidnsdump -u icorp\\testuser --print-zones icorp-dc.internal.corp
Password:
[-] Connecting to host...
[-] Binding to host
[+] Bind OK
[-] Found 2 domain DNS zones:
internal.corp
RootDNSServers
[-] Found 2 forest DNS zones:
..TrustAnchors
_msdcs.internal.corp
If we specify the zone to the tool (or leave it empty for the default zone), we will get a list of all the records. Records which can be listed but not read (so called “hidden” records) are shown but only with a question mark, as it is unknown which type of record is present and where it points to. The records are all saved to a file called records.csv.
To resolve the unknown records, specify the -r flag, which will perform an A query for all unknown records (you can easily change this to AAAA in the code if you’re in an IPv6 network). Several nodes which were blank before now suddenly have records:
If you don’t have a direct connection but are working via an agent, you can proxy the tool through socks and perform the DNS queries over TCP with the --dns-tcp flag.
Mitigations
You shouldn’t really rely on secrecy of your DNS records for security. If you really want to hide this information, removing the “List contents” permission for “Everyone” and “Pre-Windows 2000 Compatible Access” does prevent regular users from querying the entries, but this does require disabling inheritance on the DNS zone and may break stuff, so I don’t really recommend going that way. Monitoring for high volumes of DNS queries or enabling auditing on DNS zone listings may be a better way to deal with this, by detecting instead of blocking this kind of activity.
The tools
adidnsdump is available on GitHub and on PyPI (pip install adidnsdump). Right now the tool only dumps records to CSV files, but feel free to submit requests for alternate formats.
This blog was originally published on dirkjanm.io
Categories: Security Posts
Pattern Welding Explained as Wearable Art
Pattern-Welding was used throughout the Viking-age to imbue swords with intricate patterns that were associated with mystical qualities. This visualization shows the pattern progression in a twisted road with increasing removal of material. It took me two years of intermittent work to get to this image. I liked this image so much that I ordered it for myself as a t-shirt and am looking forward for people asking me what the image is all about. If you want to get a t-shirt yourself, you can order this design via RedBubble. If you end up ordering a t-shirt, let me know if it ends up getting you into any interesting conversations!
Categories: Security Posts
