Malicious DLL execution using Apple's APSDaemon.exe signed binary

[tr4cefl0w]

This is going to be a short an easy one. I’ve been very busy lately and wasn’t able to keep working on the Python malware tutorial I but figured that might be useful to some of you.

This is a simple malicious DLL execution using an Apple’s signed binary. However, it doesn’t qualify as a proper signed binary proxy execution (according to MITRE ATT&CK Matrix but whatever) as it’s not part of the operating system. But, for that same reason, it can be very useful to misguide and fool monitoring analysts (especially the less experienced ones) into thinking that the execution is legitimate, unlike, let’s say using rundll32 which isn’t signed and suspicious most times when executed by itself.

The only caveat is that you have to drop both the malicious DLL and APSDaemon.exe on disk, but, if you were able to get a shell somehow or execute code on the machine using phishing or drive-by install, this won’t be a problem.

APSDaemon.exe is Apple’s Push Notification service binary installed by iTunes. I tested a version from 2011 and a version from January 2019, and in both cases, it works. It doesn’t seem to be reported, not publicly at least even though it’s been around for a long time. That said it’s not exceptional, I’m pretty sure it’s common with many signed binaries that don’t use proper mechanism to check the integrity of loaded libraries.

Here we’ll use the binary created and signed on January 15, 2019.
SHA256: F0B2EDBC23DD0DD0ADED9EE5F14985EB2FBF7E03A1FE86A5598DE58CA729E52D

If we open the binary in IDA and search for strings, we see an AppleVersions.dll.

If we follow xrefs to that string, we ultimately end up on that DLL’s import table being pushed on the stack.

This is followed by a call to a subroutine that we can safely assume will load the DLL in memory. If we look into that subroutine, we see further down a call to LoadLibraryA. We can set a breakpoint there in IDA or any debugger (I prefer x64dbg) and validate that it does load AppleVersions.dll.

As you can see there are a few problems here:

• It doesn’t require a fully qualified path for the library to load as it should to avoid being abused
• It doesn’t implement SetDllDirectory using "" as lpPathName to remove the current directory from the search order.
• The original AppleVersions.dll is digitally signed, yet APSDaemon.exe doesn’t use the WinVerifyTrust function to verify the signature.

So let’s use this to execute malicious code. I first tried using a simple C# reverse shell but no luck. GetLastError is called and an exception is raised. We can identify the problem by looking at the value returned by the function in the eax register. In this case, 0x7F is returned which is the system error code for ERROR_PROC_NOT_FOUND. It looks like LoadLibrary loads the DLL but cannot load the sections.

It was late and didn’t want to waste time figuring out what went wrong so I figured I’d try a simple reverse shell in C. Because I suck at C, I took a code sample from here and compiled it to a DLL with cl /LD shell.c.

Then, after renaming it AppleVersions.dll, if we drop it in the same directory as APSDaemon.exe and start listening on the attacker’s machine, we get a reverse shell executed through a signed Apple binary.

To make it look more legit, you can also rename APSDaemon.exe to something like iTunes.exe. Obviously, in real-life situations and to avoid detection, don’t use an existing payload that can be found on GitHub. Make your own.