Hey all,

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.

1. 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.
2. Grab and parse the appropriate bitness payload
3. 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.

Hey all,

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.

Features

• 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.

Hey all,

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