Security News New RecoverIt Tool Exploits Windows Service Failure Recovery Functions to Execute Payload

[Brownie2019]

Content source

https://cybersecuritynews.com/recoverit-tool/

A new open-source offensive security tool named “RecoverIt” has been released, offering Red Teamers and penetration testers a novel method for establishing persistence and executing lateral movement on compromised Windows systems.
The tool, developed by security researcher TwoSevenOneT, weaponizes the built-in failure recovery mechanism of Windows Services to trigger arbitrary code execution, bypassing some of the most common detection heuristics used by Endpoint Detection and Response (EDR) systems.
Windows Services are designed with resilience in mind. The Service Control Manager (SCM) includes a “Recovery” tab for each service, allowing system administrators to define specific actions if a service fails unexpectedly.

Read the full Story on:

New RecoverIt Tool Exploits Windows Service Failure Recovery Functions to Execute Payload

A new open-source offensive security tool named "RecoverIt" has been released, offering Red Teamers and penetration testers a novel method for establishing persistence and executing lateral movement on compromised Windows systems.

cybersecuritynews.com

 

[Bot]

Read the full Story on:

New RecoverIt Tool Exploits Windows Service Failure Recovery Functions to Execute Payload

A new open-source offensive security tool named "RecoverIt" has been released, offering Red Teamers and penetration testers a novel method for establishing persistence and executing lateral movement on compromised Windows systems.

cybersecuritynews.com

This “RecoverIt” story (dated February 9, 2026) is essentially about abusing a legitimate Windows feature: a service’s built-in “Recovery” actions (including “Run a program”) to get code execution triggered by a service failure, without modifying the service’s ImagePath.

What the technique is (defender view)

• Windows services can be configured to take actions when they “fail” (restart service, reboot, or run a program).
• RecoverIt automates changing those failure-recovery settings so that when a chosen service crashes, the Service Control Manager ends up launching an attacker-chosen process as a recovery action.
• This is not a privilege-escalation vulnerability by itself; changing service configuration typically requires admin/SYSTEM-level rights already. The value (for an attacker) is stealth/persistence and evading simplistic detections that focus only on ImagePath changes.

Why it can slip past some monitoring
Many environments alert heavily on classic service persistence (new service creation and/or ImagePath/binPath changes). This technique can leave ImagePath untouched and instead change recovery settings, which many orgs don’t baseline or alert on.

Also, per the author’s write-up, the “service failed” event doesn’t necessarily spell out which recovery program was launched, so defenders often need process/registry telemetry (Sysmon/EDR) to see the full chain.

Practical detection ideas

• Baseline and alert on changes to per-service recovery-related registry values under:
  HKLM\SYSTEM\CurrentControlSet\Services\<ServiceName>\
  (notably FailureActions, FailureCommand, and RebootMessage).
• If you use Sysmon/EDR: alert when services.exe spawns unusual child processes (command interpreters and script hosts are common red flags) especially when it closely follows a service crash/termination event.
• Correlate Windows System log service-failure events (e.g., unexpected termination) with near-simultaneous process creation events where the parent is services.exe.

Hardening / prevention (where feasible)

• Reduce who can administer services (least privilege). If attackers don’t have admin/SYSTEM, they generally can’t set this up.
• Consider application control (WDAC/AppLocker) so even if services.exe is coerced into launching something, only approved binaries/scripts can run.
• Review service “Recovery” settings in your environment; “Run a program” is legitimate in some orgs, but it’s also an obvious persistence hook if left unmonitored.

Conclusion
Treat this as a reminder to monitor more than just ImagePath/service creation: service failure-recovery configuration is another persistence surface, and it’s easy to overlook unless you baseline it and watch for changes.

Sources

• New RecoverIt Tool Exploits Windows Service Failure Recovery Functions to Execute Payload
• Defense Evasion: The Service Run Failed Successfully
• GitHub - TwoSevenOneT/RecoverIt: A tool that helps change the recovery configuration of a Windows service to make lateral movement more stealthy
• JSI Tip 10158. Where are the Service Recovery options stored in the registry?
• SERVICE_FAILURE_ACTIONSA (winsvc.h) - Win32 apps

 

[Divergent]

Technical Analysis & Remediation

MITRE ATT&CK Mapping

T1543.003 (Create or Modify System Process: Windows Service) Modifying service configuration parameters to enable persistence.

T1112 (Modify Registry)
Altering specific registry keys to define failure actions.

T1574 (Hijack Execution Flow)
Triggering execution via induced service failure.

CVE Profile
[N/A: Abuse of Native Functionality] | [Status: Active PoC]

Telemetry & Anchors

Target Registry Keys
The tool modifies FailureCommand and FailureActions configurations for target services. It notably avoids touching the ImagePath or binPath.

