Honeypots mailing list archives
Nested honeypots
From: Nick Smith <nick.smith () telus net>
Date: Wed, 09 Jun 2004 11:51:38 -0700
Hi, This thought popped into my head today while doing something completely unrelated. I am sure that some of you have already thought of this, but since I cannot it recall it being mentioned in the past, I thought that I would float the idea... So far, we have been using our honeypots to determine how attackers go about exploiting normal systems. However, savvy attackers are now aware of the existence of honeypots and are developing anti-honeypot techniques. With this in mind, how about setting up a honeypot within a honeypot (honeycrystal??? i.e. something even sweeter within the honeypot) so that we can see how an attacker will behave once s/he discovers that the resource that they are interacting with appears to be a honeypot of some kind? I'm not picking on honeyd, but it sprung to mind as an example because its virtualization capabilies and because, being lower interaction, it *might* be easier to fingerprint. The scenario would be something like: Attacker is interacting with the virtual hosts created within honeyd. Something causes attacker to become suspicious, which results in some fingerprinting activity. Attacker concludes that honeyd is being used and goes about either exploiting honeyd (not aware of any exploits, but who knows) or directly attacking the host that honeyd is running on. However, the system hosting honeyd is also a honeypot, so we get to see what the attacker does once s/he thinks that they have bypassed honeyd. The value of this may be more apparent when the attacker is using encrypted sessions... Taking this up a notch, how about using VMware. Guest OS is, say, RH 6.2 (with lots of low-hanging fruit) with sebek and modified bash. Attacker compromises it and thinking how easy it was, decides to check whether s/he has exploited a honeypot. Attacker discovers that the system is indeed a honeypot and takes measures to neutralize our data capture tools. Since the attacker is using an encrypted session, s/he thinks that we are unable to see the commands s/he executes since our network based capture tools will only see encrypted traffic. However, the VMware host is also configured with the necessary data capture tools so, unbeknown to the attacker, we can follow every action that they make. Of course, the attacker might be really smart and decide to check out the VMware host, in which case they would probably discover and neutralized our data capture mechansims. However, by this time we may have captured some new, important data that may help us to make our existing honeypot techonologies more stealthy. Cheers, Nick
Current thread:
- Nested honeypots Nick Smith (Jun 09)
- Re: Nested honeypots Andrew R. Lamb (Jun 10)
- Re: Nested honeypots Ben Payne (Jun 10)