Anatomy of a Redis mining worm
Public accessible Redis servers are being exploited for a while now, but we stumbled upon an interesting mining worm in one of our honeytraps. Within the past 5 days, we've seen 173 unique IP addresses that have been infected with this worm, whereof 88% of the infected servers are located in China, 4% in the US and 4% Hongkong.
The worm searches for open Redis servers (port 6379), configures cron to download itself every few minutes (using a file upload service), starts mining and finally looks for new targets. It will send the payload "*1\r\n$4\r\nINFO\r\n" and check the response for the string "os:Linux", to prevent replication to other operating systems.
When the cron job executes, the worm will disable security, close the existing publicly open Redis port using iptables, disable SELinux and disable caching. If there are miners running, they will be killed and the cryptonight miner starts. The worm is taking advantage of public file hosting, in this case, transfer.sh, to replicate itself. Transfer.sh removes files after 14 days, that's assumed to be the reason that a copy will be made on each replication.
The miner that is being downloaded (Virustotal) uses the cryptonight proof-of-work algorithm, this algorithm is CPU only, which makes it efficient to run on exploited servers. When reversing the binary we noticed the following configuration:
{ algo": "cryptonight", "av": 0, "background": true, "colors": false, "cpu-affinity": null, "cpu-priority": null, "donate-level": 5, "log-file": null, "max-cpu-usage": 50, "print-time": 60, "retries": 5, "retry-pause": 5, "safe": true, "threads": null,
"pools": [{ "url": "jb.chakpools.com:443", "user": "N9emUy6baNTbNwFzZmjzzg7bntSr6TFYRiJy6oXuos HhQZamMFZXzpYENJcdXvC5cwN8oqCrXJ4YYgWRgBNXZk6a33wT7os", "pass": "x", "keepalive": true, "nicehash": true}],
"api": { "port": 0, "access-token": null, "worker-id": null }}
Especially for a bash worm, it is careful to remove all kind of residue, like putting a bash trap to remove everything on script exit, removing logs, syncing and droping caches.
Script breakdown:
- delete stale (older than +60 minutes) mutexes
- add a mxff0 that will function as mutex, if it already exists it will quit. This prevents running multiple instances of the same script.
- configure a trap handler, that will remove all scripts when the script is exited
- disable SELinux
- remove current crontab (which contained previous installs of the worm)
- add the Google (8.8.8.8) nameserver to /etc/resolv.conf
- empty tmp folders
- sync caches and then clear all Linux caches
- update the security limits for file and processes
- the worm disables access from the outside and enables loopback listening
- it kills competitive miners, other processes, and scanning scripts
- clean bash history, logs, mail spool and the tmp directory
- check for Centos, RedHat, Fedora or Ubuntu, Debian, Mint or Knoppix to use apt or yum
- installs Redis client tool and other tools
- download and build pnscan
- download the cryptominer binary and upload again to transfer.sh (virustotal)
- rename the miner to .gpg and execute it
- the worm will change its own script to upload a new script to prolong its existence
- prepare .dat Redis script to exploit other servers
- scans complete subnets for other open Redis servers, in random order within ranges 1.0.0.0/16 to 224.255.0.0/16
- pnscan will send the payload and look for the "os:linux", output to .r.$x.$y.o (contains all open Redis servers)
- filter out only Linux servers, output to .r.$x.$y.l
- mass exploit using redis-cli
- repeat previous steps for next subnet
- remove all evidence
If you're interested, you can find the source here.
IOCs
- sha256: 9756e66c168ec963c58b3d0ca5483927c14a64a99ba718fa9488a52d4d207ed6
- ssdeep: 12288:s/d8Tu4RnpO4rFnRwIzUDAwtkgWRFV0+JvZNFIZcLA43LLXl4Aq1A:kH41I4rVRDUDAwGL/bIZcLx3x
- jb.chakpools.com (159.203.182.176)
- filenames: .gpg, .dat, .mxff0
Links
- https://www.virustotal.com/#/file/9756e66c168ec963c58b3d0ca5483927c14a64a99ba718fa9488a52d4d207ed6/detection
- https://gist.github.com/nl5887/f6f8ed67ae95244482b54aa46b530bba
Business Email Compromise incidents
Over the past 12 months we have seen a sharp increase in the number of incidents relating to the compromise of business emails. Often O365, but also some Gmail and on premise systems with webmail access.
The objective is simple, use the system to convince the organisation, or a customer of the organisation to pay a fake invoice and transfer the money overseas. The average net of these breaches is around $85,000, but there have been cases well into the 7 figures. So quite worthwhile for the attacker. Most organisations are not set up to prevent or detect this kind of attack until it is too late.
Whilst similar to whaling emails the approach is more thought out and structured. The attacks are typically targeted. There are two scenarios we usually see:
- Compromise victim company, identify invoices to be paid by the victim, spoof the company to be paid and convince the victim to pay to an incorrect account.
- Compromise victim company, identify customer invoices to be paid to the victim, Spoof the victim and convince customers to pay invoices into an incorrect account.
The steps in the attack are relatively similar:
- Send Spear phishing email to selected targets
- This will have been harvested from your web sites, linkedin or other social media.
- The email is often a “here is a document”, your o365/Gmail account password has expired, etc. Although we have seen incidents where the password may have just been a lucky guess.
- The victim “logs in” to the service, exposing their password.
- In most incidents the owner of the mailbox can't rember. Check the proxy logs, you'll find the click.
- Attacker logs into the victim’s email
- sets up forwarding rules to an external email address and may also set up rules for emails with certain subjects or from certain email addresses to be sent directly to trash.
- Often the mailbox owner never sees any of the emails.
- The attacker monitors/searches the emails for opportunities.
- They look for invoices recently sent, about to be sent or received or about to be paid.
- Change payment details
- Emails are sent saying there is an issue or banking details have changed.
- Put on pressure to pay
- We've seen emails being used in this, reaching out to multiple people in an organisation, but also actual phone calls.
- Transfer money overseas.
- Usually we don't see this, but when talking to the banks usually we find the money has been transfered overseas. Lately however, they have been using several banks in Hong Kong and use swift payments to get the money overseas
Often other internal compromised accounts are cc’ed ,adding some legitimacy. In several instances the attackers created a domain, web site and appropriate email addresses on a slightly different domain than the company whose invoice needed to be paid. This provided them with much more control over the conversation. Including a phone number to call in the event that there is a problem with the transfer.
In several cases, once the payment detail notification was sent through, a follow up phone call is placed to make sure it sticks and of course also to head off the possibility that the victim company makes a verification call.
There are a few opportunities to detect or prevent these kinds of attacks:
- Prevent
- Have a robust payment changing process – validate using details you have in your database and call them regardless of whether someone called you
- Don’t pay to overseas accounts – especially when previous invoices were payed within the country.
- Check previous payments - Where did they go, is this different, if so halt the payment.
- Disallow forwarding rules to external addresses – This won’t stop it, but does make it more difficult
- Multi Factor Authentication (MFA) on mail
- Detect
- Logins from locations other than your office
- Logins where the IP address changes – we see many use open proxies when logging into a victim account. In logs that looks like the person travels rapidly across the globe.
- Regularly interrogate rules created in the email product – this is often how we find the other compromised accounts.
With some education of the accounts payables team, some log monitoring, MFA on mailboxes and some decent payment change processes this attack will be less effective and devastating.
Cheers
Mark H - Shearwater
PS if you have nice ways of detecting or preventing this kind of attack, by all means share.
Comments