Todos los días se producen infecciones de equipos que, si bien no suponen un gran impacto en la organización en la mayoría de casos, sí conviene actuar para que el cúmulo de éstos no suponga un riesgo para la información de la misma. Además, ante el desconocimiento de cualquier actividad sospechosa que pudiera estar realizando un activo, conviente tomar medidas antes de encontrarnos con un incidente grave.
En esto consiste la respuesta ante incidentes en equipos de usuario. Aunque sabemos que los antivirus son necesarios en cualquier equipo (sin descuidar los servidores), no impiden que los sistemas acaben comprometidos, por lo que otros mecanismos de detección son necesarios, como los NIDS o HIDS. Una vez se detecta un posible compromiso en un equipo, debemos confirmarlo antes de emprender las acciones de erradicación, por lo que viene bien una respuesta rápida ante incidentes que permita analizar el equipo de forma ágil y con el mínimo impacto en la actividad del usuario.
Por esto estuve buscando alguna herramienta que permitiera recopilar información y ejecutar determinadas acciones en el sistema y encontré PSRecon. PSRecon es una herramienta escrita en PowerShell que recopila información de un sistema Windows remoto y la presenta de forma sencilla para el analista, pudiendo enviar dicha información por correo electrónico o copiarla a un recurso compartido, así como dejarlo en una ubicación local. La herramienta está desarrollada por Greg Foss (@heinzarelli), de LogRhythm Labs, y fue presentada en la BlackHat USA 2015 liberada bajo licencia Apache 2.0.
Esta aplicación recopila la siguiente información del sistema:
System Data:
- User Data.
- Systema Data.
- Enviroment Variables.
- GPResult.
- Windows Patches.
- Firewall Configuration.
- Command Line History.
- Scheduled Tasks.
Web Data:
- Internet Explorer History.
- Recent Emails.
- Extracted Email Links.
- Downloaded Files.
- Downloaded Files Hashes.
Registry and Log Data:
- USB Device History.
- Remote Desktop History.
- Successful Logons [EVID: 4624].
- Successful Logons [EVID: 4648].
- Registry Persistence.
- Startup Drivers.
- User and Temp Startup Drivers.
- PowerShell Scripts.
Software and Process Data:
- Installed Software.
- Anti Virus.
- Services.
- Process File Hashes.
- Service Detail.
- Prefetch Files.
- AT Jobs.
Network Data:
- Hosts Networks.
- Network Shares.
- SMB Sessions.
- DNS Cache.
- ARP Table.
- Network Status.
- Listening Processes.
- Network Services.
Configuration:
- Evidence Hashes.
- PowerShell Information and Hashes.
- PowerShell Profile.
Con toda esta información suele ser suficiente, en la mayoría de los casos, para determinar si un equipo tiene sospechas de estar comprometido. No obstante, al tratarse de un script en PowerShell, podemos editarlo y añadir aquella información que necesitemos. Por ejemplo, el script consulta las conexiones de red abiertas. Personalmente, me gusta añadir la opción para mostrar la aplicación que ha abierto cada conexión de red, en busca de código malicioso comunicándose con el exterior, por lo que se puede editar el script a nuestras necesidades.
Una característica muy interesante es la capacidad de bloquear la máquina deshabilitando la interfaz de red (-lockdown) así como bloquear el usuario en el dominio (-adLock) en caso de que sospechemos que pueda afectar a otros equipos en la red.
Para poder ejecutar este script debemos antes hacer algunos cambios en la configuración del equipo para permitir la ejecución de PowerShell de forma remota y rebajar las restricciones en la política de PowerShell. Esto, evidentemente, realiza cambios en el sistema por lo que debemos tener en cuenta esto en caso de un análisis forense oficial.
Para ejecutar los comandos de forma remota haremos uso de otra gran aplicación incluida en las SysInternals, PsExec.exe. Lo haremos por dos motivos. El primero es porque necesitamos deshabilitar las restricciones de PowerShell en el equipo remoto. La segunda es que la opción de PSRecon de copiar el resultado en un recurso compartido remoto sólo funciona cuando se ejecuta localmente, por lo que en lugar de ejecutarlo en el equipo del analista con la opción -remote, es mejor lanzarlo en el equipo remoto con PsExec tras haber copiado el script.
#Copiamos el archivo al equipo comprometido C:\> xcopy psrecon.ps1 \\192.168.56.102\C$\Users\user1\ # Permitimos la ejecución remota de PS (opcional si se lanza remotamente). PS C:\> PsExec.exe \\192.168.56.102 -u user1 -h -d powershell.exe "Enable-PSRemoting -Force" # Mostramos la política y la establecemos a Unrestricted. PS C:\> PsExec.exe \\192.168.56.102 -u user1 -h powershell.exe "Get-ExecutionPolicy" PS C:\> PsExec.exe \\192.168.56.102 -u user1 -h -d powershell.exe "Set-ExecutionPolicy Unrestricted -Force" # Ejecutamos el script PS C:\Users\user1\Desktop> .\PsExec.exe \\192.168.56.102 -u ORG\user1 -h powershell.exe "C:\Users\user1\psrecon.ps1 -share -netShare \\192.168.56.1\IR" PS C:\> PsExec.exe \\192.168.56.102 -u user1 -h -d powershell.exe "Set-ExecutionPolicy Restricted -Force"
#Restablecemos la política que tenía anteriormente PS C:\> PsExec.exe \\192.168.56.102 -u user1 -h -d powershell.exe "Set-ExecutionPolicy Restricted -Force" # Deshabilitamos la ejecución remota de PS (si se ha habilitado anteriormente) PS C:\> PsExec.exe \\192.168.56.102 -u user1 -h -d powershell.exe "Disable-PSRemoting -Force"
La única limitación, si se usa un recurso remoto, es que el usuario que ejecuta el script tenga permisos para escribir en el recurso remoto, pero recomienda definir un recurso especial e independiente para este tipo de actuaciones.
Respecto a la información, es suficientemente completa para poder determinar si el equipo está comprometido o no, y la forma de presentar es bastante aceptable, por lo que es una solución bastante interesante y que tiene muchas posibilidades de mejora y ampliación.
