hunt-aspnet
Skill2 starsChanged 2 months agoMITView on GitHub
Hunt ASP.NET-specific surface — ViewState deserialization (signed-only vs encrypted), machineKey recovery, dual-parser MAC-bypass anti-pattern, request-validator bypass, trace.axd/elmah.axd disclosure, load-balanced ViewState cross-node failures, SafeControl enumeration via reflection, customErrors mode=Off stack-trace leaks, classic Webforms .aspx/.asmx/.svc surface. Built for ASP.NET Webforms + WCF + SharePoint farms.
- Sends data out
3 other projects use a version of this, 3 of them edited.
Adopted by
Most recently taken up by
- murrtada/bug-bounty-agent-skillsedited, first seen Nov 15, 2026
- elementalsouls/Claude-BugHunteredited, first seen Jul 1, 2026
- hhjkjkjk/Claude-skillsedited, first seen May 29, 2026
Other versions3 projects use a version of this.
Word for word · 0
None found.
Edited · 3
- elementalsouls/Claude-BugHunter★ 6.1k100% same
- murrtada/bug-bounty-agent-skills★ 7100% same
- hhjkjkjk/Claude-skills★ 0100% same
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository255 other files it gives its agents.
- ad-acl-abuseSkill
- ad-adcs-access-and-relaySkill
- ad-adcs-persistenceSkill
- ad-adcs-template-abuseSkill
- ad-ad-discoverySkill
- ad-ad-persistenceSkill
- ad-auth-coercion-relaySkill
- ad-credential-dumpingSkill
- ad-gpo-abuseSkill
- ad-kerberos-delegationSkill
- ad-kerberos-roastingSkill
- ad-kerberos-ticket-forgingSkill
- ad-pass-the-hashSkill
- ad-sccm-exploitationSkill
- ad-trust-attacksSkill
- hunt-ntlm-infoSkill
- offensive-active-directorySkill
- hunt-llm-aiSkill
- hunt-rag-vectorSkill
- offensive-ai-securitySkill
- cloud-iam-deepSkill
- hunt-cloud-misconfigSkill
- hunt-k8sSkill
- m365-entra-attackSkill
- network-container-escapesSkill
- offensive-cloudSkill
- offensive-container-escapeSkill
- offensive-k8s-attacksSkill
- okta-attackSkill
- vmware-vcenter-attackSkill
- credential-password-sprayingSkill
- hunt-brute-forceSkill
- hunt-forgot-passwordSkill
- post-exploit-credential-recoverySkill
- meme-coin-auditSkill
- offensive-crypto-attacksSkill
- web3-auditSkill
- ctfSkill
- advisory-miningSkill
- auth-bypassSkill
- code-injection-codegenSkill
- command-injectionSkill
- cross-pollinationSkill
- cve-hunting-methodologySkill
- decompression-bombSkill
- entity-expansionSkill
- fp-checkSkill
- method-clobberingSkill
- path-traversalSkill
- prototype-pollutionSkill
- recursion-dosSkill
- redosSkill
- sandbox-escapeSkill
- target-reconSkill
- web2-vuln-classesSkill
- evasion-av-edr-evasionSkill
- offensive-anti-forensicsSkill
- offensive-edr-evasionSkill
- offensive-keylogger-archSkill
- offensive-mitigationsSkill
- The first 60 shown.
The file
We split this skill into the rules it gives an agent
4 rules. 2 are common, 0 are distinctive, and 2 are very specific to this project.
2
Common
Most of the 3 edited versions we read keep these.
0
Distinctive
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Common: line 98
Look for load-balanced cross-node ViewState MAC failures: If POST gets a 500 with
- Very specific: line 100
Probe
trace.axdandelmah.axd: If either returns 200 anonymously, it's a Critical finding (trace leaks every request + headers + form … - Very specific: line 111
Check
customErrorsmode: If 500s expose full stack traces, framework versions, file paths, internal method names → customErrors … - Common: line 237
Before writing the report, confirm:
“Common” is measured: kept by at least 6 in 10 of the 3 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Crown Jewel Targets
ASP.NET deserialization bugs pay among the highest amounts in bug bounty when they reach RCE. Even when patched, the disclosure-tier findings (signed-only ViewState, dual-parser differential, request-validator quirks) reliably pay Low-Medium.
Highest-value targets:
- SharePoint farms (any version — 2013/2016/2019/SE) — sign-only ViewState + permissive ToolPane.aspx + anonymous FormDigest creates the CVE-2025-53770 ToolShell precondition chain
- Telerik UI for ASP.NET AJAX —
Telerik.Web.UI.WebResource.axdis a documented RCE sink when keys leak (CVE-2017-11317, CVE-2017-11357, CVE-2019-18935) - Classic ASP.NET Webforms enterprise apps — banking portals, dealer portals, HR systems left on .NET Framework 4.x
- WCF services (
*.svc?WSDL) — often forgotten admin endpoints with looser auth than the main app - Sitecore CMS — ViewState + Sitecore-specific deserialization chains (CVE-2021-42237)
- DotNetNuke (DNN) — historic ViewState RCE chains
- Umbraco CMS — ViewState + custom deserialization sinks
Asset types that pay most: internet-reachable ASP.NET Webforms apps > WCF admin services > Telerik-integrated sites > Classic ASP.NET MVC with VSF (very rare)
Attack Surface Signals
Response headers indicating ASP.NET:
X-AspNet-Version: 4.0.30319 (classic — disclosure on its own)
X-Powered-By: ASP.NET
X-AspNetMvc-Version: 5.2
Server: Microsoft-IIS/10.0
Set-Cookie: ASP.NET_SessionId=...
Set-Cookie: .ASPXAUTH=... (Forms auth cookie)
Set-Cookie: .ASPXFORMSAUTH=...
Set-Cookie: ASP.NET_SessionId=...; SameSite=None (suggests cross-origin embedding)Body signals (in form HTML):
<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="..." />
<input type="hidden" name="__VIEWSTATEGENERATOR" id="__VIEWSTATEGENERATOR" value="..." />
<input type="hidden" name="__VIEWSTATEENCRYPTED" id="__VIEWSTATEENCRYPTED" value="" />
↑ EMPTY = signed-only, not encrypted = exploitable if key leaks
<input type="hidden" name="__EVENTVALIDATION" id="__EVENTVALIDATION" value="..." />
<input type="hidden" name="__REQUESTDIGEST" id="__REQUESTDIGEST" value="0x...,...">
↑ SharePoint CSRF token; if anon-issued, see hunt-sharepointURL patterns to probe:
/trace.axd (per-app trace viewer; sometimes anon-accessible)
/elmah.axd (ELMAH error log viewer)
/elmah.axd/?id=... (ELMAH RCE / stack-trace leak)
/*.svc (WCF services)
/*.svc?wsdl (WCF WSDL)
/*.svc/mex (Metadata Exchange)
/*.asmx (legacy SOAP)
/*.asmx?WSDL (legacy SOAP description)
/*.asmx?disco (legacy discovery)
/Telerik.Web.UI.WebResource.axd (Telerik AJAX components)
/ChartImg.axd (DataVisualization controls; historic deserialization)
/ScriptResource.axd (script resource handler; sometimes leaks paths)
/WebResource.axd (web resource handler)
/_vti_bin/* (SharePoint Web Service Forwarder)
/api/ (Web API 2.x is ASP.NET on classic framework)
/signin (often FedAuth / WS-Federation)Tech-stack signals:
Server: Microsoft-IIS/10.0(or/8.5,/7.5) — confirmed Windows + IISX-AspNet-Versionheader — classic .NET Framework (4.x); .NET Core/5+ does NOT emit this- Cookies with
ASP.NET_SessionId,.ASPXAUTH,FedAuth— Forms or claims auth __VIEWSTATEin form bodies — Webforms (NOT MVC, NOT Razor Pages, NOT Blazor)MicrosoftSharePointTeamServicesheader (sometimes stripped by ELB but leaks instart.aspxbody) — SharePoint
Step-by-Step Hunting Methodology
- Fingerprint the framework version. Trigger any 500 error (stale ViewState POST is a reliable way) and look for
Version Information: Microsoft .NET Framework Version:X.X.XXXXX; ASP.NET Version:X.X.XXXX.Xin the error body. This banner discloses both the runtime and ASP.NET-version-specific patch level. .NET 4.0.30319 + ASP.NET 4.8.x is the most common modern combination. - Locate every form with
__VIEWSTATE. Spider the target and grep forname="__VIEWSTATE". Each is a candidate sink for deserialization attacks if MAC / encryption is bypassable. - Check
__VIEWSTATEENCRYPTEDvalue. Empty (value="") means ViewState is signed-only via<machineKey>but NOT encrypted. Recovery of the validation key → arbitrary deserialization. Non-empty (value="something") means ViewState is BOTH signed and encrypted; both keys needed to forge. Test the ViewState parser-error differential (the dual-parser anti-pattern). Send 7+ ViewState shapes and classify responses:
- Trivial garbage (
AAAA) →"Validation of viewstate MAC failed" - Real prefix from current page →
"Validation of viewstate MAC failed" - Flipped-bit real ViewState →
"Validation of viewstate MAC failed" - Oversize (
A * 100000) →"Validation of viewstate MAC failed" - XML-shaped (
<xss/>) → "The state information is invalid for this page and might be corrupted" ← different parser path - LosFormatter-style prefix (
/wEPDwUKMTcxNzgyOTQwMmRkkz9p4lzA...) → "The state information is invalid for this page and might be corrupted"
The differential proves there are two distinct deserialization entry points, one of which dispatches BEFORE the MAC check on some payload shapes. Historically this enables MAC-before-parse-bypass exploits.
- Trivial garbage (
- Look for load-balanced cross-node ViewState MAC failures. If POST gets a 500 with
"Validation of viewstate MAC failed. If this application is hosted by a Web Farm or cluster, ensure that <machineKey> configuration specifies the same validationKey...", the farm has multiple WFEs WITHOUT machineKey sync, or without sticky-session affinity. Operationally this breaks legit users; security-wise it confirms farm topology. - Probe
trace.axdandelmah.axd. If either returns 200 anonymously, it's a Critical finding (trace leaks every request + headers + form data; ELMAH leaks every server error including stack traces). - Enumerate WCF services (
.svc). For each, fetch?wsdland?mex(metadata exchange). MEX endpoints sometimes return full service contracts including admin operations. - Test request-validator bypass. ASP.NET's request validator blocks
<in query strings by default. Bypass categories that may still get through:- HTML-entity-encoded payloads (
<script>— but these don't execute) - Encoded inside JSON / XML POST bodies (different content-type ≠ same validator)
- In path segments (not query) — validator scope depends on framework version
- In Cookie / Referer headers (varies)
- Inside
<%@ ... %>ASP directives if reached via WebDAV PUT (rare)
- HTML-entity-encoded payloads (
- Check
customErrorsmode. If 500s expose full stack traces, framework versions, file paths, internal method names →customErrors mode="Off"is set. Should beRemoteOnlyfor production. - Look for Telerik components.
Telerik.Web.UI.WebResource.axd?type=rauis the historic upload-to-RCE chain (CVE-2017-11317). ThedialogParametersHolderparameter chain (CVE-2019-18935) requires the encryption key but is otherwise RCE. - SharePoint-specific deserialization paths — see
hunt-sharepointskill for the ToolPane.aspx + anonymous FormDigest + unencrypted ViewState chain. - SafeControl enumeration via reflection. SharePoint's
Picker.aspx?PickerDialogType=<TypeName>(and DNN-equivalent endpoints) accept class names and return DIFFERENT error messages for "type exists but not whitelisted" vs "type does not exist." Feed a wordlist ofMicrosoft.SharePoint.*.WebControls.*types to enumerate the SafeControl list — useful for CVE-2019-0604-family hunting.
Payload & Detection Patterns
Stack-trace fingerprint (trigger via stale ViewState POST):
curl -sk -X POST "https://target.example/page.aspx" \
--data "__VIEWSTATE=AAAA&__VIEWSTATEGENERATOR=AAAA"
# Inspect body for:
# - "Validation of viewstate MAC failed" → confirms signed ViewState
# - "The state information is invalid for this page" → confirms ALTERNATE parser path
# - "Version Information: Microsoft .NET Framework Version:X.X.XXXXX" → exact patch level
# - "Microsoft.SharePoint.Client.ServerStub..." → SharePoint farmViewState parser-error differential probe (Python):
import requests, re, json
S = requests.Session(); S.verify = False
# Get fresh form
r = S.get("https://target.example/path/page.aspx")
real_vs = re.search(r'__VIEWSTATE" id="__VIEWSTATE" value="([^"]+)', r.text).group(1)
real_vsg = re.search(r'__VIEWSTATEGENERATOR" id="__VIEWSTATEGENERATOR" value="([^"]+)', r.text).group(1)
# Test 7 payload shapes
for label, vs in [
("trivial", "AAAA"),
("real", real_vs),
("flipped-bit", real_vs[:50] + "X" + real_vs[51:]),
("oversize", "A" * 100000),
("base64", "VGVzdE1hcmtlcjY3OFhZWg=="),
("xml-shaped", "<xss/>"),
("losformatter", "/wEPDwUKMTcxNzgyOTQwMmRkkz9p4lzA" + "A"*50),
]:
r = S.post("https://target.example/path/page.aspx",
data={"__VIEWSTATE": vs, "__VIEWSTATEGENERATOR": real_vsg})
title = re.search(r'<title>([^<]+)</title>', r.text)
title = title.group(1)[:100] if title else "—"
print(f" [{label:14s}] {r.status_code} {title}")trace.axd anonymous check:
curl -sk -o /dev/null -w "%{http_code}\n" "https://target.example/trace.axd"
# 200 = full trace dump exposed → Critical
# 403 = mod set to localhost-only → check via X-Forwarded-For: 127.0.0.1WCF service enumeration:
# Find all .svc files
curl -sk "https://target.example/" -o body.html
grep -oE '/[a-zA-Z0-9/_-]+\.svc' body.html | sort -u
# For each found:
curl -sk "https://target.example/Service.svc?wsdl" | xmllint --format - | head -60Request-validator bypass categories:
# Default: <script>alert(1)</script> in ?q= → "Potentially dangerous Request.QueryString value detected"
# Bypasses that sometimes work:
?q=%3cscript%3e (URL-encoded — depends on validator config)
?q=<svg/onload=alert(1)> (depends on validator version)
?q=<%00script> (NUL-byte; older validators)
?q=javascript:alert(1) (no < at all — passes validator)
Cookie: foo=<script> (cookie body not validated by default)
Referer: http://x.com/<script> (referer not validated in classic ASP.NET)Telerik exploit gate (CVE-2019-18935 — requires encryption keys):
# Fingerprint Telerik
curl -sk "https://target.example/Telerik.Web.UI.WebResource.axd?type=rau" -X POST
# If response is RadAsyncUploadHandler-style → Telerik present; try keys
# Public exploits require leaked machineKey AND telerikEncryptionKeyCommon Root Causes
viewStateEncryption="Auto"defaults to signed-only on pages without sensitive ViewState data. Many SharePoint pages are configured this way. When__VIEWSTATEENCRYPTEDis empty, ViewState is signed-only — recovery ofvalidationKeyalone enables forgery.<machineKey>AutoGenerate in a Web Farm. Each WFE generates a different key on first boot; ViewState issued by one WFE fails MAC validation on another. Operationally produces 500s; security-wise broadcasts the topology (the error message names the cluster).<customErrors mode="Off">left from development. Stack traces with full method names, file paths, version banners exposed to anonymous internet users.trace.axd/elmah.axdleft enabled in production. Often forgotten in<system.web><trace enabled="true">blocks.- Forgotten WCF
.svcadmin endpoints. Built for internal admin tooling, never disabled when the main app went to internet exposure. - Dual-parser anti-pattern:
ObjectStateFormatter(legacy) vsLosFormatter(modern) deserialize in different orders relative to MAC validation. Some payload shapes hit the legacy parser BEFORE MAC check. - Request validator only applies to URL-encoded body and querystring. Headers, cookies, XML/JSON bodies, and multipart fields are NOT validated by default. Developers assume validator is universal; it is not.
<machineKey>checked into source repos. Configuration check-ins to GitHub frequently leak validation/decryption keys. Combine withhunt-miscsource-recon for Telerik / SharePoint / DNN keys.SafeControlsweb.config entries trusted to gate deserialization. SharePoint's<SafeControl>list determines which classes Picker.aspx can instantiate. Bypasses exist when the inheritance check is the only gate (CVE-2019-0604 family).
Bypass Techniques
| Defense | Bypass |
__VIEWSTATEENCRYPTED non-empty (encrypted) | Recover both decryption + validation keys from any source-code leak / config-disclosure / VS forge primitive; without keys, deserialization cannot be triggered |
Request validator blocks < in querystring | Move payload to Cookie / Referer / JSON body / multipart filename — validator doesn't reach those contexts in classic ASP.NET |
EnableViewStateMac="true" enforced | Recover validationKey from web.config disclosure or <machineKey> AutoGenerate fingerprinting (ysoserial.net --minify --islegacy mode generates ViewState that passes some MAC-validation gaps) |
trace.axd localhost-only | Set X-Forwarded-For: 127.0.0.1 if the trace mode is localOnly and the validation uses Request.UserHostAddress (some apps use Forwarded-For instead) |
WCF .svc 401 on anonymous | Try ?wsdl and ?mex first; metadata is sometimes anonymously enumerable even when service ops require auth |
| Telerik upload patched | Check the Telerik version: anything pre-2017Q1 (build 2017.1.118 or earlier) is the original RAU RCE. Check 2017Q3 - 2019Q3 for CVE-2019-18935 |
SafeControl whitelist enforced | Inheritance gate (instanceof PickerDialog) IS the gate on patched SP — bypass requires finding a SafeControl subclass with a deserialization sink; enumerate via Picker.aspx |
customErrors mode="On" (no stack traces) | Force a different error path: invalid Content-Length, malformed ViewState that triggers a parser-level exception below the customErrors handler |
Gate 0 Validation
Before writing the report, confirm:
- What can the attacker DO right now with the disclosed information?
trace.axd200 with full request dump → Critical (PII / session cookies / Authorization headers exposed)elmah.axd200 with error log → High (stack traces + internal paths + sometimes credentials)__VIEWSTATEENCRYPTEDempty + recoverable machineKey via separate finding → Critical chain to RCE__VIEWSTATEENCRYPTEDempty without key recovery → Low-Medium (primitive present, not exploitable on its own)- Stack traces in 500s → Low unless they include credentials / connection strings
- Have you reproduced the full chain to attacker-attainable impact, or only the primitive?
- Cross-reference
triage-validationPre-Severity Gate. "Primitive confirmed" is not Critical until the chain ends in impact.
- Cross-reference
- Can a triager reproduce in <10 min from your report?
- Each step copy-pasteable curl / Python.
- For RCE chains: link the public exploit tool (ysoserial.net, viewgen, telerik-revda) and the specific gadget chain.
Real Impact Examples
Scenario A — Signed-only ViewState + permissive ToolPane on EoL SharePoint 2013
https://target-portal.example/_layouts/15/ToolPane.aspx?DisplayMode=Edit returns 200 anonymously. The form contains __VIEWSTATE (signed only — __VIEWSTATEENCRYPTED=""), and __REQUESTDIGEST is anonymously issued via _api/contextinfo. Combined with SP2013 being end-of-life (no patch will ever ship), this is the canonical CVE-2025-53770 "ToolShell" precondition chain on a permanently-unpatched code path. Reported severity: Critical. The dual-parser test (Section 4 of Methodology) confirmed that XML-shaped payloads reach the legacy ObjectStateFormatter BEFORE MAC validation — additional evidence that the chain is reachable even without full machineKey recovery (though full RCE requires both).
Scenario B — Telerik RadAsyncUploadHandler exposed on legacy bank portal
/Telerik.Web.UI.WebResource.axd?type=rau returns the Telerik upload handler. Telerik version (visible in JS bundle metadata) is 2016.3.1027. CVE-2017-11317 applies — keys are baked into the public Telerik DLL of that version. Upload → write aspx to /app_data/ → request → RCE. Reported severity: Critical.
Scenario C — trace.axd + elmah.axd both exposed on enterprise HR portal
trace.axd 200 returns 50 most recent requests, including Authorization: Bearer eyJ... headers on API requests. elmah.axd 200 returns full error log with database connection-string in one of the exceptions. Reported severity: Critical (credentials in plaintext to anonymous internet).
Related Skills & Chains
hunt-rce— ViewState deserialization is the headline ASP.NET RCE path; signed-only ViewState + leaked machineKey = RCE every time. Chain primitive: ASP.NET ViewState dual-parser MAC-bypass anti-pattern detected (signed but not encrypted,<%@ Page enableViewStateMac="true" viewStateEncryptionMode="Never" %>) + machineKey recovered (from web.config disclosure,elmah.axd, source leak, or GitHub) →hunt-rceysoserial.netTypeConfuseDelegategadget → arbitrary command inw3wp.exeworker-process identity.hunt-sharepoint— SharePoint farms inherit every ASP.NET anti-pattern plus their own surface. Chain primitive: ASP.NET fingerprint reveals SharePoint (X-SharePoint headers +/_layouts/reachable) → pivot tohunt-sharepointfor SP-specific RCE paths (ToolShell, SafeControl reflection) before generic ViewState attack.hunt-ntlm-info— IIS sites that advertise NTLM/Negotiate anonymously leak AD topology. Chain primitive: ASP.NET app behind IIS withWWW-Authenticate: NTLM→hunt-ntlm-infoType-2 challenge capture → internal forest name → cross-reference Entra tenant viam365-entra-attackdiscovery.hunt-file-upload— Telerik RadAsyncUpload, Kentico, Umbraco, and DotNetNuke all have historical upload-handler RCE. Chain primitive: ASP.NET CMS fingerprinted →hunt-file-uploadbypass matrix against the CMS upload handler →.aspxwritten into web-accessible path → request → RCE under app-pool identity.triage-validation—trace.axd/elmah.axddisclosure is only Critical when it actually leaks live credentials/tokens; pure stack traces are usually Low. Chain primitive: pull every reported finding throughtriage-validation7-Question Gate before submission — distinguish "verbose error" (informational) from "live bearer token in error log" (Critical) before writing the report (redteam-report-template).
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

