LetsDefend is a hands on Blue team training platform where I have completed theory labs as well as practical labs where I respond to tickets based on SOC daily routines. Below are some of the tickets I picked up and worked through.
LetsDefend is a hands on Blue team training platform where I have completed theory labs as well as practical labs where I respond to tickets based on SOC daily routines. Below are some of the tickets I picked up and worked through.
Investigation overview
Investigated a medium alert involving a suspicious PowerShell script being run on the host machine "Tony". The alert was provided with reference to a file "payload_1.ps1" which was ran from the user's Download directory. This script attempted to communicate with a known malicious command and control (C2) endpoint.
My investigation steps:
1) Isolation
Knowing the file was already downloaded, I wanted to prevent any potential lateral movement or execution of the program. I immediately isolated "Tony" using the endpoint security system. This allowed me to start my analysis without risking going further.
2) Web Browser
As the file was downloaded from the web, I found the exact timestamp that the alert noted and reviewed the URL. This matched what was ran on our host machine.
3) Malware review
I took the URL and checked it against VirusTotal, where numerous vendors deemed it as malicious with detections around possible C2 activities and potential PowerShell backdoor.
This confirmed to me that this was malicious Malware.
4) C2 verification
The playbook wanted me ot confirm whether the C2 was requested or not. By reviewing the network logs, I could see that there was outbound traffic from the host "Tony" to the malicious C2 IP. This traffic was allowed and was successful, showing that the script has reached the C2 before being contained.
Conclusion
This was a True Positive alert and an example of where Malware breached a system. The Malware was downloaded and executed, and not quarantined automatically. The containment only happened once I started investigating and isolating the machine.
My next steps
The next steps I would recommend is to keep the host isolated and escalate to Tier 2 to for further investigation, as the script was executed.
Images to support my investigations are below this dropdown.
During this ticket, I was tasked with investigating a high-severity alert related to detected SQL Injection activity against a webserver "WebServer1000". The initial alert showed a suspicious HTTP request coming from an external IP (118.194.247.28) that included SQL Injection, XSS payloads and an attempt to execute xp_cmdshell to access the /etc/passwd file.
My steps
1) Initial review
Firstly, I began by reviewing the alert details and taking note of the source and destination addresses. The Source IP was related to an external host and should not have been able to gain access. I took this IP to Virustotal, wherein the majority of vendors deemed it as malicious, which helped me identify that this was not part of planned testing. To double check this, I searched internal emails for any keywords such as "test" ", pentest", "SQL" and could not find anything internal.
2) Request Analysis
I then took a deeper look into the HTTP request within the logs, and the payload contained a collection of exploitation attempts being SQL-injected using "UNION ALL SELECT", XSS and a remote command execution attempt of "xp_cmdshell". I did some research into this as I was unsure of this combination, and I found that it was more than likely related to exploitation tools like SQLMap.
3) Success Determination
I then wanted to check if the payload landed. I figured the best way would be to see what went out. The response request was only 865 bytes, which I felt was too little data to be a database, especially considering the attacker attempted to enumerate tables. I then checked on the outbound connections and checked other devices to check for lateral movement, but none were found.
I deemed the attack as unsuccessful, but a True Positive
I based my initial decision on the size of the data leaving and made the decision not to push to level 2. (I was wrong)
4) Feedback
However, after completing the lab and getting feedback, I understood that the correct procedure would have been to escalate due to the presence of attempted RCE (xp_cmdshell) and the fact that the payload reached and executed against the server regardless of the amount of output.
This means the attack must be treated as a successful attack and should require further analysis.
5) Closing notes
Whilst I managed to identify this attack as a true positive, and even though no evidence of exfiltrated data was observed during my review, it still should be treated as a high-risk scenario that requires escalation.
6) New next steps
Raise to T2 for deeper analysis and recommend reviewing current security on the accesses to databases, and monitor these IPs and consider blocking them.