NanoCore RAT Sample Adds Sandbox-Evasion Tricks, Beacons to Dead DuckDNS Domain

A Commodity RAT Wrapped in a Sandbox-Aware Shell

A 280-kilobyte Windows executable carrying the internal name En2m7acq.exe — tagged internally as product "Unemawermaq" — has surfaced with a detection profile that reads less like a novelty and more like a warning about how far anti-analysis engineering has trickled down into everyday commodity malware. Fifty-nine of 77 antivirus engines flag the file outright, and all three sandboxes that processed it — VMRay, C2AE, and Zenbox — converge on the same verdict: a NanoCore Remote Access Trojan, unsigned, packed, and instrumented to notice when it's being watched. The news here isn't that NanoCore exists — it's a RAT with a decade-long shelf life in the criminal underground — it's the specific tradecraft stack wrapped around this particular build, and the fact that the record ties the sample to an espionage-motivated cluster rather than the financially driven operators NanoCore usually serves.

The binary (sha256 6427336ade955128d895921dbb9bbcc379ad910690ff63f6deff3794a2086c8c) first appeared under the threat label trojan.midie/nanobot, with popular-name tags of "midie," "nanobot," and "msil" attached by the detection engines that fingerprinted it. It is a straightforward PE32 GUI executable for Intel 80386 systems, compiled with a timestamp of 2023-07-24 and observed across eight submissions from six unique sources — modest numbers that suggest limited, rather than mass, circulation. It carries no digital signature: signed: false, no issuer, no certificate chain at all. Alternate filenames recovered alongside it — En2m7acq, En2m7acq.exe, a hash-named .exe, and a Windows desktop path referencing "new malware samples extracted" — read exactly like the debris trail of a sample pulled out of a malware repository rather than a file distributed under any pretense of legitimacy. Community detection tags flag it as a "spreader," and three additional tags — detect-debug-environment, checks-user-input, and long-sleeps — are the actual story: this isn't a bare-bones RAT drop, it's one instrumented specifically to survive automated triage.

Inside the Binary: Anti-Debug Checks and a Packed .text Section

Static build data on this sample is where the anti-analysis argument gets concrete. The .text section registers an entropy of 7.68 across 266,240 bytes — a figure that sits at the high end of what packed or encrypted code typically produces, and it pairs with an import table showing zero recorded entries. A legitimate Win32 GUI application of this size would ordinarily expose dozens of imported Windows API calls; here, the table is effectively empty, which is consistent with — though not independently confirmed as — a packer or crypter concealing the real API surface until runtime. The remaining sections tell a duller story by comparison: .data sits at 0.0 entropy, .rsrc at 4.61, and .reloc at 5.17, meaning the packing effort is concentrated almost entirely in the code section carrying the payload logic.

The file's imphash — feae4b4d85d0b5d3b68f83f4fee0492d — along with its vhash (0250467d05555bz3yz5e3z), tlsh, and ssdeep fuzzy hashes are all recorded and available for future matching, but none of them currently link this sample to any sibling file in this record. That absence matters: the analyst review explicitly flags this indicator as isolated, sharing no imphash, signer, or threat_label with any peer sample in the catalog. A second hash cataloged alongside it — c93d8e331a542c6f64a6dbc58a7a1038840e9b5b31a8c4edf1d87043bf5d8827 — carries no populated detection, sandbox, or behavioral fields whatsoever, meaning it functions here as a bare placeholder rather than corroborating evidence. In practical terms, the strong sample in this record is a single, self-contained data point: well-evidenced on its own, but not yet part of a demonstrable file cohort or builder lineage.

The tagging on the sample — detect-debug-environment, checks-user-input, long-sleeps — maps directly onto the technique list attached to this record: virtualization and sandbox evasion [T1497], with sub-techniques for user-activity checks [T1497.002] and time-based evasion through extended sleep intervals [T1497.003], plus debugger evasion [T1622]. Combined with the entry point recorded at offset 235491 within a 280 KB image, the picture is of a loader designed to stall or bail out the moment it detects instrumentation rather than a RAT that simply happens to be obfuscated. This is a meaningfully different engineering posture than "run a packer and ship it" — it suggests whoever assembled this build tested it against automated analysis pipelines before distribution, a detail sandbox operators and SOC teams increasingly need to plan around when a single pass through a sandbox no longer guarantees a true verdict.

