ACSC Logo
© GEMXIT
GEMXIT Logo
Agent Foskett Investigation • Microsoft Defender XDR • Excel • PowerShell • Process Trees • DeviceNetworkEvents • KQL

The Excel File Never Contained a Macro — It Still Started PowerShell

Excel opened the document.

Seconds later, PowerShell appeared.

The obvious explanation was a malicious macro.
Except the workbook contained no VBA macro.

That did not make the process chain harmless.

Agent Foskett stopped trying to prove a macro existed.

He followed what Excel actually launched.

Discuss endpoint security Back to investigations
Agent Foskett investigating Excel spawning PowerShell without relying on a macro assumption
No Macro Did Not End the Investigation

The absence of VBA answers one question about the document. Endpoint telemetry still has to explain why Excel was associated with a PowerShell child process.

✓ Reconstruct Excel child processes
✓ Preserve the PowerShell command line
✓ Follow network and file activity from the process

The first theory was wrong

Excel followed by PowerShell immediately suggested a macro-enabled attack chain. But the document review did not support that theory. Instead of forcing the evidence to fit the assumption, the investigation returned to endpoint telemetry and treated the process relationship itself as the starting point.
Excel openedThe document was associated with the start of the timeline.
No VBA macro foundThe expected explanation was not supported by the document evidence.
PowerShell still appearedThe endpoint process chain still required an explanation.

Start with every child process created by Excel

Use DeviceProcessEvents to identify processes whose initiating process was excel.exe. Preserve both command lines and the initiating process ID so the investigation can reconstruct the relationship rather than relying on process names alone.
excel-child-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
let Device = "LAPTOP-042";
DeviceProcessEvents
| where Timestamp > ago(7d)
| where DeviceName =~ Device
| where InitiatingProcessFileName =~ "excel.exe"
| project Timestamp,
          DeviceName,
          AccountName,
          FileName,
          ProcessCommandLine,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine,
          InitiatingProcessId
| order by Timestamp asc

Isolate the Excel-to-PowerShell relationship

Narrow the process tree to PowerShell started by Excel. The full ProcessCommandLine is the key evidence here: it can reveal switches, script paths, encoded content or other arguments that explain what PowerShell was instructed to do.
excel-powershell-chain.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
let Device = "LAPTOP-042";
DeviceProcessEvents
| where Timestamp > ago(7d)
| where DeviceName =~ Device
| where FileName in~ ("powershell.exe", "pwsh.exe")
| where InitiatingProcessFileName =~ "excel.exe"
| project Timestamp,
          FileName,
          ProcessCommandLine,
          ProcessId,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine,
          InitiatingProcessId
| order by Timestamp asc

The process tree mattered more than the macro theory

The evidence established that Excel was associated with PowerShell execution even though the workbook did not contain the expected VBA macro. At that point, the correct investigation was not “where is the macro?” but “what mechanism produced this child process, and what did that child process do next?”
Document theory challengedThe absence of VBA meant the initial explanation had to change.
Process relationship preservedExcel and PowerShell remained linked in endpoint telemetry.
Behaviour became the evidenceThe investigation followed execution rather than assuming a specific document technique.

What did PowerShell connect to?

Use the PowerShell process ID as a pivot into DeviceNetworkEvents. This avoids guessing that the command contacted the internet. If network telemetry exists for that process, preserve the remote URL, IP, port and command line.
powershell-network-activity.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
let Device = "LAPTOP-042";
let PowerShellPid = 7840;
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where DeviceName =~ Device
| where InitiatingProcessId == PowerShellPid
| project Timestamp,
          RemoteUrl,
          RemoteIP,
          RemotePort,
          Protocol,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine
| order by Timestamp asc

Did PowerShell create or modify a file?

Pivot the same process ID into DeviceFileEvents. File creation or modification shortly after the PowerShell execution can expose a downloaded payload, script, archive or other artefact that becomes the next investigative pivot.
powershell-file-activity.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
let Device = "LAPTOP-042";
let PowerShellPid = 7840;
DeviceFileEvents
| where Timestamp > ago(7d)
| where DeviceName =~ Device
| where InitiatingProcessId == PowerShellPid
| project Timestamp,
          ActionType,
          FileName,
          FolderPath,
          SHA1,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine
| order by Timestamp asc

Did the resulting payload execute later?

If a suspicious file is identified, use its hash to search historical process telemetry on the device. This separates the initial document-triggered execution from later payload activity and helps extend the timeline beyond the moment Excel was opened.
payload-execution-history.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
let Device = "LAPTOP-042";
let PayloadHash = "0123456789abcdef0123456789abcdef01234567";
DeviceProcessEvents
| where Timestamp > ago(30d)
| where DeviceName =~ Device
| where SHA1 == PayloadHash
   or InitiatingProcessSHA1 == PayloadHash
