Thread by @KyleHanslovan

EMOTET ANALYSTS: Everyday, our team sees 5-15 clients networks wrecked by Emotet. Cleanup/response can take 3d - 3mo depending on IT department skills, tools, and telemetry. We’re creating a “synchronized” removal capability and could use additional perspective. 1/x

We know the core of lateral movement for Emotet, TrickBot, Qakbot, etc. is abusing of elevated creds/tokens, standard local admin passwords, and MS17-010 for poorly maintained networks. With these, payloads are dropped to remote shares via SMB & started via remote services. 2/x

For starts, we could use some perspective to make sure there’s not more we’re missing in regards to lateral movement.

We are aware of email spreading and browser password scraping plugins. However, we like to scope this to stopping local self-propagation of the bot first. 3/x

Our rough idea purge Emotet en masse (within a single network) follows this basic plan:
1️⃣ Create host fw rules to disable SMB inbound/outbound.
2️⃣ Blow away all persistent payloads.
3️⃣ Reboot to purge in-memory payloads & free locked files
4️⃣ When all clear, remove fw rules
4/x

For anyone who’s done #DFIR at scale, you know it’s NEVER this simple. This is also very disruptive to network productivity.

1️⃣ Disabling SMB is going to break authentication, file sharing, scanning devices, etc.. This approach is extreme if not very limited in time.
5/x

2️⃣ We’re fortunate that identifying the persistence mechanisms is our specialty. We have the data to task all hosts to remove these with little effort.

*Probably* not going to break anything here unless these worms change their TTPs.
6/x

3️⃣ As for the reboot, this is a big interruption. Doing this could lose unsaved work if outage not coordinated.

Another concern is the race condition which can happen between blowing away peristence & the reboot. Would love to hear your thoughts here (delete on reboot?) 7/x

3️⃣ Also interested if we’re straight out of our mind to think this simple to quickly blow away persistence and reboot?

Obviously, we’ll still have the other Dridex, IcedID, Qakbot artifacts dropped. However, we’re just trying to simultaneously chop the heads of this hydra! 8/x

4️⃣ As for disabling the in/outbound FW rules, we’re most concerned about “When?”. The easy (lazy?) answer is a “After the last infected host has been sanitized/rebooted?”

Business operations may change this priority though. That said, I think this step might be case-by-case. 9/x

4️⃣ For instance, IT has (finally) implemented network segmentation for critical assets. All critical assets are sanitized, so now disable host fw rules restricting SMB.

Probably endless other scenarios. Would ❤️ your thoughts on enumerating the most common/risky ones. 11/x

Alright, please tear into the technical worth/execution of this idea. Criticism here is worth more than praise.

I only ask you to refrain from “you should wipe every host” comments. We know this the right answer in theory. However, security in practice is a separate beast. 12/12

Help/feedback? @JAMESWT_MHT @Mesiagh @executemalware @AmirRedh @dms1899 @pollo290987 @ps66uk @NelsonSecurity @DynamicAnalysis @Bank_Security @Jan0fficial @Bitterman59 @bauldini @dmfroberson @HazMalware @unixronin @avman1995 @James_inthe_box @JayTHL @racco42

Help/feedback? @DecayPotato @devnullnoop @baberpervez2 @leunammejii @papa_anniekey @neonprimetime @jcarndt @pancak3lullz @FullM3talPacket @jkayden37 @gorimpthon @CholeVallabh @prsecurity_ @malware_traffic

Thanks you so much #infosec!