Cybersecurity Q&A
Browse concise answers derived from our published, source-linked cybersecurity coverage.
What is the core idea behind using a password hash to authenticate to Exchange Web Service (EWS)?
The core idea is to simulate NTLM Over HTTP protocol by directly using the NTLM hash to encrypt the server's Challenge, bypassing the need for a plaintext password. Instead of relying on Mimikatz's over pass the hash (which requires admin privileges), you can implement this programmatically using a tool like Impacket to send the appropriate NTLM authentication messages. The [Penetration Techniques - Pass the Hash with Exchange Web Service](/news/penetration-techniques-pass-the-hash-with-exchange-web-service) article explains the step-by-step approach.
How can I decrypt Exchange communication traffic to analyze NTLM authentication steps?
You can decrypt Exchange TLS traffic by either configuring the Exchange server to export its certificate and disabling ECDH, or by setting the `SSLKEYLOGFILE` environment variable on the client. Then use Wireshark with the corresponding RSA keys or pre-master secret log to capture plaintext data. This method is detailed in the [Penetration Techniques - Pass the Hash with Exchange Web Service](/news/penetration-techniques-pass-the-hash-with-exchange-web-service) article, which demonstrates how to observe NTLM Over HTTP exchanges.
Which tools can verify CAT file digital signatures, and why might Get-AuthenticodeSignature fail?
`signtool.exe` and `sigcheck.exe` can verify CAT signatures, while PowerShell’s `Get-AuthenticodeSignature` may fail on Windows 7 because it does not natively support catalog queries. On Windows 10, `Get-AuthenticodeSignature` retrieves CAT signatures. For example, using `signtool.exe verify /pa /a C:\Windows\System32\xwizard.exe` shows the catalog-signed status, whereas `Get-AuthenticodeSignature` might return an unsigned result on older systems.
Does moving a CAT-file-signed executable to a different location invalidate its digital signature?
No, moving the file does not invalidate the CAT digital signature. The article demonstrates that after relocating xwizard.exe, both `signtool.exe verify /pa /a` and `sigcheck.exe` still report the signature as valid. This is because the signature is stored in the system catalog database, not tied to the file path. This behavior is important for understanding file trust mechanisms in Windows.
How does a CAT file digital signature work and how is it applied?
A CAT file stores the SHA1 hashes of multiple files. You generate a .cat file using `makecat.exe`, sign the .cat file with a certificate via `signtool.exe`, and then add it to the system’s security catalog database with `signtool catdb`. Once added, any file whose hash is in the CAT file is considered signed by the system, even though the digital signature cannot be viewed through file properties or `Get-AuthenticodeSignature` on older Windows versions.
What are the two main methods for adding digital signatures to files in Windows?
The two main methods are Authenticode, which appends a digital signature directly to the end of a file (e.g., consent.exe), and catalog signing via CAT files, where the file’s hash is stored in a security catalog that is then signed. Authenticode signatures appear in file properties, while CAT signatures do not. For a detailed comparison, see the [CAT File Digital Signature Usage Techniques](/news/cat-file-digital-signature-usage-techniques) article.
What are the key takeaways from the expansion of techniques for exploiting simulated trusted directories?
The article demonstrates that simulated trusted directories are a versatile attack vector for bypassing security tools and system mechanisms. Beyond UAC bypass, attackers can evade Autoruns persistence detection, deceive ShimCache forensic artifacts, and forge legitimate UAC prompts by combining directory spoofing with signature stealing. Understanding these techniques is crucial for blue teams to implement defensive measures such as monitoring unusual directory paths and verifying file signatures. For further details, refer to the full [Expansion of Techniques for Exploiting Simulated Trusted Directories](/news/expansion-of-techniques-for-exploiting-simulated-trusted-directories) article.
How can an attacker forge a normal UAC prompt by simulating a trusted directory?
The attacker creates a simulated trusted directory and places a malicious executable requiring administrator privileges (e.g., `testuac.exe`) under a legitimate system name like `diskpart.exe`. When executed, UAC displays the path as the trusted `diskpart.exe`, but the missing signature triggers a warning. To fully spoof the prompt, the attacker can use tools like SigThief to steal an Authenticode signature from a legitimate file (e.g., `consent.exe`) and attach it to the malicious binary. This technique builds on the concepts discussed in [Analysis of UAC Bypass Exploitation by Mocking Trusted Directories](/news/analysis-of-uac-bypass-exploitation-by-mocking-trusted-directories).
What is the method for deceiving ShimCache using a simulated trusted directory?
The attacker creates a simulated trusted directory (e.g., `c:\windows \system32`) and copies a malicious executable (e.g., `putty.exe`) as `notepad.exe` into it. After executing `notepad.exe` from that path, the ShimCache records the execution as `notepad.exe` for the system drive. Upon reboot, forensic tools parsing the ShimCache will show a legitimate filename, making the malicious execution highly deceptive. This technique is explained in the [Expansion of Techniques for Exploiting Simulated Trusted Directories](/news/expansion-of-techniques-for-exploiting-simulated-trusted-directories) article.
How can an attacker bypass Autoruns detection by simulating a trusted directory?
An attacker can create a simulated trusted directory (e.g., `\\?\c:\windows ` with a trailing space) and place a malicious executable like `putty.exe` under a legitimate name (e.g., `notepad.exe`). By registering that path in startup locations such as Userinit or LSA Providers, Autoruns sees the file name as a Microsoft-signed executable and hides it by default. This technique, detailed in [Expansion of Techniques for Exploiting Simulated Trusted Directories](/news/expansion-of-techniques-for-exploiting-simulated-trusted-directories), allows the malicious payload to run at startup without appearing in Autoruns' default view.
How did the author fix the 'No module named memorpy' error in LaZagne?
The error occurred because the original code had a typo, referencing `memorpy` instead of `memory_profiler`. However, simply installing `memory_profiler` and modifying the import allowed compilation but caused runtime errors. The correct fix was to install the real `memorpy` package from its GitHub repository using `pip install https://github.com/n1nj4sec/memorpy/archive/master.zip`. This resolved both the import and runtime issues. The experience highlights the importance of verifying third-party package sources when fixing bugs in security tools.
What steps are required to compile a custom LaZagne script into a standalone Windows executable?
The article covers two methods: py2exe and PyInstaller. For py2exe, you create a `mysetup.py` script that points to `laZagne.py`, then run `python mysetup.py py2exe`. You must ensure all dependencies (like `pyasn1`) are accessible. For PyInstaller, install it (e.g., via source compilation), then use `pyinstaller -F laZagne.py` to produce a single exe. Both methods generate an executable in a `dist` folder. This allows you to distribute your extended LaZagne version without requiring Python on the target machine.
How does 360 Speed Browser store saved passwords compared to Google Chrome?
360 Speed Browser, like Chrome, uses the Chromium kernel and stores encrypted passwords in an SQLite database file named `Login Data`. The key difference is the folder path: Chrome uses `AppData\Local\Google\Chrome\User Data`, while 360 Speed Browser uses `AppData\Local\360Chrome\Chrome\User Data`. The data structure and decryption method are identical, so a LaZagne module for Chrome can be adapted simply by changing the path. For a deeper look at Chrome password extraction, refer to [Penetration Techniques - Offline Export of Passwords Saved in Chrome Browser](/news/penetration-techniques-offline-export-of-passwords-saved-in-chrome-browser).
What is LaZagne and how can it be extended to support additional browsers like 360 Speed Browser?
LaZagne is an open-source Python tool for recovering passwords stored locally on a computer. To add support for a new browser, you create a new Python module (e.g., `cse.py`) under `lazagne/softwares/browsers`, following the structure of existing modules like `chrome.py`. Then register the class in `manageModules.py` by importing the module and adding its class to the module list. The article demonstrates this for 360 Speed Browser, which uses the same Chrome kernel and stores passwords in a similar `Login Data` SQLite file. For a similar approach for Firefox, see [Exporting saved passwords from Firefox browser via Network Security Services](/news/exporting-saved-passwords-from-firefox-browser-via-network-security-services).
How can defenders detect LDAP-based brute-force attempts against domain user passwords?
Defenders can monitor the `lastbadpasswordattempt` attribute in domain user properties, which records the timestamp of the last incorrect login. Anomalous patterns in this attribute across multiple users may indicate a password spraying attack. Additionally, enabling logging on the domain controller for LDAP bind failures (error 0x209A or “Invalid credentials”) and correlating with high `badPwdCount` values can help identify ongoing brute-force activity.
What is the difference between brute-forcing domain passwords inside vs. outside the domain, and what tools are used?
Inside the domain, you can use `DomainPasswordSpray` to perform LDAP queries via ADSI, which also allows retrieving the password policy. Outside the domain, you can use `ldapsearch` on Kali with a bash loop like `for i in $(cat test.txt); do ldapsearch ...`, or a modified version of `DomainPasswordSpray` that uses an LDAP path (e.g., `LDAP://192.168.1.1/DC=test,DC=com`) instead of domain context. The article [Penetration Basics - Brute-Forcing Domain User Passwords via LDAP Protocol](/news/penetration-basics-brute-forcing-domain-user-passwords-via-ldap-protocol) provides detailed examples.
How can you identify disabled and locked domain users before launching a password spray attack?
Disabled users are identified by the `ACCOUNTDISABLE` flag (bit 0x0002) in `userAccountControl`. Locked users are detected by checking the `badPwdCount` and `lockoutTime` attributes rather than the LOCKOUT flag (bit 0x0010), which is unreliable. For example, with PowerView you can run `Get-NetUser | select name,badPwdCount,lockoutTime` to see locked accounts. This filtering is critical before using tools like `DomainPasswordSpray`.
What are the key considerations to avoid account lockouts when brute-forcing domain user passwords via LDAP?
The default lockout threshold is 5 incorrect attempts, and locked accounts typically require a 30-minute waiting period. You must first obtain the domain password policy using tools like [Penetration Basics - Obtaining Domain User Password Policies](/news/penetration-basics-obtaining-domain-user-password-policies) to determine the `lockoutThreshold` value and stay within that limit. Additionally, after brute-forcing, you cannot clear the last incorrect password timestamp because it is owned by the Security Accounts Manager (SAM).
How does the `.NET_oneliner` payload load assemblies from memory in Pupy?
The `.NET_oneliner` payload generates a PowerShell command that uses `[Reflection.Assembly]::Load()` to download and execute a .NET assembly directly from memory. For example: `powershell -w hidden -enc "xxxxxxxxxxxxxx"`. This approach avoids writing the assembly to disk and leverages PowerShell's ability to load .NET objects. The underlying technique is further analyzed in the article [Analysis of Exploiting .NET Assembly Loading from Memory (Assembly.Load)](/news/pupy-exploitation-analysis-features-on-windows-platform) — note that the provided content references a previous article on this topic, but you can also refer to the main Pupy feature article for context.
Which communication protocols can be used with Pupy's transports?
Pupy supports a wide range of communication protocols including `obfs3`, `http`, `ssl`, `ecm`, `tcp_cleartext`, `dfws`, `rsa`, `udp_secure`, `kc4`, `ec4`, `ws`, `scramblesuit`, `udp_cleartext`, and `ssl_rsa`. These can be customized in the transport configuration files located at `pupy/pupy/network/transports/conf.py`. The variety of protocols allows operators to blend traffic with normal HTTP, SSL, or obfuscated streams to evade detection, similar to techniques seen in [Application Techniques of Troubleshooting Platform in Penetration Testing](/news/application-techniques-of-troubleshooting-platform-in-penetration-testing).