ACSC Logo
© GEMXIT
GEMXIT Logo
Agent Foskett Investigation • PowerShell • Microsoft Defender XDR • DeviceProcessEvents • Indirect Network Activity • Data Exposure • KQL

The PowerShell Command Never Contained a URL

The security team looked for the obvious sign of data theft.

A large download.

There wasn't one.

No 4 GB transfer. No archive dragged to a desktop. No dramatic spike in downloaded files.

Agent Foskett looked at the cloud activity and found a different question waiting for him.

What if the attacker never needed to download the files at all?

Discuss Microsoft 365 securityBack to investigations
Agent Foskett investigating suspicious PowerShell and Microsoft Defender XDR file sharing
Cloud Data Exposure Investigation

The files were not copied out in bulk. Access to them was extended beyond the expected boundary.

Inspect sharing and link activity
Identify the account, object and IP address
Follow what happened after access was granted

Everyone searched for downloads

Bulk downloads are an obvious exfiltration signal, but cloud collaboration creates another path. A compromised account may expose data by changing access, creating a sharing link or sharing an object with another identity. The investigation has to follow access changes as well as file transfers.
No bulk downloadThe expected exfiltration pattern never appeared. There was no single large transfer to explain the incident.
The permissions changedCloud activity showed that files and folders had been shared beyond their expected audience.
The data could still leaveOnce access is granted, the recipient can retrieve the content later. The original account does not need to perform the final download.

Start with the PowerShell command line

The first hunt is deliberately simple: find recent PowerShell executions where the command line does not contain an obvious HTTP or HTTPS URL. This establishes the suspicious process activity without assuming that a visible URL must be present before network behaviour can exist.
powershell-without-visible-url.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("powershell.exe", "pwsh.exe")
| where ProcessCommandLine !contains "http://"
| where ProcessCommandLine !contains "https://"
| project Timestamp, DeviceName, AccountName,
          FileName, ProcessCommandLine,
          InitiatingProcessFileName, InitiatingProcessCommandLine
| order by Timestamp desc

Start with the user's cloud activity

In Microsoft Defender XDR, DeviceProcessEvents contains events involving accounts and objects in Office 365 and other connected cloud applications. Start broad: establish what the account did, which application recorded it, the source IP address and the objects involved.
cloud-activity-baseline.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
DeviceProcessEvents
| where Timestamp > ago(7d)
| where AccountId =~ "alex.morgan@contoso.com"
| project Timestamp, Application, ActivityType,
          AccountDisplayName, AccountId, IPAddress,
          ObjectName, ObjectType, ObjectId,
          IsExternalUser, RawEventData
| order by Timestamp asc

Hunt for sharing-related activity

Action names can vary with the underlying Microsoft 365 activity and connected service, so first inspect the values present in your tenant. Then narrow the investigation to sharing, link and permission-related operations rather than assuming one hard-coded action name will describe every event.
discover-sharing-actions.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
DeviceProcessEvents
| where Timestamp > ago(30d)
| where Application in ("Microsoft PowerShell Online", "Microsoft Microsoft Defender XDR for Business")
| where ActivityType has_any ("share", "sharing", "link", "permission")
| summarize Events=count() by ActivityType, Application
| order by Events desc

Now identify the objects that were exposed

A sharing event is only the beginning. Investigators need the object name, type, account, source IP and raw event context so they can determine whether a single harmless document was shared or an entire sensitive folder became reachable.
shared-objects.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
DeviceProcessEvents
| where Timestamp > ago(7d)
| where AccountId =~ "alex.morgan@contoso.com"
| where Application in ("Microsoft PowerShell Online", "Microsoft Microsoft Defender XDR for Business")
| where ActivityType has_any ("share", "sharing", "link", "permission")
| project Timestamp, ActivityType, Application,
          ObjectName, ObjectType, ObjectId,
          AccountId, IPAddress, RawEventData
| order by Timestamp asc

Look inside the raw event — carefully

DeviceProcessEvents exposes RawEventData for additional source-specific information. During a real investigation, inspect the returned structure before extracting fields because the properties available can differ by activity. This is where recipient, link or permission context may become visible for the event you are examining.
inspect-raw-sharing-event.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
DeviceProcessEvents
| where Timestamp > ago(7d)
| where AccountId =~ "alex.morgan@contoso.com"
| where ActivityType has_any ("share", "sharing", "link", "permission")
| project Timestamp, ActivityType, ObjectName, RawEventData
| take 20

Was this normal collaboration — or an outlier?

