Bumblebee to Akira: Search Engine Poisoning Pipeline

amanda.garcia's shift began with a click on a sponsored "Software Update" search result, and within seconds her browser started reaching out to an external host. Before anything was downloaded, this is the channel the operator used to stage delivery and later beacon back. Working in the SIEM and XDR timeline at the very start of the incident, determine the external domain the workstation contacted as the entry point of this intrusion.

Having established the callback domain that opened this intrusion, 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 mounted as if it were a routine maintenance package — the classic SEO-poisoning lure. Using the XDR timeline's file-download and mount events in the opening minutes of the incident, identify the delivered artifact that kicked off execution.

The mounted maintenance image you found did not run on its own — opening it triggered a hidden shortcut that handed control to a signed Windows utility, which in turn side-loaded the attacker's first-stage loader from a temporary directory. This is the Bumblebee step of the chain. Walk the execution tree spawned by the shell on corp-wks-442 and name the loader module that the LOLBin executed.

Once the loader was resident, it dropped and ran a second-stage executable from amanda.garcia's Temp directory later the same day on corp-wks-442. To confirm scope and check the sample against threat intelligence, the team needs a durable identifier for that binary rather than just its (generic) name. Pivot to the process-creation events in the SIEM for that workstation and recover the file hash recorded for this first dropped payload.

With code execution established on corp-wks-442, the operator began staging on disk. The next day, a file with an innocuous text extension was written into amanda.garcia's Temp folder and then launched as a process — an extension that does not match its behavior, a common masquerading trick. Review the XDR file-system artifacts and the SIEM process activity for this host and name the suspicious file created during this staging step.

The intrusion did not stop at one binary. A short time after the staging activity, the same Temp-folder execution pattern reappeared on corp-wks-442 — another run of a generically named executable under amanda.garcia's account. To prove this is a separate sample rather than a repeat of the earlier one, recover its file hash from the SIEM and compare it to the fingerprint you established earlier.

As the intrusion matured, the telemetry shifts from amanda.garcia's browser-driven infection to deliberate, hands-on-keyboard tradecraft: a signed Windows utility abused to dump credential material from memory, service enumeration via PowerShell, and an outbound HTTPS POST back to the callback domain from the start of this case. These are not the workstation user's actions. Investigate the SIEM and determine which account was driving this credential-theft phase.

In the closing stage of the intrusion, corp-wks-442 produced a dense burst of process executions. Almost all of them are legitimate Windows and office binaries — but one entry is an attacker-supplied program whose name fits no standard system or business application, the kind of oddly branded tool that rides in on SEO-poisoning campaigns. Review the XDR timeline for this final burst and identify the single non-standard executable that does not belong.