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
With a reported CVSS score of 9.2 and security updates scheduled for today, October 21, these vulnerabilities deserve attention, especially if you're still running legacy PHP versions.
𝗪𝗵𝗶𝗹𝗲 𝘄𝗮𝗶𝘁𝗶𝗻𝗴 𝗳𝗼𝗿 𝘁𝗵𝗲 𝗼𝗳𝗳𝗶𝗰𝗶𝗮𝗹 𝗽𝗮𝘁𝗰𝗵𝗲𝘀 𝗮𝗻𝗱 𝘁𝗲𝗰𝗵𝗻𝗶𝗰𝗮𝗹 𝗱𝗲𝘁𝗮𝗶𝗹𝘀, 𝘂𝗽𝗱𝗮𝘁𝗲 𝗮𝗹𝗹 𝗣𝗛𝗣 𝗩𝗲𝗿𝘀𝗶𝗼𝗻𝘀 𝘁𝗼 𝗮𝘁 𝗹𝗲𝗮𝘀𝘁 𝟴.𝟮 𝘁𝗼 𝗯𝗲 𝗮𝗯𝗹𝗲 𝘁𝗼 𝗵𝗮𝘃𝗲 𝘁𝗵𝗲 𝘀𝗲𝗰𝘂𝗿𝗶𝘁𝘆 𝘂𝗽𝗱𝗮𝘁𝗲𝘀. I decided to spend some time exploring what we can already hunt for using Microsoft Defender XDR and KQL. I've put together a short technical article covering six hunting scenarios:
- PHP installations and outdated versions
- Suspicious child processes and command execution
- Reconnaissance activity
- Unexpected PHP file creation
- Unusual outbound network connections
- New process relationships compared to historical activity
These are not PHP2Shell-specific detections, but they can help identify suspicious activity on PHP servers without relying on published IoCs.
Sharing the queries in case they're useful for your own investigations.
𝗪𝗵𝗶𝗹𝗲 𝘄𝗮𝗶𝘁𝗶𝗻𝗴 𝗳𝗼𝗿 𝘁𝗵𝗲 𝗼𝗳𝗳𝗶𝗰𝗶𝗮𝗹 𝗽𝗮𝘁𝗰𝗵𝗲𝘀 𝗮𝗻𝗱 𝘁𝗲𝗰𝗵𝗻𝗶𝗰𝗮𝗹 𝗱𝗲𝘁𝗮𝗶𝗹𝘀, 𝘂𝗽𝗱𝗮𝘁𝗲 𝗮𝗹𝗹 𝗣𝗛𝗣 𝗩𝗲𝗿𝘀𝗶𝗼𝗻𝘀 𝘁𝗼 𝗮𝘁 𝗹𝗲𝗮𝘀𝘁 𝟴.𝟮 𝘁𝗼 𝗯𝗲 𝗮𝗯𝗹𝗲 𝘁𝗼 𝗵𝗮𝘃𝗲 𝘁𝗵𝗲 𝘀𝗲𝗰𝘂𝗿𝗶𝘁𝘆 𝘂𝗽𝗱𝗮𝘁𝗲𝘀. I decided to spend some time exploring what we can already hunt for using Microsoft Defender XDR and KQL. I've put together a short technical article covering six hunting scenarios:
- PHP installations and outdated versions
- Suspicious child processes and command execution
- Reconnaissance activity
- Unexpected PHP file creation
- Unusual outbound network connections
- New process relationships compared to historical activity
These are not PHP2Shell-specific detections, but they can help identify suspicious activity on PHP servers without relying on published IoCs.
Sharing the queries in case they're useful for your own investigations.
Further than have the PHP software updated with the supported versions and take actions over the Exposed Devices,having the latest PHP version installed doesn't mean your web applications are actually using it. I would recommend a double check over IIS, Apache or other process that could be executing old PHP Versions even if the server has installed the newest ones, see example : https://lnkd.in/esrKn-FK
Another small hunting idea using CallActivityEvents Table. The query extracts the Top-Level Domain (TLD) from the person performing the action in a Microsoft Teams call and enriches it with an external country list. In this example, I exclude .CH to quickly surface activity where the originator is using a domain associated with another country. A different hunting angle to spot unexpected external participants, unusual call activity, or simply identify interactions that deserve a closer look. Of course, a foreign TLD is not malicious by itself — it is just another piece of context for the hunter. 🔎
For years, when hunting phishing emails, I have mainly focused on what the user sees inside of it. But I think AI agents are going to change this.
An email may soon have two audiences: Human + AI Agent. And they may not always see exactly the same thing.
In this new KQL, I explore a simple example: invisible Unicode characters. Microsoft and Micro<U+200B>soft may look the same to us, but not necessarily to a detection, filter, parser or AI agent. For attackers, this difference can be interesting as a way to obfuscate content and potentially evade keyword-based detections or other systems processing the text.
I hunt these patterns in email and add context around them. Because attackers will not only write emails for us. They will(are) start writing emails for our agents too.
An email may soon have two audiences: Human + AI Agent. And they may not always see exactly the same thing.
In this new KQL, I explore a simple example: invisible Unicode characters. Microsoft and Micro<U+200B>soft may look the same to us, but not necessarily to a detection, filter, parser or AI agent. For attackers, this difference can be interesting as a way to obfuscate content and potentially evade keyword-based detections or other systems processing the text.
I hunt these patterns in email and add context around them. Because attackers will not only write emails for us. They will(are) start writing emails for our agents too.
The EntraIdSignInEvents table exposes the JA4 fingerprint in the GatewayJA4 field. But looking at the complete fingerprint alone does not tell us much. The interesting part starts when we break it down. With a simple KQL query, we can separate the TLS version, SNI, number of cipher suites, extensions and ALPN, together with the cipher and extension hashes. Then we can see how many sign-ins, users, IPs and countries are behind each JA4. The idea is simple: understand what is normal first, then look for what is different.
In DeviceNetworkEvents, we can find both JA4 and JA4S inside AdditionalFields for some TLS connections. This is interesting because we can look at both sides of the same TLS communication. We can compare clients, servers and JA4/JA4S combinations, and look for patterns or connections that behave differently from what we normally see. The following KQL extracts and decodes both fingerprints from the same network event.
This is something I have seen many times during my years working in cybersecurity: users download software with a filename they recognize and trust, but the file behind that name can be something completely different.
Monitoring the filename is not enough. Monitoring the hash is better, but legitimate software changes constantly: new version, new SHA256, another hash to validate and maintain. So I started thinking about how AI agents could help us here — not by deciding what is malicious, but by doing the repetitive work for us.
For this research, I built an AI-maintained baseline of legitimate software and used it from KQL to hunt two different scenarios:
🎯 Known filename + Unknown hash + Untrusted download source
Monitoring the filename is not enough. Monitoring the hash is better, but legitimate software changes constantly: new version, new SHA256, another hash to validate and maintain. So I started thinking about how AI agents could help us here — not by deciding what is malicious, but by doing the repetitive work for us.
For this research, I built an AI-maintained baseline of legitimate software and used it from KQL to hunt two different scenarios:
🎯 Known filename + Unknown hash + Untrusted download source
CVE-2026-65400 affects the macOS Screen Sharing service and can allow an attacker on the network to authenticate without valid credentials. Huntress' research goes further, describing the pre-authentication path and opportunities to obtain root-level file access and ultimately code execution. First thing first: patch. Update affected devices to macOS Tahoe 26.6.1, Sequoia 15.7.9, or Sonoma 14.8.9. Apple released these versions on August 6 to address CVE-2026-65400. If patching is not immediately possible, disable Screen Sharing. After patching, we still need to answer the hunter's question: was any of this activity already happening before the update? The KQL below hunts across Microsoft Defender XDR telemetry for activity around the observed attack path: Screen Sharing file activity, SSH sessions, privileged file writes, LaunchDaemon persistence, process masquerading, Packet Filter changes, XMRig artefacts and related network activity. One process particularly worth reviewing is SSFileCopyReceiver / SSFileCopySender. Huntress notes that these are privileged Screen Sharing helpers, and their research highlights root-context activity and filesystem operations as useful hunting opportunities.
Weekly, I have to analyze different Device Code Phishing cases. We already have very good reports, TI feeds and IOC lists with URLs and domains used in these attacks, but there is always a problem: someone needs to find and report the IOC first. What if the phishing domain was registered today? What if nobody has reported it yet and your user is one of the first targets?
So instead of waiting for the IOC, I wanted to look at the behaviour. We know that a Device Code authentication happened, so why not look at what the user was doing just before it?
The KQL takes the Cmsi:Cmsi event as the reference and goes 5 minutes backwards, collecting the last 3 websites visited by the same user before the Device Code authentication, together with their countries.
🌐 URL → 🌐 URL → 🌐 URL → 🔐 Device Code
From there we can remove Microsoft services, known sites and expected countries and focus on what looks different. A domain with zero reputation and no presence in any. If an user visited an unknown site just before a Device Code authentication, from an unexpected location, I definitely want to have a look.
This is not about detecting Device Code. It is about getting more context around it and, again, trying to focus a little more on IOAs and behaviour instead of only IOCs.
That sequence is what I want to hunt in this new KQL Query.
So instead of waiting for the IOC, I wanted to look at the behaviour. We know that a Device Code authentication happened, so why not look at what the user was doing just before it?
The KQL takes the Cmsi:Cmsi event as the reference and goes 5 minutes backwards, collecting the last 3 websites visited by the same user before the Device Code authentication, together with their countries.
🌐 URL → 🌐 URL → 🌐 URL → 🔐 Device Code
From there we can remove Microsoft services, known sites and expected countries and focus on what looks different. A domain with zero reputation and no presence in any. If an user visited an unknown site just before a Device Code authentication, from an unexpected location, I definitely want to have a look.
This is not about detecting Device Code. It is about getting more context around it and, again, trying to focus a little more on IOAs and behaviour instead of only IOCs.
That sequence is what I want to hunt in this new KQL Query.
attackers are continuously abusing Device Code phishing, convincing victims to authenticate using the legitimate Microsoft login page. The victim completes the password and MFA correctly, but the resulting tokens are delivered to the attacker.
And one point that I think is important: Device Code Flow should not be enabled if you don't really need it. The recommendation is clear: disable it where possible and only allow documented exceptions.
The KQL below takes Cmsi:Cmsi as a reference (which means a Device Code Authentication flow was used) point and looks 15 minutes backwards (the time that a Code is valid) for the same user, grouping the authentication flow together with countries, IPs, browsers and User-Agents. The aim is to identify authentication flows where we observe different Browsers, Countries, IPs or User-Agents, potentially showing the transition between the victim and attacker context.
The idea is simple: Look at the complete authentication sequence and identify what changes between the victim and attacker context.
And one point that I think is important: Device Code Flow should not be enabled if you don't really need it. The recommendation is clear: disable it where possible and only allow documented exceptions.
The KQL below takes Cmsi:Cmsi as a reference (which means a Device Code Authentication flow was used) point and looks 15 minutes backwards (the time that a Code is valid) for the same user, grouping the authentication flow together with countries, IPs, browsers and User-Agents. The aim is to identify authentication flows where we observe different Browsers, Countries, IPs or User-Agents, potentially showing the transition between the victim and attacker context.
The idea is simple: Look at the complete authentication sequence and identify what changes between the victim and attacker context.
Page 1 of 8