Monday, February 17, 2025
HomeMalwareEmoCrash - Researchers Exploited a Bug in Emotet Malware to Stop its...

EmoCrash – Researchers Exploited a Bug in Emotet Malware to Stop its Distribution

Published on

SIEM as a Service

Follow Us on Google News

EmoCrash: Recently, the cybersecurity researchers have detected and exploited a bug with infamous Emotet malware to stop its distribution.

Emotet is one of the most notorious email-based malware that offers several botnet-driven spam campaigns and ransomware attacks as a service. 

It includes a flaw that enabled the cybersecurity researchers to initiate a killswitch and stop the malware from affecting the systems for six months. But, the cybersecurity experts have worked out on a vaccine, that is EmoCrash, against the ransomware Emotet.

EmoCrash

Emotet first appeared in the year 2014, since then, they emerged into a full-fledged botnet that’s intended to steal account credentials and download. But this malicious malware mysteriously vanished from February, and now again, it re-emerged in early August.

The patch that the experts have developed was named EmoCrash; well, this was created after several trial and error.

A report from Binary Defense threat researcher, James Quinn, tried to infect a clean computer with Emotet intentionally, and he detected that the abnormal registry key triggered a defense overflow in Emotet’s code and struck the malware. 

The result was quite positive as it effectively preventing users from getting affected. Moreover, Quinn had designed both an Emotet vaccine and a killswitch at a time, and here they are mentioned below:-

  • Killswitch, V1
  • Killswitch, V2

EmoCrash would be extended across a network, as it could enable system administrators to examine or to put a setup warning for the two log event IDs. And soon after, they can discover when and if Emotet affected their networks.

Emotet’s New mechanism

Earlier in February, Emotet published a massive codebase overhaul, and this codebase changes several of the installation and resolution mechanisms, offering a polymorphic state-machine to their code stream. 

That’s why the codebase added a coat of obfuscation to the loader, as it makes critique more difficult. One of the key transformations was the replacement of the word list and file generation algorithm that are used by Emotet in previous Emotet installs.

They were replacing the old ones with a new algorithm that was created a filename to gather the malware on each victim system, utilizing a randomly chosen “exe or dll” system filename from the system32 record.

Here they name the file as an exclusive OR (XOR) key, and the XOR key was installed to the volume serial number in little-endian form.

Dev mode

Emotet entered dev mode on February 7, and at that time, the operators of Emotet stopped spamming. After that, they started working on developing their malware, and it continued from February 7 – July 17, 2020. 

Though their distribution of spam was defeated, but, they were not “inactive” through this time; as they proceeded to focus on a few core binary and protocol updates. So, the security experts have warned users to stay safe as this notorious malware may occur anytime.

You can follow us on Linkedin, Twitter, Facebook for daily Cybersecurity and hacking news updates.

Latest articles

Meta’s Bug Bounty Initiative Pays $2.3 Million to Security Researchers in 2024

Meta's commitment to cybersecurity took center stage in 2024 as the tech giant awarded...

Google Chrome Introduces AI to Block Malicious Websites and Downloads

Google has taken a significant step in enhancing internet safety by integrating artificial intelligence...

Fake BSOD Attack Launched via Malicious Python Script

A peculiar malicious Python script has surfaced, employing an unusual and amusing anti-analysis trick...

SocGholish Malware Dropped from Hacked Web Pages using Weaponized ZIP Files

A recent wave of cyberattacks leveraging the SocGholish malware framework has been observed using...

Supply Chain Attack Prevention

Free Webinar - Supply Chain Attack Prevention

Recent attacks like Polyfill[.]io show how compromised third-party components become backdoors for hackers. PCI DSS 4.0’s Requirement 6.4.3 mandates stricter browser script controls, while Requirement 12.8 focuses on securing third-party providers.

Join Vivekanand Gopalan (VP of Products – Indusface) and Phani Deepak Akella (VP of Marketing – Indusface) as they break down these compliance requirements and share strategies to protect your applications from supply chain attacks.

Discussion points

Meeting PCI DSS 4.0 mandates.
Blocking malicious components and unauthorized JavaScript execution.
PIdentifying attack surfaces from third-party dependencies.
Preventing man-in-the-browser attacks with proactive monitoring.

More like this

Fake BSOD Attack Launched via Malicious Python Script

A peculiar malicious Python script has surfaced, employing an unusual and amusing anti-analysis trick...

SocGholish Malware Dropped from Hacked Web Pages using Weaponized ZIP Files

A recent wave of cyberattacks leveraging the SocGholish malware framework has been observed using...

Lazarus Group Targets Developers Worldwide with New Malware Tactic

North Korea's Lazarus Group, a state-sponsored cybercriminal organization, has launched a sophisticated global campaign...