BG - A Tale of Two Malware Families - Overcoming Anti-Forensics and Foiling Botnets in the Cloud

good morning everybody Welcome to besides uh very happy to be uh back in person have a few uh little things to announce first of all I want to say thank you to our sponsors uh specifically uh Diamond sponsor LastPass in Palo Alto networks uh also the goal sponsor just to name a few Amazon and visual and blue cat uh second a couple of housekeeping things uh please silence your cell phones the talk is being recorded and streamed so we want this to be uh to be clean and also as a respect for our presenters um if you have questions uh when we have the the Q a at the end please come back to the front so the presenter can hear

and repeat for the people we're streaming to um B-side has a very strict picture taking policy you're probably aware of that so don't take any picture without the explicit consent of anybody in the frame and I think I'm probably done with the housekeeping except keep your mask all time now let me uh introduce uh Matt Matt is going to talk about uh malware families anti-forensic and some botnets I guess so Matt you have the floor foreign thank you very much Evan hey so hello and welcome to my top A Tale of Two malware families overcoming anti-forensics and foiling botnets in the cloud so let's kick off with some formalities before we get started on the content for

today so first of all I'm Matt Muir and I'm a threat intelligence researcher at Cato security prior to working at Kato I was a Mac OS malware researcher and I've got a background in devops digital forensics and operational cyber security so you can follow me on Twitter at the handle on screen and I'll share the slides after the talk unless besides do that for me of course so as part of Cato Labs Cato straight research team I'm regularly involved in conducting Research into new software threats affecting Cloud infrastructure as the name of the talk suggests I'm here today to talk to you about two recent malware families we've been tracking both of which exhibit some interesting

anti-forensics or detection evasion techniques foreign so without further ado I'll first go over the agenda of the talk before diving into some real life examples of cloud malware we've seen in the wild so kick off this presentation by introducing you to what we call the cloud challenge next I'll move on to the first malware family coin stump as we'll see coinstomp is a cloud native malware campaign that exhibits some interesting detection of Aging techniques following that I'll discuss ABC bot a botnet initially discovered by netlab 360 that we've been tracking since 2021 and has a longer history than we first realized finally we'll wrap up with some highlights of a more recent Cloud native campaign

give you some tips for detecting this type of behavior in your environment and finish off with some further reading before the Q a session so I'd like to begin by giving a brief overview of something we call the cloud challenge despite a sustained migration to the cloud from companies across the globe organizations are increasingly susceptible to attacks which are advancing in both severity and in sophistication recent cloud-focused malware campaigns have demonstrated that adversity groups possess an intimate knowledge of cloud Technologies and their security mechanisms and not only that but they're using this to their advantage Cloud compute environments remain an obvious Target for such groups however we're now also beginning to see a shifted Focus towards serverless

Computing in containers on top of this the ease of which Cloud resources can be compromised has led to adversity groups competing over potential targets so unfortunately Defenders haven't adapted at the same pace there are a number of reasons for this with visibility into Cloud infrastructure being a commonly cited one but it's an unavoidable fact that the campaigns I'm going to cover are both successful in achieving their objectives and are widespread clearly attackers in the cloud space are utilizing this to their advantage by employing ttps aimed at evading detection foiling attribution and covering their tracks so this leads me to this slide which I stole from a colleague Chris who did a similar talk recently at forward Cloud

Tech most Cloud threat actors see themselves as the GIF on the left or is Chris Hemsworth in the movie Black Cat which is a great movie of course however despite the cloud being a lucrative and easily exploitable Target for many threat groups the reality is that most cyber attacks on cloud infrastructure are not hugely technical ultimately when it comes to technical resource this means that most Cloud threat actors actually have more in common with Homer on the gift to the right so what we'll see throughout this talk is that although the tools are rudimentary so most payloads are shell scripts for example the developers make use of some Nifty tricks and Linux specific knowledge debate detection

so the first of two malware families I'm going to discuss today is what we refer to as coin Stomp coin stump is a cloud native malware campaign that we've been tracking since early 2022 and it was notable for its Antony anti-hardening sorry and detection of Asian techniques so to give everyone a quick overview of this family coin stomp is a cryptojacking malware Campaign which exploits resources hosted primarily by Asian cloud service providers so for example tencent and Alibaba cloud there have been a couple of theories about why these csps are specifically targeted by this campaign it could be the case that is simply due to the location of the attackers and familiarity with the csps in their

