REMCOS RAT – .NET Unpacking

REMCOS es un software de acceso y control remoto comercial escrito en C++ y Delphi, tiene amplia documentación y soporte en su sitio. -PoC Remcos Remote Control Administration of remote systems –

Sus primeras apariciones en malpedia fueron en 2017, teniendo una mayor visibilidad en los medios y la comunidad en 2020. Sus TTP fueron bien documentadas y ampliamente registradas, dejare fuentes de investigación interesantes al final del artículo.

https://malpedia.caad.fkie.fraunhofer.de/details/win.remcos

BitDefender publicó recientemente detalles sobre una campaña asociando a REMCOS, entre las tecnicas a destacar:

Mapping DLLs into the address space and resolving functions in the mapped file instead of the conventional LoadLibrary + GetProcAddress function calls

Hosting payloads on Imgur and employing a custom steganography algorithm to encode and decode data

Multiple layers of code injection to hide malicious actions behind seemingly legitimate processes

La muestra que vamos a tratar hoy tiene distintas composiciones o capas, a lo largo del informe se van a detallar los pasos que fuimos dando hasta llegar a obtener finalmente malware REMCOS.

En principio vamos observar un binario que utiliza como compilador .NET, a medida que avanzamos con en el análisis iremos dando con indicios que nos van a confirmar la existencia de otros binarios. Esta práctica es común a la hora de entregar piezas de malware conocidas, ayuda a evadir controles de AV/ERD. Hay que tener presente que esas capas adicionales también pueden utilizar packers que dificulten aún más el análisis.

Al final del informe se podrá comprender de qué forma se preparó a REMCOS para ser entregado, teniendo cómo resultado los portables ejecutables utilizados, cifrado de comunicaciones al c2 y posibles funcionalidades del malware no observadas en otro tipo de análisis.

La muestra la descargamos directamente desde AnyRUN al azar, el decoder lo obtuvimos del colega dark0pcodes a quien quiero agradecer por darme animos a escribir esta entrada y tomarse el tiempo para responder mis dudas sobre el tratamiento de este caso que vamos a compartir. Pueden encontrar mas sobre sus investigaciones en su web https://darkopcodes.wordpress.com/, tambien dejare un enlace de su Workshop en ekoparty2020 «Threat Intelligence, the Malware Analysis Way».

La información del archivo que vamos a tratar es la siguiente:

Filename: sake.exe
MD5: 83c72a4a182bf4f77cb143fce1559006
SHA256: 3908ede26aad1fc2a1db9d3a26a017549b40ebc7d73d731fcb5691aab82b830f
Magic: sake.exe: PE32 executable (GUI) Intel 80386 Mono/.Net assembly, for MS Windows
Sandbox1: VT
Sandbox2: AnyRUN

Para el análisis vamos a utilizar las siguientes herramientas:

Detect-It-Easy: – Detect It Easy, or abbreviated «DIE» is a program for determining types of files.
pestudio: – is to spot artifacts of executable files.
dnSpy: is a debugger and .NET assembly editor.
x64dbg: An open-source x64/x32 debugger fo r windows.
Megadumper (.NET): Dump native and .NET assemblies.
HxD: View / Editor Hexadecimal Windows.
TSCD: TS CD Hex Dump
Decrypt: REMCOS RAT settings (Script)

Pueden encontrar estás herramientas y más en el Toolkit de Indetectables

Inicialmente abrimos el documento con pestudio y Detect-It-Easy , que nos va a proveer de datos mínimos en los strings y el tipo de packer que puede estar utilizando -o no-. Es recomendable comparar entre herramientas rápidamente y obtener de ellas lo realmente necesario para tener una idea inicial del archivo.

Imports, Strings, Libreries other dats: «selfbot.exe» / volcano.dat»

El resto de los strings son ilegibles o bien forman parte del método de compilación, por lo que comparamos con Detect Easy y HxD antes de abrir el debugger.

La última revisión rápida la podemos llevar a cabo con un editor hexadecimal y luego pueden optar por ejecutar la muestra sin conexión a internet o bien utilizar dnSpy para un debug, en nuestro caso vamos por esta ultima opción.

ACLARACIÓN: No estamos relevando comunicaciones en esta instancia, aunque si lo desean pueden utilizar INetSim o FakeNet para simular trafico, capturarlo y analizarlo con CapTipper .

Ya tenemos establecido que el método de compilación es .NET y encontramos más información sobre posibles .exe o .dat , esa información la mostró inicialmente pestudio.

Una buena idea sería intentar identificar la cabeceras del PE en este caso «MZ» en ASCII / «4d 5a» en Hexadecimal o bien «UPX» que también fue mostrado anteriormente.

En la seccion 00000430 se puede observar «erotic.dat» y seguido «4d 5a o MZ»

Seccion 000053e0 se vuelven a ver los strings «4d 5a o MZ»

En esta instancia procederemos a ejecutar sake.exe con dnSpy y tratar de confirmar si existe más de un ejecutable en este archivo inicial.

Confirmamos entonces que la información previa que habiamos obtenido corresponde a resources del archivo inicial.

Resources – View dnSpy.
0x00000364: planet.resources‎ (37082 bytes, Embedded, Public)
0x00000439: erotic.dat‎ = 36864 bytes

0x00009444: poorcharm.resources‎ (6364 bytes, Embedded, Public)
0x0000951B: volcano.dat‎ = 6144 bytes

Lo que más resalta a simple vista en la siguiente imagen es la construcción de los arrays(GetResource) seguido de (CreateInstance) para terminar de cargar en un nuevo objeto. En la siguiente ejecución se puede observar cómo se van a utilizar los strings «name» y «key». (tambien existe un XOR)

