Chapter 4: Windows Honeypot Deployment

		Chapter 4 - Windows Honeypot Deployment Honeypots for Windows by Roger A. Grimes Apress 2005

A common honeypot choice for first-timers and experienced pros alike is to use a real installation of one of Microsoft’s OSs. Using a bona fide OS requires a heavy emphasis on data control for the honeypot administrator, but almost guarantees that the intruder won’t immediately spot the telltale signs of a honeypot trap. This chapter covers which Microsoft OS to choose, how it should be set up, and how to keep the intruders from taking complete control of the honeypot.

Decisions to Make

When choosing to use a genuine OS as your honeypot platform, you need to make several important decisions:

• Do you really need a high-interaction honeypot?

• Should you use a real OS or a VM?

• Which Microsoft OS should you install?

• Should you have a client or server OS?

• Should you patch the OS or leave it without patches?

• What support tools are available?

• Which services and applications should you install?

• Should you use Security Account Management (SAM) or Active Directory (AD)?

• What OSs do hackers prefer?

• What hardware will you need?

Let’s look at what’s involved in each of these decisions.

Do You Really Need a High-Interaction Honeypot?

Do you really want all the hassles a high-interaction honeypot brings to your environment? Although a high-interaction honeypot is going to appear as a production system and give hackers the juiciest target to explore, the upkeep and maintenance are the highest of any of the honeypot choices.

The most critical issue is how to control hackers once they have compromised the honeypot system. In a very real sense, if the hacker is able to execute an unknown program or script on your system, you can’t really trust the system anymore. System executables could be modified to hide the honeypot’s activity. Inband monitoring tools could be modified to hide the hacker’s real intent. You should be able to trust your external monitoring tools, but all data collected directly off the system should be considered suspect. This chapter will discuss some of the tools and techniques you can use to attempt to discover what your hackers did and what software they installed.

Note 

Inband monitoring refers to tools that operate within the normal communication channels of the OS. Inband monitoring tools can be detected by the hacker, because they are readily visible to the hacker if the hacker looks for them. Out-of-band monitoring uses mechanisms and resources not readily visible to resources and users within the OS. More on this in Chapter 10.

Another critical issue is how you will ensure that the hacker doesn’t use your Windows honeypot to attack other production systems. Data control is the issue here, and, as discussed in previous chapters, mature solutions aren’t widely available in the Windows world.

In order for the honeypot to appear realistic, you will need to develop content to place on the computer. Potentially, you will need to develop a content update plan. How often will the content be updated? Who will update it? Will you need to log in to the machine and create normal-looking user activity so that file-use dates and log files are updated realistically? The normal process of logging in to Windows updates dozens to hundreds of files. Even a standalone system without any users logging in to it would have frequent file and Registry update activity. The lack of any noticeable signs of activity could be suspicious to the intruder.

Real Operating System or Virtual Machine?

Another choice is whether you want to run a real OS or host it using a virtual or emulated environment, like VMware or Virtual PC. As covered in previous chapters, a stand-alone OS is easier to deploy initially, but a VM environment allows quick redeployment, better data control, and centralized monitoring. However, if a hacker is looking for the specific clues, a VM environment can always be revealed. This chapter will discuss how to deploy both real OSs and VMs.

Which Microsoft Operating System to Choose?

Microsoft offers more than a dozen OSs you can deploy, including the following:

• Windows for Workgroups 3.11

• Windows 95/Windows 95 OSR2

• Windows 98/Windows 98 Second Edition (SE)

• Windows Millennium Edition (Me)

• Windows NT Server 3.51

• Windows NT Workstation 4.0

• Windows NT Server 4.0

• Windows NT Server 4.0 Terminal Server Edition

• Windows NT Server 4.0/4.5 Small Business Server Edition

• Windows 2000 Professional

• Windows 2000 Server

• Windows XP Home Edition

• Windows XP Professional Edition (32- and 64-bit versions available)

• Windows Server 2003 (32- and 64-bit versions available)

