Cybersecurity Q&A
Browse concise answers derived from our published, source-linked cybersecurity coverage.
Why can't I simply use the HTTP protocol to download files from GitHub via the command line?
GitHub only supports the HTTPS protocol, so any command-line download method relying on HTTP will fail. As detailed in [Penetration Techniques - Multiple Methods for Downloading Files from GitHub](/news/penetration-techniques-multiple-methods-for-downloading-files-from-github), tools like certutil, bitsadmin, and PowerShell work with HTTPS, while others such as some VBScript approaches require switching to objects that support HTTPS, like Msxml2.ServerXMLHTTP.6.0 or WinHttp.WinHttpRequest.5.1.
What is the difference between machine account SPNs and user account SPNs in Kerberoasting?
Machine account SPNs are registered under computer objects and use a random, complex password that cannot be used for remote logon, making them worthless for cracking. User account SPNs are registered under domain user objects, and their passwords can be cracked offline and reused for lateral movement. This distinction is why attackers focus on domain user SPNs, as explained in the [Domain Penetration - Kerberoasting](/news/domain-penetration-kerberoasting) article.
How can organizations defend against Kerberoasting attacks?
Defenses include using strong, complex passwords for service accounts, regularly rotating them, and avoiding the use of high-privileged domain user accounts for services. Additionally, enabling AES encryption for Kerberos tickets (instead of RC4) makes cracking harder, and monitoring for unusual TGS requests can detect ongoing attacks. For related defensive measures, see [Domain Penetration - Implementation of Pass The Hash](/news/domain-penetration-implementation-of-pass-the-hash) and [Penetration Techniques - Remote Registry in Windows](/news/penetration-techniques-remote-registry-in-windows).
What are the common methods to enumerate SPNs and request TGS tickets for Kerberoasting?
Attackers can enumerate valuable SPNs using the `setspn.exe` command, the PowerShell Active Directory module (`Get-ADUser -Filter {AdminCount -eq 1 -and servicePrincipalName -ne 0}`), or tools like PowerView (`Get-NetUser -SPN -AdminCount`). To request TGS tickets, they use `New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken` with the SPN name. These steps are detailed in the implementation section of [Domain Penetration - Kerberoasting](/news/domain-penetration-kerberoasting).
Why are Service Principal Names (SPNs) critical to a Kerberoasting attack?
SPNs uniquely identify services running on servers and are stored in Active Directory. An attacker first queries SPNs—particularly those registered under domain user accounts (Users) rather than machine accounts—because only user account passwords are valuable for lateral movement. The attacker then requests TGS tickets for services with high-privilege user SPNs, making SPN enumeration the first step in [Domain Penetration - Kerberoasting](/news/domain-penetration-kerberoasting).
What is Kerberoasting and how does it work?
Kerberoasting is a domain penetration technique where an attacker obtains a service ticket (TGS) for a service running under a domain user account, then cracks the ticket offline to recover the account's plaintext password. The attack exploits the Kerberos authentication process: any domain user can request a TGS for any service, and the TGS is encrypted with the NTLM hash of the service account's password, allowing brute-force cracking. For a full breakdown, see [Domain Penetration - Kerberoasting](/news/domain-penetration-kerberoasting).
How does an attacker send the search request to access internal file shares via Exchange ActiveSync?
The attacker sends an HTTP POST request to the EAS endpoint with a `Cmd=Search` parameter and a WBXML (WAP Binary XML) body. The WBXML encodes an XML document that specifies the UNC path to query (e.g., `\\myserver\myshare`). The tool [PEAS](https://github.com/FSecureLABS/peas) handles the WBXML conversion automatically, but understanding the protocol—as detailed in the article on [Application Techniques of Troubleshooting Platform in Penetration Testing](/news/application-techniques-of-troubleshooting-platform-in-penetration-testing)—is crucial for custom exploit development.
What is the PEAS tool and what capabilities does it offer for penetration testing?
PEAS (Python Exchange ActiveSync) is an open-source tool built on pyActiveSync that extends functionality to include credential verification, email extraction, and—most critically—file share enumeration and file retrieval. Attackers can use PEAS to list and download files from internal UNC shares, such as `\\dc1\SYSVOL`, simply by authenticating to Exchange ActiveSync. This technique demonstrates how a single compromised mailbox can lead to lateral movement within a domain, as described in the article on [Enabling Anonymous Access Shares on Windows Systems](/news/penetration-techniques-enabling-anonymous-access-shares-on-windows-systems-via-command-line).
How can an attacker verify a user's mailbox password through Exchange ActiveSync?
An attacker can verify credentials by sending an OPTIONS request to the default EAS URL (`/Microsoft-Server-ActiveSync`) with HTTP Basic Authentication. If the credentials are valid, the server returns a 200 status code. This technique is often used as the first step in a broader attack, such as accessing internal file shares. The article provides Python code examples for automating this verification, which is a foundational step in the [PEAS tool](https://github.com/FSecureLABS/peas).
What is Exchange ActiveSync and how can it be used to access internal file shares?
Exchange ActiveSync (EAS) is a Microsoft Exchange protocol that synchronizes mail, calendar, contacts, and tasks between a mail server and mobile devices. Security researchers have demonstrated that by exploiting EAS's search functionality, an attacker with valid credentials can enumerate and read internal file shares—such as SYSVOL—without needing direct network access to those shares. Tools like [PEAS](https://github.com/FSecureLABS/peas) automate this process, as detailed in the article on [Penetration Techniques - Accessing Internal File Shares via Exchange ActiveSync](/news/penetration-techniques-accessing-internal-file-shares-via-exchange-activesync).
Can you walk through the exploitation of the NDP461-KB3102438-Web.exe DLL hijacking vulnerability?
First, Process Monitor filters are set to capture all DLL load attempts (excluding successful loads initially) to find `NAME NOT FOUND` entries. Running NDP461-KB3102438-Web.exe reveals it tries to load `CRYPTSP.dll` unsuccessfully because the DLL is missing from its directory. A malicious DLL (e.g., one that pops a calculator) renamed to `CRYPTSP.dll` is placed in the same directory. Upon re-running the program, ProcessMonitor shows a successful load (`Result: SUCCESS`) of `C:\test\CRYPTSP.dll`, and the calculator executes, proving hijacking. This step-by-step is detailed in the [Rattler article](/news/automated-dll-hijacking-vulnerability-identification-tool-rattler-testing).
What is Rattler and how does it automate the discovery of DLL preloading vulnerabilities?
Rattler is an open-source tool by Chris Le Roy from SensePost that automates the identification of DLL hijacking vulnerabilities (also called DLL preloading vulnerabilities). It monitors DLL loading behavior during application execution to pinpoint which DLLs can be hijacked by analyzing the search order and KnownDLLs exclusion. The tool streamlines the manual Process Monitor approach described in the [Rattler testing article](/news/automated-dll-hijacking-vulnerability-identification-tool-rattler-testing), making it faster to find exploitable DLL paths in software like Explorer Suite.
Why are some DLLs like Kernel32.dll immune to hijacking while others like CRYPTSP.dll are vulnerable?
DLLs listed under the `KnownDLLs` registry key (e.g., `Kernel32.dll`) are protected because the system ignores the application's directory and loads them from predefined locations, making hijacking impossible. In contrast, if a DLL is not in `KnownDLLs` (like `CRYPTSP.dll`), the system follows the standard search order: with SafeDllSearchMode enabled, the application's directory is checked first. Since `CRYPTSP.dll` is uncommon, placing a malicious copy in the application folder causes it to be loaded instead. The [Rattler article](/news/automated-dll-hijacking-vulnerability-identification-tool-rattler-testing) demonstrates this with a test program that successfully hijacked `CRYPTSP.dll` but failed for `Kernel32.dll`.
How can Process Monitor be used to identify DLL hijacking vulnerabilities in an application?
Process Monitor can filter for operations like `CreateFile` and `LoadImage` with paths containing `.dll`, and exclude results of `SUCCESS` to show only `NAME NOT FOUND` events. This reveals which DLLs the application tries to load from its directory but cannot find. For example, testing NDP461-KB3102438-Web.exe showed it attempted to load `CRYPTSP.dll` with a `NAME NOT FOUND` result, indicating a potential hijacking point. By placing a malicious `CRYPTSP.dll` in the same directory and rerunning the application, Process Monitor confirms successful loading (Result: SUCCESS), as detailed in the [Rattler testing article](/news/automated-dll-hijacking-vulnerability-identification-tool-rattler-testing).
What is the root cause of DLL hijacking vulnerabilities and how does SafeDllSearchMode affect exploitation?
DLL hijacking vulnerabilities occur when a program calls a DLL without specifying its full path, allowing an attacker to place a malicious DLL with the same name in the application's directory. SafeDllSearchMode, enabled by default since Windows XP SP2, changes the search order: with it enabled, the application directory is searched first, then system directories, followed by the current directory (see [Automated DLL Hijacking Vulnerability Identification Tool Rattler Testing](/news/automated-dll-hijacking-vulnerability-identification-tool-rattler-testing)). Disabling SafeDllSearchMode moves the current directory to second priority, making hijacking easier, but even with it enabled, uncommon DLLs not in the KnownDLLs list are still vulnerable because the application directory is searched first.
Can the BGInfo whitelist bypass be executed from a network share?
Yes. Both `bginfo.exe` and the malicious `.bgi` file can be hosted on a remote server and executed via UNC path. The command `\\WIN-FVJLPTISCFE\test\bginfo.exe \\WIN-FVJLPTISCFE\test\test1.bgi /timer:0 /nolicprompt /silent` will bypass local whitelisting rules if the network share is trusted. This is similar to other LOLBin techniques like using `odbcconf` or `tracker` to load DLLs from remote sources, as seen in [Study Notes Weekly No.3](/news/study-notes-weekly-no-3-use-odbcconf-to-load-dll-get-exports-etw-usb-keylogger).
How can you automatically generate a malicious .bgi file using PowerShell?
You can write a PowerShell script that reads the fixed header (0x00000000 to 0x00000300) from a known `.bgi` template, encodes it as Base64, then decodes and writes it to a new file. Using `[System.IO.File]::WriteAllBytes()` and `[System.IO.FileStream]`, you append the flag byte (calculated as `path_length + 2`) and the VBS script path, then overwrite trailing `0D0A` bytes with nulls. This automation removes the need for manual GUI steps. The article [Study Notes of using BGInfo to bypass Application Whitelisting](/news/study-notes-of-using-bginfo-to-bypass-application-whitelisting) provides the complete PowerShell code for this process.
How can you manually create a malicious .bgi file to launch a VBS script?
You manually create a `.bgi` file by opening BGInfo, adding a VBS data source under 'Custom', pointing it to your script (e.g., `cmd.vbs`), and saving the project. The resulting binary file contains a fixed header (0x00000000 to 0x00000300) and then a flag byte at offset 0x00000301 indicating the VBS path length plus 2. The flag value is `path_length + 2` in hex. The VBS path must use uppercase drive letters (e.g., `C:\test\cmd.vbs`). For step-by-step instructions, refer to the article [Study Notes of using BGInfo to bypass Application Whitelisting](/news/study-notes-of-using-bginfo-to-bypass-application-whitelisting).
What is BGInfo and how can it be abused to bypass application whitelisting?
BGInfo is a Sysinternals tool that displays system information on the desktop, but it also supports custom data sources like VBS scripts. By configuring a VBS script to launch `cmd.exe` and saving it as a `.bgi` file, an attacker can execute arbitrary commands even under application whitelisting restrictions. The bypass works by running `bginfo.exe vbs.bgi /timer:0 /nolicprompt /silent`, which triggers the script without user interaction. Note that this technique only works with BGInfo versions prior to 4.22, which patched the vulnerability. For more details, see [Study Notes of using BGInfo to bypass Application Whitelisting](/news/study-notes-of-using-bginfo-to-bypass-application-whitelisting).
What is the recommended defense against using msxsl.exe to bypass AppLocker?
Administrators should create an AppLocker executable rule that explicitly denies or restricts msxsl.exe. Even if the binary’s path is changed, the rule will prevent it from running. This defense is demonstrated in the article and is part of a broader strategy of controlling all signed binaries that can execute scripts. For further reading, similar techniques are covered in [Use xwizard.exe to load dll](/news/use-xwizard-exe-to-load-dll) and [Use Logon Scripts to maintain persistence](/news/use-logon-scripts-to-maintain-persistence).