SOC Foundation Lab — Demond Mack

Case Studies

SOC Investigations

Three investigations covering SSH and RDP brute force detection, a full Mythic C2 attack chain from initial access to exfiltration, and EDR-driven endpoint response using Elastic Defend.

Case Study 01 — Network / Endpoint

SSH & RDP Brute Force Detection

High Severity T1110.001 Detected & Alerted Real Attack Telemetry

▼

Both SSH and RDP services were exposed to the internet on Vultr-hosted servers, immediately attracting real external brute force attacks. Failed authentication logs from /var/log/auth.log on the Ubuntu SSH server and Windows Event ID 4625 on the RDP server were ingested into Elasticsearch via Elastic Agent and Fleet Server.

Custom Kibana alerts were created for both services — triggering after 5 failed login attempts within 5 minutes. Geographic dashboards visualized attack sources in real time. osTicket was integrated with Elasticsearch via API key to automatically generate tickets when alerts fired.

ANALYST FINDING

Multiple external IPs confirmed actively brute forcing both SSH and RDP services. Threat intelligence enrichment via AbuseIPDB and GreyNoise confirmed malicious intent. No successful unauthorized logons detected. Firewall rules updated to restrict access.

SSH Detection — Kibana Query

agent.name: "my-ubuntu-ssh" AND system.auth.ssh.event: "Failed"
AND system.auth.user: "root"
// Alert threshold: 5 failures in 5 minutes
// Dashboard: SSH Failed Activity — GeoIP map of source IPs

RDP Detection — Event ID 4625

event.code: "4625"
// Logon failure — wrong username or password
// Key fields: source.ip, winlog.event_data.TargetUserName
// Alert threshold: 5 failures in 5 minutes

Investigation Findings — click to expand analyst actions

▶Multiple external IPs identified targeting root account via SSH brute force

// Kibana — extract attacker IPs from SSH auth logs

agent.name: "my-ubuntu-ssh" AND system.auth.ssh.event: "Failed" | extract source.ip, system.auth.user | stats count by source.ip | sort count desc // Cross-reference each IP on AbuseIPDB and GreyNoise

▶RDP failed logons analyzed — source IPs and usernames extracted for investigation

// Kibana — RDP failed logon analysis

event.code: "4625" // Add fields: source.ip, winlog.event_data.TargetUserName // Save as "RDP Failed Activity" // Check for any 4624 success events from same IPs

▶osTicket automatically created incidents when alert thresholds were exceeded

// osTicket integration — Elasticsearch alert webhook

# Elasticsearch alert action → HTTP POST to osTicket API # API key configured in Kibana connector # Auto-populates ticket with: alert name, source IP, # timestamp, affected host, event count # Analyst assigned for triage and investigation

MITRE ATT&CK

ID	Technique	Evidence
T1110.001	Brute Force: Password Guessing	Multiple failed SSH and RDP authentication attempts from external IPs
T1133	External Remote Services	SSH port 22 and RDP port 3389 targeted as external access vectors
T1078	Valid Accounts	Root account targeted on SSH server — high value target

No breach occurred. The following documents what would have triggered escalation and the exact response actions.

IOCs That Would Have Indicated Compromise

▶ Event ID 4624 or SSH "Accepted" from any attacker IP

▶ New process spawned immediately after successful logon from external IP

▶ Outbound connection from server to attacker IP after successful auth

▶ New user account created — persistence mechanism

▶ Sysmon Event ID 3 — network connection to unknown external IP

Response Actions

▶Step 1: Block attacker IP at Vultr firewall immediately

// Vultr — add firewall rule to block attacker IP

# Vultr firewall group — add inbound deny rule # Source IP: [attacker IP] # Ports: All # Action: Drop # Also configure Fail2Ban on Ubuntu SSH server: fail2ban-client set sshd banip [attacker_ip]

▶Step 2: Check for successful SSH logons and active sessions

// Linux — check for active sessions and recent successful logins

who # active sessions last # recent login history grep "Accepted" /var/log/auth.log | tail -20 # Check for new cron jobs or authorized_keys modifications cat /root/.ssh/authorized_keys crontab -l

Evidence collected — Kibana dashboards, alert configuration, osTicket integration, and threat intelligence.

SSH Auth Logs

Failed root login attempts extracted from auth.log

Attacker IPs Extracted

grep and cut commands isolating source IPs

SSH Failed Activity

Kibana dashboard — GeoIP map of attack sources

RDP Failed Activity

Event ID 4625 — failed logon visualization

osTicket Incident

Auto-generated ticket from Elasticsearch alert

osTicket Integration

API key configuration and alert connector

Case Study 02 — C2 / Threat Hunting

Mythic C2 Full Attack Chain Investigation

Critical Mythic C2 T1059.001 · T1041 · T1003 Detected & Investigated

▼

Attack phases

Session established

File exfiltrated

✓

Fully detected

