Trigram Campaign

Preamble

An Already-Partially Documented Threat

Since 2022, actors whose TTPs are consistent with those of North Korea have persistently targeted developers in the cryptocurrency ecosystem. The modus operandi remains largely the same: fake recruiters, fake technical interviews, or fake coding exercises trick the victim into executing a malicious payload themselves. The most well-known campaign, Contagious Interview, reportedly compromised at least 30,000 devices across more than 100 countries, according to an alert published in September 2026.

Several recent publications describe details associated with the campaign under study:

• Proofpoint has been tracking, since April 2026 under the name UNK_DeadDrop, a cluster highly likely to be North Korean, which lures developers with email-based job offers directing them to trojanized code repositories [1];
• SafeDep documented on November 3, 2026, the compromise of the open-source repository antd-img-crop, which distributed an infostealer dubbed OverLord by its authors [2];
• Genians published in August 2026 an analysis attributing to Kimsuky an operation leveraging AI and Git repositories as its command infrastructure [3].

What's New in This Article

This analysis brings three new elements:

1. A description of the operators' back office. As far as we know, this is the first public description of the operational tooling behind a campaign of this kind: the management platform, victim-tracking consoles, and email-delivery infrastructure.
2. Correlating separately published research. Trigram's infrastructure links the activities described by Proofpoint, SafeDep, and Genians.
3. Observation of a live infrastructure. A C2 rotation was observed during the analysis, and the scale of the campaign could be quantified (approximately 50 impersonated brands).

Initial Access Phase

Initial Contact with the Victim

The attack begins with an email advertising a job opportunity. The sender poses as a recruiter, offering a fully remote software development position. To get the victim's interest, the email notably emphasizes a substantial annual salary.

The message is sufficiently detailed to appear as legitimate. It also includes a link to a website where the job posting can be reviewed and an application submitted, along with a referral code to enter upon registration.

The objective is to lead the victim to click the link and proceed through the recruitment process without looking suspicious.

Visual Looking

The picture below is an example of a mail used for this initial contact.

Figure 1: Example of a mail used for the attack's initial phase.

Decoy Analysis

The website presents itself as a recruitment platform where visitors can view a job listing and submit an application directly online.

At first glance, the site mirrors the standard elements of a recruitment platform:

• a company overview,
• a description of the open position,
• a form for candidates to submit their details.

The process is relatively straightforward and unfolds in several steps:

• Company and job overview: The site describes the company's business and presents the open position, including key responsibilities and salaries.
• Application submission: The candidate is prompted to fill out a form requesting various details, including their name, email address, the position looked, a link to their portfolio, and a personal statement.
• Spam verification: Once the form is submitted, the visitor is redirected to a new page asking them to complete a verification step to confirm they are not a robot.
• Confirmation: The process concludes with a page indicating that the application has been successfully received.

The entire experience is designed to give a sense of coherence and legitimacy. The site handles field validation, the sequencing of the various steps, and the display of confirmation messages.

It is, however, during the spam verification stage that the site's behavior becomes suspicious. Presented as a routine validation step, this procedure actually prompts the candidate to copy and execute a command directly on their machine.

Environment Identification

Upon page load, a script embedded in the web page determines the visitor's environment, in particular through the User-Agent string. This influences navigation within the site and provides the attackers with information about authorized visitors.

Visitor Filtering

The script identifies the operating system and only targets Windows, macOS, and Linux. It also checks for the presence of the cn_ip_restricted cookie, set by the server, and reads its value. If the cookie exists with a value of 1, or if the operating system is not among the targeted platforms, navigation within the site is disabled and the user is effectively blocked. These checks are performed entirely within the browser and do not trigger any data transmission.

Visitor Data Collection

For visitors who pass the filter, the script extracts the following information from the browser's User-Agent string:

• the operating system,
• the browser and its version,
• the device type, which in practice resolves to desktop, as mobile devices have already been filtered out.

IP-Based Access Restriction

The cn_ip_restricted=1 cookie suggests that the site employs an IP-based access restriction mechanism tied to the visitor's IP address. The cn prefix may refer to China, but this interpretation remains unconfirmed.

This restriction mechanism relies in part on the following JavaScript code:

When this cookie is present, the site displays a limited version of the home page. The buttons and links are disabled and the normal initialization processus is interrupted. The page remains reachable, but any interaction with it is now impossible, as shown in the following code:

