A slightly scary commit, on the plus side, my .NET profiler is a million times easier to extend now

Success! After hours of debugging, I found that removing runat="server" from the outer most element of the CVE-2025-49704 payload generated by YSoNet fixed it. Every in the wild sample I've seen has this field set so I'm pretty confused now. @irsdl any idea why this might be?

...so yes

Not the response I want when I resort to AI to debug some mutual TLS issues

After a bit more digging it look like its referenced in Microsoft.JScript, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a but not Microsoft.JScript, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a The later of which is used by my IIS

For years I've seen adversaries using the "unsafe" keyword in their JScript eval shells and assumed it was required to eval complex statements (i.e code), but after trying to work out what it actually does for some training I'm working on I found it does nothing! Its unreferenced

It put my life on hold for a month and I'm very sleep deprived but thanks for the great CTF @HuntressLabs @_JohnHammond @HuskyHacksMK @_BensonBoy23 @sudo_Rem @IzzyBoopFPV @Kaspertame #HuntressCTF

Defender seems interested in my upcoming BSides Canberra training on Attacking and Defending Microsoft IIS Training

We're people really ignoring virus alerts on Server 2019 enough that we needed a danger dog added to them?

Awesome writeup, I'll have to give Harmony hooking under DnSpy a go. If you're interested in .NET under IIS at all, I did a talk at BSides Canberra on using Harmony to mess with webshells (although I think you did a far better job of explaining Harmony) youtu.be/9O0ktG6xuTk