Beaconing to a Dead End: The DuckDNS Channel

Once running, the sample calls out to secur3.duckdns.org — a subdomain registered against DuckDNS, the free dynamic-DNS service long favored by lower-cost RAT operators precisely because it requires no domain purchase, no WHOIS trail, and no registrar footprint to track. Two Proofpoint Emerging Threats Open signatures fire on this traffic: "ET INFO DYNAMIC_DNS Query to *.duckdns. Domain" and "ET INFO DYNAMIC_DNS Query to a *.duckdns .org Domain," both rated low severity individually but jointly confirming that the C2 channel design leans on a web-service style beacon [T1102] rather than a dedicated, purchased infrastructure footprint. That's a deliberate resilience trade-off common to NanoCore deployments: dynamic DNS lets an operator repoint the subdomain to a new IP the moment the old one burns, without touching the malware's configuration.

But the domain's current DNS state undercuts any read of this as live, functioning infrastructure. The last recorded snapshot shows an A-record resolving to 127.0.0.1 — loopback, not a routable address — alongside a self-referential MX record pointing back at secur3.duckdns.org itself. That combination is a textbook signature of either a sinkholed domain, an abandoned dynamic-DNS entry an operator never repointed, or simple provider-side misconfiguration; it is not what an actively tasked C2 endpoint looks like at the moment of capture. VirusTotal's community detection on the domain sits at just 6 of 91 engines, with a reputation score of -19 and a single malicious community vote against zero harmless votes — low but not zero, consistent with a domain that has been flagged historically even if it isn't answering live requests today.

No TLS certificate, no registrar string, and no domain-creation date are attached to this record — gaps the underlying evidence explicitly notes as blocking any certificate-issuer or domain-age analysis. That's worth sitting with rather than glossing over: without a creation date, there's no way to say whether secur3.duckdns.org was stood up specifically for this campaign or has been sitting in an operator's rotation for years. The infrastructure picture here is therefore a single node, observed at a single point in time, bound to the file only through the shared IDS signature match on the duckdns.org query pattern — not through any certificate serial, shared A-record with other infrastructure, or registrar concentration, because none of those axes have data to link. Readers should treat this less as a mapped C2 network and more as a fragment of what is very likely a larger, faster-rotating DuckDNS pool that NanoCore operators cycle through routinely.

Detection Consensus and the Gaps It Leaves

The sandbox layer is where the strongest, least ambiguous evidence in this record sits. VMRay classifies the sample as a "SPREADER" with the malware name NanoCore attached directly. C2AE returns a malicious verdict at 70% confidence, tagging it "RAT" and again naming NanoCore. Zenbox goes further, returning 96% confidence and stacking four classification tags simultaneously — MALWARE, TROJAN, EVADER, and RAT — with the family named as "Nanocore." Three independent sandboxes landing on the same family name, with the "EVADER" tag specifically corroborating the anti-analysis behavior observed at the static layer, is about as clean a behavioral consensus as this kind of record produces.

The antivirus layer tells a slightly more nuanced story than the 59/77 headline ratio suggests. Engines flagging the file include ALYac, APEX, AhnLab-V3, Alibaba, Antiy-AVL, Arcabit, Avira, BitDefender, Bkav, CAT-QuickHeal, CrowdStrike, Cylance, Cynet, DeepInstinct, DrWeb, ESET-NOD32, Elastic, Emsisoft, F-Secure, FireEye, Fortinet, GData, Google, Ikarus, K7AntiVirus, K7GW, Kaspersky, Kingsoft, and Lionic among others — a broad, mainstream-vendor spread that indicates the sample's signatures have circulated widely enough to be absorbed into most major detection engines' baselines. Sixteen engines still return no detection at all, including Acronis, Avast-Mobile, Baidu, BitDefenderFalx, CMC, ClamAV, Gridinsoft, Jiangmin, SUPERAntiSpyware, SymantecMobileInsight, TACHYON, Trustlook, Webroot, Zoner, and the Google Safe Browsing and Tehtris feeds — a mixed bag of mobile-focused, regional, and specialty engines rather than a coordinated blind spot among top-tier EDR products. Community sentiment sits at two malicious votes against zero harmless, and the file's overall reputation score is a modest -2, reflecting a sample well-established in detection databases but not attracting the kind of intense community scrutiny a fresher or more targeted campaign might generate.

