Threat Hunting Exercise: Analyzing Firewall Unauthorized Rule Change Audit Anomaly Dataset

This hunt uses a simulated firewall management-plane dataset (firewall_rule_change_2022-08-26T033000.json) capturing T1562.004: Impair Defenses (Disable or Modify System Firewall), where an attacker with stolen administrative credentials adds a permissive outbound "allow" rule to the perimeter firewall, opening a direct path for later data exfiltration or C2 that bypasses existing network controls.

Step 1: Hypothesis Formation

Hypothesis: A new firewall rule is created outside of a documented change window, granting broad outbound access (e.g., any-any on a non-standard port, or a rule scoped narrowly to a single internal host and single external IP) that does not correspond to any change-management ticket, and the rule is created by an administrative account at an unusual hour or from an unusual management-console source IP. Indicators:

• Firewall management API/console log shows a rule creation/modification event outside the standard change window (e.g., business hours, defined maintenance windows).
• The new rule is unusually permissive (wide port range, "any" destination, or a specific external IP with no documented business justification).
• The administrative account used has no corresponding change ticket, or the source IP/session used to make the change differs from that account's normal management access pattern.
• Traffic matching the new rule begins flowing within minutes of its creation.

Null Hypothesis: A network engineer made an emergency/out-of-band change under a valid incident or urgent business need, with after-the-fact documentation to follow. Invalidate by checking for a retroactive change ticket or engineer confirmation within a reasonable window, and confirming the source IP/session matches the engineer's normal access pattern.

Rationale: A single permissive firewall rule change can silently undo months of careful network segmentation, and because it's a management-plane action rather than a network-traffic anomaly, it's invisible to traffic-based detection until it's actually used; this hunt validates firewall change-log auditing against the change-management system as a control that catches the backdoor at the moment of creation, before any traffic even flows.

Step 2: Data Sources and Scope

• Sources: Firewall management/API audit log (rule create/modify/delete events with admin identity); Change-management (ServiceNow/Jira) ticket system; VPN/bastion authentication logs for the administrative session.
• Scope: ~2022-08-26T03:30:00-03:32:00 UTC; Firewall: FW-PERIM-01; Admin account: admin.jsmith; Change window policy: Tue/Thu 14:00-16:00 UTC only.
• SIEM Queries (Splunk/ELK):
• index=firewall_mgmt action IN (create,modify) object_type=rule | eval hour=strftime(_time,"%H") | where hour<6 OR hour>20
• Cross-check CM: index=firewall_mgmt action=create object_type=rule | join ticket_id [search index=snow_tickets status=approved] (unmatched results = unauthorized)
• index=vpn_auth user="admin.jsmith" | table _time src_ip session_id (compare against baseline access pattern)

Step 3: Key Findings

Parsed events (5 shown) confirm a broad outbound-allow rule was created at 03:30 UTC - well outside the approved Tue/Thu 14:00-16:00 change window - by an admin account authenticating from an unrecognized VPN session, with matching traffic beginning within 8 minutes.

Validation:

• Timeline: unrecognized admin session, out-of-window rule creation, and immediate utilization of the new path all within 8 minutes - a deliberate, purpose-built backdoor rule, not an emergency engineering change.
• False Positives: no change ticket exists for this modification; the admin session source IP is inconsistent with the account's established access pattern; the change falls on a day and time with no scheduled maintenance window at all.
• Correlation: credential/session anomaly, unauthorized timing, absent change record, and immediate traffic utilization together confirm a malicious firewall rule change, not legitimate emergency administration.

Step 4: Recommendations & Next Steps

• Immediate Response: Remove the unauthorized rule immediately; disable admin.jsmith's credentials pending investigation and force a password/MFA token reset; isolate 10.310.2.44 and investigate what traffic it sent to 91.219.237.50 during the 8-minute active window; review all other rules created/modified by this account historically.
• Detection: Sigma-style rule: title: Firewall Rule Created Outside Approved Change Window → selection: firewall_action IN (create,modify) AND object_type=rule AND NOT within_approved_window AND NOT matched_to_approved_ticket.
• Pro Tip: Require firewall management-plane changes to be tied programmatically to an approved change ticket ID at the API level (not just as a manual process) - this converts "no matching ticket" from a manual audit finding into an automatic, real-time block-or-alert control at the moment of the change.

Hypothesis confirmed - an attacker using compromised administrative credentials created an unauthorized, overly permissive outbound firewall rule outside the approved change window, and began using it for outbound traffic within 8 minutes!