Criterios de evaluación.

All these methods used to capture information make ManTrap an extremely powerful technology. To better understand its capacity to gather information, let's review an actual attack captured by ManTrap. What makes this attack unique is that this was the first time this attack was ever captured in the wild, demonstrating ManTrap's ability to not only detect known activity but the unknown as well.

Our honeypot in question, a default installation of Solaris8, was configured with three cages. The first of the three cages, cage one, was configured to run the most services to include all CDE and rpc-based services. Cage one was also configured to e-mail alerts to an administrator. Alerts are nothing more than specific log entries from the cage's log file (in this case, /usr/rti/var/log/cage1) that are remotely sent to an

administrator. The Alert Level determines which logged events are alerted. In Figure 10-10, we see the alerting configuration for cage one, sending all alerts to [email protected].

On January 8, 2002, cage one was successfully attacked with the Solaris dtspcd vulnerability. ManTrap

successfully detected and captured the entire attack. This attack was the first recorded incident of a dtspcd attack, making information gathering critical. The more we could learn about this new attack, the better.

ManTrap first alerted to the attack via an e-mail alert. As you see in Figure 10-10, cage one was configured to send e-mail alerts on important activity. The ManTrap sniffer, rti.sniffd, detected and reported the attack. Even if no service had been running on this port, the connection would have still been detected and reported. Following are the entries from two consecutive e-mails. Combined, these alerts indicate that the dtspcd service is being probed and activated. As a honeypot, no system should be connecting to this service, so this is highly suspicious.

Date: Tue, 08 Jan 02 08:47:03 CST From: [email protected] To: [email protected] Subject: ManTrap alert

2002.01.08:08.47.03:64:rti.sniffd: incoming connection from=(208.61.1.160:3595) to=(172.16.1.102:6112)

The second alert is not from the sniffer but from the process log. This captures and logs all of the process activity on each cage. In this case, we see that after the connection to dtspcd service, the service is activated—in this case with uid=(0).

Date: Tue, 08 Jan 02 08:47:04 CST From: [email protected] To: [email protected] Subject: ManTrap alert

2002.01.08:08.47.04:128:rti.proclog: exec args=(/usr/dt/bin/dtspcd); pid=(3472); ppid=(799); uid=(0); euid=(0); gid=(0); egid=(0)

These two consecutive e-mail alerts indicate that suspicious activity is taking place. However, it is the third e- mail alert that confirms an attack has just occurred. We see that the attacker has successfully executed commands as a superuser on the cage. In this case, the attacker is creating a backdoor by having the root shell listen on the ingresslock service, or port 1524. Based on this executed activity, the attacker simply connects to port 1524 on our honeypot and they have complete remote access to the cage.

Date: Tue, 08 Jan 02 08:47:04 CST From: [email protected] To: [email protected] Subject: ManTrap alert

2002.01.08:08.47.04:128:rti.proclog: exec args=(/bin/ksh -c echo "ingreslock

stream tcp nowait root /bin/sh sh -i">/tmp/x;/usr/); pid=(3472); ppid=(799);

uid=(0); euid=(0); gid=(0); egid=(0)

These alerts demonstrate several capabilities of ManTrap technologies. First, ManTrap has the capability to detect and alert attacks in progress, even if they are unknown attacks. Second, these alerts are highly informative, explaining to you step by step the attacker's actions and the effects those actions have on the honeypot. In the first alert, ManTrap's sniffer detects and alerts to a connection on port TCP 6112. At the time of this attack, I had no idea what port TCP 6112 was. As if to answer my own question, ManTrap immediately followed up with the second alert, stating that the /usr/dt/bin/dtspcd service had been started and as UID 0. The attacker's connection had initiated the dtspcd process, which was most likely an attack. Even though I had no idea what port 6112 was, ManTrap was able to inform me that the attacker was focusing on the dtspcd service.

Last, in the third e-mail, we see the actual result of the exploit. The process log has recorded the execution of a backdoor on the cage, giving the attacker full access. This confirms that not only was an attack launched but it was successful. Connections and actual system activity are logged and recorded, which makes ManTrap a powerful tool for information capture.

Keep in mind that these alerts are nothing more than entries logged to the ManTrap log file. Since this attack was against cage one, all of this information is stored in /usr/rti/var/log/cage1. We can reference the information in the log file later to analyze the attack in greater detail.