Atomic Stealer's Dyld Injection Tactics

So first up uh for the afternoon session we have a talk from Tom Noi Jitu on uh atomic steelers DLD injection tactics. So please take [music] away Tomoi and welcome to the stage.

>> Thank you everyone for showing up. So today's presentation is going to be on Mac OS dynamic load library injection attacks and we're going to focus specifically on the atomic stealer malware. So starting off with who am I? I'm Tonmo. I'm a thread researcher at Sofas. Also a first-time speaker. And my interest lies in thanks. And in terms of my interest, it lies in finding files which usually go undetected. So usually have a detection of zero. So the malware has been seen in the wild for the very first time. Also interested in breaking down malware binaries and hunting for anomalies in logs. So in terms of today's agenda, we'll cover the current landscape. We'll also

talk about the Ty injection. We'll then move on to atomics dealer, the attack chain, the anti-analysis technique it uses. Then we'll move on to the capabilities and some close it off with some detection strategies and the current exposure. So let's start off with why this matters. So if you look into the current uh Mac OS landscape, the Mac OS enterprise adoption is increasing almost every day. You also have new malware families emerging almost daily or weekly. And in terms of detections, back in 2023, we have seen a massive rise of over 60%. In terms of current vectors, these are usually deployed via social engineering of fake installers. You also have supply chain compromises and also have

legitimate app abuse. in terms of some telemetry. So in the last seven months, if you look into this slide, this is the overall malware being deployed in Mac OS infrastructure OS. And if you look into the blue uh bar stack, you can see that's the info steeler bar stack. And over the months from March to September, the bar has been rising on and on. So this is only the trend from the current year, but it's still going and increasing almost every day compared to other malware families. So for this presentation I'm going to talk about this specific AMOS sample which was first submitted to Virus Total on 3rd of March um which is the day I

started reversing engine started reversing the binary and working on it. Uh why this is important is because this specific sample uses anti-analysis techniques. It also has multiarchitecture support active C2 infrastructure and also bypasses the basic security measures. Now one of the curious thing that got to me is if you look into this chart there is a dwell time between 3rd of March to 20th of March. So between 10 days the sample was showing up as zero detected. Now there could be many reasons for this one. The first reason being when the sample was submitted and until 20th of March someone or something didn't really press the reanalyze button which is why you suddenly have a pop-up of 20 vendors

detecting it. So if you're an analyst who please do not rely on VT vertex but if you do rely on VT vertex please click the reanalyze button because you'll get the new uh engines that are detecting on this one. Another interesting factor because the when it was first submitted it was run a static analysis but engines also detected on behavioral analysis. One important thing with this sample was this one specific line of code. So if you go to VT right now and look into the behavioral analysis section, this line of code what it does is it checks if the infrastructure of the virtual machine is either Kimu or VMware. So if it detects that it's if it's either Kimu or VMware

and once it's detected it go like okay I'm I'm running on a Kimu or VMware I'm going to exit myself. So when you look into the behavioral analysis you don't really understand or see what happened afterwards. So the malware stopped running and virus total go like okay this binary doesn't really do anything it's just a benign binary which is why this was quite interesting. Now let's move on to dynamic load library injection itself to understand the technique better. So in terms of mechanisms this particular injection method use can be used in three different ways. It can be used using environment variables. It can be used using binary modification. It can also be used using runtime

injection. For this specific talk and this sample, we're going to focus on environment variables because if I go on talking about all the other methods, I think I'll have to do a three-hour presentation, which is not ideal cuz we all want to go home. So, moving on to the environment variables. This is the official definition by Apple, which was super hard to find cuz I actually had to scrape it off the web archive because you don't really find this definition anymore and they have changed it. So starting with the definition, it's has a lot of buzzwords and stuff like this is a colon separated dynamic libraries to load before once specified which when you read it you're like what is this

talking about? Also uses fancy words like dyld force flat name space. So let's make it easier. What it typically does is it has an environment variable and it sets the dyd inside libraries value to a malicious pathway. For those of you who are not aware of what an environment variable is, it's pretty much in a host machine. It's like a shortcut that tells you where specific files are. So typically an injection command would look like this. You have the environment variables set to the malicious library pathway. Then you would run or pass a benign application, for example, calculator. And when calculator would launch, instead of running on validate libraries, it will go and find the

