Identifying Security Platform Product Abuse with Machine Learning

Shaefer Drew; Michael Brautbar; Paul Knight; Edward Raff; Lana Peric-McDermott; Simran Sarin; Nickolas Machado; Hanna Albright

cs.CRSep 18, 2026

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,

Organizations: USA · CrowdStrike · Canada · Ireland ·

Abstract

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

Panel of Figure 2 — 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 $\leq$ 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.

Panel of Figure 4 — 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

\times

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.

Appendix figures & tables1 asset

Supplementary material from the paper’s appendix.

Appendix

Software Security

Software security studies how to find, prevent, validate, and repair vulnerabilities in code, systems, dependencies, and software supply chains.

See all 95 papers

GenAI-Driven Threat Detection with Microsoft Security Copilot
May 20, 2026Scott Freitas, Amir GharibAutonomous Cyber Defense Cybersecurity
Microsoft Security Research
Lifecycle-Aware Dynamic Analysis for Secure ML Model Execution
Jun 17, 2026Gabriele Digregorio, Marco Di Gennaro, Francesco Pastore +3
Politecnico di Milano
MOLE: Detecting Insider Threats in AI Agents
Sep 7, 2026Aashiq Muhamed, Virginia SmithAI Agent Security AI Agent Security Benchmarks
Carnegie Mellon University Pittsburgh, PA 15213, USA

May 20, 2026J/K move · Enter open · S save

GenAI-Driven Threat Detection with Microsoft Security Copilot

Scott Freitas, Amir Gharib

Microsoft Security Research

Autonomous Cyber Defense Cybersecurity LLMs for Cybersecurity

Open paper AskPDF arXiv

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.

Abstract

Software Security

Explore similar work

GenAI-Driven Threat Detection with Microsoft Security Copilot

Lifecycle-Aware Dynamic Analysis for Secure ML Model Execution

MOLE: Detecting Insider Threats in AI Agents