• Malware en Windows

  • Soluciona aquí tus preguntas frecuentes. Temas recomendados antes de preguntar.
Soluciona aquí tus preguntas frecuentes. Temas recomendados antes de preguntar.
 #225244  por p0is0n-123
 02 Sep 2010, 13:39
Malware actual vs Windows Vista/Seven


En estas lecturas se hace un experimento para ver si el viejo malware es compatible con Windows Vista, se explica el como y el porque este sistema se la lleva bien o no con este tipo de programas
[+] Windows vista y Malware I Introduccion a UAC/rootkits y credenciales
[+] Windows vista y Malware II Prueba fracasada: hackdefender rootkit
[+] Suplantación de nombres y malware en vista
[+] Windows vista y Malware III UAC antirootkit
[+] Windows vista y Malware IV Windows defender VS Ducktoy: Defensa inteligente
[+] Windows vista y Malware V Ultimo intento, Turkojan 4.0 ahogandose
Como resultado tenemos una baja compatibilidad con el malware antiguo por razones de programación. Los rootkits ahora tienen que enfrentar un SSDT organizado de forma diferente, nuevos controles sobre procesos, rutas, UAC y otras piedras en el camino.

RATs Compatibles: Bifrost en sus ultimas versiones, Coolvibes 0.5/0.6, Turkojan, PainRAT, Spy-Net.
Problemas con funcionalidad de RATs compatibles: La opción de administrar el registro y los servicios no suelen trabajar ya que si el usuario no es administrador no se puede tener acceso a dichas cosas. Al igual pasa con la lectura/escritura de algunos directorios por las razones antes mencionadas.

Problemas con Autoinicios
Windows Vista posee un estricto control sobre el registro de Windows, por lo que cualquier intento de crear un autoinicio en LOCAL_MACHINE seran fallidos ya que se necesitan privilegios de administrador para lo mismo. Los autoinicios recomendados para este sistema son los añadidos en CURRENT_USER o los llamados 'ActiveX' (Active Setup) que no comprometen el sistema de seguridad en el registro y pueden pasar desapercibidos más facilmente si se escriben en HKCU (CURRENT_USER).

1) Si se va a añadir un cambio al registro usando un .REG y añadiendolo con REGEDIT.EXE, se mostrara una advertencia pues REGEDIT.EXE esta firmado en su manifest para solicitar permisos de administrador antes de realizar cualquier accion.
2) Si se añade el autoinicio por MS-DOS valiendose del archivo REG.EXE (REG ADD ...) no se solicitaran permisos al ejecutarlo, pero si se esta añadiendo en una clave en donde el usuario actual no tenga permisos (Como en LOCAL MACHINE) no proseguira hasta tener permisos.
3) Si se programara este añadido en el registro sin depender de REGEDIT.EXE o REG.EXE para añadir los valores podriamos esquivar en parte el UAC y tomar los permisos del usuario actual (AsInvoker), el problema lo tendriamos con la heuristica AV y Windows Defender que detectarian dichas acciones al momento de ejecutarsen. (Suponiendo un sistema seguro).

Suplantación de aplicaciónes y controles .DLL
Es posible suplantar un ejecutable, pero si esta ubicado en system32 necesitaremos tantos permisos para poder reemplazar el archivo del sistema por nuestro archivo que seria igual el lio. En este link por ejemplo hacen una demostración con un ejecutable llamado magnify.exe, el cual reemplazan por un cmd.exe para hacer un backdoor en el logon.
Hay otra forma más sutil, no con aplicaciones sino suplantando controladores (DLL)
Un ejemplo con los controladores: Estos .DLLs pueden pasar a ejecutarsen con los mismos niveles de permisos que tenga la aplicación que las invoque.
El problema es que en VISTA se clasifican las aplicaciones, rutas y o acciones en nivel bajo, medio o alto (admin), y solo podemos tener control sobre las .DLLs de nivel bajo. Por lo general casi todos los .DLLs estan en /system32 (nivel alto), por lo que podemos tomar las DLLs de nivel bajo como las ActiveX que llama Internet Explorer (/users/appdata/..) Suplantando un ActiveX estariamos limitados a las siguientes cosas:

Rutas: Las rutas de 'alta' son los directorios del sistema /windows, /system32. Cualquier cosa que quisieramos tomar de alli necesitaria permisos. Podemos entonces usar los directorios de nivel 'bajo' como /program files/ y otras rutas alternas que no los piden.
En cuanto al registro, los autoinicios comunes se clasifican en 'alta' (necesitan permisos), por lo que suplantar una .dll o archivo seria más efectivo.
Ejecución: Si la ejecución no tiene acciones de nivel alto, tiene su correspondiende manifest para ejecutar como 'AsInvoker' y esta en un directorio de nivel bajo no habria problema. De igual forma podemos ejecutar usando "cmd /c aplicacion.exe" para tomar los permisos de cmd con algunas aplicaciones.

