Deception Toolkit Examples
DTK Detection logs
The examples below are logs from a variety of access attempts - some
real and some merely tests. Note that these use the compressed logfile format
(you have the option of non-compressed log files at installation). The
compressed format provides full informationon the first line and subsequent
lines simply replace identical information with '-' to save space. For the
time field, a '+5' (for example) indicates that there was a 5 second gap
between the previous log entry and this one.
Web service attempt
Here is someone trying to access a web server on this site when there is
none. Note that the fake web server on this site redirects them to a
legitimate Web server and that unless this activity is repeated, it does not
necessarily indicate any mal intent.
204.30.67.199 80 80 1998/03/31 13:49:17 3244 3244:1 listen.pl S0
- - - +0 - - 3244:1 - S0 GET / HTTP/1.0
Possibly automated Warez ftp attempt
Here is someone (from an
actual record) trying to login thinking that this is a Warez site. Warez is
illegally copies software, typically placed on Internet servers without the
knowledge or consent of the owner. People who use the illegal software come
to Warez sites to retrieve the stolen goods.
128.146.27.27 21 21 1998/04/01 06:46:02 5426 5426:1 listen.pl S0
128.146.27.27 21 21 1998/04/01 07:06:14 5458 5458:1 listen.pl S0
- - - +0 - - 5458:1 - S0 user warez^M
- - - +1 - - 5458:1 - S0 pass warez^M
In this case, it appears that the tool in use does a scan for FTP servers
(at 1998/04/01 06:46:02) and that the user then returns to sites with ftp
ports opened to see if Warez software is available. This address corresponds
to an IP range that appears to be associated with Ohio State University.
Manual ftp attempt
Here is someone trying the same ftp login attempt manually rather than
with an automated Warez lookup process.
127.0.0.1 21 21 1998/04/01 07:06:14 5458 5458:1 listen.pl S0
- - - +0 - - 5458:1 - S0 user warez^M
- - - +3 - - 5458:1 - S0 pass warez^M
The difference is that it took 3 seconds between the user ID and password
entries. People are often slower than automated systems, but this is not
always a reliable indicator.
Telnet attempt retrieving a password file
127.0.0.1 23 23 1998/04/02 05:34:23 8041 8041:1 listen.pl S0
- - - +3 - - 8041:1 - S1 root
- - - +1 - - 8041:1 - S2 toor
- - - +2 - - 8041:1 - S3 ls
- - - +2 - - 8041:1 - S3 df
- - - +4 - - 8041:1 - S3 cat /etc/passwd
- - - +0 - - 8041:1 - S4 NOTICE //dtk/notify.pl 23 4 Email fc at all.net Just sent a password file to an attacker - telnet login
Note that in this case an email was generated to fc at all.net indicating that
this password file was sent out. Similarly, a beeper can be beeped or other
such notices given. Here's what the notice looks like:
From root@all.net Thu Apr 2 05:34:37 1998
Return-Path: root
Received: (from root@localhost) by all.net ...
Date: Thu, 2 Apr 1998 05:34:36 -0800
From: root .
Reply-to: root .
Message-Id: <199804021334.FAA08048@all.net>
To: fc at all.net
Subject: Urgent-Breakin-Attempt
23 4 Email fc at all.net Just sent a password file to an attacker - telnet login
The following scans came from running SEQ-scan against DTK with DTK
implementing "listen" deception on ports 11, 17, 25, and 79 and deception
through TCP-wrappers on other detected ports. These scans were done from
and to localhost on a test machine. Note also that these results have been
reordered to show the association between specific elements of a port scan
decetion. This can be done by a simple sort by field 7.
Normal port scans
Normal port scans look like this:
127.0.0.1 25080 25 1998/03/18 18:59:18 27216 24816:4 listen.pl S0 Init
- - - +1 - - 24816:4 - S0 NoInput
127.0.0.1 25060 11 1998/03/18 18:59:18 27214 24820:2 listen.pl S0 Init
- - - +1 - - 24820:2 - S0 ChildSignal PIPE
127.0.0.1 25066 17 1998/03/18 18:59:18 27215 24819:2 listen.pl S0 Init
- - - +1 - - 24819:2 - S0 WeClose
127.0.0.1 21 21 1998/03/18 18:59:21 27250 27250:1 listen.pl S0
127.0.0.1 23 23 1998/03/18 18:59:21 27249 27249:1 listen.pl S0
127.0.0.1 25675 79 1998/03/18 18:59:18 27222 24817:1 listen.pl S0 Init
- - - +1 - - 24817:1 - S0 WeClose
127.0.0.1 80 80 1998/03/18 18:59:21 27273 27273:1 listen.pl S0
127.0.0.1 110 110 1998/03/18 18:59:21 27271 27271:1 listen.pl S0
SYN port scans
SYN packet only scans look like this:
0.0.0.0 11 11 1998/03/18 19:02:19 24820 24820:0 listen.pl S0 PortScan
- - - +11 - - 24820:0 - S0 PortScan
0.0.0.0 17 17 1998/03/18 19:02:19 24819 24819:0 listen.pl S0 PortScan
- - - +11 - - 24819:0 - S0 PortScan
unknown 21 21 1998/03/18 19:02:20 27305 27305:1 listen.pl S0
unknown 23 23 1998/03/18 19:02:20 27306 27306:1 listen.pl S0
0.0.0.0 79 79 1998/03/18 19:02:21 24817 24817:0 listen.pl S0 PortScan
- - - +10 - - 24817:0 - S0 PortScan
unknown 80 80 1998/03/18 19:02:22 27344 27344:1 listen.pl S0
unknown 110 110 1998/03/18 19:02:22 27345 27345:1 listen.pl S0
unknown 21 21 1998/03/18 19:02:30 27363 27363:1 listen.pl S0
- - - +10 - - 24816:0 - S0 PortScan
unknown 23 23 1998/03/18 19:02:30 27364 27364:1 listen.pl S0
unknown 80 80 1998/03/18 19:02:32 27402 27402:1 listen.pl S0
unknown 110 110 1998/03/18 19:02:32 27403 27403:1 listen.pl S0
Note that wrappers indicates "Unknown" while listen indicates "0.0.0.0" for
the same result.
Small packet scans
Snall packet only scans look like this:
127.0.0.1 30356 11 1998/03/18 19:04:27 27417 24820:3 listen.pl S0 Init
- - - +0 - - 24820:3 - S0 ChildSignal PIPE
127.0.0.1 30727 25 1998/03/18 19:04:27 27419 24816:5 listen.pl S0 Init
- - - +0 - - 24816:5 - S0 NoInput
127.0.0.1 30494 17 1998/03/18 19:04:27 27418 24819:3 listen.pl S0 Init
- - - +0 - - 24819:3 - S0 WeClose
127.0.0.1 31802 79 1998/03/18 19:04:27 27435 24817:2 listen.pl S0 Init
- - - +0 - - 24817:2 - S0 WeClose
127.0.0.1 23 23 1998/03/18 19:04:28 27469 27469:1 listen.pl S0
127.0.0.1 21 21 1998/03/18 19:04:28 27470 27470:1 listen.pl S0
127.0.0.1 80 80 1998/03/18 19:04:28 27475 27475:1 listen.pl S0
127.0.0.1 110 110 1998/03/18 19:04:28 27474 27474:1 listen.pl S0
Note that undersized packet scans result in an almost instantaneous
"WeClose" , "ChildSignal PIPE" or "NoInput" when it encounters "listen"
ports, while TCP wrappers ports give no additional information.
Forged IP address SYN scan
Not much of a forgery!
127.0.0.1 2084 11 1998/03/18 19:19:49 27521 24820:4 listen.pl S0 Init
- - - +0 - - 24820:4 - S0 ChildSignal PIPE
127.0.0.1 2252 25 1998/03/18 19:19:49 27534 24816:6 listen.pl S0 Init
- - - +0 - - 24816:6 - S0 NoInput
127.0.0.1 2114 17 1998/03/18 19:19:49 27533 24819:4 listen.pl S0 Init
- - - +0 - - 24819:4 - S0 WeClose
127.0.0.1 3413 79 1998/03/18 19:19:49 27535 24817:3 listen.pl S0 Init
- - - +0 - - 24817:3 - S0 WeClose
127.0.0.1 110 110 1998/03/18 19:19:51 27577 27577:1 listen.pl S0
127.0.0.1 80 80 1998/03/18 19:19:51 27579 27579:1 listen.pl S0
127.0.0.1 23 23 1998/03/18 19:19:51 27580 27580:1 listen.pl S0
127.0.0.1 21 21 1998/03/18 19:19:51 27581 27581:1 listen.pl S0
Note again the detection information provided by "listen" ports as opposed to
wrappers ports.
Lamer TCP scans
As lame a scan as they get.
127.0.0.1 15379 11 1998/03/18 19:25:17 27625 24820:5 listen.pl S0 Init
- - - +0 - - 24819:5 - S0 WeClose
127.0.0.1 15395 25 1998/03/18 19:25:17 27627 24816:7 listen.pl S0 Init
- - - +0 - - 24816:7 - S0 NoInput
127.0.0.1 15386 17 1998/03/18 19:25:17 27626 24819:5 listen.pl S0 Init
- - - +0 - - 24820:5 - S0 ChildSignal PIPE
127.0.0.1 16419 79 1998/03/18 19:25:17 27628 24817:4 listen.pl S0 Init
- - - +0 - - 24817:4 - S0 WeClose
127.0.0.1 110 110 1998/03/18 19:25:18 27680 27680:1 listen.pl S0
127.0.0.1 80 80 1998/03/18 19:25:18 27682 27682:1 listen.pl S0
127.0.0.1 23 23 1998/03/18 19:25:18 27683 27683:1 listen.pl S0
127.0.0.1 21 21 1998/03/18 19:25:18 27684 27684:1 listen.pl S0
Note again the detection information provided by "listen" ports as opposed to
wrappers ports.
FTP Bounce Scans
FTP bounce scan detections look like this:
127.0.0.1 21 21 1998/03/18 18:53:46 27166 27166:1 listen.pl S0
- - - +8 - - 27166:1 - S0 USER anonymous
- - - +0 - - 27166:1 - S1 PASS -wwwuser@
- - - +2 - - 27166:1 - S2 PORT 1,2,3,4,0,1
- - - +0 - - 27166:1 - S2 LIST
- - - +0 - - 27166:1 - S2 PORT 1,2,3,4,0,2
...
- - - +0 - - 27166:1 - S2 PORT 1,2,3,4,0,1023
- - - +0 - - 27166:1 - S2 LIST
- - - +0 - - 27166:1 - S2 PORT 1,2,3,4,0,1024
- - - +0 - - 27166:1 - S2 LIST
...
The PORT commands indicate the attempt to have this machine 127.0.0.1 scan a
remote machine (1.2.3.4). The results to the person doing the scan indicates
that all ports are open on all machines in any network. An enhanced
deception on the FTP port can produce any desired subset and limit results
to particular machine classes. For example, the following additions to state
2 of 21.respond are designed to make it appear as if only the machines listed
have only the services described:
# State Pattern NexStat Exit lf/file output/filename
2 /^[Pp][Oo][Rr][Tt]\s1,2,3,7,[0-9]+,25/ 2 1 1 220 - OK
2 /^[Pp][Oo][Rr][Tt]\s1,2,3,8,[0-9]+,25/ 2 1 1 220 - OK
2 /^[Pp][Oo][Rr][Tt]\s1,2,3,1[3-5],[0-9]+,53/ 2 1 1 220 - OK
...
2 port 2 1 1 520 - Unreachable
The last line should replace the previous state 2 "port" response. A good
deception might follow this up with deception services on those IP addresses
and ports, designed to reveal known flaws of different sorts that help
determine the attacker's sophistocation level and persistence and help to
track the attacker's behavior, capabilities, and source.
Note also that the source of the FTP bounce scan is apparent in the log.
FIN scans
FIN scans are handled at a low level by the IP stack and do not result in
any activity in the DTK modules, however, FIN scans do indicate that
deception ports are active. Followup entry attempts attempting to exploit
DTK-handles services will cuase detection of those attacks.