Dive into Attack Flow with the OceanLotus Adversary Emulation Plan
Written by Maggie MacAlpine.
Attack Flow provides a model that helps defenders move from tracking individual adversary behaviors to tracking the sequences of behaviors that adversaries employ towards their goals. Attack Flows also help cybersecurity professionals understand how adversaries operate and can be rendered to visualize attacks for the benefit of low-level analysis as well as communicating high-level principles to management.
On October 12, the Center for Threat-Informed Defense published its latest addition to the Adversary Emulation Library with the OceanLotus Adversary Emulation Plan. This represents our first non-Windows focused adversary emulation plan, with an explanation of defenses from the perspective of the adversary. OceanLotus is a suspected Vietnam-based threat group that has been active since at least 2012. With a strong focus on Southeast Asian countries like Vietnam, the Philippines, Laos, and Cambodia, they are highly targeted when choosing victims, using strategic web attacks aimed specifically at their targets. [1]
This blog will use the Attack Flow Builder to walk you through the step-by-step process of building an Attack Flow for the OceanLotus adversary emulation plan.
Let’s get started!
Before we begin, here is a list of resources to help you follow along with the contents of this tutorial.
- OceanLotus Emulation Plan — For this tutorial, we’ll walk through the technical steps listed in the OceanLotus emulation plan.
- Attack Flow Introduction — Look here for a description of the Attack Flow data model.
- Attack Flow Builder — An open source tool for creating, viewing, and editing Attack Flows.
- More Attack Flow Resources — The Attack Flow website provides use cases, example flows, and a guide to best practices.
- OceanLotus Attack Flow — Here you can find the full OceanLotus Attack Flow used in this blog post.
Diving into Attack Flow
Emulation plans like OceanLotus are a great place to begin when familiarizing yourself with Attack Flow, as they offer step-by-step instructions that include each MITRE ATT&CK® technique. Attack Flow in turn offers an easy, standardized way to visualize those steps.
Tips:
- One strategy for laying out an Attack Flow like OceanLotus is to first create an Action for each Technique listed in the emulation plan, from beginning to end. Laying them out in the Attack Flow Builder can assist with keeping track of all the steps and provide a handy visual.
- From there, you can begin to link the arrows between the actions. Note that arrows indicate dependencies, not chronology. There are other condition options available, such as “AND” and “OR” as well as “TRUE/FALSE”, for clarifying how these actions are related.
- In addition to automatically filling in each Technique, you can also automatically populate each Action with its associated Tactic.
- Attack Flow is based on STIX, so if you have a tool that ingests STIX, it should be able to parse the domains, IP, addresses, files, hashes, etc. from your Attack Flow.
- Attack Flow offers an easy way to create clean, standardized images, examples of which are on display below. Simply select the boxes you wish to focus on and click “Save Selection as Image” found under File. This can be especially useful when presenting your Attack Flow step-by-step process in presentations to stakeholders and team members.
- When presenting your Attack Flow, be sure to check out the “Jump to Parent” and “Jump to Children” features by right-clicking on an Action. This will allow you to move seamlessly through the Attack Flow.
Step 0:
At Step 0, we already have options open to us as far as how to visualize the OceanLotus emulation plan in the Attack Flow. Those options are based on our target audience and goals for the Attack Flow.
Image 2 utilizes Conditions and Assets to visualize the steps in the emulation plan. This can be useful if your goal is to highlight specific vulnerabilities of a particular asset in your system, perhaps within the wider context of multiple threats to that asset.
However, separating out every asset can create visual clutter that could be distracting or confusing to your intended audience. Image 3 offers a simpler visual of the same steps described in Step 0 of the OceanLotus emulation plan.
Each Attack Flow is different, just as every organization and every audience is different and will have different needs. There are infinite variations on how to visualize a Flow, from the simple to the complex. Here we will stick to a relatively simple visual of the OceanLotus emulation plan but keep these options in mind as we move forward.
Step 1:
By now you may have noticed the “Confidence: Certain” note on each Action box. One feature Attack Flow offers is the ability to label each stage with a confidence level, ranging from “Speculative” or “Very Doubtful”, all the way to “Very Probable” or “Certain”.
The confidence feature is one that sets Attack Flow apart from most written emulation plans. In a written emulation plan, it might be unclear which steps are based on observed behaviors versus what is speculation. This can lead to wild conclusions or misunderstandings of an APT group’s capabilities. There is also the possibility that you have different intelligence sources with conflicting information, which might lead you to use other labels like “Doubtful”, “Even Odds”, or “Probable”. By making the level of confidence visually clear each step of the way, such misunderstandings can be avoided.
As this is an emulation plan, most of the steps will be labeled as, “Certain”. However, some steps of the OceanLotus emulation plan are based on speculation regarding the APT group’s activities; those will be labeled as, “Speculative”. Labeling these steps as “Certain” is an editorial choice. One could also label confidence levels as “Probable” or “Very Probable” based on underlying cyber threat intelligence (CTI), reserving “Certain” for scenarios with unambiguous evidence. This would depend upon one’s goals for the Flow.
You might have also made a note of the “Condition: True/False” feature at the top of Step 1. The use of True/False is optional in this case. It might be inherently obvious that a phishing attack only launches after the targeted user clicks on the link, and not require such clear visual enumeration. Here it is a stylistic choice. However, there are more complex flows where this option is extremely useful. For example, if OceanLotus was known to pivot to a different strategy if the user failed to click on the phishing link, a “True/False” condition is how you could show the branching paths.
Finally, you’ll see the “File” enumerated, branching off from “Embedded Payloads”. Again, this is an optional visual that might make sense for users with particular goals. For example, showing the file path might be useful when presenting to a SOC team so they can spot it easily.
Step 2:
Here in Step 2, you may notice that the “Confidence” level has changed to “Speculative”. This was due to gaps in the available CTI. When writing emulation plans, our team occasionally needs to insert steps based on educated guesses to produce a full, end-to-end plan. As you can see in the third column, there is no known reporting that OceanLotus uses these steps. As such, we’ve lowered the Confidence level to “Speculative” to make this clear visually.
We have also separated out the file paths as an example. Again, this is optional, but might make sense for your own Flow depending on your audience. In this case, threat hunters might find noting the file path particularly useful for use in mitigation efforts.
Step 3:
Here we broke out the Linux Server Asset for clarification, but this isn’t always necessary as breaking out each asset might reduce the clarity of the flow in some cases. In this case, one might choose to do so to enumerate when the attack has moved beyond the “hpotter” device or how it is used to launch later steps in the attack.
Step 4:
Here in Step 4, we have the first instance of using a Condition to clarify the flow. “System Information Discovery” and “Network Share Discovery” are not dependent on one another. The attacker can also use either one, or both, to move on to the next step, “Exfiltration over C2 Channel”.
Step 5:
In Step 5, we have an example of how one Action can lead to multiple subsequent but not dependent steps, both of which lead to Step 6: the successful exfiltration of the data.
Step 6:
Step 6 marks the completion of OceanLotus’s objective. In this step, they exfiltrate the targeted data.
What’s Next?
If you’ve made it this far in our walkthrough of Attack Flow, it’s time for you to try building your own!
- You can create your own copy of this OceanLotus emulation plan Attack Flow for hands-on practice. What other assets or conditions would you add?
- You can try building attack flows for other emulations plans published in the Center’s Adversary Emulation Library.
- You can build your own Attack Flow from the latest reports, like those put out by CISA.
Get Involved
We would love to hear about how you’re using our work! If you have any feedback or contributions you’d like to make to the project, please email us at ctid@mitre-engenuity.org or submit an issue via Github!
About the Center for Threat-Informed Defense
The Center is a non-profit, privately funded research and development organization operated by MITRE Engenuity. The Center’s mission is to advance the state of the art and the state of the practice in threat-informed defense globally. Comprised of participant organizations from around the globe with highly sophisticated security teams, the Center builds on MITRE ATT&CK®, an important foundation for threat-informed defense used by security teams and vendors in their enterprise security operations. Because the Center operates for the public good, outputs of its research and development are available publicly and for the benefit of all.
© 2023 MITRE Engenuity, LLC. Approved for Public Release. Document number CT0088
