# Case study: Two true positives from one curated domain

Copy as Markdown[Open in ChatGPT](https://chatgpt.com/?q=Read%20https%3A%2F%2Fcoralogix.com%2Fdocs%2Fuser-guides%2Fenrichment_rules%2Funified_threat_intelligence%2Fcryptominer-case-study.md%20and%20help%20me%20with%20my%20question%20about%20this%20Coralogix%20documentation%20page.)[Open in Claude](https://claude.ai/new?q=Read%20https%3A%2F%2Fcoralogix.com%2Fdocs%2Fuser-guides%2Fenrichment_rules%2Funified_threat_intelligence%2Fcryptominer-case-study.md%20and%20help%20me%20with%20my%20question%20about%20this%20Coralogix%20documentation%20page.)

A mining-pool domain, curated into Coralogix [Unified Threat Intelligence](https://coralogix.com/docs/user-guides/enrichment_rules/unified_threat_intelligence.md) the day it was published, became two confirmed cryptominer findings at two customers, each found and reported the same day.

## At a glance[​](#at-a-glance "Direct link to 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[​](#context "Direct link to 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](https://coralogix.com/docs/user-guides/enrichment_rules/unified_threat_intelligence.md). This case study records what domain enrichment produced in one instance: a single curated indicator, two customers, two confirmed true positives.

## The indicator[​](#the-indicator "Direct link to 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.

Note

Enrichment is what made that lookup mean something, instead of being one more DNS record in 1.17 billion.

## Detection flow[​](#detection-flow "Direct link to 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[​](#detection-logic "Direct link to 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[​](#the-two-cases "Direct link to 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<br />**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)<br />**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[​](#technical-notes "Direct link to Technical notes")

### What a miner looks like on the wire[​](#what-a-miner-looks-like-on-the-wire "Direct link to 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[​](#separating-a-true-positive-from-a-false-one "Direct link to 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[​](#why-a-management-appliance-is-the-worse-of-the-two "Direct link to 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[​](#limits-of-this-analysis "Direct link to 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"[​](#why-a-miner-is-never-just-a-miner "Direct link to 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[​](#key-takeaways "Direct link to Key takeaways")

1. **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.
2. **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.
3. **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[​](#next-steps "Direct link to Next steps")

Switch on [Unified Threat Intelligence](https://coralogix.com/docs/user-guides/enrichment_rules/unified_threat_intelligence.md) for the fields that carry IPs, domains, URLs, and hashes, and the curated feed is applied to your logs as they arrive.