CaptiveCrunch: Midnight Blizzard targets travelers worldwide for malware delivery and credential theft | Microsoft Security Blog
Storm-2945, a sub-cluster of the Russian threat actor Midnight Blizzard, has been observed compromising the sign-in portals of hospitality-related organizations such as hotels since May 2026 in order to deliver malware to travelers and steal credentials in an operation we call CaptiveCrunch.
Turning Chrome Remote Desktop into Pure Red Team Ops
How to hide the Chrome Remote Desktop connection banner by patching a single dialog resource, then abuse host.json and MSI packaging to turn CRD into a quiet persistent access channel.
Unless you've been living under a rock, you're probably aware frontier large language models (LLMs) have been keenly focused on automating software development, vulnerability discovery, and most recently exploit development. The most publicized instance of this was Anthropic's marketing campaign around the release of Mythos. What better way to drum up business than by
SakDriver: Reversing a Windows Kernel Driver Rootkit
A reverse-engineering walkthrough of SakDriver, a Windows kernel-mode rootkit first mistaken for a Cobalt Strike Beacon. It patches ETW, hides processes via DKOM, masquerades as a minifilter and a fake Microsoft service, and — most notably — receives C2 commands through the Windows registry. Includes the full recovered command table, IOCs and a matching YARA figure.
Summary A vulnerability in vBulletin has been identified, the vulnerability allows an unauthenticated user to cause the vBulletin to execute arbitrary code (PHP) on the remote server. Vendor Response The vendor has issued a fix available at: https://forum.vbulletin.com/forum/vbulletin-announcements/vbulletin-announcements_aa/4509404-vbulletin-6-2-2-is-available and https://forum.vbulletin.com/forum/vbulletin-announcements/vbulletin-announcements_aa/4509358-security-patch-released-for-vbulletin-6-2-1-6-2-0-and-6-1-6 CVE CVE-2026-61511 Credit An independent security researcher working with SSD Secure Disclosure. Affected Versions Root … vBulletin Runtime Template runMaths Preauth RCE Read More »
The HTTP protocol plays a vital role in the seamless functioning of web applications, however, the implementation of HTTP parsers across different technologies can introduce subtle discrepancies, leading to potential security loopholes.
In this resea...
CVE-2026-50458: Finding a UAF in the Windows Brokering File System
On Tuesday, July 14, Microsoft released the largest Patch Tuesday update in its history, fixing more than 600 vulnerabilities. A bug I reported to Microsoft on May 17 was patched as CVE-2026-50458 in this release, so I am publishing the writeup I wrote at the time, while the details were still fresh. I hope you enjoy it!
Breaking ONLYOFFICE in 3 steps: OnlyShells vulnerability chain
Technical breakdown of OnlyShells — a five-vulnerability chain in ONLYOFFICE Desktop Editors combining zero-click XSS, a Chromium V8 RCE, and an update-service LPE to achieve remote code execution as NT AUTHORITYSYSTEM when a victim opens a crafted document.
Inside Pegasus: The evolution of the world's most notorious spyware system - Amnesty International Security Lab
We are presenting here our most complete analysis to date of the Pegasus spyware. This blog post builds on previous technical reports and forensic investigations by Amnesty International’s Security Lab. Significantly it also draws on previously unpublished internal NSO Group marketing material and internal technical material which was disclosed as part of a long-running civil […]
Unpacking “Cruciferra”: An Analysis of a Crypter Service | Proofpoint US
Key Findings Cruciferra is a sophisticated crypter service used by multiple unrelated cybercriminal threat clusters. It has been observed delivering a wide range of
Three Steps to the Terminal: A Siemens ROX II Zero-Day Trilogy
A technical analysis of three chained zero-day vulnerabilities in Siemens ROX II OT switches that allow privilege escalation and persistent root access.
Fraggap (CVE-2026-53362) is a bug in the Linux UDPv6 corking path that allows a 15-byte OOB write into skb_shared_info. The code is here. {.markdown-image-centered} CONFIG_IPV6=y...
[Wipeload Step 5.] Sorry, I studied ALPC just to show you this (EN) - hackyboiz
pHi everyone! Today gongjae is back with Step 5 — the crown jewel of the Wipeload project, haha./p
pimg src="/2026/07/19/gongjae/Wipeload_step5/EN/image.png" alt="image"/p
blockquote
pPrevious research postsbra href="https://hackyboiz.github.io/2026/06/06/OUYA77/Wipeload_step1/kr/"https://hackyboiz.github.io/2026/06/06/OUYA77/Wipeload_step1/kr//abra href="https://hackyboiz.github.io/2026/06/21/ji9umi/Wipeload_step2/kr/"https://hackyboiz.github.io/2026/06/21/ji9umi/Wipeload_step2/kr//abra href="https://hackyboiz.github.io/2026/06/26/ji9umi/Wipeload_step3/kr/"https://hackyboiz.github.io/2026/06/26/ji9umi/Wipeload_step3/kr//abra href="https://hackyboiz.github.io/2026/07/13/OUYA77/Wipeload_step4/kr/"https://hackyboiz.github.io/2026/07/13/OUYA77/Wipeload_step4/kr//a/p
/blockquote
pSteps 2–3 covered ji9umi’s Renderer RCE, and in Step 4 OUYA77 gave us a detailed tour of the Chrome sandbox. Picking up that Way from both of them, I’m going to walk you through — in detail — stronghow do we actually get to Medium-privilege code execution from Chrome?/strong In today’s Step 5 I’ll explain ALPC, the key ingredient of the Sandbox Escape, and in Step 6 we’ll take that ALPC and see how it takes us all the way to Medium-privilege code execution!/p
pShall we get right into it? Let’s go~/p
h1 id="1-Sorry-I-studied-ALPC-just-to-show-you-this"a href="#1-Sorry-I-studied-ALPC-just-to-show-you-this" class="headerlink" title="1. Sorry, I studied ALPC just to show you this"/a1. Sorry, I studied ALPC just to show you this/h1pALPC (Advanced Local Procedure Call) is the IPC that sits at the very bottom of process-to-process conversations inside Windows. The local RPC we’re all familiar with, at the kernel level, mostly ends up riding ALPC too, and system services everyone has heard of like “csrss.exe” or “lsass.exe”, DCOM, WinRT activation… pretty much every user-mode service is talking over an ALPC port somewhere. Chrome is no exception — the Mojo IPC pipe between the renderer and the browser has ALPC partially baked into its underlying transport. Which is to say: the object we’re going to be poking at today is dead common, but the kind of thing you’d miss unless you look closely!!/p
pimg src="/2026/07/19/gongjae/Wipeload_step5/EN/image2.png" alt="image"/p
blockquote
p?? : You studied ALPC just to do THIS?brgongjae : delNope, just did it for fun/del/p
/blockquote
pInside the kernel, two objects star in this show. code_ALPC_PORT/code is the communication endpoint, and codeKALPC_MESSAGE/code is a single message flowing through that endpoint. Easiest mental model: server opens a port, clients attach, they exchange messages!/p
pa href="https://hackyboiz.github.io/2025/11/29/gongjae/Windows_ALPC/KR/"https://hackyboiz.github.io/2025/11/29/gongjae/Windows_ALPC/KR//a/p
pActually, we already went over ALPC once in a previous research post, right? Stuff like the port splitting into two tiers of connection port / communication port, and basic message-attribute concepts — I put all of that together in the earlier ALPC post! If this is your first time hearing about ALPC, I’d recommend giving that one a skim first… but honestly the single most important fact is: stronghow does the Chrome sandbox treat ALPC?/strong/p
pimg src="/2026/07/19/gongjae/Wipeload_step5/EN/image3.png" alt="image"/p
pThe answer: the codeNtAlpc*/code family of syscalls themselves are strongnot/strong on the sandbox’s filter list!! Even though it’s an undocumented interface with nothing on the official docs, it’s a very-much-alive API, so even an Untrusted IL renderer can call the stubs codentdll/code exports directly./p
h2 id="1-1-Sync-vs-Async"a href="#1-1-Sync-vs-Async" class="headerlink" title="1.1 Sync vs Async"/a1.1 Sync vs Async/h2pThere are two ways to send a message over ALPC. strongAsync/strong requests toss the request onto a queue and the calling thread goes on its merry way. strongSync/strong requests, on the other hand, park the calling thread inside the kernel until an answer comes back!/p
pimg src="/2026/07/19/gongjae/Wipeload_step5/EN/image4.png" alt="image"/p
pFor the kernel to sustain that “parked” state, it obviously needs some info, right? Which thread is waiting on which message, who to wake up when the reply lands — that stuff has to be recorded somewhere!/p
aside
💡
Quick aside on why the two modes are asymmetric here: async requests don’t need the kernel to know “who’s waiting on this reply?” As long as the completion callback is correctly registered, we’re done. 🫠
Sync is a different story though. The moment the reply arrives, the kernel code handling it has to figure out **“okay, I got this — who exactly am I supposed to wake up??”**, and that answer has to be pre-stored as a back-pointer somewhere.
/aside
h2 id="1-2-Waiting-thread"a href="#1-2-Waiting-thread" class="headerlink" title="1.2 Waiting thread"/a1.2 Waiting thread/h2pSo when a sync request comes in, the kernel slips a back-pocket pointer into the message object that says “the thread waiting on this message’s reply is THIS guy!!” That’s the code_KALPC_MESSAGE.WaitingThread/code field, and in the environment I’m experimenting with today, Windows 22H2 22621.963, it lives at offset +0x20./p
pThere’s a matching field going the other direction too. On the thread side there’s a field that records “the message I’m currently waiting on is THIS guy!!” — that’s code_ETHREAD.AlpcMessageId/code, located at offset +0x578. WaitingThread from earlier and this AlpcMessageId form a pair of back-pointers pointing at each other!/p
pimg src="/2026/07/19/gongjae/Wipeload_step5/EN/image5.png" alt="image"/p
blockquote
pKind of like how Tai Lung and Master Shifu shared a special bond back when Tai Lung was little…/p
/blockquote
pThere’s a reason the kernel bothers to write this pair with code_InterlockedExchange/code atomically… since the same thread can be touched from multiple places at once, you need atomicity to avoid races. 😂/p
pBut even so — when the pair matches it’s beautiful, and the moment one side falls out of step, that’s when things go sideways. The main character of today’s vuln is this very field, and an unmanaged back-pointer is guaranteed to blow up in your face sooner or later, haha!/p
h1 id="2-Root-Cause"a href="#2-Root-Cause" class="headerlink" title="2. Root Cause"/a2. Root Cause/h1pAlright, as I said above, we need to see why this unmanaged back-pointer is the seed of the vuln, right? But first, let’s quickly review sync vs async messaging through some code!/p
h2 id="2-1-ALPC-MSGFLG-SYNC-REQUEST"a href="#2-1-ALPC-MSGFLG-SYNC-REQUEST" class="headerlink" title="2.1 ALPC_MSGFLG_SYNC_REQUEST"/a2.1 ALPC_MSGFLG_SYNC_REQUEST/h2pThe entry point where a message actually lands on the queue is codeAlpcpDispatchNewMessage/code. That “somewhere in the middle” I mentioned earlier is right here! Looking at it in IDA it feels like this:/p
precode class="hljs cpp"span class="hljs-keyword"if/span ((SendFlags & span class="hljs-number"0x20000/span) != span class="hljs-number"0/span) { span class="hljs-comment"// ALPC_MSGFLG_SYNC_REQUEST/span
span class="hljs-comment"// plant the thread back-pointer/span
*(_QWORD *)(msg + span class="hljs-number"0x20/span) = curthread; span class="hljs-comment"// msg.WaitingThread = current _ETHREAD/span
_InterlockedExchange64(curthread + span class="hljs-number"0x578/span, msg); span class="hljs-comment"// _ETHREAD.AlpcMessageId = msg/span
}/code/pre
pTwo lines, that’s the whole trick. Stuff the current thread’s code_ETHREAD/code directly into codemsg+0x20/code, and conversely plant the message at codecurthread + 0x578/code. That completes the pair of back-pointers pointing at each other./p
pLet’s also briefly trace how SendFlags gets here./p
aside
💡
When user code calls `NtAlpcSendWaitReceivePort`, the kernel enters `AlpcpSendMessage`, decides routing, and then hands off to this `AlpcpDispatchNewMessage`. The trigger I’m using today goes through `NtWaitForWorkViaWorkerFactory`, but even there — the moment it processes a deferred send — we end up at that same dispatch site.
→ Bottom line: no matter which road you take, if `SendFlags & 0x20000` is satisfied, those two lines run!!
/aside
pcodeSendFlags & 0x20000/code is checking the codeALPC_MSGFLG_SYNC_REQUEST/code flag — if it were an async request, those two lines get skipped wholesale, right? So to hit this vuln you absolutely have to set 0x20000 in SendFlags and take the sync-request branch. The original Theori blog really emphasized this too!!/p
pOne more thing worth noting: the reason the setting is stamped in both directions is to leave no gaps when routing the reply. But this pair hides a fun little asymmetry — would you believe me???/p
pimg src="/2026/07/19/gongjae/Wipeload_step5/EN/image6.png" alt="image"/p
ol
liWhen the thread dies, the code_ETHREAD/code gets deleted entirely, so the codeAlpcMessageId/code on the other side also disappears with it/li
liBut the WaitingThread planted on the message side stays right there as long as the message is alive/li
/ol
pThis asymmetry is exactly the starting point of the vulnerabi
Exploit brokers pay $500,000 for a WordPress RCE. I found one with GPT5.6 Sol Ultra and $25 › Searchlight Cyber
Stay current: Get research alerts for newly disclosed vulnerabilities and exposures If you're running WordPress and want to check if your instance is vulnerable, you can use our tool we've hosted here: https://wp2shell.com/. We held off on publishing this issue to give defenders a chance to upgrade their WordPress instances over the weekend, but during
DinDoor, DenoRAT, and NightshadeC2: Analyzing TAG-150's Evolving Tradecraft
eSentire's TRU breaks down a TAG-150 attack chain using ClickFix lures to deploy Deno-based malware DinDoor and DenoRAT, ultimately loading the NightshadeC2 RAT/infostealer.
[$4,500] Remote Code Execution Vulnerability in Meta's Manus AI
A crafted manus:// Deep Link could replace the token used by Manus My Computer, reconnect the desktop app, and lead to remote code execution through its sidecar.
Smashing the ServiceNow Sandbox – Pre Authentication RCE › Searchlight Cyber
Stay current: Get research alerts for newly disclosed vulnerabilities and exposures Smashing the ServiceNow Sandbox: Pre Authentication RCE This blog post is our second exploring pre-auth script execution security vulnerabilities in ServiceNow. If you haven't seen the first, which includes some background context, you can read it here. After finding our first pre-auth critical bug