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.
- The Challenge
- Architecture Overview
- Virtual Machine Configuration
- Security Hardening
- Baseline Documentation
- EICAR Validation Test
- The Malware Script
- Malware Execution and Monitoring
- Behavioral Analysis and IOC Extraction
- MITRE ATT&CK Mapping
- Why My RAT Doesn't Auto-Execute
- Evidence Collection and Preservation
- Phase 1 Summary
- Network Configuration
- Threat Intelligence Platform Setup
- Manual Analysis
- Automated IOC Correlation
- Implications for Security Operations
- Conclusion and Lessons Learnt
- Initial State
- Stage 1: Containment
- Stage 2: Eradication
- Stage 3: Recovery
- Response Metrics
- Lessons Learned
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.
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.
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.
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:
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
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.
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.
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
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 networkingVerified the configuration took effect:
ip addr show eth0The 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.
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.
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 |
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.
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.
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.
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.txtThe 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.txtThis documents listening ports, established connections and which processes own them.
See: Network Baseline (raw data for comparison)
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)
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.
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.
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
}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
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.
| 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 |
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.
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.
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.
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.
-
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.
- 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
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
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.
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.
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.
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.
Next, I uploaded the custom malware script to VirusTotal for comprehensive analysis.
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.
.png)
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 capabilityconvertto-json- Data serializationget-ciminstance- System information gatheringnew-item- File/registry creation capabilityout-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-wmibehavior tag) - File creation (5 files dropped)
- Timing delays detected (
long-sleepsbehavior 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.
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
.envfile and IOCs fromiocs.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
| 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% |
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
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.
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.
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_*.login 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.
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-JobIf Process Was Active: I Would execute process termination:
Stop-Process -Id [PID] -ForceOr 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
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
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
| 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.
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
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.
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.
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.comis 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-Signatureheader - No
SPFauthentication results - No
DMARCpolicy - No
Received:headers showing mail server path - No
Return-Pathheader
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.
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
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 datarequest.form.get('password')- Pulls password from POST datarequest.remote_addr- Victim's IP addressrequest.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 passwordfetch('/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.
Terminal 1 - Credential Harvester:
python3 harvester.pyRunning and waiting for connections.
Terminal 2 - HTTP Server (for email delivery):
python3 -m http.server 9000Serves the generated phishing email to the Windows VM.
Terminal 3 - Wireshark:
sudo wiresharkPacket capture on eth0 interface.
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
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
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.
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 |
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 pagelogin.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.
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>
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
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.
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.
Effective phishing defense requires detection capabilities across multiple security layers. Here's where this attack would be caught in a properly secured environment:
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
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
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)
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://(nothttps://) - 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
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.
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.
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.