One Domain Runs Both Ends of a SWIFT-Themed Malware Chain

A Single Domain Doing Double Duty

A domain named to evoke SWIFT bank-transfer messaging, registered through Dynadot Inc on 2022-06-10, has been quietly running both ends of an intrusion chain from one machine. swift-be.com is not fronting a CDN, is not split across a constellation of look-alike names, and is not hiding behind a bulletproof host. Instead, the same domain serves a PHP check-in script at swift-be.com/roks4/gate.php and a directly named executable payload at swift-be.com/roks4/shit.exe — both sitting under the identical /roks4/ path. That co-location is the single most concrete signal in this record, and it says more about how this operation runs than any actor label attached to it.

The pattern is compact enough that CTX Team's cohort analysis binds the two URLs together under nothing more elaborate than the shared domain and path — no shared file hash, no shared signer, no shared infrastructure edge ties the payload to the check-in script beyond simply living in the same directory. That is itself informative: it points to a self-managed staging server built by a single operator or small crew, rather than the distributed, multi-domain hosting fabric that better-resourced operations typically assemble. When one domain does the job of luring, staging, and calling home, the infrastructure footprint an investigator can pull on is thin by design.

Inside /roks4/: A Cert That Didn't Want to Last

The domain's certificate history adds a second, sharper anomaly. swift-be.com was created on 2022-06-10, but its TLS certificate — a wildcard covering *.swift-be.com and swift-be.com, issued by Let's Encrypt's R3 intermediate — wasn't minted until 2023-05-05, and it expired a mere 89 days later, on 2023-08-03. Nearly a year of dormancy between domain registration and certificate issuance, followed by a validity window measured in months rather than years, is the signature of an infrastructure node stood up for a specific, time-boxed operation rather than a durable, professionally maintained asset. Let's Encrypt's short default validity periods make 89-day certs unremarkable on their own, but paired with a domain that otherwise sat quiet for a year, the timing reads as purpose-built rather than incidental.

The WHOIS record backing this reinforces the throwaway framing: the registrar, Dynadot Inc, appears nowhere else across the indicators tied to this record — a registrar footprint of exactly one domain. The domain resolves to a single A-record (75.2.18.233) through name servers ns1.dyna-ns.net and ns2.dyna-ns.net, and it carries a modest Cisco Umbrella popularity rank (848,680, recorded 2023-06-09) — consistent with a low-traffic node rather than a widely-trafficked distribution point. None of this scales into a cluster; it scales into a single, disposable staging box that did its job and, per the short cert life, was likely never meant to run long.

From Lure to Check-In: Reading the Chain

The available evidence lets CTX Team walk the intrusion in rough order, even where individual links have to be inferred rather than observed directly. Initial access is the weakest-evidenced stage: the SWIFT-mimicking domain name paired with a payload sitting at swift-be.com/roks4/shit.exe suggests the domain was meant to be reached through some kind of lure — most plausibly a phishing message referencing payment or banking terminology [T1566] — but no email artifact or delivery vector appears in the available indicators, so that first step is an inference from naming convention alone, not a confirmed observation.

Execution is better documented. One of the two file indicators, catalogued under the hash 936d9411d5226b7c5a150ecaf422987590a8870c8e095e1caa072273041a86e7, is a DOS batch file that Windows systems have repeatedly dropped into %TEMP% under randomized filenames — its recorded alternate names include %TEMP%\970187.bat, C:\Users<USER>\AppData\Local\Temp\277218.bat, %TEMP%\978234.bat, %TEMP%\914437.bat, and C:\Users<USER>\AppData\Local\Temp\239890.bat. That renaming-on-every-run behaviour is a textbook downloader/dropper pattern executing through the Windows command shell [T1059.003]. Two low-severity IDS rules fire against its network behaviour — a Snort rule flagging "(stream_tcp) data sent on stream after TCP reset sent" and a Suricata rule flagging "SURICATA STREAM Packet with invalid timestamp" — both pointing to irregular outbound TCP activity accompanying the script's run, rather than to a clean HTTP handshake.

Defense evasion is the most directly evidenced stage in the whole chain. The second file, hash b7b4909368356522737b6b91ee4bba99d33e1c2bf86d4320d3aa6a6eda1dc10d and internally named Newsarpy4.exe, is a 644KB Win32 PE that build-provenance data shows is unsigned, packed with PEiD, and carries an import table with zero recorded entries [T1027] — a combination that frustrates static analysis by hiding the API calls a reverse engineer would normally read straight off the import table. Its .text section registers entropy of 6.25 against a total file size of 643,072 bytes, consistent with a packed payload sitting on top of a much smaller unpacked core. Despite the evasion attempt, 52 of 75 engines still flag the file as malicious, and a Dr.Web vxCube sandbox run returned a straightforward malicious verdict — packing bought the sample some cover, not immunity.