malicious library. in terms of the process flow. So it starts up with the application launch then you have the load library being initialized and once the library is loaded the symbols are resolved and the process is executed. So if you're wondering okay libraries are being executed what is Apple doing about this one? So Apple does have existing mitigations that it has been developing over years and they're still working on it. So the first one is SIP which is the system integrity protection. This pretty much blocks modification of any and all system paths. So it reduces hijack opportunities. Then you have gatekeeper. You'll hear me talk about gatekeeper a lot here which is quite important. So

what gatekeeper does is it checks code signing on downloaded apps and blocks on-site and untrusted applications. Then you also have hard harden runtime which enforces library validation. So make sure that only valid libraries are allowed to la run. Then notorization is there which blocks unauuthorized code. And you also have entitlement restrictions which limits risky entitlements. And in this case, the one we're going to focus on is the alli allow dyd environment variable. So let's move on to atomic stealer. So looking into the atomic steeler memory, it targets all Mac OS uh OS. And in terms of architecture, it supports both Intel and ARMbased architecture. And the goal of this malware is pretty much to steal credentials. and if it

finds any crypto keys in the wallets and the delivery methods is usually via DMG installers. So the infection vector would pretty much look like either via fishing campaign or via malvertising. So you'll have little popups on Google browsers with sponsor ads and it usually would ask you to download fake software installers which you would use almost every day and it ask or prompts the user to open the application by using rightclick which performs execution. In terms of the architecture as previously mentioned for platform support it supports both x86 and ARM 64. So it doesn't matter whether you're running the old Intel or the new silicon, it's going to work on both of them. In terms of binary

characteristics, it has universal binary format. For code signing, it's usually non or invalid. So it uses fake code signing or runtime code signing and it requires a gatekeeper bypass. Okay, let's talk a little bit about gatekeeper because you have almost heard me talk about using the word gatekeeper a lot. So as per Apple's definition, it ensures only trusted software runs on Mac systems. It verifies that software which are not in the app store are from an identified Apple developer. It also confirms Apple notoriization and detects unauthorized software modification and requires user approval for first time use which is why gatekeeper bypass is required in this case. Moving on to the actual malware or the malicious binary of what it looks like.

It usually looks like this when you first open it. So it pretends or impersonates to be a benign application. For example, you can see on the first one it's a Chrome application and it actually gives the user instructions on how to set it up. So it tells the user right click on the icon and click open which is one of the form of gatekeeper bypass and all because it's a DNG file there are compressed files. You can actually extract the DMG files and look into the underlying internal files inside it. So the first screenshot at the top is the folder structure. You have the macro files and all the meta library resource files. If you run a file on the macro

file itself, you can also see that it supports both Intel and ARM 64. And also with all reverse engineering, I think the first thing we want to do is run strings on it because why not? Let's get some IC's out of the way. So when you run strings on it, you can see it's almost encrypted and you can hardly read anything that's actually readable code. For the core components, you have the DMG installer which acts as a dropper and if you are running it on your host machine, it would look like this. You will double click on the DMG file which is the second screenshot. It also performs uh VM debugger detection to make sure any anti-analysis techniques

are not there. then it goes into data collection and communicates back to the C2. Okay, let's understand the process flow of how this is actually injecting the binary. So you have the stager app which is the DMG file. So once it runs it adds shell codes to the macro binary. Then it runs two processes. The first process is the parent process which is benign and the second process is the child process which actually calls the malicious library and executes and injects the dial library into it. So when I was reverse engineering the sample this is what it looks like when you open it in binary ninja. So you have multiple functions that it's using but

one of the most interesting one that I found was the self-sign function which is generating XML based entitlement files. It's also enables DYL environment variables for injection. It disables page protection so that it can inject it can modify the memory space for injection. Also, it uses another function named mask process name which kind of gets benign processes which are already running in your machine and pretends itself pretends a child processes to be named as that. I know the screenshot doesn't make sense cuz we're all all not reverse engineers but if we look into the XML based entitlements this is what it looks like. So this XML based entitlements is actually being saved in the temporary

folder and you can see it's getting uh it's getting over permissive entitlements and self assigning itself with those entitlements and one of the most interesting one is the one in the middle which is the alli allow dyt environment variables which is why it's saying that okay I'm going to allow every any and all environment variables that I find in the system to run by this binary. So if you look into this stage a little bit more, here is where it does code signing because you do need code signing to be there for any binary to be run on a Mac OS system. So it runs and grabs the entitlements from the temp directory where it saves it and signs the binary.

