LetsDefend- SOC142 — Multiple HTTP 500 Response
In this alert we have a problem related to the HTTP response status.
HTTP response status codes indicate whether a specific HTTP request has been successfully completed. Responses are grouped in five classes:
- Informational responses (
100–199) - Successful responses (
200–299) - Redirection messages (
300–399) - Client error responses (
400–499) - Server error responses (
500–599)
We have the following information to start our analysis:
First step is to collect some useful info.
Source Address :
101.32.223.119
Destination Address :
172.16.20.6
User Agent :
Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.88 Safari/537.36
If we check the reputation of the source IP address it is flagged as malicious
If we analyze the logs we can find an interesting timeline of what happened:
At 1 p.m., the attacker tries a SQL injection that not succeeds as evident from the HTTP response of 500.
Interestingly, the query that the attacker is trying to inject is intentionally wrong.
The attacker adds the boolean expression =AND true to the userNumber parameter. But the AND keyword requires a left-hand operand, so the result will be a syntax error.
Why then make a “wrong” query?
It could be that the attacker wants to try to use this injection to force the web application to generate an error message, which could potentially reveal information about the structure of the underlying query or database.
Next, the attacker launches a SQL injection which is successful as seen from the HTTP status:
Let’s analyze this query:
The attacker adds a union select statement which allows the attacker to add new data to the result set. In this case, the attacker selects the value 1 for the first column and an empty string “ for the second column.
1 and “ are used to match the number and type of columns in the original SQL query that is being injected.
Then, the attack uses the into outfile clause to write the result of the modified query to a file named cmd.php in the web server's var/www/html directory.
Finally, the attack adds a comment symbol # to the end of the query to bypass any remaining parts of the original query.
The result is that the attacker creates a new file on the server, which can be accessed via a URL and contains the output of the SQL query. In fact, the attacker is going to use the cmd.php file to execute arbitrary commands on the server via a reverse shell connection.
Then we can see from the logs that are executed these other two commands:
The fist one whoami retrieves the username of the currently logged-in user on the server.
The second one id retrieves the user and group IDs of the currently logged-in user on the server.
Eventually the attacker via reverse shell gets remote control on the compromised server:
The command in this screenshot indicates the use of nc, the Netcat utility, to create a reverse shell to the attacker’s IP address and port number. In this case, the -e option is used to run the /bin/sh command on the server, which opens a command prompt on the remote device.
Indeed, if we go to analyze the command history of the compromised device, we can see as analyzed before that precisely those commands were executed on the machine and that a connection was established with the IP flagged as malicious.
If we look at the processes analyzed on the machine we notice that two particular actions were performed:
The executed command indicates the antivirus program ClamAV removal, which looks like a suspicious action.
Nesta command is run to check the status of the Imunify360 WebShield service, which is a security suite with tools and services to protect your Linux-powered web server against malicious attacks.
Conclusion: This alert is a true positive.
The attacker has successfully executed an SQL injection by taking advantage of inadequate input sanitization, enabling the attacker to retrieve database information.
