When a cyberattack affects a business server, the first question is rarely just whether something went wrong. Teams need to establish what happened, when it started, which accounts and systems were involved, what data was reached, and whether an attacker still has access.
Those answers depend on security logs. A log is not automatically useful evidence simply because it exists. An incomplete record, an incorrect timestamp or a log that can be edited by the same administrator who caused the event may leave investigators with a list of suspicions rather than a defensible timeline.
Good logging supports incident response, legal and regulatory review, operational learning and recovery decisions. It also helps a business distinguish between a compromised production system and a recovery point that can be trusted.
Start with the events that reveal an attacker’s path
The right event set varies by operating system, application and infrastructure, but the aim is consistent: record the actions that show initial access, privilege escalation, lateral movement, persistence, data access and attempts to hide or destroy evidence.
Authentication and identity events
Record successful and failed logins across servers, directory services, VPNs, cloud consoles, remote administration tools and important applications. The useful detail includes the account used, authentication method, source address, target system, result and reason for failure where available.
Do not limit this to human users. Service accounts, scheduled-task identities, API keys, machine certificates and application identities can be abused just as effectively as named accounts. Password changes, multifactor authentication events, token issuance, session creation, session termination and account lockouts should also be retained.
Privilege and account changes
Privilege changes often mark the point at which an intrusion becomes materially more dangerous. Log additions to administrator, root, domain administrator, database owner and cloud administrator roles. Record changes to sudoers files, group membership, delegated permissions, access policies and service-account rights.
Account creation, deletion, disabling and re-enabling should be visible, including the identity that performed the action. The same applies to changes in API credentials, SSH keys, access tokens, certificates and password-reset settings. An attacker may create a new account rather than continue using the account used for initial access.
Process execution and persistence
Process execution logs can show how an attacker moved from a valid login to malicious activity. Where practical, capture the executable name, full command line, parent process, user or service identity, process ID, start time and host. File creation, script interpreter use, scheduled tasks, cron jobs, services, startup items, registry run keys and remote-management commands can expose persistence mechanisms.
Command-line detail matters. A record that says powershell.exe ran is less useful than one that shows the script, parameters, parent process and destination contacted. Logging should be balanced with privacy and secrets management: command lines can contain passwords, tokens or personal data, so access to them needs appropriate controls.
Configuration, firewall, VPN and DNS activity
Configuration changes can explain both how an attacker entered and why normal controls stopped working. Record changes to operating-system security settings, endpoint protection, firewall rules, remote-access settings, directory policies, routing, proxy settings and network security groups.
Firewall logs should show allowed and denied connections, source and destination addresses, ports, protocols, interface or zone and the rule that handled the traffic. VPN logs should include connection and disconnection times, assigned address, account, device information, authentication result and gateway. These records can connect an external source to activity that later appears on an internal server.
DNS requests are often overlooked. They can reveal command-and-control infrastructure, staging locations, newly registered domains and attempts to reach cloud storage or data-transfer services. Retain the requesting host, queried name, record type, response, resolver and timestamp. DNS alone does not prove compromise, but it can complete a sequence that other logs only partly show.
Web, database and cloud administrator activity
Web access logs should capture the request time, source address, host, method, path, status code, response size, user or session identifier where appropriate and the user agent. Reverse proxies and web application firewalls can add context about blocked requests, rule matches and forwarded client addresses. Preserve the original source information carefully; proxy headers should not be treated as trustworthy unless the proxy chain is controlled.
For databases, record logins, failed logins, privilege changes, schema changes, administrative commands, queries involving sensitive tables, exports, backups, restores and changes to audit settings. Full query logging may be expensive or contain sensitive data, so organisations should define which databases, actions and data classes require detailed capture.
Cloud control planes need their own audit trail. Record administrator actions involving identity and access management, storage, virtual machines, security groups, keys, logging settings, snapshots, network routes and deletion or retention policies. A cloud workload log may show what happened inside a server, while the provider’s administrator log shows who changed the surrounding environment.
Backup operations are security events
Backups should not be treated as a separate concern from incident logging. Record backup job starts and finishes, source systems, selected data, result, operator or service identity, destination, retention changes, deletion requests, encryption or key errors, restore requests and restore outcomes.
An attacker who cannot immediately encrypt or steal production data may try to delete recovery points, shorten retention, disable jobs or compromise the credentials used to manage backups. These actions need to appear in an audit trail that is not controlled solely by the production administrator.
The fields that turn a log entry into evidence
Event volume is not the same as investigative value. Each important event should answer a small set of questions: when did it happen, where did it originate, what did it target, who or what performed it, what action occurred, and did it succeed?
- Synchronized timestamp: Use a consistent time source and record the timezone or UTC offset. Include a precise event time where the platform supports it, as well as collection time when these differ.
- Source and destination: Capture source and destination IP addresses, ports, hostnames, interfaces, zones, URLs, database objects or cloud resources as relevant. Record NAT or proxy context when it affects attribution.
- Identity: Identify the human user, service account, process, device, certificate, token or API client. A display name alone is not enough if it cannot be mapped to a unique identity.
- Action: State what was attempted: login, role assignment, process launch, file access, rule change, export, deletion or restore.
- Result: Distinguish success, failure, denial, partial completion and error. Failure events can show probing and repeated attempts; successful events show what access was achieved.
- Correlation identifiers: Preserve request IDs, session IDs, trace IDs, transaction IDs, process IDs and job IDs. These identifiers allow investigators to connect a proxy request to an application event, database query and downstream action.
- Object and change detail: For configuration or access changes, record the resource affected and, where possible, the previous and new values.
Correlation IDs are especially valuable in distributed environments. A user may authenticate through an identity provider, access a VPN, connect to a web service, trigger an application worker and cause a database query. Without shared identifiers or a reliable mapping between systems, the timeline becomes a manual exercise in guesswork.
Organisations should document clock sources, expected drift and timestamp formats. A five-minute difference between a firewall and a server can be enough to misorder events during a short attack. Log collectors should preserve the original timestamp rather than silently replacing it with the time at which the event arrived.
Define a minimum event set and an investigation checklist
Every business should maintain a written logging baseline for its servers and critical systems. At minimum, it should cover authentication, privilege and account changes, process execution, configuration changes, network access, DNS, web and database activity, cloud administration and backup operations. The baseline should identify the system owner, expected log source, collection method, retention period and person responsible for reviewing serious events. A practical reference for building an security log and incident response event checklist can help teams identify gaps before an incident occurs.
The baseline is not a one-time configuration task. Review it after a major software change, migration, new cloud service, acquisition or incident. Test that the events expected on paper are actually generated, collected, searchable and retained for the required period.
Centralize collection without creating a single point of failure
Centralized collection makes investigation faster because analysts can search across servers, identity systems, networks and applications using one timeline. It also reduces the chance that an attacker who compromises one server can erase every record of their activity.
Send logs to a dedicated collection tier or security information and event management platform. Use secure transport, restrict who can submit or alter records, monitor collector health and alert when an important source stops sending data. A silent logging failure can be as serious as an alert that was never configured.
Centralization should not mean that every system has unlimited access to every log. Separate ingestion, search, administration and deletion privileges. Keep a record of log access and export activity, particularly when evidence may be shared with a forensic provider, insurer, regulator or law-enforcement agency.
Retention and tamper resistance
Retention should reflect the time an attacker may remain undetected, legal obligations, contractual requirements and the speed of internal investigation. Short retention can remove the evidence needed to understand initial access. Excessive retention without access controls can increase privacy and security risk.
Use append-only or immutable storage where appropriate, protect the logging service with separate credentials and prevent production administrators from changing or deleting historical records. Hashing, signed records, write-once storage and independent copies can strengthen tamper detection. The exact control should match the sensitivity of the environment, but the principle is simple: the person who can compromise production should not be able to rewrite the evidence about it.
Keep production and evidence separate
Logs should not depend entirely on the health of the systems they monitor. If an attacker gains administrator access to a server, local logs may be deleted, altered or encrypted. Send copies off the host and, for critical systems, maintain a separate administrative boundary for the collection and retention infrastructure.
Protect the logging platform itself with multifactor authentication, limited administration, network segmentation and independent monitoring. Back up its configuration and, where appropriate, its data. If the logging platform is unavailable during an incident, the organisation may lose both visibility and the ability to prove what was collected.
How agencies can isolate evidence across clients
Managed service providers, IT agencies and security teams supporting several businesses need an additional layer of discipline. Evidence must be separated by client, not merely labelled by a field that an analyst could accidentally filter incorrectly.
Use distinct tenants, storage areas or access domains for each client, with separate roles and least-privilege permissions. Client identifiers should be included in event metadata, but they should not be the only control preventing cross-client access. Search, dashboards, exports, alerting and retention policies should be tested for tenant isolation.
Keep an audit trail of which staff member accessed which client’s evidence and when. Define how evidence is preserved during an investigation, how it is transferred, and when it is deleted. If a shared collector is used, document the technical and procedural controls that prevent one client’s logs from appearing in another client’s investigation.
Agencies should also agree in advance who can authorize collection, containment, account suspension, restoration and disclosure. During an attack, unclear authority can delay action while evidence continues to disappear.
Use logs to reconstruct the attack lifecycle
A useful investigation is a timeline, not a collection of alarming events. Start with the earliest credible signal and test each stage against multiple sources.
- Initial access: Look for unusual authentication successes, repeated failures followed by a success, exposed services, suspicious VPN sessions, web requests exploiting vulnerable paths, new remote tools and unexpected cloud logins. Compare the source, device, geography, time and authentication method with normal activity.
- Execution and privilege escalation: Identify the first suspicious process, script, command or application action. Then trace changes to local, directory or cloud privileges. Ask whether the account already had excessive rights or whether the attacker created a new route to administration.
- Lateral movement: Follow authentication and network records from the first host to other servers, file shares, databases, hypervisors and management systems. Look for the same account, source address, tool or process appearing across multiple systems.
- Persistence: Search for new accounts, scheduled jobs, services, startup entries, SSH keys, API tokens, modified access policies and altered remote-management settings. Persistence may be created days before data theft or encryption.
- Data access and impact: Correlate web requests, database access, file reads, archive creation, exports, cloud storage activity and unusual outbound connections. Establish what was accessed, not just what was potentially available.
- Defence evasion: Check for stopped agents, cleared event logs, disabled audit policies, changed firewall rules, deleted snapshots, altered backup schedules and failed log collection. These events can indicate both attacker intent and the limits of the available evidence.
The timeline should distinguish observed facts from assumptions. Record the source of each conclusion, preserve relevant raw logs and note gaps. If a server was offline or logging was disabled, say so plainly. A defensible incident report is more useful when it acknowledges uncertainty than when it presents an unsupported exact time.
Questions to ask when reviewing logs after an incident
Use practical questions to keep the review focused:
- What is the earliest event that cannot be explained by normal business activity?
- Which account, service, device or exposed application was involved first?
- Was the first access successful, or did repeated failures reveal preparation before the breach?
- Which privileges changed after the initial access?
- What processes, scripts, tools or scheduled tasks appeared on the affected systems?
- Which internal hosts did the account or source contact next?
- Were sensitive files, database tables, mailboxes or cloud storage objects read or exported?
- Did the attacker change firewall rules, DNS settings, logging, identity policies or backup operations?
- Are the timestamps from all relevant systems synchronized well enough to support the sequence?
- Which logs are missing, delayed, locally stored or potentially tampered with?
- What accounts, keys, tokens and sessions must be revoked before recovery?
- Which systems have been examined sufficiently to decide that restoration is safe?
Containment and evidence preservation must be balanced. Disconnecting a compromised server may stop further damage, but shutting it down or wiping it can remove volatile evidence. Follow an agreed incident procedure and involve qualified forensic support when the facts may have legal, regulatory or insurance consequences.
Recovery depends on trustworthy history
Logs can show when systems were compromised, but they cannot repair them. Recovery requires a known-good copy of data and system state, plus confidence that the attacker did not alter the recovery process.
Before restoring, identify the earliest suspected compromise and treat recovery points created afterwards with caution. Review backup job logs, administrator activity, retention changes and restore tests. Confirm that backup credentials were not exposed, that recovery data is complete, and that restored systems will not immediately reconnect to the attacker’s infrastructure.
Clean recovery points should be retained long enough to cover the likely dwell time and investigation period. Immutability for the retention window helps prevent an attacker from rewriting or deleting those points after gaining access to production. Encryption protects the data if storage is accessed, while key separation ensures that the storage provider cannot simply decrypt customer data on its own.
For businesses protecting servers they control, Safenix provides off-site backup encrypted with a key Safenix never holds, stored in Germany and immutable for the length of the retention window. The service is designed for controlled business servers, not sites hosted on shared hosting.
After an incident, restoration should be tested in an isolated environment before production cutover. Validate applications, accounts, network paths, scheduled tasks, monitoring and security controls, then rotate credentials and confirm that the original entry route is closed. Businesses evaluating how to retain clean recovery points and test restoration can review Safenix off-site server backup options.
Make logging part of resilience planning
Security logs are most valuable when they are designed before an emergency. Document the event baseline, synchronize clocks, centralize collection, restrict access, separate evidence from production and test retention and restoration procedures.
Server monitoring can identify abnormal behaviour early, while audit logs provide the detail needed to reconstruct decisions and actions. Together with clean, protected recovery points, they give a business two things an incident response team needs most: a reliable account of what happened and a safer way to return to operation.