LogSentinel: Advanced Threat Log Analyzer

Step 1 Virtual Machine Initialization

To simulate a real-world enterprise attack and defense scenario, a multi-machine virtual lab environment was prepared using Oracle VirtualBox. The lab consists of three virtual machines, each representing a different role within the network.

Virtual Machines Used

• Kali Linux
  • Role: Attacker machine used to perform brute-force attacks, exploitation, and post-exploitation activities.
• Metasploitable 2
  • Role: Intentionally vulnerable Linux server used as a target for exploitation and log generation.
• Windows Virtual Machine (Windows 10)
  • Role: Enterprise-like endpoint system used to generate Windows security and system logs during authentication attacks.

All virtual machines were successfully powered on and verified to be running simultaneously to ensure proper inter-VM communication during attack simulations.

What: VirtualBox Manager displaying Kali Linux, Metasploitable and Windows VM in running state Purpose: Proof of complete and active lab environment

Network Isolation Configuration

To maintain a secure and controlled testing environment, network isolation was implemented for all virtual machines. This prevents external network exposure while allowing internal communication between lab systems.

Network Configuration Details

• All virtual machines were configured to use:
  • Host-Only Adapter or Internal Network
• Each VM was connected to the same isolated virtual network
• No internet access was provided to target machines to avoid unintended exposure

This configuration ensures:

• Safe attack simulation without affecting external systems
• Accurate logging of internal attack traffic
• Realistic enterprise-style network segmentation

Verification

• Network settings were verified within the VirtualBox configuration panel to confirm: - Identical network mode across all VMs - Correct adapter assignment What: Network settings of a virtual machine showing Host-Only / Internal Network configuration Purpose: Evidence of secure network isolation

Verify Logging on Targets

Metasploitable (Linux)

To confirm that the Linux target system was generating authentication and privilege-related logs correctly, logging was verified on the Metasploitable virtual machine

Procedure

The Metasploitable virtual machine was started and logged into using the default user account (msfadmin). A terminal session was opened to monitor authentication logs in real time. Live log monitoring was enabled using the following command:

sudo tail -f /var/log/auth.log

This command continuously displays authentication-related events such as user logins, failed authentication attempts, and privilege escalation activity. To generate log entries, a privileged command was executed using sudo

sudo ls

Immediately after executing the command, new log entries appeared in the terminal, confirming that authentication and sudo activity was being properly recorded by the system.

Verification Result

• Authentication events were logged in real time
• Sudo command execution generated corresponding log entries
• The /var/log/auth.log file was confirmed to be active and functional

What: Terminal showing live authentication logs using sudo tail -f /var/log/auth.log
Purpose: Proof that Linux authentication logging is enabled
What: Privileged command execution (sudo ls) generating authentication logs
Purpose: Confirmation of sudo activity logging

Verify Logging on Targets

• Windows (Windows 10 / 7) To ensure that the Windows target system was correctly recording security‑related events, Windows security logging was verified using the built‑in Event Viewer and supported by audit policy configuration.

Procedure

The Windows virtual machine was started and logged into normally. The Event Viewer was opened by pressing Win + R, entering eventvwr.msc, and pressing Enter. Within Event Viewer, the following logs were accessed: - Windows Logs → Security - Windows Logs → System

• Audit Policy Verification and Configuration (Supporting Step)

To ensure that failed authentication attempts were consistently logged, Windows audit policies were reviewed and explicitly configured using the auditpol command‑line utility.An elevated Command Prompt was opened by selecting Run as Administrator, and the current audit policy configuration was reviewed using:

auditpol /get /category:*

This command displayed all audit categories and subcategories, including those under Logon/Logoff, such as Credential Validation.To guarantee logging of failed authentication attempts (Event ID 4625), auditing was enabled for failed credential validation events:

auditpol /set /subcategory:"Credential Validation" /failure:enable
auditpol /set /subcategory:"Credential Validation" /success:enable
auditpol /set /subcategory:"Logon" /failure:enable /success:enable

