Cybercriminals Impersonate Malwarebytes to Steal User Credentials

Cybercriminals Impersonate Malwarebytes to Steal User Credentials

As part of an ongoing effort to highlight active and technically interesting intrusions, a new “Flash Hunting Findings” investigation has uncovered a short but well‑structured malware campaign impersonating MalwareBytes to deliver infostealers and steal user logins and crypto‑wallet data.

The activity was observed between January 11 and January 15, 2026, and is characterized by consistent ZIP structures, reuse of a unique behash, and the abuse of DLL sideloading to gain execution on victim systems.

Threat actors are distributing ZIP archives that abuse the MalwareBytes brand to appear legitimate. Most of the samples use filenames following a consistent pattern such as:

malwarebytes-windows-github-io-X.X.X.zip

Across all observed versions, these ZIP files share the same behash, allowing defenders to easily cluster and track them:

behash: "4acaac53c8340a8c236c91e68244e6cb"

The first known instance of these archives was seen on January 11, 2026, with the latest identified sample dated January 14, 2026, suggesting a focused, time‑bound operation rather than a long‑running spam wave.

Inside, the archives have a nearly identical internal layout. Each package contains:

  • A legitimate, trusted executable (EXE), used as the loader.
  • A malicious DLL that serves as the primary payload.
  • A seemingly harmless TXT file used as a pivot artifact for hunting.

This consistency across all ZIPs makes the campaign highly fingerprintable from a threat‑hunting perspective.

TXT Pivot for Infrastructure and Campaign

Each archive includes a TXT file observed on VirusTotal under filenames such as gitconfig.com.txt or Agreement_About.txt.

The file’s content is minimal, containing only a GitHub URL string, and does not contribute functionally to the intrusion chain.

However, this TXT file is extremely useful for defenders. By leveraging its VirusTotal resource and querying its “execution parents” via the VT API v3 endpoint:

/api/v3/files/09a8b930c8b79e7c313e5e741e1d59c39ae91bc1f10cdefa68b47bf77519be57/execution_parents

analysts can quickly enumerate additional ZIP archives that dropped or interacted with this TXT file.

This provides an efficient pivot for discovering further samples tied to the same operation and mapping out the broader infrastructure and distribution methods behind the campaign.

The core of the attack relies on DLL sideloading, a well‑known technique where a malicious DLL is placed alongside a legitimate executable so that Windows loads the attacker’s code instead of, or in addition to, the genuine library.

CoreMessaging.dll (source – Virustotal).

In this campaign, the primary payload is a malicious DLL named CoreMessaging.dll. When the victim or an analyst executes the trusted EXE bundled in the ZIP, the operating system resolves DLL dependencies from the local directory first, resulting in the loading of the attacker‑controlled CoreMessaging.dll.

This gives the threat actor code execution while preserving the appearance of a legitimate application launch.

The DLLs used in this operation expose several distinctive traits that make them excellent hunting anchors:

  • Unusual signature strings in their metadata, including phrases such as
    Peastaking plenipotence ductileness chilopodous codicillary.
    and fake copyright notices like
    © 2026 Eosinophil LLC
  • Exported function names composed of strange alphanumeric identifiers, for example:
    15Mmm95ml1RbfjH1VUyelYFCf and 2dlSKEtPzvo1mHDN4FYgv

These artifacts can be used in VT or EDR telemetry searches to uncover related DLLs and additional stages within the same threat cluster.

Infostealer Final Payloads

Behavioral analysis of the ZIP samples’ “relations” in sandboxes shows a clear, repeatable infection chain: the ZIP is extracted, the legitimate EXE is run, CoreMessaging.dll is sideloaded, and then new payloads are dropped and executed.

Within the “Payload Files” section of these analyses, investigators consistently observe secondary-stage binaries flagged as infostealers.

Payload files.
Payload files ( Source – Virustotal).

These final payloads are detected by multiple YARA rules, including signatures that focus on behavior and patterns associated with harvesting cryptocurrency wallet browser extension IDs and other sensitive data.

In addition to standard credential theft, this suggests a strong monetization angle around crypto‑asset theft.

To track these secondary payloads, analysts can pivot on another behash representing the final stage:

behash: 5ddb604194329c1f182d7ba74f6f5946

Files matching this behash have been repeatedly linked to the infostealer family used in this operation and provide yet another stable indicator for clustering and ongoing hunting.

For defenders, this campaign offers several concrete detection and hunting opportunities:

  • Look for ZIP archives using MalwareBytes‑like names and sharing the initial behash.
  • Monitor for DLL sideloading involving CoreMessaging.dll alongside unusual exports and distinctive signature strings.
  • Use the TXT file and both behash values as pivots in VirusTotal, EDR telemetry, and threat‑intel platforms.
  • Treat any unexpected MalwareBytes “installer” or GitHub‑branded ZIP downloaded from untrusted sources as highly suspicious.

While the observed activity window is short, the reuse of infrastructure, DLL traits, and behash identifiers makes this threat cluster relatively easy to track for well‑equipped security teams and a timely reminder that trusted brands remain a powerful lure for credential‑stealing operations.

Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.



Source link