region I suspect that since many of these csvs are newer than for example AWS Google cloud and azure the security controls that are in place are perhaps not as mature as other cloud service providers making it more likely that instances and resources will be deployed in an insecure fashion if anyone has done research on this specifically then please get in touch with me as I'd like to know more about it so if you're someone that follows Cloud security research you're probably bored to death at this point by a family of cryptojacking show Scripts but with coin stump we noticed some interesting techniques which hinted the attacker's awareness of cloud security measures and the incident response process

so these included the use of time stamp manipulation otherwise known as time stomping an attempt to remove system cryptographic policies in order to weaken the target system C2 communication via a reverse show and a reference to a prior cryptojacking campaign potentially in an attempt to foil attribution so now with the overview of the way let's have a deeper look at the malware itself and the payloads that are utilized so the first thing that caught our eye when analyzing a Coinstar payload was the presence of this date time string which you can see passed in as a parameter to the touch command Dash T auction hopefully you all actually can see that okay but I've highlighted the relevant

section in the screenshot so the function on screen begins with an existence check for user bin mod user if this isn't found the script then grips for a sequence of strings found in the true mods binary in a subshell and uses grips Dash L option to return the file name only less can be seen on line 16 here it then renames the chamod binary to mod user and runs the touch command with Dash t and a date time string of 22-23 on the 20th of May 2019. in hindsight that's a lot of consecutive twenties for a live talk um so this may be common knowledge to most people in the room but after Consulting the touch commands

man page we realized that this is of course a pretty neat way to perform time stomping with a command that's virtually ubiquitous across unix-like systems on Lane 21 we see the exact same technique employed for the chatter or change attributes command except this time with a slightly different date time string so why are the three actors in this case obfuscating usage of chatter into mod in the first place of course both of these commands are specific to file Access Control most Cloud native malware campaigns assume that certain files of interest will be restricted for editing either via fail attributes or permissions so using the Gmod and chapter commands to modify these permissions or attributes is of course the most obvious

way to overcome this this is why we see this in virtually all malicious shell scripts that we analyze at Kindle so clearly this is a creative example of living off the land to obfuscate system utilities typically leveraged include malware campaigns but how successful actually is it well out of interest and since my employer happens to develop an incident response platform we decided to run these commands in a text machine and import an image of it into Kato to see how this would look to an instant responder so as you can see on the highlighted portion of the slide Cato identified a disparity between the timestamps of both the mod user and chair user files it seems like the touch command updated

both the modified and access timestamps to the date time hard-coded in the shell script however most importantly for us as Defenders or response responders the created time was still correct it seemed likely that this was an attempt to obfuscate usage of the chatter into mod command line tools as some forensic stones may prioritize files recently accessed or executed when building a timeline of events using a copy of these system binaries also avoids alerting admins who may have set up monitoring for execution of these utilities so you may be thinking that using touch for time stomping is not particularly novel or technically advanced however this following technique we've yet to see in other campaigns so this seemingly innocuous one-liner

that we can see on the slide here residing at line 23 of the same script we saw the time stomping Behavior actually is some pretty interesting stuff going on first of all RM is used to remove all files or subdirectories within user share which of the string crypto in the name so this of course sounded quite interesting to us as malware analysts so we had a look at what might be stored under such a directory in various Linux distributions this led us to discover that in real and rail light distributions it's possible to define a system-wide cryptographic policy which is stored in config files under user share crypto hyphen policies these policies allow or deny application

Level usage of certain cryptographic protocols depending on the user's risk posture so for example American Federal institutions are required to deploy Computing systems which conform to fips 140-2 and there's a FIP specific policy bundled with rail to help enforce this clearly this is an attempt by the malware developer to weaken the system by removing such policies in order to enforce the cryptographic policies in the first place a process named crypto is used which interfaces with the Linux kernel crypto API to ensure that the policies are indeed removed from the system and no longer enforced the malware then goes ahead and kills the crypto process after removing the config files so this is something that wasn't really

