Introduction

This writeup documents a complete SOC investigation into a multi-stage cyber attack targeting SomeCorp's infrastructure. You'll walk through the entire incident response process—from initial alert triage to evidence collection—using Elastic Stack's powerful Kibana interface. This investigation demonstrates real-world techniques for correlating logs across multiple sources to reconstruct an attack timeline.

Task 2: Environment Setup and Initial Reconnaissance

Overview

Before diving into alert investigation, establishing the proper Kibana environment is crucial. This task introduces you to the data you'll be working with and ensures you understand the scope of available logs.

Question 1: How many logs are available for analysis within the entire time range?

Answer: 1467

Investigation Steps:

  1. Access the Kibana dashboard at the provided URL

  2. Click on the Data View dropdown (top-left area)

  3. Select "Alert Triage With Elastic" from the available data views

  4. Click on the calendar icon (time picker) in the top-right corner

  5. Select "Entire data range" from the quick select options

  6. Observe the total hit count displayed above the log entries (typically shows "1,467 hits")

Why This Matters: Understanding the total log volume helps you gauge the investigation scope. In this case, 1,467 logs represent a manageable dataset for detailed analysis. In production environments, you'd be dealing with millions of logs, making filtering techniques even more critical..

Question 2: What is the field value for the client.ip in the weblogs index?

Answer: 203.0.113.55

Investigation Steps:

  1. In the Kibana search bar, enter the query: _index:weblogs

  2. Press Enter to apply the filter

  3. Notice the log count reduces significantly (filtering only web server logs)

  4. Look at the Available Fields panel on the left sidebar

  5. Scroll down to find the client.ip field

  6. Click on the field name to expand it

  7. View the Top 5 values section—you'll see only one IP address: 203.0.113.55

Why This Matters: The _index filter allows you to focus on specific log sources. By isolating weblogs (IIS server logs) from Windows event logs, you can analyze web-based attacks separately. The presence of only one client IP in the weblogs immediately flags this as potentially suspicious—legitimate web servers typically have multiple client IPs.

Task 3: Investigating Web Attacks

Overview

This task focuses on identifying web-based exploitation attempts. You'll investigate automated attacks targeting the ProxyLogon vulnerability (CVE-2021-26855), a critical Microsoft Exchange Server flaw that allows unauthenticated attackers to bypass authentication and execute arbitrary commands.

Question 1: How many POST requests did the IP address 203.0.113.55 make to proxyLogon.ecp?

Answer: 3

Investigation Steps:

  1. Clear any previous filters in the search bar

  2. Enter this KQL query:

    _index:weblogs and client.ip:203.0.113.55 and http.request.method:POST

  3. Build a data table by clicking the "+" icon next to these fields:

    • client.ip

    • user.agent

    • http.request.method

    • url.path

    • http.response.status_code

  4. Count the visible POST request entries (should show exactly 3 logs)

Technical Analysis: POST requests to proxyLogon.ecp are characteristic of ProxyLogon exploitation attempts. The endpoint is part of Microsoft Exchange's Explicit Logon functionality. In normal operations, legitimate users rarely access this endpoint directly. Three consecutive POST requests suggest automated exploitation.

Question 2: Which user.agent paired with the IP address 203.0.113.55 made the POST requests?

Answer: python-requests/2.25.1 (may vary in different instances)

Investigation Steps:

  1. Using the same query from Question 1

  2. Look at the user.agent column in your table

  3. Identify the user agent string (will be consistent across all three requests)

Red Flag Identification: The python-requests user agent is a dead giveaway of automated exploitation. Legitimate users access web applications through browsers (Chrome, Firefox, Edge), not Python HTTP libraries. This immediately confirms automated attack tooling is being used.

Question 3: How many logs contain the cmd= query parameter in the url.path field?

Answer: 20

Investigation Steps:

  1. Modify your query to search for web shell activity:

    _index:weblogs and client.ip:203.0.113.55 and http.request.method:GET and errorEE.aspx

  2. Click the sort order button and select "Sort Old → New" (chronological order)

  3. Examine the url.path field in your table

  4. Count entries containing the cmd= parameter (should show 20 logs total)

