Dormant Domain Aged Three Years to Target Iraq's Auto Sector
A domain registered in July 2023 sat parked for 1,063 days before being activated in June 2026 to deliver a packed, sandbox-aware downloader against automotive organisations in Iraq. The payload combines Extra Window Memory process injection with a data-destruction capability, backed by two freshly provisioned Contabo VPS nodes sharing identical Let's Encrypt certificate patterns.
##A Three-Year Wait to Strike: How a Dormant Domain Became the Gateway for Iraq's Automotive Sector Attack
Sometime in July 2023, an operator registered datausercenterphx.com through Namecheap and then, apparently, did nothing with it. No certificate was issued. No payload was staged. The domain sat parked against Namecheap's own forwarding nameservers — dns1.registrar-servers.com and dns2.registrar-servers.com — accumulating age and, with it, the kind of passive domain reputation that age-based filtering systems are designed to reward. The operator had registered it with a 10-year expiry running to 2033-07-29, an unusual commitment for what would eventually prove to be a downloader staging point. Nearly three years passed.
Then, on 2026-06-16, a Let's Encrypt certificate was issued against the domain — serial 50ba653e0f968ea0357072e113c70eabcbd, valid from that date through 2026-09-14, an 89-day window — and the domain's A-record was pointed at a freshly provisioned Contabo VPS node at 164.68.122.31 in France. Within days, a packed Windows executable named GetflashProNewPhoenix_protected.exe was being served from temp.datausercenterphx.com/getflashpro/, wrapped in HTTPS legitimacy borrowed from a domain that had spent 1,063 days doing nothing but aging. The target: automotive-sector organisations in Iraq.
CTX Team's analysis of this campaign — tracked under identifier CTXbke7mzmjzl, first observed 2025-12-11 and last seen 2026-06-28 — reveals a payload cluster whose attributed technique breadth extends well beyond what a simple downloader requires. The combination of a deliberate multi-year domain-aging strategy, a full suite of sandbox and debugger evasion sub-techniques [T1497.001, T1497.002, T1497.003, T1622], process injection via Extra Window Memory [T1055.011], and a data-destruction capability [T1485] points to an operator with specific targeting intent and a willingness to cause irreversible operational damage — not an opportunistic mass-distribution campaign.
The Domain That Aged Into a Weapon
The 1,063-day gap between datausercenterphx.com's registration date of 2023-07-29 and the issuance of its first HTTPS certificate on 2026-06-16 is the campaign's most deliberate fingerprint. Domain aging as a reputation-laundering technique is not novel, but the patience required here — holding a registered asset dormant across nearly three calendar years before activation — indicates an operator who planned this delivery infrastructure well in advance of the campaign's operational phase, or who maintains a standing inventory of aged domains available for deployment on demand.
The 10-year registration expiry to 2033-07-29 reinforces this reading. Throwaway infrastructure is typically registered for one year, sometimes two; a decade-long commitment either signals pre-planned long-term use of this specific domain or a broader operational philosophy of registering assets with extended lifespans to avoid the renewal-lapse signals that threat-intelligence platforms flag. CTX Team's analyst findings note this expiry as an explicit outlier — atypical for the campaign's otherwise commodity infrastructure profile.
When the domain was finally activated, the operator's DNS configuration was minimal and functional: a single A-record pointing to 164.68.122.31, Namecheap's own forwarding MX records (eforward1.registrar-servers.com through eforward5.registrar-servers.com), and an SPF record referencing spf.efwd.registrar-servers.com. No custom mail infrastructure, no elaborate subdomain tree. The temp subdomain used for payload delivery was the only operational element, and it served a single purpose: hosting GetflashProNewPhoenix_protected.exe at the path /getflashpro/.
The domain currently returns a detection ratio of 5/91 on VirusTotal — low enough that the majority of security tooling would pass it as benign, which is precisely the outcome the aging strategy was designed to produce. The HTTPS certificate, issued by Let's Encrypt's YR1 intermediate, provides the superficial legitimacy of an encrypted connection [T1071] without any operator-controlled PKI investment. From a filtering perspective, the delivery endpoint presents as an aged .com domain with a valid TLS certificate serving content over HTTPS — a profile that would clear most automated reputation checks without triggering alerts.
The Contabo Backbone: A Fingerprint That Will Reproduce
The infrastructure supporting this campaign is deliberately commodity, but it is not fingerprint-free. Both C2-candidate IP addresses — 164.68.122.31 and 161.97.66.13 — sit within ASN 51167, operated by Contabo GmbH, and geolocate to France under RIPE NCC allocation. Their respective RIPE records place them in the 164.68.96.0/19 and 161.97.64.0/18 netblocks, both assigned to Contabo. Neither IP carries any VirusTotal detection (0/91 for both), and neither has accumulated community votes in either direction — consistent with freshly provisioned nodes that have not yet appeared in prior threat-intelligence feeds.
The certificate pattern across both IPs is where the operator's provisioning behaviour becomes legible. The node at 164.68.122.31 carries a Let's Encrypt YR2 certificate — serial 69abce45858f0ed07986396db6f6c92eb93 — issued 2026-06-16, valid through 2026-09-14, with the Contabo-default hostname vmi1380908.contaboserver.net as both the subject CN and the sole subject alternative name. The node at 161.97.66.13 carries an identically structured Let's Encrypt YR2 certificate — serial 6e19d554381a5fe20d2f9648bd626fac0fa — issued 2026-06-06, valid through 2026-09-04, with the Contabo-default hostname vmi1488651.contaboserver.net as its subject. Both certificates carry an 89-day validity window — the standard Let's Encrypt issuance period — and both were provisioned within ten days of each other.
The significance of the default-hostname subjects is operational: when a Contabo VPS is provisioned and Let's Encrypt is configured without a custom domain, the certificate is issued against the provider-assigned hostname in the format vmiXXXXXXX.contaboserver.net. This is the automated provisioning path — the operator did not configure custom TLS for these nodes, suggesting either speed of deployment or indifference to the certificate-level fingerprint. The result is a highly repeatable pattern: any future Contabo VPS provisioned by the same operator using the same automated setup will produce an identical certificate structure, with only the vmiXXXXXXX numeric identifier changing. Hunting on ASN 51167 combined with Let's Encrypt YR2 issuance and contaboserver.net subject CN patterns provides a concrete pivot for identifying additional nodes that may not yet appear in current IOC sets.
The relationship between the two IPs is partially resolved by the available evidence. The domain datausercenterphx.com resolves directly to 164.68.122.31, establishing that node as the delivery endpoint for GetflashProNewPhoenix_protected.exe and the primary infrastructure anchor for the campaign's named URL artifacts. The second IP, 161.97.66.13, shares the ASN, geolocation, and certificate pattern but has no domain resolving to it and no URL artifacts in the current IOC set. Its role — whether a secondary C2 node, a backup delivery point, a separate campaign phase, or simply a co-provisioned but not-yet-activated asset — cannot be determined from the available evidence. What the shared provisioning fingerprint does establish is that both nodes were stood up by the same operator, using the same infrastructure provider and the same certificate-provisioning workflow, within a ten-day window in early June 2026.
The C2 communication attributed to this campaign runs over an application-layer protocol [T1071.002], consistent with the file-transfer protocol framing that the temp subdomain and /getflashpro/ path structure suggest. The beacon path from an infected host back to the Contabo infrastructure would, from a network-monitoring perspective, resemble a legitimate file-retrieval operation over HTTPS — another layer in the campaign's evasion architecture.
Inside the Payload: Evasion Before Execution
The binary at the centre of this campaign announces its nature in its filename. The _protected suffix in GetflashProNewPhoenix_protected.exe is a naming convention associated with packed or obfuscated payloads — tools that apply a protective wrapper to the original executable to frustrate static analysis and signature-based detection [T1027, T1027.013]. The GetflashPro component of the name is a plausible impersonation of a legitimate Flash-related utility, a social-engineering layer that may assist in convincing a target to execute the file.
CTX Team's analysis covers eleven file SHA256s associated with this campaign. None of the eleven have been subjected to per-sample sandbox detonation or static analysis; the MITRE technique attributions for the file cluster derive from campaign-level threat metadata. The confidence level on technique-specific claims should be read accordingly.
Consistently across all eleven hashes, the technique attribution establishes a sandbox and debugger evasion capability of unusual breadth. The payload is attributed with all three sub-techniques under the T1497 family: system-environment checks [T1497.001], which probe for virtualisation artefacts such as registry keys, process names, and hardware identifiers characteristic of analysis environments; user-activity checks [T1497.002], which look for evidence of genuine human interaction — mouse movement, keyboard input, recently accessed files — before proceeding; and time-based evasion [T1497.003], which introduces delays or checks system uptime to outlast sandbox analysis windows. Alongside these, debugger detection [T1622] is attributed, covering the scenario where a researcher attaches a debugger to the process rather than running it in a sandbox. Together, these four evasion checks form a comprehensive pre-execution gate: the payload probes its environment from multiple angles before committing to its primary functionality. As MITRE's T1497 description notes, adversaries employing these techniques "may alter their malware to disengage from the victim or conceal the core functions of the implant" upon detecting an analysis environment — meaning that automated detonation pipelines that do not account for all four evasion vectors may return clean or inconclusive results even when the sample is present.
The obfuscation layer [T1027.013] sits beneath the evasion checks: the binary's packed state means that static analysis of the file on disk reveals little about its runtime behaviour. The combination of packing and multi-vector environment checking creates a payload that is designed to be opaque to both static and dynamic analysis pipelines — a capability investment that goes well beyond what a simple downloader requires.
Execution Architecture: Extra Window Memory and the Native API Path
Once the payload clears its environment checks, the execution chain attributed to the three primary file hashes — b346b51d7a30bedf3af8bd94512a35e17f3538bf8f0253b1c6baacb4f006e1e2, 20a2e80ba8a30a5fcb22c303c88f293a70defc5e38a9e2068a84f82f937611ca, and 61abab243ceacf63e059d2de94263afb2c0a68dedbb4c93c09f42e7eec51e90f — involves Native API calls [T1106] and process injection via Extra Window Memory [T1055.011].
Extra Window Memory injection is a relatively uncommon process-injection sub-technique that abuses a feature of the Windows GUI subsystem. When a window is created, the operating system allocates a small block of memory — Extra Window Memory, or EWM — that applications can use to store per-window data. An adversary exploiting this mechanism can write shellcode or a pointer to malicious code into this memory region and then redirect execution to it, effectively hosting malicious code within the address space of a legitimate GUI process. The technique's relative obscurity is operationally significant: endpoint detection and response platforms that focus their injection-detection coverage on the more common VirtualAllocEx/WriteProcessMemory/CreateRemoteThread pattern may not have equivalent coverage for EWM-based injection. As MITRE's T1055 description notes, "execution via process injection may also evade detection from security products since the execution is masked under a legitimate process."
The use of Native API calls [T1106] alongside EWM injection suggests the payload interacts directly with low-level Windows kernel interfaces rather than routing through higher-level Win32 API wrappers. This approach bypasses some user-mode API hooking mechanisms that security products use to monitor process behaviour, providing an additional layer of evasion at the execution stage.
Post-injection, the attributed discovery and collection capabilities paint a picture of a payload that conducts systematic host reconnaissance before exfiltrating data. Process enumeration [T1057] and application window listing [T1010] together allow the implant to build a map of running software — identifying security tools [T1518], productivity applications, and other indicators of the target environment's configuration. Registry queries [T1012] and registry modification [T1112] extend this reconnaissance into the system's configuration store. Screen capture [T1113] provides a visual record of the target's activity, a collection capability that is particularly valuable for operators targeting business processes rather than specific file repositories. The combination of these discovery and collection techniques, delivered through a process-injected implant running under a legitimate host process, is consistent with a payload designed for sustained, low-visibility access to a target system.
The Destructive Capability: Beyond Collection, Into Disruption
The technique attribution that most sharply distinguishes this campaign from a standard downloader operation is the data-destruction capability [T1485] attributed to the three primary file hashes alongside file deletion [T1070.004] and timestomping [T1070.006].
T1485, as MITRE's description frames it, covers adversary behaviour designed to "destroy data and files on specific systems or in large numbers on a network to interrupt availability to systems, services, and network resources" — with the explicit note that such destruction is "likely to render stored data irrecoverable by forensic techniques through overwriting files or data on local and remote drives." This is categorically different from the data collection and exfiltration that characterises espionage-motivated campaigns. An operator who deploys T1485 capability is not merely interested in reading the target's data; they retain the option to make that data permanently unavailable.
The anti-forensic capabilities attributed alongside T1485 reinforce this picture. File deletion [T1070.004] removes artefacts that would otherwise support incident response and forensic recovery. Timestomping [T1070.006] modifies file metadata timestamps to obscure the timeline of malicious activity, complicating the reconstruction of what happened and when. Together, these three techniques — destruction, deletion, and timestamp manipulation — form an impact-and-cover-tracks capability cluster that would leave a targeted organisation with both operational disruption and degraded ability to understand the scope of the intrusion.
A critical caveat applies here: the attribution of T1485, T1070.004, and T1070.006 derives from campaign-level threat metadata rather than per-sample detonation analysis. No direct forensic artefact confirms that the destructive capability has been exercised against a target. No sandbox verdicts or behavioural reports are available to independently corroborate the attribution. The claim that this payload can destroy data is supported by the threat metadata; the claim that it has done so against Iraqi automotive targets is not directly evidenced. Analysts should treat the destructive capability as an attributed risk rather than a confirmed impact.
That said, the targeting context makes the attribution worth taking seriously. CTX Team's analysis identifies Iraq and the automotive sector as the targeted region and industry. Iraq's automotive sector encompasses vehicle importers, dealerships, parts distributors, and fleet operators — organisations whose operational continuity depends on inventory systems, customer records, and supply-chain data. A payload with data-destruction capability deployed against this sector could cause significant operational disruption disproportionate to the apparent sophistication of the delivery infrastructure.
An Unattributed Operator With a Specific Targeting Profile
No actor or threat group is attributed to this campaign. No public reporting links this infrastructure or payload cluster to a named group. The campaign is, at present, analytically unattributed.
The targeting specificity — a single country, a single industry sector, a payload with destructive capability — is consistent with either a financially motivated operator seeking leverage over a specific sector or a regionally focused disruptive actor, but neither hypothesis can be asserted from the available evidence. The multi-year domain-aging strategy suggests an operator with planning patience and some degree of operational infrastructure management, but this observation does not narrow the attribution space meaningfully. Contabo GmbH's ASN 51167 is widely used by legitimate customers and threat actors alike; its appearance here is a fingerprint for hunting, not an attribution signal.
What can be said is that the operator's investment in evasion — a three-year domain-aging strategy, a packed binary with four-vector sandbox evasion, EWM process injection, and Native API execution — is disproportionate to the infrastructure cost (two commodity VPS nodes, free Let's Encrypt certificates, a Namecheap domain). This asymmetry between operational sophistication in the payload and operational economy in the infrastructure is itself a signal: the operator appears to prioritise payload-level evasion over infrastructure obfuscation, accepting that the Contabo nodes are identifiable and replaceable while investing in ensuring the payload survives automated analysis pipelines long enough to execute on target.
What the Patience Signals About Operational Intent
The most analytically significant aspect of this campaign is the temporal architecture of its delivery infrastructure. A 1,063-day dormancy period is not an accident or an oversight — it is a deliberate operational choice that reflects a specific threat model. The operator assessed that domain age would be a meaningful factor in the target environment's filtering posture, and they were willing to absorb the cost of maintaining a registered asset for nearly three years before activating it. This level of pre-operational patience is more commonly associated with targeted intrusion campaigns than with opportunistic malware distribution.
The 10-year registration expiry on datausercenterphx.com extends this logic further. If the domain's purpose were purely disposable — a one-campaign staging point to be abandoned after detection — a one-year registration would suffice. A decade-long commitment suggests either that the operator intends to reuse this domain across multiple campaign phases, or that their standard operating procedure involves registering domains with extended lifespans as a matter of course, maintaining a portfolio of aged assets available for activation. Either interpretation points toward an operator with a structured approach to infrastructure management rather than ad hoc campaign setup.
The payload's evasion architecture reinforces this reading. Implementing all three T1497 sub-techniques alongside T1622 debugger detection requires deliberate development effort — these are not default features of commodity malware builders. An operator who invests in this level of analysis-environment coverage is building for a target population that has endpoint security tooling deployed, and they expect their payload to encounter automated analysis before reaching a human analyst. The combination of a reputation-aged delivery domain and a multi-vector evasion payload suggests an operator who has thought carefully about the detection pipeline their campaign will traverse.
For the Iraqi automotive sector, the practical implication is that the campaign's delivery infrastructure was specifically engineered to look unremarkable at every automated checkpoint: an aged .com domain, a valid HTTPS certificate, commodity hosting, zero prior detections on the C2 IPs. The payload, once delivered, was engineered to survive the sandbox analysis that would follow. And if the threat-metadata attribution of T1485 reflects actual capability, the operator retained the option to move beyond collection into destruction — an escalation path that would leave targeted organisations with both a compromised environment and degraded forensic visibility into how it happened.
The repeatable infrastructure fingerprint — Contabo ASN 51167, Let's Encrypt YR2 issuance, 89-day certificate validity, default vmiXXXXXXX.contaboserver.net subject CN — is the most concrete hunting pivot this campaign leaves behind. The delivery domain and its two associated IPs are now known quantities. What remains unknown is how many additional Contabo nodes the same operator may have provisioned using the same automated workflow, carrying the same certificate structure, and waiting — as datausercenterphx.com once waited — for their own activation window.