Scan of the Month Challenge - Scan 27

Massimo Buso - massimobuso@yahoo.it

April 2003

Last modified: Milan, 26 April 2003

Abstract:

In early March 2003, the Azusa Pacific University Honeynet Project deployed an unpatched Windows 2000 honeypot having a null (blank) administrative password. The challenge is based on logs from five days of honeypot operation, collected using Snort and cleaned from irrelevant traffic. The mission is to analyze the log file in order to answer the questions below.


Contents

What is IRC?

From www.irchelp.org:

IRC (Internet Relay Chat) provides a way of communicating in real time with people from all over the world. It consists of various separate networks (or "nets") of IRC servers, machines that allow users to connect to IRC.
[ ... ]
Generally, the user (such as you) runs a program (called a "client") to connect to a server on one of the IRC nets.

From RFC2810 (please consider RFC1459 as the original and basic RFC for IRC, while RFC2810/RFC2811/RFC2812/RFC2813 are actually updates; so RFC1459 is the reference for this document when IRC is involved):

The IRC Protocol is based on the client-server model, and is well suited to running on many machines in a distributed fashion. A typical setup involves a single process (the server) forming a central point for clients (or other servers) to connect to, performing the required message delivery/multiplexing and other functions.

[...]

An IRC network is defined by a group of servers connected to each other. A single server forms the simplest IRC network. The only network configuration allowed for IRC servers is that of a spanning tree where each server acts as a central node for the rest of the network it sees. A sample small IRC network follows:

                                 1--\
                                     A        D---4
                                 2--/ \      /
                                       B----C
                                      /      \
                                     3        E

             Servers: A, B, C, D, E         Clients: 1, 2, 3, 4

The IRC protocol provides no mean for two clients to directly communicate. All communication between clients is relayed by the server(s).

What message is sent by an IRC client when it asks to join an IRC network?

From www.irchelp.org:

The recommended order for a client to register follows (item 1. is not mandatory):

  1. Pass message (connection password)
    PASS <password>
  2. Nick message
    NICK <nickname> [ <hopcount> ]
  3. User message
    USER <username> <hostname> <servername> <realname>

After registration, the JOIN message is used by a client to start listening a specific channel:

What is a botnet?

A botnet is a federation of IRC bot, logically group together thanks to IRC distributed architecture. An IRC bot is a program which connects to an IRC server, joins a specific channel and awaits for commands.

What are botnets commonly used for?

Illegitimate use of bots are IRC channel takeovers (IRC wars), remote access/backdoors, DDOS (Distributed Denial Of Service). Of course, as usual, the botnet concept is not malicious in principle, you can use for example for file sharing, but commonly this name addresses some sort of illegal use.

What TCP ports does IRC generally use?

IANA registered ports for IRC are:

ircu 6665-6669/tcp IRCU
ircu 6665-6669/udp IRCU

In the real Internet world, the most common used port is 6667/tcp and udp is not used because of reliability. Anyway IRC servers tipically listen on several other ports by default including 6660-6669/tcp and 7000/tcp.

What is a binary log file and how is one created?

In this area the term "binary log file" means raw packet logging into a file. Tcpdump and ethereal can save the packets they capture into a binary log file by using "-w <filename>". Snort can produce binary log file in a tcpdump binary format by using a line in the snort configuration file like

output log_tcpdump: <filename>
The tcpdump format (it would be better to call it libpcap format) is not the only one; for example others are snoop/novell LANalyzer/MS network monitor and many more.

What IRC servers did the honeypot, which has the IP address 172.16.134.191, communicate with?

Looking for TCP connections originated from the honeypot towards outside, we use tcpdump with a filtering expression to capture SYN/ACK packets incoming from outside servers (second phase of TCP/IP three-way handshaking):

tcpdump -n -nn -r sotm27 'tcp and dst host 172.16.134.191 and tcp[13]==18'
By using command above, we build the pipeline:
tcpdump -n -nn -r sotm27 'tcp and dst host 172.16.134.191 and tcp[13]==18'|cut -d ' ' -f 2|sort|uniq
and the output is (each line is in the form <A.B.C.D IP address>.<TCP PORT>):
	128.242.214.10.80
	194.192.187.194.80
	194.68.68.12.80
	194.68.68.39.80
	198.49.161.200.80
	205.188.137.80.80
	206.151.167.254.80
	207.172.16.150.80
	207.172.16.156.80
	207.46.196.108.80
	207.46.196.120.80
	207.68.171.238.80
	207.68.171.245.80
	207.68.176.250.80
	207.68.183.190.80
	207.68.184.62.80
	209.196.44.172.6667
	213.66.244.241.80
	216.154.242.126.80
	216.239.33.101.80
	216.239.51.100.80
	216.239.57.100.80
	217.140.0.47.80
	217.151.192.226.80
	217.151.192.231.80
	217.199.175.10.6667
	63.241.174.144.6667
	64.0.96.9.80
	65.57.83.13.80

