ACSC Logo
© 2026 GEMXIT
GEMXIT Logo
Endpoint Security • AppData Execution • Microsoft Defender XDR

The Script Ran From AppData

The alert never arrived.

No ransomware note. No screaming antivirus banner. No dramatic pop-up on the user's screen. Just a quiet PowerShell process, a short command line, and a script path buried under C:\Users\...\AppData\Roaming.

To most people, AppData looked like clutter. To Agent Foskett, it looked like a question.

Why was a script running from a user-writable folder that most users never open?

Discuss endpoint security Back to briefings
Agent Foskett Microsoft Defender XDR AppData script investigation
Briefing summary

AppData is not malicious by itself. But when scripts, PowerShell, unusual parent processes and persistence all point back to AppData, the endpoint is giving investigators a trail to follow.

Script In AppData
PowerShell Execution
User-Writable Path
Persistence Check

AppData was not the attack

The folder was only the hiding place. The investigation starts with the behaviour that came from it.
User writable AppData gives users write access without needing local administrator rights. That makes it convenient for legitimate applications and attractive to attackers.
Easy to ignore Most users never browse AppData, and many defenders expect noisy application files to live there. Suspicious content can blend into normal clutter.
Behaviour matters The question was not whether AppData existed. The question was why a script in AppData launched PowerShell and changed the endpoint state.

What Defender XDR can show

A strong AppData investigation moves across process, file and registry evidence rather than relying on one alert.
DeviceProcessEvents Review process creation, parent-child relationships, command lines and suspicious interpreters running content from AppData.
DeviceFileEvents Identify scripts, executables, shortcuts and DLLs written into AppData, Temp, Startup or ProgramData paths.
DeviceRegistryEvents Check whether AppData paths were written into Run keys, RunOnce keys or other persistence locations.

Find scripts running from AppData

Start by looking for script interpreters and command shells referencing AppData in the command line.
find-scripts-running-from-appdata.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
DeviceProcessEvents
| where Timestamp > ago(30d)
| where FileName in~ (
    "powershell.exe",
    "pwsh.exe",
    "cmd.exe",
    "wscript.exe",
    "cscript.exe",
    "mshta.exe"
)
| where ProcessCommandLine has @"\AppData\"
| project
    Timestamp,
    DeviceName,
    AccountName,
    FileName,
    ProcessCommandLine,
    InitiatingProcessFileName,
    InitiatingProcessCommandLine
| order by Timestamp desc

The path changed the meaning

PowerShell alone is common. A script path under AppData changes the investigation.
PowerShell was not enough PowerShell is used by administrators, installers and attackers. The command line and file path decide whether the event deserves attention.
The folder was user-owned User profile paths can allow execution without admin rights. That lowers the barrier for payload staging and persistence.
The script had context The same filename in a managed scripts folder may be normal. In AppData after a browser or email event, it becomes suspicious.

Look for scripts written into AppData

Find scripts and executable content created or modified in AppData and nearby user-writable paths.
look-for-scripts-written-into-appdata.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
DeviceFileEvents
| where Timestamp > ago(30d)
| where ActionType in~ ("FileCreated", "FileModified", "FileRenamed")
| where FolderPath has @"\AppData\"
| where FileName has_any (
    ".ps1",
    ".vbs",
    ".js",
    ".jse",
    ".bat",
    ".cmd",
    ".lnk",
    ".exe",
    ".dll"
)
| project
    Timestamp,
    DeviceName,
    ActionType,
    FolderPath,
    FileName,
    SHA256,
    InitiatingProcessFileName,
    InitiatingProcessCommandLine
| order by Timestamp desc

The parent process told the story

The parent process often explains how the script arrived and why it ran.
Browser to PowerShell A browser spawning PowerShell can suggest a download, exploit chain, malicious ad, fake update or user-driven execution path.
Outlook to script host Email clients launching script interpreters deserve careful review, especially when attachments or links were involved.
Explorer to AppData Explorer can be normal, but it can also show a user double-clicking a staged file or shortcut from a hidden location.

Review suspicious parent processes

Look for common user applications launching PowerShell or script hosts.
review-suspicious-parent-processes.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29
  30. 30
  31. 31
  32. 32
  33. 33
  34. 34
DeviceProcessEvents
| where Timestamp > ago(30d)
| where FileName in~ (
    "powershell.exe",
    "pwsh.exe",
    "cmd.exe",
    "wscript.exe",
    "cscript.exe",
    "mshta.exe",
    "rundll32.exe"
)
| where InitiatingProcessFileName in~ (
    "outlook.exe",
    "winword.exe",
    "excel.exe",
    "powerpnt.exe",
    "chrome.exe",
    "msedge.exe",
    "firefox.exe",
    "teams.exe",
    "explorer.exe"
)
| project
    Timestamp,
    DeviceName,
    AccountName,
    InitiatingProcessFileName,
    InitiatingProcessCommandLine,
    FileName,
    ProcessCommandLine
| order by Timestamp desc

Persistence was the next question

If the script only ran once, the attacker still needed a way back.
Registry Run Keys Run and RunOnce keys can point directly to scripts, shortcuts or binaries stored under AppData.
Scheduled Tasks A scheduled task can relaunch an AppData payload at logon, startup or a quiet time of day.
Startup folders A shortcut or copied script in a startup path may survive reboot and keep the compromise alive.

Hunt for AppData persistence

