Cybersecurity Q&A
Browse concise answers derived from our published, source-linked cybersecurity coverage.
What is the Last WebAdmin Sessions feature in Sophos UTM and how is it accessed?
Last WebAdmin Sessions is a log feature accessible via the web management page under Management. It records each user login with details like username, login time, logout time, IP address, and configuration changes. By default, it shows the most recent 20 records. Understanding this feature is crucial for forensic analysis, similar to how administrators might [clear single records in RecentFileCache.bcf and Amcache.hve](/news/penetration-techniques-clearing-single-records-in-recentfilecache-bcf-and-amcache-hve) on Windows systems.
How can attackers bypass signature verification without leaving a custom DLL on the system?
Attackers can reuse an existing system DLL that exports a function returning `TRUE`. For example, `ntdll.dll` exports `DbgUiContinue`, which always returns `TRUE`. By setting the registry key's `Dll` value to `C:\Windows\System32\ntdll.dll` and `FuncName` to `DbgUiContinue`, the verification process is hijacked without deploying any new files. This technique is highlighted in the [article](/news/authenticode-signature-forgery-pe-file-signature-forgery-and-signature-verification-hijacking) and reduces forensic artifacts.
What is the role of SIP (Subject Interface Package) in signature verification, and why is it a target?
SIP (Subject Interface Package) provides a pluggable architecture for Authenticode signature verification, with different GUIDs for PE files, catalog files, etc. The `CryptSIPDllVerifyIndirectData` registry key points to the DLL and function that performs actual verification. By changing this key to a custom DLL that always returns `TRUE`, attackers can completely bypass signature checking for PE files, making any forged signature appear valid. This is explained in the [CAT File Digital Signature Usage Techniques](/news/cat-file-digital-signature-usage-techniques) article as a related concept for catalog signatures.
How does the signature verification hijacking technique work?
Signature verification hijacking modifies the registry key `HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CryptSIPDllVerifyIndirectData\{C689AAB8-8E78-11D0-8C47-00C04FC295EE}` (for PE files) to replace the default DLL and function name with a custom DLL that always returns `TRUE`. This causes `Get-AuthenticodeSignature`, `signtool`, and `sigcheck` to report any forged signature as valid, as demonstrated in the [article](/news/authenticode-signature-forgery-pe-file-signature-forgery-and-signature-verification-hijacking). The technique leverages the Subject Interface Package (SIP) architecture for verification.
What is Authenticode signature forgery and how is it performed?
Authenticode signature forgery involves copying a valid digital signature from a trusted Microsoft-signed PE file (e.g., `consent.exe`) and appending it to a different executable. Tools like SigThief automate this by extracting the signature's Security Directory RVA and Size and patching them into the target file, as detailed in [Authenticode Signature Forgery - PE File Signature Forgery and Signature Verification Hijacking](/news/authenticode-signature-forgery-pe-file-signature-forgery-and-signature-verification-hijacking). However, this technique alone results in a 'HashMismatch' error because the file's hash no longer matches the embedded signature.
Why can't I query PostgreSQL database tables in Sophos XG, and how do I resolve it?
PostgreSQL runs with low-privilege user permissions, preventing direct table queries. To gain full access, you need to escalate privileges by modifying the database connection settings or using the existing credentials found in the decrypted cscconf.bin configuration file. Once you have the database password, you can connect as a superuser and execute queries. This is a common challenge in firewall appliance debugging; similar issues arise in [Setting up GoAnywhere Managed File Transfer Vulnerability Debugging Environment](/news/setting-up-goanywhere-managed-file-transfer-vulnerability-debugging-environment).
What is the csc configuration file and how can I decrypt it for reverse engineering?
The csc (core service controller) process reads an encrypted configuration file at /_conf/cscconf.bin. To decrypt it, you can use IDA to modify the csc binary's logic so that it outputs the decrypted data before loading the Perl packages. This approach is necessary because the original file is encrypted and the normal process deletes itself after loading, preventing direct inspection. For similar setups, see [Server Backup Manager Vulnerability Debugging Environment Setup](/news/server-backup-manager-vulnerability-debugging-environment-setup) or [VMware Workspace ONE Access Vulnerability Debugging Environment Setup](/news/vmware-workspace-one-access-vulnerability-debugging-environment-setup).
How can I enable remote debugging for the Jetty web server in Sophos XG?
To enable Jetty remote debugging, first locate the startup script at /usr/bin/jetty and remount the filesystem with `mount -o rw,remount /`. Add the JVM debugging parameter `-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:8000` to the exec line. Since the built-in OpenJDK lacks the debug library, replace it with a complete JDK (e.g., jdk-11.0.15) by backing up /lib/jvm/java-11-openjdk and extracting the new JDK there. Restart the service with `service tomcat:restart -ds nosync` and ensure the firewall allows port 8000 using `iptables -I INPUT -p tcp --dport 8000 -j ACCEPT`. You can then attach a remote debugger in an IDE like IntelliJ IDEA.
How do I set up a Sophos XG virtual appliance for vulnerability debugging in VMware Workstation?
To set up a Sophos XG virtual appliance, download the installation package from the official site (older versions can be obtained by guessing version numbers, e.g., [Sophos XG Vulnerability Debugging Environment Setup](/news/sophos-xg-vulnerability-debugging-environment-setup) mentions VI-18.5.3_MR-3.VMW-408.zip). Import the OVF file into VMware Workstation, then configure two virtual networks: VMnet7 as Host-only with subnet 172.16.16.0 and VMnet8 as NAT. Assign the VM's network adapters: first to VMnet7, second and third to VMnet8. After booting, use the console to get the LAN IP (e.g., 172.16.16.16) and access the web interface at https://172.16.16.16:4444 to activate with a trial license.
How can defenders detect and prevent an attacker from maintaining persistent access to user email boxes?
Defenders should regularly audit inbox rules (Get-InboxRule) and folder permissions (Get-MailboxFolderPermission) for each mailbox. After a password change, administrators should also reset any forwarding rules or delegate permissions that may have been set by the attacker. Additionally, monitoring for unusual SOAP/EWS activity, such as excessive UpdateInboxRules or AddDelegate calls, can indicate compromise. The article emphasizes that changing the password alone does not revoke previously granted permissions or rules. For comprehensive defense strategies, refer to the full [Penetration Basics - Methods to Continuously Obtain Exchange User Inbox Emails](/news/penetration-basics-methods-to-continuously-obtain-exchange-user-inbox-emails) article.
What is the difference between adding a forwarding rule via ECP and setting up mail forwarding via EAC for persistent email access?
Adding a forwarding rule via ECP (Inbox Rules) is user-level and can be done with just the user's password and access to the Exchange Control Panel. Setting up mail forwarding via Exchange Admin Center (EAC) requires Exchange administrator privileges. Both forward emails to another account, and unlike permissions-based access, the forwarding operation ensures the attacker still receives copies even if the original user deletes the email. The forwarding can also be configured to deliver both to the forwarding address and the mailbox. This distinction is vital for understanding attack vectors in [Penetration Basics - Obtaining Domain User Password Policies](/news/penetration-basics-obtaining-domain-user-password-policies).
How can an Exchange administrator use PowerShell to add persistent email access to a user's mailbox?
An administrator can run PowerShell commands on the Exchange server using the `Microsoft.Exchange.Management.PowerShell.SnapIn` snap-in. To grant user test2 full access (Owner) to test1's inbox, they execute `Add-MailboxFolderPermission -Identity [email protected]:\Inbox -User [email protected] -AccessRights Owner`. This gives test2 persistent access. To view current permissions, use `Get-MailboxFolderPermission`, and to remove, use `Remove-MailboxFolderPermission`. For more on Exchange management, see [Penetration Techniques - From Exchange File Read/Write Permissions to Command Execution](/news/penetration-techniques-from-exchange-file-read-write-permissions-to-command-execution).
What is a less detectable method to continuously read a target user's Exchange emails without modifying their mailbox rules?
Instead of forwarding rules, an attacker can add themselves (user test2) as a delegate with folder permissions on test1's inbox. This can be done via Outlook Web App (OWA) by setting "Editor" permissions, or programmatically using **AddDelegate** or **UpdateFolder** SOAP requests. User test2 can then access test1's inbox as a shared folder. However, note that if test1 deletes an email, test2 loses access to that message. This approach is covered in the article alongside the [Penetration Basics - Implementation of Exchange One-Liner Backdoor](/news/penetration-basics-implementation-of-exchange-one-liner-backdoor).
How can an attacker persistently access an Exchange user's emails after obtaining their password, even if the password is later changed?
After gaining a user's password (e.g., user test1), an attacker can add a forwarding rule via the Exchange Control Panel (ECP) or via SOAP XML messages. For example, using the **UpdateInboxRules** operation, they can create a rule that forwards all incoming emails to a controlled account. This persistence method remains active even after test1 changes their password, as the rule is tied to the mailbox, not the password. For more details, refer to the original article on [Penetration Basics - Methods to Continuously Obtain Exchange User Inbox Emails](/news/penetration-basics-methods-to-continuously-obtain-exchange-user-inbox-emails).
How does the WLL persistence technique compare to other Office persistence methods like COM hijacking?
The WLL method is simple and reliable: it relies on Word's Startup folder, which is a standard mechanism. In contrast, [COM Object hijacking to maintain persistence——Hijack Outlook](/news/use-com-object-hijacking-to-maintain-persistence-hijack-outlook) exploits COM registration, which can be more stealthy but also more complex. The article notes that WLL supports multiple files and is relatively easy to detect via folder monitoring, whereas COM hijacking may evade simple file scans.
What considerations should be taken when creating a WLL backdoor DLL to avoid crashes?
The DLL must be carefully written to avoid crashing Word. For example, using `MessageBox` in `DLL_PROCESS_ATTACH` caused Word to freeze. The article recommends using `WinExec` or similar lightweight calls. Also, compile with optimization flags (e.g., release mode, `/OPT:nowin98`) to keep the DLL small (3KB). DLLs generated by Metasploit's msfvenom often cause Word to crash, so custom C code is preferred.
How can an attacker automate the deployment of a WLL backdoor using PowerShell?
The article provides a PowerShell script that base64-encodes a compiled 3KB DLL (e.g., calc.dll) and stores it in a variable. The script then decodes and writes the DLL as a `.wll` file to the Word Startup folder. This automation allows the attacker to deploy the backdoor without manual file placement, making it efficient for mass exploitation.
What is a WLL file and how can it be used for persistence in Microsoft Word?
A WLL file is simply a renamed DLL that is placed in the Word Startup folder (`%APPDATA%\Microsoft\Word\Startup`). When Word launches, it automatically loads any WLL files in that folder, executing their code. An attacker can create a DLL that runs a payload (e.g., calc.exe or a reverse shell) in its `DLL_PROCESS_ATTACH` handler, achieving persistence every time Word starts. For more details, see [Use Office to maintain persistence](/news/use-office-to-maintain-persistence).
How does the NTLM Challenge fit into Pass the Hash attacks against Exchange?
In NTLM authentication, the server sends a random Challenge (16-byte nonce) to the client. During a Pass the Hash attack, the attacker uses the stolen NTLM hash to encrypt this Challenge, producing the correct response. The server then verifies the response, granting access if it matches. This is identical to the normal process but uses the hash directly instead of deriving it from a password. The article details the full exchange in the [Penetration Techniques - Pass the Hash with Exchange Web Service](/news/penetration-techniques-pass-the-hash-with-exchange-web-service) article.
What are the advantages of the open-source Python implementation for Pass the Hash with EWS over the Mimikatz method?
The Python implementation using Impacket does not require administrator privileges or operations on the lsass process, allowing authentication for multiple users simultaneously. It directly passes the NTLM hash to generate the response to the server's Challenge, enabling EWS login without elevated privileges. The code is available on GitHub, as referenced in the [Penetration Techniques - Pass the Hash with Exchange Web Service](/news/penetration-techniques-pass-the-hash-with-exchange-web-service) article.