• Windows Small Business Server 2003

• Longhorn (32- and 64-bit beta versions available)

This list doesn’t include the less popular versions, such as other beta releases, embedded versions, and mobile platform choices like Windows CE or Pocket PC. There are even computers still actively running Microsoft MS-DOS.

Many of the base OS platforms are further divided into different editions. For instance, Windows Server 2003 comes in Web, Standard, Enterprise, and Datacenter editions. The Enterprise Edition is the version that the other editions should be compared against. The Web Edition is essentially meant to serve as a web server and does not support many features of the other editions. The Web Edition supports only a maximum of 2 CPUs and 2GB of RAM. It cannot be a domain controller, but it can participate in Active Directory. It also cannot host Microsoft Certificate Services, Volume Shadow Copying, Terminal Services, or Cluster Services. The Standard Edition of Windows Server 2003 has the same software applications and services as the Enterprise Edition, but has more restricted license limitations. The Datacenter Edition is not sold through normal channels, and it is usually bought as part of high-end database solution purchase. Most Windows Server 2003 honeypots I’ve seen are the Enterprise Edition. This is because the price is right, with Microsoft offering a free 180-day evaluation version. The Web Edition is also a popular choice, with its list price starting around $399. For more information about Windows Server 2003 pricing, see http://www.microsoft.com/windowsserver2003/howtobuy/licensing/pricing.mspx.

Remember that a Windows honeypot requires a licensed copy of the OS, plus any necessary client access licenses (CALs). Most of the time, when you purchase the OS, you get at least five CALs with the base product. This should be fine for most honeypots. If you are using the honeypot to attract hackers to IIS, you do not need separate CALs unless the attackers would be authenticating to a back-end SQL Server machine (not likely).

Note 

The licensing guidelines presented here are subject to change. Check with your authorized Microsoft distributor regarding licensing requirements.

Longhorn is Microsoft’s next client and server base OS, which is expected to be released in 2006 or 2007. Beta copies are widely available in Microsoft’s beta and Microsoft Development Network (MSDN) forums. Figure 4-1 shows a screen from a beta version. Longhorn is a significant Windows upgrade with a moderate learning curve, much like the differences introduced between Windows 3.11 and Windows 95. The most talked-about Longhorn features are a SQL Server–based storage engine called Windows Future Storage (WinFS), IPv6, Microsoft’s Trustworthy Computing architectural changes, a new 3D video-driven user interface, new low-level APIs, and new integrated antivirus and firewall features. A future Windows Server release, code-named Blackcomb, will likely ship two to three years after Longhorn. For more details, visit http://www.winsupersite.com/longhorn. You may want to create a Longhorn research honeypot to see if its increased default security features make it more resistant to attack than its predecessors.

Figure 4-1: A Microsoft Longhorn screen

Note 

Microsoft’s software often changes features and protections substantially between beta versions and its general release. If you tested a beta release of a Microsoft Windows OS, you would need to retest it after its general release. For example, as this book was going to press, Microsoft announced that WinFS will not be in the first public release of Longhorn, but will be added during a later upgrade.

