# SOC Playbook Bundle **VantagePoint Networks** --- | Field | Value | |--------------------|--------------------------------------------| | Document ID | VPN-SOC-PB-001 | | Version | 1.0 | | Classification | | | Author | | | Approved By | | | Effective Date | | | Review Date | | | Organisation | | | SIEM Platform | | | EDR Platform | | | SOAR Platform | | --- ## Table of Contents 1. [How to Use This Bundle](#how-to-use-this-bundle) 2. [Playbook 1: Brute Force Attack](#playbook-1-brute-force-attack) 3. [Playbook 2: Malware Detection](#playbook-2-malware-detection) 4. [Playbook 3: Phishing](#playbook-3-phishing) 5. [Playbook 4: Command and Control (C2) Beaconing](#playbook-4-command-and-control-c2-beaconing) 6. [Playbook 5: Privilege Escalation](#playbook-5-privilege-escalation) 7. [Playbook 6: Data Exfiltration](#playbook-6-data-exfiltration) 8. [Playbook 7: Rogue DHCP / ARP Spoofing](#playbook-7-rogue-dhcp--arp-spoofing) 9. [Playbook 8: VPN Anomaly](#playbook-8-vpn-anomaly) 10. [SOC Shift Handover Template](#soc-shift-handover-template) 11. [Evidence Preservation Checklist](#evidence-preservation-checklist) --- ## How to Use This Bundle Each playbook follows a standardised structure: 1. **Description** -- What the alert means and why it matters 2. **Severity** -- Default severity and escalation conditions 3. **Data Sources** -- Where to look for evidence 4. **Detection Logic** -- SIEM rules and detection patterns 5. **Triage Steps** -- Initial analysis to determine true/false positive 6. **Investigation** -- Deep-dive analysis for confirmed alerts 7. **Containment** -- Immediate actions to limit impact 8. **Escalation Criteria** -- When to escalate to L2/L3 or Incident Response 9. **False Positive Indicators** -- Common benign triggers 10. **MITRE ATT&CK Mapping** -- Framework alignment for threat intelligence All timestamps must be recorded in UTC. All actions must be documented in . --- ## Playbook 1: Brute Force Attack ### Description A brute force attack involves repeated authentication attempts against a user account or service using guessed or known credentials. Variants include credential stuffing (using breached credential lists), password spraying (trying common passwords across many accounts), and traditional brute force (trying many passwords against one account). ### Severity - **Default:** Medium - **Escalate to High:** If a successful login follows failed attempts - **Escalate to Critical:** If a privileged account is targeted or compromised ### Data Sources | Source | Log Type | Location | |---------------------------------|---------------------------------------|-----------------------------| | Active Directory | Windows Security Event Log (4625, 4624, 4771, 4776) | | | Azure AD / Entra ID | Sign-in logs, Audit logs | | | VPN Gateway | Authentication logs | | | Web Application | Access logs, WAF logs | | | SSH | auth.log / secure log | | | Email Gateway | SMTP authentication logs | | | EDR | Process and authentication telemetry | | ### Detection Logic **Rule 1: Single Account Brute Force** ``` source_type=authentication AND event_result=failure | stats count by target_user, source_ip, time_window=m | where count > ``` **Rule 2: Password Spraying** ``` source_type=authentication AND event_result=failure | stats dc(target_user) as unique_users, count by source_ip, time_window=m | where unique_users > AND count > ``` **Rule 3: Successful Login After Failures** ``` source_type=authentication AND event_result=failure | followedby (source_type=authentication AND event_result=success AND same target_user AND same source_ip) | within m ``` ### Triage Steps 1. Review the alert details: source IP, target account, timestamp, failure count 2. Check GeoIP location of the source IP against known user locations 3. Verify if the source IP is internal or external 4. Check if the target account exists and is active 5. Determine if there was a subsequent successful authentication 6. Check if the source IP appears in threat intelligence feeds 7. Verify if this is a known scanner or penetration test (check ) 8. Check for concurrent brute force activity against other accounts from the same source ### Investigation 1. Pull full authentication log for the target account for the past hours 2. If successful login occurred: - Identify all subsequent activity by the account (logons, file access, process creation) - Check for lateral movement indicators - Review email activity for new forwarding rules - Check for privilege escalation or group membership changes 3. Correlate the source IP with other alerts in the past days 4. Check if the account credentials appear in known breach databases 5. Review the account's normal authentication pattern (baseline) 6. Check for MFA bypass or MFA fatigue indicators ### Containment 1. If account compromised: disable the account immediately 2. Block the source IP at the perimeter firewall 3. If password spraying: implement temporary account lockout policy 4. Force password reset for the targeted account(s) 5. Revoke all active sessions and tokens 6. Enable enhanced logging on the targeted service 7. If VPN or remote access: disable remote access for the affected account ### Escalation Criteria Escalate to Incident Response team when: - A privileged account (admin, service account) is successfully compromised - Multiple accounts show successful logins following brute force activity - Post-compromise activity (lateral movement, data access) is observed - The source is internal (insider threat or compromised internal host) - Attack is ongoing and automated blocking is insufficient ### False Positive Indicators - User forgot password and is attempting multiple times - Service account with expired or rotated credentials - Automated monitoring tool with misconfigured credentials - Password manager sync issues - Scheduled task with outdated saved credentials - Legitimate penetration test (verify against ) ### MITRE ATT&CK Mapping | Tactic | Technique | ID | |-------------------|-------------------------------|------------| | Credential Access | Brute Force | T1110 | | Credential Access | Brute Force: Password Guessing | T1110.001 | | Credential Access | Brute Force: Password Spraying | T1110.003 | | Credential Access | Brute Force: Credential Stuffing | T1110.004 | | Initial Access | Valid Accounts | T1078 | --- ## Playbook 2: Malware Detection ### Description Malware detection alerts indicate that antivirus, EDR, or sandbox analysis has identified malicious software on an endpoint or server. This includes viruses, trojans, worms, rootkits, keyloggers, cryptominers, and potentially unwanted programs (PUPs). ### Severity - **Default:** High - **Escalate to Critical:** If malware is ransomware, RAT, or rootkit - **Escalate to Critical:** If malware is detected on a server or domain controller - **Lower to Medium:** If malware was blocked before execution ### Data Sources | Source | Log Type | Location | |-----------------------|---------------------------------------|------------------------| | EDR | Detection events, process trees | | | Antivirus | Detection and quarantine logs | | | SIEM | Correlated alerts | | | Email Gateway | Attachment analysis results | | | Web Proxy | Download events, URL categorisation | | | Sandbox | Dynamic analysis results | | | DNS | Query logs (C2 domain resolution) | | ### Detection Logic **Rule 1: EDR Malware Detection** ``` source= AND event_type=detection AND severity IN (high, critical) AND action != blocked ``` **Rule 2: Malware Execution Indicators** ``` source= AND ( process_name IN () OR file_hash IN (threat_intel_ioc_list) OR behaviour_tags CONTAINS ("ransomware", "rat", "rootkit", "cryptominer") ) ``` **Rule 3: Multi-Stage Alert Correlation** ``` (email_attachment_detected OR web_download_detected) FOLLOWED BY process_creation on same host FOLLOWED BY (network_connection to known_bad_ip OR dns_query to known_bad_domain) WITHIN 60m ``` ### Triage Steps 1. Review the EDR/AV alert: host, user, file path, file hash, detection name 2. Determine if the malware was blocked, quarantined, or executed 3. Check the malware classification (ransomware, trojan, PUP, etc.) 4. Look up the file hash on VirusTotal or internal threat intel 5. Identify the delivery vector (email attachment, web download, USB, lateral movement) 6. Check if the host is a workstation, server, or critical asset 7. Determine if the user has administrative privileges 8. Check for additional alerts on the same host or user in the past 24 hours ### Investigation 1. Review the full process tree in EDR for the malware execution chain 2. Identify parent process and initial execution context 3. Check for persistence mechanisms: - Registry run keys - Scheduled tasks - Services - Startup folder items - WMI subscriptions 4. Review network connections made by the malware process 5. Check DNS queries from the host for known C2 domains 6. Identify any files created, modified, or encrypted by the malware 7. Check for lateral movement attempts (SMB connections, RDP, WMI) 8. If email-delivered: identify all recipients who received the same message 9. Scan the file hash across all endpoints to identify additional infections ### Containment 1. If malware executed and is active: - Isolate the host via EDR network quarantine - Do NOT power off (preserve memory for forensics) 2. Block file hash across all endpoints via EDR 3. Block associated C2 domains and IPs at firewall and DNS 4. If email-delivered: quarantine the message from all mailboxes 5. If web-delivered: block the download URL at the proxy 6. Disable the affected user account if credentials may be compromised 7. Scan all endpoints for the same IOCs (file hash, mutex, registry keys) ### Escalation Criteria Escalate to Incident Response team when: - Ransomware is detected (always escalate immediately) - Malware is detected on a server, domain controller, or critical asset - Multiple hosts are infected (potential worm or lateral movement) - RAT or rootkit is confirmed - Data exfiltration indicators are present - Malware evaded detection and was only found through hunting ### False Positive Indicators - Legitimate penetration testing tools (Cobalt Strike, Metasploit) during authorised test - System administration tools flagged as PUPs (PsExec, AutoIt, etc.) - Custom scripts flagged by heuristic detection - Development tools or compilers triggering behavioural rules - Quarantined malware samples in security research environments ### MITRE ATT&CK Mapping | Tactic | Technique | ID | |-------------------|----------------------------------------|------------| | Execution | User Execution: Malicious File | T1204.002 | | Persistence | Boot or Logon Autostart Execution | T1547 | | Defence Evasion | Obfuscated Files or Information | T1027 | | Command and Control | Application Layer Protocol | T1071 | | Impact | Data Encrypted for Impact | T1486 | --- ## Playbook 3: Phishing ### Description Phishing alerts indicate that a suspicious or malicious email has been delivered to or interacted with by an employee. This includes spear phishing (targeted), whaling (executive targeting), business email compromise (BEC), and credential harvesting campaigns. ### Severity - **Default:** Medium - **Escalate to High:** If credentials were submitted to a phishing page - **Escalate to High:** If a malicious attachment was opened - **Escalate to Critical:** If executive accounts are targeted or compromised (BEC) ### Data Sources | Source | Log Type | Location | |-----------------------|---------------------------------------|------------------------| | Email Gateway | Message trace, threat detection | | | Email Platform | Audit logs (O365/Google Workspace) | | | Web Proxy | URL access logs | | | EDR | Process creation from email clients | | | User Reports | Phishing report button / helpdesk | | | DNS | Query logs for phishing domains | | | Identity Provider | Authentication logs post-phishing | | ### Detection Logic **Rule 1: Phishing Email Delivered** ``` source= AND verdict IN (phishing, spam_phishing, malicious) AND delivery_status=delivered ``` **Rule 2: User Clicked Phishing Link** ``` source= AND url IN (phishing_url_feed) AND referrer CONTAINS "mail" OR user_agent CONTAINS "Outlook" ``` **Rule 3: Credential Submission to Phishing Page** ``` source= AND http_method=POST AND url_category=phishing ``` ### Triage Steps 1. Review the email: sender, subject, recipients, URLs, attachments 2. Check sender domain against known impersonation patterns 3. Analyse any URLs using URL analysis tool (do NOT click on a production system) 4. Check if the email was reported by a user or detected by automated systems 5. Determine how many recipients received the email 6. Check if any recipients clicked links or opened attachments 7. Verify sender authentication (SPF, DKIM, DMARC results) 8. Check if the sender domain was recently registered (lookalike domain) ### Investigation 1. If link clicked: - Check web proxy logs for the user's interaction with the phishing site - Determine if credentials were submitted (POST request to phishing URL) - Review the phishing page to understand what data was requested 2. If credentials submitted: - Treat as compromised credentials immediately - Review authentication logs for the account post-submission - Check for new MFA devices registered - Check for new mail forwarding rules or delegates - Review account activity for signs of compromise 3. If attachment opened: - Follow Malware Detection playbook (Playbook 2) in parallel - Submit attachment to sandbox for dynamic analysis 4. Identify all recipients and check each for interaction 5. Check threat intelligence for the phishing infrastructure ### Containment 1. Quarantine the phishing email from all recipient mailboxes 2. Block the phishing URL at the web proxy and DNS 3. Block the sender domain if confirmed malicious 4. If credentials submitted: - Force immediate password reset - Revoke all active sessions and tokens - Review and remove suspicious MFA devices - Remove any mail forwarding rules added by attacker 5. If attachment opened: follow Malware Containment (Playbook 2) 6. Send security awareness notification to affected users 7. Update email gateway rules with new phishing indicators ### Escalation Criteria Escalate to Incident Response team when: - Credentials for privileged accounts were submitted - BEC is confirmed (attacker has access to executive mailbox) - Malware was delivered and executed via attachment - Multiple users submitted credentials to the same campaign - Phishing campaign appears specifically targeted at - Financial fraud is attempted (wire transfer, invoice manipulation) ### False Positive Indicators - Marketing emails incorrectly classified as phishing - Legitimate password reset emails from known services - Internal phishing simulation campaigns (check ) - Newsletters or automated notifications from legitimate services - Emails with tracking pixels misidentified as malicious ### MITRE ATT&CK Mapping | Tactic | Technique | ID | |-------------------|---------------------------------------------|------------| | Initial Access | Phishing: Spearphishing Attachment | T1566.001 | | Initial Access | Phishing: Spearphishing Link | T1566.002 | | Initial Access | Phishing: Spearphishing via Service | T1566.003 | | Credential Access | Input Capture: Web Portal Capture | T1056.003 | | Collection | Email Collection | T1114 | --- ## Playbook 4: Command and Control (C2) Beaconing ### Description C2 beaconing indicates a compromised host is communicating with an attacker-controlled infrastructure at regular intervals. The beacon maintains persistence and allows the attacker to issue commands, exfiltrate data, and deploy additional payloads. Common C2 frameworks include Cobalt Strike, Metasploit, Sliver, and custom implants. ### Severity - **Default:** High - **Escalate to Critical:** If the beaconing host is a server or domain controller - **Escalate to Critical:** If data exfiltration is observed alongside beaconing ### Data Sources | Source | Log Type | Location | |-----------------------|---------------------------------------|------------------------| | NDR | Network flow data, anomaly detection | | | Firewall | Connection logs, threat intelligence | | | Web Proxy | HTTP/HTTPS traffic, SSL inspection | | | DNS | Query logs, NXDOMAIN responses | | | EDR | Process network connections | | | SIEM | Correlated network alerts | | | Threat Intelligence | IOC feeds, C2 infrastructure lists | | ### Detection Logic **Rule 1: Periodic Beaconing Detection** ``` source=firewall_logs | stats count, stdev(interval) as jitter, avg(interval) as avg_interval by src_ip, dst_ip, dst_port, time_window=24h | where count > AND jitter < AND avg_interval BETWEEN AND ``` **Rule 2: Known C2 Infrastructure** ``` (source=dns_logs AND query_domain IN (c2_domain_feed)) OR (source=firewall_logs AND dst_ip IN (c2_ip_feed)) ``` **Rule 3: DNS Tunnelling Indicators** ``` source=dns_logs | stats avg(query_length) as avg_len, count as query_count, dc(query) as unique_queries by src_ip, parent_domain, time_window=1h | where avg_len > AND query_count > AND unique_queries > ``` ### Triage Steps 1. Review the alert: source host, destination IP/domain, port, protocol, frequency 2. Check destination against threat intelligence feeds 3. Perform WHOIS lookup on the destination domain/IP 4. Check if the destination domain was recently registered 5. Analyse the beaconing pattern: interval, jitter, payload size consistency 6. Check if the traffic is encrypted and if SSL inspection reveals content 7. Identify the process on the source host responsible for the connections 8. Check if the source host has other alerts or anomalies ### Investigation 1. Review the full connection history between source and destination 2. Analyse the process tree for the beaconing process in EDR 3. Check for known C2 framework indicators: - Cobalt Strike: named pipes, malleable C2 profiles, default certificates - Metasploit: meterpreter indicators, staged payloads - Sliver: implant indicators, mTLS/HTTP/DNS protocols 4. Review DNS queries from the host for DGA (Domain Generation Algorithm) patterns 5. Check for data transfer volumes (potential exfiltration) 6. Look for lateral movement from the compromised host 7. Check for persistence mechanisms on the host 8. Review user activity on the host for signs of hands-on-keyboard activity 9. Memory analysis may be required for advanced implants ### Containment 1. Isolate the host via EDR network quarantine (do NOT alert the attacker by powering off) 2. Block the C2 domain/IP at firewall and DNS sinkhole 3. Check for the same C2 indicators across all endpoints 4. Preserve memory dump of the affected host 5. Disable the user account associated with the host 6. Block any identified persistence mechanisms 7. If DNS tunnelling: block the parent domain and monitor for domain switching 8. Notify Incident Response team ### Escalation Criteria Always escalate C2 beaconing to the Incident Response team. Additional urgency when: - The C2 has been active for an extended period (advanced persistent threat) - Multiple hosts are beaconing to the same or related infrastructure - Data exfiltration is observed - The host is a high-value target (server, DC, executive workstation) - The C2 framework is associated with a known threat actor ### False Positive Indicators - Heartbeat/keepalive connections from legitimate software (cloud agents, update checks) - VPN or tunnelling software with periodic reconnection - Backup or sync software with regular check-in intervals - IoT devices with scheduled telemetry reporting - CDN or cloud service IPs shared with legitimate services - Software licence check-in mechanisms ### MITRE ATT&CK Mapping | Tactic | Technique | ID | |-----------------------|---------------------------------------------|------------| | Command and Control | Application Layer Protocol: Web Protocols | T1071.001 | | Command and Control | Application Layer Protocol: DNS | T1071.004 | | Command and Control | Encrypted Channel | T1573 | | Command and Control | Protocol Tunnelling | T1572 | | Command and Control | Data Encoding | T1132 | | Exfiltration | Exfiltration Over C2 Channel | T1041 | --- ## Playbook 5: Privilege Escalation ### Description Privilege escalation occurs when an attacker or insider gains higher-level permissions than originally authorised. This includes exploiting OS vulnerabilities (vertical escalation), abusing misconfigurations, or leveraging legitimate administrative tools inappropriately. ### Severity - **Default:** High - **Escalate to Critical:** If domain admin or equivalent is achieved - **Escalate to Critical:** If the escalation occurs on a domain controller ### Data Sources | Source | Log Type | Location | |-----------------------|---------------------------------------|------------------------| | Active Directory | Event IDs 4728, 4732, 4756, 4672, 4648 | | | EDR | Process creation, privilege use | | | Windows Event Logs | Security, System, PowerShell logs | | | Linux Audit | auditd logs, sudo logs | | | Cloud IAM | IAM policy changes, role assignments | | | PAM | Privileged session logs | | ### Detection Logic **Rule 1: Sensitive Group Modification** ``` source=windows_security AND EventID IN (4728, 4732, 4756) AND target_group IN ("Domain Admins", "Enterprise Admins", "Schema Admins", "Administrators", "Account Operators", "") ``` **Rule 2: Privilege Escalation Tool Usage** ``` source= AND (process_name IN ("mimikatz.exe", "rubeus.exe", "sharphound.exe", "bloodhound.exe", "psexec.exe", "procdump.exe") OR command_line CONTAINS ("sekurlsa", "kerberoast", "asreproast", "golden ticket", "silver ticket", "dcsync")) ``` **Rule 3: Unusual Sudo or Privilege Use (Linux)** ``` source=auditd AND type=USER_AUTH AND result=success AND exe="/usr/bin/sudo" AND (auid NOT IN () OR command IN ()) ``` ### Triage Steps 1. Identify the account performing the escalation and the account/group being modified 2. Determine if this was an authorised administrative action (check change management) 3. Verify the performing account's role and whether they have authority to make this change 4. Check for a corresponding change request in 5. Review the timing: was this during business hours? During a maintenance window? 6. Check for preceding suspicious activity on the performing account (brute force, phishing) ### Investigation 1. Review the full activity timeline of the performing account for the past hours 2. Check how the account was authenticated (normal login, pass-the-hash, ticket) 3. Look for lateral movement or reconnaissance preceding the escalation 4. Check for Kerberoasting or AS-REP roasting indicators 5. Review DCSync attempts or NTDS.dit access 6. Check for golden ticket or silver ticket indicators 7. Review cloud IAM changes for shadow admin creation 8. Audit all changes made with the escalated privileges 9. Check for new service accounts, scheduled tasks, or persistence mechanisms ### Containment 1. Remove the unauthorised privilege grant immediately 2. Disable the account that performed the escalation 3. If domain admin compromised: assume full domain compromise - Initiate KRBTGT password reset (double reset, with waiting period) - Review all domain admin accounts - Check for golden ticket persistence 4. Reset passwords for all affected privileged accounts 5. Review and revert any configuration changes made with escalated privileges 6. Enable enhanced auditing on all privileged groups and accounts ### Escalation Criteria Escalate to Incident Response team when: - Domain Admin, Enterprise Admin, or equivalent is compromised - The escalation is not attributable to an authorised change - Known attack tools (Mimikatz, Rubeus, etc.) are detected - The escalation occurs on a domain controller or critical server - Multiple accounts show privilege escalation in a short timeframe ### False Positive Indicators - Authorised IT administration during change windows - PAM solution check-out of privileged credentials - Automated provisioning tools adding users to groups - Break-glass account usage during an incident (verify with IR team) - Group policy refresh triggering privilege audit events ### MITRE ATT&CK Mapping | Tactic | Technique | ID | |---------------------|-----------------------------------------------|------------| | Privilege Escalation | Valid Accounts: Domain Accounts | T1078.002 | | Privilege Escalation | Abuse Elevation Control Mechanism | T1548 | | Credential Access | OS Credential Dumping: LSASS Memory | T1003.001 | | Credential Access | Steal or Forge Kerberos Tickets | T1558 | | Persistence | Account Manipulation | T1098 | --- ## Playbook 6: Data Exfiltration ### Description Data exfiltration alerts indicate that sensitive data may be leaving the organisation through unauthorised channels. This includes large file transfers, use of cloud storage services, email attachments, DNS tunnelling, and physical media. ### Severity - **Default:** High - **Escalate to Critical:** If classified or regulated data (PII, financial, health) is confirmed exfiltrated - **Escalate to Critical:** If exfiltration is to a known adversary infrastructure ### Data Sources | Source | Log Type | Location | |-----------------------|---------------------------------------|------------------------| | DLP | Policy violations, data classifications | | | Web Proxy | Upload events, cloud storage access | | | CASB | Cloud application usage, data sharing | | | Email Gateway | Outbound attachment analysis | | | EDR | File access, USB events | | | Firewall | Large outbound transfers | | | DNS | DNS tunnelling indicators | | | Print | Print audit logs | | ### Detection Logic **Rule 1: Large Outbound Transfer** ``` source=firewall_logs AND direction=outbound AND bytes_out > AND dst_ip NOT IN (approved_destinations) AND dst_ip NOT IN (known_cdn, known_cloud_services) ``` **Rule 2: DLP Policy Violation** ``` source= AND action IN (alert, block) AND data_classification IN (confidential, restricted, pii, pci) ``` **Rule 3: Unusual Cloud Upload** ``` source= AND activity=upload AND (app NOT IN (sanctioned_apps) OR data_volume > OR sharing_scope=external) ``` ### Triage Steps 1. Identify the user, source host, and destination of the data transfer 2. Determine the volume of data transferred 3. Check if the destination is a legitimate business service 4. Review the DLP classification of the data (if DLP triggered) 5. Check if the user has a business justification for the transfer 6. Verify if this is part of normal job function (e.g., sales sharing files with clients) 7. Check for preceding indicators of compromise on the user account or host 8. Determine the channel: email, web upload, USB, cloud sync, DNS tunnel ### Investigation 1. Review the files or data that was transferred (file names, types, sizes) 2. Check file access logs to see what data the user accessed before the transfer 3. Review the user's data transfer history for the past days (baseline) 4. If USB: check EDR for USB device details (vendor, serial number, device type) 5. If cloud: review CASB logs for sharing permissions and external recipients 6. If email: review recipient addresses and attachment contents 7. Correlate with HR data: is this user on a PIP, notice period, or flagged for departure? 8. Check for automation or scripting that might automate the exfiltration 9. If DNS tunnelling suspected: see C2 Beaconing playbook (Playbook 4) ### Containment 1. Block the exfiltration channel (URL, IP, cloud app, email recipient) 2. Disable USB access on the host if removable media was used 3. Revoke cloud sharing permissions for externally shared files 4. If malicious actor: disable the user account 5. If insider threat: coordinate with HR and Legal before account actions 6. Preserve forensic evidence from the host 7. Assess if the exfiltrated data requires regulatory notification ### Escalation Criteria Escalate to Incident Response team when: - Regulated data (PII, PCI, health records) is confirmed exfiltrated - The exfiltration appears deliberate and sustained - The data is being sent to a known adversary or competitor - The volume of data exceeds - Insider threat is confirmed - Regulatory notification may be required ### False Positive Indicators - Legitimate business data sharing with partners or clients - Cloud backup or sync tools operating normally - Software updates downloading large files - Video conferencing or media streaming - Development teams pushing code to external repositories (GitHub, etc.) - Marketing teams uploading content to social media or CDN platforms ### MITRE ATT&CK Mapping | Tactic | Technique | ID | |---------------|-------------------------------------------------|------------| | Exfiltration | Exfiltration Over Web Service | T1567 | | Exfiltration | Exfiltration Over Alternative Protocol | T1048 | | Exfiltration | Exfiltration Over C2 Channel | T1041 | | Exfiltration | Exfiltration Over Physical Medium | T1052 | | Collection | Data from Local System | T1005 | | Collection | Data from Network Shared Drive | T1039 | --- ## Playbook 7: Rogue DHCP / ARP Spoofing ### Description Rogue DHCP servers and ARP spoofing are network-layer attacks that allow an adversary to intercept, modify, or redirect network traffic. A rogue DHCP server distributes malicious network configuration (gateway, DNS), while ARP spoofing associates the attacker's MAC address with a legitimate IP address. ### Severity - **Default:** High - **Escalate to Critical:** If credential interception or MitM is confirmed - **Escalate to Critical:** If affecting server or management VLANs ### Data Sources | Source | Log Type | Location | |-----------------------|---------------------------------------|------------------------| | Network Switches | DHCP snooping logs, DAI logs | | | DHCP Server | DHCP lease and conflict logs | | | NDR | ARP anomaly detection | | | IDS/IPS | ARP spoofing and DHCP attack alerts | | | Network Monitoring | MAC-IP binding changes | | | EDR | Network configuration changes | | ### Detection Logic **Rule 1: Rogue DHCP Server** ``` source=switch_logs AND event_type=dhcp_snooping_violation OR (source=dhcp_logs AND dhcp_server_ip NOT IN ()) ``` **Rule 2: ARP Spoofing / Duplicate IP** ``` source=switch_logs AND event_type=dynamic_arp_inspection_violation OR (source= AND alert_type=arp_spoofing) ``` **Rule 3: Gateway MAC Change** ``` source= AND event_type=mac_ip_binding_change AND ip_address IN () ``` ### Triage Steps 1. Identify the source MAC address and switch port of the offending device 2. Determine if the device is known in the asset inventory 3. Check if DHCP snooping and Dynamic ARP Inspection (DAI) are enabled on the switch 4. Verify the legitimate DHCP server is operational and responding 5. Check if any clients have received incorrect network configuration 6. Determine the VLAN and network segment affected 7. Check if this coincides with any network maintenance or device deployment ### Investigation 1. Identify the physical device by tracing the MAC address to the switch port 2. Check the switch port configuration and connected device 3. If rogue DHCP: compare offered configuration with legitimate DHCP - Check offered gateway, DNS, and lease parameters - Determine if traffic would be redirected through the rogue device 4. If ARP spoofing: identify which IP addresses are being spoofed - Check for MitM indicators (traffic interception, SSL stripping) 5. Review network captures for signs of credential interception 6. Check if any clients have changed their DNS or gateway settings 7. Assess if this is a misconfiguration (new device, VM) or deliberate attack ### Containment 1. Shut down the offending switch port immediately 2. If device identified: physically locate and disconnect 3. Enable DHCP snooping on all affected VLANs if not already enabled 4. Enable Dynamic ARP Inspection (DAI) on affected switches 5. Force DHCP renewal on all affected clients (`ipconfig /release` and `/renew`) 6. Flush ARP caches on affected devices and switches 7. Verify all clients have correct gateway and DNS configuration 8. If credential interception suspected: force password reset for affected users ### Escalation Criteria Escalate to Incident Response team when: - MitM attack is confirmed with credential or data interception - The rogue device cannot be physically located - The attack targets server or management VLANs - The attack persists after containment measures - Deliberate adversarial intent is determined ### False Positive Indicators - New device or VM with DHCP server service enabled unintentionally - Developer testing DHCP configuration in a lab environment - Network printer or IoT device with embedded DHCP server - Virtualisation software (VMware, VirtualBox) bridged networking - Duplicate IP address from static configuration error - Wireless access point in bridge mode ### MITRE ATT&CK Mapping | Tactic | Technique | ID | |---------------------|------------------------------------------|------------| | Credential Access | Adversary-in-the-Middle: ARP Cache Poisoning | T1557.002 | | Credential Access | Adversary-in-the-Middle: DHCP Spoofing | T1557.003 | | Collection | Adversary-in-the-Middle | T1557 | | Discovery | Network Sniffing | T1040 | --- ## Playbook 8: VPN Anomaly ### Description VPN anomaly alerts indicate suspicious patterns in remote access VPN usage. This includes connections from unusual locations, simultaneous sessions from different geographies, connections at unusual times, or excessive failed authentication attempts against the VPN gateway. ### Severity - **Default:** Medium - **Escalate to High:** If impossible travel or simultaneous multi-geo sessions detected - **Escalate to Critical:** If VPN credentials are confirmed compromised with post-auth activity ### Data Sources | Source | Log Type | Location | |-----------------------|---------------------------------------|------------------------| | VPN Gateway | Authentication, session, traffic logs | | | Identity Provider | MFA logs, conditional access logs | | | SIEM | Correlated VPN alerts | | | GeoIP Database | IP geolocation data | | | EDR | VPN client process telemetry | | | Threat Intelligence | Known VPN/proxy/Tor exit node lists | | ### Detection Logic **Rule 1: Impossible Travel** ``` source=vpn_logs AND event=session_start | sort by user, timestamp | calc distance(prev_geo, current_geo) as distance_km, timediff(prev_timestamp, current_timestamp) as time_hours | where distance_km > AND time_hours < ``` **Rule 2: VPN from Suspicious Source** ``` source=vpn_logs AND event=session_start AND (src_ip IN (tor_exit_nodes) OR src_ip IN (known_vpn_proxy_services) OR geo_country IN ()) ``` **Rule 3: Concurrent VPN Sessions** ``` source=vpn_logs AND event=session_start | stats dc(src_ip) as unique_ips, dc(geo_country) as unique_countries by user | where unique_ips > 1 AND unique_countries > 1 | within time_window=m ``` ### Triage Steps 1. Identify the user, source IP, GeoIP location, and connection time 2. Compare against the user's normal VPN usage pattern (location, time, frequency) 3. Check if the source IP is a known VPN/proxy/Tor exit node 4. Verify if the user is travelling (check calendar, travel requests, manager) 5. Check if MFA was successfully completed for the session 6. Determine if multiple concurrent sessions exist from different locations 7. Review the user's recent authentication activity for other anomalies ### Investigation 1. Review the full VPN session: duration, data transferred, resources accessed 2. Check what internal resources were accessed during the VPN session 3. Compare accessed resources with user's normal access pattern 4. If impossible travel: determine which session is legitimate 5. Check for credential theft indicators (phishing, brute force) preceding the VPN session 6. Review EDR telemetry from the connecting device (if MDM/EDR enrolled) 7. Check if the device certificate matches the expected device 8. Review any file transfers or data access during the session 9. Contact the user through a verified channel to confirm the session ### Containment 1. Terminate the suspicious VPN session 2. Disable VPN access for the affected user account 3. If credentials compromised: force password reset and MFA re-enrollment 4. Block the source IP at the VPN gateway 5. If attacker accessed internal resources: assess and contain data access 6. Enable enhanced logging for the user's account 7. Review conditional access policies for VPN access ### Escalation Criteria Escalate to Incident Response team when: - Confirmed unauthorised VPN access with internal resource access - VPN credentials are confirmed stolen (e.g., following phishing) - Attacker accessed sensitive systems or data via VPN - Multiple user accounts show similar VPN anomalies (coordinated attack) - VPN gateway vulnerability is suspected ### False Positive Indicators - User travelling and connecting from a new location - User using a mobile hotspot with dynamic IP geolocation - Corporate VPN client reconnecting after network change (new IP) - User using a personal VPN service before connecting to corporate VPN - GeoIP database inaccuracy (IP recently reassigned) - Split-tunnel VPN showing different exit points for different traffic ### MITRE ATT&CK Mapping | Tactic | Technique | ID | |-------------------|----------------------------------------|------------| | Initial Access | Valid Accounts | T1078 | | Initial Access | External Remote Services | T1133 | | Credential Access | Brute Force | T1110 | | Lateral Movement | Remote Services: VPN | T1021 | | Defence Evasion | Use Alternate Authentication Material | T1550 | --- ## SOC Shift Handover Template ``` SOC SHIFT HANDOVER VantagePoint Networks SHIFT DETAILS Date: ____________________________ Outgoing Shift: ____________________________ Outgoing Analyst: ____________________________ Incoming Shift: ____________________________ Incoming Analyst: ____________________________ Handover Time: ____________________________ (UTC) ENVIRONMENT STATUS Overall Status: [ ] Green (Normal) [ ] Amber (Elevated) [ ] Red (Active Incident) Threat Level: [ ] Low [ ] Moderate [ ] High [ ] Critical ACTIVE INCIDENTS | Incident ID | Priority | Type | Status | Assigned To | Next Action | ETA | |-------------|----------|------|--------|-------------|-------------|-----| | | | | | | | | | | | | | | | | | | | | | | | | OPEN INVESTIGATIONS | Ticket ID | Alert Type | Status | Notes | Assigned To | |-----------|------------|--------|-------|-------------| | | | | | | | | | | | | | | | | | | NOTABLE EVENTS THIS SHIFT 1. ____________________________________________________ 2. ____________________________________________________ 3. ____________________________________________________ PENDING ACTIONS (Carry Forward) 1. ____________________________________________________ 2. ____________________________________________________ 3. ____________________________________________________ SYSTEM HEALTH | System | Status | Notes | |------------------|----------|------------------------------------| | SIEM | [ ] OK | | | EDR | [ ] OK | | | NDR | [ ] OK | | | Firewall Logging | [ ] OK | | | Email Gateway | [ ] OK | | | Threat Intel | [ ] OK | | | Ticketing System | [ ] OK | | UPCOMING EVENTS - Scheduled maintenance: ________________________________ - Penetration tests: ____________________________________ - Threat intel advisories: ______________________________ - Other: ________________________________________________ COMMUNICATION LOG | Time (UTC) | From/To | Channel | Summary | |------------|---------|---------|---------| | | | | | | | | | | OUTGOING ANALYST SIGNATURE: _________________ DATE: ________ INCOMING ANALYST SIGNATURE: _________________ DATE: ________ ``` --- ## Evidence Preservation Checklist Use this checklist when preserving digital evidence for any SOC investigation. ### Before Collection - [ ] Incident ticket created and documented in - [ ] Chain of custody form initiated - [ ] Legal hold notification checked (coordinate with if needed) - [ ] Write blocker available (if physical media involved) - [ ] Storage media sanitised and ready for evidence - [ ] SHA-256 hashing tool available and verified ### Volatile Evidence (Collect First -- Ordered by Volatility) - [ ] Memory dump captured (WinPMEM, LiME, or EDR memory acquisition) - [ ] Running processes listed (process name, PID, parent PID, path, hash) - [ ] Active network connections recorded (netstat, ss, or EDR telemetry) - [ ] Logged-in users and active sessions recorded - [ ] Routing table and ARP cache captured - [ ] Scheduled tasks and cron jobs listed - [ ] Open files and handles documented - [ ] System uptime and last boot time recorded - [ ] Clipboard contents captured (if relevant) - [ ] All volatile evidence hashed (SHA-256) ### Non-Volatile Evidence - [ ] Disk image created (forensic image, not clone, unless authorised) - [ ] Disk image hashed and hash recorded (SHA-256) - [ ] Relevant log files exported from SIEM - [ ] Firewall logs for affected hosts exported - [ ] DNS logs for affected hosts exported - [ ] Email logs and message trace exported (if email-related) - [ ] EDR telemetry exported for affected hosts and timeframe - [ ] Cloud audit logs exported (if cloud services involved) - [ ] Relevant PCAP files captured or exported from NDR - [ ] Configuration files backed up from affected systems - [ ] All non-volatile evidence hashed (SHA-256) ### Documentation - [ ] Evidence log updated with all items collected - [ ] Chain of custody form completed for each evidence item - [ ] Storage location recorded and access restricted - [ ] Investigation timeline updated - [ ] All analyst actions documented with timestamps ### Evidence Integrity - [ ] All evidence hashes verified after transfer/copy - [ ] Evidence stored in with access controls - [ ] Evidence retention period set per - [ ] Backup of evidence created and stored separately --- **Document End** *This document is the intellectual property of VantagePoint Networks. Unauthorised reproduction or distribution is prohibited.* *VantagePoint Networks -- Professional Network Security Solutions*