SOC138 | Detected Suspicious Xls File

Platform: LetsDefend Date Investigated: March 13, 2021 Verdict: True Positive ✅ Contained: Yes

Summary

A suspicious Excel attachment, ORDER SHEET and SPEC.xlsm, landed on endpoint Sofia (172.16.17.56) and tripped the malware detection rule for suspicious Xls files. The investigation needed to confirm three things, whether the file itself was actually malicious, whether it reached out to a command and control server, and whether it had been contained or was still live on the device.

Alert Details

Field	Value
Event ID	77
Event Time	Mar 13, 2021, 08:20 PM
Rule	SOC138, Detected Suspicious Xls File
Source	Sofia, 172.16.17.56
File	ORDER SHEET and SPEC.xlsm
File Hash, MD5	7ccf88c0bbe3b29bf19d877c4596a8d4

Investigation Steps

1. Hash Reputation Check Took the file's MD5 hash and ran it through VirusTotal. 45 out of 63 security vendors flagged it as malicious. That ratio alone is strong evidence this is not a normal spreadsheet, it is a known piece of malware circulating widely enough that most major engines already carry a signature for it.

2. Network Traffic Review Filtered the firewall logs by the source IP. Found an outbound connection from 172.16.17.56 on port 52155 to 177.53.143.89 on port 443, timestamped Mar 13, 2021, 08:20 PM, the exact same minute as the alert itself. That timing match is what ties this connection directly to the malicious file executing, rather than being unrelated background traffic. This is the C2 callout.

3. Endpoint History Review Checked the Processes tab on Endpoint Security. Found a process named PowersheLL.exe, no process ID, no parent process, configured to run at system boot. Worth noting the odd capitalization, real PowerShell is lowercase, this is a fake dressed up to look legitimate at a glance. This is a persistence mechanism, the malware was set to relaunch every time the machine booted, which is also why a single cleanup pass would not have been enough on its own.

One honest gap to flag here, the timestamp on that process entry reads October 19, 2020, about five months before the alert fired. There is no clean explanation for that gap from the data alone, it may be a quirk in how this training case was built. Either way, the process being unsigned, parentless, and set to launch at boot is reason enough to treat it as the persistence mechanism behind this infection, regardless of the exact date it shows.

4. Quarantine Status Check Device Action on the original alert reads Allowed, meaning the file was not automatically blocked or quarantined when it arrived. Combined with the boot persistence finding, cleanup needed manual intervention rather than relying on an automated response.

Why This Matters

This case follows a classic malicious document chain, a trojanized attachment that establishes persistence through a disguised process at boot. LetsDefend classifies this alert type under MITRE ATT&CK T1112, Modify Registry, Defense Evasion, with a default severity of Medium. The detection ratio confirmed the file's intent, the firewall log confirmed it actually phoned home, and the boot persistent process explained why the infection would not have just gone away once the file was opened.

Playbook Answers

• ✅ Check If Someone Requested the C2

• ✅ Analyze Malware

• ✅ Check if the Malware is Quarantined and Cleaned

Actions Taken

The device, 172.16.17.56, was contained since the file was not automatically quarantined and had already established persistence. Manual containment was necessary specifically because the automated response did not catch this one.

Verdict and Closing Rationale

True Positive. A 45 of 63 VirusTotal detection ratio confirms the file itself is malicious, the firewall log shows it phoning out to a C2 address at the exact same timestamp as the alert, and Endpoint Security shows a disguised process configured to launch at every boot with the file never having been quarantined automatically. All three playbook checks point the same direction, this device needed to be contained.

Takeaway for Future Cases

What made this case solid was not the VirusTotal ratio on its own, it was lining up three separate sources, hash reputation, firewall timing, and endpoint process history, and watching them agree with each other. A high VT score tells you the file is bad. The firewall timestamp tells you it actually executed and called out. The process entry tells you why it would not just disappear after one reboot. Any one of those alone is suggestive, all three together is what makes a containment decision easy to defend.