Now I'm sure we've all heard the spiel "Mac's don't get viruses", "Mac AV is a waste of money" etc. but we know that's simply not true. This knowledge, however, doesn't help when you find yourself on an engagement desperately trying to reconfigure payloads because you've landed in the Design department and, of course, all the endpoints on your subnet are OSX.
Before I go much further, confession time: I have, and love, my MacBook Pro. Since switching to it a few years ago as my daily driver, I couldn't be without it, to the extent that I bought my own to use at work rather than use the Windows laptop provided.
So here we are, my go-to C2 is .Net based and while the control centre will run on OSX, with some cajoling, there is no OSX stager capability out of the box; enter 'Merlin' and 'Apfell'.
While I've experimented with Ne0nd0g's Merlin C2 on and off for a while, I actually very rarely find myself using it on engagements and I have no idea why. One of Merlin's key features is its ability to evade network detection by utilising the HTTP/2 protocol (which most tools are ill-equipped to understand or inspect).
Out of the box, setup is relatively simple. It's just a case of downloading the applicable server and agent binary from the GitHub repo (https://github.com/Ne0nd0g/merlin/releases). Once you've got the relevant binaries, you can spin up the merlin server from the terminal using the below command.
Similarly, agent execution is achieved simply by executing the binary on your target host with the relevant details of your C2 server.
And that's it - we have a remote shell on our OSX host.
While this is very simple to set up, this simplicity comes with its drawbacks. From an attack vector perspective, the need to drop a binary onto disk and the requirement for a URL flag makes it more complex to trick a user into execution via social engineering. Additionally, the pre-compilation of the agent means it is much more likely to be detected by signature detection, as shown by VirusTotal.
Straight away, we can start to address some of these issues. Instead of utilising the released binary, we can create our own from source.
In addition to providing a method for 'one-click' execution by hard coding the connection URL, this automatically drops the detection rate.
Unfortunately, not enough for the NextGen Sophos AV running on my Mac. At this stage, I would typically look at writing a separate dropper application as well as converting the stager into shellcode to avoid detection. This is both outside of the scope of this small blog and outside of my current OSX coding skills.
ApFell is a recent addition to my C2 arsenal, mainly due to it being directly targeted against *nix-based systems and not Windows. Fundamentally using a Web GUI frontend with docker instances running in the background, setup is achieved relatively easily via an installation script https://github.com/its-a-feature/Apfell.
On connecting to the WebGui you can easily review what operations are in progress and choose which one you want to connect to.
Payload generation is similarly streamlined by simply accessing the 'Create Components/Create Payload' menu.
From this menu, you can customise your attacking payload with the standard information such as encryption key, call-back host/port etc. The most notable element of payload creation is the ability to choose what functionality to include in your payload – a stroke of genius in situations where you're trying to stay undetected.
By restricting the functionality of any initial stager to just that which is required (typically something with command execution). Once a foothold has been achieved you can always include additional functionality in later payloads.
On clicking 'Submit' you can review/host/download your payload from the 'Manage Operations/Manage Payloads' page.
Now, because I'm one - lazy and two - don't like dropping directly malicious files to disk when I can help it, Apfell's ability to host files is definitely another bonus.
Though based upon VirusTotal's detection metrics, dropping the resulting file onto the disk is currently unlikely to raise many flags.
By clicking on 'Config' you can review the settings of your payload, as well as obtain the relevant execution command.
Whilst not exactly the easiest command to trick users into executing, well in the capabilities of a rubber ducky/digispark attack scenario.
It’s not pretty, but it gets the job done, with AV none the wiser.
As stated before, this isn't exactly pretty or social engineering friendly – however thanks to Microsoft's inclusion of the VBA command 'Shell' and its cross-platform capabilities, getting this to execute from a macro is straight forward.
I started to play around with throwing some obfuscation into this, but in the end this wasn't needed and AV lets it sail through with no issues, although the detection rate was increased.
This is most likely down to using an 'xlsm' to wrap my payload and the AV's in question being a bit twitchy (none of the Enterprise-based AV batted an eye), rather than them identifying the malicious content for what it is.