The MITRE list attached to this record extends well past what's directly observable in the sandbox and static data on hand. Registry querying [T1012] and system information discovery [T1082] describe reconnaissance behavior typical of RAT operators mapping a fresh foothold; native API usage [T1106] and registry modification [T1112] describe execution and persistence mechanics; process injection [T1055] with three sub-techniques — thread execution hijacking [T1055.003], extra window memory injection [T1055.011], and a third variant [T1055.012] — describes NanoCore's known capability for hiding inside legitimate processes; and data encrypted for impact [T1486] closes out the list. None of the injection or destructive-impact techniques have a directly observed artifact in this record's sandbox or rule data — they're attributes the platform associates with the NanoCore family generically rather than behavior traced in this specific run, and that distinction matters for anyone building detection logic off this record alone.

An Espionage Label on a Criminal-Grade Tool

The record attributes this activity to Codoso — tracked elsewhere under the aliases Sunshop Group, APT19, C0d0so, C0d0s0, C0d0so0, and Codoso Team — with a stated motivation of espionage. That attribution sits oddly against the tooling: NanoCore is a widely resold, plugin-based commercial RAT with a well-documented history in financially motivated crimeware rather than nation-state espionage kits, and its presence here, wrapped in generic anti-sandbox tagging rather than any custom implant architecture, is not the signature most analysts associate with an APT-tier operator's primary toolkit. That doesn't rule out the pairing — espionage-motivated actors have used off-the-shelf RATs opportunistically before, whether to blend into criminal noise or because a lower-tier operator within a larger group's toolkit reached for what was cheap and available — but on the strength of a single isolated sample with no shared imphash or signer to a broader Codoso-linked file set, this reads as a data point worth tracking across future sightings rather than a settled conclusion.

What a Single Isolated Sample Signals

Every piece of strong evidence in this record traces back to one file and one domain observed at a single moment — and the honest reading of that is a fragment, not a campaign map. The confidence scoring behind this record lands at a medium level, and the underlying rationale is blunt about why: of two cataloged files, only one carries usable detection, sandbox, or behavioral data; the single domain has no TLS certificate and no creation date to anchor an age or issuer analysis; and there are no IP addresses or URLs in the catalog to widen the infrastructure lens at all. That's not a failure of collection so much as a structural property of dynamic-DNS-fronted commodity RAT operations — a bare subdomain requires no certificate purchase, no hosting contract, and no registrar paper trail, which is exactly why operators favor it, and exactly why it frustrates the kind of cross-referencing that cracks open better-resourced infrastructure clusters.

What this record does establish cleanly is the shape of a delivery chain that starts with a user or script invoking an unsigned executable [T1204], proceeds through deliberate environment-checking before the payload fully activates [T1497, T1622], and settles into a dynamic-DNS beacon [T1102] built for disposability rather than durability. The loopback A-record and self-referential MX on secur3.duckdns.org are a useful reminder for anyone building detection off point-in-time DNS snapshots: a domain that resolves nowhere useful today may simply be between rotations, not retired for good, and historical resolution data — not a single lookup — is what separates a dead node from a temporarily quiet one. For a threat family as old and as commercially available as NanoCore, the interesting question going forward isn't whether it still gets used — it plainly does, at a 59/77 detection ratio that proves most defenses already know its signatures — but who is reaching for it, and under what motivation, when the label on the file points toward espionage rather than crime.