EXPMON

Advanced sandbox-based system specifically designed and built for detecting file-based zero-day and hard-to-detect exploits. By @HaifeiLi.

[EXPMON @EXPMON_]

EXPMON has been updated to v20260601!

This includes a Detection Logic update, and fixed a bug in the Task Schedule module.

https://t.co/5RWoPOG9Bv

[EXPMON @EXPMON_]

Kinda unbelievable, but someone just submitted an Outlook 0-click crash to @EXPMON_!

https://t.co/w4UvVmeeAs

EXPMON detected it as "Malicious - unclassified exploit, please check for potential zero-day".

After spotting this "surprise detection" on EXPMON, I did a quick manual test this Friday afternoon just now. Luckily, this isn't an exploitable Outlook zero-day, but rather a non-exploitable "stack overflow" crash (note: this is a stack exhaustion/overflow, not a "stack-based buffer overflow"). However, it utilizes the exact same 0-click attack vector on Outlook. Had this crash been exploitable, it would be a very serious threat.

Since this sample poses no risk, I am sharing the full content of the PoC sample in the attached picture.

This detection once again validates EXPMON's capability to detect advanced, unknown Outlook 0-click attacks - a capability I previously discussed here: https://t.co/ZhnTObYVUK. If you are concerned about such advanced attacks, let's talk! :)

[Haifei Li @HaifeiLi]