Application Data Collection

The application form collects the following personal and professional information:

• Full name
• Email address
• Position of interest
• LinkedIn profile or portfolio
• Personal statement

The data is then stored locally in the browser's localStorage under the key alb-application, and transmitted to the server via an HTTP POST request in JSON format to the /track-activity route. In case of failure, the script falls back to navigator.sendBeacon as a secondary delivery mechanism.

Fake Anti-Spam Checks

After completing the application form, the visitor is redirected to the /anti-spam path. This page presents itself as a verification step designed to filter out automated applications. This mechanism fits within the context of a campaign that appears to aim pre-identified targets rather than a broad audience. To proceed, the candidate must enter a referral code.

Referral Code Validation

When the applicants submit their referral code, the site sends them to the server via a POST request to /refcode/unlock in the following format:

If the server accepts the code, it answers with a JSON payload containing the following fields:

• refCode: The code confirmed by the server. The site populates it back into the input field, which then becomes read-only.
• code: A value whose purpose is unknown on the client side. This data is stored in the browser's sessionStorage under the key alb_verify_draft.
• jobTag: An optional field, used only for tracking purposes. When the code is accepted, the script sends a message to the server (/track-activity) to indicate that the code has been unlocked, attaching the jobTag value. It has no direct effect on the page.

If the code is rejected, the site displays one of the followin messages:

• "Already used.": The code has already been used.
• "Locked to another IP.": The code is bound to a different IP address.
• "Invalid code.": Catch-all for all other cases, including network errors or incomplete server responses.

When the code is accepted, the site displays a confirmation message to the candidate. The illustration below shows an example. Its appearance may vary depending on the site.

Figure 2: Invitation Code.

Generation and Execution of the Malicious Command

Scenario

As soon as the sponsorship code is validated, the web page displays a random identifier (a nonce) and provides a command to be run. To allay the victim's suspicion, the web site presents this step as a simple verification test to prove that the user is not a robot.

The requested manipulation is straightforward:

• Copy the command directly from the web site.
• Open the terminal on the machine (PowerShell or Command Prompt on Windows, or the regular Terminal on macOS and Linux).
• Paste and execute the command, which validates the trap and triggers the infection.

The screenshot below shows the instructions presented to a Linux user, along with the nonce and the command to be executed.

Figure 3: The nonce and the command to be executed.

The web page displays an explaination saying that this command allows the nonce to be signed from the Terminal and registered in the Committee's chain. This presentation gives the operation the appearence of a simple technical check.

An analysis of the command demonstrates that it only sends the nonce to the server via a POST request to /api/verify. It does not download any file nor execute any script on the victim's machine.

The web page then waits a confirmation from the server. It does this using a SSE (Server-Sent Events) connection, or, if that fails, by regularly sending requests to /api/verify/status. Once the nonce has been received, it deliberately displays the following error message: « Operation timeout. Please try again. Nonce Refreshed. ».

This error message is intentionally displayed and does not correspond to a real timeout. In reality, it marks the transition to a second phase of the attack. The web page keeps the same appearance, but the behavior of the copy button is now changed. the victim is therefore urged to repeat the verification without realizing that the machanism has changed.

Clipboard Substitution

The script alters the copy behavior and intercepts the two methodes used to retrieve the command :

• When the victim clicks the « Copy » button, the script places the malicious command directly into the clipboard.
• If the victim selects the text and use Ctrl+C, the script also intercepts this action and replaces the copied content with the malicious command.

The command displayed on the screen still contains the new nonce, but the one that ends up in the clipboard is different. It includes a trailing newline at its end, causing its execution immediately when pasted into a Terminal, without the victim having to press Enter.

Each copy is also reported to the server. The script sends a request to /refcode/cmd-copy and transmits a cmdline_copied event to /track-activity. This event includes, among other data, the operating system, the nonce, and a magic flag that indicates whether the malicious command has been copied. The attacker can therefore monitor the victim's actions.

Commands Executed According to the Operating System

The command is built based on the detected OS and the web page's address, here represented by <site>. It downloads a script from the domain of the fake recruitment web site and the executes it.

Windows Command

1. PowerShell starts without switching profile (-NoProfile).
2. It launches cmd in a hidden window.
3. curl downloads the file verify_w from the remote server, without verifying the TLS certificate (-k) and without any output displayed (-s). The file is saved as v.cmd in the current directory.
4. Once the download finishes successfully, the file v.cmd is automatically executed by CMD.

