Detecting Malicious Traffic That Was Allowed Through The Firewall

Firewalls are often viewed as the first line of defense against external threats. Every day, they inspect, filter, and control thousands of connections between internal systems and the internet.

Modern solutions such as Fortinet FortiGate do far more than simply allow or block traffic. They leverage threat intelligence, intrusion prevention signatures, reputation services, and behavioral analysis to identify potentially malicious activity in real time.

When reviewing firewall security events, most attention naturally goes to blocked threats. A blocked exploit attempt or denied connection demonstrates that a security control worked as intended.

However, from a detection engineering perspective, the more interesting question is often:

? “What happened to the threats that were detected but still allowed?”

Business requirements, policy exceptions, temporary firewall rules, misconfigurations, or incomplete threat coverage can sometimes result in suspicious traffic being permitted despite being identified as malicious or high risk.

For defenders, these situations deserve special attention because the firewall recognized something suspicious, yet the communication was still successful.

This detection was developed to identify exactly those scenarios by focusing on malicious or suspicious traffic that was allowed to communicate and remained active long enough to represent a meaningful security risk.

Not all firewall detections carry the same level of risk.

When a threat is identified and blocked, the attack chain is interrupted before meaningful communication can occur.

Allowed malicious traffic is different.

If communication associated with malware, exploit activity, botnet infrastructure, or known malicious indicators is permitted to continue, defenders must assume that the threat may have successfully interacted with the environment.

• Examples of High-Risk Allowed Traffic
  • Communication with known malicious infrastructure
  • Successful exploitation attempts
  • Botnet command-and-control activity
  • Malware beaconing
  • Data exfiltration channels
  • Threat intelligence indicator matches
  • Persistent sessions involving suspicious destinations
  • Critical severity threats that bypassed blocking controls

A blocked event typically indicates that a security control worked as intended.

An allowed event may indicate that a threat successfully communicated through the environment and therefore warrants immediate investigation.

The goal of this detection is not to alert on every suspicious firewall event.

Instead, it focuses on identifying the subset of events most likely to represent meaningful attacker activity.

To achieve this, the rule applies several layers of filtering and correlation.

Detection Workflow

• Reviews recent Fortinet FortiGate logs from CommonSecurityLog.
• Identifies traffic that was explicitly allowed by the firewall.
• Searches for malicious indicators, threat classifications, and high-severity events.
• Correlates activity with Microsoft Threat Intelligence indicators.
• Evaluates whether the communication persisted for more than ten minutes.
• Suppresses previously alerted indicators to reduce duplicate incidents.
• Generates alerts for four high-confidence threat scenarios.

This approach helps reduce noise while prioritizing activity that may represent genuine compromise.

let dt_lookBack = 1h;

let ioc_lookBack = 14d;

let ManagedAttempts =
    SigninLogs
    | where TimeGenerated > ago(14d)
    | union AADNonInteractiveUserSignInLogs
    | where isnotempty(DeviceDetail_dynamic.deviceId) or isnotempty(parse_json(DeviceDetail_string).deviceId)
    | distinct IPAddress;

let IP_Indicators =
    ThreatIntelIndicators
    | where TimeGenerated > ago(ioc_lookBack)
    | distinct TIEntity = ObservableValue
    | where isnotempty(TIEntity)
    | where ipv4_is_private(TIEntity) == false
        and TIEntity !startswith "fe80"
        and TIEntity !startswith "::"
        and TIEntity !startswith "127.";

//
// Case 1 - High Severity Inbound/Outbound Allowed Security Exploit
//
let HighSeverity_PreviouslyAlertedIPs =
    CommonSecurityLog
    | where TimeGenerated between (ago(14d) .. ago(1h))
    | where DeviceVendor contains "Fortinet"
    | where DeviceProduct contains "Fortigate"
    | where DeviceAction contains "accept"
    | where Activity contains "forward accept"
    | where isnotempty(IndicatorThreatType)
    | extend AcceptTime = TimeGenerated
    | join kind=leftouter (
        CommonSecurityLog
        | where DeviceAction !contains "accept"
        | extend CloseTime = TimeGenerated
    ) on MaliciousIP
    | where isnull(CloseTime) or CloseTime > AcceptTime
    | summarize arg_min(CloseTime, *) by MaliciousIP
    | where (CloseTime >= AcceptTime + 10m) or isnull(CloseTime)
    | distinct MaliciousIP;

