When Malicious Code Hits a Defense Contractor

Word count: ~1,850 Specificity markers hit: (1) NIST/CMMC control references — SI.L2-3.14.2, SI.L2-3.14.3, IR.L2-3.6.2, DFARS 252.204-7012 (2) Cost/time estimates — 72-hour DC3 reporting window, EDR $8–$25/endpoint/month (3) Tool/product names — CrowdStrike Falcon, Microsoft Defender for Endpoint, SentinelOne, VirusTotal (4) Common mistake — reimaging before capturing forensic evidence (5) Decision point — when malicious code triggers DC3 reporting

---

When Malicious Code Hits a Defense Contractor

You get the alert. Malware detected on a workstation in your CUI environment. What you do in the next two hours determines whether this is a contained incident or a reportable breach.

Defense contractors have obligations that most organizations don't: the 72-hour DC3 reporting clock under DFARS 252.204-7012, the forensic preservation requirement, and the potential contractual notification to your prime. These don't give you a pass on getting containment right, but they do change your response sequence in ways that matter.

Here's how to think about malicious code — what CMMC requires for protection, how different types behave, and what you do when the defenses don't catch it in time.

What CMMC Requires

The System and Information Integrity (SI) domain has two controls that directly govern malicious code:

SI.L2-3.14.2 requires you to employ malicious code protection mechanisms at appropriate locations within your information systems, update the mechanisms when new releases are available, and configure them to perform periodic scans and real-time scanning of files from external sources.

Translation: anti-malware on every endpoint in your CUI environment, with automatic signature updates and real-time scanning enabled. Endpoint Detection and Response (EDR) platforms — CrowdStrike Falcon, Microsoft Defender for Endpoint, or SentinelOne — are increasingly the standard for organizations seeking CMMC Level 2. Traditional anti-virus catches known signatures; EDR catches behavioral anomalies, which is what catches novel threats. EDR licensing runs $8–$25 per endpoint per month depending on the platform and feature tier.

SI.L2-3.14.3 requires you to address the receipt of false positives during malicious code detection and any resulting potential impact on system availability. In plain terms: don't configure your endpoint protection so aggressively that it blocks legitimate tools and creates operational disruptions, but also have a process for reviewing and resolving false positive determinations — and document it.

The detection controls are only part of the picture. What happens after detection is where most organizations are underprepared.

What Different Malware Types Do

Understanding the behavior of different malware types tells you what to look for and how to respond.

Ransomware encrypts files and demands payment. The primary concern for defense contractors isn't the ransom — it's the period between initial access and encryption when the attacker was in your environment, potentially exfiltrating CUI before triggering the encryption payload. Modern ransomware actors routinely spend days to weeks in a network before encrypting, using that time to steal data they can threaten to publish (double extortion). A ransomware event on a CUI system is almost always a DC3-reportable incident.

Trojans and remote access tools (RATs) establish persistence and create backdoors for attacker control. They often sit quiet for extended periods. When an EDR detects one, your immediate question is: how long has it been there, and what has it been doing? Check your logs for the past 30–60 days from that endpoint.

Infostealers are designed specifically to harvest credentials, browser data, and files. They frequently target saved passwords in browsers and memory, which can yield credentials for CUI systems even if the infostealer itself was on a non-CUI machine. If an infostealer fires on any machine in your environment, check whether the stolen credentials had access to CUI systems.

Worms self-replicate across network connections. A worm on one machine in your CUI environment may quickly reach adjacent systems. Your immediate priority is containment — isolate the affected segment — before the worm spreads to additional CUI systems and makes scope assessment impossible.

Spyware and keyloggers capture user activity. If a keylogger has been running on a workstation used to access CUI, assume credentials and potentially CUI content have been captured. That's an exfiltration event, which triggers DC3 reporting.

The Response Sequence

When your EDR or SIEM fires a malware alert, work through this sequence:

Step 1: Assess, Don't Panic

Confirm the alert is real. EDR behavioral detections occasionally fire on legitimate tools. Check the EDR console: what process triggered the alert, what behavior was flagged, what's the confidence level? A medium-confidence alert on a known third-party tool is different from a high-confidence detection of process injection and C2 communication.

If this is confirmed malware, document the time of your discovery. This is the start of your 72-hour DC3 reporting window if CUI is involved.

Step 2: Isolate the Affected System

Remove the affected endpoint from the network. Most EDR platforms let you do this remotely with a "network contain" command — the machine stays powered on and accessible to your security team via the EDR agent, but all other network connections are blocked. Do not power off the machine; volatile memory contains forensic evidence (running processes, network connections, encryption keys in memory) that is lost on shutdown.

If your EDR doesn't support network containment, physically unplug the network cable. Again — leave it powered on.

