How Ransomware Groups Got In: @rapid7 MDR’s Top Initial Access Vectors from Q1 2025.

Top Initial Access Vectors
- Account Compromise (No MFA)
- Vuln Exploitation (all known, patchable)
- Brute Forcing
- Exposed RDP
- SEO Poisoning

What our #MDR team saw in real-world ransomware intrusions in Q1—and what you can do to reduce risk 🧵 1. Account Compromise (No MFA)
Over 50% of ransomware-related intrusions started with compromised credentials.

What we saw:
- Single-factor sign-ins (VPNs, email, portals)
- Accounts that should’ve had MFA, but didn’t—usually due to misconfigurations

✅ Action:
- MFA all of the things. All of them.
Go with phishing-resistant MFA (like FIDO2 or security keys) if you can.
- If you're using push-based MFA, make sure number matching and location-based checks are turned on to stop push fatigue abuse.
- Also, audit your IdP—misconfigured policies and exceptions are more common than you think.

Top 3 #M365 Account Takeover (ATO) actions spotted by our SOC in Q1:

1. New-inbox rule creation to hide attacker emails
2. Register new MFA device for persistence
3. Create mailbox forwarding rules to monitor victim comms and intercept sensitive info

More details in 🧵... 50% of ATO activity in M365 we identified was for New-inbox rules created by an attacker to automatically delete certain emails from a compromised account. By deleting specific emails, an attacker can reduce the chance of the victim or email admins spotting unusual activity.

BEC threat actors favorite #M365 Inbox-rule names:

'.'
'..'
'.;'
'l'
'r'

By deleting specific emails, an attacker can reduce the chance of the victim spotting unusual activity.

You can build high quality detections to spot this activity. A 🧵with real-world examples... Account takeover (ATO) activity in M365 can involve various unauthorized actions performed by an attacker who has gained control over the account.

A #SOC analyst picks up an alert and decides not to work it.

In queuing theory, this is called “work rejection”–and it’s quite common in a SOC.

TL;DR - “Work rejection” is not always bad, but it can be measured and the data can help improve performance. More details in the 🧵.. A couple of work rejection plays out in the SOC. The most common:

An analyst picks up an alert that detects a *ton* of benign activity. Around the same time, an alert enters the queue that almost *always* finds evil. A decision is made...

What does a #SOC tour look like when the team is remote?

TL;DR - Not a trip to a room with blinky lights - but instead a discussion about mission, mindset, ops mgmt, results and a demo of the tech and process that make our SOC “Go”.

SOC tour in the 🧵... Our SOC tour starts with a discussion about mission. I believe a key ingredient to high performing teams is a clear purpose and “Why”.

What’s our mission? It's to protect our customers and help them improve.

A good detection includes:
- Clear aim (e.g, remote process exec on DC)
- Unlocks end-to-end workflow (not just alert)
- Automation to improve decision quality
- Response (hint: not always contain host)
- Volume/work time calcs
- Able to answer, “where does efficacy need to be?” On detection efficacy:
⁃ As your True Positive Rate (TPR) moves higher, your False Negative Rate moves with it
⁃ Our over arching detection efficacy goal will never be 100% TPR (facts)
⁃ However, TPR targets are diff based on classes of detections and alert severities

There’s no more strategic thing than defining where you want to get to and measuring it.

Strategy informs what "great" means, daily habits get you started (and keep you going) and measurements tell you if you’re there or not.

A 🧵 on #SOC strategy / metrics: Before we hired our first #SOC analyst or triaged our first alert, we defined where we wanted to get to; what great looked like.

Here’s [some] of what we wrote:

How to think about presenting good security metrics:

- Anchor your audience (why are these metrics important?)
- Make multiple passes with increasing detail
- Focus on structures and functions
- Ensure your audience leaves w/ meaning

Don’t read a graph, tell a story

Ex ⬇️ *Anchor your audience 1/4*

Effective leaders have a firm handle on SOC analyst capacity vs. how much work shows up. To stay ahead, one measurement we analyze is a time series of alerts sent to our SOC.

Once a month we get in front of our exec/senior leadership team and talk about #SOC performance relative to our business goals (grow ARR, retain customers, improve gross margin).

