Cybersecurity Q&A
Browse concise answers derived from our published, source-linked cybersecurity coverage.
What are the default ports used by Veeam Backup & Replication services for debugging and how do I locate the process to attach a debugger?
The Veeam Backup Service (Veeam.Backup.Service.exe) uses ports 9392 and 9401 (SSL). To locate the process, run `netstat -ano | findstr 9401` to find the PID (e.g., 7132), then use dnSpy to attach to that process. For more details, see the [Setting Up Veeam Backup & Replication Vulnerability Debugging Environment](/news/setting-up-veeam-backup-replication-vulnerability-debugging-environment) article.
How can a domain user read all user hashes by exploiting ACL on ntds.dit?
An attacker can modify the ACL of the `ntds.dit` file (or its share) in a domain controller's SYSVOL to grant read access to a regular domain user. Once the ACL is changed, the user can access and extract all domain password hashes. This domain ACL exploitation technique is explained in the [ACL article](/news/penetration-techniques-access-control-list-in-windows).
What PowerShell commands can be used to add full access permissions for a user to a file?
You can use `Get-Acl` and `Set-Acl` cmdlets to create a `FileSystemAccessRule` with `FullControl` and inheritance flags, then add it via `AddAccessRule`. The article provides a complete `Add-ACL` function that accepts a path and applies the rule, with optional recursion using `Get-ChildItem`. Further details are in the [PowerShell ACL section](/news/penetration-techniques-access-control-list-in-windows).
How can an attacker use ACL modification for local privilege escalation backdoor?
After gaining administrator privileges, an attacker can modify the ACL of system directories (e.g., using icacls or PowerShell) to grant full control to a regular user. This enables the regular user to exploit techniques like DLL hijacking or file replacement for privilege escalation. This scenario is covered in the exploitation section of the [ACL article](/news/penetration-techniques-access-control-list-in-windows).
What are the key components of an Access Control List (ACL) in Windows?
An ACL consists of a Discretionary Access Control List (DACL) and a System Access Control List (SACL). The DACL determines which users or groups are allowed or denied access, while the SACL logs access attempts. Each ACL contains multiple Access Control Entries (ACEs) that specify the actual permissions, as detailed in this [article on ACLs](/news/penetration-techniques-access-control-list-in-windows).
What is the Nmap zip version for Windows and how is it configured?
Nmap provides a command-line zip version for Windows, downloadable from the official Nmap site. After extracting the zip, it can be used directly from the command line without a full installation, provided WinPcap is installed (or set up as described in the article). This allows penetration testers to leverage Nmap's powerful scanning capabilities on a Windows pivot machine. For related techniques on Windows, see [Penetration Techniques - Deleting Single Windows Log Entries](/news/penetration-techniques-deleting-single-windows-log-entries).
What are the basic usage examples of Masscan for network scanning?
Masscan can scan a network range for specific ports, e.g., `masscan.exe -p80 192.168.81.1/24` to find hosts with port 80 open. It also supports scanning all ports on a host (`-p0-65535`), retrieving banners with `--banners`, and using configuration files via `-c`. Default scans use SYN scan with no ping, no DNS, and randomized hosts. Adjust speed with `--rate`. These scanning techniques are foundational for information gathering in internal network penetration, as also discussed in [Penetration Techniques - Enabling Anonymous Access Shares on Windows Systems via Command Line](/news/penetration-techniques-enabling-anonymous-access-shares-on-windows-systems-via-command-line).
How can you install WinPcap silently via the Windows command line?
WinPcap can be installed via command line by simulating its installation: copy `packet.dll` and `wpcap.dll` to `%SystemRoot%\system32`, copy `npf.sys` to `%SystemRoot%\system32\drivers`, then create and start the npf service using `sc create npf` and `sc start npf`. A batch script can automate this for both 32-bit and 64-bit systems, making it ideal for internal network penetration where GUI installation is not available. This technique is covered in detail in the article [Penetration Techniques - Running Masscan and Nmap on Windows Platform](/news/penetration-techniques-running-masscan-and-nmap-on-windows-platform).
How do you compile Masscan on Windows using VS2012?
To compile Masscan on Windows with VS2012, you need to add VS2012 configuration information in `misc/string_s.h` to fix compilation errors. After successful compilation, you must copy `Packet.dll` and `Wpcap.dll` (from a system with WinPcap installed) to the same directory as `masscan.exe`. However, the target system still requires WinPcap to be installed for scanning to work. For more details, see the original article: [Penetration Techniques - Running Masscan and Nmap on Windows Platform](/news/penetration-techniques-running-masscan-and-nmap-on-windows-platform).
Why does ADAudit Plus force the password algorithm to bcrypt even if another algorithm is specified?
The code in `AuthUtil.createUserAccount()` checks if the algorithm is not "bcrypt" and logs an info message, then overrides the algorithm to bcrypt. This ensures all passwords are hashed with the strong, adaptive bcrypt algorithm for better security. This enforcement is noted in the [ADAudit Plus Analysis - Data Encryption Analysis](/news/adaudit-plus-analysis-data-encryption-analysis) article.
What happens when a custom user is added in ADAudit Plus, regarding password encryption?
When a custom user is added via Admin > Technicians, the system retrieves the password profile and workload factor, generates a bcrypt salt using `BCrypt.gensalt(workload)`, and calls `getEncryptedPassword()` to hash the plaintext password. The algorithm is forced to bcrypt if not already set. The hashed password, salt, algorithm, and factor are then stored in the `aaapassword` table.
Where are the encrypted passwords stored in the ADAudit Plus database, and how can they be queried?
Encrypted passwords are stored in the `public.aaapassword` table. They can be queried using PostgreSQL with a command like: `SELECT * FROM public.aaapassword ORDER BY password_id ASC;`. The table includes columns for `password`, `algorithm` (set to bcrypt), `salt`, and `factor`. More details are in the [ADAudit Plus Analysis - Data Encryption Analysis](/news/adaudit-plus-analysis-data-encryption-analysis) article.
How is the bcrypt salt generated and what determines the workload factor in ADAudit Plus?
The salt is generated using `BCrypt.gensalt(workload)`, where `workload` is derived from the `FACTOR` column in the `AaaPasswordProfile` table. If the factor is not set or is invalid, it defaults to a predefined workload constant (`PAM.workload`). The workload factor determines the computational cost of bcrypt hashing.
What encryption algorithm is used to store passwords in ADAudit Plus, and where is it implemented?
ADAudit Plus uses the bcrypt algorithm to hash passwords, as shown in the [ADAudit Plus Analysis - Data Encryption Analysis](/news/adaudit-plus-analysis-data-encryption-analysis) article. The implementation is located in the `com.adventnet.authentication.util.AuthUtil.class` file inside `AdvAuthentication.jar`. The code forces the algorithm to bcrypt if it's not already set.
Why was memcpy used instead of strcpy in the test code for shellcode injection?
strcpy stops copying when it encounters a null byte (0x00), which would truncate shellcode containing necessary null bytes (e.g., address pointers). memcpy does not have this limitation, making it more suitable for testing shellcode that may include null bytes. This practical consideration is highlighted in the article's test setup for [Windows Shellcode Study Notes - Bypassing DEP via VirtualProtect](/news/windows-shellcode-study-notes-bypassing-dep-via-virtualprotect).
What bug was encountered when using the automatically generated ROP chain from mona, and why did it cause VirtualProtect to fail?
The automatically generated ROP chain unintentionally overwrote the SEH chain (Structured Exception Handler), corrupting the parameters passed to the VirtualProtectEx function. As a result, the function call returned 0, indicating failure. This bug forces the exploit developer to manually verify and fix the ROP chain based on the specific execution environment, as described in the debugging section of [Windows Shellcode Study Notes - Bypassing DEP via VirtualProtect](/news/windows-shellcode-study-notes-bypassing-dep-via-virtualprotect).
How does the mona plugin in Immunity Debugger assist in generating a ROP chain for DEP bypass?
The mona plugin automatically searches all loaded DLLs for suitable gadgets to construct a ROP chain that calls VirtualProtect and disables DEP. After running `!mona rop -m *.dll -cp nonull`, it produces files like rop_chains.txt containing ready-to-use ROP chains. However, the article notes that the generated chain may have environment-specific bugs, such as overwriting the SEH chain, requiring manual adjustment. This process is part of the detailed walkthrough in [Windows Shellcode Study Notes - Bypassing DEP via VirtualProtect](/news/windows-shellcode-study-notes-bypassing-dep-via-virtualprotect).
What is the core principle behind bypassing DEP using the VirtualProtect function?
The bypass relies on Return-Oriented Programming (ROP) to call VirtualProtect and change the shellcode's memory page permissions to executable (PAGE_EXECUTE_READWRITE). Instead of jumping directly to the shellcode, the exploit constructs a ROP chain that first invokes VirtualProtect with appropriate parameters, then transfers control to the shellcode. This technique is detailed in [Windows Shellcode Study Notes - Bypassing DEP via VirtualProtect](/news/windows-shellcode-study-notes-bypassing-dep-via-virtualprotect), while an alternative using VirtualAlloc is covered in [Windows Shellcode Study Notes - Bypassing DEP with VirtualAlloc](/news/windows-shellcode-study-notes-bypassing-dep-with-virtualalloc).
What is Data Execution Prevention (DEP) and how does it prevent shellcode execution?
Data Execution Prevention (DEP) is a security feature introduced in Windows XP SP2 that marks memory pages containing data as non-executable. When a stack overflow successfully redirects execution to shellcode in the data segment, DEP triggers a CPU exception instead of executing the malicious instructions. This makes direct shellcode execution impossible, as explained in [Windows Shellcode Study Notes - Bypassing DEP via VirtualProtect](/news/windows-shellcode-study-notes-bypassing-dep-via-virtualprotect).
How is the shellcode extracted from the compiled executable, and what tool is used?
After compiling with the recommended settings, the .exe is opened in IDA (Interactive Disassembler). The machine code of the `shell_code()` function is extracted as a byte sequence. Since the entry function is first, the extraction can start from its beginning. The article provides a complete code example that dynamically resolves API addresses without relying on imports. This method is part of a series on shellcode development, including bypassing DEP or UAC.