What Am I Supposed to Do With This Threat Intelligence?

Summary

A business associate (responsible for enterprise defense) recently recounted being handed a vendor report that detailed a threat actor’s name, pictures, location, and responsibility for attacks unrelated to my associate’s organization. My associate responded, “What am I supposed to do with is? Call Liam Neeson?”

Business-minded security leaders interested in the concept of threat intelligence frequently ask the question, “What am I supposed to do with this intelligence?” It’s a good question. The following is our answer, devoid of vagueries, and instead focusing on specific examples to illustrate three salient points — that useful threat intelligence:

Immediately improves operational security.

Supports and enhances business decisions.

Helps prioritize strategic security controls.

Introduction

The goal of investment is to decrease operational risk (and possibly establish a competitive advantage). Frameworks like ISO 27001 or NIST CSF are critically important because the INFOSEC body of knowledge is massive. It’s a compendium of 30 years worth of expertise and leading practices distilled into an outline for practitioners to reference and measure against ongoing progress.

Thus, a substantial piece of any security program involves governance, and rightfully so.

A threat-centric security team is, by definition, already supporting comprehensive execution of governance goals (based on prior threats and security knowledge), and believes that timely and relevant threat intelligence will achieve improved efficiency in reducing operational risk. These security teams conclude, and history has proven, that regulatory compliant businesses are frequently breached and suffer a multitude of consequences related to the failure of confidentiality, integrity, and availability of information.

To migrate from a governance-driven model to a threat-centric security organization is a business decision that impacts areas beyond the security team. New resources are required to support a successful threat-centric program. For those enterprises considering adding a threat intelligence capability, the following are tangible and measurable outcomes which will accelerate the security improvement cycle, instead of waiting for the next, outdated version of legislation or compliance framework.

Immediate Operational Security Improvement

Analysts and pundits love to declare, “threat intelligence needs to be actionable.” In the same breath, and with much disdain, comes the follow-up, “IOC feeds are generally useless.” The first statement hinges on “actionable” or “contextually relevant.”

Ironically, the best examples of directly “actionable” intelligence are the by-products and metadata resulting from attacks that occur outside of the enterprise.

These low-level artifacts should be correlated with internal telemetry (logs) to identify previously unknown compromises and to generate new security control rules. The firewalls, NIDS, HIDS, web proxy technologies, etc., generally rely on rules. Applying new rules to these devices based on external attack data before the enterprise is victimized by a similar attack is the definition of “proactive” and “actionable.” This ability to correlate is not an advanced capability, rather it’s an extremely basic task that forms the baseline for future growth, maturity, and integration of tools like machine learning.

Choosing the right attack information sources is an important part of operational improvement. External attack indicators may originate from the web/open source, processed malware, active scanning, passive network collection (deception), and/or human/closed sources. They all have their own merits, and the uniqueness and visibility of the source correlates to the number and/or value of new incidents identified and control rules created.

For example, autoshun.org is a web source of aggregated indicators of compromise (IOCs) that represents the knowledge previously unavailable to an enterprise that is only monitoring its own logs. New Snort rules (Snort is an open-source, free, and lightweight network intrusion detection system [NIDS]) should be generated and counted based on the collective insight.

Autoshun.org is an open resource for operational security control improvement via Snort.

Similarly, Critical Stack offers a free service that delivers updated Bro rules (Bro is an open source, UNIX-based network monitoring framework) based on the company’s collective insight.

Finally, updating DNS RPZ is an effective security control to implement after all open source threat feeds have been identified and summarized; DNS RPZ may also help identify the corresponding authoritative nameservers serving malicious domains.

Proactive information collection turned into operationally useful intelligence is not confined to open source technologies like Snort, Yara, and Bro. There are plenty of commercial security solutions that can leverage an API; it’s the flexibility of form and delivery that is crucial for enterprises to identify.

Support and Enhance Business Decisions

To demonstrate business decision support we use Recorded Future — a SaaS product that presents real-time analytical summaries through search of, and alerting functions for, unstructured text across thousands of web sources, using natural language processing in seven core languages — to surface threat actor tactics, techniques, and procedures (TTPs). Below are a few examples of DDoS services and tools that Recorded Future identified between March 7-9, 2016, and the related original information sources.

Recorded Future table of DDoS entity results for March 7, 2016.

Recorded Future table showing a specific Russian forum advertisement.

The forum advertisement corresponding to the above Recorded Future reference.

Recorded Future DDoS reference (via an entity alert) leads to the Jankens DDoS service advertisement on Pastebin.

In this first example, if a business decision maker is struggling with the cost of outsourcing DDoS mitigation services, then presenting data points related to verified adversary capabilities and intent in the relevant industry vertical is valuable because it improves the process and outcome. The data should also include comparisons of defensive control solutions and an assessment of financial investment vs. specific threat level compared to competitors in the same industry.

Evaluating all known DDoS (or “booter” as they are known in the Underground Economy) service advertisements annually for veracity and true capabilities as well as successful attacks in the same industry vertical (and all industries generally) translates into a valuable report full of data points to illustrate trends.

Are DDoS attacks diversifying technical methods?

Is the efficacy of specific denial-of-service attack types increasing? What are the preferred DDoS attack types?

What are the available defensive control options?

What are their respective proven success rates?

What’s the likelihood of being targeted by a denial-of-service attack?

