A Deep Dive into the OceanLotus Adversary Emulation for macOS & Linux
Written by L. Piper and Cat Self.
Last week we shared a new OceanLotus adversary emulation plan. In this deep dive, we’ll touch on how and why we chose OceanLotus and then we will share a detailed walk-through of the of the emulation plan.
Open-source threat intelligence reporting shows that adversaries operate on macOS and Linux, yet cyber defenders lack tools and resources to emulate threats against those systems. Working in partnership Center participants including AttackIQ, Inc., CrowdStrike, Inc., Fujitsu, and IBM Security, we selected OceanLotus as a threat actor group to emulate with a goal of raising awareness of threats to macOS and Linux systems. This emulation plan will begin to give visibility into a less documented operating system and it’s our first emulation plan for offensive operations that includes a documented range setup.
Picking an Adversary
The clear and simple purpose for this project was to have an emulation specific to macOS and Linux. The original groups considered were Lazarus, FancyBear, and OceanLotus. However, to be an adversary worthy (and feasible) of emulation, our team asks the following questions:
Is there sufficient and recent open-source threat intelligence reporting?
We look for reporting that includes:
- Reverse engineering reports of implants
- Network traffic
- Coding patterns
- Lateral movement techniques
- Documented campaigns over a significant time period
Are the Tactics, Techniques, & Procedures (TTPs) relevant to the emulation objectives?
- Does this adversary have enough documented MITRE ATT&CK® techniques to span the entire cyber attack lifecycle? This is a question of the depth of open-source reporting available to us.
- Are we aware of enough clearly defined ATT&CK techniques from this adversary (especially for underreported areas) to complete an emulation on macOS & Linux?
Is there enough variety of TTPs to create multiple emulation plans?
This question addresses two obstacles we often face as adversary engineers: repeatable behaviors and reporting gaps.
1. Infection chains can include exploits. One of our goals is to provide an emulation that results in quality detection. This means we avoid exploits that can be easily patched and we focus on repeatable behaviors. This results in us asking, is there enough open-source reporting describing repeatable behaviors rather than exploits?
2. The second obstacle is the lack of reporting on behaviors after initial infection. This almost always includes lateral movement, privilege escalation, and hands-on-keyboard discovery. Our question is: Is there reporting specific to macOS or Linux lateral movement, discovery, or other post-exploitation behaviors?
What is unique about this adversary?
There are certain behaviors that an adversary “has to” perform to complete their mission, i.e., what is different about the way this actor performs when compared to another actor. This is much harder to discern and often takes conversations, analysis, and reflection on the patterns of behavior rather than an obvious answer. A starting point can be reviewing the implant structure, network packets, and targeted system services.
The results to our questions are as follows:
This left us with two groups to research and then re-ask the above questions. This led us to the last question we ask: what can we develop within the given timeframe that would be useful to the community?
- FancyBear was rich in reporting and covered the targeted platforms, however we didn’t feel we could do it justice with the amount of time we had available.
- The reporting on OceanLotus covered the required platforms and we could simplify a scenario that would allow for faster development.
After multiple discussions, some spicy debates, and lots of coffee, we decided on OceanLotus.
Who is OceanLotus?
When asking this question, a good place to start is the ATT&CK group page for OceanLotus (G0050). OceanLotus (aka APT32, SeaLotus, APT-C-00) is a suspected Vietnam-based threat group that has been active since at least 2012. The group has targeted multiple private sector industries as well as foreign governments, dissidents, and journalists. They are highly calculated when choosing victims, frequently using Drive-by Compromise (T1189) and Phishing attacks (T1566.001, T1566.002) aimed specifically at their targets. Geographically, OceanLotus targets the Philippines, Cambodia, Laos, Australia, Germany, US and Vietnam.[1][2][3]
OceanLotus Emulation Plan
A little background: This emulation plan was researched, developed, and tested over a two-and-a-half-month period. A big shout out to Melanie Chan for the OSX.OceanLotus development and Jared Stroud for the Rota Jakiro development. Based on reporting, both of these implants have been in development for at least three years with large development teams. As we mentioned earlier, we simplified the scenario due to the timeline and scope for this emulation. For those that want to dig into the details, at the end we provide context to what was prioritized for development.
The above diagram shows the operations flow of our emulation plan, starting on the macOS host and moving to the Linux host. Below we detail an assumed breach scenario used in this emulation plan. For a detailed playbook of commands and code executed, reference our Emulation Plan in our GitHub repo.
So it Begins…
It all started with a double-click….
1 — Hope Potter downloads OSX.OceanLotus, which is a macOS application bundle disguised as a Word document (T1566.001)
2 — Hope double-clicks the bundle (conkylan.app — unicorn in Vietnamese) resulting in the execution of a bash script inside the Application bundle (T1204.002). The bash script drops three additional files; .plist file, .dylib file, and a Mach-O executable (T1059.004, T1027.009).
3 — The bash script then executes the Mach-O which connects with the C2 server using network communications .dylib and sends the local host information to the C2 server (T1129, T1082, T1071.001, T1041).
4 — Once a connection is established, the implant is tasked with conducting discovery of remote services used on the host, in this case SCP & SSH (T1083). Turns out that Hope is a developer that helps manage a file server in the environment and connects to the Linux server using a non-password protected SSH key.
5 — The implant is then tasked to download a Linux backdoor, Rota Jakiro, to the macOS host, then SCP Rota Jakiro to the Linux host and execute it (T1078.003, T1021.004, T1570).
The remaining actions are performed on the Linux host illustrated in Figure 3.
6 — After execution, Rota Jakiro establishes persistence using two auto-run files: a desktop environment file (.desktop) and a shell profile configuration file (.profile) (T1547.013, T1546.004).
7 — Using native API calls and process information, Rota Jakiro configures the processes to monitor each other via an entry in shared memory, using one process to respawn the other if it dies (T1106, T1057).
8 — Rota Jakiro then collects system information and sends the information to the C2 server (T1082, T1041). To detect mounted drives and files of interest, Rota Jakiro downloads and executes shared object files to detect mounted drives and files of interest (T1105, T1129).
9 — Rota Jakiro then exfiltrates the zipped file of interest, mission accomplished(T1041).
The End.
Building a macOS environment
We also wanted to make it much easier to setup a macOS environment for adversary emulation. Enter our hero Michael Butt. Michael built out Terraform scripts for easy deployment of our macOS environment to make it easier to execute our emulation represented in the below diagram.
You can find the set up scripts for our AWS environment configuration here. (Please appreciate the awesome dragon theme from Game of Thrones. You’re welcome.)
The Technical Bits
During this project we faced tricky questions with no clear answers. Let’s be honest, open-source reporting leaves a lot to the imagination. For most of these questions, the answers only came after we had spent time with hands on the keyboard.
Below is a breakdown of the questions we faced, and how we chose to answer them. We saved the best for last for those of you that like to read.
Is Rota Jakiro software developed by OceanLotus?
In April 2021, Netlab 360 released a report on a newly discovered Linux malware. The report reviewed the samples evolution from 2018 to 2021. Based on community feedback pointing to OceanLotus, in May 2021 Netlab 360 released a second report comparing the 2017 sample of the macOS OceanLotus software reported by Palo Alto to the 2021 discovered Rota Jakiro Linux software. Although there is limited reporting on attribution of this sample, the Center research team felt confident to include Rota Jakiro as a part of our emulation based on the technical analysis of this report and community engagement.
To $root or not to $root?
Often on Linux systems, an adversary does not need root level permissions if the user or service has the needed permissions to accomplish the objective. In researching Rota Jakiro, we saw different implementations of persistence based on root and non-root users. We found that the non-root implementation offered more interesting techniques, so we chose to implement the non-root user persistence. This method leverages two auto-start scripts, the user’s desktop environment file (.desktop) and a shell profile configuration file (.profile). Once executed, these two processes monitor each other and re-execute the other if one process dies using Linux native API calls.
Which version of OSX.OceanLotus do we emulate?
When we first set out to emulate OceanLotus we were excited to have a macOS implant with solid technical reporting over several years. However, the conundrum that every adversary emulation engineer often faces with an implant reported over time, what version should we develop?
OSX.OceanLotus ended up being a bit more confusing. Although the reporting seemed detailed, each year the new report focused on the dropper rather than the core implant. We were often left wondering, is it possible OceanLotus is using the same implant in 2020 that was reported in 2017?! To avoid going down any rabbit holes, we put this question aside for now and focused on prioritizing what we cared about for the emulation. We asked ourselves, what techniques do we care about the most? We wanted techniques specific to OceanLotus that would benefit Blue Teamers if emulated. With this in mind, we reviewed open-source threat intelligence to identify trends in OceanLotus’ TTPs. For example, in 2017, a Unit 42 report described a macOS implant very similar to a Linux implant discovered in 2021 by NetLab 360 called Rota Jakiro.
- These implants both modularize their functionality using Shared Modules (T1129)
- OceanLotus & Rota Jakiro use the same hex value command IDs to execute a shared module or plug-in 🧩 (command IDs: 0x25D5082, 0x1B25503, 0x1532E65)
Reports from 2018, 2019, and 2020 discuss the OSX.OceanLotus implant from two separate cyber security vendor blogs (Trend Micro & ESET).
Key changes to this implant:
- Uses a 1-byte command code
- Uses scripts as the primary dropper
The shared modules technique was described in both the 2017 macOS report and the 2021 Rota Jakiro report. Currently, there is no telemetry capturing the .dylib or .so files executed in a running program unless you capture the file on disk. This was the motivation we had for prioritizing the 2017 macOS report and the 2021 Linux report in order to provide a CTI based emulation for this technique. This technique will be released with the 2023 October ATT&CK update!
What if the OS is too old to be relevant?
Do we build on an old OS or spend additional time and resources to research developing on a newer OS?
Before we began this project, we agreed that when making a tough call, our default question is, what does CTI say? Therefore, our default answer for this tough decision defaulted to what CTI said: develop on macOS Catalina 10.15.7. When in doubt, base it on CTI.
A couple of days later….
To fill in gaps we reviewed behavior patterns throughout reporting. Here is what we found in vendor reports:
- 2017 — OceanLotus does not leverage scripts
- 2018 — OceanLotus uses a Perl script
- 2019 — Commands are executed with /bin/sh
- 2020 — OceanLotus uses a bash script to handle most of the initial execution
After seeing the increased reliance on scripts over the years, we decided to implement the 2020 usage of a bash script for our primary dropper inside our Application bundle. It was a very happy surprise that adopting this pattern gave us insight into why OceanLotus adopted scripts. It turns out the implementation of bash scripts enabled us to execute the implant on Catalina and on macOS 13 Ventura.🥳 🎤
Although this seems like an easily detectable technique, scripts are executed by almost every legitimate application in the macOS ecosystem, resulting in a significant amount of noise to blend in with. It turns out that we had nothing to worry about with an old OS. We just need to emulate the adversary and they will address that concern for us. 😹
This is the first macOS emulation that is publicly released. We faced a lot of obstacles, but not nearly as many as those that came before us. Thank you to those that took the painstaking efforts to make macOS accessible:
- AWS & macOS Endpoint Security Teams creating a macOS cloud environment
- Researchers that published blogs so we understood the adversary
- Analysts that put the pieces of multiple operations and actions together in a repeatable plan
- Analysts from all over the world that translated binary into words
When charting new waters, sometimes our boat feels so small in the vast ocean. But this project showed us that there are friends in this vast ocean and they helped us navigate these tricky waters. Thank you.
Where do we go from here?
Now that we have released our first macOS and Linux emulation plan, we want to know what the community thinks. We hope you will head to our repository and take the plan for a test drive to see if it can be a valuable security tool in your macOS environment. If something isn’t working for you, or you have suggestions on how to make it better, we’re all ears at ctid@mitre-engenuity.org
- Grab an issue and fix it. We encourage the community to contribute emulation code & fix bugs in our repository, that is if you can find them. These issues can range from helping us fix broken links to implementing components of an emulation plan that we did not have time to develop.
- Contribute open-source intelligence. For the first time, we have an avenue for the community to contribute research on a specific threat actor to the adversary emulation library. We are currently limiting this to the OceanLotus threat actor to try out this process. This information helps us emulate an adversary better through providing research that fills in the reporting gaps we discussed earlier. As research can be sensitive in nature, check out our Wiki for more information on how we hope to address this factor.
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. Approved for Public Release. Document number CT0084
