Security Incident Lifecycle: Behavioral Malware Analysis and IOC Extraction, Threat Intelligence Correlation and Incident Response, Phishing Simulation.

A hands-on cybersecurity project where I analyzed custom malware, extracted indicators, correlated them against threat intelligence, responded to the simulated breach and built a phishing simulation in an isolated lab environment.

I demonstated how real attacks work from start to finish: how attackers gain access, what malware does at the system level, how to spot it, how to extract useful indicators and how to respond when it happens. The project covers two attack paths: technical attacks; malware execution and behavioral analysis and social engineering; phishing for credential harvesting. This project covers the complete malware incident lifecycle and how attackers harvest credentials through social engineering, showing why organizations need defense-in-depth strategies.

The malware itself is a simple PowerShell simulation, it is not truly malicious but the analysis techniques are identical to production environment standard. The custom PowerShell script simulates a Remote Access Trojan (RAT); malware designed to establish persistent C2 communication, gather system reconnaissance and maintain backdoor access. RAT typically create and write files for logging, configuration storage and payload delivery, all of which my malware demonstrates.

Phase 0: Baseline Setup — Configured an isolated lab with two VMs on an internal network, disabled security software (intentionally), and captured the system state before anything happened which serves as the control group for comparison.

Phase 1: Malware Analysis & IOC Extraction — Executed malware (RAT) and monitored what it actually does: DNS queries to hardcoded C2 domains, registry modifications for persistence, file creation, system reconnaissance. Captured it all with Wireshark, Process Monitor, and Autoruns.

Phase 2: Threat Intelligence Correlation — Took the indicators I extracted and ran them through VirusTotal (Through Web interface and using custom threat feed parser). The key finding: custom malware got 0/68 detections while a known test file got 61/68. This is why behavior matters more than signatures especially for novel malwares.

Phase 3: Incident Response — Applied standard IR procedures: isolated the network (containment), removed persistence mechanisms (eradication), quarantined evidence for analysis (evidence preservation) and validated the system was clean (recovery/validation).

Phase 4: Phishing Simulation — Built a realistic phishing email, fake Microsoft login form and credential harvester. Showed how attackers actually capture credentials and analyzed the attack from both network and forensic perspectives.

Why I Built This

In cybersecurity, you can read about attacks all day but until you've actually watched one happen on a system you're monitoring, seen the network packets it generates, how it tries to maintain persistence and extracted the indicators yourself, it's just theory. This project bridges that gap.

I also wanted to demonstrate something realistic; signature-based detection can miss novel threats but behavioral monitoring catches them.

Also, phishing works because it exploits human psychological vulnerabilities: urgency, fear, trust in familiar brands. Understanding this hands-on showed why technical controls alone can't defend against social engineering.

Skills & Tools Demonstrated

Malware Analysis
Behavioral monitoring using Process Monitor and Process Explorer to track system activity in real-time. Network traffic analysis with Wireshark to capture C2 communication patterns. Registry inspection with Autoruns and Registry Editor for persistence mechanism detection. MITRE ATT&CK framework for behavioral mapping.

Digital Forensics
Registry inspection and manual verification using Registry Editor. File system artifact analysis and timeline correlation using timestamps. Evidence preservation with cryptographic hashing (MD5/SHA256). Chain of custody documentation throughout evidence collection and transfer.

Threat Intelligence
IOC extraction (domains, file creation and writing, registry keys, behavioral patterns). Manual threat intelligence queries via VirusTotal web interface for file hash analysis. Automated IOC correlation using custom Python threat feed parser for command-line processing of domains and registry indicators. Detection gap analysis comparing signature-based detection (0/62 vendors) against behavioral indicators.

Network Forensics
Wireshark packet capture and protocol analysis for real-time traffic inspection. NetworkMiner for forensic credential extraction from HTTP traffic.

Incident Response
PowerShell for network isolation and registry persistence removal. Windows CLI tools (netstat, tasklist, Registry Editor) for baseline comparison and validation. Evidence handling and chain of custody procedures following NIST IR framework.

Scripting & Automation
PowerShell for custom malware simulation with C2 beaconing and persistence mechanisms. Python for custom threat feed parser (command-line IOC correlation), VirusTotal API integration, credential harvester server development and email generation. HTML/CSS/JavaScript for phishing form design and Microsoft UI cloning.

Virtualization & Network Isolation
VirtualBox hypervisor configuration managing Kali Linux (analyst workstation) and Windows 10 (malware sandbox). Internal network segmentation (192.168.100.0/24) completely isolated from internet. Security hardening (disabling Defender, Firewall, shared folders, USB pass-through).

Command-Line Proficiency
PowerShell for Windows system administration, malware development, and incident response. Linux/bash on Kali for file operations, tool configuration, and network analysis. Windows CLI tools (netstat, tasklist, ipconfig) for system enumeration.

Lab Environment
VirtualBox, Kali Linux (analyst workstation), Windows 10 (malware sandbox), isolated 192.168.100.0/24 internal network with no external connectivity.

Phase 0: Baseline Environment Setup

The Challenge

Malware analysis has an important requirement which is isolation. You cannot risk malware escaping your lab and infecting production systems, personal devices or spreading to the internet. At the same time, the malware needs a realistic environment where it can exhibit its true behavior.

I needed to build a lab that was Isolated enough to be completely safe and Realistic enough to observe genuine malware behavior

My solution was a two-phase approach:

Phase 1: Preparation (NAT Mode)

While both VMs still had internet access (NAT adapter):

I downloaded Sysinternals Suite on Windows VM
I Verified Wireshark and network analysis tools on Kali VM (pre-installed)
Installed neccessary python libraries
Tested all tool functionality

Phase 2: Lockdown (Internal Network)

After tools were ready:

Switched both VMs to Internal Network adapter (malware_lab)
Configured static IP addresses for inter-VM communication
Applied security hardening to Windows VM
Tested and verified complete isolation.
Documented clean system baselines

This gave me completely isolated VMs ready for safe malware analysis.

Architecture Overview

I designed a two-VM architecture connected via an isolated Internal Network:

┌─────────────────────────────────────────────────────────────────┐
│                    Host Machine (Laptop)                        │
│                     ❌ NO ACCESS TO VMs                          │
│                                                                 │
│  ┌──────────────────────┐        ┌──────────────────────────┐  │
│  │   Windows 10 VM      │        │    Kali Linux VM         │  │
│  │   (Victim/Target)    │◄──────►│  (Analyst Workstation)   │  │
│  │                      │        │                          │  │
│  │  192.168.100.20/24   │        │   192.168.100.10/24      │  │
│  │  Promiscuous: DENY   │        │   Promiscuous: ALLOW ALL │  │
│  │                      │        │                          │  │
│  │  • Malware execution │        │   • Wireshark capture    │  │
│  │  • Process Monitor   │        │   • Evidence storage     │  │
│  │  • Baseline capture  │        │   • Python HTTP server   │  │
│  │  • System monitoring │        │   • File hashing         │  │
│  │  • Firewall: OFF     │        │   • tcpdump capture      │  │
│  │  • Defender: OFF     │        │                          │  │
│  │  • USB: Disabled     │        │                          │  │
│  └──────────────────────┘        └──────────────────────────┘  │
│           │                                  │                  │
│           └──────────────┬───────────────────┘                  │
│                          │                                      │
│              Internal Network: "malware_lab"                    │
│                   192.168.100.0/24                              │
│                                                                 │
│            ❌ NO Internet   ❌ NO Host Access                    │
│            ❌ NO Gateway    ❌ NO DNS Servers                    │
└─────────────────────────────────────────────────────────────────┘

Key Security Features:

VMs communicate only with each other (no external access)
No gateway configured (this prevents accidental routing)
No DNS servers (this prevents external name resolution)
Host machine remains completely isolated from the VMs
Windows Defender disabled (if active, it would quarantine malware before analysis, I need to observe behavior not have it removed)
Windows Firewall disabled (would block connections I need to capture and analyze. Network isolation provides the actual security)

Why Internal Network mode?

NAT/Bridge modes allow internet access
Host-only mode connects to host machine
Internal Network is completely isolated

I chose Internal Network because it provides complete isolation. The VMs can communicate with each other but cannot reach:

