Cybersecurity Q&A
Browse concise answers derived from our published, source-linked cybersecurity coverage.
Can SSPs be deleted or enumerated, and what are the limitations?
SSPs can be enumerated using `EnumerateSecurityPackages` to list all loaded packages (Kerberos, NTLM, etc.). However, the `DeleteSecurityPackage` API returns an error (0x80090302) because Microsoft does not allow SSP removal without a system restart, as noted in security research. This limitation means that once a malicious SSP is added via registry or RPC, it persists until reboot, similar to challenges faced in [Credential Manager retrieval](/news/penetration-techniques-information-retrieval-from-windows-credential-manager).
How does misc::memssp differ from SSP registration for credential extraction?
`misc::memssp` directly modifies the lsass process memory to inject code that captures credentials, rather than registering a legitimate SSP. This in-memory patching approach avoids file writes to disk and registry changes, generating a log at `mimilsa.log`. It is comparable to techniques used in [Password Filter DLL](/news/application-of-password-filter-dll-in-penetration-testing) but operates purely in memory, making it harder to detect.
What are the three methods to add an SSP like mimilib.dll in Mimikatz?
Method 1 involves copying mimilib.dll to `C:\Windows\System32` and adding it to the registry key `HKLM\System\CurrentControlSet\Control\Lsa\Security Packages`, then rebooting. Method 2 uses the `AddSecurityPackage` API after registry modification, which loads the SSP immediately without reboot. Method 3 exploits RPC to force lsass to load the DLL without touching the registry or memory, offering stealth advantages as described in the [Usage of SSP in Mimikatz](/news/usage-of-ssp-in-mimikatz) article.
What is SSP and how does Mimikatz use it to extract credentials?
SSP (Security Support Provider) is a DLL that handles authentication in Windows. Mimikatz uses its mimilib.dll as an SSP to hook the `SpAcceptCredentials` function, which captures plaintext passwords passed by LSA and saves them to a log file like `kiwissp.log`. This technique is similar to [sekurlsa::wdigest](/news/implementation-of-sekurlsa-wdigest-in-mimikatz) but operates by registering a custom SSP rather than reading memory.
Why does Pupy use a separate transfer component for screen control, and what advantage does it provide?
Pupy's transfer component acts as a relay between Client and Server, encoding and forwarding data via websocket while applying RSA+AES encryption. This design increases the difficulty of intercepting or reverse-engineering communication, enhancing security. Removing this transfer simplifies data visibility but sacrifices encryption, as demonstrated in the alternative HTTP-Remote-Desktop-Server approach.
What should developers consider when customizing the HTTP-Remote-Desktop-Server for their own use?
Key considerations include: using 32-bit Python2 for PyGtk compatibility, setting firewall rules (e.g., `netsh advfirewall firewall add rule ... localport=9010 action=allow`), and modifying `run.py` to accept IP/port parameters. Additionally, communication data is not encrypted by default, so compression or encoding should be added for efficiency. The compiled single exe can be built with PyInstaller.
What is an alternative approach to implement screen control similar to Pupy, and what are its limitations?
An alternative is HTTP-Remote-Desktop-Server, which uses a Python-based Client (with PyGtk and pyautogui) to capture screenshots and execute commands, and a browser Server. Unlike Pupy, it requires manual refresh to update screen content (no streaming) and uses uncompressed PNG screenshots, making it less efficient but simpler for secondary development.
What UAC-related issue occurs when using Pupy's screen control, and how can it be mitigated?
When operating with standard user permissions, Pupy cannot interact with UAC pop-ups because the consent.exe process requires system privileges to close. To disable UAC prompts temporarily, you can use the registry command `reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v ConsentPromptBehaviorAdmin /t REG_DWORD /d 0 /f`, and re-enable with value 5.
How does Pupy's rdesktop module enable screen control on Windows?
Pupy's rdesktop module uses a three-part architecture: a Client that captures screen content and executes received mouse/keyboard messages, a Transfer that acts as a bridge using RSA+AES encryption (via websocket), and a Server that displays the screen in a browser and captures input. This allows remote viewing and control, as explained in the [Pupy Exploitation Analysis - Features on Windows Platform](/news/pupy-exploitation-analysis-features-on-windows-platform) article.
How does the ewsManage_Downloader organize downloaded emails and handle special characters in folder names?
When downloading emails, the tool uses the email username as the parent folder and creates different subfolders for each operation (e.g., search, download). To avoid errors from special characters like `>` that are invalid in folder names, the code removes such characters when creating subfolders. This ensures the file system can store the downloaded emails without issues.
Why is it necessary to redesign the code structure for the downloader compared to the original ewsManage.py?
Each SOAP XML message request requires full NTLM authentication, preventing the use of session mechanisms to simplify login. Additionally, the downloader must support multiple functions (keyword search, date range, attachment extraction) that were not in the original code. Redesigning reduces code redundancy and streamlines authentication handling for each request.
What is the correct syntax for filtering emails by date and size in EWS SOAP queries?
For date-based searches, the correct format is Year/Month/Day. For example, filtering emails sent between January 1, 2021 and December 30, 2021 uses `sent:>=2021/1/1 AND sent:<=2021/12/30`. For size-based filtering, use `size:<2000` but note that the less-than sign must be XML-escaped as `<`, so the actual query string becomes `size:<2000`. These syntax details are crucial when building SOAP XML messages manually.
How did the article fix the bug related to the Domain parameter for NTLM authentication?
The original ewsManage.py required specifying the Domain parameter (e.g., test.com\administrator required Domain=test.com). However, if the user was only an administrator without a domain prefix, the Domain parameter could not be set. The fix adds parameter validation: if Domain is NULL, the NTLM Type1 message is generated without the Domain parameter, allowing flexible login for both domain and non-domain users.
What is the main purpose of the ewsManage_Downloader tool described in this article?
The ewsManage_Downloader tool automates downloading emails and extracting attachments from Exchange servers using SOAP XML messages with NTLM authentication. It supports both plaintext and NTLM hash logins, keyword and date-based searches, and can specify download quantities. This is a practical extension of the concepts covered in our previous [Exchange Web Service (EWS) Development Guide](/news/exchange-web-service-ews-development-guide) and [Exchange Web Service (EWS) Development Guide 2 – SOAP XML Message](/news/exchange-web-service-ews-development-guide-2-soap-xml-message).
How does Glimpse prevent multiple instances of its agent from running simultaneously?
Glimpse creates a lock file at `%public%\Libraries\lock` containing the PID of the current PowerShell process. If the file exists, it checks the creation time; if older than 10 minutes, the process exits and deletes the lock file, ensuring only one active instance at a time, as described in the [Analysis of APT34 Leaked Tools - PoisonFrog and Glimpse](/news/analysis-of-apt34-leaked-tools-poisonfrog-and-glimpse) article.
What specific files does the PoisonFrog agent release in the %public%\Public folder, and what is the role of each?
The agent releases three files: `dUpdater.ps1` generates a system ID, reads proxy settings, and downloads files from the C2 server to execute commands or upload files; `hUpdater.ps1` creates folders for receive/send/done and receives commands via DNS A records; and `UpdateTask.vbs` loads both PowerShell scripts, as explained in the [Analysis of APT34 Leaked Tools - PoisonFrog and Glimpse](/news/analysis-of-apt34-leaked-tools-poisonfrog-and-glimpse) article.
Why do the analysts believe that the leaked PoisonFrog and Glimpse tools are unlikely to be widely misused?
The analysts note that both tools were already captured and thoroughly analyzed as early as 2017 by firms like FireEye and Palo Alto Networks. The techniques they employ, such as DNS protocol tunneling for data transmission, are considered outdated, reducing the risk of large-scale adoption, as discussed in the [Analysis of APT34 Leaked Tools - PoisonFrog and Glimpse](/news/analysis-of-apt34-leaked-tools-poisonfrog-and-glimpse) article.
What are the main differences in C2 communication between PoisonFrog and Glimpse?
PoisonFrog's agent uses HTTP to download commands and DNS A records for control, while Glimpse expands C2 channels by using both DNS A records and DNS TXT records for data exfiltration and command delivery. Additionally, Glimpse provides a C#-based graphical control panel, whereas PoisonFrog relies on a Node.js server, as outlined in the [Analysis of APT34 Leaked Tools - PoisonFrog and Glimpse](/news/analysis-of-apt34-leaked-tools-poisonfrog-and-glimpse) article.
How does PoisonFrog achieve persistence on the victim machine?
PoisonFrog creates two scheduled tasks named `\UpdateTasks\UpdateTask` and `\UpdateTasks\UpdateTaskHosts`, both running every 10 minutes. These tasks execute `UpdateTask.vbs`, which loads two PowerShell scripts (`dUpdater.ps1` and `hUpdater.ps1`) with current user and System permissions, as detailed in the [Analysis of APT34 Leaked Tools - PoisonFrog and Glimpse](/news/analysis-of-apt34-leaked-tools-poisonfrog-and-glimpse) article.
Does the MSDTC backdoor work on 64-bit systems with a 32-bit DLL?
No. On 64-bit systems, the MSDTC service launches the 64-bit version of `msdtc.exe` and therefore only loads 64-bit DLLs. The 32-bit `oci.dll` placed in `SysWOW64` will not be loaded. Attackers must use a 64-bit DLL for persistence on 64-bit systems.