So IRC servers are:

During the observation period, how many distinct hosts accessed the botnet associated with the server having IP address 209.196.44.172?

First let's examine the traffic generated from/to the IRC server IP 209.196.44.172. We use the textual version of ethereal in this way:

tethereal -x -n -l -r sotm27 'ip.addr==209.196.44.172 and tcp.port==6667 and irc'
After playing a little bit with the text/hex dump view of our traffic, we decide to write down a little piece of code to print the TCP payload of the interesting packets. The fact of the matter is that ethereal's IRC protocol support is not as strong as we need. No fear: we need only to print the raw TCP payload.
/* Compiled under RedHat 7.3 with:
	gcc -o ircsniff -I/usr/include/pcap -Wall -lpcap ircsniff.c */

#include <stdio.h>
#include <string.h>
#include <pcap.h>
int main(int argc,char **argv)
{
	u_char emptymsg[]="\x20\x0d\x0a\x00\x00\x00";
	pcap_t *pcap_pkt;
	char ebuf[PCAP_ERRBUF_SIZE];
	struct pcap_pkthdr pcap_h;
	unsigned char *pkt;
	int i;

	pcap_pkt = pcap_open_offline(argc!=2?"-":argv[1],ebuf);
	while ( (pkt=(u_char *)pcap_next(pcap_pkt,&pcap_h)) != NULL )
		if ( !(pcap_h.caplen==60 && !memcmp(pkt+54,emptymsg,6)) ) /* not empty msg */
			for (i=54;i<pcap_h.caplen;i++) printf("%c",*(pkt+i)); 
	pcap_close(pcap_pkt);
	return 0;
}

This piece of code needs libpcap library to be compiled. Minimal approach is used: no error management, no clean parameters management, etc., just it should work for our current job. If it's called exactly with one argument then this must be the filename of tcpdump/pcap binary file from which packets are read, otherwise the standard input is used. Each packet is considered only from each 55th byte, so as to print the TCP payload only.

Using our 'ircsniff' program:

tethereal -l -w- -r sotm27 'ip.addr==209.196.44.172 and tcp.port==6667 and irc'|./ircsniff > irc.209.196.44.172

the file "irc.209.196.44.172" we get contains (partial):

