Re: Nested honeypots

[Ben Payne <ben () das wisc edu>]

Assuming both the nested honeypot and the host honeypot are running the 
most current version, would they both have the same exploits?

If I discovered that I were working in honeypot, I would evacuate and 
run test again.

The nested honeypots idea would only work if the "honeycrystal" were a 
very old version, with many known exploits.

Sounds extremely paranoid to me.



Ben



Nick Smith wrote:

> 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
>
>