Next up is masquerading the process itself. So the self-sign function would go ahead and call the mass process name and grabs one of these four hard-coded process names from the host environment because these are all benign processes. You have networker, helper, security agent and system events. So it'll act like one of this processes and run it as a child process. Also uses OS script to run all this stuff. So moving on to the attack chain. So you have an initial uh infection which is the DMG file itself where the file system is loaded. So this is a high level attack chain and it does self modification via process names. It also performs dyd injection which is the

dynam dynamic load library infe uh injection creates persistence then communicates back to the C2. In terms of what the operation would look like, it would take a screenshot. Uh it would perform command execution. Also does data expiltration and perform cleanup and stuff. So it goes through a constant loop of checking okay do I need to perform more persistence and capture more data. If not at the end of the process it would perform cleanup. If we look into the attack chain in more detail. So there are seven phases of this attack chain. The first one is the initial compromise where you have the malware delivery itself and after the malware delivery the file file is written to the system or downloaded to

the system then it goes into phase two which is self modification where it does code signing bypass it adds itself entitlements which is the permissive entitlements sets itself as hidden. So you have the terminal which is running in the background which is hidden and also does kind of process allowing by uh disabling memory protection so that it can write itself in memory. For phase three it goes into process masquerading. So it finds a random process from one of the selection of four and launches it with a spoof name. After that, for phase four, it does dyld injection where the dyld environment variable is set up using the dyld insight libraries. And for phase five, it performs

communication back to the C2. So you have CD communication being established, it also uses a user agent. And in terms of phase six for operational activities, it does screen capture every 5 minutes and transmit that data back to the C2. It also does command reception and execution to maintain persistence. Also performs process hill check to make sure the process is running properly. Then for phase seven which is the last one for cleanup, it does temporary file deletion, log tampering and memory cleanup. Now let's look into the anti-analysis techniques. So when you're running if you run this in a v virtual machine, it will go and find the system information and graph physical memory to start off.

make sure it's not a virtual machine. Then it also runs the same script which we have seen in the virus to uh file analysis which checks for if my virtual machine is either Kimu or VMware. I was indeed running in VMware but you can use LLDB to debug this in runtime and you can use break points and once it reached the thread which specifically checks for this virtual machine attributes you can set the thread to be zeroed out so that you can bypass that and go and extract the memory out. Um if you want to know how I did this I wrote a blog on this one so that tells you more in details in

terms of how I got the raw code out to understand the clear text code. So moving on to some stealth operations for this particular malware. So it sets itself as a hidden terminal. As you can see from the command, it sets itself to invisible. For file cleanup at the end of the script, it performs the typical RMRF. So it uh removes any and all sorts of zip files it would create in the temp directory. And also for a process name masquerading like I mentioned before it selects the four process names to make sure it known as a spoof process. For a file-based data structure uh it goes and finds any and all sorts of chromian based file

structures that it can find. It also looks for text files, PDF files, docs files because some users do have a tendency of saving their credentials in document files. I still don't know why it's a thing right now. Um then moving on to it also goes and look for SQLite files because Mac OS is heavily database formatted. So it grabs any and all sorts of database SQLite database that it can find. In terms of cryptocurrency or crypto theft, it has hard-coded extension names. So these are all the extension names that it has hardcoded in the clear text code. it goes and finds okay if this wallet extension is there in the browser grabbed all the wallet keys that

you can find. Then in terms of system intelligence it also collects hardware information any installed application that the host would have and on the other screenshot you can see it also checks if the user password is valid. So it has functions that grabs the username and password and checks if the password is valid against the system itself. One interesting thing, it does have a collection limit so it doesn't go in and harvest any and all things in the machine all in one go. It sets itself to a 10 megabyte limit possibly because to bypass DLP or to make sure it doesn't get picked up easily. So it sets itself to a 10 megabyte limit which is pretty

small. So when it's transferring out data and it doesn't get flagged in terms of the C2 itself. So what it does is it uses curl and has a user ID uh which is not B 64 and also has a build ID. So the build ID is quite useful if you're a threat hunter to identify campaigns and variants. Um also sets itself to a limit of 5 minutes. So it will run any every 5 minutes and as you can see the file which was saved in temp directory named as out.zip it sends that file out. Now, one question. If you are an Amos developer out there and you're listening to the talk, I was wondering if you could message me