Search registry values where persistence points back to AppData paths.
hunt-for-appdata-persistence.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
DeviceRegistryEvents
| where Timestamp > ago(30d)
| where RegistryValueData has @"\AppData\"
| where RegistryKey has_any (
    @"\Software\Microsoft\Windows\CurrentVersion\Run",
    @"\Software\Microsoft\Windows\CurrentVersion\RunOnce",
    @"\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run"
)
| project
    Timestamp,
    DeviceName,
    ActionType,
    RegistryKey,
    RegistryValueName,
    RegistryValueData,
    InitiatingProcessFileName,
    InitiatingProcessCommandLine
| order by Timestamp desc

Review scheduled tasks pointing to AppData

Look for scheduled task creation or update activity where the task action references AppData.
review-scheduled-tasks-pointing-to-appdata.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
DeviceEvents
| where Timestamp > ago(30d)
| where ActionType has_any ("ScheduledTaskCreated", "ScheduledTaskUpdated")
    or InitiatingProcessCommandLine has_any ("schtasks", "Schedule.Service")
| where tostring(AdditionalFields) has @"\AppData\"
    or InitiatingProcessCommandLine has @"\AppData\"
| project
    Timestamp,
    DeviceName,
    ActionType,
    InitiatingProcessAccountName,
    InitiatingProcessFileName,
    InitiatingProcessCommandLine,
    AdditionalFields
| order by Timestamp desc

What investigators should ask

An AppData case should reconstruct the full endpoint story, not stop at the folder path.
Who wrote the file? Find the process responsible for creating or modifying the script. The writer may be more important than the script name.
Who launched it? Follow parent-child process relationships. The launcher often explains whether the execution was user-driven, automated or attacker-controlled.
Did it come back? Check scheduled tasks, Run keys and startup paths to determine whether the activity survived logoff or reboot.

Build the AppData endpoint timeline

Combine process, file and registry evidence to reconstruct the order of events on the device.
build-the-appdata-endpoint-timeline.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29
  30. 30
let InvestigationDevice = "DEVICE-NAME-HERE";
let StartTime = ago(1d);
union isfuzzy=true
(
    DeviceProcessEvents
    | where Timestamp > StartTime
    | where DeviceName =~ InvestigationDevice
    | where ProcessCommandLine has @"\AppData\"
        or InitiatingProcessCommandLine has @"\AppData\"
    | project Timestamp, DeviceName, EvidenceType="Process", ActionType, Detail=ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine
),
(
    DeviceFileEvents
    | where Timestamp > StartTime
    | where DeviceName =~ InvestigationDevice
    | where FolderPath has @"\AppData\"
    | project Timestamp, DeviceName, EvidenceType="File", ActionType, Detail=FolderPath, InitiatingProcessFileName, InitiatingProcessCommandLine
),
(
    DeviceRegistryEvents
    | where Timestamp > StartTime
    | where DeviceName =~ InvestigationDevice
    | where RegistryValueData has @"\AppData\"
        or InitiatingProcessCommandLine has @"\AppData\"
    | project Timestamp, DeviceName, EvidenceType="Registry", ActionType, Detail=strcat(RegistryKey, " ", RegistryValueName, " ", RegistryValueData), InitiatingProcessFileName, InitiatingProcessCommandLine
)
| order by Timestamp asc

AppData was only the hiding place

The folder did not make the activity malicious. The combination of evidence did.
No alert does not mean no case A quiet endpoint can still contain suspicious execution. The absence of a detection is not the absence of behaviour.
The process tree mattered A script in AppData, launched by a strange parent process, tells a stronger story than a script path alone.
Follow what changed Good incident response explains what was written, what executed, what connected and what persisted.

Related investigations

Continue the investigation through process trees, PowerShell, LOLBins, network activity and timeline reconstruction.
The Child Process Shouldn't Have Existed Follow suspicious parent-child process relationships after initial execution.
The Process Tree Told The Real Story Use process lineage to separate normal activity from attacker execution.
The PowerShell Command Was Base64 Encoded Decode suspicious PowerShell activity and understand why attackers hide commands.
The USB Drive Was Never Meant To Be Found Pivot from removable media activity into script execution and persistence.
The Timeline Told The Story Use timeline reconstruction to explain the order of events across Defender XDR evidence.
The Device Was Talking To Something It Shouldn't Pivot from endpoint execution into suspicious outbound network connections.
Need help investigating endpoint behaviour?
GEMXIT helps organisations understand Microsoft Defender XDR evidence, endpoint telemetry, KQL hunting and practical incident response.
Contact GEMXIT

Final thought

The script path did not shout. It whispered. Defender XDR gave investigators enough evidence to hear it.
At GEMXIT We help organisations investigate Microsoft Defender XDR, endpoint security, process execution, persistence and practical threat hunting. If you want to understand how this applies to your environment, see our Microsoft Security services.
Agent Foskett mindset Do not investigate AppData as a folder. Investigate the behaviour that came from it.
Develop IT. Protect IT. The script looked small. The evidence trail was not. GEMXIT PTY LTD | GEMXIT UK LTD

The Script Ran From AppData

This Agent Foskett investigation explains how scripts running from AppData can reveal suspicious PowerShell execution, file writes, registry changes and endpoint persistence.

Microsoft Defender XDR AppData Investigation

DeviceProcessEvents, DeviceFileEvents and DeviceRegistryEvents can help defenders investigate AppData abuse, suspicious scripts, parent-child process relationships and persistence.

KQL Hunting For AppData Script Execution

Defenders can use KQL to hunt for PowerShell running from AppData, scripts written to user-writable folders, scheduled tasks, registry Run keys and suspicious endpoint timelines.

ACSC Logo

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT 2026