Identifying Security Platform Product Abuse with Machine Learning
Authors: Shaefer Drew, Michael Brautbar, Paul Knight, Edward Raff, Lana Peric-McDermott, Simran Sarin, Nickolas Machado, Hanna Albright, Vitaly Zaytsev
Organizations: USA · CrowdStrike · Canada · Ireland · Brazil
Product abuse is an individually rare, but growing, problem across the SaaS industry. Highly sophisticated threat actors can misuse security platforms within customer environments or conduct bypass experiments on the product itself. Threat actors can leverage living-off-the-land (LOTL) attacks to avoid using cumbersome, frequently detected malware. Remediating this threat requires collecting multiple data modalities across different types of databases, addressing a cold-start problem in the intrinsic rarity of such sophisticated but dangerous events, and designing within the constraints of real-world deployment (e.g., cost, user behavior, performance, etc). To wit, we provide the first study of such a whole-system defense, especially with respect to a deployed and operational capability. Our results show an increase in product abuse coverage by 35%, a 30% reduction in monthly alerts, and adaptability to changes in malicious actors' behavior. We review both the constraints we considered in designing the system to meet operational requirements and a retrospective evaluation of the value of explainable features and counterfactual performance on previously identified attacks.
Figures & tables
Fig. 1: Modeling Diagram. Outlines the ML-based framework of how anomaly detection and risk scoring are combined to generate product abuse leads
Fig. 2: Recall vs Contamination Ratio (what fraction of the dataset we choose to mark as anomalous, as ranked by our model). Based on historical data we can acheive 100% recall considering only 20% of potential alerts, and still highly effective 40% at ≤ 2.5%, giving us an effective means to balance analyst availability and “hunt” for such rare but dangerous events.
Risk Factor
Data Source
Rank
Suspicious VPN
IP Context
Very Bad
Event 12 ( creating a new user )
Interesting Events
Slightly Bad
Threat Actor Association
Security Tickets
Extremely Bad
TABLE II: Risk Factors and Rankings. Examples of risk factor features and their rankings provided by subject matter experts. These are used as input to data source risk scores. Very/Extremely Bad ranks contribute to higher marginal risk increases than slightly bad ranks.
Fig. 3: Visualizes the impact of a risk factor on the initial risk score, based on the number of factors that hit at each rank. Very Bad and Bad are represented in the figure.
Risk Factor
Hit Count
Interesting Event 15
3
Threat Actor Association
1
Suspicious Browser
1
TABLE IV: Risk Factors Explanation Example. This demonstrates the risk explanation for a single example product abuse lead, where the factors contributing to the risk score included the user performing interesting event 15 three times, having an associated threat actor in an overlapping security ticket, and using a suspicious browser to perform these actions. These explanations help point investigators in the right direction.
Fig. 4: Local Explanation of Top 10 SHAP Features for Isolation Forest, signifying the top feature contributions to the anomaly score. These were shared with investigators (who could resolve events to specific types via a database) who used them to identify discrepancies between initial modeling and how attacks tend to work, and successfully iterate to our current solution.
Stat
Model
Rules-Based
Recall
39% [24, 58]
4% [1, 18]
Avg Monthly Lead Reduction
30% [22, 37]
NA
TABLE V: Using a historical corpus of 28 product abuse cases (3-month window), the new approach catches 9.8 × more instances. Bracketed values are 95% CIs (Wilson score interval [ 33 ] for recall; exact Poisson rate-ratio [ 32 ] for lead reduction). This is a significant operational advantage, mitigating what was previously a reactive-only issue.
Stat
Model
Rules-Based
Precision
13.3% [9.0, 19.2]
3.7% [2.9, 4.6]
Avg Monthly Lead Reduction
57.6% [54.3, 60.7]
NA
TABLE VI: Our ML solution was deployed against live data in a 5-month “beta” release, showing far higher precision than the rule-based approach. Bracketed values are 95% CIs (Wilson score interval [ 33 ] for precision; exact Poisson rate-ratio [ 32 ] for lead reduction). Given the high-risk and low-enough-to-staff load of alerts, the model is continuing expanded roll out due to its success.
Defending against today's increasingly sophisticated cyberattacks requires security analysts to continuously translate evolving attacker tradecraft into detection logic. This places defenders in a reactive posture, requiring constantly updated expertise across an increasingly fragmented security landscape. We introduce the Dynamic Threat Detection Agent (DTDA), an always-on adaptive agent that continuously investigates security incidents across Microsoft Defender to uncover hidden threats and generate explainable detections when attack-story gaps are found. DTDA combines: (1) a unified activity timeline spanning alerts, events, user and entity behavior analytics, and threat intelligence; (2) versioned LLM prompt contracts with schema validation, grounding requirements, bounded retries, and fail-closed suppression; (3) a planner-executor investigation loop that generates attack-specific hypotheses and gathers supporting and refuting evidence; and (4) dynamic alert generation with a context-relevant title, severity, MITRE mappings, remediation guidance, implicated entities, and natural-language attack description. Integrated into Microsoft Security Copilot and deployed across tens of thousands of Defender customers, DTDA operates continuously at industry scale. In a 120-day online evaluation, DTDA achieves 80.1% precision from customer feedback while generating novel alerts for approximately 15% of investigated incidents. In offline evaluation, DTDA recovers hidden malicious activity with 0.78 F1 using GPT-5.4, improving over GPT-4.1 by 0.12 F1 and outperforming the baseline by 0.26 F1 points. Operationally, DTDA processes single-incident investigations end-to-end in a median of 28 minutes at a median token cost of USD 2.04, with a 0.38% job-level failure rate. These results demonstrate that autonomous agents can identify missed malicious activity at a production scale.
The growing reliance on pre-trained Machine Learning (ML) models has introduced new attack surfaces. Recent vulnerabilities demonstrate that malicious behavior can be embedded within model artifacts, often bypassing existing defenses. Current model-scanning solutions primarily rely on static, format-specific rules or known attack signatures, which limit their ability to generalize across frameworks and to detect novel exploitation paths. In contrast, we propose a solution that focuses on the effects an attack has on the host system executing the model and builds on foundational intuitions about ML model execution. In particular, we observe that ML models operate within well-defined lifecycle phases and that, within each phase, interactions with the host system are highly structured and predictable. We translate these intuitions into Moat, a dynamic lifecycle-aware approach for securing ML model execution, and instantiate this design in Re-Moat, our reference implementation. We evaluate Re-Moat across multiple ML frameworks using 77,974 real-world model artifacts from the Hugging Face Hub, 31 Proofs-of-Concept (PoCs) from CVEs, and 334 models from a state-of-the-art dataset, and compare it against state-of-the-art model-scanning solutions. Our results show that our approach detects all evaluated attack classes while maintaining a close-to-zero false-positive rate, validating our intuitions and motivating dynamic analysis for securing ML model execution.
Gabriele Digregorio, Marco Di Gennaro, Francesco Pastore +3
Model misalignment, prompt injection, or operator misuse could lead AI agents operating frontier-lab accounts to exfiltrate model weights, poison training data, or weaken release gates. Existing benchmarks do not test whether defenders can detect this activity among routine work under a limited review budget. We introduce MOLE, an open benchmark of 150 AI-operated accounts sharing 9 stateful services over 30 workdays, with 12 threats and 8 corpora from four models totaling roughly 20 billion tokens. Of 39 agent models, 72% complete most assigned harmful objectives and agent refusal does not predict completion. MOLE enables comparison of 40 monitors across corpus generators, observability levels, and threats; even the best evaluated monitor in our single-day audit-event comparison misses nearly half of completed harm. MOLE also enables monitor development: benchmark-guided search improves a mid-tier monitor by 49-64%, while selective use of a stronger monitor improves budget-AUC by 10% over applying it to every account-day at comparable modeled cost.
Aashiq Muhamed, Virginia Smith
Carnegie Mellon University Pittsburgh, PA 15213, USA