because it's 2025 and I do not know why you guys are using HTTP and not HTTPS. I mean, please use encryption. So, moving on to detection strategies. So, you have the typical detection strategies if you have access to the host machine itself. So you can use and look through the unified locks for networkbased artifacts. You can look for any artifact that has com.apple.net network or any one of the spoof names to find out okay what are those artifacts or logs look like. It can also monitor networkbased activities if you're running a dynamic analysis to make sure if there is any established connections to any public IP addresses which are unknown. If you have the process ID, you

can do a deeper dive using the process ID as well. For persistence, one of the main location is SSH. You want to make sure that they haven't created any persistence via any SSH keys. Also check for launch demons for auto starts. So you want you want to make sure those malicious DMGs or installers are not launching every time you turn on the machines. Uh the last command is a oneliner to go and look through any and all launch agents for file system monitoring for looking specifically for dyld environment variable. You can grip for dyld inside libraries but the first one you will get a lot of false positives because a lot of benign application use the dyld insert

libraries function. So it's pretty hard to grab out what's the malicious command and what is the good command. The other thing that helps is if you know the process ID so you can link together logs in uh the log files and make sure that those are related to dyld inside libraries. Also if you have open snoop installed make sure because in this case we know that the file being written out is odd.zip. So you can scan for okay what what binary or what application is writing out a file named odd.zip. And also because it's a info stealer it will definitely access your keychain. So you can look through the unified locks for okay what has accessed my keychain in

the last 24 hours. You can reduce it down to 30 minutes depending on when you think the process would have ran. In terms of process behavior analysis, you can use drust once you know the process ID. So these are good commands to keep in handy. Um, also enable Mac OS uh detail to logging if you don't have it enabled cuz this would be a a time for any analyst out there cuz you would have a hard time going through logs cuz there won't be enough. And to monitor for injection process specifically, you can use the log stream command which locks all dyd injection processes. Also, this will have a high amount of false positives. So you can use other commands

to come and streamline which are actually the false positives to the true positives. Okay. So for indicators of compromise in terms of a behavior if you think that you have been compromised by Amos or this specific variant check for dyld inside libraries usage in your logs. Also check if there are any binaries in your temp directory or hidden folders. check for C2 connections to random IP addresses which are not known in your environment. And one thing I found from a set of different v uh variants out there, some variants actually have dedicated ports. So it would call out to I still have no idea why they use ports like 999, 888. They're super easy ports

to spot out. So do keep an eye out for that. Check for process name mimicking for mimicking of Apple services names and also any temporary entitlement P list that are being created in the temp directory because these are heavily used for self-signing and allowing excessive permissions. So what does the current exposure look like? Uh dynamic load library in infection is not something that it's new or it's discovered this year. This has been there for a long time and it's still being misused. Um, this doesn't target all app store apps. It only targets non-h hardened third party apps. So if you have applications that you're downloading directly from the website or if you have applications that are not

hardened that you're downloading using home view, those are affected because those are the applications that use weak imports and insecure permissions. Also recent exploits which have been uh produced in via CVE in 2025 is the Dainci resolve and the fast CAD reader. These are actually video editors that are used by many people legitimate applications and you have dial hijack happening through this applications because when this applications were developed the it could access uh folders and it has over permissive permissions in terms of active tooling that are still working. You have spectre of ops mythic pose and c2 infrastructure which also uses uh dip hijacking techniques. You also have other tools like Mac injector automated and dive hijacking

toolkit which are still active and are almost getting updated every week. So in terms of my personal opinion should we be worried um in terms of attack infrastructure with the newer Mac OS stuff you don't have to worry about it cuz once you run the binary Apple will give you millions of pop-ups saying that this is malicious. So I'm going to quarantine it straight away. And almost all app store apps are hardened itself. This only targets third party and not hardened application. You also have SIP which prevents system process hijacking. So which is running all the time. But the thing is this doesn't run in kernel level. This runs it with host level privileges. So it ask you to give it

privilege so that it can run. So it bypasses SIP as well. Also like I mentioned this is almost targeted towards third party applications because they are not hardened or goes through the attack chain so much and attackers usually exploit this for persistence and escalation cuz you don't really need admin rights. Also in terms of this attack itself it's not very stealthy. So even if it goes undetected it leaves a lot of artifacts behind and with the behavior analysis it's pretty easy to spot out if something is infected or not. and also it's viable for specific or low privilege attacks on vulnerable applications. So yes, in terms of my own research blog, uh that's the link to my own

research and you can always go to the Sofos Mut research site where we publish about upcoming trends in different ransomware or different malware varants we find and also that's my Twitter link. So yes, thank you