Thanks, I've tried that but still didn't get the "null" values. I do get an error which says - "The specified span would result in too many (>175000) rows." I get this error a lot during this search but i don't understand why would the null values only be missing? Additionally - does this error necessarily mean that search has failed or stopped at the limit?

As per my investigation the minute that was alerted on, there are "svc_radius_probe_ctx" events occurred. what type of changes I should make to resolve it ? should I increase the time ? or is there anything need to be done from RSA console ? 

Are you saying that you are getting false alerts i.e. when you look back at the minute that was alerted on, there are "svc_radius_probe_ctx" events? If so, this could be that they have not been indexed by the time the alert report is executed, i.e. you have not left enough time between the event happening, and it being sent to Splunk, and it being indexed. There is (nearly) always a lag between the event time (_time) and the index time (_indextime), and your alert report schedule and time period should take this into account.

Hi @KingUs80 , see in the Splunk Security Essentials App (https://splunkbase.splunk.com/app/3435), or, if you already have, in Enterprise Security Premium App. The feature in ES is Threat Intelligence: you must have an internal list of malicious sites of a list downloaded from free or payment services. Other apps that you could use are MISP42 (https://splunkbase.splunk.com/app/4335) or https://splunkbase.splunk.com/apps?keyword=threat+intelligence  Ciao. Giuseppe

I know it's a little bit delayed, but due to the nature of the 0day from February you would need to know which method was being exploited (i.e. which characters the exact attack wanted to utilize). That said, you could write a detection that checks for Outlook.exe (and all versions of it) connecting over port 445. If you have sysmon installed, you could use EventId 3's for this. Florian Roth also wrote a YARA rule that could detect emails that have that malicious Moniker link in it :  rule EXPL_CVE_2024_21413_Microsoft_Outlook_RCE_Feb24 { meta: description = "Detects emails that contain signs of a method to exploit CVE-2024-21413 in Microsoft Outlook" author = "X__Junior, Florian Roth" reference = "https://github.com/xaitax/CVE-2024-21413-Microsoft-Outlook-Remote-Code-Execution-Vulnerability/" date = "2024-02-17" modified = "2024-02-19" score = 75 strings: $a1 = "Subject: " $a2 = "Received: " $xr1 = /file:///\\[^"']{6,600}.(docx|txt|pdf|xlsx|pptx|odt|etc|jpg|png|gif|bmp|tiff|svg|mp4|avi|mov|wmv|flv|mkv|mp3|wav|aac|flac|ogg|wma|exe|msi|bat|cmd|ps1|zip|rar|7z|targz|iso|dll|sys|ini|cfg|reg|html|css|java|py|c|cpp|db|sql|mdb|accdb|sqlite|eml|pst|ost|mbox|htm|php|asp|jsp|xml|ttf|otf|woff|woff2|rtf|chm|hta|js|lnk|vbe|vbs|wsf|xls|xlsm|xltm|xlt|doc|docm|dot|dotm)!/ condition: filesize < 1000KB and all of ($a*) and 1 of ($xr*) } I hope that this late in the game, you have patched all your Outlook installations, and would instead go for detecting if any are unpatched.

Are you asking if Splunk Observability Cloud supports Windows IIS telemetry logging, or if it supports logging for your specific PHP webshop? If the latter, then it would be helpful to know the name of the PHP webshop.

If I understand correctly, you have two different log types ABC and EFG in the same index, and you want to count how many success, fail, and error events occur, but only for correlation IDs that occur in both ABC and EFG? Assuming the field names are correct, your current query should work to count success, fail, and error events from both, though it will count events that only occur in one of the two types. It is not clear how you would like the details (json_ext of message) to be displayed with the count of success, fail, and error events. You could do stats ... by json_ext to see the counts by json_ext, but this would only be practical if the json_ext messages are not very different.

1. The best practice is to define as much as you can from the so-called magic eight. It boosts performance on ingestion and lets you avoid errors with line breaking or timestamp recognition. 2. Sourcetype is just a value of metadata associated with an event. From technical point of view it doesn't have to be "defined" anywhere prior to setting given value as sourcetype. You could even create an index-time transform setting a sourcetype to a completely random value and Splunk would still work and process the events (although the effects might be far from desirable). It's the other way around - the value of the sourcetype metadata can - if configured properly - affect how Splunk processes events. BTW, sourcetype is just one of the metadata fields that comes into play when Splunk decides what to do with an event. Other ones are source and host.