Cybersecurity Q&A
Browse concise answers derived from our published, source-linked cybersecurity coverage.
What is CVE-2019-9621 and how does it affect Zimbra authentication?
CVE-2019-9621 is an SSRF vulnerability in Zimbra that allows an attacker to escalate a regular user token to an administrator token by abusing the `ProxyServlet.doProxy()` function. By sending a crafted request to `/service/proxy?target=https://127.0.0.1:7071/service/admin/soap`, the server proxies the request and returns an admin token. This technique is detailed in the [Zimbra SOAP API Development Guide](/news/zimbra-soap-api-development-guide).
How can you authenticate to the Zimbra SOAP API using a regular user account?
Regular user authentication is done via the `Auth` request under the `zimbraAccount` namespace, sent to the endpoint `uri + "/service/soap"`. You provide the username and password in a SOAP envelope; the response contains an `authToken` used for subsequent requests. Example code is available in the [Zimbra SOAP API Development Guide](/news/zimbra-soap-api-development-guide).
What are the main namespaces in the Zimbra SOAP API and their purposes?
The Zimbra SOAP API includes namespaces like `zimbraAccount`, `zimbraAdmin`, and `zimbraMail`. `zimbraAdmin` is used for mail server management (requires admin privileges), `zimbraAccount` handles user-related operations, and `zimbraMail` deals with mail-related tasks. For more details, refer to the [Zimbra SOAP API Development Guide](/news/zimbra-soap-api-development-guide).
What firewall rules must be enabled on a client for remote Group Policy update via `Invoke-GPUpdate`?
The client’s firewall must allow the following inbound connections: Remote Scheduled Tasks Management (RPC), Remote Scheduled Tasks Management (RPC-ERMAP), and Windows Management Instrumentation (WMI-IN). Without these rules, the `Invoke-GPUpdate -Computer` command will fail to force a remote policy refresh.
Where are scheduled task configurations stored within a GPO, and how often do clients refresh Group Policy?
The scheduled task XML definition is stored at `\\<domain>\SYSVOL\<domain>\Policies\{GPO-ID}\User\Preferences\ScheduledTasks\ScheduledTasks.xml`. By default, domain users refresh Group Policy every 90 minutes (with a random offset of 0‑30 minutes), while domain controllers refresh every 5 minutes. Clients can also be forced to refresh immediately with `gpupdate /force` or remotely via `Invoke-GPUpdate`.
What are the two main exploitation approaches for remote execution via GPO scheduled tasks?
If you have domain administrator privileges or edit permissions on a GPO, you can either (1) create a new GPO with a malicious scheduled task, or (2) modify an existing GPO that already contains scheduled tasks by replacing the `ScheduledTasks.xml` file. Both approaches require forcing a client policy refresh (e.g., `Invoke-GPUpdate`) and later cleaning up traces. The prerequisite is control over GPO editing, often achieved after domain compromise.
How can you create a GPO with a scheduled task using only PowerShell commands?
First, create the GPO with `New-GPO -Name TestGPO1`, then link it to the domain with `New-GPLink -Name TestGPO1 -Target 'dc=test,dc=com'`. To add a scheduled task, you must back up the GPO using `Backup-Gpo`, manually create the `ScheduledTasks.xml` file in the backup, modify `Backup.xml` and `gpreport.xml`, and finally restore the GPO with `Import-GPO`. An open‑source script, `New-GPOImmediateTask`, automates these steps. More detail is provided in the [companion command‑line article](/news/domain-penetration-remote-execution-via-scheduled-tasks-in-gpo-command-line-implementation-principles-and-script-details).
What is the advantage of using Group Policy Objects (GPO) to deploy scheduled tasks in a domain environment?
GPO-based scheduled tasks allow an administrator to centrally deploy and manage scheduled tasks across all computers or users in an Active Directory domain. By creating or modifying a GPO, you can define an immediate task that runs each time Group Policy refreshes, enabling remote execution without manual intervention on each target. For more details on the underlying technique, see the [Domain Penetration - Remote Execution via Scheduled Tasks in GPO](/news/domain-penetration-remote-execution-via-scheduled-tasks-in-gpo) article.
What steps should an attacker follow to verify and extract Firefox saved passwords?
First, determine the Firefox version from the registry to identify the correct record file (`logins.json` for ≥32.0, `signons.sqlite` for 3.5–32.0). Locate the file using `dir %APPDATA%\Mozilla\Firefox\Profiles\*logins.json /s /b` (or for signons.sqlite). Check if records exist. Then, if no Master Password is set, simply copy the record and key files and decrypt them with `firepwd.py`. If a Master Password is set, either use `firefox_decrypt.py` on a complete profile or load the profile into Firefox to enter the password. After extraction, the attacker may also need to cover their tracks, similar to [deletion and bypass of Windows logs](/news/penetration-techniques-deletion-and-bypass-of-windows-logs).
How can an attacker export Firefox passwords if a Master Password is set?
If a Master Password is set, the attacker must either use a tool that supports Master Password decryption—such as `firefox_decrypt.py` with the full profile folder—or import the record and key files into a local Firefox instance using the `-profile` parameter and then enter the Master Password manually. Note that `firepwd.py` has a known bug with `key4.db` Master Password decryption, making `firefox_decrypt.py` the more reliable choice for newer Firefox versions.
How can an attacker export Firefox passwords offline if no Master Password is set?
If no Master Password is configured, the attacker only needs to obtain the record file (`logins.json` or `signons.sqlite`) and the corresponding key file (`key4.db` or `key3.db`) from the user's Firefox profile directory. Tools like `firepwd.py` can then decrypt the `encryptedUsername` and `encryptedPassword` fields using the stored key and IV, revealing the plaintext credentials. This offline approach is similar to techniques used for [Chrome browser password export](/news/penetration-techniques-offline-export-of-passwords-saved-in-chrome-browser).
What tools can export saved Firefox passwords, and what are their limitations with Master Passwords?
Common tools include `WebBrowserPassView`, `firepwd.py`, `LaZagne`, and `firefox_decrypt.py`. `WebBrowserPassView` supports command-line export but cannot decrypt with a Master Password. `firepwd.py` can handle key3.db with a Master Password but has a bug with key4.db. `firefox_decrypt.py` uses Network Security Services (NSS) and supports both key3.db and key4.db Master Password decryption, though it requires matching Python and Firefox architectures. For a deeper dive into the NSS method, see [Exporting saved passwords from Firefox browser via Network Security Services](/news/exporting-saved-passwords-from-firefox-browser-via-network-security-services).
How does Firefox store saved passwords, and what files are involved?
Firefox saves login credentials in a record file (`logins.json` for version 32.0+, or `signons.sqlite` for older versions) located in the user's profile folder under `%APPDATA%\Mozilla\Firefox\Profiles\xxxxxxxx.default\`. The passwords are encrypted using 3DES-CBC, and the decryption keys are stored in a key file: `key4.db` (version ≥58.0.2) or `key3.db` (older versions). Understanding this structure is essential for offline password recovery, similar to the approach for [Chrome browser](/news/penetration-techniques-offline-export-of-passwords-saved-in-chrome-browser).
What are the key JAR files and configuration locations for Password Manager Pro vulnerability analysis?
The main web application logic resides in `AdventNetPassTrix.jar` under the `lib` directory (`C:\Program Files\ManageEngine\PMP\lib`). The wrapper configuration file for debugging is at `conf\wrapper.conf`, and database credentials are in `conf\database_params.conf`. The embedded PostgreSQL instance uses port 2345. These locations are essential for setting up a complete [vulnerability debugging environment](/news/password-manager-pro-vulnerability-debugging-environment-setup) and analyzing security flaws.
How do I connect to the PostgreSQL database used by Password Manager Pro?
Use the `psql` client bundled with Password Manager Pro. The connection string from `database_params.conf` uses `localhost` but fails due to SSL mismatch; replace `localhost` with `127.0.0.1`. Example command: `"C:\Program Files\ManageEngine\PMP\pgsql\bin\psql" "host=127.0.0.1 port=2345 dbname=PassTrix user=pmpuser password=Eq5XZiQpHv"`. For single commands, use the URI format: `psql --command="SELECT * FROM table;" postgresql://pmpuser:[email protected]:2345/PassTrix`, as shown in the [database connection section](/news/password-manager-pro-vulnerability-debugging-environment-setup).
How can I decrypt the Password Manager Pro database password?
The database password in `database_params.conf` is encrypted using a fixed key `@dv3n7n3tP@55Tri*` stored in `PMPDBPasswordGenerator.class`. The decryption algorithm is in `PMPEncryptDecryptImpl.class` inside `AdventNetPassTrix.jar`. You can write a decryption program based on that class; a reference implementation is available online (see the [article's section on password cracking](/news/password-manager-pro-vulnerability-debugging-environment-setup)). Decrypting the example password yields `Eq5XZiQpHv`.
How do I enable remote debugging (JPDA) for Password Manager Pro?
Remote debugging is configured by uncommenting the JPDA settings in the `wrapper.conf` file located at `C:\Program Files\ManageEngine\PMP\conf\wrapper.conf`. Remove the `#` from lines containing `-Xdebug`, `-Xnoagent`, and `-Xrunjdwp`, setting the address to `8787` (do not use `*:8787` to avoid hostname errors). Restart the service, and the Java process will listen for debugger connections, as detailed in the [debugging setup guide](/news/password-manager-pro-vulnerability-debugging-environment-setup).
How can I install Password Manager Pro for vulnerability research?
To set up a vulnerability debugging environment, first download the latest or an older version of Password Manager Pro from ManageEngine's official site ([Password Manager Pro Vulnerability Debugging Environment Setup](/news/password-manager-pro-vulnerability-debugging-environment-setup)). Older versions require a valid License; otherwise, they can only be launched once. Install on Windows 7 or above (Windows 7 not supported), then access the web interface at `https://localhost:7272` with default credentials `admin/admin`.
After uploading a file via clientUploader, where can it be accessed, and who can view it?
After a successful upload, the file is stored in the `downloads` directory and is accessible via the URL path `/downloads/<filename>`. However, only verified (authenticated) users can access these files, ensuring security. This mechanism is part of the file upload function detailed in [Zimbra SOAP API Development Guide 2](/news/zimbra-soap-api-development-guide-2). For pre-authentication methods, refer to [Zimbra SOAP API Development Guide 6 - Pre-authentication](/news/zimbra-soap-api-development-guide-6-pre-authentication1).
Where are Zimbra login logs stored, and what additional functionality does the open-source code from this guide include?
Zimbra login logs are stored at `/opt/zimbra/log/mailbox.log`. The open-source code from this guide (available on GitHub) adds two new features: obtaining tokens for mailbox users and file upload via clientUploader. It also includes support for the CVE-2019-9621 SSRF vulnerability, allowing access to management resources when the admin port (7071) is closed. For related features like email forwarding, see [Zimbra SOAP API Development Guide 5 - Email Forwarding](/news/zimbra-soap-api-development-guide-5-email-forwarding).