A controlled red team exercise simulated a full adversary attack chain using Mythic C2 framework and Kali Linux as the attack platform. The attack progressed through 6 phases: RDP brute force for initial access, discovery commands, disabling Windows Defender for defense evasion, downloading and executing a Mythic Apollo agent via PowerShell, establishing a C2 session, and exfiltrating a simulated password file.

The investigation used Sysmon telemetry and Elasticsearch queries to reconstruct the full attack timeline. Process GUIDs were used to correlate process creation, network connections, and file operations to the Apollo C2 agent. A custom Kibana alert and suspicious activity dashboard were created to detect future C2 activity.

ANALYST FINDING

Full attack chain detected and documented. Apollo agent identified via SHA-256 hash and original filename. C2 network connections traced to Mythic server. File exfiltration confirmed via process GUID correlation. All 6 attack phases mapped to MITRE ATT&CK framework.

Attack Chain Timeline

Phase 1 — Initial Access

RDP Brute Force — T1110.001

Hydra used on Kali Linux to brute force RDP credentials on Windows Server. Successful logon achieved after multiple attempts.

Phase 2 — Discovery

System Discovery Commands — T1082

whoami, ipconfig, net user, net group executed to enumerate the environment post-access.

Phase 3 — Defense Evasion

Windows Defender Disabled — T1562.001

Set-MpPreference -DisableRealtimeMonitoring $true executed via PowerShell to disable Defender before agent deployment.

Phase 4 — Execution

Mythic Apollo Agent Deployed — T1059.001

PowerShell used to download and execute Apollo agent (servicehost.exe) from Mythic C2 server. Agent masqueraded as legitimate Windows process.

Phase 5 — C2

C2 Session Established — T1071.001

Apollo agent connected back to Mythic C2 server. Active session confirmed in Mythic console. Full command and control established.

Phase 6 — Exfiltration

File Exfiltrated — T1041

passwords.txt downloaded from Windows Server via active C2 session. File transfer logged in Mythic console and Sysmon telemetry.

Investigation — Process GUID Correlation

▶Apollo agent identified via SHA-256 hash and original filename in Sysmon Event ID 1

// Kibana — query for process creation with Apollo agent filename

event.code: "1" AND winlog.event_data.OriginalFileName: "Apollo.exe" // Extract: SHA-256 hash, process GUID, parent process // SHA-256 submitted to VirusTotal for confirmation // Process GUID used to correlate all subsequent activity

▶C2 network connections traced using process GUID from Apollo agent

// Kibana — correlate network connections to Apollo process GUID

event.code: "3" AND winlog.event_data.ProcessGuid: "[apollo_guid]" // Shows: destination IP (Mythic C2 server), port, timestamp // Confirms outbound C2 communication channel established

▶File exfiltration confirmed via Sysmon file creation event correlated to C2 session

// Kibana — file operations correlated to Apollo process GUID

event.code: "11" AND winlog.event_data.ProcessGuid: "[apollo_guid]" // Shows: passwords.txt file access and download // Timestamp correlates with active C2 session window // Confirms data was accessed and transferred

MITRE ATT&CK

ID	Technique	Phase
T1110.001	Brute Force: Password Guessing	Initial Access
T1082	System Information Discovery	Discovery
T1562.001	Impair Defenses: Disable Security Tools	Defense Evasion
T1059.001	PowerShell	Execution
T1071.001	Application Layer Protocol: Web	C2
T1041	Exfiltration Over C2 Channel	Exfiltration

This was a controlled simulation — all activity was intentional. The following documents what a real incident response would look like if this attack chain was discovered in a production environment.

Immediate Containment Actions

▶Step 1: Isolate compromised host immediately using Elastic Defend

// Elastic Defend — isolate host from network

# In Kibana Security → Endpoints # Select compromised host → Actions → Isolate Host # This cuts all network connections except Elastic agent # Prevents further C2 communication and lateral movement # Host remains manageable via Elastic console

▶Step 2: Kill C2 process and collect forensic evidence

// PowerShell — terminate C2 agent and preserve evidence

# Get process details before killing Get-Process servicehost | Select-Object Id, Path, StartTime # Hash the executable for evidence Get-FileHash "C:\path\to\servicehost.exe" -Algorithm SHA256 # Kill the process Stop-Process -Name "servicehost" -Force # Do NOT delete the file — preserve for forensics

▶Step 3: Check for persistence mechanisms left by the attacker

// Kibana — check for persistence artifacts

# Scheduled tasks created during attack window event.code: "4698" AND @timestamp >= [attack_start_time] # New services installed event.code: "7045" AND @timestamp >= [attack_start_time] # Registry run keys modified event.code: "13" AND winlog.event_data.TargetObject: "*Run*" # New user accounts created event.code: "4720" AND @timestamp >= [attack_start_time]

Scope Determination

Check: Did the C2 agent attempt lateral movement to other hosts?

Check: Were any credentials dumped (LSASS access — Event ID 4656)?

Check: What data was exfiltrated — assess sensitivity and compliance impact

If sensitive data exfiltrated: Legal and compliance notification required — escalate immediately

Evidence from the full attack chain simulation and subsequent investigation.

Attack Diagram