let HighSeverity =
    CommonSecurityLog
    | where TimeGenerated > ago(1h)
    | where DeviceVendor contains "Fortinet"
    | where DeviceProduct contains "Fortigate"
    | where DeviceAction contains "accept"
    | where Activity contains "forward accept"
    | where isnotempty(IndicatorThreatType)
    | extend AcceptTime = TimeGenerated
    | join kind=leftouter (
        CommonSecurityLog
        | where DeviceAction !contains "accept"
        | extend CloseTime = TimeGenerated
    ) on MaliciousIP
    | where isnull(CloseTime) or CloseTime > AcceptTime
    | summarize arg_min(CloseTime, *) by MaliciousIP
    | where (CloseTime >= AcceptTime + 10m) or isnull(CloseTime)
    | where SourceIP != "10.100.1.200"
    | where DestinationIP != "10.100.1.200"
    | join kind=leftanti HighSeverity_PreviouslyAlertedIPs on MaliciousIP
    | extend AlertCase = "Fortinet - High Severity Inbound/Outbound Allowed Security Exploit"
    | extend CS_ipEntity = MaliciousIP;

//
// Case 2 - Botnet Identified and Allowed
//
let Botnet_PreviouslyAlertedIPs =
    CommonSecurityLog
    | where TimeGenerated between (ago(14d) .. ago(1h))
    | where DeviceVendor contains "Fortinet"
    | where DeviceProduct contains "Fortigate"
    | where DeviceAction contains "accept"
    | where Activity contains "forward accept"
    | where IndicatorThreatType has "Botnet"
    | extend AcceptTime = TimeGenerated
    | join kind=leftouter (
        CommonSecurityLog
        | where DeviceAction !contains "accept"
        | extend CloseTime = TimeGenerated
    ) on MaliciousIP
    | where isnull(CloseTime) or CloseTime > AcceptTime
    | summarize arg_min(CloseTime, *) by MaliciousIP
    | where (CloseTime >= AcceptTime + 10m) or isnull(CloseTime)
    | distinct MaliciousIP;

let Botnet =
    CommonSecurityLog
    | where TimeGenerated > ago(1h)
    | where DeviceVendor contains "Fortinet"
    | where DeviceProduct contains "Fortigate"
    | where DeviceAction contains "accept"
    | where Activity contains "forward accept"
    | where IndicatorThreatType has "Botnet"
    | extend AcceptTime = TimeGenerated
    | join kind=leftouter (
        CommonSecurityLog
        | where DeviceAction !contains "accept"
        | extend CloseTime = TimeGenerated
    ) on MaliciousIP
    | where isnull(CloseTime) or CloseTime > AcceptTime
    | summarize arg_min(CloseTime, *) by MaliciousIP
    | where (CloseTime >= AcceptTime + 10m) or isnull(CloseTime)
    | join kind=leftanti Botnet_PreviouslyAlertedIPs on MaliciousIP
    | extend AlertCase = "Fortinet - Botnet Identified and Allowed"
    | extend CS_ipEntity = MaliciousIP;

//
// Case 3 - Critical Severity Threat Was Allowed
//
let CriticalThreat_PreviouslyAlertedIPs =
    CommonSecurityLog
    | where TimeGenerated between (ago(14d) .. ago(1h))
    | where DeviceVendor contains "Fortinet"
    | where DeviceProduct contains "Fortigate"
    | where DeviceAction contains "accept"
    | where Activity contains "forward accept"
    | where ThreatSeverity >= 5
    | extend AcceptTime = TimeGenerated
    | summarize arg_min(AcceptTime, *) by SourceIP
    | distinct SourceIP;

let CriticalThreat =
    CommonSecurityLog
    | where TimeGenerated > ago(1h)
    | where DeviceVendor contains "Fortinet"
    | where DeviceProduct contains "Fortigate"
    | where DeviceAction contains "accept"
    | where Activity contains "forward accept"
    | where ThreatSeverity >= 5
    | where isnotempty(IndicatorThreatType)
    | extend AcceptTime = TimeGenerated
    | join kind=leftouter (
        CommonSecurityLog
        | where DeviceAction !contains "accept"
        | extend CloseTime = TimeGenerated
    ) on SourceIP
    | where isnull(CloseTime) or CloseTime > AcceptTime
    | summarize arg_min(CloseTime, *) by SourceIP
    | where (CloseTime >= AcceptTime + 10m) or isnull(CloseTime)
    | join kind=leftanti  CriticalThreat_PreviouslyAlertedIPs on SourceIP
    | extend AlertCase = "Fortinet - Critical Severity Threat Was Allowed"
    | extend CS_ipEntity = SourceIP;

