In this article, we covered part 6 of Windows persistence techniques through MSSQL Server as part of TryHackMe win local persistence.
It explores using SQL Server as a persistence mechanism. After compromising a Windows machine, the attacker uses Microsoft SQL Server (MSSQL) to maintain long-term access by embedding malicious behavior through SQL triggers—automated responses to database events such as INSERT operations.
Understanding SQL Triggers
SQL triggers are functions that execute automatically when specific actions occur in a database (e.g., INSERT, DELETE, LOGIN). These can be exploited to run payloads whenever a user interacts with the database—such as adding records to a table—without needing user awareness or interaction.
Access Requirements and Privilege Escalation
The attack assumes prior system access and administrative privileges on the database. Using the default sa (System Administrator) account in MSSQL, the attacker enables powerful features and ensures all users can impersonate this account. This impersonation is critical, as it allows even low-privileged accounts to run system commands through xp_cmdshell.
Exploitation Through xp_cmdshell
This attack method’s built around a quiet but forceful backdoor. The attacker slips in through something routine—a database trigger—and plants malicious code that springs into action every time someone adds a new employee. On the surface, it looks like business as usual. Behind the scenes, it’s setting up a live connection back to the attacker.
First, the trigger sits in the employees table of the hrdb database. Every time someone inserts a new employee through the website, that trigger runs. But instead of just updating a log or sending a notification, it runs a PowerShell command that calls home. The script it calls—evil.ps1—is hosted by the attacker and reaches out to them, giving them direct access into the system.
To get this trigger to fire, the attacker just creates a new fake employee using the site’s form. Looks normal. But this quiet move flips the switch, and the SQL Server’s xp_cmdshell feature does the rest, running the downloaded PowerShell script like it’s part of everyday operations.
At first, things don’t go smoothly. The script’s syntax isn’t quite right, and it fails. But after a quick fix—replacing the download method with Net.WebClient—the second trigger does the trick. The attacker gets their shell.
Once they’re in, they start poking around, moving through directories and checking for files. Eventually, they grab a flag file—proof they’ve gained control. Not stopping there, they also prep an alternative method: uploading an ASPX shell to keep another door open.
What makes this attack stand out isn’t just the entry point—it’s how it hides in plain sight, riding on a normal feature of the system that no one questions. It blends in. That’s what makes it dangerous.
Impersonating The sa User
Giving everyone permission to act like the sa user in SQL Server is like handing out master keys to your entire building—no locks, no controls, no trace of who’s doing what. It’s one of the worst things you can do when it comes to database security.
Here’s what happens when impersonation of sa is allowed for all users, especially the public role:
Anyone becomes the admin.
The sa account isn’t just powerful—it’s all-powerful. It can access and change anything in the database. If you use GRANT IMPERSONATE ON LOGIN::sa TO public;, you’re basically saying, “Everyone’s now an admin.” That includes every low-level user, app connection, or even anonymous access points.
Then there’s xp_cmdshell
Once users can act as sa, they can run OS-level commands straight from SQL Server. That means they can read files, write files, start programs, open reverse shells—you name it. What should be a locked-down database suddenly becomes a gateway to your entire server.
This isn’t a one-time mistake, either. Once the impersonation is set up, any future access—even from a compromised user account—can jump right back into admin territory without needing to exploit anything else. It’s a built-in backdoor.
The least privilege principle?
Gone. Normally, you’d give users just enough access to do their jobs and nothing more. But impersonating sa tosses that idea out. It means every user could reach the most sensitive parts of the system. That doesn’t just increase risk—it multiplies it.
In short, letting users impersonate sa turns small problems into disasters. It’s the kind of thing that attackers hope to find—and defenders should never allow.
Windows Persistence P6 | TryHackMe Room Answers
Insert flag10 here
THM{NO_NO_AFTER_YOU}
Insert flag11 here
THM{LET_ME_HOLD_THE_DOOR_FOR_YOU}
Insert flag12 here
THM{I_INSIST_GO_FIRST}
Insert flag13 here
THM{USER_TRIGGERED_PERSISTENCE_FTW}
Insert flag14 here
THM{BREAKING_THROUGH_LOGIN}
Insert flag15 here
THM{THE_LOGIN_SCREEN_IS_MERELY_A_SUGGESTION}
Insert flag16 here
THM{EZ_WEB_PERSISTENCE}
Insert flag17 here
THM{I_LIVE_IN_YOUR_DATABASE}
