This post is about reflective dynamic link libraries (DLL) and will do a simple walk-through on how to write one. This is a technique developed by Stephen Fewer and will use his code to make the magic happen. I realize this is a topic that has been discussed several times so I’m going to keep this post simple and tight.
What is a DLL? A DLL is portable code that is often shared by applications. However, with respect to this post, a DLL is an opportunity to execute code. Why even bother with this? If our goal is to execute code why not write an exe to disk? For a moment, consider the footprint: writing to disk, creating a process, and then doing stuff; it can add up in a hurry. Enter DLLs and how we can go about loading them into memory.
Normally, DLLs are loaded into memory when a process is started; however, they can also be injected into an already running process. Through DLL injection we no longer need to create a process to execute code (various DLL injection techniques); yet, we still need to write our file to disk in order to inject. Reflective DLL injection solves this. Developed by Stephen Fewer, this technique allows us to inject code into an existing process without ever writing to disk. So using reflective DLL injection we go from writing to disk and creating a process to injecting our code entirely in memory … thank you Stephen.
How to Defend or Detect
Endpoint protection platforms (EPP) are starting to flag these techniques. Personally, I would explore reflective DLL injection on an endpoint using my EPP software to identify any limitations. Additionally, reflective DLLs will often execute malicious code by using Windows API calls, a potential detection point. For example, createremotethread is a popular technique to execute shellcode in a remote process.
After watching Raphael’s latest post on in-memory evasion, a few other tools:
Continue reading “Reflective DLLs and You”
This post is about spawning an Empire session over an already established foothold using reverse port forwarding. Spoiler, it’s all in the custom proxy settings.
Why not run an entirely new session back to the C2 infrastructure? Personally, I spend quite a bit of time running my externally destined traffic through the gauntlet: NGFWs, NIDS, and proxies *cough* check your stager *cough*. Every time you call home the chance for detection increases, especially when introducing different types of C2 network traffic.
Onto the example. Setup the reverse port forward; I used Cobalt Strike, but any old reverse port forwarder could be used, like SSH, meterpreter, and so on.
Continue reading “Empire and Proxy Pivots”
Forewarning, this is going to be a quick and dirty post. I’ll publish code to github once there is something worthwhile to post, until then, you can find the code below.
So you’re admin, you’ve bypassed UAC, it’s time to run hashdump and/or mimikatz but nothing happens, what gives?
It could be a number of issues: bitness of the session, the inability to impersonate or become SYSTEM, and so on (see Rob’s post which discusses it further). Usually my go to is to spawn a new SYSTEM session via psexec or getsystem, both of which will probably end up creating a new service (see Raphael’s post about getsystem). So what’s the problem? Well I’ve found that Endpoint Protection Platforms (EPP) have begun to either block or flag this activity as suspicious.
Enter Windows update standalone installer, or wusa.exe, which executes in an interesting manner. When called from a low or medium integrity process it will spawn as a high integrity elevated process, perfect for bypassing UAC, a technique which can be seen in TokenMagic and TokenDuplication. Additionally, it can be used to run SYSTEM tasks without spawning a service. As a quick and dirty PoC I used a reflective DLL to spin up a hidden instance of wusa.exe which needs to be run from a low or medium integrity process.
Continue reading “Dude, Where’s My Hashes”
Lately I’ve been playing around with MSI files as an all-in-one phishing package. I feel that MSIs are moderately trusted when it comes to downloadable files. Couple this with the ability to introduce some logic and I think MSIs can be a great way to avoid common security controls while shooting for that initial foothold during an engagement.
Personally, I feel when targeting users of high infosec awareness it’s best to bring the target to you and make them want to download your software. I like to bundle a bunch of publicly available legitimate tools with one or two of my custom written files … never embed cleartext shellcode, always grab it from a web server, dns, or whatever. This post follows ThunderMSI, a faux CISSP study guide that performs a series of actions depending on the user’s privilege level.
Recommended Read – Wixsharp Managed Setup
How to Defend
- Be skeptical when downloading software. It might be a good idea to have an auditing VM dedicated to vet software before installing on your primary machine.
- A good HIDS should be able to flag or detect several of the suspicious actions in this PoC. For example, a well written MSI shouldn’t be writing an exe to system32 or creating scheduled tasks in Windows sub-directories.
- Monitor processes for network IO. It’s not a good thing if cmd.exe or powershell.exe is consistently generating unexpected network traffic.
ThunderMSI is a C# program using wix and wixsharp that builds into a single .MSI file. It contains nothing that should be flagged as malicious; however, there are some WINAPI calls (createremotethread) that might trigger advanced endpoint solutions.
Continue reading “Phishing with Smart-ish MSIs”
Lately I’ve been playing around with Visual Studio Tools for Office (VSTO) as a persistent foothold. VSTOs are Microsoft Office add-ins that can enhance the user’s experience or automate tasks. Enabled add-ins are run every time the target Office application is started, a perfect persistence point. VSTOs can be written in C# or VB, and if done correctly, do not require administrative privileges to install.
Because of this event driven nature and the non-admin installation, I think VSTOs could be a decent addition to a phishing installation package. I’ve put together a proof of concept which can be found at https://github.com/ThunderGunExpress/ThunderVSTO
What This is Not
A complete installation package. This persistent VSTO would need to be included in some sort of a larger installation package. Fortunately, I plan on posting about this at a later date.
How to Defend
Sysinternals Autoruns checks for Office add-ins; however, unless I’m missing something, it only displays the HKLM\Software\Microsoft\Office\**Office App**\Addins. Personally, I would target HKU instead (non-admin) which is not tracked by Autoruns.
Continue reading “Persistent VSTO”
This really isn’t much of a post; instead, I wanted to show some love for https://www.hackthebox.eu/ which a friend recently introduced me to. I just started to work my way through some of the challenges and I think it’s very well done.
We all know that UAC is not a security boundary. That being said, it can be super annoying, and sometimes difficult, when you just want to spawn a window-less high integrity session so you can continue with funtimes.
Recently I came across the technique described on Tyranid’s Lair to bypass UAC, but I could only find Powershell implementations like UAC-TokenMagic and Invoke-TokenDuplication. So to take a different route, I put together a reflective DLL that uses this technique and an Aggressor script to make everything easy.
The DLL creates a duplicate token for wusa.exe, crafts a new restricted token, spawns an elevated hidden instance of cmd.exe, and proceeds to inject shellcode into cmd.exe via RTLCreateUserThread. I’ve tested it on Windows 7, 10, 2008, and 2012 on both x64 and x86 architectures.
Lately I’ve been neglecting my CTF posts so I could put some time into OutlookToolbox, a C# DLL that uses COM to target Outlook in the background. Additionally, I put together a Cobalt Strike Aggressor script to assist with the execution of OutlookToolbox, both of which can be found at the repository here – https://github.com/ThunderGunExpress/OutlookToolbox.
This is a quick and dirty post which will cover the features. Later, I plan on creating another post which further explores potential use cases of OutlookToolbox.
- Only use for good.
- I have not done extensive testing with this tool, use at your own risk. I recommend testing OutlookToolbox on a replica of your target first.
- The Aggressor script uses several brm (file and/or directory remove) function calls which can bulldoze entire directories if input is not sanitized correctly. I’ve tried to iron out all the issues, but still, I would put OutlookToolbox in a non-critical directory like C:\Users\Public\Documents just to be safe.
What it Does
- Lists folders in Outlook (Inbox, Sent Items, Conversation History, Joe’s Custom Folder … )
- Exports target folder to a CSV File
- Enumerate targets using the GAL
- Download specific messages
- Sends an email on behalf of the target user
How to Prevent
Configure Outlook’s programmatic access security to report on suspicious activity – MS link. Email encryption will cause several of these functions not to work, not a bad idea.
Continue reading “OutlookToolbox”
Lately, I’ve been dedicating my spare time to Pentestit v11, a terrific pentest lab which is great to hone those skills. If you have the spare time, I highly recommend participating – lab.pentestit.ru.
Version 11 is named “Who is Mr. Hacker?”. To start, we are given a network diagram and two target IP addresses: 192.168.101.10 and 192.168.101.11. For this post, I’ve created my own network diagram so I can mark it up along the way.
Obviously there are spoilers ahead.
Continue reading “Pentestit v11”
Just a FYI, this is more or less a placeholder post with little content until I upload a walk-through.
While surfing reddit/netsec someone posted a link of a walk-through of some targets in a virtual pentest lab called practicalpentestlabs, naturally I decided to give it a go.
To join the game, it’s as simple as registering and establishing a VPN session into the lab environment via openvpn. Target IP addresses are provided, and depending on the difficulty, a little hint giving potential avenues of attack. The goal is to hack into each of the targets and grab the contents of secret.txt, which usually resides in /root or the administrator’s desktop. The contents of secret can then be submitted for points, the amount awarded is based on the difficulty of the target. Accumulated points are tracked on a pretty slick dashboard … sorry I couldn’t help myself :S
At the moment, I’ve worked through the web application and scenario based targets with the exception of “X”. I thought the targets were challenging but not insanely difficult. Practical pentest labs was a great walk-through of various vulnerabilities while not obscuring them to a point where it’s less an exploitation exercise, and more a game of hide and seek. Continue reading “Practical Pentest Labs”