In SOC143 we’re informed of a potential password stealing file having been detected in the email system, so let’s get to the bottom of this.
Alert
The SIEM alert we receive includes all the relevant information we need to start looking into this incident, mainly the SMTP address and the source and destination addresses. The rule name also gives us an indication in regards what to look for, but given that there isn’t that much going on in an email message this would become rather obvious really fast anyway.
Detection
Parse Email
First and foremost we need to look into the alert to see what has been caught, and we have lot to work with already. The email in question was sent April 26, 2021, 11:03 p.m. using SMTP address 180.76.101.229, and while it’s safe to say that the originating address was spoofed, it’s bill@microsoft.com with the recipient in our end being ellie@letsdefend.io.
The email itself has no body, but it does include one zip file called bd05664f01205fa90774f42468a8743a.zip. The file contains a document called Ellie@letsdefend.io_63963965Application.HTML, which we will be analyzing through the online malware sandbox AnyRun later on.
Analysis
Analyse the URL/Attachment
We’ll do a quick VirusTotal run on the HTML file, and as expected get back a positive result for a trojan.
But while we know what it is, we want to know what it actually does, and while we could always open up the file on our own lab host, it’s good to play it safe and use a service like AnyRun to do it for us so that we’re able to see if the file may try to call back home.
Opening the file we get what looks like a Microsoft login prompt, and if we press the Sign In button the script tiers to reach out to tecyardit.com / 109.68.33.64, most likely in order to deliver the credentials an unassuming user may have inputted to the fake login field.
Containment
Check if Mail Was Delivered to User
We see that the device action is set to Allowed, meaning that the emails has indeed been delivered to ellie@letsdefend.io, so we should delete the email from their Inbox, and then make sure they have not opened the attachment and fallen victim.
Delete Email From Recipient!
Check If Someone Opened the Malicious File/URL
After removing the email we’ll check the logs to see if anyone has reached out to the indicated C2 server tecyardit.com / 109.68.33.64, but since our Log Search comes up with nothing we know that the vigilant user has not accessed the file in the attachment. That, or they just hadn’t gotten around to it - either way, this is a good outcome.
Lessons Learned
Once again we get reminded that the end users are a potential weak link, and even if we do have detection and mitigation systems in place something is bound to get past them, and at that point not falling victim for phishing and other malware becomes the responsibility of the users themselves.
Conducting user security awareness training often is a great way to help mitigate these risks.
Artifacts
We should note the following:
The maliscious file and its MD5 hash: Ellie@letsdefend.io_63963965Application.HTML / bd05664f01205fa90774f42468a8743a
The C2 server address and IP we uncovered: tecyardit.com / 109.68.33.64
Overall this case was a generic phishing attempt delivered via email, but as the vigilant user has not accessed the file simply removing the file and the message and updating detection rules will suffice.