Failed Authentication Test

To generate a security event, a failed authentication attempt was performed. The user signed out of the system and attempted to log in using the correct user account with an incorrect password. After the failed login attempt, the system was logged into again using the correct password.The Event Viewer was refreshed, and the Security log was examined for authentication failure events.

Verification Result

A failed logon event with Event ID 4625 and Keywords: Audit Failure was successfully observed in the Security log. This confirms that Windows authentication failures are being logged correctly and are available for further analysis.

Configure Shared Folders

To enable secure and efficient transfer of log files between virtual machines and the host system, a shared folder mechanism was configured. This shared storage location is used to centralize logs collected from both Linux and Windows target systems before analysis.

Procedure

A shared folder was created on the host machine and configured in Oracle VirtualBox for both the Kali Linux and Windows virtual machines. Host System

• A directory named Shared was created on the host system.
• This directory serves as the central repository for log files.

Windows Virtual Machine

• The shared folder was automatically mounted and made accessible as:

D:\IDM\KaliShareFolder

• This allowed Windows Event Logs to be exported directly into the shared directory for later analysis.

Verification Result

• The shared folder was successfully accessible from both virtual machines.
• Files placed in the shared folder from one system were immediately visible on the other systems.
• This confirmed that the shared folder was functioning correctly as a log transfer mechanism.

Step 2: Attack Simulation & Log Generation

Objective

The objective of this scenario is to simulate brute force authentication attacks against both Linux (Metasploitable) and Windows systems in a controlled lab environment, in order to generate security logs for analysis and demonstrate real-world attack behavior.

Lab Environment

• Attacker Machine: Kali Linux
• Target Systems:
  • Metasploitable 2 (Linux – SSH Service)
  • Windows (RDP / Local Login)
• Network Type: Host-Only / Isolated Lab Network
• Attack Tool: THC Hydra

Scenario Overview

Brute force attacks attempt to gain unauthorized access by systematically trying multiple username and password combinations. In this scenario, a dictionary-based brute force attack was simulated against an SSH service on Metasploitable and failed login attempts were generated on a Windows system

Part A: Brute Force Attack on Metasploitable (SSH) Resolve SSH Cryptographic Compatibility

Modern SSH clients disable deprecated algorithms by default, which prevents connections to legacy systems like Metasploitable. To allow controlled testing, legacy algorithms were temporarily enabled.

• command run:

sudo nano /etc/ssh/ssh_config

• Configuration Added:

Host 192.168.56.109
    KexAlgorithms +diffie-hellman-group1-sha1
    HostKeyAlgorithms +ssh-rsa
    PubkeyAcceptedAlgorithms +ssh-rsa
    MACs +hmac-md5,hmac-sha1

Manual SSH Verification

• Before launching the brute force attack, SSH connectivity was verified manually.
• command run:

ssh msfadmin@192.168.56.109

Result:

• Successful login confirms SSH connectivity and cryptographic compatibility.
• This step ensures the attack tool will function correctly.

SSH Brute Force Attack Using Hydra

A dictionary-based brute force attack was launched using Hydra against the SSH service.

• command run:

hydra -l msfadmin -P /usr/share/wordlists/rockyou.txt ssh://192.168.56.109 -t 4

Observed Output:

• Active authentication attempts ([STATUS] messages)
• SSH service identified on port 22
• Continuous password attempts generated

Result

• SSH brute force attack successfully simulated
• Authentication logs generated on Metasploitable
• Attack behavior validate

Windows Failed Login Attack Simulation (RDP / Local Authentication)

Objective

The objective of this step is to simulate a brute-force–style authentication attack against a Windows 10 system by generating multiple failed login attempts. This activity is performed to ensure that Windows Security logs correctly capture and record authentication failures for further analysis.

Attack Method

