Arc Browser UXSS, Local File Read, Arbitrary File Creation and Path Traversal to RCE
Arc Browser UXSS, Local File Read, Arbitrary File Creation and Path Traversal to RCE After announcing the bug bounty program I downloaded the browser and started looking for vulnerabilities, using my …
You Already Have Our Personal Data, Take Our Phone Calls Too (FreePBX CVE-2025-57819)
We’re back - it’s a day, in a month, in a year - and once again, something has happened.
In this week’s episode of “the Internet is made of string and there is literally no evidence to suggest otherwise”, we present even further evidence that as a species we made a fairly painful mistake when we discovered electricity - and it just got worse and worse.
Today, inside this hellscape we call the Internet, a mean person has discovered a zero-day(s) in FreePBX (now lovingly called CVE-2025-57819).
⌚All Xiaomi watches hacked (Cross Tenant IDOR) The IoT is part of everyone’s daily life! So why not explore it? 🤨 So there I was, late at night, wearing my Xiaomi smartwatch and thinking about …
Out-of-bound read in ANGLE CopyNativeVertexData from Compromised Renderer
Introduction Back in the beginning of the year 2024, we started our project on ANGLE, it is a chromium graphic library, handling rendering stuff on chrome process. Fortunately, our team found some of the vulnerabilities in different areas (suto has shared some information on his tweet previously). In this blog post, we will explain how a libANGLE integer underflow bug can be turned into a powerful primitive that allows us to read the Chrome WebGPU process.
Total Identity Compromise: Microsoft Incident Response lessons on securing Active Directory
Total Identity Compromise: Microsoft Incident Response lessons on securing Active Directory
When Microsoft Incident Response (formerly DART/CRSP) is engaged during an incident, almost all environments include an on-premises Active Directory component. In most of these engagements, threat actors have taken full control of Active Directory –i.e., total domain compromise.
Total domain compromise often starts with the compromise of a regular non-privileged user rather than a domain admin. Threat actors can use that account to discover misconfiguration and attack paths in Active Directory that lead to full domain control. Oftentimes, threat actors leverage freely available tools such as AdFind, AD Explorer, or BloodHound to find attack paths through Active Directory environments. After total domain compromise, restoring trust back into Active Directory can take significant time and investment.
To aid in our investigations, Microsoft Incident Response leverages a custom-built Active Directory enumeration tool to retrieve metadata about users, groups, permissions, group policies and more. Microsoft Incident Response uses this data to not only aid in the investigation, but also to shape attacker eviction and compromise recovery plans and to provide best practice recommendations on taking back and maintaining positive identity control. In addition to the Microsoft Incident Response custom tool, there are other tools, such as Defender for Identity, and open-source tools such as BloodHound and PingCastle, that you can use to secure Active Directory in your own environment.
Across all industry verticals, Microsoft Incident Response often finds similar issues within Active Directory environments. In this blog, we will be highlighting some of the most common issues seen in on-premises Active Directory environments and provide guidance on how to secure those weaknesses. These include:
Initial Access – Weak password policies, excessive privilege and poor credential hygiene, insecure account configuration
Credential Access – Privileged credential exposure, Kerberoasting, insecure delegation configuration, Local Administrator Password Solution (LAPS) misconfiguration, excessive privilege via built-in groups
Privilege Escalation – Access control list (ACL) abuse, escalation via Exchange permissions, Group Policy abuse, insecure trust configuration, compromise of other Tier 0 assets
Initial Access
Weak Password Policies
It is not uncommon for Microsoft Incident Response to engage with customers where accounts have weak or easy to guess credentials, including those of privileged users such as Domain Admins. Simple password spray attacks can lead to the compromise of such accounts. If these standard user accounts are provided VPN or remote access without multi-factor authentication, the risk is increased: threat actors can connect to the VPN via devices in their control and begin reconnaissance of the environment remotely. From here, a threat actor can then attempt to escalate to Domain Admin privileges via weaknesses in Active Directory.
Recommendation
Where possible, Microsoft Incident Response recommends deploying passwordless authentication technology, such as Windows Hello for Business (which uses biometrics such as facial recognition or fingerprints) or FIDO2 security keys. Fully deploying passwordless authentication allows you to disallow password authentication, which eliminates password-based attack vectors (such as password sprays and phishing) for those users. If you are not yet ready to begin deploying passwordless solutions, you can increase the strength of your on-premises password policy through group policy and fine-grained password policies. Current guidance recommends longer (14 or more characters) but less complex passwords (no special characters or similar required), with users having to change them much less frequently. This discourages users from cycling through easy-to-guess passwords to satisfy complexity and rotation requirements, such as changing their password from ‘Monday10’ to ‘Monday11’.
If you are licensed for Azure Active Directory P1 or higher, you can also deploy Azure Active Directory Password Protection, which can disallow your users from using easy to guess passwords even in on-premises Active Directory. You can also ban custom words unique to your business, such as the name of your company or the city in which you operate.
For both passwordless and stronger password policies, if you work in a complex environment where the rollout of those solutions may take some time, start by targeting your Domain Admins and other privileged users. Your Tier 0 accounts can, and should, be held to a higher security standard.
Excessive Privilege and Poor Credential Hygiene
One of the most common issues found in Active Directory is accounts, particularly service accounts, being assigned too much privilege. In Microsoft Incident Response engagements, it is not uncommon to find multiple service accounts and named user accounts to be granted Domain Admin privileges. Additionally, service accounts used for applications or scripts are often granted local administrative access over all workstations and servers. Though this is an easy way to allow a product or script to function, these accounts then become a weak point in your security.
Service accounts are attractive targets because the passwords are rarely rotated. Security controls for them are often weaker, and they can’t be protected by MFA. Furthermore, the passwords for these accounts are often stored in clear text, whether that be sent in email, saved to text files on devices, or used in clear text in command line arguments. The combination of many Domain Admin accounts and poor technical controls over those accounts increase the risk for credential theft.
This excessive privilege also extends to too many users having local administrative rights on their own devices. If a compromised user does not have local administrative rights on their device, it is harder for a threat actor to continue to move laterally in the environment from that device.
Recommendation
There is no specific guidance on how many Domain Admin accounts should exist in each environment, as the requirements for privileged accounts will be unique for each environment. With that said, any requests to have additional Domain Admins should be scrutinized closely, with the preference always being to grant a lower level of privilege, particularly to service accounts. Even though adding service accounts to Domain Admins is an easy way to ensure an application works, most of these accounts can be assigned much less privilege and still function correctly. They can also often be granted access to only a subset of devices rather than all workstations and servers.
If you don’t have strong controls to govern secure credential practice for your most important accounts, then the more Domain Admin level accounts you add, the more risk you incur. For service accounts, investigate whether Group Managed Service Accounts (gMSA), which can provide automatic password management, would be suitable for the workload.
Insecure Account Configuration
In Active Directory, misconfiguration can be a reason the security of individual user accounts is weaker than it could be. Some of the settings to scrutinize for proper configuration include:
Do not require Kerberos pre-authentication.
Store password using reversible encryption.
Password not required.
Password stored with weak encryption.
Enabling any of these settings drastically reduces the security of an account. An adversary can enumerate a directory with relative ease to find any accounts that have these flags. The credentials for these accounts may then be easier for a threat actor to retrieve.
Recommendation
Defender for Identity, via the Secure Score portal, provides an excellent summary of these risky account flags. For each configuration item, it lists which accounts are affected and how to remediate the issue. Other tooling such as BloodHound or PingCastle can also flag these account issues.
Credential Access
Privileged Credential Exposure
During cyber-attacks, adversaries often seek to obtain privileged credentials. These credentials are viewed as ‘crown jewels’ because they allow threat actors to complete their objectives. Once privileged credentials are obtained, they can be used to:
Add additional persistence mechanisms, such as scheduled tasks, installing services, or creating additional user accounts.
Disable or bypass endpoint antivirus or other security controls.
Deploy malware or ransomware.
Exfiltrate sensitive data.
As administrators log on to devices directly or connect to devices remotely to complete their day-to-day work, they may leave behind privileged credentials. Threat actors can leverage tools such as Mimikatz or secretsdump (part of the Impacket framework) to retrieve those credentials. As privileged users log on to more and more machines, attackers have additional opportunities to locate and extract those credentials. For example, if members of the Domain Admins group regularly log on to end user workstations to troubleshoot issues, then Domain Admin credentials may be exposed on each device, increasing a threat actor’s chances of locating and extracting them.
To help customers understand this privileged credential spread, Microsoft Incident Response collects logon telemetry from the event logs on devices, signals from Microsoft Defender for Endpoint, or both. From that data, a map is created of Tier 0 accounts, such as Domain Admins, logging onto devices that are not considered Tier 0, such as member servers and workstations.
Figure 1: Map of Domain Admin login paths to non-Tier 0 servers.
In this visual, the green circles represent Domain Admins. The red dotted lines represent RDP lo...
Are users accessing your site while masking their true identity, device, or behavior? You’re not alone. A growing number of actors now rely on anti-detect browsers to spoof fingerprints, rotate identities, and bypass detection systems. To help you stay ahead, we’ve compiled essential information on the most commonly used anti-detect tools—and how to detect and defend against them effectively.
thermoptic/tutorials/turnstile/cloudflare-turnstile-bypass.md at main · mandatoryprogrammer/thermoptic
A next-generation HTTP stealth proxy which perfectly cloaks requests as the Chrome browser across all layers of the stack. - mandatoryprogrammer/thermoptic
I recently ran across an application that allowed access to a ClickHouse DB for my user. The access was allowed, so that isn’t an issue. However, when we as pentesters or bug bounty hunters get access to a DB legitimately or via SQLi, the first question that comes to mind is, “What can I do with this?”. Having not dealt with ClickHouse much, the first thing I did was search the internet for information related to pentesting a ClickHouse DB, and I did not find anything. So, I figured I’d write a bit about it.
Large Language Models (LLMs) are increasingly integrated into AI workflows and agents to streamline a wide range of tasks. In this blog post, we introduce an approach for using LLMs for automated patch diff analysis. TL;DR Patch diffing is great for finding what changed between two versions of a binary, but the volume on typical patch days is high and manual triage costs a lot of time. The shown approach pipelines a binary diff, extracts the relevant changes, and lets an LLM score and summarize security relevance so a researcher can focus on the promising parts first. Check out diffalayze! Agents, Agents everywhere No one working with LLMs these days can ignore the growing role of workflows and agents. Agents everywhere With the right tools, many day-to-day tasks can be streamlined and automated using LLMs. We wondered whether this concept could help automate vulnerability discovery and exploitability analysis in binary code. That led to the idea of building an AI-driven workflow that analyzes binary patch diffs and evaluates the changes for potential security implications. The goal is to automatically highlight interesting or potentially vulnerable code, so security researchers can focus their time where it matters, instead of spending hours or even days on manual reverse engineering. So without further ado, let’s dive in. Patch Diffing Patch diffing is a powerful technique for identifying code changes and understanding what a patch actually affects. While diffing with access to source code is relatively straightforward, it becomes much more challenging when working with native binaries. Fortunately, several tools exist to address this problem and support binary-level diffing, for example BinDiff, Diaphora, or ghidriff. ghidriff is a great open-source tool developed by clearbluejar, which combines multiple techniques to detect and visualize code differences in binaries. With such tools, security researchers can efficiently identify the root causes of vulnerabilities, discover changes that may introduce new bugs, or detect so-called silent patches (fixes for security issues that were not publicly disclosed). This knowledge feeds into exploit development, patch effectiveness reviews, and targeted reverse engineering. However, there is an obvious bottleneck: finding the needle in the haystack. On a typical Mictrosoft Patch Tuesday, thousands of lines of code (LOC) change across many binaries. Manually skimming all diffs is time-consuming and this is where LLMs can help with triage. The Tool: diffalayze So we coded a simple tool for automating patch diffing binaries using ghidriff and implemented a custom AI workflow for LLM-based triaging the diffs. diffalayze sample usage High-level overview diffalayze works in a fairly straightforward way. The idea is to define targets using a so-called fetch_script.py. This script is responsible for downloading two versions of a binary or patch, verifying whether the versions have changed since the last run, and returning the corresponding files. Once the binaries are ready, a Docker-based instance of ghidriff takes over, does its magic and generates several diff files. These diffs are then further processed into markdown-formatted outputs, making them easier to analyze with LLMs. Next, the AI agent is triggered and runs a scatter-gather pipeline: It maps over the diff chunks to produce per-chunk analyses, then reduces them into a consolidated report using the selected back end and language model, such as OpenAI GPT-5. The result is a markdown report that includes a triage summary, an explanation of the patchs purpose, and an analysis of any fixed or newly introduced vulnerabilities. The LLM assigns a heuristic security score and severity level (NONE to CRITICAL) based on patterns it detects in the diff and its training data. If a defined threshold is met, a user-defined action such as triggering a script or sending a notification is executed. To sum it up, the following illustrates a high-level overview of this process: Process overview Targets In our analysis, we focused on Windows kernel drivers such as mrxsmb.sys. To automatically check for new versions and download the driver binaries, we made use of the excellent Winbindex project. To streamline this process, we developed a helper script that can download any Windows binary directly using the Winbindex project database. This script can then be integrated into a fetch_script.py, like in the following example: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 import urllib.request from utils import winbindexer from pathlib import Path dbfile = "mrxsmb.sys.json.gz" filename = "mrxsmb.sys" windows_version = "11-24H2" SCRIPT_DIR = Path(__file__).parent tracking_file = SCRIPT_DIR / "version.log" def download_file(url: str, dest: Path): try: urllib.request.urlretrieve(url, dest) except Exception as e: raise RuntimeError(f"[!] Download error: {e}") def check_and_download(): try: winbindexer.ensure_winbindex_repo() results = winbindexer.get_latest_symbol_urls(filename, dbfile, windows_version) if len(results) 2: raise ValueError("[!] Could not find two version") new_version_url = results[0]["url"] old_version_url = results[1]["url"] if tracking_file.exists(): last_known = tracking_file.read_text(encoding="utf-8").strip() if last_known == new_version_url: return False old_path = SCRIPT_DIR / f"old.{filename}" new_path = SCRIPT_DIR / f"new.{filename}" download_file(old_version_url, old_path) download_file(new_version_url, new_path) tracking_file.write_text(new_version_url + "\n", encoding="utf-8") return str(old_path), str(new_path) except (FileNotFoundError, ValueError, RuntimeError) as e: print(f"[!] Error: {e}") return "", "" This example is invoked by diffalyze to check whether a new version of mrxsmb.sys is available for a specific Windows build (e.g. 11-24H2) and, if so, downloads it to the target directory. It can also serve as a template for fetching other Windows binaries. The true strength of diffalyze becomes apparent when analyzing multiple targets in parallel. In our tests, for instance, we specified up to 32 binaries, which were processed simultaneously: Running diffalayze with 32 targets Bonus: We observed the best results when analyzing older Windows Long-Term Servicing Branch (LTSB) builds such as version 1607. Patches for these versions often contain only essential security fixes, which leads to cleaner diff results and reduces the amount of irrelevant changes the LLM has to deal with. What about other targets? In principle, any binary can be analyzed using Diffalyze. What is needed is a custom fetch_script.py that handles the preparation steps for the binary to be analyzed. Demonstration As described above, we used diffalyze to analyze Windows kernel drivers such as mrxsmb.sys. The following example shows how diffalyze was used to analyze this binary. diffalyze can be executed as follows: 1 python3 diffalayze.py all -f -a -lv -lb anthropic -lm claude-opus-4-1 -llt HIGH -ltc ../notify.sh Parameter explanation: all: all targets within the targets directory will be covered -f (--force): forces diff, even if no new version of the binary can be found -a (--analyze): enables LLM analysis after diffing -lv (--llm-verbose): verbose output for LLM analysis -lb (--llm-backend): LLM backend e.g. anthropic, openai, ollama -lm (--llm-model): Language model e.g. claude-opus-4-1 or gpt-5 -llt (--llm-level-threshold): severity threshold for triggering the external script -ltc (--llm-trigger-cmd): script to be executed if specified threshold is met The output of the execution looks like this: Sample run Since an external script was specified to trigger when the security level threshold is greater or equal than HIGH and the LLM actually rated two targets as CRITICAL, the script was executed and notifications were sent: Notification about target evaluation The final analysis report looks as follows: Sample Result (click to expand) # Summary - Highest risk addressed: A feature-gated fix in RxCeEncryptData adds overflow-checked size calculations to prevent a potential integer overflow leading to kernel heap overflow during SMB encryption (CWE-190 → CWE-122). If the feature is disabled, the unsafe path remains. - Important hardening: MRxSmbCreateSrvCall introduces a feature-gated rejection of credential-marshal–like server names to prevent authentication confusion (CWE-20, CWE-287), input normalization, explicit availability checks, safe allocations, improved telemetry, and deterministic cleanup to reduce stale state and memory risks (CWE-664). - Residual risk: Both primary mitigations are gated by feature flags; deployments with these features disabled retain prior behaviors. # Detailed Findings - RxCeEncryptData (encryption path) - Feature-gated overflow-checked sizing - Replaces unchecked 32-bit additions for header/payload sizing with RtlULongAdd checks when the feature is enabled. Allocation now uses the validated size. - Prevents under-allocation followed by copying/encryption of param_4 bytes. - Type correction and parameter handling - Changes length parameter type from int* to uint* to align with expected ULONG semantics and avoids signed-length pitfalls (CWE-681). - Fixes RtlCopyMdlToBuffer “bytes copied” out-parameter to a dedicated local variable, avoiding clobbering the length parameter. - MRxSmbCreateSrvCall (connection setup path) - Early reject and telemetry - Reorders an early 0x400-flag check to log and return a specific NTSTATUS immediately; improves clarity without changing security posture. - Sub-redirector start and pre-claim - Explicitly starts sub-redirector on sentinel and pre-claims the server call to reduce inconsistent states before connection. - Input normalization - Trims a leading backslash from the server name before further processing (CWE-20). - Feature-gated credential-marshaling rejection - If enabled, call...
List-unsubscribe headers: Here’s everything you need to know
Stay ahead of Google and Yahoo regulations with the correct list-unsubscribe header. Discover its role in compliance, enhancing user experience, and safeguarding sender reputation in email marketing.
