Case study: catching a crypto-miner with behavioural and network signals

Crypto-miners are some of the quietest attackers in endpoint security. They don’t exfiltrate data, don’t move laterally, don’t trigger obvious alarms. They just sit there, burning CPU cycles and sending coins to someone else’s wallet. Antivirus usually misses them because there’s no malware signature - just a legitimate binary doing something it shouldn’t.

Here’s a walkthrough of how behavioural and network signals combine to catch what a signature scanner can’t.

The scenario

A developer’s workstation starts running noticeably slow around three weeks after a new project dependency is pulled from a public package repository. Nothing in the antivirus logs. No quarantine events. The developer submits a ticket about “the laptop being laggy.”

In a SOC with only signature-based detection, this goes nowhere. With behavioural telemetry, you have a thread to pull.

What behavioural detection actually sees

The miner in this case was a stripped-down XMRig binary dropped by a malicious npm package and persisted via a cron job. It runs as a child of the developer’s shell, which isn’t unusual on its own - but the process tree tells a different story when you look at what that child is doing.

Key signals in the event stream:

Process behaviour - MITRE T1496 (Resource Hijacking):

• Sustained CPU utilisation above 85% for the node_helper process across 4-hour windows
• Process spawned from an npm install run, not from a user-facing script
• Binary hash not seen in this environment before; no corresponding package in package.json

Network behaviour - outbound connection to Stratum mining pool:

• Persistent TCP connection on port 3333 to an IP not in the organisation’s baseline
• Keepalive packets every 30 seconds to the same host
• DNS lookup for a .moneroocean.stream domain shortly before the first connection

Persistence - MITRE T1053.003 (Cron Job):

• A new crontab entry written by the node_helper process, not by the user
• Entry runs every 10 minutes and restarts the miner if it isn’t already running

Each of these signals is individually explainable. A process using a lot of CPU could be a build. An outbound TCP connection could be legitimate tooling. A cron job could be a developer’s own script. The combination, correlated across a short time window, is the catch.

The detection rule

This is a simplified Sigma rule covering the process-plus-network correlation:

title: Crypto-miner process with outbound Stratum connection
status: experimental
logsource:
  category: process_creation
  product: linux
detection:
  miner_process:
    ParentImage|endswith:
      - '/npm'
      - '/node'
      - '/sh'
    CommandLine|contains:
      - '--donate-level'
      - '--pool'
      - 'stratum+'
  outbound_stratum:
    DestinationPort:
      - 3333
      - 4444
      - 14444
    Initiated: 'true'
  timeframe: 5m
  condition: miner_process and outbound_stratum
falsepositives:
  - Development tools that legitimately connect to port 3333 (rare; verify binary)
level: high
tags:
  - attack.t1496
  - attack.t1059.004

Real-world tuning note: port 3333 is also used by some legitimate development proxies. The key differentiator is the process lineage - a miner process spawned from a package manager is high-confidence; a proxy launched from an IDE is not. Build that into your detection logic before alerting.

What made containment clean

One-click endpoint isolation cut the miner’s network access immediately, stopping the pool connection and preventing any further persistence writes. The 90-day telemetry window meant it was straightforward to trace the original npm install that dropped the binary and identify whether other endpoints had pulled the same package version.

The miner had been running for 19 days before detection. With only signature-based coverage, the actual dwell time would likely have been much longer - or indefinite, until the hardware showed wear.

The takeaway

Crypto-miners don’t look like attackers until you correlate process behaviour with network telemetry. A process tree alone might not be enough. A network log alone might not be enough. The combination, with a reasonable detection window, is what turns a vague “laptop is slow” ticket into a containable incident with a clear timeline.

If your current EDR can’t correlate behavioural and network signals on a per-process basis, you’re relying on the attacker making a noisier mistake. That’s not a detection strategy.

If you want to talk through detection coverage for your environment, get in touch.