highPhishing

Storm-1811 Signed Nine Times: An EV Code Signing Certificate, DNS MX Tunneling, and a Ransomware Precursor Built in Four Iterations

PublishedMarch 12, 2026

Threat Actors:s stockpiled the certificate before use.ProfileAssessment**: Blitz Brigantine (a.k.a. Storm-1811, STAC5777)by Microsoft)s through likely fraudulent means.

phishingdll-sideloadingsocial-engineeringc2ransomwareexploitaptspearphishing

TL;DR: Nine malware samples from the A0Backdoor family surfaced on MalwareBazaar today -- all signed with a now-revoked Extended Validation code signing certificate issued to an Argentinian media company. The samples are the work of Blitz Brigantine (Storm-1811 / STAC5777), a Black Basta and Cactus ransomware affiliate targeting finance and healthcare across 10 countries. The attack chain abuses Microsoft Teams vishing and Quick Assist to deploy trojanized MSI installers that sideload a shellcode launcher DLL through legitimate Microsoft CrossDeviceService binaries. The backdoor phones home through DNS MX record tunneling -- a covert channel that hides C2 traffic inside what looks like routine email infrastructure lookups to Google and Cloudflare DNS. We reconstructed four distinct build iterations spanning December 9-17, 2025, identified two DLL sideloading vectors (hostfxr.dll and clipsp.dll), mapped the build pipeline's operational security failures, and authored four YARA rules for detection. This is the most APT-like cluster we have analyzed to date.

Why This One Matters

Most malware we process through GHOST lands somewhere on the commodity spectrum -- mass-distributed stealers, boilerplate loaders, infrastructure that screams "automated." This cluster is different. An EV code signing certificate does not fall off the back of a truck. Someone either compromised a legitimate Argentinian company or walked through SSL.com's identity verification process with forged documentation. The threat actors then used that certificate to sign nine distinct payloads across four build iterations, deployed them through Microsoft's own collaboration tools, and tunneled their command-and-control traffic through DNS MX records to avoid leaving a single direct connection to attacker infrastructure.

This is methodical. This is funded. And the end goal is ransomware.

The Delivery: Teams Vishing and Quick Assist Abuse

The initial access vector for this campaign does not involve a phishing email in the traditional sense. The operators behind Blitz Brigantine have adopted a social engineering playbook that exploits enterprise communication tools:

Email bombing -- the target's inbox is flooded with subscription confirmations and spam, creating confusion and urgency
Microsoft Teams call -- the attacker contacts the victim via Teams, impersonating IT support offering to "fix" the email problem
Quick Assist session -- the victim grants remote access through Microsoft Quick Assist, a legitimate Windows remote support tool
MSI deployment -- the attacker drops Update.msi via Microsoft cloud storage and executes it

This delivery chain is devastatingly effective because every tool involved is a legitimate Microsoft product. The victim never opens a suspicious attachment. They never click a phishing link. They grant access through the same Quick Assist workflow their real IT department uses. Most email security gateways and browser sandboxes never see a thing.

The Payload: Anatomy of an MSI That Looks Like Microsoft

The MSI installer masquerades as "Microsoft Cross Device Add-in" -- a product name close enough to real Microsoft branding that it would not raise flags during a casual review. Under the hood, the packaging is polished:

