Arnold Chan
@slazTrusted contributorCompletionist
2 followers2,100 downloads4,386 copies51 likes26,184 views
7,555 detections
Filters
Last updated
All Time
Detection languages
5,650
1,006
394
169
98
Categories
2,356
1,807
1,233
1,013
924
Platforms
4,191
1,622
1,250
676
676
Products / Services
2,820
1,003
991
720
485
MITRE Techniques
2,087
1,520
1,413
1,070
536
CVEs
38
33
24
22
21
IDS Classtypes
477
179
104
79
52
IDS Protocols
554
156
144
86
18
Detects the loading of the Alinubx.sys (aka CcProtect.sys) kernel driver, often dropped as nvfsflt64.sys or registered as NvFsFilter, followed by a rapid, simultaneous termination of security product processes. This activity is indicative of a BYOVD (Bring Your Own Vulnerable Driver) attack chain where kernel-mode primitives are used to terminate EDR/AV processes.
Detects the loading of the Alinubx.sys (aka CcProtect.sys) kernel driver, often dropped as nvfsflt64.sys or registered as NvFsFilter, followed by a rapid, simultaneous termination of security product processes. This activity is indicative of a BYOVD (Bring Your Own Vulnerable Driver) attack chain where kernel-mode primitives are used to terminate EDR/AV processes.
This rule identifies successful OAuth 2.0 device code authentication attempts originating from both an IP address and country not previously seen for that specific user, using a 90-day baseline that requires at least 5 prior non-device-code sign-ins to be established (reducing noise from sparse-history/new accounts). It excludes known legitimate device-code applications (e.g., Azure CLI, Azure PowerShell, Visual Studio, VS Code) and sign-ins from devices already marked compliant/managed. This tightened logic reduces false positives from routine travel or home/office network changes while still catching device code phishing, where an adversary tricks a user into entering a device code on a malicious site to obtain an access token.
Hunts network, HTTP, and email-URL telemetry for known ARToken infrastructure (operator backend IPs and phishing/panel domains). Bounded to a 30-day lookback and tiers matches by confidence: domain hits are high-confidence (attacker-registered infrastructure), while IP hits are medium-confidence since the IPs sit on shared DigitalOcean hosting that can be reassigned to unrelated tenants once ARToken's infrastructure is taken down. Empty/unparsed indicator fields are excluded to avoid spurious matches in the HTTP event parsing branch. No known file hashes are associated with this intel.
Hunts network, HTTP, and email-URL telemetry for known ARToken infrastructure (operator backend IPs and phishing/panel domains). Bounded to a 30-day lookback and tiers matches by confidence: domain hits are high-confidence (attacker-registered infrastructure), while IP hits are medium-confidence since the IPs sit on shared DigitalOcean hosting that can be reassigned to unrelated tenants once ARToken's infrastructure is taken down. Empty/unparsed indicator fields are excluded to avoid spurious matches in the HTTP event parsing branch. No known file hashes are associated with this intel.
Correlates a successful OAuth device-code sign-in with a subsequent Microsoft Authentication Broker / Device Registration Service event for the same user within 30 minutes, excluding known legitimate device-code applications (Azure CLI, Azure PowerShell, Visual Studio, VS Code) and requiring both events to have succeeded. The correlation is further restricted to cases where the device-registration event originates from a different IP address or city than the original device-code sign-in -- the pattern expected when an attacker uses a stolen token to register their own device and mint a Primary Refresh Token, versus a legitimate user completing device enrollment from their own network shortly after a CLI/developer login.
Correlates a successful OAuth device-code sign-in with a subsequent Microsoft Authentication Broker / Device Registration Service event for the same user within 30 minutes, excluding known legitimate device-code applications (Azure CLI, Azure PowerShell, Visual Studio, VS Code) and requiring both events to have succeeded. The correlation is further restricted to cases where the device-registration event originates from a different IP address or city than the original device-code sign-in -- the pattern expected when an attacker uses a stolen token to register their own device and mint a Primary Refresh Token, versus a legitimate user completing device enrollment from their own network shortly after a CLI/developer login.
This rule identifies successful OAuth 2.0 device code authentication attempts originating from both an IP address and country not previously seen for that specific user, using a 90-day baseline that requires at least 5 prior non-device-code sign-ins to be established (reducing noise from sparse-history/new accounts). It excludes known legitimate device-code applications (e.g., Azure CLI, Azure PowerShell, Visual Studio, VS Code) and sign-ins from devices already marked compliant/managed. This tightened logic reduces false positives from routine travel or home/office network changes while still catching device code phishing, where an adversary tricks a user into entering a device code on a malicious site to obtain an access token.
Detects potential exploitation of CVE-2025-3248 in Langflow by identifying suspicious inbound network traffic targeting the /api/v1/validate/code endpoint, correlated with subsequent python child processes containing base64 decoding and execution primitives such as eval, exec, or subprocess.
Detects unauthorized access and data retrieval attempts from a MinIO object storage instance using default administration credentials (minioadmin:minioadmin). The rule monitors both command-line execution of MinIO client (mc) operations and network connections to MinIO service ports (9000/9001) that involve the use of the default credential pair.
Page 336 of 756