Fortaleza: Five Clicks to SYSTEM from the Lock Screen

You're looking at a Windows Server. Nothing exotic: an application server running an internal helpdesk portal, plus SMB, RDP and WinRM. The kind of box every company has by the hundreds.

It's going to fall three times, through three paths that have nothing in common. And the worst of the three needs no compiled exploit, no shellcode, and not a single password.

You exploit it with the mouse. From the lock screen. Before any user exists.

This is Fortaleza, one of the easy-tier tasks in the CPPJ, and the lesson it hides is uncomfortable: a server's most critical vulnerability is rarely its most sophisticated one. Everything that follows happens inside an authorized lab, on infrastructure we built for exactly this.

Not every Windows box is a domain

Before you touch anything, identify what's in front of you. If you're coming from Cetro, where the target was a Domain Controller, the scan here tells a different story:

nmap -Pn -n -sV -p 80,135,443,445,3389,5985 \
  --script "smb-os-discovery,smb2-security-mode,smb-vuln-ms17-010,http-title,ssl-cert,rdp-ntlm-info" \
  10.10.10.102

PORT     STATE SERVICE       VERSION
80/tcp   open  http          Microsoft IIS httpd 10.0
|_http-title: Spartan-Labs // Internal Helpdesk
443/tcp  open  ssl/http      Microsoft IIS httpd 10.0
| ssl-cert: Subject: commonName=expired.local
|   Not valid before: 2026-05-06T20:58:48
|_  Not valid after:  2026-05-06T21:09:18
135/tcp  open  msrpc         Microsoft Windows RPC
445/tcp  open  microsoft-ds  Windows Server 2016 Standard 14393 microsoft-ds
3389/tcp open  ms-wbt-server Microsoft Terminal Services
5985/tcp open  http          Microsoft HTTPAPI httpd 2.0

A DC gives itself away by its constellation: DNS, Kerberos, LDAP, Global Catalog. None of that here. The signature is different — IIS + SMB + RDP + WinRM — and it describes a standalone application server, not a domain authority.

One line of netexec confirms it, and it's still the highest information-per-character tool you'll run:

nxc smb 10.10.10.102 -u '' -p ''

SMB  10.10.10.102  445  FORTALEZA  [*] Windows Server 2016 Standard 14393 x64 \
     (name:FORTALEZA) (domain:Fortaleza) (signing:False) (SMBv1:True)

Read that banner slowly, because it decides your entire strategy:

• `domain:Fortaleza` equals `name:FORTALEZA`. The "domain" it reports is its own hostname. Translation: this is a workgroup, not Active Directory. Users will be local, not domain accounts, and everything you know about AD attacks does not apply here.
• `signing:False` — SMB signing isn't required. Useful for a relay, though you won't need one on this box.
• `SMBv1:True` — a protocol that should have died in 2017 is still on. That's the MS17-010 surface, and yes, the box is vulnerable. But we already opened that door in the Cetro post, so we just note it and move on.

Three doors, then. MS17-010 is the famous one. The second is a command injection in the web portal that leads to SeImpersonatePrivilege — we're saving that for part two, because it deserves a post of its own.

The third is hiding in plain sight, inside the scan you just read.

The certificate that was born expired

Go back to 443. The certificate is self-signed, it's called expired.local, and it has a quirk almost nobody looks at:

Not valid before: 2026-05-06T20:58:48
Not valid after:  2026-05-06T21:09:18

Eleven minutes of validity.

A certificate doesn't last eleven minutes by accident. Nobody configures that by mistake, and no tool generates it that way by default. This is a deliberately invalid TLS endpoint, and in a recon exercise it's exactly the kind of anomaly that separates whoever reads the output from whoever merely copies it.

Hold onto that. It means nothing yet. In two minutes it will mean everything.

The convenience feature that runs as SYSTEM

Here's the piece that turns that certificate into a key.

The box has FortiClient installed, Fortinet's VPN client, version 5.0.1.194. And FortiClient ships an option — off by default — called "VPN before logon": it lets you connect to the corporate VPN before signing into Windows, straight from the logon screen.

The business case is reasonable. A laptop booting outside the office needs to reach the domain to validate credentials; without a VPN first, there's no login. It's a feature that exists to solve a real problem.

The problem is the execution context.

Everything that happens on the logon screen runs as `NT AUTHORITY\SYSTEM`. That's not a Fortinet decision: that's how Windows works. That screen is the Winlogon session, a moment that precedes the existence of any user, so the only available context is the machine's own. The service behind the feature says it out loud:

SERVICE_NAME: FA_Scheduler   (FortiClient Service Scheduler)
    SERVICE_START_NAME : LocalSystem
    START_TYPE         : 2   AUTO_START

Now put the two halves together. If the server certificate is invalid when the VPN tries to connect, FortiClient does the polite thing: it shows you a certificate warning and asks whether you want to continue.

That dialog — and any window it opens from there — inherits the SYSTEM token.

That's CVE-2017-7344. No memory corruption, no broken crypto. Just a privileged interface that lets you reach further than its author ever imagined.

Why this box meets both requirements

