Microsoft Teams impersonation and social engineering tactics are being used in an ongoing campaign to deliver a stealthy malware payload known as A0Backdoor.
Researchers at BlueVoyant report that the operation combines social engineering techniques, malicious installers, and covert command-and-control (C2) communications to gain persistent access within targeted networks.
“The malware’s loader exhibits anti-sandbox evasion, and the campaign’s command-and-control appears to have pivoted to a covert DNS mail exchange-based channel that confines endpoint traffic to trusted recursive resolvers,” said the researchers.
Inside the Teams Impersonation Attack Chain
The activity appears to primarily target organizations in sectors such as finance and healthcare and closely aligns with tactics previously associated with the threat actor cluster Blitz Brigantine, also tracked as Storm-1811.
This group is linked to ransomware operations such as Black Basta and Cactus and is known for using social engineering to gain initial access before deploying malware or launching follow-on ransomware attacks.
In this campaign, attackers first obtain access through social engineering techniques that impersonate internal IT personnel.
After convincing victims to grant access — often through remote support tools such as Quick Assist — the attackers deploy malicious MSI installer packages designed to appear as legitimate Teams-related software updates.
These installers frequently use names such as Update.msi or UpdateFX.msi and are crafted to blend into normal enterprise workflows.
Malware Delivered Through DLL Sideloading
Once executed, the installers drop files into directories commonly associated with Microsoft services, including locations tied to Teams add-ins or Cross Device functionality.
The packages typically include a mix of legitimate Microsoft-signed binaries alongside attacker-controlled DLL files.
This combination enables a technique known as DLL sideloading, where a trusted application loads a malicious library placed in the same directory, allowing attacker code to execute while appearing to originate from a legitimate Microsoft component.
At the center of the infection chain is a malicious DLL named hostfxr.dll, which impersonates a legitimate Microsoft .NET hosting component.
Instead of performing its expected function, this DLL acts as a loader responsible for decrypting and executing hidden malware embedded within the file.
The malicious version is designed to closely resemble the legitimate component in order to evade suspicion while being loaded by a trusted executable.
Loader Uses Obfuscation and Anti-Analysis Techniques
The loader incorporates several anti-analysis techniques intended to slow or disrupt security investigations.
One example involves repeatedly invoking the Windows CreateThread API to generate a large number of threads.
While this behavior has little effect during normal execution, it can overwhelm debugging tools and slow down dynamic analysis, sometimes even causing debugging environments to crash.
The malicious DLL also contains encrypted payload data embedded in its .data section.
During execution, the loader decrypts this data using a custom algorithm that derives its key from the ASCII string crossdeviceservice.exe, which corresponds to the name of the legitimate executable used in the sideloading chain.
Once decrypted, the payload is written to memory and executed as shellcode.
This shellcode introduces additional layers of obfuscation and control logic.
Many of its strings and functional components remain encrypted until runtime, preventing analysts from identifying its behavior through static analysis.
The shellcode first creates a mutex tied to the executing binary to ensure that only one instance of the malware runs on a system at any given time.
The malware also incorporates a time-based execution mechanism.
It calculates the current system time and divides it into execution windows lasting roughly 55 hours.
If the malware runs outside of the expected time slot, the cryptographic values used to decrypt the payload change, preventing the embedded malware from successfully executing.
This technique helps reduce the likelihood that researchers or automated analysis systems will trigger the payload.
In addition, the shellcode attempts to detect sandbox or virtualized environments.
It queries system firmware tables and searches for indicators such as QEMU, a virtualization platform used in analysis environments.
If such indicators are found, the malware modifies its key generation logic, preventing successful payload decryption and effectively hiding its true functionality.
Once these checks are completed, the shellcode decrypts and executes the final payload, A0Backdoor.
A0Backdoor Uses DNS Tunneling for Command and Control
The A0Backdoor itself is designed to operate stealthily after execution. Like earlier stages of the infection chain, it decrypts its core functionality only in memory, helping to conceal its behavior from traditional security scanning.
Once active, the backdoor begins fingerprinting the compromised system by collecting identifying information using Windows APIs such as GetComputerNameW, GetUserNameExW, and DeviceIoControl.
This data allows the attackers to uniquely identify infected systems.
Instead of establishing direct connections to attacker infrastructure, the malware uses a covert DNS tunneling technique for command-and-control (C2) communication.
The infected host sends specially crafted DNS queries containing encoded system metadata to public DNS resolvers.
Those resolvers then query attacker-controlled authoritative DNS servers on behalf of the infected system.
The attackers respond with DNS MX records that contain encoded command data embedded within the hostname field. The malware extracts and decodes this data to receive instructions from the operators.
Because the infected endpoint only communicates with trusted public DNS resolvers rather than directly contacting attacker infrastructure, the activity can blend into normal network traffic.
This indirect communication method makes the C2 channel harder for defenders to detect.
How Organizations Can Reduce Attack Surface
Organizations can reduce the risk from these campaigns by strengthening security controls across endpoints, collaboration platforms, and network monitoring.
- Restrict and monitor remote-support tools by limiting Quick Assist and similar utilities to authorized help desk personnel, requiring authentication and session logging, and alerting on remote sessions initiated from unknown or external sources.
- Implement application allow-listing to prevent unauthorized executables or DLLs — especially those in user-writable directories like AppData — from running.
- Monitor for DLL sideloading and suspicious file activity by detecting Microsoft executables loading unexpected or unsigned libraries and inspecting directories such as Teams add-ins or Microsoft-related AppData paths.
- Strengthen collaboration platform security by restricting external Microsoft Teams communications where possible, enforcing conditional access policies, and requiring verification procedures before users accept remote support requests.
- Improve DNS security monitoring by analyzing logs for high-entropy subdomains, unusual MX record queries, or excessive unique DNS requests that could indicate DNS tunneling activity.
- Use EDR tools to identify suspicious memory execution, process injection, unusual thread creation, and other behaviors associated with malware loaders and shellcode execution.
- Regularly test incident response plans and use attack simulation tools.
Together, these measures help organizations strengthen operational resilience, detect suspicious activity earlier, and limit the potential blast radius if an attacker gains access.
This campaign reflects a broader pattern in which attackers combine social engineering with legitimate enterprise tools to gain initial access.
By impersonating IT staff through collaboration platforms like Microsoft Teams and using built-in remote support utilities, attackers can bypass defenses that focus primarily on detecting malicious software.
The use of DNS-based command-and-control communication also shows how attackers are adapting their infrastructure to blend into normal network activity rather than relying on direct connections to suspicious servers.
These tactics highlight the growing need for zero trust solutions, which require continuous verification of users and devices before access is granted.
