Will Dormann

That's been around since the inception of vulnerabilities being discussed. "What does this get an attacker that they didn't already have?" is a question that nobody seems to consider.

2026-06-28 13:44:51 UTC

- reply

OK, I looked at one more, because I had free cycles, and I apparently don't value my own time.
The imagemagick "vulnerability":
If you **run imagemagick from a special harness designed to exploit imagemagick**, imagemagick will load an EXE file from the path you specify to the harness.
How does the exploit work? It adds a PATH environment variable to the directory where the attacker-provided gswin64c.exe is located, and subsequently executed.
You can replace "imagemagick" with <anything_else> in this exploit. This is how Windows works. If you can set a PATH to an arbitrary directory, Windows will look for things there.
Anyway, I'm calling it. This exploitarium repo is pure slop. But that won't spread people who don't bother looking at the contents from spreading the news.
https://media.infosec.exchange/infosec.exchange/media_attachments/files/116/828/029/355/522/512/original/49a46674c32eb369.png

2026-06-27 03:57:28 UTC

- reply

Because I'm slightly masochistic, I looked at the ffmpeg PoC.
If you **run the compiled C code**, it does indeed create a /tmp/ffmpeg_rasc_exec_demo file as proof of exploitation.
Does this actually prove anything? No, not really. The C program you just ran is a contrived application where instead of giving ffmpeg (libavcodec) an image buffer, it gives it a specially crafted struct:<code>typedef struct DemoChunk { uint8_t plane[64]; demo_callback cb; uint8_t palette[1024]; } DemoChunk; </code>
Which when contrived PoC code runs, lands in code that does <code> puts("[callback] hijacked callback reached"); system("touch /tmp/ffmpeg_rasc_exec_demo"); </code>
Is there a bug in ffmpeg? Perhaps.
But all this PoC proves is "Contrived harness designed to do <thing> does <thing>. Does this PoC prove that people in the real world have anything to worry about? No. At least not based on this PoC. If your attack involves the victim running a crafted malicious executable, then fine. Have it do that you want. You don't even need ffmpeg.
I didn't think that PoC||GTFO would need clarification about what it means. Yet here we are.
I probably won't look at any more of these, unless a more-masochistic individual has the patience to sift through them and point out what might be of interest.

2026-06-27 03:34:26 UTC

Somebody posted a bunch of exploits on GitHub that claim to be 0days.
https://github.com/bikini/exploitarium
Let's look at the first one: A 7-Zip MotW bypass.
**Problem #1**: 7-Zip **DOESN'T EVEN WRITE MOTW FOR EXTRACTED FILES BY DEFAULT**. This doesn't have a CVE, because [apparently CVE is difficult](https://github.com/CVEProject/cve-documents/issues/29 ).
**Problem #2**: If you are a security-conscious person who enabled writing MotW in 7-Zip extracted files (contratulations!), you might notice that the archive contains a :Zone.Identifier:$DATA (MotW ADS) file in it and recognize shenanigans.
**Problem #3**: When you extract the file, you will be presented by the following dialog asking if you want to overwrite the ::DATA (primary data stream) of the file. And if you got this far, you're a security-conscious person, so you won't do this.
If you get past all of those hurdles, and click Yes in the dialog, then yes, you'll have a file extracted from a RAR that came from the internet that contains an attacker-controlled MotW (that says it didn't come from the internet).
Is this a vulnerability? Sure. But it both relies on a **non-default** 7-zip configuration, and it also relies on **user interaction** to succeed. As such, I can't say that I'm terribly interested in it.
How about the other 22 exploits in the repo? I skimmed through a few, and some seem quite contrived (sort of like the 7-zip one), but some may be legit.
But alas, I don't have the mental fortitude to sift through it all, based on what I've seen. Maybe somebody else here will.
https://media.infosec.exchange/infosec.exchange/media_attachments/files/116/819/948/011/919/334/original/9769c2b70237c247.png
https://media.infosec.exchange/infosec.exchange/media_attachments/files/116/819/953/048/972/397/original/49f29bad5378b265.png

