Cybersecurity Q&A
Browse concise answers derived from our published, source-linked cybersecurity coverage.
How did the author fix the bug where the DLL payload prevented normal program flow after execution?
The issue was that the intermediate payload altered the stack, causing the DLL not to return to the loader properly. The fix involved editing the DLL's binary with CFF Explorer: shifting the stack balance adjustment code backward, filling the gap with NOPs (0x90), and ensuring the payload maintains stack balance. This restored normal execution after the payload ran.
What technique is used to bypass Autoruns detection when hijacking system DLLs for Office applications?
The article shares specific DLL hijacking locations that only trigger when a particular Office feature is used—for example, LOCALSVC.DLL for Word's Review View or tiptsf.dll for Insert Picture. Because the payload executes only upon user interaction with that feature (not at startup), it evades Autoruns and similar startup detection tools.
How does implanting a backdoor into a DLL file differ from implanting one into an EXE file using The Backdoor Factory?
The main difference is that DLLs have export functions, which must be preserved for proper hijacking. The Backdoor Factory injects a payload into the DLL's code caves and modifies execution flow, similar to EXE files, but the payload must not break exported functions. If the payload disrupts stack balance, it can crash the DLL, as demonstrated in the article's debugging section. For more details on the EXE approach, see [Implanting backdoors into EXE files using BDF](/news/implanting-backdoors-into-exe-files-using-bdf).
What are the steps to add or remove the 'Password Never Expires' attribute programmatically?
To add it, modify the `userAccountControl` attribute of the target user by performing a bitwise OR with 65536 (e.g., `$newValue = $currentValue -bor 65536`). To remove it, use a bitwise XOR with 65536 (`$newValue = $currentValue -bxor 65536`). These operations must be applied via an LDAP write (e.g., using `DirectoryEntry` in C# or `Set-ADUser` in PowerShell). The article provides reusable C# code on GitHub for this purpose, ensuring accurate manipulation during penetration tests.
From a defensive perspective, why is it important to minimize users with 'Password Never Expires' and how can you monitor them?
Reducing the number of users with non-expiring passwords limits the attack surface for credential theft and persistence. Attackers often target such accounts because they remain valid indefinitely, making them ideal for lateral movement or [Domain Penetration - Using MachineAccount to Achieve DCSync](/news/domain-penetration-using-machineaccount-to-achieve-dcsync). Defenders should regularly enumerate users with this attribute using the same tools (PowerShell, PowerView) and set up monitoring alerts for any changes to `userAccountControl` values that add or remove the 65536 bit.
What external-domain methods can be used to enumerate users with 'Password Never Expires'?
From outside the domain, you can leverage the `ActiveDirectory` module by importing `Microsoft.ActiveDirectory.Management.dll` and specifying server credentials, e.g., `Search-ADAccount -Server 192.168.1.1 -Credential $cred -PasswordNeverExpires`. PowerView also works with `Get-NetUser -DomainController` and credentials. On Kali, you can use `ldapsearch` with a valid bind DN and password, then grep for `userAccountControl` and check the value manually. These enumeration techniques are commonly used in external recon phases of penetration testing, often coupled with [Penetration Basics - Choosing a Suitable C2 Domain](/news/penetration-basics-choosing-a-suitable-c2-domain) for post-exploitation.
How can I enumerate domain users with 'Password Never Expires' set from inside the domain using PowerShell or PowerView?
From inside the domain, you can use the `ActiveDirectory` module with commands like `Search-ADAccount -PasswordNeverExpires | FT Name`, or `Get-ADUser -filter * -properties Name, PasswordNeverExpires | where {$_.passwordNeverExpires -eq "true"}`. With PowerView, import the module and filter users via `Get-NetUser` and a bitwise AND check: `if(($User.useraccountcontrol -band 65536) -eq 65536)`. These methods are essential for identifying weak accounts during domain attacks, similar to techniques used in [Domain Penetration - AS-REPRoasting](/news/domain-penetration-as-reproasting).
What is the implementation principle behind the 'Password Never Expires' attribute for domain users?
The attribute is stored in the `userAccountControl` field of a domain user object, represented numerically. The specific value for 'Password Never Expires' is 65536 (DONT_EXPIRE_PASSWORD). To enable it, you perform a bitwise OR with 65536 on the current `userAccountControl` value; to remove it, you use a bitwise XOR. Checking for the attribute requires a bitwise AND with 65536. This principle is central to enumerating and manipulating the attribute in domain penetration testing, as detailed in [Penetration Basics - The Password Never Expires Attribute for Domain Users](/news/penetration-basics-the-password-never-expires-attribute-for-domain-users).
What are the two main approaches to obtain remote desktop connection passwords mentioned in the article?
The article describes two approaches: (1) Using a keylogger program to record the password as the user types it when mstsc.exe starts, and (2) reading the memory data of the mstsc.exe process to extract the password entered by the user. RdpThief implements the second approach, which is more stealthy and can capture credentials even if the user mistypes or enters them programmatically. For related techniques, see [extracting credentials from lsass.exe](/news/penetration-basics-remotely-extracting-credentials-from-the-lsass-exe-process) and [multi-user RDP](/news/penetration-techniques-multi-user-login-for-windows-remote-desktop).
What issue does RdpThief encounter on Windows 7 and what are the recommended solutions?
On Windows 7, RdpThief fails to capture the server name because the hooked API `SspiPrepareForCredRead` does not exist. One solution is to hook `CredReadW` instead, which does record the Server name. Alternatively, after a remote desktop connection is established, you can read the server name from the registry via the [remote desktop connection history](/news/penetration-techniques-obtaining-remote-desktop-connection-history-on-windows-systems). Both approaches restore full credential capture on Windows 7.
How does the Detours library assist in hooking system APIs for credential extraction?
The Detours library allows intercepting and redirecting Windows API calls, which RdpThief uses to replace original functions like `SspiPrepareForCredRead` or `CredReadW` with custom ones that capture the password and server name. The typical workflow involves `DetourTransactionBegin()`, `DetourAttach()` to attach the hook, and `DetourTransactionCommit()` to apply it. This method enables monitoring the data flow inside mstsc.exe without modifying the application itself.
What is RdpThief and how does it extract plaintext credentials from Remote Desktop Client?
RdpThief is a tool that extracts plaintext credentials entered into the Remote Desktop Connection client (mstsc.exe) by reading the process memory, rather than using a keylogger. It uses the Detours library to [hook system APIs](/news/penetration-techniques-extracting-plaintext-credentials-from-remote-desktop-client) and API Monitor to locate where mstsc.exe stores the username and password. Once injected into the mstsc.exe process, it captures credentials and writes them to a file (e.g., %temp%\data.bin). The tool is especially useful in penetration testing after discovering remote desktop connection history.
How do I send an email with an attachment using the Zimbra SOAP API?
First upload the attachment to obtain an `aid`. Then call the `SendMsg` command with the `attach` parameter referencing that `aid`. The request must include the sender (`<e>`), recipient, subject (`<su>`), and body (`<mp>`). Set `noSave` to 1 to avoid saving a copy in sent items. This process is explained in the [Zimbra SOAP API Development Guide 3 - Email Operations](/news/zimbra-soap-api-development-guide-3-email-operations), which extends the base API usage from the [Zimbra SOAP API Development Guide](/news/zimbra-soap-api-development-guide).
What is the correct way to upload an attachment before sending an email via the Zimbra SOAP API?
Upload the attachment using `FileUploadServlet` at `https://<server>/service/upload?fmt=raw,extended`. Include the file in a POST request with a `Cookie` header containing the auth token. The response returns an `aid` (server attachment ID) and file type. This attachment ID is then used in the `SendMsg` command. For full details, refer to the [Zimbra SOAP API Development Guide 3 - Email Operations](/news/zimbra-soap-api-development-guide-3-email-operations) and the related [Zimbra SOAP API Development Guide 5 - Email Forwarding](/news/zimbra-soap-api-development-guide-5-email-forwarding) for advanced email operations.
Can I view the full content of an email, including attachments, without using a SOAP API call?
Yes. After obtaining the Item ID, you can retrieve the complete email content by accessing a fixed URL: `https://<server>/service/home/~/?auth=co&view=text&id=<ItemID>`. The response includes the email body and any Base64-encoded attachments. This method is detailed in the [Zimbra SOAP API Development Guide 3 - Email Operations](/news/zimbra-soap-api-development-guide-3-email-operations) and is useful for export tasks described in [Zimbra SOAP API Development Guide 4 - Email Export and Folder Sharing](/news/zimbra-soap-api-development-guide-4-email-export-and-folder-sharing).
How do I retrieve the Item ID of an email in the Zimbra SOAP API for further operations like viewing or deleting?
To get the Item ID, you need to invoke the `Search` command with a query like `in:inbox`. The response contains `<m>` tags with attributes such as `id` (the Item ID), `a` (sender), `su` (subject), and `sf` (timestamp). This approach is covered in the [Zimbra SOAP API Development Guide 3 - Email Operations](/news/zimbra-soap-api-development-guide-3-email-operations) and builds on the foundation of the [Zimbra SOAP API Development Guide](/news/zimbra-soap-api-development-guide).
Why might a PNG file size change after LSB steganography, and how can you avoid that?
Some implementations, like Grant Curell's C++ code, may add extra tEXt chunks or retain original metadata, increasing file size. To avoid this, you can use a tool like `compress.cpp` from the [modified PNG_stego project](/news/steganography-techniques-lsb-steganography-in-png-files) to remove redundant chunks, restoring the original size. Pure LSB steganography on the IDAT chunk itself does not inherently change the file size when properly implemented.
What tool can visually analyze LSB steganography in PNG images, and how does it reveal hidden data?
Stegsolve is a Java-based tool for steganalysis. After opening an encrypted image, you can go to Analyse → Data Extract, select the 0th bit of each RGB plane in Bit Planes, and choose LSB First with RGB order. This reveals the encrypted payload's bits visually. Stegsolve also allows XOR comparison between two images to highlight subtle differences caused by LSB embedding.
How can you decrypt or extract hidden data from a PNG file that uses LSB steganography with a password?
To decrypt, use a tool like [cloacked-pixel](https://github.com/cyberinc/cloacked-pixel) with the command `python lsb.py extract big.png-stego.png output.txt password`. This reverses the embedding process by reading the least significant bits of the pixel data, applying the password-based decryption, and writing the hidden payload to a file. The same password used during encryption is required.
What is the role of the IDAT data chunk in PNG LSB steganography, and how is it compressed?
The IDAT data chunk stores the actual pixel data of the PNG image. It uses a compression algorithm based on LZ77 (deflate), and the compressed data can be decompressed using zlib. In LSB steganography, the payload is hidden by altering the least significant bits of the decompressed pixel data before re-compressing it into the IDAT chunk. Tools like [cloacked-pixel](https://github.com/cyberinc/cloacked-pixel) replace all other chunks with only the essential IDAT chunk.