NOTICE AUTH :*** Looking up your hostname...
NOTICE AUTH :*** Checking Ident
NOTICE AUTH :*** No Ident response
NOTICE AUTH :*** Found your hostname
NICK rgdiuggac
USER rgdiuggac localhost localhost :rgdiuggac
:irc5.aol.com 001 rgdiuggac :Welcome to the Internet Relay Network rgdiuggac
:irc5.aol.com 002 rgdiuggac :Your host is irc5.aol.com[irc5.aol.com/6667], running version 2.8/hybrid-6.3.1
NOTICE rgdiuggac :*** Your host is irc5.aol.com[irc5.aol.com/6667], running version 2.8/hybrid-6.3.1
:irc5.aol.com 003 rgdiuggac :This server was created Sun Jan 19 2003 at 19:04:03 PST
:irc5.aol.com 004 rgdiuggac irc5.aol.com 2.8/hybrid-6.3.1 oOiwszcrkfydnxb biklmnopstve
:irc5.aol.com 005 rgdiuggac WALLCHOPS PREFIX=(ov)@+ CHANTYPES=#& MAXCHANNELS=20 MAXBANS=25 NICKLEN=9 TOPICLEN=120 KICKLEN=90 NETWORK=XNet CHANMODES=be,k,l,imnpst EXCEPTS KNOCK MODES=4 :are supported by this server
:irc5.aol.com 251 rgdiuggac :There are 0 users and 4752 invisible on 4 servers
:irc5.aol.com 252 rgdiuggac 1 :IRC Operators online
:irc5.aol.com 254 rgdiuggac 4 :channels formed
:irc5.aol.com 255 rgdiuggac :I have 346 clients and 1 servers
:irc5.aol.com 265 rgdiuggac :Current local  users: 346  Max: 348
:irc5.aol.com 266 rgdiuggac :Current global users: 4752  Max: 4765
:irc5.aol.com 250 rgdiuggac :Highest connection count: 349 (348 clients) (378 since server was (re)started)
:irc5.aol.com 375 rgdiuggac :- irc5.aol.com Message of the Day - 
:irc5.aol.com 372 rgdiuggac :- - WELCOME TO AMERICA ONLINE'S - IRC SERVER
:irc5.aol.com 372 rgdiuggac :- 
:irc5.aol.com 372 rgdiuggac :- - !!!   WARNING WARNING WARNING WARNING   !!!
:irc5.aol.com 372 rgdiuggac :- - !!!  THIS SERVER SCANS FOR OPEN PROXIES !!!
:irc5.aol.com 372 rgdiuggac :- - !!!    PORTS: 8080,3128,80,1080,23      !!!
:irc5.aol.com 372 rgdiuggac :- -   So if this is a legal problem in your 
:irc5.aol.com 372 rgdiuggac :- -     country please disconnect NOW! 
:irc5.aol.com 372 rgdiuggac :- -  We do this to make your IRC experience 
:irc5.aol.com 372 rgdiuggac :- -  more enjoyable.
:irc5.aol.com 376 rgdiuggac :End of /MOTD command.
:rgdiuggac MODE rgdiuggac :+i
MODE rgdiuggac -x
MODE rgdiuggac +i
JOIN #xx :sex0r

[...]

Interesting information can be uncovered such as:

Now we are close to the answer: "how many bots populate the botnet".

It's worth to remember that when a JOIN command - used to join an IRC channel - is accepted successfully by an IRC server then it sends back the list of users who are on the channel. If we assume an exact match between users and bot compromised site, in this way we can calculate the number of hosts on the botnet.

The command response code to use is 353 - RPL_NAMREPLY, so we can filter messages like:

grep ':irc5.aol.com 353 rgdiuggac #xàéüîéðìx' irc.209.196.44.172
And finally we build a pipeline with the grep command above and a perl command to clean out just the "grepped" part above:
perl -p -e 's|:irc5.aol.com 353 rgdiuggac #xàéüîéðìx :| |g'

So the final command is:

grep ':irc5.aol.com 353 rgdiuggac @ #xàéüîéðìx' irc.209.196.44.172 | perl -p -e 's|:irc5.aol.com 353 rgdiuggac @ #xàéüîéðìx :| |g' > irc.209.196.44.172.users

So now the file "irc.209.196.44.172.users" contains the list of users space-separated. Rapidly we do the grand total:

    cat irc.209.196.44.172.users | tr -s ' \n\r' '\n' |sort|uniq|less|wc -l
and the result is 3458.
Because the first line is a pure newline character, the very final number of hosts on the botnet is 3457.

Assuming that each botnet host has a 56 kbps network link, what is the aggregate bandwidth of the botnet?

Because the number of bots compromised host is 3457 then the aggregate bandwidth is
3457 * 56 kbps, which approx equals to 189 Gbps

What IP source addresses were used in attacking the honeypot?

Our analysis is done using a different approach for UDP,TCP and ICMP. The UDP traffic from outside can be processed by

tcpdump -n -nn -r sotm27 'udp and dst host 172.16.134.191'|cut -d ' ' -f 2|cut -d '.' -f 1-4|sort|uniq
Giving as a result 113 hosts from 100 class B subnets.

TCP traffic from outside can be found running tcpdump and use a capture filter to get packets originating from the honeypot with SYN / ACK flags both set (second phase of the TCP three-way handshaking of a external-originated TCP session):

tcpdump -n -nn -r sotm27 'tcp and src host 172.16.134.191 and tcp[13]==18'|cut -d " " -f 4|cut -d "." -f 1-4|sort|uniq
Giving as a result 69 hosts from 67 class B subnets.

Using again tcpdump we discover that no other protocol except UDP and TCP are in our binary log file:

tcpdump -n -nn -r sotm27 '!(udp or tcp)'

Combing the two results obtained for TCP and UDP we have the following list of 128 attacking hosts:

