HTTPS Inspection
The last defense system we will discuss is HTTPS inspection,
in which the traffic is decrypted and unpacked, inspected and then repacked,
and encrypted again.
This is essentially a man-in-themiddle.
From an architectural standpoint, this is often done at the Internet Edge zone.
Because decrypting and re-encrypting traffic is very expensive and complex,
most environments perform this process on a dedicated device.
In this scenario, client machines trust the inspection device’s certificate
since it is often signed by the organization’s certificate authority,
allowing the device to impersonate the client.
There is no easy way to bypass HTTPS inspection devices.
If we are using HTTPS, we must simply assume that our traffic will be inspected
and try to keep a low profile.
One way to do this is to abort a payload if we suspect that it is being inspected.
We can do this with TLS Certificate Pinning in Meterpreter.
Using this technique, we can specify the certificate that will be trusted.
Meterpreter will then compare the hash of the certificates
and if there is a mismatch, it will terminate itself.
This can be controlled by setting the StagerVerifySSLCert option to “true”,
and configuring HandlerSSLCert with the certificate we trust and want to use.
We can also try to categorize the target domain of our traffic
to reduce the likelihood of inspection.
Some categories, like “banking”, are usually not subject to inspection
because of privacy concerns.
If we can categorize our domain to an accepted category,
we may be able to bypass HTTPS inspection and, by extension,
bypass other detection systems as well since our traffic is encrypted.
So far in this module, we have discussed various defensive devices
and demonstrated various generic bypasses.
In the next sections, we will discuss various techniques that can be used to
bypass multiple systems all at once.