[Security Solution] Persistence via Update Orchestrator Service Hijack

[jdixon-86]

Describe the bug: Looks like you are missing a path in the custom query: C:\WINDOWS\uus\AMD64\MoUsoCoreWorker.exe

New query:

kibana.alert.rule.parameters.query: "process where event.type == "start" and
  process.parent.executable : "C:\\Windows\\System32\\svchost.exe" and
  process.parent.args : "UsoSvc" and
  not process.executable :
         (
          "C:\\Windows\\System32\\UsoClient.exe",
          "C:\\Windows\\System32\\MusNotification.exe",
          "C:\\Windows\\System32\\MusNotificationUx.exe",
          "C:\\Windows\\System32\\MusNotifyIcon.exe",
          "C:\\Windows\\System32\\WerFault.exe",
          "C:\\Windows\\System32\\WerMgr.exe",
          "C:\\Windows\\UUS\\amd64\\MoUsoCoreWorker.exe"
          )

Kibana/Elasticsearch Stack version: 8.2.0

Server OS version: NA

Browser and Browser OS versions: NA

Elastic Endpoint version: 8.2.0

Original install method (e.g. download page, yum, from source, etc.):

Functional Area (e.g. Endpoint management, timelines, resolver, etc.):

Steps to reproduce: Query:

kibana.alert.rule.parameters.query: "process where event.type == "start" and
  process.parent.executable : "C:\\Windows\\System32\\svchost.exe" and
  process.parent.args : "UsoSvc" and
  not process.executable :
         (
          "C:\\Windows\\System32\\UsoClient.exe",
          "C:\\Windows\\System32\\MusNotification.exe",
          "C:\\Windows\\System32\\MusNotificationUx.exe",
          "C:\\Windows\\System32\\MusNotifyIcon.exe",
          "C:\\Windows\\System32\\WerFault.exe",
          "C:\\Windows\\System32\\WerMgr.exe"
          )

Current behavior:

Expected behavior:

Screenshots (if relevant):

Errors in browser console (if relevant):

Provide logs and/or server output (if relevant):

Any additional context (logs, chat logs, magical formulas, etc.):

[elasticmachine]

Pinging @elastic/security-solution (Team: SecuritySolution)

[terrancedejesus]

@MindyRS or @KnowMoreIT - Thanks for bringing this to our attention! Do you have any specific data to show the executable being launched from this location and is it extremely noisy? Based on my understanding, the Microsoft Update Orchestrator Service executable is natively suppose to live in the C:\Windows\System32\ directory and thus if we are seeing it launched from C:\Windows\uus\AMD64\ that is suspicious and requires investigation.

The rule still needs tuned to not alert on C:\\Windows\\System32\\MoUsoCoreWorker.exe as that is where it natively lives. I will setup a lab and do some testing for this as well as to tune the rule.

References: https://strontic.github.io/xcyclopedia/library/MoUsoCoreWorker.exe-B23D3D91F4892DF3FA0D1E84B97E8160.html https://github.com/SigmaHQ/sigma/blob/master/rules/windows/raw_access_thread/sysmon_raw_disk_access_using_illegitimate_tools.yml

[jdixon-86]

@terrancedejesus It is generating a lot of noise for me because of the path but I am having trouble determining what the C:\Windows\UUS folder is. There is not much information that I can find on it. However, I have noticed it is only on Windows 11 machines (home and pro) and haven't seen it on any Windows 10 or prior so far. It is digitally signed by Microsoft and no scans turn up any malware for it.

I have attached the executable as well as the JSON file showing the DLL load event. (Btw you may want to add .json to the list of extensions available to upload).

MoUsoCoreWorker.zip MoUsoCoreWorker - JSON.zip .