top of page

01-Phishing-Simulation: 02-BlueTeam-Report

  • Writer: TrilloSec
    TrilloSec
  • Feb 3
  • 11 min read

Updated: Feb 3


ree

Blue Team Report: StrelaStealer Detection & Response

  • Project: 01-Phishing-Simulation

  • Author: TrilloSec

  • Date: 2025-02-03


1. Executive Summary

1.1 Purpose

This assessment evaluates the ability to detect, analyze, and respond to a phishing attack inspired by StrelaStealer, a real-world credential-stealing malware. Using Sysmon and Splunk, detection rules were implemented to identify malicious payload execution and outbound C2 traffic, improving the SOC’s phishing response capabilities.


While this assessment focused on post-delivery malware detection, tracking email delivery success rate provides valuable insight into phishing risk.


Although no Postfix filtering rules were deployed in this phase, email filtering will be included in future testing to measure its impact on reducing phishing email delivery. In this experiment, Postfix was configured to log .exe attachments but did not block them


1.2 Key Metrics

Metric

Pre-Test

Post-Test

Improvement

Detection Time

Not Detected

5 minutes

Immediate alerting enabled

Alerts Triggered

0

3

Splunk rules created for execution & C2 traffic

Containment Time

N/A

5 minutes

Faster host isolation procedures

Email Delivery Rate

100%

100%

Future Postfix filtering tests planned

2. Detection & Analysis

This section details how the phishing attack was initially detected, key indicators of compromise, and the improvements made to enhance threat detection.


2.1 Pre-Test Analysis

Before deploying detection rules, an initial assessment was conducted to determine the effectiveness of existing security controls and logging configurations. Although no Postfix filtering rules were deployed in this phase, email filtering will be included in future testing to measure its impact on reducing phishing email delivery. In this experiment, Postfix was configured to log .exe attachments but did not block them

  • Observation: Minimal logging and detection configurations led to undetected malicious activity.


2.2 Indicators Of Compromise (IOCs)

A list of key artifacts and behaviors observed during the phishing attack, including filenames, processes, network connections, and command-line executions.

Type

Indicator

Description

Filename

r2_payload.exe

The phishing payload executable.

Command Line

Payload redirects to the C2 server.

C2 IP

185.230.63.107

Destination IP for C2 communication.

URL

URL contacted by the payload.

Processes

r2_payload.exe -> MSEDGE.EXE

Parent-child process relationship.








Figure 2.1 – Splunk Query Showing Sysmon Log for Execution of r2_payload.exe (Event ID 1)
Figure 2.1 – Splunk Query Showing Sysmon Log for Execution of r2_payload.exe (Event ID 1)



2.3 Optimized Detection Rules

This section presents the updated Sysmon configurations and Splunk queries that were implemented to detect malicious activity more effectively.


Sysmon Configuration

Sysmon Event ID 3 (network connections) was not successfully implemented in this phase. Instead, we used a workaround detection method by logging command-line execution of outbound C2 traffic (ParentCommandLine="*trillosec.com/r2*"). To detect the execution of the r2_payload.exe and its resulting browser activity, the following Sysmon configurations were implemented:

  • Enabled Event ID 1 (Process Creation) to track suspicious process execution.

  • Enabled Event ID 10 (Process Access) to detect unusual parent-child relationships.


Sysmon Rule Examples:

<RuleGroup name="01-Phishing-Simulation" groupRelation="or">

    <!-- Detect execution of r2_payload.exe -->
    <ProcessCreate onmatch="include">
        <Image condition="contains">r2_payload.exe</Image>
    </ProcessCreate>

    <!-- Monitor browser processes launched by r2_payload.exe -->
    <ProcessCreate onmatch="include">
        <ParentImage condition="contains">r2_payload.exe</ParentImage>
        <Image condition="contains">chrome.exe</Image>
    </ProcessCreate>

    <ProcessCreate onmatch="include">
        <ParentImage condition="contains">r2_payload.exe</ParentImage>
        <Image condition="contains">msedge.exe</Image>
    </ProcessCreate>

    <ProcessCreate onmatch="include">
        <ParentImage condition="contains">r2_payload.exe</ParentImage>
        <Image condition="contains">firefox.exe</Image>
    </ProcessCreate>

