Malicious File Investigation

This runbook is the family-specific continuation of Critical Alert Triage for any alert whose evidence points at a malicious file observed on the network. It covers every severity tier of the MetaDefender Core file-scanning family — a MetaDefender Core High, Medium, or Low antivirus (AV) Detection alert on the Hunt page — and the common case where an MD Core alert has been promoted to Critical by the Indicator of Compromise (IOC) auto-escalation rule because the file's hash or the connection that delivered it coincides with an independent feed match. The steps below take the analyst from "a file landed on a host and MetaDefender flagged it" to "a triage decision recorded in the incident-management system".

This runbook is written for Tier 1 Security Operations Center (SOC) analysts performing first-response triage on file-scan alerts, Tier 2 analysts resolving escalations into malware incidents, and threat hunters pivoting from a single file-scan verdict into a broader campaign investigation. It assumes the analyst has already executed Critical alert triage through step 5 when the lead originated from a Critical-severity alert — the affected asset, the supporting sidebar evidence, the repetition history, and any same-flow corroboration are already in hand. For High, Medium, or Low MD Core alerts that did not pass through the Critical-triage runbook, the analyst records the affected asset and its criticality tier before executing the runbook below.

First-use acronym expansions in this runbook: SOC (Security Operations Center), IOC (Indicator of Compromise), C2 (command-and-control), AV (antivirus), MD Core (MetaDefender Core — OPSWAT's on-premises multi-AV scanning server), MD Cloud (MetaDefender Cloud — the Software-as-a-Service equivalent), PUA (potentially-unwanted application), SHA-256 (Secure Hash Algorithm 256-bit), MD5 (Message Digest algorithm 5), IP (Internet Protocol), DNS (Domain Name System), TLS (Transport Layer Security), SNI (Server Name Indication), HTTP (Hypertext Transfer Protocol), HTTPS (Hypertext Transfer Protocol Secure), SMB (Server Message Block), SMTP (Simple Mail Transfer Protocol), FTP (File Transfer Protocol), URL (Uniform Resource Locator), URI (Uniform Resource Identifier), ASN (Autonomous System Number), GeoIP (geographical IP lookup), TIDB (Threat Intelligence Database), REPDB (Reputation Database), EDR (endpoint detection and response), IR (incident response), PDF (Portable Document Format), ZIP (Zip archive), PCAP (packet capture), MVP (Minimum Viable Product), FRD (Functional Requirements Document), S3 (Simple Storage Service), SaaS (Software-as-a-Service), MIME (Multipurpose Internet Mail Extensions).

Trigger Scenario

An analyst reaches this runbook from one of three starting points. In each case the lead describes a file the sensor extracted from observed traffic that MetaDefender has scanned and at least one AV engine has flagged.

Primary — MetaDefender Core High AV Detection alert on the Hunt page. The analyst opens the Hunt Page, navigates to the All Alerts bucket, and selects the MD Core Alert sub-tab. A row carries alert_type: "mdcore", a High severity label, and the enrichment-specific columns mdcore.scan_result: Infected (or Suspicious) and mdcore.threat_name naming the canonical verdict. The sidebar's MD Core Enrichment section shows six or more positive engines against the total scanned.
Primary — MetaDefender Core Medium or Low AV Detection alert on the same sub-tab. The same surface and sidebar, but with the severity tier set to Medium (three to five positive engines) or Low (one or two positive engines). The Low tier carries a rule description of "possible false positive" and is expected to include a mix of real threats and single-vendor heuristic flags.
Secondary — Critical alert carrying an MD Core enrichment with threat_found: true. The alert reaches the analyst through Critical Alert Triage because the IOC auto-escalation rule promoted it to Critical / 0.99 confidence: the scanned file's hash or the delivering connection matched an independent indicator feed (C2 or OPSWAT InSights). The underlying MD Core verdict may be at any positive-engine count.

The three trigger surfaces converge in this runbook because the investigation is the same: a file reached an internal host, MetaDefender has weighed in, and the analyst needs to decide whether the file was executed, whether the recipient needs containment, and whether the same file is elsewhere on the network. The evidence-gathering steps are identical once the analyst is in the Hunt workspace.

Prerequisites

Before executing this runbook the analyst confirms the following.

Steps 1 through 5 of Critical Alert Triage are complete when the lead is a Critical-severity alert. The affected asset, its owner and criticality tier, the sidebar evidence summary, and any repetition or same-flow correlation already live in the incident ticket. For High, Medium, or Low MD Core alerts triaged directly, the analyst still records the affected asset and its criticality tier before executing the runbook.
A Hunt session open on the originating MD Core Alert sub-tab (for the primary triggers) or on the originating alert row carrying an MD Core enrichment (for the secondary trigger), with the detail sidebar visible.
Access to the organization's asset inventory for the affected host — the recipient of the file, which on an inbound download is the host on the client side of the carrier protocol (typically the internal host that initiated the connection) and on an outbound transfer is the external destination or internal server being written to. Operators read the file direction from the delivering protocol: HTTP response bodies, FTP RETR, SMB reads, and SMTP attachment fetches all place the recipient on the internal side; HTTP PUT / POST, FTP STOR, SMB writes, and SMTP message sends place the recipient on the destination side.
A working mental model of the organization's sanctioned software-distribution paths — which update servers, which internal package repositories, which software-delivery platforms, and which business-partner file-exchange endpoints legitimately deliver executables, installers, scripts, documents, and archives to corporate endpoints.
Access to the incident-management system used by the SOC and, when available, read access to the organization's Endpoint Detection and Response (EDR) console so the file's post-delivery fate on the recipient host (executed, quarantined, still on disk) can be confirmed against endpoint telemetry.
Awareness of whether the MetaDefender Core enrichment's long-term archive storage is enabled in the current deployment. When it is, the original bytes of the scanned file are available for forensic retrieval through the configured Simple Storage Service (S3) bucket. When it is not, the carved file is deleted from the sensor's extraction directory after scanning (the default DELETE_AFTER_SCAN behavior described in MetaDefender Core File Scanning) and forensic recovery relies on the recipient host's copy if any remains.

Missing any of these is a hard stop. A malicious-file investigation run without asset context tends to misidentify the recipient; run without the sanctioned-software-distribution baseline, it tends to over-escalate legitimate installers delivered through obscure but approved channels; run without EDR or archive-storage access, it tends to close on incomplete post-delivery evidence.

Investigation Steps

Each step is numbered, adds a distinct piece of evidence, and feeds the decision tree at the end. The analyst executes steps in order even when the verdict looks obvious early; a malicious-file disposition is never safely recorded on partial evidence because the same multi-vendor verdict can be a real malware delivery and a legitimate installer with a heuristic flag depending on the delivery context and the recipient's expected software set.

On the Hunt page, the analyst clicks the alert row to open the detail sidebar. The sidebar renders the underlying FileInfo event record alongside the MD Core Enrichment section (see Hunt page — The Detail Sidebar). The analyst records the following fields from the enrichment block before any pivot.

mdcore.<sha256>.threat_found — the boolean that gates every MD Core rule. On a triggered alert this is true on at least one entity.
mdcore.<sha256>.threat_name — the canonical threat label (for example, Trojan.PDF.Emotet.Generic, Win.Trojan.RedLine-10012345-0, PUA.Adware.Generic). The naming convention identifies the malware family when the verdict is not a heuristic.
mdcore.<sha256>.scan_result and mdcore.<sha256>.scan_result_code — the human-readable label (Infected, Suspicious, No Threat Detected) and its numeric counterpart. The scan-result-code map from the detection chapter is 0 = No Threat, 1 = Infected, 2 = Suspicious, 3 = Failed to Scan, 4 = Cleaned / Quarantined, 5 = Unknown, 6 = Skipped - Clean, 7 = Skipped - Infected. A code of 3 or 5 on a triggered alert is anomalous and points at a scanning-infrastructure fault rather than a verdict; the analyst records the anomaly and treats the evidence as degraded.
mdcore.<sha256>.positive_engines and mdcore.<sha256>.total_engines — the numerator and denominator of the AV-vendor agreement. Fifteen of thirty engines flagging the file is stronger evidence than two of thirty.
mdcore.<sha256>.cached_result — true when the verdict came from MetaDefender's hash cache rather than a fresh scan. The behavioral meaning is identical to a fresh scan, but a cached verdict with an old scan_time means the engine set and signature versions reflect the earlier scan, which matters when a freshly-reclassified file is in play.
mdcore.<sha256>.scan_time — the timestamp of the scan that produced the verdict. Cached results may carry a timestamp days, weeks, or months older than the event.
mdcore.<sha256>.data_id — the MetaDefender scan identifier, useful for pivoting into the MetaDefender console for per-engine details beyond what the enrichment carries.
mdcore.<sha256>.file_info — the object containing the file's SHA-256, SHA-1, MD5, file size in bytes, file type, and file-type description (for example, "file_type": "PDF", "file_type_description": "PDF document").
mdcore.<sha256>.scan_details — the per-engine map. The analyst notes which vendors flagged the file (Kaspersky, Bitdefender, Microsoft, ESET, and so on) and which did not; broad cross-vendor agreement (a dozen independent engines naming variants of the same family) is qualitatively stronger than a single-vendor heuristic flag repeated across rebranded engines.

The underlying FileInfo block on the sidebar carries the base record: fileinfo.filename, fileinfo.magic (the libmagic file-type string — for example, PDF document, version 1.5), fileinfo.size, fileinfo.sha256, fileinfo.md5, fileinfo.state (CLOSED on a scanned file), and fileinfo.stored (true on a scanned file). Above that, the base network section carries src_ip, src_port, dest_ip, dest_port, proto, app_proto, and the community_id correlator for the connection that delivered the file.

When the event carries multiple file entities — multi-part archive transfers and bulk SMB copies are the common cases — the md core block contains one entry per SHA-256 and the rule reduces across them using the maximum positive_engines value. The sidebar shows every entity; the analyst records every threat_found file on the event before proceeding.

2. Read the verdict against the severity tier and the per-vendor agreement

MD Core's severity mapping is mechanical: the alert engine compares the maximum positive_engines across all file entities on the event to three thresholds. The analyst reads the numbers from step 1 and locates the alert on the following ladder.

Severity	Trigger	What it usually means
Critical	Any tier promoted by IOC auto-escalation — the file's hash or the delivering connection coincides with a C2 or OPSWAT InSights indicator.	Multi-source corroboration: a file the AV engines flagged and an independent feed hit on the same delivery context. Escalation by default (see step 6).
High	Maximum `positive_engines` >= 6.	Broad AV agreement. Six or more independent vendors flagging the same bytes is strong corroboration of a real malicious classification. Treat as an incident candidate.
Medium	Maximum `positive_engines` is 3, 4, or 5.	Partial agreement. Typical early-detection band for variants that have propagated to some vendor signatures but not all. Most cases are real; a material minority are aggressive-heuristic disagreements that resolve on deeper inspection.
Low	Maximum `positive_engines` is 1 or 2.	Minimum threshold. The rule description is "possible false positive" by design — one or two vendors flagging a file is an invitation to look closer, not a conclusion.

The analyst records the ratio, the severity tier, and a qualitative read of the vendor agreement in the ticket. "12 of 30 engines flagging the file, vendors include Kaspersky, Bitdefender, Microsoft, and ESET, all labeling it as a variant of Emotet — strong cross-vendor agreement on a known family" is the kind of note that survives handoff. The opposite shape — "2 of 30 engines flagging, vendors are two rebranded instances of the same engine kernel, label is PUA.Generic.Heuristic" — is the shape that justifies deeper investigation before any containment action.

A cached result with an older scan_time is worth a second reading at this step: when the engine set and signature versions on the cached scan are months out of date relative to the event, the verdict may have since been reclassified. The data_id field supports a lookup into the MetaDefender console for the current verdict when an analyst is uncertain about a stale cache.

3. Identify the recipient host and the file delivery context

The MD Core alert fires on the FileInfo event, which represents the completed extraction of a file from observed traffic. The analyst's next question is: which host received the file, and over what connection? The answers come from the base network section and from the community_id pivot.

The analyst reads the base record. On an inbound download (HTTP response body, FTP RETR, SMTP attachment fetch, SMB read) the recipient is the host on the client side of the carrier protocol — typically the internal host that initiated the connection. On an outbound transfer (HTTP PUT / POST, FTP STOR, SMTP message send, SMB write) the recipient is the external destination or the internal server being written to. The src_ip and dest_ip fields on the base section are the 5-tuple endpoints of the delivering connection; the Suricata file-store output does not itself label which side is the recipient, so the analyst infers direction from the carrier protocol and the session evidence.

The analyst then right-clicks the community_id value and selects Show all events with this community id. A new All Events tab opens on the Hunt Page filtered to every protocol transaction, flow record, file extraction, and enrichment that belongs to the same connection. This view exposes:

The carrier-protocol session that delivered the file. An HTTP row on the same community_id carries the method, host, URL, User-Agent, referer, and response content-type — the full download transaction. An SMTP row carries the mail-from, recipients, subject, and attachment filenames. An SMB row carries the share, the filename, and the access flags. An FTP row carries the command sequence (USER, PASS, RETR, STOR). The protocol context identifies the delivery mechanism and the user or process on the recipient host that requested or accepted the transfer.
The DNS resolution that preceded the connection. When the host was reached by name, the DNS query and answer sit on the same community_id. The resolved name identifies the external endpoint — a known software-distribution host, a business-partner portal, an unfamiliar content-delivery network, or a domain whose shape matches a domain-generation-algorithm pattern (see C2 beacon investigation — step 8).
The TLS handshake when the delivery rode HTTPS. The SNI, the certificate subject and issuer, and the JA3 / JA4 client fingerprint identify the client and the endpoint even when the payload is opaque. A corporate browser's fingerprint downloading from a legitimate vendor portal reads very differently from a hand-rolled-transport fingerprint fetching a file from a raw IP.
The Flow record for the connection — total bytes, packet counts per direction, duration, and the flow-end reason. The size on the Flow record should match fileinfo.size to within headers and framing overhead; a large discrepancy means additional content rode the same connection.

The analyst records the recipient host's identity, the delivery protocol, the carrier session details, and the external endpoint's identity. "Recipient 10.40.12.88 (finance-workstation-412, Tier 2); HTTPS download from cdn-updates.supplier.example.com (52.x.x.x, ASN 16509 Amazon, SNI matches corporate business-partner portal); file is a 284 KB PDF reported by the HTTP response Content-Type as application/pdf; inbound transfer, recipient is the internal host" is the shape of a note the rest of the runbook operates on.

4. Pivot to the FileInfo records for the same hash

With the recipient identified, the analyst asks the population-scope question: how many times has this hash been observed on the network, on how many hosts, and over what time range? The answer distinguishes a one-off delivery to a single host from a campaign-scale distribution.

From the alert row the analyst right-clicks the SHA-256 value (or selects fileinfo.sha256 in the sidebar) and selects Search file hash across all events. A new All Events tab opens filtered to every event that references the hash — the upstream HTTP download, any SMB write, any SMTP attachment fetch, any downstream repetition, and every subsequent MD Core scan verdict. The analyst widens the time range to Last 7 days or Last 30 days as appropriate and reads:

How many distinct recipients the hash reached. A single FileInfo row with the alert's own community_id is a host-scoped event. A dozen FileInfo rows across different recipient hosts is a fleet-scoped distribution that changes the escalation shape immediately.
Which delivery protocols carry the hash. A file that arrives inbound over HTTPS on some hosts and via SMB lateral copy on others is either a legitimate software update followed by internal distribution, or a malware delivery followed by lateral spread — step 5 resolves the ambiguity.
The timeline of observations. A hash observed at a steady trickle over days is consistent with a sanctioned software-distribution pattern; a hash observed in a tight burst across many hosts is consistent with a targeted campaign.
Whether any recipient has been scanned multiple times. A cached_result: true verdict on subsequent observations is the expected behavior — hash-lookup-first deduplication (described in MetaDefender Core File Scanning) ensures the same bytes are scanned once and the verdict is reused.

The analyst also navigates to the Files bucket on the Hunt page and filters to the same SHA-256. The Files bucket returns FileInfo event rows with columns for fileinfo.filename, fileinfo.magic, fileinfo.sha256, fileinfo.md5, fileinfo.size, and the scan result columns. The row-per-observation view is useful when the same hash has been delivered under different filenames — a file renamed between deliveries is a stronger malicious-distribution signal than consistent-filename deliveries of a legitimate installer.

5. Check the recipient population and lateral-movement context

A malicious file that reached one host is a host-scoped compromise; the same file on several hosts is either a coordinated delivery (targeted campaign, watering-hole download from a shared site, or mass-mail attachment) or lateral distribution from an initial foothold. The analyst distinguishes the two by reading the timing and the delivery surface.

Coordinated external delivery. Multiple recipients received the file from the same external endpoint within a narrow time window, each via the same carrier protocol. The pattern matches a phishing campaign (the same attachment delivered to a set of recipients over SMTP), a watering-hole attack (the same URL served to several internal browsers), or a supply-chain compromise (the same update package pulled from a compromised vendor host).
Lateral distribution. The file appeared inbound on one recipient and was subsequently observed on internal-to-internal SMB writes, internal-to-internal HTTP transfers, or administrative-share file copies from that recipient to other internal hosts. The timing is typically sequential: a first recipient, then minutes to hours later one or more secondary recipients reached via internal protocols. The pattern is a post-initial-foothold motion and the blast radius expands to every recipient on the lateral chain.
Independent arrivals with no shared source. The same hash on several hosts with no shared external endpoint and no internal-lateral evidence is an ambiguous pattern — it may be a legitimate file arriving through unrelated legitimate channels (a common-use PDF, an executable distributed through a published link) or the signal of a broader external-distribution campaign that the sensor's carve coverage has only partially captured.

From the originating alert row the analyst then opens a second tab using the right-click pivot Hunt all events from this IP on the recipient's IP and widens the time range to Last 7 days. This tab shows every conversation the affected host has held with any endpoint — internal or external — over the window. The analyst looks for corroborating signals that elevate the hypothesis: outbound beacon-shaped patterns that emerged after the delivery (a C2 or Beaconing alert on the same source), anomalous DNS queries (unusual labels, high unique-subdomain ratios), data-exfiltration-shaped upload flows, or an ML Random Cut Forest anomaly tied to the same host. Corroborating signals appearing after the file delivery are the strongest evidence the file was executed.

The analyst records the population scope explicitly. "Hash observed on 8 recipients over 36 minutes, all inbound over HTTPS from the same external endpoint, no subsequent internal-to-internal propagation — coordinated external delivery" and "Hash observed on recipient A at 14:02; subsequently copied to recipients B and C over SMB from A at 14:23 and 14:41 — lateral distribution" are the two common shapes.

6. Check for IOC enrichment on the file, the recipient, or the delivering endpoint

This is the single strongest disposition lever in the runbook. The alert sidebar carries the C2 Enrichment section whenever any C2 feed match fired on the delivering endpoint; the Insights Enrichment section carries parallel matches from the OPSWAT InSights Threat Intelligence Database (TIDB) and Reputation Database (REPDB) feeds.

Any c2.matches[] entry present on the delivering src_ip, dest_ip, or resolved DNS name. The alert is IOC-Critical by construction. Severity is Critical, alert-level confidence is 0.99, and the match payload identifies the threat actor or malware family the indicator belongs to. An MD Core verdict with a C2-flagged delivery endpoint is a two-source corroborated malicious-delivery event; the finding on its own is sufficient for escalation to incident response (see Decision Tree).
Parallel InSights TIDB match on the file hash, the recipient, or the delivering endpoint. See InSights TIDB and REPDB for the feed semantics. A TIDB hit on the file's SHA-256 is the strongest corroboration the feeds produce — an independent threat-intelligence feed has the same bytes catalogued as malicious. A TIDB hit on the delivering IP or domain is secondary corroboration. Both promote the alert to Critical under the IOC auto-escalation rule.
Parallel InSights REPDB match on the delivering endpoint. A REPDB hit is lower-confidence than a TIDB hit but is still material, especially when the REPDB category names a class consistent with a malware-distribution host (anonymous file-sharing, known compromised hosting tenant, paste-site mirror). REPDB alone also promotes to Critical under the IOC auto-escalation rule.
No IOC match on any feed. The alert is threshold-High, Medium, or Low on AV-vendor evidence alone. The case for escalation now depends on the verdict strength in step 2, the delivery-context quality in step 3, the population scope in steps 4 and 5, and the post-delivery EDR evidence in the next step.

The analyst records the IOC state explicitly in the ticket — "IOC match present on hash / delivering IP / delivering domain / none" — because it is the single field that changes downstream dispositions most often. A Low-tier MD Core alert with an IOC match on the delivering URL is triaged identically to a High-tier alert; a High-tier alert with no IOC match still warrants escalation on verdict strength alone when the population or delivery context corroborate, but the disposition record must reflect the absence of IOC evidence.

7. Pull the post-delivery evidence on the recipient host

The question the file-scan verdict cannot answer on its own is: did the recipient execute the file? The network-only surface MetaDefender NDR operates from captures the delivery, not the execution. Post-delivery evidence comes from the recipient host's endpoint-telemetry sources — EDR process trees, operating-system process-creation events, file-write and file-delete audit records, user-session context, scheduled-task creation, registry changes on Windows endpoints, and (on a network surface) the source host's subsequent outbound traffic.

The analyst queries each available source, in roughly this priority order:

EDR process telemetry on the recipient host. A process-creation event naming the file (the exact filename, the SHA-256, or a path under the browser's download directory) within seconds or minutes of the FileInfo timestamp is direct evidence the file was executed. Absent EDR, many endpoints expose equivalent events through the operating-system audit log (Windows Security 4688, Linux auditd execve, macOS ESF) that the SOC may have access to through a log-aggregation pipeline.
EDR or endpoint-antivirus quarantine and block events. A block event naming the same hash confirms the endpoint prevented execution — a material piece of information that shifts the disposition toward monitor or close even on a High-tier MD Core verdict. A quarantine event at scan time is strong evidence the file was detected locally; a quarantine event at the moment of attempted execution is evidence the file landed on disk but did not run.
Outbound beacon or exfiltration signals on the same recipient after the delivery. The C2 Beacon Investigation and Data Exfiltration Investigation runbooks are the pivot targets when the network-only surface shows a beacon or data-movement pattern emerging on the recipient in the minutes or hours after the file arrived. An emergent outbound beacon or an exfiltration-shaped upload following a malicious-file delivery is strong evidence the file was executed and established an active session.
User-session context. When the delivery rode an interactive protocol — a browser download, an email client opening an attachment, a user double-clicking an installer — the logged-in user at the time of the delivery is relevant to the disposition. A delivery to a software-distribution service account is a different problem from a delivery to a finance user's interactive session.

When the long-term archive storage described in MetaDefender Core file scanning — Post-scan file handling is enabled and the file is retained in the configured S3 bucket, the analyst retrieves the original bytes for forensic review — hash re-verification, static analysis, signature-check against known threat samples, sandbox detonation. Retrieval is a manual action outside the MetaDefender NDR user interface, against the configured archive bucket. When storage is off by default and no post-scan archive exists, the forensic question depends on whether the recipient host still has a copy on disk — another EDR or endpoint-inventory question.

The analyst records each post-delivery source consulted and its finding. "EDR process tree on recipient shows no execution of invoice-2025-11.pdf within four hours of arrival; Windows Defender quarantined the file at 14:28 with threat name Trojan:PDF/Emotet.Gen!A (matching the MetaDefender verdict); no outbound beacon or exfiltration signals from the recipient" is the shape of a disposition-closing record.

8. Cross-reference the threat name against known campaigns and request PCAP when evidence gaps remain

The canonical threat name from mdcore.<sha256>.threat_name identifies a malware family (or, for PUA or heuristic verdicts, a classification). The analyst cross-references the name against the organization's threat-intelligence context — the SOC's campaign-tracking notes, the external threat-intelligence subscriptions the organization consumes, and OPSWAT InSights content when a TIDB match named an actor cluster. The purpose of the cross-reference is twofold: it confirms whether the family has been observed on the organization's network before (a campaign in progress), and it provides tactical context (the family's typical delivery vectors, its typical post-execution behavior, its known command-and-control infrastructure) that guides the rest of the investigation and the response plan.

Commodity malware families. Emotet, TrickBot, IcedID, Qakbot, RedLine, AsyncRAT, DarkComet, and similar families carry well-documented playbooks. The presence of a known commodity name suggests a known response — block the delivery channel, isolate the recipient, hunt for the family's known persistence mechanisms on the recipient.
Document-exploit verdicts. A PDF, Office-document, or Rich Text Format file flagged with an exploit name (Exploit.CVE-2023-XXXX, Exploit.Office.Generic) is an attempted code-execution payload rather than a direct executable. The response priority is confirming whether the document was opened on the recipient and, if so, whether a follow-on payload was retrieved.
PUA and heuristic verdicts. PUA.Generic, Adware.Generic, and HEUR:Trojan.* classifications are weaker classifications that depend on the deployment's tolerance for potentially-unwanted applications and on whether the file matches an expected software set. Policy-driven allowlists at the endpoint-antivirus level often handle these verdicts without SOC involvement; a SOC-visible MD Core Low alert on a PUA verdict is usually a tuning candidate rather than an incident candidate.
Unknown or bespoke threat names. A threat name that does not match any known family and was flagged by only one or two engines is the highest-uncertainty case. The cross-reference often fails at this step; the decision rests on the other evidence in the runbook (delivery context, recipient population, IOC enrichment, post-delivery evidence).

When the session evidence from step 3 is insufficient — the delivery rode an encrypted carrier with no usable SNI or hostname, the filename from fileinfo.filename is a generic file.bin or missing, or the protocol parser did not populate the expected session row — the analyst requests a PCAP for the flow's time window through the organization's PCAP request workflow. PCAP availability is configuration-dependent and selective on MetaDefender NDR (see Alert, Flow, and PCAP Pivoting), so not every flow has a retained PCAP; when one is available, the analyst inspects the file magic bytes at the start of the transfer, the content-type headers for any inner protocol, and the overall transfer cadence to corroborate the file-type and size the FileInfo record reports. When a PCAP is unavailable, the investigation concludes on the evidence already gathered; the analyst explicitly records the gap in the ticket so a disposition on partial evidence is traceable.

Decision Tree

The analyst records one of four outcomes. Each branch lists the minimum artifacts captured before the ticket is closed.

Escalate — confirmed or probable malware delivery. The disposition when any of the following holds: the alert is IOC-Critical (C2 or InSights match on the hash, the delivering endpoint, or the recipient) on any tier; the alert is High-tier (six or more positive engines) with a recognizable commodity-family threat name on a Tier 1 or Tier 2 asset; two or more independent indicators converge (a named commodity-family verdict, an unfamiliar delivery endpoint, a coordinated multi-recipient delivery pattern, an emergent outbound beacon or exfiltration signal on the recipient, an EDR process-creation event on the recipient); or the population pivot in step 4 surfaced the same hash on multiple recipients with no sanctioned distribution channel. The analyst opens an incident response (IR) ticket, requests endpoint isolation for the recipient (or recipients), hands the host off to forensic recovery, blocks the file hash at the perimeter and any in-line antivirus layer the organization operates, blocks the delivering URL or domain when the organization's policy allows indicator-based blocking, retrieves the archived file from long-term S3 storage when archive-after-scan is enabled, engages the organization's mail-security or web-proxy team when the delivery rode an SMTP or HTTP channel they operate, and transfers the evidence record and pivot tabs into the incident. The Escalate branch is where this runbook ends and incident-response procedures take over.
Monitor — suspicious but not conclusive. The disposition when the evidence is partial: a Medium-tier alert on an unfamiliar file with no IOC corroboration, no recognizable threat-name family, and no post-delivery execution evidence; a High-tier alert where the delivery path is plausibly legitimate (a known software vendor host, a sanctioned internal distribution server) but the specific file has not been positively identified; a Low-tier alert where one corroborating signal exists (an uncommon recipient, an unfamiliar delivery endpoint) but the rest of the evidence is clean. The analyst records the observation in the ticket, leaves the Hunt tabs open, schedules a follow-up review (typically within four to twelve hours for High severity and twenty-four hours for Medium or Low severity), and watches for re-occurrence, emergent recipient-host signals, or new corroboration. When a corroborating signal surfaces within the review window — the hash re-delivered to another recipient, an outbound beacon on the recipient, an EDR quarantine event, an IOC feed update tagging the hash — the analyst re-enters at step 1 with the accumulated context and re-evaluates. When no new evidence surfaces, the disposition moves to close as benign.
Close as benign — identified legitimate explanation. The disposition when the evidence positively identifies a sanctioned file-distribution pattern: the file is a recognized legitimate installer (a signed vendor package, a known internal build artifact, a sanctioned document) delivered through a sanctioned channel (a corporate update server, an approved business-partner portal, an enterprise mail channel to an expected recipient), the recipient is an expected participant in that channel, and the MetaDefender verdict is a heuristic flag that disagrees with broader AV consensus or a PUA classification that matches the organization's tolerance. The analyst records the specific fields that justify the conclusion in the ticket — "file AcmeSoftwareUpdate-v4.12.18.msi, SHA-256 ..., delivered inbound over HTTPS from updates.acme.example.com (ASN 16509, SNI matches corporate vendor portal), recipient 10.40.12.88 is subscribed to Acme's update channel per asset inventory, 2 of 30 engines flagging with HEUR:PUA.Generic against 28 clean verdicts, Windows Defender on the recipient reports no quarantine or block, closing as benign" is the shape of a defensible close-note — so later readers can reopen the conclusion when one of those fields changes.
Tune the rule — recurring benign pattern with a scoped policy fix. The disposition when the same benign file-distribution pattern has been confirmed multiple times across the same population, the source of the noise is understood (a specific vendor's installer signature regularly tripping a single engine's heuristic, a specific PUA category consistently flagged despite policy-level acceptance, a specific high-volume content type the organization does not need scanned), and the MetaDefender Core tuning surface supports a scoped exclusion. Relevant tuning levers exposed through Policy and documented in MetaDefender Core File Scanning include the Multipurpose Internet Mail Extensions (MIME) skip-list (exact-match and prefix-match), the maximum file-size cap, and the deployment-mode engine set itself. Tuning is a detection-engineering action, not a triage shortcut: the analyst opens a follow-up task against the MetaDefender integration's Policy configuration rather than tuning inline, submits the change through the organization's peer-review workflow, and keeps the alert live until the tuned policy deploys. The default disposition for a single confirmed-benign alert is close, not tune — a single occurrence does not justify reducing coverage, and reducing coverage at the scanner level affects every future delivery of the matched pattern. A Low-tier alert on a PUA classification is triaged through close unless the same pattern produces sustained alert volume.

Every branch is recorded in the incident-management system. The runbook reference, the disposition, the asset context, the verdict / vendor-agreement / IOC evidence, the population-scope reading, the post-delivery evidence, and the pivot tab references form the minimum record. When the disposition is Escalate, the record hands off directly into the incident.

Common False-Positive Patterns

A material share of MD Core alerts — especially at the Low tier and a meaningful fraction at the Medium tier — have benign explanations. Recognizing the patterns saves investigation time and keeps analysts from over-escalating legitimate deliveries.

Legitimate installers flagged by a minority of engines. Commercial installers bundling common installer frameworks (Inno Setup, InstallShield, NSIS, WiX), self-extracting archives, and installer shims regularly trip a small number of AV heuristics because the frameworks they use are also used by malicious distributions. The verdict is usually one or two engines with generic heuristic labels (HEUR:*.Generic, Packer.*, Application.Heur.*) against a much larger clean consensus. Disposition: close when the publisher identity, the signing authority, the delivery channel, and the expected-software-set match. Tuning is not usually the right response because the pattern is publisher-specific rather than population-wide.
Development tools and build artifacts tripping heuristics. Compilers, debuggers, reverse-engineering tools, penetration-testing toolkits held in developer inventory, red-team frameworks stored on a security-team asset, and unsigned build artifacts produced by internal continuous-integration pipelines regularly trigger MD Core verdicts. Disposition: close once the source (developer workstation, internal build pipeline, security-team asset) and the file identity are confirmed. Tune the policy only when a specific internal build pipeline produces sustained volume on a well-identified hash set; the tuning lever is scoped to the hash or the recipient rather than the verdict.
Potentially-unwanted applications (PUAs) inside organizational tolerance. Vendor toolbars, opt-out bundleware, browser extensions with telemetry, and consumer utilities flagged as PUA by vendors with aggressive PUA policies appear at the Low and Medium tiers. Whether they are false positives depends on the organization's policy — a SOC that tolerates PUAs on user workstations treats the alerts as low-priority close-outs; a SOC that enforces a strict software catalog treats the same alerts as a policy-enforcement surface. Disposition: close aligned with the organization's PUA policy; escalate to endpoint-management when the PUA reached a host that should not carry it.
Sanctioned document downloads flagged as document exploits. Industry-standard document templates that embed macros (financial-reporting spreadsheets, procurement forms, training materials), vendor-provided PDFs with embedded JavaScript for form interactivity, and Office documents from sanctioned internal document-management systems occasionally carry structural properties that heuristic engines flag as exploit-shaped. Disposition: close when the source (an internal document-management URL, a known-vendor portal), the recipient (a user whose role expects the document), and the document identity are all consistent.
Legitimate binaries downloaded by automated patching infrastructure. Operating-system update servers, endpoint-management update channels, and vendor-provided patch distributions deliver binaries whose signatures and heuristic footprints sometimes trip isolated engines. The recipient is usually an update-agent service account rather than an interactive user, and the delivering endpoint resolves to the vendor's update infrastructure. Disposition: close once the update-channel identity is confirmed.
Cached verdict on a later-reclassified file. A hash-lookup-first cache hit with a stale scan_time may carry a verdict that MetaDefender has since updated — either a clean file that a post-scan signature reclassified, or (less often) a flagged file that a post-scan signature declassified. The file's current verdict may differ from the cached one the MD Core enrichment propagated. Disposition: confirm the current verdict through the MetaDefender console (via data_id) before recording a final disposition; re-submit the file for a fresh scan when the organization's policy allows it.
Red-team, penetration-testing, and malware-research activity. Authorized internal security activity produces MD Core alerts by design — red-team toolkits contain real malware samples and authorized malware-analysis workflows transmit real threats by design. Disposition: close once the activity is confirmed with the red-team, the vulnerability-management program, or the malware-research team. Every SOC maintains a communication channel with internal security teams so these alerts are identifiable on sight.

Closing on a false-positive pattern still requires the runbook's evidence record. "Looks like a legitimate installer" is not a disposition; "file AcmeSoftwareUpdate-v4.12.18.msi, SHA-256 ..., signed by Acme Corporation, delivered from updates.acme.example.com matching sanctioned Acme update channel, recipient is subscribed per asset inventory, 2 of 30 engines flagging with heuristic labels against 28 clean verdicts, closing as benign" is.