A 🧵on how we translate business objectives to SOC metrics. As a business we want to grow Annual Recurring Revenue (ARR), retain and grow our customers (Net Revenue Retention - NRR) and improve gross margin (net sales minus the cost of services sold). There are others but for this thread we'll focus on ARR, NRR, and gross margin.
/1

Julie Zhou's, "The Making of a Manager" had a big impact about how I think about management.

One of the key lessons is that managers should focus on three areas to achieve a high multiplier effect: purpose, people, and process.

Let's apply that lesson to make a #SOC manager.. Purpose: Be clear with your team about what success looks like - and create a team and culture that guides you there. Go through the exercise of articulating your teams purpose.

The "purpose" we've aligned on at Expel in our SOC: protect our customers and help them improve.

A good alert includes:
- Detection context
- Investigation/response context
- Orchestration actions
- Prevalence info
- Environmental context (e.g, src IP is scanner)
- Pivots/visual to understand what else happened
- Able to answer, "Is host already under investigation?" Detection context. Tell me what the alert is meant to detect, when is was pushed to prod/last modified and by whom. Tell me about "gotchas" and point me to examples when this detection found evil. Also, where in the attack lifecycle did we alert? This informs the right pivots.

Gathering my thoughts for a panel discussion tomorrow on scaling #SOC operations in a world with increasing data as part of the Sans #BlueTeamSummit.

No idea where the chat will take us, but luck favors the prepared. A 🧵 of random thoughts likely helpful for a few. Before you scale anything, start with strategy. What does great look like? Are you already there and now you want to scale? Or do you have some work to do?

Before we scaled anything @expel_io we defined what great #MDR service looked like, and delivered it.

4 steps to scaling a #SOC:

1. Collect data, you won't know what it means
2. Collect data, *kind* of understand it
3. Collect data, understand it. Able to say: "This is what's happening, let's try changing *that*"
4. Operational control. "If we do *this*, *that* will happen" What you measure is mostly irrelevant. It’s that you measure and understand what it means and what you can do to move your process dials up or down.

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

Let's walkthrough an example:

This is a time series of alerts sent to the #SOC for triage since Jan 1. Counts are given at a daily granularity.

The overall trendline, plotted in grey, is showing a gradual increase, expected as we’ve onboarded new customers over the period.

https://twitter.com/jhencinski/status/1389220787891183619

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.

Seeing automated exploitation of Internet-facing Exchange servers to drop webshell (working to confirm CVE#)

- exploit to deploy webshell
- w3wp.exe ➡️ CMD shell ➡️ PS download cradle
- c2: 86.105.18.116

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. :)

Can we detect ZIP / JScript for initial access on 🪟?

1. Open txt editor
2. var WshShell = new ActiveXObject("Wscript.Shell");

WshShell.Popup("You can configure WSH files to open in Notepad");

WScript.exit;

3. Save as 1.js
4. Double-click
5. Query SIEM / EDR What about #BEC in O365?

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?

When I think about threat hunting:

- 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.

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?

To the "do it all" IT folks or new #SOC analysts that need a little help - a thread for you.

Cheat sheets and example queries for Endgame, CS Falcon, ATP, and CbR using a recent incident as the starting point.

cc: thanks to @AshwinRamesh94 for the query work Yesterday we stopped a #ransomware attack at a customer where initial entry was a remote admin connection from a 3p IT provider

- Attacker had admin
- Connected to host via ConnectWise (RDP)
- Opened CMD shell to open PS download cradle to deploy SODINOKIBI from hastebin[d]com

TL;DR - Potentially bad #ATP rule update last night. Don't panic. Investigate - don't let me bias you. Providing for broader context.

#MDR insight: Between 06:25 UTC - 07:40 UTC we detected an unusually high # of false positive MS Defender ATP alerts for "Cobalt Strike C2". We observed false positive alerts for:
[CommandAndControl] Cobalt Strike C2

Observed at: all customers running MS Defender ATP.

Fp sequence: System boot / logon initialization / ATP alert on netconn to 127.0.0.1.

We timelined.

No evidence of attacker activity. Bad rule.