LoFP LoFP / t1210

t1210

TitleTags
3rd party apache modules - https://bz.apache.org/bugzilla/show_bug.cgi?id=46185
bad connections or network interruptions
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.
exploits that were attempted but unsuccessful.
false positives will be present based on gateways in use, modify the status field as needed.
false positives will most likely be present based on risk scoring and how the organization handles system to system communication. filter, or modify as needed. in addition to count by analytics, adding a risk score may be useful. in our testing, with 22 events over 30 days, the risk scores ranged from 500 to 80,000. your organization will be different, monitor and modify as needed.
files generated during installation will generate a lot of noise, so the rule should only be enabled after the fact.
legitimate processes may be spawned from the microsoft exchange server unified messaging (um) service. if known processes are causing false positives, they can be exempted from the rule.
none thus far found
not all exports and downloads are malicious, special attention must be put as well on /en-us/splunkd/__raw/services/pdfgen/render in the context of this search.
scanning attempts with the abnormal use of the http post method with no indication of code execution within the http client (request) body. an example would be vulnerability scanners trying to identify unpatched versions while not actually exploiting the vulnerability. see description for investigation tips.
this detection does not require you to ingest any new data. the detection does require the ability to search the _internal index. focus of this search is \"uri_path=/servicesns/nobody/splunk_secure_gateway/storage/collections/data/mobile_alerts*\" which is the injection point.
this rule was tuned using the following baseline: https://raw.githubusercontent.com/microsoft/css-exchange/main/security/baselines/baseline_15.2.792.5.csv from microsoft. depending on version, consult https://github.com/microsoft/css-exchange/tree/main/security/baselines to help determine normalcy.
this search will provide information for investigation and hunting of lookup creation via user-supplied xslt which may be indications of possible exploitation. there will be false positives as it is not possible to detect the payload executed via this exploit.
this search will provide information for investigation and hunting possible abuse of user-supplied xslt. there may be false positives and results should individually evaluated. please evaluate the source ip and useragent responsible for creating the requests.
unlikely
werfault.exe will legitimately spawn when dns.exe crashes, but the dns service is very stable and so this is a low occurring event. denial of service (dos) attempts by intentionally crashing the service will also cause werfault.exe to spawn.