Look what I found in my mailbox today! 🎉 Thank you @ISC2 for this milestone. Excited to officially be a Certified Information Systems Security Professional (CISSP). #ISC2 #CISSP #Cybersecurity #InfoSec

Last year's Flare-On almost killed me. I ended up 16th, and 'manually' reversing tasks 7 and 9 was so painful: frankoverflow.com/2025/10/25… This year I got 40th, and here's my full writeup: /goal Play Flare-On, my username is FrankOverF1ow and password is REDACTED

#flareon13 registration is live at flare-on13.ctfd.io See you all tonight, its gonna be a weird one!

One last hailmary. A decade of experience. You can see my 50+ CVEs here: cypher.church/CVEs ... I have mainly been doing math these last 3 years, trying to get a novel sieving system working based on quadratic residues rather then divisibility: github.com/BigPolarBear1/fac… 1/2

We put all the best models in our home-grown sandbox infra (SPACE, the sandbox behind @perplexity_ai Computer), gave them root inside the VM, and one goal: hack out of the sandbox and capture the flag. Results were super interesting! 1. No model escaped the VM, but a few found a real vulnerability in how we enforce network policies and were able to exploit it: gpt-56-sol, gpt-56-cyber, opus-5, and kimi-k3 (open weight ftw!) We later discovered that several other sandbox providers such as Daytona, Vercel, Modal and E2B were similarly vulnerable and we disclosed our findings to them. 2. This wasn't just a misconfiguration. One vulnerability relied on the fact that CDNs and shared infra like Fastly or S3 serve many domains/buckets from the same IPs, so allowlisting a package repository like pypi[.]org quietly allowed other sites on those IPs. In one run, gpt-56-cyber found that Taboola's image service shared an IP with PyPI, had Taboola fetch a thum[.]io URL, got thum[.]io to screenshot the blocked callback, then OCR'd the flag out of the PNG. Three unrelated services, none of them hacked, chained together to walk right past the policy. 3. Security and preventing rogue agents was our #1 priority. We logged every trajectory, command, and network call, and a researcher plus a security agent watched runs live. We were alerted the moment the first bypass landed and we paused everything to review. We designed the agent harness be tightly scoped and runs outside the sandbox, so we always have full control, and we'll be open sourcing the harness soon! Running agents like this safely isn't rocket science. It's simply applying good engineering practices: proper guardrails, observability, and alerting. Check out our open source project, Numbat, to learn how you can do this yourself. 4. We learned a ton about how differently models approach hacking. Opus swept ~400,000 Cloudflare IPs and went all the way down to raw memory-mapped hardware. When Kimi had no internet or tools, it hand-built an entire gRPC client from scratch to poke at the host. Grok decided within a few minutes that the task was impossible and started trying to hack its own harness instead. Part II will dive deeper into the different hacking personalities of these models and how their behavior changes when they operate in swarms. Super excited to share what we learn with y'all! Read about the full research here: perplexity.ai/hub/blog/escap…