Armed with this data, an informed business decision can be made on maintaining or upgrading associated defensive controls.

A second example involves PowerShell. The accelerated and creative development of open source tools and methodologies that leverage Powershell for post-exploitation persistence, lateral movement, and privilege escalation are a constant threat to enterprises that need PowerShell for legitimate information technology functions.

Recorded Future table showing April 2016 results for PowerShell.

As the forum post above illustrates, blocking PowerShell is a non-starter for most organizations. The INFOSEC team must present a strong business case for exploring and prioritizing new security controls to mitigate the risk while still allowing PowerShell functionality. A good threat intelligence resource can quickly summarize a large amount of data points to articulate the imminent and persistent business need to address a constantly evolving threat like PowerShell.

Recorded Future table showing April 2016 results for Powershell and Mimikatz.

The red team can subsequently create and test realistic post-exploitation attack scenarios and measure current security control efficacy. The security architecture team will build and implement the corresponding controls, but threat intelligence is the originating catalyst and recommendation for resource allocation to further understand the implications of the PowerShell threat to the business.

Altering access to PowerShell or removing PowerShell permissions on workstations across an entire enterprise or even specific segments will have an enormous impact that may be difficult to fully measure. IT support and incident response may require more human and financial resources to cope with the loss or reduced functionality of PowerShell, but the IT administration team may also experience decreased morale as a direct result of a new PowerShell security control that they view as draconian or unnecessary. Measuring an intangible like morale is difficult, but it’s part of the business decision process.

In this example, timely and comprehensive threat intelligence related to PowerShell enhances the ultimate business decision for corresponding controls, and also provides a powerful narrative to share with the business to transform potential skeptics into advocates and collaborators for well researched security improvements.

Prioritizing and Improving Strategic Security Controls

Within any security team exists an ongoing dialogue about security control improvements and the corresponding strategic resource prioritization. Using NIST’s CSF as an example, which function should a CISO prioritize: identify, protect, detect, respond, or recover? A threat-centric security team identifies macro threat trends and micro adversary tools and behaviors to prioritize security control changes.

Further analysis reveals a macro trend of remote compromised device access being commoditized and sold as proxies for malicious activities. The trend itself is not new, but perhaps the adversary tools or methodology are changing.

In addition to potentially prioritizing RDP/VNC access control, additional alerts lead to a Python script used for checking the availability of known proxies. Further exploration leads to a comprehensive list of known Chinese proxy nodes which should be integrated into a security control access list and/or shared with a customer-facing fraud team.

Additionally, the identification of adversary behaviors and TTPs observed around these remote access mechanisms is important for modeling attack scenarios that mimic the same toolchains.

It’s easy to assume that vendors are preventing specific attacks, but providing strategic intelligence to the incident response/penetration testing/red teams facilitates a true test of security control efficacy, and often the results will surprise.

Further, the Chinese proxy lists should be shared with the security architecture/authentication and customer fraud teams to increase log event correlation and alerting. Increased visibility into potentially malicious tactics and infrastructure benefits different pieces of the security program.

Python script designed to poll a list of proxies for availability.

Extensive list of open proxy nodes discovered on a Chinese speaking forum.

In this case the search for adversary RDP/VNC TTPs leads to an unexpected discovery around proxying connections that is also valuable strategic intelligence to share with the business as previously discussed with peer teams in enterprise information security.

Chinese language tutorial on editing the Windows registry subsequent to remote desktop protocol access, specifically using the host at 61.143.160.181 (China Telecom) in this example.

Making changes to the ServiceDLL registry key.

First reference of IP address 61.143.160.181.

A summary of known open source information about the victim’s IP address (61.143.160.181) reveals potential malicious use beginning two years prior to the tutorial post.

Additional Recorded Future alerts related to criminal services leads to the identification of a potentially new dynamic DNS (DDNS) provider being used to host a criminal marketplace. The DDNS provider’s domains represent an opportunity to improve security control efficacy. Specifically, the nameservers for uas-store[.]ru (31.184.234.191) are ns1-ns3.entrydns.net. Entrydns appears to be a legitimate DDNS provider.

The second example involves Recorded Future leads surfaced from Chinese language tutorial documents referencing MassBleed and Bdtunnel. Both are open source tools released in 2014, but their inclusion in suspicious tutorials should signify increased threat actor intent and/or capability.

This specific intelligence should be provided to adjacent security groups and it should reinforce prioritization around SSL vulnerability remediation, access control, and information protection processes and procedures.

Recorded Future timeline showing two years of MassBleed references

Recorded Future table showing Chinese language tutorial on using MassBleed.

The third example relates to NLP alerts for new threat actor tools. The 16 line Javascript SQLi DDoS V2 script and Legionnaire.py are both new. Their respective code should be provided to the vulnerability management, penetration testing, and/or red team for proactive consideration to specifically understand how existing security controls will fare in production testing and where (when applicable) the gaps exist to share with the security architecture group for prioritization and remediation.

Recorded Future reference (via an entity alert) leads to Legionnaire hosted on GitHub.

The fourth and final example illustrates monitoring for previously undetected breaches that may impact customers. Substantiated information about unauthorized access to a database should immediately trigger predefined remediation processes.

Index of compromised databases.

Conclusion

A threat-centric security program complements and accelerates a mature GRC (governance, risk, and compliance) program.