Re: Nested honeypots

["Andrew R. Lamb" <arl7969 () it rit edu>]

Nick,

There is a wealth of information out there on virtual honeypots. I think your concept aligns with the idea of 
amalgamated honeypots (warning: self advertisement link coming up) - check out my paper at 
http://www.lucidic.net/whitepapers/alamb-3-2002.html

> From a hacker's perspective, you'd want to attack a host of a honeypot most likely to hide your tracks. Try setting up 
> honeyd inside a virtual machine and leave it running; see if you get anything exciting :) you just might.

Nick Smith <nick.smith () telus net> writes:
> 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