Research Note 2026-01: Unflagged Jenkins Infrastructure Used for Fake Exchange Deployment and FCCCall Malware Builds

• Audience: Defenders, CTI teams, exchange security teams, hosting providers, national CERTs
• Status: Public sanitized note
• Related series: Hunting Lazarus
• Prepared: 2026-05-08

---

This is a defender-facing research note, not a numbered Hunting Lazarus installment. It publishes sanitized infrastructure and detection context while withholding credentials, victim data, operator identities, access mechanics, and live exploitation details. A richer TLP:AMBER package is available to vetted defenders on request.

Related investigation: Hunting Lazarus Parts I – VII.

---

Executive Summary

Red Asgard identified a Jenkins continuous integration server used as both a fake cryptocurrency-exchange deployment hub and a malware build environment for the FCCCall family of trojanized video-conferencing installers. The same Jenkins environment produced fake-exchange platforms and FCCCall installers. At preparation time on 2026-05-08, the infrastructure was not meaningfully represented in public malware-intelligence tooling available to defenders.

The Jenkins server was not a victim CI box with malware on it. It was operational infrastructure: a build-and-deploy hub for fake exchange platforms and trojanized conferencing malware.

---

What Is New

• A single Jenkins environment carrying both fake-exchange platform deployment and FCCCall malware build jobs.
• Thirteen named fake-exchange brands deployed from one operator-controlled hub, at least two confirmed in active operational state at the time of observation.
• Eighteen FCCCall installers produced in a single five-and-a-half-hour window from the same Jenkins build server.
• A build cadence consistent with a UTC+9 evening working window, aligning with DPRK operational timing but not serving as standalone attribution.
• At preparation time on 2026-05-08, the infrastructure was not adequately represented in public detection systems available to defenders.

---

Infrastructure (Sanitized)

Indicator	Value	Notes
Hostname	jenkins.tokenloopz.com	Jenkins continuous integration panel
IPv4	94.136.184.44
Hosting	Contabo VPS	ASN AS51167
Service	Jenkins	Internet-exposed admin panel
Co-resident workload	Fake cryptocurrency exchange platform deployment	Multiple operator accounts, named brands
Co-resident workload	FCCCall malware build pipeline	Trojanized video-conferencing installer family

Defenders should re-scan to record current TLS certificate metadata, HTTP response headers, favicon hash, and Jenkins version banner at the time of their own observation rather than relying on a stale snapshot.

Fake-exchange brands deployed from this hub

The following brand names appeared in deployment artifacts on the host. They are listed because each represents a public-facing fraud surface that exchange security teams, payment processors, and national CERTs may already be receiving consumer-protection complaints about:

crymadx, excelon, leogacy, minzo, mundiarch, orbitex, seawealth, tajirexchange, trueluck, kalapuse, keyptonomics, fxed, HesperWealth

Brands are listed at concept level only. No active platform URLs, working credentials, or victim-facing endpoints are published in this note.

---

Observed Activity

Fake-exchange platform deployment

Multiple distinct fake-exchange brands were deployed from the Jenkins environment, each with its own frontend, branded identity, and operator account. Capabilities observed across the platform set, at concept level:

• SMS/2FA interception capability (Twilio account with provisioned phone number present in environment configuration).
• Wash-trading bot infrastructure to make platforms appear legitimate.
• Integration with real cryptocurrency exchange APIs in a subset of platforms.

FCCCall malware build cadence

On 2026-04-13, the Jenkins server produced eighteen FCCCall installers in approximately five and a half hours. FCCCall is a Contagious Interview malware variant delivered as a trojanized video-conferencing application, distinct from the coding-test delivery vector documented in earlier installments of the Hunting Lazarus series.

The burst followed a two-wave structure consistent with a single supervised batch operation rather than a fully automated pipeline:

Wave	Window (PST)	Window (KST)	Builds	Avg interval
1	02:37 – 03:55	19:37 – 20:55	7	~11 min
Gap	03:55 – 06:26	20:55 – 23:26	–	151 min
2	06:26 – 08:07	23:26 – 01:07 (next day)	11	~9 min

Each of the eighteen builds was customized rather than identical. Build environment metadata included hardcoded UTC+9 timezone markers. The wall-clock window of the burst falls inside a UTC+9 evening working window.

The build pipeline ran inside ephemeral Docker containers – each build produced a fresh container hostname (12-character hex Docker ID), executed as root inside the container with internal-only Docker networking. The pattern is consistent with a clean-room-per-build supply-chain build pattern where each installer is rebuilt from scratch in an isolated workspace. Container OS observed: a current Linux 6.8.x kernel (Ubuntu 24.04 LTS family).

Delivery and exploitation chain

The Jenkins-built FCCCall installers are delivered through the broader Contagious Interview social-engineering chain documented elsewhere in the Hunting Lazarus series:

LinkedIn / freelancer-platform recruiter pretext
  -> Telegram / messaging-platform handoff
  -> FCCCall installer download (built on this Jenkins)
  -> BeaverTail credential-harvest payload execution on victim
  -> InvisibleFerret persistence
  -> FTP / Socket.IO callback to operator C2 substrate

