There are no fragmented IP packets in the log; so filters
based on TCP flags etc will work for all packets and we can use tcpflow
for this (as of now, it doesn't handle IP fragments).

Finding/confirming open ports on the honeypot:

It's usually a very useful exercise in noting what TCP/UDP ports
were open at the start of the logs and which ones were suspiciously
opened later on. These latter ones are almost always backdoors
installed after a successful compromise. This connection auditing
is also important to configure Snort/other IDS for the honeypot when
we run it later. Usually though, such open-services information is available
from the system's administrator or direct access to the system itself.

For TCP ports, this is easy. We look for SYN-ACKs
from the honeypot. The source ports of these SYN-ACKs are open
(at least at that point of time). Ports that are not touched and
hence dont show up in the logs can be ignored.

The incrementing listening port-numbers pattern is almost
always a sign of FTP session (in this case, a FTP client from the
honeypot connected to an Active FTP server outside). A quick manual
check confirms this. We'll be looking at outbound connections from the
honeypot (something suspicious) soon. Let's mark this (outbound FTP connection)
as lead #1.

At this point it is instructive to note that the SYN-ACKs, just
like any other packet, could have been dropped by the kernel under heavy
load and hence never logged. So, there could be more ports open as well.
Missing SYN/SYN-ACKs for TCP sessions' logs is not rare, and a more
reliable way of detecting open ports is to use 23 (ARSF) as the mask
and match that with 18 (AS) or 16 (A) for TCP flags of packets from the
honeypot. For source ports < 1024, this works fine. However, this will
include all the ephemeral source ports (for outbound connections) as
well. Since we already have 3 ports to pursue, we'll stick to this list
for now (if we reach a dead-end, we can review this then).

Other ways of finding open TCP (and UDP) ports are:

- Use Snort/Bro/some IDS and find a vertical (ie port) scan,
and check responses.
- Although imperfect, check RSTs (RST-ACKs) from the honeypot.

Note: 3 most common reasons for a port to generate RSTs are:

- Its a closed port, and a connection arrives on it.
- The OS generates a RST-ACK since the user-space application
just crashed (happens on Windows boxs) [1,2].
- If the socket does an 'abortive release' close() using the SO_LINGER
socket option.

The first two factors have interesting security implications.
If we can find open ports that generated RSTs, it could mean that they
were closed before and were opened after a compromise as backdoors, or
that the application serving the port crashed during a session, which
could mean that there were overflow/other exploits attempts on it.

- the TCP port 1524 was indeed somehow opened on the honeypot.
- the source IP 61.219.90.180 was involved in this.
- the port 6112 was also somehow involved.

This has all the signs of a compromise, let's mark this as lead
#2, and we'll pursue it soon.

For UDP ports, doing the 'open-ports' analysis is tricky. Unlike
TCP listeners, UDP listeners get to inspect the payload/header of a
request before responding. It just might be that an UDP listener is
looking for a specific content in the UDP request in order to respond.
So for such open ports, no UDP/ICMP-Port-unreachable response clearly
doesn't mean anything:

32789, through a quick manual analysis, is seen as used as an
ephemeral port and that's why we see the two-way traffic from it. We
find from these tests that UDP port 53 is definitely open on the honeypot.
Port 137 was definitely closed since we see an ICMP Port Unreachable for/from
it.

#

Open-UDP

Open-TCP

Default-Type

1.

53

-

DNS

2.

-

1524

Ingreslock/Suspect

3.

-

6112

Dtspcd

4.

-

7000

IRC

Finding outbound TCP/UDP connections initiated
by the honeypot:

Fundamentally, since we control a honeypot, any
outbound connections from it that are unintentional/deliberate,
are suspect and potentially imply a compromise. Let's find the
outbound TCP connections initiated by our honeypot.

include $RULE_PATH/bad-traffic.rules
include $RULE_PATH/exploit.rules
include $RULE_PATH/scan.rules
include $RULE_PATH/finger.rules
include $RULE_PATH/ftp.rules
include $RULE_PATH/telnet.rules
include $RULE_PATH/rpc.rules
include $RULE_PATH/rservices.rules
include $RULE_PATH/dos.rules
include $RULE_PATH/ddos.rules
include $RULE_PATH/dns.rules
include $RULE_PATH/tftp.rules
include $RULE_PATH/web-cgi.rules
include $RULE_PATH/web-coldfusion.rules
include $RULE_PATH/web-iis.rules
include $RULE_PATH/web-frontpage.rules
include $RULE_PATH/web-misc.rules
include $RULE_PATH/web-client.rules
include $RULE_PATH/web-php.rules
include $RULE_PATH/sql.rules
include $RULE_PATH/x11.rules
include $RULE_PATH/icmp.rules
include $RULE_PATH/netbios.rules
include $RULE_PATH/misc.rules
include $RULE_PATH/attack-responses.rules
include $RULE_PATH/oracle.rules
include $RULE_PATH/mysql.rules
include $RULE_PATH/snmp.rules
include $RULE_PATH/smtp.rules
include $RULE_PATH/imap.rules
include $RULE_PATH/pop3.rules
include $RULE_PATH/pop2.rules
include $RULE_PATH/nntp.rules
include $RULE_PATH/other-ids.rules
include $RULE_PATH/web-attacks.rules
include $RULE_PATH/backdoor.rules
include $RULE_PATH/shellcode.rules
include $RULE_PATH/policy.rules
include $RULE_PATH/porn.rules
include $RULE_PATH/info.rules
include $RULE_PATH/icmp-info.rules
include $RULE_PATH/virus.rules
include $RULE_PATH/chat.rules
include $RULE_PATH/multimedia.rules
include $RULE_PATH/p2p.rules
include $RULE_PATH/experimental.rules

It's a bidrectional rule. From the Snort 'alert' file, we find
that they (the ICMP Echo-Reply heart-beats) were generated by the honeypot.
A clear sign of a DDoS agent installed on the honeypot. Let's check the
handler/master IPs the honeypot is communicating with:

From [5], we find that this is an open-proxy scan made by an external
IRC server when the honeypot attempted to connect to it. This only confirms
what we already know from lead #1. There's no more information here. Let's
skip this.

Single hit on a session with tcp port 6112 from source host
61.219.90.180 . Excellent! It's the same source IP as lead #2! The exploit
itself best correlates with [9]. Note that we haven't even used an IDS as
yet!

Summarizing the 4 solid leads so far, we have that the honeypot
has attempted connections to ports 80 (web), 21 (FTP), and 6667/5555
(IRC) on external hosts. Source 61.219.90.180 has attempted a buffer-overflow
exploit on dtspcd service (port 6112) and around that time a previously
closed TCP port 1524 has opened up on the Honeypot. The honeypot also
has a Stacheldraht DDoS agent installed on it that is attempting to link
up with two seemingly down handler/master hosts.

Extrapolating from the leads gathered so far, the most probable
analysis would be: The source 61.219.90.180 connected to the dtspcd service
on the honeypot (TCP port 6112), and exploited a buffer overflow on it,
and managed to install a backdoor on TCP port 1524. The attacker then
grabbed some tools, exploits, etc from some web servers and FTP sites and
installed the DDoS agent on the honeypot. It also appears that the honeypot
was made to join a IRC botnet.

Let's see if this is what actually happened.

Analysing leads:

Let's begin with the source IP 61.219.90.180 and its sessions with
the honeypot:

We note the "801c 4011 801c 4011 801c 4011" Sparc No-Op sled from
lead #2 and Snort alerts. This is where the attacker attempts a buffer
overflow on port 6112 (dtspcd service). The overflow, if successful,
would run the following on the victim host:

Briefly, what's happening here is, the attacker installs a "/bin/sh"
backdoor through inetd on the "ingreslock" (TCP port 1524) service port.
We already know the exploit was successful, since the previously closed
TCP port 1524 was opened soon after this attack (from our connection auditing
above). Port 6112 session provides no more interesting info. Let's move
on to the session(s) with port 1524:

We again use Ethereal's "Follow this TCP stream" tool on the 1524
session, and save an ASCII file. Let's go through this very important
session (edited and commented inline) now:

PsyBNC (from a quick Google search) is found to be an IRC Bouncer. Like any IRC bouncer, it hides thesource IP of the IRC client/user, and more specifically, it allows persistent connections to the IRCserver even when the IRC client disconnects - this allows the IRC user to maintain a NICK/Operator-statuson an IRC channel without having to be 'logged-on' at all times.# ./solbnc# ./dlp

"strings solbnc | grep skillz" gives 1 hit. Then comparing strings output with one from [3]below for the agent "td", we see some strong correlation. We conclude that "solbnc" is a Stacheldrahtstyle DDoS agent. (Why that name though, solbnc?).

"dlp" just deletes some logs and kills inetd. So 1524 wont be accessible anymore as a /bin/sh backdoorto others.

So we have a successful compromise detection, and have confirmed all the leads so far. The only unexplainedlead at this point is the external IRC (botnet?) connection attempts (port 6667 and 5555) from lead #1.

Do explain these outbound IRC connections, we quickly check the session(s) immediately preceding the firstoutbound connection attempt from the honeypot to port 6667. We find that the honeynet has a session onits port 7000 installed in the above compromise! We use Ethereal's "Follow this TCP Stream" to analyze thissession:PASS fargetta:Welcome!psyBNC@lam3rz.de NOTICE * :psyBNC2.2.1NICK Dj`bobz`

The 'ADDSERVER' commands explain the outbound IRC server connections from the honeypot! The attacker (same one, since he/she logs-in using password on the IRC server (actually a bouncer/proxy server on 7000, and uses 'bobz' as NICK) adds irc.stealth.net to the list of IRC servers on the port 7000 bouncer. Again note, the .itdomain in the IRC welcome message - it again implies that the attacker is Italian.

Day 1 Questions:

1. What is the OS of the honeypot? How did you determine that?
A. From the port 1524 session analyzed above, from the output of "uname
-a", we find the system info is "SunOS zoberius 5.8 Generic_108528-09
sun4u sparc SUNW,Ultra-5_10"

2. How did the attacker(s) break into the system?
A. It was a buffer-overflow vulnerability in the "dtspcd" service on
TCP port 6112 which was exploited to launch a /bin/sh backdoor on TCP
port 1524 using the inetd
daemon.

3. What systems were used during the attack, and how?
4. Create a diagram that demonstrates the sequences involved in the
attack.
A. Please refer to the above analysis and the following diagrams for
answers to these questsions: Day 1 Activity
, Day 3 Activity .

5. What is the purpose of the ICMP Packets with the word 'skillz' in
them?
A. This is the Stacheldraht DDoS agent's communication protocol with
its masters/handlers. It periodically sends ICMP Echo Reply packets with
the word 'skillz'
in them to a list of handler/master host IPs. More information can
be found in reference [3] below.

Since we already have analyzed a successful compromise on the honeypot
in day 1, what's left for us to analyze is any unusual activity the attackers
involve the honeypot in. This is to use the activity to learn new hacking
methodologies. Since the Challenge mentions a unique protocol being used,
we begin with tethereal's protocol stats:

There are several protocols displayed here, some wrongly tagged based
on port numbers only. The one ipv6 sub-protocol of ip stands out! It clearly
has been used as a tunneled protocol inside ipv4 packets. The authors have
little experience analyzing ipv6 traffic, let alone ipv6 tunneled inside
ipv4 packets. A little Googling was necessary. [6] & [7] provided some
insight.

We quickly find that two unusual protocol numbers were being used 0,
and 41. The protocol with number 0 is seen to be IPv6 Hop-by-Hop Options,
and seems irrelevant for our analysis. Let's check the other protocol 41,
which from [8], is for IPv6 tunneled inside IPv4 packets.

Using '-z io, users, ip' on tethereal over the protocol 41, we find that
there was just one user-IP pair, and the 'peer' for this honeypot activity
was 163.162.170.173, which is 'Telecom Italia Lab'.

We suspect that the attacker launched this tunneled IRC connect by running
some commands over the SSH session on port 5001. What exact commands were
run can not be known here, but we know that the attacker did download the
'ipv6sun' script over FTP (day 1) which most likely was involved in setting
this up (again, it reads from stdin, which we don't see on the 5001 session).
We also see a new version 2.3.1 of PsyBNC was downloaded on day 3. This one
perhaps supported IPv6 IRC servers.

The honeypot has an IRC session over this TCP-over-IPv6-over-IPv4 tunnel
with port 6667 of an external IRC server. Using 'Follow this TCP Stream'
in Ethereal and checking the NICKs, and channel names seen, we find that
it's the same attacker(s) who control that IRC channel as well ('bobz').

Other notable activities on day 3 were (details not shown for brevity):

- As shown above, on day 1, the Stacheldraht DDoS agent was installed
on the Honeypot and it periodically sent ICMP Echo Replies to handler 61.134.3.11
which didn't reciprocate then. The handler host comes up on day 3 and starts
replying with ICMP Echo Replies with 'ficken' in it (caught by Snort). Snort
also caught the related 'Niggahbitch' ICMP Echo Replies from the same handler.
There was apparently no other command exchange activity between the agent
and the handler apart from these ICMP pings to Ack each others' presence.
- There was a lot of scanning from the Honeypot for different hosts/ports.
- Using argus (with -z switch and grepping for 'sSE') we find that there
were no interesting TCP (over IPv4) sessions - just connects to the 7000/5001
backdoors and to an external IRC server (sessions that were expected).

Day 3 Questions:

6. Following the attack, the attackers enabled an unique
protocol. Can you identify that protocol and why it was used?
A. The attackers used IPv6 tunneled in IPv4 packets. Since most Intrusion
Detection Systems and even network traffic analysis tools have focussed
and have been used for mostly on IPv4 traffic/networks, it wouldn't surprise
us if no IDS detects/decodes this unique protocol as of now. We did find
that both Ethereal and Tcpdump support IPv6 tunneled inside IPv4 packets.

7. Can you identify the nationality of the attacker?
A. He/she/they are Italian. There were several pointers to this in the
analysis so far, including domains .it of external sites the honeypot connected
to, language used in files/sessions etc.

Thanks for a very interesting SOTM challenge!

Bonus Questions:

1. What are the implications of using the unusual IP protocol to the Intrusion
Detection industry?
A.

- Intrusion Detection is a fairly new industry. Commercial and Opensource
IDSes have only recently (last few years) matured in terms of Signature Base,
Protocol Decode Engines, Anomaly Detection, and Correlation.
- Most networks on the Internet today are based almost exclusively on IPv4
suite of protocols. Most vulnerabilities too are thus limited to IPv4 servers.
Naturally, IDSes too have limited their detection capabilities almost exclusively
to the 'regular' IPv4 protocols (TCP/UDP/ICMP etc over IPv4). IPv6 is a fairly
new phenomenon, meaning that few networks today deploy IPv6 protocols in production
use. - IDSs can only analyze protocols they can decode. To minimize Layer
4-7 regular expression searches, ID signatures are getting more and more
protocol dependent. Meaning, the core ID decode engine has to support a particular
protocol for good/any signatures to be written for that protocol. If an IDS
doesn't recognize a protocol/payload structure, signatures become essentially
blind floating string searches if any at all. Its quite like analyzing an
encrypted session.
- Hackers can evade detection by using such covert channels, that are invisible
to IDSs. It should be noted that, the compromise itself might still occur
over a regular IPv4 sub protocol that IDSs do support.

2. What tools exist that can decode this protocol?
A. From this challenge, we found that the following tools could be used
to decode the IPv6 packets tunneled inside IPv4 ones: