rapid7
Objective See KIller: OSX Antivirus Enumeration & Detection.
Summary
Objective See offers a variety of free and open source security tools. This module will be able to detect the presence of these tools on a system and disable them. Here is a list of the tools I'd like to target:
LuLu a firewall and network monitor that alerts users when processes on their system are looking to communicate externally.
Do Not Disturb Detect and prevent evil maid (physical) attacks such as USB insertion, opening the device etc. It can take screenshots as well as provide email and phone notifications in the event of unauthorized access. Perhaps we can block these communications instead of disabling the product entirely?
ReiKey Keylogging detection. Most key logging is done via the CoreGraphics interface I am not sure whether the OSX keylogger uses this interface.
BlockBlock Detect and block persistence attempts such as cron jobs, launch Daemons/Agents, periodic scripts, login items etc.
RansomWhere? Generic Ransomware detection. As MetaSploit does not have a ransomware module I'm not going to set this as a high priority. Here is a quick synopsis of how this product works
OverSight Detects Camera and Microphone access.
Basic example
Most of these products have a disable/enable switch, we could reverse engineer the tools and determine how to send this signal to the application. Some products even offer installation instructions for example:
sudo RansomWhere_Installer.app/Contents/MacOS/RansomWhere -uninstall
Uninstalling products can even be done manually:
//stop launch daemon
$ sudo launchctl unload /Library/LaunchDaemons/com.objective-see.ransomwhere.plist
//remove launch daemon, its plist, and supporting files
$ sudo rm -rf /Library/LaunchDaemons/com.objective-see.ransomwhere.plist
$ sudo rm -rf /Library/Objective-See/RansomWhere
Other methods of thwarting these products may be through DoS or altering the set of allow/deny rules used by the product.
Motivation
Objective see's products are free and highly effective at detecting novel OSX malware species. Disabling these security products is vital to achieving post exploitation goals such as persistence or exfiltration. Lastly, creating an offensive tool aimed at these will inevitably lead to an evolution on the defensive side whereby these products are (hopefully) hardened against such attacks.
sounds fun to add. maybe we could have some post modules focused on disabling this. I'll see if I do some research on these such as how they can be disabled and what privileges are approximately needed to mess up with them
Okok, LuLu needs sudo for all ways to mess up with it, such as ejecting the system driver:
# To find the driver
systemextensionsctl list
# Then
sudo systemextensionsctl uninstall <TEAM_ID> <BUNDLE_ID>
For DND it seems to be similar, though if we just want to disable communications. For local alerts XPC is used. For remote alerts it uses what seems to be a separate Digita framework, though it seems like isn't available
I think for all of them it's just to do priv escal first to be able to disable, unless they have a way to shut them down without any privileges.
Going back to DND, I want to see if using Wireshark or something similar I find the exact ports and protocol it uses.
yeah I'll reverse engineer each of these, then I'll put here what I manage to find
if any vulns allow to write to any files, config files can be edited to disable tools
I've already gotten a decent bit of the module down just for enumerating. Taking it one product at a time, focusing on LuLu first. I'll link what I've got Friday afternoon. Thank you!
We could find the PID associated w each product and send it a KILL. However some will respawn at launch as they run as agents/daemons. I want to be able to send a disable signal or fully uninstall the product.
We could find the PID associated w each product and send it a KILL. However some will respawn at launch as they run as agents/daemons. I want to be able to send a disable signal or fully uninstall the product.
Looking at the source code (luckily these are open source) they have some methods for enabling/disabling, but we would need to attach to the process with a debugger which would need sudo, uninstall also needs sudo, almost everything needs sudo. So maybe we could have this as a post module after priv escal unless we find something different. I'll see if I do my idea of finding what port DND uses and see if with low privs we can mess it up
well apparently DND no longer supports connecting to phones for alerts see there's nothing to check out there
For ReiKey, if it ONLY checks CoreGraphics it should be as simple as using other methods such as Carbon events, the AX API, or the IOHID API for keylogging.
We could find the PID associated w each product and send it a KILL. However some will respawn at launch as they run as agents/daemons. I want to be able to send a disable signal or fully uninstall the product.
Looking at the source code (luckily these are open source) they have some methods for enabling/disabling, but we would need to attach to the process with a debugger which would need sudo, uninstall also needs sudo, almost everything needs sudo. So maybe we could have this as a post module after priv escal unless we find something different. I'll see if I do my idea of finding what port DND uses and see if with low privs we can mess it up
I'll add Sudo in the check method. Do you think these should be separate modules or just one big Objective Cee module? I figured because they're all written by the same developers the calls to enable or disable would be relatively similar and could justify having one module for all Objective Cee products. However I do not like the idea of module bloat. I'm going to start using the process explorer this weekend and see what I can find for debugging.