2026-06-23 12:50:14 UTC

- reply

> nearly half
I wonder if there's another common fraction that could help to convey the concept of 34%... 🤔
😂

2026-06-10 16:49:46 UTC

- reply

Eh, it sure doesn't look fixed to me?
Also, sfc /scannow suggests you're running it on bare metal as opposed to just reverting to a VM snapshot? 😬
https://media.infosec.exchange/infosec.exchange/media_attachments/files/116/726/835/618/170/580/original/1e1380b75079a89f.png

2026-06-10 15:41:35 UTC

- reply

Ah, so change the named pipe name? 😂
https://media.infosec.exchange/infosec.exchange/media_attachments/files/116/726/655/964/467/021/original/6c1d7b19d3249a33.png

2026-06-04 15:00:56 UTC

- reply

I'm going to go out on a limb here...
https://media.infosec.exchange/infosec.exchange/media_attachments/files/116/692/433/829/956/371/original/e357b8b91da492b2.png

2026-06-04 14:28:25 UTC

- reply

https://www.youtube.com/watch?v=aW2LvQUcwqc

2026-06-04 13:31:47 UTC

- reply

I also tested [another PoC](https://github.com/hnytgl/CVE-2026-41089 ) and it was even more fake. i.e. it didn't even create a CLDAP structure that made sense.
I get that PoC||GTFO is a thing, but we've clearly entered a phase where it needs to be Verified PoC||GTFO. 🤦‍♂️
https://media.infosec.exchange/infosec.exchange/media_attachments/files/116/692/083/358/777/859/original/77e9c8cd6e0af56f.png

2026-06-04 13:23:07 UTC

- reply

Yes, my test environments (unpatched Server 2016, 2022, and 2025) all had a maximum DNS suffix of 64 chars. (Longer isn't allowed)
https://media.infosec.exchange/infosec.exchange/media_attachments/files/116/692/049/575/250/713/original/3ef786e32d2e758c.png
https://media.infosec.exchange/infosec.exchange/media_attachments/files/116/692/058/641/106/787/original/9d54baff81429e7d.png
https://media.infosec.exchange/infosec.exchange/media_attachments/files/116/692/066/460/411/287/original/66e42781919dfaa6.png

2026-06-04 12:44:26 UTC

- reply

😂
I miss the days when things like this were written by humans, using logic and facts. As opposed to statistically plausible slop.

2026-06-04 12:40:59 UTC

- reply

Yeah, I've seen what it claims to do.
But either they are hand-waving over a critical requirement of what it takes to repro, or it's fake.

2026-06-04 12:35:57 UTC

- reply

Ah, so you've confirmed that it works?
With AI and clout seeking these days, we've **long** passed the "PoC exists on Github" thing having any meaning whatsoever. 😂
Personally, I couldn't get that one to do anything.

2026-06-03 16:18:44 UTC

- reply

Reference?

2026-05-27 12:32:46 UTC

In today's episode of "CVE is a disaster":
Anthropic has published a [cordinated vulnerability disclosure dashboard](https://red.anthropic.com/2026/cvd/ ) for their findings.
Vulnerabilities disclosed: 1596
Vulnerabilities patched: 97
Assigned a CVE or a GHSA: 88
...
**CVE COUNT for 1596 disclosed vulnerabilities: 14**
If something has an adoption rate of less than 1%, what do you call it?

2026-05-13 15:41:08 UTC

- reply

Also note that the [RedSun author noticed that the vulenrability was fixed, without a CVE](https://deadeclipse666.blogspot.com/2026/05/were-doing-silent-patches-now-huh-also.html )

2026-05-12 15:12:13 UTC

- reply

I suspect that Microsoft pushed out Defender updates that mitigate the exploit.
With current definitions, I've not seen RedSun succeed. No matter how long I wait.
With old definitions, success is pretty quick.
https://media.infosec.exchange/infosec.exchange/media_attachments/files/116/562/230/582/681/814/original/262483d424fd1700.png
https://media.infosec.exchange/infosec.exchange/media_attachments/files/116/562/231/063/519/567/original/0f68eaf9c05845c3.png

2026-05-08 03:31:00 UTC

The 3 recent Linux LPEs are sort of interesting in that each one took a different path from discovery to disclosure.<li><a href="https://infosec.exchange/@wdormann/116489443704631952" target="_blank">Copy Fail</a>: Publicity stunt where they claim to have done the right thing, yet didn't bother to tell a single distro vendor, and lied about updates being available.</li><li><a href="https://infosec.exchange/@wdormann/116535129483797487" target="_blank">Dirty Frag</a>: Attempted to do proper coordination, including notifying the <code>linux-distros</code> mailing list. But the <a href="https://github.com/V4bel/dirtyfrag/blob/master/assets/write-up.md#disclosure-timeline" target="_blank" rel="nofollow noopener">embargo was broken</a>, so it was disclosed unexpectedly ahead of time.</li><li><a href="https://infosec.exchange/@wdormann/116536031268240371" target="_blank">Copy Fail 2</a>: <a href="https://www.openwall.com/lists/oss-security/2026/05/07/12" target="_blank" rel="nofollow noopener">Discovered as an n-day by looking at kernel commit logs and Spender noticing that it was copyfail-class</a></li>
Each path had basically exactly the same outcome (No fixes at publication time). 😂
#note1lpq…s76v

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-05-04 18:18:14 UTC

- reply

Apparently26.04 is considered a "development release", so you can apparently get it via do-release-upgrade -d
That is, if Ubuntu's servers were up. 😂<code>$ sudo do-release-upgrade -d Checking for a new Ubuntu release Could not download the release announcement Please check your internet connection. $ </code>

2026-04-30 18:37:32 UTC

- reply

What went wrong with this case?
Theori appear to have only contacted the linux kernel devs with the vulnerability, as opposed to going the usual CVD route that includes all of the major Linux distros.
Why is this a problem? Since the linux kernel became a CNA, there has been a [flood of CVEs for the Linux kernel](https://tuxcare.com/blog/the-linux-kernel-cve-flood-continues-unabated-in-2025/ ). The Linux kernel devs' arguments is that any given kernel flaw could presumably be leveraged to behave as a vulnerability, and it's not worth their time to determine "vulnerability" or "not a vulnerability". Everything gets a CVE.
Now the case with copy.fail? It was indeed reported to the kernel devs. And it got a CVE. A single CVE buried in flood of all of the Linux kernel CVEs.
And it appears that every distro on the planet was blindsided by this proven-exploitable vulnerability because they were not given any warning. Or even any suggestion to pick this single CVE out of the sea of Linux kernel CVEs as worth cherry picking.
Much to the chagrin of the Linux devs, RHEL doesn't use up-to-date Linux kernels. They cherry pick CVEs to backport to their chosen kernel version. (e.g. the latest and greates RHEL 10.1 uses 6.12.0, which was released November 17 2024). And in this world where bad actors like Theori don't involve vendors in vulnerability coordination, and just about every Linux kernel bug gets a CVE, this workflow fails. Hard.
Good times...

2026-04-30 13:38:34 UTC

- reply

If you're curious about IOCs for copyfail, look in syslog for:NET: Registered PF_ALG protocol family
for attempts to exploit copyfail on systems that use the vulnerable code as a module. For systems that have the vulnerable code compiled into the kernel, like RHEL, you'll see this line on every boot.
And at least for this particular flavor of exploit, a wall-clock nearby:process 'su' launched '/bin/sh
with NULL argv: empty string added`
is an indication of successful exploitation.
But it's worth noting that the "process launched" stuff is merely what the ITW PoC will leave behind. More clever exploitation may not be as obvious.
https://media.infosec.exchange/infosec.exchange/media_attachments/files/116/493/963/820/216/458/original/0b40e679216dba90.png

2026-04-30 12:46:21 UTC

- reply

While this vulnerability seems to be discovered using AI ("Xint Code"), I have to assume that they also let the AI decide how to do the vulnerability coordination as well.<li><code>major builds are out as of this writing</code> 😂 No distros have official updates for CVE-2026-31431. Fedora 42 and newer have updates, but no official advisory or acknowledgement of CVE-2026-31431. So with them it's unclear if it's even intentional. <a href="https://access.redhat.com/security/cve/cve-2026-31431" target="_blank" rel="nofollow noopener">Red Hat</a>, <a href="https://ubuntu.com/security/CVE-2026-31431" target="_blank" rel="nofollow noopener">Ubuntu</a>, <a href="https://explore.alas.aws.amazon.com/CVE-2026-31431.html" target="_blank" rel="nofollow noopener">Amazon Linux</a>, and <a href="https://www.suse.com/security/cve/CVE-2026-31431.html" target="_blank" rel="nofollow noopener">Suse</a> all have advisories as of now, but NO updates.</li><li><code>disable the algif_aead module</code> as a mitigation. 😂 Bespoke distros like RHEL don't use a module, it's compiled into the kernel.</li>
I can't figure out what the Xint Code angle is with this copyfail stuff. On one hand, yes, it is a true vulnerability that affects a **LOT** of Linux distros available. And they did submit the bug for fixing to the upstream kernel people.
**BUT** the CVE has only existed for a week. And **NONE** of the distros **IN THEIR ADVISORY** had updates available at the time that they pulled the trigger for publication of the shiny [copy.fail](https://copy.fail/ ) website.
I struggle to think of how this even happens. In all my years of infosec, you're either on board with doing CVD (e.g. coordinating with the former CERT/CC) or you're not (dropping 0day). But this all fits bizarrely in the middle. The publication gives the **guise** that they did the right thing, (and please use our AI services). But at the same time, they clearly chose to release the vulnerability details and functional exploit **before** any distro had the ability to properly do anything about it.
Either these Xint Code people have a hidden agenda or ulterior motive that we aren't aware of yet. Or they're just **really bad** at coordinated vulnerability disclosure. You pick.
https://media.infosec.exchange/infosec.exchange/media_attachments/files/116/493/722/586/962/066/original/5bf4d4045d9bf621.jpg
https://media.infosec.exchange/infosec.exchange/media_attachments/files/116/493/723/221/755/401/original/59717c1351453e9e.jpg

2026-04-29 20:28:39 UTC

- reply

Or RHEL.
I suspect that some people use that?
https://media.infosec.exchange/infosec.exchange/media_attachments/files/116/489/879/332/883/559/original/6a8c2c61116db7aa.png

2026-04-29 18:55:18 UTC

- reply

If you're using an obscure distro like "Debian", you may not have a fix available.
https://media.infosec.exchange/infosec.exchange/media_attachments/files/116/489/512/203/071/598/original/f31e01d91386113d.png

2026-04-29 18:37:29 UTC

So [CopyFail](https://copy.fail/ ) CVE-2026-31431 is a thing.
https://media.infosec.exchange/infosec.exchange/media_attachments/files/116/489/442/181/221/777/original/e03a85c201d4361a.png

2026-04-25 16:55:26 UTC

Apparently [Ubuntu 26.04 has been released](https://canonical.com/blog/canonical-releases-ubuntu-26-04-lts-resolute-raccoon ).
At least somewhat?
https://media.infosec.exchange/infosec.exchange/media_attachments/files/116/466/388/705/021/635/original/d5286f9c00cf6475.png

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