Evidence collection
Disk and memory images taken with standard tools, hashes recorded, and chain of custody documented.
Start here
Free Audits 5Urgent help
Emergency 4Ongoing support
Managed IT 5Projects
Servers & Hosting 6 Network & Virtualization 9 DevOps 5 Security & Recovery 5 Hardware & Licensing 2Find out where your servers, security, backups and performance stand, at no cost.
Server down, network out, site hacked or data lost? Call us now.
Monthly network and server support with response times written into the contract.
Setup, configuration, management and migration of Linux and Windows servers, panels and mail.
Network design and cabling, MikroTik, VoIP, branch links, virtualization and private cloud.
Networking & communications
Virtualization & cloud
Containers, Kubernetes, automated delivery, infrastructure as code and observability.
Server hardening, firewalls, backup and DR, ransomware recovery and incident forensics.
Advice, supply and installation of servers and network gear, plus genuine enterprise licenses.
Start here
Urgent help
Ongoing support
Projects
Cleaning a hacked server fixes today's problem. Without knowing how the attacker got in, there's a good chance they come back. We preserve the evidence and analyse logs, disks and memory to establish the entry point, the timeline and what the attacker did.
Digital forensics is the preservation and analysis of log, disk and memory evidence after a security incident, to establish how an attacker got in, when it happened and what they did. It is needed when a server that was cleaned gets infected again, customer data turns up somewhere public, or management or a lawyer asks for a documented incident report. PikoSystem takes disk and memory images with recorded hashes and chain of custody, reviews login, web server and firewall logs, Windows event logs and Linux auth.log to build a timeline, examines modified files, web shells and suspicious processes with Autopsy and Volatility, and searches other systems for backdoors and unknown SSH keys. You receive a technical report with evidence for each finding, a plain-language management summary, a list of indicators of compromise and prioritized remediation steps.
Disk and memory images taken with standard tools, hashes recorded, and chain of custody documented.
Login, web server and firewall logs, Windows event logs and Linux auth.log reviewed to build an incident timeline.
Modified files, web shells, scheduled tasks, suspicious services and in-memory processes examined with Autopsy and Volatility.
The exploited vulnerability or compromised account identified, along with the attacker's movement through the network and the data they could reach.
Other systems searched for backdoors, added users and unknown SSH keys.
The widely used NIST SP 800-61 model describes incident response in four phases: preparation; detection and analysis; containment, eradication and recovery; and post-incident activity. Forensics sits mainly in analysis, yet it shapes every later phase. Without knowing the scope of the intrusion, containment and cleanup stay partial.
Order of work matters for the same reason. Volatile evidence such as memory contents, open network connections and running processes disappears at shutdown and has to be collected before disk imaging. If a server was reinstalled before anyone called us, some questions can no longer be answered with proof.
In the Security log, 4624 is a successful logon and 4625 a failed one, and the logon type, 10 for RDP, shows how the session arrived. 4672 marks a logon with special privileges, 4720 a new user account and 4698 a new scheduled task. Event 1102 means the Security log was cleared.
In the System log, 7045 records a newly installed service, a trace left by tools like PsExec. The TerminalServices-RemoteConnectionManager log records RDP authentication as event 1149, and PowerShell event 4104 captures script text when Script Block Logging is enabled. On Linux, auth.log or secure, the output of last and lastb, and users' shell history are the starting points.
In many investigations the log that should hold the answer doesn't exist. The Windows Security log is small by default and overwrites itself within days on a busy server. Process creation auditing (event 4688) and Script Block Logging are off by default, and servers whose clocks aren't synced with NTP make timelines hard to build.
Preparation fixes this: larger log sizes, a sensible audit policy, Sysmon, logs shipped to a separate server the attacker can't wipe, and consistent time across every system. With those settings in place, the next investigation starts from evidence.
The number of systems involved matters, and the condition of the evidence matters more. A machine that is still running, with memory available to capture, answers far more questions than a server restored or reinstalled after the incident.
Other factors: how long logs are kept and whether central logging exists, disk encryption with BitLocker or LUKS and access to recovery keys, cooperation from the data center or hosting provider, disk sizes, and whether the report is for internal use or legal proceedings, which demand stricter chain of custody documentation.
We tell you what not to touch and collect evidence before any cleanup.
We examine logs, disk and memory images and rebuild the incident timeline.
We deliver the technical report and management summary and walk you through the findings.
We close the entry point or help your team close it, and add the IOCs to your monitoring.
Disconnect the server from the network, but avoid shutting it down or reinstalling it if you can. Don't delete logs or suspicious files, and write down everything that has been done so far. Then call us so we can collect evidence before anything else changes.
We collect and report evidence using standard methods, recorded hashes and chain of custody. Whether it is accepted is up to the court or authority, and an officially appointed expert may also be required. If legal action is likely, tell us at the start.
Yes. We review web server access logs, control panel logs and changes to WordPress files and the database to find whether the breach came from a plugin, a theme or a weak password. Site cleanup is available if needed.
Related searches
Quote
A few lines on where things stand and what you want is enough. An engineer calls you back, not a sales rep.