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.
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.
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:
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.
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 loader script, once running on the host system (outside of Docker) performs the following actions.
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.
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:
Results are reported back to the C2, and hence the cycle repeats.
An overview of the Ngrok infrastructure is shown above.
The deployed miner was configured to use the minexmr pool, and the wallet id used is:
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:
About the author: oncyberblog.wordpress.com staff
(Security Affairs – Ngrok, malware)
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.