New A0Backdoor Linked to Teams Impersonation and Quick Assist Social Engineering

What Happened?

BlueVoyant Security Operations Center (SOC) and Threat Fusion Cell (TFC) continue to track an activity cluster that uses email bombing and IT-support impersonation over Microsoft Teams to obtain Quick Assist access, then pivot to a deeper attack. This research shows that once on the victim’s host, the actors sideload a malicious DLL to deliver a new backdoor BlueVoyant has dubbed the A0Backdoor. 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. Taken together, these traits mirror a threat group TFC tracks as Blitz Brigantine (a.k.a. Storm-1811, STAC5777) and their Black Basta-linked social-engineering playbook while showing an ongoing tooling refresh designed to blend into enterprise infrastructure and bypass controls tuned to prior patterns. 

This widely reported attack begins when the threat group, posing as information technology staff, targets users within an organization by overloading their emails with spam. The adversary then contacts the impacted user via Microsoft Teams and informs the user about the abnormal behavior, offering to assist them. They request remote access to the device using the built-in Windows remote assistance application Quick Assist. Once on the device, the threat group attempts to load their own proprietary tooling in order to maintain access to the compromised device. 

During investigation of two separate instances, BlueVoyant researchers observed the threat group’s software was digitally signed MSI Packages. Researchers found at least some of these MSI packages were hosted on Microsoft cloud storage tied to personal accounts (my[.]microsoftpersonalcontent[.]com) and delivered via tokenized download links, complicating retroactive acquisition. Various other MSI packages and binaries were found signed with one of at least three different certificates dating back to July 2025, indicating the threat group has been using their proprietary tooling for a while. 

BlueVoyant found both MSI packages from the two separate incidents contained software packages masquerading as Microsoft Teams and CrossDeviceService. 

The MSI packages contained instructions to drop the software packages into the following paths:

• CrossDevice Service - C:\Users\<User>\AppData\Local\Microsoft\CrossDevice Share\25017.203.3370
• Microsoft Teams - C:\Users\<User>\AppData\Local\Microsoft\TeamsPhoneAddins\3.1.1.15\

MSI Package Analysis

BlueVoyant researchers dug into a sample named Update.msi (SHA256: 0c99481dcacda99014e1eeef2e12de3db44b5db9879ce33204d3c65469e969ff) which contained the files depicted in the image above. The DLLs contained within the MSI file were signed by Microsoft except for the file named hostfxr.dll, normally a Microsoft-signed .NET hosting component; however, here it was replaced with a malicious lookalike signed with the same non-Microsoft certificate as the MSI package, MULTIMEDIOS CORDILLERANOS SRL. This pattern repeated across multiple samples observed for this time period.

Initial analysis of hostfxr.dll indicated it contained compressed or encrypted data within its .data section. Analysts also tallied numerous calls to junk functions, which can overwhelm the debugging environment and significantly slow analysis; testing shows this occasionally caused debugger instability.

Like many malware loaders, the primary purpose of hostfxr.dll was to decrypt the data stored in its .data section into a newly allocated memory region, mark that memory as writable and executable, and then transfer execution to it. BlueVoyant researchers also noted that, at runtime, hostfxr.dll makes extensive use of ‘CreateThread’ calls. This behavior is intended to hinder dynamic analysis. Under normal execution without a debugger attached, the excessive thread creation does not significantly impact runtime behavior. However, when a debugger is attached, the large number of threads can overwhelm the debugging environment, significantly slowing analysis and, in some cases, causing the debugger to crash. 

The DLL hostfxr.dll decrypts the embedded bytes using a custom byte-wise decryption loop over an encrypted buffer. The first byte of the buffer is used as a seed value, while the remaining bytes are decrypted in place using a repeating key derived from the ASCII string crossdeviceservice.exe (the name of the executable but in lower case).

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 when its null terminator is reached. After fully decrypting the payload, hostfxr.dll invokes the code stored in the newly allocated memory region containing the decrypted payload. BlueVoyant researchers discovered the decrypted payload resembled shellcode.

Shellcode Breakdown

Upon execution, the shellcode begins by decrypting additional embedded data that contains its core functionality. This same decryption routine is applied repeatedly throughout the shellcode, ensuring key strings are not revealed until runtime. Performing decryption at runtime allows the shellcode to remain concealed and significantly complicates static analysis. 

After the shellcode decrypts the main function, the shellcode begins by decrypting a hard-coded string, “globalscope0,” and appending it to the result of the ‘GetModuleFileNameW’ API call, which retrieves the name of the binary executing the shellcode, in this case, CrossDeviceService.exe. This combined value is then passed to the ‘CreateMutexW’ API.

The purpose of this mutex is to ensure that the shellcode does not execute multiple times simultaneously. The shellcode verifies this condition by invoking ‘GetLastError’ and evaluating the returned value; if the result indicates that the mutex already exists, execution follows a conditional jump that terminates the shellcode. 

If the shellcode determines that no other instances are running, it continues with execution. 