Technical Analysis: The cmd= parameter is a signature indicator of web shell activity. Web shells are malicious scripts uploaded to compromised servers that allow attackers to execute arbitrary commands. The format errorEE.aspx?cmd=[command] shows the attacker issuing commands directly through HTTP GET requests. This represents successful post-exploitation activity.

Question 4: Which command was run utilizing errorEE.aspx on Jul 20, 2025 @ 04:45:50.000?

Answer: hostname

Investigation Steps:

  1. Keep the same query active from Question 3

  2. Click on the time picker and set a custom time range around the target timestamp

  3. Or use the table's search functionality to locate the exact timestamp: 04:45:50.000

  4. Examine the url.path field for that specific log entry

  5. Parse the URL parameter: errorEE.aspx?cmd=hostname

Attack Timeline Context: The hostname command is a reconnaissance command attackers use to identify the compromised system's identity. This typically appears early in the command sequence, following basic commands like whoami and ipconfig. It's part of the discovery phase of the attack lifecycle.

Key Takeaways from Task 3:

  • ProxyLogon exploitation occurred using automated Python tooling

  • Web shell (errorEE.aspx) was successfully deployed

  • Attacker executed 20 commands for reconnaissance and further exploitation

  • Attack progression: Vulnerability exploitation → Web shell deployment → Command execution

Task 4: Uncovering Account Activity

Overview

Web logs showed the initial compromise, but now you must pivot to host-based evidence. This task focuses on Windows Security Event logs and Sysmon to track authentication events and user account manipulation—critical indicators of lateral movement and persistence establishment.

Question 1: What is the winlog.record_id of the Administrator 4624 logon event?

Answer: 17166 (may vary in different instances)

Investigation Steps:

  1. Enter this query to filter for Administrator logon events:

    @timestamp >= "2025-07-20T05:11:22" and winlog.event_id:4624 and host.name:winserv2019.some.corp and winlog.event_data.TargetUserName:Administrator

  2. Build a table with these columns:

    • winlog.event_id

    • host.name

    • winlog.event_data.TargetUserName

    • winlog.logon.type

    • winlog.event_data.IpAddress

  3. Locate the matching Administrator logon event

  4. Click the expand arrow (>) on the left side of the log entry

  5. Scroll through the JSON document view

  6. Find the field winlog.record_id and note its value

Understanding Event ID 4624: This Windows Security event logs every successful authentication to a Windows system. The event contains critical forensic data including logon type (interactive, network, RDP), source IP address, and account name. Logon Type 10 specifically indicates RemoteInteractive (RDP) logons.

Correlation Alert: Notice the IpAddress field shows 203.0.113.55—the same IP from the web attacks. This confirms the attacker leveraged the compromised web server to pivot into the Windows environment via RDP.

Question 2: What is the process.pid of the Sysmon 1 event that occurred on Jul 20, 2025 @ 05:11:27.996?

Answer: 964

Investigation Steps:

  1. Clear previous filters and enter this Sysmon-focused query:

    @timestamp >= "2025-07-20T05:11:27.996" and winlog.event_id:1 and user.name:Administrator

  2. Add these fields as table columns:

    • user.name

    • process.parent.name

    • process.command_line

    • process.pid

  3. Filter to the exact timestamp: 05:11:27.996

  4. Locate the process.pid field value in the matching log

Understanding Sysmon Event ID 1: Sysmon (System Monitor) is a Windows system service that logs detailed process creation events. Event ID 1 captures process creation with parent-child relationships, command-line arguments, and file hashes—invaluable for tracking attacker activity. PID (Process ID) is the unique identifier Windows assigns to each running process.

Process Chain Analysis: The PID 964 process is likely dwm.exe (Desktop Window Manager) or csrss.exe (Client Server Runtime Subsystem), which are normal Windows session initialization processes following an RDP logon. This confirms the logon completed successfully.

Question 3: What is the winlog.event_id for the new user account being created?

Answer: 4720

Investigation Steps:

  1. Use this query targeting user account management activities:

    @timestamp >= "2025-07-20T05:13:10.000" and winlog.channel:Security and winlog.task:User Account Management

  2. Create a table with these columns:

    • winlog.event_id

    • winlog.task

    • message

  3. Sort Old → New to see earliest events first

  4. Look for the event with task description related to user creation

