Finding Hardcoded Secrets

Compiled .NET assemblies frequently contain hardcoded secrets that developers intended to keep private. Connection strings, API keys, bearer tokens, and internal URLs all survive compilation and are readable without source code access. mcilspy provides two complementary approaches for finding them.

Caution

If you discover credentials in a production assembly, treat them as compromised. Rotate the secrets immediately, then fix the code. Hardcoded secrets in compiled binaries are trivially extractable by anyone with access to the file.

Start with String Literals

The search_strings tool reads the .NET User Strings heap directly from metadata — no decompilation required. This is the fastest way to find embedded text.

Search for common secret patterns:

"Search for any URLs in MyApp.dll"

The tool supports regex, so you can cast a wider net:

"Search MyApp.dll for strings matching the regex https?://|api[_-]?key|password|secret|bearer|connectionstring"

Useful regex patterns for common secret formats:

Pattern	Finds
https?://	URLs and API endpoints
[A-Za-z0-9]{32,}	Long alphanumeric tokens (API keys, hashes)
(?i)password|pwd|passwd	Password field references
Server=.*Database=	SQL connection strings
mongodb(\+srv)?://	MongoDB connection URIs
Bearer\s+[A-Za-z0-9\-._~+/]+=*	Bearer tokens
-----BEGIN	PEM-encoded certificates or private keys

Follow Up with Field Constants

String literals tell you what values exist, but search_fields with constants_only reveals where they live in the type system. This is especially useful for configuration classes that store secrets as const or static readonly fields.

"Search for constant fields with 'key' or 'secret' in their name in MyApp.dll"

The constants_only parameter filters to const and static literal fields, which are the most common places developers store configuration values:

"Search fields in MyApp.dll with pattern 'connection' and constants_only enabled"

Practical Workflow

1. Broad string search — Run search_strings with a pattern like https?://|password|key|token|secret to find raw values.

2. Identify interesting hits — URLs to internal services, anything that looks like a key or token, base64-encoded blobs.

3. Find the declaring types — Use search_fields with the field name or value to locate the class that holds the secret.

4. Decompile the context — Call decompile_assembly with type_name set to the declaring class to see how the secret is used.

5. Check for obfuscation — If strings look encoded, search for base64 decode calls with search_methods using pattern FromBase64 or Decrypt.

Dealing with Obfuscated Secrets

Some assemblies encode or encrypt their secrets at compile time. When search_strings returns base64-encoded or otherwise scrambled values, look for the decoding logic:

"Search for methods named Decrypt, Decode, FromBase64, or Deobfuscate in MyApp.dll"

Then decompile those methods to understand the encoding scheme. Simple XOR or base64 obfuscation is common and easily reversible once you can read the implementation.

Note

The search_strings tool reads the #US (User Strings) metadata heap directly, which is typically 10-100x faster than decompilation-based approaches. It works without ilspycmd installed.