Procedemos a establecer 2 Breakpoints(BP) en las (lineas 22 y 32) secciones que nos parecieron más interesantes, la idea es poder dummpear los procesos a medida que avanzamos y entender cómo se comporta la muestra.

La primer ejecución nos evidencia cómo utiliza los strings que observamos anteriormente. Es importante activar MegaDumpper para que registre cada ejecución. (botón derecho sobre cualquier PID de interés opción: «NET Dumper» y creara una carpeta llamada Dumps).

Primer BP ejecutado, evidenciando la utilización de name / key.

En la segunda ejecución y trás dumpear nuevamente el proceso con MegaDumpper obtenemos una DLL. (belong.dll MD5: 0332CE0C766F4412F539462C1E4DA63D), con este nuevo elemento se deben repetir los pasos anteriores (pestudio, detect-it-easy,hxd, dnSpy)

(belong.dll MD5: 0332CE0C766F4412F539462C1E4DA63D)

*belong.dll MD5: 0332CE0C766F4412F539462C1E4DA63D* desde dnSpy Decode Base64 Strings

Nos resta una última ejecución con dnSpy que terminaria creando el proceso selfbot.exe en el path «c:\user\user\appdata\roaming\selfbot.exe» cómo así también \AppData\Roaming\Screens\.

Este ultimo BP termina de crear el file selfbot.exe

MegaDumper habrá registrado los siguientes procesos durante todo el flujo de ejecución. Deben mantenerlo en activo desde el primer BP que establecimos anteriormente.

Finalmente obtuvimos selfbot.exe que termina utilizando UPX como packer.

Ultimop ejecutable utilizando UPX como packer.

En esta entrada no vamos a cubrir el unpacking de UPX, con localizar el Jump Tail y establecer un BP en esa instancia pueden posteriormente utilizar Scylla y OllyDumpEx. (Recuerden que al abrirlo desde x64dbg el entrypoint debe estar situado en PUSHAD.)

Tail Jump , se debe establecer un BP y Ejecutarlo para posteriormente utilizar Scylla y OllyDumpEx

Si lograron el parchado con éxito les quedara un binario con strings mucho más claros. Se pueden apreciar los comandos que utiliza REMCOS para sus operaciones.

Por último renombrar este archivo a «remcos.exe» y ejecutar extractor.py para extraer el C2 al cual se comunica la muestra.

extractor.py https://github.com/dark0pcodes/remcos_rat_decoder

Obtenemos los siguientes valores:

b’transcendentalistschool[.]com[:]37845[:]hackedbysakegang|@@Sake@@5@@\x01@@\x01@@\x00@@\x00@@\x00@@\x00@@
6@@sake.exe@@sake@@\x00@@0@@remcos_dblkdlqwgt@@1@@6@@logs.dat@@\x01@@\x00@@\x01@@60@@\x00@@@@5@@6@@S
creens@@\x00@@\x00@@\x00@@\x00@@\x00@@\x00@@\x00@@\x00@@\x00@@5@@6@@audio@@\x00@@0@@0@@@@\x00@@\x01@
@0@@\x00@@1@@sake@@sake@@’

Fuentes:

2017-12-22 – MALSPAM USES CVE-2017-0199 TO DISTRIBUTE REMCOS RAT

Remcos RAT Revisited: A Colombian Coronavirus-Themed Campaign

Malware Analysis – .NET Unpacking Channel: MalwareAnalysisForHedgehogs

Eko2020 Workshop | Felipe Duarte: Threat Intelligence, the Malware Analysis Way

Commodity .NET Packers use Embedded Images to Hide Payloads

x64dbg | UPX Unpacker

FakeNet Genie: Improving Dynamic Malware Analysis with Cheat Codes for FakeNet-NG

«Anti-Virus ARTIFACTS I» Autor: Devisha Rochlani