Linux Command

1. Bash is launched with setsid -f to run it in its own session, in the background, and without depending on a terminal. Its standard input, output and errors and discarded.
2. curl download the file verify_w from the remote server, without verifying the TLS certificate (-k) and without any output displayed (-s). The file is saved as u in the current directory.
3. If the download succeeds, it executes the file with exec bash u.

macOS Command

1. Perl performs a double fork and calls POSIX::setsid to detach the process from the terminal: the first fork allows setsid to create a new session, the second prevents the process from taking back a controlling terminal. Perl is used here likely because macOS does not provide a native setsid comand.
2. curl downloads the file verify_w from the remote server, without verifying the TLS certificate (-k) and without any output displayed (-s). The file is saved as verify_m in the current directory.
3. If the download succeeds, it executes the file with exec bash verify_m.

Across the three OS, the commands define at the end a variable that holds the nonce in JSON format ($d, jsd, json), but this variable is never used. We can suppose that this is an arrangement for these commands to look like the one shown to the user : the human eye notices more easily the changes at the beginning and the end of a block of text.

Summary of the Initial Access Phase

The initial access works with a fake recruitment campaign targeting developpers and using the ClickFix technique:

• Filtering: Mobile users, unsupported systems and visitors flagged by the cn_ip_restricted cookie (which means subject to a restriction) are directed to an inactive page.
• Trick: The victim fills out a job-application form and then passes though a fake anti-spam verification that requires a one-time referral code.
• Substitution: After running an innocuous first command, the victim receives a fake error: « Operation timeout. Please try again. Nonce Refreshed. ». The web site then replaces the command in its clipboard with a second malicious command, without notifying the user.
• Execution: The second command downloads a script from the remote server and silently runs it on the victim's machine.
• Tracking: All stages of this process are reported back to the server via /track-activity.

Dropper Execution Phase

Operating Diagram

Summary

Analysis of the scripts highlights a single infection chain, adapted for three environments:

• Linux
• macOS
• Windows

These scripts act as loaders: they prepare the execution environment, retrieve the necessary components, and launch a JavaScript payload, install_guard.js, fetched from a remote server.

The operation follows several common stages:

• Background execution: The initial script launches a secondary process asynchronously, detaching it from the terminal.
• Payload decoding: The first script extracts and decodes a second layer of code hidden in Base64.
• Environment preparation: This second script configures its working directory, sets up a locking mechanism to prevent concurrent installations, and checks for an existing Node.js installation.
• Node.js deployment: If no compatible version (v18 minimum) is available, the script downloads a portable version of Node.js v20.18.1, matched to the operating system and its architecture.
• Payload retrieval: The script then downloads install_guard.js from the operator's infrastructure. The file must meet a minimum size of 50 KB to be considered valid before being executed with Node.js.

The Windows variant incorporates several specific mechanisms. It notably uses a VBScript to relaunch the CMD file asynchronously, as well as PowerShell to decode the Base64 payload. It also attempts to strip the Mark-of-the-Web (MOTW) attribute, removing Internet provenance information that could trigger security warnings or restrictions on Windows.

In conclusion, these droppers share a common architecture, tailored to the specifics of Windows, macOS, and Linux. They prepare the environment, download and execute a JavaScript component, while incorporating resumption mechanisms, process management, and communication with the attacker's infrastructure.

This component then deploys an infostealer tasked with collecting browser credentials, cryptocurrency wallets and sensitive files present on the machine. It also gathers system information and exfiltrates the collected data to the attacker. Finally, it deploys agents designed to maintain access to the machine. The infostealer's operation and the capabilities of these agents will be detailed in a follow-up article.

Infrastructure

Overview

The mapped infrastructure comprises approximately 200 IOCs, including:

• URLs
• IP
• Domain names
• Certificates
• Email addresses

It is organized across three depth levels, from targets to operators (Figure 4):

Figure 4: Infrastructure architecture, from hooks to back-office operator.

Layer #1: Decoy. Fake recruitment sites, conference invitation pages, and package-tracking portals. This is the only surface visible to targets. These sites also distribute the Stage 2 scripts.

Layer #2: Command and Control (C2) servers. They host the JavaScript payload (install_guard.js) and receive installation telemetry. C2 addresses are never hardcoded in the code: they are retrieved via a GitLab repository acting as a relay, allowing the attackers to swap C2 infrastructure at any time.

