Quick 🧵of some of the insights and actions we're sharing with our customers based on Q2 '21 incident data.
TL;DR:
- #BEC in O365 is a huge problem. MFA everywhere, disable legacy protocols.
- We’re 👀 more ransomware attacks. Reduce/control the self-install attack surface.
Insight: #BEC attempts in 0365 was the top threat in Q2 accounting for nearly 50% of the incidents we identified
Actions:
- MFA everywhere you can
- Disable legacy protocols
- Implement conditional access policies
- Consider Azure Identity Protection or MCAS
re: Azure Identity Protection & MCAS: They build data models for each user, making it easier to spot atypical auth events. Also, better logging. There's $ to consider here, I get it. Merely providing practitioner's perspective. They're worth a look if you're struggling with BEC.
For the G-Suite crowd: We did not identify a BEC attempt in G-Suite in Q2.
O365 has some initial configurations that need to be changed by default, whereas G-Suite’s settings out-of-the-box are pretty straightforward.
Insight: ⬆️ in ransomware activity. Of the ransomware incidents we stopped, 100% required user interaction to gain initial entry in Q2.
Actions:
- Control self-install attack surface: associate WSH files with Notepad, block Excel 4.0 macros
- Also, don't expose RDP to Internet
The top entry point for incidents that could have resulted in eventual ransomware deployment? Zipped JScript files and Excel 4.0 macros. Note the actions above.
Not exploits, self-install as a vector.
Insight: Continue to see ⬆️ on attacks targeting cloud identity access providers, ~50% targeting Okta creds.
Insight: Windows PowerShell isn’t dead. The bad guys are still using it. ~ 19% of the opportunistic attacks we identified executed PowerShell as part of the install sequence
Actions:
- Before we go throwing around "constrained lang mode" understand how your org uses PS
Insight: Orgs experienced more incidents from employees self installing malware or running an evil macro than from s/w vulnerabilities. In fact, only 3% of malware incidents we identified in Q2 were the result of a s/w vuln.
Action:
- Control self-install attack surface
Insight: Nearly half of the #redteam activity we detected in Q2 was in #AWS. Initial leads? Custom rules on CloudTrail for odd use of legit account and access to cloud instance metadata API.
Historical context of how an account is typically used makes it easier to spot evil.
Insight: 3% of malware incidents identified in Q2 were the result of a s/w vuln (cue the coin miners).
We see a lot of variance at the end of Feb that continues into the beginning of Mar. This was due to a number of runaway alerts and some signatures that needed tweaking.
What’s most interesting is that the variance decreases after we released the suppressions features on Mar 17.
We believe this is due to analysts having more granular control of the system and it’s now easier than ever get a poor performing Expel alert back under control.
Process tree below so folks can query / write detections
Also, update!
Detection moments:
- w3wp.exe spawning CMD shell
- PS download cradle to execute code from Internet
- CMD shell run as SYSTEM to run batch script from Public folder
- Many more
Bottom line: a lot of ways to spot this activity.
Build.test.learn.iterate.
Also, update. :)
And some additional details from @heyjokim after further investigating:
Attack vector/Initial Compromise: CVE-2021-27065 exploited on Exchange Server
Foothold: CHOPPER webshells
Payload: DLL Search Order Hijacking (opera_browser.exe, opera_browser.dll, opera_browser.png, code)
1. Create an inbox rule to fwd emails to the RSS Subscriptions folder 2. Query your SIEM 3. How often does this happen? 4. Can you build alert or cadence around inbox rule activity?
- Pro-active search for active / historical threats
- Pro-active search for insights
- Insights lead to better understanding of org
- Insights are springboard to action
- Actions improve security / risk / reduce attack surface
With these guiding principles in hand, here's a thread of hunting ideas that will lead to insights about your environment - and those insights should be a springboard to action.
Here are my DCs
Do you see evidence of active / historical credential theft?
Can you tell me the last time we reset the krbtgt account?
Recommendations to harden my org against credential theft?
2020 @expel_io incident stats tell a familiar story: a lot of commodity malware *still* being deployed via evil macros and zipped HTA / JS files.
This isn't a thread to tell you to block macros or associate WSH files with notepad (like PS), but questions to ask if you can't.
On blocking macros: If it were easy, everyone would do it.
But if you're a #SOC analyst, do you fire an alert when winword.exe spawns an unusual process like PS or regsvr32?
Can you create a macro that behaves like an evil one but is totally benign to test your alerting?
Can you use #EDR to understand which processes are almost never spawned from winword.exe? Or maybe ask which processes spawned from winword.exe initiate an external connection out? Can you fine tune your logic and deploy in BLOCK mode?