312-50 Question 170
Single answer▪ Fileless Malware ConceptsDuring an internal assessment, a SOC analyst reports that several Windows 10 endpoints spawned powershell.exe from WINWORD.EXE shortly after users opened a phishing document. EDR telemetry shows the PowerShell process used the -EncodedCommand flag, made an outbound HTTPS connection, and then injected code into a legitimate process without dropping any executable to disk. Traditional antivirus did not alert. As the ethical hacker validating detection gaps, which finding BEST explains why this attack behaved like fileless malware and evaded signature-based AV?
- A
The attack primarily executed in memory using trusted tools like PowerShell and process injection, leaving little or no malicious file on disk for signature-based AV to scan.
- B
The attack was fileless because the phishing document was a Microsoft Word file rather than an executable, so antivirus products do not inspect it.
- C
The attack was fileless because HTTPS encryption prevents endpoint security tools from analyzing PowerShell behavior on the host.
- D
The attack was fileless because code injected into a legitimate process automatically becomes trusted by Windows Defender and cannot be detected.
Show answer and explanation
Correct answer: A
Explanation
The best answer is Option 1 because fileless malware commonly relies on living-off-the-land techniques, where trusted native tools such as PowerShell are abused to run malicious code in memory rather than dropping a traditional executable. In this scenario, the combination of WINWORD.EXE spawning powershell.exe, use of -EncodedCommand, outbound network activity, and code injection into a legitimate process is strongly consistent with fileless execution patterns. These attacks often evade legacy antivirus because signature-based engines are optimized for scanning files on disk, while fileless techniques emphasize memory-resident execution and legitimate host binaries. Defenders typically counter this with behavior-based monitoring, PowerShell Script Block Logging, AMSI integration, constrained PowerShell policies where appropriate, process creation auditing, and EDR memory/injection detection. Microsoft guidance on PowerShell logging and AMSI, as well as MITRE ATT&CK techniques such as PowerShell (T1059.001), Command and Scripting Interpreter, and Process Injection (T1055), align with this explanation.
- A. Correct.
Correct. This is the defining characteristic of many fileless malware techniques: abuse of legitimate interpreters or administrative tools such as PowerShell, WMI, or scripting engines to execute malicious logic directly in memory. Process injection into a legitimate process further reduces visibility and can help bypass controls that rely heavily on static file signatures. Because little or no payload is written to disk, traditional signature-based antivirus may miss the activity unless behavioral or memory-based detections are in place.
- B. Incorrect.
Incorrect. A Word document can absolutely be inspected by security tools, and malicious Office documents are a well-known infection vector. The fact that the initial lure was a document does not make the attack fileless. The fileless aspect is the in-memory execution of malicious code via PowerShell and injection, not the document format itself.
- C. Incorrect.
Incorrect. HTTPS may limit network inspection without SSL/TLS decryption, but endpoint tools can still analyze local process creation, command-line arguments, parent-child relationships, AMSI content, script block logging, memory behavior, and injection events. HTTPS alone does not make malware fileless.
- D. Incorrect.
Incorrect. Injecting code into a legitimate process does not automatically grant trust or immunity from detection. Modern EDR and Windows security controls can detect suspicious injection patterns, anomalous memory permissions, and unusual parent-child process behavior. This option reflects a common misconception that running inside a trusted process guarantees stealth.