12.252.61.161 12.253.142.87 12.83.147.97 129.116.182.239 141.149.155.249 144.134.109.25 148.235.82.146 162.33.189.252 164.125.76.48 168.226.98.61 168.243.103.205 169.254.205.177 172.168.0.154 192.130.71.66 195.36.247.77 195.67.251.197 200.135.228.10 200.50.124.2 200.60.202.74 200.66.98.107 200.78.103.67 202.63.162.34 203.106.55.12 203.115.96.146 205.180.159.35 206.149.148.192 207.6.77.235 208.186.61.2 209.45.125.110 209.45.125.69 210.12.211.121 210.203.189.77 210.214.49.227 210.22.204.101 210.58.0.25 211.149.57.197 212.110.30.110 212.122.20.74 212.162.165.18 213.107.105.72 213.116.166.126 213.122.77.74 213.170.56.83 213.217.55.243 213.23.49.158 213.44.104.92 213.7.60.57 213.84.75.42 216.170.214.226 216.192.145.21 216.228.8.158 216.229.73.11 217.1.35.169 217.222.201.82 217.227.245.101 217.227.98.82 217.35.65.9 218.163.9.89 218.237.70.119 218.244.66.32 218.25.147.83 218.4.48.74 218.4.65.115 218.4.87.137 218.4.99.237 218.87.178.167 218.92.13.142 219.118.31.42 219.145.211.132 219.145.211.3 219.65.37.37 219.94.46.57 24.107.117.237 24.161.196.103 24.167.221.106 24.197.194.106 24.74.199.104 4.33.244.44 4.64.221.42 61.111.101.78 61.11.11.54 61.132.88.50 61.132.88.90 61.134.45.19 61.140.149.137 61.14.66.92 61.150.120.72 61.150.72.7 61.155.126.150 61.177.154.228 61.177.56.98 61.177.62.66 61.185.212.166 61.185.215.42 61.185.242.190 61.185.29.9 61.203.104.148 61.55.71.169 61.8.1.64 62.127.38.198 62.150.170.134 62.150.170.232 62.194.4.114 62.201.96.159 62.251.129.118 64.17.250.240 64.254.203.68 66.139.10.15 66.190.67.122 66.233.4.225 66.73.160.240 66.81.131.17 66.8.163.125 66.92.135.108 67.201.75.38 67.81.161.166 68.115.33.110 68.152.53.138 68.154.11.82 68.169.174.108 68.37.54.69 68.45.123.130 68.84.210.227 80.181.116.202 81.114.77.37 81.202.125.5 81.50.177.167 81.57.217.208

What vulnerabilities did attackers attempt to exploit?

