Whenever a worm utilizes the normal access and daily tools systems admins use, there is a significant problem. After all, shutting down the attack vector suddenly isn’t that easy. So, without making dramatic changes to your environment, how can you rest assured?
One of the latest threats to use administrative access is Win32/Morto. This worm scans entire IP address ranges for port 3389 and uses the Remote Desktop Protocol (RDP) to log on to the Remote Desktops of Windows machines through guessing usernames and passwords. When it succeeds it uses an exploit to gain administrative access to try and infect other machines.
We’re now seeing the first version of this worm, but since the modest success of it, we might see other incarnations sporting longer username and password lists alongside other exploits. In a worst case scenario, Morto might evolve to include brute forcing techniques to gain access to machines.
Remote Desktop Protocol (RDP) is used heavily by admins to log on to workstations and servers. Although manageability features in newer versions of Windows allow admins to remotely perform (routine) actions through PowerShell, Group Policy Preferences and Server Manager, many admins still rely on Remote Desktop. Especially when they need to change settings in non-Microsoft products running on top of their machines. Switching off Remote Desktop is not seen as a solution to defend against this threat.
Many Internet-facing Windows webservers have Remote Desktop enabled to allow the admin to manage the server remotely. Either from the office or home, since flexibility is key when the box gets compromised.
Many organizations work with passwords to allow their employees to authenticate. In recent versions of Windows, password complexity is enforced by default, but in many organizations people are allowed to use weak passwords, either for (reduced) single sign-on or other reasons. Two factor authentication is not widely used, especially not for service accounts.
Shutting off Remote Desktop is not an option in these situations, so how does one effectively defend against Morto?
Defending against Morto.A
You can effectively battle Morto.A in many ways. I’ll describe the countermeasures below. Combining multiple of these countermeasures increases your success:
Apply a stringent and complete authentication policy
A good defense is to use strong passwords throughout the networking infrastructure. Since tokens or smartcards can not be implemented overnight and are not suitable for all authentication purposes (for instance service accounts), this is probably the best short term defense.
Windows and Active Directory both include password policies. Since Windows Server 2008, the option ‘Password must meet complexity requirements’ is default enabled, requiring newly set passwords to adhere to complexity rules. These rules include the use of at least 7 uppercase and lowercase characters, numbers and non-alphanumeric characters (3 out of 4) and prevent the use of a significant portion of the logon name. Other tidbits of the default password policies include a minimum length of six characters.
In many environments, these password policies were (temporarily) disabled. From an authentication security point of view this is horrendous, since it allows anyone to use weak passwords. Even admins can use weak passwords to secure the service accounts, most of which are able to log on anywhere.
You have a couple of options on getting your users to use stronger passwords:
- Re-enable password policies
For a stand-alone server, this is accomplished through the Local Security Policy (secpol.msc) under Account Policies in the Password Policy.To change the password policies for an entire Active Directory domain, open the Group Policy editor (gpedit.msc) and browse for the default domain policy. Here under Computer Configuration, then Windows Settings, Security Settings, Account Policies and finally under Password Policy change the settings for minimum password length and password complexity. Changing these setting in another group policy on the domain level, will lead to the above change in the default domain policy. Changing these settings on another level in Active Directory (for instance on a Site or Organization Unit will not have an effect on user accounts in the domain).Off course, for your entire network, you might need to change these settings on all your domains.
If you want to restrict password policies to users of your Terminal servers only, you’ve set up your environment according to best practices and you’re using at least Windows Server 2008 Domain Controllers, you can also create a Fine-grained Password Policy to the ‘Remote Desktop Users’ group.
- Clearing the ‘password never expires’ settings on user accounts
Getting everyone a new password is not as easy as re-enabling the default password policy. Some users may not be compelled to change their passwords (since the option ‘Password never expires’ is checked in the account properties), while other users still have a lease on their current passwords, that only compel them to change it in a couple of weeks. The below one-liner script will clear the ‘Password never expires’ for all user accounts in a certain Organizational Unit:
dsquery user "ou=useraccounts,dc=domain,dc=tld" | dsmod user -pwdneverexpires no
- Setting the ‘User must change password at next logon’ attribute
Again, enabling password policies for new passwords and clearing the ‘password never expires’ settings is not enough. Users will still have passwords that don’t need to be changed, simply because these passwords are not at the end of their lifetime (as defined in the password policy). To force all users in a certain Organizational Unit to change their password, use the following one-liner:
dsquery user "ou=useraccounts,dc=domain,dc=tld" | dsmod user -mustchpwd yes
Secure Service Accounts
Changing passwords on Service Accounts is not a small change. Breaking essential services like Exchange Server or the backup is not an appropriate risk to take in order to defend against Morto.
On of the new features of Active Directory in Windows Server 2008 R2 is Managed Service Accounts. Managed Service Accounts (MSAs) are virtual domain accounts that can be used on Windows 7 and Windows Server 2008 R2 in Active Directory environments running Windows Server 2003 and Windows Server 2008 Functional levels. Domains at the Windows Server 2008 R2 functional level provide native support for both automatic password management and SPN management. This means, that when you’re only running Windows Server 2008 R2-based Domain Controllers, you don’t need to worry about Service Account passwords no more; Active Directory will take care of that (with the restriction that you can only use an MSA on one domain member).
Another route to prevent the misuse of Service Accounts by Morto, is to deny them rights to log on through Remote Desktop Services. You can achieve this simply by creating a Group Policy and specifying a group containing all Service Accounts in the ‘Deny log on through Remote Desktop Services’ under User Rights Assignment, under Local Policies, under Security Settings in the Windows Settings of the Computer Configuration.
Change the usernames for well-known accounts
Guessing the password for a built-in Administrator account would be any attackers first attack vector. Changing the name of these accounts is an effective way for you to prevent these attacks through Remote Desktop Services.
An alternative route would be to disable local administrator accounts and securing the domain administrator with a password no-one knows. Then, you might consider using accounts with administrative privileges for each of your systems administrators. Admin_SBerkouwer or SBerkouwer9 would be good ways to denote an account with administrative privileges I can use besides my non-priviledged SBerkouwer account.
Renaming local administrative accounts can be done through Group Policy.
I would like to add, this is a security best practice, I would like to see in any network.
Apply an environment-wide Password Lockout policy
While eradicating weak passwords throughout your enterprise is a good step, this on its own results on a more or less unmanageable network. Remote Desktop Servers might be unresponsive due to logon attempts and security logs might fill so quickly, tracing back to where Morto entered the network becomes impossible due to overwritten logs.
This is where Password Lockout comes to the rescue. Although Password Lockout policies are not enabled by default in any version of Windows or Active Directory, it is a best practice to detect and defend against guessing and brute forcing passwords.
The reason why Account Lockout policies are not enabled by default, is because they might hinder your people to log on and burden servicedesk personnel. Good lockout policies, therefore, are key. Setting a permanent account lockout after three invalid attempts will prove to be career suicide. Locking out an account for two minutes after ten invalid attempts would be equally effective against Morto, but would not hinder any normal person much.
In every Active Directory domain in your network, define an account lockout policy in the default domain policy under Windows Settings, Security Settings, Account Policies and finally under Lockout Policy. Changing these setting in another group policy on the domain level, will lead to the above change in the default domain policy. Changing these settings on another level in Active Directory (for instance on a Site or Organization Unit will not have an effect on user accounts in the domain).
If you want to restrict account lockout policies to users of your Terminal servers only, you’ve set up your environment according to best practices and you’re using at least Windows Server 2008 Domain Controllers, you can also create a Fine-grained Password Policy to the ‘Remote Desktop Users’ group.
Report on invalid logon attempts through auditing
After you’ve created password and account lockout policies, you can easily detect invalid logon attempts throughout your enterprise, right from the security logs of your Domain Controllers for domain accounts. For local accounts (for instance the local administrator accounts on the Remote Desktop Servers themselves) the security logs of the servers provide valuable information.
For Domain accounts you can put the ‘Audit account logon’ policy to good use. After you enable the auditing of failures in the default domain policy under Computer Configuration, Windows Settings, Security Settings, Local Policies and finally in Audit Policy. For Audit Account Logon Events and Audit Logon Events, enable the auditing of both success and failure.
Now, the events to look for and where to look for them depends on the Operating System versions of your Domain Controllers:
- Windows 2000 Server-based Domain Controllers
When you’re running Windows 2000 Server-based Domain Controllers, you need to check the Security logs of all your Domain Controllers. Microsoft KnowledgeBase article 824209 explains how to download and use EventCombMT to ease this pain. EventCombMT has predefined filters to scan for invalid logon attempts and account lockout policies, but if you want to go commando you’ll want to report on the following events:
- Windows Server 2003-based Domain Controllers
In a domain with Windows Server 2003-based Domain Controllers or newer Domain Controllers, you can check the event log of one of the Domain Controllers, since the security events surrounding invalid logon attempts and account lockouts get replicated between all Domain Controllers. You’ll want to report on the following events:
- Windows Server 2008 and Windows Server 2008 R2-based Domain Controllers
In Windows Server 2008, new events were created with the new auditing policies. You’ll want to report on the following events:
For your Remote Desktop Hosts, it’s also important to scavenge the security logs. Using Group Policy from within Active Directory, make sure to audit for logon events and also start looking for events 529, 539 and 12294. These would indicate username and/or password guessing.
Limit the reach of your Remote Desktop availability
I’ve seen virtual local area networks (VLANs) being used more and more over the past years. Now, I see companies defining VLANs for servers, printers and desktops. VLANs for the desktops of systems administrators is not a very common practice yet.Through VLANs, access can be restricted to critical servers. For instance, using VLANs for critical servers and administrative personnel, you could limit TCP 3389 to these servers to administrators only.
If you’re not using VLANs, you can still achieve the same goal, through the use of the Windows Firewall and DHCP reservations.
DHCP reservations allow you to assign IP addresses to machines with specific MAC addresses. These addresses are Network Interface Card (NIC)-specific. Placing the desktops (and laptops) of systems administrators in a specific range of IP addresses, allows for Windows Firewall rules on other machines. (whether they’re servers or workstations). You can then limit access to Remote Desktop Services to IP adresses in the 192.168.1.x range, through the following command:
netsh advfirewall firewall set rule name="Remote Desktop (TCP-in)"
Alternatively you can use remoteip=192.168.1.0/24 to specify these computers.
If you’re using Remote Desktop on a webserver and you, as a systems administrator, manage it from a slew of IP addresses, limiting the reach of Remote Desktop Services through remote IPs is not really a good solution. In that case, securing Remote Desktop using IPSec, might be the way to go. Microsoft KnowledgeBase article 315055 explains it.
Alternatively, when your webserver already listens to IPv6 traffic, you might choose to enable the Remote Desktop Protocol to aNetwork Interface Card (NIC) assigned with an IPv6 address only. Within the Terminal Services Configuration snap-in (tsconfig.msc) on the Network Adapter tab of the RDP-Tcp properties you can select the Network Interface card from the list. Morto doesn’t scan for RDP on IPv6 addresses, yet.
Apply a centrally managed anti-malware solution
Many anti-malware vendors have added signatures for Morto.A and will add signatures for future versions of Morto when they get spotted in the wild. Even if the measures above seem inadequate or inappropriate to your situation, you might still be safe from most of the harm the Morto.A worm does, since the payload gets detected and removed when it first hits your environment. (most likely a managed desktop or laptop). An up to date anti-malware solution will prevent Morto.A from spreading and at the same time inform you of any (detected and removed) infections.
Apply a centrally managed Microsoft update solution
Since Morto.A uses an exploit to wreak havoc on your machines, it is sensible to patch the servers with critical updates fast. Fast, in this context, might mean hours, but in the case of a fully automated testbed for Microsoft updates, might also mean weeks. The rule of thumb here is to be quicker getting critical updates on your systems, than attackers are exploiting them.
Windows Server Update Services (WSUS) can be used free of charge, when you’re already using Windows Server. For more control or tested updates, Microsoft System Center Configuration Manager or Novell Patch Manager can be used. Although these two solutions cost a significant amount of money per managed desktop/laptop, they add significant benefits.
To effectively defend against Win32/Morto.A, perform the following actions:
- Apply a stringent and complete authentication policy
- Deny Service Accounts to log on through Remote Desktop
- Changing the usernames for well-known accounts
- Apply an environment-wide Password Lockout policy
- Report on invalid logon attempts through auditing
- Limit the reach of your Remote Desktop availability
- Apply a centrally managed anti-malware solution
- Apply a centrally managed Microsoft update solution
This will provide a layered defense and adequate detection mechanisms. Don’t worry if you can’t perform all the above actions, you’ll be pretty safe given the circumstances.