How do Security Analyst investigate alerts? Well, it can vary. However, I will be going through an investigation methodology which utilizes the creation of a hypothesis. To demonstrate how this works, I will use a Let's Defend alert and attempt to solve it without consulting their playbook.
The alert we will be investigating is in the below screenshot.
The details of the alert are as follows:
The first thing we will do is create hypothesis regarding the alert. In other words, make an educated assumption based on the limited information provided in the alert. Then we will work to confirm whether it is true or false.
For example, in regard to this alert, our hypothesis could be as follows:
“The suspected phishing email Lars received on Jun 13,2021 was malicious and has compromised his endpoint.”
The assumption could have also been the converse of the statement, but what matters is that we work through evidence to prove our hypothesis.
We will now examine evidence to prove this hypothesis.
Let’s begin by extracting key points from the initial alert to see where we will begin our investigation.
Event Time: Jun, 13, 2021, 02:13 PM
Rule: SOC146 - Phishing Mail Detected - Excel 4.0 Macros
SMTP Address: 24.213.228.54
Source Address: trenton@tritowncomputers.com
Destination Address: lars@letsdefend.io
E-mail Subject: RE: Meeting Notes
Device Action: Allowed
All of the above are important and will be helpful. However, I would say that two of the most crucial to obtain would be the timestamp and action since it will help us build a timeline of what occurred. (Side note: in real life, account for time zone differences that may exist across your tools and know the hour difference between UTC and your time zone).
We have these tools available:
We will first retrieve this email for phishing analysis, so we can prove that the email is malicious. To do that we go to mailbox (probably same as an email gateway anywhere else).
We can search based on the subject and verify sender.
The body of the email is below.
Quickly grab the attachment and dump it into a sandbox tool. I used any.run.
Based on initial looks at the file in the sandbox (AnyRUN) we know that this is suspect.
The results were as follows in Any.Run:
A quick rep-check on the .dll files based on the SHA256 shows that it was malicious.
Based on the results of the sandbox, we confirmed the first part of the hypothesis that the email is malicious because the file attached in it was malicious. According to MITRE ATT&CK,
“Adversaries may abuse Regsvr32.exe to proxy execution of malicious code. Regsvr32.exe is a command-line program used to register and unregister object linking and embedding controls, including dynamic link libraries (DLLs), on Windows systems. The Regsvr32.exe binary may also be signed by Microsoft.”
It is a technique used to evade defenses, which is why the malicious iroto.dll could be run without triggering a block.
Now we investigate further to confirm/deny the second part of the hypothesis which was that the endpoint has been compromised. What IoCs will we be looking for to prove this? Well, we see the excel file spawned new processes using Excel macros. Specifically, the exploitation of regsvr32 to run malicious .dll files.
We also identified two malicious outbound network connection attempts.
And one confirmed connection. I believe the other site is probably no longer active which is why it did not connect although a DNS request was made for it.
So with all of these known malicious artifacts we will quickly track how far along the attack path the attack got. To do this we first pivot on the process list of the endpoint LarsPRD looking for exploitation of regsvr32 to run the malicious .dll files.
As expected, we find evidence that the process was ran which indicates 2 things:
1. The user open the attachment and macros were ran.
2. The end point is compromised.
So now we contain it.
The next thing we want to check is the outbound network connections around the time of the event to identify if connections were made to the identified malicious IPs. We will filter for June 13, 2021 around 2:00 pm.
The 188.213.19[.]81 matches the malicious outbound network connection we found in the sandbox, so in real life we would block that Ip since it is deemed malicious. It resolves to nws[.]visionconsulting[.]ro
We also see it in the browser history.
Was any of the identified malicious commands ran on the endpoint? In the command history we see the iroto.dll was ran using the regsvr32.exe
At this point, we have all the IoCs we would need. We can check log management (like a SIEM) to look for any connections from the device from around the time of the incident. Use the IP for the compromised machine and see what we find. 172.16.17[.]57
The only two logs associate with the malicious endpoint are the malicious ones we were already looking at. This is really an ideality more so than a reality because in a real environment you’d have to create a specific query to achieve this.
There does not appear to be evidence of lateral movement.
Recap:
If your org has a web proxy, or web filter, you would want to:
-block those URLs.
-remediate like emails if present
-create a query to search for any other connections to those ips
-block the ips
-train the user
What if you were in an MSSP and had no access to the email? Perform recon on the file using the hash and then look for connected processes and connections that may have been running on that endpoint. Based on that, you should be able to call the company or whatever your SLA requires and let them know of the security incident.
Thanks for reading!
Comentarios