Full 6-phase attack chain mapped in draw.io

Mythic C2 Server

Server initialized with Apollo agent profile

C2 Session Active

Apollo agent connected — full C2 control established

File Exfiltrated

passwords.txt downloaded via active C2 session

Process Creation Query

Event code 1 — Apollo.exe original filename detected

C2 Detection Alert

Kibana alert fires on Apollo agent process creation

Suspicious Activity Dashboard

PowerShell, CMD, network connections, Defender disabled

SHA-256 Hash Extracted

Apollo agent hash for VirusTotal submission

Case Study 03 — EDR Response

Elastic Defend EDR — Malware Detection & Host Isolation

Critical Elastic Defend T1204 · T1562 Blocked & Isolated

▼

Malware blocked

SHA256

Hash captured

✓

Host isolated

Execution allowed

Elastic Defend EDR was deployed on the Windows Server endpoint to provide real-time detection and prevention capabilities. When a malicious file (mydfir-30.exe) was executed on the host, Elastic Defend immediately blocked the execution, generated a prevention alert, and provided full telemetry including the file hash, path, parent process, and execution context.

The host isolation feature was demonstrated — cutting all network connections except the Elastic agent management channel — allowing the analyst to maintain visibility and control of the compromised endpoint while preventing further attacker activity or lateral movement.

ANALYST FINDING

Malicious file execution blocked at the endpoint before any payload executed. SHA-256 hash captured and documented. Host successfully isolated via Elastic Defend console. EDR telemetry provided full context for investigation without requiring manual log analysis.

EDR Prevention Event Details

# Elastic Defend prevention alert fields:
file.hash.sha256: [malware_hash]
file.path: C:\Users\[user]\Downloads\mydfir-30.exe
process.parent.name: explorer.exe
event.action: "prevented"
agent.hostname: [windows_server]
@timestamp: [detection_time]

Investigation Findings — click to expand analyst actions

▶Malicious file blocked — SHA-256 hash extracted and submitted to VirusTotal

// PowerShell — hash the blocked file for threat intel

Get-FileHash "C:\Users\user\Downloads\mydfir-30.exe" -Algorithm SHA256 # Submit hash to VirusTotal: https://virustotal.com # Check detection ratio across 70+ AV engines # Identify malware family and behavior indicators

▶Host isolated via Elastic Defend — network severed, agent connection maintained

// Kibana — isolate host via Elastic Defend console

# Security → Endpoints → Select host # Actions → Isolate Host # Confirm isolation — status changes to "Isolated" # All network traffic blocked EXCEPT: # - Elastic agent management (port 443 to Fleet) # Analyst can still run commands via Osquery or response actions

▶Telemetry reviewed — file path, parent process, and user context documented

// Kibana — query for full EDR event context

event.action: "prevented" AND agent.hostname: "[hostname]" // Review: file.path, file.hash.sha256 // Review: process.parent.name — how was it launched? // Review: user.name — which account attempted execution? // Review: @timestamp — correlate with other events

MITRE ATT&CK

ID	Technique	Evidence
T1204.002	User Execution: Malicious File	User attempted to execute mydfir-30.exe from Downloads folder
T1562.001	Impair Defenses	Defender disabled prior to execution attempt — EDR still caught it
T1055	Process Injection (suspected)	Malware behavior profile suggests injection capability

Elastic Defend blocked this execution. The following documents what would have happened if EDR was not deployed or was bypassed.

If EDR Was Not Present or Bypassed

▶ Malware executes — new process spawned under user context

▶ Sysmon Event ID 1 — process creation with suspicious parent (explorer.exe → malware.exe)

▶ Outbound network connection from malware process — C2 callback

▶ Persistence mechanism installed — scheduled task or registry run key

▶ Credential access attempted — LSASS process access Event ID 4656

Defense-in-Depth Response

▶Layer 1: Elastic Defend blocks at execution — first line of defense

// Elastic Defend prevention policy — malware prevention enabled

# Policy settings: # Malware protection: Prevent (not just detect) # Memory threat protection: Prevent # Ransomware protection: Prevent # Behavioral protections: Enabled # These settings block execution before any payload runs

▶Layer 2: If execution succeeds — detect via Sysmon behavioral indicators

// Kibana — behavioral detection if EDR bypassed

# Unusual parent-child process relationships event.code: "1" AND winlog.event_data.ParentImage: "*explorer*" AND winlog.event_data.Image: "*Temp*" OR "*Downloads*" # Outbound connections from new processes event.code: "3" AND NOT winlog.event_data.Image: "*trusted*" # These create the detection net if prevention fails

Evidence from Elastic Defend deployment, malware prevention events, and host isolation.

Malware Blocked

Elastic Defend prevention alert — mydfir-30.exe stopped

EDR Telemetry

File hash, path, parent process captured

Host Isolated

Network severed — Elastic agent maintained

Sysmon Integration

Custom event channels configured in Elasticsearch

osTicket — EDR Alert

Auto-generated incident from Elastic Defend alert

Suspicious Activity Dashboard

Real-time visibility across all endpoint activity