LoFP LoFP / network

network rule

TitleTags
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 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 proceses 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 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 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.
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 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.