LS23 RT NET REPORT

Network and Cyber-Physical Systems

Table of Contents
Firewalls
Air Defence Systems
Tactical Radio
Gas Distribution Service
5G
Satellite
Bank of Berylia

​Firewalls
​Controlling firewalls

C - completed (attack successful). S - started, but not completed (attack not successful).

As announced during webinars, firewalls did not have built-in binary backdoors. Thus the only
way how RT could access a firewall was abusing its configuration. The configuration could be
easily examined by Blue Teams.

VyOS: fw1-beg and fw2-beg: show configuration

API service enabled with a guessable key
rogue SSH authorized key
rogue user
 minion to a RT controlled salt server
cronjob regularly downloading and executing a file from RT controlled web server
rogue wireguard server
NAT rules that allowed access to services on internal IPv4 hosts
BGP peering allowed from any host
MikroTik CHR fw-bafbg: /export
API service enabled
rogue user
rogue SSH authorized key
rogue L2TP server
layer 2 management service open and a rogue layer 2 tunnel to RT controlled host that
allowed accessing that layer 2 management interface
RT controlled RADIUS server used for authentication
NAT rules that allowed access to services on internal IPv4 hosts
BGP peering allowed from any host
OpenWRT fw1-baf and fw2-baf: uci show and directory /etc
rogue SSH authorized key in /root/.ssh/authorized_keys
rogue CRL updater that downloaded and executed files from RT controlled web server:
/etc/init.d/crl
NAT rules that allowed access to service on internal IPv4 hosts: uci show firewall
BGP peering allowed from any host /etc/frr/frr.conf
FortiNet fw1-bob and fw2-bob: all misconfigurations were visible on the Web UI.
rogue user
RT controlled RADIUS server used for authentication
BGP peering with www-bob. This was used during Partner Run (a test run of the exercise),
but due to various reasons this was not used during the execution.
Debian fw1-5g and fw2-5g. Except for BGP access allowed from any peer
/etc/frr/frr.conf , there were no other misconfigurations.

BTs that spent effort on finding the misconfigurations and managed to have a properly cleaned
up configuration deployed during the 30 minute grace period were not affected by firewall
attacks. There were only 2 teams who managed to do this during grace period and had no
successful firewall attacks during the game. By phase 4, half of the teams had managed to fix
their configurations and RT was not successful with attacking.

Just like in real life, once a RT got access to a firewall, persistence was set up:

fw1-baf, fw2-baf, fw1-beg, fw2-beg: ICMPv6 bind shell.

all except fw1-bob, fw2-bob: memory-resident tasks that disabled firewall block rules, added
new rogue users and SSH keys, keeped API and other services enabled, added necessary NAT
rules that allowed other RT subteams to access their targets on internal hosts. Such a task can
be created by for example running a script that deletes itself from disk and continues running
in memory. Some BTs did not figure out it is a memory-resident RT attack script that regularly
modifies their configuration and created tickets to GT about their misbehaving firewalls (e.g.
DROP rules become ACCEPT rules).
​BGP attacks

C - completed (attack successful). S - started, but not completed (attack not successful).

All firewalls, except fw1-bob and fw2-bob were initially misconfigured to allow peering from any
host and to accept any advertised prefix. For example, a snippet from bird.conf on fw1-5g:

template bgp peers {

local as {{ LOCAL_ASN }};
multihop 255;
ipv4 {
import all;
export all;
};
ipv6 {
import all;
export all;
};
}
protocol bgp 'v4' from peers {
neighbor range 0.0.0.0/0 external;
}
protocol bgp 'v6' from peers {
neighbor range ::/0 external;
}

RT used a host in SINET to connect to all firewalls (except fw1-bob, fw2-bob) and to advertise
smaller prefixes for firewall internal connected routes. For example, if a DMZ used a IPv4
network 100.0.0.0/24 then RT advertised 100.0.0.0/25 and 100.0.0.128/25 prefixes with
an invalid nexthop. With a /64 IPv6 network, RT advertised a /65 prefix with an invalid
nexthop. In routing, smaller prefix is preferred and thus the traffic to networks behind the
firewall never arrived its destintion. If RT stopped advertising prefixes, the connected routes
started to work again in a few seconds. Traffic between hosts on the same L2 network was not
affected (except traffic from firewall and traffic to firewall).

