Microsoft released a blog this week which I don’t think people have fully understood the implications of, but it’s great research and a great attack by the threat actor.

I think it’s highly likely multiple threat actors will now jump on this, it’s even automatable.

The attack:

1) take a web.config file. They’re really easy to find.
2) POST request to RCE in IIS

The architecture of .net means this is surprisingly easy to do and you don’t patch your way out of it.

https://www.microsoft.com/en-us/security/blog/2025/02/06/code-injection-attacks-using-publicly-disclosed-asp-net-machine-keys/

I’ve bookmarked this thread so it doesn’t auto delete the toots, put it that way. You could just automate spraying the internet with this one.

@GossiTheDog “ publicly available, static ASP.NET machine key” THE. WHAT.

This is like finding the string “pass=replaceme” AND SHIPPING THAT TO PROD.

@GossiTheDog The dangers of exposing ViewState encryption keys (or encryption oracles) were popularized at least by 2010 because of the padding oracle fixed with MS10-070:

https://web.archive.org/web/20101225182433/http://netifera.com/research/poet//PaddingOraclesEverywhereEkoparty2010.pdf

Similar attacks can be executed against frameworks that also protect stateless session data with encryption/MAC's, see CVE-2018-15133 of Laravel:

https://mogwailabs.de/en/blog/2022/08/exploiting-laravel-based-applications-with-leaked-app_keys-and-queues/

We've been hunting for web.config's during pentests too - the latest exploit I remember must've been written around last December by teammate based on a file read vuln exposing web.config.

So yeah, don't expose your private keys... If you do, that's not the problem of the crypto system (or ASP.NET in this case).

@GossiTheDog That is technically true, but scanners already look for exposed web.configs, so any affected, but not already exploited Internet-facing sites would be simultaneously extremely negligent and lucky.

https://github.com/projectdiscovery/nuclei-templates/blob/2390fd195ab00f2bb1142dd27ac2ab888622d9bd/http/exposures/configs/web-config.yaml#L22

@GossiTheDog 1) 3000 is not a big number on the Internet (quality matters though) 2) This is an overestimation because not all keys are useful (as the captured text also implies)

I haven't touched ASP.NET for a while, but I'd risk to say that app configuration also affects exploitability as i) not all apps rely on signed ViewState (IIRC) ii) deserialization gadgets are not universal.

These are of course solvable problems, but still need to be taken into account for risk assessment.

@GossiTheDog MS Defender alerts if it finds configs with those leaked keys. Quite useful

@buherator @GossiTheDog

Is it possible that Broadcom has spotted these same attacks earlier?

https://www.broadcom.com/support/security-center/protection-bulletin/godzilla-webshell-deployment-campaign

@buherator @GossiTheDog

Or ASEC: https://asec.ahnlab.com/en/85088/

They go in more detail, but mention ASP.NET environments with vulnerable configurations.

Unfortunately, I don't know enough about ASP.NET to make an educated guess whether these attacks could be related.

@GossiTheDog Forgive my ignorance, what is nom?

@buherator @GossiTheDog There's long list of "default" secret keys used for JWT and session cookies collected in various github projects. On Ruby on Rails, Django the secret session key can lead to RCE through unmarshalling. JWT can give you admin role etc.

https://github.com/wallarm/jwt-secrets

@zeljkazorz @buherator @GossiTheDog ASEC's appears to be the closest and I'm trying to determine if Godzilla (web shell) and Godzilla (post-exploitation framework) are one and the same.

This is the web shell version https://github.com/BeichenDream/Godzilla frequently referenced

@screaminggoat @zeljkazorz @GossiTheDog "However, due to inadequate server configurations, attacks become possible if *the serialized data is not verified* (CWE-642)" - this sounds more like disabled MAC than leaked key to me

@GossiTheDog https://github.com/search?q=%3CmachineKey+path%3Aweb.config&type=code

@GossiTheDog Thanks! Now I'm more confused: npm does .NET these days? Or we're talking NuGet?

@GossiTheDog Yeah, edits are weird around here, thanks for the clarification! I can only see npm being used for frontend stuff in .NET projects, could you perhaps link an affected repo/npm page?

@mttaggart @GossiTheDog Some recurring themes in these repos are 1) abandonware 2) test/training code

Also, TIL you can use boolean expressions, e.g. you can filter for autogenerated keys:

https://github.com/search?q=%3CmachineKey+validationkey+path%3Aweb.config+NOT+autogenerate&type=code

@buherator@infosec.place @GossiTheDog @screaminggoat

Symantec says their protection bulletin was prompted by the AhnLab blog post.

I believe @buherator is right. Whether Microsoft found a continuation of the same campaign, with a slightly different approach / toolset, is impossible to tell.

Judging by the capabilities provided by the Godzilla post-exploitation framework and the Godzilla webshell, I wold venture to say that they are one and the same, only Microsoft used that particular expression (and did not elaborate on it, which means they expect the readers to be familiar with it already - i.e., it's known and documented).

@buherator @GossiTheDog Yep, quite a few CTF repos in here.