The internet (malware can't establish C2 communication with external servers)
The host machine or home network (malware cannot escape the lab to infect other devices)

Why Two Different Promiscuous Mode Settings? I set the Windows promiscuous mode to "Deny" while I Set Kali to "Allow All".

The Windows machine is my target, it's where malware runs. It doesn't need to see network traffic from other machines. Setting promiscuous mode to "Deny" means Windows only sees packets meant for it (normal network behavior)

The Kali machine is the analyst workstation, it needs to capture EVERYTHING happening on the network. Setting promiscuous mode to "Allow All" means Kali can see all network traffic, even packets not addressed to it, Wireshark can capture complete network conversations which is important for network monitoring and analysis. Also, it is a standard configuration for any network analysis workstation

This mimics how real security monitoring is done,the analyst's workstation needs visibility into all network traffic for detection and forensics while the systems being monitored don't need that capability.

Virtual Machine Configuration

Windows 10 VM (The Target)

VirtualBox Network Configuration:

Adapter 1: Internal Network
Name: malware_lab
Promiscuous Mode: Deny
Cable Connected: ✓

Windows Static IP Configuration: Using PowerShell, I identified the network interface name, then configured a static IP address (192.168.100.20/24). To validate the configuration, I pinged the Kali VM at 192.168.100.10, it responded which confirms internal connectivity. I then pinged 8.8.8.8 (Google's DNS server) and it failed, confirming isolation from the external network.

netstat ip show address
netstat ip set address name=“Ethernet” static 192.168.100.20
ping 192.168.100.10
ping 8.8.8.8

Kali Linux VM (The Analyst Workstation)

This VM serves as the analysist workstation and evidence storage location.

VirtualBox Network Configuration:

Adapter 1: Internal Network
Name: malware_lab
Promiscuous Mode: Allow All
Cable Connected: ✓

Kali Static IP Configuration:

I identified the network interface (eth0) and configured the static IP:

sudo nano /etc/network/interfaces

Added the static IP configuration:

auto eth0
iface eth0 inet static
    address 192.168.100.10
    netmask 255.255.255.0

Applied the changes by restarting the networking service:

sudo systemctl restart networking

Verified the configuration took effect:

ip addr show eth0

The output confirmed eth0 was now configured with 192.168.100.10/24.

I tested connectivity by pinging the Windows VM at 192.168.100.20 which succeeded, confirming inter-VM communication. Ping to 8.8.8.8 failed, confirming isolation from the external network.

Security Hardening

Before executing malware, I needed to harden the Windows VM to prevent interference from built-in security features and eliminate attack vectors that could allow escape from the VM.

Windows VM Security Hardening

VirtualBox-Level Hardening

I configured VirtualBox settings to eliminate potential escape vectors:

Setting	Configuration	Why
Shared Folders	Disabled (none configured)	Prevents malware from accessing host filesystem through shared folder bridges
Shared Clipboard	Disabled	Prevents data exfiltration or malicious content injection via clipboard
Pointing Device	PS/2 Mouse (not USB Tablet)	Eliminates USB pass-through attack surface; which is a standard in sandboxes

Operating System-Level Hardening

1. Disabled Windows Defender Real-Time Protection: Windows Defender would automatically quarantine malware before I am able to analyze it. I need to observe the malware's behavior, not have it removed by antivirus. This is safe only because the VM is completely isolated.

2. Disabled Windows Firewall: The firewall would block network connections that I need to capture and analyze. I want to see every connection attempt the malware makes, including those that would normally be blocked. The isolated network provides the actual security.

3. Disabled Windows Update: Windows updates could trigger a reboot during analysis, interrupting evidence collection. Updates could also change the baseline state mid-analysis, making it difficult to attribute changes to the malware versus legitimate updates.

⚠️ Critical Safety Note:
These steps were ONLY safe because the VM is completely isolated on an Internal Network with no internet or host access. It should not be done on a production system or internet-connected machine.

Baseline Documentation

Before executing any malware, I needed to document the "clean state" of the Windows VM. Without knowing what normal looks like, I can't identify what changed.

Baseline Concept: Document the clean state -> Execute malware -> Compare to find changes

Why Baselines Matter

In real incident response, you typically arrive after the system has been compromised. While you can reconstruct what "normal" looked like using system logs, configurations and documentation, you don't have a precise snapshot from the exact moment before compromise. In a lab, I can capture baselines deliberately by running the same commands before and after malware execution to see exactly what changed. This gives me forensic precision.

Baselines enable me to:

Identify new processes spawned by malware
Detect new persistence mechanisms (registry keys, scheduled tasks, services)
Spot suspicious network connections
Correlate file system changes to specific timestamps
Confirm that indicators I extract actually came from malware, not pre-existing configuration.

Baseline Capture Process

1. Process Baseline

Launched Process Explorer to document the running process tree, showing parent-child relationships and system activity. This gave me a visual reference of what normal looks like.

The output file: Process Explorer Baseline showing normal Windows system processes

Also used native tasklist command:

tasklist | Tee-Object -FilePath C:\Baseline\tasklistBefore.txt

The output file: Tasklist Baseline (raw data for comparison after malware execution)

2. Persistence Mechanism Baseline

I launched Autoruns to document every auto-start locations where malware commonly hides to survive reboots. This includes registry run keys, scheduled tasks, services, drivers, shell extensions, and logon entries. I saved the complete Autoruns baseline configuration Autoruns Baseline for detailed comparison later.

I also documented Registry Baseline (Key Persistence Locations) the specific locations where malware commonly establishes persistence:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced

3. Network Connection Baseline

Captured active network connections with netstat:

netstat -ano | Tee-Object -FilePath C:\baseline_netstat.txt

This documents listening ports, established connections and which processes own them.

See: Network Baseline (raw data for comparison)

EICAR Validation Test

Before running my custom malware, I validated that my entire analysis pipeline was working correctly using the EICAR test file a harmless text string that all antivirus software detect as malware:

It's not actually malicious, it's a standardized test to verify that antivirus detection and analysis pipelines are functioning.

I captured the network traffic with wiresharkon my Kali VM while transferring EICAR test file to the malware sandbox using python server.

See: EICAR Transfer PCAP (raw network capture saved to file)

Why Test with EICAR First?

1. Pipeline Validation
If my tools can detect EICAR being transferred and "executed," I know they'll work for custom malware.

2. Safety Confirmation
Verifies that Windows Defender is actually disabled. If Defender were active, it would immediately quarantine EICAR.

3. File Transfer Testing
Validates that my Python HTTP server method works for transferring files between isolated VMs.

4. Network Capture Verification
Ensures Wireshark on Kali is properly capturing traffic from the Windows VM in promiscuous mode.

Result: File transfer was successful, Wireshark captured correctly and Windows Defender did not interfer. Pipeline validated; ready for malware analysis.

With the EICAR test confirming that my analysis pipeline worked, I proceeded to execute the custom malware script.

Phase 1: Malware Analysis & IOC Extraction

With my lab validated and baselines captured, I moved to analyzing malware behavior. I created custom PowerShell scripts that simulate realistic Remote Access Trojan instead of downloading actual samples.

Why custom scripts?

Control: I know exactly what the malware does, which helps me learn what to look for. With real malware, I'd be discovering behavior reactively.
Safety: Even in an isolated lab, creating benign simulations is safer for learning fundamentals.
Skill Development: Writing malware taught me how attackers think. I researched actual techniques used by real threat actors (MITRE ATT&CK framework), studied Windows internals and implemented behaviors like HTTP beaconing and registry persistence. This offensive mindset directly improves my defensive capabilities.

The Malware Script

I created a PowerShell script that combines multiple attack techniques into a single payload.

The script simulates:

C2 beaconing — Makes DNS queries to hardcoded domains
Registry persistence — Writes configuration to HKCU so malware "remembers" the C2 address across reboots
System reconnaissance — Collects hostname, username, domain, OS version, and PowerShell version
File artifacts — Creates logs in the temp folder with randomized filenames
Background execution — Uses PowerShell background jobs to run tasks asynchronously
Beacon intervals — Implements random delays (2500-4500ms) between C2 communications to avoid pattern detection
Self-cleaning — Deletes old diagnostic logs older than 7 days to avoid detection through file accumulation

Together, these behaviors simulate how real malware operates. It not only tries to communicate with attackers but also hides itself, remembers where to call back to, and steals basic system information. Understanding each technique individually helps me recognize them in production environments.

File: Custom PowerShell RAT

# Service endpoints configuration
$endpoints = @(
    "update-cdn.net",
    "telemetry-api.org",
    "metrics-service.com"
)

# Configuration registry path
$configPath = "HKCU:\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced"
$logFile = Join-Path $env:TEMP "diagnostic_$(Get-Random -Minimum 1000 -Maximum 9999).log"

# Logging function
function Write-DiagnosticLog {
    param([string]$Message)
    $timestamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss"
    "$timestamp - $Message" | Out-File -FilePath $logFile -Append -Encoding UTF8
}

Malware Execution and Monitoring

I transferred the malware script from Kali to Windows using the same Python HTTP server method I validated with EICAR. Then I executed it from PowerShell while monitoring what happened in the background.

On Kali VM: I started Wireshark capturing on eth0 interface

On Windows VM: I launched Process Monitor (Procmon64.exe) and started capture

With monitoring tools active, I executed the malware:

powershell.exe -ExecutionPolicy Bypass -File .\network_diagnostic.ps1

The script executed and completed all programmed behaviors. Timestamp of completion 14:05

Behavioral Analysis and IOC Extraction

1. Network Behavior Analysis(C2 Beaconing)

I stopped the Wireshark capture, saved the pcap file and began analyzing the network traffic to identify C2 beaconing patterns.

See wireshark packet capture output here: Malware Network Activity

General DNS Query Capture

Applied DNS filter to see name resolution attempts:

Individual C2 Beacon Analysis

Findings:

The malware made DNS queries to three hardcoded domains: update-cdn.net, telemetry-api.org, metrics-service.com.

All queries failed with "Destination unreachable" responses because:

The domains don't actually exist
The network has no DNS servers configured
No gateway exists to reach external networks

Since DNS resolution failed, the malware never progressed to making HTTP POST requests. The connection attempt stopped at the DNS query stage.

Why This Matters:

These failed DNS queries are themselves evidence. Real malware would keep retrying and DNS lookups leave network signatures that monitoring tools detect. Even failed connection attempts reveal attacker intent and infrastructure.

2. Persistence

Registry Persistence

The malware modified the registry to store configuration data. I verified this by manually checking Registry Editor:

The keys written to:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced

Were:

PrimaryEndpoint → "update-cdn.net" (C2 server configuration)
LastDiagnostic → "2025-11-07 14:04" (timestamp of last execution)

The "Last Modified" timestamp (14:04) falls within the execution window of the malware. This confirms the registry modifications are malware artifacts, not pre-existing configuration.

Why Manual Verification Matters:

Process Monitor captured thousands of events during execution, but I didn't see clear RegSetInfoKey operations proving the registry write. So I manually checked Registry Editor for persistence locations. This revealed the malware didn't just attempt to write, it actually succeeded. This could be as a resut of Process Monitor Buffer Saturation; Process Monitor captures system-level events at an extremely high rate, on an unfiltered capture, it can generate a lot of events per minute. If I didn't apply aggressive enough filters from the start, the internal circular buffer could have overflowed, dropping events including the registry writes. This is why pre-execution filtering is critical in production analysis.

It could also be as a result of Filter Timing and Capture Gaps; It's possible I accidentally paused or momentarily stopped the Process Monitor capture at the exact moment the registry write occurred. Even a brief pause (clicking through menus, adjusting filters) can create gaps in the event stream. This reinforces why continuous monitoring from before execution through completion is essential.

This is demonstrates that automated monitoring tools are powerful but they can be incomplete. Manual verification of key locations (registry, file system, startup programs) catches what tool logs might miss. An analyst needs both, the tools for automation but always verify the critical findings manually. This reinforces a critical principle in malware analysis: never rely on a single tool or data source

Autoruns Persistence Comparison

After execution, I captured a new Autoruns snapshot to compare against Phase 0 baseline:

See Autoruns After Execution: Autoruns After Execution

There was no new entries in standard auto-start locations (Registry Run keys, scheduled tasks, services, startup folders).

Why This Matters:

My malware writes to HKCU:\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced; a non-standard location. Autoruns correctly didn't flag it as persistence because it's not an auto-start location. This demonstrates why manual registry verification is necessary: automated tools can only detect known persistence patterns.

3.File Creation and Writing Activities

Process Monitor clearly captured the malware creating and writing to its log file.

The malware created three files in the Windows temp folder which is the number of times I ran the scripts: diagnostic_2394.log, diagnostic_5298.log, diagnostic_5896.log.

The randomized naming demonstrates a basic obfuscation technique to avoid pattern detection.

See artifact files: Diagnostic Log 1 Diagnostic Log 2 Diagnostic Log 3

4. Process Activity

Process Explorer captured Before execution: 77 processes running normally(seen in phase0 above), After execution: 83 processes (6 new processes spawned by PowerShell)

These 6 new processes were transient; they terminated after the script finished. Nothing was persistent in the running process list. See Process Explorer After for the output file

Process Monitor captured 817,093 system events during execution:

The key events logged were:

CreateFile operations (creating the diagnostic logs)
WriteFile operations (writing data to logs)
Process creation/termination (PowerShell spawning child processes)

See compressed Process Monitor log with all events: Process Monitor Log

Tasklist Comparison:

Compared tasklist snapshots from before and after execution to identify persistent processes. See After execution: Tasklist After Execution

Finding: No new persistent processes. All processes spawned during execution terminated, returning the system to its baseline state.

This confirms malware execution was transient; no processes remained running after script completion, requiring re-execution for continued C2 communication.

5. Network Traffic Analysis

Looking at Wireshark's conversation stats:

192.168.100.20 (Windows) → 192.168.100.10 (Kali)
9 packets total, 805 bytes
Protocol breakdown: DNS (55.6%), ICMP (44.4%)

The small payload indicates reconnaissance or handshake traffic, not data exfiltration. Real data theft would show much larger transfers. The protocol breakdown confirms DNS dominates the traffic, the malware is primarily doing name resolution, not bulk data transfer.

6. Network State Changes

I compared netstat snapshots taken before and after malware execution. See After Execution output file Network After Execution

Netstat showed no changes between before and after execution. No new listening ports, no new established connections, no new network activity.

This confirms what Wireshark revealed; all C2 communication attempts failed at the DNS stage. The malware made DNS queries (which failed), but never progressed to establishing actual network connections. There were no successful TCP connections to external servers, no listening backdoor ports, and no persistent network anomalies.

In a real-world scenario with successful C2 communication, netstat would show: New listening ports (for reverse shell access), Established TCP connections to attacker infrastructure, Unusual port usage patterns.

MITRE ATT&CK Mapping

Technique	ID	Evidence	Notes
Command and Scripting Interpreter: PowerShell	T1059.001	Executed with `-ExecutionPolicy Bypass`; uses `Start-Job` for background execution	Initial execution mechanism
System Information Discovery	T1082	JSON logs containing hostname, username, domain, OS version, PowerShell version	Reconnaissance to understand target environment
Modify Registry	T1112	Keys written to `HKCU\...\Explorer\Advanced` (`PrimaryEndpoint`, `LastDiagnostic`)	Configuration storage (not auto-start persistence)
Data Staged: Local Data Staging	T1074.001	Creates diagnostic logs in `%TEMP%` with randomized filenames	Stages collected data locally before exfiltration
Application Layer Protocol: DNS	T1071.004	DNS queries to C2 domains (`update-cdn.net`, `telemetry-api.org`, `metrics-service.com`)	Attempted C2 beaconing via DNS resolution (failed in isolated network)
Indicator Removal: File Deletion	T1070.004	Deletes diagnostic logs older than 7 days from %TEMP%	Covers tracks by removing artifacts

Why My RAT Doesn't Auto-Execute and Why That's a Design Choice Not a Limitation

Configuration Storage vs. Executable Persistence

My malware implements configuration storage (registry data persists across reboots) but not executable persistence (no automatic execution at startup).

Configuration Storage: Stores parameters (C2 addresses, settings) for processes to read. My malware writes to HKCU\...\Explorer\Advanced—the C2 address survives reboot but nothing launches the malware.
Executable Persistence: Stores instructions for the OS to launch programs. Real RATs modify HKLM\...\Run, Services, or Scheduled Tasks for automatic execution at startup.

The critical difference: Configuration is data at rest (the process must execute first to read it). Executable persistence is instruction storage (the OS automatically launches the program).

Why Autoruns Missed This

Autoruns is an enumeration tool that checks known auto-start locations (Run keys, Services, Tasks, IFEO). It doesn't catch custom registry keys used for configuration storage; a technique used by real malware.

Why I Made This Design Choice

Demonstrates tool limitations — Autoruns catches standard persistence but misses sophisticated configuration storage techniques
Forces runtime detection — Analysts must detect malware during active execution (beaconing, process spawning, logging) not just forensic analysis
Teaches critical distinctions — Not all registry writes are persistence; analysts must differentiate between instructions (what OS launches) and configuration (what programs read)
Mirrors real-world TTPs — Modern malware avoids traditional persistence, using Living-off-the-Land Binaries and fileless techniques instead

Detection Requires Multiple Methods Autoruns alone is insufficient. Effective detection needs:

Sysmon Event ID 13 (any registry write) + filtering
Windows Event ID 4657 (registry auditing, if enabled)
EDR solutions (behavioral anomalies)
Process Monitor (manual analysis)
Manual verification (correlating registry, network, process data)

Lesson: Analysts must understand what each tool detects and misses. Just because one tool didn't flag something doesn't mean the threat isn't there. Effective threat hunting requires combining multiple detection methods and thinking like attackers to understand why certain design choices evade specific defenses.

Evidence Collection and Preservation

I created a custom PowerShell script server on Windows to serve evidence files, then transferred them to Kali using wget. PowerShell File Server

Windows VM - Custom PowerShell Server:

Why This Matters

NIST IR Framework (SP 800-61), SANS Incident Handling, and ISO/IEC 27035 all mandate proper evidence preservation. Evidence integrity is critical for:

Maintaining artifact integrity to support attribution and root cause analysis
Evidence identification and collection during the investigation phase
Proper preservation to maintain integrity for future analysis and potential legal proceedings

Transferring to Kali preserves the Windows VM as a "crime scene" and enables independent analysis without further system degradation.

File Integrity Verification

I generated MD5 and SHA256 hashes for the malware script and EICAR test file for threat intelligence correlation:

Why Both MD5 and SHA256?

SHA256 is the modern cryptographic standard (MD5 is deprecated but still used for legacy compatibility)
Dual hashing provides defense-in-depth, if one algorithm is compromised, the other validates integrity

Why I Didn't Hash Other Artifacts:

The diagnostic logs, Process Monitor captures, and pcap files are evidence of behavior, not IOCs for threat intelligence. They're unique to this lab and won't be correlated externally. Hashing them would be forensically redundant in a learning context.

In a Production Environment:

I would hash everything:

All diagnostic logs (proves they weren't altered post-collection)
Process Monitor captures (validates system event sequence)
Wireshark pcaps (proves network traffic authenticity)
Autoruns snapshots (documents persistence mechanisms)

Why: Legal standards require comprehensive evidence integrity. Every artifact might become evidence in court. Hash values create an immutable audit trail proving nothing was modified after collection.

The Window Virus Threat Real Time protection Incident

Before I completed evidence transfer, I rebooted my the Windows VM and Windows Virus Threat Real Time protectionhad automatically re-enabled itself.

When I attempted to hash the EICAR file on Windows for documentation purposes but Windows Virus Threat Real Time protection immediately flagged and quarantined it.

Lesson Learned:
Windows Defender can re-enable itself after system reboots or certain Windows Update triggers, even in isolated VMs. In production malware analysis labs, tools like FLARE VM or hardened analyst workstations have Defender permanently disabled via Group Policy to prevent this interference.

Key Learnings

Multi-Tool Verification is Essential
Process Monitor is powerful but not infallible. Manual verification caught what automated tools missed.
Baselines Enable Accurate Analysis
Without pre-execution snapshots, distinguishing malicious from benign activity would be nearly impossible.
Network Isolation Works
All C2 beacon attempts failed as expected, proving the isolated network prevented malware escape.
Evidence Preservation is Critical
Cryptographic hashing and proper chain of custody maintains integrity for professional reporting.
Automation Helps, Humans Validate
Tools automate collection, but human analysis identifies what matters and validates findings.

Phase 1 Summary

Executed custom PowerShell RAT in isolated environment
Captured network traffic (DNS queries) with Wireshark
Logged system activity with Process Monitor
Verified registry persistence manually with Registry Editor
Compared baselines (processes, network, autoruns, tasklist)
Extracted network, file, registry, and behavioral IOCs
Preserved evidence on Kali with MD5/SHA256 hashing

Phase 2: Threat Intelligence Correlation

For this phase, I correlated extracted IOCs using two methods to demonstrate both manual and automated threat intelligence workflows:

1. Web Interface (Manual) For the web interface approach, I submitted the EICAR test file and my custom malware script. The EICAR file is a known test sample detected by virtually all vendors, while my custom malware is novel and likely undetected. By submitting both, I could observe the detection gap firsthand and demonstrate how signature-based detection performs against unknown threats.

2. Command-Line (Automated) I developed a custom threat intelligence feed parser to demonstrate automated IOC correlation capabilities. Although manual web queries would be sufficient for the small number of indicators, this demonstrates scripting and automation skills, shows understanding of threat intelligence APIs, proves I can build tools when needed.

Where custom parsing provides real value:

Large-scale incidents: 50+ IOCs from real malware families
Continuous monitoring: Daily/hourly checks of evolving indicators
Batch processing: Analyzing multiple malware samples simultaneously
Enterprise integration: Feeding results to SIEM/SOAR platforms
Time-critical response: Rapid triage during active incidents

Network Configuration

Before starting threat intelligence queries, I needed to reconfigure the lab network. During Phase 1, both VMs were on an isolated internal network for safe malware execution. For Phase 2, the Kali VM needed internet access to query external threat intelligence platforms while keeping the Windows VM isolated.

Configuration:

Kali VM: Switched Adapter 2 to NAT mode for internet connectivity and disconnected Adapter 1 (Internal Network)
Windows VM: Remained on internal network (no internet access)
Verification: Confirmed Kali could reach external APIs while Windows remained isolated

This setup demonstrates safely querying threat intelligence platforms without risking malware communication if any persistence mechanisms remained active on the Windows VM.

Threat Intelligence Platform Setup

I registered for VirusTotal's API service to access their threat intelligence database programmatically. VirusTotal aggregates results from 60+ antivirus engines and provides behavioral analysis through multiple sandboxes.

I used the free tier with limits, these limits were more than sufficient for this analysis but would require rate limiting in the automation script to avoid exceeding quotas.

Threat Intelligence Platform Selection

VirusTotal (Used)

I submitted file hashes to VirusTotal to analyze the malware script and EICAR test file. This platform excels at detecting known malware through multi-engine scanning and provides behavioral analysis reports. It's the standard choice for validating whether malware samples are already detected by the security community.

AbuseIPDB (Not Used)

AbuseIPDB correlates IP addresses with abuse history and malicious activity. My malware doesn't hardcode C2 IP addresses,it uses domains instead. The only IP that appeared in analysis was 8.8.8.8 (Google's public DNS), which is legitimate. AbuseIPDB would only be valuable if the domains resolved to suspicious IPs or if the malware used direct IP-based C2 communication.

AlienVault OTX (Not Used)

OTX correlates indicators with known threat campaigns to determine if they're part of documented APT activity. While my malware uses standard techniques (C2 beaconing, registry persistence, logging) found in thousands of known malware families, the specific IOCs are unique to this lab—these exact domains, registry keys, and file patterns don't exist in the wild. OTX wouldn't find matches because these are lab-created indicators, not indicators from real campaigns.

Why This Approach

VirusTotal was sufficient for this analysis. The combination of web interface queries (for immediate results) and command-line automation (for future scalability) provides both tactical and strategic threat intelligence workflows without unnecessary complexity.

Manual Analysis

Control Test: EICAR Validation

To ensure VirusTotal queries were working correctly, I first tested with the EICAR anti-malware test file - a harmless file that all antivirus products should detect.

Results:

Detection: 61/68 vendors (89.7%)
YARA Rules Matched: 3 EICAR-specific rules
Verdict: Confirmed malicious test file

Why This Matters:

High detection rate proves VirusTotal queries are working correctly and returning accurate results. If EICAR hadn't been detected, it would indicate a methodology problem, not a malware detection gap. This control test establishes a baseline before analyzing the custom malware.

Custom Malware Analysis

Next, I uploaded the custom malware script to VirusTotal for comprehensive analysis.

Detection Results

1. Antivirus Verdict: 0/62 vendors detected this file as malicious (0% detection rate)

This was a significant finding; despite implementing clear malicious behaviors documented in Phase 1, not a single antivirus vendor flagged this script as a threat. This demonstrates a complete failure of signature-based detection against novel malware.

2. Static Analysis Results

While vendors didn't flag the file as malicious, VirusTotal's static analysis did identify suspicious PowerShell cmdlets:

Detected Cmdlets:

invoke-webrequest - HTTP communication capability
convertto-json - Data serialization
get-ciminstance - System information gathering
new-item - File/registry creation capability
out-file - File writing operations

Analysis: VirusTotal successfully identified the individual components of malicious behavior but failed to correlate them into a threat verdict. The presence of invoke-webrequest combined with convertto-json and system enumeration cmdlets should raise suspicion, yet no vendor flagged it. This also demonstrates a critical gap in signature-based detection: while the technical indicators of malicious behavior are visible in static analysis, antivirus engines failed to recognize the threat pattern.

This 0/68 detection rate validates the effectiveness of:

Custom PowerShell malware (no existing signatures)
Living-off-the-Land techniques (using only native Windows cmdlets)
The need for behavioral/heuristic analysis beyond static string matching

3. Behavioral Analysis Results

VirusTotal executed the script in multiple sandboxes and captured the following behaviors:

Network Activity Captured:

DNS queries to all three C2 domains
Connection to IP 8.8.8.8 (Google DNS for resolution)

System Activity Captured:

WMI system information gathering (calls-wmi behavior tag)
File creation (5 files dropped)
Timing delays detected (long-sleeps behavior tag)

MITRE ATT&CK Signatures: 6 triggered (5 LOW, 1 INFO)
Sigma Rules: 4 triggered (2 MEDIUM, 2 LOW)

Critical Finding: The sandbox successfully captured ALL the malicious behaviors I documented in Phase 1 - C2 beaconing, system reconnaissance, file dropping, and suspicious timing patterns. Yet despite this comprehensive behavioral detection, the final verdict remained "No security vendors flagged this file as malicious."

This exposes a critical disconnect in VirusTotal's detection ecosystem:

Behavioral analysis works: Sandboxes correctly identified malicious activity
Signature-based detection failed: No AV engine recognized the threat pattern
Scoring system is misleading: The "0/68" metric ignores behavioral evidence entirely

This finding validates that:

Custom PowerShell malware evades signature-based detection even when behaviors are clearly malicious
VirusTotal's sandbox results are informational but don't affect the detection score
Security analysts must examine the Behavior tab, not just the score
Sole reliance on signature-based metrics creates a false sense of security

This demonstrates why modern security requires EDR/behavioral analysis, not just signature-based antivirus.

4. C2 Infrastructure Captured

The Relations tab revealed that VirusTotal's sandbox successfully identified the complete C2 infrastructure:

Contacted Domains:

Domain	Detections	Status
update-cdn.net	0/95	Clean
telemetry-api.org	0/95	Clean
metrics-service.com	0/95	Clean

Contacted URL:

http://update-cdn.net/api/v1/status

Every C2 endpoint were captured by the sandbox, yet none were flagged by threat intelligence feeds. This confirms these are novel indicators not present in any vendor's threat database.

Key Observation:

This analysis revealed a critical gap between what behavioral sandboxes detect and what antivirus vendors act upon:

Both my manual analysis and VirusTotal's automated sandbox identified the same malicious behaviors. The difference is that I concluded the file was malicious based on these behaviors, while the antivirus vendors did not translate behavioral observations into threat signatures.

This demonstrates that the technology to detect malicious behavior exists and works effectively. The failure point is in converting behavioral intelligence into actionable threat signatures that can protect endpoints in real-time.

Automated IOC Correlation

After validating findings manually, I built a Python script to automate the correlation process and demonstrate scalability.

1. IOC Organization

I created a structured JSON file containing all indicators for automated processing: File here IOC Collection

{
  "metadata": {
    "project": "Malware Analysis - Phase 2",
    "date": "2025-11-17"
  },
  "file_hashes": {
    "eicar_control": "131f95c51cc819465fa179f6ccacf9d494aaaff46fa3eac73ae63ffbdfd8267",
    "custom_malware": "05e7d9a4d05470b5dcce3b963b140df486c866f2c31450e3a11ccf12d0dbcc7e"
  },
  "domains": [
    "update-cdn.net",
    "telemetry-api.org",
    "metrics-service.com"
  ]
}

This structured format allows the script to process any number of indicators without code modifications, just update the JSON file with new IOCs.

2. Correlation Script Design

Script: Threat Intelligence Parser

The script performs the following operations:

Load Configuration: Read API key from .env file and IOCs from iocs.json
File Hash Correlation: Query each hash against VirusTotal's file endpoint
Domain Correlation: Query each domain against VirusTotal's domain endpoint
Rate Limiting: 15-second delays between requests to stay within API quotas for a free tier
Result Aggregation: Compile all findings into a timestamped JSON report
Summary Generation: Calculate detection statistics

3. Execution Results

I ran the automated correlation against all 5 IOCs

Generated Report: VirusTotal Correlation Results

Detection Statistics

Category	IOCs Analyzed	Detected	Clean/Not Found	Detection Rate
Control (EICAR)	1	1	0	100%
Custom Malware	1	0	1	0%
C2 Domains	3	0	3	0%
Total Custom Indicators	4	0	4	0%

Implications for Security Operations

This analysis has several important implications for how organizations approach threat detection:

What Doesn't Work:

Relying solely on antivirus signatures (0% detection rate for novel threats)
Assuming "clean" scan results mean files are safe
Trusting vendor threat intelligence feeds for zero-day protection

What Does Work:

Behavioral analysis with manual interpretation (captured all malicious activity)
Network monitoring for C2 patterns (would detect beacon traffic)
EDR with custom detection rules (could identify this behavior)
Threat hunting based on TTPs rather than signatures

Recommended Approach:

Assume Signature Evasion: Novel threats will bypass antivirus
Implement Behavioral Monitoring: Deploy EDR with behavioral analytics
Network-Based Detection: Monitor for C2 communication patterns
Custom Detection Rules: Create YARA/Sigma rules based on observed TTPs
Threat Hunting Programs: Proactively search for suspicious behaviors

Conclusion and Lessons Learnt

Phase 2 successfully demonstrated the critical gap between behavioral detection capabilities and deployed threat signatures. While VirusTotal's sandbox technology effectively captured all malicious behaviors, this intelligence failed to translate into protective action by antivirus vendors.

The custom malware achieved 100% evasion against 62 antivirus engines despite implementing well-documented malicious techniques. This proves that signature-based detection, while effective against known threats (89.7% detection for EICAR), provides zero protection against novel malware.

For organizations, this means that effective threat detection requires multiple layers: behavioral analysis, network monitoring, custom detection rules, and proactive threat hunting, not just relying on vendor signatures.

The automation framework developed in this phase demonstrates scalability for larger incident response scenarios and can be extended to integrate multiple threat intelligence platforms for comprehensive IOC correlation.

Phase 3: Incident Response

After analyzing the malware and correlating the extracted IOC, the artifacts remained on the system. In this phase, I demonstrated actual incident response execution: containment, eradication, and recovery procedures on the infected Windows VM. This shows practical experience with incident response decision-making and execution.

Initial State

1. Registry Persistence

Location: HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced
Keys: PrimaryEndpoint (value: "update-cdn.net"), LastDiagnostic (value: timestamp)

These keys demonstrated how malware stores configuration data in the registry to survive reboots. While the stored values were placeholders in this case, the technical process of identifying and removing them mirrors production incident response.

2. File Artifacts

3 files: diagnostic_*.log in my temp directory
Created by the malware to log its activities

3. Network indicators: Domains: update-cdn.net, telemetry-api.org, metrics-service.com
Behavior: DNS beaconing pattern
Status: Intentionally non-existent (no real C2 infrastructure)

These domains were chosen to resemble legitimate services (CDN, telemetry, metrics) which is a common malware evasion technique. The beaconing behavior demonstrated typical C2 communication patterns even though no actual command server existed.

See Phase 1 for the full analysis of what these artifacts were and how I found them.

Stage 1: Containment

1. Network Isolation

Why Disable Network Adapter:

Network isolation is the first critical containment step because it prevents the malware from spreading to other machines on the network.

This malware is actively attempting C2 communication and gathering system reconnaissance. In a production environment, while I observed DNS queries and file creation, I cannot assume those are its only capabilities. Real-world malware often uses network protocols for:

Lateral movement — SMB for file shares, RPC for remote execution, WMI for system administration
Propagation — Replicating to network file servers, domain controllers, or other workstations
Data exfiltration — Sending stolen data to external servers.

If other machines on the network were vulnerable or accessible, the malware could spread undetected while I'm analyzing the initial infection.

Disabling the network adapter immediately severs all network connectivity—preventing the malware from: Spreading to other machines via SMB, RPC, or network shares, Communicating with C2 infrastructure, exfiltrating data to internal or external locations, receiving commands to propagate further.

This limits the blast radius to a single machine rather than allowing an incident to escalate across the entire network. This also eliminates uncertainty about firewall rule coverage or configuration errors.

Production environments would additionally implement:

DNS sinkholing for known C2 domains
Firewall blocks for suspicious IP ranges
VLAN isolation for quarantine networks
Network monitoring to detect bypass attempts

All connectivity tests failed - isolation confirmed

2. Process Analysis

I checked for active malicious processes, there was no active malicius process because the malware terminated after it executed for ~2-minute as observed in Phase 1.

# Check for PowerShell processes
Get-Process | Where-Object {$_.Name -like "*powershell*"}

# Check for suspicious background jobs
Get-Job

If Process Was Active: I Would execute process termination:

Stop-Process -Id [PID] -Force

Or leverage EDR capabilities in production environments for remote process killing with detailed telemetry capture.

Principle Demonstrated: Immediate threat restriction while preserving system state for analysis

Stage 2: Eradication

1. File Removal

I identified the malware files as seen in phase 1, quarantined them and confirmed they have been quarantined

Quarantine Rationale:

I quarantined the files locally despite being transferred to Kali in Phase 1 to:

Provide redundancy (evidence preservation)
Simulate EDR behavior (tools like CrowdStrike quarantine locally + upload to cloud)
Prevent re-execution on the endpoint during investigation by isolating the malware artifacts from system paths where they could be executed, accessed by users, or interfere with operations
Maintain evidence chain until investigation formally closes

2. Registry Cleanup

Analytical Perspective: Complete Key Removal

Registry artifacts require different consideration than file artifacts because they integrate with system operation rather than existing as discrete objects.

During Phase 1, the malware created two registry values in HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced:

PrimaryEndpoint: Stored "update-cdn.net" (a placeholder simulating C2 address)
LastDiagnostic: Stored timestamp (simulating operational tracking)

While these specific values were demonstration data, they represent how real malware stores:

Command and control server addresses or IP addresses
Encryption keys or authentication tokens
Operational parameters (beacon frequency, protocol selection)
Campaign identifiers or bot registration data
Failover C2 addresses in prioritized lists

Why Complete Removal:

Unlike files which can be quarantined, registry keys:

Remain Functional If Left: Registry values are read by system processes and potentially by malware components. Leaving them in place provides:
- Information to other malware on the system
- Functional configuration if malware re-executes
- Forensic indicators that system was compromised
Low Re-Analysis Need: Unlike malware samples that might undergo multiple analysis techniques, registry values are typically fully documented in initial analysis. Once the key location, name, type, and value are recorded, there's limited value in maintaining them in active registry.

Location Significance: HKCU\...\Explorer\Advanced

This location contains legitimate Windows settings (folder view options, file extensions, etc.)
Security tools rarely monitor this path for changes
It's user-specific (HKCU) so doesn't require elevation
Blending with legitimate settings provides camouflage

Registry state documented in Phase 1 (infected state screenshots available in Phase 1 analysis).

Removed malicious keys and Confirmed keys no longer exist:

Remove-ItemProperty -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced" -Name "PrimaryEndpoint"
Remove-ItemProperty -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced" -Name "LastDiagnostic"
Get-ItemProperty -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced" -Name "PrimaryEndpoint"
Get-ItemProperty -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced" -Name "LastDiagnostic"

In a production environment with real incidents, I would additionally:

Check associated registry locations (Run keys, Services)
Examine registry for additional malware artifacts
Use forensic tools (Registry Explorer, RegRipper) for comprehensive analysis
Document full registry timeline of changes

3. Antivirus Scan (Verification)

I executed Windows Defender scan:

Start-MpScan -ScanType QuickScan
Get-MpThreat

The Get-MpThreat output shows the EICAR test file, which might seem confusing since Windows Defender already quarantined it back in Phase 1.

Get-MpThreat displays the threat detection history, not just current active threats. The EICAR file shown here is the historical record from Phase 1 when Defender detected and quarantined it. The threat is already neutralized, it's sitting in Defender's quarantine folder, isolated from the system. This command is essentially showing the threat log, including items already handled.

System status: Clean

The system is considered clean despite the EICAR reference because No active threats detected, Historical threats are contained, Custom malware and artifacts removed

Stage 3: Recovery

1. Network Restoration; With Monitoring

Why Monitor After Cleanup: Even with thorough eradication, monitoring serves to:

Detect Unknown Persistence: Malware may have persistence mechanisms not identified in initial analysis (Scheduled tasks that trigger on network availability, WMI event subscriptions, Startup folder items, Service installations)
Validate Cleanup Effectiveness: Monitoring provides confirmation that No artifacts were missed during eradication, No time-delayed components activate, System behavior returns to normal baseline
Build Response Confidence: Systematic monitoring before declaring "all clear" reduces risk of premature recovery and re-compromise.

I did a 15-minutes monitoring to demonstrate the methodology while acknowledging that production environments require extended monitoring (24-48 hours minimum).

Recovery Summary

Network: Restored to operational state
Monitoring: No reinfection indicators detected
System: Verified clean and functional
Decision: Safe to return to normal operations

Response Metrics

Metric	Duration	Observation
Containment	~10 minutes	Network isolation and verification
Eradication	~10 minutes	File quarantine and registry cleanup
Verification	~15 minutes	Systematic IOC absence confirmation
Recovery	~15 minutes	Network restoration and monitoring
Total	~50 minutes	Complete response cycle

Lab Environment Factors:

The controlled environment enabled faster response through:

Single infected system (no scope expansion)
Pre-identified IOCs from Phase 1 analysis
No business impact considerations or approval workflows
Simple malware without rootkit or kernel-level components
No stakeholder communication requirements

Real-World Considerations: Production incidents involve:

Scope determination across multiple systems
Business impact assessment
Management approval for containment actions
Coordination across IT, security, and business teams
Change management procedures
Communication with affected users
Legal and compliance consultation
Documentation for audit requirements

The exercise demonstrates technical execution speed and procedure while recognizing that organizational factors significantly impact real incident response timelines. The methodology remains applicable; the timeline scales with complexity.

Lessons Learned

Evidence-Based Approach:

Quarantining files before deletion preserved analysis flexibility while achieving security objectives. This approach demonstrated:

Professional evidence handling
Forensic methodology awareness
Option preservation for continued learning

Systematic Verification:

Checking each IOC category independently provided confidence in eradication completeness. The verification principle applies universally:

Don't assume cleanup worked
Test absence of each artifact type
Use multiple verification methods
Document verification results

Complete Documentation:

Recording actions, decisions, and rationale creates:

Reproducible procedures
Knowledge transfer capability
Audit trail for review
Learning resource for future reference

Conclusion

In this phase, I successfully demonstrated incident response procedures through practical execution on a system containing malware artifacts. The systematic approach of containment, eradication, verification, and recovery provided hands-on experience with response methodology while recognizing simulation boundaries.

Phase 4: Custom Phishing Simulation

In this Phase, I demonstrated phishing attacks from sides of: how they're built and how they are detected. Rather than using automated tools like the Social Engineering Toolkit, I built everything from scratch to demonstrate the mechanics.

What I Built:

Python email generator that creates convincing phishing emails
Flask web server that harvests credentials
Fake Microsoft login page (HTML/CSS/JS)
Complete attack chain from email to credential capture

What I Analyzed:

Network traffic showing cleartext credential transmission
Automated credential extraction with NetworkMiner
Email authentication gaps
Detection opportunities at multiple layers

This phase demonstrates both offensive tradecraft and defensive analysis - understanding how attacks work to build better detection.

Building the Attack Infrastructure

Part 1: Building the Phishing Email Generator

A realistic phishing email needs several components working together:

Proper MIME structure with both text and HTML versions
Convincing sender address and headers
Professional HTML styling matching the impersonated brand
Embedded phishing link pointing to the credential harvester
Psychological triggers (urgency, authority, fear)

Full script: email_gen.py

1. Message ID Generation

Why this matters: Every email has a unique Message-ID header. By generating random IDs, I simulated what a real email would look like. In a real phishing campaign, attackers randomize these to avoid pattern-based detection.

Technical detail: The Message-ID format is <random_string@domain>. I chose outlook.com to loosely match Microsoft's infrastructure, though a real analysis would catch that Microsoft Account Team emails wouldn't use consumer Outlook domains.

2. Email Header Construction

Header analysis:

From address: Spoofed to look like Microsoft's security team. The domain accountprotection.microsoft.com is a real Microsoft domain, making this appear legitimate at first glance
Subject line: Uses urgency ("unusual activity") and security framing to trigger concern
Date header: RFC 822 compliant format - attention to detail makes emails harder to detect

Detection opportunity: In a production environment with email security, SPF/DKIM checks would fail because this email isn't actually from Microsoft's mail servers. This is the first line of defense. (See Part 6 for detailed header analysis)

3. HTML Email Body

This demonstrates the psychological manipulation:

Social engineering breakdown:

Visual authority: Microsoft's blue (#0067b8) and Segoe UI font are instantly recognizable
Warning symbol: The ⚠ emoji creates immediate visual alarm
Specific details: Showing timestamp, device, and location makes it feel legitimate (even though I generated these)
Escape clause: "If this was you, you can safely ignore this email" - builds trust by not forcing action
Urgency escalation: "If this wasn't you, your account may be at risk" - creates pressure
Clear call-to-action: Big blue button saying "Verify Account Now" - makes the desired action obvious

Why a user would fall for this: The email looks professional, includes specific details, and creates a time-sensitive security scenario. Under pressure, users skip the critical thinking step of verifying the sender or hovering over the link.

4. MIME Multipart Assembly

Technical note: Email clients first try to render the HTML version, falling back to plain text if HTML isn't supported. Both versions contain the same phishing link, ensuring the attack works regardless of the client.

Missing headers (red flags for email security):

No DKIM-Signature header
No SPF authentication results
No DMARC policy
No Received: headers showing mail server path
No Return-Path header

These missing headers would immediately flag this email in any organization with proper email security gateways. Modern email security relies heavily on SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail), and DMARC (Domain-based Message Authentication) to verify sender authenticity.

Part 2: Credential Harvesting Server

Flask Architecture Decision

I chose Flask over alternatives (Django, FastAPI, raw HTTP server) because:

Lightweight: Minimal overhead, perfect for single-purpose credential harvesting
Simple routing: Clean decorator syntax for HTTP endpoints
Industry standard: Flask is commonly used in security tools and red team infrastructure
Quick development: Built-in templating, form handling, JSON responses

Server Implementation

Full script: harvester.py

Route 1: Serving the Fake Login Page

When victim clicks the phishing link (http://192.168.100.10:8080), Flask serves the fake Microsoft login page from the templates/login.html file.

This works because: Flask's render_template() function processes Jinja2 templates, allowing for dynamic content if needed (though my login page is static).

Route 2: Credential Capture Endpoint

Data extraction:

request.form.get('email') - Pulls email from POST data
request.form.get('password') - Pulls password from POST data
request.remote_addr - Victim's IP address
request.headers.get('User-Agent') - Browser fingerprint

No validation: Notice there's no input validation, no length checks, no email format verification. This is intentional; attackers want to capture whatever users provide, even if it's garbage data.

Multi-Format Logging Strategy

Three-tier logging for:

Plain text log (captured.log): Human-readable, easy to tail/grep
JSON log (captured.json): Machine-parseable, ready for automation
Console output: Real-time monitoring during attack

JavaScript Credential Submission

Attack flow:

e.preventDefault() - Stops normal form submission (prevents page reload)
FormData - Collects email and password
fetch('/login', ...) - Sends credentials to harvester asynchronously
Success response → Shows confirmation → Redirects to real Microsoft

Why the redirect? Users expect to end up at Microsoft after "verifying" their account. Redirecting to the real site maintains the illusion and prevents suspicion.

By this point, credentials are captured, logged, and the victim believes they successfully verified their account. No error messages, no broken experience, just a smooth transaction that happens to have compromised their credentials.

Part 3: Attack Simulation and Traffic Capture

Multi-Terminal Setup

Terminal 1 - Credential Harvester:

python3 harvester.py

Running and waiting for connections.

Terminal 2 - HTTP Server (for email delivery):

python3 -m http.server 9000

Serves the generated phishing email to the Windows VM.

Terminal 3 - Wireshark:

sudo wireshark

Packet capture on eth0 interface.

Attack Simulation

From the Windows VM, I navigated to http://192.168.100.10:9000/email_preview.html to view the phishing email.

The email displayed a professional Microsoft security alert warning about unusual sign-in activity from Lagos, Nigeria, with specific timestamp and device information. The psychological pressure created by the security warning combined with the professional appearance simulates how attackers make email phishing attacks seem convincing.

I clicked the "Verify Account Now" button, which directed the browser to http://192.168.100.10:8080 where the fake Microsoft login page loaded. I entered test credentials (mira@emberltd.com / 86yt322) and clicked "Sign in."

The Flask harvester immediately captured the credentials:

Terminal output showed:

[+] Got credentials from 192.168.100.20
    mira@emberltd.com / 86yt322

The browser displayed a success message ("Verification complete. Your account is secure.") maintaining the deception:

Attack Timeline: Credentials captured within approximately 90 seconds of viewing the email, demonstrating how quickly phishing attacks succeed when social engineering is effective.

Full attack chain artifacts:

Email generator script: email_gen.py
Credential harvester: harvester.py
Fake login page: login.html
Email preview template: email_preview.html
Generated email: phishing_20251118_045347.eml
Captured credentials: captured.log, captured.json

Part 4: Network Traffic Analysis with Wireshark

Why Wireshark in This Scenario?

In a real phishing attack, the attacker only sees web server logs (credentials, IP, user agent). I used Wireshark to represent the defender's perspective—what a SOC analyst would see when investigating this incident on the organization's network. I demonstrated:

How network monitoring detects credential theft
What IDS/IPS signatures would trigger
How incident responders reconstruct attacks from PCAPs
Network-based indicators of compromise

PCAP Analysis

Capture file: phishing_converted.pcap

1. HTTP Traffic Overview

I applied http filter to isolate all HTTP requests:

Traffic observed:

Packet 196: GET request for email HTML
Packet 264: GET request for login page (/)
Packet 615: POST request to /login (credential submission)
Packet 618: HTTP 200 response with JSON success

Protocol breakdown:

All traffic over HTTP (port 8080)
No encryption (no TLS/HTTPS)
Complete visibility into payload

2. Isolating Credential Submission

I applied the filter http.request.method == "POST" to isolate the credential submission packet, then used "Follow → HTTP Stream" to view the complete conversation:

Complete HTTP conversation:

POST /login HTTP/1.1
Host: 192.168.100.10:8080
Connection: keep-alive
Content-Length: 255
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/142.0.0.0 Safari/537.36 Edg/142.0.0.0
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryP7sLBlaWhXaoNlV7
Accept: */*
Origin: http://192.168.100.10:8080
Referer: http://192.168.100.10:8080/
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9

------WebKitFormBoundaryP7sLBlaWhXaoNlV7
Content-Disposition: form-data; name="email"

mira@emberltd.com
------WebKitFormBoundaryP7sLBlaWhXaoNlV7
Content-Disposition: form-data; name="password"

86yt322
------WebKitFormBoundaryP7sLBlaWhXaoNlV7--

HTTP/1.1 200 OK
Server: Werkzeug/3.1.3 Python/3.13.7
Date: Tue, 18 Nov 2025 10:48:09 GMT
Content-Type: application/json
Content-Length: 21
Connection: close

{"status":"success"}

Critical finding: Credentials in cleartext

Critical Finding: Credentials transmitted in cleartext with zero encryption. Any network monitoring tool (IDS/IPS, DLP, SIEM) or attacker performing MITM would capture these credentials.

Detection Opportunity: Organizations with network security monitoring would catch this through IDS rules like:

alert http any any -> any any (msg:"Possible credential theft - password in POST"; 
content:"password"; http_client_body; sid:1000001;)

User-Agent Intelligence:

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 
(KHTML, like Gecko) Chrome/142.0.0.0 Safari/537.36 Edg/142.0.0.0

Extracted information:

OS: Windows 10 (64-bit)
Browser: Microsoft Edge 142
Rendering engine: Chromium-based

This intelligence helps attackers tailor future exploits (OS-specific malware, browser vulnerabilities) and profile organizational desktop builds.

Part 5: Automated Analysis with NetworkMiner

Wireshark provided deep packet-level analysis, but I also used NetworkMiner to demonstrate automated credential extraction commonly used in SOC triage workflows.

Tool Selection Rationale:

For this lab (5 minutes of traffic, 1 credential), Wireshark was completely sufficient. I chose to include NetworkMiner to demonstrate:

Automated triage capabilities - Rapid credential extraction without manual stream following
Tool diversity - Real SOC environments use multiple complementary tools
Scalability benefits - Where NetworkMiner excels in production incidents

When NetworkMiner Provides Real Value:

Scenario	NetworkMiner Advantage	Time Saved
Large PCAPs (2GB+, 8+ hours of traffic)	Instant credential extraction vs. hours of manual filtering	Hours → Minutes
Mass compromise (200+ HTTP sessions, 30+ users)	Automatic parsing of all credentials/files	Hours → 5 minutes
SOC Tier 1 triage	Quick "were credentials stolen?" answer for escalation	Enables rapid decision-making
Junior analyst workflow	No need for TCP stream reconstruction knowledge	Lowers skill barrier

NetworkMiner Analysis

1. Hosts Tab Analysis

192.168.100.10 (Kali - Attacker)

OS: Unknown (Linux fingerprint)
Services: HTTP on port 8080
Server banner: Werkzeug/3.1.3 Python/3.13.7
Open ports: 8080, 9000

192.168.100.20 (Windows - Victim)

OS: Windows 10
Browser: Mozilla/5.0 (Edge)
Sent: 559 packets (43,628 bytes)
Received: 267 packets (30,971 bytes)

The asymmetry in packet counts (victim sent more than received) is normal for HTTP POST - credentials sent upstream are small, but include HTTP headers and form data.

2. Credentials Tab

Automatic Extraction:

Client: 192.168.100.20
Server: 192.168.100.10
Protocol: MIME/MultiPart
Username: mira@emberltd.com
Password: 86yt322
Timestamp: 2025-11-18 10:48:09 UTC+00

This is NetworkMiner's primary value; it parsed the HTTP POST, recognized the form fields and extracted credentials without me writing filters or following streams manually.

SOC Triage Scenario: Analyst drops PCAP into NetworkMiner, immediately sees credentials were compromised, escalates to incident response. Total time: 2 minutes.

3. Files and Sessions

NetworkMiner automatically carved files from the TCP streams:

index.html (3,446 bytes) - The fake login page
login.json (21 bytes) - Success response

The Sessions tab visualized the complete HTTP conversation flow between victim and harvester, providing an intuitive overview faster than navigating Wireshark's packet list.

Tool Comparison Summary:

Analysis Need	Tool Used	Rationale
Protocol-level detail	Wireshark	Required for understanding HTTP structure, headers, POST payload
Rapid credential extraction	NetworkMiner	Demonstrates SOC triage—instant results without manual analysis
Large-scale forensics	NetworkMiner advantage	Multi-GB PCAPs with 100+ sessions analyzed in minutes vs. hours

Conclusion: Both tools serve complementary purposes. In my analysis, Wireshark was the primary tool for protocol understanding, while NetworkMiner demonstrated automated triage capabilities essential for real SOC workflows.

Part 6: Email Header Security Analysis

I examined the generated email file to identify authentication gaps that would flag this as malicious in production environments.

Email source: phishing_20251118_045347.eml

Header Structure:

From: Microsoft Account Team <account-security-noreply@accountprotection.microsoft.com>
To: victim@company.local
Subject: Unusual sign-in activity detected
Date: Tue, 18 Nov 2025 04:53:47 +0000
Message-ID: <xl2hyzgylynxx4oi@outlook.com>

What's Missing: Email Authentication

Modern email security relies on three authentication standards. My phishing email fails all of them:

Security Control	Status in Attack	Real-World Impact
SPF (Sender Policy Framework)	❌ Failed	Email not from authorized Microsoft mail servers; would be flagged as "SoftFail" or "Fail"
DKIM (DomainKeys Identified Mail)	❌ Missing	No cryptographic signature; high spam score, likely quarantined
DMARC (Domain-based Message Authentication)	❌ Not enforced	No policy instructions for receiving server on SPF/DKIM failures
Received Headers	❌ Missing	No SMTP relay path; immediate indicator of manual creation/spoofing
Return-Path	❌ Missing	No bounce address; legitimate emails always have this

SPF Check:

Receiving server query: "Is 192.168.100.10 authorized to send for microsoft.com?"
Microsoft's SPF record: "v=spf1 ... -all"
Result: FAIL (IP not in authorized list)

DKIM Check:

No DKIM-Signature header present
Result: NONE (cannot verify email integrity)

DMARC Policy:

microsoft.com DMARC: "v=DMARC1; p=reject; ..."
Action with failed SPF+DKIM: REJECT at gateway

Additional Red Flags

Message-ID Domain Mismatch:

From: account-security-noreply@accountprotection.microsoft.com
Message-ID: <xl2hyzgylynxx4oi@outlook.com>

Microsoft Account Team would not generate Message-IDs with @outlook.com. This inconsistency would trigger content analysis rules in advanced email gateways.

No Received Headers:

Legitimate emails have a chain of Received: headers showing the path through SMTP servers:

Received: from mail.microsoft.com (10.10.10.1) by mx.company.com
Received: from relay1.microsoft.com by mail.microsoft.com
Received: from sender.microsoft.com by relay1.microsoft.com

My email has zero Received headers because it wasn't sent through SMTP; it's a locally generated file. This is a red flag for email gateways.

Content-Based Detection

Beyond authentication failures, content analysis would flag:

Subject line patterns:

"Unusual sign-in activity detected" - High-frequency phishing phrase database match
Creates urgency and fear - Psychological manipulation indicator

Link analysis:

Destination: http://192.168.100.10:8080 - Private IP range (RFC 1918)
Legitimate Microsoft would never link to non-routable addresses
Missing HTTPS - No encrypted connection

Generic content:

No personalization (no account number, no name)
Real Microsoft security alerts include account-specific details and partial recovery email

Urgency tactics:

"Verify your identity immediately"
"This link will expire in 24 hours"
Time pressure to bypass critical thinking

Reality Check:

With proper email security (SPF/DKIM/DMARC enforcement + content filtering), this phishing email would be rejected at the gateway before ever reaching a user's inbox. The multiple authentication failures combined with content red flags would result in:

Gateway rejection (DMARC p=reject for microsoft.com)
Or quarantine (if DMARC policy is less strict)
Or spam folder (high spam score from missing authentication)

The attack only succeeded in this lab because I bypassed email infrastructure entirely (direct HTTP delivery). In production, email security is the first and most effective line of defense against phishing.

Part 7: Multi-Layer Detection Analysis

Effective phishing defense requires detection capabilities across multiple security layers. Here's where this attack would be caught in a properly secured environment:

7.1 Email Gateway (Layer 1)

Detection Methods:

SPF/DKIM/DMARC Enforcement:

Query: "Is sender IP authorized for microsoft.com domain?"
Microsoft's SPF: -all (strict reject for unauthorized servers)
Action: Email rejected at gateway before delivery

Content Filtering:

Subject pattern match: "unusual sign-in activity" → Phishing database hit
Link analysis: Destination is private IP (192.168.100.10) → Block
Missing personalization → Suspicion score increase

Effectiveness: Blocks 80-90% of phishing attempts

7.2 Network Security (Layer 2)

IDS/IPS Signatures:

Signature 1: Cleartext credential transmission

alert http any any -> any any (msg:"HTTP POST with password field"; 
content:"password"; http_client_body; 
content:"Content-Disposition: form-data"; http_client_body; 
sid:1000001; rev:1;)

Signature 2: Non-standard HTTP service on internal host

alert tcp $HOME_NET any -> $HOME_NET 8080 (msg:"Internal HTTP server on non-standard port"; 
flow:to_server,established; 
content:"POST"; http_method; 
sid:1000002; rev:1;)

Signature 3: Suspicious User-Agent + credential submission pattern

alert http $HOME_NET any -> any any (msg:"Workstation posting credentials to internal IP"; 
content:"multipart/form-data"; http_header;
content:"password"; http_client_body; 
sid:1000003; rev:1;)

Network Behavior Analytics:

Workstation (192.168.100.20) connecting to unusual internal server (192.168.100.10:8080)
Short-lived HTTP session with immediate disconnect after POST
User-Agent from internal host to internal server (unusual pattern)

Effectiveness: Detects 70-80% of attacks that bypass email gateway

7.3 Endpoint Security (Layer 3)

EDR/Antivirus Indicators:

Browser telemetry:

User navigating to IP address instead of domain name
Form submission to non-HTTPS site (browser warning generated)
Credential manager not offering autofill (site not recognized)

Process behavior:

Browser making HTTP request to internal IP
No certificate validation (HTTP vs. HTTPS)
Form submission event to unknown destination

Modern browser warnings:

"Not secure" indicator in address bar for HTTP
Form submission warning: "This site is not secure. Are you sure you want to send this information?"

Effectiveness: Warns users 60-70% of the time (if they pay attention)

7.4 User Awareness (Layer 4)

Red flags users should recognize:

Email indicators:

Generic greeting (no personalized name or account number)
Unexpected security alert with no prior context
Urgency creating panic ("immediate action required")
Sender address inconsistency (Message-ID domain mismatch)

Link indicators:

Hover over button → Status bar shows IP address, not microsoft.com
URL preview shows http:// (not https://)
Destination is not a legitimate Microsoft domain

Page indicators:

No HTTPS padlock in address bar
Browser displays "Not secure" warning
URL bar shows IP address (192.168.100.10:8080)
No SSL certificate information available

Behavioral red flags:

Request to verify credentials for security (legitimate alerts don't ask for this)
No alternative verification method offered (e.g., app notification, SMS)
Time pressure ("expires in 24 hours")
Threat of account closure

Effectiveness: Final line of defense—critical for novel attacks that bypass technical controls

7.5 Defense-in-Depth Summary

No single layer prevents all phishing attacks. Effective defense requires overlapping controls:

┌─────────────────────────────────────┐
│   Email Gateway (Layer 1)           │  Blocks 80-90%
│   SPF/DKIM/DMARC + Content Filter   │
└──────────────┬──────────────────────┘
               │ 10-20% get through
               ↓
┌─────────────────────────────────────┐
│   Network Security (Layer 2)        │  Detects 70-80%
│   IDS/IPS + Behavior Analytics      │  of remaining
└──────────────┬──────────────────────┘
               │ 2-6% get through
               ↓
┌─────────────────────────────────────┐
│   Endpoint Security (Layer 3)       │  Warns 60-70%
│   EDR + Browser Warnings            │  of remaining
└──────────────┬──────────────────────┘
               │ 1-2% get through
               ↓
┌─────────────────────────────────────┐
│   User Awareness (Layer 4)          │  Final defense
│   Training + Skepticism             │  for novel attacks
└─────────────────────────────────────┘

In This Simulation:

Layer 1 would have blocked (authentication failures at email gateway)
Layer 2 would have detected (cleartext credentials in network traffic)
Layer 3 would have warned (HTTP site, no HTTPS, IP address in URL)
Layer 4 had multiple opportunities (visible red flags in email and page)

Reality: Many organizations are weak in at least one layer, which is why phishing remains effective. Defense-in-depth ensures that if one layer fails, others provide backup protection.

Security Insights

1. Social Engineering Remains the Weakest Link

Despite multiple technical red flags (IP address in URL, HTTP instead of HTTPS, missing email authentication headers), the attack succeeded because of effective psychological manipulation. The professional Microsoft branding, specific sign-in details, and urgency framing overrode critical thinking. No amount of technical security can completely compensate for human susceptibility to authority, urgency, and fear—which is why user awareness training remains critical even in technically sophisticated environments.

2. Phishing Is Technically Simple But Psychologically Sophisticated

The technical implementation was straightforward: Flask web server, HTML form, HTTP POST handler. The real sophistication lies in crafting believable narratives that exploit cognitive biases—authority (Microsoft branding), urgency ("account may be at risk"), and fear (account compromise). This psychological dimension is why phishing remains effective after decades of awareness training and technical defenses.

3. Dual Perspective Provides Complete Understanding

Attackers see only harvester logs (credentials, IP, User-Agent)—simple, clean data. Defenders see network traffic, protocol anomalies, behavioral patterns, authentication failures—much richer detection opportunities. By building the attack infrastructure and then analyzing it forensically, I identified exactly where defenders can detect and block these attacks across multiple layers. This offensive-defensive synthesis is essential for security professionals who must think like attackers to build effective defenses.

Conclusion

This phase demonstrated the complete lifecycle of a credential phishing attack, from custom infrastructure development (Python email generator, Flask harvester, fake Microsoft login page) through execution and multi-tool forensic analysis (Wireshark, NetworkMiner). By building the attack from scratch rather than using pre-packaged frameworks like GoPhish or SET, I gained deep understanding of the underlying technical mechanisms—MIME multipart email structure, HTTP POST exploitation, cleartext credential transmission, and social engineering content design.

The simulation captured credentials within 90 seconds of the victim viewing the email, demonstrating how effective social engineering compresses decision-making time despite visible red flags. The dual-perspective analysis—playing both attacker (infrastructure development, credential harvesting) and defender (network forensics, detection engineering)—provided comprehensive visibility into the attack lifecycle that wouldn't be possible from either perspective alone.

Key Findings:

Email gateway security is the most effective defense - With proper SPF/DKIM/DMARC enforcement, this attack would be blocked before reaching any inbox
Network monitoring provides secondary detection - Cleartext credentials in HTTP traffic are easily detected by IDS/IPS
Defense-in-depth is essential - Multiple overlapping layers ensure that if one control fails, others provide backup
Offensive understanding improves defensive capabilities - Building the attack revealed exactly where and how defenders can detect it

This offensive-defensive synthesis demonstrates that understanding attacker techniques and tooling directly improves defensive architecture, detection engineering, and incident response capabilities; core competencies for modern security professionals.

Name		Name	Last commit message	Last commit date
artifacts		artifacts
docs		docs
logs		logs
pcaps		pcaps
results/phase2		results/phase2
screenshots		screenshots
scripts		scripts
templates/phase4		templates/phase4
.env.example		.env.example
.gitignore		.gitignore
LICENSE		LICENSE
README.md		README.md
requirements.txt		requirements.txt

Latest commit

History

Folders and files

Repository files navigation

Security Incident Lifecycle: Behavioral Malware Analysis and IOC Extraction, Threat Intelligence Correlation and Incident Response, Phishing Simulation.

Table of Contents

Phase 0: Baseline Environment Setup

Phase 1: Malware Analysis & IOC Extraction

Phase 2: Threat Intelligence Correlation

Phase 3: Incident Response

Phase 4: Custom Phishing Simulation

Project Overview

Why I Built This

Skills & Tools Demonstrated

Phase 0: Baseline Environment Setup

The Challenge

Phase 1: Preparation (NAT Mode)

Phase 2: Lockdown (Internal Network)

Architecture Overview

Virtual Machine Configuration

Windows 10 VM (The Target)

Kali Linux VM (The Analyst Workstation)

Security Hardening

Windows VM Security Hardening

VirtualBox-Level Hardening

Operating System-Level Hardening

Baseline Documentation

Baseline Concept: Document the clean state -> Execute malware -> Compare to find changes

Why Baselines Matter

Baseline Capture Process

EICAR Validation Test

Why Test with EICAR First?

Phase 1: Malware Analysis & IOC Extraction

The Malware Script

Malware Execution and Monitoring

Behavioral Analysis and IOC Extraction

MITRE ATT&CK Mapping

Why My RAT Doesn't Auto-Execute and Why That's a Design Choice Not a Limitation

Evidence Collection and Preservation

File Integrity Verification

The Window Virus Threat Real Time protection Incident

Key Learnings

Phase 1 Summary

Phase 2: Threat Intelligence Correlation

Network Configuration

Threat Intelligence Platform Setup

Threat Intelligence Platform Selection

Manual Analysis

Control Test: EICAR Validation

Custom Malware Analysis

Detection Results

Automated IOC Correlation

Detection Statistics

Implications for Security Operations

Conclusion and Lessons Learnt

Phase 3: Incident Response

Initial State

Stage 1: Containment

Stage 2: Eradication

Stage 3: Recovery

Response Metrics

Lessons Learned

Conclusion

Phase 4: Custom Phishing Simulation

Building the Attack Infrastructure

Part 1: Building the Phishing Email Generator

Part 2: Credential Harvesting Server

Server Implementation

Part 3: Attack Simulation and Traffic Capture

Multi-Terminal Setup

Attack Simulation

Part 4: Network Traffic Analysis with Wireshark

PCAP Analysis

Part 5: Automated Analysis with NetworkMiner

NetworkMiner Analysis

Part 6: Email Header Security Analysis

What's Missing: Email Authentication

Additional Red Flags

Content-Based Detection

Part 7: Multi-Layer Detection Analysis