Understanding Event ID 4720: This Security event logs whenever a new user account is created on a Windows system. In enterprise environments, legitimate user account creation typically happens through automated provisioning systems or during business hours by IT staff. An account created at 5:13 AM by a recently compromised Administrator account is highly suspicious.

Question 4: What is the name of the new user account?

Answer: svc_backup

Investigation Steps:

  1. Using the same query from Question 3

  2. Examine the message field in the 4720 event

  3. Look for the Account Name or TargetUserName field within the message

  4. Note the username: svc_backup

Threat Intelligence Analysis: The name svc_backup follows common IT naming conventions (svc = service account). Attackers deliberately choose names that blend in with legitimate system accounts to avoid detection. Service accounts typically have elevated privileges and are less frequently monitored than standard user accounts, making them ideal for persistence.

Attack Progression:

  1. 05:11:22 - Administrator RDP logon from attacker IP

  2. 05:13:10 - Backdoor account svc_backup created

  3. This represents the persistence establishment phase

Task 5: Exposing Command Execution

Overview

Account creation alone isn't enough for full system compromise. This task reveals how the attacker escalated privileges, added the backdoor account to administrative groups, and performed reconnaissance using multiple command-line tools.

Question 1: What command does the attacker use to add the new account to the "Remote Desktop Users" group?

Answer: net localgroup "Remote Desktop Users" svc_backup /add

Investigation Steps:

  1. Query for command-line activity:

    @timestamp >= "2025-07-20T05:13:15" and process.parent.name:cmd.exe and user.name:Administrator

  2. Create a table with these columns:

    • process.command_line

    • process.name

    • process.parent.name

  3. Sort chronologically (Old → New)

  4. Scan through the process.command_line column

  5. Locate the net localgroup command adding user to Remote Desktop Users group

Understanding net localgroup Command: This Windows built-in command manages local group memberships. The Remote Desktop Users group grants logon rights via RDP. By adding svc_backup to this group, the attacker ensures persistent remote access even if the Administrator account is later secured.

Complete Privilege Escalation Sequence:

net user svc_backup Password123 /add
net localgroup "Server Operators" svc_backup /add
net localgroup "Remote Desktop Users" svc_backup /add  
net localgroup "Administrators" svc_backup /add

This shows methodical privilege escalation to multiple high-privilege groups.

Question 2: What is the winlog.record_id of the 4732 Security event when the attacker adds the user to the Administrator group?

Answer: 17254 (may vary in different instances)

Investigation Steps:

  1. Expand your query to include both Sysmon process creation and Security events:

    @timestamp >= "2025-07-20T05:13:15" and (winlog.event_id:4732 or process.parent.name:cmd.exe)

  2. Build a table showing:

    • winlog.event_id

    • winlog.record_id

    • process.command_line

    • message

  3. Look for Event ID 4732 entries

  4. Find the one where the message indicates addition to the "Administrators" group

  5. Note the winlog.record_id value

Understanding Event ID 4732: This Security event logs "A member was added to a security-enabled local group." It's the Windows audit trail confirmation of the net localgroup commands you saw in Sysmon logs. Correlating Sysmon Event ID 1 (process creation) with Security Event ID 4732 (group modification) provides multi-source validation.

Correlation Power: You now have:

  • Sysmon evidence: The actual command executed

  • Security event evidence: The Windows security subsystem's confirmation This dual-source corroboration strengthens your investigation findings.

Question 3: What PowerShell command did the attacker run on Jul 20, 2025 @ 05:16:14.628?

Answer: net group "Domain Admins" /domain

Investigation Steps:

  1. Query for PowerShell script block logging:

    @timestamp >= "2025-07-20T05:13:15" and event.module:powershell and event.code:4104

  2. Add the powershell.file.script_block_text column (shows actual commands in plaintext)

  3. Sort Old → New

  4. Navigate to timestamp 05:16:14.628

  5. Read the command from the script block text field

Understanding PowerShell Event 4104: Script Block Logging captures the actual PowerShell code executed on the system. This event type was introduced specifically for security monitoring. The command net group "Domain Admins" /domain enumerates domain administrator accounts—critical reconnaissance for domain-wide compromise.

Attack Pivot Analysis: The attacker switched from local reconnaissance (whoami, whoami /priv, hostname) to domain reconnaissance. This signals an escalation from single-host compromise to potential domain-wide lateral movement.

