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_at_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
>
>
Received on Thu Jun 10 2004 - 15:57:30 PDT
