Sample Contents: cyber kill chain report

[Anonymous]

After having discussed a while ago in a few posts how complex scenarios can be accomplished by leveraging the flexibility of Security Analytics and customizing the product (Let's deliver some more value by customizing Security Analytics), I want now to present in a few articles some sample contents that may be used as a starting point to implement ad-hoc use cases within the different modules of the platform.

Let's start with reports and specifically with what can be achieved with the data stored in our concentrators and/or brokers (NWDB).

Very often, in a real production environment, simple reports just showing the top protocols or the risks found in the network are not enough. More and more users ask for complex and comprehensive reports, better if depicting a specific use case from different prospectives.

In such a situation, the signature-less approach of Security Analytics (especially when dealing with the network traffic) is ideal to spot a security issue out of the noise: the more indicators are pointing to the same direction, the more accurate the identification and eventually the response to a specific threat can be.

The sample report attached to this post is going exactly in this direction including many rules (29) which are going over the different phases of the cyber kill chain such as reconnaissance, break-in, lateral movement, data exfiltration and persistency.

For each phase, different rules try to highlight potentially anomalous/malicious scenarios. On top of those, the report includes also a Situational Awareness section (which can be useful to get an initial understanding of what has happened on the network before getting into details) and a Policy Violation section (to catch all the activities that are not part of an attack but related since violations of policies could weaken the security posture of an organization).

The table of contents of the report is the following:

• 1.Situational Awareness
  • Situational Awareness: Outbound Protocols
  • Situational Awareness: Outbound Protocols by size
  • Situational Awareness: Top Destination Countries
  • Situational Awareness: Top Destination Countries by size
• 2.Reconnaissance Phase
  • Recon: Port Scan Activity
• 3.Break-in Phase
  • Break-in: downloaded binaries
  • Break-in: Potential SQL Injection
  • Break-in: Top E-mail Subjects
  • Break-in: displayed domain mismatching
  • Break-in: Potential Mispelled Domains
• 4.Lateral Movement Phase
  • Lateral Movement: Remote Account Creation
• 5.Data Exfiltration Phase
  • 5.1.HTTP
    • Data Exfiltration: Cloud Storage Domains
    • Data Exfiltration: HTTP POST
    • Data Exfiltration: suspicious HTTP POST
    • Data Exfiltration: suspicious HTTP POST by size
    • Data Exfiltration: uploaded images
  • 5.2.DNS
    • Data Exfiltration: DNS queries by size
    • Data Exfiltration: long DNS hostnames
  • 5.3.FTP
    • Data Exfiltration: outbound FTP
  • 5.4.Other Protocols
    • Data Exfiltration: Outbound Bulk Data Transfer
    • Data Exfiltration: large ICMP requests
• 6.Persistency Phase
  • Persistency: unusual User Agents
  • Persistency: missing User Agents
  • Persistency: Outbound SSL VPN
  • Persistency: outbound unknown protocols
  • Persitency: anomalous traffic by countries
• 7.Policy Violation
  • Policy Violation; Outbound ICMP
  • Policy Violation: connections to sensitive networks
  • Policy Violations: Top User Agents

Some of the rules are depending over custom meta keys, lists and correlation rules. Specifically the report has the following dependencies:

• The direction meta to identify outbound connections (within the package or at )
• Correlation rules to identify port scan activities and data transfer (within the package)
• Reporter Lists (within the package):
  • legitimate dns server: to exclude legitimate DNS servers from the DNS-related reports
  • potential mispelled domains: to identify potential spear phishing attacks (if many entries have to be considered, go for a feed instead)

The package contains both the report definition, the dependencies and the report sample output (screenshot, PDF and HTML formats).

Credits for organizing the different phases and for articulating around specific rules go to our partner One eSecurity.

Disclaimer: please DO NOT consider what is described and attached to this post as RSA official content. As any other unofficial material, it has to be tested in a controlled environment first and impacts have to be evaluated carefully before being promoted in production. Also note the content I publish is usually intended to prove a concept rather than being fully working in any environments. As such, handle it with care.