Layer #3: Operator back office. Victim-tracking consoles and a campaign management platform (rms-platform). The latter centralizes target collection from GitHub, bulk email delivery, interaction tracking, and a cryptocurrency wallet management module.

These three levels rely on abused legitimate services: GitHub and GitLab for code and configuration hosting; Brevo, Resend, Mailgun, and Smartlead for email delivery; and FullStory for visitor session recording.

Two constants characterize all mapped elements:

• Concentrated hosting with Advin Services. Domains are predominantly registered with Namecheap and use low-cost TLDs (.xyz, .ink, .site, .space, .online). This pattern is not unique to this campaign. Proofpoint had already noted in April 2026 the use of Advin addresses as sending servers by the UNK_DeadDrop cluster [1], and SafeDep located the third-stage servers of the antd-img-crop compromise on the same hoster [2].
• Artifacts consistent with AI-assisted development. The platform's internal documentation (described bellow) contains passages that are clearly copied from a conversational AI assistant, including a response that ends by prompting the user to provide "their domain name." The configuration also references a Gemini API key. The code exhibits a homogeneous, heavily commented style characteristic of generative tools. These elements do not allow determining the extent of AI reliance, but they are consistent with AI-assisted development.

Layer #1: Decoys

The decoys constitute the only surface directly exposed to targets. They support the social engineering scenarios described in the Initial Access phase, from the lure email to the execution of the malicious command. They also distribute the Stage 2 scripts (verify_w for Windows, verify_m for Linux and macOS).

The mapping reveals three distinct scenarios: recruitment, conference invitation, and package tracking. They share a common technical foundation: the target enters a verification code, then pastes the site-generated command into their terminal.

Scenario 1: Recruitment in the Web3, AI, and Tech Sectors

This scenario is the most prevalent in the corpus. The sites impersonate blockchain, artificial intelligence, and software development companies, presenting a job opening. The impersonation is double: it targets both the domain name and the visual identity, which is replicated identically.

The domain names follow recurring patterns, combining the impersonated brand name with a term evoking recruitment or community:

Below is a visual comparison between the official sites and the phishing sites:

Legitimate Website: somnia.network

Phishing Website: somniabuilders[.]network

Legitimate Website: ritual.net

Phishing Website: buildwithritual[.]xyz

Legitimate Website: webflow.com

Phishing Website: joinwebflow[.]xyz

Scenario 2: Invitation to the ICAGLLMBT Conference

One site stands out in the corpus: an invitation to the International Conference on Advances in Generative AI, Large Language Models and Blockchain Technology (ICAGLLMBT). The title is genuine. It refers to a series of conferences announced in multiple cities and dates. The domain icagllmbt[.]space mirrors it to lend credibility to the invitation, which advertises a Tokyo edition on July 7-8, 2027.

Figure 5: "Login" page on the conference website.

The TTPs align with those of the recruitment scenario. After a registration form, the target arrives at an information collection page and is prompted to complete a verification that leads to self-infection (Figure 6).

The site's JavaScript code also contained a debug invitation code that allowed direct access to this page, bypassing the intermediate steps:

Figure 6: Conference Register Form.

This scenario presents a particularity: it does not rely solely on the attackers' own email campaigns. The form offers the target, if unable to attend the event, the option to designate a substitute. It also generates a ticket and an access code to be forwarded (Figure 7). The target thus becomes a dissemination vector within their own professional network, expanding the campaign's reach beyond the attackers' original recipient list.

Figure 7: Ticket and Access Token to Share.

The domain icagllmbt[.]space is not limited to this decoy role. SafeDep documented its use as a Stage 2 server in the compromise chain of the GitHub repository antd-img-crop, a component downloaded approximately 98,000 times per week on npm [2]. A malicious commit, pushed on October 31, 2026, added a script executed at build time that downloaded verify_m or verify_w from this domain. A single domain thus simultaneously serves as both a social engineering decoy and a distribution point for a software supply-chain attack.

Scenario 3: Delivery Tracking

This scenario exploits the logistics theme. The decoys replicate the tracking interfaces of three carriers: DHL (Germany), DPD (Geopost Group, France), and Aramex (United Arab Emirates) (Figure 8).

