When compromised mailboxes attack & Using Microsoft Sentinel to Respond

Business Email Compromise (BEC) isn't fun for the owner of the compromised mailboxes, or the folks on the receiving end of phish sent from those compromised mailboxes.  This post is for those in the latter camp, a place I've been on a couple of occasions in my career.  In one instance the bad actor got rather ambitious and sent numerous phishing messages to my organization - all were leveraging existing threads in multiple mailboxes, and using at least one of three malicious hyperlinks. Here is how I attacked the problem with Sentinel:

We blocked inbound mail from the source to stop the bleeding, and then went about identifying the messages involved:

       

let suspectmessages = (
EmailEvents
| where SenderFromDomain contains "sourceofphish.net"
)
| summarize by NetworkMessageId;
EmailUrlInfo
| where NetworkMessageId has_any (suspectmessages)
| summarize by Url

Of course this could also be done in MS 365 Advanced Hunting, but I was SO HAPPY when email data was added to the MS 365 connector into Sentinel.  With the above, we are inventorying all of the messages coming from the breached organization, and from that list taking stock of all of the hyperlinks therein.  The malicious links stood out like sore thumbs, and  we promptly blocked them via endpoint indicators and web filtering.

After seeing what the messages did in a sandbox, and querying DeviceNetworkEvents to make sure nobody hit those indicators, I wanted to focus on who the specific senders were: 

       
let suspectmessages = (
EmailEvents
| where SenderFromDomain contains "sourceofphish.net"
)
| summarize by NetworkMessageId;
let badURLmessages = (
EmailUrlInfo
| where NetworkMessageId has_any (suspectmessages)
| where Url has_any ('evildomain1.com', 'evildomain2.in', 'evildomain3.com')
| summarize by NetworkMessageId);
EmailEvents
| where NetworkMessageId has_any (badURLmessages)
| sort by TimeGenerated desc 

 I only had a few malicious links so I just populated an array in the "Where url has_any" line.  Looking at this in retrospect this could have been made a little smoother, but it got the job done.  Now I had a timeline of events and plenty of information to share with the victim company, and indicators to share with our friendly neighborhood ISAC.



Comments

Post a Comment

Popular posts from this blog

MS 365: Handilng False Positives Is Two Step Process on the Back End

Today in "weird things I just noticed", I was looking at a group of messages falsely flagged as Junk Mail in the Explorer (within the 365 Defender portal).  I selected the messages, clicked Message Actions, and then Report Clean.  All done? Not quite.  If you do this within Outlook, your message is reported and automatically moved to the Inbox.  In Explorer, you then need to separately take the action "Move to Inbox"- which presents a Remediation wizard to document what you're doing and set the priority.  Once complete you can go to the Action Center to track process. That's fine, I see where Microsoft is coming from since it's a back-end administrative action that involves getting hands within someone's mailbox.  It's just something to keep in mind if you identify a source of false positives in email filtering.
Read more

Microsoft Sentinel - Hunting for Single Character Filenames

 Hackers, the good ones and the evil ones, are lazy.  In the interest of fewer keystrokes they will use filenames with single characters (e.g. "f.exe" or "2.ps1").  So this short but sweet query will help you find potentially problematic executables: let allowlist = datatable (DName:string) ['because you are going to have exceptions','Put em here']; let allowarray = allowlist | summarize make_set(DName); DeviceProcessEvents | where FileName matches regex @'^.\.[eE][xX][eE]' or FileName matches regex @'^.\.[pP][sS][0-9]' or FileName matches regex @'^.\.[cC][mM][dD]' or FileName matches regex @'^.\.[cC][oO][mM]' | where SHA1 !in (allowarray) | project AccountName, DeviceName, SHA1, FileName, FolderPath, InitiatingProcessAccountName, InitiatingProcessAccountUpn   I was reminded of this when reading this tweet from @GossiTheDog and @h2jazi, but please note that the above query will NOT de...
Read more

Active Directory Identity Protection Alerts & Using Microsoft Sentinel For the Deets

Image
 Ever get one of these? An alert that says "User at Risk Detected... We detected a new user with at least high risk in your [company] directory.  This might be because we noticed suspicious account activity or we found their emails and passwords posted in a public location." This is Azure AD Identity Protection at work.  But if you click on "View Detailed Report" to dig into the risk events, you may get the rather vague "Unfamiliar Sign in Properties" as the source of the alert.  But.what property in particular caused this alert?  The portal doesn't seem to say. The good news is you may be able to find the answer in Sentinel.  Use this query to look at the high risk detection: //The details on identity protection risk detections, highlighting what you're probably looking for @tinyinfosec May, 2022 //Then go back to SignInLogs to review all recent signins in context SecurityAlert | where ProductName == "Azure Active Directory Identity Protectio...
Read more