• Type: Authentication failure simulation
• Target System: Windows 10 Virtual Machine
• Technique Used: Manual incorrect password attempts (local login)
• Expected Log Event: Windows Security Event ID 4625 This method represents a realistic brute-force scenario in which an attacker repeatedly attempts to guess user credentials.

Procedure

• The Windows 10 virtual machine was powered on and allowed to reach the login screen.
• A valid local user account was selected.
• An incorrect password was entered deliberately.
• The system displayed an authentication error message indicating a failed login attempt.
• This incorrect login process was repeated multiple times to simulate a brute-force attack.
• After generating the failed attempts, the user logged in successfully using the correct credentials.

Attack Evidence

• What: Windows Security log showing failed authentication event
• Event ID: 4625 (An account failed to log on)
• Purpose: Windows attack simulation evidence

Log Verification

• The Windows Event Viewer was used to verify log generation:
• command run:

Windows Logs → Security

The following event was observed:

• Event ID: 4625
• Keywords: Audit Failure
• Description: An account failed to log on
• This confirms that Windows authentication failure logging was functioning correctly and that the simulated attack generated valid security logs.

Result

• Multiple failed login attempts were successfully simulated on Windows 10
• Windows Security logs recorded authentication failures
• Attack evidence was captured and preserved for analysis

Security and Ethical Note

All activities were conducted in a controlled, isolated virtual lab environment strictly for educational and defensive security research purposes. No external or unauthorized systems were targeted.

Summary

This step successfully demonstrated how brute-force authentication attempts against a Windows system are logged and detected. The generated Event ID 4625 entries provide critical data for intrusion detection, monitoring, and forensic investigation.

Exploitation Attempt on Metasploitable

Objective

The objective of this scenario is to demonstrate how a vulnerable network service can be exploited after proper reconnaissance. This step simulates a controlled exploitation attempt against an intentionally vulnerable system in order to understand the impact of unpatched services and generate attack evidence for security analysis.

Target Environment

• Attacker Machine: Kali Linux
• Target System: Metasploitable 2
• Vulnerable Service: FTP (VSFTPD 2.3.4)
• Attack Framework: Metasploit Framework
• Network Type: Isolated virtual lab network

Vulnerability Identification (Pre-Attack)

Service Discovery

• A service and version scan was performed on the Metasploitable system to identify running services and potential vulnerabilities.
• The scan revealed the following critical finding: - Port: 21/TCP - Service: FTP - Version: VSFTPD 2.3.4 - VSFTPD version 2.3.4 is known to contain a backdoor vulnerability that allows unauthorized remote access when exploited. This step confirms that the target system is vulnerable before attempting exploitation

Exploitation Using Metasploit Framework

• Step 1: Launch Metasploit The Metasploit Framework was started on the Kali Linux attacker machine to conduct the exploitation attempt.

• Step 2: Identify Relevant Exploit Module A search was performed within Metasploit to locate exploit modules related to the VSFTPD service. The module targeting the VSFTPD 2.3.4 backdoor vulnerability was identified and selected.

• Step 3: Configure Exploit Parameters The exploit module was configured with the target system’s IP address. The default FTP service port (TCP 21) was used, as VSFTPD operates on this port.

• Step 4: Execute Exploitation Attempt

• The exploit was executed against the target system.

Observed Results:

• The vulnerable VSFTPD service responded to the exploit
• A backdoor service was successfully triggered
• A command shell session was opened on the target system
• Root-level privileges (UID 0) were obtained This confirms that the exploitation attempt was successful.

Attack Evidence

• What: Successful exploitation of VSFTPD 2.3.4 using Metasploit

• Purpose: Proof of exploitation attempt

• Evidence Shown:

  • Backdoor service spawned
  • Root-level access (UID = 0)
  • Command shell session opened

Result

• A vulnerable FTP service was successfully identified through scanning
• The VSFTPD 2.3.4 backdoor vulnerability was exploited
• Unauthorized root-level access was achieved
• This demonstrates the severe risk posed by outdated and unpatched services

