I was recently in a situation where I needed to pivot from a compromised windows endpoint to my target’s Entra tenancy. The usual go-to in this scenario is to extract the primary refresh token (PRT) from the endpoint via beacon (using BOFs like aad_prt_bof or request_aad_prt by Kozmer). However, in this case, my beacon was running on a non-domain-joined, BYOD device, meaning the PRT extraction approach was off the table. I needed another way to obtain refresh tokens, so that I could maintain access to the compromised identity when the beacon inevitably dies.

Side note - I’d strongly recommend reading “An Operator’s Guide to Device-Joined Hosts and the PRT Cookie” by Matthew Creel for a great insight into PRTs.

During a quick chat, my good friend Jack made me aware of the new BOF that was recently added to TrustedSec’s Remote Ops Repo, called get_azure_token by Christopher Paschen. This BOF is awesome and is the inspiration for this post.

In short, the BOF works by leveraging the user already being authenticated to Entra via the browser. It starts by launching a new browser window and initiating an authorization code flow for a given Entra client ID and scope. It then starts a local ‘listener’ to capture the incoming authorization code, and uses the captured code to request an access and refresh token, which is then displayed to the operator.

The BOF's approach has various advantages, one of them being that all requests originate from the end-user’s machine and IP address. However, an important caveat to note for this BOF is that the specified client ID must allow “http://localhost” as the redirect_uri parameter.

Redirect URI

Unfortunately, because the redirect_uri parameter is set to localhost, it limits the number of client IDs that can be used with this technique - especially if you wanted to leverage the family of client ID (FOCI) abuse.

Searching through the currently known first-party client IDs that are both FOCI-enabled and support “http://localhost” yields very few results. I found only three:

• Microsoft Azure CLI

• Microsoft Azure PowerShell,

• Visual Studio – Legacy

To prying eyes (the SOC), authenticating to any three of these could potentially seem unusual for a typical user and trigger an alert. To make matters more difficult, in mature tenancies, there’s a chance that these specific applications wouldn't have consent in the tenant (which unfortunately for me, was the case).

Microsoft’s Native Client Redirect URI

