When you need server forensics

Server forensics is the examination of the systems a business runs on: file servers, application and database servers, cloud virtual machines and the logs they produce. You need it when the question is bigger than one laptop. A database record changed and nobody admits to it. A file share was mass-copied before a resignation. An attacker touched a cloud workload. A lawsuit requires records that live only inside an application.

This service is part of our digital forensics services practice. It covers the evidence that ordinary device imaging misses: structured data, shared storage, cloud snapshots and server, network and authentication logs. If an attack is still in progress, start with cyber incident response and we preserve evidence as part of the response.

Typical matters include:

• Suspected tampering with financial, medical, inventory or customer records.
• Data theft from a file share, SharePoint site or document system.
• Unauthorized access to an AWS or Azure account or virtual machine.
• Litigation that needs data extracted from a line-of-business application.
• Old backup tapes, CCTV recorders or IoT devices that hold the only copy of key evidence.

What we deliver

Every engagement is scoped in writing. These are the service packages we combine for server, cloud and database work:

Server forensics evidence sources and their limits

NIST Special Publication 800-86 (2006), the federal guide to integrating forensic techniques into incident response, describes four phases: collection, examination, analysis and reporting. It also advises prioritizing sources by likely value, volatility and effort. Volatile data is lost when a system is powered down, and log files can be overwritten as new events occur. That is why the order of collection matters.

Source	What it can show	What to watch
File server or share	File creation, modification, access permissions and bulk copying	Access dates may not be recorded; file auditing may be off
Database	Current records, audit tables, transaction logs, deleted-row remnants	Many databases do not log reads or old values unless configured
AWS CloudTrail	API calls, console sign-ins and configuration changes	As of October 2026, event history covers only the past 90 days without a trail or event data store
Azure activity log	Control-plane operations on subscriptions and resources	Azure keeps activity log events for 90 days unless exported
Cloud disk snapshots	A point-in-time copy of a virtual machine disk	Captures disk only; memory must be collected separately and first
Firewall, VPN and authentication logs	Who connected, from where, and when	Short rotation, mismatched clocks and gaps across devices

How we approach AWS and Azure evidence

We follow the cloud providers’ own published guidance. The AWS Security Incident Response User Guide lists an order for EC2 instances: record instance metadata, enable termination protection and tags, take EBS snapshots, acquire memory, then decommission and isolate. It warns that live response modifies system data and that memory should be captured before isolation or shutdown. AWS also points to CloudTrail, S3 data events and VPC Flow Logs as key log sources.

Microsoft’s Azure forensics architecture describes copying OS and data disk snapshots into a separate, restricted subscription with immutable storage, computing hash values, and storing those hashes in a key vault. We apply the same principles: separate evidence storage, restricted access, hash verification and a written record of each step.

How an engagement runs

1. Request and authorization. You submit the request online. The system owner, or counsel acting for them, confirms in writing that we may access the named servers, accounts and data.
2. Scoping call. We map the systems, log retention, database type and any uptime constraints, then confirm scope and billing in writing.
3. Preservation. Quick wins first: extend or export logs about to expire, snapshot cloud disks, and capture volatile data where it matters.
4. Collection. Targeted server and share collection, database exports, cloud snapshots and log exports, each hashed and logged for chain of custody.
5. Analysis. Logs, records and artifacts normalized to one time zone and correlated into a timeline.
6. Reporting. Plain-language findings with stated limits, and a formal report or expert witness testimony if the matter goes to litigation.

Authority, consent and legal limits

We access servers, databases and cloud accounts only with written authorization from the owner or someone with legal authority to grant it, such as a company officer, counsel acting for the company or a court order. A former IT contractor’s leftover password is not authorization. For hosted systems, we work through the account owner’s own administrative access and the provider’s supported tools.

We do not bypass authentication we are not authorized to bypass, we do not access third-party systems such as an attacker’s server, and we do not hack back. Some cloud and hosting contracts limit what can be done or require notice; your administrator or counsel should confirm that. When data may be relevant to a lawsuit, Federal Rule of Civil Procedure 37(e) allows a court to act when electronically stored information is lost because a party failed to take reasonable steps to preserve it. This is general information, not legal advice.

How it is priced

• Server and share collection. Quoted per source, for agreed paths up to a stated volume. Physical server images, RAID rebuilds and downtime are quoted separately.
• Database, cloud and log work. Billed hourly with a short minimum, against an allowance we agree before work starts.
• Third-party costs. Cloud storage, API, compute and data egress charges are billed by your provider. Log ingestion platforms, database administrator time and application licenses are separate.
• Special sources. Tapes, CCTV and unusual systems are hourly, with hardware and outside specialist costs quoted.

Cost drivers are the number of systems, data volume, log retention, how custom the database or application is, and whether work must happen after hours to avoid downtime. Extra work is handled by written change order.

Mistakes to avoid before server forensics

• Do not restore from backup over the evidence. Snapshot or image first, then restore.
• Do not reboot or terminate a suspect cloud instance. You lose memory, and a terminated instance can take its disk with it.
• Do not let logs roll over. Check retention today and export what is close to expiring.
• Do not run your own queries against a suspect database. Ad hoc fixes and cleanup change the very records in dispute.
• Do not overwrite DVR footage. Most recorders loop. Pull the unit or stop recording on the affected channel.
• Do write down who has admin access. We need to know which accounts are trusted and which are suspect.

Who this is for

• Law firms
• IT directors and MSPs
• Healthcare and financial organizations
• Business owners
• In-house counsel
• Insurers and breach coaches

Frequently asked questions

Related guides

• Database forensics and proving SQL tampering
• Enterprise cloud forensics for SaaS and IaaS evidence
• Network intrusion forensics after a breach
• How Linux servers get hacked
• CCTV and DVR video forensics
• Forensic imaging and chain of custody
• Remote forensic extraction service
• Cyber incident response service
• eDiscovery and litigation support

We access servers, databases and cloud accounts only with written authorization from the owner or a court order. This is general information, not legal advice.

Sources: NIST SP 800-86, AWS: Collect relevant artifacts, AWS CloudTrail event history, Microsoft Azure forensics chain of custody, Azure activity log, CISA et al.: Event logging best practices (2024).