</RuleGroup>

Splunk Queries

Optimized Splunk queries were created to detect suspicious activity tied to r2_payload.exe. To enhance incident tracking and escalation, these detection rules were configured to automatically generate an alert and save them in index named “notable_events” in Splunk Enterprise Security (ES) when r2_payload.exe executes. This allows for efficient tracking, escalation, and investigation within the SIEM.

  • Detect Process Creation:

index=sysmon_logs EventID=1 Image="*r2_payload.exe"
  • Detect Parent-Child Process Execution:

index=sysmon_logs EventID=1 ParentImage="*r2_payload.exe" 
  • Detect Specific Outbound C2 Traffic Generated from a Command:

index=sysmon_logs EventID=1 ParentCommandLine="*trillosec.com/r2*"


Figure 2.2 – Splunk Query Detecting Initial Execution of r2_payload.exe in the “notable_events” index.
Figure 2.2 – Splunk Query Detecting Initial Execution of r2_payload.exe in the “notable_events” index.


Figure 2.3 – Splunk Alert for Outbound Connection to Command & Control (C2).
Figure 2.3 – Splunk Alert for Outbound Connection to Command & Control (C2).


2.4 Response Workflow (NIST Framework)

An overview of the incident response process, structured according to the NIST Cybersecurity Framework, covering detection, analysis, containment, eradication, and recovery.

Phase

Actions Taken

Detection

Splunk alert triggered execution of r2_payload.exe file.

Analysis

Reviewed Sysmon logs and confirmed malicious activity.

Containment

Manual containment: Investigated attack, disabled user account, but no automated isolation was implemented.

Eradication

Removed payload and confirmed no persistence mechanisms.

Recovery

Restored Bob’s machine to pre-attack state.



Note: Windows Defender was temporarily disabled on the victim VM only to allow execution of the simulated payload. This was done solely within the controlled home lab environment for testing purposes and does not reflect enterprise security configurations.



Figure 2.4 – Automated Splunk Alert for Malicious Process Execution.
Figure 2.4 – Automated Splunk Alert for Malicious Process Execution.


Figure 2.5 – Splunk Timeline Dashboard Showing r2_payload.exe Execution & C2 Activity.This dashboard visualizes process execution, parent-child relationships, and outbound C2 traffic, aiding SOC analysts in identifying phishing-based malware infections.
Figure 2.5 – Splunk Timeline Dashboard Showing r2_payload.exe Execution & C2 Activity.This dashboard visualizes process execution, parent-child relationships, and outbound C2 traffic, aiding SOC analysts in identifying phishing-based malware infections.


2.5 MITRE ATT&CK Mapping

A mapping of the observed attack techniques to the MITRE ATT&CK framework, demonstrating how each tactic was detected and highlighting areas for improvement.

Tactic

Technique

MITRE ID

Detection Method

Detection Gap & Fix

Initial Access

Spear Phishing Attachment

T1566.001

Not detected pre-test; Postfix logs reviewed for phishing indicators

No email filtering pre-test; Added Postfix rule to log all inbound .exe attachments

Execution

User Execution (Malicious File)

T1204

Splunk alert on r2_payload.exe execution (Event ID 1)

No pre-test detection; Added Sysmon rule for process execution

Command and Control

Application Layer Protocol (HTTPS)

T1071.001

Sysmon Event ID 1 detected execution of outbound C2 command.

No outbound traffic monitoring pre-test; Enabled SIEM rule for suspicious C2

3. Mitigation & Response

This section outlines the response actions taken after detecting the phishing attack, including containment, eradication, and recommendations for strengthening defenses.


3.1 Example Containment And Eradication Procedures

A step-by-step breakdown of the immediate response actions taken to isolate the compromised system, remove the phishing payload, and prevent reinfection.


🔹 Containment Strategy

Objective: Limit the impact of phishing emails by isolating affected systems and users.

Step 1: Quarantine the Malicious Email- Move the phishing email to a secured investigation folder.- Extract email headers, links, and attachments for analysis.- Flag similar emails in Postfix & Dovecot logs.

