“ SOC168 — Whoami Command Detected in Request Body” investigation

5 min readNov 28, 2022

Hello, today I will write about investigation of “SOC168 — Whoami Command Detected in Request Body” alarm from letdefend.io.

The alert is appears in our investigation channel. After that, we proceed to build the case.

Let’s start the playbook.

The first step of the playbook is asking us to understand why the alert was triggered.

To understand the alert, we are supposed to examine the rule name. The rule name mentions of the URL Containing the Linux command LS which lists the contents of the directory the user is in.

The next step then asks us to determine the traffic path on which it is occurring.

The playbook’s next phase instructs us to Collect data.

· Ownership of the IP addresses and devices.

Checking the Endpoint management displays that the address 172.16.17.16 belongs to WebServer1004.

o 172.16.17.16 (WebServer1004)

o 61.177.172.87 (Internet Address)

· If the traffic is coming from outside (Internet);

Ownership of IP address (Static or Pool Address? Who owns it? Is it web hosting?)

· We can verify that it is a Static Address. We are able to determine that the device is being web hosted on the ChinaNet Jiangsu Province Network ISP using abuseIPDB, a centralized database for abusive IP addresses.

Reputation of IP Address (Search in VirusTotal, AbuseIPDB, Cisco Talos)

Malicious

Next, we are advised to look for probable web attack payloads in the HTTP traffic.

URL appears to be safe.

https://172.16.17.16/video/

The next step is to determine whether the traffic is malicious. We are able to mark the traffic as malicious simply based on the IP address and its reputation. We can perform log analysis in the log management to verify our suspicions.

We start our search for the 61.177.172.87 IP in the Log Management section, and we find several logs that show communication between the Web server and it.

We can see the Requested URL indicated in the alert, https://172.16.17.16/video, by looking at the first pair of Raw Logs. It is in the POST Parameters that the nefarious activity occurs. We can observe that the POST Parameters contain the commands ls and whoami. While the whoami tool in Linux displays the username of each file, ls displays a list of all files in the current working directory. The HTTP Response Size changing with each request is a sign that parameter modifications were successful.

Looking at the next pair of Raw Logs, we can see that the attacker executed two more Linux commands in the POST Parameters, uname and cat /etc/passwd. The Linux command uname displays basic information about the current system, while the cat /etc/passwd set of commands views the contents of the passwd file that has records of all registered users with access to the system.

The final associated log has the same Requested URL, but in this attack attempts to run the Linux command cat /etc/shadow. The attempted command would read the contents of the shadow file, a separate file responsible for storing the encryption of the user passwords on the system, accessible only by the root user.

This would be considered an Command Injection attack since we can see that the POST Parameters and are being successfully modified for each attempt.

Search for associated artifacts from the alert in Mailbox, such as the source IP, destination IP, or server name, but nothing appears to be connected, therefore this was not planned.

We are required to determine the direction of traffic while look back to the alert.

The alert’s 61.177.172.87 source address is external to the company network. WebServer1005, 172.16.17.16 , is the internal destination address. This denotes a direction flow on the Internet → Company Network.

We are next instructed to determine whether or not the attack was successful.

we search the WebServer1004 in the Endpoint Management and look at the CMD History. We find the same commands passed in the POST Parameters in the CMD History. In the Process History, we can see the commands as well