Creepy User-Centric Post-Exploitation

I love seeing red and blue teams square off during an engagement. It works best if both sides avoid selfish desires and focus on the task at hand; improvement and training is the ultimate goal. A key component of the offensive aspect of this feud is the ability for the red team to conduct adversarial actions against users to gather data and accomplish objectives. Throughout every engagement, the red team has to be constantly aware of user behavior — tracking their movements , exploiting their weaknesses , mapping relationships , and analyzing yielded data to better accomplish the adversarial mission. By collecting, analyzing, and processing user-based intelligence, the red team is armed and prepared to succeed in accomplishing training objectives while also carrying out realistic adversarial actions. Keylogging, clipboard monitoring, and screenshots provide easy examples of user-centric post-exploitation actions that are both super useful for the red team and borderline creepy at times. These are also some of my favorite techniques before and after escalation of obtaining valuable intel. With strictly the data from these actions our team has been able to obtain passwords to critical ICS nodes, get screenshots of admins accessing sensitive data repositories (i.e. mainframes for healthcare, finance, etc), retrieve router configs copied to the clipboard, and many many more awesome things. In short, these actions are crucial for success in a large-scale and long-term engagement. One key thing about being in a red team: you must avoid limiting yourself to certain actions or tools out of habit. You have to ditch the myopic view and broaden your horizon. When I run out of ideas, I look to the real adversaries to see what they are doing. Several sets of threat actors (i.e. Flame , Duqu ) have been particularly inspiring and driven us to “up our game” when it comes to utilizing intelligence gathering against users. These actors all appear to have a wide array of modular capabilities in their tools that allow them to accomplish required actions. For our team, Empire and Cobalt Strike have the majority of capabilities we need for data collection; however, every so often we want to dig deeper and demonstrate additional actions that an adversary could carry out. In a recent engagement, those specific actions were webcam capture and microphone audio recording. You might ask “… REALLY? Why do I need audio/video from a target?” If you have asked that, you might consider brainstorming about all the ways an adversary gathers intel from a system or why they gather it. For example’s sake, audio capture makes a lot of sense for a military command center or political office. In a separate case, video capture of a high ranking C-level executive in their private office might result in good blackmail material for manipulation or access to sensitive discussions.

Before I go too far, I would be remiss if I didn’t mention that the Metasploit Project has post-exploitation capabilities to carry out these actions. Due to a couple of fail cases (which all tools have depending on the situation), I took it upon myself to look for or develop alternatives… Plus, I ❤ Offensive/Defensive PowerShell.

Audio Recording

Windows by default has a multimedia library baked into their SDK called “WinMM”. This library provides a range of features to interact with audio devices allowing you to play or record sound. One particular API, MCISendString allows you to send commands to an MCI device to accomplish the aforementioned actions. MCI Devices are Windows drivers that allow software device-independent access to multimedia functions such as playback or recording. Essentially, it is an easy front end to control with little knowledge of system-specific setups.

I have seen malware in the wild using this as a cheap way to control multimedia (open cd rom drives, play audio, record audio, etc). While it is not the most sexy method, it gets the job done. Programmatically , you simply perform the API calls to signal to the host to record and save audio.

I decided I wanted this functionality to be weaponized via PowerShell. For those not familiar, LoadLibrary is an API that allows a developer the ability to load a specific Windows DLL and GetProcAddress is an API that allows developers the ability to resolve the specific address of certain functions in a loaded DLL. Using PowerSploit’s Get-ProcAddress and Get-DelegateType functions and a well-written blog post by Matt Graeber ( @mattifestation ), I was able to load the winmm.dll, resolve the needed functions, and perform the recording. I have submitted Get-MicrophoneAudio to PowerSploit’s dev branch­ so that you too can take the next step of creeping.

For some follow on work, this script could be updated or another script could be developed to perform audio recording with DirectX as MCI is aging and is only supported for backwards compatibility.

Webcam Capture

Working with webcams proved to be slightly more difficult. Luckily, I did not have to put in much work. Chris Ross ( ) had already created Capture-Minieye , a script that utilizes DirectX to perform a webcam capture and save it to disk. First, this module reflectively loads a .NET assembly for DirextXCapture and DirectShow . Next, it utilizes the included functionality to begin recording a video file to disk. I have used this module on engagements inside of Cobalt Strike and it has successfully captured videos as expected. One downside is that it produces large output files with little compression. There appear to be methods to use compression inside of the DirectX assembly, but those are not currently utilized by the script.

Defense

I feel a responsibility to attempt to address defensive mitigations for anything I talk about offensively; however, the options to combat the techniques described in this post are limited. Standard actions to monitor endpoints such as AV, HIDS, event logging ( WMF 5.0 & PS Scriptblock Logging, etc.) are your friends but will not specifically prevent or detect most post-exploitation actions. Event monitoring works best in context and certain events, user reports, or help desk tickets will be more useful when applied contextually with all data available. Some post-exploitation actions will make more sense when you look at the series of events leading up to the action (i.e. Interactive login with a service account to a terminal server, user helpdesk ticket for suspicious behavior, suspicious command line behavior, HIDS alert for injection, etc).

Semi jokingly: A super easy indicator for your users would be the webcam light. If your webcam light turns on and you don’t know why… think OPSEC and get it checked. I look forward to any other ideas people have an I am happy to edit the post to add them.

Legal Disclaimer

I highly recommend reviewing federal/state/local laws regarding the recording of personnel as well as coordinating all actions through your point of contact. Also, make sure these are in-scope items per the rules of engagement. Laws surrounding the recording of video/audio of personnel can be complicated and therefore you should definitely verify this is okay to do. International privacy laws should also be taken into account.

Conclusion

Red team: I challenge you to seek out new post-exploitation actions to accomplish your objectives. Not only will you discover or develop awesome techniques that successfully mimic adversaries, but you will also gather critical intel that will enrich your engagements. Plus, the creepiest things often make the most impact. Your job is to educate and prepare the blue team.

Blue team: I challenge you to work to detect and respond to post-exploitation actions rather than focusing strictly on initial exploitation and prevention. This is obviously a lot harder said than done, and I will admit that your job is much more difficult, but a little practice and teamwork with your offensive side goes a long way!

Originally published at http://www.sixdub.net on May 16, 2016.