picked up on when we first published about this threat but I think that it's particularly interesting so if anyone else has seen this then please let me know as if you're interested to discuss it this was another interesting and very linuxy technique employed by Coinstar for the purposes of evading detection so as I'm sure you'll know most Linux distributions support read write operations to a remote host via the dev TCP device file naturally this is an easy and natively supported way of creating a reverse shell or C2 Communications Channel so as we can see on screen here the function cuddle is used to retrieve payloads and communicate information about the state of the system back to a

C2 server line 4 establishes communication with this server over Port 443 the port typically associated with https traffic we looked the IP of the remote server up in Showdown and saw that the server was running Python's simple HTTP server module so this suggests that although the traffic was going over Port 443 the traffic itself wasn't actually encrypted so clearly this wouldn't fill anyone with robust traffic monitoring in place but we suspect that it was an attempt to ensure that C2 Communications passed freely as it's unlikely that 443 outbound would be blocked by firewalls in the Target environment so we observed this function being invoked on a regular basis throughout the coinstop payloads usually in vacation would occur after

file existence checks used to determine whether it was necessary to retrieve additional payloads this makes us a stealthy way for the attackers to register additional implants so this was an interesting and unexpected finding when analyzing some more of the coin stop payloads coin stamp made use of KRON as a persistence mechanism and registered a Cron job under the root user whoever rather than using this persistence to launch or relaunch malicious payloads as most malware would coinstomp in States use the crown job to kill the tail and mask and utilities the latter of which is often used in these types of campaigns to find vulnerable servers to Target noticed an interested commented line in the Cron job which you may be able to

make out on line 24th reader at one point it seems as if the code hosting service and on pasta was used to host an additional payload for the coin stomp campaign we can see on Lane 243 that the URL for this provider is still added to the crown job but it's commented out resulting in it having no effect on the job itself when we visited the URL we found another URL pointing to the Anon DNS Anonymous DNS provider so this URL contains the number of strings that we recognize from a prior campaign the first of which was Xanthi a crypto mining campaign discovered by Cisco Talos that we'll come back to later in the talk

furthermore one of the payloads in the Zante campaign that we'd analyzed was called fcyzo same as the resource in the URL here unfortunately the URL was down when we attempted to retrieve this payload so we couldn't determine whether it was the exact same installation script as we'd seen in this anti-campaign we also didn't notice any overlap of infrastructure between these campaigns or anything else that would suggest they were linked so this led us to conclude that the URL likely contained those names in an attempt to foil attribution so finally to round off our overview of coin stump we noticed this rather amusing spelling mistake when stat when statically analyzing the custom version of XM rig that the coin stop scripts

drop so we're not sure if this is deliberate or not but it was jokingly suggested that it could be a reference to British crime actor Jason Statham who may well have had some involvement in this campaign so I'm not sure if everyone here will know him or not but I've included a photo of them on the next slide for visual reference

so now we've covered our first malware family I'm going to move on to another Cloud native campaign named ABC bot that we've been tracking since late 2021 to give a quick overview of this family similar to coin stomp ABC bot is a botnet which is spread via initialization shell scripts and targets Asian csps such as tencent vaidu and Alibaba cloud so the malware includes payloads consisting of shell scripts and elf executables with the shell scripts in particular displaying some notable capabilities these capabilities include insertion of attacker-controlled SSH keys to main maintain access to the Target system self-propagation in a worm-like fashion using information about Cloud Security Services and competing malware campaigns to disable competitors and registration of persistence via

common Linux persistence techniques so the campaign was originally reported on in November 2021 by netlab 360. netlab 362 Focus their analysis on the elf payloads used to connect the infected machine to the botnet I've included a reference to their research at the end of the talk if you'd like to know more about this so for this reason we won't cover the botnet related payloads today instead we'll cover one of the installation shell scripts used to propagate the malware and download additional payloads we believe this script reveals more about the attacker's capabilities and objectives since the botnet payloads was based on open source code in fitting with the theme of this talk the attacker's knowledge of the cloud

environments which their campaign targets was also evident in this shell script so let's begin by taking a look at an interesting capability displayed by the ABC bot malware family the killing of competitors although fortunately not in a literal sense so one thing that is immediately clear from analyzing this initialization script is that the developers behind ABC bot are really invested in killing off competing miners in cryptojacking campaigns the function that you can see on screen here which is several hundred lines long is dedicated to removing artifacts of competing malware campaigns and Mining software such as xmrig so we also observed the malware searching for processes associated with other prominent Linux malware campaigns so for example things like Watchdog and