(Repositorio: https://github.com/D3VI5H4)
(Twitter: https://twitter.com/devisharochlani)

En la primera entrega el autor nos enfoca rápidamente en el ejercicio de reconocimiento de los artefactos que componen a un sistema anti-virus. Se han analizado distintos productos del mercado como ser Avira, F-Secure, Norton, TrendMicro entre otros.

El autor nos presenta rápidamente las dll’s hookeadas, donde se guardan los archivos drives y una descripción de sus funciones.

Drivers Present: (Name, Description, Path)
DLL’s Present: Drivers Present (Name, Description, Path)
Functions Hooked: (DLL Name, API Name)

Este abordaje inicial de investigación ha mostrado que los productos actuales no hacen una lectura total y clara entre las APIS y sus reenvíos, permitiendo al desarrollador de malware tener un vector amplio para ejecutar sus funciones y lograr un bypass satisfactorio y posteriormente continuar con su cadena de infección y/o propagación.

Un ejemplo para referenciar lo explicado anteriormente se puede dar con NTDLL.DLL que esta disponible desde la ejecución del usuario y el sistema operativo .(incluso es un tema mucho mas complejo que solo este texto, tal vez para otra entrada). Los AV /EDR utilizan el Hookeo de APIS para interceptar las llamadas a las funciones, redireccionando el flujo del código para controlarlo y de esa forma hacer una revisión en detalle y determinar si una pieza corresponde a código malicioso.

Funciones Hookeadas para NTDLL.DLL AV: WebRoot

Podes encontrar las conclusiones finales de la primer entrega y sus versiones II y III del enfoque. Esta esta primer observación el listado de DLL’s, descripción de funciones y una PoC final sobe un keylogger en el repositorio oficial del Autor : https://github.com/D3VI5H4/Antivirus-Artifacts/blob/main/ANTIVURUS_ARTIFACTS.pdf

Desarrolladores de Exploit PlayBit y Volodya

Los investigadores Eyal Itkin e Itay Cohen de Checkpoint han desarrollado una investigación muy recomendable. El principal objetivo es centrarse en el punto de vista del exploiter en este caso PlayBit o luxor2008, sobre todo en sus técnicas, tácticas y procedimientos (TTPs) al desarrollar y planificar su código de explotación.

Graphology of an Exploit : https://vblocalhost.com/uploads/VB2020-04.pdf

Volodya

Anteriormente habían expuesto evidencia asociada a Volodya, otro destacado desarrollador de exploits, fue rastreado utilizando sus «huellas digitales» en el desarrollo, incluso se ha demostrado una notable evolución por parte del adversario a la hora de emplear el código. Las muestras de la investigación han sido 900 de las cuales se han podido identificar 12 CVE’s.

CVE-2016-0165
CVE-2015-2546
CVE-2016-0040
CVE-2017-0001
CVE-2018-8641
CVE-2019-1458
CVE-2016-0167
CVE-2018-8453 PlayBit (a.k.a luxor2008)
CVE-2013-3660 PlayBit (a.k.a luxor2008)
CVE-2015-0057 PlayBit (a.k.a luxor2008)
CVE-2015-1701 PlayBit (a.k.a luxor2008)
CVE-2016-7255 PlayBit (a.k.a luxor2008)

Grupos identificados reconocidos utilizando el exploit y sus CVE identificados. (APT28, Ursnif & Dreambot, GanCrab, Cerber, Turla, Magniber, Buhtrap, FIN8).

Por otro lado, se hace hincapié fundamental en el perfilamiento y explotación desde el punto de vista de vulnerabilidades del tipo LPE, permitiendo entender el enfoque inicial del desarrollo de exploits.

Playbit

Unos de los CVE con los que CheckPoint inicia el perfilamiento para Playbit es CVE-2018-8453, dicha vulnerabilidad fue investigada previamente por Kasperksy «Sodin ransomware exploits Windows vulnerability and processor architecture» también observado y explotada por Sodin, Sodinokibi y REvil.

CVE-2018-8453
Classification: 1-Day
Basic Description: Use-after-free in win32kfull!xxxDestroyWindow
Used by the following malware families: REvil (Sodinokibi), Maze, Neshta
Background on this vulnerability:
Originally exploited as a 0-Day, and attributed to FruityArmor.
URL: https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2018-8453
PoC: leHACK 2019: Analyzing CVE-2018-8453: An interesting tale of UAF and Double Free in Windows Kernel

CVE-2013-3660
Classification: 1-Day
Basic Description: Uninitialized kernel pointer in EPATHOBJ::pprFlattenRec
Used by the following malware families: Dyre, Ramnit
Background on this vulnerability:
This vulnerability was originally found by Google’s Tavis Ormandy, and made headlines due to an unusual disclosure process as Microsoft was not notified about the vulnerability before the full disclosure.
PoC: The Powerloader 64‑bit update based on leaked exploits

Banner del Exploit LPE **CVE-2013-3660** by Playbit – https://research.checkpoint.com/2020/graphology-of-an-exploit-playbit/

CVE-2015-0057
Classification: 1-Day
Basic Description: Use-After-Free in win32k!xxxEnableWndSBArrows
Used by the following malware families: Dyre, Evotob
Background on this vulnerability:
MS15-010 Report: Udi Yavo CTO of enSilo
Blackhat FireEye: Dyre Banking Exploit: CVE-2015-0057

CVE-2015-1701
Classification: 1-Day
Basic Description: CreateWindow callback validation error
Used by the following malware families: Locky
Background on this vulnerability:
Also known as MS15-051, this vulnerability was originally exploited as a 0-Day in an operation attributed to APT28.
Operation RussianDoll: Adobe & Windows Zero-Day Exploits Likely Leveraged by Russia’s APT28 in Highly-Targeted Attack
Locky Ransomware Spreads via Flash and Windows Kernel Exploits CVE-2015-1701
URL: https://docs.microsoft.com/en-us/security-updates/securitybulletins/2015/ms15-051

….Continuara!

Actualización de Adversario «WIZARD SPIDER».

Recientemente Crowdstrike ha dado a conocer detalles interesantes asociados al grupo criminal WIZARD SPIDER con sede en Rusia, pretenden ser actores de alto nivel en el marco de amenazas globales. Inicialmente se han centrado en el robo bancario utilizando TrickBot, Ryuk , BitPaymer y Samas dirigido a entornos corporativos.

En análisis recientes al comparar Ryuk con Hermes tienen bastante relación y su arsenal se ve en constante desarrollo. Por otro lado Hermes es un ransomware básico que fue observado en foros underground a la venta, por lo que es común que existan modificaciones de él.

El principal objetivo de WIZARD SPIDER es optimizar su framework de monetización, hacerlo más efectivo y automático por lo que sus tácticas, técnicas y procedimientos están en constante desarrollo.

Troyano TrickBot

La pieza central del grupo WIZARD SPIDER para desplegar sus operaciones fue TrickBot, recientemente esa botnet fue desarticulada, detrás de esa operación se han visto vinculados distintos participantes, como ser Microsoft, ESET y agencias Gubernamentales de Estados Unidos, se cree que el 90% de la estructura de Trickbot fue aislada.

Entre el 21 y 22 de septiembre CrowdStrike Intelligence observó que se distribuía un archivo de configuración no estándar a las víctimas infectadas con TrickBot. Dichos comandos provenían del C2 y le daban la orden al bot de que cambie sus comunicaciones hacia el servidor de comando y control (C2) 0.0.0.1 en el puerto TCP 1. Esto generó el aislamiento de esas máquinas y una baja importante para esa botnet.

Backdoor BazarLoader

Adicionalmente a Trickbot, WIZARD SPIDER ha estado utilizando BazarLoader (también conocido como Kegtap ), también se lo ha visto muy asociado a Ryuk. Las campañas de spam vinculadas a BazarLoader recientemente identificadas consisten en correos electrónicos que contienen un enlace a un archivo de Google Docs para posteriormente redireccionar la descarga del binario desde un sitio externo.

Ejemplo de archivo PDF en Google Docs de BazarLoader

Ejemplo de aviso falso Microsoft Teams PDF de BazarLoader

Los componentes de puerta trasera de BazarLoader tienen potencial de ejecutar cargas útiles arbitrarias, secuencias de comandos de PowerShell y por lotes, extraer archivos de una víctima y finalizar los procesos en ejecución. Además del componente de puerta trasera, hemos observado que WIZARD SPIDER implementa y utiliza el marco de post-explotación CobaltStrike .

Conti Ransomware

Los últimos meses han visto un resurgimiento de la actividad de WIZARD SPIDER y la introducción del ransomware Conti. Una de las mejoras incorporadas en Conti es el uso de DLS (Data Leak Site), de esta forma es posible identificar a los clientes comprometidos.

Conti es una representación convencional del ransomware moderno. Repite los archivos del sistema local y los de los recursos compartidos de red SMB destino para determinar qué datos cifrar. Luego utiliza el cifrado AES-256 a través de una clave pública codificada, este último método cifrado lo han comenzado a utilizar en Agosto 2020.

El desarrollo continuo de WIZARD SPIDER de Conti se centra igualmente en la evasión del software antivirus tradicional basado en firmas y en obstaculizar los esfuerzos de análisis de malware. Crowdstrike a observado la utilización de Conti sobre técnicas de ofuscación basadas en compiladores, como ADVobfuscator , proporciona ofuscación de código cuando se crea el código fuente del ransomware.

Pueden continuar leyendo la investigación inicial por Crowstrike AQUI.

Saludos!!!

Fuentes

Wizard Spider Adversary Update
https://www.crowdstrike.com/blog/wizard-spider-adversary-update/

TrickBot Botnet Survives Takedown Attempt
https://www.securityweek.com/trickbot-botnet-survives-takedown-attempt

TAU Threat Discovery: Conti Ransomware
https://www.carbonblack.com/blog/tau-threat-discovery-conti-ransomware/

Informe de amenazas globales de CrowdStrike 2020 .https://www.crowdstrike.com/resources/reports/2020-crowdstrike-global-threat-report/

Microsoft Teams Phishing Attack Targets Office 365 Users https://www.crowdstrike.com/resources/reports/2020-crowdstrike-global-threat-report/

Anti-VM Technique with MSAcpi_ThermalZoneTemperature

Recientemente se ha dado a conocer un método de comprobación Anti-WM muy peculiar, aunque efectivo. La comprobación del parámetro de temperatura del Host. Para esto se utiliza WMI puntualmente la clase Win32_TemperatureProbe, el encabezado del objeto es el siguiente;

[Dynamic, Provider(«CIMWin32»), UUID(«{464FFABB-946F-11d2-AAE2-006008C78BC7}»), AMENDMENT]
class Win32_TemperatureProbe : CIM_TemperatureSensor
{

command: wmic /namespace:\\root\WMI path MSAcpi_ThermalZoneTemperature get CurrentTemperature

En los entornos virtuales este resultado va a diferir advirtiendo la imposibilidad de ejecutar la totalidad del comando.

Para conocer y leer todo el concepto puede acceder desde aquí la PoC y el código en PS lo podrán encontrar aquí

Estos comandos permiten ser ejecutado con técnicas combinadas de Ofuscación en Bas64 . (powershell ofuscados, inyectar las consultas WMI vía dll’s o LNK’s previa aperturas de conhost.exe o cmd.exe).

Existen excelente referencias de como utilizar estos modelos , en el blog de Mike F Robbins se pueden encontrar funciones simples en Base64. Adelantaremos en otras publicaciones ejemplos puntuales.

New Tool: amsiscan.py and how Windows 10 Plans to Stop Script-Based Attacks and How Well It Does It (AMSI)

El script amsiscan.py publicado por Didier Stevens utiliza la función “AmsiScanBuffer” de Microsoft en Windows 10, puntualmente para el scaneo de Malware en este tipo de entornos. El script lee las entradas estándar stdin y revuelve 5 posibles resultados.

AMSI_RESULT_CLEAN
AMSI_RESULT_NOT_DETECTED
AMSI_RESULT_BLOCKED_BY_ADMIN_START
AMSI_RESULT_BLOCKED_BY_ADMIN_END
AMSI_RESULT_DETECTED

This image has an empty alt attribute; its file name is 20190612-234302.png MD5: 47E50599E0CFAF1D27416E68394289A0
SHA256: 044E41D7F31D8333CB5295FD6E430933CA67F9AC37CD400D38189C96AE48544D

Tiene al menos 5 componentes de integración;

[+] Control de cuentas de usuario o UAC (elevación de la instalación de EXE, COM, MSI o ActiveX)

[+] PowerShell (scripts, uso interactivo y evaluación de código dinámico)

[+] Windows Script Host (wscript.exe y cscript.exe)

[+] JavaScript y VBScript

Para saber mas: Antimalware Scan Interface (AMSI)

En el 2016 ya se hablo de AMSI en Blackhat, por lo que compartimos un video sobre cuan efectivo es el trabajo de AMSI y la detección de amenazas.

Para ver el PDF de la Presentación blackhat USA 2016: “AMSI: cómo planea Windows 10 detener los ataques basados en scripts y qué tan bien lo hace”

Threat-actor-profile-TA542-banker-malware-distribution-service

Fuente: www.proofpoint.com

Investigadores de Proofpoint comienzan a dar detalles sobre un actor que llevan tiempo investigando denominado TA542, el dropper que se ocupó originalmente de la distribución fue Emotet, el alcance es amplio: América del Norte, América Central, América del Sur, Europa, Asia y Australia.

Originalmente las versiones iniciales de Emotet terminaban cometiendo fraude del tipo bancario, apuntando solo a bancos alemanes, austriacos y suizos, durante años, el malware fue catalogado de esa forma TYPE: BANKER. Según la investigación las últimas versiones de Emotet entregan cargas útiles de terceros: Qbot, The Trick, IcedID y Gootkit. Por último, Emotet carga sus módulos para spam, robo de credenciales, recolección de correos electrónicos y difusión en redes locales.

Lo que se sabe de TA542, es que distribuye campañas de correo electrónico de gran volumen a distintas industrias. TA542 es actualmente uno de los actores más prolíficos en todo el panorama de amenazas.

Lee más sobre la evolución de EMOTET y la combinación con TA542 y todos los detalles respecto a cómo se planifican y coordinan sus campañas. https://www.proofpoint.com/us/threat-insight/post/threat-actor-profile-ta542-banker-malware-distribution-service

Recent MuddyWater-associated BlackWater campaign shows signs of new anti-detection techniques

Fuente: http://blog.talosintelligence.com/

Investigadores de Cisco Talos dan detalles sobre una campaña reciente llamada “BlackWater”, la misma tiene relación con un actor persistente llamado MuddyWater. Las recientes muestras asociadas desde abril 2019 dan a entender que los atacantes han agregado tres acciones a las operaciones habituales de esta familia, esto permite evadir con facilidad los controles de seguridad, esto sugiere que las tácticas, técnicas y procedimientos de MuddyWater han evolucionado para evadir las detecciones en el host y han reemplazado los nombres de variables para evitar las firmas Yara.

Los datos proporcionados en el siguiente enlace, https://blog.talosintelligence.com/2019/05/recent-muddywater-associated-blackwater.html , podrían permitir a los equipos de caza de amenazas, a identificar las actividades para dichas campañas. El código original del malware no ha sido modificado, el éxito de este cambio permite tener acceso a una puerta trasera mediante la ejecución de instrucciones Powershell.

PS_Watter1

Se pueden apreciar cambios significativos en su accionar inicial, desde secuencias de comandos en Visual Basic (VBA) ofuscadas, con esto se logra persistencia en las llaves de registro. Lo siguiente es instruir vía powershell haciendo el llamado a un servidor controlado por el atacante para extraer el componente FruityC2

WMI_OBJECT

Conclusión

Además de los nuevos pasos contra la detección descritos en este informe, los actores de MuddyWater han realizado pequeñas modificaciones para evitar las firmas comunes basadas en el host y han reemplazado los nombres de variables para evitar las firmas Yara. Estos cambios fueron superficiales, ya que su base de código subyacente y la funcionalidad del implante se mantuvieron prácticamente sin cambios. Sin embargo, aunque estos cambios fueron mínimos, fueron lo suficientemente significativos como para evitar algunos mecanismos de detección. A pesar del informe del mes pasado sobre aspectos de la campaña MuddyWater, el grupo no se desanimó y continúa realizando operaciones. Basándonos en estas observaciones, así como en el historial de MuddyWater de apuntar a entidades con base en Turquía, evaluamos con una confianza moderada que esta campaña está asociada con el grupo de actores de amenazas MuddyWater.

APT37(REAPER) TTP’s

El siguiente articulo pretende evidenciar y detallar las TTP’s llevadas a cabo por el grupo de ciber-espionaje APT37 principal protagonista por utilizar 0-day de Adobe y Microsoft. (CVE-2018-0802. y CVE-2018-4878).

Detalles sobre las campañas dirigidas asociadas al grupo APT37 (Reaper) cuyo país de origen es Corea del Norte. Las actividades de este grupo han iniciado en noviembre en 2013, según los registros proporcionados por FireEye.

Detalles de Vulnerabilidades hasta ahora utilizadas:

CVE-2013-4979 EPS Viewer

CVE-2014-8439 Adobe AIR

CVE-2015-3105 Adobe Flash Player Drawing Fill Shader Memory Corruption

CVE-2015-2419 Internet Explorer JScript9.dll

CVE-2015-5119 Adobe Flash Player ByteArray

CVE-2015-5122 Adobe Flash opaqueBackground

CVE-2015-7645 Adobe Flash ‘IExternalizable.writeExternal’

CVE-2015-2545 Microsoft Office EPS File Exploit Works

CVE-2015-2387 Adobe Type Manager

CVE-2016-1019 Adobe Flash Payer «Internet Explorer/Edge and Flash Player»

CVE-2016-4117 Flash exploit inside a Microsoft Office document

CVE-2017-0199 Microsoft Office Word Malicious Hta Execution

CVE-2018-4878 Adobe Flash Player – No existen detalles técnicos hasta la fecha.

El solo hecho de explotar vulnerabilidades sobre productos de consumo masivo por nombrar algunas como ser word, excel, java o flash, sumado a la combinación de ingeniería social y ataques dirigidos, da como resultado un buen numero de infecciones positivas.

Por otro lado, es un buen ejercicio estudiar y dar seguimiento a las actividades de estos grupos, incluso es viable reconocer el tipo de familias de malware que utilizan y hacer un estudio de las amenazas que emplean, incluso es aceptable generar indicadores internos que nos permitan interpretar; patrones de trafico, tipo de comunicación con sus C&C, tipos de files creados, modificados y vectores de ataque empleados.

Actualmente tanto para generar infecciones o para exfiltrar datos existen un sin fin de técnicas, mas o menos complejas, desde: utilizar servicios alojados en la nube o hosting con poco «control» sobre sus plataformas, sitios de confianza con mucha indexación por parte de Google. Eso complicaría bastante el monitoreo, debajo algunos ejemplos….

Cuadro-CVE — Imagen de FireEye – Detalles CVE – Cronograma

Objetivos: Corea del Sur, Japón, Vietnam y Medio Oriente, apuntando a distintas industrias: Productos Químicos, Electrónica, Industria Aeroespacial, Salud, Automovilismo, Sector Financiero y Proveedores de Internet.

Tácticas de Infección: Ingeniería Social adaptadas específicamente a los objetivos deseados, han comprometido páginas web estratégicas, por otro lado la distribución del malware es vía Torrent o clientes P2P alternativos y poco habituales.

Vulnerabilidades Explotadas: Vulnerabilidades del tipo 0day (CVE-2018-0802/CVE-2018-4878) asociada con Adobe y Microsoft.

En los los años 2015/2016 entre mayo y julio es en donde mas se han explotado las fallas del tipo día 0. El exploit mas notable y reciente se dio a conocer por parte de FireEye el 2 de Febrero de 2018.

Infraestructura de comando & control: Servidores con buena reputación comprometidos, plataformas de mensajería y proveedores de servicios cloud (Amazon, GoogleDrive, GoDaddy). Una charla muy recomendada a leer «Dynamic Callbacks for Persistence» de xtr4nge. (al final el video)

Malware: Diversas muestras tanto para intrusión y exfiltración. Se han encontrado evidencias de malware destructivo inclusive. Dependiendo la estrategia de cada actor, o el ambiente en donde se ataque utilizaran las variantes que mas convenga.

Malware-Use — Detalles de malware y linea de tiempo

CORALDEKC, DOGCALL, GELCAPSULE, HAPPYWORK, KARAE, MILKDROP, POORAIM, RICECURRY, RUHAPPY, SHUTTERSPEED, SLOWDRIFT, SOUNDWAVE, ZUMKONG, WINERACK.

Dado que la documentación corresponde a Fireeye y aún no esta finalizada, continuaremos en otro post con mas detalles, haciendo hincapié en el malware utilizado.

Tendremos la oportunidad de conocer sus conclusiones y daremos mas detalles de las descripciones de las amenazas arriba mencionadas.

Fuentes:
https://www2.fireeye.com/rs/848-DID-242/images/rpt_APT37.pdf
https://www.fireeye.com/blog/threat-research/2018/02/apt37-overlooked-north-korean-actor.html

https://www.fireeye.com/blog/threat-research/2018/02/attacks-leveraging-adobe-zero-day.html

https://www.researchgate.net/publication/239829710_Searching_for_Malware_in_BitTorrent

https://arxiv.org/ftp/arxiv/papers/1409/1409.8490.pdf

AntiVirus, Heurística y algo más!

Desde un punto de vista meramente personal creo que continuaremos siempre existirá debate sobre los mismos pilares a la hora de hablar de malware o software malicioso; técnicas, metodologías y procedimientos, qué utiliza un software determinado para una plataforma o fin especifico.

Un malware ingresa en ese tipo de categorías de software malicioso, adapta su comportamiento dependiendo el sistema en donde deba correr, demuestra su accionar e intenciones para su beneficio y lograr los cometidos programados. Estos mecanismos van desde, patrones de ejecuciones en ciertos horarios o idioma, elimina a la «competencia», detecta software de análisis y no ejecuta sus actividades, también cifran unidades locales y/o USB para ejecutar su código, desde algún punto de la memoria, y vuelve al estado anterior borrando huellas. Y podríamos enumerar mas ejemplos, es lo «bonito» de este debate.

El punto a destacar es la evolución que se observa sobre estas practicas y el «aprendizaje» que tenemos, tanto en sistemas de protección como ser: Software Anti Virus, Firewall, AntiPhishing, WAF, SIEM, Filtrado de Contenido/Web, Sistema de Detecciones de Amenazas Avanzadas.

Incluso en las técnicas que el analista debe llevar a cabo para poder estudiar las nuevas muestras, debe lidiar con trafico encriptado, comunicaciones con distintos dominios legítimos aun no denunciados, ejecuciones de sentencias y script’s que llaman a las APIS originales o bien software nativo del sistema. (cmd, powershell, vbs, dll, etc).

En el sitio https://www.exploit-db.com/ y https://cve.mitre.org/ podrán encontrar fuentes originales para su mejor lectura y compresión. Actualmente EXPLOIT DB aloja 38.500 exploits y CVE ORG 95.200

En las escritas siguientes pretenderán dar a conocer una visión general sobre el desarrollo de aplicaciones antivirus, heurística y motores de detección que pretenden proteger nuestro sistema, y poner las cosas mas complejas al código malicioso -aunque algunas de las técnicas que utilizan entre casas antivirus sean idénticas entre sí, y acarre errores durante el proceso de erradicar amenazas, también comentaremos el tipo de estrategia que lleva a cabo el software malicioso para persistir y ocultarse dentro del sistema operacional infectado.

Hoy tomaremos como guía para este post, un análisis hecho por un estimado amigo, forma parte del staff de administradores del sitio www.indetectables.net , tiene gran conocimiento en el área. En conjunto acordamos utilizar su investigación para una de mis entradas, le he sumado contenido para tener contexto en base a sus detalles técnicos y comprendamos, espero sea del agrado de todos.

Interrogantes y especulaciones a tratar:

A) ¿ Los antivirus dan prestaciones de seguridad reales ante las amenazas existentes ? (persistencia en UEFI, BIOS, Certificados legítimos y firmados, ejecuciones anómalas relacionadas a procesos y funciones originales del sistema empleado.

B) ¿ Que mejoras efectivas han desarrollado las casas antivirus para prevenir y evitar ? (documentación de fuentes técnicas, reales y confiables sobre sus desarrollos, roadmap futuro disponible para la comunidad de clientes, white pappers sobre sus motores y bases de heurística, actividades de análisis, etc…).

C) ¿Que lleva a determinar si un programa es legítimo o contiene código malicioso ? (¿comparten sus bases de heurística entre sí?, ¿Las metodologías de revisión de código son las correctas? ¿A qué tipo de pruebas son sometidos los AV?, ¿Si reporta uno, reportamos todos?)

Métodos que emplean:

Firmas o “cadena de búsqueda” Como su nombre indica, consiste en identificar un offset que tenga registrado en una base de datos de detecciones. Las firmas funcionan de forma similar a las del PEiD admitiendo comodines y varios operadores.

Según la documentación del ClamAV, que al ser un antivirus de código fuente abierto es el único que da algo de información al respecto, las firmas también pueden ser hashes MD5 del ejecutable o de una sección específica dentro de él.

offset-firmas Las firmas comúnmente son cadenas dentro del archivo.

Decisión Heurística y evaluaciones retrospectivas:

Definición del acto de “encontrar o descubrir” en el caso aplicado a los antivirus, contienen una base de reglas y compara el contenido del binario para determinar si lo que está analizando es un potencial código malicioso. El motor consulta a esa base con los patrones de malware predefinidos y asigna un porcentaje cuando existe un parecido con otra muestra.

Las determinaciones las ejecuta en base a 3 lógicas: Firmas genéricas, Desensamblado y Desempaquetamiento. (wikipedia)

Para comprobar la efectividad de la heurística y su método pro-activo de detección, el motor de actualizaciones se detiene por un lapso de tiempo (de 1 a 3 meses), logran acumular distintas muestras sin registrar, nuevos elementos aparecerán y de esa forma al ser analizados se pueden comprobar si es efectivo el diagnostico. Al no existir registros previos de ese elemento solo cuenta con su heurística para determinar si es malicioso o no.

Debajo les compartiré artículos verdaderamente interesantes sobre heurística aplicada al software antivirus.

Un analista humano de malware también desarrolla las mismas actividades a la hora de examinar un elemento, ejecuta y toma acción en base a los comportamientos encontrados de las actividades sospechosas dentro de un archivo (en el caso que actué, o bien estimula su ejecución, llevándolo al entorno para el cual fue desarrollado). Este patrón es programable y se puede aplicar, del siguiente modo;

1) Firmas genéticas. Cuando se desarrolla malware hay casos en los que se reutiliza código de otras versiones para hacer software nuevo. Eso hace que existan semejanzas entre ambos haciendo posible crear una firma genérica que los detecte. Las detecciones por este método se suelen mostrar como “una variante de” en los resultados de los antivirus.

