Lincoln Laboratory Scenario (DD0S) 2.0.2

The content and labeling of datasets relies significantly on reports and feedback from consumers of this data. Please send feedback on this dataset to Joshua W. Haines so that your ideas can be incorporated into future datasets.

Overview

This is the second attack scenario example data set to be created for DARPA as a part of this effort. It includes a distributed denial of service attack run by an attacker who is a bit more sophisticiated than the vers. 1.0. Future versions of this and other example scenarios will be even stealthier.

This attack scenario is carried out over multiple network and audit sessions. These sessions have been grouped into 5 attack phases over the course of which the adversary probes, breaks-in, installes trojan mstream DDoS software, and launches a DDoS attack against an off-site server.

ADVERSARY: Novice -- scripted attack, fairly blatant

ADVERSARY_GOAL: Install components for, and carry out, a DDOS attack

DEFENDER: Naive -- sunrpc allowed through firewall, HINFO DNS records contain some valid host information.

DESCRIPTION:
The premise of the attack is that a relatively novice adversary seeks to show his/her prowess by using a scripted attack to break into a variety of hosts around the Internet, install the components necessary to run a Distributed Denial of Service, and then launch a DDOS at a US government site. As a part of the attack the adversary uses the Solaris sadmind exploit, a well-known Remote-To-Root attack to successfully gain root access to three Solaris hosts at Eyrie Air Force Base. These attacks succeed due to the relatively poor security model applied at the AFB, many services, including the dangerous "sunrpc" service, are proxied through the base's firewall from outside to inside. The attacker is using the Mstream DDOS tool, one of the less sophisticated DDOS tools. It does not make use of encryption and does not offer as wide a range of attack options as other tools, such as TribeFloodNetwork or Trinoo. An Mstream "server", the software that actually generates and sends the DDOS attack packets, is installed on each of the three victim hosts, while an Mstream "master", the software that provides a user-interface and controls the "servers" is installed on one of the victims.

DIFFERENCES FROM VERS. 1.0:
The main difference between 2.0.2 and 1.0 is that in 2.0.2 the attacker probes for host, platform, operating system by doing DNS HINFO queries, rather than sweeping IP's and rpc ports, and that they break-into one host at Eyrie first, then fan out from there, rather than attacking each host individually.

The five phases of the attack scenario are:

  1. Probe of mill.eyrie.af.mil, Eyrie's public DNS server, via the HINFO query
  2. Breakin-to mill.eyrie.af.mil via the sadmind exploit
  3. FTP upload of mstream DDoS software and attack script, to break-into more Eyrie hosts.
  4. Initiate attack on other Eyrie hosts: Telnet to mill.eyrie.af.mil, setup DDoS master and initiate probing and attack of other Eyrie hosts. Probes are via the HINFO record query and attacks are via the sadmind exploit. Two break-ins are attempted: robin.eyrie.af.mil (a linux host listed as Solaris in the HINFO, breakin fails!) and pascal.eyrie.af.mil (breakin succeeds since the host is Solaris!)
  5. Launching the DDoS: Telnet to mill, telnet to localhost port 6723, connect to the master, and launch attack at www.af.mil.

LLS DDoS Scenario Service Plot

The service plot, shown above, illustrates the attack as seen in the inside tcpdump sensor data (the sniffer on the "inside" network). Only attack sessions are plotted here and each phase is denoted in red. The X-axis is time-of-day in Eastern Standard Time and the Y-axis is the tcp or udp service. The hash-marks indicate the presence of a network session at that time and of that service.

Downloading Offline Sensor Data

The data files can be downloaded by clicking on the links below .

Inside Tcpdump file [ gzipped ]
DMZ Tcpdump file [ gzipped ]
Solaris (2.7) BSM Audit Data from mill [ gzipped ]
Solaris (2.5) BSM Audit Data from pascal [ gzipped ]

Downloading Labeling Data

Mid-Level Labeling, based on Solaris host BSM sensors, for entire the scenario. Each file is a list of XML alerts. Each XML alert represents a BSM "exec" record that is part of the attack.

