Search Engine Poisoning: From a Sponsored Result to the Domain Controller

amanda.garcia's shift began with a click on a sponsored "Software Update" search result, and within seconds her browser walked through more than one external host. One of them appears once and hands the browser straight on; the other is the host the workstation keeps coming back to for the rest of the case. Working in the SIEM and XDR timeline around that click, name the second one. Other users' browsers reach it later in the week too, so anchor on amanda.garcia's session rather than on the domain alone.

Having established the external host that opens this case, follow what arrived next on corp-wks-442. Shortly after the browser reached that host, a file landed in amanda.garcia's profile and was opened from the shell. Using the XDR timeline's file-creation events and the SIEM process activity in the opening minutes, identify the delivered artifact that execution starts from.

Opening the mounted image did not run anything on its own: a shortcut inside it handed control to a signed Windows utility, which then loaded a module from a temporary directory instead of from a signed system path. Walk the execution tree spawned by the shell on corp-wks-442 and name the module the utility loaded.

One generically named executable is written into amanda.garcia's Temp directory on corp-wks-442 and run from there four separate times across the case, each run under a different hash. To confirm scope and check the samples against threat intelligence, the team needs durable identifiers rather than the shared filename. Pivot to the process-creation events in the SIEM for that workstation, put the four runs in order, and recover the file hash of the EARLIEST one.

The next day, a file with a text extension was written into amanda.garcia's Temp folder on corp-wks-442 and then appeared as the image of a newly created process. Review the XDR file-system artifacts and the SIEM process-creation events for this host and name that file.

The same Temp-folder execution pattern repeats on corp-wks-442 under amanda.garcia's account until it stops. To show the operator kept re-packing the payload rather than re-running one file, take the LAST run in that series and recover its hash from the SIEM, then confirm it differs from the earliest one you already submitted.

As the case matures, the telemetry shifts away from amanda.garcia's browser-driven activity on the workstation and onto corp-dc-01, where a cluster of administrative tooling runs inside a few minutes. Several accounts touch the domain controller across the week, including a backup service account and two ordinary users. Work the SIEM around that cluster and determine which account was driving it.

In the closing stage of the case, corp-wks-442 produced a dense burst of process executions inside twenty minutes. Most of them are ordinary Windows and office binaries. Review the XDR timeline and the matching SIEM process-creation events for this burst and identify the one executable that corresponds to no standard Windows component and no known business application.