Cybersecurity Q&A
Browse concise answers derived from our published, source-linked cybersecurity coverage.
Which tools are commonly used to capture Net-NTLM hashes, and how do they work?
Two widely used tools are Responder (Python, available at https://github.com/lgandx/Responder) and Inveigh (PowerShell, at https://github.com/Kevin-Robertson/Inveigh). Both operate as MITM listeners on the network, spoofing services like SMB, HTTP, or LLMNR to intercept NTLM authentication attempts. When a client sends a Net-NTLM response to an attacker-controlled service, the tool captures the hash for offline cracking. These tools are essential for lateral movement in penetration tests, especially when combined with techniques like relaying—see the original article's reference to [byt3bl33d3r's guide](https://byt3bl33d3r.github.io/practical-guide-to-ntlm-relaying-in-2017-aka-getting-a-foothold-in-under-5-minutes.html) for more advanced usage.
What is the correct format for a Net-NTLMv2 hash when using Hashcat?
For cracking Net-NTLMv2 hashes with Hashcat (mode 5600), the format is: `username::domain:challenge:HMAC-MD5:blob`. The `challenge` is the NTLM server challenge (16-bit random value), `HMAC-MD5` corresponds to the NTProofStr from the packet, and `blob` is the remainder of the client response after removing NTProofStr. For example, from a packet capture you might assemble a string like `a::192.168.62.139:c0b5429111f9c5f4:a5f1c47844e5b3b9c6f67736a2e1916d:0101000000000000669dae86ba8bd301a9134eee81ca25de...`. This format is essential for successful cracking with Hashcat, as detailed in the [article](/news/introduction-to-windows-password-hashes-ntlm-hash-and-net-ntlm-hash).
How can an attacker obtain a Net-NTLM hash in a network environment?
Attackers can capture Net-NTLM hashes by performing a man-in-the-middle (MITM) attack using tools like Responder (Python) or Inveigh (PowerShell). When a client attempts to authenticate to a server (e.g., via SMB), the attacker intercepts the challenge and response, extracting the Net-NTLM hash. Alternatively, an attacker can force an outbound NTLM authentication request from a target (e.g., via a malicious SMB share or a link in an email) to a controlled system, thereby capturing the hash. The extracted hash can then be cracked offline with tools like Hashcat.
How is an NTLM hash generated from a plaintext password?
First, the plaintext password is converted to hexadecimal format, then transformed into Unicode by appending 0x00 after each byte. This Unicode string is then hashed using the MD4 algorithm to produce a 32-character hexadecimal hash, which is the NTLM hash. For example, the password "test123" becomes the NTLM hash c5a237b7e9d8e708d8436b6148a25fa1—this can be verified with tools like Mimikatz by extracting the hash from the lsass.exe process. Penetration testers often obtain NTLM hashes from the SAM file or NTDS.dit, as discussed in [Penetration Techniques - Obtaining Local User Hashes via SAM Database](/news/penetration-techniques-obtaining-local-user-hashes-via-sam-database).
What is the difference between an NTLM hash and a Net-NTLM hash?
An NTLM hash is the user password hash stored locally in the Windows Security Account Manager (SAM) or in the NTDS.dit file on domain controllers, derived by MD4-encrypting the Unicode representation of the plaintext password. In contrast, a Net-NTLM hash is the hash that appears in network NTLM authentication as part of the challenge/response process—the client encrypts a server-issued challenge (a random 16-bit value) using its NTLM hash, and the resulting response contains the Net-NTLM hash. For more details, see [Introduction to Windows Password Hashes - NTLM Hash and Net-NTLM Hash](/news/introduction-to-windows-password-hashes-ntlm-hash-and-net-ntlm-hash).
Why does the WinRM service require administrator privileges for initial configuration, and how can an attacker still exploit it with low privileges?
Initial WinRM configuration (e.g., `winrm quickconfig` or changing the listener port) requires administrator privileges because it modifies service settings and URL ACLs. However, once configured, the service runs as SYSTEM and listens on the new port, so the attacker only needs low privileges to initiate remote connections from another machine. The critical part is gaining admin rights once to set up the persistence. Alternatively, low-privilege exploitation can be achieved through the HTTP Server API, as described in the article, by using pre-existing URL ACLs like `http://+:80/Temporary_Listen_Addresses/` which do not require admin rights to listen.
What are the detection methods for identifying WinRM service running on non-standard ports like 80 or 443?
Detection involves checking for anomalies in IIS logs and network traffic. Since the WinRM service uses HTTP.sys, requests to port 80 that are not handled by IIS will still generate entries in the HTTP.sys log. Administrators can monitor for unusual URL patterns (e.g., `/wsman` paths) or sudden increases in HTTP traffic on normally passive endpoints. Additionally, reviewing URL ACLs with `netsh http show urlacl` may reveal unauthorized reservations. For more on detection and related techniques, see [Testing and Analysis of Bypassing AppLocker Using LUA Scripts](/news/testing-and-analysis-of-bypassing-applocker-using-lua-scripts).
What is the role of the HTTP Server API in achieving port reuse for command execution on a Windows server with low privileges?
The HTTP Server API allows applications to register URL endpoints on the same port via `HttpAddUrl()`. An attacker can leverage existing URL ACLs like `http://+:80/Temporary_Listen_Addresses/` which grant `Everyone` listen permission by default, enabling a custom executable running with standard user privileges to receive HTTP requests. The attacker can then modify the sample code to execute commands sent via GET requests and return results, effectively achieving remote command execution without administrator privileges. This technique is covered in [Bypassing firewalls using IIS module functionality](/news/bypassing-firewalls-using-iis-module-functionality) as another example of reuse.
How can an attacker bypass a firewall that only allows port 80 or 443 to remotely manage a Windows server using the WinRM service?
An attacker can reconfigure the WinRM service to listen on port 80 or 443 instead of its default port 5985. This is possible because Windows HTTP.sys allows multiple processes to share the same port. By running a command like `winrm set winrm/config/Listener?Address=*+Transport=HTTP @{Port="80"}` and enabling compatibility mode with `EnableCompatibilityHttpListener`, the WinRM service can reuse port 80. For more details, see the original article [Bypassing firewall using IIS port sharing feature](/news/bypassing-firewall-using-iis-port-sharing-feature).
Which default ports and services are important for debugging Veeam Backup & Replication vulnerabilities?
Key services include Veeam.Backup.Service (ports 9392 and 9401 with SSL), Veeam.Backup.ConfigurationService (9380), and Veeam.Backup.CatalogDataService (9393). The RESTful API uses ports 9399 and 9398, while the Web UI uses 9080 and 9443. For debugging, focus on port 9401 to attach a debugger to the Veeam.Backup.Service.exe process. Understanding these ports helps in identifying attack surfaces as described in the [Veeam Backup & Replication Vulnerability Debugging Environment Setup](/news/veeam-backup-replication-vulnerability-debugging-environment-setup).
Why might the veeam-creds PowerShell script fail on Veeam Backup & Replication 11 and higher, and how can it be fixed?
The script fails because it uses the deprecated sqloledb driver, which is expired on newer systems. To fix, replace sqloledb with a supported driver like MSOLEDBSQL or MSOLEDBSQL19. First, check if the driver is installed using PowerShell's OleDbEnumerator. If not, download and install the appropriate OLEDB driver from Microsoft, which may also require updating Microsoft Visual C++ Redistributable to version 14.34 or later. This workaround is essential for successful credential extraction in the [Veeam Backup & Replication Vulnerability Debugging Environment Setup](/news/veeam-backup-replication-vulnerability-debugging-environment-setup).
What is CVE-2023-27532 and how does it relate to credential exposure in Veeam?
CVE-2023-27532 is a vulnerability that allows leaking plaintext credentials stored in Veeam Backup & Replication. The exploit calls the CredentialsDbScopeGetAllCreds function to retrieve serialized XML data containing encrypted credentials. By using Veeam's built-in DLLs (e.g., Veeam.Backup.Common.dll) to deserialize the data, an attacker can obtain the plaintext credentials. This vulnerability targets the credentials managed in the Veeam console. The [Veeam Backup & Replication Vulnerability Debugging Environment Setup](/news/veeam-backup-replication-vulnerability-debugging-environment-setup) article provides a brief analysis and POC reference.
How can I extract database credentials from Veeam Backup & Replication during vulnerability analysis?
Extract credentials by first obtaining the database connection port from SQL Server Configuration Manager (e.g., for VEEAMSQL2016) and the database name from the configuration page or registry. Then use tools like DbSchema or PowerShell scripts (e.g., veeam-creds, but with updated OLEDB driver like MSOLEDBSQL19) to connect and query the VeeamBackup database for stored credential information. For full details, see the credential extraction section in the [Veeam Backup & Replication Vulnerability Debugging Environment Setup](/news/veeam-backup-replication-vulnerability-debugging-environment-setup) article.
What steps are needed to set up a debugging environment for Veeam Backup & Replication vulnerabilities like CVE-2023-27532?
To set up a debugging environment, first install Veeam Backup & Replication from the official download using the appropriate license. Then locate the Veeam.Backup.Service.exe process (default port 9401) and attach a debugger like dnSpy. Create .ini files for Veeam.Backup.Service.dll, Veeam.Backup.DBManager.dll, and others to allow variable inspection during debugging. This setup is detailed in the [Veeam Backup & Replication Vulnerability Debugging Environment Setup](/news/veeam-backup-replication-vulnerability-debugging-environment-setup) article.
What common pitfalls should be addressed when scanning WebLogic via the T3 protocol, and how does the open-source Python script handle them?
Common pitfalls include the need to resend the T3 handshake when only `HELO` is returned (to get the full version), and handling cases where the T3 protocol is completely disabled (connection refused). The script closes and reinitializes the socket for resending, and uses regex to extract version data. The complete code is available on GitHub, as noted in the [article's open-source section](/news/penetration-basics-weblogic-version-detection).
Why is it necessary to distinguish between early and currently used WebLogic versions when using the T3 protocol?
Early versions (e.g., 10.3.6.0) return version info in a `t3 <version>` format, while modern versions (e.g., 12.2.1.3.0) use a `HELO:<version>` format followed by parameters. The Python script uses regex to handle both patterns, improving accuracy. This distinction is critical for reliable detection, as discussed in the [WebLogic version detection article](/news/penetration-basics-weblogic-version-detection).
How can you detect the WebLogic version when the Admin Console is closed or the URL is modified?
If the Admin Console is closed, you can still detect the version using the T3 protocol, which often returns version information in the socket handshake. Alternatively, if the console is accessible but its default path is changed, you must locate the correct URL (e.g., `/console/login/LoginForm.jsp`) either by manual discovery or by inspecting the configuration file. These scenarios are detailed in the original article's implementation notes.
What are the two main methods for detecting the WebLogic version during a penetration test?
The two primary methods are via the WebLogic Admin Console web page using HTTP and via the T3 protocol. The HTTP method accesses the console's default URL to parse version info, while the T3 method uses a socket connection to extract version details. For a deeper look at both techniques, refer to the full article on [Penetration Basics — WebLogic Version Detection](/news/penetration-basics-weblogic-version-detection).
Where can the complete Python implementation for MinIO version detection be found, and what commands does it support?
The full source code is available on GitHub at `https://github.com/3gstudent/Homework-of-Python/blob/master/MinIO_GetVersion.py`. It supports two commands: `getversion` to retrieve version details and `getinfo` to gather comprehensive system information. This tool is part of a series of [penetration basics detection scripts](/news/penetration-basics-minio-version-detection-1) for various services.
What common issue occurs when the MinIO port is not the default, and how is it handled in the automation script?
If the port is incorrect, the server returns a 400 status code. The automation script first tries the default port 9000; if it gets a 400 error, it attempts port 9001. If both fail, it prompts the user to manually adjust the port, ensuring the tool works in diverse environments.