2) Análisis estático (o pasivo). Se analiza el archivo sin ejecutarlo buscando señales que indiquen si es malicioso. En este caso se usan varias estrategias que van desde desensamblar para ver que hace en su inicio, revisar la tabla de importaciones buscando el uso de apis sospechosas y analizar si el archivo está comprimido por algún packer para intentar descomprimirlo y analizarlo.

3) Análisis activo (pro activa). Este sería el método más moderno y el más interesante. En su arsenal usa hooks a las principales apis usadas para el malware, también técnicas de emulación y sandbox. Con esas herramientas logra saber si un archivo es malicioso mientras el mismo está siendo ejecutado.

runPE

Técnicas conocidas para evitar estos métodos

Existen técnicas para saltar estos métodos de detección y conseguir ser «indetectable», algunas son muy conocidas en el ambiente. A modo de introducción vamos a enumerar algunas de estas;

Anteriormente solo bastaba abrir un editor hexadecimal e ir modificando bytes del contenido, en el pasado todo ese archivo .exe era un md5 completo, y al cambiar esos valores también modificaban el dicho hash, bastante simple por aquel entonces. (Muy resumidamente).

Como veremos más adelante, el utilizar apis de windows también “complica la lectura de los motores AV, incluso también podríamos ser detectados fácilmente usándolas, depende que estrategia que se quiera seguir para el desarrollo. (Ejemplo: URLDownloadToFileA utilizada por Droppers).

