The paper describes a Windows persistence method that abuses a weak signature validation path in OneDrive support binaries and DLL search behavior. The method focuses on a user-level hijack of FileCoAuthLib64.dll so that a malicious DLL executes under FileCoAuth.exe, launched indirectly by svchost.exe, without any signature check.
—
Targeted components and design weakness
DarkBit focuses on the OneDrive client stack under the per-user path:
C:\Users\<USER>\AppData\Local\Microsoft\OneDrive\X.X.X.X\FileCoAuthLib64.dll
Two binaries matter:
UserOOBEBroker.exe
FileCoAuth.exe
According to the flow on page 2, UserOOBEBroker.exe loads FileCoAuthLib64.dll and verifies its signature. When the signature fails, the broker reports an error and stops loading.
The next diagram on page 3 shows different behavior in FileCoAuth.exe. That binary loads the same FileCoAuthLib64.dll without any signature validation. The program simply calls LoadLibrary on the DLL in the OneDrive versioned directory and proceeds.
That difference in behavior creates the core weakness: a signed DLL requirement in one execution path, and no verification in another path, all pointing to the same DLL on disk.
DarkBit also notes that the replacement DLL does not require any real functional exports. The attacker only needs a valid entry point so Windows runs the initialization code when FileCoAuth.exe loads the library.
—
Attack chain and functional behavior
The document introduces a helper binary Persist.exe that orchestrates the hijack. The flowchart on page 4 shows the sequence:
1. Persist.exe runs under user context.
2. Persist.exe stops the UserOOBEBroker.exe process. That step matters because the broker currently loads the legitimate FileCoAuthLib64.dll into memory. As long as that process runs, Windows may lock or hold references to the DLL.
3. After termination, Persist.exe deletes or moves the original FileCoAuthLib64.dll from the OneDrive path.
4. Persist.exe copies the attacker DLL into the same directory with the exact same filename, FileCoAuthLib64.dll.
5. Some minutes later, according to page 5, svchost.exe launches FileCoAuth.exe automatically as part of OneDrive activity. FileCoAuth.exe loads FileCoAuthLib64.dll from the local folder. Because that binary performs no signature validation, Windows loads and runs the attacker DLL.
DarkBit highlights that FileCoAuth.exe may trigger recurrently every few minutes, so the DLL executes multiple times. The attacker DLL uses a mutex to prevent multiple concurrent instances and to enforce a single active payload.
The logic therefore links three processes:
Persist.exe sets up the hijack and persistence.
svchost.exe starts FileCoAuth.exe on a schedule or in response to OneDrive events.
FileCoAuth.exe loads and executes the malicious FileCoAuthLib64.dll under user context.
—
Persistence properties and capabilities
The technique provides the attacker with a set of practical advantages.
1. User-level, low-friction persistence
OneDrive runs by default on many Windows 10 and 11 installations. DarkBit states that testing on both versions showed successful behavior. The attacker does not require administrative rights for the core hijack, only user-level write access to the OneDrive version directory under the profile. Once in place, the DLL runs whenever OneDrive’s coordination logic triggers FileCoAuth.exe. That schedule gives repeated execution without registry edits, service installation, or scheduled tasks.
2. Signed-binary trust transference
Security tools often grant more trust to binaries under C:\Program Files or vendor directories such as OneDrive. FileCoAuth.exe and svchost.exe already hold that trust. The malicious DLL rides on top of that trust because a Microsoft-signed process loads it. Many heuristic engines focus on process creation, not on DLL authenticity inside a trusted process. The method capitalizes on that gap.
3. Flexible payload hosting
DarkBit does not restrict the behavior of the malicious DLL beyond the mutex note. The attacker crafts any payload that fits within a DLL entry point. Examples:
Loader for shellcode or a second-stage implant.
Credential theft logic focused on browser, OneDrive, or Office tokens.
Command execution stub that reaches a C2 endpoint.
The hijack stage only cares about file name and location. Payload behavior stays independent.
4. Stealth through normal file names and paths
The attack keeps all activity inside a legitimate directory, uses a legitimate DLL name, and relies on normal OneDrive binaries for execution. Forensic triage that only flags new files in unusual paths misses this change unless analysts compare hashes or signatures against a baseline.
—
Constraints and operational requirements
The approach carries several constraints that shape real operations.
OneDrive presence and versioning: The technique depends on the OneDrive client with the FileCoAuthLib64.dll architecture and the X.X.X.X version path. A different OneDrive build or removal of FileCoAuth.exe breaks the chain.
File system controls: Defensive controls that restrict modification under AppData\Local\Microsoft\OneDrive stop the DLL swap. Application control tools that block unsigned DLLs from loading into Microsoft binaries also disrupt the attack.
Visibility of process termination: Persist.exe terminates UserOOBEBroker.exe. Frequent termination of that broker process may raise suspicion in EDR telemetry, especially when correlated with file delete and create events for FileCoAuthLib64.dll.
Race conditions and integrity issues: Improper timing during deletion and replacement may cause OneDrive malfunction. An operator needs testing on target builds to avoid user-visible errors that reveal the intrusion.
—
ATT&CK alignment and tradecraft assessment
The method aligns with several ATT&CK techniques:
T1574.002 – DLL Search Order Hijacking / DLL Side-Loading: Replacement of FileCoAuthLib64.dll in the expected directory for FileCoAuth.exe.
T1053 / T1059 equivalent behaviors: Repeated, scheduled-like execution through OneDrive orchestration rather than explicit scheduled tasks.
T1547 – Boot or Logon Autostart Execution: OneDrive auto-start on user logon ensures eventual DLL execution after every reboot.
From a tradecraft perspective, DarkBit’s writeup reflects:
Solid reconnaissance of OneDrive binaries and their DLL dependencies.
Specific attention to mismatched signature checks between two loaders.
Focus on userland persistence that blends with enterprise SaaS tooling, not just classic registry or service entries.
The reference to a Telegram channel for source code distribution indicates an intent to spread knowledge of the method among offensive practitioners and script writers, which raises the probability of wide adoption.
—
Detection and defensive implications
Defenders gain several concrete detection angles.
1. File integrity around FileCoAuthLib64.dll
Security teams establish a baseline hash and signature profile for FileCoAuthLib64.dll per OneDrive version. Any unsigned or mismatched DLL in that path indicates tampering. Regular integrity checks on %LOCALAPPDATA%\Microsoft\OneDrive\*\*.dll expose such swaps.
2. Process and module monitoring for FileCoAuth.exe
Monitoring for module loads inside FileCoAuth.exe reveals non-Microsoft DLLs or unsigned images. A security product that correlates process name, publisher, and loaded module signature gains a strong signal.
3. Behavioral chaining around Persist.exe-like activity
Analysts create rules for patterns that combine: termination of UserOOBEBroker.exe, file delete or rename events on FileCoAuthLib64.dll, followed by a new DLL with different hash in the same path. That chain sharply narrows benign explanations.
4. Hardening strategies
Elevated logging on OneDrive directories, application control rules that restrict who writes DLLs under Microsoft directories, and periodic validation of signed modules inside Microsoft processes all reduce risk. Security teams also pressure vendors to enforce signature checks in every loader path so no secondary binary repeats the same weakness.
—
Intelligence judgment
The method does not introduce a brand-new class of persistence; the novelty stems from a specific victim stack and a signature gap between two Microsoft binaries. DarkBit’s paper documents a reliable path for user-context persistence on Windows 10 and 11 through OneDrive DLL hijacking with limited preconditions.
From an intelligence angle, the technique lowers the barrier for mid-tier actors who favor stealth over raw privilege escalation. Malware families that already depend on OneDrive token theft or that operate in enterprise environments with heavy OneDrive use gain a natural persistence upgrade. Defenders who track tradecraft evolution around SaaS clients and vendor helper binaries should treat this paper as an early indicator of more OneDrive-centric persistence chains that follow the same pattern: identify support DLLs, find weak signature or path checks, replace the DLL, and ride trusted vendor processes for long-term footholds.
