4 ways to harden Microsoft Windows infrastructure

Public and private infrastructures both small and large across the world use Microsoft, despite it being the bane of many security professionals’ existence. It is by far the most widely used operating system and also the most commonly misconfigured. Misconfigurations in Windows operating systems and software contribute to a vast number of security issues and compromises. In fact, Exploit Database currently has over 8,000 exploits running under the Windows platform.

With the staggering amount of verticals that Microsoft currently covers, let’s focus on where it most commonly comes into play in the enterprise environment. Performing these steps significantly decreases vulnerable attack surface and improves detection capabilities (and also might help you sleep better at night). We’re not doctors; no guarantee.

1. Upgrade to supported software versions

First and foremost, you should upgrade endpoints to a supported operating system. While corporations struggle to move off of Windows XP (and shockingly even older operating systems) the threats keep piling up and the technology forges on.

Often there are situations that arise from either a pesky vendor-controlled system or another type of device that leaves you in the unfortunate position of not being able to apply updates. Many proprietary software packages for various industries were specifically written for XP and Server 2003, which make this especially challenging for many enterprise environments. As a result vulnerabilities like MS08-067, which is an easy remote code execution bug, are still commonly found. In cases like these, the devices should remain off of the network as a matter of policy. If this is not a viable option, the next secure option would be to have them on private VLANs or an air gapped network.

As shown in the figure below XP users are down almost a full 6% in the last year, still holding on at almost 11% market share, even though support ended April of 2014.

Desktop operating system market share Q1 of 2016

Another challenge is that security takes a back seat when there is no meaningful communication to stakeholders on the potential for profit loss these outdated devices and systems pose. When businesses cling to old technology, their security risk increases. The lack of software support means that you are no longer protected from any new exploits, will not receive fixes for software bugs, and won’t have the ability to take advantage of new features. Paying for prolonged support on defunct technology just delays the inevitable upgrade while increasing the potential for security incidents.

Migrating off of a legacy platform has it’s own costs in the form of many different software upgrades, data migration, and possibly even necessitating a switch to new vendors. However, using unsupported and outdated versions presents the inherent risk of data loss, network outages, breaches, and/or fines.

2. Regularly patch third party software

Another commonly overlooked protection is the use of a software update platform. Windows Server Update Services (WSUS), System Center Configuration Manager (SCCM), and other third party applications can keep your endpoints up-to-date with the latest security patches. Not only should windows system patches be executed, but you should also be focused on patching outdated versions of commonly exploited software such as Java, Adobe Reader, Firefox, and others used within your organization.

Through asset management, you should have a full account of the software that exists in your environment. As an organization, you should also consistently evaluate the necessity of each piece of software within the environment. Do all endpoints really need Adobe Flash? Hint: No they don’t.

3. Scan for open shares

Open shares can cause a myriad of security problems. From saved credentials, trade secrets, to PII and other sensitive data, file shares frequently house important and sensitive assets. The following nmap command should be run on a regular basis to discover any new open shares.

(line breaks added to commands for readability)

nmap -T4 -v -oA myshares --script smb-enum-shares –script-args
smbuser=MyUserHere,smbpass=MyPassHere -p445 192.168.0.1-255
&& cat myshares.nmap|grep ‘|\|192’|awk ‘/[0-9]+\.[0-9]+\.[0-9]+\.
[0-9]+/ { line=$0 } /\|/ { $0 = line $0}1’|grep \||grep -v -E 
‘(smb-enum-shares|access: <none>|ADMIN\$|C\$|IPC\$|U\$|access: READ)
’|awk ‘{ sub(/Nmap scan report for /, “”); print }’ >> sharelist.txt

This can also be accomplished by using Powershell:

$$$servers = get-content c:\temp\servers.txt 
#Provide an account that has rights to enumerate the shares 
$cred = get-credential 
get-wmiobject Win32_Share -computer $servers -credential $cred | 
select __server,name,description,path | export-csv 
c:\temp\sharereport.csv -notype$$