Attack was scored only if both of the following conditions were met:

BGP session to at least one firewall was established: BT firewall allowed access from a SINET
host to firewall BGP service port and BGP service accepted the peer from SINET.
All services scored from another network behind the firewall were not available during the
BGP attack (2, 5 or 10 minutes depending on the phase) AND some of those services were
available immediately before and soon after the attack. This was to make sure that the
availability was caused by BGP attack, not due to some other reason.

Similar misconfiguration was attacked by RT at LS22 and RT saw that teams who got hit never
fixed their configuration, except for one team. To have a learning value, RT took another
approach at LS23 - all upcoming BGP attacks were announced as news articles and also the
description of the attack and possible countermeasures were revealed.
Timetable:

​DAY 1
06:20Z news article in news.berylia.org BGP hijack attack plans revealed: cybercriminals are
planning to hijack the Border Gateway Protocol (BGP) and reroute traffic to a black hole today at
06:30Z.
06:30-06:32Z 1st BGP attack. RT only connected to firewall IPv4 addresses. Later attacks used
both IPv4 and IPv6 addresses. 75% of BTs (18 teams) successfully attacked.
06:35Z news article in news.berylia.org BGP attacker group arrested: more BGP hijack attacks
will happen in a few hours.
11:00Z intel report and news article Upcoming BGP attack: BGP hijack attacks today at 12:00Z.
12:00-12:05Z 2nd BGP attack. 42% of BTs (10 teams) successfully attacked.
13:30Z news article: BGP Hijacking Attacks show no signs of stopping: third wave of attacks will
happen tomorrow at 07:00Z. The article also explains how the attack is done and how to
protect against such attack.

​DAY 2
07:00-07:10Z 3rd BGP attack. 29% of BTs (7 teams) successfully attacked.
09:20Z news article Infamous ABC hackers turn over a new leaf and join the good side: another
BGP hijacking attack at 11:00Z today.
11:00Z another event that was initially scheduled to happen at 10:00Z started, thus BGP attack
was postponed 30 minutes.
the 11:00Z event was a power disruption that caused all primary firewalls ( fw1- ) to shut
down. As some BT-s had only set up firewall rules on primary firewall, when it was shut
down, the secondary firewall became the new primary, but without the blocking rules. This
allowed RT CS team to get back some beacons that were otherwise blocked. The event
itself was not scored in any way.
11:30-11:40Z 4th BGP attack. 25% of BTs (6 teams) successfully attacked.

​Air Defence System

About 1/3 of the teams used the 30-minute grace period to set up firewalling and making sure
that SSH access required a key. This effectively prevented any attack, as RT could either not
reach the target at all or not get any access with the known passwords. The planted SSH key and
at least part of the rootkit have been identified and shared on the MISP on day 0.

Some teams struggled to identify the backdoors: while the root account was properly secured,
their system was constantly accessible via some of the credentials planted during the execution.
In some cases, the Linux management web interface went unnoticed, allowing access to the
machine even if SSH resulted locked down.

A few teams reverted their machines during execution, but delayed with setting up proper
defences again. This allowed RT to access it. On the other hand, quite some teams locked down
their c4i too tightly: RT could not score at all, but also their radar could not provide them with
any information about incoming aircrafts or attacks, still resulting in a sub-optimal situation.
​Objectives

C - completed (attack successful). S - started, but not completed (attack not successful).

Compromise ADS c4i-compromise_ads

using SSH backdoors
Compromise ADS c4i-compromise_ads_tcpudp
using TCP and UDP backdoors
Control ADS c4i-control_ads
inject TCP traffic simulating aircrafts
Destroy ADS c4i-destroy_ads