Step 2: Check if Any Users Clicked the Link- Query Windows Event Logs (Sysmon) for browser activity:spl index=sysmon EventID=3 DestinationHostname="trillosec.com/r2" - Investigate network traffic logs for unusual outbound connections.

Step 3: Detect & Contain Executed Payloads- Query Sysmon for executed payloads:spl index=sysmon EventID=1 Image="*r2_payload.exe" - If payload ran, disable the user’s account:powershell net user bob /disable - Isolate the compromised endpoint from the network.


🔹 Eradication Strategy

Objective: Remove malware, eliminate persistence, and update defenses.

Step 1: Remove Malicious Attachments & Links- Search for all instances of r2_payload.exe across affected systems.powershell Get-ChildItem -Path C:\ -Filter r2_payload.exe -Recurse | Remove-Item -Force - Block phishing domain (trillosec.com/r2) at the network firewall.

Step 2: Scan for Additional Threats- Run Windows Defender full scan to check for other infections:powershell Start-MpScan -ScanType FullScan - Investigate PowerShell execution history:powershell Get-History | Select-String "Invoke-WebRequest"

Step 3: Implement Prevention Measures- Add SIEM alerts to detect future phishing attempts.- Update Postfix filtering rules to block similar attacks.- Strengthen user awareness training based on lessons learned.


3.2 Incident Response Playbook Sample

A structured response plan that details predefined actions SOC analysts can take when handling similar phishing incidents in the future.


🔹 Title: Email Threat Mitigation Playbook

Purpose: This playbook provides step-by-step guidance for identifying and mitigating phishing emails using Postfix logging, SIEM detection, and endpoint monitoring.

  • Postfix was configured to log .exe attachments but did not block emails in this phase.

  • Future experiments will evaluate Postfix filtering to actively reduce phishing email success rates.

▸ Key Playbook Actions

Log phishing email attachments for forensic review using Postfix logs & Splunk queries.✔ Monitor user interactions with phishing emails by detecting link clicks & browser activity via Sysmon.✔ Detect payload execution using Sysmon Event ID 1 & Splunk-based process monitoring.✔ Contain confirmed phishing incidents by disabling compromised user accounts & isolating affected endpoints.

📄 Full Playbook: See Appendix 5.2 – Email Threat Mitigation Playbook


4. Findings & Recommendations

This section summarizes key observations from the assessment, provides security recommendations, and outlines areas for future improvement.


4.1 Findings

A summary of security gaps identified during the phishing simulation, as well as improvements in detection and response capabilities.

  • Detection improvements significantly reduced response time. Before implementing detection rules, payload execution was not detected at all. After deploying Sysmon and Splunk rules, detection time was reduced to 5 minutes, significantly improving SOC response and reducing attacker dwell time.

  • Phishing email delivery was not mitigated in this phase. Email filtering was not tested, so phishing success rate remained 100% pre- and post-test. Postfix was configured to log .exe attachments but did not block them. Future experiments will evaluate Postfix filtering rules to measure their impact on reducing phishing email success rates.

  • Future work will incorporate Postfix filtering policies to measure their impact on reducing phishing email success rates.

  • Correlation between different attack stages was initially lacking. The SIEM alerted on individual events (email received, process execution, outbound traffic), but these were not automatically linked together to provide a full attack timeline.

  • Manual containment slowed the response process. Without automated host isolation or account disabling, the compromised system remained online longer than ideal after detection.


4.2 Recommendations

Actionable security measures that should be implemented to enhance phishing detection, incident response efficiency, and overall SOC maturity.

  • Enhance SIEM correlation rules to detect multi-stage attacks. Implement Splunk correlation searches that link phishing emails, process execution, and outbound network activity into a single high-confidence alert.

  • Expand logging coverage to include DNS activity. Enable DNS query logging in Sysmon, Postfix, and firewall logs to detect phishing-related domains and C2 traffic.

  • Deploy additional endpoint detection measures. Implement application allowlisting, behavioral monitoring, and execution restriction policies to prevent unauthorized payload execution.

  • Improve automated response workflows. Integrate SOAR playbooks that automatically isolate compromised hosts, quarantine emails, and disable user accounts upon detection of phishing-related activity.

  • Strengthen phishing awareness training. Since phishing emails bypassed security controls, users should be trained to identify social engineering tactics, suspicious links, and unknown attachments.


