Cybersecurity Q&A
Browse concise answers derived from our published, source-linked cybersecurity coverage.
How are user passwords stored in Server Backup Manager, and where can I extract the user database file?
Passwords are hashed using SHA-1 and then Base64‑encoded, as seen in the `PasswordEncoder.class` located in `/usr/sbin/r1soft/lib/cdpserver.jar`. The user database is stored in an HSQLDB file at `/usr/sbin/r1soft/database/r1softDB.script`, which contains user entries in plain text (with the encoded password). This database path is derived from the `server.conf` configuration file. More details are in the [Server Backup Manager Vulnerability Debugging Environment Setup](/news/server-backup-manager-vulnerability-debugging-environment-setup) article.
How do I set up remote debugging for Server Backup Manager by adding JVM debug parameters?
Add the line `additional.19=-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=8000` to the configuration file `/usr/sbin/r1soft/conf/server.conf`. For JDK 5-8 use `address=8000`; avoid the `address=*:8000` syntax meant for JDK 9+. Then restart the service with `/etc/init.d/cdp-server restart` and attach your IDE to port 8000. The full setup is covered in the [Server Backup Manager Vulnerability Debugging Environment Setup](/news/server-backup-manager-vulnerability-debugging-environment-setup).
How do I install an older version of Server Backup Manager for vulnerability testing, and what initial configuration is needed?
To install an older version, download the package from http://r1soft.mirror.iweb.ca/repo.r1soft.com/release/6.2.2/78/trials/R1soft-ServerBackup-Manager-SE-linux64-6-2-2.zip, extract it, and install the `.deb` files with `dpkg -i *.deb`. Then configure the admin user and ports using `serverbackup-setup --user admin --pass 123456` and `serverbackup-setup --http-port 8080 --https-port 8443`, finally start the service with `/etc/init.d/cdp-server restart`. For detailed steps, see the [Server Backup Manager Vulnerability Debugging Environment Setup](/news/server-backup-manager-vulnerability-debugging-environment-setup) article.
How can you parse the keystroke logs generated by the HP keylogger?
The log file records virtual key codes in Unicode text. A PowerShell script can parse these codes and convert them to human-readable characters. A functional example iterates through each line, extracts the virtual key value using regex (`vk (0x[A-Fa-f0-9]+)$`), and maps it to a character. Non-printable keys are replaced with a dot. A corrected version of the script is provided in the [Analysis of CVE-2017-8360 (Keylogger in HP Audio Driver) Exploitation](/news/analysis-of-cve-2017-8360-keylogger-in-hp-audio-driver-exploitation) to handle encoding issues.
Can an attacker modify the keylogger's behavior through registry exploitation?
Yes, an attacker can redirect the log file location by setting `HKCU\SOFTWARE\Conexant\MicTray64.exe\LogName` to a custom path, such as `C:\test\log.txt`. This allows the keylogger to write keystrokes to an attacker-controlled file. Because MicTray.exe is signed, the legitimate executable can be repurposed for malicious keylogging without raising suspicion. This exploitation approach is detailed in the [Analysis of CVE-2017-8360 (Keylogger in HP Audio Driver) Exploitation](/news/analysis-of-cve-2017-8360-keylogger-in-hp-audio-driver-exploitation).
How does the HP audio driver keylogger record keystrokes?
The keylogger uses two methods: it writes keystrokes to a log file at `C:\Users\Public\MicTray.log`, and it outputs keystroke data via the Windows API `OutputDebugString()`, which can be read by tools like DbgView. Both methods require specific registry keys to be set; the OutputDebugString method activates only when the `HKCU\SOFTWARE\Conexant` key is absent and other HKLM keys are configured. Details on triggering these methods are covered in the [Analysis of CVE-2017-8360 (Keylogger in HP Audio Driver) Exploitation](/news/analysis-of-cve-2017-8360-keylogger-in-hp-audio-driver-exploitation).
What is CVE-2017-8360 and why is it significant?
CVE-2017-8360 is a vulnerability in HP's Conexant audio driver that embeds a keylogger via the executables MicTray.exe (32-bit) and MicTray64.exe (64-bit). Discovered by Modzero in May 2017, it records all keystrokes by default, posing a severe privacy risk. The keylogger is particularly dangerous because it runs with a legitimate digital signature, making it hard to detect. For a full technical breakdown, see the [Analysis of CVE-2017-8360 (Keylogger in HP Audio Driver) Exploitation](/news/analysis-of-cve-2017-8360-keylogger-in-hp-audio-driver-exploitation).
How can special Alternative Data Streams (ADS) bypass conventional detection tools like ADSCheck.exe and streams.exe?
Special ADS created with unusual filenames such as `...` (three dots), COM device names (e.g., `COM1`), or the disk root (`C:\`) are not listed by `dir /r` or detected by tools like ADSCheck.exe and streams.exe. For example, using `type putty.exe > ...:putty.exe` hides the ADS entirely from these scanners. These special names exploit Windows naming conventions to evade discovery, as detailed in the [article](/news/advanced-exploitation-techniques-for-hidden-alternative-data-streams).
What is an Alternative Data Stream (ADS) and how can it be exploited for stealthy payload execution?
An Alternative Data Stream (ADS) is a feature of the NTFS file system that allows hiding data within a file without affecting its visible size. Attackers can hide a payload like `putty.exe` inside a file using `type putty.exe > test.txt:putty.exe` and then execute it via [WMI](/news/advanced-exploitation-techniques-for-hidden-alternative-data-streams) (`wmic process call create c:\test\test.txt:putty.exe`) or PowerShell. This technique makes detection difficult because the payload doesn't alter the host file's properties.
What defenses exist against the tracker.exe DLL loading technique?
The most straightforward defense is to add tracker.exe to your application whitelisting blacklist. Since it is a Microsoft-signed binary, many whitelisting solutions allow it by default; explicitly blocking it prevents its abuse for DLL injection. Similar blacklisting can be applied to other signed binaries used in bypass techniques, as highlighted in the article.
How can I execute C# code during XSLT transformation and use it for shellcode execution?
XSLT files can contain embedded C# code inside `<msxsl:script>` blocks, which executes during XML transformation by .NET's XslCompiledTransform. This allows arbitrary code execution, including shellcode when combined with techniques like [using VirtualAlloc to bypass DEP](/news/windows-shellcode-study-notes-bypassing-dep-with-virtualalloc). The article's POC demonstrates launching calc.exe via an XSLT file. For more, refer to [Study Notes Weekly No.4](/news/study-notes-weekly-no-4-use-tracker-to-load-dll-use-csi-to-bypass-umci-execute-c-from-xslt-file).
How can I use csi.exe to execute arbitrary .NET code and bypass Windows Device Guard or UMCI?
csi.exe is a C# interactive compiler introduced in Visual Studio 2015 Update 1, and it is digitally signed by Microsoft. You can run C# code directly in its REPL, load `.csx` scripts with `#load`, or execute a script from the command line. This technique bypasses Device Guard and UMCI because csi.exe is a trusted binary. On Windows 10, you can even copy csi.exe and its dependencies (like Microsoft.CodeAnalysis.CSharp.dll) to a system without VS2015. This is similar to other application whitelisting bypass methods such as [using BGInfo](/news/study-notes-of-using-bginfo-to-bypass-application-whitelisting).
How can I use tracker.exe to load a DLL and bypass application whitelisting?
tracker.exe, a Microsoft-signed binary from the Windows SDK, can load a DLL into any process you start using the `/d` option. For example, `Tracker.exe /d test.dll /c cmd.exe` injects test.dll into cmd.exe. Because tracker.exe is digitally signed, it can bypass application whitelisting controls. However, if the target process exits quickly, as with svchost.exe, the DLL still gets loaded. See the full details in [Study Notes Weekly No.4](/news/study-notes-weekly-no-4-use-tracker-to-load-dll-use-csi-to-bypass-umci-execute-c-from-xslt-file).
How does the SubAuth feature of mimilib work and what information does it log?
The SubAuth feature uses the `Msv1_0SubAuthenticationRoutine` and `Msv1_0SubAuthenticationFilter` exports. Deploy mimilib.dll to `%SystemRoot%\System32` and add a registry value `Auth0` (type REG_SZ) under `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0` (or `\Kerberos` for domain controllers). After restart, lsass.exe loads the DLL and logs login events to `kiwisub.log`, recording UserId, PrimaryGroupId, LogonDomainName, UserName, Workstation, BadPasswordCount, and hash. This can be extended to log timestamps by modifying the source code from the [mimilib GitHub repository](https://github.com/gentilkiwi/mimikatz/blob/master/mimilib/ksub.c).
What does the DnsPlugin feature of mimilib do and how is it deployed?
The DnsPlugin feature, exporting `DnsPluginInitialize`, `DnsPluginCleanup`, and `DnsPluginQuery`, logs DNS queries on a DNS server. Deploy mimilib.dll to `%SystemRoot%\System32` on the DNS server, add a registry key `ServerLevelPluginDll` under `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\DNS\Parameters` with value `mimilib.dll`, then restart. The DNS service (dns.exe) loads the DLL and writes query names and types to `kiwidns.log`. Remote deployment via dnscmd is discussed in [Domain Penetration—Using dnscmd to Achieve Remote DLL Loading on DNS Servers](/news/domain-penetration-dns-records-and-machineaccount).
How can mimilib.dll be used to capture password changes via the PasswordChangeNotify feature?
The PasswordChangeNotify feature uses `InitializeChangeNotify` and `PasswordChangeNotify` exports. Deploy mimilib.dll to `%SystemRoot%\System32`, add `mimilib` to the `Notification Packages` registry value under `HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa`, and restart. Whenever a user changes their password, lsass.exe writes the new plaintext password to `kiwifilter.log`. This technique is also covered in [Domain Penetration - Hook PasswordChangeNotify](/news/domain-penetration-dns-records-and-machineaccount).
What is mimilib.dll and how is it used for credential theft via the Security Support Provider (SSP) feature?
Mimilib.dll is a subproject of [mimikatz](/news/mimilib-usage-analysis) that, when loaded into lsass.exe, can capture plaintext passwords. The SSP feature uses the `SpLsaModeInitialize` export function. To deploy it, save the DLL to `%SystemRoot%\System32`, add `mimilib` to the `Security Packages` registry value under `HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa`, and restart the system. This causes lsass.exe to load the DLL and write captured passwords to `kiwissp.log`.
What are the two file-writing methods in ProxyShell, and how do they compare in terms of stealth and cleanup?
The two methods are: (1) `New-MailboxExportRequest`, which exports an email containing the payload to a specified file path, but requires adding the user to the `Mailbox Import Export` role and leaves export requests that can be cleared with `-CompletedRequestAgeLimit 0`. (2) `New-ExchangeCertificate`, which writes the payload into a certificate subject, is quicker but has syntax restrictions on special characters. Both require careful cleanup—removing export requests or certificates—to avoid detection. For more on the broader exploitation flow, see the [ProxyShell Exploitation Analysis 2](/news/proxyshell-exploitation-analysis-2-cve-2021-34523).
How does the `New-ExchangeCertificate` method allow file writing in ProxyShell, and how do you avoid special character issues?
`New-ExchangeCertificate` creates self-signed certificates, and the payload can be passed via the `SubjectName` parameter. The subject must follow a fixed format like `CN=Payload` and cannot contain the special characters `,`, `+`, or `;`. To bypass this, you can Base64-encode the payload (e.g., a JScript payload) to avoid these characters. A successful write returns `Microsoft.Exchange.Data.BinaryFileDataObject`. You can delete malicious certificates afterwards using `Remove-ExchangeCertificate` with the thumbprint or a subject filter.
What are the prerequisites for writing files via the `New-MailboxExportRequest` method in ProxyShell?
Before using `New-MailboxExportRequest` to write files, you must add the target user to the role group `Mailbox Import Export` using `New-ManagementRoleAssignment`. The payload must be delivered via email—either from an external mailbox or by exploiting CVE-2021-34473 to impersonate a mailbox user, optionally creating a hidden folder for stealth. The export command then uses a `-ContentFilter` to extract only emails containing the payload, writing the file to a path like `\127.0.0.1\c$\inetpub\wwwroot\aspnet_client\test.aspx`. After writing, clear export requests to avoid leaving traces.