The vulnerability needs two conditions at once: the option enabled, and an invalid certificate. Fortaleza has both, and you can verify them by reading the registry:

HKLM\SOFTWARE\Wow6432Node\Fortinet\FortiClient\FA_VPNSTARTER
    vpn_before_logon_enabled    REG_DWORD    0x1

HKLM\SOFTWARE\Wow6432Node\Fortinet\FortiClient\Sslvpn\Tunnels\Spartan
    Server                      REG_SZ       127.0.0.1
    promptcertificate           REG_DWORD    0x0

There's the circle closing. The VPN profile points at 127.0.0.1 — that is, at the box's own IIS, on port 443. And that IIS serves the expired.local certificate that died eleven minutes after it was born.

Meaning: every single time FortiClient tries to connect the VPN before logon, it always gets an invalid certificate, and it always fires the vulnerable dialog.

That expired.local in the nmap output was never background noise. It was half the attack, waiting for someone to connect the dots.

One thing left to confirm — that the option actually reaches the logon screen — and the registry has that too: Fortinet's credential provider is registered as a system credential provider.

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers
    {AC7DD106-EAB6-4b41-AC4F-D52FD62A82C7}   REG_SZ   FortiCredentialProvider

Five clicks

With access to the logon screen — physical, or over RDP without NLA, which 3389 allows — the whole chain is UI. Not one line of code:

1. At the logon screen, pick the FortiClient VPN profile and try to connect. The password is irrelevant: you never get as far as authenticating.
2. FortiClient validates the certificate from 127.0.0.1:443, finds it invalid, and pops the warning. Click "View Certificate".
3. On the "Details" tab, click "Copy to File...". That launches the export wizard, which opens a file dialog — running as SYSTEM.
4. In that file browser, navigate to C:\Windows\System32, type * in the filename box and hit Enter to list everything.
5. Right-click cmd.exe → "Open".

C:\Windows\system32> whoami
nt authority\system

Lock screen bypass and privilege escalation to SYSTEM in a single move. No credentials, no exploit, nothing written to disk.

The class of bug, not the bug

Memorizing "FortiClient 5.0.1.194 is vulnerable" buys you nothing: you won't meet that version at a real client. What will pay off is recognizing the pattern, because the pattern is everywhere.

It's informally known as the trusted dialog problem: an interface running at high privilege that offers you, somewhere in its flow, a file picker. And a Windows file picker is not an innocent widget — it's a miniature Explorer with a context menu, able to open, execute and rename. All with the privileges of whatever process spawned it.

The chain "warning → view details → save to file → file browser → execute" shows up again and again:

• Installers running as SYSTEM that offer a "Browse..." button to pick the target folder.
• Kiosks and demo machines where the browser is locked down but a print or download dialog opens the filesystem.
• Screensavers and accessibility tools that start before login.
• Remote support tools that run elevated to "help the user".

The question to ask in front of any privileged software is always the same:

From this dialog, can I reach a file picker? And from the file picker, a cmd.exe?

Clément Notin reported CVE-2017-7344 in 2017 by asking exactly that. It affects FortiClient for Windows up to 5.4.3 and 5.6.0; it was fixed in 5.4.4 and 5.6.1.

The other side: closing the logon screen

At Spartan-Cybersecurity we think like attackers, but a good attacker understands defense better than the people implementing it. This vector closes in four different places, and it's worth closing in all of them:

• Patch the client. The fix has existed since 2017. A software inventory that doesn't track versions of VPN clients, EDR agents and support tools leaves open exactly the category of software that runs elevated by design.
• Require NLA on RDP. Network Level Authentication forces you to authenticate before the remote logon screen is ever drawn. Without NLA, anyone who reaches 3389 gets the Winlogon attack surface; with NLA, that screen doesn't exist until you've already proven who you are. Highest-impact mitigation here, and the cheapest.
• Don't enable "VPN before logon" unless you need it. And if you do need it, the endpoint certificate must be valid. A broken certificate isn't a cosmetic annoyance — here it is literally the trigger for the bug.
• Treat the lock screen as attack surface. Everything drawn there runs as SYSTEM. Every third-party credential provider you install — VPN, fingerprint reader, MFA, smart card — widens that surface. Audit which ones are registered, and why.

On the detection side: a child process of winlogon.exe or of a credential provider that turns out to be cmd.exe, powershell.exe or explorer.exe is the kind of anomaly with no benign explanation. Any EDR can alert on that; someone has to tell it to.

What Fortaleza teaches you

A server doesn't fall because of how sophisticated the attacker is. It falls from the sum of reasonable decisions made in isolation: enabling a convenient option, leaving a "temporary" self-signed certificate in place, exposing RDP without NLA, not updating a VPN client because "it's just the VPN client."

None of those is a catastrophic mistake on its own. All four together hand over SYSTEM in five clicks.

That's the mindset we train: not the one that memorizes exploits, but the one that looks at an nmap output, sees a certificate that lasts eleven minutes, and asks why.

In part two we take the path that never touches the UI: a command injection in the web portal, a token privilege called SeImpersonatePrivilege, and the exploit family that turns any IIS RCE into SYSTEM almost by default.