Add `exec intune upload` to upload data from a device to a web server

[pl4nty]

Supports registry keys, event logs, command output, and files/folders, subject to significant restrictions. Could bypass (netsh add helper payload.dll or certutil -encode come to mind), but they're pretty noisy. This talk might have some ideas. https://learn.microsoft.com/en-us/windows/client-management/mdm/diagnosticlog-csp#diagnosticarchivearchivedefinition

I used config for simplicity. Might be worth reminding users to sync after upload for faster results, but not automating it in case they want to batch changes and avoid the ratelimit.

An alternative to config is writing regkeys via script like

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MdmDiagnostics\Area\DeviceProvisioning\FileEntry]
"%ProgramData%\\targetfile*.*"=dword:000000ff

then triggering diag log collection via Graph, and polling until the archive is available for download. I think that triggers a WNS notif so could be much faster, and uses Intune-managed storage, but leaves artefacts in the registry and in Intune.

Did some quick tests of these changes with exec intune upload --access-token and I've used similar payloads before, but ran out of time for e2e testing tonight.

Logs

``` 2024-11-02 15:23:39.489 UTC - [INFO] Execution started 2024-11-02 15:23:39.693 UTC - [DEBUG] Database option not used, skipping storage of this Jwt 2024-11-02 15:23:39.697 UTC - [INFO] Creating new device assignment filter with displayName: 70c3ccd5-1aae-4e28-ac39-39f54c06abf2 2024-11-02 15:23:39.737 UTC - [VERBOSE] Sending POST request to: https://graph.microsoft.com/beta/deviceManagement/assignmentFilters 2024-11-02 15:23:42.444 UTC - [VERBOSE] Received 201 (Created) status code from: https://graph.microsoft.com/beta/deviceManagement/assignmentFilters {"@odata.context":"https://graph.microsoft.com/beta/$metadata#deviceManagement/assignmentFilters/$entity","id":"d91f479f-06d8-4126-b26f-1a0b803385ae","createdDateTime":"2024-11-02T15:23:35.8286302Z","lastModifiedDateTime":"2024-11-02T15:23:35.8286302Z","displayName":"70c3ccd5-1aae-4e28-ac39-39f54c06abf2","description":"","platform":"windows10AndLater","rule":"(device.deviceName -eq \"1234\")","roleScopeTags":["0"],"assignmentFilterManagementType":"devices","payloads":[]} 2024-11-02 15:23:42.446 UTC - [INFO] Obtained filter ID: d91f479f-06d8-4126-b26f-1a0b803385ae 2024-11-02 15:23:42.455 UTC - [INFO] Creating custom config policy for device: 1234 2024-11-02 15:23:42.459 UTC - [VERBOSE] Using ArchiveDefinition: 7b3ca282-0d03-44f1-8341-5804b575742dHKLM\Software\Policies 2024-11-02 15:23:42.460 UTC - [VERBOSE] Sending POST request to: https://graph.microsoft.com/beta/deviceManagement/deviceConfigurations 2024-11-02 15:23:42.705 UTC - [VERBOSE] Received 201 (Created) status code from: https://graph.microsoft.com/beta/deviceManagement/deviceConfigurations {"@odata.context":"https://graph.microsoft.com/beta/$metadata#deviceManagement/deviceConfigurations/$entity","@odata.type":"#microsoft.graph.windows10CustomConfiguration","id":"387584e2-d6c5-4748-a991-1db53a009f7c","lastModifiedDateTime":"2024-11-02T15:23:38.1686945Z","roleScopeTagIds":["0"],"supportsScopeTags":true,"deviceManagementApplicabilityRuleOsEdition":null,"deviceManagementApplicabilityRuleOsVersion":null,"deviceManagementApplicabilityRuleDeviceMode":null,"createdDateTime":"2024-11-02T15:23:38.1686945Z","description":"Custom config policy for device","displayName":"Custom Config Policy","version":1,"omaSettings":[{"@odata.type":"#microsoft.graph.omaSettingString","displayName":"diagnostics","description":"Diagnostics settings","omaUri":"./Vendor/MSFT/DiagnosticLog/DiagnosticArchive/ArchiveDefinition","secretReferenceValueId":"69b95033-0d33-4a4d-9a35-68b440b4bd92_387584e2-d6c5-4748-a991-1db53a009f7c_b5b0e315-507d-4f47-aaad-58ea5a426b14","isEncrypted":true,"value":"****"}]} 2024-11-02 15:23:42.706 UTC - [INFO] Obtained policy ID: 387584e2-d6c5-4748-a991-1db53a009f7c 2024-11-02 15:23:42.710 UTC - [INFO] Assigning policy 387584e2-d6c5-4748-a991-1db53a009f7c with filter d91f479f-06d8-4126-b26f-1a0b803385ae 2024-11-02 15:23:42.711 UTC - [VERBOSE] Sending POST request to: https://graph.microsoft.com/beta/deviceManagement/deviceConfigurations/387584e2-d6c5-4748-a991-1db53a009f7c/assign 2024-11-02 15:23:42.996 UTC - [VERBOSE] Received 200 (OK) status code from: https://graph.microsoft.com/beta/deviceManagement/deviceConfigurations/387584e2-d6c5-4748-a991-1db53a009f7c/assign 2024-11-02 15:23:42.997 UTC - [INFO] Successfully assigned policy with filter 2024-11-02 15:23:42.997 UTC - [INFO] Successfully created and assigned diagnostic logs policy with request ID 7b3ca282-0d03-44f1-8341-5804b575742d. 2024-11-02 15:23:42.997 UTC - [INFO] Completed execution in 00:00:03.5589467 ```

---

For more details, open the Copilot Workspace session.

[pl4nty]

My test token from intune.microsoft.com was missing a upn claim too, so I added a fallback to email.

I also hit a strange bug where the test token was missing from requests, added this workaround in a few places because I couldn't find the root cause.

[pl4nty]

Besides the DiagnosticLog CSP, I've been playing with win32 storage and Delivery Optimization for staging/exfil. Could PR the results early next year if you'd like? The authn flows are pretty gnarly though

[Mayyhem]

This looks really useful @pl4nty ! Great stuff! I'll take look in my lab and get back to you with any questions I have before merging. Thank you for the contribution!

[Mayyhem]

I fixed the provided access token bug, added deletion commands for the artifacts, and allowed optional device sync. I'm still trying to "catch" the PUT request. Does IME check that the destination is a valid web service or does it just send the PUT wherever it's pointed? I've been using netcat without success.

[Mayyhem]

I think it's just from spamming sync all day. These rate limits make troubleshooting pretty painful.