RPE-012: The Finches Across the Islands

Events

RPE-012: The Finches Across the Islands

Schedule:

• 8 June RPE announcement is made public
• 7 August Last Date for Offense Teams to Sign Up
• 10 August Start of Try-Out Round
• 21 August End of Try-Out Round
• 28 August Offense teams notified
• 28 August Last Date for Defense Teams to Sign Up
• 15 – 17 September RPE Main Event
• 30 September Results Provided

This schedule is subject to change. If we have enough defensive teams, we may choose to evaluate a second set of teams separately using the same exact modified samples from the offense. We will notify defensive teams of a second round of evaluation should this be required.

---

Description

During October and November of 1835, the HMS Beagle brought Charles Darwin to the Galapagos Islands as a stop-over during a five-year voyage. While on this voyage, it is written that Darwin was invited by Captain Robert Fitzroy to contribute to the natural history portion of the captain's account of their travels. As many know, it was during this time that he made the initial discoveries of the variety of the Finches that inhabit the islands and the variety of size and shape of the bird's beaks and overall body size. He recorded his initial reactions in his diary which was later released as the book titled 'The Voyage of the Beagle' first published in 1839. He would then go on to later write about his newly developed theory of natural selection as the process by which each subspecies of finch evolved over time adapting to their specific environment allowing them to find and consume food specific to the island they inhabited.

Instead of finches, how about malware infecting our networks?

Darwin theorized finches evolved to find food unique to the island they inhabited. As each network also presents unique mappings and environments, malware also evolves driven by the desire to achieve their successful effect or consequence. Malware infections or infection attempts can vary wildly within disparate networks or a single host (when examined over time) as attackers consistently write new samples or modify existing to escape detection. While Darwin presumably spotted these birds with good old-fashioned patience and the naked eye, the common method used to today to spot infections or attacks within the computer network is to use an intrusion detection system (IDS). Consider the following IDS rule to alert on an infection of the Petya strain of malware:

alert smb any any -> $HOME_NET any (msg: "ATTACK [PTsecurity] Petya ransomware perfc.dat component"; flow: to_server, established, no_stream; content: "|fe 53 4d 42|"; offset: 4; depth: 4; content: "|05 00|"; offset: 16; depth: 2; byte_jump: 2, 112, little, from_beginning, post_offset 4; content: "|70 00 65 00 72 00 66 00 63 00 2e 00 64 00 61 00 74 00|"; distance:0; classtype:suspicious-filename-detect; reference: url, github.com/ptresearch/AttackDetection; metadata: Open Ptsecurity.com ruleset; sid: 10001443; rev: 1;) ¹

Consider if this example rule works for all 'birds' we may encounter on a network. Will all variants or species of Petya that hit the network be identified by this 1 rule or will they require writing new rules for each infection variant? How well evolved is the sample that may or already has hit me? Conversely how well written is the rule?

Now consider the attacker's perspective. Should the target tool, for an attack, be written from scratch or modified from an existing tool? Should the author (attacker) utilize encryption in their communication? Is the communication (e.g. command and control (C2)) predictable (even through the encryption layer)? If the attack tool is modified, what degree of variation must be achieved to avoid detection? What about multiple iterations (e.g. multiple campaigns or sites) of the same sample, can a single IDS rule identify them all?

Our next Rapid Prototype Event (RPE) tests these questions. This competition pits two sides of the 'room' against each other on offense versus defense. We are looking for both attackers and defenders to answer the following questions:

• Can an attacker start with an existing sample and modify it, so the two variants are not considered alike by an IDS rule when communicating across the network?
• If so, how quickly?
• Can they modify a binary sample or source code with an automated process?
• If so, how quickly and what languages do they support?
• Can a defender write an IDS rule for a sample (Zeke, Suricata or Snort) based on network capture of an infected host (and a copy of the original sample)?
• If so, how quickly?
• Can the defense-written IDS rule catch modifications of the original infection if they know more are coming?
• Can they modify their rule to catch multiple samples (given copies of the modified and original)?
• If so, how quickly?
• Can a defender modify their network analysis tool with new rules, settings or features and avoid writing an anomaly detection rule entirely?

Offense Try-Outs

For this event, we will hold a remote try-out period to teams to participate in our final event. This process will play out as follows:

Round 1: Each offense team will be given access to the source code repository of a malware (and C2) sample produced by DreamPort (written in C) and an IDS rule (we will specify which open source IDS system we use) that can catch said sample when communicating with its C2 server. You will need to modify this sample as rapidly as possible to evade detection. Remember, we are searching for an automated system to modify samples. After a set period (limited time), we will hold a remote screen-sharing session wherein you will be required to prove your work by doing the following (while we watch):

• Compile the original sample and produce a working setup of the sample on an 'infected' host, a C2 server and an IDS monitoring traffic.
• Run the original sample invoking at least 1 malware function via C2 to prove you can compile and execute a working copy of the sample.
• Demonstrate the files have unique hash values and timestamps.
• Monitor the IDS (which we specified) loaded with the rule you were provided to ensure the communication is caught.
• Modify your sample using your automated tool or approach. For this round, we are expecting people to have modified the sample in advance, we are not foolish.
• Run your modified sample invoking the same C2 feature and prove the modified sample was not caught.

