The Ngrok campaign is unique in terms of its overall sophistication for a Docker-based attack vector.

Specifically, it demonstrates a novel, dynamic and robust operational security model and the ability to detect and attack newly deployed and misconfigured infrastructure.

Additionally, the campaign is sophisticated in seeking to detect, analyse and neutralise other competing crypto-mining malware. Its agile process can be flexed to quickly deal with new entrant-attacks and ensure a full share of the victim’s CPU resources for its activities.

Introduction

In my previous post I discussed the initial prototyping of a Docker Honeypot / Sandbox called Whaler. I’ve now been running this for a few months and tracking the number of campaigns with a range of sophistication. The most sophisticated of these was the first attack observed within hours of the initial deployment. I named the campaign Ngrok after the inventive reverse proxy used to hide the C2 infrastructure.

I’ve been following the Monero mining pool address used in the Ngrok campaign and regularly checking for other research references on the internet. The campaign has gone largely unnoticed until a recent blog published by 360totalsecurity which prompted me to finally write-up the analysis. As of today (20 Sept) the campaign is still active.

Note: I’d previously documented this as a presentation which I’ve been using in job interviews – key slides are extracted and covered below.

Summary of observed attacks

Before getting into the details of the Ngrok campaign, it’s worth summarising the key findings from the first few months of operations and development. Firstly nearly all attacks observed were Crypto-mining attackers. One exception appeared to attempt to stage a meterpreter payload to the server, but I was unable to follow-up in time on this and the attacker did not repeat the attack.

Most attackers seem to rely on discovery and indexing by Shodan as a source for their target list. There’s a clear correlation between the honeypot first appearing on Shodan and an immediate wave of attacks.

The attacks broadly fall into three levels of sophistication:

• Low Complexity – Simply pulling a pre-baked mining image from Docker Hub and running it with parameterisation for the attackers mining pool / account
• Medium Complexity – Again using Docker Hub, but creating their own container images, often with misleading names (eg mysql) but essentially containing a fully configured crypto-miner. Several of these were reported and shut down quickly working with the Docker security team. Other malware, such as an IRC botnet, was also observed bundled with the miner software.
• High Complexity – These attackers either ran their own target scanning operations, or leveraged their botnets to do this work for them. They were therefore able to detect and attack victims much quicker. Some of these attacks used the volume mounting feature of the Docker Daemon to execute a container escape – and therefore could install their payloads on the “host” system – invisible to Docker and any monitoring of running containers.

First Attack

The first attack was observed within a few hours of deploying the initial Whaler prototype. The attack was occurring approximately every 2 hours in a continuous cycle – which indicates the attack is automated.

The user agent string confirms this is likely automated, and the attacker is using an open source lightweight Ruby based docker API client framework from Swipely.

The attacking IP address is consistently hidden behind a VPN service.

Exploit

Whaler was enhanced to provide a “fingerprint” of each attack. This is used to determine how much of the attack data (Docker images, containers, pcap files etc) to retain, based on the probability this attack has already been seen. Automated attacks can drive a large amount of data storage requirements if this isn’t managed carefully!

The attack fingerprint for Ngrok is shown above. Key features are:

• The attacker uses a public alpine docker image, pre-installed with curl. There is nothing malicious about this publicly available container
• The container is parameterised to use curl to download and run a staging script from a ngrok reverse proxy address – eg hiding the backend C2 infrastructure
• Note: The ngrok.io subdomains are rotated through a set of 52 which are replaced every 8 hours
• Each victim has a unique hash identifier to identify their IP – this is used for reporting back to the C2 on details of the host and infection status
• The container mounts the root file system of the host and creates a crontab entry to execute the stager script outside of docker – this is a classic docker container escape
• There is a parameter to identify that the stager for Docker (d) should be downloaded – the attacker has a broader target scope including other misconfigured products as discussed later

Stage1 – Loader

The loader script, once running on the host system (outside of Docker) performs the following actions.

• Enumerate all processes and immediately kill any that meet a pre-defined kill list (other mining processes)
• Install the miner for the attacker by downloading two further binaries
• Report back to the C2 server (via ngrok) on the following:
  • Process ID of the infection by this attack
  • Number of CPUs
  • Current Username
  • Process name, binary location and MD5 sum of binary of anything currently running above 20% CPU

The last data point reported here enables the attacker to identify new mining campaigns and adjust their script to also target termination of those processes where found.

During the course of the analysis it was also noted that additional code was added to search for and inject Coinhive mining code into any javascript files found on the server. If these are then served via a web server it would result in further browser-based mining on behalf of the attacker.

Stage 2 – Scanner

Once the installation has been successfully completed and the infection has been reported back to the C2 infrastructure, a second script is delivered using the same mechanism as before (container escape -> cron job).

This second stage is used to enlist the victim to mas-scan a large section of IPv4 space looking for further victims. The script downloads Zmap, Zgrab and JQ and performs a scan of a pre-defined series of 8K blocks of the internet looking for:

• Redis on port 6379
• Docker on port 2375
• Jenkins, Drupal and Modx on ports 80 and 8080
• CouchDB on 5984
• Ethereum on 8545

Results are reported back to the C2, and hence the cycle repeats.

Overview of Attacker Infrastructure

An overview of the Ngrok infrastructure is shown above.

Hash Rate & Payment History

The deployed miner was configured to use the minexmr pool, and the wallet id used is:

4AuKPF4vUMcZZywWdrixuAZxaRFt9FPNgcv9v8vBnCtcPkHPxuGqacfPrLeAQWKZpNGTJzxKuKgTCa6LghSCDrEyJ5s7dnW

Using this we can see that this account was first used in early April, with approximate hashing capacity of 30-40k/s and there was a significant increase in capacity in early June, peaking at 90k/s. This uplift correlates with  360totalsecurity’s observation that the attacks “started in June” – perhaps indicating an additional target infrastructure that triggered their honeypots.

For reference, benchmarking the miner on a 1 CPU cloud server, the peak mining capacity here would be in the region of 2000 virtual CPUs.

The campaign has produced a steady, but relatively low, stream of income. It is possible that other accounts are used – in fact we also have the Coinhive account, which we are unable to determine the hashing rate or any payment details.

Between April and late August the attackers had made approx £5000 GBP.

Further details includig IoC are available at the following URL:

Ngrok Mining Botnet

About the author: oncyberblog.wordpress.com staff

Pierluigi Paganini

(Security Affairs – Ngrok, malware)

[adrotate banner=”5″]

[adrotate banner=”13″]

Share On