The Jenkins build hub is the supply-side root of that chain. Defender visibility on the build hub gives early warning of victim cohorts that are about to begin C2 callback within 24 to 72 hours of installer execution.

Operational coexistence

The fake-exchange infrastructure and the malware build infrastructure ran on the same Jenkins host, under the same Jenkins environment, accessed by overlapping operator accounts. Both classes of activity are part of a single operational substrate, not separate campaigns sharing a hosting provider.

---

Detection Opportunities

Defenders should treat a Jenkins host exhibiting the following combination of properties as suspicious and worth a closer look:

Internet-exposed Jenkins admin panel
Project / job names referencing cryptocurrency-exchange brands
Build artifact names resembling video-conferencing installers (FCCCall family)
Ephemeral Docker build containers, root-in-container, internal Docker networking
12-char hex container hostnames produced per-build (clean-room pattern)
Build bursts clustered in UTC+9 evening hours
Build cadence in the 9 - 11 minute per-installer range during active windows
Co-resident exchange-platform deployment pipelines and malware build jobs
Twilio or comparable SMS-gateway credentials in build-environment configuration

Useful pivots

Signal	Defensive use
Jenkins on the public internet with exchange-themed projects	Pivot to ASN / hosting-provider abuse intake
Build artifacts named like conferencing software	Hunt endpoint telemetry for FCCCall installer drop and execution
UTC+9-clustered build bursts on Jenkins	Differentiate operator infrastructure from victim CI
Same host hosting fake-exchange frontend + malware build jobs	Treat as adversary build/deploy hub, not isolated incident
Exchange API integration code co-resident with malware build pipelines	Rotate any keys observed in related exchange integrations
Outbound C2 callback to FTP / Socket.IO substrate within 24 - 72h of installer build	Anchor build-side observation to victim-side detonation window for endpoint hunts

These pivots are signature-light by design. The point of a defender-facing note is to put hunters on the right Jenkins surfaces and on the right artifact-naming patterns; specific Sigma / Suricata / KQL rules can be derived once defenders confirm the signals on their own telemetry.

---

Coordination and Disclosure Path

This note is being shared along parallel channels:

• Hosting provider abuse desk – sanitized IOC and abuse category, no secrets.
• Jenkins project security contact – not because Jenkins is vulnerable, but because Jenkins is being abused as adversary infrastructure.
• Cloud / package providers – only where their accounts or artifacts appear (selective, named-recipient).
• Exchange security teams – for brands and APIs tied to real exchange keys; no unrelated victim data.
• National CERT/CSIRT – hosting-country CERT plus affected-country CERTs.
• Trusted researcher list – TLP:AMBER companion package available on request.

Findings related to this infrastructure have previously been submitted to United States law enforcement, including a Rewards for Justice submission citing the Jenkins build server's production of eighteen malware installers in a single morning window. This TLP:CLEAR note is being published to give defenders independent visibility of the infrastructure regardless of law-enforcement timing.

---

Defensive Actions

• Hunt for the listed host, IP, and ASN in your Jenkins inventory and CTI feeds.
• Review Jenkins logs for unauthorized build jobs and exchange-themed deploy pipelines.
• Search package repositories and endpoint telemetry for FCCCall installer naming patterns.
• Treat the listed fake-exchange brands as fraud infrastructure for consumer-protection and AML purposes.
• Rotate any cryptocurrency-exchange API keys observed in related integrations under your custody.
• Tighten internet-exposed Jenkins instances generally: this advisory is a single instance of a broader pattern in which exposed Jenkins panels become adversary build hubs.

---

What This Note Does Not Publish

• Jenkins admin credentials or any other credential material.
• .env secrets, API keys, or signing keys observed on the host.
• Exact Jenkins build paths or job-configuration internals.
• Victim-specific package names or victim identifiers.
• Live target names or active platform URLs that would increase victim exposure.
• Exact instructions or methods for accessing the Jenkins server.
• Operator real identity, Git identity, login pattern, or ISP allocation.
• Anything that would allow a third party to reproduce access or drain accounts.

---

Status of Public Detection Coverage

At preparation time on 2026-05-08, this Jenkins host and associated infrastructure were not meaningfully represented in public malware-intelligence tooling available to defenders. The deficit is an evidentiary observation about the gap, not a claim of negligence on the part of any specific public scanner. Coverage may have changed since preparation; defenders should confirm against their own current tooling.

---

Cross-Reference

This research note will be referenced from a later Hunting Lazarus series installment that will treat fake-exchange and build infrastructure narratively. The series installment is not a substitute for this note: the defender-facing IOC and detection material lives here, and the series installment will link back to it.

---

Red Asgard publishes sanitized research notes to give defenders timely visibility of operator infrastructure during ongoing investigations. Red Asgard coordinates findings through law-enforcement, provider-abuse, CERT/CSIRT, exchange-security, and vetted-defender channels where appropriate. Victim identities are withheld. Credentials, access mechanics, and active exploitation details are intentionally absent from public material.

Contact: research notes intake at Red Asgard for the TLP:AMBER companion, vetted-defender access, or coordinated disclosure questions.