Saltandose el UAC
El UAC pregunta antes de ejecutar cualquier aplicación que no este firmada digitalmente.
Una firma digital es un manifiest dentro de los recursos de una aplicación:

Este manifest bien lo puedes editar o añadir a un ejecutable si tienes reshack/restuner. por ej:
Puedes añadir un certificado a la aplicacion para bypassear ese control, bastaria añadirle al programa que quieres que no sea detenido por el UAC ese certificado con restuner o reshack para pasarse ese control. este de ejemplo te serviria:

[?xml version="1.0" encoding="UTF-8" standalone="yes"?]
[assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"]
[assemblyIdentity version="1.0.0.0" processorArchitecture="X86" name="Test1" type="win32"/]
[trustInfo xmlns="urn:schemas-microsoft-com:asm.v3"]
[security]
[requestedPrivileges]
[requestedExecutionLevel level="asInvoker"/]
[/requestedPrivileges]
[/security]
[/trustInfo]
[/assembly]

La magia del manifest se hace más precisamente en la linea [requestedExecutionLevel level="asInvoker"/], en donde se le dice a VISTA que la aplicación se ejecutara con los privilegios del usuario actual (saltandose asi la ventanita de confirmacion de ¿desea ejecutar...?). Puedes comprobarlo modificando alguna aplicacion y añadiendole el certificado, cambiara el icono que lleva, y sus permisos de ejecucion.


Casi todas las aplicaciones integradas en Windows traen este tipo de Manifest en su interior, para ver manifest de otras aplicaciones con el fin de suplantarlas puedes hacerlo desde ms-dos, por ej con calc.exe:

Si quisieras saber si una aplicacion en particular tiene restricciones en el UAC, lo podrias hacer por remote shell. De esta forma sabiendo cual necesita de un administrador para ejecutarse, la podrias editar y reemplazarla para poderla lanzar sin la autorizacion del usuario.

En el ejemplo, notepad no necesita permisos, regedit los necesita, pero si se le otorgan puede tener más privilegios en ejecucion, y por ultimo FirewallSettings.exe es un ejemplo de una aplicacion que se podria editar para poder ser ejecutada sin permisos de administrador.

AÑADIENDO MANIFEST A NUESTRAS APLICACIONES
El Restuner tiene la ventaja pues trae un asistente para añadir Manifest a las aplicaciones, mientras que con reshacker tienes que guardar el Recurso del Manifest y luego agregarlo


DESHABILITANDO CONTROLES UAC
Puedes ejecutar un .reg para activar o desactivar el UAC, El problema es que al intentar escribir estos valores en el registro se activaria como minimo una ventanita del UAC pidiendo la confirmación para ejecutar el script (ya si la acepta, adios UAC).
(pues se llama a regedit.exe o a reg.exe para hacer los cambios, y estos ejecutables en su manifest esta configurado para pedir permiso antes de ejecutarse. Ademas de eso todos los cambios en LOCAL_MACHINE en el registro necesitan permisos).
Igual, si tienes forma de hacer los cambios en el registro estos son los .reg:

[+] Creando un archivo .REG y ejecutandolo por ejemplo:
(Saltaria una advertencia al ejecutar REGEDIT.EXE para añadirlo)
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
"ConsentPromptBehaviorAdmin"=dword:00000000
"ConsentPromptBehaviorUser"=dword:00000000

[+] En linea de comandos, pero los cambios solo surten efecto despues de reiniciar.
cmd.exe /k %windir%\System32\reg.exe ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v EnableLUA /t REG_DWORD /d 1 /f

[+] Creando un archivo .REG y ejecutandolo por ejemplo:
(Saltaria una advertencia al ejecutar REGEDIT.EXE para añadirlo)
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
"ConsentPromptBehaviorAdmin"=dword:00000002
"ConsentPromptBehaviorUser"=dword:00000001

[+] En linea de comandos, pero los cambios solo surten efecto despues de reiniciar.
cmd.exe /k %windir%\System32\reg.exe ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v EnableLUA /t REG_DWORD /d 0 /f
Como pueden notar, al agregar estas entradas en HKLM necesitaremos permiso del usuario (que confirme la acción de añadir esa configuración al registro si asi se lo permite el sistema).