From Biography to Backdoor: Tracking a DoNot (APT-C-35) Intrusion Targeting Bangladesh Military Personnel

Key Findings

•    A targeted cyber-espionage operation against Bangladesh's military and defence establishment. 
•    Initial access: a spear-phished RTF weaponised as the biography of a Bangladesh Air Force officer. 
•    The RTF pulls a malicious VBA macro via remote template injection; server-side geofencing restricts delivery to victims in the target region. 
•    The macro injects architecture-aware shellcode into the host process through callback-based API abuse. 
•    Shellcode executes in chained XOR-encoded stages, each fetching and decoding the next from the same C2 domain under rotating file extensions (.ico, .mp3, .doc) to blend with normal traffic. 
•    The final stage drops a DLL implant that establishes scheduled-task persistence disguised as OneDrive telemetry, profiles the host, and beacons to a secondary C2 over HTTPS using AES-128-CBC.
•    The C2 protocol runs a two-phase handshake: the implant registers with encrypted host data (CPU, OS version, hostname, installed software), and the server gates payload delivery on that profile. 
•    By engaging the delivery endpoint directly, the team pulled a live second-stage DoNot module (ejtest.dll) from active C2 infrastructure. 
•    The module's hardcoded AES key material is byte-for-byte identical to keys documented in independent DoNot (APT-C-35) research.

Summary

The file was named after a real Bangladesh Air Force officer. The target who opened it thought they were reading a biography. What they executed was a geofenced, multi-stage implant that beaconed back to attacker infrastructure before they finished the first page.

The Howler Cell Threat Research Team identified and analyzed this campaign against Bangladeshi military and defence targets. The RTF uses remote template injection to fetch a VBA macro, with server-side geofencing restricting payload delivery to victims inside the target region.

Once the macro runs, it injects architecture-aware shellcode through callback-based API abuse. The shellcode moves through several XOR-encoded stages, each pulled from the same C2 domain under benign-looking file extensions. The final stage delivers a DLL implant that persists through a scheduled task masked as OneDrive telemetry, profiles the host, and beacons to a second C2 over AES-128-CBC encrypted HTTPS.

DoNot (APT-C-35) was still serving payloads when the team found them. By directly engaging the C2 delivery endpoint, the team retrieved a live second-stage DLL from active infrastructure, confirming this operation is not historical. The C2 is running. Victims are receiving follow-on modules now.

The retrieved module’s AES key material matches documented DoNot samples byte-for-byte. Combined with identical C2 URI paths, shared protocol parameters (mopd= and malp=), matching beacon formats, and infrastructure patterns consistent with tracked DoNot activity, the team attributes this campaign with high confidence to the DoNot group (APT-C-35).

Impact

Retrieval of a live second-stage module from active infrastructure confirms the C2 is serving real victims, not a dormant or test setup. The targeting of Bangladeshi defence personnel through tailored lures, combined with regional geofencing, points to a focused intelligence collection effort rather than opportunistic activity.

The cryptographic and infrastructure overlap with prior DoNot operations indicates a sustained, ongoing threat to government and military organizations across South Asia.

Attack Overview

Figure 1: Complete Attack Chain from Initial RTF Delivery to Victim Vetting and Conditional Payload Deployment

Attribution

We attribute this campaign with high confidence to the DoNot group (also tracked as APT-C-35), a threat actor widely assessed by multiple vendors as India-aligned, active since at least 2016, known for sustained cyber-espionage operations against government, military, and diplomatic targets across Pakistan, Bangladesh, Sri Lanka, and neighbouring countries.

The attribution is grounded in direct artifact overlap with previously documented DoNot operations. The DLL agent's hardcoded C2 URI paths are identical to those observed in a separate DoNot sample independently documented by industry threat intelligence teams in late 2025, where only the C2 domain differed:

• /ZxStpliGBsfdutMawer/sIOklbgrTYULKcsdGBZxsfetmw for beacon registration
• /ZxStpliGBsfdutMawer/lkhgBrPUyXbgIlErAStyilzsh/N1/SA for payload retrieval

