> For the complete documentation index, see [llms.txt](https://sarpers-organization.gitbook.io/ctftricks/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://sarpers-organization.gitbook.io/ctftricks/_chapter-intro-5/data-analysis/forensics-data-analysis-logging.md).

# Logging

## Analyze Recovered Auth Logs for SSH Logins

When dealing with recovered files from a potential breach, search through system authentication logs (often found in `/var/log/` directories on Linux systems, e.g., `auth.log` on Debian/Ubuntu, `secure` on RHEL/CentOS) to find evidence of SSH login attempts. Successful (`Accepted`) and failed (`Failed`) password attempts can reveal attacker source IP addresses and target usernames, crucial for understanding initial access or lateral movement. Execute the `grep` commands from the root of the recovered file structure (e.g., the output directory of PhotoRec).

Search for successful logins:

```bash
grep -r "Accepted password for" .
```

Search for failed login attempts (potentially indicating brute-force or attempted access):

```bash
grep -r "Failed password for" .
```

Look for patterns within the output to extract the relevant usernames and source IP addresses. Typical log entries for SSH attempts might look like:

`sshd[PID]: Failed password for invalid user test from 192.168.1.1 port 12345 ssh2sshd[PID]: Accepted password for user from 192.168.1.2 port 54321 ssh2`

To extract and count specific information like source IP addresses or usernames from the `grep` output, you can pipe the results to `awk`, `sort`, and `uniq`. The `awk` command is used to select specific fields from the log line, `sort` orders the output, and `uniq -c` counts unique occurrences. Note that the field numbers for IP and user might vary slightly depending on the exact log format, but common patterns exist.

To count failed login attempts per source IP address:

```bash
grep -r "Failed password" . | awk '{print $11}' | sort | uniq -c | sort -nr
```

In this command, `awk '{print $11}'` is used to extract the 11th field, which commonly corresponds to the IP address in failed login attempts like the example shown above (`sshd[PID]: Failed password for invalid user user from IP port PORT ssh2`). The output is then sorted (`sort`), unique lines are counted (`uniq -c`), and finally sorted numerically in reverse order (`sort -nr`) to show the most frequent IPs first.

To count successful login attempts per source IP address:

```bash
grep -r "Accepted password" . | awk '{print $9}' | sort | uniq -c | sort -nr
```

Here, `awk '{print $9}'` extracts the 9th field, which often contains the IP address for successful logins following the pattern `sshd[PID]: Accepted password for user from IP port PORT ssh2`.

To count failed login attempts per username:

```bash
grep -r "Failed password" . | awk '{print $9}' | sort | uniq -c | sort -nr
```

In this case, `awk '{print $9}'` extracts the 9th field, which can correspond to the username in failed login attempts when the log format is `sshd[PID]: Failed password for user from IP port PORT ssh2`.

Analyzing the counts and the specific log entries for failed and accepted attempts helps identify potential brute-force sources and compromised accounts. Remember to adjust the field numbers in the `awk` command if the log format encountered in the recovered files differs.

***

## Splunk Log Correlation for Malware Discovery

Analyze Splunk logs by correlating multiple data sources to trace suspicious activity. Begin by identifying the initial suspicious user activity using the `name` field. Narrow down the time frame based on this activity. Then, correlate events within this time frame with logs from `source="dpkg.log"` to check for relevant package installation or removal events. A basic search to examine these logs is:

```
source="dpkg.log" | table _time,host,source,sourcetype,event
```

This query lists the time, host, source, sourcetype, and event message for all entries in the `dpkg.log`.

Following the trail, cross-reference findings from `dpkg.log` (like timestamps or related packages) with logs from `source="TeamCity logs"` to uncover potential artifact uploads (e.g., malicious ZIP packages) associated with the activity. You can initially view TeamCity events with:

```
source="TeamCity logs" | table _time,host,source,sourcetype,event
```

To specifically look for potential malicious artifacts like ZIP packages within the TeamCity logs, you can use a search such as:

```
source="TeamCity logs" | grep zip
```

For a broader view of events from both sources within the relevant timeframe, a combined search can be useful:

```
(source="TeamCity logs" OR source="dpkg.log") | table _time,host,source,sourcetype,event
```

This layered approach helps pinpoint specific malicious actions or artifacts by following the trail across system and application logs, correlating events from package management logs like `dpkg.log` with application build/deployment logs like `TeamCity logs`.