Signed Binary Proxy and DNS Tunneling at a Retail Chain

Preserve the signed binary, service configuration, memory dump, EDR telemetry, and DNS logs with hashes before making changes. Statically examine the binary's Authenticode signature, signer chain, compile timestamp, imports, sections, strings, and any embedded or side-loaded DLL; a valid signature does not mean the file is benign, so check whether it is a known vulnerable or legitimate binary abused for proxy execution. Review the service registry key, image path, dependencies, and any DLL search-order or side-loading path. Dynamically execute it in an isolated sandbox with simulated DNS and network services, monitoring process creation, file writes, registry changes, and network traffic. Analyze the memory dump for injected regions, process hollowing, handles to card data, and strings matching track data. Compare artifacts across the 14 stores to determine whether the same service name, binary hash, and injection pattern are present. Build a timeline from service creation, file timestamps, DNS queries, and EDR events. The plan should answer whether the malware scrapes memory, how it persists, how it exfiltrates, and whether it has spread beyond the 14 stores.

The signed binary is likely being used for proxy execution or DLL side-loading to bypass application allowlisting and evade suspicion; the signature gives the attacker a trusted-looking parent process. DNS TXT queries indicate tunneling or covert command-and-control designed to survive egress filtering that permits DNS to the ISP resolver. Blocking the domain alone is insufficient because the malware may use generated domains or change infrastructure, and rebooting all terminals would destroy memory evidence and may trigger destructive behavior. Containment should first isolate affected stores at the network level without powering off terminals, preserve memory from representative and affected POS devices, and block the known domain and associated indicators while monitoring for alternate domains. Disable the malicious service only after memory capture, and prevent the binary from restarting. Collect and preserve central DNS logs, then hunt for the same service and binary hashes across all 260 stores. Credential rotation and rebuilds should follow evidence collection. The SOC should also review why DNS TXT traffic to external authoritative servers was allowed and add detection for anomalous TXT volume and entropy.

Confirm exfiltration by correlating DNS TXT query payloads with memory artifacts and POS transaction activity. If DNS logs capture query names, decode the encoded labels and look for structured data, encryption, or compression. Review the memory dump for strings and buffers containing track data patterns and for network buffers associated with the tunneling process. Examine POS application logs and payment switch records for transactions processed on affected terminals during the suspected period. Compare the volume and timing of TXT queries to transaction peaks; a correlation suggests scraping, but absence of payloads in logs does not prove no exfiltration. Estimate the card count from unique transactions on affected terminals during the confirmed compromise window, then deduplicate by card or token where possible. If the malware encrypted data before tunneling, the PFI may need to recover keys from memory or infer volume from query counts. The report should separate confirmed exfiltration from probable exposure and explain the estimation method and its limits.