The use of the mopd= POST parameter for transmitting encrypted system reconnaissance and the beacon data structure collecting CPU model, OS version, hostname, and installed software is consistent across both samples, confirming a shared codebase.

The strongest attribution evidence emerged from the second-stage module (ejtest.dll) retrieved directly from the active C2. Its hardcoded AES key (32 A3 D5 97 6E 5A BC F5 C4 68 A8 24 69 E5 C7 91) and IV (29 A9 B9 E9 E7 E5 E1 A3 A8 67 54 28 BC B7 A2 BE) are byte-for-byte identical to those documented in an independent industry analysis of a DoNot sample, providing a definitive cryptographic linkage across campaigns.

The coexistence of both ||| and ### beacon delimiter variants within the same attack chain, matching delimiter conventions observed in prior DoNot reporting, further confirms this is the same tooling family deployed at different stages.

The broader attack chain reinforces this attribution. The following techniques appear in public threat intelligence repositories as distinctive DoNot tradecraft patterns:

• • Multi-stage shellcode delivery using .ico and .mp3 file extensions to masquerade payloads from a common URL path
  • RTF template injection with a randomized /<path>/<filename>.php URL structure
  • Geofenced payload delivery serving clean templates to non-targets
  • VBA-based shellcode injection via the Internal_EnumUILanguages callback

Industry research has noted infrastructure and code-signing certificate overlap between DoNot and the Patchwork group (APT-Q-36), indicating a degree of resource sharing between the two actors. While the tooling in this campaign aligns with DoNot's known arsenal, defenders should be aware of this broader ecosystem when conducting infrastructure pivots.

Infrastructure Clustering

The investigation identified three C2 domains used across different stages of the attack chain:

• • greezupdto[.]info (RTF template injection and shellcode staging) resolving to 193[.]149[.]190[.]30
  • reggyupdated[.]info (Stage 4 DLL agent C2) resolving to 45[.]61[.]136[.]27
  • exessupdate[.]info (Stage 5 module C2) following the same .info TLD and misspelled-word naming convention
    

The first two domains resolve to infrastructure associated with BL Networks (AS399629).

Pivoting on the confirmed C2 addresses through passive DNS and reverse DNS analysis revealed 16 additional domains distributed across the 193[.]149[.]0[.]0/16,45[.]61[.]0[.]0/16, and 149[.]248[.]0[.]0/16 subnet ranges, with further hosts at scattered IPs. All resolutions were corroborated through passive DNS records and are listed in Table 1.

Two domains, rollededpack[.]info and programseeget[.]info, have since rotated to new hosting but their historical IPs place them within the same cluster. Cross-cluster linkage is further evidenced by the shared IP 91[.]195[.]240[.]123, which appears in the DNS history of rollededpack, programseeget, and getsupdated, with the related 91[.]195[.]240[.]12 surfacing for tiffyservics and altzserberin.

A hosted response page was observed with the text:

This does not look like a normal default hosting block page. It appears to be a custom fake Mod Security page, likely used to disguise C2 hosting or return controlled content when accessed directly.

The domain naming conventions reinforce the clustering:

• Deliberate misspellings: "greezupdto", "tiffyservics", "shadoworkz", "exessupdate"
• Recurring prefixes: "reggy" in reggyupdated and reggysolution, "program" in programgreedz and programseeget
• The "updated/updto/update" theme across greezupdto, reggyupdated, getsupdated, and exessupdate, and near-exclusive use of the .info TLD

The complete infrastructure map is presented in Table 1.

Table 1: Identified Infrastructure Cluster

Technical Analysis

The Howler Cell Threat Research Team initiated its investigation with a suspicious RTF file named Biography Air Vice Marshal Sitwat Nayeem.doc. The filename is crafted to impersonate a biographical document relating to a senior officer of the Bangladesh Air Force, suggesting a highly targeted spear-phishing campaign directed at individuals within the Bangladeshi military and defence establishment.

The use of a real military designation as a social engineering lure is consistent with South Asian APT operations that routinely leverage defence and government themes to entice high-value targets into opening weaponized documents. The lure document, upon opening, is shown in Figure 2.

