KGB RAT: review persistent access and exposed accounts.

What was reported

Group-IB's October 14 analysis describes KGB RAT, Windows malware with credential theft, keylogging, and remote-control capabilities. Its analyzed samples used a scheduled task named ChromeUpdate and registry persistence. One observed process ran as svchost.exe from a user's temporary folder.

Those details describe the analyzed samples. A filename or task name on its own does not establish an infection. Use the original report's indicators and behavior alongside evidence from your own device.

Preserve the alert

If endpoint protection reports KGB RAT, save the alert, detection time, affected account, file path, hash, and action taken. Ask IT to isolate the device and preserve relevant evidence. Stop using it for email, administration, or password changes.

A business owner can help by recording what happened immediately before the alert: an attachment, software download, support call, or new application. Keep the original message available for the responder without opening the attachment again.

What IT should check

• Inspect the task's executable path, arguments, creation time, and associated file. Review Run entries and startup locations for related activity.
• Compare suspicious files with the published sample hashes and your endpoint telemetry. Keep the parent process and network timeline with the file evidence.
• Review other devices and accounts for the same activity. Determine which administrative, browser, email, and remote-access credentials were available during the suspected exposure.

Do not remove Windows svchost.exe or Chrome update tasks by name alone. Preserve and review the full path and surrounding activity before changing the system.

Recovery checks

From a separate trusted device, revoke exposed sessions and replace affected credentials. Review account activity for access that continued after the endpoint alert. Coordinate this with the device work so replacement credentials are not entered on a compromised machine.

Rebuild when the responder cannot account for the attacker's access or changes. Before reconnecting, confirm that protection is active, reviewed persistence is gone, account access is secured, and any restored business files have been checked. Record the remaining unknowns.