Security and Ethical Considerations

All exploitation activities were conducted strictly within an isolated laboratory environment using intentionally vulnerable systems. No real-world or unauthorized systems were targeted. The purpose of this activity is educational and defensive, focusing on vulnerability awareness and attack detection.

Privilege Escalation / Post-Compromise Activity

Objective

The objective of this scenario is to demonstrate post-compromise activity by executing privileged commands on the target system after successful exploitation. This validates the severity of the compromise and highlights the risks of misconfigured or vulnerable services.

Attack Description

Following successful exploitation of the VSFTPD 2.3.4 service, an interactive shell was obtained on the Metasploitable system. The attacker verified elevated privileges and executed system-level commands that require root access.

Actions Performed

• Verified current user privileges
• Executed privileged system commands
• Confirmed unrestricted access to protected system files

Result

• Root-level privileges were confirmed
• Sensitive system resources became accessible
• The target system was fully compromised

Security Impact

This scenario demonstrates how an initial vulnerability can lead to complete system takeover if privilege escalation paths are available. Proper patching, least-privilege enforcement, and monitoring are critical to prevent such attacks.

Step 3: Log Collection & Centralization

Objective

To collect authentication and system logs from Linux (Kali) and Windows machines and centralize them into a shared folder for evidence preservation and forensic analysis.

Environment Details

• Host OS: Windows
• Linux VM: Kali Linux (VirtualBox)
• Shared Folder Name: KaliShareFolder
• Linux Mount Path: /media/sf_KaliShareFolder
• Windows Path: D:\IDM\KaliShareFolder

A. Linux Log Collection (Kali Linux)

Step 1: Verify Shared Folder Mount

• Where: Kali Linux Terminal
• command run:

ls /media/

• Check Shared Folder Access
• command run:

ls -lh /media/sf_KaliShareFolder

• Initially, access was denied due to permission restrictions.

• Verify Group Membership

• command run:

groups

• Fix Shared Folder Permissions
• command run:

sudo chmod 775 /media/sf_KaliShareFolder

This allowed read/write access for the vboxsf group.

• Export Authentication Logs (Correct Method for Kali)
• command run:

sudo journalctl -u ssh --no-pager | sudo tee /media/sf_KaliShareFolder/auth_scenario1.log > /dev/null

• Export System Logs
• command run:

sudo journalctl --no-pager | sudo tee /media/sf_KaliShareFolder/syslog_scenario1.log > /dev/null

• Verify Log Files

ls -lh /media/sf_KaliShareFolder

auth_scenario1.log    17B
syslog_scenario1.log  1.6M

B. Windows Log Collection (Windows 10 / 11)

1. Open Event Viewer

• Where: Windows GUI
• Press Win + R
• type:
• command run:

eventvwr.msc

2. Navigate to Security Logs,

• command run:

Event Viewer
└─ Windows Logs
   └─ Security

3. Export Windows Security Logs

• Right‑click Security
• Click Save All Events As…
• Save location: D:\IDM\KaliShareFolder

4. File Name:

• command run:

all_events.evtx

• Click Save
• Accept default language options

Final Outcome

• Linux authentication and system logs successfully collected
• Windows Security logs successfully exported
• All logs centralized into a shared folder
• Evidence preserved for further forensic analysis

Move Logs to Kali

Objective: Copy all logs from the shared folder into a Kali directory for centralized storage and easier analysis.

1. Open Kali Terminal

• Click Terminal
• Or press Ctrl + Alt + T
• You should see something like:

┌──(kali㉿kali)-[~]
└─$

2. Create a Directory for the Project Logs

• command run:

mkdir ~/log_project

• mkdir → Make Directory
• ~/log_project → Creates a folder named log_project in your home directory

3. Copy All Logs from Shared Folder