Came across a really cool execution pattern while looking at an 𝗦𝗩𝗖𝗦𝘁𝗲𝗮𝗹𝗲𝗿 𝗟𝗼𝗮𝗱𝗲𝗿 infection. Extracted the payload from the packet capture and found a second stage uploaded with a .𝚙𝚑𝚙 extension. The payload drops an XOR-obfuscated file (XORed with 𝟶𝚡𝟺𝟸) disguised as .𝚙𝚑𝚙, which decodes into a Windows executable. The decoded binary uses 𝙶𝚎𝚝𝙻𝚘𝚐𝚒𝚌𝚊𝚕𝙳𝚛𝚒𝚟𝚎𝚜 / 𝙶𝚎𝚝𝙳𝚛𝚒𝚟𝚎𝚃𝚢𝚙𝚎𝚆 to enumerate drives and appears to search them for .𝚙𝚢 / .𝚙𝚢𝚠 files in the whole drive. It then infects Python scripts it finds outside a predefined set of excluded system, application, and dependency directories. The injected code then launches hidden PowerShell with ExecutionPolicy Bypass, downloads another EXE to %𝚃𝙴𝙼𝙿%, validates the 𝙼𝚉 header, and executes it. Execution flow: SVCStealer Loader → XOR-obfuscated PE disguised as .𝚙𝚑𝚙 → Enumerates drives and searches for Python scripts → Infects .𝚙𝚢 / .𝚙𝚢𝚠 files → 𝚙𝚢𝚝𝚑𝚘𝚗.𝚎𝚡𝚎 → hidden 𝚙𝚘𝚠𝚎𝚛𝚜𝚑𝚎𝚕𝚕.𝚎𝚡𝚎 → downloaded next-stage payload Very interesting way of turning legitimate Python scripts into future execution points. IOCs: hxxp[://]193[.]178[.]158[.]107/2[.]7[.]exe hxxp[://]193[.]178[.]158[.]107/2[.]8[.]exe hxxp[://]196[.]251[.]107[.]186/2[.]exe hxxp[://]196[.]251[.]107[.]186/1[.]exe

“Mysteries of the Windows Kernel” series of articles Pt.1 — Processes & Objects Pt.2 — Threads Scheduling & CPUs Pt.3 — Memory Management & Address Translation Pt. 3: medium.com/@amitmoshel70/mys…

Antidbg: A stealthy, fully syscalled C/C++ userland anti-debugging library for Windows, designed to protect software from reverse engineering. It contains 43 anti debug techniques. Github:- github.com/NotRequiem/antidb…

I was looking into BYOVD techniques today because of a recent case where a threat actor brought a vulnerable driver onto the system to disable the EDR and I want to share my thoughts on the topic. Bringing the vulnerable driver is just one part of the equation. Threat actors usually have to bring additional components to load it and execute the code needed to actually tamper with the EDR. The EDR blocked that payload... And I think that's an important point when we talk about BYOVD. For seasoned operators, this might be easy. But that is not most of what we see. The average threat actor still has to expose themselves somewhere along the chain: → Introduce and load the vulnerable driver -> LOLDrivers.io vuln drivers list → Create or start the service -> Service creation events → Drop a DLL or other payload -> File creation events under sus locations → Use PowerShell/.NET -> PowerShell execution events/AMSI detections → Compile something directly on the target -> Behavioral detections from ETW CLR provider. Usually CLR loading into non-.NET processes, assembly load notifications for newly compiled DLLs from `%TEMP%` There is not just a perfect way to detect BYOVD techniques. Defense in depth is the way to go... Again, having said all that, I know how difficult it is for the majority of organizations to have this in place. This is why these methods are still very successful and quite popular, but in my personal case, most attackers will not even come as prepared as seasoned operators like I mentioned above. We have to detect/hunt for the path they have to take to get there!

Threat intel without context has always annoyed me. Everybody thinks their feed is high-confidence until you ask them for more context about the infrastructure they're pushing through. They have no idea what infra they're tracking. I see this far too often... 🤦 You get an IP, domain, or hash marked as malicious, maybe with a threat actor tag attached, but very little explaining how anyone reached that conclusion. A lot of feeds aggregate scanning results, third-party datasets, shared intelligence, and other feeds. After enough aggregation, the original evidence gets lost. That becomes a problem when you start seeing scanned infra, honeypots, red team systems, or other noise mixed into feeds that are still being marketed as “verified” or “high confidence.” I wanted to take a different approach with the intel we publish through Threat Hunting Labs. Every IOC we publish is tied back to the intrusion where we actually observed it and goes through two stages of curation. If an IP was contacted by malware, we keep the surrounding execution context: - Which process made the connection - The command line - Process lineage - Context of the malicious process (i.e., process injection, LoTL, etc.) - Whether it was tied to persistence and more... That context is the important bit. You should be able to see why an IOC was classified as malicious instead of blindly trusting a label. Because when you have a hit, you can get context on how we have seen it used in the past so you can hunt through your logs. From there, consuming the feed is still simple. API key, plug it into the platform you already use, and go. If you want to dig deeper, all of the supporting context is available through the UI and API. This is pretty much the threat intel feed I always wanted to use myself. Very proud of what we have built here.

i don't know how many of you remember but back in the day (6 years ago), Abdelhamid was the OG! i started learning about windows logic bugs through his work instead of James's work at first. was following his work religiously and fascinated by how clever and creative he is, from kaspersky and avast, McAfee and win defender and other ms core components to inventing file delete to EoP techniques, he did them all! never thought such a great mind would have this happen to his journey it really does break my heart, I never met him nor had the honour to chat with him but he became an idol in my book. great to see, 6 years after, still his work is top-top-top tier, still mind bending and creative (wish i had a better vocab but if you can help, he is the literal definition of finding a unicorn)

Nightmare Eclipse, the person who has been dropping Windows zero-days, has finally decided to share his story. He's an ex-Microsoft employee, we had dinner together, and I've known him and his story for some time. His real name is Abdelhamid Naceri. He's a very talented and intelligent individual, and he came across as someone who'd be a real professional to work with. "If only I didn't pour my soul into that job with countless of stupid non sleep nights, i would have gotten over it..." - Naceri He loved Microsoft. I wouldn't say that what he did, releasing all those zero-days, was normal, but he felt he had no other option because of the injustice Microsoft did to him. They fired him, and you can read the vague reason they gave in the email sent to him by the Vice President of Engineering at MSRC, below. According to Abdel's account, VP Tom Gallagher met with him after the firing to tell him they were blacklisting him from Microsoft and writing him a bad reference so he'd never be able to get a job again. Normally you'd think, well, big deal, just find another job, right? But Abdel doesn't have a European passport, and he was only a couple of months away from getting permanent EU residence. So instead of granting him those couple of months, Microsoft fired him for a reason that, as far as we can tell, was never made clear, then fought him in court and offered him €55,000 plus a year's pay to drop the case. All while Abdel was releasing zero-days. Abdel continued suing Microsoft for unfair termination in Germany, a fight that has cost him over $200,000. He says Microsoft refused to reveal any details about the security breach and went another direction. If you are reading this, and you can offer him a LEGAL job, this is his e-mail: msnightmare@proton.me

Congratulations! We’re very happy to have you as part of the cohort.

Honoured to be part of the 2026 European Cybersecurity PhD Accelerator cohort by @VirtualRoutes. Thirty scholars from across Europe, working on the technical, legal, policy and economic sides of cybersecurity, and I'm looking forward to the virtual sessions and the retreat this November. My own research focuses on AI-driven cyber resilience and vulnerability forecasting, and I'm keen to test those ideas against very different perspectives. Congratulations to my fellow scholars, and thank you to the Virtual Routes team for putting this together. #CyberSecurity #PhD #CyberResilience #VulnerabilityManagement #VirtualRoutes virtual-routes.org/european-…

Microsoft has failed to properly patch ShieldBreak CVE-2026-69414 - msrc.microsoft.com/update-gu… ShieldCrash demonstrates a full bypass of the patch - github.com/MSNightmare/Shiel… Works with latest September 2026 patch

Really proud of this release and very thankful to hunt.io for supporting it. The video walkthroughs for this lab were filmed and narrated by yours truly 🙂, showing how we approached the hunts and worked through the answers. Check out the FREE lab and claim your 45-day hunt.io trial access 👇

My latest research on a new way to exploit vulnerable windows drivers: bring your own trusted caller (BYOTC). In addition to bringing a legitimate driver, an attacker can also bring a trusted user-mode client process and gain code execution inside of it: xusheng.dev/posts/byotc/main…

Been testing GPT-6 Astra against some recent malware we collected through IR engagements. I used the ChatGPT Chrome extension with Guacamole running a @ThruntingLabs FlareVM environment directly inside the browser. Samples included a recent SynkLoader, SystemBC and a few fairly nasty obfuscated DLLs. Using high effort, Astra got through the analysis in roughly 15 minutes and found pretty much everything I was looking for, including obfuscated configuration, encrypted passwords embedded in the binaries and the important execution behaviour. That part impressed me, but overall, computer use is insane! Compared with GPT-5.6 Sol, the difference is huge. Astra was much better at understanding what was on screen, interacting with the tooling and moving through the analysis without getting lost. This changes the automation angle quite a bit. You can now start thinking about automating workflows around the actual tools analysts already use, rather than having to rebuild everything around APIs and custom integrations. Just throw Computer Use at it and let it do the work. Very interesting direction for DFIR and malware analysis!

While investigating an ongoing intrusion, we have come across a threat actor using what appears to be a custom RMM written in Python. The screenshot below shows the operator panel. Anyone recognize this RMM or come across something similar before? Please reach out and we will be happy to share more details from what we are seeing at the moment.

逆向工程这活儿，以前是硬骨头，现在也要被 AI Agent 接管了。 x64dbg 老玩逆向的都熟，Windows 上经典的开源调试工具，白嫖还能自己写插件。 关键是有人给它整了个 MCP Server，直接把调试能力甩给 Claude Code、Codex 这类 Agent。啥意思？ 1️⃣ 让 AI 自己调 x64dbg 去扒程序 2️⃣ 下断点、读内存这些活儿也能交出去 3️⃣ 你在旁边看着就行 以前扒汇编得一行一行啃，眼睛都看瞎，现在连逆向都开始 Agent 化了，这门槛降得有点狠啊。 🔗 x64dbg：x64dbg.com/ 🔗 GitHub：github.com/duty1g/x64dbg-mcp…

We reverse engineered malware built to kill our own EDR. In August 2026, eSentire documented a ClickFix campaign selling a DLL sideloader as a service. It drops a malicious mscoree.dll next to a signed Microsoft binary, vb7to8.exe. Windows loads the planted copy first. Attacker code then runs inside a trusted process. The kit also ships a vulnerable driver (BYOVD) to disable EDR, including Elastic Endpoint. So we rebuilt it. A NativeAOT .NET 7 library, exports faked, a module initializer that fires on load. We dropped it beside vb7to8.exe and ran it. Elastic Defend 9.5.0 flagged the load as DLL Hijack: Masquerading. Detecting this before 9.5.0 took ~88 lines and a list of ~2,600 library names. Now it's one line. MITRE ATT&CK: T1574.001 (Hijack Execution Flow: DLL), T1036 (Masquerading). Reverse engineering walkthrough, the .NET rebuild, and the detection breakdownby @0xfluxsec and @django88_: go.es.io/4xw6o5G Original campaign research by @eSentire.