LoFP LoFP / t1133

t1133

TitleTags
administrative activity
developers may have a legitimate use for nodeports. for frontend parts of an application you may want to expose a service onto an external ip address without using cloud specific loadbalancers. nodeport can be used to expose the service on each node's ip at a static port (the nodeport). you'll be able to contact the nodeport service from outside the cluster, by requesting <nodeip>:<nodeport>. nodeport unlike loadbalancers, allow the freedom to set up your own load balancing solution, configure environments that aren't fully supported by kubernetes, or even to expose one or more node's ips directly.
false positives are limited.
false positives are possible and filtering may be required. restrict by assets or filter known jsp files that are common for the environment.
false positives are present when the values are set to 1 for utf and lookup. it's possible to raise this to ttp (direct notable) if removal of other_lookups occur and score is raised to 2 (down from 4).
false positives may be present if the activity is blocked or was not successful. filter known vulnerablity scanners. filter as needed.
false positives may be present, as this is based on the admin user accessing the papercut ng instance from a public ip address. filter as needed.
false positives may be present, but most likely not. filter as needed.
false positives may be present, filter as needed.
false positives may be present. modify the query as needed to post, or add additional filtering (based on log source).
false positives may occur and filtering may be required. restrict analytic to asset type.
false positives will be limited, however tune or modify the query as needed.
false positives will be present based on gateways in use, modify the status field as needed.
filtering may be required on internal developer build systems or classify assets as web facing and restrict the analytic based on that.
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 there is a vulnerablility scannner looking for log4shells this will trigger, otherwise likely to have low false positives.
ipv4-to-ipv6 mapped ips
it is highly possible you will find false positives, however, the base score is set to 2 for _any_ jndi found in raw logs. tune and change as needed, include any filtering.
it's possible for legitimate http requests to be made to urls containing the suspicious paths.
legitimate java applications may use perform outbound connections to these ports. filter as needed
legitimate logon attempts over the internet
legitimate or intentional inbound connections from public ip addresses on the rdp port.
legitimate usage of teamviewer
legitimate use by administrative staff
limited false positives, however, tune as needed.
network acl's may be created by a network administrator. verify whether the user identity, user agent, and/or hostname should be making changes in your environment. network acl creations by unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
similar to cve-2023-35078, the path for exploitation indicates that status=200 is required for successful exploitation of the vulnerability. false positives may be present if status=200 is removed from the search. if it is removed,then the search also alert on status=301 and status=404 which indicates unsuccessful exploitation attempts. analysts may find it useful to hunt for these status codes as well, but it is likely to produce a significant number of alerts as this is a widespread vulnerability.
ssh usage may be legitimate depending on the environment. access patterns and follow-on activity should be analyzed to distinguish between authorized and potentially malicious behavior.
the jsp file names are static names used in current proof of concept code. =
the proof of concept exploit script indicates that status=200 is required for successful exploitation of the vulnerability. false positives may be present if status=200 is removed from the search. if it is removed,then the search also alert on status=301 and status=404 which indicates unsuccessful exploitation attempts. analysts may find it useful to hunt for these status codes as well, but it is likely to produce a significant number of alerts as this is a widespread vulnerability.
the query is structured in a way that `action` (read, create) is not defined. review the results of this query, filter, and tune as necessary. it may be necessary to generate this query specific to your endpoint product.
there are no known false positive for this search, but it could contain false positives as multiple detections can trigger and not have successful exploitation.
there might be false positives associted with this detection since items like args as a web argument is pretty generic.
tune based on assets if possible, or restrict to known confluence servers. remove the ${ for a more broad query. to identify more exec, remove everything up to the last parameter (runtime().exec) for a broad query.
unlikely
valid clusters may be created by a system or network administrator. verify whether the user identity, user agent, and/or hostname should be making changes in your environment. cluster creations by unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.