Command-and-control closes the loop back at the same domain. swift-be.com/roks4/gate.php follows the gate.php naming convention long associated with lightweight PHP check-in scripts [T1071.001] — a pattern common enough in commodity C2 kits that the naming alone is a reasonable signal, though no captured traffic in this record confirms what the script actually returns to a beaconing client. What is confirmed is the co-location: the check-in script and the payload executable sit under the same wildcard-certified domain and the same /roks4/ path, which is the strongest evidence this record offers that delivery and check-in were run out of one operator-controlled node rather than a segmented, multi-tier infrastructure.

A Loader With No Imports, a Trojan With No Origin

The two files enriched in this record tell very different stories about age and purpose, and neither maps cleanly onto the "ponystealer" family label attached to the broader record. Newsarpy4.exe first surfaced in 2018 (first_seen 2018-06-12, last_seen 2018-06-19) across just three submissions from a single source — a narrow, contained footprint consistent with a payload deployed in one operation rather than broadly recirculated. Its build fingerprints — imphash 2dd6955ddc297488527c900e7aaf3151, vhash 0650366d055)z4e3z, and an ssdeep string beginning 6144:+xYFDejY4hJKja/R0pFWrrGxwrA/mY8qKbc — carry no matches elsewhere in this catalog; CTX Team's outlier review flags it as isolated, with no shared imphash, signer, or threat label tying it to any other indicator here.

The batch-script component tells the opposite story. Rather than a bespoke, campaign-specific tool, the hash 936d9411d5226b7c5a150ecaf422987590a8870c8e095e1caa072273041a86e7 is a long-lived commodity dropper that VirusTotal has logged 505 times from 144 unique sources across an eleven-year span — first_seen 2012-12-18, last_seen 2023-05-22. That volume and duration put it firmly in the category of widely-recycled downloader infrastructure that circulates across many unrelated operations rather than tooling built or maintained for this campaign specifically; three sandbox engines (Zenbox, OS X Sandbox, Zenbox macOS) actually returned clean verdicts on it even as 33 of 76 engines flag it as malicious and community voting runs 39 malicious against 3 harmless — a split that reflects a generic script whose maliciousness depends entirely on what gets fetched at runtime.

Notably, neither file exhibits the credential-harvesting behaviour the record's "ponystealer" family tag implies. The batch script is a downloader shell; the PE32 is a packed, import-stripped loader with no visible stealer functionality in its available static or behavioural fields. That gap is worth flagging rather than papering over — it suggests the actual credential-theft payload, if one exists in this chain, sits downstream of what swift-be.com currently serves, and isn't captured among these two indicators.

Gorgon Group's Name, a Tradecraft Mismatch

The feed ties this activity to Gorgon Group, also tracked under the alias Subaat, and tags the motivation as espionage against a manufacturing-sector target in Bangladesh. That attribution should be read as the feed's classification rather than a conclusion this dataset independently proves — no shared build artifact, signer, or infrastructure edge in this record links the two files or the domain back to a named actor's known toolset. What is worth noting is the mismatch between the espionage label and the tooling on display: a recycled, eleven-year-old batch downloader and an unsigned generic packer are commodity-grade instruments, not the kind of bespoke toolset usually associated with sustained espionage operations. That tension — a high-motivation label riding on low-sophistication infrastructure — is itself a useful data point, and one better left as an open observation than resolved into a tidy actor narrative.

What a Disposable Staging Node Signals

Every piece of this record — the single co-hosting domain, the year-long gap before certificate issuance, the 89-day cert life, the registrar that shows up nowhere else, the recycled batch script running under five different randomized filenames — points toward the same operational posture: cheap, fast, and expendable. This is not an operator investing in a resilient, redundant hosting fabric designed to survive takedown attempts. It's a single node stood up to do one job for one window of time, then likely abandoned once the certificate lapsed.

That has a direct implication for how defenders and trackers should treat domains fitting this shape. A swift-be.com-style node isn't a durable pivot point worth building long-term detection infrastructure around — by the time a certificate this short-lived is observed in the wild, the operational window it was built for may already be closing. The more durable signal is the pattern itself: financial-themed domain naming, single-path co-hosting of check-in and payload, and a certificate lifecycle that runs months rather than years. Recognizing that shape early, rather than waiting to confirm actor attribution or build a full infrastructure cluster around it, is the more realistic detection posture this kind of low-overhead delivery chain actually rewards. The absence of a broader shared-infrastructure ecosystem around this domain isn't a gap in visibility — it may simply be how operations at this scale are built: minimal, disposable, and gone before the next certificate would have been due.