​Vulnerabilities
SSH backdoor: the ADS application periodically creates a user that can be accessed via SSH on
non-default ports. There was also a preplanted SSH key that predefined users could exploit to
gain root access.
Privilege escalations: some system files were swapped out for privileged python executables.
Root password was periodically reset thanks to an environment variable.
Rootkit: when executed, all and every file with the name starting with dhcp was going to be
completely hidden from the system.
TCP/UDP backdoor: the ADS application has a case for handling specially crafted messages
that will trigger the creation of a new user, which can subsequentely be accessed via SSH.
TCP/UDP traffic injection: the packets sent by the radar to the c4i are not encrypted and can
therefore be crafted to flood the system with non-existing objects.

​Tactical Radio
Failing service availability is worse than having successful attacks. Some BTs firewalled the
service off and got more negative points due to no availability than all RT direct attacks
combined would have caused. Overall, teams have skillfully fixed or blocked Linux platform
vulnerabilities. It would be good to also concentrate on detecting and mitigating the VoIP
service attacks, with which RT had a high success rate.

​Objectives
RT had 3 objectives and became more noisy over time:

1. SIP-protocol attack in phases 1, 2, 3, 4 tvs-control_tvs

2. Data theft in phases 2, 3, 4 tvs-compromise_tvs
3. Destroy in phase 4 tvs-destroy_tvs
C - completed (attack successful). S - started, but not completed (attack not successful).

​Vulnerabilities
At the start of the game, there were the following vulnerabilities:

SIP server misconfiguration that accepted all passwords

The SIP attack used either the server misconfiguration, or if that was addressed, a very
noisy brute force attack (thousands of SIP protocol messages and log lines per second).
Web UI path traversal and command injection vulnerabilites
Planted simple CGI web shell in lighttpd web server
sudo access for www-data user
bind shell on port 4444
backdoored sshd binary
backdoored voipmetrics service

​Gas Distribution Service

​Objectives

C - completed (attack successful). S - started, but not completed (attack not successful).

Steal historian database using API in phases 1, 2, 3, 4 gas-historian-control_gas

Stop compressor CO401 in phases 2, 3, 4 gas-hmi-disrupt_gas_1
Stop compressor CO201 in phases 3, 4. gas-hmi-disrupt_gas_2
 Suspend HMI process and delete HMI files in phase 4 gas-hmi-disrupt_gas_3

​Vulnerabilities
The gas-historian MySQL DB has an ext-user which allowed external connections and
configurations. Firewalls fw1-beg and fw2-beg had NAT rules that allow access to gas-
historian.
The license-check.py on gas-hmi connected to a RT-controlled license-server in SINET
every hour. The license-check.py was a malware that returned a reverse shell to the
license-server during phases 2, 3, 4. A file on uploads.berylia.org was downloaded to
shutdown CO401.
The maintenance terminal conducted a health check of the PLCs every hour to verify the tag
values. The get-pip.py had an added malware function that sends a ping to a C2 server.
Upon response of the C2 server during phase 3, 4, the health check shutdown CO201.
Salt-minion installed and configured on gas-historian, gas-hmi, gas-mt. Salt-master web UI
had an SQLi vulnerability.

​5G
This year 5G attacks were taking advantage of misconfigurations on 5G core elements and the
previous knowledge of the database for each team. RT was using open ports and vulnerabilities
only to pivot from strategic location to be able to trigger those misconfigurations. Only the
defacement attack needed an access on the machine.

The unregister UEs attacks were targeting AMF in initial phases and SMF in later phases
Both were targeting the SBI API - port 7777
Connecting a rogue UPF was targeting the SMF with a misconfiguration on this one
plus previous knowledge on the database
Connecting a rogue gNB was targeting the AMF with a misconfiguration on this one
plus previous knowledge on the database
Connecting a rogue UE was only defendable by modifying the default credentials in the
database (keys, IMSI or APN) as the gNB was a GT machine

For most of the 5G attacks RT was using modified binaries from official repositories or RT was
using packet crafting.

