Los virus del futuro: Nuevos malware "invisibles" que no crean archivos maliciosos

Tradicionalmente el malware crea ficheros, copias de sí mismo o malware adicional que replica en diferentes ubicaciones del sistema que compromete, pudiendo hacerlo además con nombres similares a ficheros legítimos, con el fin de pasar desapercibido el mayor tiempo posible. Así mismo, con el fin de mantener persistencia, se ejecuta de manera automática mediante un servicio o una tarea programada, o desde el registro creando para ello valores en alguna de las claves que se cargan al iniciar el sistema operativo como, por ejemplo:

• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
• HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run
• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce
• HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\RunOnce
• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run
• HKLM\Software\ Microsoft\Windows\CurrentVersion\RunServices
• HKLM\Wow6432Node\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run

Pese a que esta práctica se sigue manteniendo hoy en día, desde hace ya tiempo, y cada vez más habitualmente, con el fin de dificultar la labor de las suites de seguridad, las cuales, además de detecciones por firmas, monitorizan los cambios en el sistema mediante protecciones heurísticas, los creadores de malware han optado por un modelo sin fichero «Fileless Malware». Este tipo de malware, también conocido como «hit & run» ya que comprometen los sistemas, realizan la tarea para la que han sido diseñados y posteriormente desaparecen procurando no dejar rastro, se mantiene residente únicamente en memoria y, como su propio nombre indica, no en disco, y aprovecha de manera habitual las características, funcionalidades y herramientas propias de los sistemas operativos en su beneficio como, por ejemplo:

• Windows Management Instrumentation (WMI): atendiendo a la definición de Microsoft, “es la fuente principal para administrar los datos y la funcionalidad en equipos locales y remotos que ejecutan los sistemas operativos Microsoft Windows”. Permite realizar multitud de tareas como realizar copias de seguridad, autorizar usuarios o grupos y establecer niveles de permisos, etc.
• PowerShell: atendiendo a la definición de Microsoft, “es un lenguaje de scripting y shell de línea de comandos basado en tareas diseñado especialmente para la administración del sistema”. Está llamado a sustituir a la tradicional consola de comandos.
• Host de aplicación HTML de Microsoft (MSHTA): permite interpretar código JavaScript.

Estas aplicaciones, además de muy potentes, se ejecutan con los permisos del usuario logueado en la máquina y apenas dejan rastro, lo que representa una ventaja adicional y significativa para los creadores de malware.

Con el fin de concretar la utilidad y uso de estas herramientas durante un ataque, a continuación, se indica el modelo desarrollado por analistas de Lockheed Martin Corporation en 2011 conocido como Cyber Kill Chain, de lo que ya hablé anteriormente en este post .

Si bien su utilización no es exclusiva durante las fases que a continuación se indican, de manera habitual se usan durante:

• Distribución, a modo de downloader (por ejemplo, mediante una macro).

• 
  
  
  
• Explotación, para realizar un movimiento lateral, para obtener credenciales, realizar un escalado de privilegios o para extraer información.

Código en PowerShell para realizar capturas de pantalla.

• Instalación, para establecer la persistencia en el caso de que el malware lo requiera.

Ejemplo de cómo el malware GAV: Poweliks.CCL utiliza rundll32.exe para mantener persistencia.

Desde 2010, cuando se detectó WMIGhost, uno de los primeros malware que se identificó que aprovechaba WMI para fines maliciosos, se han detectado multitud de familias de malware que se aprovechan de las utilidades anteriormente indicadas: Poweliks, Trojan.Kotver, JS.Nemucod (el cual descarga un ransomware) o PowerSniff son sólo algunos ejemplos de ello.

Es importante tener en cuenta que el «fileless malware» no es exclusivo de Windows, sino que también está presente en otros sistemas operativos. Para ello, utilizan herramientas instaladas por defecto que soportan lenguajes de scripting como perl, python, bash, ruby, etc. o incluso el propio PowerShell, disponible ya tanto para Linux como para OSX.

Es por ello que hay que ser consciente del riesgo que suponen este tipo de amenazas y tomar las medidas necesarias para reducir o dificultar la exposición a ellas.

• Utilizar una política de usuarios con privilegios limitados.
• Instalar la última versión de PowerShell.
• Configurar AppLocker para bloquear la ejecución de ficheros relacionados con PowerShell, como por ejemplo aquellos con extensión .ps1, o para poder ejecutar ficheros únicamente desde rutas confiables.
• Establecer una directiva de grupo (GPO) del tipo de restricción de software (SRP) indicando el hash el fichero PowerShell.exe con el fin de bloquear su ejecución. Pese a ello, hay que tener en cuenta que se pueden seguir ejecutando instancias de PowerShell sin necesidad de invocar al fichero ejecutable.
• Pese a que la política por defecto de PowerShell es la de restringir la ejecución de scripts, no es excesivamente complicado saltársela. Existen múltiples modos como, por ejemplo: cargar un fichero directamente desde Internet sin almacenarlo en disco mediante «Invoke Expression», leer un script y redirigirlo al ejecutable PowerShell.exe o utilizar el flag «Bypass» en la ejecución. Es por ello que se recomienda establecer una directiva de grupo (GPO) para activar los logs de PowerShell, y monitorizarlos en busca de patrones como los que indico a continuación:

• • • kernel32.dll
    • msvcrt.dll
    • OpenProcess
    • VirtualAllocEx
    • VirtualAlloc
    • WriteProcessMemory
    • GetModuleHandle
    • GetProcAddress
    • VirtualProtect
    • CreateRemoteThread
    • CreateThread
    • CloseHandle

• • Relacionados con inyección de código:
    •  Invoke-Expression
    •  iex
    •  Invoke-Command
    •  powershell/powershell.exe

• • Relacionados con la actividad de red:
    • System.Net.HttpWebClient
    • System.Net.WebClient
    • System.Net.HttpListener
    •  System.Net.Sockets.Socket

• • Relacionados con el cifrado de datos:
    • ConvertTo-SecureString cmdlet
    • Security.Cryptography.CryptoStream
    • [System.Convert]::ToBase64String($string)
    • Identifying any random or encoded data chunks
    • Búsqueda de términos como encrypt, crypt, password, pass, etc.

• Relacionado con el punto anterior y con el fin de simplificar el proceso, lo más óptimo es centralizar la gestión de logs.
• Establecer una directiva de grupo para bloquear las macros de Office (disponible a partir de Office 2016).
• Es posible utilizar algún plugin de Volatility para monitorizar la memoria en tiempo real en busca de ciertos patrones.
• Monitorizar las entradas de registro habituales donde el malware establece persistencia.

Por otra parte, existen una serie de utilidades que pueden ayudar en esta tarea, así como para profundizar más en el tema:

• Autoruns – muestra las aplicaciones y servicios que se ejecutan al iniciar el sistema operativo. Tiene soporte para entradas WMI.
• Frameworks orientados a las fases de explotación y post-explotación en un pentesting: PowerSploit, Empire, Nishang o p0wnedShell.

Referencias:

http://papers.rohanamin.com/wp-content/uploads/papers.rohanamin.com/2011/08/iciw2011.pdf

https://www.mysonicwall.com/sonicalert/searchresults.aspx?ev=article&id=761

http://researchcenter.paloaltonetworks.com/2016/03/powersniff-malware-used-in-macro-based-attacks/

http://www.asd.gov.au/publications/protect/Securing_PowerShell.pdf

http://www.volatilityfoundation.org/

https://technet.microsoft.com/ko-kr/sysinternals/bb963902

https://www.powershellempire.com/