kinsing this suggests that those behind ABC bot actively maintain a working knowledge of the cloud security threat landscape in a similar vein the malware also searches for malicious stalker images and removes or can or kills the containers as appropriate so this strongly suggests the ABC bot relies on exploitation of misconfigured Docker API endpoints for propagation which is of course a common infection Vector in Cloud environments and used utilized by many Cloud native campaigns so clearly the ABC Board developers had invested significant time into researching Cloud security threats given the previous slide however not only that but the developers also demonstrated a knowledge of cloud security mechanisms as disabling of Security Services native to the csps

targeted was performed so this of course allowed their malware to execute unimpeded and also allows us as analysts to determine the targets of the campaign for example several lines were dedicated to killing processes associated with the Alibaba and tencent Cloud security agents as we can see on screen here similarly the uninstallation scripts often baked into instances hosted by these csps were used to completely uninstall monitoring software in some instances the ease of which these monitoring tools can be removed could well be another reason as to why these csps in particular were targeted so we'll move on now to look at some methods of maintaining access employed by ABC book a key objective of most malware

campaigns is to establish network connectivity to allow biodirectional communication with the attacker this is of course known as command and control we saw this in our coverage of coin Stomp and its use of a Dev TCP reverse shell in a function named iptables Checker the developer behind ABC bot configures the Linux IP tables firewall to drop or accept traffic based on port numbers and Source IP addresses this particular function gave us some insights into the state of this campaign at the time of analysis so for example it's clear from the function that the malware is under active development as the author has left plenty of commented code and one of the commented rules it appears as if the developer configured

IP tables to accept all Ingress traffic from a remote IP this was likely a C2 server under the attacker's control so another comment to drill drops English traffic from ports 2375 and 2376. of course as we all know these ports are typically associated with the docker engine API we suspect that this was added at one point to prevent halt attempts to Halt execution of any malicious Docker containers the malware creates a check is also done to see whether these rules are already in place but if they aren't they're no longer added instead a more genetic rule is added to allow all Ingress traffic to a non-standard port number of 26 800. interestingly URLs embedded in the

malware also made use of the sport so another notable technique of ABC bot was the ability to infect related hosts with a copy of itself firstly the malware removes SSH Keys found on the host which appear to be from similar attacks it then goes ahead and inserts its own SSH key to guarantee ongoing access to the host after this as we can see on the slide here the malware checks for the existence of roots SSH known host file and a corresponding public key if these files are found in Roots SSH directory non-hosts are enumerated in a loop and a copy of the installation script is run on each of the remote hosts found this ensures propagation of the malware

in a warm-like fashion and could result in an organization's entire Cloud estate being rapidly compromised so now that we've covered some of the notable capabilities of ABC bot let's discuss an unexpected finding that emerged during analysis of the campaign when analyzing ABC bot we were initially under the impression that we were analyzing a relatively new malware family continued analysis revealed that this malware had a longer history than we initially thought so back in late 2020 Cisco's Tyler security research team reported on an emerging Cloud cryptojacking malware campaign the name's Anthony was originally discovered after an intrusion was found on one of Talos docker honeypots so we discovered a link between ABC but and Zante when conducting analysis on

the infrastructure behind the ABC bot campaign once we began comparing samples from both campaigns similarities and features and capabilities began to emerge additional comparison of the codes used in samples in both campaigns further confirmed their suspicions so before discussing the similarities between these families let's have an overview of xanthe itself xantha is a family of cryptojacking malware with the primary objective of hijacking system resources to mine the Monero cryptocurrency in order to main Monero On Target systems the common open source minor XM rig is is deployed so similar to ABC bot Zante also spreads via exposed Docker API endpoints with an initialization shell script responsible for propagation Network scanning and downloading of additional payloads xanthi's additional payloads included an

open source library for hiding processes script to disable Security Services and kill competing Miners and the XM reg binary itself so if you're paying attention to the previous section of this talk then this will probably sound familiar too so let's take a look at some of the signs that demonstrated these campaigns were linked in the report published in late 2020 Talos researchers commented on the coding style present in this anti-scripts they analyzed they highlighted that in the samples analyzed function declarations were located at the top of the script and function invocation was conducted at the bottom Tyler suggested that this likely aided testing of new iterations with function calls commented or uncommented as necessary so although this is of course a fairly

