After you have watched this Webinar, please feel free to contact us with any questions you may have at firstname.lastname@example.org.
JOAKIM KENNEDY: Thank you all for coming.
So what we're going to go over is a little bit of a story of a joule thief.
And that's sort of been running a little bit rampant in the last almost two years now.
So before we start-- so who am I?
So my name is Joakim Kennedy.
I am a threat intelligence manager for Anomali.
I work in the Anomali threat research team.
We are the ones that produce most of the public research that goes out on the blog.
Most of the stuff we do otherwise gets sort of published into threat stream as part of intelligence.
I like to do research.
And this is kind of part of what I like to do, which is to track what bad guys are doing and see how they evolve and report on it and force them to change their behavior.
And sometimes I build stuff to just assist us thing.
I just like to build things too as a former engineer.
Sort of the agenda.
So we're going to go over who is this Rocke.
And then we're going to take a look at the activity that they've had throughout sort of the last years.
And with any sort of good high story, we can sort of divide this up into three distinct sort of epochs that we will walk through.
So who's Rocke?
So Rocke is a Chinese actor.
They were first reported by Cisco Talos about a year ago.
It was in August 2018 and that they first announced.
They are mainly interested in getting crypto mining currency-- sorry, mined cryptocurrency on your devices.
They target Linux servers.
And the way they've mainly been doing this is been to scan the whole internet and to find and devices to compromise.
And then they've installed crypto miners on them.
The name of the group comes from an email address that he used one time for a public crypto mining pool.
So that's kind of where the initial name of the actor came from.
They have been active since late 2017.
It's hard to find sort of the original first infection, but that's sort of when the activity sort of started.
So if you kind of look at this, it's kind of a partial timeline of the group and sort of how they've changed.
The same color is when the stuff is being hosted on the same IP address.
If it's gray, it's usually a shared hosting or something that cannot really be tagged directly to the specific actor, but it is things that they've used.
So for the first sort of group, I'm going to take a look at this first epoch.
The yellow dot on the yellow square on the timeline-- that's when Talos did the initial research or made public.
So this is where their research focused on.
Turnout was also another organization that picked up on the story, but it was later linked back to the same group.
So some of this would also include a little bit from F5.
So this early tech activity-- they were basically scanning the whole internet looking for anything that had vulnerabilities related to Apache Struts, WebLogic, ColdFusion, and Jenkins.
They would scan.
And then, once they found a vulnerable host they would exploit it and install a cron job.
What this cron job would do was to reach out to a host that they controlled and download something with a JPEG-- which was clearly not a JPEG, it was a binary or usually the mining application.
A lot of this stuff was hosted on-- first started with Gitee, which is a Chinese sort of equivalent of GitHub.
They moved over also to GitHub and to GitLab and sort of host everything from the script to the binaries that they were downloading.
Then, later on, they moved on to Hadoop.
And so they were hosting their own Hadoop file share where this was hosted.
and it would just connect and download.
So some of the functionality of what this sort of cron job was doing-- it would actually look and uninstall any AV products that potentially were had on the Linux box.
It downloaded a compiled version of libprocesshider.
This is an open source-- how to frame it?
Kind of like a userland rootkit.
And it's using a functionality in Linux that is using the LD_PRELOAD, where you can basically put any shared objects or any library to be loaded in at your application start.
And what this one does, it will override a bunch of libc functions, so you can actually alter the behavior of, for example, when you open files so you can hide stuff-- so, say, something Linux malware uses.
So it's a way of actually doing a userland rootkit.
It used SSH for lateral movement.
So this is part of the script that was pulled down by the cron job and executed.
It will look for the known hosts and if there is any public keys.
And it will just try to execute a crawl command that would download this sort of setup and just sort of propagate through whatever host that you have connected.
It used public mining pools.
So once the miner was pulled down, it connected and started to read.
So it was quite easy to figure out how much they were making and sort of tracking the behavior based on the wallets that they were using.
So this was kind of the initial way of putting all these campaigns together.
So taking a look at the setup script-- when exploited, it would inject sort of a crontab entry.
So here, for example, we put something in there.
You can see that the fake JPEG is being downloaded and then executed in the shell.
The first set of sort of commands in this setup script is just to kill a bunch of other stuff.
Most of these are other mining pools or other malicious miners.
This is kind of the common thing you see in this field, where everybody compromises the same host and you want to make sure that actually you are the one they have your coin being mined.
So further down afterwards-- and this is a couple hundred after-- you can see it's downloaded its resources.
So you have-- they make it even hard for you to read.
But it defines a couple of variables here and then it will execute down here, id4, which is this one here, x.
So this is kind of the initial pull down-- download everything.
You can see it downloads from GitLab.
And this is the install.
So this is what it was executing, which is executing another file.
And it sort of drops in this, the new shell.
The new cron job sets up some scripts to monitor and then execute the update.
This part here on the run is where it actually starts the miner, figures out if it is a 32-bit or 64-bit so it knows what to run.
And there's some interesting code reuse.
So this is actually something that was picked up by F5.
They actually looked at this code snippet here that you're seeing.
They found actually a question on Stack Overflow that asked, how do I determine if-- how can I relaunch an application if it's been executed based on the PID.
And if you're actually looking at it, you have significant overlap in their code between them by Mr.
So this was posted in October 27, so kind of early on in their public career.
There's some other postings.
What this user has been asking about is-- you have a little bit of doing a mass scan of the internet.
And then we have an IRC bot written in Python at around the same time.
And then also questions with regards to bitcoin, which are the-- AUDIENCE: Did anybody answer those questions?
JOAKIM KENNEDY: I can't remember.
They've moved onto a different technique from now on, you know?
So this was actually posted just a few days-- a couple of weeks before the first release of the report on the group.
And it's the last thing that they've posted with this.
F5, I think was from July, so just a few weeks before this.
So it might have picked up that someone had actually detected who they were and sort of they've stopped using the account.
So that's kind of the first sort of initial activity of this group.
Now we are going to focus on a big part here.
So I'm going to break this down into two parts.
What you have actually, the first block here is based on a report from Palo Alto Networks, and it will basically focus from October and onwards.
And then you have-- this is in a report that we-- that we published.
And that's when we started tracking this group.
And then we have another thing happening around with sort of GRA.
So at this time, the group started to just change their persona.
And they moved over from hosting stuff on Hadoop and GitHub or Git hosting and moved their stuff onto pastebin.
They also started moving a lot of the infrastructure that was hosting the miners and the setup script from Chinese hosted providers to US based hosting provider.
So they seem to have focused on more going away from China to more targeting the Western world.
They also started to use CDNs probably to try to handle more of the activity or hide where they were actually hosting this stuff.
We've seen a lot of URLs being directed to the CDN and not where the file is hosted on their controlled infrastructure.
They actually started to write actually malware to handle a lot of the setup and things like that.
So going away just from a shell script running to actually pull down something more substantial that will also control the host.
So here's the change of sort of the script.
We still can see the initial part of the killing a lot of processes, which is all about the same making sure that your stuff is the one running.
And also cleaning up and removing everything there.
So we still have this kind of competition going on.
And we still see the same sort of rootkit stuff.
Here is the ld preload that is being download as a fake JPEG again.
And we also have the setup here with a pastebin getting added into the crontab.
So following along, it follows the same sort of TTPs that's used by the group.
And still to this day I think they're still using the ld preload.
They started flirting a little bit with Python.
So you have a code here that will actually reach-- it's base-64 encoded, but under the hood it's pulling down stuff from pastebin and also more sort of setup with cron jobs.
It's mainly the way that they're kind of keeping persistence on the box.
This is the base64 encoded code, which you can see reaching out to a pastebin site.
We also saw uninstalling monitoring software.
So these are basically instructions lifted from Tencent-- hosting provider from Alibaba web.
And all they have sort of providing monitor software so that you can put on your instance to monitor what's going on.
And if you want to uninstall it, this is kind of their instructions.
So a lot of Chinese AV products and things like that that are usually run in cloud, it does try to uninstall.
And then also the mining.
Same kind of idea-- figure out which architecture it is, pull it down, and as a fake JPEG.
This is also a domain controlled by the threat actor and just download.
It also tries to disguise the name as either known Linux servers.
So we have seen, for example, Kerberos being impersonated.
They usually try to impersonate some of the kernel threads.
So here we have the kworkerd thread, but just swapping sort of the ds is usually the way to do it.
So that's kind of the initial phase where they moved in to pastebin.
So then we started tracking the group beginning of March.
And what we picked up was it downloaded actually something new.
So instead of reaching out, initially we thought it would be in the minor.
It actually pulled down something different.
So first off, that infrastructure, that site.
So it's what seem to be an image hosted site.
This website, from our sort of understanding, is completely controlled by the threat actor.
It's made to look like a site that you can upload and host your own screenshot or your identification card that can be used when you're registered to certain Chinese services.
But clearly, it can be used to host any type of binaries and it's just used as a front.
The C2-- the sort of infrastructure they used-- we could call it like a three pastebin process.
So you have first a paste that would tell the actual current version where you should be at.
So that's the version paste here.
Then you have a-- if this string doesn't match what the malware has, it will connect to A, which is essentially just a redirect pastebin.
It pulls down what is there and executes it.
But what it pulls down is a curl or a wget command that will point to the updated version.
So it allows them to sort of shield the update stuff.
And that will be the B.
So this started, as you can see, around at the end of February.
And by the time that we looked at it, they had close to about 20,000 queries.
To give kind of an idea of how much traffic we're seeing.
So this dropper that it pulled down is a pretty big binary.
It's written in Go and it comes packaged with a minor inside it plus all the other stuff it needs.
I think the author might have some fun naming it.
If you go to GitHub.com/hippies/lsd it does not exist.
And I don't think that that organization is actually the group behind it, but they simply had the fun.
I don't what LSD stands for.
Maybe it's Linux System Dropper or something.
But it's sort of plastered everywhere in the file, as you can see.
The way this one is setting up as a persistence-- it will install itself either as a systemd daemon.
Or if it's an older system it will do an init system.
So it just runs as a normal service.
So the summary of this malware.
In addition to sort of doing exactly the same as the setup script does, it actually will reach out to a proxy or like a private pool.
So instead of actually connecting to something that's public and give its wallet address, it'll just connect immediately to this entity-- will sort of identity itself.
So it's made it pretty much impossible to track how much money they are making because it's sort of shielded.
And this is where it started.
This was a droplet on digital ocean that they completely control.
The miner does not have a configuration, so it's all statically compiled.
Once you run it, it will connect immediately to this.
So the configuration is inside the binary.
As I said, the malware is written in Go.
It also started to sort of move on.
Prior to this, we've seen that the group is actually scanning the internet and basically breaking into the machines.
This malware started also to scan, the initial version of it would just look for exposed Redis servers and then try a set of credentials.
We've also seen the same with SSH.
And it also started using this sort of persona of SYSTEMTEN, which will come up in just a second.
And then we saw a second wave.
So this happened around April, where there was a lot of post on Atlassian's forum about their confluence servers being hacked and started to consume a lot of CPU cycles.
This is kind of what they found with the crontab, which is matching pretty much straight on to what the group was doing.
So the security advisory came out on the 20th of March and we started to see them exploiting around the 17th of April.
So pretty quick picking up of the actual exploit-- pick up the vulnerability and actually develop and exploit.
The mining pool was shifted.
Instead of having direct to the IP address, it actually reached out to this domain name.
And we see the same name as it was for the pastebin user.
The malware was pulled down.
It was pretty much the same malware as we saw earlier on.
It added exploitations for Jenkins.
We actually cannot find a sample that actually is exploiting the confluence vulnerability.
From what it looks like from published reports of users, they could pinpoint a bunch of IP addresses with actually scanning.
So it's likely that the threat actors liked using infrastructure to scan the internet and then attack.
So it's not a fully wormable malware that they are using.
The Jenkins vulnerability that they use is from 2018, so about a year old.
So chaining a couple of exploits used for bypass which leads then also to remote code execution.
So sort of this last phase, we have sort of coming in from the summer.
And I call this a little bit of bringing it in back home and getting more control.
So we've seen the group going on from hosting everything on GitHub pages to pastebin, and the last sort of step is more getting just self hosting everything.
So what they started doing was instead of hosting the actual setup script as a paste on pastebin, it was served directly when you're connected to this domain name.
The update check that you would have as another pastebin was now returned via a domain name.
And these were hosted usually behind CloudFlare on some sort of shared hosting provider.
This kind of started at the end of July.
We saw a huge spike.
This is actually for the update.
So this is some data from Cisco Umbrella.
And the metric that you're seeing is about at around noon on the 29th there's about went to the update domain.
So it's kind of a shift.
And after that, it's been sort of stagnated at around 200 per hour.
Things like that.
They also did some changes to the malware with regards to it continuing also with the vulnerabilities.
It added a new exploit in the malware but something they've used previously in older campaign.
They started targeting ActiveMQ.
The way it's doing that-- it is reaching out to this sort of URL.
So it takes the host that it scans for and looks to see if this port is open, if it can-- it basically tries to upload a file.
AUDIENCE: What's ActiveMQ?
JOAKIM KENNEDY: ActiveMQ-- it's a message broker similar to Redis, similar to RabbitMQ, so you can publish and subscribe to messages.
It's usually used in the back end for a lot of web services and things like that.
It has a functionality for some file server-- it's a file server.
It was a vulnerability in 2016, which you can upload a file via a put command to that URL and then subsequently do a move verb to move that into somewhere else.
So what they are doing is the uploading a cron job, and then the command afterwards is a move to put it in where cron jobs will go.
And then next time it kicks off it will infect the host.
And other way it changed was a new way of doing like a mutex.
So it starts a web server on a very high port.
And then if another malware comes in-- if this is not a version of itself come in-- it tries to connect to this port.
And then, if something is listening it will exit because it knows it's running.
It's kind of an interesting way of doing.
I've seen it sometimes but not very common.
Sort of changed the way of making sure it's the only one that's running.
So instead of basically killing based on IP addresses or file names and stuff like that, it actually has hard-coded MD5 hashes of its miner.
And it will figure out which of the running applications is these, and then it will iterate through all of the other running applications.
If it has a CPU usage of about a bit over 40% it will kill it.
So skipping its own miner.
So it's kind of the way it's making sure that it's still the king of the hill.
So as a summary of the activity of this group, it is a Chinese threat actor.
They've been active for close to about two years.
They mainly are compromising Linux servers, as we have not seen them moving over to any other area yet.
It's been an interesting sort of journey of seeing them moving from a mainly focus on the Chinese market and the Chinese infrastructure to more Western right now.
And there's not a lot of the infrastructure they are using at all-- they used to use Alibaba and Tencent and now everything is DigitalOcean, buying CloudFlare, and things like that.
They've also migrated from just using scripting languages to a full blown malware, which sort of-- the group is sort of evolving and getting better and better and better at what they're doing.
And how do you sort of prevent this from happening?
Well, patch and don't use weak credentials.
That's the main way that they actually break in.
They seem to be somewhat efficient, given we've seen about reaching out to these domains.
It would suggest there is definitely stuff out there that's been infected.
But we know that it's more than just three movies in this sort of storyline and the groups keep evolving.
So this is probably the beginning of the fourth sort of story.
So on September 17th, so less than two weeks ago, they pushed some updates to their infrastructure and the malware they're using.
So first off, they basically stopped using this system 10 domain.
So this is another domain with just a lot of gibberish.
And instead of hosting the actual files on it, it is now reaching out to this domain name and asking for a text record.
So the scripts are hosted in the domain on the name server as records.
It's encrypted with AES and the key for it is a two-round MD5 hash of the actual domain name.
So they're making it a little bit harder to find it, but the malware gives away how it is all hidden.
If it fails to get this via the text record, it actually goes back and uses DNS over HTTPS by connecting directly to CloudFlare.
So you're actually seeing a-- this is not the first time in a malware-- I think it's the second or third iteration I've seen-- but what it's reaching out to is cloudfaredns.com doing a HTTPS request to get this data over DNS.
So it's all cached by CloudFlare.
So quite an interesting change.
They've pretty much have moved away from hosting all this data on servers and it's just on domain names.
I think even the binaries are encoded and stored in these records.
And the only thing that they have now running is the mining pool.