​Objectives
C - completed (attack successful). S - started, but not completed (attack not successful).

Unregister UEs in phases 1, 2, 3, 4 5g-amf|5g-smf-control

Connect a rogue UPF in phases 1, 2, 3, 4 5g-smf-control
Connect a rogue gNB in phases 1, 2, 3, 4 5g-amf-control
WebUI defacement in phase 2 5g-webui-disrupt
Connecte a rogue UE in phases 2, 3, 4 5g-ue-baf0[1-3]|5g-ue-beg[1-3]-control
Add UE credentials in phases 2, 3 5g-db|5g-webui-control
Wipe database in phase 4 5g-db-disrupt

​Vulnerabilities
Patched SSH server. Many of the hosts related to 5G had patched SSH servers running that
allowed authentication with an empty key during the handshake.
ICMPv6 bind shell on many hosts at /bin/chckrun . The file /root/.bashrc was modified to
start the listener as soon as the root user logs in.
Sliver Beacon. Sliver was located in /usr/bin/mon and /usr/bin/lsmon and was executed
once a user executes ls command.
Rogue users and SSH keys. Systems had rogue users: admin and named . User root had a
rogue authorized key specified in /etc/.auth .

​Satellite
The satellite systems connected the segments BAF_INT and BAF_BG on a network level. So
attacks against the satellite (signal quality or disruption) directly affected the connectivity
between BAF_INT and BAF_BG. The satellite infrastructure consists of Linux hosts to control the
satellite equipment and some satellite specific hardware (antennas and satellite). The Linux
hosts communicated with each other and with the antennas. The antennas communicated with
the satellite. Overall most BTs defended the Linux systems on an advanced level. RT also
attacked the communication using the BT systems.

In Phase 1 RT tried to reduce the signal quality to ~80% by applying an old firmware version.
In Phase 2 RT attacked a Linux host and tried to get initial access.
In Phase 3 RT tried to reduce the signal quality to 0%. This could either be achieved by putting
the satellite to safe mode or by influencing the directions of the antennas and move the
antennas out of connection. In both cases BAF_BG was not reachable anymore.
In Phase 4 RT tried to get root access to the Linux systems either by further exploiting the
initial access from phase 2 or gaining new access.

​Objectives

C - completed (attack successful). S - started, but not completed (attack not successful).

Reduce satellite signal quality to less than 100% in phase 1 satellite-disrupt_sat

Gain access to mcs in phase 2 mcs-compromise_sat
Reduce satellite signal quality to 0 in phase 3 satellite-disrupt_sat_full
Reduce antenna signal quality to 0 in phase 3 antenna-disrupt_sat_antenna_full
Get full privileges on msc in phase 4 mcs-elevate_sat_mcs
Get full privileges on gsc in phase 4 hq-gsc|bg-gsc-elevate_sat_gsc

​Vulnerabilities
Leftover system users and Mission Control System (MCS) accounts
Weak MCS API key
Web Application mission-extension with spring4shell and log4shell vulnerabilities
Web shell
Directly accessible ports. By default, BT firewalls did not block access to the following
services:
antenna:4532 used to control radio transceiver using Hamlib rigctld protocol. It can be
used to send unexpected modifications for radio transceiver.
antenna:4533 used to control antenna rotator using Hamlib rotctld protocol. It can be
used to modify antenna pointing.
gsc:19000 used for communicating with the satellite. Assuming antenna pointing and
radio frequencies are (still) accurate, it can be exploited by sending valid but unexpected
commands to the satellite.
antenna:19000 same as gsc:19000 but skips gsc .
​Bank of Berylia
The Locked Shields 2023 exercise simulated an adversary targeting the Bank of Berylia and its
employees (simulated by the User Simulation Team) and simulation of the following high-level
scenarios:

Web defacement on the internet-facing web applications of the bank

Data theft / data manipulation
Fraudulent financial transactions
Malicious insider
Supply chain compromise
Denial of service / sabotage

