Posts
This post is hosted over at TrustedSec.com, you are being redirected While Red Teamers love to discuss and almost poetically describe their C2 feature sets, EDR evasion capabilities, and fast weaponizing of N-day exploits, something that is rarely mentioned is good old loot. Loot, or information in general, will almost always be the deciding factor in whether someone clicks your link, happily follows your instructions, or accepts their MFA pushover prompt.
This post is hosted over at TrustedSec.com, you are being redirected In the age of threat hunting, automated mass scanning, and the occasionally curious SOC, properly securing your command and control (C2) infrastructure is key to any engagement. While many setups today include a CDN Domain Front with a custom Nginx or Apache ruleset sprinkled on top, I wanted to share my recipe for success. Fully (ab)using the services provided in Microsoft’s Azure infrastructure to the absolute max - AzureC2Relay!
As I mentioned in part 1 of this series. (Which I assume you have read) giving a DevOps pipeline access to the production subscription via a Service connection is the same as providing all developers who can edit that pipeline CLI access to the production environment. And while it may sound bold, it’s correct! Let’s explore just how an attacker can “move” or “hijack” an Azure DevOps pipeline session to gain actual CLI access through a Azure (Az) PowerShell session running locally, essentially using the service connection as a permanent backdoor!
On a recent engagement, the customer wanted to test how an attacker that successfully compromised external developer accounts could reach production resources. Companies inviting external consultants into their CI/CD and development services (Like Azure DevOps) is something I see a lot and have experienced from being a developer myself. Let’s explore how an attacker with developer access can abuse a DevOps pipeline to dump accessible Azure KeyVaults via a “Service Connection”, as well as exfiltrate the loot using the secrets retrieved.
This post is hosted over at redteaming.co.uk, you are being redirected DLL Side-Loading or DLL Proxy loading allows an attacker to abuse a legitimate and typically signed executable for code-execution on a compromised system. Mitre has been keeping a log of this technique since 2017, and it continues to be a popular option by threat actors (For good reasons!) Proxy loading is very similar to DLL hijacking, however, it does not break the execution flow or functionality of the original program.
My normal go-to implant / C2 for any inside penetration test is usually my modified version of Empire, nicknamed “Loke”. As Empire is fully relying on the use of PowerShell scriptlets, I need to be able to bypass common Windows hardening techniques, such as “Constrained Language Mode” for PowerShell.exe or/and AppLocker for binaries. Typically I’m able to use generic AppLocker “safe” paths (Great ressource for everything AppLocker) to invoke a PowerShell non Constrained runspace via C#.
In one of my earlier blog posts, I talked about and released a working PowerShell script to dump DLL Function calls from a signed executable, compile a “proxy” DLL and successfully run a DLL Sideloading attack.DLL Side-Loading allows you to make “safe” and singed applications run whatever code you want ( Application that load DLL’s in an unsafe way that is ) This time we will look into using this to bypass AV’s, including the latest version of Windows Defender.
The modern desktop applications of today typically rely on loading DLL’s (Dynamic Link Library) at runtime, in many instances, this is to access some third party functions that does some specific things the developer did not implement themselves. What if these functions suddenly came with a significant catch? Like loading, decrypting, and deploying a malicious payload into the memory of the computer? That’s called DLL-Sideloading. Just last year, what is believed to be an APT actor with connections to the Chinese government used this technique multiple times to deploy malware onto compromised computers belonging to the Norwegian company Visma.