Auditing Server Access With Scratchy After a Security Incident
When a web server has been compromised or subjected to a suspected attack, its access logs can provide the first reliable account of what happened. They record requests that reached the server, including timestamps, client addresses, requested resources, response codes, and user-agent strings. Scratchy, a Python-based Apache log analyzer, can turn that raw activity into a more practical starting point for investigation.
Scratchy is useful when an administrator needs to inspect a large log file quickly rather than read thousands of lines manually. It can reveal traffic patterns, repeated requests, unusual status codes, and resources that attracted suspicious attention. These findings help define the incident’s scope and identify evidence that requires deeper review.
The tool should be treated as an analysis aid rather than a complete forensic platform. A careful audit still depends on preserving original files, checking system time, comparing multiple logs, and validating conclusions against application, authentication, firewall, and database records.
Preserve Evidence Before Analysis
Before running Scratchy, create a verified working copy of each relevant access log. Preserve the original file with appropriate permissions, record its hash, and document when it was collected. If logs are rotated, gather the files covering the period before, during, and after the suspected intrusion. A short review window can conceal reconnaissance that began days earlier.
Record the server’s timezone, log format, hostname, public addresses, and any reverse proxies or content delivery networks in front of it. These details affect how client IPs and timestamps should be interpreted. If a proxy writes the actual visitor address into a forwarded header, the Apache log may contain both the proxy and originating addresses, and those fields must be distinguished correctly.
Establish A Baseline From Normal Traffic
Scratchy becomes more informative when its results are compared with ordinary server behavior. Generate or inspect summaries for a known normal period, then compare request volume, common URLs, response codes, HTTP methods, and user-agent distributions with the incident window. A sudden increase in requests to administrative paths is more meaningful when those paths are rarely accessed during normal operations.
Look for deviations rather than isolated oddities. One request containing an encoded character may be harmless, while hundreds of similar requests across many URLs can indicate automated probing. Likewise, a single 404 response is routine; a concentrated sequence of 404, 403, and 500 responses from one address may suggest directory discovery, exploit testing, or attempts to trigger application errors.
Identify Suspicious Request Patterns
Review requests for common indicators of hostile activity, such as traversal sequences, command-injection characters, unexpected file extensions, serialized payloads, and repeated access to backup or configuration files. Requests for files such as archives, environment settings, repository metadata, or old deployment packages deserve attention because they may expose credentials or source code.
Group related entries by source address, time range, requested path, and user-agent. Automated scanners often produce a recognizable rhythm: rapid requests, predictable path changes, and limited interest in normal page assets. Attackers using compromised infrastructure may rotate addresses, so an IP-based view should be combined with request signatures and timing.
If the incident involved a tool or utility from the same developer’s broader project collection, reviewing related Canyonero resources may also help place the software history and project context in perspective. That background does not replace log evidence, but it can clarify how an older utility or development environment fits into the investigation.
Compare Results Across Log Sources
Access logs show what arrived at the web server, but they do not prove that a request succeeded. Match suspicious requests with application logs, authentication records, reverse-proxy logs, firewall events, and operating-system audit data. A request returning status 200 may have delivered a normal page, while a 500 response could still have triggered a vulnerable code path before the application failed.
Pay particular attention to timestamps and clock drift. Convert records to a common timezone and account for buffering or delayed log writes. Correlation is stronger when several systems show the same sequence: reconnaissance in the access log, an application exception, a new process on the host, and an outbound connection shortly afterward.
| Evidence pattern | Possible meaning | Follow-up review |
|---|---|---|
| Many 404 requests for changing paths | Directory or file discovery | Web root, deployment archives, scanner signatures |
| Repeated 403 responses to restricted paths | Probing protected resources | Authentication logs and access-control configuration |
| Sudden 500 responses after crafted parameters | Application exploitation attempt | Application errors, process activity, database records |
| Successful requests for backup or configuration files | Possible data exposure | File permissions, downloads, secrets, source repositories |
| Unusual POST volume from a small address set | Credential attacks or form abuse | Login records, account changes, rate-limit events |
Trace Potentially Successful Activity
After identifying suspicious traffic, separate attempted access from activity that may have produced a meaningful result. Examine response sizes, redirects, session identifiers, and repeated follow-up requests. An attacker who found a valid endpoint may move from scanning to retrieving data, uploading content, or maintaining access.
Check whether suspicious requests were followed by access to newly created files, administrative actions, password changes, or unusual outbound traffic. If a web shell or malicious upload is suspected, compare the access timeline with file modification times and deployment records. Scratchy can point to the requests that deserve this comparison, but filesystem and application evidence are needed to establish impact.
Turn Findings Into An Incident Record
A useful audit is reproducible. Save the Scratchy output, command options or configuration used, input file names, collection times, and notes explaining filters or exclusions. Preserve representative log lines for each significant finding, including enough surrounding context to show the sequence of events.
Write the timeline in plain language: initial scanning, attempted exploitation, possible successful access, post-compromise activity, and containment. Distinguish facts from interpretations. “The address requested a known backup filename 42 times” is an observation; “the attacker stole the backup” requires corroborating evidence.
Practical Review Priorities
Use the following sequence to keep the investigation focused:
- Preserve original logs and calculate hashes before opening or transforming them.
- Run broad summaries first, then narrow the review by time, address, path, status code, and method.
- Compare suspicious entries with application, authentication, proxy, firewall, and host records.
- Investigate successful responses and follow-up activity before treating scans as confirmed compromise.
- Document evidence, assumptions, timezones, and unresolved questions in a timeline.
Scratchy is particularly valuable during the first pass after an incident because it reduces a large Apache log into patterns an administrator can investigate. Its reports can expose the shape of an attack, identify affected endpoints, and prioritize deeper forensic work without altering the original evidence.
Use the results as a foundation for containment and remediation: block confirmed malicious infrastructure where appropriate, rotate exposed credentials, patch vulnerable applications, remove unauthorized files, and improve log retention. Download and run Scratchy against a preserved copy of your server records, then use its findings to build a verified incident timeline.