Use case sources
Source reports and analysis supporting this case are listed below. AITBM interpretation and any indicative scoring are derived from this public evidence.
Cloud storage and computations have become popular platforms for deploying ML malware detectors. In such cases, the features for models are built on users' systems and then sent to cybersecurity company servers. The Kaspersky ML research team explored this gray-box scenario and showed that feature knowledge is enough for an adversarial attack on ML models.
They attacked one of Kaspersky's antimalware ML models without white-box access to it and successfully evaded detection for most of the adversarially modified malware files.
ASSESSED SYSTEM
One of Kaspersky's production ML antimalware models in the configuration the Kaspersky ML research team tested in 2021: an antimalware product scans files on the user's system, a local feature extractor computes PE-header, section, section-statistics and file-string features, and the features are sent to a cloud-based ML malware detector for classification, so the detector itself is reachable only as a black box.
OUT OF SCOPE
The research team's proxy models, gradient-based adversarial algorithm and adversarial files (attacker tooling); Kaspersky's non-ML detection layers and other ML models, which the record does not describe; and any later model release or protection measure, whose deployment the record does not document.
Architecture: Traditional ML / Classifier (decision tree Q6) — The decision tree resolves at Q6 by elimination. Q1 = NO (no coordinating agents). Q2 = NO (no planner, goal or task state; the model returns a verdict for each input). Q3 = NO (the model invokes no function, API, plugin or MCP tool). Q4 = NO (no inference-time retrieval layer). Q5 = NO (no generative interface; the output is a classification score or verdict). What is described is a split malware classifier, with client-side feature extraction and a cloud-hosted classification model, so classifier intra-axis weights apply. Cn-5, Cn-6 and Cn-7 are left applicable and UNKNOWN because the product acts on its verdicts and the record does not describe that action space. Tier 2: Tier 2 Consumer: the detector classifies files from users' systems and a bypass exposes individual users to malware infection, which the record names as the practical consequence. No immediate harm at scale is established for Tier 1, and the input population is not controlled internal users as Tier 3 requires.
Documented attack or failure path
- The team reviewed adversarial ML literature on antimalware and noted that Kaspersky's use of ML detectors is publicly documented.
- Using the antimalware product, they scanned a dataset of malware and clean files and labelled each sample with the target detector's prediction.
- They trained proxy models on that labelled dataset, experimenting with several architectures.
- They reverse-engineered the local feature extractor to learn the input features sent to the cloud detector (PE header, sections, section statistics and file strings).
- A gradient-based algorithm modified file features to evade the proxy while preserving the malware payload, producing transferable adversarial files.
- The adversarial files were tested against the target solution, and for most of them the production antimalware model was evaded.
Observed controls and bounded outcomes
Positive credit is given only where the record directly demonstrates a control operating. Recommended or merely presumed controls receive no positive scoring credit.
- Server-side placement of the classification model denied white-box access: the team had only black-box access to the detector and had to train a proxy model and rely on transfer.
- The evasion did not succeed for every adversarial file: the record states the production model was evaded for most, not all, of the modified samples.
Layer 1 — Intrinsic Vulnerability Profile
Each sub-metric is placed on its five-level rubric by the evidence quoted beside it. Missing applicable evidence remains unknown. The displayed midpoint and interval are scenario values, not inferred control performance.
| Sub-metric | Score | Rubric basis | Evidence |
|---|---|---|---|
| Robustness (Ro) — scenario interval 0.08–0.76 (midpoint 0.42), Tier 2 MVT 0.50 indeterminate | |||
| Ro-1Adversarial Input Resistance | 0.25w 0.32 | Ro-1 = 0.25: the detector classifies the unmodified malware but fails under a moderate, feature-space perturbation with 'most' adversarial files evading, which places ASR above the 50% bound. The 0.50 anchor requires ASR below 50% and is therefore not met. Not 0.00 because the record gives no measurement above 80% and some adversarial files were still detected; placement is from the qualitative criterion. | Adversarial malware files built by a gradient-driven algorithm against a proxy model, with the malware payload preserved, were tested against the target antimalware solution, and for most of the adversarial files the production antimalware model was successfully evaded under black-box transfer.source: secureflow/atlas |
| Fairness (Fa) NOT APPLICABLE — axis-level applicability rule (Person-Outcome Surface test): The classifier's only output is a malware-or-clean verdict on a submitted file computed from PE-header, section, section-statistics and file-string features; it allocates, denies, ranks, prices, classifies, recommends or describes no natural person, and no protected-class attribute or proxy is plausibly present in those file-structure inputs. Its tier weight is redistributed across the remaining axes and its MVT is not evaluated. | |||
| Transparency (Tr) — scenario interval 0.00–1.00 (midpoint 0.50), Tier 2 MVT 0.50 indeterminate | |||
| Privacy (Pr) — scenario interval 0.00–1.00 (midpoint 0.50), Tier 2 MVT 0.55 indeterminate | |||
| Containment (Cn) — scenario interval 0.00–1.00 (midpoint 0.50), Tier 2 MVT 0.55 indeterminate | |||
Unknown, not N/A: 19 applicable sub-metrics lack admissible public evidence. The lower, midpoint, and upper scenarios evaluate each at 0.00, 0.50, and 1.00 respectively; no weight is redistributed merely because evidence is missing.
Architecture-based NOT APPLICABLE: NOT APPLICABLE by design for this architecture class: Cn-8, Cn-9; excluded with the Fairness axis.
Layer 2 — Operational Risk Posture
| Dimension | Score | Justification |
|---|---|---|
| AaAutonomy Amplification | 0.50w 0.25 | Human-on-the-loop. The cloud detector returns malware verdicts for user files without per-file human review, which is routine autonomous action inside the product boundary; no broader decision, tool or transaction authority is documented, so 0.75 and 1.00 are not supported. |
| AsAttack Surface Exposure | 0.85w 0.35 | Documented intermediate above the 0.75 anchor. Every file the detector classifies is of arbitrary, attacker-controllable origin, and any holder of the product can submit unlimited samples and obtain verdicts, which the team used to label a training dataset. It is below 1.00 because no untrusted RAG, external agent channel or MCP tool integration exists. elevated |
| CpCascade Potential | 1.00w 0.20 | No System Dependency Graph is published for the assessed product, so the DGC gate is not met and the Section 3.2 worst-case default applies. The evidence records the detection bypass itself but no observed downstream path, so the default is not independently corroborated.GDCP: worst-case default — no verified dependency graph published elevated |
| RfRemediation Feasibility | 0.50w 0.20 | The 0.50 anchor. Transfer evasion of a gradient-trainable classifier is closed by retraining (for example with adversarial samples) or re-engineering the feature set, both of which take weeks, are probabilistic in effect and require re-evaluation. Not raised to 0.75 because the record does not establish that retraining cannot materially reduce this attack, and not lowered to 0.25 because no deployment-layer filter addresses feature-space evasion. |
Nelevated = 2 (dimensions strictly above 0.75) → CRM = 1.15.
Compound Risk Alert. Two or more dimensions are simultaneously elevated (spec 3.2.2); architectural decomposition is recommended before deployment.
Layer 3 — Public-evidence confidence diagnostic
| Component | Score | Basis |
|---|---|---|
| Pc — Public provenance evidence | 0.25 | At the 0.25 anchor. The vendor, the product's use of ML detection and the feature classes are documented, but the specific model is unnamed and no AIBOM, training-data lineage or deployment inventory exists. |
| Ec — Public evaluation coverage | 0.03 | coverage 0.05 (1 of 20 applicable sub-metrics) × independence 0.60 × fidelity 0.95. No Full, Standard, or Lite pathway is claimed for a retrospective article. |
| Tf — Public-evidence freshness | 0.00 | Evidence dated 2021-06-23; age 1943 days on the workpaper reference date. Components: T_calendar 0.00 · C_monitor 0.65 · C_event 0.65 · C_evidence 0.85. Binding term: T_calendar. evidence_date 2021-06-23 is the ATLAS incident date; the record carries no separately dated primary disclosure, so the ATLAS case is the evidence source and dt_days = 1943. C_monitor 0.65: no production detection of the bulk labelling queries or of the adversarial submissions is evidenced. C_event 0.65: a demonstrated evasion of a production model is a moderate event; no in-the-wild exploitation is recorded. C_evidence 0.85: the record documents no remediation or retest of the evaded model. agentic = false and baw = false: no runtime-mutable permission boundary, and no online learning or persistent behavioural state is evidenced. |
Public-evidence ACI = (Pc × Ec × Tf)1/3 = 0.00 — diagnostic status: Invalid as assessment-of-record evidence. It describes the evidence available to this case study, not the assurance of the underlying system, and is not inserted into the normalized-assurance scenario ERS.
Indicative ERS — normalized-assurance scenario
Published CVSS beside indicative ERS
Each published CVSS record is shown exactly as its scorer published it, one per vulnerability record, with the version, metric group and vector when stated, plus its source and access date. Records are never combined or inferred from a CVE's existence.
INDICATIVE ERS · NORMALIZED-ASSURANCE SCENARIO
5.0 midpoint, interval 1.9–8.1; Moderate scenario band; ACI fixed at 1.00. The published CVSS records do not enter this calculation.
PUBLISHED CVSS
CVSS — no applicable published score verified.
CVSS describes an individual vulnerability as its scorer published it. Indicative ERS describes the assessed AI deployment under the normalized-assurance scenario, so the two values are not direct equivalents and neither replaces the other.
AIDEFEND defences → AITBM sub-metrics
Identifiers are quoted as they appear on the AIDEFEND in Action brief or in the AIDEFEND SecureFlow defense map (audited AIDEFEND dataVersion 2026.10.15); the sub-metric mapping is AITBM's own, from the specification's AIDEFEND tables reconciled at catalogue data version 2026.10.15. AIDEFEND renumbers identifiers between releases, so the data version travels with every mapping and neither side's IDs should be cited without one. A mapping identifies a possible evidence route; a recommendation does not prove that the control was implemented or effective and receives no scoring credit by itself.
| Technique | Defence | Priority | Evidences |
|---|---|---|---|
| AID-I-003.002 | Identity, Session & API Rate-Limit ThrottlingExact SecureFlow defense-map identifier (flow atlas-aml-cs0014-confusing-antimalware-neural-networks), verified against AIDEFEND dataVersion 2026.10.15; matched to attack step step-4. Presence supplies no score credit. | Candidate evidence route | Cn-5 Cn-6 Cn-7 |
| AID-D-005.007 | Token, Tool-Use, Request-Parameter & Cost Spike Detection & AlertingExact SecureFlow defense-map identifier (flow atlas-aml-cs0014-confusing-antimalware-neural-networks), verified against AIDEFEND dataVersion 2026.10.15; matched to attack steps step-4, step-8. Presence supplies no score credit. | Candidate evidence route | Tr-3 Cn-7 |
| AID-D-005.003 | Proactive AI Threat HuntingExact SecureFlow defense-map identifier (flow atlas-aml-cs0014-confusing-antimalware-neural-networks), verified against AIDEFEND dataVersion 2026.10.15; matched to attack step step-4. Presence supplies no score credit. | Candidate evidence route | Tr-3 Cn-7 |
| AID-D-002.001 | Input / Output Distribution Drift MonitoringExact SecureFlow defense-map identifier (flow atlas-aml-cs0014-confusing-antimalware-neural-networks), verified against AIDEFEND dataVersion 2026.10.15; matched to attack steps step-8, step-9. Presence supplies no score credit. | Candidate evidence route | Ro-2 Fa-1 Fa-2 Tr-2 Cn-7 |
| AID-H-001 | Adversarial Robustness TrainingExact SecureFlow defense-map identifier (flow atlas-aml-cs0014-confusing-antimalware-neural-networks), verified against AIDEFEND dataVersion 2026.10.15; matched to attack step step-9. Presence supplies no score credit. | Candidate evidence route | Ro-1 |
| AID-H-014 | Ensemble Methods for RobustnessExact SecureFlow defense-map identifier (flow atlas-aml-cs0014-confusing-antimalware-neural-networks), verified against AIDEFEND dataVersion 2026.10.15; matched to attack step step-9. Presence supplies no score credit. | Candidate evidence route | Ro-1 Ro-2 |
| AID-D-002.002 | Labeled Performance Tracking with Ground Truth Feedback LoopExact SecureFlow defense-map identifier (flow atlas-aml-cs0014-confusing-antimalware-neural-networks), verified against AIDEFEND dataVersion 2026.10.15; matched to attack step step-9. Presence supplies no score credit. | Candidate evidence route | Ro-2 Fa-1 Fa-2 Tr-2 Cn-7 |
WHAT THIS CASE TEACHES
Keeping the classifier server-side denies white-box access but not evasion: client-side feature disclosure plus an unthrottled verdict oracle were enough for a transfer attack that evaded the production model for most samples, so Ro-1 is the one observed placement and the containment sub-metrics that would govern oracle access remain UNKNOWN.
Sources: AIDEFEND SecureFlow — Confusing Antimalware Neural Networks · MITRE ATLAS case study AML.CS0014 · Article, "How to confuse antimalware neural networks. Adversarial attacks and protection" (securelist.com)
SecureFlow attack flow
This record mirrors an AIDEFEND SecureFlow flow (MITRE ATLAS case-study conversion): an ordered attack path with MITRE ATLAS tactic and technique labels and the AIDEFEND controls matched to each step. The scenario above places only the control outcomes this flow and its primary references observed; the matched AIDEFEND controls are evidence routes and earn no score credit.
| MITRE ATLAS case study | AML.CS0014 (exercise) |
|---|---|
| Target | Kaspersky's Antimalware ML Model |
| Actor | Kaspersky ML Research Team |
| Primary evidence date | 2021-06-23 |
| SecureFlow record updated | 2026-08-02 |
| AI layers | Predictive ML / computer vision |
| Risk impact | Model evasion / bypass |
| Affected components | cloud antimalware ML model, local feature extractor, proxy antimalware model, adversarial malware files |
Attack steps
| # | Step | ATLAS tactic / technique |
|---|---|---|
| 1 | Review Adversarial ML LiteratureThe researchers performed a review of adversarial ML attacks on antimalware products. They discovered that techniques borrowed from attacks on image classifiers have been successfully applied to the antimalware domain. However, it was not clear if these approaches were effective against the ML component of production antimalware solutions. | AML.TA0002 AML.T0001 |
| 2 | Identify Public ML Antimalware UseKaspersky's use of ML-based antimalware detectors is publicly documented on their website. In practice, an adversary could use this for targeting. | AML.TA0002 AML.T0003 |
| 3 | Access Antimalware ProductThe researchers used access to the target ML-based antimalware product throughout this case study. This product scans files on the user's system, extracts features locally, then sends them to the cloud-based ML malware detector for classification. Therefore, the researchers had only black-box access to the malware detector itself, but could learn valuable information for constructing the attack from the feature extractor. | AML.TA0000 AML.T0047 |
| 4 | Build Labeled Dataset via Target ScansThe researchers collected a dataset of malware and clean files. They scanned the dataset with the target ML-based antimalware solution and labeled the samples according to the ML detector's predictions. | AML.TA0003 AML.T0002.000 |
| 5 | Train Proxy Antimalware ModelA proxy model was trained on the labeled dataset of malware and clean files. The researchers experimented with a variety of model architectures. | AML.TA0001 AML.T0005 |
| 6 | Reverse-Engineer Feature ExtractorBy reverse engineering the local feature extractor, the researchers could collect information about the input features, used for the cloud-based ML detector. The model collects PE Header features, section features and section data statistics, and file strings information. A gradient based adversarial algorithm for executable files was developed. The algorithm manipulates file features to avoid detection by the proxy model, while still containing the same malware payload | AML.TA0003 AML.T0017.000 |
| 7 | Craft Transferable Adversarial MalwareUsing a developed gradient-driven algorithm, malicious adversarial files for the proxy model were constructed from the malware files for black-box transfer to the target model. | AML.TA0001 AML.T0043.002 |
| 8 | Verify Evasion on TargetThe adversarial malware files were tested against the target antimalware solution to verify their efficacy. | AML.TA0001 AML.T0042 |
| 9 | Evade Antimalware DetectionThe researchers demonstrated that for most of the adversarial files, the antimalware model was successfully evaded. In practice, an adversary could deploy their adversarially crafted malware and infect systems while evading detection. | AML.TA0007 AML.T0015 |
Threat references
Summary and attack steps reproduced from AIDEFEND SecureFlow (https://aidefendlabs.com/en/secureflow/?flow=atlas-aml-cs0014-confusing-antimalware-neural-networks; AIDEFEND content CC BY 4.0), converted from MITRE ATLAS case study AML.CS0014 (Apache License 2.0; MITRE ATLAS is a trademark of The MITRE Corporation).