Snort will be used to uncover potential attacks to the honeypot. We use the standard stable ruleset and the following configuration file (suppose it's located in "/etc/snort/snort.conf"):

var HOME_NET 172.16.134.191/32
var EXTERNAL_NET !$HOME_NET
var DNS_SERVERS  $HOME_NET
var SMTP_SERVERS $HOME_NET
var HTTP_SERVERS $HOME_NET
var SQL_SERVERS  $HOME_NET
var TELNET_SERVERS $HOME_NET
var HTTP_PORTS 80
var SHELLCODE_PORTS any
var ORACLE_PORTS 1521
var AIM_SERVERS [64.12.24.0/24,64.12.25.0/24,64.12.26.14/24,64.12.28.0/24,64.12.29.0/24,64.12.161.0/24,64.12.163.0/24,205.188.5.0/24,205.188.9.0/24]
var RULE_PATH /etc/snort

###################################################

preprocessor frag2
preprocessor stream4: detect_scans
preprocessor stream4_reassemble
preprocessor http_decode: 80 unicode iis_alt_unicode double_encode iis_flip_slash full_whitespace
preprocessor rpc_decode: 111 32771
preprocessor bo: -nobrute
preprocessor telnet_decode
preprocessor conversation: allowed_ip_protocols all, timeout 60, max_conversations 32000

###################################################

output alert_full: snort_full
output alert_fast: snort_fast

###################################################

include classification.config
include reference.config

###################################################

include $RULE_PATH/bad-traffic.rules
[...]
include $RULE_PATH/local.rules
we omitted all the "include" lines for each snort rule file: all available rule file is included.
We will run snort with the configuration file above onto the binary log file by using
snort -c /etc/snort/snort.conf -r sotm27
We summarize snort processing with the following part of the standard output during snort execution:
===============================================================================

Snort processed 54536 packets.
Breakdown by protocol:                Action Stats:

    TCP: 54350      (99.659%)         ALERTS: 67        
    UDP: 186        (0.341%)          LOGGED: 67        
   ICMP: 0          (0.000%)          PASSED: 0         
    ARP: 0          (0.000%)
  EAPOL: 0          (0.000%)
   IPv6: 0          (0.000%)
    IPX: 0          (0.000%)
  OTHER: 0          (0.000%)
===============================================================================

A first inspection to the alert (fast log "snort_fast") suggests to eliminate a FP (False Positive), the one identified with SID (Snort ID) 615 - SCAN SOCKS Proxy attempt.

Then we can trace the IP addresses of the offending hosts by using:

grep -v ':615:' snort_fast|perl -p -e 's|^.*\s(\S+):\S+ -> 172.16.134.191.*|$1|g' | sort | uniq

and so we have back:

12.252.61.161 12.253.142.87 12.83.147.97 168.243.103.205 200.135.228.10 200.50.124.2 205.180.159.35 206.149.148.192 210.22.204.101 212.122.20.74 212.162.165.18 213.122.77.74 213.170.56.83 216.192.145.21 216.229.73.11 217.35.65.9 218.244.66.32 218.4.48.74 218.4.65.115 218.4.87.137 218.4.99.237 218.92.13.142 219.145.211.132 219.145.211.3 24.167.221.106 24.74.199.104 4.33.244.44 61.132.88.50 61.132.88.90 61.134.45.19 61.150.120.72 61.150.72.7 61.177.56.98 61.177.62.66 61.185.212.166 61.185.215.42 61.185.242.190 61.185.29.9 61.203.104.148 61.8.1.64 66.233.4.225 66.81.131.17 67.201.75.38 67.81.161.166 68.37.54.69 68.45.123.130 68.84.210.227 81.57.217.208

The total number of the above hosts is 48. Two possible attack types are indentified by snort:

The first type rappresents the this year most famous worm based on a known vulnerability on Windows 2000 and SQL 2000. Only W2k sp3 or bug fixed systems are immune. Attacks of this type use 1434/udp port of the honeypot. The confirmation of attacks success will be done in the next section.

The second type rappresents attempts to inject a shellcode into an ip session (look at snort rule of sid 1390) which in our case is an HTTP session. The possible attack could have exploit a race condition in the Microsoft web sever (buffer overflow) and later a shellcode is tryed. As a matter of fact Microsoft web servers unpatched (our case) suffer a lot of vulnerabilities (i do not want to start a religion war here): possible candidate!

At a very end we have to notice that because the honeypot administrator password is very trivial (blank password) then sessions not considered by snort (e.g. NBT - NetBios over TCP/IP) are dangerous. We will consider this in the next section.

Which attacks were successful?

We start collecting protocol statistics about the binary log file:

tethereal -n -z io,phs -R '!frame' -r sotm27
===================================================================
Protocol Hierarchy Statistics
Filter: frame

frame                                    frames:54536 bytes:17247037
  eth                                    frames:54536 bytes:17247037
    ip                                   frames:54536 bytes:17247037
      udp                                frames:186 bytes:49962
        nbns                             frames:129 bytes:26852
        data                             frames:2 bytes:120
        dcerpc                           frames:55 bytes:22990
      tcp                                frames:54350 bytes:17197075
        nbss                             frames:3769 bytes:2219209
          smb                            frames:2506 bytes:511805
            dcerpc                       frames:20 bytes:3800
            pipe                         frames:1276 bytes:258208
              dcerpc                     frames:1259 bytes:243638
                samr                     frames:523 bytes:109330
                  malformed              frames:1 bytes:1138
                srvsvc                   frames:4 bytes:1416
              data                       frames:17 bytes:14570
            data                         frames:9 bytes:12466
          data                           frames:69 bytes:104466
            nbss                         frames:13 bytes:19682
              data                       frames:1 bytes:1514
                nbss                     frames:1 bytes:1514
              nbss                       frames:1 bytes:1514
                nbss                     frames:1 bytes:1514
                  nbss                   frames:1 bytes:1514
                    nbss                 frames:1 bytes:1514
                      nbss               frames:1 bytes:1514
                        nbss             frames:1 bytes:1514
        http                             frames:12028 bytes:11481571
        data                             frames:918 bytes:185975
        ssl                              frames:1 bytes:105
        irc                              frames:9809 bytes:1632635
===================================================================
As already noted, no ICMP packets flows from/to the honeypot. This means that any UDP session from outside have found honeypot UDP port open because no "ICMP Port Unreachable" packet is sent back.
Now UDP sessions to the honeypot can be uncovered by
tcpdump -n -nn -r sotm27 'udp and dst host 172.16.134.191'|cut -d ">" -f 2|cut -d "." -f 5|cut -d ":" -f 1|sort|uniq
and the result is: 137/udp, 1434/udp, 28431/udp.
A following analysis focused specifically onto UDP port 28431 permits to exclude this as an attack.

Similarly to what done for UDP, we would like to collect TCP sessions from outside to the honeypot. By using tcpdump we are looking for TCP packets with flags SYN and ACK active and originated from the honeypot (same idea already used before):

tcpdump -n -nn -r sotm27 'tcp and src host 172.16.134.191 and tcp[13]==18' | cut -d "." -f 6 | cut -d " " -f 1 | sort | uniq
and the result is: 25/tcp, 80/tcp, 135/tcp, 139/tcp, 445/tcp, 4899/tcp.

So a summary of open ports in the whole binary file are:

service ports
smtp 25/tcp
nbt 135/tcp ; 139/tcp ; 445/tcp ; 137/udp
http 80/tcp
radmin 4899/tcp
sql dcerpc 1434/udp

So the suspect that the SQL worm attack were successful is very high. The final word is given by a statistical analysis of the packets over the time:

tethereal -x -n -tad -r sotm27 -R '!frame' -z io,stat,1800
The output of this command shows that there are holes in the bandwidth, sometimes and for hours, just when the 1434/udp packet arrived. This is exactly the effect of the worm; SQL work attack: success!

Then, we have to confirm the shellcode injection into the MS web server. From the snort log file we have that the host originating the attack has IP 210.22.204.101; then we use tethereal to look to the session it generates:

tethereal -l -x -n -r /root/sotm27 -R 'ip.addr==210.22.204.101 and http'

We can argue that (ordering by time from the oldest to the newest event):

  1. Browsing home page (with lot of attractive messages for an attacker)
  2. Attempt to exploit the well known '.ida' buffer overflow to inject a x86 shellcode (packet 1839-1840)
  3. Second attempt, same idea (maybe something was changed such as padding characteristics) (packet 1888-1889)
  4. Third and others attempts happen, up to a total number of 11 attempts

Looking through packets from 1841 to 1887 we can suppose that the effect of the malicious code should be to open a socket on the honeypot at port 99/tcp. The attacker is looking for that but that's not happen: attack unsuccessfull!

We are missing two issues:

  1. radmin, Software for Remote Administration
  2. nbt, NetBios over TCP/IP

The first issue, radmin, can be investigated by:

tcpdump -n -nn -r sotm27 'dst host 172.16.134.191 and tcp dst port 4899'|cut -d ' ' -f 2|cut -d '.' -f 1-4|sort|uniq
What results from here is that only the host of IP 210.22.204.101 has session to this tcp port.

However a close analysis:

tethereal -n -l -r sotm27 -R 'ip.addr==210.22.204.101 and tcp.port==4899'
reveals that at the beginning of the packet captured this port was not opened and this up to packet 1355-1356, and only at packet 2070-2071-2072 the tcp three-way handshaking successfully established a socket.

So the honeypot was violated by host IP 210.22.204.101, and this happens in the range of packets from 1357 to 2069. This happens exploiting NBT sessions, last chance. In fact the attacker by exploiting the weakness of the Administrator password, copied the radmin server into the honeypot and the put it into execution.

What did you learn about analysis as a result of studying this scan?

Firstable, i understand for what's better tcpdump and for what ethereal, that is the first is better for up-to ISO/OSI level 3 analysis, while ethereal for 4 to 7.

Second, I have studied botnet a little and i have to say that ideas behind are very fashinated.

Finally, to find common attacks is best to think simple.

How do you anticipate being able to apply your new knowledge and skills?

Blocking NBT traffic at border routers.
Enforcing password policy (host basis and eventually at the Domain Controller)
Upgrading operating systems and installed software according to vendors bug/security fixing

How can we improve the SotM challenge? What would you like to see added? What would you like to see done differently?

Minor issues: