LoFP LoFP / network

network rule

TitleTags
administrators may intentionally disable or modify logging during maintenance, troubleshooting, or device reconfiguration. these events should be verified against approved change management activities.
bits is a legitimate windows component used by microsoft services such as windows update or microsoft edge for downloading updates. although this analytic filters known microsoft edge update urls, false positives may still occur from other legitimate enterprise applications or software distribution platforms that utilize bits. additional tuning may be required to account for internal application distribution systems or approved update mechanisms that also rely on bits.
blocked connection events are generated via an access control policy on the firewall management console. hence no false positives should be present.
certain ssl certificates may be flagged in threat intelligence feeds due to historical misuse, yet still be used by legitimate services, particularly in content delivery or shared hosting environments. internal or self-signed certificates used in testing or development environments may inadvertently match known blacklisted fingerprints. it is recommended to validate the connection context (destination ip, domain, clientapplication) and correlate with other indicators before taking action.
developers, administrators, or automation tools may use `curl` or `wget` for legitimate purposes such as software installation, configuration scripts, or ci/cd tasks. security tools or health monitoring scripts may also use these utilities to check service availability or download updates. review the destination `url`, frequency, and process context to validate whether the download activity is authorized.
downloading rar or powershell files from the internet may be expected for certain systems. this rule should be tailored to either exclude systems as sources or destinations in which this behavior is expected.
environments that leverage dns responses over 60k bytes will result in false positives - if this traffic is predictable and expected, it should be filtered out. additionally, this detection rule could be triggered by an authorized vulnerability scan or compromise assessment.
false positives are directly related to their snort rules triggering and the firewall scoring. apply additional filters if the rules are too noisy by disabling them or simply ignoring certain ip ranges that trigger it.
false positives can occur in environments where vulnerability scanners or malware sandboxes are actively generating simulated attacks. additionally, noisy or overly aggressive snort rules may produce bursts of alerts from legitimate applications. review host context before escalating.
false positives may be present based on organization use of saml utilities. filter, or restrict the analytic to citrix devices only.
false positives may be present if the organization works with international businesses. filter as needed.
false positives may be present, filtering may be needed. also, restricting to known web servers running iis or sharefile will change this from hunting to ttp.
false positives may be present, restrict to cisco ios xe devices or perimeter appliances. modify the analytic as needed based on hunting for successful exploitation of cve-2023-20198.
false positives may be present. modify the query as needed to post, or add additional filtering (based on log source).
false positives may occur due to legitimate security testing or research activities.
false positives may occur with certain rare activity. apply additional filters where required.
false positives should be limited as the destination port is specific to active directory web services protocol, however we recommend utilizing this analytic to hunt for non-standard processes querying the adws port. filter by app or dest_ip to ad servers and remove known processes querying adws.
false positives should be limited to as this is strict to active exploitation. reduce noise by filtering to f5 devices with tmui enabled or filter data as needed.
false positives should be minimal here, tuning may be required to exclude known test machines or development hosts.
false positives should be minimal. simultaneous vulnerability scanning across multiple internal hosts might trigger this, as well as some snort rules that are noisy. disable those if necessary or increase the threshold.
false positives should be unlikely.
false positives should be very unlikely.
false positives will be present for accessing the 3cx[.]com website. remove from the lookup as needed.
get requests will be noisy and need to be filtered out or removed from the query based on volume. restrict analytic to known publically facing fortigates, or run analytic as a hunt until properly tuned. it is also possible the user agent may be filtered on report runner or node.js only for the exploit, however, it is unknown at this if other user agents may be used.
if you have front-facing proxies that provide authentication and tls, this rule would need to be tuned to eliminate the source ip address of your reverse-proxy.
in the wild, we have observed three different types of attempts that could potentially trigger false positives if the http status code is not in the query. please check this github gist for the specific uris : https://gist.github.com/patel-bhavin/d10830f3f375a2397233f6a4fe38d5c9 . these could be legitimate requests depending on the context of your organization. therefore, it is recommended to modify the analytic as needed to suit your specific environment.
iot (internet of things) devices and networks may use telnet and can be excluded if desired. some business work-flows may use telnet for administration of older devices. these often have a predictable behavior. telnet activity involving an unusual source or destination may be more suspicious. telnet activity involving a production server that has no known associated telnet work-flow or business requirement is often suspicious.
it is important to note that false positives may occur if the search criteria are expanded beyond the http status code 200. in other words, if the search includes other http status codes, the likelihood of encountering false positives increases. this is due to the fact that http status codes other than 200 may not necessarily indicate a successful exploitation attempt.
it is possible that legitimate remote access software is used within the environment. ensure that the lookup is reviewed and updated with any additional remote access software that is used within the environment. known false positives can be added to the remote_access_software_usage_exception.csv lookup to globally suppress these situations across all remote access content
large outbound transfers may occur due to legitimate activities such as cloud backups, file syncing, os or application updates, or developer build deployments. backup servers, ci/cd pipelines, and enterprise sync tools (e.g., onedrive, dropbox) may exhibit similar patterns. additional validation using user context, scheduled task windows, or endpoint telemetry is recommended to reduce false positives.
legitimate account creation and privilege elevation activities by authorized administrators will generate alerts with this detection. to reduce false positives, consider implementing a baseline of expected administrative activities, including approved administrative usernames, typical times for account management, and authorized administrators who regularly perform these actions. you may also want to create a lookup table of approved administrative accounts and filter out alerts for these accounts. additionally, scheduled maintenance windows should be taken into account when evaluating alerts.
legitimate configuration changes during routine maintenance or device setup may trigger this detection, especially when multiple related changes are made in a single session. network administrators often make several configuration changes in sequence during maintenance windows. to reduce false positives, consider implementing a baseline of expected administrative activities, including approved administrative usernames and scheduled maintenance windows. the detection includes a threshold (count > 2) to filter out isolated configuration changes, but this threshold may need to be adjusted based on your environment's normal activity patterns.
legitimate network interface configuration changes may trigger this detection during routine network maintenance or initial device setup. network administrators often need to create or modify interfaces as part of normal operations. to reduce false positives, consider implementing a baseline of expected administrative activities, including approved administrative usernames, typical times for interface configuration changes, and scheduled maintenance windows. you may also want to create a lookup table of approved interface naming conventions and filter out alerts for standard interface configurations.
legitimate smart install operations (e.g., image/config transfers) can produce larger payloads. baseline typical sizes for your environment and allowlist known management stations when appropriate.
legitimate snmp configuration changes may trigger this detection during routine network maintenance or initial device setup. network administrators often need to configure snmp for monitoring and management purposes. to reduce false positives, consider implementing a baseline of expected administrative activities, including approved administrative usernames, typical times for snmp configuration changes, and scheduled maintenance windows. you may also want to create a lookup table of approved snmp hosts and filter out alerts for these destinations.
legitimate tftp server configurations may be detected by this analytic during authorized backup operations or device maintenance. network administrators sometimes use tftp for legitimate configuration backups, firmware updates, or during troubleshooting. to reduce false positives, consider implementing a baseline of expected administrative activities, including approved administrative usernames and scheduled maintenance windows.
legitimate use of cisco smart install may generate traffic to port 4786 within environments that actively use this feature for switch deployment and management. network administrators might use smart install for legitimate device configuration purposes, especially during network deployment or maintenance windows. to reduce false positives, baseline normal smart install usage patterns in your environment and consider implementing time-based filtering to alert only on unexpected usage outside of scheduled maintenance periods. additionally, consider whitelisting known management stations that legitimately use smart install.
legitimate users and applications may use these domains for benign purposes such as file transfers, collaborative development, or storing public content. developer tools, browser extensions, or open-source software may connect to githubusercontent.com or cdn.discordapp.com as part of normal operation. it is recommended to review the associated process (`eve_process`), user behavior, and frequency of access before classifying the activity as suspicious.
misconfigured applications or automated scripts may generate repeated blocked traffic, particularly if attempting to reach decommissioned or restricted resources. vulnerability scanners or penetration testing tools running in authorized environments may trigger this alert. tuning may be required to exclude known internal tools or scanner ips from detection.
network scanning or testing tools that probe cisco smart install endpoints may trigger similar signatures. validate against maintenance windows or approved security assessments.
planned maintenance, network outages, routing changes, or benign configuration updates may reduce log volume temporarily. validate against change management records and corroborate with device health metrics.
servers that process email traffic may cause false positives and should be excluded from this rule as this is expected behavior.
some applications or scripts may continue to reference old s3 bucket names after they have been decommissioned. these should be investigated and updated to prevent potential security risks.
some benign applications may exhibit behaviors that resemble encrypted threat patterns, especially if they use uncommon encryption libraries or custom protocols. custom-developed or internal tools may trigger high eve confidence scores depending on how they encrypt data. it is recommended to validate the associated process (`eve_process`) and destination context, and correlate with other logs (e.g., endpoint or threat intel) before taking response action.
some intrusion events that are linked to these classifications might be noisy in certain environments. apply a combination of filters for specific snort ids and other indicators.
some legitimate services or custom applications may use non-standard ports for development, remote management, or internal communication. ephemeral ports in test environments may occasionally overlap with ports used in this detection. additional context such as process name, user behavior, or endpoint telemetry should be used to validate suspicious sessions before escalation.
some network security policies allow rdp directly from the internet but usage that is unfamiliar to server or network owners can be unexpected and suspicious. rdp services may be exposed directly to the internet in some networks such as cloud environments. in such cases, only rdp gateways, bastions or jump servers may be expected expose rdp directly to the internet and can be exempted from this rule. rdp may be required by some work-flows such as remote access and support for specialized software products and servers. such work-flows are usually known and not unexpected.
some networks may utilize these protocols but usage that is unfamiliar to local network administrators can be unexpected and suspicious. because this port is in the ephemeral range, this rule may false under certain conditions, such as when an application server with a public ip address replies to a client which has used a udp port in the range by coincidence. this is uncommon but such servers can be excluded.
this analytic is limited to http status 200; adjust as necessary. false positives may occur if the uri path is ip-restricted or externally blocked. it's recommended to review the context of the alerts and adjust the analytic parameters to better fit the specific environment.
this rule could identify benign domains that are formatted similarly to fin7's command and control algorithm. alerts should be investigated by an analyst to assess the validity of the individual observations.
this rule should be tailored to either exclude systems, as sources or destinations, in which this behavior is expected.
this rule should be tailored to exclude systems, either as sources or destinations, in which this behavior is expected.
vnc connections may be made directly to linux cloud server instances but such connections are usually made only by engineers. vnc is less common than ssh or rdp but may be required by some work flows such as remote access and support for specialized software products or servers. such work-flows are usually known and not unexpected. usage that is unfamiliar to server or network owners can be unexpected and suspicious.
vnc connections may be received directly to linux cloud server instances but such connections are usually made only by engineers. vnc is less common than ssh or rdp but may be required by some work-flows such as remote access and support for specialized software products or servers. such work-flows are usually known and not unexpected. usage that is unfamiliar to server or network owners can be unexpected and suspicious.