Improving Your Simple Windows Domain for Offensive Testing: Installing MS SQL Server Express on Windows Server 2022 Server Core Edition

by Justin Palk

A couple of years ago, I put together a series on standing up a simple Windows AD domain in a lab environment. This article is part of a new series on adding additional capabilities to make the lab an even more useful environment for practicing tradecraft.

The orignial lab setup included a web server and a file server. This post explains how to add a MS SQL Express database server instance to a server running Windows Server 2022 Server Core edition. When I first stood up the lab I used standard server instances for the file and web servers. When I had to rebuild my lab recently, I decided to move these hosts to Server Core instances, as they used slightly less RAM. Server Core includes all the key features of regular Windows Server, save one – there is no GUI. Everything is done via the command line, or over remote management. We’re all good with PowerShell, right?

Absent a GUI, installing SQL Server Express is a little more complicated. To start, download the installer from Microsoft (this link is for the 2022 version). Run the installer and select the Download Media option.

When given the option for which package to download, choose Express Core.

You should now have a package SQLEXPR_x64_ENU.exe in the download folder you chose. Transfer this file to your server. I put SSH on the servers, so I transferred it over using scp.

Access the server’s command line via either SSH, PowerShell remoting, or through the console in your hypervisor, navigate to the directory to which you uploaded the SQL Express installer and unpack it as shown below.

Change directories into the SQLEXPR_x64_ENU directory, and then install SQL Server Express using the command shown below (tailored for your environment).
SQLEXPR_x64_ENU.exe /Q /ACTION=Install /FEATURES=SQLEngine /INSTANCENAME=<your instance name> /SQLSVCACCOUNT="NT AUTHORITY\NETWORK SERVICE" /SQLSYSADMINACCOUNTS="<yourdomain>\<sql admins group>" /TCPENABLED=1 /IACCEPTSQLSERVERLICENSETERMS

The screenshot below shows me installing SQL Server Express in my lab.

At this point, SQL Server Express is installed, and we can use the Windows command shell’s sc command to confirm the service is running and configured to start automatically.

But if we were to try and connect to the server, we’d quickly encounter a problem. Jumping over to my lab’s Kali box, I run a quick portscan and discover neither port 1433/tcp nor 1434/tcp is open.

There’s actually two problems blocking us here. The first is that by default SQL Express uses a random high port for access. We can fix this with a couple of quick registry edits. First we need to disable the dynamic ports feature, and then we need to set the static port to 1433/tcp using the commands below. Note that you’ll want to run these in a command shell, not PowerShell.

reg add "HKLM\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL16.<your instance name>\MSSQLServer\SuperSocketNetLib\Tcp\IPAll" /v TcpDynamicPorts /t REG_SZ /d "" /f

:: Assign static port 1433
reg add "HKLM\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL16.<your instance name>\MSSQLServer\SuperSocketNetLib\Tcp\IPAll" /v TcpPort /t REG_SZ /d "1433" /f

:: Restart the service again
net stop MSSQL$SQLEXPRESS && net start MSSQL$SQLEXPRESS

The second issue is that we need to open the firewall, like we’ve done for a couple of other services in the lab. On your DC, go to the Server Manager and select the Group Policy Management option from the Tools menu, as shown below.

In the Group Policy manger, navigate into your domain’s Group Policy Objects folder, right click on it and select New.

In the GP management editor, go to Computer Configuration → Policies → Windows Settings → Security Settings → Windows Defender Firewall with Advanced Security → Windows Defender Firewall with Advanced Security and right-click on Inbound Rules and select New.

On the Rule Type screen, select Port.

On the Protocols and Ports screen, select TCP, and Specific local ports, specifying 1433.

Then, on the Action screen, select Allow the connection. We can leave the defaults for the profile since this GPO is only going to apply to VMs in an isolated VLAN, and then give the rule a name like “Allow MS SQL in”. Once you’ve added the firewall rule, close the GPO editor and back in the Group Policy Management tool drag the new rule from the Group Policy Objects folder to the Server folder to link the GPO. Then, back on your server, you can either restart the host, run gpupdate in the shell, or just wait for the GPO to take effect. Now, if we scan the SQL Server port, we find that it’s open.

I’m going to leave it as an exercise for the user to populate data into the database, but now we have a lab target against which we can execute tools such as PowerUpSQL, SharpSQL and the like.

---

About Justin Palk, Senior Security Consultant:

Justin Palk has more than 16 years of experience in IT and information security, and has worked in the academic, federal civilian government and health research sectors. He has held a variety of roles including system administrator, developer, auditor, assessment team lead and web application penetration tester. He regularly competes in CTFs in the U.S. and Europe.

Certifications:
GCIH, GWAPT, GPEN, GMOB, GDSA