Cybersecurity Q&A
Browse concise answers derived from our published, source-linked cybersecurity coverage.
Can PowerShell be used to call IFileOperation for UAC bypass? How?
Yes, PowerShell can directly call IFileOperation because powershell.exe is itself a trusted file. An attacker first compiles a COM component in C# that wraps IFileOperation, then loads it in PowerShell using either Assembly.LoadFile or in-memory loading. Since PowerShell is trusted, no UAC prompt appears, allowing file copying to privileged directories. This method leverages the same principle as bypassing AppLocker via scripting, as discussed in [Testing and Analysis of Bypassing AppLocker Using LUA Scripts](/news/testing-and-analysis-of-bypassing-applocker-using-lua-scripts).
Why does modifying the PEB structure allow an attacker to bypass UAC when using IFileOperation?
The COM component IFileOperation uses the Process Status API (PSAPI) to read the process's PEB structure, specifically the ImagePathName and DLL names, to determine if it's a trusted process. By modifying these fields to mimic a trusted file like explorer.exe, the process can invoke IFileOperation with elevated privileges without triggering a UAC confirmation dialog. This technique is similar in concept to other UAC bypass methods, such as [Bypassing UAC via COM Component IARPUninstallStringLauncher](/news/bypassing-uac-via-com-component-iarpuninstallstringlauncher).
What are the three implementation methods for exploiting IFileOperation described in the article?
The three methods are: (1) DLL injection into explorer.exe, where a DLL calls IFileOperation to copy files; (2) modifying the PEB structure to impersonate a trusted process like explorer.exe, thereby deceiving the PSAPI; (3) directly calling IFileOperation from a trusted file like powershell.exe. Each method avoids UAC prompts by masquerading as or using a trusted process. For more on UAC bypass techniques, see [Study Notes of using sdclt.exe to bypass UAC](/news/study-notes-of-using-sdclt-exe-to-bypass-uac).
What is the COM component IFileOperation and how can it be exploited for unauthorized file copying?
The COM component IFileOperation is a Windows interface for file operations that can be called with elevated privileges if the calling process is a trusted file like explorer.exe or powershell.exe. Attackers exploit this by making an untrusted process appear as a trusted one, enabling file copying into protected directories without triggering UAC. This technique is detailed in the article [Unauthorized file copying via COM component IFileOperation](/news/unauthorized-file-copying-via-com-component-ifileoperation) and is applicable from Windows 7 to Windows 10.
How does token duplication allow escalation to SYSTEM, and what tools are commonly used?
Token duplication leverages a SYSTEM-privileged token to create a new process with the same high integrity. Tools like `incognito`, `Invoke-TokenManipulation.ps1`, and `SelectMyParent` automate this. For example, `incognito.exe execute -c "NT AUTHORITY\SYSTEM" cmd.exe` launches a SYSTEM command prompt. This method requires existing administrator privileges to access SYSTEM tokens. Details are in the [token duplication section](/news/penetration-techniques-switching-from-admin-privileges-to-system-privileges#0x04).
What is the role of Capcom.sys in privilege escalation, and how is it exploited?
Capcom.sys is a legitimate driver from Capcom's Street Fighter V that contains a vulnerability allowing kernel code execution. After loading the driver using `sc create Capcom type= kernel binPath= C:\test\Capcom.sys` and starting it, an exploit program (e.g., ExploitCapcom) can be run even with regular user privileges to gain SYSTEM access. This method is specifically for x64 Windows 7 systems. See the [Capcom.sys section](/news/penetration-techniques-switching-from-admin-privileges-to-system-privileges#0x05) for details.
How can I use the `schtasks` command to obtain SYSTEM privileges, and what are the OS limitations?
You can create a scheduled task that runs with SYSTEM privileges using `schtasks /Create /TN TestService2 /SC DAILY /ST 00:36 /TR notepad.exe /RU SYSTEM`. This method works on Windows 7 through Windows 10, but the older `at` command is only supported on Windows 7. Remember to delete the task with `schtasks /Delete /TN TestService2 /F` after use. This technique is covered in the [service creation section](/news/penetration-techniques-switching-from-admin-privileges-to-system-privileges#0x02).
What are the prerequisites and common methods to escalate from Administrator to SYSTEM privileges in Windows?
The prerequisite is having administrator privileges on the system. Common methods include creating a service using `sc`, `schtasks`, or `psexec`, exploiting MSIExec with custom `.msi` files, duplicating a SYSTEM token with tools like `incognito` or `Invoke-TokenManipulation`, or leveraging vulnerable drivers like `Capcom.sys`. Each method has specific OS compatibility and detection considerations. For more details, refer to [Penetration Techniques - Switching from Admin Privileges to System Privileges](/news/penetration-techniques-switching-from-admin-privileges-to-system-privileges).
What is the token removal technique to disable Windows Defender, and what are its requirements?
The token removal technique exploits the fact that the Windows Defender process (MsMpEng.exe) runs as a **Protected Process Light (PPL)**. By using a thread with **SYSTEM privileges**, an attacker can remove all tokens from MsMpEng.exe, preventing it from accessing other process resources and thus disabling its detection capabilities. This method requires SYSTEM privileges and is demonstrated by tools like KillDefender. Defenses include using tools such as [PPLGuard](https://github.com/elastic/PPLGuard) to block non-PPL processes from modifying PPL tokens. See the [Penetration Basics - Windows Defender](/news/penetration-basics-windows-defender) article for the full POC reference and defense recommendations.
How do I add an exclusion path to Windows Defender to prevent it from scanning certain files or folders?
You can add exclusions via the Windows Security panel under **Virus & threat protection settings > Add or remove exclusions**, or via PowerShell as an administrator: `Add-MpPreference -ExclusionPath "C:\test"`. The registry location for path exclusions is `HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions\Paths`. To remove an exclusion, use `Remove-MpPreference -ExclusionPath "C:\test"`. For more on exclusion types and commands, refer to the [Penetration Basics - Windows Defender](/news/penetration-basics-windows-defender) article.
What prerequisites are required to disable Windows Defender real-time protection via the command line, and how can I achieve it?
Disabling real-time protection via command line requires **TrustedInstaller privileges** and that **Tamper Protection** is disabled. The command is: `reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Defender\Real-Time Protection" /v "DisableRealtimeMonitoring" /d 1 /t REG_DWORD /f`. Tamper Protection status can be checked with `reg query "HKLM\SOFTWARE\Microsoft\Windows Defender\Features" /v "TamperProtection"` (value 5 = enabled, 4 = disabled). For obtaining TrustedInstaller privileges, tools like AdvancedRun can be used as noted in the article.
How can I check the current version of Windows Defender installed on my system?
You can view the Windows Defender version through the Windows Security panel by navigating to **Settings > About** and checking the 'Antimalware Client Version'. Alternatively, use the command line: `dir "C:\ProgramData\Microsoft\Windows Defender\Platform\" /od /ad /b` — the larger number indicates the latest version. For more details on Defender basics, see [Penetration Basics - Windows Defender](/news/penetration-basics-windows-defender).
What are the recommended defenses against net session exploitation?
Defenses include restricting domain users from using high-privilege accounts (like domain administrator) for remote connections via `net use`, and ensuring users promptly clear their net sessions with `net session /delete /y` or `net use * /del /y` after use. These practices limit the availability of exploitable tokens if a host is compromised.
What are the main exploitation strategies for net session tokens in a Windows domain?
Two primary strategies exist: local privilege escalation and domain penetration. For local escalation, if you have `SeImpersonate` or `SeAssignPrimaryToken` privileges, you can use the net session token to create a new process with higher privileges (as covered in [Penetration Techniques - Exploitation of Nine Windows Privileges](/news/penetration-techniques-exploitation-of-nine-windows-privileges)). For domain penetration, the token's permissions allow access to domain resources based on the session user's group memberships, enabling lateral movement.
Why does mimikatz's `process::start` command fail to create a process using an impersonated token from a net session, and how can this be overcome?
When mimikatz impersonates a token via `token::elevate`, it only changes the Thread Token (Impersonation Token), but `process::start` uses `CreateProcess` without passing a token, so the new process runs under the original primary token. To successfully create a process with the net session's token, you either need to modify mimikatz source code to use `CreateProcessAsUser` or use a tool like incognito, as described in [Penetration Techniques - Token Theft and Exploitation](/news/penetration-techniques-token-theft-and-exploitation).
How can you list active net sessions on a Windows host?
Several methods exist to view net sessions: the `net session` command in cmd, the Sysinternals tool LogonSessions (which shows sessions with Logon type 'Network'), a custom C++ program using LsaEnumerateLogonSessions and LsaGetLogonSessionData, or mimikatz with `token::list` after enabling debug privileges. These tools reveal the session's user, SID, and authentication identifier, which can then be used for token impersonation.
What is a net session in Windows, and why is it valuable for penetration testers?
A net session is created when a remote user connects to shared resources on a Windows machine using the `net use` command. For penetration testers, discovering an active net session is valuable because its authentication token can be exploited to create processes under the user's identity, potentially escalating privileges or enabling lateral movement within the network, as detailed in [Penetration Techniques - Exploitation of net session in Windows](/news/penetration-techniques-exploitation-of-net-session-in-windows).
How can you defend against Net-NTLMv1 downgrade attacks?
Since Windows Vista/Server 2008, Net‑NTLMv2 is the default and is significantly more secure. To prevent downgrade to Net‑NTLMv1, ensure that the `lmcompatibilitylevel` registry key is set to at least 2 (or higher) and that clients do not allow older LM/NTLMv1 authentication. Additionally, limit administrative privileges on endpoints because enabling Net‑NTLMv1 requires admin rights. For further protection, consider disabling NTLM altogether or using Kerberos where possible. Related defense strategies are also discussed in [intranet security articles](/news/intranet-security-using-nsa-smbtouch-for-batch-detection-of-intranet).
What is the InternalMonologue exploitation technique for Net-NTLMv1 and why is it stealthy?
InternalMonologue is a tool that locally downgrades the client’s NTLM protocol from Net‑NTLMv2 to Net‑NTLMv1 by modifying registry keys (requires admin privileges). It then interacts with the local NTLM Security Support Provider (SSP) to obtain a Net‑NTLMv1 response using a fixed Challenge (`1122334455667788`). Because it never sends network traffic or touches the `lsass.exe` process, it generates no authentication logs. The captured response can then be cracked via free rainbow tables on sites like [crack.sh](https://crack.sh/get-cracking/) to reveal the user’s NTLM hash. Full details are in [the original article](/news/introduction-to-net-ntlmv1-password-hash-in-windows).
How do you capture and crack a Net-NTLMv1 hash using Wireshark and Hashcat?
First, enable Net‑NTLMv1 on the client by setting `lmcompatibilitylevel` to 0 in the registry. After capturing the NTLM authentication with Wireshark, extract the Challenge (8 bytes) from the server’s response and the LM Response and NTLM Response from the client’s response. Format the data as `username::hostname:LM response:NTLM response:challenge` and use Hashcat with `-m 5500` for dictionary cracking. For example: `hashcat -m 5500 log1::WIN-BH7SVRRDGVA:fec9b082080e34ba...:51acb9f9909f0e3c...:8d2da0f5e21e20ee /tmp/password.list`. This method is detailed in [the original article](/news/introduction-to-net-ntlmv1-password-hash-in-windows).