Offense teams participating in this round will be given 7 days from the release of the malware source code to accomplish this round. We will release the source code and compilation instructions; you must provide your own environment to build the sample. Each remote collaboration session will take place in a single day and within two hours of each other to minimize unfair time (to work) discrepancies between each team. If you fail round 1 you will be disqualified from continuing.

If there are enough competitors, we may choose to execute a second round. If so, this round will play out as follows:

Round 2: Each offense team must repeat round 1 but produce 3 modified samples that accomplish the same features but will be done using a different but still single starting sample. While the original sample for this round is expected to be caught once again, we are looking for a repeatable process for the 3 copies that ensure they are not caught when invoking the same feature. If you successfully pass both rounds, we will invite you to participate in our final event. We are planning to hold the final event remotely.

What Does 'Modify' Mean?

It is important to be clear about expectations from the offense. The goal is to find an offensive team and product or process that can automatically modify a malware sample to change the network signature such that a single IDS anomaly rule (compiled or source) that detects an original copy does not trigger on the modified copy. We are looking for automated or semi-automated processes not smart highly caffeinated people. If you think you are offense material, you should carefully consider this. First while the preference is to find a product that can parse an executable or script to insert modification of behavior automatically, we will accept a process that requires access to source code. Second, you should consider changing the following:

• The encryption algorithm or encryption parameters in a C2 message.
• The timing of invoking the C2 function.
• The actual data payload of each packet sent/received in a single C2 function.
• The upstream location of the C2 services.

We do not expect or want a modification process/tool to ONLY change the location of the upstream C2 asset. This is a solved problem that requires DNS trickery and not much else.

What About the Defense?

We do not plan to hold defense try-outs. Instead, we will release the same malware sample that we are using for round 1 of our offense try-outs and encourage you to experiment with the sample and C2 server to see if you can write your own IDS rules or if you bring a product, modify your training or configuration data with said sample to ensure it is caught. During our final event, we plan to let a maximum of 4 defense teams sit on our cyber range at a time while malware infections are launched. Each team will have access to the same computing resources and may create their own virtual machine images or snapshots to run the open-source tools they wish. They must first prove they can setup a functional IDS system (or their own product) on this network from a tap port and catch the original malware sample traffic we release in advance.

If your technology is not open source based, you must be prepared to supply your own rules or data to power your network monitoring feature. DreamPort will not supply any data other than the malware sample. You are strongly advised to bring expertise that can write IDS rules or if you have proprietary rules, they will remain your property and no team or DreamPort person will access them. You will need to ensure this proprietary technology can be updated or retrained on the fly. Your technology will have Internet access in the event you utilize cloud services for augmentation of your capability but know this cloud communication will be part of the network traffic capture thus will be viewable by all teams.

The Main Event

The execution of this RPE is planned as a virtual event at DreamPort (due to the ongoing COVID-19 pandemic). We anticipate this to be a two-and-a-half-day event from 0900 to 1700 EST where setup occurs on the first day. We may extend the time of execution should participants be willing. We will be utilizing one of the cyber range systems donated by our valuable partners as the execution environment. At this time, our plan is to provide a network which will consist of the following assets:

• Windows 2016 Active Directory Domain
• Windows 10 desktops
• 5 or fewer Windows 7 desktops
• Debian Linux Servers

This environment will contain the following security services:

• Centralized Syslog
• Centralized Windows Event Collector
• Elastic Search/Kibana (aggregating all the logs from the previous two systems)

Defense teams must provide their own IDS system (or proprietary technology) installations and rules or configuration data as a virtual machine or software to augment this environment. Teams will be given 75 minutes from first access within the environment to ensure their technology stack is setup to their liking at which point a snapshot of these assets will be taken from the powered off state. Once their time 'in the box' comes, we will restore this snapshot and the attacks will start. As a defender you will receive a network map, but this will not be 100% accurate.

At the same time, offense teams should be preparing for their attacks. In addition to the first sample used in the offense try-outs (the first one of which defense will have a copy), we will release up to four additional samples on the first day of the RPE. These malware samples may be in any of the following languages:

• C/C++
• Java
• Python
• Go
• Rust

The source code for the C2 services that drive these samples will not be made available. Before anything happens, you (as the offense) will be provided an unmodified compiled or ready for execution copy of each sample to DreamPort to serve as a baseline of subsequent comparisons. DreamPort personnel will tell you which sample to use in which round.

Once this is done, the real fun will start. As an offense team, you must provide your own VPC asset (out on the Internet) to execute C2 communications with your sample, and we strongly encourage you to use firewall or filtering rules to only allow access to/from the DreamPort main IP address and any offsite locations you will use. You are strongly advised to use a VPC asset as the malware C2 function must work (and not result in an HTTP 400, 401, 404 or 500 error) and should ideally be hidden among normal background traffic of a Windows network. When you are alerted as the offense, you will have 60 minutes to modify a sample (from the baseline you provided) and provide the modified sample and corresponding C2 server information to a DreamPort engineer. This means you must also setup the C2 server or already have it setup and ready prior to turn-in of your sample. You must provide instructions to the engineer to show them how to run your sample, the command line, the parameters, or configuration file etc. If we can't run the sample, you are not part of that round.

