Re: Honey VS Vinegar

[the rxmr <the.rxmr () gmail com>]

In-Reply-To: <FEBC66CCD411744381228574BAB53A9B8035E3 () MAIL fac gatech edu>

I'm glad you asked about this.  I have had this on my mind all week and began preparing these questions, etc.  So, here 
it goes...
------------------------------------------------------
AGGRESSIVE TACTICS FOR ATTRACTING MALICIOUS ACTIVITIES TO A HONEYPOT


WHY?

Many independent honeypot researchers find that much of the traffic they receive comes in the form of automated, 
self-propagating attacks from currently compromised computers; this is due to a number of factors not covered here.  
The data collected from these types of attacks can benefit the novice researcher.

However, there comes a time when one needs to advance their research and knowledge.  That is to say, with regard to 
better understanding tactics and motives, a honeypot operator benefits substantially from observing, and recording, an 
attacker's activities while interacting with the honeypot one-on-one, as it were.  In other words, a researcher should 
seek to lure many attackers in to "actively" using their honeypot versus primarily observing and analyzing automated 
exploit code.

It should be noted that luring attackers in to honeypots that are located within a production environment is not 
necessarily advocated.  The new knowledge that can be gleaned from enticing attackers that would otherwise not spend 
the time and resources to pursue compromising a random machine has the potential to greatly reward this research 
community.


HOW?

I will briefly cover six previously undefined concepts and offer terminology and definitions for consideration.  They 
are Honeykeys, Honeyposts, and Honeychat, respectively.  I will also briefly touch on how to implement these tools 
within a honeytoken.  In addition, I will briefly discuss Honeyteams, Honeymails, and a Honeysearch.

Honeykeys are ostensible pseudoclaims made in public or private on how to enter a honeypot; they are a blueprint for 
gaining access to a particular system.  These instructions may include items such as the address (in IPv4, IPv6, URL, 
Domain/Path, etc.) login, password, service/exploit (FTP, SSH, VPN, SQL, trojan, proxy/relay, etc.) and whatever other 
information the honeykey creator believes will entice malicious users to interact with their honeypot.  A honeykey's 
effectiveness lies within it being crafted and deployed to remain innocuous and sophistical.

Furthermore, a honeykey should never indicate its underlying intent; it should be made available through the use of a 
pseudonym and as anonymously as possible.  It is advised that honeykeys be made available about honeypots which have 
the ability to have an IP address that can be changed or dynamically assigned and that the domain/URL can be changed.  
This to help ensure that a honeypot's operation remain inconspicuous and undetected.  Also, honeykeys can be made 
available through a "team effort".

Honeykeys can be deployed through the use of a honeytoken.  For example, a file containing a list of IP addresses that 
claim to be compromised along with honeykey data for the honeypots that the honeykey creator wants to advertise.  The 
data provided about the remaining machines should not function; this should give the impression that some machines have 
been patched, fixed, etc. when an attacker attempts to use the bogus data.

The file should be named appropriately to attract interest in members of the Black Hat community.  The name and other 
data should contain language, dialect and terminology and other information that is generally representative of the 
information that is common those whom a honeypot operator is attempting to lure.  Less conspicuous names should be 
given consideration so that one particular filename does not gain recognition as being indicative of containing such 
data.  Also, the file names should be rotated regularly and reuse should be avoided, if possible.

The files can be distributed through popular file-sharing networks, or as attachments in carefully crafted Emails that 
reach the Black Hat community, or as attachments in newsgroup postings that are frequented by the intended audience.  
The file can also be made available on a honeypot that gives the appearance that it has already been compromised and 
such “goodies” are leftovers from the previous attacker.  Some of these uses do not necessarily fall within the concept 
of a honeytoken.  Let your imagination be your guide as to how to deploy such tactics.

Honeykeys can be disclosed in posts to online forums, message boards, newsgroups and other mediums in which their 
content would blend in with other topics that are discussed therein.  This type of disclosure is what I call a 
Honeypost.  This can also be done through a “team effort”, a Honeyteam, where one member requests such information and 
at some point the other team member replies with the honeykey/s.  However, this information is also publicly available 
to all other parties and that is part of the goal.  Also, honeyteams can be comprised of more than two members and can 
be from different research groups.  There may be other ways to make such information available, as well.

Honeychat is when a honeykey is deployed through real-time communications such as IRC conversations, Instant Messaging 
conversations, chat rooms, and other such mechanisms.  This can also be effectively done by a Honeyteam, as previously 
mentioned or through a carefully crafted IRC script (or scripts) and bots or other such tools.  It is meant to be 
observed by those who would take advantage of and use that information (and possibly spread it).  For example, a 
honeypot operator could program, plant and activate one of the variants of the SubSeven Trojan that performs 
notifications of compromise via IRC.  Furthermore, the honeypot operator could leak the fact that machines he 
compromises with SubSeven notify them on a particular IRC site and channel plus other convincing tidbits so that others 
may monitor his notifications and attempt to connect to the SubSeven server on the “compromised” machine.  This is just 
one small example and there are other methods that honeypot resear
 chers could devise for themselves.