Microsoft provides a predefined redirect URI called the native client redirect URI (https://login.microsoftonline.com/common/oauth2/nativeclient), which is used in OAuth flows for native applications like desktop or mobile apps. It essentially allows these apps to receive an authorization code from Entra without hosting a web server or using a custom URI scheme - the browser simply redirects to this URI with a “code” parameter, which the app captures and exchanges for access and refresh tokens.

To get a better understanding of the authcode flow in action, check out JUMPSEC’s tool called TokenSmith (made by Sunny Chau) which automates the process (although the URL and authcode must be copied between the target by hand). If you paste the URL into a browser where you’re signed in (and the client ID is allowed), you’ll see the authcode returned almost instantly.

It occurred to me that the authorization code also resides in the window title. If we extracted it from there, it could allow us to use the native client redirect URI instead, giving us access to a much larger range of FOCIs and removing the restriction of only being able to use FOCIs that allow "http://localhost" as the redirect URI.

There’s going to be multiple ways to do this, but the easiest to PoC I could come up with was extraction via GetWindowTextA API. With this approach, we could carry out authcode flows against a greater number of FOCIs - including our favourites like Teams, Copilot, Edge, etc. This can make a massive difference in terms of OPSEC.

I noted the following first-party FOCIs allow the “native client” redirect URI:

BOF or it didn’t happen

As a basic proof-of-concept, I threw together a BOF that does the following:

1. Opens a browser window to the authcode flow URL (for a client ID and scope)

2. Extracts the returned code from the window title

3. Uses the code to request and obtain the tokens

beacon> entra-authcode-flow <clientid> <scope>

You can find the BOF and usage instructions at my GitHub, here.

Closing Thoughts

It goes without saying, but this is probably for edge-case scenarios only. In my eyes, obtaining the PRT is an easier and more reliable method for identity persistence. This was purely a concept that I wanted to try out, and I was pleased to see that it worked somewhat reliably for me and my team.

Again, the most important benefit with this approach (for the red team) is that all authentication requests and token requests originate from the compromised endpoint. When paired with your favourite post-exploitation tools like GraphSpy (especially via SOCKS) this could become a nice little technique to have on standby.

Thanks for reading!

Acknowledgements

• Christopher Paschen (@freefirex) for creating the original get_azure_token BOF

• FOCI research by SecureWorks and Dirk-Jan’s first-party scopes

• V3ded and Jack Halon for proofreading and code review (thank you guys <3)

• @ethicalsoup for some extra proofreading!

Delivering staged implants has been back on the cards for a while. Major EDR vendors are now scrutinising executables more if they appear to house embedded shellcode, as this produces an artefact with much higher entropy. This is why staging has had a bit of a comeback, because if your implant stage is delivered remotely and in-memory, then you can reduce the entropy of the file and avoid this cat-and-mouse game. I’ve personally found this to be quite effective, especially for lateral movement.

Of course, staging relies on the target reaching your remote stager. This can be a bit more difficult for more isolated targets, such as those found deep within ICS networks. I’ve found that one of the most effective solutions is to host the shellcode via beacon on a neighbouring host (assuming you can get one) using BOF.NET.

Hosting Files in-memory via BOF.NET

Ceri Coburn’s BOF.NET project includes several built-in BOFs to demonstrate the project’s functionality, including a virtual file system (VFS) and a WebServer BOF. This provides all the functionality we need to temporarily store and host a file in-memory, without uploading or dropping our shellcode anywhere. After initialising BOF.NET in beacon, adding files to the VFS is straightforward:

beacon> bofnet_vfs_add [local-path] [filename] [mimetype]

With your payload available in beacon’s memory, you can host the file on any interface that your target can access. In this example, I’m using the GOAD SCCM lab on Ludus, where the IP of my foothold beacon (with hostname “client”) is 10.3.10.43. This makes the VFS accessible via HTTP through client, client.sccm.lab, etc.

beacon> bofnet_job WebServer http://[internal-ip]:[port]/

The WebServer BOF allows you to serve content on any port permitted by your privileges. In this example, a high-integrity beacon is used to serve on port 80, which is allowed through the firewall. Whatever port you use must be accessible through the local firewall. I recommend using TrustedSec’s list_firewall_rules BOF to help with this.

Pivot Listeners

In situations where the target is unreachable from your beacon, or has no open ports, it’s worth using the reverse TCP beacon rather than the traditional “bind” peer-to-peer variants. In other words, if the target can reach you but you can’t reach the target, pivot listeners are probably your best bet. Note that you must have the privileges to create a listener on whichever port you decide to listen on.

Currently, you can only start a pivot listener through the GUI, where you specify the listen IP. This should ideally match your BOFNET WebServer IP and listen port:

Next, generate the pivot listener shellcode and upload it to the VFS. Host it using the WebServer BOF, ensuring the target can access both the server and the shellcode. You can view any hits to your server using the following command:

bofnet_jobstatus [job-id]

By configuring an arbitrary payload stager to point to the internal BOF.NET WebServer address, execution should allow it to fetch the stage from the neighbouring host. In turn, this should allow a beacon to establish a connection back to the pivot listener.

Kudos to Rasta Mouse for proofreading.

VST (Virtual Studio Technology) is a software interface standard developed by Steinberg Media in 1996. They allow music producers to use digital audio plug-ins like instruments (synthesisers, drum machines, etc.) and effects (guitar pedals, etc.) within their DAW software like Ableton Live, Cubase or FL Studio. They have an important role in modern music production environments, with both paid and free/open-source VSTs available from popular sites like KVR Audio.

I know that VST plug-in piracy is common within the producer community (even in professional and enterprise studio environments). With this in mind, I decided to do some reading on the security of the VST standard, to see how difficult it would be to tamper with and backdoor a plugin.

Command Execution

On Windows systems, a VST plug-in is a multi-threaded DLL which is packed into a folder structure (for macOS, it’s a Mach-O bundle) which means that creating a simple plugin that executes some commands should be straightforward. Steinberg has a “Hello World” VST3 example plugin and build instructions on their GitHub, which provides a simple template for us to work from (here).

git clone https://github.com/steinbergmedia/vst3_example_plugin_hello_world.git
mkdir build
cd build
cmake ../vst3_example_plugin_hello_world
cmake --build .

Adding command execution is as simple as prepending a system call before instantiating the plugin in "HelloWorldController".

Recompile the plugin and relocate it to the default VST3 directory for the DAW. In my case, with Ableton Live on Windows, the default path is:

C:\Program Files\Common Files\VST3\

When the plugin is launched in Ableton Live, the command runs without interruption of the DAW's operation, and we see our result.

Persistence

Executing arbitrary code is simple, but a technique for persistence is what makes it especially interesting. Instead of relying on the target to launch the VST within their DAW, we can ensure execution as soon as the DAW opens.

When Ableton detects changes to plugins in the default VST3 directory, it triggers initialisation by calling functions from "DLLMain" in the VST. Therefore, any new plug-in located within the default directory will execute each time Ableton is launched.

Using Ableton as an example, consider the following: a simple shellcode runner to execute beacon shellcode within the remote process "AbletonPushCpl.exe". This is Ableton's USB Audio Class Driver Control Panel process which exists as a child of “explorer.exe” and is present on Windows computers with Ableton Installed - ensuring our beacon lives on after Ableton is quit by the target.

Note that execution will occur again only if the user re-opens the VST inside Ableton, as initialisation only occurs when Ableton detects a new or modified VST in the default directory. In theory, the code could automate this to become a self-propagating VST.

Conclusion

Detection rates for malicious VST plugins remain low, as most vendors appear to ignore the VST format entirely. Given that most independent music producers, who are probably prime targets for this, wouldn’t typically have EDR systems installed, there's a high chance that targeted attacks would succeed.

Of course, downloading and running VSTs on personal or domain-joined computers (like those in production studios or universities) from unknown sources is a bad idea. Treat them like any other executable file.

I think whilst Ableton and other DAW manufacturers aren't solely responsible for preventing malicious VSTs, adding an option to allow only VSTs with valid code signatures would be a great starting point to reduce the impact of this vector.

Update: For macOS, there’s some interesting articles by SpecterOps and Csaba Fitzl which explore the weaponisation of Apple Audio Units (AU) - Apple’s competing audio plugin format to VST - for unsigned code execution and persistence, which are absolutely worth a read:

• Audio Unit Plug-ins: Legitimate Un-signed Code Execution

• Beyond the good ol' LaunchAgents - 13 - Audio Plugins

Disclaimer: Please consider this article a point-in-time review. Zero-Point Security will always be updating this course and I will not be updating or amending this post in parallel. For the latest information about the course and exam, please see the official Zero-Point Security website.

After a great experience completing the Red Team Ops (RTO) course and Certified Red Team Operator (CRTO) certification last year, I jumped at the opportunity when Rasta Mouse recently announced the release of its “big brother” course, Red Team Ops II (RTO2) and the accompanying Certified Red Team Lead (CRTL) certification.

I enrolled in the course in November and studied the material over 3 months in preparation for the 72-hour practical exam. This week, I passed the exam, and I thought it would be valuable to share a summary of my experience and thoughts.

Material and Content

The course is considered a direct follow-up to RTO, focusing on evading modern security defences using various strategies. Whilst RTO teaches how to execute common AD attacks with Cobalt Strike, RTO2 teaches you how to perform successful attacks in hardened network environments, going up against modern EDR solutions and blue teams. This course does not cover AD attacks, C2 principals or general Cobalt Strike ops, as this knowledge is assumed. Does this mean CRTO is a prerequisite for CRTL? Not necessarily, but ZPS suggests that all students are comfortable with every module covered in CRTO at the very least.

There are currently seven modules: C2 Infrastructure, Windows APIs, Process Injection, Defence Evasion, Attack Surface Reduction (ASR), Windows Defender Application Control (WDAC) and EDR Evasion. In my opinion, the best modules are Defence Evasion and EDR Evasion, which is where this course shines. I did find that some modules would lack in-depth explanations, resembling more of a "do this" approach rather than delving into the "why it works”. Considering the course has a very strong and clear emphasis on self-driven research (very much unlike RTO, which is far more spoon-fed), I think this is reasonable, especially given the price.

In my eyes, there are very few places where you can find this level of information while simultaneously practising with Cobalt Strike from your browser. Plus, like all Zero-Point courses, you receive lifetime access to the material even after updates have been made.

Lab Environment

The lab setup consists of a small Windows Active Directory domain featuring workstations, various servers, and a domain controller. It also provides multiple C2 redirector servers alongside “attacker-linux” and “attacker-windows” virtual machines. There are plenty of machines available for completing all the exercises and practising evasion techniques whilst you progress through the material.

Another way the course differs from RTO is how the content doesn't really follow alongside the lab environment. The lab is primarily for practising specific exercises or teachings from the material rather than following a narrative. While it still includes tasks like "do this on machine X to reach machine Y", it offers more freedom for tinkering rather than solely focusing on completing tasks.

Most of your time will be spent on the attacker-windows host, where you'll have access to Visual Studio, various tools, and your Cobalt Strike client. This attacker machine is equipped with everything you need since tools cannot be copied in or out of the lab environment (just like RTO, using Guacamole).

Exam

The course fee includes an exam attempt that you can schedule ad-hoc, which is great. The exam requires students collect all flags (unlike CRTO, which is 6/8) within the allotted 72 hours to pass. The exam environment is made "available" for 5 days and it's up to the student to start/stop the exam environment within that time. I think that 72 hours is very reasonable considering what the exam entails.

That being said, it's fair to say that the exam is very difficult. I found it far more difficult than I was expecting - primarily because it had some “surprises” in there that I didn’t see coming. The main difference between the CRTO exam and the CRTL exam is that everything to pass CRTO was in the material. With CRTL, this was not the case and requires some real-world experience to get through it. I think relying solely on the content from RTO2 simply isn’t enough to achieve a passing score - it requires some extra effort.

The exam does, however, do a great job of solidifying what was taught in the course and applying those skills under pressure. It took me ~30 hours of run-time before I had the final flag. Again, it’s a very difficult exam experience and I expect it'll stay this way as the course matures and updates over time.

One of the great things about Zero-Point Security exams is that you pretty much know when you've passed because it’s entirely flag-based. If you get all the flags, you pass. You do have to wait for the SnapLabs "event" to finish for the badge to arrive via email. I received mine about 30 minutes before the event officially ended.

Conclusion

To any current or future students, I strongly advise completing all exercises within the lab environment and making notes from the course material. I also found it beneficial to revisit some of the content in RTO, which had been updated since I took the CRTO exam. I’d also suggest taking full advantage of the lab setup, especially to practice setting up your Artifact Kit, SleepMask Kit, C2 profile, and redirectors multiple times.

It’s also worth checking out the following YouTube playlists created by Raphael Mudge, the original creator of Cobalt Strike. I found these helped solidify some of the teachings in various modules, even though they’re quite old at this point. Fair warning, he does talk very slowly in these videos - watching at 2x speed worked fine for me!

• Red Team Operations with Cobalt Strike (2019)

• Using Direct Syscalls in Cobalt Strike's Artifact Kit

• In-memory Evasion (2018)

My personal experience with RTO2 and the CRTL exam has been fantastic. I think the only drawback of the course is the lack of support at times (as ZPS is a one-man operation, after all) and sometimes the content feels quite dry in the way it’s presented (in comparison to OffSec, for example). That said, the course has really boosted my confidence in operating in security-aware networks and I've already implemented several techniques to some of my internal tools. A solid 8/10!