//
// Case 4 - TI Map IP Entity
//
let TIMapIP =
    IP_Indicators
    | join kind=innerunique (
        CommonSecurityLog
        | where TimeGenerated >= ago(dt_lookBack)
        | extend CS_ipEntity = iff(isnotempty(SourceIP), SourceIP, DestinationIP)
        | join kind=leftanti ManagedAttempts on $left.CS_ipEntity == $right.IPAddress
        | where DeviceAction contains "accept"
        | where Activity contains "forward accept"
        | extend AcceptTime = TimeGenerated
    ) on $left.TIEntity == $right.CS_ipEntity
    | join kind=leftouter (
        CommonSecurityLog
        | where TimeGenerated >= ago(dt_lookBack)
        | where DeviceAction !contains "accept" or Activity !contains "accept"
        | extend CS_ipEntity = iff(isnotempty(SourceIP), SourceIP, DestinationIP)
        | join kind=inner IP_Indicators on $left.CS_ipEntity == $right.TIEntity
        | extend CloseTime = TimeGenerated
    ) on TIEntity
    | where isnotnull(CloseTime)
    | where CloseTime > AcceptTime
    | summarize arg_min(CloseTime, *) by TIEntity
    | where not((CloseTime > AcceptTime) and (CloseTime < AcceptTime + 10m))
    | extend AlertCase = "TI Map IP Entity"
    | extend CS_ipEntity = TIEntity;

// Final Output
//
union HighSeverity, Botnet, TIMapIP, CriticalThreat
| extend
    PolicyName = extract(@"FTNTFGTpolicyname=([^;]+)", 1, AdditionalExtensions),
    PolicyID = extract(@"FTNTFGTpolicyid=([^;]+)", 1, AdditionalExtensions)
| summarize arg_min(AcceptTime,*) by CS_ipEntity
| project
    AcceptTime,
    AlertCase,
    Computer,
    DeviceProduct,
    PolicyName,
    PolicyID,
    MaliciousIP = CS_ipEntity,
    MaliciousIPCountry,
    DeviceAction,
    DestinationIP,
    DestinationTranslatedAddress,
    ApplicationProtocol,
    DestinationPort

Rather than relying on a single condition, the detection evaluates multiple scenarios that may indicate malicious communications were successfully established through the firewall

Each scenario focuses on a different aspect of suspicious activity while sharing a common objective: “Identifying threats that were detected but not blocked.”

Threat Intelligence Preparation

Before evaluating suspicious communications, the rule prepares two important datasets.

• Threat Intelligence Indicators
  • The rule builds a list of known malicious IP addresses using Microsoft Threat Intelligence data.
  • Only public IP addresses are retained. Private ranges, loopback addresses, and local network ranges are excluded because they are not relevant for external threat intelligence correlation.
• Managed Sign-In Activity
  • The rule also builds a list of managed authentication IP addresses observed through Azure AD sign-in activity.
    These addresses are later excluded to reduce false positives generated by legitimate authentication traffic.
• Why This Matters
  • Preparing these datasets improves detection accuracy and allows later stages of the rule to focus on truly suspicious communications.

High-Severity Exploit Activity

• What This Detects
  • This logic identifies exploit-related activity where:
    • FortiGate classified the traffic as malicious or suspicious
    • The firewall action was Accept
    • A threat category was assigned
    • The communication remained active for more than ten minutes
  • To reduce duplicate incidents, the detection also verifies whether the same malicious IP address has generated an alert within the previous fourteen days.
• Why This Matters
  • Exploit-related communications that are detected but not blocked may indicate successful attacker interaction with a vulnerable system. Long-lived sessions increase the likelihood that the activity represents more than a simple connection attempt.

Botnet Communication

• What This Detects
  • This logic focuses on traffic classified by FortiGate as Botnet activity.
  • The detection identifies:
    • Allowed traffic
    • Botnet-related threat classifications
    • Communications that remained active for more than ten minutes
  • Previously alerted botnet IP addresses are suppressed to minimize duplicate alerts.
