While mostly being a decisive technique, DLL hijacking has always had one huge disadvantage in the way that it executes our third-party code once loaded into the process. It's known as Loader Lock, and when our third-party code is run, it's subject to all its strict limitations. These include creating processes, doing network I/O, calling registry functions, creating graphical windows, loading additional libraries, and much more. Trying to do any of these things under Loader Lock will likely crash or hang the application. Until now, only satisfactory (but needing something more), soon-to-break, or sometimes a tad over-engineered solutions for this problem have existed. So today, we're doing 100% original research reverse engineering the Windows library loader to not just cleanly workaround Loader Lock but, in the end, disable it outright. Plus, coming up with some stable mitigation & detection mechanisms defenders can use to help guard against DLL hijacking.

This blogpost embarks on the initial stages of kernel exploitation. The content serves as an introduction, leading to an imminent and comprehensive whitepaper centered around this subject matter. Through this, a foundation is laid for understanding how kernel drivers are developed, as well as basic understanding around key concepts that will be instrumental to comprehending the paper itself.

We’ve all seen these great diagrams of how SSH port forwarding works but if your brain is anything like mine, these diagrams leave you with a lot of unanswered questions. If you’re on a red team, understanding how to traverse a network better than the people who designed it gives you immense power to do evil things. SSH is such a powerful tool but sometimes the syntax and other concepts can get in the way of us accomplishing our goals. In an effort to do more evil things in a timely fashion I’ve put together a massive list of SSH things that I find useful.

The intention of this post is to provide basic queries for targeted AD DS information gathering used in penetration testing. The reader can pick their poison when deciding how to deliver them. Some delivery method examples include vbscript, powershell (i.e. adsi and adsisearcher type accelerators), dsquery, ADExplorer, AdsiEdit, javascript, win32API, .NET languages, ldapsearch, adfind, adsearch, and likely many others. Equally, defenders can use these queries to test their detection capabilities when large traffic spikes may not be produced, see what attackers will see from various perspectives within their environment, and aid to remediate domain privilege escalation and lateral movement opportunities from breach hosts.

In this article, I will focus on the Direct System Call technique and show you how to create a Direct System Call shellcode dropper step-by-step using Visual Studio in C++. I will start with a dropper that only uses the Windows APIs (High Level APIs). In the second step, the dropper undergoes its first development and the Windows APIs are replaced by Native APIs (Medium Level APIs). And in the last step, the Native APIs are replaced by Direct System Calls (Low Level APIs). I will also explain how to analyse and check your droppers using tools such as API Monitor, Dumpbin and x64dbg.

Stack spoofing is a really cool malware technique that isn’t new, but has been receiving some more attention recently. The goal of this post is to introduce readers to the concept and dive into two implementations. This post will focus only on call stack spoofing in x64 Windows with “active” spoofing techniques.

In the realm of cybersecurity, privilege escalation attacks pose a significant threat to system security. One such vulnerability that gained attention in recent years is the “Potato” attack (CVE-2023–21746). This attack exploits a security flaw in Windows’ NTLM, allowing attackers to elevate their privileges to the SYSTEM level. This article provides an overview of the “Potato” attack, delves into its background, and outlines how penetration testers can replicate the attack in a controlled lab environment.

Since LOLBAS are one of the growing trends in cyber-security attacks and they are also very hard for security solutions to detect, we set out to find new official LOLBAS. In this blog post, we’ll show how we found 12 new LOLBAS that security professionals should protect against.

So you are a tester and you would like to know more about GraphQL Testing. No more sparse information, we cover enough to get you started. This post contains my knowledge acquired during my penetration tests involving GraphQL and during the development of GraphQL apps!

I have seen a lot of open-sourced tooling enable SeDebugPrivilege but haven’t seen many dive into why this privilege is of such interest. I think it is widely known that SeDebugPrivilege skips some OS security checks, but I have never seen anyone mention which OS security checks it skips and which ones it doesn’t. While diving into this I found out that the Mandatory Integrity Control (MIC), and ACE checks (both Discretionary Access and Conditional Access) are the ones bypassed, while protection checks and 3rd party pre-operation callbacks are not. This is good information for anyone wanting to know when to use SeDebugPrivilege to obtain more access to a process or thread object. Let’s dive into this a bit more in-depth.