Next, the shellcode appears to normalize the current time by calling ‘GetSystemTimeAsFileTime’, which returns a 64-bit count of 100-nanosecond intervals since 1 January 1601 (the Windows FILETIME epoch). In this sample, it then subtracts the constant equivalent to the FILETIME-to-Unix offset (0x19DB1DED53E8000) and then divides by 0x989680 (10,000,000) to convert from 100-nanosecond ticks to whole seconds. At this stage, the shellcode has the current Unix time as a 64-bit integer. 

It then applies what appears to be a “timeslot” formula in seconds. In this build, the code subtracts a baseline value of 0x018275 (98,933) and divides the result by a fixed period of 0x030D40 (200,000 seconds, or approximately 55 hours) to yield an integer slot value. Across a single period, that slot remains stable and is subsequently mixed into other hashing and decryption calculations. Executions outside the intended window produce a different slot and, by extension, different calculated results. These constants may vary across samples.

Although the arithmetic largely uses 64-bit values, the analyzed sample also contains 32-bit instructions that affect the lower dword of intermediate results. The practical effect is a comparatively small working slot value (for example, 0x227D or 0x227E in our tests) that conveniently fits in four bytes. Whether it is purely for storage/convenience or part of an obfuscation strategy is unclear, but the resulting 4-byte slot is then incorporated into the data that is hashed during key derivation.

When execution occurs outside the intended time window, the computed time-slot changes and the subsequent keying material differs, which prevents decryption of the embedded payload. In testing with this sample, slot values advanced roughly every ~55 hours (the configured period), but it was not determined whether the baseline is anchored to build time or another reference. The contants and anchoring mechanism may vary across builds. 

After computing the time, the shellcode decrypts and resolves the API ‘GetCommandLineW’ in order to process the command line. 

During analysis, BlueVoyant uncovered that the command line ends with two spaces followed by a non-breaking space (U+00A0). In common UI views this appears as a normal space, but the code point is preserved and incorporated into the key material. When analyzing the properties of the process ‘CrossDeviceService.exe’ at runtime, the trailing byte is hidden and is masqueraded as a space.

However, this ‘0xA0’ value is intentionally preserved and incorporated into the construction of a key that is subsequently hashed and used to decrypt an AES-encrypted blob.

After obtaining the value stored at the end of the command-line string, the shellcode attempts to determine if it is running in a sandbox or virtual environment. First, the shellcode queries the firmware table of the virtual machine using the API ‘GetSystemFirmwareTable’. Once obtained, the shellcode searches the results for the string ‘QEMU’. If identified, the shellcode modifies the key that’s meant to be hashed. The shellcode also attempts to query for other known sandbox values. 

Once these checks pass, the shellcode generates the key material described earlier and initializes the hashing process. It first calls ‘CryptCreateHash’, supplying the algorithm identifier 0x800C, which corresponds to the SHA-256 hashing algorithm. This instructs the cryptographic provider to hash subsequent data using SHA-256. The shellcode then hashes the generated values by invoking ‘CryptHashData’. The resulting hash output is subsequently used as the decryption key to decrypt the embedded payload within the shellcode. 

The shellcode includes logic to decrypt its embedded payload using AES in CBC mode. After generating the hash, which is used as the decryption key, the shellcode locates the encrypted data and copies it into a newly allocated memory region that is created with execute and write permissions. The shellcode then retrieves the initialization vector (IV), which is stored 16 bytes immediately preceding the encrypted data. The encrypted data is then subsequently decrypted using the API ‘CryptDecrypt’.

After decrypting the payload, the shellcode locates the export named ‘set_error_writer’ and overwrites the associated function code with a jump that redirects execution to the entry point of the newly decrypted A0 Backdoor. 

A0Backdoor - The Payload

Similar to the shellcode component, the A0Backdoor employs runtime decryption to conceal its primary logic, deliberately obscuring core functionality and impeding direct static analysis. Upon execution, the backdoor allocates a new memory region and copies its own code into this newly allocated space. While this self-copying behavior does not appear to directly contribute to the backdoor’s functional capabilities, it is noteworthy. 

After relocating itself in memory, the backdoor decrypts its core routines using a hard-coded XOR key. This process includes decrypting its embedded command-and-control (C2) server configuration. 

Once decrypted, the backdoor proceeds to fingerprint the compromised system by collecting host-specific information. This is accomplished through Windows API calls such as ‘DeviceIoControl’, ‘GetUserNameExW’, and ‘GetComputerNameW’, enabling the malware to uniquely identify the infected device before initiating further communication with its C2 infrastructure. 

The A0Backdoor establishes communication with its C2 infrastructure using a technique known as DNS tunnelling, specifically via a covert DNS channel. Rather than opening direct sessions to attacker-controlled infrastructure, the backdoor issues DNS queries to a public resolver (e.g., 1.1.1[.]1). The resolver then queries the attacker-controlled authoritative name servers on the host’s behalf. As a result, the endpoint only contacts the public resolver, avoiding direct connections to the C2 while still exchanging commands over DNS.