Welcome back to the Linux Command Line Hackery series, this is Part-V of the series. Today we are going to learn how to monitor and control processes on our Linux box, so wrap your sleeves up and let's get started. Command: ps Syntax: ps [options] Description: ps displays information about the currently running processes. Some of the common flags of ps are described briefly below Flags: -Aor -e -> select all processes -a -> select all processes except both session leaders and processes not associated with a terminal. T -> select all processes associated with current terminal -u<username or id> -> select all processes of a given user or userlist Open up a terminal and type ps: ps what you'll see is a list of processes currently running in your terminal. One important thing to notice in the output is what's called as PID which stands for process ID. It is the number that uniquely identifies a process. Just keep that PID concept in mind we'll use it soon. OK I know that's not really what you want to see rather you want to see all the processes that are currently running on your box. Don't worry we have flags to rescue, in order to see all the processes you can use the -e flag like this: ps -e Boom! you get a long list of processes currently running on your machine (don't stare at me like that, you asked and I gave you that). If you want to see processes of a particular user you can type the following command in your terminal: ps -u bob here "bob" is a username. This command will list all processes of the user with effective user name of bob. You can do a full-format listing of the processes using the -f flag like this: ps -fubob But the output of the ps command is a snapshot not really a live preview of what is going on in your box. I know your next question is going to be something like this, Isn't there a command in Linux that gives me a live updating information of the processes? Yes, there is a command called top that we'll learn about next. Command: top Syntax: top [options] Description: top gives a dynamic real-time view of a running system. That is, it gives the up-to-date information about all the processes running on your Linux box (sounds fun!). Besides giving information about current processes and threads top also provides a brief system summary. To start top just type this command: top and you'll get a nice and cute looking ugly display :). Well what the heck is going on here you might ask, right? What you get is information about what is going on with your computer. To see what more can you do with top just type <h> within the program window and you'll be given list of options that you can play with. OK looking at what processes are going on in your box is cool but what if you want to terminate (or close) a process, is there a command line utility for that? Yes, there is and that's what we are going to look at next. Command: kill Syntax: kill [options] <pid> [...] Description: kill is used to send a signal to process which by default is a TERM signal meaning kill by default sends a signal of termination to process (Cruel guy). To list the available signals we can use the -l or -L flag of the kill command. To simply terminate a process we provide kill command a PID (process ID) and it will send the TERM signal to the process. So to kill a process first we'll list the running processes and then we'll keep the PID of the process in mind that we want to terminate. After that we'll issue the kill command with the PID that we just found. ps -ax kill 1153 the above command will send a TERM signal to the process whose PID is 1153, as simple as that. We can also use our already learned skills to refine the output of ps command. Say we have a xterm terminal running on our box and we want to terminate it. By using ps command all alone we'll get a long listing of all processes running on our box. But we can limit the output of ps command to just those processes that we're interested in by piping ps command with the grep command like this: ps -ax| grep xterm wow! that's amazing, we're able to pull out only those results from the ps command that contained xterm in them. Isn't that a cool trick? But what is that vertical bar ( | ) doing in the middle, you may be thinking, right? Remember we learned about the input and output re-directors previously, the vertical bar (pipe in geeky terms) is another re-director whose task is to redirect the output of one command as input to another command. Here the pipe redirects the output of ps -ax command as input to grep command and of-course from the previous article you know that grep is used to search for a PATTERN in the given input. That means the above command searches for the xterm word in the output of ps -ax command and then displays just those lines of ps -ax command which contain xterm. Now get that PID and kill that process. That's it for today, try these commands up on your own box and remember practice is gonna make you master the Linux command line. :)
Estas cinco semanas de confinamiento ha dado lugar a que podamos revisar más información y que intentamos evadirnos conociendo nuevos conceptos y nuevas herramientas. Hace poco estuve revisando el blog de DarkByte y encontré un artículo interesante sobre un proyecto llevado a cabo por @3v4Si0N en el que se proporciona una shell inversa en Powershell. Hasta aquí puede parecer un shell inversa más, pero lo que llamó mi atención es que ya preveía que AMSI daría guerra.
Figura 1: HTTPRevShell: Shell reversa en PowerShell & Bypass AMSI (All-in-One)
Ya hemos comentado por aquí que a veces nos dicen que iBombshell no funciona, que AMSI te la detecta y nosotros siempre respondemos que si una medida defensiva como AMSI y Windows Defender detectan la consola de iBombshell es algo bueno y positivo, pero no es lo que tú quieres cuando estas haciendo un Hacking a un Windows.
La estrategia seguida por @3v4Si0N es clara: primero lanzo una función que me permita hacer el bypass de AMSI y luego ya ejecuto el código de la shell inversa. Está bien. Si nos encontramos que el día de mañana al descargar la función que nos propone @3v4Si0N nos la detecta AMSI, habría que ir parte por parte:
1. Cogemos la parte de código del bypass de AMSI e intentamos cargarlo en memoria.
2. Si nos lo detecta. Tendremos que ir, casi o sin casi, instrucción por instrucción para ver dónde está rompiendo, es decir, dónde se está detectando. Si tenemos esto claro, lograremos llegar a la instrucción que no le gusta a AMSI. A partir de aquí la ofuscación, la modificación o el cifrado pueden ser aliados. Esto ya lo hemos visto en algún post dónde hablamos de los AMSI "Classics".
3. Una vez que tenemos localizado esto y conseguimos cargar la función en memoria, se ejecuta. AMSI deshabilitado. La técnica más buscada y utilizada es ScanBuffer igual a 0. De esta forma AMSI informará de que no ha leído nada, pero realmente se está ejecutando lo que queramos.
Y ahora vamos a ver paso a paso cómo probar estos dos escenarios de los que hemos hablando antes. Primero con conexiones HTTP y luego añadiendo una capa de cifrado SSL a las comunicaciones para tener una conexión HTTPs.
Manos a la obra: probando HTTP revshell
Se puede descargar desde su Github, recomendable hacer un clone desde su rama Dev:
git clone –b dev [git url]
De esta forma ver sus últimos avances disponibles antes de pasar a master. Como decía anteriormente, lo que me llamó la atención de la herramienta era su integración directa con un bypass de AMSI. En el script podemos encontrar una función llamada Invoke-PatchMe, la cual implementa ese bypass.
Figura 5: Función Invoke-Patchme
En la parte del command and control no hay mucho que decir, tenemos dos opciones o ir por HTTP o gestionar la shell a través de HTTPs. La segunda opción es una opción más interesante, ya que permitirá evadir la detección por análisis de lo que estamos enviando, pero se podrá detectar el uso del SSL en una comunicación, digamos no autorizada. Hay que barajar el entorno y los PROs y CONs en cada escenario de red y veremos cómo hacerlo usando este servidor escrito en Pyhton.
La ejecución del C2 es sencilla, simplemente utilizamos o lanzamos el fichero server.py apuntando a una dirección IP y un puerto local. Tanto dirección IP como puerto son locales, y como podéis ver, el servidor está escrito en nuestro querido Python.
Figura 7: HTTP/S Revshell escrito en Python desde nuestro Kali Linux
Para el ejemplo, levantamos una Powershell en un Windows 10 y probamos a descargar el script, tal y como comenté anteriormente, si esto lo detecta AMSI habría que dividir el contenido del script e ir cargándolo poco y, quizá, necesitemos del uso de la ofuscación.
Es decir, para aplicar esa aproximación paso a paso, sería como utilizar la estrategia Divide & Conquer (Divide y Vencerás) que tanto se usa en algorítmica tradicional, pero aplicado al mundo del pentesting en una disciplina de un ciberseguridad.
Figura 9: Ejecución Invoke-WebRev
En este caso, no hay detección por parte de AMSI, por lo que podemos invocar directamente la shell reversa. Una vez que se ejecuta la función Invoke-WebRev pasan dos cosas:
1. La primera es que se ha ejecutado el Invoke-PatchMe y AMSI se ha parcheado, logrando el bypass de éste.
2. Ahora se invoca a la función Invoke-WebRev y se conecta contra el C2 escrito en Python.
De la primera situación podemos sacar lo siguiente. Para comprobar que AMSI está deshabilitado, si ejecutamos el comando "amsiutils" veremos que no lo reconoce. Si AMSI estuviera habilitado, el mensaje sería distinto, indicando que ha sido bloqueado por ser software malicioso. Este comando es un comando de prueba para ver si AMSI está habilitado o no.
Figura 10: Comprobando si AMSI está deshabilitado o no
Cuando la función Invoke-WebRev es ejecutada, se logra la conexión con el C2. Debemos aceptarla dando un ENTER. El juego de peticiones es curioso, ya que desde la shell se envía un POST, la primera vez, dejando abierta la conexión. Cuando queramos interactuar con la shell, contestaremos con un OK y algo más de info en forma de comando.
Figura 11: Ejecución de comando dir sobre sesión PowerShell remota
Entonces, el resultado de la ejecución de la shell se devuelve de nuevo en un POST que deja abierta la conexión para el siguiente comando. Es como si hubiera un desfase. En la siguiente imagen se puede ver la salida de la ejecución del comando "dir" sobre la Powershell remota con la que se interactúa gracias al uso de la shell implementada en Powershell.
Figura 12: Tráfico generado por HTTP ( POST y OKs)
Aquí se puede ver el tráfico por HTTP y el juego de POST y respuestas de OK. Salvo que el OK lo manda el C2 cuando quiere algo, y el POST es generado como una nueva petición que sale desde la Powershell hasta el C2 cuando se quiere devolver resultados. Es cómo utilizar HTTP de forma asíncrona.
Figura 13: Ejecución de servidor con cifrado SSL
Para ver cómo funciona la opción con SSL ejecutamos lo siguiente:
Python server.py –ssl [ip] [puerto]
La única diferencia con el caso anterior es que hacemos uso del parámetro SSL. Tal y como se puede ver en las imágenes anterior y siguiente.
Figura 14: Ejecución con cifrado ssl
Si analizamos con Wireshark la comunicación, veremos que ya no hay tráfico por HTTP y que en cuanto enviamos comandos y obtenemos resultados, tenemos el tráfico cifrado. Ahí se puede ver el inicio de una conexión con el Client HELLO.
Figura 15: Ahora el tráfico va completamente cifrado
Sin duda es una herramienta interesante que puede ser utilizada dentro de herramientas como iBombShell o Empire. Incluso, se puede hacer uso a través de Metasploit gracias al uso de la extensión de Powershell que existe en Meterpreter. Lo ideal es almacenarla dentro de alguna DLL y que en el proceso de explotación de una vulnerabilidad se inyecte la DLL y se ejecute esta interesante shell.
Why vlang? V is a featured, productive, safe and confortable language highly compatible with c, that generates neat binaries with c-speed, the decompilation also seems quite clear as c code. https://vlang.io/
After open the binary with radare in debug mode "-d" we proceed to do the binary recursive analysis with "aaaa" the more a's the more deep analys.
The function names are modified when the binary is crafted, if we have a function named hello in a module named main we will have the symbol main__hello, but we can locate them quicly thanks to radare's grep done with "~" token in this case applied to the "afl" command which lists all the symbols.
Being in debug mode we can use "d*" commands, for example "db" for breakpointing the function and then "dc" to start or continue execution.
Let's dissasemble the function with "pD" command, it also displays the function variables and arguments as well, note also the xref "call xref from main"
Let's take a look to the function arguments, radare detect's this three 64bits registers used on the function.
Actually the function parameter is rsi that contains a testing html to test the href extraction algorithm.
The string structure is quite simple and it's plenty of implemented methods.
With F8 we can step over the code as we were in ollydbg on linux.
Note the rip marker sliding into the code.
We can recognize the aray creations, and the s.index_after() function used to find substrings since a specific position.
If we take a look de dissasembly we sill see quite a few calls to tos3() functions. Those functions are involved in string initialization, and implements safety checks.
tos(string, len)
tos2(byteptr)
tos3(charptr)
In this case I have a crash in my V code and I want to know what is crashing, just continue the execution with "dc" and see what poits the rip register.
In visual mode "V" we can see previous instructions to figure out the arguments and state.
We've located the crash on the substring operation which is something like "s2 := s1[a..b]" probably one of the arguments of the substring is out of bounds but luckily the V language has safety checks and is a controlled termination:
Switching the basic block view "space" we can see the execution flow, in this case we know the loops and branches because we have the code but this view also we can see the tos3 parameter "href=" which is useful to locate the position on the code.
When it reach the substr, we can see the parameters with "tab" command.
Looking the implementation the radare parameter calculation is quite exact.
Let's check the param values:
so the indexes are from 0x0e to 0x24 which are inside the buffer, lets continue to next iteration, if we set a breakpoint and check every iteration, on latest iteration before the crash we have the values 0x2c to 0x70 with overflows the buffer and produces a controlled termination of the v compiled process.
Para consultas puedes usar el 