tenuous link it's interesting to note that samples from the ABC bot and Santa campaigns both followed this convention so diving deeper into the samples themselves we see several of the functions in Zante have an identical name to those in ABC but some of the functions also have the string go appended to the end of their names and this is another convention that we observed in both campaigns so we identified five functions with identical naming that you can see on the slide here subsequent analysis of each of the above functions was performed and they were determined to be semantically equivalent so these functions were mainly responsible for adding public DNS servers to resolve.com to ensure outbound DNS requests could be made

registering persistence via cron and RC Scripts creating and modifying iptables rules as we saw earlier in our analysis of ABC bot and downloading of additional payloads such as those used to connect the machine to the botnet in ABC Bots case and the downloading of the XM rig in xanti's case so we mentioned earlier the propagation via numeration of known hosts was a notable capability of ABC bot this exact same technique was used in the samples of xantha we analyzed albeit with a slightly different implementation examples of the codes responsible from both campaigns can be seen on the slide similarly in ABC but a number of malicious users were added to the system to facilitate a back door

the users added to the system were identical in samples from both campaigns and included usernames such as logger Cecil system and Auto updater both ABC book and xanthe searched for and removed hard-coded users when analyzing ABC but we originally believed that the usernames been searched for were from competing campaigns however we now believe that at least one of the usernames search for by ABC bot was from a historical campaign from yesterday actor the username in question was opsec underscore X12 and both at ABC bot and Zante included code to remove this user when we first analyze samples from xanthe we realized that this username was being displayed as ASCII art at the top of one of the payloads

so while this could of course be an attempt by one threat actor to copy another we believed our prior findings indicated that this was more than coincidental so now on to our final and most interesting finding although each of the similarities we've discussed were enough to give us reasonable suspicion that these campaigns were linked we still had some doubts so code readers is of course common amongst malware developers with payloads such as shell scripts where everything is in plain text copying is even more likely so in light of this we needed one final piece of evidence to conclusively link the campaigns we already discussed a function from ABC bot named iptables Checker which was responsible for configuring iptables to

allow Ingress traffic from a non-standard port an incredibly similar version of this function was also found in the xanthosample we analyzed not only that but rules used within this function to allow traffic from the C2 server included the exact same IP address in both Sante and an ABC bot so the lanes from payloads in both campaigns that demonstrate this are viewable on screen so to us this constituted an overlap of infrastructure which was fairly strong proof that the campaigns were linked the server at the hard-coded IP address would have to be under the control of the developer behind both ABC bot and xanthe for it to be usefully included in the script of course there would be little reason

for the developer to include this if it wasn't a part of their own infrastructure so we believe that this is the strongest indicator yet that these campaigns are linked and at the same today actor is responsible so in summary the ABC bot and scientific campaigns demonstrated this sophistication of malware developers in the cloud security space although code reuse is common in malware particularly malware involving shell Scripts we've highlighted an overlapping infrastructure an identified reuse of unique strings which would be difficult and or pointless for someone to copy if the same threat actor is behind these campaigns we believe that this indicates a shift away from cryptocurrency mining which is of course a common objective of

cloud malware and the main objective of xanthe onto potentially more destructive botnet activities as we highlighted with ABC bot so this should give you some idea of the destructive potential of cloud3 actors if they decide to broaden their Horizons from cryptojacking that is so I know that the title of this talk is a tale of two malware families but since the two families discussed in the talk are relatively old now I wanted to include an example of something recent which fits with the theme of the top I also thought it would be a good idea to give some tips to Defenders who may be concerned about preventing or detecting this type of threat in their

environment so this snippet is from a recent campaign from the threat actor Watchdog who targeted our honeybot infrastructure it utilizes a similar time stomping technique as we saw in the overview of Coinstar but and perhaps more interestingly we can see the attackers implementing a very rudimentary albeit effective process either first the binary for PS is copied to another file named P.S lanigiro a very simple shell script is then written to bnps the sole purpose of which is to call the renamed PS binary and pipe the output through an inverse grip to filter out processes with the names with the strings ddns and scan in the name so as you may expect from this ddns and

