back caretBlog

Five Reasons You Need to Decrypt Traffic for SecOps Analysis

What attack behaviors can't you detect or investigate if your traffic is encrypted?

Fair warning: this is a hefty post that goes in-depth on why security teams need decryption capabilities, complete with a breakdown of specific, common attack behaviors that cannot be detected in a timely way without full decryption capabilities.

Don't want to read the full blog? Watch this 4-minute video for a summary of why decryption is crucial for SecOps (illustrated by our cutting edge visual effects):


It is a well established fact that attackers are using encryption to mask their behaviors, but some vendors still claim to be able to detect encrypted attacks by analyzing the telemetry of network communications—who is talking to whom, how much, and how often. While these vendors may be able to infer some suspicious behavior by watching the telemetry of encrypted communications, this essentially only enables them to build signatures (or "fingerprints") to detect known or very-similar-to-known malware.

For example, some vendors will use the Sequence of Packet Lengths and Times (SPLT), combined with information about which protocols and cipher suites are being used, to infer that malware is being used. To be clear, this is a valid approach for detecting many types of malware, but these methods simply cannot detect many other attack-chain behaviors.

Ultimately, you must decrypt network communications to confidently detect and respond to many common threat behaviors. True network traffic analysis for the enterprise requires the ability to decrypt approved traffic for analysis. Fundamentally, what's the point of investing in advanced detections, machine learning, and behavioral analysis if they only operate on—and thus can only see—a far less granular and thus inferior set of data?

Let's dive into the most common attack behaviors that cannot be quickly detected by network traffic analysis platforms that only operate on encrypted traffic, or don't decode the entire content payload for the range of application protocols attackers use:

  1. Suspicious authentication activity (if LDAP is encrypted, a best practice for enterprises)
  2. Stealthy database access attempts & exfiltration
  3. Command and control communications
  4. Cross-site scripting (XSS) attacks - the Magecart hack that's all over the news these days used these methods, and XSS overall has been found to be the most common attack technique against web applications.
  5. SQL injection attacks

Suspicious LDAP Activity

For organizations using LDAP for identity access and management, which includes the many, many businesses using Active Directory (AD), it is a best practice to encrypt LDAP traffic in motion across the network. Inside that traffic there is information like usernames, login attempts, failed-login notifications, and much more. By encrypting this traffic, attackers can't use it against you. By decrypting the traffic, you can identify suspicious behavior if the attacker is using brute force and other techniques.

For attackers, it is a common practice to compromise legitimate AD credentials and use them to explore your network and attempt to access potentially valuable data. In this process, attackers inevitably leave behind some network artifacts. For example, when an attacker uses compromised AD credentials to try to access a restricted database or storage area and fail, that creates a "failed login" message. This evidence, associated with that username and other contextual info, is transmitted across the network via LDAP. If a user has repeated failed logins against sensitive assets like user databases or payment information, that may be a signal of a brute force attack underway.

If that LDAP traffic is encrypted, many network traffic analysis platforms would miss the signal entirely. If you can't see AD users behaving strangely because you aren't inspecting the decrypted traffic, you miss clear signals that you could use to detect and respond to attacks.

Database Actions

Many organizations encrypt database connections because of the sensitivity, including requirements to support privacy regulations, of the information passed over the network. Without the ability to decrypt these database transactions, network traffic analysis products can only infer what an actor is doing on the network based on limited telemetry data about which hosts were talking to each other and the size and timing of the packets that were transmitted.

By decrypting those database connections and analyzing the content of the transaction, the network traffic analysis product can analyze application-layer information such as SQL statements, error messages, and methods used. This visibility is important, because it shows evidence that an attacker will otherwise destroy. For example, if an attacker gains sufficient privileges to the database, they can delete the audit table to erase the logs tracking their activity.

However, while log-based systems would be blinded, a record of all the attacker's activity on the database would still be captured by a network traffic analysis product that can both decrypt the database connections as well as parse the application-layer content. You would be able to see not only the DROP command that deleted the audit table, but also the preceding SQL statements to see what data they viewed or modified.

Command and Control

Malware authors are increasingly using encryption to hide their command and control (C&C) communications, including HTTPS, SMTPS, and SSL/TLS protocols.

Cross-Site Scripting (XSS)

A cross-site scripting attack involves using an available input field on a website or application to insert executable code that can be used to steal login credentials or bypass identification and access controls. The malicious code is most likely transmitted using the POST method over the encrypted HTTPS protocol.

If a network traffic analysis platform is observing this traffic without decrypting it, they would only see that some encrypted HTTPS communication occurred between whichever devices were involved.

If the network traffic analysis platform was decrypting the traffic, it would be able to see the POST method. That means that a properly configured system could proactively detect the malicious code contained there, and at the very least a security analyst investigating a breach and searching for root cause would be able to dig back into the transaction and see how the attacker misused the application. Read how Reveal(x) detects the Apache Struts 2 exploit (CVE-2018-11776) by parsing the HTTP transaction payload.

No amount of machine learning pixie dust or analytics can substitute for real visibility into the packet contents in this case. This level of detail for detection, investigation, and forensics is only available by inspecting decrypted data.

SQL Injection

A SQL Injection Attack is also a code-injection attack, but one that operates against a database rather than a website. The basic approach is to use a legitimate data entry field to sneak malicious SQL commands into the database, tricking the database into sharing restricted data, deleting important data, or otherwise compromising the confidentiality, integrity, or availability of the database contents.

A SQL injection attack hidden in encrypted traffic would look exactly like legitimate database traffic. All of the potentially incriminating attributes of a SQL injection transmission would be obfuscated if the packets are encrypted.

However, if the packets are decrypted, the incriminating SQL statement would be trivial to detect.The malicious code and escape characters included in the wrong fields would stick out like a sore thumb.

In Conclusion

Don't let impaired technology dictate and compromise your security posture!

Several network traffic analysis vendors who shall remain nameless are claiming that their machine learning technology can provide detections that are just as reliable without traffic decryption. The attack activities and major real-world attacks described in this post are just a small sampling of the reasons why these vendors are wrong.

Why don't they decrypt? Most just don't have the compute capacity to handle the workload of decryption and keep up with traffic. They may also lack the visibility into the L7 application contents, or the array of support for protocols that would make decryption worthwhile. So they tell you the limited parts they see are good enough, effectively deciding how aggressively you can detect, investigate, and forensically assess sophisticated attacks.

Every enterprise has sensitive data to protect, as well as critical applications and websites to keep secure and trustworthy. Using comprehensive network traffic analysis that is able to decrypt and identify common, yet sophisticated, attack behavior is an absolute must. You can't hand off your accountability, risk, and disclosure requirements to a third party. Don't let them dictate your security posture.

Learn more about the powerful decryption options you can take advantage of today in our Embracing Encryption ebook: download your copy here.

Related Blogs

Sign Up to Stay Informed