Question 4: What is the name of the archive that the attacker creates using the Rar.exe executable?

Answer: finance_it_archive.rar

Investigation Steps:

  1. Use this simple process name query:

    process.name: "Rar.exe"

  2. Add process.command_line and user.name columns

  3. Examine the full RAR command line

  4. Parse the output filename from the command

Example command line you'll see:

"C:\Program Files\WinRAR\Rar.exe" a -r -ep1 finance_it_archive.rar "C:\Users\ITAdmin\Documents\" "C:\Scripts\"

Understanding the RAR Command:

  • a = add files to archive

  • -r = recursive (include subdirectories)

  • -ep1 = exclude base folder from paths

  • Target: finance_it_archive.rar

  • Sources: Documents and Scripts folders

Data Exfiltration Evidence: RAR.exe is legitimate compression software, which is why no alert triggered. However, in context:

  • Executed by recently created svc_backup account

  • Targeting sensitive folders (IT admin documents and scripts)

  • Created during a confirmed intrusion timeline

  • Unusual file name suggesting targeted data theft

This represents the collection and staging phase before data exfiltration.

Task 6: Conclusion

Complete Attack Chain Reconstruction

Based on your investigation, here's the full attack timeline:

Phase 1: Initial Access (04:38 - 04:46)

  • 04:38:00 - Attacker scans for ProxyLogon vulnerability

  • 04:38:15 - Three POST requests exploit CVE-2021-26855

  • 04:40:30 - Web shell errorEE.aspx deployed successfully

  • 04:45:50 - First commands executed (hostname, whoami, ipconfig)

Phase 2: Privilege Escalation (05:11 - 05:14)

  • 05:11:22 - RDP logon as Administrator from attacker IP

  • 05:13:10 - Backdoor account svc_backup created

  • 05:13:45 - Account added to Server Operators

  • 05:13:48 - Account added to Remote Desktop Users

  • 05:13:52 - Account added to Administrators

Phase 3: Persistence & Reconnaissance (05:14 - 05:17)

  • 05:14:30 - PowerShell reconnaissance begins

  • 05:16:14 - Domain Admin enumeration (net group "Domain Admins" /domain)

  • 05:16:45 - Additional privilege verification (whoami /priv)

Phase 4: Collection & Staging (05:18 - 05:25)

  • 05:18:20 - RAR compression of IT admin documents

  • 05:22:15 - Archive finance_it_archive.rar created

  • 05:25:00 - Likely exfiltration preparation completed

Key Indicators of Compromise (IoCs)

Network Indicators:

  • Source IP: 203.0.113.55

  • User-Agent: python-requests/2.25.1

  • ProxyLogon.ecp POST requests

Host Indicators:

  • Web shell: errorEE.aspx

  • Backdoor account: svc_backup

  • RAR archive: finance_it_archive.rar

  • Suspicious RDP logon at 05:11:22

Behavioral Indicators:

  • Off-hours Administrator activity (5 AM)

  • Rapid group membership modifications

  • Domain reconnaissance commands

  • Compression of sensitive directories

Investigation Techniques Demonstrated

  1. Multi-source log correlation: Combined IIS logs, Windows Security logs, Sysmon logs, and PowerShell logs

  2. Timeline construction: Chronological ordering revealed attack progression

  3. KQL query crafting: Targeted queries isolated specific IOCs

  4. Context analysis: Distinguished normal vs. malicious use of legitimate tools (RAR.exe)

  5. Evidence collection: Recorded specific record IDs and artifacts for incident response

Final Thoughts

This investigation showcased the power of the Elastic Stack for security operations. By systematically querying different log sources and correlating events across time, you reconstructed a sophisticated multi-stage attack from initial exploitation through data staging.

The key lesson: no single log source tells the complete story. Web logs revealed the entry point, Windows Security logs showed credential abuse, Sysmon tracked process execution, and PowerShell logs exposed reconnaissance activity. Only by correlating all sources could you build the complete attack narrative.

Continue practicing these investigation techniques in the recommended rooms to further enhance your SOC analyst skillset!

Happy hunting, and remember: the best defense is a vigilant SOC analyst who knows how to read the logs!

Keep Reading

No posts found

© 2025 Andrés.

Report abuse

Privacy policy

Terms of use

Powered by beehiiv