Sharing is a normal business function. Context matters. Compare the account's recent activity by source IP, application and action type. A burst of unusual sharing from a new network immediately after a suspicious sign-in deserves a very different interpretation from routine collaboration.
sharing-by-ip.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
DeviceProcessEvents
| where Timestamp > ago(30d)
| where AccountId =~ "alex.morgan@contoso.com"
| where ActivityType has_any ("share", "sharing", "link", "permission")
| summarize FirstSeen=min(Timestamp),
            LastSeen=max(Timestamp),
            Events=count(),
            Objects=dcount(ObjectId)
          by IPAddress, Application, ActivityType
| order by LastSeen desc

Correlate sharing with the sign-in window

The strongest evidence comes from sequence. If your environment exposes Microsoft Entra sign-in data in advanced hunting, correlate the identity activity with the cloud actions. The objective is not merely to find two suspicious records — it is to establish whether they belong to the same incident window.
correlate-signin-and-sharing.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
let TargetUser = "alex.morgan@contoso.com";
let StartTime = ago(1d);
DeviceProcessEvents
| where Timestamp > StartTime
| where AccountId =~ TargetUser
| where ActivityType has_any ("share", "sharing", "link", "permission")
| project Timestamp, Application, ActivityType,
          ObjectName, IPAddress, AccountId
| order by Timestamp asc

The important distinction: sharing is not the same as downloading

The evidence should be described precisely. A sharing event can demonstrate that access was granted or changed; it does not automatically prove that the recipient later downloaded or opened the content. If the investigation needs to prove subsequent access, hunt for the corresponding recipient or object activity and preserve the complete audit trail.
Prove the shareIdentify the account, object, sharing operation, time and relevant access details.
Then prove accessIf you need to establish that the recipient used the access, find the later object activity rather than assuming it happened.
Keep the claims defensible“The file was shared externally” and “the file was exfiltrated” are not automatically identical conclusions.

Investigation findings

The original hunt had focused on file downloads. The cloud audit trail showed why that was too narrow.
The attacker avoided the obvious patternThere was no dramatic bulk-download event to attract attention.
Access was extended insteadSharing-related cloud activity exposed sensitive objects beyond their expected audience.
The timeline connected the behaviourThe suspicious identity activity and subsequent sharing operations formed one coherent investigation path.

Agent Foskett's notebook

Investigators often search for the action they expect an attacker to take. Good investigations also ask how the same objective could be achieved another way.
Do not hunt only for downloadsData exposure can begin with a permission or sharing change long before a recipient retrieves anything.
Cloud collaboration is evidencePowerShell and Microsoft Defender XDR activity can reveal who changed access, to what object, from where and when.
Follow the objectiveIf the objective is data access, investigate every path that can grant it — not only the path that copies bytes to a device.

Related Agent Foskett investigations

Continue with cloud data movement, identity compromise and KQL correlation investigations.
The User Downloaded 4GB of Data Before ResigningInvestigate the obvious data-movement pattern: high-volume downloads before departure.
The New MFA Method Was Registered 11 Minutes After The LoginTrace suspicious identity activity before the cloud actions begin.
The Conditional Access Result Said Success — But That Wasn't the Whole StoryUnderstand why a successful access decision is not the end of an identity investigation.
The KQL join Revealed The AttackerConnect evidence spread across different Microsoft Defender XDR tables.
Agent Foskett AcademyBuild practical KQL and Microsoft security investigation skills through structured lessons.
No bulk download doesn't mean no endpoint compromise.
Follow the permissions, sharing events and the complete cloud activity timeline.
Visit the Agent Foskett Academy

Final thought

The missing download was not proof that nothing had happened. It was the clue that the investigation was asking the wrong question.
The files stayed in Microsoft 365The attacker did not need to move them immediately.
The access boundary moved insteadSharing changed who could reach the information.
Investigate outcomes, not assumptionsWhen one exfiltration path is absent, ask how else the attacker could achieve the same objective.
Develop IT. Protect IT.
GEMXIT PTY LTD | GEMXIT UK LTD
Talk to GEMXIT
ACSC Logo

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT

The PowerShell Command Never Contained a URL

This Agent Foskett investigation explores Microsoft 365 endpoint compromise through PowerShell and Microsoft Defender XDR sharing activity rather than obvious bulk downloads. It follows account activity, cloud objects, IP addresses and sharing-related events to reconstruct what changed and when.

Microsoft Defender XDR DeviceProcessEvents, PowerShell and Microsoft Defender XDR Investigation

The investigation demonstrates how DeviceProcessEvents can help defenders examine Office 365 cloud activity involving accounts and objects, discover relevant ActivityType values, inspect RawEventData and identify unusual sharing behaviour around an incident window.

KQL, Indirect Network Activity and Cloud Data Exposure

GEMXIT helps organisations investigate Microsoft 365 cloud activity, identity compromise, PowerShell and Microsoft Defender XDR access, suspicious sharing and endpoint compromise using practical KQL and evidence-driven Microsoft security investigation workflows.