Rosetta 2 Keeping Mac Malware Alive for Years to Come

I'm currently a cyber security structure instructor at LSU and I've also co-founded a public safety software company that also does some cyber security and I'm also a former software my name is Rafaela mechig I also recently got my master's degree from in computer science from Louisiana State University where I now work as a researcher with the applied cyber security lab and in the past I've also done I was I worked as a cyber security analyst for a handful of companies all right so for our research motivation and importance as the name of this talk implies our research largely focused on malware everyone here is aware of how destructive and costly malware can be but it only continues to become more so the average data breach now comes at a cost of more than four million dollars to the company and ransomware earnings last year were in excess of 600 million so despite the obvious impact and cost of malware we haven't seen very much technical research in this space on Apple silicon um so this is also despite the fact that we've seen in the wild actual binaries compiled with code for M1 with just one such strain infecting over 30 000 Mac OS endpoints so it's also important to look at new technology through the lens of an attacker so considering known uh techniques as well as already compiled malware that may be able to be reused thanks to Rosetta 2. arm 64 considerations such as needing to update your dependencies to arm 64 as well as your code needing to validly sign in order to run arm 64 slices at all and then also needing an arm64 machine so Apple silicon to actually debug those code slices may actually make it preferable for malware authors to stay on Rosetta 2 or stay on Intel and just let Rosetta 2 handle the translation itself um so assuming that malicious actors can and will use Rosetta to to their benefit it's also important to identify novel forensics artifacts that incident responders may be able to use in an incident to figure out what malware ran when it ran and even you know how it ran whether or not it ran through Rosetta 2. so a final motivation related to This research was the nature of the apis chosen so spyware has obvious privacy implications and memory only malware continues to be difficult to detect even for forensics analysts and it's also important to look specifically at malicious capabilities associated with userland rather than just the the kernel level capabilities that often overshadow user land in the research so now we're going to dive a little bit into the background that's required to understand some of the work that we did and we're going to start off with what exactly is Apple silicon so in late 2020 Apple announced that they were going to start rolling out their own processors which at the time it was the M1 so the M1 is a system on a chip so not only does it contain your CPU it also contains your GPU your Universal memory uh secure n club and all of those components integrated within a single ship now a lot of uh one of the biggest changes that they announced that came with the M1 was that they were changing the architecture from Intel x8664 to into arm 64. now this is not the first time that Apple has announced that they were going to switch architectures so in 2006 they announced that they were switching away from in powerpc into Intel architecture and then from Intel now now in 2020 they announced that they're switching away from Intel to arm now the thing about changing your CPU architecture is that all of the software that is able to run on that architecture will not be able to run on the new architecture because when you change the CPU you're changing the entire instruction set with which that CPU is able to run that software and so I'm not a business Expert but telling your entire customer base that the software that they've spent thousands of dollars on will not be able to run on future iterations of your product it's not a very good business model right so with that in mind Apple decided to make sure that there was some compatibility after they transitioned into the new architecture for a couple of reasons so this would allow some time for current software developers uh to roll out uh Native applications and adapt to the new architecture but the having Rosetta it would allow to for software that relies on older dependencies to still run right so there are essentially two main ways that you can run Intel code on the M1 so you have Universal binaries and you have Rosetta 2. with the universal binaries so universal binary is is Apple's version of a fat binary which contains compiled code for two different architectures in this case and which gets combined into a single binary and then at runtime the operating system will decide which code slice to run depending on the uh whichever matches closely the architecture so one thing that can be noted is that with the universal binaries you can actually even though you're running it on M1 you can default you can force the execution of the Intel slice and some scripts will only uh will already just straight the fall tube Rosetta two now with Rosetta 2 that's the other way that you can run Intel binaries and what exactly is it so Rosetta 2 is a dynamic binary translator so whenever what that means is that whenever you run an Intel binary for the first time it will be translated into arm that's going to generate a new arm equivalent binary and which is our DOT aot files so these aot files they will be stored in a specific folder that is protected by System Integrity protection which means that even if you have root access you're not able to see this uh this directory so you would have to reboot the machine and disable Sip and then reboot it so that then you can actually access the directory another thing about Rosetta is that it does not come pre-installed so whenever you try to run an Intel binary for the first time you'll get a prompt asking for you to install it and then you'll never be prompted again and lastly Rosetta is capable of translating most Intel based apps with the exception of virtualization software or kernel extensions here we have two screenshots of what the oah directory which contains all your aot files looks like so we disabled Sip and we were able to view all these files so at the top we have the top level directory of the oah where we have a directory at the top with with all the numbers and there those contain subdirectories which contain your aot files and then we have an oah version file which contains Rosetta runtime information and then at the bottom we access that that other directory and you can see all the subdirectories that contain your aot files and then here we have a test program so this is the VM app output which is it's the equivalent of proc map on Windows if you're familiar with it that shows the process mappings in memory so you can see we ran a test program that was compiled for Intel and you can see all the references to the aot file the to the aot file in memory and also to the Rosetta engine running as well all right so getting into some of the previous work that's been done in this space the work that most closely relates to ours is that that was done by KO nakagawa where he was examining Rosetta 2 and specifically looking at it for potential exploitation um so while he was doing that he ended up reversing the Rosetta 2 runtime binary detailing how to um debug the emulation process at the rm64 level as well as patch engagra to actually correctly disassemble aot files where it did not before the corellium research team was able to get Linux running on M1 chips in order to do this they had to understand and Implement a lot of the sort of Hardware programming chips or tricks that were used on Apple silicon so for example the custom interrupt routing that Apple uses for their apple silicon chips needed to be implemented in the Linux kernel by the corellium team in order to actually make this work properly so Zach Ops was able to exploit m1s using a historically vulnerable arm-based i o kit driver that was included on m1s and essentially led to a race condition being possible that led to exploitation so over the years there's been a lot of great analysis of Mac malware binaries done on Intel most notably would be Patrick Wardle and his security blog Objective C his book The Art of Mac malware and then his security conference that happens yearly objective by the sea that are all largely on Mac security and Mac malware so looking at malware analysis on Apple silicon binaries specifically as the number of samples grows in this space we're going to see more and more reports coming out some of the notable ones are Red Canary exposing and detailing silver Sparrow which was that Max sample that I mentioned earlier that infected over 30 000 Mac OS endpoints that had an M1 binary within it Google's threat analysis group looking at cdds which was it was essentially a watering hole campaign attacking pro-democracy Hong Kong websites that also included an M1 binary that they detailed and then Patrick Wardle analyzing go search 2022 or 22 where he was looking at the anti-analysis arm logic associated with that M1 binary foreign so moving into our analysis goals we had two main analysis goals that we were attempting to accomplish we wanted to test Which Intel compiled samples would still work on the M1 and analyze those that did not go correctly and see if it was because of Rosetta 2 and then we also wanted to look specifically at specific apis within the objective-c API to see if they were still going to work through Rosetta 2 and how they would work so starting with running Intel binaries on M1 and on Apple silicon so the environment that we used that we set up in order to do this was using parallels so that was the virtualization software we used there was essentially no virtualization software that had support other than parallels so VMware wasn't an option nor any other products so parallels is what we went with the VMS were Mac OS Monterey 12.2 a couple notable things about them is that snapshots were not a feature and still are not a feature with their M1 VMS so if you've ever done any malware analysis especially Dynamic analysis you can imagine how much fun that was to deal with um another notable thing is that sip had to remain enabled uh so in order to disable sip you need to boot into recovery mode and do it from recovery mode but there's no way to modify the config options or the boot config order associated with M1 VMS on parallels or well it's actually not true you could do it but you would need to modify system files to do it so you would need zip to be disabled so there's like a really nice catch 22 there that just makes it not possible um but there was only one uh sample that we tested that actually was affected by this and I'll go into a little bit more about what I did there um and then the host was a Mac OS Monterey 12.2 and then the one sample that was in fact or was affected by System Integrity protection remaining enabled uh was actually run on a 12.1 Mac OS host that just had networking totally disabled all of the VMS were pre-installed with Rosetta 2 command line developer tools and Wireshark Rosetta 2 for obvious reasons command line developer tools because a lot of the the malware relied on functionality from those and then Wireshark to perform some some network analysis and then the way the networks were set up uh so parallels has three main networking modes uh host only network is the only option that actually allows you to isolate the VM and take it offline um and have it be basically within its own subnet so that was the mode that we went with uh it also served its own DNS which was not ideal but still allowed us to view the DNS queries that were going to be coming out of the malware the the classic way to actually set this up is to have multiple VMS within one like VM net on VMware where you would have one of them acting as the DNS for the other so you would have like inet Sim or something running so that whenever the malware made connectivity pings it would get 200 get 200s okays back and the malware would continue with whatever functionality it was going to do any attempts at that only resulted in frustration on parallels with M1 so the the best we could do was having observing DNS queries but having those connectivity pings ultimately fail the malware ending its functionality uh there so moving into the malware selection the criteria related to it how functionality was determined and where we ultimately got the malware so the first and foremost thing we were looking for was clear indicators of compromise so uh you know either C2 or other connectivity pings coming out of the malware launch agents or other persistence mechanisms so launch agents are the most common persistent mechanism on Mac OS they can be used for anything from watching a directory and then whenever that directory's contents change something happens or having set intervals on which a job runs or even every time a user logs in a script is run so launch agents are are really popular for persistence there and we we see a couple of those with the samples tested and then information harvesting so any credential harvesting looking for passwords looking for running processes any enumeration of that in-text files that would then be exfiltrated out all all things of that nature fall under the information harvesting umbrella for us recency was also considered so cdds which was the one that was analyzed by Google's threat analysis group is one of the samples we tested that had both a 2021 and a 2019 installer associated with it the 2021 version was what was tested the impact level associated with it so silver Sparrow the one that affected 30 000 Mac OS endpoints was an obvious one there and then we also wanted to look at the viability of the attack Vector we wanted these to be attacks that still posed a real threat to even M1 users so that if Rosetta 2 were functional and did translate this malware it would be a real viable attack Vector that M1 users could be infected by this Intel based malware so what we get when we add all of that up is recent high impact malware that can actually affect M1 users today about 150 samp samples were looked at and only 16 were determined to be a part of our testing from that 150. so we tried to be selective we tried to pick good samples um and then the functionality that was determined was just using the iocs that we mentioned and there's a little bit of a caveat there that without too much help I'll get into some specific samples and and the ones that we determined were non-functional and how I determined that and then all of the samples that we used were obtained from Objective C the objective-c blog maintains a repository of malware so if you see any of these samples and you're curious to try them out yourself or you know pick them apart see how they work that that repository is a very good source and and we'll have all of our samples discussed so looking at the security mechanisms for Mac OS this is useful because in part the results that we report on are what security mechanisms all of the malware encountered so briefly looking through them with file quarantine essentially the way that the flow works for that is when you download a file from the internet Apple markets it with the com.apple.quarantine flag and then any file that has that flag when it's Run for the first time uh essentially a dialog box box pops up it's probably one you've seen before this file was downloaded from the internet are you sure you want to run it you click yes the flag is removed and it runs this is often pretty easy for malware to get around if the initial stage is already on there because using like other FTP protocols or even curl is is simple enough to get around that quarantine flag so anything that comes in with curl or another protocol is going to not pick up that quarantine flag and be able to run straight away without user interaction so gatekeeper was the next one that they tried since you know file quarantine ended up not quite being enough with gatekeeper the idea was that only developers that were validly signed by Apple would be able to run their software on a Mac without any user interaction so the thing about user interaction though is that social engineering is easy enough you can ultimately get users to override those check boxes easily enough and developer IDs ended up being easy enough to obtain illicitly so they introduced notarization as a third mechanism where when the apps are notarized they're only going to be notarized when they pass checks related to malicious content being a part of a binary or code signing so actually having a valid signature associated with gatekeeper and if you pass both of those you're considered notarized and again can run without user interaction but unnotarized apps like with file quarantine are going to result in a dialog box asking the user if they're sure they want to run that application because essentially Apple can't guarantee your security there and the final one that sort of has been developed while all of these three mechanisms were being introduced over time was their ex protect malware protection mechanism so it uses Yara scanning essentially just looking for known malware that's going to be a part of like the X protect sets of Yara signatures uh so it's not going to detect novel malware and we'll see in a little bit the results that it actually doesn't do a great job of detecting even years old malware and it also can be overridden for applications via checkbox but for executables or other file types it's actually going to need system Integrity protection disabled and to be disabled altogether through the command line so looking at the malware and what was determined as functional or non-functional and initially looking at the security mechanisms so the first thing to note is that 11 out of 16 were functional basically out of the box and we'll get into the specific behaviors that made them functional but they would encounter one maybe two of those security mechanisms that required interacting with the dialog box and then would work so they were essentially one social engineering campaign from working the next thing to note is that with malware protection all of the samples tested when they were tested at the time were at least three months old but only five out of 16 samples were actually fingerprinted by xprotectus malware and as mentioned in the the obtaining and selection of the malware these were all high impact samples that were very notable for their time so it was interesting to see only 5 out of 16 be picked up by xprotect um so looking at the specific non-functional ones and whether or not uh Rosetta 2 was the culprit there so apple juice slash Mac loader its initial stage was caught by gatekeeper and then its second and third stage didn't deploy at all even after allowing it through uh gatekeeper so it needed to actually have its uh its file extensions changed and then given executable permissions and then eventually ultimately ran and functioned technically through Rosetta 2 but it was non-viable to the point that it was put in the the non-functional malware and you'll see that as a trend with these that are part of the non-functional malware all of them except for crisis could have made it into the functional malware category if it were not for that viability category which means that 15 out of 16 samples essentially function through Rosetta 2 and so the 11 out of 16 that we're looking on the left side are not just ones that Rosetta 2 allowed to function but ones that were so effective that they actually are viable even on M1 systems and will work straight away so moving on to crisis the reason that that one didn't work was simple enough it was an i-386 executable so it was 32-bit Intel and Rosetta 2 doesn't translate 32-bit In