CyberDefenders Write-up: Injector

Disclaimer:

All the answers apart from the obvious will be redacted to encourage defenders to try the challenge themselves.

The Prompt:

A company’s web server has been breached through their website. Our team arrived just in time to take a forensic image of the running system and its memory for further analysis. As a security analyst, you are tasked with mounting the image to determine how the system was compromised and the actions/commands the attacker executed.

1. What is the computer’s name?

Challenge files include a memory dump and a ‘File’ with no extension.

If you can’t recognize a file type on Windows, check the file signature. Here it is obvious that it is some sort of image file, but let’s look at it in hex anyway. The starting bytes are 33 C0 8E D0 BC 00 7C 8E which are the magic numbers for a Master Boot Record (MBR).

If you place the MBR template, you can see the first sector here, 2048 which leads to an NTFS file system.

Mount the image, and extract all the hive files necessary. I parsed them with RegRipper.

We can find the computer name in the SYSTEM registry hive.

2. What is the Timezone of the compromised machine? Format: UTC+0. (no-space)

We can add/subtract the ActiveTimeBias field to the local timezone set on the machine. Cyber5W has an amazing course on timezone conversions relevant to DFIR.

3. What was the first vulnerability the attacker was able to exploit?

Right away in the tree we can see an installation for ‘xampp’, a web server.

Extract the apache logs to take a closer look.

We have a PID for the httpd service, let’s keep that in mind for now. We’ll use it at the time of memory analysis.

In access.log, many requests were made to the web app in place. The compromise starts with an XSS attack.

4. What is the OS build number?

Again, can be found from the SOFTWARE registry hive.

5. How many users are on the compromised machine?

User control related information is stored in the SAM hive.

Total of 4 accounts, 2 of which are user created (RID > 1000).

6. What is the webserver package installed on the machine?

XAMPP, as known from #3.

7. What is the name of the vulnerable web app installed on the webserver?

If you’ve built a PHP web application, you probably know the default directory to look for, it’s the htdocs folder.

Here we can find the root directory of our web app.

8. What is the user agent used in the HTTP requests sent by the SQL injection attack tool?

From the access.log file where we saw all those requests earlier, we can do some text manipulation. I’ve found regex in sublime text to be extremely useful.

\[.*\] \”.*?\” [0–9]{0,9} [0–9]{0,9} \”.*?\”

I used the above pattern to match and find the user agent column. Or if you have time at hand, you could manually skim through it. Not good for large logs.

On Linux systems, log processing is even faster with utilities such as awk, cut and grep.

9. The attacker read multiple files through LFI vulnerability. One of them is related to network configuration. What is the filename?

A Local File Inclusion is a vulnerability which allows access to the files on the system which is running the web server. The most common LFI challenges seen in CTFs are the ones with the infamous ZipSlip vulnerability exploited for directory traversal.

Again, access.log file reveals the attempts for the same.

Filtered results from access.log

10. The attacker tried to update some firewall rules using netsh command. Provide the value of the type parameter in the executed command?

Now it’s time for some memory analysis, boot up your VMs!

While using volatility, I cat out the results of the common plugins I know we’ll be needing.

[cmdscan results]

11. How many users were added by the attacker?

Earlier from hive analysis we saw there were 2 user created accounts. user1 and hacker. Presumably, hacker would be the one with more privileges. In above snapshot we can already see the creation of the user1 account. Let’s find the command to verify the creation of hacker.

The cmdscan results does not contain any such commands. Neither does the console plugin results.

Remember the PID from earlier, for the running httpd service?

Seems like it spawns another process with PID 2880. Let’s dump it and look into it.

vol.py -f memdump.mem --profile=VistaSP1x86 memdump -p 2880 -D .

The request here translates to:

ip=xxx.xxx.xx.xxx && net localgroup "Remote Desktop Users" hacker /add&submit=submit$hacker

12. When did the attacker create the first user?

User creation dates can be found in the SAM registry hive.

13. What is the NThash of the user’s password set by the attacker?

Run the volatility plugin hashdump.

14. What is The MITRE ID corresponding to the technique used to keep persistence?

We know the persistence technique has something to do with the 2 user accounts created. I checked the registry but did not find anything suspicious relating to persistence.

If you remember, CTF01 case had a similar persistence tactic where the adversary added their ssh keys after creating 2 new users one for the initial foothold and other for privilege escalation.

15. The attacker uploaded a simple command shell through file upload vulnerability. Provide the name of the URL parameter used to execute commands?

The uploads folder contains a phpshell.php which contains the identifier for command injection.

16. One of the uploaded files by the attacker has an md5. hat starts with “559411”. Provide the full hash.

Outside the uploads folder, in the root directory we have webshells.zip containing 2 .php files.

17. The attacker used Command Injection to add user “hacker” to the “Remote Desktop Users” Group. Provide the IP address that was part of the executed command?

Covered in #11.

18. The attacker dropped a shellcode through SQLi vulnerability. The shellcode was checking for a specific version of PHP. Provide the PHP version number?

I was stuck on this one for a while as I could not get hold of the file that was finally dropping the shellcode. After looking around for a while, I found this amazing write-up, kudos to Syed Hasan, who explains the absence of the final dropper file. Give it a read here.

There is one rather strange request in access.log file, it’s the largest of all.

Cleaning it up, we can see a tmpukudk.php which I did not find on the disk image.

Converted from hex and beautified, we can see the PHP version it checks for.