• Why This Matters
  • Botnet traffic is often associated with:
    • Malware infections
    • Command-and-control communications
    • Attacker-controlled infrastructure
    • Automated malicious activity
  • Persistent communication with botnet infrastructure may indicate that a system is already compromised and actively communicating with external infrastructure.

Critical Severity Threats

• What This Detects
  • This logic focuses on the highest-severity threats identified by FortiGate.
  • The detection identifies:
    • ThreatSeverity greater than or equal to 5
    • Allowed traffic
    • Associated threat indicators
    • Communications that remained active
• Why This Matters
  • A critical severity rating indicates that FortiGate assessed the activity as highly suspicious or potentially malicious. If such traffic is allowed through the firewall, the event should be treated as a high-priority investigation.

Why the Rule Uses a Ten-Minute Persistence Requirement

A key design feature of this detection is the persistence check

Not every suspicious connection represents meaningful attacker activity. Enterprise environments generate a large volume of short-lived network events that may include:

• Failed connection attempts
• Automated scanning activity
• Short-lived probes
• Sessions immediately terminated by security controls

To improve detection quality, the rule evaluates whether communication remained active for at least ten minutes after it was first observed.

Why Persistence Matters

Long-lived communications are more likely to indicate:

• Successful attacker interaction
• Malware beaconing
• Command-and-control activity
• Data transfer operations
• Ongoing exploitation attempts

By focusing on persistent communications, the detection increases confidence while reducing alert fatigue.

Investigation Guidance

When reviewing alerts generated by this rule, analysts should examine:

• Source IP address
• Destination IP address
• Threat category
• Policy name and Policy ID
• Application protocol
• Destination port
• Device action
• Country information
• Associated firewall policies

Additional investigation should determine:

• Whether the communication was expected
• Whether the destination is known malicious infrastructure
• Whether the source host shows signs of compromise
• Whether similar activity exists for other devices or users

Example 1: Allowed Security Exploit

• A FortiGate device identifies traffic associated with a known exploit attempt.
• The firewall allows the communication due to an existing policy exception.
• The session remains active for more than ten minutes.
• This may indicate a successful exploitation attempt or active attacker communication.

Example 2: Botnet Communication

• An internal workstation communicates with an external IP categorized as Botnet infrastructure.
• The firewall permits the connection and the communication persists.
• This may indicate malware infection or command-and-control activity.

Example 3: Threat Intelligence Match

• An internal device establishes communication with an IP address present in Microsoft Threat Intelligence feeds.
• The session remains active and was not blocked.
• This may indicate contact with known malicious infrastructure and should be investigated immediately.

When this detection triggers, recommended actions include:

1. Validate the malicious IP reputation.
2. Review the associated Fortinet policy that allowed the communication.
3. Determine whether the communication was expected or authorized.
4. Review endpoint activity on the affected system.
5. Investigate related network connections.
6. Search for additional communications involving the same IP address.
7. Review threat intelligence associated with the indicator.
8. Examine firewall logs before and after the event.
9. Isolate affected systems if malicious activity is confirmed.
10. Update firewall policies if inappropriate allowances are identified.

Many security controls focus on detecting attacks that were blocked.

However, from a defender’s perspective, the most important events are often the threats that successfully communicate despite being identified as suspicious.

This detection helps identify situations where:

1. Known malicious traffic was allowed
2. Botnet communications succeeded
3. Critical severity threats remained active
4. Threat intelligence indicators communicated through the environment

By focusing on allowed and persistent malicious traffic, the rule helps analysts prioritize activity that may represent genuine compromise rather than unsuccessful attack attempts.

Wizard Cyber develops behavioral and threat-informed detections designed to identify malicious activity across cloud, endpoint, identity, and network environments.

Our detection engineering capabilities include:

• Firewall and network security monitoring
• Threat intelligence correlation
• Botnet and command-and-control detection
• Exploitation activity monitoring
• High-fidelity Microsoft Sentinel analytics
• Custom behavioral detections for Microsoft Defender XDR
• Advanced threat hunting and detection tuning

Our approach focuses on identifying attacker behavior and successful threat activity rather than relying solely on blocked events, static indicators, or signature-based detections, helping organizations detect meaningful security incidents before they escalate into larger compromises