Case study: Two true positives from one curated domain
A mining-pool domain, curated into Coralogix Unified Threat Intelligence the day it was published, became two confirmed cryptominer findings at two customers, each found and reported the same day.
At a glance
| Indicator | Monero mining-pool domain, published in threat research on blockchain-based C2 |
| Added to Unified Threat Intelligence | 10 September, the same day as publication |
| Detection | Coralogix Unified Threat Intelligence alert on enriched DNS and network firewall logs |
| Threat | XMRig cryptominer mining Monero, connected to attacker-controlled infrastructure |
| Verdict | 2 true positives, one per customer, in two unrelated environments |
| Noise to signal | 1 in 1.17 billion DNS records the lookup had to stand out from |
Context
Coralogix Unified Threat Intelligence enriches logs as they are ingested. When an IP, domain, URL, or file hash in a log matches an indicator in the curated feed, the event gets a _suspected field carrying the malicious value, the feeds that reported it, and a confidence score, and an alert can trigger on it the moment it lands. Setup, the enriched fields, and the out-of-the-box alerts are covered in Unified Threat Intelligence. This case study records what domain enrichment produced in one instance: a single curated indicator, two customers, two confirmed true positives.
The indicator
On 10 September, a Monero mining-pool domain was published in threat research into blockchain-based command-and-control infrastructure, where attackers abuse public ledgers and associated mining services to hide the coordination of compromised hosts. It was integrated into Coralogix Unified Threat Intelligence the same day: picked up by the threat intelligence team, assessed, normalized, scored, and pushed to every customer environment as enrichment before the day was out. At the time, none of our customers had any traffic to it.
Across the customer estates involved, the window examined holds roughly 1.17 billion DNS records. A lookup to a mining pool is, on its own, just one more line: no exploit signature, no malware hash, no failed login, and mining pools are legitimate services reachable from anywhere. What separates a benign lookup from an incident is context, and enrichment at ingest is how that context is attached to the event before anyone has to go looking for it.
Enrichment is what made that lookup mean something, instead of being one more DNS record in 1.17 billion.
Detection flow
The indicator sat in the feed for nineteen days before any host touched it. When one did, the enriched event matched, the Coralogix alert triggered, and analysts validated and notified the customer the same day. The same sequence repeated eight days later at a second customer.
No new agent was deployed and no additional data was shipped. The customers' existing DNS, firewall, and cloud logs were already flowing into Coralogix, and Unified Threat Intelligence sits on top of them. Because enrichment happens at ingest, the context travels with the event: when the alert triggers and an analyst opens the record, it already says why it is interesting, which feeds reported the domain, and how confident they are.
Detection logic
Unified Threat Intelligence enrichment adds a <field>_suspected object next to any configured log field whose value matches an indicator. For customer #1 that field was the DNS query name; for customer #2 it was the destination of the network firewall flow. The object carries malicious_value, reporting_feeds (each feed with its confidence_level on a 0 to 10 scale, malware family, and tags), and total_feeds. The confidence level is the indicator's risk score normalized at ingestion: confirmed C2 infrastructure scores 10, single-source uncorroborated indicators around 4, and the score rises as independent feeds corroborate it and decays as it ages. The alert is a standard Coralogix alert over that enriched field, so it needs no custom parser or lookup. The alert condition used for the domain match is a single Lucene filter on the enriched score:
cx_security.domain_suspected.reporting_feeds.Coralogix.confidence_level.numeric:[5 TO 10]
The same condition in DataPrime, extended to show which source hosts matched which domain:
source logs
| filter $d.cx_security.domain_suspected != null
| filter $d.cx_security.domain_suspected.reporting_feeds.Coralogix.confidence_level >= 5
| groupby $d.cx_security.source_ip, $d.cx_security.domain_suspected.malicious_value
aggregate count() as hits
Both fields are normalized under cx_security, so the query is the same regardless of the customer's original log schema. A threshold of 5 catches corroborated and C2-class indicators while leaving single-source, uncorroborated ones (which score around 4) for review rather than alerting. What matters is that the match, the indicator context, and the confidence score are already on the event, so the alert condition is a filter rather than a join.
The two cases
What makes this pair instructive is how different the compromised assets were: a security appliance in the management plane, and an ordinary cloud workload. Neither is where most teams expect to find a miner, and both were caught by the same enriched indicator.
| Customer #1 | Customer #2 | |
|---|---|---|
| Asset | Firewall management console, the system used to administer the customer's perimeter policy | Cloud server |
| Date | 29 September | 7 October, 21:49 IST |
| Observed behavior | Host resolved the tagged mining-pool domain | Pulled an XMRig cryptominer from an external IP address via curl; two minutes later began attempting connections to a public Monero mining pool |
| Telemetry | DNS logs, enriched at ingest | Network firewall logs, enriched at ingest |
| Detection | Coralogix Unified Threat Intelligence alert on the indicator match | Coralogix Unified Threat Intelligence alert on the indicator match |
| Validation | Appliance confirmed running XMRig, mining Monero, and maintaining connections to attacker-controlled infrastructure | Download, execution, and pool traffic tied into one sequence, confirming the miner was launched rather than merely dropped on disk |
| Why it matters | A compromised management-plane host has trusted reachability to the very devices meant to enforce segmentation | A direct curl download means the host was reachable and writable by something external |
| Evidence basis | Network telemetry: sustained resolution of the pool domain and outbound connections to attacker-controlled infrastructure from the appliance | Network telemetry: the download event, then repeated mining-pool connection attempts from the same host two minutes later |
| Initial access vector | Not determined from log data; outside the scope of this log-based analysis | Not determined from log data; the host was reachable and writable by something external |
| MITRE ATT&CK | Impact: T1496.001 Resource Hijacking: Compute Hijacking Command and Control: T1071 Application Layer Protocol (mining-pool traffic) | Command and Control: T1105 Ingress Tool Transfer (curl download of the miner); T1071 Application Layer Protocol (mining-pool traffic)Impact: T1496.001 Resource Hijacking: Compute Hijacking |
| Verdict | True positive | True positive |
| Customer notified | Same day, with the investigation report | Same day, with the investigation report |
Technical notes
What a miner looks like on the wire
XMRig and its forks resolve the pool hostname, open a TCP session to it, and speak the Stratum JSON-RPC protocol, beginning with a login message that carries the wallet address. Pools commonly listen on ports such as 3333, 4444, 5555, 7777, and 443, frequently with TLS, so the port alone is not a reliable signal. The reliable signals are the DNS resolution of a known pool domain, the reconnection cadence when a session drops, and, for a fresh infection, the download of the binary immediately before the first connection. All three are visible in DNS and firewall logs without endpoint telemetry, which is why enrichment on those fields catches this class of threat on assets that have no agent.
Separating a true positive from a false one
A single lookup of a mining-pool domain is suspicious but not conclusive; a security tool, a sandbox, or a curious engineer can produce one. Validation in both cases rested on behavior over time rather than a single event: repeated connection attempts from the same host, the absence of any business reason for that host to reach a mining pool, and in customer #2's case the curl download of the miner from an external IP address two minutes before the first pool connection, which turns correlation into sequence. Process-level confirmation (the running XMRig process, its command line, and persistence mechanism) sits with the customer's own incident response team, as containment and eradication do.
Why a management appliance is the worse of the two
A cloud server running a miner is a compromised workload. A firewall management console running one is a compromised control point: it holds the policy for the perimeter devices it manages, has trusted reachability to them by design, and is the kind of appliance that rarely runs an endpoint agent. Whatever delivered the miner had code execution on a system that could, in principle, change what the firewalls allow. That is why this finding was escalated as critical even though the payload itself was a nuisance-class cryptominer.
Limits of this analysis
This case study is based on log data available in Coralogix. The initial access vector, the persistence mechanism, and any lateral movement before the first observable were not established from that data and are not claimed here. The dates given are the earliest observables in the telemetry, not necessarily the moment of compromise. Indicators of compromise are deliberately not reproduced here: they decay, the public mining pool involved is a legitimate service that is only an indicator in context, and Coralogix customers already have the current indicator set applied through Unified Threat Intelligence.
Why a miner is never "just a miner"
It is tempting to file cryptomining under nuisance: some wasted CPU, a slightly higher cloud bill. That underestimates what the finding tells you. For a miner to be running, an attacker had to get code onto the host and execute it. The miner is the visible payload; the access that delivered it is the real problem, and that access is reusable. The same foothold that mines Monero today can stage ransomware, exfiltrate data, or pivot into the rest of the environment tomorrow. Catching the miner early is the opportunity to close the door before the next tenant moves in.
Key takeaways
- Curation turned a published indicator into same-day coverage. The domain was in every customer's enrichment the day it appeared in research, nineteen days before the first host touched it.
- Enrichment at ingest is what made the lookup visible. One DNS record among 1.17 billion carried the context an alert could trigger on, with no query, lookup service, or manual correlation in between.
- One indicator covered two very different assets. A firewall management console and a cloud server, on DNS and network firewall telemetry respectively, were caught by the same curated domain.
Customer identities and technical identifiers in this case study have been withheld. The timeline, behaviors, and outcomes are reported as observed by Coralogix security analysts.
Next steps
Switch on Unified Threat Intelligence for the fields that carry IPs, domains, URLs, and hashes, and the curated feed is applied to your logs as they arrive.