cp /media/sf_KaliShareFolder/* ~/log_project/

• cp → Copy
• /media/sf_KaliShareFolder/* → All files from the shared folder
• ~/log_project/ → Destination in Kali

This copies:

• auth_scenario1.log
• syslog_scenario1.log
• all_events.evtx

4. Verify Logs Are Copied

• command run:

ls -lh ~/log_project

5. Notes for Report All logs from the shared folder were successfully copied into a Kali directory (~/log_project) for centralized storage and analysis. This ensures that Linux and Windows logs are available in one location for forensic investigation.

Step 4: Python Log Analyzer Development

Objective:

To create the main Python script that will serve as the log analyzer for Linux and Windows authentication logs.

Action Taken:

• Opened a terminal in Kali Linux
• Navigated to the project directory: ~/log_project
• Created a new Python script named log_analyzer.py using the nano editor:
• Command run:

gedit log_analyzer.py

• Outcome:
  • The file log_analyzer.py was successfully created in the project directory
  • The script file is ready for code implementation (Step 4.2)

log_analyzer.py

#!/usr/bin/env python3

import re
import argparse
import collections
from datetime import datetime
from Evtx.Evtx import Evtx as evtx_module

# =========================
# Global Incident Timeline
# =========================
timeline = []

# =========================
# Linux Log Parsing
# =========================
def parse_linux_log(file_path):
    failures = collections.defaultdict(int)
    successes = []
    sudo_commands = []

    with open(file_path, 'r', encoding='utf-8', errors='ignore') as f:
        for line in f:
            # Failed SSH login
            failed_match = re.search(r'Failed password for .* from (\S+) port', line)
            if failed_match:
                ip = failed_match.group(1)
                failures[ip] += 1
                timeline.append(("Linux", "FAILED_LOGIN", datetime.now(), ip))

            # Successful SSH login
            success_match = re.search(r'Accepted password for .* from (\S+) port', line)
            if success_match:
                ip = success_match.group(1)
                parts = line.split()
                if len(parts) >= 6:
                    timestamp_str = ' '.join(parts[:3])
                    try:
                        timestamp = datetime.strptime(timestamp_str, '%b %d %H:%M:%S')
                        timestamp = timestamp.replace(year=datetime.now().year)
                        successes.append((timestamp, ip))
                        timeline.append(("Linux", "SUCCESS_LOGIN", timestamp, ip))
                    except ValueError:
                        pass

            # Privilege escalation via sudo
            sudo_match = re.search(r'sudo:.*COMMAND=(.*)', line)
            if sudo_match:
                command = sudo_match.group(1).strip()
                sudo_commands.append(command)
                timeline.append(("Linux", "PRIV_ESC", datetime.now(), command))

    return failures, successes, sudo_commands


# =========================
# Windows EVTX Parsing
# =========================
def parse_windows_log(file_path):
    failures = collections.defaultdict(int)
    successes = []

    try:
        with evtx_module(file_path) as evtx:
            for record in evtx.records():
                root = record.lxml()
                ns = {'e': 'http://schemas.microsoft.com/win/2004/08/events/event'}

                event_id_elem = root.find('.//e:EventID', ns)
                if event_id_elem is None:
                    continue
                event_id = event_id_elem.text.strip()

                time_elem = root.find('.//e:TimeCreated', ns)
                timestamp = None
                if time_elem is not None:
                    ts = time_elem.attrib.get('SystemTime')
                    if ts:
                        ts = ts.split('.')[0].rstrip('Z')
                        try:
                            timestamp = datetime.fromisoformat(ts)
                        except ValueError:
                            pass

                ip_elem = root.find('.//e:Data[@Name="IpAddress"]', ns)
                ip = None
                if ip_elem is not None and ip_elem.text:
                    ip_text = ip_elem.text.strip()
                    if ip_text not in ['-', '::1', '127.0.0.1', '0.0.0.0']:
                        ip = ip_text

                # Failed login
                if event_id == '4625' and ip:
                    failures[ip] += 1
                    timeline.append(("Windows", "FAILED_LOGIN", timestamp, ip))

                # Successful login
                elif event_id == '4624' and ip and timestamp:
                    successes.append((timestamp, ip))
                    timeline.append(("Windows", "SUCCESS_LOGIN", timestamp, ip))

    except Exception as e:
        print(f"[ERROR] Could not parse .evtx file: {e}")
        return {}, []

    return failures, successes


# =========================
# Anomaly Detection
# =========================
def detect_anomalies(failures, threshold=10):
    alerts = []
    for ip, count in sorted(failures.items(), key=lambda x: x[1], reverse=True):
        if count > threshold:
            alerts.append(f"[ALERT] Possible brute force from {ip}: {count} failed attempts")
    return alerts


# =========================
# Main Execution
# =========================
if __name__ == "__main__":
    parser = argparse.ArgumentParser(
        description="LogSentinel - Advanced Threat Log Analyzer (Blue Team Project)"
    )
    parser.add_argument("--linux_log", help="Path to Linux auth/syslog file")
    parser.add_argument("--windows_log", help="Path to Windows Security .evtx file")
    parser.add_argument("--threshold", type=int, default=10, help="Brute-force alert threshold")
    args = parser.parse_args()

    all_failures = collections.defaultdict(int)
    all_successes = []
    sudo_commands = []

    print("\n=== LogSentinel Analysis Report ===\n")

    # Linux analysis
    if args.linux_log:
        print(f"[+] Parsing Linux log: {args.linux_log}")
        linux_fails, linux_success, linux_sudo = parse_linux_log(args.linux_log)

        for ip, count in linux_fails.items():
            all_failures[ip] += count

        all_successes.extend(linux_success)
        sudo_commands.extend(linux_sudo)

        print(f"    Failed logins: {sum(linux_fails.values())}")
        print(f"    Successful logins: {len(linux_success)}")
        print(f"    Sudo commands: {len(linux_sudo)}")

    # Windows analysis
    if args.windows_log:
        print(f"[+] Parsing Windows log: {args.windows_log}")
        windows_fails, windows_success = parse_windows_log(args.windows_log)

        for ip, count in windows_fails.items():
            all_failures[ip] += count

        all_successes.extend(windows_success)

        print(f"    Failed logins: {sum(windows_fails.values())}")
        print(f"    Successful logins: {len(windows_success)}")

    # Anomaly detection
    print("\n[+] Running anomaly detection...")
    alerts = detect_anomalies(all_failures, args.threshold)

    if alerts:
        print("\n".join(alerts))
    else:
        print("    No brute-force activity detected.")

    if alerts and all_successes:
        print("\n[WARNING] Successful login observed after brute-force activity.")

    # =========================
    # Incident Timeline Output
    # =========================
    if timeline:
        print("\n[+] Full Incident Timeline:")
        timeline.sort(key=lambda x: x[2] if x[2] else datetime.now())

        for source, event, ts, detail in timeline:
            ts_str = ts.strftime('%Y-%m-%d %H:%M:%S') if ts else "N/A"
            print(f"    [{source}] {ts_str} - {event} - {detail}")

    # Privilege escalation summary
    if sudo_commands:
        print("\n[+] Privilege Escalation Indicators:")
        for cmd in sudo_commands[:10]:
            print(f"    {cmd}")
        if len(sudo_commands) > 10:
            print(f"    ... and {len(sudo_commands) - 10} more")

    print("\n=== Analysis Complete ===\n")

Implement Parsing

Objective:

Parse Linux and Windows authentication logs, detect brute-force attempts, and correlate IP addresses across platforms using Python regex logic.

• Command run:

1. Linux Analysis

python3 log_analyzer.py --linux_log syslog_scenario1.log --threshold 10

=== LogSentinel Analysis Report ===

[+] Parsing Linux log: syslog_scenario1.log
    Found 11 failed login attempts from 1 IPs

[+] Running anomaly detection...
[ALERT] Possible brute force from 192.168.56.2: 11 failed attempts

=== Analysis Complete ===

Explanation:

• Script parsed syslog_scenario1.log.
• Detected 11 failed SSH login attempts from 192.168.56.2.
• Threshold alert correctly triggered (>10 failures).
• Linux sudo commands and successful logins also supported.

2. Windows Log Analysis

• Command run:

python3 log_analyzer.py --windows_log all_events.evtx

=== LogSentinel Analysis Report ===

[+] Parsing Windows log: all_events.evtx

[+] Running anomaly detection...
    No brute force attempts detected above threshold.

=== Analysis Complete ===

Explanation:

• Windows Security logs parsed from all_events.evtx.
• Detects Event ID 4625 (failed logon) and 4624 (successful logon).
• No threshold alert triggered for Windows logs in this dataset.

3. Cross-Platform IP Correlation

python3 log_analyzer.py --linux_log syslog_scenario1.log --windows_log all_events.evtx --threshold 10

=== LogSentinel Analysis Report ===

[+] Parsing Linux log: syslog_scenario1.log
    Found 11 failed login attempts from 1 IPs
[+] Parsing Windows log: all_events.evtx

[+] Running anomaly detection...
[ALERT] Possible brute force from 192.168.56.2: 11 failed attempts

=== Analysis Complete ===

Explanation:

• Combined analysis of Linux and Windows logs performed.
• Linux brute-force attempts detected and flagged.
• Cross-platform correlation enabled by unified script.

4. Regex Logic Verification

• Command run:

gedit log_analyzer.py

• the key regex lines are:

# Linux failed login
failed_match = re.search(r'Failed password for .* from (\S+) port', line)

# Linux successful login
success_match = re.search(r'Accepted password for .* from (\S+) port', line)

# Linux sudo commands
sudo_match = re.search(r'sudo:.*COMMAND=(.*)', line)

• Purpose: Extract failed logins, successful logins, and sudo command usage from Linux logs.

✅ Summary:

• Failed login regex: r'Failed password for .* from (\S+) port'
• Successful login regex: r'Accepted password for .* from (\S+) port'
• Sudo commands regex: r'sudo:.COMMAND=(.)'

Step 5: Timeline & Incident Analysis

Objective

The objective of Step 5 is to reconstruct a security incident timeline using system logs and detect anomalous behavior such as brute‑force attacks. This step demonstrates blue‑team incident response, log correlation, and detection capability.

Generate Incident Timeline

Purpose

To reconstruct the sequence of events during a suspected attack, including:

• Failed authentication attempts
• Successful logins (if any)
• Privilege escalation activity

Log Source Identification

Linux Logs Used

• syslog_scenario1.log (Contains SSH authentication failures and sudo activity)
• Windows Logs Used all_events.evtx (Parsed offline for authentication events)

Log Verification Commands

• command run:

grep -i "failed password" syslog_scenario1.log
grep -i "accepted password" syslog_scenario1.log
grep -i "sudo" syslog_scenario1.log

Result

• Multiple failed SSH login attempts detected
• Sudo (privilege escalation) commands detected
• No successful SSH logins present

Incident Timeline Generation

• command run:

python3 log_analyzer.py \
  --linux_log syslog_scenario1.log \
  --windows_log all_events.evtx \
  --threshold 10

Interpretation

• 11 failed SSH login attempts occurred within a short time window
• All attempts originated from a single source IP
• No successful login was detected
• Indicates a brute‑force attack attempt

Anomaly Detection Output

Purpose

To automatically identify malicious behavior using threshold‑based detection.

• Detection Logic
• Threshold set to 10 failed attempts
• Any IP exceeding the threshold triggers an alert
• Alert Detection Output

[ALERT] Possible brute force from 192.168.56.2: 11 failed attempts

Interpretation

• The source IP exceeded the defined threshold
• Alert correctly identifies SSH brute‑force behavior
• Confirms effective blue‑team detection capability