If you can see the TLS handshake but nothing more (that is, the CONNECT request is not followed by any other requests), the client (the malware in this case) is probably pinning the server certificate (or at least public key), and rejecting the certificate that Fiddler offers it because that's not the expected one. If this is the case, you still have a few options (however, they all require some degree of reverse engineering). In no particular order:
- Since .NET binaries usually depend heavily on the .NET runtime's provided classes, you can replace key DLLs with modified versions that change functionality to your benefit. For example, you could replace whatever HTTP client class it's using with one that also logs all requests and responses, in plain text, to a file. One way to do that would simply be to download the source code for the relevant DLLs, edit the class(es) you care about, and recompile it. This will not work if the malware is enforcing signature checks on its libraries, though (as it almost certainly is); you would need to disable those checks.
- You could attempt to reverse-engineer the malware to find the certificate/public key pinning code, and disable it. This is near-trivial if the binary is not obfuscated, but realistically it probably is; obfuscation makes reverse engineering harder but not impossible. There are any number of decompilation tools for .NET assemblies available free of charge.
- Same idea as #2, except instead of trying to change the code flow to not perform cert pinning, you look for the certificate or public key that is being pinned to (note: it may be simply a hash/thumbprint of the key/cert, not the full thing) and replace it with the appropriate value for the cert it sees from Fiddler. If you're very lucky, the expected cert is stored outside the binary and you can simply replace it; if you are less lucky you will need to dig into the binary to find where the check is performed and how the expected value is calculated, and change what is probably a hardcoded array or something.
- Sort of like #1, run the malware under a debugger with breakpoints on the HTTP client functions and find the plain-text value of the HTTPS requests and responses. Assuming the malware uses standard .NET HTTP client classes, this requires relatively little reverse engineering and you don't need the malware's private symbols (symbols for Microsoft's classes are available from their symbol servers). However, virtually all malware checks for an attached debugger - it's one of the oldest tricks in the book - so you'd need to find and disable those checks first if you wanted this to work.
- Also somewhat like #1 combined with #2, you could decompile the malware, find where it makes HTTPS requests and where it gets the responses, and "instrument" those functions with your own code that logs those requests and responses, in plain text, to a file. This has the advantage of not needing to read much of the (presumably obfuscated) code - you are just looking for a few specific classes, and probably then adding a wrapper around any invocation of them - but it's still a lot of work. Also, malware may have self-integrity checks that will prevent it from running or change its behavior if it sees itself as modified; for proper results (for this approach or the others that change the binary) you would need to find and remove or fix those checks, too.
Another possibility is that the server is expecting a client certificate from the malware before it will complete the handshake, but in that case I would expect Fiddler to prompt you for it. If it turns out that the problem is a client cert after all, you will need to find that cert and feed it to Fiddler.
Malware analysis can be hard. A really well-written piece of malware is going to be a tough nut to crack. On the other hand, really serious malware is extremely unlikely to be written in .NET - decompilation is too easy, and you can pull far more obfuscatory tricks with native code - so it's probably not all that heavy on anti-analysis mitigations.