DreamPort will ensure that anti-virus (AV) assets (including Windows Defender) are disabled for this event. The DreamPort engineer will have Administrator or root level access to the assets within the experiment network. For the defensive teams it is not your job to worry about endpoint security. Malware events happen and they will happen on this experiment network. Just focus on network communication monitoring and intrusion detection.

Round of Fun

Each round will flow the exact same way. Both offense and defense teams will be alerted that a round has started. Offense has 60 minutes to modify a sample and submit to DreamPort. When you submit a sample (as an offensive team), you should make sure your C2 server is ready for communication. Once all samples are submitted, the unmodified samples compiled or produced from the source repositories will be released to all defense teams at this point and at the same time. This will also include a network packet capture (PCAP) file which contains traffic generated by the 'malware' which defenders can use to jumpstart their IDS rule or signature writing. For offensive teams, please be ready to support producing multiple samples from a single original source if you are able!

At this point, the network will be reset to a clean state. The experiment network is not considered reset until the rebooted assets come online and at least 1 computer can access the network and Internet and the domain controller network time has updated. Keep in mind, our experiment environment uses randomized automation to create background traffic that will make it difficult to identify a single box and the potential infection. Sometime in the first hour after the round has launched, DreamPort engineers posing as 'users' of this experiment network will execute both the modified and unmodified samples (based on how many offense teams we have) as though infections have occurred. Defense teams will not know which asset were infected save for the information that their technology software can tell them. Once the infections have taken place, teams must determine if they can determine what took place. As a defensive team, you should be working as fast as possible to create IDS rules or training data for your technology to insert back into your installation for the original sample that was released before the round started. At a minimum, as a defensive team you should strive to detect the original unmodified sample with your IDS install or proprietary security stack. You must write the rules, provide the training data to augment your install. We will not provide any rules.

We encourage communication with offsite personnel from your company or team to help with tasks such as testing IDS rules against the known malware sample you were given (as a defensive team) or continued improvement of your modification capabilities (as an offensive team).

It is important to note, that for each round, we will execute the original sample and C2 server that was released to all participants as we expect the IDS rules produced or modified by the Defense to only evolve forwards. You as a defensive team should be able to catch everything you knew about already and hope that you can catch the modified samples.

Remote Access

The DreamPort experiment networks are accessible via VPN and we will grant a maximum of two accounts for a single team to connect remotely during the event. We must state we cannot support sharing of these accounts so if you are working as a team (offense or defense) please be prepared to setup a VPN concentrator (e.g. PFSense) to allow multiple workstations in a location to access our experiment infrastructure. The remote access will terminate after the event completes.

Discord Chat

Like our previous event, we will be utilizing a Discord Chat Server which we strongly encourage all participating teams to join. Details on this connection will be released at the start of the event.

Evaluation

We are planning the following evaluation criteria for this event:

Offense

• Did the participant team modify a sample in 60 minutes (or less) given access to source code?
• Did the participant team modified sample work as the original?
• Did the modified sample trigger an IDS or security product alert?
• Did the offensive team use an automated method to modify samples?
• Did the offensive team successfully produce multiple modified samples from an original?

Defense

• Did the defensive team catch the original sample when executed?
• Did the defensive team catch the unmodified malware sample (implicitly, did they write an IDS rule for the sample they received)?
• Did the defensive team's IDS rules, machine learning models or technology catch modified samples?
• Did the defensive team attribute any sample to an original unmodified?
• Did the defensive team attribute two modified samples together?

Suggested Skills

We are strongly suggesting the following skills for this RPE:

Offense

• VMWare/VirtualBox/KVM
• C/C++
• Python
• Suricata, Snort, Zeke
• Windows API
• OpenSSL
• libcurl/libpcap/jansson/libXML
• glibc
• gcc/clang

Defense

• VMWare/VirtualBox/KVM
• Suricata, Snort, Zeke
• Python
• ElasticSearch/Kibana/FileBeats/PacketBeat
• Netflow
• Tcpdump/Netsniff/Wireshark

Schedule

We have chosen the following schedule of events:

• 8 June RPE announcement is made public
• 3 July Last Date for Offense Teams to Sign Up
• 6 July Start of Try-Out Round
• 17 July End of Try-Out Round
• 24 July Offense teams notified
• 24 July Last Date for Defense Teams to Sign Up
• 11 - 13 August RPE Main Event
• 24 August Results Provided

This schedule is subject to change. If we have enough defensive teams, we may choose to evaluate a second set of teams separately using the same exact modified samples from the offense. We will notify defensive teams of a second round of evaluation should this be required.

¹https://github.com/ptresearch/AttackDetection/blob/master/eternalblue(WannaCry%2CPetya)/eternalblue(WannaCry%2CPetya).rules