Figure 2: Initial Lure document - Biography Air Vice Marshal Sitwat Nayeem.doc

Notably, the document presents a classic social engineering lure designed to trick the victim into enabling active content. The upper portion displays a fake "Protected View" banner with the Microsoft Office logo, instructing the user to click "Enable editing" followed by "Enable content". The garbled text in the lower half is the raw byte rendering of an embedded object that fails to display correctly, a characteristic artifact of weaponized RTF files containing binary payloads.

The RTF does not embed malicious macros directly. Instead, it uses remote template injection to fetch the malicious payload from an attacker-controlled server at runtime. This means the document itself contains no executable code or OLE macro objects, allowing it to evade static analysis tools and email gateway scanners. The actual payload delivery occurs only when the victim opens the document and follows the lure instructions.

Figure 3: Extracting Remote Template URL

As shown in Figure 3, dumping stream entry 522 from the RTF reveals a sequence of 60 unicode escape characters (\u104, \u116, \u116, \u112, ..) embedded within the \*\template destination. Decoding these values yields the complete remote template URL:

• hxxp[://]greezupdto[.]info/5IrzalAfHEUM9Tg6/5zbnrP5Dj2BLtwQm[.]php

This URL is where Microsoft Word fetches the external template when the victim opens the document. The use of unicode escape sequences to encode the URL is a deliberate obfuscation technique intended to evade static detection rules that scan for plaintext HTTP strings or hex-encoded URLs within RTF files.

Interestingly, requesting this URL directly through a browser or automated analysis tool returns a clean, benign Word template containing no macros or executable content.

The C2 server fingerprints incoming requests and selectively serves the weaponized template only to victims matching specific criteria, such as IP geolocation within Bangladesh or South Asia and a User-Agent string consistent with Microsoft Word. All other requests, including those from sandboxes, VPNs, and researchers, receive the harmless decoy. This server-side filtering ensures that the malicious template remains invisible to automated analysis pipelines and makes sample retrieval significantly more difficult for defenders.

Stage 1: Remote Template

The remote template, once served to a valid target, contains a VBA project with three macros: Document_Open, xmsttxruylzhq, and xyz. The Document_Open subroutine acts as the auto-execution trigger, firing immediately when the document is opened. Its logic is straightforward: it first wipes the visible document content by calling ActiveDocument.Content.Delete, then invokes the primary payload routine xmsttxruylzhq. The xyz subroutine is a decoy stub containing only a variable declaration, likely included to pad the macro listing or serve as a placeholder for future functionality (Figure 4 and Figure 5).

Figure 4: Document_Open subroutine

The core of the attack resides in xmsttxruylzhq method, which implements a classic shellcode injection technique entirely within VBA. The macro stores the shellcode in two separate byte arrays: scxddptpffdfv targeting 32-bit systems and kmmrwjafwaaxbb targeting 64-bit systems. A compile-time conditional selects the appropriate variant based on the architecture of the running Office process.

Figure 5: Determining Shellcode within VBA

The macro begins by declaring three Windows API functions through obfuscated aliases (see Figure 6 for snippet):

1. ZwAllocateVirtualMemory - to allocate a region of executable memory within the current process
2. RtlMoveMemory - to copy data byte-by-byte into that allocated region
3. Internal_EnumUILanguages - callback-based API abused here as an execution primitive
   

Figure 6: Executing Shellcode

Stage 2: Initial Shellcode Loader

The shellcode embedded within the VBA byte arrays is not stored in plaintext. Instead, it is encoded using a two-step bitwise transformation to evade signature-based detection.

As shown in Figure 7, the decode loop operates on each byte of the encoded payload by first applying a bitwise NOT, then XORing the result with the key 0x65. This combined operation is functionally equivalent to a single XOR with key 0x9A, which explains the prevalence of 0x9A bytes throughout the raw shellcode arrays, as these represent encoded null bytes.

Figure 7: XOR loop at start of shellcode

The corresponding assembly performs this loop starting at offset 0x26 from the shellcode base for a total of 0x29A (666) bytes. As seen from Figure 8, it locates its own position in memory using an FPU-based GetEIP trick (fldpi followed by fnstenv and pop ebp), a classic position-independent code technique that avoids direct call/pop patterns commonly flagged by security tools. Once the base address is resolved, the loop decodes the payload in place, revealing the actual shellcode instructions that handle the next-stage DLL download and execution.

Figure 8: Retrieving EIP as seen in 32-bit shellcode

Upon decoding the shellcode using the NOT + XOR 0x65 loop described earlier, the second-stage payload is revealed (Figure 9).

Figure 9: Decoding stage 3 shellcode

Stage 3: Shellcode Downloader

This shellcode resolves the Windows API functions it needs at runtime by walking the PEB (Figure 10) to locate loaded modules, then parsing their export tables using a ROR7 hash-based lookup to match function names against pre-computed hash values. This avoids embedding any plaintext API names in the shellcode, a standard evasion technique against string-based detection.

Figure 10: Decoded shellcode overview

The shellcode also incorporates an anti-hooking check. Before calling a resolved API, it inspects the first bytes of the function for common hooking indicators: 0xE8 (CALL), 0xE9 (JMP), 0xCC (INT3 breakpoint), and 0xEB (short JMP). If any of these are detected and the bytes at offset+5 are not a NOP sled (0x90909090), the shellcode adjusts the call target to skip past the hook (Figure 11). This allows it to bypass inline hooks placed by security products and software breakpoints set by debugging tools.

Figure 11: Anti-Hooking Check

The core payload constructs a download URL in memory:

• • hxxp[://]greezupdto[.]info/5IrzalAfHEUM9Tg6/5zbnrP5Dj2BLtwQmZ0pksh86sDDpVlY1WWOk8oExh1o7bh1g[.]ico

This points to the same C2 domain from the RTF template injection stage, but with an extended path and a .ico extension to disguise the download as an icon file.

The shellcode downloads this ICO file, allocates executable memory, and applies a first decode pass (NOT + XOR 0xCB, effectively XOR 0x34). The result is another self-decoding shellcode that, upon execution, applies a second XOR pass with key 0x57 to reveal its functional payload and an embedded C2 URL requesting the next stage disguised with a .mp3 extension.

This multi-layered encoding chain, with each stage peeling off one XOR layer before executing the next, is designed to ensure that no single decryption reveals the complete payload, complicating both static and dynamic analysis.

Figure 12: Stage 4 Shellcode

As seen from Figure 12, the second pass XOR reveals two embedded C2 URLs, both pointing to the same base path but with different file extensions:

• hxxp[://]greezupdto[.]info/5IrzalAfHEUM9Tg6/5zbnrP5Dj2BLtwQmZ0pksh86sDDpVlY1WWOk8oExh1o7bh1g[.]mp3 (next-stage payload)
• hxxp[://]greezupdto[.]info/5IrzalAfHEUM9Tg6/5zbnrP5Dj2BLtwQmZ0pksh86sDDpVlY1WWOk8oExh1o7bh1g[.]doc (clean decoy document)

The delivery infrastructure (greezupdto[.]info) was no longer serving the decoy document at the time of analysis. However, we were able to obtain the .mp3 file, which contains the final-stage agent DLL. The file's MZ header bytes have been deliberately tampered with to evade in-memory signature scans that search for PE file markers in executable regions (Figure 13).

Figure 13: Final Agent – DLL payload

Stage 4: DLL Agent

The final payload is a fully-featured implant that handles persistence, system reconnaissance, C2 communication, and next-stage payload delivery. The DLL exports a single-entry point a4Strau, invoked via rundll32.exe.

Configuration Decryption

All sensitive strings within the DLL are encrypted using AES-128-CBC with a hardcoded key and IV, decrypted at runtime as needed. By extracting the key and IV from the binary's data section and decrypting each base64-encoded blob, we recovered the complete implant configuration (Figure 14).

• • AES Key: AB BD 3A 7B 8C B2 B4 C6 AB C7 D9 09 E4 E5 C2 C1
  • AES IV: BB B3 44 58 95 B3 C7 E1 75 C6 E7 D6 D9 D5 BD DB

Figure 14: AES KEY and IV

Table 2 summarizes the decrypted configuration strings:

Table 2: Decrypted Strings - Base64 + AES

Persistence

Upon execution, the DLL establishes persistence through the COM-based Task Scheduler API. It creates a scheduled task disguised as a legitimate OneDrive process

• Task Name: OneDrive Reporting Task-S-1-5-21-1025909648-4285204302-2845685589-1001
• Trigger: Repeats at a configured interval, starting 2021-01-01T04:30:00, ending 2028-05-02T12:05:00
• Action: rundll32.exe %TEMP%\BinSat\dn110mploc.dll,a4Strau

The DLL copies itself to %TEMP%\BinSat\ and registers the task, ensuring it runs persistently across reboots for the duration of the scheduled window. The use of a realistic SID in the task name and the "OneDrive" naming convention is intended to blend in with legitimate Windows telemetry when viewed in Task Scheduler.

System Reconnaissance

Before contacting the C2, the DLL collects a detailed system profile. It gathers CPU information, retrieves the OS version through RtlGetVersion, queries the username and computer name, and enumerates all installed software. This information is assembled into a structured beacon string (Table 3):

Table 3: Initial data sent to C2

Individual software entries are delimited by ? characters. The complete data is then NULL-padded to the next 16-byte boundary, AES-CBC encrypted with the hardcoded key/IV, base64-encoded (see Figure 15), and transmitted as the mopd POST parameter (Figure 16).

Figure 15: Initial plaintext data and encryption routine reproduced using mock data

Figure 16: Sending initial data to C2

C2 Communication

The DLL communicates with its C2 over HTTPS (port 443) using the WinINet API (Figure 17). The beacon is sent as a POST request to:

• https://reggyupdated[.]info/ZxStpliGBsfdutMawer/sIOklbgrTYULKcsdGBZxsfetmw

Figure 17: C2 communication function using InternetConnectA with port 443 (0x1BB)

The C2 server responds with one of three response types, governing a two-phase handshake:

• finder: Idle acknowledgement. The DLL searches for the campaign identifier MFG in each response. Since "finder" does not contain MFG, the implant loops, sleeping for one second between retries (Figure 18).

Figure 18: C2 responding with "finder"

• MFG?<value>: Campaign match. The DLL parses the value after the ? delimiter as a floating-point number. A non-zero value signals that a payload is staged and ready for download, advancing the implant to the second phase.

• %PDF prefixed response: Payload delivery. In the second phase, the DLL sends a POST request to a separate URI path (/ZxStpliGBsfdutMawer/lkhgBrPUyXbgIlErAStyilzsh/N1/SA) using the malp= parameter instead of mopd=. The request body includes the encrypted system profile appended with the requested module name (NuGetPackgingdunk.dll), indicating to the server which payload to serve. The DLL checks the server response for a %PDF marker. If present, it strips the first 10 bytes before writing the remaining content to disk, likely to handle cases where the payload is wrapped in a PDF header to evade network inspection. If the marker is absent, the response is written directly to disk. In our testing, the server delivered the payload as a raw DLL without the %PDF prefix.

By directly crafting a phase 2 POST request to the payload delivery endpoint with the correct malp= body format, the server responded with an HTTP 200 and delivered a second-stage DoNot group DLL payload with the internal name ejtest.dll (Stage 5).

The response headers, shown in Figure 19, include content-disposition: attachment; filename=NuGetPackgingdunk.dll and content-type: application/zip, confirming active payload distribution from this C2 infrastructure. The retrieved payload is saved to %TEMP%\Inititate\TermdyunkSyubtyqdz.dll.

Figure 19: Second stage DoNot group DLL - ejtest.dll

Self-Deletion

After establishing persistence and completing its initial C2 registration, the DLL removes its original copy from disk using a time-delayed self-delete command as seen in Table 4:

Table 4: Self Deletion command

The ping command introduces a 3-second delay to ensure the DLL has finished execution before the file is deleted, a well-known cleanup technique to minimize forensic artifacts on the victim's filesystem (Figure 20).

Figure 20: Self deletion

Stage 5: Second-Stage DoNot Module (ejtest.dll)

Analysis of the retrieved module reveals it is a fully functional DoNot implant built on the same architecture as the Stage 4 DLL:

• • WinINet-based HTTPS communication on port 443
  • AES-128-CBC encrypted beacons with base64 encoding
  • Modular download capability for additional payloads
  • C2 domain: exessupdate[.]info, following the same .info TLD and misspelled-word naming convention observed across the broader infrastructure cluster
  • Matching URI pattern /KECqHPncsDnNqmvrUQMkA/
  • Staging directory: \pintok\clopr, mirroring the Stage 4’s \Inititate\ pattern of randomized or misspelled folder names
  • Beacon delimiter: |||N1|||N1, distinct from the Stage 4 DLL's ###N1###1###

Figure 21: Second stage payload C2 communication

The module's hardcoded AES key (32 A3 D5 97 6E 5A BC F5 C4 68 A8 24 69 E5 C7 91) and IV (29 A9 B9 E9 E7 E5 E1 A3 A8 67 54 28 BC B7 A2 BE) are byte-for-byte identical to those documented in an independent industry analysis of a DoNot (APT-C-35) sample.

This shared key material across campaigns provides the strongest possible cryptographic linkage to previously attributed DoNot operations. The coexistence of both ||| and ### delimiter variants within the same attack chain confirms that both conventions belong to the same tooling family, deployed at different stages. This second-stage retrieval from an active C2 confirms that the infrastructure is not merely responsive but actively distributing follow-on modules to compromised hosts.

Conclusion

This investigation confirmed an active, multi-stage espionage campaign against Bangladeshi defence entities. The kill chain runs from a geofenced RTF remote-template injection, through chained shellcode loaders, to a modular DLL implant with AES-encrypted C2. By querying the delivery endpoint directly, we pulled a live second-stage module (ejtest.dll) off the active infrastructure, confirming the operators were still serving follow-on payloads at the time of analysis.

We attribute the campaign to the DoNot group (APT-C-35) on four independent lines of evidence: C2 URI paths identical to prior DoNot campaigns; AES key material matching independently documented DoNot samples byte-for-byte; staging and VBA-injection tradecraft consistent with documented DoNot patterns; and a domain cluster sharing consistent naming conventions and cross-cluster DNS linkage.

Regional defenders should hunt the indicators in the appendix, prioritising HTTPS POST traffic carrying the mopd= and malp= parameters, scheduled tasks spoofing OneDrive naming conventions, and DNS queries to .info domains matching the patterns documented here.

EDR Detection Methodology

• Monitor Microsoft Office applications retrieving remote templates or initiating outbound network connections to external infrastructure.
• Monitor for Microsoft Office applications spawning unexpected child processes, particularly when followed by network connections, file creation activity, or execution of additional payloads.
• Alert on suspicious downloads of payloads masquerading as benign file types such as .ico and .mp3, followed by execution of DLL-based components.
• Monitor for scheduled task creation, system reconnaissance activity, and subsequent encrypted HTTPS communications to suspicious or low-reputation infrastructure.

IOCs

Files

Confirmed Campaign Infrastructure

Related Infrastructure Identified Through Clustering

Notable C2 URI Paths

• /ZxStpliGBsfdutMawer/sIOklbgrTYULKcsdGBZxsfetmw
• /KECqHPncsDnNqmvrUQMkA/copestravolxacoperj
• /ZxStpliGBsfdutMawer/lkhgBrPUyXbgIlErAStyilzsh/N1/SA
• /KECqHPncsDnNqmvrUQMkA/xocnsdropstaresdf/N1/SA

MITRE ATT&CK Mapping

References

• Analysis of the attack activity of the brain worm (APT-Q-38) using PDF document lures (QiAnXin Threat Intelligence)