Archive

Archive

CaptiveCrunch: Midnight Blizzard targets travelers worldwide for malware delivery and credential theft | Microsoft Security Blog
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.
·microsoft.com·
CaptiveCrunch: Midnight Blizzard targets travelers worldwide for malware delivery and credential theft | Microsoft Security Blog
The Cold Email
The Cold Email
Written pieces, talks, and other bits by Zach Holman.
·zachholman.com·
The Cold Email
The Rise Of Offensive AI
The Rise Of Offensive AI
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
·securifera.com·
The Rise Of Offensive AI
SakDriver: Reversing a Windows Kernel Driver Rootkit
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.
·core-jmp.org·
SakDriver: Reversing a Windows Kernel Driver Rootkit
vBulletin Runtime Template runMaths Preauth RCE - SSD Secure Disclosure
vBulletin Runtime Template runMaths Preauth RCE - SSD Secure Disclosure
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 »
·ssd-disclosure.com·
vBulletin Runtime Template runMaths Preauth RCE - SSD Secure Disclosure
(Research) Exploiting HTTP Parsers Inconsistencies
(Research) Exploiting HTTP Parsers Inconsistencies
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...
·blog.bugport.net·
(Research) Exploiting HTTP Parsers Inconsistencies
Inside a DPRK BlueNoroff ClickFix Kit | JUMPSEC
Inside a DPRK BlueNoroff ClickFix Kit | JUMPSEC
JUMPSEC threat intelligence reveals how Iran‑aligned MuddyWater uses Russian malware‑as‑a‑service and blockchain C2, blurring cybercrime and nation‑state espionage.
·jumpsec.com·
Inside a DPRK BlueNoroff ClickFix Kit | JUMPSEC
CVE-2026-50458: Finding a UAF in the Windows Brokering File System
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!
·rotcee.github.io·
CVE-2026-50458: Finding a UAF in the Windows Brokering File System
Inside Pegasus: The evolution of the world's most notorious spyware system - Amnesty International Security Lab
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 […]
·securitylab.amnesty.org·
Inside Pegasus: The evolution of the world's most notorious spyware system - Amnesty International Security Lab
Frag Gap
Frag Gap
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...
·blog.qwerty.or.kr·
Frag Gap
[Wipeload Step 5.] Sorry, I studied ALPC just to show you this (EN) - hackyboiz
[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
·hackyboiz.github.io·
[Wipeload Step 5.] Sorry, I studied ALPC just to show you this (EN) - hackyboiz
Exploit brokers pay $500,000 for a WordPress RCE. I found one with GPT5.6 Sol Ultra and $25 › Searchlight Cyber
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
·slcyber.io·
Exploit brokers pay $500,000 for a WordPress RCE. I found one with GPT5.6 Sol Ultra and $25 › Searchlight Cyber
Smashing the ServiceNow Sandbox – Pre Authentication RCE › Searchlight Cyber
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
ServiceNow
·slcyber.io·
Smashing the ServiceNow Sandbox – Pre Authentication RCE › Searchlight Cyber