CVE-2026-40361 (https://t.co/CNZKI1aKWG), patched today, is a critical 0-click UAF/RCE bug in Microsoft Outlook that I discovered back in Q1. You definitely want to patch this sooner rather than later.

The danger of such 0-click bugs in Outlook is that they are triggered as soon as the victim reads or previews the email - no clicking of links or attachments is required. Since the bugs reside in Outlook's email rendering engine, it is difficult to mitigate or block (though specifically setting Outlook to render emails only in plain text format is a valid mitigation).

Fun fact about the discovery: after the discovery of the #BadWinmail bug a decade ago, I wanted to run an experiment in Q1 to see if I could find another 0-click RCE in Outlook. The result? It wasn't easy — I even built a dedicated system for it — but I eventually found this one. :)

To understand why such bugs are so critical, check out the #BadWinmail video demo I released a decade ago: https://t.co/DBhE5sWGDH. They share the same attack vector (though #BadWinmail was a working exploit, while this one was a PoC). Essentially, anyone could compromise a CEO or CFO just by sending an email. The threat perfectly bypasses enterprise firewalls and is delivered directly to the inbox. Furthermore, note that Outlook (Classic) lacks an application sandbox, making this attack vector even more dangerous.

Regarding defense and detection: if you are concerned about Outlook 0-click 0-days, my EXPMON system (https://t.co/NKqtbTEmVW) provides cutting-edge detection against such advanced threats. When I designed the original system in 2020/2021, I developed this functionality specifically considering the impact of #BadWinmail. The system accepts .eml or .msg formats, and email samples are deeply tested within an Outlook sandbox. For enterprise users, emails can be "dumped" from the mail server, and EXPMON can be deployed in a private network. Contact me for more details.

P.S. I just noted that the title of the Microsoft Security Update (https://t.co/CNZKI1aKWG) lists this as a Microsoft Word bug, which may or may not be entirely accurate. I demonstrated this bug to MSRC by showing that it works in a real, live Outlook + Exchange Server environment. My bet is that because the bug resides in wwlib.dll — a shared DLL used heavily by both Outlook and Word — it likely affects both Outlook (via email) and Word (via a document file). Regardless of the title, it is a genuine Outlook 0-click RCE.

#CVE-2026-40361 #PatchTuesday #Outlook #0click #EmailSecurity #EnterpriseSecurity #expmon #ThreatIntel #ExploitDetection

[Haifei Li @HaifeiLi]

I'm currently on @EXPMON_ (https://t.co/NKqtbTEmVW) doing a Backup, Detection Logic update, and *maybe* a later Big Data Analytics (BDA) for recent submissions. The long-overdue BDA, which I explained here (https://t.co/R0LTX0qyVT), is the core process of EXPMON to recognize unknown/truly-advanced 0day attacks, was paused last month due to the finding of the big Adobe Reader 0day - it cost me a lot of energy/time, this is a free service:).

So expect some offline of the service.

[EXPMON @EXPMON_]

Correction: Adobe has informed us that they previously made a mistake with the CVSS score and have now corrected it to 8.6. This reflects the fact that the vulnerability is triggered via a local file-opening attack vector. Please note that this does not reduce the urgency of the issue and users should continue to apply the patch as soon as possible in order to prevent potential attacks.

[EXPMON @EXPMON_]

Adobe has confirmed our findings and has issued an emergency security update for all Adobe Reader (and other affected products) users.

https://t.co/2cOeuZ9Gn0

The underlying exploited zero-day vulnerability has been rated Critical (CVSS 9.6) and is tracked as CVE-2026-34621. It appears that Adobe has determined the bug can lead to arbitrary code execution — not just an information leak. This aligns with our findings and those of other security researchers over the last few days.

EXPMON would like to thank Adobe for releasing this emergency security update quickly to help protect users.

UPDATE NOW!

#expmon #zeroday #0day #pdf #adobereader #CVE-2026-34621

[EXPMON @EXPMON_]

"Adobe has advised that the security update should be installed within 72 hours."., from Media coverage:

https://t.co/ibm8Qr2uvk

[Haifei Li @HaifeiLi]

Fun fact about the Adobe Reader 0day: actually, it's the "AdobeCollabSync.exe" ("C:\Program Files\Adobe\Acrobat DC\Acrobat\AdobeCollabSync.exe") process who communicates to the attacker-controller server, not the "Acrobat.exe".

Therefore, if you're hunting the threat with your e.g EDR telemetry, you may want to look at that "AdobeCollabSync.exe" process too.

#threatintel

[Haifei Li @HaifeiLi]

Update: I've just confirmed this (https://t.co/jK7LYKsxjC) is a real variant, it connects to 188.214.34.20:34123.

So it's confirmed that this PDF 0day/APT campaign has been ongoing for at least 5 months!

[Haifei Li @HaifeiLi]

Dear security community/researchers, I'd really like to call to look at this https://t.co/QjEnkm96x9, this information shows that the threat actors behind this Adobe Reader 0day attack was not just collecting local information but was really delivering additional exploits, need more analysis to figure out what the exploit really is. I'm one person and not have enough time to working on all the things..

Another earlier sample found today (https://t.co/TXrTcAPCa5), which appeared on VT on 2025-11-28, shows that this APT campaign has been ongoing for at least 5 months, showing how serious this threat is.

#pdf #zeroday #0day #threatintel #apt

[Haifei Li @HaifeiLi]

Whoa! This does seem to be a variant if you look at the Relations on VT, and this sample appeared on VT since 2025-11-28, (if confirmed) showing how long this advanced zero-day attack campaign has been ongoing!

However, I don't have a VT account, could someone share the sample w/ me or just submit it to https://t.co/NKqtbTEmVW ? Thanks!

https://t.co/IevPWqHypl

[EXPMON @EXPMON_]

** ZERO-DAY ALERT **

EXPMON detected sophisticated zero-day fingerprinting attack targeting Adobe Reader users
https://t.co/y4S09qBw5D

#expmon #zeroday #0day #threatintel #pdf #adobereader #acrobat #cybersecurity

[EXPMON @EXPMON_]

Here is another "0day crash" sample detected by EXPMON that was later found to be non-exploitable (a previous one in WPS Office: https://t.co/NYfNzTkhoJ).

Check out this sample detected in mid-January:
https://t.co/NqX1GXVlfE

This is a highly suspicious crash in LibreOffice Impress, affecting the latest version.

The crash occurs within the "soffice.bin" process (note: not the "soffice.exe" process), as shown in below picture.

Although I noted this detection back in January, I was tied up with other findings (primarily my Office fuzzing project). I later submitted the case to the ZDI program. Their team helped with the triage and confirmed that this is a non-exploitable crash - even though it occurs within a very suspicious "memcpy()" function. I'd like to thank the ZDI researchers for their time and effort in analyzing this bug.

If you are a LibreOffice developer looking to patch this "non-exploitable-but-still-ugly" bug, or a researcher interested in the technical details, you can download the sample here: https://t.co/Olr9tOgQle (password: "infected"). Enjoy!

Yeah, from time to time EXPMON detects various suspicious things even in public samples - not necessarily "0day attacks", but sometimes "0day bugs". :)

#expmon #exploitdetection #threatintel #libreoffice

[EXPMON @EXPMON_]

A "wild" submission on EXPMON!

On January 17, a suspicious RTF sample was submitted to EXPMON (https://t.co/f7wUjd1Or4).

https://t.co/y3ynpaoHpf

While the EXPMON system didn't immediately flag it as "Malicious", it reported multiple highly suspicious Indicators — such as the "suspicious process started from users folder", and the "suspicious process created by main". These Indicators allowed me (and other researchers) to quickly zero in on and investigate the sample.

Upon analysis, I've confirmed that it triggered an unpatched crash on the latest version of WPS Office. Since I found no suspicious payload within the sample, I reported it as a potential vulnerability via the ZDI program. Thanks to the ZDI researchers, it was confirmed last week that the crash is technically non-exploitable. Therefore, I am now disclosing the full details.

The sample is available for download here (password: "infected"): https://t.co/XtFYk5rTza, so other researchers can investigate this interesting crash.

The crash looks like the following attached picture shows.

This case once again demonstrates EXPMON's capabilities — not only in detecting in-the-wild zero-day exploits but also in identifying minor suspicious behaviors from an exploit/vulnerability perspective.

I have also updated the Detection Logic for WPS to ensure immediate reporting when a suspicious WPS application crash is detected. You can view the re-submission of the sample here: https://t.co/eyzACHpOPM.

Some interesting points regarding this submission..

1. This is the first WPS crash that EXPMON detected since EXPMON covered the WPS Office software in January (https://t.co/vMAoPFDOud).

2. This is not a normal sample, but a manmade/crafted one, a crash PoC.

3. While this is probably not exploitable, it still looks ugly (an integer overflow?). If you're the vendor (WPS), you may want to patch it.

4. No idea who submitted this, and EXPMON does not track any submitter information. And, yeah, I noted the string message in the sample.. Anyway, thanks for testing EXPMON, I guess..

#expmon #zeroday #0day #wps #threatintel

[Haifei Li @HaifeiLi]

If you're into WPS Office security research, this might be an interesting sample, submitted by someone couple weeks ago https://t.co/fdQ8jDCKJz. Not saying it's def. an exploit, but it does have an OLESS stream containing maybe some malicious WPS-specific Macros. No time to dig more for me, new to WPS.

#expmon #threatintel

[EXPMON @EXPMON_]

A "wild" submission on EXPMON!

On January 17, a suspicious RTF sample was submitted to EXPMON (https://t.co/f7wUjd1Or4).

https://t.co/y3ynpaoHpf

While the EXPMON system didn't immediately flag it as "Malicious", it reported multiple highly suspicious Indicators — such as the "suspicious process started from users folder", and the "suspicious process created by main". These Indicators allowed me (and other researchers) to quickly zero in on and investigate the sample.

Upon analysis, I've confirmed that it triggered an unpatched crash on the latest version of WPS Office. Since I found no suspicious payload within the sample, I reported it as a potential vulnerability via the ZDI program. Thanks to the ZDI researchers, it was confirmed last week that the crash is technically non-exploitable. Therefore, I am now disclosing the full details.

The sample is available for download here (password: "infected"): https://t.co/XtFYk5rTza, so other researchers can investigate this interesting crash.

The crash looks like the following attached picture shows.

This case once again demonstrates EXPMON's capabilities — not only in detecting in-the-wild zero-day exploits but also in identifying minor suspicious behaviors from an exploit/vulnerability perspective.

I have also updated the Detection Logic for WPS to ensure immediate reporting when a suspicious WPS application crash is detected. You can view the re-submission of the sample here: https://t.co/eyzACHpOPM.

Some interesting points regarding this submission..

1. This is the first WPS crash that EXPMON detected since EXPMON covered the WPS Office software in January (https://t.co/vMAoPFDOud).

2. This is not a normal sample, but a manmade/crafted one, a crash PoC.

3. While this is probably not exploitable, it still looks ugly (an integer overflow?). If you're the vendor (WPS), you may want to patch it.

4. No idea who submitted this, and EXPMON does not track any submitter information. And, yeah, I noted the string message in the sample.. Anyway, thanks for testing EXPMON, I guess..

#expmon #zeroday #0day #wps #threatintel

[Haifei Li @HaifeiLi]

No idea who submitted this* but this is a “zero-day but probably non-exploitable crash” which could be triggered on the latest WPS Office software (which is popular especially in Asia), and there’s a wild message in the sample seems to me (?). Since this is non-exploitable crash and no payload found, full disclosure soon.

https://t.co/EsWNgFtMrV

* EXPMON does not track any information of the submitter, only receive samples.

#expmon #0day #zeroday #wps #exploitdetection

[EXPMON @EXPMON_]

EXPMON has been updated to v20260203!

This is a Detection Logic update, to provide more accurate & deeper decisive Detection Result against the ongoing Microsoft Office zero-day exploits CVE-2026-21509, an improvement of yesterday's v20260202 Detection Logic update.

Now it should give decisive Detection Result even for PoC level exploits. An example is https://t.co/H7A1v41vsL, this is a minimal PoC for this CVE-2026-21509 zero-day vulnerability - now detected & reported.

#expmon #CVE-2026-21509 #office #zeroday #0day #ThreatIntel

[EXPMON @EXPMON_]

EXPMON has been updated to v20260202! This is a Detection Logic update, to provide decisive Detection Result against the ongoing Microsoft Office zero-day exploits CVE-2026-21509.

For example, below are two real, in-the-wild samples of the Office 0day which were just disclosed today:
https://t.co/zheEVSvbl1
https://t.co/09je1OQvra

Previously, these samples were detected only via the Indicators (see https://t.co/KzrhztnfDL). Since this update, they will now be classified/shown as "Malicious - potential exploit CVE-2026-21509", easier for users to identify the threat.

Enjoy the hunting!:)

#expmon #CVE-2026-21509 #office #zeroday #0day #threatintel

[Haifei Li @HaifeiLi]

Someone submitted the real CVE-2026-21509 sample to EXPMON last night!

Check out this submission:
https://t.co/5Cf6TDBQxz

The SHA256 of the sample, it's a RTF file:
c91183175ce77360006f964841eb4048cf37cb82103f2573e262927be4c7607f

While EXPMON didn't report the 0day immediately - this is well expected, it reported various highly suspicious Indicators, including the key Indicator named "activex compatibility shellexplorer registry key accessed". I shared how to use this key Indicator on EXPMON to hunt the 0day just days ago: https://t.co/Qwcvhb6VKa.

That's enough to investigate it manually in your local env, and I have just confirmed this is indeed the CVE-2026-21509 zero-day exploit!

My quick analysis showed that this is the initial attack vector sample in a full attacking chain. Thanks to EXPMON logs, I quickly found that the RTF file was trying to load the IE engine (the "ieframe.dll") while also trying to connect to the threat actor controlled server, one of the url is "\\wellnesscaremed[.]com\davwwwroot\venezia\Favorites\blank.doc" (see the pic attached) - all activities are automatic, meaning as soon as the victim open the Word document, the victim could be pwned. There're not just one but quite serveral OLE objects in the RTF which are, to be honest, quite sophisticated, showing the sophistication of the zero-day attack. Full details haven't been fully understood in such a short time.

The same sample was also listed/confirmed by the Ukrainian CERT https://t.co/PMi6u3r5Wr independently, there're more details in that article please go check out.

What a wild story! Thank you very much to the person who submitted the sample (and I received your message about adding the "unzip" feature:))! Once again it confirmed the effectiveness of the EXPMON system when it comes to detecting unknown 0day exploits.

Quickly, for defenders:
1. Please research all the things starting from the sample, this is the confirmed CVE-2026-21509 0day intinal attack vector sample, and add detections (currently the detection ratio on VT is pretty low) in the full chain.
2. If you're an Microsoft Office user, please apply Microsoft's official patch or workarounds ASAP https://t.co/E6q8y0aZa0, as now the attacking exploit is well known so attacks are expected to increase rapidly.

For me, there's more work to do, including an EXPMON update for determinate detection against this 0day exploits. In the meantime, if you see the "activex compatibility shellexplorer registry key accessed" Indicator on EXPMON, please be cautions because that's likely the 0day sample/variants.

#CVE-2026-21509 #expmon #0day #zeroday #exploit #threatintel

[Haifei Li @HaifeiLi]

Protip for @EXPMON_ : if you have a bunch of suspicious samples to submit, you can use this script to do that https://t.co/alQ3ZW8ZWe, like what I'm doing right now. Zipping them into a .zip & submitting may work too but using the script is cleaner (easy to see each detection).