smittyb wrote:I assume you are doing black box testing and you aren't sure if a honeypot is present.

Yes, One scenario is black box testing. The second scenario is professionally if we are going for a black box testing, we should be smart enough to say that there is/are honeypots in the network and their details are so and so.

If you do a black box testing and the honeypot is well configured it is nearly impossible to determine that it's a honeypot without getting direct access to that box.

Just by portscanning and fingerprinting it only would work if somebody assembles a weird configuration (e.g. you get the Banner of a Microsoft Exchange Server on TCP Port 25 and TCP fingerprinting tells you that it's probably some Flavor of Red Hat Linux ...)

There is no receipe how to do that, you'll need to take all the results you're able to get and think creative - I mean for instance I would think that it's rather unlikely (but nevertheless not impossible, so take care !) that somebody will place a honeypot inside an internal LAN side by side with the companys main fileserver.

The idea behind a honeypot is that it fools the hacker into thinking he has acquired access to an important area. If well setup you should not be able to tell other than you cant seem to move further to any other part of a network. The biggest mistake when setting up a honeypot is making it too inviting! If you were to scan a target of what you thought should have been a secure site and find it has lots of ports open with vulnerable services just begging you to jump in, thats more than likely a honeypit!

Thanks for the reply. If the honeypot is based on a UML , one way to identify it is by identifying its MAC address.

My only understanding about this is that as UML will be running more than one instance of an OS / honeypot, all these will be having the same MAC ID. So by identifying the MAC ID's we can identify whether the systems are honeypots or not.

Correct me if I am wrong and also can anybody throw more light on this?

To see the MAC address you need to be on the same pysical network segment - that's very unlikely in a real black box test - in general you'll have to access the network you want to test from the ugly internet (the same way as wiley hacker would do it). So that would not be an option.

You can easily identify mac address on a wireless network from the outside with tools like kismet but thats another issue. A well configured honeybot will be extremely difficult to identify, especially from the outside. All examples I am aware of that identify honeypots rely on a poor configuration and we know Admins never do that, lol! There are even commercial tools such as Honeypot Hunter that use anti-honeypot technology. Honeypot Hunter checks with lists of HTTPS and SOCKS4/SOCKS5 proxies for honeypots. Even tools like that can be defeated if the honeypot is configured properly.

Last edited by Kev on Fri Jul 21, 2006 10:08 am, edited 1 time in total.

Even so, why would you want to? A Honeypot is a bare-bones system, usually with nothing more on it than the OS. It serves as bait for hackers. When properly configured, when a hacker finds a honeypot and is exploring it, the honeypot sends a message (usually an email) to the Admin and gives the Admin time to repsond to the potential attack by a hacker.

I would say if the hacker finds an install of KFsensor, the most common Honeypot software, then the hacker could be assured yhe had found a Honeypot. But if he's smart, he'd better get out of there and cover his tracks before he Admin sees him and can track him down. Next step is to call the FBI.

All a honeypot is is BAIT! That's it!!!

Last edited by oyle on Sat Jul 22, 2006 9:52 am, edited 1 time in total.

MCP, MCP+I, MCSA, MCSE(NT4/W2K), CCNA, CCA, NWCCC, VH-PIRTS, CEH --------------------"hackers are like jedi, crackers are like the sith: do not fall prey to the dark side".

The only value for the ethicial hacker or admin in seeing if he can detect a honeypot outside of the network is to test the honeypot he has created. That is if you even fool with such things. I am not a big believer in them except in the case where an Admin wants to actually watch and learn how attacks take place.

Last edited by Kev on Fri Jul 21, 2006 7:47 pm, edited 1 time in total.

Kev wrote:The only value for the ethicial hacker or admin in seeing if he can detect a honeypot outside of the network is to test the honeypot he has created. That is if you even fool with such things. I am not a big believer in them except in the case where an Admin wants to actually watch and learn how attacks take place.

As Kev mentioned, the ulitimate aim of this discussion is to test the honeypot installation and to learn and countermeasure. As we know, to defend an attack we have to think like an attacker. Even though policies and guidelines exists, the human factor always plays a major role in all security aspects. What I mean to say is that all the Admins won't be configuring the systems or honeypots in the similar manner. There will be some configuration changes from installation to installation and the hacker's will be exploiting these minor changes. So our aim should be to detect these configuration changes and to identify the security impact created by these changes.

Does any one know about a scenario where a honeypot has been compromised and used for further attack? Do you think it is possible or has it happened?

I have never heard of a honeypot that has been compromised and used for further attacks. As Oyle pointed out, it’s really a trap and is being observed more than most servers. While it might be a tempting target from the outside, once breached it is the worse place a hacker can end up. Remember, hackers like to sneak into the network. Attacking a honeypot with the idea of further breaching a network is like walking through the front door of a house that is under heavy surveillance by the police! I have heard of honeypots being attacked with denial of service, but never used as a launch area for further successful infiltration of a network.

As the next logical line of defense, a Sheepdip should be installed. If by some chance a persistent hacker makes his way past the Honeypot with intentions of planting a Trojan, backdoor, or virus, the savvy Admin should install a Sheepdip. A Sheepdip is a separate box that looks for Trojans, viruses, etc. That's ALL it does. Proper placement should be inside the DMZ. A proper DMZ should be formed by dual firewalls, and each firewall should be a different brand, so they check for different tests, constantly. Proxy server also in the DMZ.

Yes Oyle is very correct. We should never take things for granted as far as securing a network. I thought I should clarify my post, while I have not heard of a honeypot being a place to launch further attacks, in no way am I saying it’s impossible. I have been involved with security for long time now and can say I have seen some amazing hacks. I remember when we all thought it would be impossible to hack Cisco and then it happened. So I would say its not bad to be a little on the paranoid side if you are in charge of securing a network. Perhaps one day we ethical hackers can meet and have our own “capture the flag” games like they do in Defcon and attacking and owning a honeypot stealthy could be one of them.

Last edited by Kev on Sat Jul 22, 2006 10:49 am, edited 1 time in total.

Y'know, I may not be able to find a full-time job working in networking, but I'll bet half of these places I apply to don't even KNOW what a sheepdip is, much less a honeypot. Someone needs to enlighten these people managing networks.

Last edited by oyle on Sat Jul 22, 2006 12:48 pm, edited 1 time in total.

MCP, MCP+I, MCSA, MCSE(NT4/W2K), CCNA, CCA, NWCCC, VH-PIRTS, CEH --------------------"hackers are like jedi, crackers are like the sith: do not fall prey to the dark side".