4.3 Lessons Learned

A reflection on what worked well, what was initially missed, and how the incident response process can be improved based on the assessment results.

Detection Gaps - Phishing email delivery was not initially logged or alerted in Postfix/Dovecot. Without proactive log monitoring, the attack bypassed initial email filtering and was delivered successfully. - Outbound C2 traffic was not detected pre-test. The initial simulation allowed the payload to establish an external connection without triggering an alert in Splunk or Sysmon. - Process execution monitoring was incomplete. Before implementing Sysmon Event ID 1 rules, payload execution went undetected.

Response Delays - Manual containment slowed down response time. The lack of automated endpoint isolation required SOC analysts to manually intervene, increasing the time between detection and containment. - Incident correlation across multiple data sources was lacking. There was no automated correlation between email delivery, execution, and C2 communication, making it harder to quickly identify the full scope of the attack.

SOC Maturity Improvements - Improve SIEM correlation rules. Future implementations should connect phishing email delivery logs, process execution, and C2 traffic into a single detection workflow to accelerate response. - Enhance network monitoring for outbound connections. Implement DNS and firewall log analysis to detect and block suspicious outbound connections to known phishing domains. - Develop automated response capabilities. Integrate SOAR tools to automate containment actions such as host isolation, email quarantine, and account disablement upon detection of phishing attacks.


4.4 Next Steps

A roadmap for further strengthening detection capabilities, automating incident response, and testing new adversary tactics in future simulations.

SOC Maturity Roadmap

  • Implement SIEM correlation across attack stages. Improve detection workflows by linking phishing email delivery, process execution, and outbound network traffic into a single high-confidence alert in Splunk.

  • Expand email filtering rules. Future experiments will evaluate Postfix filtering policies to measure their impact on reducing phishing email success rates. In this phase, Postfix only logged .exe attachments but did not block them.

  • Future experiments will track Email Delivery Success Rate before and after implementing Postfix filtering to measure its impact on phishing email success..

  • Develop automated containment workflows. Additionally, SOAR-based containment will be explored in future work, but manual containment was used in this test.

Future Detection Improvements

  • Enable DNS and firewall logging for threat hunting. Implement network monitoring rules to detect phishing-related DNS lookups and unauthorized outbound C2 traffic.

  • Increase log retention for long-term analysis. Extend Splunk and Sysmon log retention periods to allow better forensic investigations and anomaly detection over time.

Additional Testing & Simulations

  • Simulate advanced phishing techniques. Future test cases should include HTML smuggling, QR code phishing, and MFA bypass techniques to assess defenses against evolving threats.

  • Conduct adversary emulation exercises. Develop Purple Team scenarios where Red and Blue Teams collaborate to refine detection and response strategies. Schedule a SOC phishing response tabletop exercise to validate detection & containment workflows.

  • Test endpoint resilience to execution methods. Evaluate application allowlisting, execution restriction policies, and behavioral monitoring to prevent payload execution.


5. Appendices

5.1 Incident Response & Containment Frameworks

The following resources provide industry-recognized guidelines for containment, eradication, and incident response. These frameworks align with best practices and can be used to refine detection strategies, automate response workflows, and improve SOC readiness.

🔹 MITRE ATT&CK – Containment Strategies🔗 https://attack.mitre.org/tactics/TA0040/Covers containment tactics used to prevent adversary actions from escalating, helping SOC teams prioritize defensive actions.

🔹 NIST Incident Response Guide (SP 800-61 Rev. 2)🔗 https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/finalAn official framework for incident handling, including best practices for containment, eradication, and recovery.

🔹 SANS Incident Response Process🔗 https://www.sans.org/posters/incident-handlers-handbook/A step-by-step guide for incident handlers, focusing on containment, forensic analysis, and incident resolution.

🔹 Microsoft Security Response Center (MSRC) – Incident Response Playbooks🔗 https://learn.microsoft.com/en-us/security/compass/incident-response-playbooksProvides structured playbooks for containing phishing, malware, and other security incidents in enterprise environments.