Step 3: Preserve Forensic Evidence Before Anything Else

This is where defense contractors diverge from standard IT incident response. DFARS 252.204-7012 requires you to preserve images of all systems involved in a cyber incident for 90 days, available for DoD inspection on request.

Before you reimage, run the remediation, or restore from backup, capture a forensic image of the affected system. Your IR provider or internal security team should do this with a tool like FTK Imager or dc3dd. The image captures the full disk state at the time of isolation, preserving evidence of what the malware did.

Skipping this step to restore service faster is the most common mistake in defense contractor incident response — and it's a contractual violation, not just a best practice failure. If DC3 later asks for system images and you've already reimaged, you're in breach of your DFARS obligations.

Step 4: Determine the Scope

Once the affected system is isolated and imaged, assess the blast radius:

• What user account(s) were active on the system?
• What CUI systems, file shares, or applications did those accounts have access to?
• Did the malware make network connections? To where? (Check firewall logs, EDR telemetry)
• Are there signs of lateral movement? (Authentication events on other systems from the compromised machine's IP or user account)
• How long was the malware active? (Check EDR process start times, system event logs)

The scope assessment answers the critical question: does this trigger DC3 reporting?

Step 5: DC3 Reporting Decision

Under DFARS 252.204-7012, you must report to DC3 within 72 hours if the incident involves covered defense information (CDI) — which includes CUI on your systems covered by that contract.

Report if: - Malware was active on a system that stores, processes, or transmits CUI - The malware made outbound network connections (potential exfiltration) - Credentials with CUI access were potentially compromised - You have reason to believe CDI was accessed or exfiltrated

You do NOT report to DC3 if: - The malware was detected and blocked before execution on a fully isolated CRMA (non-CUI asset) with no path to CUI - It was a false positive

When in doubt, report. The downside of an unnecessary DC3 report is minor administrative overhead. The downside of missing a required report is contract liability.

File the report at the DIBNet portal (dibnet.dod.mil). You'll need your CAGE code and a narrative describing the incident. If your prime contractor is involved, notify them as well — your contract may specify the notification obligation.

Step 6: Remediate Properly

After forensic preservation and scope assessment, remediate:

1. Remove the malware (EDR-guided remediation, manual removal, or full reimage)
2. Patch the vulnerability or misconfiguration that allowed initial access
3. Reset credentials for any accounts that ran on the affected system
4. Block identified indicators of compromise (file hashes, IPs, domains) at your firewall and email gateway
5. Verify clean state on the endpoint before reconnecting to the network
6. Review other systems for the same indicators

If the malware arrived via a phishing email, pull that email from every mailbox it was delivered to using admin mail search. The same payload may be sitting unclicked in a dozen other inboxes.

Step 7: Close the Loop

Complete your incident documentation: timeline, systems involved, data potentially exposed, actions taken, outcome, DC3 report number if filed. Update your risk register and your POA&M if you identified a control gap that contributed to the incident. Review your email filtering, endpoint configuration, and patch status to address whatever allowed initial access.

Common Mistake: Reimage First, Ask Questions Later

The instinct when malware fires is to restore service as quickly as possible. Reimage the machine, restore from backup, get the user back to work. That's the right instinct for an IT help desk, but it's wrong for a defense contractor.

Reimaging destroys the forensic evidence DFARS requires you to preserve. It also destroys the evidence you need for your own scope assessment — without a forensic image, you often can't determine what the malware was doing or how long it was active, which means you can't accurately assess whether CUI was accessed.

The right sequence: isolate, preserve, assess, report (if required), then remediate. That order feels slow when a user is screaming about their encrypted files, but it's the sequence your obligations require.

What Your Assessor Expects

For SI.L2-3.14.2, your assessor will verify that anti-malware or EDR is deployed on all CUI systems with automatic updates enabled and real-time scanning active. They may check configuration screenshots or pull reports from your EDR console showing protection status across your endpoint inventory. Systems that are "deployed but not configured" — with signatures out of date or real-time scanning disabled — are findings.

For IR.L2-3.6.2 (incident tracking and reporting), if you've had any malware incidents since your last assessment, they may ask how you handled them. Documented incidents with clear timelines, containment actions, and reporting decisions (including rationale for not reporting to DC3 if that was the decision) demonstrate mature incident handling.

What they're not expecting is that you've never had a detection. EDR solutions on well-maintained systems detect things regularly — adware, potentially unwanted programs, policy violations. A completely empty incident log is often a sign that detection isn't working, not that the environment is perfectly clean. Show your log.

---

CTA: Check that every system in your CUI environment has EDR deployed with real-time scanning enabled and signatures current. Pull an inventory report from your endpoint management platform and keep it as assessment evidence.