Property	Value
Product Name	Cross Device Add-in
Manufacturer	Microsoft 3rd Party Application Component
Version	25017.203.3370
Build Tool	Advanced Installer 19.9 (build de6d6401)
Install Path	`%LocalAppData%\Microsoft\CrossDevice Share\25017.203.3370\`
Execution	CustomAction type 1234 (hidden, async, SYSTEM context)

The install path is the detail that sells the disguise. It nests inside %LocalAppData%\Microsoft\ -- a directory that any sysadmin would recognize as a legitimate Microsoft application folder. The version number 25017.203.3370 mimics Microsoft's internal build numbering scheme.

The MSI drops four files into the install directory:

CrossDevice Share\25017.203.3370\
    |-- CrossDeviceService.exe    (legitimate .NET 9 apphost)
    |-- CrossDeviceService.dll    (legitimate .NET assembly, AOT-compiled)
    |-- hostfxr.dll               (TROJANIZED -- dll_sc_launcher.dll)
    |-- hostpolicy.dll            (legitimate .NET hosting)

Three of the four files are real Microsoft binaries, complete with PDB paths pointing to Microsoft's internal build infrastructure (D:\a\_work\1\s\artifacts\obj\win-x64.Release\). The fourth -- hostfxr.dll -- is the weapon.

The Sideload: Hijacking .NET's Own Loading Mechanism

DLL sideloading is not new. But sideloading through .NET's hosting layer is a particularly elegant choice. When CrossDeviceService.exe launches, it follows the standard .NET apphost initialization sequence: load hostfxr.dll, initialize the runtime, load the application assembly. The attacker replaces hostfxr.dll with their own DLL that exports all the expected functions (hostfxr_main, hostfxr_close, hostfxr_initialize_for_runtime_config) while silently executing a shellcode payload.

The internal name for all malicious DLLs is dll_sc_launcher.dll -- "DLL shellcode launcher." The attackers are not even being subtle in their own build artifacts.

We identified two sideloading vectors across the nine samples:

Vector	File Replaced	Export Pattern	Samples
.NET hostfxr	hostfxr.dll	`hostfxr_*` functions	4 variants
Windows CLIP	clipsp.dll	`Clip*` functions (ClipCallServer, ClipOpen, ClipClose)	1 variant

The clipsp.dll variant targets Windows Client License Service Provider -- a completely separate sideloading chain built on the same day as hostfxr v3 (December 16, 2025). This parallel development of multiple sideloading vectors indicates the operators are actively diversifying their execution paths, likely to maintain access if one vector gets detected and blocked.

The Encryption: Dictionary Words as Camouflage

Each trojanized DLL carries a ~950KB encrypted blob in its .rdata section. The decryption routine is custom but not complex:

The first byte of the encrypted buffer serves as a seed value
Each subsequent byte is decrypted via a byte-wise subtraction loop
The decryption key is derived from the lowercase ASCII string crossdeviceservice.exe -- the name of the host executable
For each byte, the routine subtracts a value composed of the seed, the current loop index, and the corresponding key byte, with the key cycling at its null terminator
An additional 55-hour time window check prevents decryption outside the expected execution window

That last detail is an anti-sandbox trick. Most automated sandbox runs complete in 5-15 minutes. If the malware checks the system clock and determines it is not within a 55-hour window relative to some baseline, it refuses to decrypt the payload. The sandbox sees nothing. The analyst sees nothing. The malware sits inert until real deployment.

But the most creative evasion technique is the dictionary padding. Random English words are embedded alongside the encrypted shellcode:

accordion, balaclava, calculator, precipitation,
psychiatrist, skullduggery, overclocking

These words serve a single purpose: entropy dilution. Encrypted data has high entropy (randomness), and many EDR products flag PE sections with entropy above a threshold as suspicious. By mixing in recognizable English words, the operators drag the overall section entropy down from near-theoretical maximum to a level that passes static analysis heuristics. The encrypted blob still registers at 7.51 entropy -- high, but no longer an automatic red flag when blended with plaintext strings.

The C2: Hiding in Plain DNS

This is the detail that elevates this campaign from "competent cybercrime" to "genuinely sophisticated." The A0Backdoor does not make HTTP callbacks. It does not connect to a hardcoded IP. It does not use a domain generation algorithm that resolves to attacker infrastructure. Instead, it communicates entirely through DNS MX record queries.

[A0Backdoor on victim machine]
        |
        | DNS MX query: <encoded_metadata>.fsdgh[.]com
        | (sent to 8.8.8.8 or 1.1.1.1)
        |
        v
[Google/Cloudflare public DNS resolvers]
        |
        | Recursive lookup to authoritative NS for fsdgh[.]com
        | (ns1.fsdgh[.]com / ns2.fsdgh[.]com -- attacker-controlled)
        |
        v
[Attacker's nameserver receives query, extracts encoded data]
        |
        | Returns commands encoded in MX record responses
        |
        v
[A0Backdoor receives MX response, executes commands]

This is covert channel design at its best. Here is why it works:

DNS to 8.8.8.8 and 1.1.1.1 is universally whitelisted. Every corporate network allows DNS queries to Google and Cloudflare. Blocking them would break the internet.
MX queries look like email infrastructure lookups. A network monitoring tool seeing MX queries thinks "someone is checking mail routing." It does not think "C2 channel."
No direct connection to attacker infrastructure. The victim machine never touches an attacker-controlled IP. The DNS query travels through Google or Cloudflare's recursive resolver, which then contacts the attacker's authoritative nameserver. Firewall logs show traffic to 8.8.8.8 -- nothing actionable.
The data channel is in the subdomain itself. Encoded victim metadata travels in the subdomain portion of the query (<encoded_data>.fsdgh[.]com), meaning the data exfiltration happens in the DNS query, not the response.

C2 Indicator	Value
Domain	fsdgh[.]com
Registrar	Realtime Register B.V. (Netherlands)
Created	2026-02-04 (34 days before MalwareBazaar upload)
NS1	ns1.fsdgh[.]com (no glue records, unresolvable)
NS2	ns2.fsdgh[.]com (no glue records, unresolvable)
DNSSEC	Unsigned
Protocol	DNS MX tunneling via public resolvers
Current Status	Registered but NS offline

The nameservers are self-referential (ns1/ns2.fsdgh.com) with no glue records at the registry level, meaning they currently resolve to nothing. Either the infrastructure has been deliberately taken offline, or the operators are staging for the next phase.

The Certificate: Five Months of Stockpiling

The Authenticode signature on all nine samples traces back to a single Extended Validation code signing certificate:

Field	Value
Subject CN	MULTIMEDIOS CORDILLERANOS SRL
Country	Argentina
Province	San Juan
Tax ID (CUIT)	30-71069624-8
Issuer	SSL.com EV Code Signing Intermediate CA RSA R3
Valid From	2025-07-21
Valid To	2026-07-21
Thumbprint (SHA-256)	`f16c37e18db8c324dfe9a8922361610a7d4bf5b723ca7bd8c724819a6cf417d2`
Status	REVOKED

EV code signing certificates are the gold standard of software trust. Obtaining one requires physical verification of the organization, government-issued identification, and a call-back to a verified phone number. These are not self-signed certificates you generate in five minutes. Someone either compromised Multimedios Cordilleranos SRL -- a real media company in San Juan, Argentina -- or fabricated documentation convincing enough to pass SSL.com's verification process.

The timeline is telling: the certificate was issued July 21, 2025. The first signed malware sample appeared December 9, 2025. That is a five-month gap between acquisition and first use. The operators stockpiled the certificate, waiting until their tooling was ready before burning it.

During the active campaign window, this certificate was fully valid and trusted. Windows SmartScreen would have waved these binaries through. EDR products that use code signing as a trust signal would have scored them as low risk. The certificate has since been revoked by SSL.com, but the damage window -- from first signing in December through revocation -- gave the operators months of trusted execution.

The Build Pipeline: Four Iterations in Nine Days

Authenticode timestamps across all nine samples reveal a rapid development cycle that leaked significant operational security details:

Date	Time (UTC)	Event
2025-07-21	17:34	EV certificate issued by SSL.com
2025-12-09	15:48	hostfxr.dll v1 compiled and signed
2025-12-09	15:50	MSI v1 packaged and signed (+2 min)
2025-12-11	16:41	hostfxr.dll v2 compiled and signed
2025-12-11	16:44	MSI v2 packaged and signed (+3 min)
2025-12-16	15:29	hostfxr.dll v3 compiled and signed
2025-12-16	15:32	MSI v3 packaged and signed (+3 min)
2025-12-16	15:42	clipsp.dll variant signed (+10 min)
2025-12-17	14:50	hostfxr.dll v4 signed (new imphash)
2025-12-17	14:53	MSI v4 packaged and signed (+3 min)
2026-02-04	17:29	fsdgh[.]com registered
2026-03-10	10:56	All 9 samples uploaded to MalwareBazaar

Several things jump out:

The 2-3 minute gap between DLL signing and MSI packaging is consistent across all four builds. This is an automated build pipeline -- compile the DLL, sign it, drop it into the MSI template, sign the MSI. The consistency eliminates manual intervention.

The imphash changes between v3 and v4. Three of the four hostfxr.dll variants share imphash cb24c83e9e0f68a811d65891b8e7dc53. The fourth (December 17) has a different imphash (8f1fd2927973be754986ef34afeba09d), indicating the source code was modified between December 16 and 17. Given that the MSI template and clean files remained identical, this confirms a modular pipeline where only the malicious DLL is swapped between builds.

All four MSIs share identical ProductCode, UpgradeCode, and version strings. The only file that changes is the trojanized hostfxr.dll. New encrypted shellcode payloads are compiled and inserted into the same MSI template. This is production-grade malware engineering.

Attack Chain

[Email Bombing / Microsoft Teams Vishing]
         |
         v
[Victim grants Quick Assist remote access]
         |
         v
[Update.msi deployed via Microsoft Cloud Storage]
         |
         v
[MSI installs to %LocalAppData%\Microsoft\CrossDevice Share\25017.203.3370\]
    |-- CrossDeviceService.exe  (legitimate .NET 9 apphost)
    |-- CrossDeviceService.dll  (legitimate .NET assembly)
    |-- hostfxr.dll             (TROJANIZED - dll_sc_launcher.dll)
    |-- hostpolicy.dll          (legitimate .NET hosting)
         |
         v
[CrossDeviceService.exe loads hostfxr.dll via .NET init sequence]
         |
         v
[hostfxr.dll decrypts ~950KB shellcode from .rdata]
[Key: "crossdeviceservice.exe" + seed byte + positional index]
[Anti-sandbox: 55-hour time window, QEMU detection, IsDebuggerPresent]
         |
         v
[A0Backdoor shellcode executes in memory]
         |
         v
[DNS MX queries to <encoded>.fsdgh[.]com via 8.8.8.8 / 1.1.1.1]
[Metadata encoded in high-entropy subdomains]
[Commands returned in MX record responses]
         |
         v
[Lateral movement --> Ransomware deployment (Black Basta / Cactus)]

What We Found vs. What Was Known

BlueVoyant published initial reporting on the A0Backdoor family and its connection to Storm-1811. Our analysis extends their findings substantially:

Aspect	Prior Reporting (BlueVoyant)	Our Analysis
Samples analyzed	2 hashes mentioned	9 samples fully analyzed (4 MSI + 5 DLL)
Build iterations	Not documented	4 distinct builds reconstructed (Dec 9-17)
Sideloading vectors	hostfxr.dll only	hostfxr.dll (4 variants) + clipsp.dll (1 variant)
Certificate status	Active at time of report	Now REVOKED by SSL.com
Imphash clustering	Not documented	2 distinct imphash clusters, code change between v3/v4
Encrypted payload detail	"Custom byte-wise decryption"	~950KB blob, entropy 7.51, dictionary word padding technique
Build pipeline analysis	Not documented	Automated 2-3 min DLL-to-MSI cycle, Advanced Installer 19.9
C2 domain status	fsdgh.com reported as active	NS servers offline, no glue records

Anti-Analysis Techniques

The operators layer multiple evasion mechanisms, each targeting a different class of defender:

Technique	Target Defender	Implementation
EV code signing	SmartScreen, EDR trust chains	Revoked cert from Multimedios Cordilleranos SRL
55-hour time window	Automated sandboxes	Decryption refuses to proceed outside window
QEMU artifact detection	VM-based analysis	Checks for QEMU hardware strings
IsDebuggerPresent	Manual reversing	Standard anti-debug API
Dictionary word padding	Static entropy analysis	English words dilute section entropy below alert threshold
Runtime-only decryption	Disk forensics	Payload never exists in plaintext on disk
Heavy thread pool usage	Behavioral analysis	CreateThread, CreateThreadpoolTimer, CreateThreadpoolWait
Legitimate sideload host	Application whitelisting	Real Microsoft binary loads the malicious DLL

Indicators of Compromise

Network Indicators

# C2 Domain (DNS MX tunneling)
fsdgh[.]com

# C2 DNS pattern
*[.]fsdgh[.]com (MX queries via 8[.]8[.]8[.]8 and 1[.]1[.]1[.]1)

File Indicators -- MSI Installers

# MSI v1 - Update.msi (2025-12-09)
SHA-256: 7a1914bdc09b3f4cb6c64d3ff13585e52cb1e61acb96b798f811674a67f528d3

# MSI v2 - Update (2).msi (2025-12-11)
SHA-256: 1ec97383327393c772d3664b126150431617a4882b5e0b20b0cb240fdbf0eab1

# MSI v3 - Update (4).msi (2025-12-16)
SHA-256: 0c99481dcacda99014e1eeef2e12de3db44b5db9879ce33204d3c65469e969ff

# MSI v4 - Update (3).msi (2025-12-17)
SHA-256: a68683df0f2f8dd594d5c1554f62a2fd60ac42f130c75c1a12b6c99e445649fa

File Indicators -- Trojanized DLLs

# hostfxr.dll v1 (2025-12-09) -- imphash: cb24c83e9e0f68a811d65891b8e7dc53
SHA-256: 3da98d2e328c4878eb3c43ab560dda53370b87bbaa900253e5e871db457bb239

# hostfxr.dll v2 (2025-12-11) -- imphash: cb24c83e9e0f68a811d65891b8e7dc53
SHA-256: d618cbee8607403c41f3c5528c4998258d29f5a06461de3e47e09b5e67c16c39

# hostfxr.dll v3 (2025-12-16) -- imphash: cb24c83e9e0f68a811d65891b8e7dc53
SHA-256: 26db06a2319c09918225e59c404448d92fe31262834d70090e941093e6bb650a

# hostfxr.dll v4 (2025-12-17) -- imphash: 8f1fd2927973be754986ef34afeba09d
SHA-256: 77d916998e9e9b5c248b464d83ec199dec6ad56b8c12e53f3d60568975b8580d

# clipsp.dll variant (2025-12-16) -- imphash: 338888d33faf3d11abed4461126e3456
SHA-256: b6017c2f4fa83c28bcee7ec80e7c06f67b02835b61fa51a21cc5b6915352830c

File Indicators -- Clean Sideloading Components

# CrossDeviceService.exe (legitimate .NET 9 apphost)
SHA-256: 0a03fe00baf9381c31144ff6bc937036585b991e25e9c3ff4eb1581ddab84a4f

# CrossDeviceService.dll (legitimate .NET assembly)
SHA-256: 3bbaa1fe8f8698966a182f8636d7e3b882ebf95429eebcbf1fb35a3c0f6245ad

# hostpolicy.dll (legitimate .NET hosting)
SHA-256: b602ce56d1e017d51a4542530db02087fd7f0a1218f4bbd4e35cae8b82a3c734

Certificate Indicators

# EV Code Signing Certificate (REVOKED)
Thumbprint (SHA-256): f16c37e18db8c324dfe9a8922361610a7d4bf5b723ca7bd8c724819a6cf417d2
Serial:               2F2E62C3A8A3A4B85C44D3DF84D6D41A
Subject CN:           MULTIMEDIOS CORDILLERANOS SRL
Issuer:               SSL.com EV Code Signing Intermediate CA RSA R3

Behavioral Indicators

# Install path
%LocalAppData%\Microsoft\CrossDevice Share\25017.203.3370\

# Internal DLL name (all variants)
dll_sc_launcher.dll

# MSI identifiers
ProductCode:  {298A183F-68CC-4B11-840F-66749C9DD8BB}
UpgradeCode:  {36A917B0-FC49-454C-83C3-8C35D88FAA2F}

# Fuzzy hashes (primary MSI)
SSDEEP: 49152:92SX7jizoL5laI3xBBkpu7+is6PhvIg6Wsl5q0hWrACxtFTSxKP8pIEmM:J0ssiYWsBQZHSCMDmM
TLSH:   T1CFE50122738BC626C55D02B0159AEB5E1139FDB34B3450E7B7E8392F98F44C26779B82

MITRE ATT&CK Mapping

Tactic	Technique	ID	Implementation
Initial Access	Phishing: Spearphishing via Service	T1566.003	Microsoft Teams social engineering
Execution	User Execution: Malicious File	T1204.002	Update.msi execution via Quick Assist
Execution	System Services: Windows Installer	T1218.007	MSI CustomAction type 1234 (SYSTEM context)
Persistence	Hijack Execution Flow: DLL Side-Loading	T1574.002	hostfxr.dll / clipsp.dll replacement
Defense Evasion	Subvert Trust Controls: Code Signing	T1553.002	EV certificate (Multimedios Cordilleranos SRL)
Defense Evasion	Obfuscated Files or Information	T1027	Encrypted shellcode + dictionary word padding
Defense Evasion	Virtualization/Sandbox Evasion	T1497.001	QEMU detection, 55-hour time window
Defense Evasion	Debugger Evasion	T1622	IsDebuggerPresent API check
Defense Evasion	Masquerading: Match Legitimate Name	T1036.005	"Microsoft Cross Device Add-in" branding
Command and Control	Application Layer Protocol: DNS	T1071.004	DNS MX-based C2 tunneling
Command and Control	Protocol Tunneling	T1572	Data encoded in DNS subdomain queries
Discovery	Process Discovery	T1057	Process enumeration
Discovery	System Language Discovery	T1614.001	Locale checks

Detection: YARA Rules

rule A0Backdoor_DLL_SC_Launcher {
    meta:
        author = "GHOST - Breakglass Intelligence"
        description = "Detects A0Backdoor DLL shellcode launcher (hostfxr.dll variant)"
        date = "2026-03-10"
        tlp = "TLP:CLEAR"
        severity = "CRITICAL"
        reference = "https://intel.breakglass.tech"
    strings:
        $internal_name = "dll_sc_launcher.dll" ascii
        $export1 = "hostfxr_main" ascii
        $export2 = "hostfxr_close" ascii
        $export3 = "hostfxr_initialize_for_runtime_config" ascii
        $cert_subject = "MULTIMEDIOS CORDILLERANOS SRL" ascii
        $cert_serial = { 2F 2E 62 C3 A8 A3 A4 B8 5C 44 D3 DF 84 D6 D4 1A }
    condition:
        uint16(0) == 0x5A4D and
        $internal_name and
        2 of ($export*) and
        ($cert_subject or $cert_serial)
}

rule A0Backdoor_MSI_Dropper {
    meta:
        author = "GHOST - Breakglass Intelligence"
        description = "Detects A0Backdoor MSI installer packages"
        date = "2026-03-10"
        tlp = "TLP:CLEAR"
        severity = "CRITICAL"
    strings:
        $msi_magic = { D0 CF 11 E0 A1 B1 1A E1 }
        $product = "Cross Device Add-in" wide ascii
        $manufacturer = "Microsoft 3rd Party Application Component" wide ascii
        $upgrade_code = "{36A917B0-FC49-454C-83C3-8C35D88FAA2F}" ascii
        $product_code = "{298A183F-68CC-4B11-840F-66749C9DD8BB}" ascii
        $cert = "MULTIMEDIOS CORDILLERANOS SRL" ascii
    condition:
        $msi_magic at 0 and
        $cert and
        2 of ($product, $manufacturer, $upgrade_code, $product_code)
}

rule A0Backdoor_Clipsp_Sideload {
    meta:
        author = "GHOST - Breakglass Intelligence"
        description = "Detects A0Backdoor clipsp.dll sideloading variant"
        date = "2026-03-10"
        tlp = "TLP:CLEAR"
        severity = "CRITICAL"
    strings:
        $internal = "dll_sc_launcher.dll" ascii
        $clip1 = "ClipCallServer" ascii
        $clip2 = "ClipOpen" ascii
        $clip3 = "ClipClose" ascii
        $clip4 = "ClipGetLicenseData" ascii
        $cert = "MULTIMEDIOS CORDILLERANOS SRL" ascii
    condition:
        uint16(0) == 0x5A4D and
        $internal and
        3 of ($clip*) and
        $cert
}

rule A0Backdoor_Generic_SC_Launcher {
    meta:
        author = "GHOST - Breakglass Intelligence"
        description = "Generic detection for A0Backdoor shellcode launcher via dictionary padding signature"
        date = "2026-03-10"
        tlp = "TLP:CLEAR"
        severity = "HIGH"
    strings:
        $internal = "dll_sc_launcher.dll" ascii
        $pad1 = "accordion" ascii
        $pad2 = "balaclava" ascii
        $pad3 = "calculator" ascii
        $pad4 = "precipitation" ascii
        $pad5 = "skullduggery" ascii
        $pad6 = "psychiatrist" ascii
    condition:
        uint16(0) == 0x5A4D and
        $internal and
        3 of ($pad*)
}

Hunting Queries

Endpoint -- search for install directory:

file_path:*\\Microsoft\\CrossDevice Share\\25017.203.3370\\*

Endpoint -- dll_sc_launcher.dll in loaded modules:

loaded_module_name:"dll_sc_launcher.dll" OR
loaded_module_internal_name:"dll_sc_launcher.dll"

Network -- DNS MX queries to unusual domains from endpoints:

dns_query_type:"MX" AND
NOT dns_query:(*.google.com OR *.microsoft.com OR *.outlook.com) AND
source_type:"endpoint"

Network -- high-entropy subdomain queries (DNS tunneling indicator):

dns_query_entropy:>3.5 AND
dns_query:*fsdgh.com

Certificate -- Authenticode signatures from revoked cert:

authenticode_thumbprint:"f16c37e18db8c324dfe9a8922361610a7d4bf5b723ca7bd8c724819a6cf417d2" OR
authenticode_serial:"2F2E62C3A8A3A4B85C44D3DF84D6D41A" OR
authenticode_subject:"MULTIMEDIOS CORDILLERANOS SRL"

Recommended Actions

Immediate (24-48 hours)

Block fsdgh[.]com at the DNS resolver level -- not just the IP. Block the domain itself so MX queries never leave your network.
Add all 9 SHA-256 hashes to EDR blocklists (MSIs and DLLs).
Block the certificate thumbprint (f16c37e...6cf417d2) in code signing policies and application control rules.
Hunt for the install path %LocalAppData%\Microsoft\CrossDevice Share\25017.203.3370\ on all endpoints.
Hunt for dll_sc_launcher.dll in loaded module telemetry.
Alert on DNS MX queries to unknown or low-reputation domains originating from endpoint IPs (not mail servers).

Short-term (1-2 weeks)

Implement DNS logging with entropy analysis -- subdomain entropy above 3.5 bits/character combined with MX query type is a strong tunneling indicator.
Review Microsoft Teams external communication policies -- restrict external users from initiating calls or chats with internal users.
Audit Quick Assist usage -- restrict Quick Assist to authorized IT staff via Group Policy. Consider blocking it entirely and using a managed remote support tool.
Deploy the YARA rules above to mail gateways, file share scanners, and endpoint agents.
Check MSI installation logs for packages signed by non-Microsoft certificates installing to Microsoft paths.

Medium-term (1-3 months)

Implement code signing certificate allowlisting for binaries in system and Microsoft application directories.
Deploy DLL sideloading detection via Sysmon EventID 7 (Image Load) -- flag unsigned or non-Microsoft DLLs loaded by Microsoft-signed executables.
Build DNS tunneling detection capabilities -- monitor for anomalous MX query volumes, high-entropy subdomains, and DNS queries to newly registered domains from endpoint IPs.
Review EV certificate trust in your environment -- consider whether you need to trust all EV certificates or can restrict to a subset of known CAs.

Attribution

We attribute this activity to Blitz Brigantine (also tracked as Storm-1811 by Microsoft and STAC5777 by Sophos) with HIGH confidence based on:

Exact TTP match -- DLL sideloading via CrossDeviceService + hostfxr.dll is documented as exclusive A0Backdoor tooling for this group
Same certificate -- the Multimedios Cordilleranos SRL certificate was explicitly named in BlueVoyant's A0Backdoor reporting
Same delivery chain -- MSI installers masquerading as Microsoft updates, delivered via Teams vishing + Quick Assist
Same C2 protocol -- DNS MX-based tunneling via public resolvers
Consistent targeting -- finance and healthcare sectors across US, UK, Germany, Canada, Australia, France, Japan, South Korea, Singapore, and Switzerland

Blitz Brigantine operates as an affiliate for both Black Basta and Cactus ransomware operations. The A0Backdoor is the precursor: once persistent access is established, the operators conduct reconnaissance and lateral movement before handing off to the ransomware deployment team. If you find this backdoor in your environment, assume the clock is already ticking.

References

BlueVoyant, "New A0Backdoor Linked to Teams Impersonation and Quick Assist Social Engineering" (2026)
BleepingComputer, "Microsoft Teams phishing targets employees with A0Backdoor malware" (2026)
MalwareBazaar samples uploaded by JAMESWT_WT (2026-03-10)
CAPESandbox: https://www.capesandbox.com/analysis/56928/
Triage: https://tria.ge/reports/260310-m1tstsht3s/
CERT-PL MWDB: https://mwdb.cert.pl/sample/7a1914bdc09b3f4cb6c64d3ff13585e52cb1e61acb96b798f811674a67f528d3/

Published by Breakglass Intelligence. Investigation conducted 2026-03-10. 9 samples analyzed. 4 build iterations reconstructed. 2 sideloading vectors identified. 1 revoked EV certificate. DNS MX tunneling C2 confirmed. Classification: TLP:CLEAR