As with the loadshipdpd[.]ink domain presented below, the domains mapped on the same infrastructure (193.160.32[.]10, listed in the table below, Figure 8) and associated with this "package tracking" cluster were observed on the server for a very brief period, between October 8 and 10, 2026.

Figure 8: Decoy Page "Delivery Tracking".

What link the three scenarios

Put together, all those technical elements link those scenarios to a common infrastructure:

Therefore we estimate with a high confidence that those three scenarios originate from the same operator and share a common technical platform.

Layer #2: Command & Control Servers (C2)

A Multi-Layer Infrastructure

Once the ClickFix command is executed, the Stage 2 script (verify_w or verify_m, depending on the victim's OS), downloaded from the decoy domain, deploys a Node.js environment and then retrieves the install_guard.js JavaScript payload (see the dropper execution phase). This payload does not embed its Command and Control (C2) server address; instead, it defines the address of a configuration file hosted on a public GitLab repository, which acts as a relay (dead drop resolver).

This architecture distinguishes three roles:

• Distribution servers, which host install_guard.js and receive installation telemetry;
• The GitLab relay, which points to the current C2 address;
• The C2 server proper, with which the payload communicates once installed.

Operators can thus swap the C2 server by modifying a single file on GitLab, without redeploying code to victims or altering their decoys.

Chain observed on 4 nov. 2026:

A Rotation Observed Under Analysis

The GitLab relay is not permanent. On October 31, 2026, SafeDep reported a relay hosted on the repository gitlab[.]com/drop-indexings/tasks. A few days later, the payload was querying another repository of the same structure, gitlab[.]com/up-indexings/tasks. The latter had been created on November 3, 2026, at 03:05 UTC, the day before our observation. The config.json file it contains was uploaded by an account using the username 0xapp123.

The repository name (tasks) and the path structure are preserved from one generation to the next; only the account changes (*-indexings). This pattern constitutes an exploitable detection indicator.

Our investigations have enabled us to identify four domains that serve as distribution or C2 functions: api.gaganata[.]ink, api.fallgganata[.]ink, gamsterb[.]ink and api.cerysoi[.]ink.

A Resilient Infrastructure

Paired naming. fallgganata is most likely a fallback server for gaganata, as confirmed by SafeDep's analysis. Similarly, cerysoi shares its suffix with chestsoi[.]ink, another domain identified by SafeDep. These pairs suggest batch generation of names.

Overlap with the back office. The subdomain dashboard.gaganata[.]ink appears in the configuration of the operator administration platform (see Layer #3). The same domain thus serves both as a payload distribution point and for campaign management.

Layer #3: Operators Back-End

Principle

The third level regroups the campaign's operational tooling. It includes victim-tracking consoles, exposed across multiple domains, and a campaign management platform dubbed rms-platform by its operators. This analysis goes beyond the infection chain alone: it reveals how operators select their targets, write to them, track their progress, and exploit the data collected.

Administration Consoles hidden into Decoys

The tracking consoles are not standalone applications: they are delivered within the same JavaScript code as the decoys. The same bundle is served to all visitors, and a check on the hostname or URL path determines which interface is displayed:

At the root of subnet.dokamacto[.]xyz, a visitor sees a recruitment decoy ("AAV Career") displaying an eligibility error (Figure [n]). Under the /ops-7f3k9m path, this same domain displays the operator console. This design choice has a major implication: every decoy visitor unknowingly receives the full console code. This is what made it possible to rebuild its functionality.

http://subnet.dokamacto[.]xyz/ops-7f3k9m

http://subnet.dokamacto[.]xyz

Two of these hosts are already known:

• The domain asteara[.]org is among the infrastructure attributed by Proofpoint to the UNK_DeadDrop cluster as early as April 2026 [1].
• The IP address 170.205.29[.]83 was used by the same cluster for its phishing email delivery [1] and appears among the C2 servers listed by Genians [3]. The back office described here thus relies, at least in part, on infrastructure running since six months.

A Victims-Tracker Step-by-Step

The console code precisely describes the steps the operator follows for each victim. Each corresponds to an event reported by the decoy or the malicious payload:

The last two steps clarify the ultimate purpose of the operation. The "facial verification" most likely extends the payload's narrative, which presents itself as a deepfake protection (deepfake_guard). Password retrieval matches the behavior documented by SafeDep: on macOS and Linux, the payload displays a fake system window prompting for the user's password, then uses it to unlock stored secrets and install itself with elevated privileges.

The console also provides several operational functions:

• Decoy monitoring. Each decoy domain managed by the console is tested every 30 seconds via a request to the /verify_w or /verify_m paths. Operators can thus immediately detect a decoy that has been taken down.
• Performance metrics. Over 24-hour windows, the console compares successful installations to "real visitors." Bots and blocked IP addresses are tracked separately, and the latter can be managed directly from the interface.
• Target scoring. Each target is rated "important," "moderate," or "useless," suggesting triage of victims based on their value.
• Session recording. The decoys integrate the FullStory behavioral analytics service (organization o-23XVR6-na1), which allows replaying each visitor's navigation.

The operator thus has real-time visibility into each victim, from copying the command to retrieving their password.

Focus on rms-platform: A Campaign Management Platform (Level 3)

Presentation

The console infrastructure led to a web service exposed on port 8000 at 170.205.30[.]27. This service, a Django application, was displaying a detailed error page, as debug mode remained enabled. The page leaked the application's route list (Figure 9), the path to its source code (/root/rms-platform/), and the names of configuration variables. Sensitive values were masked by Django.

Figure 9: Routes API de RMS.

These elements describe a platform that covers the full campaign lifecycle:

The complete set of configuration constants in use is also listed by the debug mode. Below is an organized selection of the latter:

Targeting

Several elements suggest an automated target collection from GitHub: the platform documentation describes, step by step, the extraction of profiles via the GitHub API, and GitHub-related constants were identified in the RMS configuration. This hypothesis is consistent with the observed targeting: Web3 ecosystem developers contacted in the name of blockchain projects.

Figure 10: Section "Logic for Scraping GitHub Users" from Attackers Documentation.

Delivery

The platform distributes its email volume across four sending providers: Resend, Brevo, Mailgun, and Smartlead. It relies on more than 50 Resend API keys, 13 Brevo keys, and 3 Smartlead keys, each associated with an impersonated brand. Several parameters aim to stay below spam detection thresholds: daily volume caps, random delays between sending cycles, offer validity periods, and a minimum cooldown before presenting a new offer to the same target.

The internal documentation related to the attackers' email sending (Figure 10) also reveals the IP address 198.54.127[.]82.

Figure 11: Mail Sending Configuration Section from Attackers Documentation.

Decoy Tracking and Management

The referral codes described in the Initial Access phase are issued and validated by the operator back-office platform, as are package-tracking codes (waybills). Each code is associated with an offer (job-tags) and, based on the decoys' error messages, an IP address. A tracking pixel and webhooks round out the system by measuring email opens and incoming replies.

Cryptocurrency Wallets

The function of this module could not be established with certainty. Several elements suggest it is used to monitor cryptocurrency wallets and transfer their contents. We also observed that they possess explorer API keys covering five blockchain networks: Basescan, Etherscan, Polygonscan, Solscan, and Tronscan.

We retain this hypothesis with low to moderate confidence. If confirmed, it would place the financial objective at the center of the campaign. Further details will follow in the next article.

AI-Assisted Development

The documentation served by the platform (route guide/) contains passages that appear to be directly taken from an exchange with a conversational AI assistant (hypothesis based on the presence of emojis, em dashes, and conversational markers such as "just let me know your domain name"). One of them, dedicated to bypassing Gmail blocks, concludes with an offer of further assistance to the user, typical of this type of tool. The configuration also references the use of a Gemini API key (see the table of constants identified in the "Resource Management System" configuration).

Figure 12: Mail Sending Configuration Section from Attackers Documentation.

An Industrialized Campaign: Approximately 50 Impersonated Brands

The configuration variables follow a systematic naming convention: a three- or four-letter prefix, followed by the provider name (e.g., MINA_RESEND_KEY, MINA_BREVO_KEY). These prefixes denote the impersonated brands. They appear in:

• the decoy domain names,
• a directory exposed on 193.160.32[.]10 (port 8080), containing the visual assets for each decoy page,
• a second directory exposed on the same server (port 8090), which lists decoy domains.

Figure 13: Open directory on 193.160.32[.]10.

Some domains also confirm the use of Brevo: their DNS zone contains a brevo-code TXT record, used to verify domain ownership with this French provider. Several domains share the same code, indicating they were registered from a single Brevo account:

The scale of the campaign emerges from these mappings: approximately fifty brands, each with its own domains, visual assets, and sending accounts, all managed from a single platform. This level of organization reflects an industrialized operation, designed to be quickly rolled out to new brands and to withstand the takedown of individual domains.

Attribution

Super-Administrator of the Consoles: eros1030109@gmail[.]com

The administration consoles provide a TypeScript source file, superAdmin.ts, which grants full privileges to a hard-coded email address:

This address appears among the indicators published by Genians on 10 August 2026, in a report attributing to Kimsuky an operation that uses local LLMs and Git repositories as Command-and-Control (C2) infrastructure [3]. OctoProbe links it to the display name « Oura Kano », which is also shared with the twin address apollo1030109@gmail[.]com [4].

C2 Relay Administrator: 0xapp123

A Medium account using the alias @0xapp123 posted an article presenting past Web3 projects and inviting readers to contact him for professional opportunities [6]. The contact address given is the super-administrator's email address, eros1030109@gmail[.]com.

The same alias appears at the core of the C2 infrastructure: the config.json file of the up-indexings/tasks relay (see Layer #2) was uploaded by a Gitlab account named 0xapp123. The link between the two accounts relies only on the identity of this alias. However, this alias is associated on one side with the super-administrator's email address and on the other side with the management of the C2 relay for the same campaign.

We assess with high confidence that these accounts belong to the same operator.

Database Linked to the Relay Documented by SafeDep: silviattech1129

The configuration of rms-platform contains the connection address for a hosted MongoDB database, whose user name is silviattech1129_db_user. This identifier also appears in the history of the drop-indexings/tasks relay documented by SafeDep [2]: the author adress of a commit in that repository uses the same username, silviattech1129 (commit 6b84014). This exact match, on an uncommon identifier, directly ties the infection chain described by SafeDep to the control platform analyzed here.

We assess with high confidence that the compromise of antd-img-crop and the Trigram campaign are carried out by the same operators.

Developer: alexlopez-g

The configuration of the rms-platform references a backup repository for the platform's code: alexlopez-g/rms-platform (variable GH_BACKUP_REPO). The GitHub account alexlopez-g describes itself as a developer based in the state of Washington (hxxps://www.linkedin[.]com/in/alex-lopez-g).

Figure 14: alexlopez-g Github profile.

This account contributed to the repository Foxtopia-NFT/foxtopia-frontend, presented as an NFT application, with a commit signed by the address harper.danie95@gmail[.]com. Three elements link the repository the the campaign:

• The malicious files. The src/fonts/vendor directory contains scripts whose names and functionality correspond to the droppers described in this article: install-guard-launcher.js, setup-env.cmd, setup-env.sh, setup-env-launcher.vbs, env-check.js.
• The execution mechanism. The directory contains a .vscode/tasks.json file (which triggers these scripts when the project is opened). This is the method described by Proofpoint about UNK_DeadDrop: a planified task configured to run on the folder opening launches scripts placed in a vendor/ directory [1].
• The use in fake recruitment approaches. On 26 June 2026, a designer warned the Contra platform community after receiving two nearly identical job offers, one from the address harper.danie95@gmail[.]com, the other from the domain dscufo[.]xyz. Both invited the victim to execute a command in her terminal [5].

Figure 15: https://contra.com/community/weG4gy2L-alert-avoid-fake-designer-job-offers.

The alexlopez-g account appears both as the manager of the platform's code and as the author of a compromised repository.

We assess with high confidence that it is controled by the operators of the campaign. It is also worth noting that Proofpoint observed many senders using the first name « Alex » in UNK_DeadDrop campaigns[1].

Recruiter: pichi_finance_hr

The platform is configured to control a Telegram account pichi_finance_hr. The name impersonates the Human-Resources department of Pichi Finance, a real cryptocurrency that is now inactive and that previously raised funds from Mantle Network, a brand also impersonated by the campaign. Our hypothesis is that Telegram is likely used as an approach channel, complementary to emails.

Summary of the Identities

Link with Known-Activities: an Extent of UNK_DeadDrop Activity

Proofpoint has been tracking, since April 2026 under the name UNK_DeadDrop, a campaign highly likely to originate from North Korean. It targets cryptocurrency sector developers through job offer or code review request emails bringing them to trojanized repositories [1]. Trigram shares three types of elements with this cluster:

• Infrastructure. The domain asteara[.]org and the IP address 170.205.29[.]83, attributed by Proofpoint to UNK_DeadDrop, host or serve the Trigram back office.
• Tooling. Several indicators suggest that the final payload relies on the OverLord framework [2], for which Proofpoint describes a modified version in UNK_DeadDrop [1]. It removes a publisher extension, google-update-support, that it does not itself install [2]: this is the name of the extension that UNK_DeadDrop deploys to maintain persistence [1]. This framework will be covered in greater detail in a follow-up article.
• TTPs. The Foxtopia repository replicates the tasks.json + vendor/ mechanism described by Proofpoint, as confirmed by these two screenshots of the repo.

Figure 16: https://github.com/Foxtopia-NFT/foxtopia-frontend/blob/main/.vscode/tasks.json.

Figure 17: https://github.com/Foxtopia-NFT/foxtopia-frontend/blob/main/.vscode/tasks.json.

Trigram distinguishes itself by expanding its vectors (ClickFix portals, conference invitations, compromise of a legitimate repository) and by a remotely fetched payload rather than being embedded in the repository. We assess with high confidence that Trigram is a continuation of UNK_DeadDrop activity, with an evolved modus operandi.

Conclusion

Key Takeaways

Trigram is a large-scale campaign that impersonates about 50 brands in the blockchain and AI sectors, to trick developers into executing an infostealer themselves. Three social engineering scenarios (recruitment, conference, and package tracking), a software supply-chain compromise, and trojanized code repositories all converge on the same infrastructure and the same payload.

Analysis of this infrastructure revealed the hidden mechanisms behind the attack: a malicious command-and-control (C2) dashboard. This system automates the targeting of users on GitHub, orchestrates massive phishing campaigns through four email providers, monitors the compromise of each victim in real time, and launders the stolen funds through cryptocurrency wallets. The findings, when cross-referenced with research by Proofpoint, SafeDep, and Genians, place this activity within the continuity of the North Korea-aligned threat cluster, UNK_DeadDrop.

A Threat That Is Becoming Industrialized

Four trends emerge from this analysis:

• Industrialization. Social engineering no longer relies on individual interactions but on a campaign management platform comparable to a marketing tool: target segmentation, sending quotas, conversion metrics, and monitoring of decoys.
• Vector multiplication. The same payload is distributed via decoy websites, trojanized code repositories, and the compromise of legitimate projects. Operators exploit developers' trust in their everyday tools.
• Use of legitimate services. Email service providers and code platforms make detection more challenging.
• Use of AI. Behavioral analysis services and conversational assistants lower the cost of the operation.

What's Next

The dropper examined earlier in this article subsequently deploys an infostealer and an agent. Their inner workings and capabilities will be detailed in a forthcoming article, including our findings on cryptocurrency exfiltration.

References

• [1] Proofpoint, Don’t Fear the Repo: UNK_DeadDrop Phishing Campaign Targets Developers to Steal Cryptocurrency, juin 2026 — proofpoint.com/us/blog/threat-insight/dont-fear-repo-unkdeaddrop-phishing-campaign-targets-developers-steal
• [2] SafeDep, antd-img-crop GitHub Repository Hijacked to Deliver OverLord Stealer, 3 novembre 2026 — safedep.io/blog/antd-img-crop-forged-commit-overlord-stealer
• [3] Genians, Kimsuky Integrates AI into Attack Operations, From AI-Generated Decoy Documents to a Local LLM, 10 août 2026 — https://www.genians.co.kr/en/blog/threat_intelligence/kimsuky_ai_llm
• [4] OctoProbe, Kimsuky Operation GitPower GitHub C2, 3 novembre 2026 — https://www.octoprobe.ai/blog/kimsuky-operation-gitpower-github-c2/
• [5] Contra, Scam alert: fake job offers targeting designers, 26 juin 2026 — https://contra.com/community/weG4gy2L-alert-avoid-fake-designer-job-offers
• [6] Medium, @0xapp123 — https://medium.com/@0xapp123/my-past-web3-projects-and-find-a-great-opportunity-to-work-for-you-46591e84f299

Appendices

Observed Techniques Mapping (MITRE ATT&CK)

Tableau MITRE ATT&CK.

IOCs

TRIGRAM Infrastructure

Our analysts have mapped TRIGRAM's infrastructure using the osintracker application.

Here is a preview:

Osintracker Graph of Trigram's infrastructure.

Signatures

Yara Signatures