​Overall Observations
There were observable improvements in Blue Teams’ identification and eradication of typical
vulnerabilities and obvious system misconfiguration, changes of default credentials,
implementation firewall rules. Additionally, large number of Blue Teams deployed additional
security controls on the end-point systems already within Phase 1, or towards beginning of
Phase 2 of the exercise. This is a very positive development as the defensive actions performed
by number of the blue teams were executed much faster and in very early phases of the exercise
compared to Locked Shields 2022.

​Observations Phase 1 and Phase 2

At least 4 blue teams were quick in deployment of additional security controls in form of AV/EDR
products on the Windows-based endpoints already in Phase 1. Additional blue teams followed in
the beginning and throughout Phase 2. This is a very positive development compared to Locked
Shields 2022. Number of blue teams were also successful in changing the default credentials and
implementation of firewall rules pushing the adversary to adapt and seek other attack paths.

​Observations Phase 3 and Phase 4

RT observed additional hardening on the systems and very active defense indicating active
monitoring and response to adversarial activities. These comprised of active identification of
established beacons, removal of rogue accounts on systems and active fighting over control of
the targeted systems. By Phase 4 number of blue teams were able to eradicate most of the
vulnerabilities and misconfigurations, change default credentials, deploy additional hardening
and security controls, implement effective firewall rules.

At this stage, the adversary was limited to make use only of access and command & control
which was established in the earlier phases of the exercise and remained undetected. The
additional improvements of the defensive posture pushed the adversary to use ‘social
engineering’ type of attacks targeted at the employees of the Bank of Berylia (simulated by the
User Simulation Team). However, the improved defensive posture significantly increased the
time, cost and effort the adversary must have put into executing a successful attack.
Unfortunately, there were still blue teams within Phase 4, which did not change the default
credentials or did not implement effective firewall rules and remained exposed to the simpler
form of attacks. However, the number of blue teams still exposed to these weaknesses was
lower than in Locked Shields 2022, thus also here RT observed an improvement across the
individual exercises.

​Objectives

C - completed (attack successful). S - started, but not completed (attack not successful).

Gain foothold on one of the employee workstations in phase 1 ws[1-5]-m365-

compromise_bob
Gain foothold on rms-rdp in phase 1 rms-rdp-compromise_bob
Gain full access on one of the employee workstations in phase 1 ws[1-5]-m365-elevate_bob
Gain full access on rms-rdp in phase 1 rms-rdp-elevate_bob
Steal data from one of the bank systems in phase 2, 3 datatheft_bob
sensitive data: bank transactions, bank employees’ user accounts
Complete a money transfer to a specified account in phase 2, 3 moneytransfer_bob
Disrupt the bank in phase 4 disruption_bank_bob
Prevenet employees from logging into the bank system, cause transactions to fail.
Disrupt office in phase 4 disruption_office_bob
Prevenet employees from logging into the employee workstations or rms-rdp, cause
transactions to fail.

​Vulnerabilities
Workstation vulnerabilities
Bindshell
Leftover user
PAM misconfiguration
Portainer running with a weak password
Exposed Docker API
SQL injection in ApprovePayments API
Weak JWT authentication in RMS-API backend
RCE in the rms-ng UI component

​Conclusion
In comparison to Locked Shields 2022, RT observed improvements and faster implementation of
firewalling, hardening of assets, changes of default credentials, faster deployment of additional
security controls, additional monitoring and protection of key assets (such as the jumphost).
Which indicates a much better analysis and anticipation of various attack paths by the blue
teams throughout the exercise. This significantly increased the cost and effort on the
adversary’s side to execute various malicious actions which translated into tactical advantage for
the blue teams which successfully implemented improvements in their defensive posture.

RT was are aware of at least 1 blue team bringing specialists from the financial sector to the
exercise who were actively monitoring the financial system to identify rogue/fraudulent
financial transactions and were successful in identifying some of the rogue/fraudulent
transactions executed by the adversary.

RT thanks all the blue teams for their dedication, hard work and effort in actively defending their
systems and infrastructure which RT notably observed and experienced throughout the exercise.