GbengaCyber/MDE-Malware-Analysis---Detection-Investigation-Remediation
GitHub: GbengaCyber/MDE-Malware-Analysis---Detection-Investigation-Remediation
Stars: 0 | Forks: 0
# MDE Malware Analysis: Detection - Investigation & Remediation
**Name:** Gbenga Abraham
**Target roles:** SOC Analyst | Incident Responder | Security Operations Analyst
**LinkedIn:** [linkedin.com/in/gbenga-abraham-a31a40250](https://www.linkedin.com/in/gbenga-abraham-a31a40250)
## Who I Am
I am a security analyst with hands on experience in malware incident response, threat detection, and investigation using Microsoft Defender for Endpoint and Microsoft Sentinel. I built this portfolio to show real work, not certifications, not course completions, but an actual investigation I ran myself in a live environment with a real malware sample.
I provisioned the lab environment in Azure from scratch, sourced a real malware sample, executed it, triaged the alerts, contained the threat, and documented everything. The screenshots throughout this page are evidence from each step of the investigation.
## Business Context
This lab simulates the type of security incident that happens inside real organisations
every day. A user receives a file that looks legitimate, opens it, and within seconds
an attacker has access to their saved passwords, has set the malware to restart
automatically after every reboot, and has begun downloading tools to take full remote
control of the machine.
For a business this means stolen credentials can be used to access email, financial
systems, customer data, or internal applications. If the attacker gets remote control
they can move to other machines on the network, steal files, or deploy ransomware.
The longer the infection goes undetected the more damage is done.
In this lab I played the role of the SOC analyst who receives the alert, investigates
what happened, stops the attacker from doing further damage, removes the malware,
and documents everything so the same attack can be detected faster next time.
## Tools and Platforms
Microsoft Defender for Endpoint and Defender XDR for alert triage and incident investigation. Microsoft Sentinel with KQL for threat hunting across raw telemetry. Azure for building and hardening the isolated malware analysis environment. MalwareBazaar for sourcing the real malware sample safely. VirusTotal for pre execution sample intelligence. Microsoft Graph PowerShell for containment actions.
## Lab: SalatStealer Infostealer on Azure VM
I built an isolated malware analysis lab in Azure, onboarded it to Microsoft Defender for Endpoint, sourced a real SalatStealer sample from MalwareBazaar, and detonated it in a controlled environment.
The sample was zero day at time of download with zero VirusTotal detections. It was packaged with UPX compression to bypass static antivirus scanning. Within 8 seconds of execution the malware had established six persistence mechanisms, accessed Chrome browser saved passwords, disabled Windows Defender scanning on its own directories, disabled UAC, disabled Windows Recovery, and attempted to download a remote access toolkit from GitLab. Microsoft Defender for Endpoint raised a High severity incident with a priority score of 100 out of 100 and 12 active alerts.
**Malware family:** SalatStealer: detected as Trojan:Win32/SalatStealer!pz
**Platform:** Azure VM with Microsoft Defender for Endpoint and Microsoft Sentinel
**Verdict:** True Positive: Active credential stealing infection
**MITRE ATT&CK techniques observed:** T1555.003 Credentials from Web Browsers, T1053.005 Scheduled Task, T1547.001 Registry Run Keys, T1562.001 Impair Defences, T1036.005 Masquerade Match Legitimate Name, T1490 Inhibit System Recovery, T1105 Ingress Tool Transfer, T1548.002 Bypass UAC
## Step 1: Lab Provisioned in Azure
I created a Windows 10 virtual machine in Azure inside a dedicated resource group called malware lab rg. The region is Canada East. The VM is named soclab which is the same name that appears later in MDE as the device under investigation. Before doing anything else I locked RDP access to my IP address only through NSG rules so the VM could not be accessed by anyone else on the internet.
## Step 2: RDP Locked to Analyst IP Only
This screenshot shows the NSG inbound rule for RDP. The source is set to My IP address rather than Any. This is a critical hardening step, it means only the analyst machine can connect to this VM remotely. No internet scanner or attacker can reach it. This step must happen before downloading or running any malware sample.
## Step 3: Sample Intelligence from MalwareBazaar
Before executing anything I gathered intelligence on the sample. The file name is Dior fix.exe, a social engineering lure pretending to be a brand software patch. First seen is the same day as this lab which makes it a zero day submission with no prior analysis on any platform. The signature shows SalatStealer. The TrID result shows UPX compressed which explains why the VirusTotal detection count was zero, the real malicious payload is hidden inside the UPX wrapper and only unpacks in memory at runtime.
## Step 4: MalwareLab Folder Created Inside the VM
All sample work was contained to C:\MalwareLab\ inside the isolated VM. The folder was created fresh for this lab. Nothing from this folder ever touched the analyst host machine. The date modified confirms it was set up on the day of the investigation.
## Step 5: Malware Executed: SmartScreen Fires First
Before MDE even raised an alert, Windows SmartScreen fired as the first detection layer. The file has no digital signature and shows Unknown publisher. I noted the exact time of clicking Run anyway as T plus zero, the start of the IR timeline. This popup is exactly what a real user would see if they received this file through a phishing email and tried to open it.
## Step 6: MDE Incident Alert Fired
## What the Malware Did: The Full Attack in 8 Seconds
At 2:40:25 PM the malware launched from C:\MalwareLab\. Eight seconds later, at 2:40:33 PM, it had already done the following.
It copied itself three times and gave each copy the name of a real Windows system process, SearchIndexer.exe, backgroundTaskHost.exe, and winlogon.exe. These are legitimate Windows process names but the malware placed them in completely wrong locations. The real files live in C:\Windows\System32\. The fake copies were placed in Program Files, AppData, and other non-system locations. MDE flagged all three immediately with the note that each was an unsigned file with the same name as a common Windows file and a confirmed path mismatch. This technique is called file masquerading, MITRE T1036.005.
At the same time it created three scheduled tasks and three registry Run keys all pointing to these fake binaries. This is dual persistence, if you find and remove the scheduled tasks but miss the Run keys the malware restarts on the next login anyway. Six persistence mechanisms in 8 seconds is not an accident. The attacker designed redundancy so that partial remediation leaves the infection active.
At 2:40:41 PM the fake winlogon.exe opened Chrome's Login Data file with full read access. Login Data is the SQLite database where Chrome stores every saved username and password. The malware read it. Every password the user had saved in Chrome was accessible to the attacker. MDE raised the alert: Possible theft of passwords and other sensitive web browser information.
PowerShell was then used to add the malware's directories to Windows Defender's exclusion list so AV would stop scanning those folders. It ran ReAgentc.exe to disable Windows Recovery so the machine could not be reset to a clean state. It set the EnableLUA registry value to zero which disabled UAC entirely, no more permission prompts for any action. And it attempted to download a toolkit from GitLab including 7zip for file compression, RDP libraries for remote control, and ffmpeg for screen recording. The NSG outbound block prevented that download in this lab. In a real unprotected network it would have succeeded and the attacker would have had full remote visual control of the machine.
The scheduled tasks continued firing every three minutes at 2:43, 2:46, and 2:49 PM throughout the investigation, re-executing the fake binaries each time.
## Step 7: Device Isolated in MDE
After confirming True Positive the device was isolated through the MDE portal. The device page showed 12 active alerts and Risk level High. Isolation cuts all network access except the MDE communication channel which stays active so investigation continues. The attacker loses their connection. Remote AV scans can still be initiated without needing RDP access to the machine.
## Step 8: SHA256 Hash Blocked as MDE Indicator
The final containment step was blocking the SHA256 hash as a custom indicator in MDE. The hash now appears as a managed indicator. Every device enrolled in the tenant will automatically block this file if it is encountered anywhere else. The same payload cannot execute on any other machine in the organisation.
## KQL Queries Used in the Investigation
These queries were run in MDE Advanced Hunting to reconstruct the full attack chain from raw telemetry.
**Credential access confirmation**
DeviceFileEvents
| where DeviceName contains "soclab"
| where Timestamp > datetime(2026-05-23T14:40:00)
| where FolderPath has_any (
"Login Data", "Cookies", "Web Data", "logins.json", "key4.db")
| where InitiatingProcessFileName !in~ (
"chrome.exe","firefox.exe","msedge.exe")
| project Timestamp, ActionType, FileName,
FolderPath, InitiatingProcessFileName
| order by Timestamp asc
**Persistence registry writes**
DeviceRegistryEvents
| where DeviceName contains "soclab"
| where Timestamp > datetime(2026-05-23T14:40:00)
| where RegistryKey has_any (
"CurrentVersion\\Run", "EnableLUA", "ExclusionPath")
| project Timestamp, ActionType, RegistryKey,
RegistryValueName, RegistryValueData,
InitiatingProcessFileName
| order by Timestamp asc
**Scheduled task creation**
DeviceEvents
| where DeviceName contains "soclab"
| where Timestamp > datetime(2026-05-23T14:40:00)
| where ActionType == "ScheduledTaskCreated"
| project Timestamp, AdditionalFields, InitiatingProcessFileName
| order by Timestamp asc
## IOCs
| Type | Value |
|---|---|
| SHA256 | 1963aa0f51baebbc5f9a04bf57e0358dda6c80e16055a9654bf9a4cae08b4415 |
| SHA1 | c3c8ddee1d679cc2d7a6ea93997a199a59c48f33 |
| MD5 | aee4431579b6a0bbabe55e3e5113af39 |
| File | C:\Program Files (x86)\WindowsPowerShell\SearchIndexer.exe |
| File | C:\Users\labuser\AppData\Local\PlaceholderTileLogoFolder\backgroundTaskHost.exe |
| File | C:\Program Files (x86)\Microsoft\winlogon.exe |
| Registry | HKCU\...\CurrentVersion\Run .. SearchIndexer |
| Registry | HKCU\...\CurrentVersion\Run .. backgroundTaskHost |
| Registry | HKCU\...\CurrentVersion\Run .. winlogon |
| Scheduled task | SearchIndexer |
| Scheduled task | backgroundTaskHost |
| Scheduled task | winlogon |
| URL | https://gitlab[.]com/webrat1/importantfiles/ |
| AV name | Trojan:Win32/SalatStealer!pz |
## What I Learned
Zero out of 71 on VirusTotal does not mean clean. This sample had no detections because it was UPX packed, submitted for the first time that day, and never previously analysed. The context was the real indicator, social engineering file name, zero day, unsigned binary. I always check the Behaviour tab on VirusTotal now, not just the detection count.
Persistence is redundant by design. Six mechanisms in 8 seconds is deliberate. Removing only the scheduled tasks leaves the Run keys active. Removing only the Run keys leaves the tasks firing. During eradication you must check every persistence location, Run keys, RunOnce, scheduled tasks, startup folders, and services.
The path is the tell. Every fake binary used a real Windows process name but the wrong path. winlogon.exe does not belong in Program Files. SearchIndexer.exe does not belong in WindowsPowerShell. If a system process name is running from anywhere other than System32 or the Windows folder that is worth investigating immediately.
AV fires after the fact. Defender AV did not detect the UPX packed file on disk. It only fired after the file unpacked itself in memory and began executing. MDE caught the behavioural patterns, credential access, persistence writes, Defender modification, that static AV had no way to detect. This is the real difference between antivirus and endpoint detection and response.
*All malware analysis was performed in an isolated Azure lab environment. No real user data or production systems were involved.*
## Step 2: RDP Locked to Analyst IP Only
This screenshot shows the NSG inbound rule for RDP. The source is set to My IP address rather than Any. This is a critical hardening step, it means only the analyst machine can connect to this VM remotely. No internet scanner or attacker can reach it. This step must happen before downloading or running any malware sample.
## Step 3: Sample Intelligence from MalwareBazaar
Before executing anything I gathered intelligence on the sample. The file name is Dior fix.exe, a social engineering lure pretending to be a brand software patch. First seen is the same day as this lab which makes it a zero day submission with no prior analysis on any platform. The signature shows SalatStealer. The TrID result shows UPX compressed which explains why the VirusTotal detection count was zero, the real malicious payload is hidden inside the UPX wrapper and only unpacks in memory at runtime.
## Step 4: MalwareLab Folder Created Inside the VM
All sample work was contained to C:\MalwareLab\ inside the isolated VM. The folder was created fresh for this lab. Nothing from this folder ever touched the analyst host machine. The date modified confirms it was set up on the day of the investigation.
## Step 5: Malware Executed: SmartScreen Fires First
Before MDE even raised an alert, Windows SmartScreen fired as the first detection layer. The file has no digital signature and shows Unknown publisher. I noted the exact time of clicking Run anyway as T plus zero, the start of the IR timeline. This popup is exactly what a real user would see if they received this file through a phishing email and tried to open it.
## Step 6: MDE Incident Alert Fired
## What the Malware Did: The Full Attack in 8 Seconds
At 2:40:25 PM the malware launched from C:\MalwareLab\. Eight seconds later, at 2:40:33 PM, it had already done the following.
It copied itself three times and gave each copy the name of a real Windows system process, SearchIndexer.exe, backgroundTaskHost.exe, and winlogon.exe. These are legitimate Windows process names but the malware placed them in completely wrong locations. The real files live in C:\Windows\System32\. The fake copies were placed in Program Files, AppData, and other non-system locations. MDE flagged all three immediately with the note that each was an unsigned file with the same name as a common Windows file and a confirmed path mismatch. This technique is called file masquerading, MITRE T1036.005.
At the same time it created three scheduled tasks and three registry Run keys all pointing to these fake binaries. This is dual persistence, if you find and remove the scheduled tasks but miss the Run keys the malware restarts on the next login anyway. Six persistence mechanisms in 8 seconds is not an accident. The attacker designed redundancy so that partial remediation leaves the infection active.
At 2:40:41 PM the fake winlogon.exe opened Chrome's Login Data file with full read access. Login Data is the SQLite database where Chrome stores every saved username and password. The malware read it. Every password the user had saved in Chrome was accessible to the attacker. MDE raised the alert: Possible theft of passwords and other sensitive web browser information.
PowerShell was then used to add the malware's directories to Windows Defender's exclusion list so AV would stop scanning those folders. It ran ReAgentc.exe to disable Windows Recovery so the machine could not be reset to a clean state. It set the EnableLUA registry value to zero which disabled UAC entirely, no more permission prompts for any action. And it attempted to download a toolkit from GitLab including 7zip for file compression, RDP libraries for remote control, and ffmpeg for screen recording. The NSG outbound block prevented that download in this lab. In a real unprotected network it would have succeeded and the attacker would have had full remote visual control of the machine.
The scheduled tasks continued firing every three minutes at 2:43, 2:46, and 2:49 PM throughout the investigation, re-executing the fake binaries each time.
## Step 7: Device Isolated in MDE
After confirming True Positive the device was isolated through the MDE portal. The device page showed 12 active alerts and Risk level High. Isolation cuts all network access except the MDE communication channel which stays active so investigation continues. The attacker loses their connection. Remote AV scans can still be initiated without needing RDP access to the machine.
## Step 8: SHA256 Hash Blocked as MDE Indicator
The final containment step was blocking the SHA256 hash as a custom indicator in MDE. The hash now appears as a managed indicator. Every device enrolled in the tenant will automatically block this file if it is encountered anywhere else. The same payload cannot execute on any other machine in the organisation.
## KQL Queries Used in the Investigation
These queries were run in MDE Advanced Hunting to reconstruct the full attack chain from raw telemetry.
**Credential access confirmation**
DeviceFileEvents
| where DeviceName contains "soclab"
| where Timestamp > datetime(2026-05-23T14:40:00)
| where FolderPath has_any (
"Login Data", "Cookies", "Web Data", "logins.json", "key4.db")
| where InitiatingProcessFileName !in~ (
"chrome.exe","firefox.exe","msedge.exe")
| project Timestamp, ActionType, FileName,
FolderPath, InitiatingProcessFileName
| order by Timestamp asc
**Persistence registry writes**
DeviceRegistryEvents
| where DeviceName contains "soclab"
| where Timestamp > datetime(2026-05-23T14:40:00)
| where RegistryKey has_any (
"CurrentVersion\\Run", "EnableLUA", "ExclusionPath")
| project Timestamp, ActionType, RegistryKey,
RegistryValueName, RegistryValueData,
InitiatingProcessFileName
| order by Timestamp asc
**Scheduled task creation**
DeviceEvents
| where DeviceName contains "soclab"
| where Timestamp > datetime(2026-05-23T14:40:00)
| where ActionType == "ScheduledTaskCreated"
| project Timestamp, AdditionalFields, InitiatingProcessFileName
| order by Timestamp asc
## IOCs
| Type | Value |
|---|---|
| SHA256 | 1963aa0f51baebbc5f9a04bf57e0358dda6c80e16055a9654bf9a4cae08b4415 |
| SHA1 | c3c8ddee1d679cc2d7a6ea93997a199a59c48f33 |
| MD5 | aee4431579b6a0bbabe55e3e5113af39 |
| File | C:\Program Files (x86)\WindowsPowerShell\SearchIndexer.exe |
| File | C:\Users\labuser\AppData\Local\PlaceholderTileLogoFolder\backgroundTaskHost.exe |
| File | C:\Program Files (x86)\Microsoft\winlogon.exe |
| Registry | HKCU\...\CurrentVersion\Run .. SearchIndexer |
| Registry | HKCU\...\CurrentVersion\Run .. backgroundTaskHost |
| Registry | HKCU\...\CurrentVersion\Run .. winlogon |
| Scheduled task | SearchIndexer |
| Scheduled task | backgroundTaskHost |
| Scheduled task | winlogon |
| URL | https://gitlab[.]com/webrat1/importantfiles/ |
| AV name | Trojan:Win32/SalatStealer!pz |
## What I Learned
Zero out of 71 on VirusTotal does not mean clean. This sample had no detections because it was UPX packed, submitted for the first time that day, and never previously analysed. The context was the real indicator, social engineering file name, zero day, unsigned binary. I always check the Behaviour tab on VirusTotal now, not just the detection count.
Persistence is redundant by design. Six mechanisms in 8 seconds is deliberate. Removing only the scheduled tasks leaves the Run keys active. Removing only the Run keys leaves the tasks firing. During eradication you must check every persistence location, Run keys, RunOnce, scheduled tasks, startup folders, and services.
The path is the tell. Every fake binary used a real Windows process name but the wrong path. winlogon.exe does not belong in Program Files. SearchIndexer.exe does not belong in WindowsPowerShell. If a system process name is running from anywhere other than System32 or the Windows folder that is worth investigating immediately.
AV fires after the fact. Defender AV did not detect the UPX packed file on disk. It only fired after the file unpacked itself in memory and began executing. MDE caught the behavioural patterns, credential access, persistence writes, Defender modification, that static AV had no way to detect. This is the real difference between antivirus and endpoint detection and response.
*All malware analysis was performed in an isolated Azure lab environment. No real user data or production systems were involved.*