Case Study: Bypassing Norton HIPS with Custom Certificates
A Host-based IPS (HIPS)
is an IPS that is often integrated into an endpoint software security suite.
This type of system has full access to the host’s network traffic
and as with a traditional IPS,
can block traffic based on signatures.
In this case study,
we will demonstrate a bypass for the Norton HIPS
that is bundled with Norton 360
and the Symantec Endpoint Protection
enterprise solution.
Although this product can detect and block standard Meterpreter sessions,
it is signature-based,
which means we can bypass it
with simple network traffic modifications.
Specifically, this product detects the standard Meterpreter HTTPS certificate.
Certificates are used to ensure
(or certify) the identity of a domain.
They are also used to encrypt network traffic
through a variety of ryptography mechanisms.
Normally, certificates are issued by trusted authorities called
Certificate Authorities or CAs,
which are well-known.
For example, the CA trusted root certificates
are pre-installed on most operating systems,
which streamlines validation.
Let’s dig in to our case study,
using Norton IPS on the Windows 10 client.
To simulate an attack, we’ll set up a reverse
HTTPS Meterpreter multi/handler listener
on our Kali machine.
Next, we’ll connect to the reverse shell from our browser.
It’s important that we use our browser to connect for this case study
because our focus is on the certificate that is generated
and not the Meterpreter traffic itself.
This connection is blocked immediately
and Norton 360 generates a popup
on the Windows 10 desktop
flagging the Meterpreter Reverse HTTPS session.
Clicking View Details reveals further information,
including our Kali attack machine’s IP and port,
the local IP and port,
referred to as Destination Address,
the date and time of the connection,
and a description of the alert.
Since the alert refers to an HTTPS signature,
let’s take a moment to view the offending signature.
To do this, we must first stop the IPS functionality within Norton 360.
This setting is available in the Security tab
under the Advanced section.
From here, we’ll switch off Intrusion Prevention.
With intrusion prevention switched off, we’ll connect to our listener again
from the Windows 10 browser.
The browser presents a certificate error
because Meterpreter is using a self-signed certificate,
which means it wasn’t certified
by a trusted CA.
Let’s view that certificate.
Next, we’ll restart the Meterpreter listener
on our Kali machine and connect again.
This will again throw the certificate error.
However, the certificate has changed:
Notice that every detail of the certificate is different.
Meterpreter randomizes this certificate
in an attempt to evade signature detection.
However, if we were to re-enable Norton’s IPS feature,
this certificate would flag as well.
Since we don’t understand exactly why this is flagging,
we can begin with
two safe assumptions.
Norton may be flagging this because it’s a self-signed certificate.
If this were the case, we could use a real SSL certificate,
which requires that we own that domain.
This is the best approach if we own a safe domain.
To do this, we would obtain a signed, valid certificate,
perhaps from a service provider like Let’s Encrypt,
which provides free
three-month certificates.
We need to consider that self-signed certificates are somewhat common
for non-malicious use though.
Therefore, at this point, it is unlikely that this is the cause of our problem.
It’s more likely that Norton contains signatures for the data
present in Meterpreter’s randomized certificates.
will proceed with this assumption
and create our own self-signed certificate,
customizing some of its fields in an attempt to bypass those signatures
There are several approaches we could consider.
One approach is to generate a self-signed certificate
that matches a given domain
with Metasploit’s impersonate_ssl auxiliary module.
This module will create a self-signed certificate
whose metadata matches the site we are trying to impersonate.
Another option is to manually create a self-signed certificate
with openssl,
which allows us full control over the certificate details.
We don’t need to own a domain for this approach
but if the certificate is passing through HTTPS inspection,
which is covered later in this module,
the traffic might flag
because of an untrusted certificate.
However, despite the drawback of potential HTTP inspection flagging our traffic,
we’ll try this approach
and generate a new
self-signed certificate
and private key
that appears to be from NASA.
We’ll use several openssl options:
req: Creates a self-signed certificate.
-new: Generates a new certificate.
-x509: Outputs a self-signed certificate
instead of a certificate request.
-nodes: indicates that we will not encrypt
private keys.
-out cert.crt specifies the output file
-keyout priv.key: specifies the output file for the private key.
In order to use this certificate and key with Metasploit
we must create a .pem file
by simply concatenating the key
and certificate with cat.
We also must change the CipherString
in the openssl.cnf config file
or our reverse HTTPS shell will not work properly.
First, we will locate this line in the config file:
We will remove the “@SECLEVEL=2” string,
as the SECLEVEL option limits the usable hash and cypher functions
in an SSL or TLS connection.
We’ll set this to “DEFAULT”, which allows all.
Finally, we’ll configure Metasploit to use our newly-created certificate
through the HandlerSSLCert option,
which we’ll set to the path of our certificate file.
Once this is set, we’ll restart our listener.
Let’s re-enable Norton’s host-based IPS,
reload the web page,
and view the certificate in our browser:
Although the browser still complains bout the self-signed certificate,
our newly-created “NASA” certificate
bypassed Norton’s IPS.
This confirms that Norton was, in fact,
flagging Meterpreter’s “randomized” certificate
field data.
In a real-world engagement, we might consider
using more sensibly-customized field data,
but regardless of the actual field data,
we can use simple changes like this to bypass some IPS software.
This example highlights the shortcomings of signature-based IPS sensors.