scan are two malicious processes run by the malware amazingly this actually works and it's perhaps the most unixy process I don't have ever seen in my life so more importantly this demonstrates that you don't need fancy root kits to have effective detection evasion so this was another simple but very effective but effective technique Sorry by employed by Watchdog for hiding artifacts on the target system so when analyzing their payloads we saw multiple references to paths containing directories that were named with three full stops or an ellipsis so it turns out that this name is perfectly valid for files and directories on Linux systems and has the added benefit of looking similar to the two dot Alias for The Parent Directory

and long listings so as you can see on the screen here the Ellipsis directory is hidden and could easily be mistaken for The Parent Directory by an unsuspecting admin obviously this wouldn't feel proper EDR Solutions but include computer instances or containers where you may be manually investigating a breach this is the kind of thing that could be easily overlooked so we briefly touched on this technique when we discussed Coinstar but it's one that seems to be a favorite amongst Cloud 3 actors in this screenshot we can see existence checks for a file named cd1 this is actually a version of Karo that's been renamed in order to obvious get its usage the malware then sets an envir with the

path to the renamed version of Karo so that any attempts to retrieve additional payloads make use of cd1 and not the current winner itself it's difficult to see just how effective this would be but suppose if you're monitoring for invocations of Karo then it's a way for the attacker to avoid generating an alert this technique has also been observed when obfuscating usage of other data transfer utilities so for example W get not only that but we've observed it being utilized in campaigns from Watchdog rock group team TNT and so on so moving on now to some tips for anyone fortunate enough to have to defend against these types of attacks so first things first make sure you have

the basics covered remember Cloud today actors don't typically make use of advanced zero days or nation-state level tooling although their attacks are increasing in sophistication they still have more in common with Homer than they do with Chris Hemsworth in Black Cat so in terms of Basics ensure that you've got proper auditing in place in your hosts or containers and you're not exposing services to internet on this Saturday of course Docker and redis are still some of the most common infection vectors in Cloud attacks we actually got an idea of how common it is to exploit these Services when we deploy to hadaka Honeypot that was first compromised only 12 minutes after we put it up

so watch for new additions to user bin or bin directories both campaigns described today relied upon the renaming of binaries under these directories survey detection if you monitor for rights to use urban or bin you'll easily be able to identify when this occurs and Trace the usage of the renamed utilities so thirdly Implement a vaccine host most people probably know to do this already but Cloud today actors rely heavily on SSH propagation so if you have a known host file on your host with IPS of all the other hosts in your organization this ensures rapid compromise of your Cloud estate if you're targeted by some of these campaigns so ensure adequate CSP logins in place

this is of course an obvious one but it comes up all the time Cloud malware campaigns are successful partly due to misconfigurations in Cloud environments but also largely due to the lack of visibility The Defenders have into resources in their estate a comprehensive csb logging strategy can help with this so finally monitor for execution of the touch binary using touch to modify timestamps on a file isn't of course an everyday occurrence if you see execution of touch particularly when combined with the dash t or d options then it's a good indication that something strange is going on so I'd like to wrap up now with a note the incident response in the cloud is hard and hopefully this is giving you

some knowledge of techniques currently in use by Cloud native three actors if you're interested in this type of thing here are a list of references that we used when conducting This research so as you can see here there are blogs from netlab 360 Talos unit 42 Etc these organizations are all well worth following if you're a fan of cloud security research or you work in this area I've also included the blogs that we published which detail This research and you can find many more on the blog section of our website at catoscurity.com blogs so I hope that you all enjoyed the talk and of some idea of the techniques currently used by cloud3 actors as I mentioned in the beginning I'll

post the slides afterwards if b-sides don't do it first then please feel free to reach out to me if you want to discuss any of this further so I can be reached I am your kadoscurity.com or Matt Muir on Twitter so I think we've got some time for a q a session now so if you have any questions about Cloud security or the content in the talk then please let me know otherwise I look forward to seeing you all around Vegas for the rest of black cat and Defcon foreign

so they won't be on the blog but I can post them publicly I'll post them on Twitter after after the talk most of the screenshots that were used in the slides come from the blogs so if you're interested in that then check those out yes

yes so you're not actually the first person to ask me this um we didn't actually do that but it's something that we probably will look into in future does that answer your question

yeah yeah I mean my background's in malware analysis so my focus really is on the payloads itself quite often but yeah I would agree that it's definitely a key part of of the puzzle any any more questions at all

cool thank you