An internet-facing file-transfer appliance's access log shows POSTs to an unknown .aspx page in its web root — is that enough to declare an intrusion?
answer
- no sensor can run on the box
- the log records requests, not execution
- compare against the vendor file manifest
- 200 and a byte count is not content
- unexplained artefact clears the bar
basics
~20 sUsually yes. A page in the appliance's web root that appears in no vendor manifest, driven from outside with command-shaped parameters, is an artefact no legitimate process explains — enough to declare, though the log proves no code ran.
solid answer
~50 sThe bar for declaring is a reasonable belief of unauthorised adversarial action grounded in an artefact that no legitimate process explains, not certainty about impact. Here the artefact is a page that is not part of the shipped product being driven from outside with parameters that read like commands, returning 200s and, on one response, megabytes. Be precise about what the record supports: an access log proves requests arrived, a status code was returned and a byte count was sent. It does not prove which code executed, what a POST body contained, or what those bytes were. On a sealed appliance you cannot install an endpoint sensor, so there is no process telemetry to settle it; you corroborate instead with the vendor's file manifest and hashes, with flow records showing bytes leaving to that client, and with the appliance's own application log naming the accounts and files a session touched. Declare, preserve the appliance whole, then scope.
code
text · 6 lines#Fields: date time c-ip cs-method cs-uri-stem cs-uri-query sc-status sc-bytes cs(User-Agent)
2026-03-14 02:11:07 203.0.113.44 POST /admin/upload.aspx - 200 431 python-requests/2.31.0
2026-03-14 02:11:52 203.0.113.44 GET /files/tmp_9f3.aspx cmd=whoami 200 96 python-requests/2.31.0
2026-03-14 02:14:36 203.0.113.44 GET /files/tmp_9f3.aspx cmd=dir 200 4187 python-requests/2.31.0
2026-03-14 03:02:19 198.51.100.17 GET /files/tmp_9f3.aspx cmd=get 200 2884190 Mozilla/5.0
...go deeper
Know what an access log line contains: client address, method, page, query string, status and response size. Be able to say which of those are attacker-controlled and which the server records for itself.
Explain the gap between requests served and code executed, and name the corroboration you would fetch: the vendor file manifest, flow records for volume and direction, and the product's own application log for accounts and files touched.
Demonstrate that you can declare on partial evidence without over-claiming. State the bar, apply it, list the innocent explanations you eliminated, and describe preserving a sealed appliance before disconnecting it.
Be ready to argue what it means to run internet-facing appliances you cannot instrument: compensating visibility, contractual telemetry requirements on the vendor, and where an uninstrumentable box is allowed to sit in the architecture at all.
## The situation A managed file-transfer appliance sits on the internet by design: partners upload to it, internal systems collect from it. It is a vendor-sealed box, so no endpoint sensor can be installed on it and there is no process-creation telemetry at all. Its own web-server access log and application log are the entire observation surface. That constraint is the point of the question, because the instinct trained on endpoint alerts (look at the parent process, look at the command line) has nothing to work with here. ## Reading the record honestly A W3C-style access log line records what the web server was asked for and what it answered. Field by field, from the excerpt: - `c-ip` is the client address that made the request. It tells you the request came from outside, and nothing about who was at the keyboard. - `cs-method` and `cs-uri-stem` name the verb and the page. A `POST` to an upload endpoint followed minutes later by `GET`s to a page in a different directory is a shape worth explaining. - `cs-uri-query` is the query string. Values like `whoami` and `dir` are command-shaped, and a shipped product page does not normally take them. - `sc-status` `200` means the server answered successfully. It does not mean the intended code path succeeded, and a webshell returning an error message still returns 200. - `sc-bytes` is the size of the response. A response of 2.8 MB means that many bytes left the server toward that client. It does not say what they were. - `cs(User-Agent)` is self-declared by the client. A scripted agent string is suggestive and trivially forged, so it is corroboration, never proof. ## What the log proves and what it does not It proves that a page exists at that path and is reachable, that requests to it were served, and that data of a given size was returned. It does not prove code execution, does not carry the POST body that likely wrote the file in the first place, does not identify a person, and cannot tell you whether the megabytes were customer data or an error page repeated. Interviewers listen hard for candidates who slide from *bytes were returned* to *data was exfiltrated*; those are different claims with different evidence behind them. ## The corroboration that closes the gap Because the appliance carries no sensor, you build the case from three other places. 1. **The file system, through vendor tooling.** The single strongest fact is that the page is not in the vendor's manifest of shipped files, or that its hash matches nothing the vendor publishes. An unlisted executable page in a web root is not a thing that appears by accident. 2. **Network records.** Flow records carry the five-tuple, byte and packet counts and timestamps, and carry no payload at all. They can confirm the volume and direction independently of the application's own logging, and they can show whether the appliance started making outbound connections it never made before. 3. **The appliance's application log.** Separate from the access log, it records product-level actions: which accounts authenticated, which transfers ran, which files were listed or fetched. That is where you learn what the intruder could have reached, as opposed to what they requested. ## Applying the bar The declaration bar is not certainty and not impact. It is: is there an artefact that no legitimate process explains, and does it imply unauthorised action by a human adversary? An unlisted page in the web root, driven externally, with command-shaped parameters, answered 200 — yes, on all counts. The alternative explanations are worth ten seconds each and all fail: a vendor hotfix would appear in the change record and the manifest, an internal test would not come from an external address, a scanner would generate 404s rather than 200s from a page that should not exist. ## Sequence after the call Declare, then preserve before you touch. On a virtual appliance that usually means a snapshot of the whole VM plus an export of the access, application and system logs to somewhere the appliance cannot overwrite, because appliance logs frequently rotate on a short cycle. Then scope: which accounts and files that session reached, whether the same page was hit from other addresses, and how far back the first request to it goes. Note that the earliest request in your surviving log is the earliest you can *see*, not the earliest that happened — retention is a ceiling on the claim, not a fact about the intruder.
- The 2.8 MB response is the scariest line in that log. What can you actually assert from it?Only that the server sent roughly 2.8 MB to that client in one response. Not what the bytes were, not that they were customer data, not that the transfer completed at the other end. To say anything about content you need the application log naming the files that session touched, or a copy of the page itself to see what it returns.
- Would you take the appliance off the internet before or after declaring?Declare first, because on most plans the declaration is what gives you the authority to disconnect a partner-facing system without the business owner's agreement. Then cut it, but snapshot the appliance whole before or as you do it — appliance logs rotate quickly and pulling the network can trigger a restart that discards volatile state.
- How does the absence of any EDR alert on this appliance affect your confidence?Not at all. No sensor can run on it, so there was never a rule that could have fired; the absence of an alert is a fact about coverage, not about the estate. Treating a silent console as reassurance on an uninstrumented device is one of the more expensive habits in this job.
saying these in an interview costs you the question
- Reads a 200 status as proof that the attacker's code executed successfully
- Says the 2.8 MB response proves customer data was exfiltrated
- Trusts the user-agent string as an identifying fact
- Waits for endpoint telemetry that can never exist on a sealed appliance
- Deletes the suspicious page immediately to make the box safe
- Treats the earliest surviving log line as the true start of the intrusion