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.
Как мы в Selectel нашли уязвимость в Mailcow, или немного о безопасности в open source
У коммерческих решений есть очевидные плюсы: профессиональная поддержка, регулярные аудиты, соответствие стандартам и сертификация. Open source — бесплатен, гибо...
10 Things I Hate About Attribution: RomCom vs. TransferLoader | Proofpoint US
Threat Research would like to acknowledge and thank the Paranoids, Spur, and Pim Trouerbach for their collaboration to identify, track, and disrupt this activity. Key takeaways
C4 Bomb: Blowing Up Chrome’s AppBound Cookie Encryption
In July 2024, Google introduced a new feature to better protect cookies in Chrome: AppBound Cookie Encryption. This new feature was able to disrupt the world of infostealers, forcing the malware...
Historical Analysis of Reflected Vulnerabilities: The Evolution of Windows Defender Defenses
This report analyzes a historical class of security flaws known as “reflected vulnerabilities,”which were once potent zero-day attack vectors targeting early Windows versions and antivirussoftware. We examine classic exploitation techniques, such as parser attacks, packet fragmen-tation, and syscall abuse, which could lead to remote code execution (RCE) or privilege esca-lation. The objective is educational, demonstrating how modern defenses in Windows 11 andWindows Defender—such as Address Space Layout Randomization (ASLR), Data ExecutionPrevention (DEP), Control Flow Guard (CFG), and hardened parsers—have rendered this classof vulnerabilities obsolete. Proof-of-concept (PoC) code is provided solely to illustrate histor-ical concepts and is non-functional on modern systems, ensuring compliance with responsibledisclosure principles.
Mutation-Based XSS + V8 type confusion + V8 sandbox escape = RCE on Basecamp.
Disclosed it on Hackerone: https://t.co/slsv3j4jXx
go read the comments if you wanna see what a week of exploit dev pain looks like.
Meowsterio: Weaponizing ClickOnce in 2025 - g0njxa - Medium
Meowsterio is a traffer’s group specialised in the cryptocurrency theft, recruiting workers to spread infostealers using fake online custom-created projects as lure to phish people. The Meowsterio…
CrowdStrike Investigates the Threat of Patchless AMSI Bypass Attacks
CrowdStrike researchers investigate various tactics to bypass Windows' AMSI security feature and discuss how the Falcon platform detects and protects against them.
OneClik: A ClickOnce-Based APT Campaign Targeting Energy, Oil and Gas Infrastructure
The Trellix Advanced Research Center has uncovered a sophisticated APT malware campaign, we’ve dubbed OneClik, specifically targeting the Energy, Oil and Gas sector through phishing attacks and the exploitation of Microsoft ClickOnce.
