Do techniques exists to know if a machine is a honeypot (or suspicious indicators)?
What techniques can be used for a software inside the honeypot or outside it?
What techniques uses malware to prevent infecting honeypot?
Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.Sign up to join this community
The honeypot is not just there to attract an attacker, but also to gain information about them. So, a honeypot wants to log all actions of the attacker.
An attacker may now cause a log overflow (a technique seen in the wild is writing and deleting some file very often) and change their bahaviour on the information gained this way.
A malware may also try other methods to detect whether the machine it has infected is raw iron or a virtual machine.
Ideally, no. A honeypot is a word used to define the purpose of a machine, but has no bearing on the machine itself, how it's configured or any particular software running on it.
That said, someone creating a honeypot typically has the goal of luring targets into expending resources or breaking OpSec. To do this, they would present a goal that appears to offer a significant reward and/or minimal effort required to exploit. Provided the owner of the honey pot is not a very good poker player (knowing how much to offer without making the trap obvious), one could potentially measure the "too good to be true" value of a machine.
Sadly, though, if one were to compare this measure with the majority of internet connected hosts, a deliberately weak and valuable goal will be largely indistinguishable from one that is accidentally so.
Hmmm, how to tell if you have walked into a honeypot, let's see...
The machine looks like it was just set up yesterday and the only thing it has on it besides default directories is a folder called "Sensitive" filled with page scans of old copies of 2600 and lists of mispelled names and address purporting to be employees of HB Gary.
The mouse driver has the manufacturer labeled as "Microsoft SMS Solutions"
You try to talk to the drive controller or any other DMA device and the computer begins responding like it had a lobotomy.
The CPUID op code places value 0x02 in EAX
You do an RDTSC timing on an instruction sequence and the resulting value is some insane number.
You try to make an HTTP connection to cnn.com and get the error "cannot connect"
The only printers installed on the machine have the word "generic" in their name.
You give the command "net view" and get back the response "The list of servers for this workgroup is not currently available."
Your radio scanner suddenly has a lot of wierd activity on Motorola trunking lines by guys with Texan accents saying things like "Code 10" and "in position".
In all seriousness, the only people who fall for honeypots are adolescents or amateurs using Blackhole or something. Normally, hackers who present any serious threat will never enter a honeypot because they target specific IPs which they know ahead of time to be valid machines. If the hacker wants to identify any honeypots sitting on, say, a corporate network, it is easy to do because the machine will either have no outbound traffic or the traffic will be contrived and not follow a normal usage pattern. Also, a supposed machine sitting alone outside the DMZ is a dead givaway.
While, as Smiling Dragon stated ideally honey pots are undetectable, they can be. An attack can use context and known implementation details to detect a honey pot.
Context can be very important. That is, a machine is too obviously insecure (as stated above) or too insecure relative to the environment, this can be an indicator to tread softly.
With regards to implementation details this follows like other software, especially operating system software (consider OS fingerprinting). If a stimuli that induces a response known to be (or thought to be) from a honey pot this can alert or caution an attacker.
These might papers be worth a read for you, http://old.honeynet.org/papers/individual/DefeatingHPs-IAW05.pdf and http://ro.ecu.edu.au/cgi/viewcontent.cgi?article=1027&context=adf