Process Relationship
The malicious payload is spawned directly by services.exe as a child process.

Targeting Vector
The tool requires a service that can be induced to crash. The documentation highlights UevAgentService (User Experience Virtualization Agent) as a prime target because it crashes immediately if the broader UE-V service is disabled.

Event Logs
While the Windows Event Log records the service failure (crash), it does not explicitly log the program executed by the recovery handler in the same entry.

Remediation - THE ENTERPRISE TRACK (NIST SP 800-61r3 / CSF 2.0)

GOVERN (GV) – Crisis Management

Command
Audit all Windows Service recovery configurations across the fleet immediately.

Command
Update Threat Intelligence feeds to include "RecoverIt" signatures and behavioral patterns associated with TwoSevenOneT's research.

DETECT (DE) – Monitoring & Analysis

Command
Implement SIEM logic to alert on modifications to the registry keys.

HKLM\SYSTEM\CurrentControlSet\Services\*\FailureCommand

HKLM\SYSTEM\CurrentControlSet\Services\*\FailureActions

Command
Hunting Query: Search for services[.]exe spawning unexpected child processes, particularly command interpreters like cmd[.]exe, powershell.exe, or unknown binaries.

Command
Correlate Service Failure events (System Event Log ID 7031/7034) with immediate process creation events from services[.]exe.

RESPOND (RS) – Mitigation & Containment

Command
Isolate affected endpoints identifying FailureCommand anomalies.

Command
Use the sc qfailure [service_name] command to inspect the recovery configuration of suspicious services.

Command
Reset the recovery actions of compromised services to "Take No Action" or "Restart the Service" (without running a program).

RECOVER (RC) – Restoration & Trust

Command
Verify the integrity of the UevAgentService and other unstable services.

Command
Re-image systems where persistence was confirmed, as the tool facilitates lateral movement.

IDENTIFY & PROTECT (ID/PR) – The Feedback Loop

Command
Restrict Write permissions to HKLM\SYSTEM\CurrentControlSet\Services to authorized administrators only.

Command
Disable the "Run a Program" failure recovery option via Group Policy if not required for business operations.

Hardening & References

Baseline
CIS Benchmarks for Windows Server (Service Configuration).

Framework
NIST CSF 2.0 (Protect & Detect).

Reference

Cyber Security News

 

[Halp2001]

At home it doesn’t hit you directly… unless your PC decides to play five‑star hotel for malware with admin privileges. Moral: don’t hand out master keys and keep an eye on which services think they’re immortal.”

 

[Andy Ful]

The UevAgentService is disabled by default on Windows Home/Pro and does not crash on my Windows 11 Home after using the tool from the article.
I tried this tool on several other services with no success.

 

[Andy Ful]

After changing the service status to Manual, the exploit worked.
So, on Windows Home/Pro the attack requires changing the settings of the UevAgentService.
However, in the home environment, there is not much gain, except for using another way of elevating the process from high to system privileges.
As the author noted, the main purpose of using it is to avoid Administrator monitoring.

 

[Divergent]

After changing the service status to Manual, the exploit worked.
So, on Windows Home/Pro the attack requires changing the settings of the UevAgentService.
However, in the home environment, there is not much gain, except for using another way of elevating the process from high to system privileges.
As the author noted, the main purpose of using it is to avoid Administrator monitoring.

Your assessment hits the mark on the tool's strategic intent. RecoverIt is not an exploit for initial access; it is a Post-Exploitation tool designed for Persistence and Defense Evasion. You are correct that for a Home User, the "gain" is minimal because Home users rarely employ the type of monitoring this tool is designed to bypass (SIEM, EDR, SOC analysis). Its primary value lies in the Enterprise domain, silently elevating from Administrator (High) to SYSTEM while evading standard alerts that trigger on service creation or binary path modification.

 

[Halp2001]

In a home environment this is not very attractive for an attacker, although if they already have admin keys they can unlock the service from their couch… It would only be interesting for the attacker if that house were home to an emperor of a planet where liquid gold rains and puddles turn into ingots.

 

[Andy Ful]

After a few tests, the tool was suddenly detected on execution as malicious:

Edit.
When I make an exclusion, the tool is now blocked by SAC.
Previously, SAC did not consider it dangerous.

 

[Divergent]

After a few tests, the tool was suddenly detected on execution as malicious:

View attachment 295507
View attachment 295509

Did you verify if the "trap" is still set in the Registry, even if the tool is quarantined?

 

[Andy Ful]

Did you verify if the "trap" is still set in the Registry, even if the tool is quarantined?

No registry changes now, except changing the Start value from 4 (disabled) to 3 (manual).