[New Rule] Toolshell Exploit Chain Detections #4928
Conversation
|
⛔️ Test failed Results
|
|
⛔️ Test failed Results
|
|
⛔️ Test failed Results
|
|
This PR is blocked. UpdateAdded these to the |
|
⛔️ Test failed Results
|
terrancedejesus
added
Domain: Network
Rule: New
Rule: New - GuidelinesThese guidelines serve as a reminder set of considerations when proposing a new rule. Documentation and Context
Rule Metadata Checks
New BBR Rules
Testing and Validation
|
| data_stream.dataset : "network_traffic.http" and | ||
| url.path: /_layouts*ToolPane.aspx and | ||
| http.request.referrer: *SignOut.aspx and | ||
| http.request.headers.content-type: "application/x-www-form-urlencoded" and |
There was a problem hiding this comment.
What if they use other content-types like multipart/form-data?
There was a problem hiding this comment.
Good point. It's safe to exclude this I'd think without jeopardizing fidelity.
| http.request.body.content: *__VIEWSTATE=* and | ||
| http.request.headers.content-type: "application/x-www-form-urlencoded" and | ||
| http.request.body.bytes >= 500 and | ||
| http.response.headers.server: Microsoft-IIS* |
There was a problem hiding this comment.
This indicator could vary right? Do we need this?
There was a problem hiding this comment.
It could be inferred if the body contains _VIEWSTATE that IIS & Sharepoint are the intended target. A response indicating IIS suggests that the request is on-target which we would care about.
| http.request.referrer: *SignOut.aspx and | ||
| http.request.body.content: *__VIEWSTATE=* and | ||
| http.request.headers.content-type: "application/x-www-form-urlencoded" and | ||
| http.request.body.bytes >= 500 and |
There was a problem hiding this comment.
Why 500? Is this arbitrary?
There was a problem hiding this comment.
Its more arbitrary but we can expect the body to be larger in most cases. See https://swapneildash.medium.com/deep-dive-into-net-viewstate-deserialization-and-its-exploitation-54bf5b788817 as a reference. The research here shows examples of the serialized data in the body and how the requests are. It also talks about machine key use and ysoserial, just like the toolshell exploit chain.
| http.request.headers.content-type: "application/x-www-form-urlencoded" and | ||
| network.direction: "ingress" and | ||
| http.request.method: "POST" and | ||
| request: (*MSOTlPn_Uri* and *DisplayMode*) and |
There was a problem hiding this comment.
Is this an IOC? Can this be easily changed?
There was a problem hiding this comment.
No these are specific to the PoC and what researchers are reporting from their honeypots.
Ref: https://github.com/kaizensecurity/CVE-2025-53770/blob/master/payload
See SANS report as well that just came out: https://isc.sans.edu/diary/Analyzing+Sharepoint+Exploits+CVE202553770+CVE202553771/32138/
| network.direction: "ingress" and | ||
| http.request.method: "POST" and | ||
| request: (*MSOTlPn_Uri* and *DisplayMode*) and | ||
| http.request.body.bytes > 5000 |
There was a problem hiding this comment.
Same thing here, is 5000 arbitrary?
There was a problem hiding this comment.
Arbitrary again, but we can expect that the initial deserialization exploit includes a rather large HTTP body as it includes a large payload that mimics a legit web config. If you look at the PoC https://swapneildash.medium.com/deep-dive-into-net-viewstate-deserialization-and-its-exploitation-54bf5b788817 you will see the URL encoded string with ASP.NET markup with an encoded datablock that is deserialized by the server. So yes, we expect the body to be rather larger than normal.
| risk_score = 73 | ||
| rule_id = "99c9af5a-67cf-11f0-b69e-f661ea17fbcd" | ||
| setup = """### Network Traffic Setup | ||
|
|
There was a problem hiding this comment.
once you add an investigation guide, it would be nice to cover the FPs.
There was a problem hiding this comment.
This one may have some FPs, not sure as we don't have a production IIS environment to run the query against to establish baseline but I suspect they will be low. The other rule, FPs should be low. It's more noise I'd be concerned about which is why I added a max number of signals.
rules/network/initial_access_potential_toolshell_exploit_attempt.toml
Outdated
Show resolved
Hide resolved
Co-authored-by: Mika Ayenson, PhD <[email protected]>
|
⛔️ Test failed Results
|
…pt.toml Co-authored-by: Jonhnathan <[email protected]>
|
⛔️ Test failed Results
|
Pull Request
Issue link(s):
Summary - What I changed
Adds detections for initial CVE-2025-53771 and CVE-2025-53770 exploit attempts and for VIEWSTATE RCE attempts later in the Toolshell attack chain. Relies on Network Traffic integration, specifically HTTP traffic. Max signals have been set for the exploit attempts due to potential scanning. Also HTTP response
200for the initial exploit should only flag on successful attempts but it does not confirm webshell deployment (this would be endpoint). No need to include HTTP response200on VIEWSTATE RCE as this is later in the attack chain and assumed machine keys were stolen and VIEWSTATE payloads are signed so we want to capture all of these. Also, thehttp.request.body.bytesbeing over 500 should indicate larger payloads, likely commands, being sent.How To Test
Checklist
bug,enhancement,schema,maintenance,Rule: New,Rule: Deprecation,Rule: Tuning,Hunt: New, orHunt: Tuningso guidelines can be generatedmeta:rapid-mergelabel if planning to merge within 24 hoursContributor checklist