Working in Graphs

As an attacker, I can only think of a small number of engagements where the path to our objectives looked even remotely like a chain. In most of those cases, we were re-establishing access to a familiar environment. In a few others, we just got lucky (e.g., a domain admin happened to have an active session on our initial access point).

If you create a graph of an attacker's actions you end up with something that looks very organic, a bit like a growing tree. The branches divide (and occasionally rejoin) before eventually converging on the nodes related to the attacker's objectives.

There is a great quote by John Lambert of the Microsoft Threat Intelligence Center:

Defenders think in lists.
Attackers think in graphs.
As long as this is true, attackers win.

As an attacker, I absolutely love this quote. However, most of the defenders I know are able to think in graphs. So why do defenders often think in lists? Also, what about lists is so bad? Lists can be especially useful tools (attackers use playbooks all the time).

I think the source of the list mentality (and resulting hatred of it) has a lot to do with the structure of audit reports and ticketing systems and less to do with any individual's propensity to think in lists or graphs. The biggest advantage graphs have over lists is the preservation of relationships between nodes. List based reports and ticketing systems tend to strip out context, and, in information security, the context of information is often just as important as the information.

Here is a remix of John's quote:

Defenders work in graphs.
Auditors report in lists.
As long as this is true, attackers win.

So what can we do to help address this?

Call to Action Based Reporting

Ideally, all actions and findings could be presented in an interactive graph of the environment, complete with the relevant network, system, user, and data assets. While web-based reporting may eventually make this dream possible, the industry has not really moved away from PDF, Excel Spreadsheets, and Ticketing Systems (and probably won't for a while). Until then, I believe using Action Based Reporting instead of Findings Based Reporting will help defenders maintain context and better apply the report content to graphs.

The Kill Graph

Kill chains remind me of the Texas Sharpshooter that fires at the side of a barn several times and then draws targets with the bullseye centered around each hole. Trimming all the branches of an attack to create a kill chain makes the attacker appear surgical and almost impossible to stop. It also removes key information and opportunities for positive feedback.

Instead of documenting the "Kill Chain", the use of a "Kill Graph" will help restore context. It sounds a bit weird, but I think the terminology switch is helpful. There are many ways to structure a "Kill Graph" (e.g., assets as nodes and actions as edges, or vice versa). A good graph keeps as much context as possible and avoids eliminating dead ends.

OJAR Narratives

There is a pattern I often use for writing report narratives. I believe it has helped me present actions (and the relationship between actions) in a more graph-like way, even when forced to use a linear narrative:

• Objective: Describe what the actor wanted to accomplish.
• Justification: Explain the benefits (and when appropriate, risks) of attempting to achieve the objective.
• Action: Describe the actor's actions.
• Result: Describe the results of the actions.

While this pattern is not a perfect template, intentionally adding actor Objectives and Justifications help the reader maintain context by relating the current set of actions to prior, parallel, or future actions. Here is an example of text used to report a set of active-recon actions (with each part labeled):

(Objective) Redox Security wanted to identify externally facing login forms that do not use two-factor authentication. (Justification) Single-factor login forms are often vulnerable to brute-force attacks and provide a way to validate credentials discovered in public-breach data. (Action) Redox Security used Wfuzz, a web-application bruteforce tool, to search all previously discovered web services for possible logon URLs. To reduce network traffic, Redox Security configured Wfuzz to use a two-second pause between requests. (Result) Wfuzz received '200 OK' responses for 15 URLs and received various error responses for another 2065 URLs. (Objective) To test if the 15 discovered URLs contained valid login forms, (Action) Redox Security manually reviewed each URLs and (Result) found that they all contained valid login pages. (Objective) To check for the presence of single-factor authentication (Action) Redox Security attempted to login to each page with an invalid username and password. (Result) Of the 15 pages, three returned an "Invalid Username or Password" response without prompting for an additional factor.

Actions at the Root

Lists are incredibly useful tools. They are easy to follow and repeat. Because of this, reports often treat findings (or the lack of findings) as the basis for the narrative and the root-level items in lists. While this may seem efficient, this approach can quickly eliminate context.

While there is nothing wrong with providing a list of vulnerabilities or findings, the root of lists is usually not the best place to put them. Instead, where possible, use actions as the root items and list any findings as child items. This helps maintain context and creates a more graph-like data structure. By focusing on actions first, vulnerabilities are presented as tools that an attacker chooses to leverage as they move towards a set of objectives. Not all actions are successful or have noteworthy security implications, so some actions may lack child items.

The following shows how findings from the previous narrative example can be structured (note that the finding details are intentionally excluded). This is still a list, but, compared to most findings lists, this action-first list holds more context and preserves key relationships between findings:

• Action: Redox Security reviewed publicly exposed breach data for Client credentials.

  • Finding: Redox Security found twenty-three credentials related to Client domain in public breach data.

• Action: Redox Security performed web-application discovery of login pages using Wfuzz.

  • Finding: Client Web Application Firewall did not block the discovery scan.
• Action: Redox Security manually reviewed discovered login pages.

• Action: Redox Security provided invalid credentials to 15 Client login forms in a ten-minute window.

  • Finding: Three login pages check credentials without the use of multifactor authentication.
  • Finding: Failed logins across multiple external websites did not trigger defensive actions.

• Action: Redox Security attempted to use previously discovered credentials against login pages without multi-factor authentication.

  • Finding: Two users use weak or previously compromised credentials.

Focused Exercises

After writing the report for several large Red Team engagements, I remember having a sense of pride at the length (often 500+ pages) and sheer amount of detail included in the reports. However, I found that these reports regularly overwhelmed defenders. To cope, defenders often jumped right to the lists at the end.

Large and detailed reports are often necessary for large engagements. However, Redox Security believes there is a better way to structure security exercises. While greatly limiting scope is almost always counter-productive (malicious attackers don't care about your scope), focusing it is very helpful. Focused exercises lead to reports that are easier to manage and understand. Running many small and focused exercises is generally better than running one large, broad exercise.

Data-Driven Reporting

The ability to traverse graphs in many ways is one of their most powerful properties. While this feature is great for analysis, it does not easily translate to linear reports or finding tickets. Flattening the graph creates lists. However, unless the connections between items is preserved, lists do not easily create graphs. Because of this, I think the industry needs a graph-based data model for security reporting. I believe it is possible to create a reporting data model that can be shared by both offensive and defensive teams. If a standard is created and agreed upon, it will facilitate automated consumption of security reports into various SIEM and ticketing tools and may help improve reporting for BAS like services. While I have a lot of ideas around this topic, I believe trying to reach a standard without broad community support will lead to failure. If you are interested in helping create a standardized data model for security reporting, please reach out to me at tivey@redoxsecurity.com.

Conclusion

Lists have their place in security, but they tend to strip out context. The use of focused security exercises with action-based reporting will help defenders better manage complex graph-like environments and will further reduce the kill-chain (list) mentality.

Credit

Post Image Photographer: @valiphotos