The 64-bit versions of Windows require 64-bit CPUs, like Intel’s Itanium or AMD’s Opteron and Athlon processors. Although 64-bit versions of Windows have not been widely deployed, 64-bit malware is already in existence. The Rugrat virus (http://securityresponse.symantec.com/avcenter/venc/data/w64.rugrat.3344.html) was released in May 2004 as a working demonstration of a 64-bit virus. It is a direct-action infector virus, meaning that it infects other 64-bit executables only when executed. It does not stay resident in memory. It avoids infecting Windows system files protected by Windows File Protection (WFP).

Starting with Windows Server 2000, Terminal Server is available as an included installable application, and it no longer requires a separate version of the OS, as it did in Windows NT Server 4.0. Small Business Server editions contain Windows NT Server 4.0, 2000, or 2003, along with a set of common applications, including Exchange Server, Proxy Server (or Internet Security and Acceleration Server), SQL Server, IIS, Routing and Remote Access Server (RRAS), Shared Fax Services, and Microsoft Outlook.

Client or Server?

Do you want to run a honeypot using a client or server OS? The vast majority of honeypots run server software, but there is an exciting learning path for administrators wishing to explore client holes.

You can deploy a research honeypot using a client OS and wait to be attacked, or go on the offensive. Most malware attacks are against client OSs, but require action on the part of the end user. Usually, the end user executes a malicious file, opens a rogue e-mail, or surfs to a hacker web site. At any point in time, there are usually more than a dozen documented but unpatched holes in Internet Explorer and Outlook Express. You can create a client honeypot system whereby you surf to known malicious sites, open rogue e-mail messages, and execute untrusted files. By monitoring the client honeypot system, you can capture the malware attack and track the exploits.

Patched or Unpatched?

Should the OS you place on the honeypot be patched or left in an unpatched state? As stated in previous chapters, it depends on your goals. If the primary goal is to protect a production network, the honeypot should be patched to the level of the surrounding systems. If you are interested in a particular exploit, patch the system with all security updates, except the related patch. If you want to attract the most hacking opportunities, leave the system in an unpatched state. See the “Installing Necessary Patches” section later in this chapter for more information about Microsoft patches.

What Support Tools Are Available?

Another factor that will impact which OS you will install on your honeypot is the availability of software support tools. Most of the better patch–management tools are available only for the newer OSs. Most monitoring, logging, and management tools (covered in Chapter 10) are being built for Windows 2000 and above. Fortunately, there are plenty of tools that work with Windows 9x, but you won’t find those versions being updated and their bugs fixed.

When choosing an OS, make sure the support tools you want to use are available. For example, the Windows Software Update Services (SUS) patching service works with only Windows 2000 and later Microsoft computer systems.

Which Services and Applications to Install?

Production OSs never exist without running applications and updated content. Which applications and network services do you want to install?

A popular choice for honeypots is IIS. Hackers and automated malware love to attack Microsoft’s web server application. Other possibilities include Exchange Server, DNS, DHCP, Microsoft Office, Windows Media Services, WINS, .NET Framework, accessibility software (recently used in an announced exploit), FrontPage Server Extensions (a frequent hacker target on IIS servers), FTP, SQL Server, Certificate Services (and web enrollment), SharePoint, IAS, RRAS, Terminal Services, wireless services (802.11x networking), and so on. Of course, there is all that non-Microsoft software to consider. You need to install enough software to make the honeypot realistic.

If you are going to set up a complex application like IIS, SQL Server, or Exchange Server, do you have the expertise to install, configure, and analyze it? If you don’t, you’ll end up doing more research, finding someone who does have the expertise, taking educational classes, or choosing not to run the application until you understand it better.

And here’s another good question: How do you plan to keep the content updated? Automated malware doesn’t care about updated content, but real hackers will. Unless you plan to pose your honeypot as a forgotten system, neglected by its operators, you will need some method of updating its content. I don’t know of any automated tools or scripts for doing so, so updating the content will probably be a manual process.

SAM or Active Directory?

In Windows NT and later, user security principal accounts (group and service accounts) are stored either in the local SAM database or in Active Directory. When you create a Windows honeypot, you need to decide where to create and store the user accounts.

It is probably easiest, and most secure, to create the user accounts in the local SAM. Most hackers attack the local administrator account, even if Active Directory is installed. Installing Active Directory means either making the honeypot system a domain controller or creating a secondary honeypot as the domain controller. Still, using Active Directory on a honeypot adds realism. And if you install Active Directory, you can use Group Policy Objects to install and manage user accounts and security settings. Without Active Directory, only the Local Security Policy is available (on Windows 2000 and later). As compared to Active Directory’s Group Policy Objects, the Local Security Policy is significantly limited. See the “Automating Security” section later in this chapter for more details.

Caution 

Never install a production Active Directory directory service on a honeypot! If hackers manage to compromise the honeypot, they can do significantly more damage using Active Directory user accounts than they can using local accounts.

Hacker’s Choice?

So, which OS and applications do hackers prefer? How can you make the most attractive honeypot? First, remember that 99.9% of the attacks against most honeypots come from automated malicious programs. This means that most attacks will randomly assault your honeypot whether or not the honeypot contains a particular piece of software. To create an exploitable honeypot, it needs to contain vulnerable weaknesses and be contactable over the Internet. With that said, many honeypot administrators find high levels of exploitation using the following honeypot scenarios:

• Windows NT Server 4.0, Service Pack 2 or earlier

• Any version of Windows with weak or blank administrative passwords

• Any unpatched version of IIS

• IIS servers with Front Page Extensions installed

• Any version of Windows with open, unprotected (without passwords) network shares, although Windows 9x systems are attacked more often because of their lack of NTFS security permissions

• Any version of Windows with port 135 (RPC) open to the Internet

• Any Windows Server version with FTP actively running

• SQL Server machines with blank SA passwords running on ports 1433 and 1434

• Exchange Server machines with open relaying allowed or with anonymous authentication allowed

In order to attract malicious exploits and hackers, create a honeypot with unpatched software or applications, attach it to the Internet, and allow its ports to be probed. Most honeypot systems following these guidelines report malicious scans within hours, or even minutes.

What Hardware Is Required?

What hardware should you use to support a honeypot running one of the Windows OSs? Table 4-1 lists the minimum and recommended CPU, RAM, and hard drive (HD) requirements for the most common OSs. Hard drive size refers to free space available.

Table 4-1: Windows OS Minimum and Recommended Hardware Requirements

OS	Minimum			Recommended
	CPU	RAM	HD	CPU	RAM	HD
Windows for Workgroups 3.11	286	2MB	30MB	386SX	4MB	50MB
Windows 95/Windows 95 OSR2	386DX	4MB	55MB	486	8MB	100MB
Windows 98/Windows 98 SE	486DX-66	16MB	255MB	Pentium	24MB	500MB
Windows Me	Pentium-150	32MB	320MB	Pentium II-300	64MB	2GB
Windows NT Workstation 4.0	Pentium	16MB	110MB	Pentium	64MB	300MB
Windows NT Server 4.0	Pentium	32MB	125MB	Pentium	64MB	500MB
Windows 2000 Professional/Server	Pentium-133	64MB	2GB	Pentium-133	256MB	2GB
Windows XP	Pentium-233	64MB	1.5GB	Pentium-300	128MB	1.5GB
Windows Server 2003 Enterprise	Pentium-133	128MB	1.5GB	Pentium-733	256MB	1.5GB
Longhorn	Pentium-IV	512MB	8GB	Pentium-IV	1GB	10GB

The values shown in Table 4-1 are the minimum and recommended requirements according to Microsoft. I use a more general rule of thumb. For honeypots, I recommend a computer with a relatively new CPU and the RAM and hard drive sizes listed in Table 4-2.

Table 4-2: Recommended Hardware Requirements for a Honeypot

OS	RAM	HD
Windows 9x/Me	64MB	500MB
Windows NT	128MB	2GB
Windows 2000/XP128MB–256MB	2GB
Windows Server 2003 Enterprise	256MB	4GB
Longhorn	1GB	8GB–10GB

If you are planning to run your honeypot as a VM session, you will need enough RAM on the host computer to run the VM software, plus enough RAM and CPU power for each concurrently running virtual session. In my experience, you need at least 128MB to 256MB of RAM set aside for the VM host itself (assuming it is running on Windows 2000 or XP), and any of the latest CPUs are capable of adequately supporting multiple VM sessions. For example, I run three Windows Server 2003 honeypot VM sessions on a computer with 1GB of RAM. I give the host machine and each of the virtual sessions 256MB of RAM (256MB × 4=1GB).