In short: IT forensics for servers answers the question of what actually happened in an attack: when, how and with what consequences. Together with specialised forensic partners, we preserve evidence to a forensic standard, analyse logs, file systems and databases, and deliver a traceable report. It serves as a basis for notifications, insurance and, where applicable, criminal prosecution.
When you need IT forensics for your server
Not every incident needs a forensic investigation. It makes sense above all when personal data, payment data or trade secrets may be affected, when a report to the police or a legal dispute is foreseeable, or when an insurer expects reliable evidence. When it comes to the question of whether a notification to the supervisory authority is necessary, too, proven facts help more than assumptions.
After PHP2Shell, one particular point comes on top. The vulnerabilities CVE-2026-109618 and CVE-2026-109619 allow code execution without logging in, and there are no published, confirmed indicators of compromise. Whether a server was affected therefore cannot be ticked off with a checklist, but only established through behavioral analysis: which processes were running, which files were created, which connections went out? First pointers are provided by Am I already compromised?.
How forensics differs from quick cleanup
Cleanup wants to make the server clean again. Forensics wants to understand and prove. One question is "Is the server secure again?", the other "What exactly happened, and which data was reachable?" For notifications, insurance and customer information, the second question is usually the decisive one. Both go together if the order is right: first preserve, then change. Anyone who deletes, patches or restarts first loses volatile traces and often can no longer show later what the attacker saw.
Keep all server logs from 20 October 2026 onwards and ask your hosting provider not to rotate or delete logs. Missing logs are the most common cause of open questions in the report.
Which traces on a PHP web server count
A typical web server holds more traces than many operators assume. Whether they are usable depends on how long they are kept and whether they were preserved before any intervention.
- Access and error logs of the web server and of PHP-FPM, including crashed workers
- File system: new or modified files, their timestamps and owners, executable code in upload folders
- Database: new user accounts, changed settings, injected content
- System: cron jobs, users, SSH keys, login logs, running processes and network connections
- Upstream systems: logs from CDN, WAF, firewall, load balancer and mail server
The upstream systems in particular are often forgotten. They sit outside the web server and are therefore harder for an attacker to manipulate. Some providers keep them only briefly, so you should export them early.
How does PHP SOS help?
- Define the assignment: Together with you we define which questions are to be answered, for example entry point, time period, affected data or lateral movement in the network. This determines which systems are examined.
- Preserve to a forensic standard: We and our specialised partners create copies of disks, logs, databases and, where possible, memory. Every backup receives a checksum, and every handover is documented.
- Analyse: We analyse access and error logs, file changes, user accounts, cron jobs, processes and outgoing connections. The methodology for logs is described in Analysing web server logs after an attack.
- Build the timeline: From the findings we build a timeline of the incident in which every statement points to a concrete piece of evidence.
- Hand over the report: You receive a technical report and an understandable summary for management.
What you get and what we need
The report contains the preserved evidence with checksums, the documentation of the chain of custody, the timeline, the determined or probable entry point, the affected systems and data types, and recommendations. Every statement is marked as proven, probable or unknown.
We need from you:
- access to the affected systems, or permission for your hosting provider to provide us with copies
- a person with decision-making authority who sets the scope and priorities
- information about the system landscape, service providers and known changes in recent weeks
- existing logs, including from firewalls, CDN, WAF or mail servers
- the information whether insurers, police or a lawyer are already involved
If you would like to file a report, you will find notes at Filing a report: central contact points for cybercrime. What insurers typically expect in a claim is explained in Cyber insurance: what counts in a claim.
What we do not promise
Forensics can only analyse the traces that exist. If logs are missing, overwritten or manipulated by the attacker, gaps remain, and we name them. We do not promise that a court will weigh our results in a particular way, and we do not give a legal assessment. We do not name perpetrators, but describe what the traces show. Statements such as "no data was definitely taken" are made only if the evidence supports them.
If the attack is still ongoing, containment takes priority. In that case we start with incident response and preserve as many traces as possible in parallel.
Frequently asked questions
What does court-admissible evidence preservation mean?
Traces are preserved in such a way that it can later be shown they are unaltered. This includes checksums, a documented chain of custody and working on copies rather than the original. Whether a court accepts a piece of evidence, however, is for the court to decide.
Can IT forensics establish whether customer data was taken?
It is often possible to narrow down which data an attacker had access to and whether there are indications of exfiltration. A reliable exclusion is not always possible, especially if logs are missing. The result is therefore separated into proven, probable and unknown.
How long do logs have to be kept?
For the investigation, as long as possible, at least until it is completed. For PHP2Shell, the trade press advises keeping server logs from 20 October 2026 onwards. Legal retention and deletion duties are something you clarify with your data protection officer.
May I restart or patch the server before the forensics?
A restart wipes volatile traces in memory, and a patch changes files. If you can, back up first or talk to us briefly. If the danger is acute, containment takes priority, and that is documented.