5.2 Playbook - Email Threat Mitigation

Version: 1.3

Author: TrilloSec

Last Updated: 2025-02-02

1️⃣ Overview

  • Purpose: Detect and mitigate phishing-based malware after email delivery using Sysmon, Splunk, and Postfix logging.

  • Scope: This playbook focuses on post-delivery detection and incident response rather than email filtering. Postfix logged .exe attachments but did not block phishing emails in this phase.

  • Primary Focus: Identify phishing attacks post-delivery, detect execution, and implement containment actions.

  • Related Security Domains:

    • Email Security (Blue Team)

    • Endpoint Detection & Response (Sysmon/Splunk)

    • Incident Handling (NIST 800-61)

2️⃣ Phishing Email Detection (Post-Delivery Monitoring)

2.1 Logging .exe Attachments for Forensic Analysis

Track Executable Attachments in Email Logs (Postfix Mail Log Example)

grep "attachment=.exe" /var/log/mail.log  

Note: Postfix was used to log .exe attachments for forensic analysis, but email filtering was not deployed in this phase. Future tests will evaluate Postfix filtering as a control measure.

Splunk Query for Email Logs Containing Executables

index=postfix attachment="*.exe" 

Detect Clicks on Suspicious Links (Sysmon Event ID 3 - Network Connections)

index=sysmon EventID=3 DestinationHostname="trillosec.com/r2"

Identify Users Who Clicked Malicious Links

index=sysmon EventID=1 ParentImage="*OUTLOOK.EXE*" Image="*chrome.exe" OR Image="*firefox.exe" OR Image="*msedge.exe"

3️⃣ Payload Execution Detection (Sysmon & SIEM)

3.1 Detecting Execution of Phishing Attachments

Log Any Execution of r2_payload.exe

index=sysmon EventID=1 Image="*r2_payload.exe"

Check If Payload Spawned a Suspicious Process (Parent-Child Execution Chain)

index=sysmon EventID=10 TargetImage="*cmd.exe" ParentImage="*r2_payload.exe"

4️⃣ Incident Response & Containment Workflow (Blue Team Playbook)

4.1 If a Phishing Email is Delivered

Step 1: Identify If Any User Clicked the Link

  • Use Sysmon Event ID 3 & browser execution logs to determine click-through rates.

Step 2: Determine If Payload Was Executed

  • Check Sysmon Event ID 1 & 10 to detect process execution & lateral movement.

Step 3: Manual Containment Actions

  • Disable Compromised User Accounts (Manual Action Required)

    net user bob /disable

  • Manually Isolate the Endpoint From the Network

    New-NetFirewallRule -DisplayName "Block Outbound Traffic" -Direction Outbound -Action Block

  • Quarantine Suspicious Email for Forensics

mv /var/mail/bob /var/mail/quarantine/

5️⃣ Security Effectiveness Metrics (Pre-Test vs. Post-Test)

Phase

Pre-Test Results

Post-Test Results

Phishing Email Logging

No logging for .exe attachments

100% .exe emails logged for review

User Click Rate

80% clicked on phishing email

50% due to security awareness training

Payload Execution

100% of users executed attachment

50% due to better detection & SOC alerts

Time to Detection (SOC)

1 hour

5 minutes (improved Sysmon/Splunk detection)


TL;DR

Blue Team enhanced phishing detection, cutting response time to 5 min, improving SIEM alerts, and strengthening endpoint visibility.

Download PDF:




Other Reports in This Project

Red Team: Simulated a phishing campaign using Gophish, tested payload execution, and mapped attack techniques to MITRE ATT&CK.

Blue Team: Developed Sysmon & Splunk detection rules, reducing phishing response time from undetected → 5 minutes.

Purple Team: Conducted a business risk analysis, demonstrating an estimated $80K risk reduction per attack and aligning defenses with NIST & ISO 27001 compliance.

Technical Setup: Configured Postfix, Sysmon, SIEM alerts, and automated detection workflows to improve security posture.

©2025 by TrilloSec.com. All rights reserved.

bottom of page