Log Analysis During an Incident: What Should You Look For?

The systems record all user activities and internal processes—such as logins, their origin, uptime, and other actions—in event logs, enabling administrators to anticipate potential incidents or issues. To analyze them, it is necessary to understand how they work. Before diving headfirst into reviewing our logs, it’s a good idea to establish a plan:

1. Identify log sources and automated tools that we can use during the analysis.
2. Copy the log entries to a location where you can view them.
3. Minimize "noise," that is, routines: repetitive entries that make it difficult to verify their validity after confirmation.
4. Determine whether the timestamps in the log record are reliable, taking the time zone into account.
5. Focus on the most recent modifications, errors, outages, status changes, access events, and administrative events, as well as any other suspicious or unusual events in your environment.
6. Link activities to different logs to get a complete picture.
7. Come up with theories about what might have happened, then examine the records to confirm or disprove them.

The analysis methodology is essential for investing your time wisely and knowing where to look in order to resolve the issue as quickly as possible.

Focus your efforts on searching for logs from the server’s operating system and hardware, applications, security tools, the outbound proxy, and user applications, as well as other security sources. For example, we suggest the following search criteria, inspired by the SANS methodology.

What keywords should I look for inLinux systems and major applications (/var/log)?

• Successful connections: "Password accepted"; "Public key accepted"; "Session open";
• Connection failed: "Authentication failed"; "Incorrect password";
• User logged out: "session closed";
• User account modified or deleted: "password changed"; "new user"; "delete user";
• sudo commands: "sudo: … COMMAND=…" "su FAILED";
• Service failure: "failure" or "malfunction";

 What codes should you look for inWindows systems and major applications(Windows Event Log)?

• User login or logout events: Success: "528", "540"; Logout: "538", "551", etc.; Failure: "529–537", "539";
• Changes to user accounts: Created: "624"; Authorized: "626"; Modified: "642"; Deactivated: "629"; Deleted: "630";
• Password changes: Staff: "628"; Others: "627";
• System startup or shutdown: "7035", "7036", etc.
• Access to the object denied (authorized audits): "560", "567", etc.

What should you look for in network devices (examples based on Cisco ASA logs)?

• Traffic allowed by the firewall: "Connection established"; "Allowed access list";
• Traffic blocked by the firewall: “access list… denied”; “deny incoming traffic”; “deny… by”;
• Bytes transferred: "Closing TCP connection... duration... bytes...";
• Bandwidth and protocol: "limit... exceeded"; "CPU usage";
• Attack activity detected: "attack originating from";
• Changes to user accounts: "user added"; "user deleted"; "user privilege level changed";
• Administrator access: "User AAA..."; "User... locked"; "Login failed";

 What are the criteria for choosing a web server?

• Excessive attempts to access non-existent files;
• Code (SQL or HTML) in the URL;
• Access to unimplemented extensions;
• Messages indicating the startup, shutdown, or failure of the web service;
• Access to risky pages that accept user input;
• 200 error codes on files that don't belong to you;
• Check the logs on all load-balancing servers;
• User authentication failed: Code "401", "403";
• Invalid request: Code "400";
• Internal server error: Code "500";

Use these steps as a checklist when reviewing your incident logs to optimize your processes. You can also use them for regular log reviews or entrust this task to experienced professionals.

Are you interested in this topic or concerned about your cybersecurity? Follow us onSCASSI Cybersecurity’ssocial media channels to stay up to date on our latest news, and feel free to contact us with any questions. We’re here to help!