This is going to be a non-technical post, so if you’re looking for some sort of tool or walkthrough this post probably isn’t for you. I’m going to make an argument that the perimeter for Industrial Control Systems (ICS) is one of if not the most important security control. I understand that some might see this as antiquated way of thinking and are probably calling me a dinosaur. My response is to read below and that I think of myself more as a crustacean from the Proterozoic era looking for about tree-fiddy.
I have the opportunity to do offensive and defensive work for Critical Infrastructure. Critical Infrastructure (Utilities, Generation, Transmission, O&G, etc.) is an interesting industry from a cybersecurity standpoint. In the Enterprise space, cybersecurity is often viewed as risk mitigation. For example, our organization makes $1B dollars, the consequences of a cyber-incident is ABC, our threats are XYZ; therefore, we’re going to spend $1M dollars. Just like in the Enterprise space, Critical Infrastructure sites vastly vary in size and revenue. I’ve seen sites with one person handling all IT administration and cybersecurity to sites with large fully financed security teams. Regardless of size, staffing, and solutions implemented; Critical Infrastructure usually has one thing in common – the extreme consequence of a security incident can result in loss of life.
What is my point? Resources for cybersecurity at Critical Infrastructure can be limited while the consequences are severe. Why is that important? Well I imagine it could be overwhelming trying to secure Critical Infrastructure. Also, the next thing I’m going to say might ruffle some feathers so I wanted to give a bit of context.
The Industrial Control Systems (ICS) perimeter is one of the most important security controls when it comes to Critical Infrastructure … I can hear your collective moan from here. You say – “Nearly every security professional has adopted the ‘assume breach’ mantra, you’re taking us back years!”, my reply is to finish this paragraph. I understand why one needs to assume breach in the Enterprise space. The internet is a cesspool with exploits flying around, nasty emails, C2 traffic, etc. Enterprise infosec has to deal with thousands of end users reaching out to the internet downloading junk and having junk land in their inboxes each with an itchy trigger finger. Your perimeter will be breached and it will be breached often. However, what if I told you, that in order to breach your perimeter you had to come through one of five endpoints, welcome to Critical Infrastructure networks.
Continue reading “The ICS Perimeter – A Line in the Sand”
I’m back from Vegas and trying to work off all those late nights and delicious beers. Before I get down to business, I want to talk about the training I attended at Black Hat. My colleague and I had the opportunity to attend SpecterOps’ Red Team Ops training and it was absolutely fantastic. I doubt any the SpecterOps crew will read my humble blog, but if for some reason you find yourself here – thank you, it was terrific.
Windows services get a lot of attention. There is a reason why PSExec is a mainstay when laterally moving – it works, it’s stable, and it brings you in on a privileged session; however, it’s noisy. So I put together a reflective DLL which accomplishes the same thing but using scheduled tasks instead, while not calling schtasks.exe. It’s a similar level of noisy, but in my opinion it’s less likely to attract attention and it’s an alternative option.
I think there are quite a few potential applications for this code. Lateral movement is one. Including persistence in your custom foothold payload without calling schtasks.exe might be another. Using it to start a SYSTEM session could also be a use case.
The code includes a reflective DLL and an Aggressor script. The Aggressor script takes care of uploading the binary and calling the DLL. The DLL creates, executes, and deletes the scheduled task. Everything is pretty commented so if you’re adverse to writing a binary you could execute a one-liner instead. **NOTE** The Aggressor script or DLL will not clean up the binary, that is on you.
You can find the code at https://github.com/ThunderGunExpress/Reflective_Schtasks
Once again, this is skeleton code and has the following limitations:
- Use an IP address for remote targets and 127.0.0.1 for local targets
- If running against a local target you’ll need to be in a high integrity context
The first payload through the front door has a tough job. Consider all the security products specifically made to scrutinize its footprint on both the endpoint and network, life is not easy. Personally, I like to get a bit more visibility into who (or what) is executing payloads. To get that additional visibility, I slapped together a janky C# payload with a PHP delivery program.
Code – https://github.com/ThunderGunExpress/CustomStager
How to Defend
Defense in depth. Standard AV won’t detect this but I would expect the more advanced products might. AWL will definitely block this from executing. NGFW won’t detect the custom stager but might detect the subsequent C2 stager. Manual network traffic analysis and poking of updates.php will uncover it’s purpose pretty quickly. It’s the same old cat and mouse game – people are going to run executable code, as security professionals we have to ensure that we increase the chance of detection.
So at the moment, I’ve only tested this with a staged payload. Why would one want to stage a stager? Well number one, we’re injecting directly into memory with custom written software, so we’ll bypass a good deal of endpoint protection software. Number two, visibility and control.
We’re all security professionals here, so I’m not going to do a deep dive on visibility and control examples but a few come to mind:
- Determine if something like a NGFW is dropping your C2 staging traffic. For Cobalt Strike users, check out the following.
- Control who is delivered exploitation code based on username, email address, or whatever … the possibilities are endless with C#
- Avoid delivery to hostile machines.
So this is skeleton code waiting to be built upon. It could be used in an office macro or maybe a MSI. Here is a quick rundown of the C# program.
- Get the version from updates.php while sending the username to the web server. This is where you would add logic to the payload delivery system.
- Grab and parse the appropriate bitness payload
- Create a thread in the current process with the parsed shellcode
The single spaced shellcode is read from payload_x86.xyz or payload_x64.xyz which is in the same directory as updates.php. Note the “|” which will be at the head and tail of the shellcode, it’s required by the C# payload. The shellcode can be crafted via something like Cobalt Strike, msfvenom, or whatever.
This post is a revisit to a tool that was introduced in 2017 – OutlookToolbox. When the code was published I was happy with the overall functionality but unhappy with the execution. I wanted to write a C# DLL and forced the implementation. The old version used rundll32 to access C# functions which were exported with using Robert Giesecke’s Unmanaged Exports. The final result was a DLL and Aggressor script that wrote the DLL to disk and received status updates via txt files; so janky. Well enter Cobalt Strike’s new feature – in-memory .NET assembly execution. Long story short, we can run OutlookToolbox in-memory with only the odd csv or msg file ever touching the disk.
Code – https://github.com/ThunderGunExpress/OutlookToolbox_v2
What It Is
A C# console application that interfaces with Outlook in the background.
How to Defend
Sophisticated threat-actors are using this tactic. They are harvesting our emails for information that allows them to get closer to their objectives. The good news it that we can control how external background access to Outlook is handled – see Microsoft’s link here. If I recall correctly, if Outlook is set to Always warn me about suspicious activity the tool will stop during the SanityCheck (anti-popup) function. OutlookToolbox will do just fine with the other two configurations, the check AV one is the default.
- SanityCheck – Checks Outlook’s popup configuration (via registry and wmi) and attempts to determine if interfacing with Outlook will cause a popup.
- EnumerateFolders – Lists all the folders within Outlook (inbox, sent items, conversation history, and so on).
- FolderToCSV – Exports all the contents of a folder to CSV which includes – From, To, Type (it can get at Lync messages), . The message’s body is truncated to 1000 characters.
- ExportMessage – Exports target email or collection of emails from a specific sender.
- EnumerateTarget – Check the GAL for target user’s details like manager, colleagues (reports to same manager), title, and alias. Could be used in conjunction with EmailPivot.
- EmailPivot – Sends a crafted email on behalf of the target session. Great for getting in that trust chain (or whatever it’s called) between two people. Also has the ability to send replies from the TO user directly to deleted items with Outlook rules. Don’t do this unless you absolutely know what you are doing. Clean up could be difficult and it’s incredibly nasty.
Check out the old OutlookToolbox post for screenshots. There are some minor changes but the UI is pretty much the same.
I’m back in the pocket after doing the deep dive into hack the box. I really enjoyed the bulk of the challenges and learned some new great tricks and techniques. One box I highly recommend is Reel. It’s a great challenge with domain privilege escalation techniques that you might see in a pentest. Anyways, after reaching Guru status I decided to take a step back for a while, it’s a part-time job working all the newly released boxes.
Before I went dark I was testing Cobalt Strike’s built-in PSExec module against various Endpoint Protection Platform (EPP) products and was getting flagged. It was pretty clear that the EPPs weren’t detecting the binary but was instead flagging via heuristic analysis. It might have been the randomized filename of the binary, the timing, writing to the $ADMIN share, or some sort of combination. I wrote some skeleton code that can be further customized to help bypass heuristic analysis. The current flow of the reflective DLL and Aggressor script can be seen below.
You can find the code at https://github.com/ThunderGunExpress/Reflective_PSExec
The code and script is pretty crude and has the following limitations at the moment:
- Use an IP address as the target, not a hostname
- If running against a remote target ensure the session is in a medium integrity context
- If running against a local target ensure the session is a high integrity context
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”