Each object in the array in the log represents one process launch, with the following fields:

The events in this log file describe a partial tree - every process has a parent, but not every parent process appears in this log. We can sometimes match a process’s parent_process_id to another object’s process_id. This can help us link them up to prove which process was launched by which. The timestamp field also helps us see which process started after which.

To find the name of the bootstrap executable downloaded via the browser, we will look at the command line entries to find executable files. You can download the log files and use grep or Ctrl+F, or you can scan through the file manually.

In the very first JSON object, we see the chrome.exe process running an interesting command line.

Chrome is opened directly to a URL ending in an .exe - a download link. The file name at the end of that URL, agent-WP1buGiXuuz5gPKdfu4Mxi.exe, is the bootstrapper the user's browser pulled down, and the answer to Question 1.

Next, we need to find the name of the main agent executable launched after the bootstrapper runs.

On line 62 (command_linefield), the downloaded file is running from the Downloads folder (it appears to have been downloaded twice, hence the “(1)”).

After that, we see a bunch of native Windows processes running - msiexec.exe, SgrmBroker.exe, and svchost.exe. None of these is the main agent executable we are looking for, so we can make the logical jump to the next process that is NOT the bootstrapper itself running again, and is NOT located in System32 or syswow64 (native Windows directories), but is located in Program Files (x86), which is layer_agent_svc.exe. This is our answer to Question 2. Note that the word layer was also present in the FQDN visited by Chrome at the beginning of the logs.

If we want to double-check, we can look more closely at one of the native Windows processes- msiexec.exe (on line 85). It is the official command-line utility for Windows Installer, so it appears in the logs during installation, updating, repair or removal of software packages.

We can see that this msiexec.exe (located at C:\Windows\system32\msiexec.exe), with a process id of 6484, subsequently spins up an embedded MSI worker (line 130, C:\Windows\syswow64\MsiExec.exe) - this is likely the bootstrapper silently installing the agent package via Windows Installer rather than showing a setup wizard.

Another child process of msiexec.exe (process id 6484) is a process called layer_agent_svc.exe .

This is the difference between the bootstrapper (a throwaway installer run from the Downloads folder) and the payload (the actual agent, now living in Program Files (x86), ready to run persistently as a service).

Right after the agent starts, it spawns PowerShell. Looking at the command_line section reveals the the word “Firewall”. Lets investigate this log more closely:

The cmdlet New-NetFirewallRule creates an inbound allow rule for the agent's own binary, so it allows incoming connections. The cmdlet runs a second time at line 170 for a different -Name value ("LayerAgent Service Command").

On line 211, we see Task Manager running. It runs twice - process IDs 8140 and 8184. Someone is likely opening Task Manager to confirm that layer_agent_svc.exe is running. It cannot be conhost.exe or msiexec.exe, since those processes do not provide the function of verifying if a process is running.

Lastly, Defender is being enabled with -wdenable at line 233:

From this process’s timestamp, subtract the timestamp of the last PowerShell firewall rule command to get our answer for Question 6.

Keep in mind that this process tree does not show Defender being disabled first, so we can only speculate that it was disabled beforehand.

• Sysmon: https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon
• Our Tutorial Video for this challenge

** Tutorial Video will be uploaded shortly after it has been recorded **