4. Carefully configure and patch MS-SQL servers

SQL Servers can be easy targets for attackers, if not configured and patched properly. There are a wide variety of tools and methods you can put in place to provide privilege escalation and access to database information.

When third party vendors have access

It is a common practice to give vendor’s support access to the database or database server that they support. Some security considerations that are vendor-specific are listed below.

• Require the vendors to use SQL Server’s native security instead of one pre-defined account for all user connections. When only one user account accesses the data, accountability is lost.
• When new applications are purchased, ensure that clients will not be connected to the SQL Server using a login and password stored in a connection string.
• Audit vendor configurations when new applications are purchased.
• Ensure that the vendor does not store unencrypted logins and passwords required by the application in .sql files, .xml files, .cfg files, .ini files, or record them in .log files.
• Ensure the authentication and activity of vendor accounts are monitored as well as disabling them when not in use.
• Do not allow the vendor to control/use the SA login. A vendor should not require the SA login for equipment that your organization owns.
• Do not store sql logins and passwords unencrypted in plain text files of any kind.

MS SQL authentication

SQL Server supports two authentication modes. The mode is selected during installation, but can also be changed later. When authentication modes are changed, all client connections will also need to be changed to the new mode in order for the server to remain operational. The security mode required is determined by the type of client connections used with the application databases on the SQL Server. If all client applications support trusted connections, use Windows Authentication Mode. If some clients do not support trusted connections, use Mixed Mode.

Windows Authentication mode – this method relies solely on Windows authentication of the login. Connections using this mode are known as trusted connections. This is the most secure mode, as it does not send logins and passwords over the network unencrypted. Use Windows Authentication mode whenever possible. When Windows Authentication is enabled, Windows credentials are trusted to log onto SQL Server and passwords are not passed across the network during authentication.

Mixed Authentication mode – logins can be authenticated by Windows Authentication or by SQL Server Authentication. Mixed mode is available for backward compatibility with legacy systems. In order to access data from a SQL Server database, a user must pass through two stages of authentication – first at the SQL Server level using a SQL LOGIN and then at the database level using a DATABASE USER.

SA user security – SA is the built-in system administrator account that exists on every MS SQL Server. Because it is well-known and has full rights on the SQL Server it is often targeted by malicious people. The SA login can not be deleted. The SA login can be renamed, but that doesn’t change its SID (which is always 0x01) and it can still be found. Members of the sysadmin fixed server role have complete control of the SQL Server.

Some general SQL authentication best practices are listed below:

• Have a strong password (as required by the SQL install).
• Limit the number of logins with sysadmin privileges.
• The service account running MS SQL needs to be a sysadmin with a strong password.
• Always run SQL Server services by using the lowest possible user rights, such as a minimally-privileged domain account. Many server-to-server activities can be performed only by a domain user account. Avoid granting additional permissions to this account.
• Never connect clients to the database using the sa account in any connection string, ODBC connection, OLE initialization file, etc. This includes interfaces and report writers. Use the least powerful login possible.
• Never store the sa password in a file of any kind other than password safe. No sysadmin password should ever be stored.
• Avoid using the sa login, pull it out for emergencies only

If Windows Authentication is being used, the sa account is disabled. Enable it, assign a strong password, disable it again, and setup monitoring of any account activity surrounding it’s use. Why? A malicious person can easily change the server to Mixed Authentication mode by updating the registry and restarting the SQL service. They then have the ability to change the SA password to one of their choosing.

To change this setting in SQL Server Management Studio, right-click the server, Properties, Security page. Under Server Authentication click the radio button for SQL Server and Windows Authentication mode, enter and confirm a strong password, click OK to save the change. Following this step, go back to the security page and set the authentication mode back to Windows Authentication mode and click OK to save.

There are countless configuration possibilities across all Microsoft products, however these four suggestions will cover the low-hanging fruit and give you the ability to pause before tackling the next hurdle in the environment. A great number of commonly scripted offensive attack scenarios can be mitigated with creating a structured and least privilege Microsoft environment.