| project Timestamp,
          FileName,
          FolderPath,
          ProcessCommandLine,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine
| order by Timestamp asc

Has Excel launched PowerShell anywhere else?

Finally, scope the same parent-child relationship across the environment. Excel spawning PowerShell is not automatically malicious, but repeated or matching command lines on multiple endpoints can reveal a broader campaign or repeated administrative behaviour that needs explanation.
excel-powershell-environment-scope.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
DeviceProcessEvents
| where Timestamp > ago(30d)
| where InitiatingProcessFileName =~ "excel.exe"
| where FileName in~ ("powershell.exe", "pwsh.exe")
| summarize Executions=count(),
            FirstSeen=min(Timestamp),
            LastSeen=max(Timestamp),
            Users=dcount(AccountName)
    by DeviceName,
       ProcessCommandLine
| order by Executions desc

No macro does not identify the alternative mechanism

The absence of VBA does not prove how PowerShell was started. Office documents and surrounding workflows can involve multiple execution paths, and endpoint telemetry may show the resulting process without fully identifying the document-level trigger. The analyst should describe what the evidence proves and investigate the mechanism separately.
KnownExcel was associated with the PowerShell child process in endpoint telemetry.
Not establishedA VBA macro was not supported as the execution mechanism.
Next questionDetermine the actual trigger using document, process and surrounding endpoint evidence.

What the evidence can and cannot prove

A parent-child process relationship can strongly support that Excel initiated PowerShell from the endpoint's perspective. It does not automatically prove that the workbook itself was malicious or identify the exact Office technique involved. Network and file events show what PowerShell did after execution, not necessarily why Excel launched it.
ProvenThe process telemetry can establish the Excel-to-PowerShell relationship and command line.
CorrelatedProcess IDs connect PowerShell with subsequent network and file activity.
Do not overclaimNo macro does not automatically identify another execution technique.

Agent Foskett's investigation mindset

A good hypothesis is useful until the evidence disproves it. When the expected macro is absent, do not close the case and do not invent a replacement explanation. Return to the process tree, preserve the command line and follow the behaviour one event at a time.
Test the assumptionDo not treat “Excel plus PowerShell” as automatic proof of a macro.
Follow executionThe parent-child relationship gives the investigation a defensible pivot.
Let telemetry reveal the mechanismDo not name an exploit or technique until the evidence supports it.

Investigation findings

The workbook did not contain the VBA macro initially suspected, but Microsoft Defender XDR process telemetry still showed Excel associated with PowerShell execution. The PowerShell command line, process ID, network activity and file events provided a defensible path through the incident. The absence of a macro changed the hypothesis; it did not erase the suspicious behaviour.
The macro theory failedThe document evidence did not support VBA as the trigger.
The process chain remainedExcel-to-PowerShell execution still required investigation.
The behaviour told the storyNetwork, file and later process activity extended the investigation beyond the document.

Related Agent Foskett investigations

Continue with Office, PowerShell and endpoint process investigations.
The Browser Spawned PowerShellFollow an unusual parent-child process relationship through Microsoft Defender XDR. The Command Line Told a Different StoryInvestigate the arguments that reveal what a trusted-looking process was actually instructed to do. Agent Foskett AcademyBuild practical Microsoft security investigation and KQL skills.
No macro. PowerShell still ran.
When the first theory fails, follow the process tree instead of forcing the evidence to fit.
Continue the Investigation

Final thought

The absence of a macro is useful evidence, but it is not a clean bill of health for the document or the surrounding activity. If Excel is followed by PowerShell, investigate the relationship that actually exists in the telemetry. Security investigations become stronger when the analyst is willing to abandon the first explanation and follow what the endpoint really recorded.
What launched?Reconstruct Excel's child processes.
What was PowerShell told to do?Preserve and investigate the full command line.
What happened next?Follow network, file and payload execution evidence.
Develop IT. Protect IT.
GEMXIT PTY LTD | GEMXIT UK LTD
Talk to GEMXIT
ACSC Logo

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT

The Excel File Never Contained a Macro — It Still Started PowerShell

This Agent Foskett investigation explores Excel child processes, PowerShell execution, DeviceProcessEvents, DeviceNetworkEvents, DeviceFileEvents and KQL in Microsoft Defender XDR.

Excel To PowerShell Investigation

The investigation begins with an Excel document that contains no VBA macro but is still associated with PowerShell execution, forcing the analyst to follow endpoint behaviour instead of the initial document theory.

Microsoft Defender XDR Process Trees And KQL

Parent-child process telemetry, command lines, process IDs, network events and file events help defenders reconstruct suspicious Office-to-PowerShell activity without assuming an unsupported execution mechanism.