第一部分
转载SecurityFocus上的一篇文章,不错,对windows用户有很大帮助,尤其在个人操作隐私等方面会了解的更多!
It's a security person's worst nightmare. You've just inherited a large, diverse enterprise with relatively few security controls when something happens. We all try to detect malicious activity at the perimeter of the network by monitoring our intrusion detection systems, and watching attackers bang futilely on our firewall. Even those attackers tricky enough to slip through the firewall bounce harmlessly off our highly secured servers, and trip alarms off throughout the network as they attempt to compromise it. Reality is usually somewhat different: most of us simply don't have the tools, or at least we don't have expensive, dedicated tools. But we do have ways to stop the pain.
This article is the first in a two-part series that will offer a case study of forensics in a Windows environment. This installment will offer a brief overview of the detection and analysis of attack an attack incident. The second installment will look at continue to look at network traffic analysis techniques and will resolve a hypothetical attack scenario.
Although 2002 has been a relatively quiet year for network compromises, there have been quite a few new attacks released, and a fairly significant number of incidents as a result. For the purposes of this discussion, I've blended a number of these incidents together to create a hypothetical Web-hosting company, Web4Sale.com, to demonstrate some of the techniques I've used this year in combating intrusions.
Detection of Potential Incidents
One of the most significant indications that you have a problem in your enterprise is unexpected traffic volume in unusual places. Consider our Web-hosting company as an example. The company's revenue is tied to how many Web sites it can host. This usually translates into huge public address space, and large numbers of systems. It's reasonable to expect that this portion of the enterprise will always have high traffic loads on it. But network management and monitoring rarely travels these connections, as even the helpdesk is a little nervous about broadcasting the root password across the Internet nowadays. What you will usually see are dual-homed servers, with a public interface to serve clients, and a private interface allowing management and control of the server from a trusted source inside the enterprise. If you start seeing large volumes of traffic here, you have a major problem: the attackers are already deep inside the network. This is actually one of the more common ways to detect a "live" attack in progress.
Another major indication of trouble, and a way to detect compromises without robust IDS or firewall solutions, is to look for unexpected types of traffic. SANS calls this, "playing the home field advantage," and it's based on the simple idea that we know our networks better than our adversaries do. If we see something abnormal, we ought to be concerned and investigate. This is really the second step when you see large or unusual traffic patterns: determine what kind of traffic it is, and see if it is "normal". If you see a lot of NetBIOS on a management interface that normally communicates via SSH or SecureCRT, you may have a problem.
Of course, in order to determine whether any activity or traffic is anomalous, we must understand our networks well. There are some great tools that are freely available on the Internet to help you characterize and understand your network. In most cases, all you need is a laptop running some flavor of Linux, and you can get the rest for free. While this won't be an integrated enterprise solution, you can build a quick and dirty toolkit that will help you solve problems when they occur. Some of the more useful tools in my toolkit are:
Ethereal - Ethereal will allow you to capture and graphically inspect network traffic, and can be run under Windows or Linux.
EtherApe EtherApe builds a "talkers map" for a given network segment, and is a great tool to help characterize "normal" traffic.
tcpreplay - tcpreplay lets you replay captured traffic and control the speed at which it flows through another program.
I frequently use tcpreplay in combination with EtherApe to watch traffic maps develop and look for anomalies. Again, these tools and others like them are freely available, and don't really take long to learn to use.
One drawback to these tools is that they are time-intensive from an analysis perspective and it takes time to learn to use all of their strengths. However, the advantage is that we can use assets that already exist to help us understand the network's normal behavior. Then, when we see major deviations from "normal" we can infer that we might have a problem. And the technique works even if you aren't a Web-hosting company or an application service provider, since virtually every network has at least one person responsible for making sure it works. Consider that poor helpdesk person or the engineer in the Network Operations Center (NOC) to be one of your IDS sensors, and you'll have a leg up on the opposition.
Identifying the Attack
Every Internet-connected network will come under attack eventually and, unless your enterprise is extremely unusual, one of those attacks will eventually succeed. The key to minimizing the damage is in understanding what happened, how the attacker compromised your system, how major the scope of the compromise was, what recovery options are available to eliminate the attacker, and the vulnerability from the enterprise.
Consider our Web-hosting example again. Thanks in part to good preparation and relationship building with the helpdesk and NOC staff, and partly to good luck, we saw a major traffic spike on the management interfaces of several servers in the Web4Sale.com production environment. Web4Sale.com, like most large providers, manages and maintains their network from a central point in the enterprise using a private network (10.20.0.0/24). This Class C equivalent address block is the only group of addresses we expect to see talking on the management interfaces of the production Web servers. Armed with this knowledge, we began trying to find out what was happening in the enterprise.
The first step in identifying what was going on was to look at the suspicious traffic. Under normal circumstances, we expect to see traffic on the management interface to and from 10.20.0.0/24. We also expect this traffic to be encrypted via SSH, so anything that doesn't match that profile is at least suspicious. Using a Linux laptop and tcpdump, we selected a host to monitor and start sniffing packets. To accomplish this in the switched environment, we plugged into a mirror port on a Cisco 2500 series switch and mirrored the traffic we were interested in:
tcpdump -i eth0 -s 1500 host winbox.private.com
where eth0 was the capture interface and winbox.private.com is the address of the monitored server's management interface.
The data we got back was extremely interesting. Immediately we notice two anomalies. First, there was a tremendous volume of NetBIOS traffic on the private interface:
10/02/02 08:27:18 netbios.public_ip.com 137 -> winbox.private.net 137
10/02/02 08:27:19 netbios.public_ip.com 137 -> winbox.private.net 137
10/02/02 08:27:20 netbios.public_ip.com 137 -> winbox.private.net 137
Second, there is a public IP address that is showing up in the traffic (netbios.public_ip.com).
Our first rule is to use the home field advantage. Our knowledge of the network indicated that NetBIOS traffic has no business being on the management interface. Worse yet, this is a private network that is not supposed to be routable from the Internet. So why is netbios.suspicious.com sending traffic to the private interface of winbox.private.com? At this point, it was pretty clear that some type of unauthorized use was occurring. The next step was to identify what was being done on winbox.private.com and determining whether or not it was compromised from outside the enterprise, or whether someone on the inside was using it inappropriately. It was time for inspection of the host itself.
Host-Based Forensics
The most important thing to understand when you start examining a system forensically is that nothing about the system under examination can be trusted. We treat every host we examine as if it was fully compromised, root-kitted, and aggressively monitored by the attackers in case of examination. One of the first things we need to decide is whether or not the system needs to come down. Unfortunately there is no hard and fast rule here - it's a judgment call. The investigator has to weigh the possibility that the system is being used to cause additional compromise against the risk of losing volatile data in memory. In our case, since an attacker was actively using the system under examination, we made the decision to leave the system up and running while we collected information about our adversary's methods and intent.
Forensics is really the art of obtaining, recording, and tracking information about a possibly criminal activity for the potential use in court at a later date. This means we have to take every precaution to make sure the data we collect is accurate, trusted, and is not modified from the time of collection onward. By recording each step in the collection and processing of forensic data, and tracking its movement, who accessed it, and what was done to it, we help preserve the "Chain of Custody". This is a non-trivial task that is very well discussed in any number of books on computer forensics, and your general counsel can help you if you have detailed legal questions. In general, the best practice is to collect evidence using trusted tools, save data to removable media, and ensure the data can be authenticated.
The first challenge is the tools. In reality, almost everything we would need to examine winbox.private.com is available in the Windows 2000 operating system or the Windows 2000 Resource Kit. However, as we cannot trust a potentially compromised device, we need to build our own trusted version of the tools we need. Simply obtaining a clean copy of the operating system (preferably one that has never been connected to the compromised network) and burning copies of certain files to a CD-ROM will accomplish this goal. Some of the tools you'll need will include:
at.exe
cmd.exe
dir.exe
ipconfig.exe
nbtstat.exe
net.exe
netstat.exe
nslookup.exe
route.exe
tracert.exe
There are also some freely available tools in the Internet you will want to use. One of the most important is md5sum.exe, a port of the Linux command of the same name that can be used to determine whether or not the evidence has been modified since it was collected. The best practice is to run a given tool, capture the output on a floppy, then immediately generate an MD5 sum of the data, with the objective of having the file creation times be nearly identical. The important thing to remember is that until the MD5 sum is generated, we have no guarantee that the data was not manipulated. If the attackers are ever prosecuted, a time-gap between data collection time and the MD5 sum time can be extremely damaging to the prosecution's case.
Other tools of use will include Fport.exe from Foundstone and a variety of tools including the following:
pslist.exe - a tool to list processes from the Windows 2000 command line.
psservice.exe - a tool that associates services with process Ids for Windows 2000.
psfile.exe - a Windows 2000 tool similar to lsof does under Linux.
psloggedon.exe - a tool that associates users with running processes.
listdlls.exe - a tool to list which DLL files are being used by running processes
A simple Internet search will yield these tools and many more of use during forensic examination of Windows 2000 hosts.
In the case of this investigation, the first step was to identify who was logged onto the system, what resources were being shared, and what processes were running. All commands were run from the CD-ROM (E:\) and data was saved to the floppy (A:\):
E:\nbtstat -a winbox.private.com > a:\nbtstat-a_output.txt
E:\md5sum a:\nbtstat-a_output.txt > a:\nbtstat-a_output.md5
This pattern was repeated for each command below, and the output on the floppy was later analyzed to determine the following information. There are many good texts on computer forensics including The Anti-Hacker Toolkit by Keith Jones and Incident Response by Kevin Mandia (among numerous others), as well as excellent articles on SecurityFocus about specific techniques to employ in either a Windows or Unix environment. However, this article is less about tools, and more about techniques. what we need to look for while we execute these tools.
What to Look For?
The real issue in forensic analysis, as with any response-oriented activity, is to determine what happened, who the culprit was, and what the impact of the event has been. The tools discussed above are extremely useful in this analysis, but ultimately it is the skill of the investigator that determines whether or not a case will be resolved. While most experts agree the that field of computer forensics is at least as much art as science, there are a handful of things everyone agrees are important things to look for:
Objective Tool / Technique
Identify unusual processes pslist, psinfo, psfile
Identify unusual listening ports netstat, Fport, psservice
Identify unusual open files psfile, listdlls, Fport
Identify logged in users psloggedon, nbtstat
Identify process owners psloggedon
Examine routing tables netstat, route
Examine temporary files dir, type
Identify suspicious directories/folders dir, Explorer
We are attempting to reconstruct the scene of the crime, so to speak. Remember, one of our key advantages over the adversary is that we have the home field advantage - we know our networks and systems better than those attacking us. Armed with the knowledge of what constitutes "normal", we can make a cursory examination of a compromised server in less than a half-hour. The off-line analysis often takes much longer, particularly when you are examining directory structures looking for hidden directories, or items that shouldn't be there. In addition, we always need to remember to look for clues in the registry that might identify what our attackers were trying to accomplish. Temporary files can be examined with a sector editor for code fragments or clues to other activity. Batch files (*.bat) should be examined to make sure they haven't been modified or created simply to further the attacker's goals. And finally, in most Windows environments there is at least minimal logging going on using the Windows Event Logs and Security Logs.
In the Web4sale case, winbox.private.com was examined using trusted versions of netstat, route, nbtstat, hostname, net, and dir. Additionally, we used Fport, pslist, psloggedon, and psservice to identify the owners of a variety of suspicious processes that were detected. The excerpts below show some of the data collected during this investigation.
E:\hostname
Winbox.private.com
E:\nbtstat -a winbox.private.com
NetBIOS Remote Machine Name Table
Name Type Status
-----------------------------------------------
WINBOX <00> UNIQUE Registered
WINBOX <02> UNIQUE Registered
PROD <00> GROUP Registered
PROD <1E> GROUP Registered
..__MSBROUWS__ <01> GROUP Registered
ADMINISTRATOR <03> UNIQUE Registered
MAC ADDRESS = XX-XX-XX-XX-XX-XX
E:\net session
Computer User name Client Type Opens Idle time
----------------------------------------------------------------
\\TGT1 ADMINISTRATOR 0 00:00:27
\\TGT2 ADMINISTRATOR 0 00:00:15
\\TGT3 ADMINISTRATOR 0 00:00:23
\\TGT4 ADMINISTRATOR 0 00:00:05
E:\Fport.exe
Fport v2.0 - TCP/IP Process to Port Mapper
Copyright 200 by Foundstone, Inc
http://www.foundstone.com
Pid Process Port Proto Path
420 svchost -> 135 TCP C:\WINNT\system32\svchost.exe
8 System -> 445 TCP
888 MSTask -> 1025 TCP C:\WINNT\system32\MSTask.exe
8 System -> 1027 TCP
8 System -> 445 UDP
430 svchost -> 80 TCP C:\Program Files\Apache\httpd.exe
1625 servu -> 3215 TCP C:\Client_Data\Inetpub\_vti-bin\ \servu.exe
While I have not shown all the output of each tool, there are some important clues in this data. First, we have confirmed the hostname of the target (winbox.private.com) and have gathered some information about who is logged in, what processes are running and which services are listening on the device. Given this output, there are several things of concern to us from an investigative perspective. The first thing that leaps out is the output of the net session command, which clearly shows NetBIOS sharing between winbox.target.com and a number of other servers using the private address of each server. We know this is abnormal, as the private network is intended for management only, and resource sharing using MS Windows File and Printer Sharing is specifically unauthorized by policy. We also see that in each case, the illicit connections were made using the authentication credentials of the local Administrator on the target machine - this is a very bad thing. Worse, the output of Fport indicates winbox.private.com is running what appears to be an FTP server, on an ephemeral port (greater than 1024), whose source is in an extremely unusual location (C:\Client_Data\Inetpub\_vti-bin\ \), which appears to be a hidden directory. This is particularly suspicious since winbox.private.com is running Apache as the Web server, and the directory structure for the FTP server seems to be hidden in a directory that is normally associated with Microsoft IIS.
By recursively listing the hidden directory (E:\dir /s /a C:\Client_Data\Inetpub\_vti-bin\" "\ /p) we were able to find the executable version of the FTP server, its configuration file, and a number of interesting batch files, configuration files, and tools. Of particular interest was the batch file titled "VFS_MNT.BAT" (partial listing below).
net use F \\tgt1\c$\WINNT\system32\ \_vti-bin\ /user:Administrator AdminPass
net use G \\tgt2\c$\WINNT\system32\ \_vti-bin\ /user:Administrator AdminPass
net use H \\tgt3\c$\WINNT\system32\ \_vti-bin\ /user:Administrator AdminPass
net use I \\tgt4\c$\WINNT\system32\ \_vti-bin\ /user:Adminstrator AdminPass
There is an alarming trend here. First, the attacker has mounted a hidden directory on each of the targets with local administrator privileges, allowing the attacker to create a virtual file system for the illicit FTP server. Of course, in reality sharing the Administrator password across systems this way is extremely poor practice, but in this case it was the norm. Worse, the attacker now has the ability to serve data hidden across multiple systems via one or potentially more illicit FTP servers hidden in the enterprise.
Putting it All Together
This case study is really a blending of a number of incidents examined in the latter part of 2002, and doesn't really represent any single incident. However, all of the incidents observed shared certain common traits: 1) large enterprises supported by extremely high bandwidth Internet connections; 2) largely Windows NT and Windows 2000 enterprises; 3) persistent compromise of Administrator and Domain Administrator accounts; 4) widespread use of a distributed 2-tier FTP server, where the FTP root directory structure was comprised of a virtual file system of shared drives. Our mythical Web hosting company, Web4Sale.com, suffers from this same set of common criteria, and like most of the real-world incidents, the attackers are serving both warez and porn.
At this stage of the investigation, we've discovered the compromise (although we have yet to identify the compromise method), identified the post-attack "fingerprint" of this particular group, and have begun to understand what is happening in the enterprise. Should we need to initiate corrective action at this time, there are a number of things we can do to end the current compromise, starting with changing the Administrator passwords, and restricting NetBIOS using packet filters on the switches supporting the Web4Sale.com enterprise. However, before we start with the eradication phase of our incident response, we really need to complete the identification phase: we have yet to identify the initial compromise method, or to identify the scope of the compromise! In the next installment of this series, we'll look at network traffic analysis techniques to continue our response, and resolve these issues.
Windows Forensics - A Case Study: Part Two
by Stephen Barish
last updated March 5, 2003
--------------------------------------------------------------------------------
This article is the second in a two-part series that will offer a case study of forensics in a Windows environment. In Part One, we discussed host-based forensics techniques that first responders can use to detect attacks in relatively unprotected environments, and how to begin collecting information to determine the appropriate response. Part One dealt with understanding what an attacker was doing on an individual host. This article deals with determining the scope of the compromise, and understanding what the attacker is trying to accomplish at the network level. Along the way, we'll be discussing some tools and techniques that are useful in this type of detective work.
The Objective
As we left off last time, we had discovered the compromise (although we have yet to identify the compromise method), identified the post-attack "fingerprint" of this particular group, and begun to understand what was happening in the enterprise. Before we start with the eradication phase of our incident response, we really need to complete the identification phase: we have yet to identify the initial compromise method, or to identify the scope of the compromise!
At this point in the investigation, we have reason to believe the attackers are making illicit use of the victim network to serve content to their friends and neighbors. While it is possible any individual content provider might not mind serving some of this material (the kind that isn't unlawful anyway), our victim network isn't getting paid for this service, and the attackers have a free ride. Of more concern, the investigation so far has yielded information that indicates the attackers have compromised both local and domain Administrator accounts in our enterprise.
Our objectives moving forward are simple. We want to determine how widespread the attacker's control over the network is, what the initial compromise method was, and who the attacker is (if possible).
Developing a Toolkit
It would be great if all of us had fully monitored environments and the staff required to correlate and analyze all the security data that can be extracted from such an enterprise. Unfortunately, the reality of the situation is that most of us do not have host and network IDS systems, tiered firewalls, strong authentication and authorization systems, and logging is generally insufficient. The problem gets worse in larger environments where the sheer amount of data and systems we're responsible for makes it extremely difficult to perform even "near-real time" analysis. So when the inevitable incident occurs, we need a "quick and dirty" toolkit and methodology to assess what is happening on the network, so we can make smart decisions on remediation measures.
I typically like to use a laptop loaded with both Windows 2000 (and the Windows 2000 Resource Kit) and Linux to conduct my network assessments, and a variety of tools that operate in both environments.
Tool Windows Unix
Network Sniffer(s) Windump, Ethereal Tcpdump, Ethereal, dsniff
IDS Software Snort Snort
Analysis Software EtherApe, tcpreplay
Port Scanners Fscan, nmapwin Nmap
These are just a few tools that are available, and represent my personal favorites - your mileage may vary. However, by using the capabilities these tools and others like them offer, we can usually develop a good picture of what is happening on the network, and what an attacker is doing.
Getting Started
Before we even consider launching a sniffer, we need to determine what data we're looking for in the network traffic. In a 100Mbps switched network, it's trivial to overwhelm a sniffer, an analysis workstation, or an analyst. I like to start by looking at a victim box, preferably one I know is still being used by the attacker. In a switched environment, which is really the worst case from a traffic analyst's perspective, I like to set up on a mirror port tap into the network connection between the victim box and the switch. Provided the switch supports full duplex mirroring of an individual port, it is highly preferable to monitor from the switch rather than interrupt network connectivity, as it introduces much less of a signature that the attacker might notice. While it is possible to insert a sniffer between the switch and the monitored host using an Ethernet tap, it's a distinct second choice. Given a choice, I almost always prefer to set up on a mirror port.
The advantage to setting up on a mirror port rather than using an Ethernet tap is that you can quickly reconfigure the switch to allow monitoring of another individual host or VLAN (provided the switch will support the desired configuration). Although mirroring a highly utilized VLAN is almost sure to cause packet loss and collision problems on some switches, I've found the technique can help get a "quick and dirty" view of what's going on. It's certainly not the most desirable solution from a long-term IDS perspective, but it will help us monitor and analyze incoming traffic.
Windows Native Tools
For those of who grew up sniffing traffic in a largely Unix environment, there is good news! Most of the tools we are used to now exist in some form or other in the Windows environment. For instance, the standard tcpdump utility used in most Unix distributions has been ported with the name Windump. Windump makes use of a port of libpcap (unsurprisingly called WinPcap to interact with the various network interfaces on a sniffing host virtually identically with tcpdump. Windump reads and writes the binary output of tcpdump, so data can be collected and analyzed in either environment.
After downloading and installing Windump and setting up on the switch's mirror port, we can start capturing and pre-processing traffic. The real power in using Windump is that it allows users to filter traffic prior to recording it in either text, ASCII, or hex formats. By carefully crafting filters, we can minimize the amount of unnecessary traffic collected. For instance, the following command with imbedded filter will find traffic between victim and target, and will record it to a file.
C:\> Windump -i1 host victim and target -w output
In reality, we rarely know what we'll be looking for during the initial data capture, so it is wisest to conduct full content monitoring. In this case, we want to capture the entire packet, including any payload that may be of interest. Since the Maximum Transfer Unit of Ethernet is 1500 bytes, we set our snaplength to 1500 bytes also using the -s switch. Finally, we use -n to prevent Windump from converting host addresses and port numbers. This will prevent us from sending unintended packets to a DNS server that may be owned by the attacker.
C:\> Windump -i1 -s1500 -n -w output
To analyze this data, we could use Windump to read output and pass it through a series of filters, but it is much more intuitive to dump the resulting data into a more graphical analysis tool. My personal favorite is Ethereal. Ethereal provides a graphical interface for analysts to point-and-click their way through the packet, its headers, and down into the data itself. I also like its ability to decode certain protocols and reassemble TCP streams.
Ethereal has its own extremely powerful filter language, and because it automates a significant amount of the analysis, is often easier to use than Windump. Regardless, either tool can be used to collect or conduct extremely sophisticated network analysis - if you have a bit of time on your side.
What to Look For?
Just as when we conduct a host-based forensic analysis, we need to have a plan for what to investigate. While each incident will have some unique aspects, there are certain general techniques that are common to almost all network analysis. These are:
Top Talkers
Top Recipients
Most Common Ports/Protocols
Comparison with Known/Valid Traffic
Coordination / Correlation with Forensic Examination
The first four elements in this list rarely surprise anyone, and in the case study we're investigating, would undoubtedly show the majority of the activity. After all, if policy says NetBIOS should not exist on the management VLAN, its mere presence is a sign of concern (see Part One of this series). However, coordinating and correlating network analysis with the results of the forensics exercise is often overlooked. Recall from Part One that we found a file on the compromised server that, when executed, attempted to make connections to multiple hosts on the network as the Administrator. By conducting full content monitoring of these hosts and using Ethereal for analysis, we can begin to search for additional anomalies.
C:> Windump -i2 host TGT1 -s1500 -w output
After collecting data for a while (typically we collect one-hour snapshots that overlap by approximately one minute), we can begin analyzing the resulting data. After loading output into Ethereal, we construct a filter to look for SMB packets (the protocol underlying Windows File Sharing) and find a host of sessions to and from TGT1, all on the management interface (Interface 2 as reported by Windump -D). As we inspect the traffic, we can see a series of attempts to authenticate to TGT1.
No. Time Source Destination Protocol Info
27 4.7277 winbox.victim.com TGT1.victim.com SMB TREE CONNECT ANDX REQUEST, NTLMSSP AUTH
35 5.2552 winbox.victim.com TGT1.victim.com SMB TREE CONNECT ANDX REQUEST, NTLMSSP AUTH
42 6.3521 winbox.victim.com TGT1.victim.com SMB TREE CONNECT ANDX REQUEST, NTLMSSP AUTH
These appear to be requests for authentication to a Windows file share. The fact that we are seeing rapid connections from winbox.victim.com to TGT1.victim.com is somewhat suspicious also, as it represents some automated process running the connection attempts. By further filtering with Ethereal, and using its native protocol decoding capabilities, we can reconstruct the following sequences:
FILTER: (ip.addr eq 192.168.254.2 and ip.addr eq 192.168.254.205) and (tcp.port eq 1095 and tcp.port eq 445)
Resulting Stream (Excerpt1)
00000389 00 00 01 48 ff 53 4d 42 73 00 00 00 00 18 07 c8 ...H.SMB s.......
00000399 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff fe ........ ........
000003A9 01 08 50 00 0c ff 00 48 01 04 11 0a 00 01 00 00 ..P....H ........
000003B9 00 00 00 a6 00 00 00 00 00 d4 00 00 a0 0d 01 4e ........ .......N
000003C9 54 4c 4d 53 53 50 00 03 00 00 00 18 00 18 00 66 TLMSSP.. .......f
000003D9 00 00 00 18 00 18 00 7e 00 00 00 0c 00 0c 00 40 .......~ .......@
000003E9 00 00 00 0e 00 0e 00 4c 00 00 00 0c 00 0c 00 5a .......L .......Z
000003F9 00 00 00 10 00 10 00 96 00 00 00 15 82 88 e0 4c ........ .......W
00000409 00 41 00 50 00 54 00 4f 00 50 00 73 00 62 00 61 .I.N.B.O .X.A.d.m
00000419 00 72 00 69 00 73 00 68 00 4c 00 41 00 50 00 54 .i.n.i.s .t.r.a.t
00000429 00 4f 00 50 00 a0 22 69 06 b4 2d 12 7f 00 00 00 .o.r.."i ..-....
00000439 00 00 00 00 00 00 00 00 00 00 00 00 00 8b e9 d5 ........ ........
00000449 b8 26 a1 f2 01 06 6b 6c e3 62 0d 7f fa 63 15 7f .&....kl .b..c.
00000459 7d d6 64 30 5e d0 ca 7d 5f 30 5f 13 a4 a7 c3 15 }.d0^..} _0_.....
00000469 d1 fb 87 33 8b 00 57 00 69 00 6e 00 64 00 6f 00 ...3..W. i.n.d.o.
00000479 77 00 73 00 20 00 32 00 30 00 30 00 32 00 20 00 w.s. .2. 0.0.2. .
00000489 32 00 36 00 30 00 30 00 20 00 53 00 65 00 72 00 2.6.0.0. .S.e.r.
00000499 76 00 69 00 63 00 65 00 20 00 50 00 61 00 63 00 v.i.c.e. .P.a.c.
000004A9 6b 00 20 00 31 00 00 00 57 00 69 00 6e 00 64 00 k. .1... W.i.n.d.
000004B9 6f 00 77 00 73 00 20 00 32 00 30 00 30 00 32 00 o.w.s. . 2.0.0.2.
000004C9 20 00 35 00 2e 00 31 00 00 00 00 00 .5...1. ....
When Ethereal decodes the SMB datastream, it inserts a "." between characters because most low-level logging and communications in Windows uses Unicode characters. In Unicode, US characters have "00" in the high order byte. Ethereal decodes all non-ASCII characters as a "." The character stream "W.I.N.B.O.X.A.d.m.i.n.i.s.t.r.a.to.r." indicates the Administrator of winbox is attempting to connect to the target (TGT1).
As expected, the Administrator is attempting to authenticate to TGT1. However, by scanning through the other packets of this type, we uncovered several other usernames including INET_GLOBAL, a shared account for configuring Web servers, and HELPTECH1, the username of a Help Desk employee, and USERCHUCK who was a high-level programmer in the company. While it would be nice to jump to conclusions and simply grill USERCHUCK or HELPTECH1, we really have no proof of any wrongdoing by either user at this point.
Ethereal is particularly useful when conducting analysis of this sort, as you can page rapidly through the hex representation of the data packet (as shown above) and look for anomalies. However, in a real-world response scenario, it can take hours to start breaking out usernames and passwords this way thanks to the density of data on the network. Although in some cases this type of analysis is the only way to actually break back communications between compromised hosts and the attackers, there are some tools that make life even easier on the analyst. Mike Davis has ported Dug Song?s popular dsniff package to Windows (
http://www.datanerds.net/~mike/), which will decode usernames and passwords for a whole host of Internet protocols including FTP, Telnet, HTTP, POP, NNTP, IMAP, SNMP, LDAP, Rlogin, NFS, SOCKS, X11, IRC, AIM, CVS, ICQ, Napster, Citrix ICA, Symantec pcAnywhere, NAI Sniffer, Microsoft SMB, and Oracle SQL.
Looking for Intrusions
By now it should be fairly obvious what a time-consuming process analyzing network traffic can be when using simple tools like Windump. Although Ethereal provides more useful information to the analyst, it really doesn't detect problems; rather, it just provides us with strong analysis tools to investigate the traffic we've collected. When we expand our traffic analysis from the individual host to the network at large, the problems of data saturation expand immensely. To counter this, we need employ some more sophisticated tools.
Snort, a packet capture engine and lightweight IDS written by Martin Roesch is extremely useful for this type of analysis. Snort 1.9 binaries are available for the Win32 platform, including the ability to log to a MySQL or MSSQL database. With the addition of a graphical front-end such as ACID I can develop statistical analyses automatically (top talkers, most common protocols, etc.) without having to investigate each packet manually. Additionally, by deploying custom signatures and alerts, Snort can greatly reduce the analysis burden. For instance, the rules below will detect any NetBIOS connections to drives F, G, H, and I on target systems (as we saw in the batch file in Part One).
alert tcp any -> $HOME_NET 139 (msg:"NETBIOS SMB F$access"; flow:to_server,established; content:"\\F$|00 41 3a 00|"
alert tcp any -> $HOME_NET 139 (msg:"NETBIOS SMB G$access"; flow:to_server,established; content:"\\G$|00 41 3a 00|"
alert tcp any -> $HOME_NET 139 (msg:"NETBIOS SMB H$access"; flow:to_server,established; content:"\\H$|00 41 3a 00|"
alert tcp any -> $HOME_NET 139 (msg:"NETBIOS SMB I$access"; flow:to_server,established; content:"\\I$|00 41 3a 00|";)
These rules will trigger alerts if any host attempts to mount network drives on the network address assigned to the variable HOME_NET. By changing the value of HOME_NET as we change the traffic flowing the mirror port, we can slowly expand the dimensions of our search. These signatures will ultimately allow us to monitor the entire Management VLAN for attempted NetBIOS sessions. By modifying the rules or adding additional rules to look for more network resources, drives, etc., we can begin to build a picture of how large the compromise is. Since we know that by policy no NetBIOS can be present on this VLAN (or any other unencrypted traffic), any alerts represent probable attacker activity.
When I start monitoring network traffic this way, I almost always run two simultaneous captures. By running Snort in real-time with a tailored signature set, I can monitor for ongoing activity and attacks (assuming I've been able to characterize the attacker's behavior and develop custom signatures). But I need to continue full-content monitoring in parallel in order to assure I can conduct more detailed off-line analysis if required. This can be extremely important as in most investigations we discover more about the attacker's methods and behavior the longer the investigation goes on. By maintaining the original data, we can re-run it through Snort with an updated rule set whenever we desire by simply running
C:\SNORT> snort -r Windumpfile -c C:\SNORT\snort.conf
Remember from Part One of this series that NetBIOS is not permitted on the Management VLAN. Therefore, any NetBIOS access represents suspicious traffic at a minimum, and may range from misuse to abuse or compromise. We can use Ethereal to search Windumpfile for the IP addresses that Snort identifies and look manually for usernames that may be compromised.
Wrapping It Up
The network side of the analysis is often much more time consuming than the "live approach" of a compromised host. As analysts, we have to learn to discriminate between "normal" traffic and the traffic we believe to be abnormal and/or possibly malicious. In the first part of this series, we said that we have the home-field advantage over our attackers. After reading the numerous emails I've received from the field, I'd say that it may be more accurate to say that "we ought to have the home-field advantage." We ought to know the policies our networks operate under, and those policies ought to be complied with. While this is not always the case in reality, it is certainly something we ought to strive for.
Historically the Windows environment has been difficult to monitor, analyze, and secure, simply because of the lack of security tools that run on the platform. Thanks to Sysinternals who distribute the ps utilities demonstrated in Part One, companies like Foundstone and @Stake, and the open source world of WinPcap, Windump, Ethereal, Snort, etc. we are now gaining an increasing ability to conduct the type of investigations from Windows that used to only be possible in the Unix environment.
The astute reader will note this series hinted at a possible source of the original compromise, but did not conclusively prove it. The reality of the situation is that this sometimes happens, particularly in complex environments where there is poor access control and monitoring. There are some data sources that were not investigated in this series, such as the Windows Event and Security Logs, Web server logs, etc., and in a real incident these should absolutely be studied. Often there is sufficient data in the enterprise to rule out certain kinds of attacks even if a robust network security monitoring environment isn't in place.
In our case study there were several "cardinal rules" of security that were violated. The batch file in Part One would not have operated successfully as written if the Administrator account was not identical on each host. In several of the cases that inspired this article, the Global Domain Administrator account was actually the same as each Local Administrator account, further reducing the security of the enterprise as a whole. The second major problem was the bad monitoring environment. Clearly some architectural changes and a redesign of the network are called for. Using some of the tools discussed in this series, and with minimal cost, it is possible to build a rudimentary IDS capability, although monitoring it will probably take significant manpower.
At the risk of starting a religious discussion, Windows is neither more or less inherently secure than any other platform - with a few arguable exceptions. It is one of the most attacked operating systems on the face of the planet, thanks to its wide proliferation. As a result, its flaws are exploited often and well. If you are running a large Windows environment, my advice to you is to prepare yourself for the inevitable compromise by doing the following:
Build a Toolkit
Fscan and Fport from Foundstone
PS Utilities from Systinternals
Trusted versions of Windows utilities for each version of Windows in your environment
Dual-boot Windows / Linux Laptop loaded with Winpcap, Windump, Ethereal, and Snort+MySQL and Acid along with Linux variants for the Linux partition
Use Windump/tcpdump and tcpreplay + EtherApe to characterize the network
Implement an IDS - Even a Rudimentary One,/span>
Finally, take the time to prepare yourself. This goes beyond characterizing the environment, although that's a good first step. There are some great books out there to get you started in network analysis, notably Network Intrusion Detection and Intrusion Signatures and Analysis by Stephen Northcutt and company. The Anti-Hacker Toolkit and Incident Response are two other great source texts (as mentioned in Part One). Most importantly, take the time to dig into the tools and practice using them. Learn their features and filter languages in particular, as these will be infinitely useful to you the more you learn.
[
Last edited by DragonGo on 2005-5-16 at 09:20 ]