At the beginning of this document I mentioned that some independent honeypot operators become frustrated with the same 
uninteresting attacks aimed at their systems.  Also, some operators may not wish to attract attackers to their 
honeypots at one time or another.  However, they may still be looking to do some research.  This is where the concept 
of a Honeysearch comes in to play.

A honeysearch is the process of actively seeking out primarily the most recent exploits from various resources; older 
exploits may be found as well.  The search should be performed from a honeypot or from a machine in which malicious 
code can be contained and analyzed.  Many specimens can gathered from searching and downloading suspicious files from 
common sources where malicious code is likely to be found.  This includes USENET, IRC, file-sharing applications, and 
websites that are likely to contain browser exploit code, to name a few.

Other methods may include the use of one more Email accounts that have been created and used to attract a large amount 
of unsolicited messages and, therefore, a prime recipient of Email-borne attacks; this is a Honeymail.  That is to say 
that each Email address/es is made widely available via communicating randomly through many public resources as 
previously mentioned such as USENET, forums, etc.  Also, replying or attempting to “opt-out” of mass-mailings may 
invite retaliation in the form more malicious mails.

Also, one may attempt to provoke such an attack from a member of the Black Hat community by engaging in an inflammatory 
conversation in a public forum or newsgroup (while making that Email address clearly visible and responsive to incoming 
messages – if possible, no content rejecting, filtering, etc.).  This may also invoke a response from allies of those 
whom you are attempting to provoke.  For a possible multi-vector response/attack, consider engaging in this verbal 
combat from your honeypot so that its IP address is possibly disclosed, as well.  This method obviously combines the 
use of the honeypost and/or honeychat concepts.

Some ISP’s, mail service providers, and researchers deploy a network of such honeymails to help “train” their antiSPAM 
technologies, most commonly known as a “spam trap”.  The two main differences between spam traps and honeymails is that 
a honeymail is used primarily to harvest Email-borne malware and its existence, in the form of the address, is made 
public to attract traffic.  Some readers may be conducting similar antiSPAM/anti-phishing research.  There are other 
methods of performing a honeysearch or soliciting malicious traffic to a honeypot and each researcher should devise 
their own course of action.


CONCLUSION

While this document was written to give independent researchers new methods of obtaining data, larger research groups 
can benefit from the described activities, as well.  After consideration, they should be deployed through a subtle, 
coordinated, systematic and methodological effort.  As always, be careful when playing with fire and don’t take on more 
than can be handled responsibly.  As the Black Hat community seeks to exploit systems, these methods seek to exploit 
that complex system for which there is no patch or workaround, the gullibility of the human mind and the fragile ego.  
These activities have the potential to attract attackers of all levels of skill, mentality, maturity, and experience.  
However, they will not always work.

It is also a goal of this paper to offer new terminology for consideration to the language of honeypot research so that 
a framework for documenting such activities can continue to be formalized.  Common terminology to describe concepts, 
activities, and the findings of such research enables this community to communicate more quickly and effectively.  
However, I am not asking that the community adopt these terms and definitions; they are just what I have come to use 
over the course of my experience with honeypots.  It is also a personal desire of mine to attempt to “profile” 
individual attackers and be able to analyze that data for similarities when other attacks are discovered; that is one 
reason why I suggested enticing potential attackers on a sometimes personal level.

Some people in the research community may already be using the same or similar tactics and terminology.  Some may 
disagree with what has been suggested.  I hope that some people find what has been described interesting enough to 
develop a plan for use and share their findings with us.  I am anxious to continue to learn from all of your research 
efforts.

These topics are open for discussion, criticism, and feedback.  Play both sides of the coin effectively; that is, be on 
both the offensive and defensive and, if necessary, aggressively pursue your research.  Each tactic has its advantages 
and disadvantages and I sincerely believe that by deliberately attracting more attention to your honeypots that a swarm 
of new knowledge is just waiting for us all.

------------------------------------------------------


> I was wondering about the complications inherent in "advertising" a
> honeypot.=20
>
>
> If you give the IP a DNS entry, the (google/altavista/lycos)bots try and
> index your IIS/Apache honeypot and you get a false alarm, even though
> the nicer ones may turn around after a robots.txt is found the traffic
> is recorded.=20
>
> Does this compromise the integrity of your honeypot?
>
> Then again, what about teaming up with fellow honeynets and
> googlebombing a misconfigured IIS 6.0/Apache banner to the previously
> mentioned DNS entry.
> (http://johnny.ihackstuff.com/index.php?module=3Dprodreviews shows a few
> examples of what people are searching for)=20
>
> Is this entrapment? Will you only observe known exploits through this
> type of lure?
>
> I know how I feel (1: Ignore the searchbots, 2: Entrapment? they
> shouldn't be trying to compromise servers via Google so go ahead and 3:
> Even known exploits can make room for nice code storage), but was
> wondering what conclusions others have reached, and more importantly: To
> those who automatically publish their logs: How do you automagically
> clean all of this up?
>
> -JP