Let’s Defend: Event 62 – SOC128 – Malicious File Upload Attempt – Write-up (Advertisement)

Hello people, welcome back to another write-up on a new SOC case on the Let’s Defend platform! In today’s case we investigate a potentially malicous file upload attempt to our git server. If you missed my last Let’s Defend write-up, you can find it here.

The event

alert summary

On Feb. 22 a file named „phpshell.php“ (alarm bells ringing) was uploaded to our host „gitServer“. The action was allowed, but the alarm was triggered. Thankfully we got the file hash and the file itself to investigate.

Log management

log search results

I searched for the term „phpshell“ and immediately found two log entries. The time stamps are one and two minutes after the SOC rule triggered the alarm.

raw log of phpshell.php with parameter cmd=whoami
raw log of phpshell.php with parameter cmd=cat /etc/passwd

Well, these two log entries look like a php reverse shell, where the command is handed via the „cmd“-parameter in the GET-request. The attackers first checked on which user account the reverse shell was executed and in the second picture they tried to read the /etc/password-file containing user names, user ids and sometimes (in older linux versions) even the user password hashes. Both actions were allowed by the firewall.

The file

VirusTotal results for file hash search

Searching for the hash on virustotal.com shows a very clear picture of the maliciousness of that given file. 23 out of 58 vendors listed this file as „malicious“ and most of them specify the file as „backdoor“/“webshell“. To confirm these results, let’s take a look at the file itself:

content of phpshell.php

Okay, this is indeed a very simple webshell. The attackers did not even try to hide the bad intents of that file by obfuscating the content. That is fairly enough information for me, so we move on to the playbook now.

The playbook

playbook – define threat indicator

Well, for this decision I chose „Unknown or unexpected outgoing internet traffic“, but I think the option „other“ would have been fine, too. As the attackers tried to access the content of the /etc/passwd-File there might be some „unexpected“ outgoing traffic in my opinion.

playbook – check if malware is quarantined / cleaned

Since the file has not been removed / cleaned yet, we click „not quarantined“.

playbook – analyze malware

We previously found out, that this .php-file is malicious so we choose „malicious“ here. The C2 address controlling the webshell is

Please forgive me: I forgot to save the screenshot from the following playbook question: Was the C2 address accessed?

As we can see from the screenshot above, the IP was accessed before the incident. Unfortunately I misclicked to „not accessed“. :-/

playbook – analyst note

After filling in the artifacts we found, we need to leave a note for our co-workers or anybody else reviewing these cases to give an overview about our investigation.

Closing the alert

closing the alert – true positive

Now we can close the alert choosing true positive and filling out the neccessary information.

The result

We finished this case successfully. I missed out the five points for misclicking, but it is fine for me. I hope you guys enjoyed this investigation as much as I did. See you soon on another investigation here on my blog.

Nach oben scrollen