When trying to analyze malware, have there been cases where malware detected the use of mitmproxy and ceased operation?
If that has happened, would it be a good idea to be constantly using a proxy as a measure for deterring any malware?
When trying to analyze malware, have there been cases where malware detected the use of mitmproxy and ceased operation?
If that has happened, would it be a good idea to be constantly using a proxy as a measure for deterring any malware?
Whether or not using a proxy all the time is a good idea depends on your threat model. Attackers could try to specifically target the proxy itself. If everyone starts using a proxy malware authors would probably adapt. The dazzlespy malware uses a custom root CA and stops if a TLS intercepting proxy is used.
This is largely because one can do traffic analysis off netflow data without using a proxy at all. Consequently, refusing to operate when a regular (non-decrypting) proxy is in place isn't worth it: Sandboxes will still monitor your data, and sites with competent networking staff will still know which IPs you reached out to (which DNS names you looked up, etc) without needing a proxy.
Job one of TLS is to encrypt content end-to-end. If every connection out of a company gets decrypted, that has a few serious impacts.
Whichever system that decryption happens on, and the secrets it uses at runtime, becomes a major vulnerability.
...since making something like this exist in a company means there's a single piece of hardware through which everything from employee credit card numbers to major banking transaction flows. In effect, the company is giving up the full benefits of transport-layer security, and hoping that it can guard that basket.
Legitimate software that does certificate pinning will fail.
A great deal of legitimate software performs certificate pinning for reasons that are not at all user-hostile.
If you're writing the updater for a commercial accounting package, you don't want there to be a risk that a hostile government will make fake certificates for your update server (signed by a CA under their control) and use them to distribute ransomware or wipers to your customers.
Proxies that decrypt SSL work by adding a certificate authority to the system's or browser's certificate store, and using that authority to sign fake certificates generated for sites the browser or client software is trying to access.
Typically, malware authors don't do a good job of their transport layer security; sometimes, they completely ignore failure notices (and consequently end up connecting to MITMed servers even without a CA vouching for that server). However, just like more competent and security-aware application developers, competent and security-aware malware developers are also liable to use certificate pinning.
"Certificate pinning" is the technique whereby a developer hardcodes a CA certificate into the application at compile time, and instructs their SSL or TLS library to trust only that certificate, and not query the operating system's security layer to get the list of trusted CAs.
If a piece of malware performs certificate pinning, it's still possible to investigate its control channels, but takes more work: For example, one might find the hardcoded CA certificate in the binary and replace it with one that the analyst controls. One can also take a memory dump at runtime and extract session keys from same; this is discussed at Can we decrypt captured malware (Meterpreter) HTTPS/SSL traffic with the keys from memory? -- it may not allow full man-in-the-middle control from the beginning of the session, but does allow encryption for the duration of time those session keys were valid.