La teoría indica que deberíamos de llamar a otras funciones para “ofuscar o camuflar” las llamadas que ejecuta la dll, binario, macro, etc, ese tipo de peticiones en lo posible debieran estar cifradas, utilizando algoritmos como ser: Caesar o XOR, si se lee la documentación acorde, explica que las funciones alternativas a utilizar serian: LoadLibrary() y GetProcAddress().

El proceso continúa su ejecución cargándose en memoria y las instrucciones que tiene originalmente la función URLDownloaderToFile, pero sin quedar escritas en “texto plano” dentro del binario. El equipo de FluProject explica la teoría/practica simple en documentación de su proyecto. (data 2013).

Una herramienta bastante útil para buscar estos patrones sobre la memoria ram, es volatility (memory forencis framework – http://www.volatilityfoundation.org/ ), por lo que es viable que en algún string del análisis se vea expresada la intención de conexión o bien algún proceso previo de índole sospechosa. Por ejemplo: Procesos con nombres parecidos a los del sistema operativo “rundll123.exe” arrancando desde el directorio del usuario. (%LocalAppData%\Temp %WinDir%\TEMP\)

Firmas: La forma más rápida es ir encontrando las firmas rompiendo el ejecutable y analizando si es detectado, para ello se usa herramientas como el AVFucker o el DSplit para ir arrinconando las firmas. Luego se termina usando las técnicas de RIT y XOR para que la firma quede rota sin que el ejecutable deje de ser funcional. Esta metodología de trabajo tiene casi una década.

offset-tool

Heurística y documentación:

Por la naturaleza de las estrategias usadas en la heurística, lo más práctico para saltarlas es tener en cuenta que busca cada una a la hora de la concepción del malware cuando se lo está programando.

La documentación de la CIA liberada por WikiLeaks habla al respecto. Entre los documentos filtrados hay uno muy interesante llamado “Development Tradecraft DOs and DON’Ts”, de los que voy a copiar algunos puntos interesantes:

DO NOT decrypt or de-obfuscate all string data or configuration data immediately upon execution.
DO strip all debug symbol information, manifests(MSVC artifact), build paths, developer usernames from the final build of a binary.
DO NOT explicitly import/call functions that is not consistent with a tool’s overt functionality (i.e. WriteProcessMemory, VirtualAlloc, CreateRemoteThread, etc – for binary that is supposed to be a notepad replacement).
DO make all reasonable efforts to minimize binary file size for all binaries that will be uploaded to a remote target (without the use of packers or compression). Ideal binary file sizes should be under 150KB for a fully featured tool.
DO NOT write plain-text collection data to disk.
DO NOT assume a «free» PSP product is the same as a «retail» copy. Test on all SKUs where possible.
DO test PSPs with live (or recently live) internet connection where possible.
NOTE: This can be a risk vs gain balance that requires careful consideration and should not be haphazardly done with in-development software. It is well known that PSP/AV products with a live internet connection can and do upload samples software based varying criteria.

También hay varias listas de comportamientos que son detectados:

Decryption loop detected
Reads the cryptographic machine GUID
Contacts random domain names
Reads the windows installation date
Drops executable files
Found potential IP address in binary memory
Modifies proxy settings
Installs hooks/patches the running process
Injects into explorer
Injects into remote process
Queries process information
Sets the process error mode to suppress error box
Unusual entropy
Possibly checks for the presence of antivirus engine
Monitors specific registry key for changes
Contains ability to elevate privileges
Modifies software policy settings
Reads the system/video BIOS version
Endpoint in PE header is within an uncommon section
Creates guarded memory regions
Spawns a lot of processes
Tries to sleep for a long time
Unusual sections
Contains ability to start/interact device drivers

Fiabilidad más allá de lo técnico

Una vez que se entiende cómo funcionan los medios usados para la detección y qué técnicas se emplean para saltarlos surge una pregunta interesante. ¿Es realmente fiable cómo hacen las firmas? ¿Constituye realmente un antivirus una solución completa de seguridad?

Creación de firmas:

Viendo la imagen anterior, es interesante observar como antivirus diferentes cometieron el mismo error. Esto nos hace suponer que podría existir el caso en que una nueva firma sea copiada entre motores lo que significaría que también pueden copiar los errores.

En febrero de 2010, para probar si esto realmente estaba sucediendo, Kaspersky creó veinte ficheros inocentes y marcaron diez de ellos como detecciones en sus motores. Luego de estos hubo 20 muestras a VirusTotal y esperaron.

En ese momento se activó el mecanismo que tiene VirusTotal donde las muestras detectadas fueron enviadas a todos los motores de la página para su análisis.

Al poco tiempo, varios motores detectaban también las muestras y confirmó dos cosas; que se sospechaban desde hace tiempo; que realmente existía la copia de firmas y que se estaba creando una tendencia de aumentar los falsos positivos por el mal uso de VirusTotal.

Los antivirus como vector de ataque:

No hay ninguna duda que realmente el peor escenario sería usar una solución de seguridad para lograr encontrar un vector de ataque. Para encontrar la forma más rápida basta con mirar los CVE al respecto.

searchresultav

Viendo los resultados se puede observar que fallas como denegación de servicio, elevación de privilegios y de ejecución de código remoto son posibles haciendo que la probabilidad de ataques, más allá de un malware, como vector en si es posible.

Conclusión

Los antivirus por si solos no deben ser tomados como una única medida de seguridad, inclusive muchas veces su elección pasa netamente por un tema monetario dejando lo técnico y la seguridad en un segundo plano.

Dada la constante búsqueda de nuevos métodos para evitarlos e inclusive para explotarlos es recomendado en ambientes corporativos complementar la seguridad con diferentes capas, ya sean, por ejemplo, filtrados de red y e-mails más agresivos y políticas elaboradas de Active Directory. Esto da lugar a que puedan existir inclusive ciertas medidas de contingencia en caso de que se logre una infección por parte de malware.

Hasta la próxima !