Mid-Level Labeling, based on Network Tcpdump sensors, by phase of the scenario. Each file is a list of XML alerts. Each XML alert represents a network session that is part of the attack.

  • Download a tar'd gzip'd file of this entire dataset here

Download Labeling Data by Scenario Phase

PHASE 1: The adversary performs an HINFO query (a valid dns query) of mill.eyrie.af.mil, the Base's public dns server. The server has been configured with HINFO records for some of its hosts, these records contain the platform and operating system of each host. This allows the adversary to know that the sadmind attack will probably work and which stack pointer to use. In the network data, the evidence is two dns queries, one to lookup the IP and one to get the HINFO information.

PHASE2:
In phase 2 the attacker sucessfully breaks into the Eyrie dns server, mill.eyrie.af.mil, using the sadmind exploit. The exploit is invoked twice, once to append a user to the password file and once to append the user to the shadow-password file. The stackpointer chosen works on the first try, since the attacker knew the right one to use from the HINFO output.

PHASE3:
Next the attacker ftp's to mill and places: the attack script which will can the rest of Eyrie (via dns/hinfo) and breakinto Solaris hosts, the mstream server software, and the mstream master software.

PHASE4:
In phase 4 the attacker telnets to mill, starts the mstream master software on mill, and launches the script that will probe other hosts on the 112 network at Eyrie and breakinto those that are correctly denoted as Solaris according to the HINFO records. Actions carried out by this script are aslo part of phase 4. Evidence here includes: a telnet to mill, dns queries local on mill, sadmind attacks vs. robin(linux) and pascal(Solaris), ftp to pascal to place mstream server software, and a telnet to pascal to start the mstream server.

PHASE5:
In the final phase, the attacker manually launches the DDOS. This is performed via a telnet login to the victim on which the master is running, and then, from the victim, a "telnet" to port 6723 of the localhost. In the case of scenario 2.0.2 however, the attacker notices that the server on pascal is not registered with the master and he/she telnets to pascal to re-start that server. port 6723/TCP is the port on which the master listens for connections to its user-interface. After entering a password for the user-interface, the attacker is given a prompt at which he/she enters two commands. The command "servers" causes the UI to list the mstream servers which have registered with it and are ready to attack. the command "mstream 131.84.1.31 5" causes a DDOS attack, of 5 second duration, against the given IP address to be launched by all three servers simultaneously. The mstream DDOS consists of many, many connection requests to a variety of ports on the victim. All packets have a spoofed, random source IP address. The attacker then logs out. The tiny duration was chosen so that it would be possible to easily distribute tcpdump and audit logs of these events -- to avoid them being to large. In real life, one might expect a DDOS of longer duration, several hours or more.

In the case of this scenario, however, it should be noted that the DDoS does not exactly succeed. The Mstream DDoS software attempts to flood the victim with ack packets that go to many random tcp ports on the victim host. The AirForce base firewall, the Sidewinder firewall, is not configured to pass traffic on all these ports, thus the only mstream packets that make it though the firewall are those on well-known ports. All other mstream packets result in a tcp reset being sent to the spoof source address. Thus in the DMZ dump file, one sees many resets apparently coming from "www.af.mil" going to the many spoofed source addresses. These are actually created by the firewall as a result of the reciept of the tcp packet for which the firewall is configured not to proxy!

Notes

These data files were collected over a span of approximately 1 hour, 45 minutes on April 16 2000, from 14:45 to 16:28.

The background traffic is of virtually the same content and frequency as was used in the 1999 datasets, therefore, the 1999 data sets may be used to train for this data.

Changes in the background traffic from 1999 to the current year include moving 4 hosts from the 114.0 subnet to the 113.0 subnet and adding the host mill (172.16.115.20) to be the Eyrie AFB Domain Name Service (DNS) server as well as a recipient of telnet traffic.

Background traffic generation was started approximately twenty minutes prior to data collection to allow spurious network startup traffic to subside.

The Windows NT server hume.eyrie.af.mil had a mis-configuration in the mail server, so there are numerous DNS queries from hume that can be ignored. Hume played no role in the attack scenario except in that it was probed in phases one and two.

Additional information is provided on the documentation page.

 

top of page