Sergio Albea
@Sergio_AlbeaTrusted contributorCompletionist
15 followers230 downloads2,155 copies99 likes17,300 views
73 detections
Filters
Last updated
All Time
Detection languages
73
Categories
11
11
9
8
7
Platforms
39
18
8
8
7
Products / Services
32
18
5
4
3
MITRE Techniques
14
12
11
10
9
CVEs
1
1
1
1
During my vacation, I've been enjoying conversations with people from different countries about their national teams and the World Cup. What I don't expect (although it certainly can happen) is a Mexican speaking Japanese, a Spaniard speaking Russian, or an Egyptian speaking Spanish. Yet, this is becoming more and more common, and I love it. Our world is becoming increasingly connected and multicultural.
However, the same logic doesn't always apply to emails.
That thought inspired me to build a KQL query that I'll explore further after my break, but I wanted to share it now. The idea is detect emails where the language doesn't match the expected language(s) of the sender's country. While this isn't a detection by itself, it can be a valuable hunting signal when combined with other indicators.
KQL Query Filter options:
EmailCount < X → Filter based on the number of emails observed.
Country !in ("Spain") → Exclude countries with a higher false-positive ratio.
SenderDomains !in ("Domain1","Domain2") → Exclude trusted sender domains.
However, the same logic doesn't always apply to emails.
That thought inspired me to build a KQL query that I'll explore further after my break, but I wanted to share it now. The idea is detect emails where the language doesn't match the expected language(s) of the sender's country. While this isn't a detection by itself, it can be a valuable hunting signal when combined with other indicators.
KQL Query Filter options:
EmailCount < X → Filter based on the number of emails observed.
Country !in ("Spain") → Exclude countries with a higher false-positive ratio.
SenderDomains !in ("Domain1","Domain2") → Exclude trusted sender domains.
The aim of this query is detect SSH connections attempts where the external sources are specifying babeld (Network Protocol) or Conker (Network Conf. Manager) as parameters to establish a connection, is detect suspicious activity such as:
Unauthorized SSH connections.
Malicious use of SSH for lateral movement within a network.
Exfiltration attempts via SSH tunneling.
Unauthorized SSH connections.
Malicious use of SSH for lateral movement within a network.
Exfiltration attempts via SSH tunneling.
This query helps to identify service creation events regardless of the tool/method used for service creation (even if the threat actors use the Windows API directly, without leaving any command line traces).
Shebangs (#!) are native to Unix-like operating systems (macOS and Linux). Standard Windows consoles (Command Prompt and PowerShell) do not natively use them. However, they do work on Windows when using tools such as the Python Launcher, Git Bash, Cygwin, or Unix-like environments such as WSL. In simple terms, a Shebang tells the operating system which interpreter should execute a script. For example: #!/usr/bin/python3
Distinct scripts can not look dangerous based on their extension, but they are still executable files. In environments with macOS, Linux, WSL, Git Bash or Python Launcher, this can help to identify scripts renamed to hide their real purpose.
Distinct scripts can not look dangerous based on their extension, but they are still executable files. In environments with macOS, Linux, WSL, Git Bash or Python Launcher, this can help to identify scripts renamed to hide their real purpose.
Shebangs (#!) are native to Unix-like operating systems (macOS and Linux). Standard Windows consoles (Command Prompt and PowerShell) do not natively use them. However, they do work on Windows when using tools such as the Python Launcher, Git Bash, Cygwin, or Unix-like environments such as WSL. In simple terms, a Shebang tells the operating system which interpreter should execute a script. For example: #!/usr/bin/python3
For this query, I would recommend performing some threat hunting first and creating a whitelist for known false positives or trusted devices (for example, devices managed by developers). Once the detection is properly tuned, it can be a good way to monitor the download or import of Shebang files on suspicious directories, making it a strong candidate for a threat detection rule.
For this query, I would recommend performing some threat hunting first and creating a whitelist for known false positives or trusted devices (for example, devices managed by developers). Once the detection is properly tuned, it can be a good way to monitor the download or import of Shebang files on suspicious directories, making it a strong candidate for a threat detection rule.
Shebangs (#!) are native to Unix-like operating systems (macOS and Linux). Standard Windows consoles (Command Prompt and PowerShell) do not natively use them. However, they do work on Windows when using tools such as the Python Launcher, Git Bash, Cygwin, or Unix-like environments such as WSL. In simple terms, a Shebang tells the operating system which interpreter should execute a script. For example: #!/usr/bin/python3
The first thing that came to my mind was to hunt for cases where these kinds of files were received via email, and yes, I quickly found a few Python and ECM-related examples.
The first thing that came to my mind was to hunt for cases where these kinds of files were received via email, and yes, I quickly found a few Python and ECM-related examples.
This query is oriented to identify IOCs observed into different Security websites and reports with the aim to identify quickly possible attacks reported from different sources. The TI Feed used, is based on a Claude AI Agent running daily collecting the mentioned indicators from the different sources. Additional Info --> https://www.linkedin.com/pulse/use-ai-agents-enrich-generate-ti-feeds-based-security-sergio-albea-bxzze
Creating multiple detections without reviewing them over time to ensure they’re still effective can easily turn them into pure noise, adding nothing but fatigue to our day-to-day incident analysis.
The DOVE Model (Detection Overlap & Value Evaluation) evaluates detections across four main dimensions (https://zenodo.org/records/20011459):
1. Detection Type
IOC-based detections tend to have a shorter lifecycle, current TI sources are collecting a huge number of indicators based on new attack or threats which present a higher duplication risk.
IOA-based detections focus on behaviors, have a longer lifecycle, provide higher unique value and requires extended time to create corresponding detection.
2. System / Technology Coverage
Mainstream technologies (e.g., Windows, M365, macOS) are heavily monitored and widely covered by SIEM platforms, increasing duplication probability.
Non-mainstream or custom systems offer less coverage and therefore provide opportunities for more unique detections.
3. Threat Recency
Older or well-known threats are widely documented and likely already covered by existing detections.
New or emerging threats are less likely to be covered, reducing duplication risk and increasing detection value.
4. Source / Provider
Built-in or native detections are already integrated into SIEM platforms and often overlap with custom logic.
Custom or third-party detections introduce tailored logic and reduce overlap probability.
The following KQL query can evaluate how useful are our current detections with the aim to detect alerts that are showing the same assets within the same hour, which indicates potential overlap.
Custom detections added in current SIEM or XDR solutions can easily turn from useful detections into noise, so analyzing their results is crucial.
The DOVE Model (Detection Overlap & Value Evaluation) evaluates detections across four main dimensions (https://zenodo.org/records/20011459):
1. Detection Type
IOC-based detections tend to have a shorter lifecycle, current TI sources are collecting a huge number of indicators based on new attack or threats which present a higher duplication risk.
IOA-based detections focus on behaviors, have a longer lifecycle, provide higher unique value and requires extended time to create corresponding detection.
2. System / Technology Coverage
Mainstream technologies (e.g., Windows, M365, macOS) are heavily monitored and widely covered by SIEM platforms, increasing duplication probability.
Non-mainstream or custom systems offer less coverage and therefore provide opportunities for more unique detections.
3. Threat Recency
Older or well-known threats are widely documented and likely already covered by existing detections.
New or emerging threats are less likely to be covered, reducing duplication risk and increasing detection value.
4. Source / Provider
Built-in or native detections are already integrated into SIEM platforms and often overlap with custom logic.
Custom or third-party detections introduce tailored logic and reduce overlap probability.
The following KQL query can evaluate how useful are our current detections with the aim to detect alerts that are showing the same assets within the same hour, which indicates potential overlap.
Custom detections added in current SIEM or XDR solutions can easily turn from useful detections into noise, so analyzing their results is crucial.
If you are in a country where there is more than one local language, like me in Switzerland, it is challenging to create detections based on subjects because you can have them in multiple languages. Therefore, focusing on the value odspnotify inside of InternetMessageId - which does not change based on the language - helps to detect cases.
This one is related to OneTimePassCode and is useful to identify if the code is sent to other domains, which could mean that a forwarding rule has been configured or some other suspicious activity.
This one is related to OneTimePassCode and is useful to identify if the code is sent to other domains, which could mean that a forwarding rule has been configured or some other suspicious activity.
The are some cases where InternetMessageIds contain a date integrated, sometimes encoded, sometimes not. Therefore, we have two timestamps to compare:
- InternetMessageId date → usually when the sending system generated the message.
- Timestamp (EmailEvents) → when Microsoft received/processed the email.
So if we compare “when it was created” vs “when it arrived”, we can detect cases such as emails created by the system but, due to local configuration, email campaigns that deliver slowly, or messages that were postponed compared to when they were received by Microsoft.
The ratio of true positive was really high and multiple emails were not detected as a Threat so good case to add as a detection.
- InternetMessageId date → usually when the sending system generated the message.
- Timestamp (EmailEvents) → when Microsoft received/processed the email.
So if we compare “when it was created” vs “when it arrived”, we can detect cases such as emails created by the system but, due to local configuration, email campaigns that deliver slowly, or messages that were postponed compared to when they were received by Microsoft.
The ratio of true positive was really high and multiple emails were not detected as a Threat so good case to add as a detection.
Page 2 of 8