LoFP LoFP / network

network rule

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