Will Dormann

I play with vulnerabilities and exploits.
I used to be https://twitter.com/wdormann but Twitter has become unbearable, so here I am.

Public Key

npub12xhpqz0ygq7cy87pcyhpf06tgr0yf37uv9mcnzzqeg00n70tca5q0vzxeq

NIP-05 Address

wdormann_at_infosec.exchange@momostr.pink

Profile Code

nprofile1qqs9rtssp8jyq0vzrlquzts5ha95phjyclwxzauf3pqv58hel84uw6qpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsyhhd2s

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub12xhpqz0ygq7cy87pcyhpf06tgr0yf37uv9mcnzzqeg00n70tca5q0vzxeq

Show more details

Last Notes

2026-05-07 14:53:44 UTC

Let's talk about Windows .URL (InternetShortcut) files.
Last year there was discussion about a vulnerability in how Windows handles .URL files. Specifically, when a .URL file specifies a WorkingDirectory directive, an otherwise harmless app being launched would load DLLs from the remote (e.g. WebDAV) server specified. You know, being the current working directory of the app being launched and all. This vulnerability was being [exploited in the wild](https://www.virustotal.com/gui/file/e0a44274d5eb01a0379894bb59b166c1482a23fede1f0ee05e8bf4f7e4e2fcc6 ), and it worked well because it bypassed annoying (to attackers) things like SmartScreen. Sure, it required the victim to click Open on a dialog saying Type: Unknown File Type (😂), but we all know that users are click-happy, so this is fine. Besides, the file clearly has a .pdf extension, so it should be safe (😂).
Microsoft recognized the vulnerability and published an [update in the form of CVE-2025-33053](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-33053 ).
If we were to believe the [Microsoft documentation at the time](https://web.archive.org/web/20250710095434/https://learn.microsoft.com/en-us/windows/win32/lwef/internet-shortcuts ),
> When the user clicks the icon, the browser is launched and displays the site associated with the shortcut.
But wait...
How did this .URL file cause a program to be launched? The URL= parameter specifies a website address to be loaded in the browser.
Oh, naive child. Obviously a .URL file can directly point to code on a remote (e.g. WebDAV) server. This technique is also [being exploited ITW as well](https://www.virustotal.com/gui/file/93a2d60d1ccfe3e009b1a81951653b559e0cae01c2454244a3a0fbd49a5e4539 ).
I reported this to Microsoft, as this has the **EXACT SAME IMPACT** as CVE-2025-33053. So if that's a vulnerability, then this too is a vulnerability, right?
Bless your innocent soul. Per MSRC:
> When the Shell invokes an app from a remote share, it's expected that you will see the legacy Windows Security prompt, not the SmartScreen one. SmartScreen Application Reputation (AppRep) evaluation applies to locally downloaded files that bear an Internet Zone mark of the web. It is not meant to apply to execution of files from Network Shares.
Okie dokie. I'm sure Windows users surely appreciate this. But what about the [incorrect documentation](https://archive.ph/MgBI8 )? After my prodding, they [updated the wording](https://learn.microsoft.com/en-us/windows/win32/lwef/internet-shortcuts ):
> When the user clicks the icon, the URL path is opened by the handler application, typically the user's default web browser.
Leaving in the quite misleading first sentence:
> The Internet shortcut object is used to create desktop shortcuts to Internet sites.
(An "Internet site" is a web page, right?)
How can CVE-2025-33053 warrant a CVE, while the behavior I described has the exact same trigger and impact is **not** CVE worthy? That's pretty easy. Microsoft assigns CVEs to **updates**, not **vulnerabilities**. They are the decider as to what is a vulnerability and what is not.
What can we do about it?
At the very least, turn off the Windows feature that hides file extensions, **even if you have the option turned on to see file extensions**. The disdain that Microsoft has for Windows users is tangible here. On what planet would I not want to see the actual extension of a file? Go to HKCU\InternetShortcut and delete the NeverShowExt value. After this, your pwned.pdf file will reveal its true self as being pwned.pdf.url.
More powerful protection would be to block the ability to receive .URL files via email, web browsers, etc. There is no workflow that I can imagine that requires a user to double-click on a .URL file that **came from the internet**.
Even more powerful than that would be to disassociate .URL files from opening in Windows (thx @npub1yg8…ccz0 ).
This screen recording is a Windows 11 system that has no internet connectivity. The fact that no warning was displayed that SmartScreen cannot be reached is evidence that SmartScreen is not in play at all. And that dialog...Do you want to open this file?
andType: Unknown File Type
Do you think that users are presented with enough information to make an informed security decision? Of course not. But obviously we all know that we can't rely on users making informed security decisions in general. Don't put users in that position.
https://media.infosec.exchange/infosec.exchange/media_attachments/files/116/533/712/734/034/973/original/7873081a273e8a42.mp4

2026-05-06 13:33:00 UTC

- reply

> This issue > **will be**> fixed in upcoming releases of PAN-OS as captured in the table above.
Sooooooo, exploited ITW I take it?
(Without saying it)

2026-04-19 23:55:05 UTC

The folks at iTerm2 figured out a way to get [arbitrary code execution as the result of cat <file>](https://blog.calif.io/p/mad-bugs-even-cat-readmetxt-is-not ), which is... impressive?
https://media.infosec.exchange/infosec.exchange/media_attachments/files/116/434/067/860/519/298/original/4cb433f6a295d12d.mp4

2026-04-16 02:27:28 UTC

From the same author as [BlueHammer](https://github.com/Nightmare-Eclipse/BlueHammer ) we now have [RedSun](https://github.com/Nightmare-Eclipse/RedSun ).
This works 100% reliably to go from unprivileged user to SYSTEM against Windows 11 and Windows Server with April 2026 updates, as well as Windows 10.
https://media.infosec.exchange/infosec.exchange/media_attachments/files/116/412/016/760/812/126/original/af2cf09911b90b83.png
https://media.infosec.exchange/infosec.exchange/media_attachments/files/116/412/016/764/961/933/original/c70c00109489ea5a.png
https://media.infosec.exchange/infosec.exchange/media_attachments/files/116/412/016/775/721/000/original/3fe5485c2580eca2.png

2026-04-15 13:32:05 UTC

- reply

A path that would make me feel more comfortable would be:
> We've changed the default setting in Signal to not put message bodies in the (external-to-Signal) notifications database. At least until the dust has settled.
But no, the battle that is being chosen is:
We are pleading with Apple to have self-deleting messages not be permanently retained in the notifications database.
I get that security vs. usability are usually at odds with each other. But I suppose I'd like a bit more transparency here.

2026-04-15 11:44:37 UTC

- reply

From a worse place on the interwebs.
Implying:
Signal message content being present in Apple Notifications database even after Signal itself is deleted is apparently expected and fine.
Signal message content being present for **self-deleting** messages is not (in their minds).
🤔
https://media.infosec.exchange/infosec.exchange/media_attachments/files/116/408/541/015/099/359/original/fbc649f7a4c317fa.jpeg

2026-04-15 00:28:00 UTC

- reply

From elsewhere on the interwebs:
https://media.infosec.exchange/infosec.exchange/media_attachments/files/116/405/885/299/611/568/original/a9f8519ee94ab60d.jpeg

2026-04-14 21:19:48 UTC

- reply

Yup. It seems to make the race condition unwinnable.

2026-04-09 22:03:47 UTC

There is at least one Adobe Reader 0day being exploited in the wild:
https://justhaifei1.blogspot.com/2026/04/expmon-detected-sophisticated-zero-day-adobe-reader.html
TL;DR: One 0day is being used to simply communicate details to a C2 server to get further commands. Specifically, there is a vulnerability that allows reading arbitrary local files using Reader JavaScript. In this case, ntdll.dll and friends, so that the C2 knows specifically what version of Windows the victim is running.
Nobody knows what secondary payload the C2 is delivering to selected targets. But it's a direct pipeline to allow the C2 to run arbitrary JavaScript on the victim system.
So I'll bet dollars to donuts that there is a **second** more powerful vulnerability that the attackers have up their sleeves. Or at the very least, the same vulnerability that allows the privileged file read might be able to be leveraged to do something nasty. And the whole AES-encrypted C2 stuff is merely to not put the payload statically in the exploit PDF, allowing a dynamic payload for any given target.

2026-04-09 19:44:08 UTC

- reply

On the macOS side of things, we have [confirmation that Signal notification contents get stored, even for disappearing messages](https://objective-see.org/blog/blog_0x2E.html )
iOS sadly offers less visibility into what's going on. But the FBI probably appreciates that it's happening there too.
The default notification setting for Signal (on both iOS and macOS) ensures that potentially sensitive information leaks out of the Signal app. This is unfortunate.

2026-04-09 15:50:26 UTC

- reply

Can we get a comment on this?
1) The default Signal setting to show message contents in push notifications seems... bad, assuming this article is accurate.
2) Does changing the in-Signal-app setting for Notification Content indeed prevent notifications from being stored **anywhere**, which by default contains incoming message **bodies**.

2026-04-09 14:56:37 UTC

Let me get this straight...
The **default setting** for Signal on an iPhone allows law enforcement to see the content of all incoming messages, even after the app has been deleted? 🤔
https://www.404media.co/fbi-extracts-suspects-deleted-signal-messages-saved-in-iphone-notification-database-2/
https://media.infosec.exchange/infosec.exchange/media_attachments/files/116/375/318/988/912/395/original/cd2e38defe89c4af.jpeg
https://media.infosec.exchange/infosec.exchange/media_attachments/files/116/375/319/484/821/201/original/fe0e2e85e6dc2ef5.jpeg

2026-04-08 18:38:17 UTC

- reply

Yeah, that's good.
My spice collection is in every possible container that exists, so no fixing that. 😂
https://media.infosec.exchange/infosec.exchange/media_attachments/files/116/370/536/400/007/455/original/6f0cfe7c628b6733.jpeg

2026-04-08 18:21:27 UTC

- reply

That's nice, but any time I see spice organization like this, I can't help but think: "all original containers prematurely go into a landfill, for reasons."
😂

2026-04-08 03:27:51 UTC

- reply

It's kind of neat. And slightly complex.
But essentially the consequences of pissing off security researchers wanting to do the right thing.

2026-04-08 03:23:38 UTC

- reply

I didn't make the exploit. I merely looked at it after it was published. Now that I'm allowed to talk infosec publicly again.
I also shared my thoughts about what it's like to work with MSRC these days. 😂

2026-04-06 13:46:04 UTC

There's a new Windows 0day LPE that has been disclosed called [BlueHammer](https://github.com/Nightmare-Eclipse/BlueHammer ). The reporter [suggests](https://deadeclipse666.blogspot.com/2026/04/public-disclosure.html ) that it's being disclosed due to how MSRC operates these days.
MSRC used to be quite excellent to work with.
But to save money Microsoft fired the skilled people, leaving flowchart followers.
I wouldn't be surprised if Microsoft closed the case after the reporter refused to submit a video of the exploit, since that's apparently an MSRC requirement now. 😂
Anyway, yeah, it works. Maybe not 100% reliably, but well enough...
https://media.infosec.exchange/infosec.exchange/media_attachments/files/116/358/058/162/383/747/original/7d522a2d40cec255.png

2026-04-03 18:00:06 UTC

Dear Linux UI people:
If you want to round corners, cool.
**However**, if you do round corners, maybe **just maybe** move the point where the cursor is activated to where the corner actually **is** after rounding. Not where it **would have been** if you didn't do the rounding. 🤷‍♂️
https://media.infosec.exchange/infosec.exchange/media_attachments/files/116/342/075/188/455/221/original/a10c931f6c0fa0ca.mp4

2026-04-02 19:42:03 UTC

I've always known that I'm **terrible** at using websites (I never know where to click). But I guess I've recently realized that this applies to apps as well.
Today's case: Paragon Hard Disk Manager.
My goal: Mount a backup as a drive letter.
After multiple rounds with support, I convinced them to indicate on a screenshot exactly where it is that I should click.
I get that I'm possibly being obtuse, but I have **NEVER** in my computing years been drawn to click on a thin **DOTTED LINE** part of an arrow with the expectation of it doing something.
And no, there was no mouse hover indication that the line had special meaning.
https://media.infosec.exchange/infosec.exchange/media_attachments/files/116/336/792/652/990/016/original/5582a453244ee4d1.png
https://media.infosec.exchange/infosec.exchange/media_attachments/files/116/336/793/168/296/379/original/df302add1b68d9ba.png
https://media.infosec.exchange/infosec.exchange/media_attachments/files/116/336/801/859/576/328/original/0141f4e9822fc698.png

2026-03-20 15:08:06 UTC

Call me crazy, but there are times when I think that ChatGPT sprinkling in knowledge about what I normally ask is... **not** useful.
This is from a question I asked about grease.
https://media.infosec.exchange/infosec.exchange/media_attachments/files/116/262/125/391/332/770/original/49ed8ad5a126090f.png

2026-03-09 23:00:37 UTC

My local hardware store just installed a vending machine out front of it, in case you need things when they're closed.
I love it.
https://media.infosec.exchange/infosec.exchange/media_attachments/files/116/201/699/300/335/899/original/9c33a05602a61b0b.jpeg

2026-03-09 03:19:57 UTC

I already knew that we use nonsense measurement systems here in the US. But only recently did I realize that a US gallon is different than a UK gallon.
https://media.infosec.exchange/infosec.exchange/media_attachments/files/116/197/055/752/673/643/original/9e6c3c630064a3aa.mp4

2026-02-15 18:28:07 UTC

Ars Technica [retracted an article](https://arstechnica.com/ai/2026/02/after-a-routine-code-rejection-an-ai-agent-published-a-hit-piece-on-someone-by-name/ ) about how AI is making the world worse because...
**the Ars article itself** contained AI-generated quotes in it.
https://arstechnica.com/staff/2026/02/editors-note-retraction-of-article-containing-fabricated-quotations/
Welp, we had a decent run, folks. But it's time to call it.
https://media.infosec.exchange/infosec.exchange/media_attachments/files/116/076/049/706/592/161/original/a20b3659e47f7476.png

2026-01-23 19:29:49 UTC

When you get a screenshot of an individual window in Windows, using either Alt + PrtScn or the fancy new Snipping Tool, you also capture the contents of whatever is **behind** the window around the edges.
Linux doesn't do this.
macOS doesn't do this.
Just Windows.
Why are expectations for how Windows works so low?
Or has Microsoft crafted a world where they are not required to care?
https://media.infosec.exchange/infosec.exchange/media_attachments/files/115/946/059/945/899/333/original/827cd84b29ab8788.png
https://media.infosec.exchange/infosec.exchange/media_attachments/files/115/946/062/007/795/294/original/c57f226b386b39bd.png

2025-12-31 14:43:11 UTC

I recently bought something from poshmark.com, for the first time. While I haven't heard of them before, I figure with credit card protections as they are in the US, there's really no harm with giving it a shot.
Within about **30 minutes** of placing my order, I got a not-very-good phishing email from purchase-orders@loyverse[.]com, claiming to be "Poshmark".
The first time in my life that I've received a phish from somebody claiming to be Poshmark.
My wonders at this point:<li>Is Poshmark unknowingly leaking the email addresses of people who purchase through their site?</li><li>Is Poshmark knowingly leaking the email addresses of people who purchase through their site? Sub-wonder: If true, is this publicly known?</li><li>Is the person whose Poshmark listing I purchased from either compromised or malicious?🤔</li>

2025-12-27 13:56:26 UTC

- reply

Surely you can come up with a higher contrast font color scheme for your articles?
Safari on iPhone here.
https://media.infosec.exchange/infosec.exchange/media_attachments/files/115/791/871/445/397/841/original/dc15a7ea92019411.jpeg

2025-10-30 15:12:46 UTC

Microsoft:
> As much as 30% of the company's code is written by AI.
Also Microsoft:
Somehow we managed to make it so that [clicking the x in Task Manager doesn't close the app](https://www.windowslatest.com/2025/10/30/windows-11-kb5067036-issue-task-manager-wont-close-and-duplicates-may-hurt-performance/ ). Whoopsie daisy!
https://media.infosec.exchange/infosec.exchange/media_attachments/files/115/463/758/861/236/645/original/2fff515a1fda37bf.png

2025-10-28 18:48:14 UTC

I've noticed that Gmail is letting a pattern of spam messages through lately (maybe the past month or two?).
With the subject line of Delivery Status Notification (Failure) and then just a junk email body.
Just me? Is using a subject line of Delivery Status Notification (Failure) really all it takes to get past Gmail's spam filtering?
https://media.infosec.exchange/infosec.exchange/media_attachments/files/115/453/279/983/177/054/original/b0a6dc6f7a7cb502.png

2025-10-25 22:08:09 UTC

TIL that I can take the part of my post-sauce tomatoes that I'd otherwise throw away (the skins), throw them in a spice grinder, and you get delicious tomato powder!mindblown.gif
https://media.infosec.exchange/infosec.exchange/media_attachments/files/115/437/080/249/765/993/original/0172c1fa588119e8.jpeg

2025-10-22 13:32:47 UTC

- reply

I initially had it at 60 and got the error.
So I took their suggestion of setting it to 59. 😂

2025-10-22 13:22:31 UTC

Never change, Linux.
https://media.infosec.exchange/infosec.exchange/media_attachments/files/115/418/026/377/254/515/original/c3defadb4ae6a24f.png

2025-10-17 13:34:08 UTC

Do you or somebody you know have a Windows 10 that isn't fit for a Windows 11 upgrade? (e.g. no TPM)<li>Get a Windows 11 25H2 ISO</li><li>Run <code>setup /product server</code></li>
Enjoy your Windows 11 with no coerced Microsoft Account, TPM features, etc.
https://media.infosec.exchange/infosec.exchange/media_attachments/files/115/389/760/139/297/698/original/a40929b810a7a5bd.png
https://media.infosec.exchange/infosec.exchange/media_attachments/files/115/389/760/525/928/238/original/359b7ab0e60c9842.png

2025-10-08 17:19:29 UTC

- reply

Three clicks is a lot to expect, I suppose.

2025-10-08 14:52:07 UTC

For some reason, people seem to be spun up about recent changes that allegedly force people to create Microsoft accounts during Windows 11 setup.
Except, nothing is being forced.
Windows 11 Pro or better:
Just do the usual:<li>Set up for work or school</li><li>Sign-in options</li><li>Domain join instead</li><li>Create local account.</li>
Windows 11 Home:
Ok, fine. Microsoft has indeed removed the OOBE.CMD batch file. But you know what? You can run the command that a batch file runs without the batch file itself?reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\OOBE /v BypassNRO /t REG_DWORD /d 1 /f
Once you reboot, you'll have the I don't have internet link, where you can create a local account.
https://media.infosec.exchange/infosec.exchange/media_attachments/files/115/339/098/324/820/507/original/0c702edb7cf88c97.png
https://media.infosec.exchange/infosec.exchange/media_attachments/files/115/339/098/336/907/693/original/73f8d637c48da2ec.png
https://media.infosec.exchange/infosec.exchange/media_attachments/files/115/339/098/349/572/219/original/643e0ae19d349b4f.png
https://media.infosec.exchange/infosec.exchange/media_attachments/files/115/339/099/231/060/018/original/d0c84dbe5a016502.png

2025-08-25 22:23:20 UTC

I approve.
https://media.infosec.exchange/infosec.exchange/media_attachments/files/115/091/740/267/819/777/original/f82a022d7dde9742.jpeg

2025-05-24 14:13:14 UTC

- reply

I leave for vacation a week ago with Twitter down, and as I return it's (still/again/🤷‍♂️) down.
Great job, folks!
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/563/217/651/895/953/original/1a241080547799f3.png

2025-05-17 13:21:34 UTC

Please don't bother coming back.
KTHXBYE
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/523/377/317/595/933/original/b792df1bd59374e2.png

2025-05-13 17:35:27 UTC

Ooh, another of my NTFS vulnerabilities that I reported **years** ago was patched today. 🎉
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-32707
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/501/728/289/047/593/original/127d5aa8905234a9.png

2025-05-13 15:21:40 UTC

I'm at a meeting hosted by somebody else where they're using Microsoft Teams, and in the chat I attempted to share an image that is on my laptop. By clicking the + button and Attach file.
The result of doing this is that Teams puts the image in **MY COMPANY'S SHAREPOINT SERVER**, and nobody else in Teams can see the image because they **DON'T HAVE AN ACCOUNT** on my company's SharePoint server. 🤦‍♂️
Wonders:
1) Has anybody at Microsoft actually tried **using** Teams?
2) Why do people **choose** to use Teams?
Aside: If you copy an image and press Cmd - V to put the image in the chat, Teams actually... puts the image in the chat.
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/501/201/358/592/222/original/03cbbcbea6ab57d9.png

2025-05-12 17:42:07 UTC

It's fruit update time.
https://support.apple.com/en-us/100100
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/496/091/652/470/910/original/31285c09c3d0fc9c.png

2025-05-09 13:36:55 UTC

- reply

You've got this.
And a tomato is a perfect example of a thing that is night and day when it comes to grocery store vs garden. 🎉

2025-05-09 13:32:34 UTC

- reply

Here are my notes from last season:
https://docs.google.com/document/d/1tOnZuUFsUPCxhaD-cgmQ6h8asci15UATkz7ul6MYad8/edit?usp=drivesdk
Tomato-specific I'd say to get some of the blossom rot stop spray. It's magic. While egg shells sounds like a good idea, I'm not convinced that it does a thing, since calcium isn't water soluble. (Tomatoes will get soft black spots on the blossom side if they don't have enough calcium while growing)
And if you really want to be in touch with the garden, get a soil test kit with those powder capsules. When it comes to the nutrients and pH, you'd never be able to tell with your eyes.
But in the end, it's just dirt + water + sun + seeds. How much you put into it is up to you. Nature will take care of the rest. But you **will** get a better bounty with more effort spent. Guaranteed. 😀

2025-05-09 13:16:35 UTC

- reply

Specifically, out of three seedlings that successfully germinated, each of them look exactly like this one. All of their plant friends who received the same treatment are fine.
Bad batch of seeds maybe?
/me lifts his skinny fists like antennas to heaven

2025-05-09 13:12:04 UTC

Last year: Not a single one of my Blue Beech tomato seedlings survived.
This year:
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/478/041/040/737/214/original/32a57f757a3bfe20.jpeg

2025-05-09 13:03:39 UTC

- reply

TBH, I've never really fully grok'd what Tamper Protection actually does.
Here's a PoC of a bypass that I found a long time ago. 🤷‍♂️
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/478/007/440/392/968/original/729ad9588b5ff4c3.mp4

2025-05-09 01:01:19 UTC

- reply

No, Tamper Protection does nothing to stop this.
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/475/168/930/570/810/original/2600e081f6982feb.mp4

2025-05-08 20:08:29 UTC

Neat way to disable Windows Defender (or possibly other AV products)...
Register a no-op AV product in the Windows Security Center (WSC). This action is protected by an NDA that AV vendors sign, and, well...
Anyway, yeah, admin users can do admin things. Don't forget that.
https://github.com/es3n1n/defendnot
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/474/016/191/416/836/original/c1cc0ab02f3454bc.png

2025-05-07 04:37:11 UTC

- reply

I'll admit that even with the [updated explicit instructions on how to get Commvault updates](https://documentation.commvault.com/11.38/essential/downloading_software_on_demand.html ), I fail to see how one can get these mythical SP38-CU25-434 and SP38-CU25-438 optional updates.
When I first go to "Download or copy software", Commvault tells me that I'm Up-to-date
If I **manually** force a download of Latest Fixes for Current Release: 11.38.25, I get an installer that specifies:<code>[Image Information] Version=11.80.380.0 ServicePack=38 SPTranID=6988515 UnixTime=1732240991 RevisionNumber=1352 Tip=1 ReducedMedia=1 </code>
And if I run this installer and even reboot for good measure, the system is still vulnerable. And the jar that contains the vulnerable code, cv-ac-common.jar has not changed from my original 11.38.25 vulnerable system.
I'm not particularly good with computers, so hopefully Commvault sysadmins in the real world are better at this than I am. But I'll admit that even with explicit instructions, I have no idea how to get the updates that protect me against CVE-2025-34028.🤷‍♂️
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/464/625/502/384/086/original/45466ea5816f3fef.png
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/464/626/098/201/251/original/1e08cf8bfc350eb5.png

2025-05-07 03:35:35 UTC

- reply

Oh, wow.
Only after pestering the Commvault PSIRT did they update the language of their advisory.
While it **still** incorrectly says that 11.38.0 - 11.38.19 are affected and that 11.38.20 is resolved (it is not), the've added a section below this misinformation to convey the actual state of the world:
11.38.20 is only patched if it has the SP38-CU20-433 **and** SP38-CU20-436 **additional** updates installed.
And 11.38.25 is only patched if it has the SP38-CU25-434 **and** SP38-CU25-438 **additional** updates installed.
I cannot think of a behavior that is more vindictive to their customers to botch language in an advisory so bad, and **also** to not bother bumping release versions for the fixes for a CVSS 10 EITW vulnerability. 🤦‍♂️
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/464/450/506/092/601/original/f3c0de7a8753837f.png
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/464/451/116/329/288/original/814b4ab3c55bf412.png

2025-05-06 04:06:49 UTC

- reply

Now that I have a local copy of the Commvault VM so that I don't burn truckloads of Azure dollars, I can look at things at my leisure.
**AND**, it seems that the VM that I have is 11.38.25, which contains the fix for CVE-2025-34028.
**EXCEPT** the exploit for CVE-2025-34028 still works against it. 🤦‍♂️
Commvault claims that 11.38.20 **and** 11.38.25 fixes the watchTowr-reported CVE-2025-34028 vulnerability. (Aside: How is it even possible that **two** different versions in the same product line are the ones that fix a single vulnerability?) watchTowr [discovered the bug in 11.38.20](https://labs.watchtowr.com/fire-in-the-hole-were-breaching-the-vault-commvault-remote-code-execution-cve-2025-34028/ ).
I trust watchTowr, so I don't believe Commvault's statement that 11.38.20 fixes the vulnerability that watchTowr found in 11.38.20.
I also trust the PoC that I just ran against 11.38.25, so I don't believe Commvault's statement that 11.38.25 fixes the vulnerability that watchTowr found in 11.38.20.
Yes, I have trust issues. 😕
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/458/901/003/124/252/original/4d7dcf947b77b06c.png
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/458/903/072/597/218/original/bc949823bc70c827.png
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/458/905/102/553/591/original/8249341a63d86457.png

2025-05-01 18:55:42 UTC

- reply

After successfully touching grass and beginning to write up CVE-2025-34028...
CVE-2025-34028 is a path traversal vulnerability. And yes, the path traversal allows for an unauthenticated attacker to plant files in arbitrary locations. And presumably Commvault has fixed the path traversal part.
**BUT**, what about the fact that deployCCPackage() is reachable **by design** (by way of deployServiceCommcell.do being explicitly listed in authSkipRules.xml)?
Directory traversal aside, in what world does the ability for an unauthenticated client to deploy a Command Center package make sense, whatever that means? 🤔

2025-05-01 14:52:34 UTC

- reply

Thanks.
Yes, you can still RDP in with the old password after the account has been switched to passwordless. No Microsoft Authenticator required.
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/433/133/528/491/341/original/085a25003a5ee86b.png
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/433/137/940/672/639/original/69b69794726d790b.png

2025-05-01 12:39:57 UTC

- reply

Not sure what you mean...
My hotmail account **is** passwordless? (Locally it uses a PIN)
Unless you're talking about something else?

2025-04-30 23:07:53 UTC

- reply

In my case:
Windows 11 Enterprise with a local account initially (via BYPASSNRO)
I added a Microsoft (hotmail.com) account.
I then turned on RDP.
That's all. Absolutely nothing else.
If I log in via that hotmail account to RDP, it will accept the original cached password even if I change my hotmail account password.
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/429/420/945/735/068/original/f090a15060e8ba01.png
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/429/422/475/304/248/original/6caffd399e4feb41.png

2025-04-30 23:01:40 UTC

- reply

Hm, that all sounds different than what I tested.

2025-04-30 22:11:06 UTC

- reply

Really? I found it quite easy:
1) log in to windows with a Microsoft account
2) Turn on RDP
🤷‍♂️

2025-04-30 19:58:12 UTC

- reply

Yeah, I didn't have a local AD ready to test.
But I could definitely see a difference with authenticating RDP using a local account vs. an online account.
With local accounts, the instant the password changes, the RDP client needs the new password.
For online accounts, the old password still works, indefinitely.

2025-04-30 19:36:04 UTC

- reply

I've seen no evidence that the RDP cred cache gets updated ever.
Granted, I only started looking at this very recently, but the reporter seems to indicate that this is the case.

2025-04-29 12:49:13 UTC

Google published a [blog post about 0days and the like](https://cloud.google.com/blog/topics/threat-intelligence/2024-zero-day-trends ). This jumped out at me:
> Vendor investments in exploit mitigations are having a clear impact on where threat actors are able to find success.
Stack canaries gained popularity in the Linux world in 2002. When did the Linux-based Ivanti ICS product get stack canaries, after years of ITW exploitation? 2025. That's right. They decided to wait **TWENTY THREE YEARS** before deciding to turn on a compile-time flag that would have prevented successful exploitation of April's CVE-2025-22457.
We all know that comparing the security disposition of companies/products based on CVE counts is both foolish and futile, but sometimes they make it easy for us. 😂

2025-04-24 17:11:09 UTC

- reply

Oh, what's that?'NICIPConfigUpdateDeployment-1745511600265' is not valid
?
Oh, let me put my Azure translation hat on. Ok, got it:
> You have exceeded your limit of 10 publicly available IP addresses. Please > **first**> Disassociate> the IP address and > **then**> delete it. Otherwise you will get another error message.
Boy, this hat is useful.
Just kidding. There's no such hat.
You need to trudge through things until you brute-force figure things out.
Time to go touch grass...
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/394/045/439/163/623/original/30076432cca1f602.png

2025-04-24 16:25:39 UTC

- reply

What's that?
The "Most used by Azure users" VM type that I picked isn't available?
You know what, instead of Go Fish, maybe tell me what I can use?
**Edit**: Azure Spot pricing apparently isn't a thing. No matter which Size + Region combination you choose, you'll get an error that says that the combo isn't available where you want it. 🤦‍♂️
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/393/820/926/795/345/original/5559760f76334056.png
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/393/821/371/981/644/original/c122cb0b6873f44a.png

2025-04-24 16:12:39 UTC

- reply

What's that? I need to remove the number of data disks in my VM? Maybe tell me how to do this?
**Ohhhh**... You've selected an Azure VM image that requires more than 4 disks, and the VM type currently selected has only 4 disks? I'm no UI/UX expert, but maybe just **TELL ME THIS**?
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/393/791/242/538/845/original/68441ab2dff3f3c5.png

2025-04-24 16:02:55 UTC

If you create an ARM VM in Azure, beware that your "Recently used size" will be ARM, and as such you will not be able to create any preconfigured x64 VMs.
Because of course if your "Recently used size" is ARM, Microsoft will disable the ability to pick an x64 size. 🤦‍♂️
Yes, I had to create a sacrificial x84 VM in Azure to work around this. Once my recently used size was x64, I was able to pick any size that I wanted.
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/393/660/047/299/710/original/b8c83e056a7bd900.png
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/393/660/464/816/983/original/b2b5148efbc9de3f.png

2025-04-17 13:50:30 UTC

- reply

From over at the Bad Site ™
Both the vulnerability and the "fix" for CVE-2025-21204 are quite silly.
The scenario is:<li>Non-admin user creates <code>C:\inetpub\wwwroot</code> directory and puts web content there</li><li>Admin user at some point in the future enables IIS on the system.</li>
The outcome is:
The web content provided by the non-admin user (be it a web shell or whatnot) is served up by IIS.
Maybe non-admin users shouldn't be able to make directories or junctions (to directories or files) in C:\?
NAH.
Maybe installing IIS should provide a clean webroot when it's installed?
NAH.
Just preemptively make a C:\inetpub directory that non-admin users can't write to. That fixes the problem. 🤦‍♂️
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/353/620/324/754/138/original/fcf2349753b50d90.png

2025-04-16 20:11:46 UTC

Get your Apple updates folks.
https://support.apple.com/en-us/100100
CVE-2025-31200 and CVE-2025-31201 are being exploited ITW.
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/349/460/193/856/875/original/192ef3c5baac44a7.png

2025-04-16 02:39:59 UTC

Microsoft blocks ActiveX by default in Microsoft 365, Office 2024
https://www.bleepingcomputer.com/news/microsoft/microsoft-blocks-activex-by-default-in-microsoft-365-office-2024/
About damn time!
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/345/323/808/365/253/original/5298a4f71037e0f1.jpeg

2025-04-14 11:31:51 UTC

- reply

If I remember my testing properly, a junction to a folder does not break the update. But a weird junction to a file (which Microsoft claims is not possible) does break the April update.
Which mirrors the test that a C:\inetpub directory does not break the update but a C:\inetpub file **does** break things. Except that the junction variant is something a non-admin user can do.

2025-04-11 12:29:27 UTC

- reply

Would changing the ACLs to not allow non-admin users the ability to create directories off of C:\ **really** have a real-world impact of limiting LPEs?
Absolutely. When you write a tool to look for things (e.g. [Crassus](https://github.com/vu-ls/crassus )), you see things. Heck, I've seen a privileged service attempt to open files in C:\Program%20Files\, which any non-admin Windows user can create by default.
But no, even despite being presented with evidence for how this could fix an entire **CLASS** of LPEs on Windows, MSRC was not interested.
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/319/328/558/499/280/original/9f375a596e6be1fe.png
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/319/328/591/059/828/original/be09298e7e7ce5a8.png
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/319/328/622/114/978/original/142b3c0de51b5c9b.png
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/319/328/635/901/976/original/e1f0e54c4a14ddad.png

2025-04-11 12:20:56 UTC

- reply

Hilarious.
The two things that MSRC seems to aim to to achieve are:<li>Avoid saying anything about what their security updates do unless their hand is forced.</li><li>Take the path of "least resistance" as opposed to fixing the root cause of problems. (In this case, non-admins can create subdirectories directly off of <code>C:\</code>)</li>
https://infosec.exchange/@wdormann/114319281111054638

2025-04-11 12:16:36 UTC

- reply

So, apparently this is the "fix" for [CVE-2025-21204](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-21204 ). Microsoft recently updated their advisory to say what the update does.
Prior to everybody freaking out, the advisory for CVE-2025-21204 said nothing about what it does.
Two gripes:<li>MSRC publishing content-free advisories has consequences, but they never seem to appreciate this.</li><li>I told MSRC YEARS AGO that they can avoid an entire class of LPE vulnerabilities in 3rd-party software and their own software by not allowing non-admin users to be able to create directories off of <code>C:\</code>. They refused to make any change because it might "break things".</li>
Great job, folks.
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/319/275/744/743/060/original/dfdb200d561b058f.png
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/319/276/345/443/373/original/42bf117e3da87c7a.png

2025-04-10 20:26:26 UTC

- reply

Ah, you'd think that you couldn't.
But indeed you can!
That is, a non-admin user can create a "directory" junction to a **file** target, which will have the result of April's security updates failing to install. 😂
It seems that this weird concept of a junction to a file achieves an unexpected double-standard:<li>It counts as a directory when it comes to NTFS ACLs (a non-admin user can create a junction in <code>C:\</code>)</li><li>Depending on how the junction is accessed, it might count as a file as opposed to being treated as a directory.</li>
This seems like a problem. Obviously in the case of April's updates here. But perhaps even more generically in that a junction to a file target seems to almost guarantee unexpected behavior.
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/315/468/118/374/963/original/117737951bd66c59.png
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/315/468/098/079/634/original/231bb5eedc25ad85.png
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/315/494/751/134/719/original/1f3da3b5b4a3c3d9.png
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/315/468/576/264/239/original/637c727e33bcbaa2.png

2025-04-10 19:58:07 UTC

- reply

Just to be clear, while mklink /h can itself be used by a non-admin user, that same non-admin user would not be able to create a hard link in C:\ as that would be the same as creating a file there. Which non-admin users can't do.

2025-04-10 19:35:25 UTC

- reply

You can?
Non-admin users don't have SeCreateSymbolicLinkPrivilege, so I don't believe you. 😀
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/315/339/916/620/405/original/0ac365f918db7466.png

2025-04-10 19:28:04 UTC

- reply

Ah, that'd do it!
But at the same time, creating files in the root directory requires admin privileges.
And if you're a trigger-happy admin, there are plenty of footguns that you can use. 🤷‍♂️
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/315/306/010/556/017/original/4edcd62c718580ca.png
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/315/312/018/694/860/original/c76890f4e4d646cb.png

2025-04-10 18:32:52 UTC

- reply

Specifically, I've seen all April updates install even when C:\inetpub exists ahead of time.
I should have known better than to attribute the correlation of C:\inetpub in a VM before updates to the causation of a failed update.
What happens with C:\inetpub is tough to see, as it either happens before the Procmon boot driver loads, or Procmon is otherwise foiled by the updates occurring. But either way, there's a bit of a blind spot between pre-reboot C:\inetpub not being there and it being there post-reboot. A Procmon boot log sees nothing. 😕
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/315/085/369/818/791/original/2e70f29df7d7ed13.png
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/315/096/002/788/236/original/c73ec6e4493404ac.png

2025-04-10 15:37:32 UTC

- reply

If IIS is truly installed, KB5057589 installs fine.
Presumably the failed installation is due to unexpected permissions on C:\inetpub?

2025-04-10 14:17:31 UTC

- reply

Yeah, so this is interesting. I was skeptical, but I can confirm that [KB5057589](https://support.microsoft.com/en-us/topic/kb5057589-windows-recovery-environment-update-for-windows-10-version-21h2-and-22h2-april-8-2025-74bc2baa-4ac6-40d0-8dde-4a8462b8f7e7 ) (which installs [KB5055674](https://support.microsoft.com/en-us/topic/kb5055674-safe-os-dynamic-update-for-windows-10-version-21h2-and-22h2-april-8-2025-bccc4714-2dca-4d07-be7b-1f38d9eb3e5b )) for Windows 10 will fail to install if there is a C:\inetpub directory present ahead of time, which a non-admin user can fulfill.
I wouldn't expect the update to be so fragile that the mere presence of a C:\inetpub directory prevents its installation. While KB5057589 is indeed listed as a "Security Update", I can find no information of what CVE(s) it fixes. 🤔
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/314/084/290/005/673/original/1046fbf3d5631702.png
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/314/084/912/020/799/original/ada09b9ca13f641b.png
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/314/085/867/522/689/original/e8d5cf1eaac1fb90.png

2025-04-09 16:05:41 UTC

After installing April's updates, Windows 10 and 11 systems now have an empty C:\inetpub directory.
This seems... unexpected?
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/308/855/978/617/969/original/add7da11cee02475.png

2025-04-09 15:09:07 UTC

Vulnerability thoughts:<li>Most attacks these days rely on chains of vulnerabilities.</li><li>Things that get CVSS scores are almost exclusively CVEs, which are individual vulnerabilities.</li>
It's the vulnerability chains that matter, but the numbers that people are looking at are the individual vulnerability "links". And as a result, we ironically benefit by people **not** following the rules and assigning a CVSS for the whole chain to an individual link. Case in point:
https://infosec.exchange/@wdormann/114275453831928356
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/308/629/954/933/414/original/6216600d2af4e4d9.png

2025-04-05 12:59:21 UTC

- reply

Yeah, the funny/scary thing about all of this is that these recent cases were all based on "we saw that the device was compromised by the failed ICT test"
That right there is evidence that the attacker was **SO BAD** that they didn't even bother to **hide their tracks**. Imagine what the good ones are up to. 😂
Yes, the same thing could be said for any attack, but the Ivanti case is somewhat special based on how trivial it is to subvert both the external ICT and also the factory reset process.

2025-04-04 18:57:16 UTC

- reply

I mean, this would be discoverable with the dumbest of dumb HTTP fuzzing.
You'd need to know **absolutely nothing** about the target app or what it expects.

2025-04-04 14:25:25 UTC

- reply

And [per the excellent folks at watchTowr](https://labs.watchtowr.com/is-the-sofistication-in-the-room-with-us-x-forwarded-for-and-ivanti-connect-secure-cve-2025-22457/ ), we can see what the vulnerability is:
A stack buffer overflow in X-Forwarded-For
No need to find a specific endpoint or do something clever. Simply make a web request to **anywhere** on an ICS system with a large X-Forwarded-For HTTP header and you'll get a stack buffer overflow on the system. 🤦‍♂️
And due to the fact that the Ivanti web server does a fork() without a corresponding exec(), we get the same memory layout every single time.
Now, about Ivanti's use of remediated... The function where the overflow happens just happens to have been rewritten in a way that avoids the overflow.
Did Ivanti recognize the possibility of a stack buffer overflow and not recognize it as a security issue? Or did they just happen to change code to accidentally avoid the overflow (and decide to use exploit mitigations as well).
You decide...
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/280/140/413/280/971/original/0ad30e70a74288ae.png
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/280/141/105/205/085/original/68fe07f0072d0c64.png
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/280/192/527/118/331/original/44446d921b84ffc5.png
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/280/146/260/123/934/original/dccbbd6e0aa12435.png

2025-04-04 12:10:51 UTC

- reply

There's this magical thinking that the CVE ID is what gives attackers the ability to compromise systems.
If you say that your software is vulnerable but fail to assign CVEs, you're only helping the **attackers**.
I remember the time that Microsoft got mad at me for "leaking" one of their CVEs to the public before the update was available. As in their world, CVE IDs were for Microsoft updates. Not for identifying vulnerabilities. 🤦‍♂️
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/279/610/521/759/845/original/8f190a43dddeb82b.jpeg
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/279/610/521/686/617/original/6d2aabcc66a7daea.jpeg

2025-04-04 11:58:06 UTC

- reply

Apparently the CVE system is for bickering. 🤷‍♂️
https://www.securityweek.com/details-emerge-on-cve-controversy-around-exploited-crushftp-vulnerability/
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/279/568/311/468/701/original/c44506e0803e839c.jpeg

2025-04-03 18:57:08 UTC

- reply

Now, regarding the "silent fix" of CVE-2025-22457, which per Ivanti:
> This vulnerability has been remediated in Ivanti Connect Secure 22.7R2.6 (released February 11, 2025)
That word remediated...
Careful readers will see that Ivanti didn't **fix** the vulnerability in 22.7R2.6.
What changed in 22.7R2.6? With this version, Ivanti compiled **some** of the ICS binaries with exploit mitigations that have been around for 20 years. And wouldn't you know it, it paid off already? Everybody's gotta learn sometime...
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/275/552/878/380/322/original/545a16fc157c657d.png
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/275/562/489/795/107/original/21b3dd2357824bab.png

2025-04-03 18:30:45 UTC

- reply

Given that the web server on an ICS runs as the limited nr user, both the Ivanti and the Mandiant advisory are missing any indication whatsoever how the threat actors are gaining root privileges.
I've reported 4 different ICS LPEs to Ivanti recently, but none of them have been fixed yet.
Back in the CVE-2025-0282 days, Ivanti made up a CVE-2025-0283 CVE to capture the LPE aspect of attacks happening in the wild. I say "made up" because I've seen no evidence whatsoever that any LPE was fixed between 22.7R2.5 and 22.7R2.6.
Knowing what's going on in an ICS device is a huge blind spot, but apparently seeing how attackers are LPE'ing is even blind-er.

2025-04-03 18:06:02 UTC

Ivanti CVE-2025-22457 is being exploited ITW.
https://forums.ivanti.com/s/article/April-Security-Advisory-Ivanti-Connect-Secure-Policy-Secure-ZTA-Gateways-CVE-2025-22457
Per [Mandiant](https://cloud.google.com/blog/topics/threat-intelligence/china-nexus-exploiting-critical-ivanti-vulnerability ):
> We assess it is likely the threat actor studied the patch for the vulnerability in ICS 22.7R2.6 and uncovered through a complicated process, it was possible to exploit 22.7R2.5 and earlier to achieve remote code execution.
Gee, who could have imagined that attackers are looking at patches? 🤔
1) This apparently was silently fixed for ICS in 22.7R2.6, as the fix for this was released in February. Ivanti Policy Secure and ZTA gateways are expected to receive a patch in late April.
2) The advisory still conveys the magical thinking if **if** your device shows signs of compromise, then you should perform a "factory reset." This is magical in that the [ICT won't catch a compromise nor will the "factory reset" reset to factory condition if the attacker is bothering to try](https://infosec.exchange/@wdormann/113805254385223581 ).
While Mandiant also parrots the magical thinking of running the ICT tool, which I guess is the best advice if you're not going to throw the device in the trash since there isn't an official integrity checking tool that is sound, they do throw out a tidbit of:
> ... and conduct anomaly detection of client TLS certificates presented to the appliance.
Bets on whether CVE-2025-22457 is an overflow in the handling of a field in a client-provided certificate? 😂
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/275/335/314/017/398/original/c8817f4a63e90e8d.png

2025-04-02 12:53:40 UTC

- reply

FWIW, I did some testing with the eicar string in an AES-encrypted zip (via 7-zip)<li>EICAR as <code>eicar.com</code> : Blocked</li><li>EICAR as <code>hello.txt</code> : Allowed</li><li>EICAR with an appended <code>A</code> as <code>eicar.com</code> : Blocked</li><li>CRC32 collision as <code>eicar.com</code>: Blocked</li><li>CRC32 collision as <code>hello.txt</code>: Allowed</li>
So at least as of this specific test, it may be that the Gmail SMTP server is perhaps just using filenames for "blocking" the sending of mail.
And again, I use scare quotes around "blocked" as while the SMTP server does say that the message was blocked "because its content presents a potential security issue." But the email is indeed sent to the recipient., despite the warning.
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/268/465/099/733/873/original/a728f1552bfe07a2.png

2025-04-02 04:40:02 UTC

- reply

But why would the EICAR string with the file name wd.txt get blocked in an encrypted (password-protected) ZIP?

2025-04-02 02:37:25 UTC

- reply

FWIW, I generated a file with the same size and CRC32 as eicar.com and put it in a password-protected ZIP file and the Gmail SMTP server didn't complain a bit. 🤔

2025-04-01 23:15:54 UTC

- reply

Actually, after some further tests:<li>The Info-ZIP that comes with macOS creates an encrypted ZIP 1.0 archive, and is reported to be blocked by Gmail SMTP.</li><li>The same encrypted ZIP from 7-zip using "ZipCrypto", or AES encryption is also reported to be blocked by Gmail SMTP.</li><li>I say "reported to be blocked" as while the Gmail SMTP server gives me this warning saying that the sending of the message failed, it actually does send the message. But seemingly delayed slightly. 🤦‍♂️</li>
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/265/211/899/449/690/original/9e6f53a0df92f20f.png

2025-04-01 23:11:18 UTC

- reply

CRC32 isn't enough to uniquely identify files. There'd be too many false positives due to collisions, IMO.

2025-04-01 22:38:36 UTC

- reply

Ah, good guess!
Using standard zip encryption with an unguessable password not in the message body:<li><code><eicar string></code> as <code>eicar.com</code>: Blocked</li><li><code>hi</code> as <code>hi.txt</code>: Allowed</li><li><code><eicar string></code> as <code>wd.txt</code>: Blocked</li>
Were it not for the last case, I'd assume that somehow the combination of encrypted + suspicious filename = Block. But that last case...
I'm at a complete loss as for how the EICAR string as wd.txt in an encrypted ZIP file is blocked. 🤷‍♂️

2025-04-01 17:59:38 UTC

- reply

I didn't investigate much further, but I suspect that Gmail's SMTP server will attempt a list of known passwords, plus each word that exists in the email itself to decrypt encrypted ZIP files that are attached.

2025-04-01 17:52:50 UTC

- reply

Yeah, even with a number of different ZIP passwords, I found that Gmail's SMTP server still found the evil inside if I didn't use PGP encryption at the higher layer.
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/263/976/042/780/469/original/87d57216a4fab70e.png

2025-04-01 17:23:34 UTC

- reply

I did have an AV vendor recently request my EICAR-containing PoC in a password-protected ZIP file in my already-PGP-encrypted email.
Presumably their workflow for handling encrypted emails automatically deleted my PoC. 😂

2025-04-01 17:17:27 UTC

- reply

I mean, when they refused to accept my video on YouTube, they **did** tell me to upload the video to OneDrive, which could end up costing me money depending on my quota. 😂

2025-04-01 17:04:20 UTC

- reply

One of the 3 vulnerabilities that I've outlined is that the on-endpoint driver blocklist is a differently-maintained list than the [online list](https://learn.microsoft.com/en-us/windows/security/application-security/application-control/app-control-for-business/design/microsoft-recommended-driver-block-rules ).
Am I being pedantic and nit-picking here?
Per MSRC, the discrepancy is intentional:
> Lastly, regarding the Online Driver Blocklist, the online list is supposed to be a superset
Let's say that theoretically this is not a lie...
1) How well known is it that the online Microsoft recommended driver block rules list is **intentionally** a superset of what endpoints see? The language in the online blocklist clearly says that **the** blocklist gets put on endpoints via Windows Update. 🤔
2) Let's pick a sample driver used by the years-old exploit [KDU](https://github.com/hfiref0x/KDU ). Driver number 1 provided by this tool is [RTCore64.sys](https://www.loldrivers.io/drivers/e32bc3da-4db1-4858-a62c-6fbe4db6afbd/ )
This driver is definitely in the online Microsoft recommended driver block rules list. Let's test it out in a Windows 11 with the "Microsoft Vulnerable Driver Blocklist" option enabled.
Oh... it loads? And it allows us to disable driver signature verification?
This seems less than ideal.
Tell me, oh internet public, why might Microsoft intentionally choose to allow a years-old public exploit to continue to work?
Oh, right. It's easier to blow off a researcher with a "this is intentional" as opposed to actually read the report that they submitted and address the problem. 🤦‍♂️
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/263/831/243/704/491/original/9698eeaa0dc836cb.png
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/263/763/706/131/252/original/1f8af87742e4dfa7.png
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/263/774/009/521/212/original/b853179446315e81.png

2025-03-31 14:09:04 UTC

In today's episode of drama in the CVE ecosystem:
The Canonical CNA created [CVE-2025-0927](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-0927 ) and an [associated advisory](https://ubuntu.com/security/CVE-2025-0927 ) for a heap overflow in HFS+ in the Linux kernel.
The Linux kernel CNA stripped out the information (like the reporter of Attila Szász, useful references, etc) from the CVE entry and added the passive-aggressive:
> The Linux kernel CVE team has been assigned CVE-2025-0927 as it was incorrectly created by a different CNA that really should have known better to not have done this.to this issue. [sic]
Also TIL: If you look only at the assignerShortName in a cvelistV5 CVE entry, you might not get the whole picture of whose CVE it technically is. While the Linux kernel rewrote history to claim that **they** assigned the CVE, that was only done via the cna container's ProviderMetadata shortName value. The top-level [assignerShortName](https://github.com/CVEProject/cvelistV5/blob/main/cves/2025/0xxx/CVE-2025-0927.json#L7) for the entry still shows canonical.
Good times...
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/257/381/114/219/227/original/3812831817c8bd89.png
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/257/431/435/673/328/original/f86fe742deac6337.png
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/257/433/764/597/291/original/8cafd467d7c4c038.png

2025-03-31 04:35:43 UTC

I can't quite put my finger on it, but something about this current administration makes me think that they're not putting their best efforts into things.
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/255/179/276/930/717/original/ace3949c3b8883d2.jpeg