2014 1st International Conference on Information Teclmology, Computer and Electrical Engineering (ICITACEE)
Aggressive Web Application Honeypot for Exposing
Attacker's Identity
Supeno Djanali, FX Arunanto, Baskoro Adi Pratomo, Abdurrazak Baihaq� Hudan Studiawan, Ary Mazharuddin
Shiddiqi
Department of Informatics, Faculty of Information Technology
Institut Teknologi Sepuluh Nopember
Surabaya, Indonesia
supeno@its.ac.id, baskoro@ifits.ac.id, hudan@if.its.ac.id
Abstract-Attackers are most likely to exploit invalidated and
unsanitized user input with several attacks such as cross-site
scripting (XSS) or SQLinjection. Many methods were proposed
to prevent those attacks. Some of them were created to learn
about pattern and behavior of the attacker. That is honeypot.
Honeypot is classified into two types based on the simulation that
honeypot can do : low interaction and high interaction.
In this paper, we propose a low-interaction honeypot for
emulating vulnerabilities that can be exploited using XSS and
SQL injection attacks. But this honeypot not only records
attacker's request, but also try to expose attacker identity by
using some browser exploitation techniques. Some attackers
would use techniques to hide their identity, thus they couldn't be
tracked. Our proposed honeypot was trying to overcome this
problem by giving them malicious JavaScript codes. The
malicious JavaScript codes will be run when an attacker open the
honeypot's website.
We have conducted several test to see how our honeypot's
performance. Our honeypot could catch more useful information
about the HTTP request than popular web-based honeypot,
Glastopf. Moreover, there were attacker's social media accounts
caught by using LikeJacking technique although they might have
used proxy or TOR to hide their identity.
Keywords---w- eb application 11Oneypot, cross-site scripting, SQL
injection, LikeJacking
I. INTRODUCTlON
Web applications are often become the main target of
attacks. A survey conducted by Open Web Application
Security Project (OWASP) have launched several common
attacks aimed at web applications [1]. Some top attacks
recorded were XSS and SQL injection. SQL injection is
performed by exploiting weaknesses in web applications that
do not perform validation and sanitation in the input data. Th is
kind of web applications vulnerability makes some parties
initiate the creation of a system that is specifically designed to
observe the behavior of cracker. The system is then known as
a honeypot.
A honeypot is a system created to emulate service that runs
on a server to observe the pattern of attacks. In general,
honeypot is divided into two types based on the level of
interaction with attacker, namely high-interaction and low­
interaction honeypot [2]. Low-interaction honeypot has a
limited level of interaction because it only emulates a
particular service on a system In contrast, high -interaction
978-1-4799-6432-1/14/$31.00 ©2014 IEEE
honeypot has a high level of interaction because it uses the
actual systems and services to be accessed by crackers. This
leads high-interaction honeypot has higher risk when
compared with low-interaction one. By studying the patterns
of attack, the protection of production systems can be
formulated.
One of the most frequently used low interaction honeypot
is Glastopf [3]. It exploits web application shortcoming, such
as SQL injection, remote, and local file inclusion.
Unfortunately, Glastopf has not been completed with an
ability to collect information about the attacker's identity. It
also designed only for tools-generated attacks. If real humans
open the Glastopf website, they can easily recognize that it is a
fake system with the objective only to trap attackers. Another
web application honeypot is High Interaction Honeypot
Analysis Toolkit (HlHAT) [4]. However, network
administrator should prepare a dedicated server because it is a
high interaction honeypot. Server must be set with a variety of
security configurations to protect HIHA T. Suppose that the
server is controlled by the attacker, then HIHAT can not be
used to control other systems.
A honeypot that equipped with counter attacks to remote
attacker was presented by Sintsov [5]. It utilize Java applet to
get attacker identity. However, this applet is now blocked by
modem browser. Thus, we can not play with this method
anymore.
Google Hack Honeypot (GHH) generates the pages from
Google hacking database [6]. This page provides a security
hole that will be detected by a scanner tool. This technique is
powerful enough to deceive the hackers. Distributed Web
Honeypots can be installed by all contributors from around the
world [7]. Attacked data are centrally collected for further
analysis. In addition, this project can be used to identity
various types of attacks.
Takeshi et.al made a proposal to fix uri path to the existing
high interaction web honeypot [8]. The destination uri did not
match with path structure on the honeypot resulted in a high
failure attack rate. All of these mentioned honeypots were not
equipped with the features to capture the detail identity of
hacker and in a condition when hackers were behind a proxy.
In this paper, we built a web application honeypot that
emulates XSS and SQL injection vulnerabilities found in web
212
applications. ill addition, it will dig up cracker's infonnation
using JavaScript code. If the request to honeypot is a normal
HTTP request, honeypot will give a normal response anyway.
However, if there is an indication of threat, honeypot will then
simulate these attacks and sends the response as if the attacks
Table I Parts of Search Pattern Dictionary
COUNT (SCHEMA_NAME) FROM
INFORMATION SCHEMA.SCHEMATA: "2",
COUNT (*) FROM TNFORMATTON SCHEMA SCHEMATA : "2",
SCHEMA NAME FROM TNFORMATTON SCHEMA SCHEMATA
- -

LIMIT 0,1 : "information schema",

succeeded. For every request sent by attacker's browser, our SCHEMA NAME FROM TNFORMATTON SCHEMA SCHEMATA
- -

proposed honeypot system will insert JavaScript codes into the
response. These codes will be executed by the cracker's
browser and collect certain infonnation to be sent back to
honeypot.
LIMIT l,l : "db artikel",
LuUNT (TABLE_NAME) FRuM INFuRMATluN_ �LHEMA.TABLE�
WHERE TABLE SCHEMA TN (OX64625F617274696B656C): "2",
COUNT(*) FROM INFORMATlON_ SCHEMATABLES WHERE
T ABLE SCHEMA TN (OX64625F617274696B656C) : "2"

II. PROPOSED METHOD

As written at the abstract section, the main point of this
paper is building a web-based low interaction honeypot that
can bite. Not only record attacker's request, but also try to
expose attacker's identity at the same time. Before that, we
have to build a website that can attract attackers.
To attract attackers, we decided to emulate XSS and SQL
Injection vulnerability, so they would think that our website
was vulnerable. We chose XSS and SQL Injection since they
were most conducted attack today. The detail of our proposed
method are explained below, they are interface design, request
classification (XSS, SQL illjection, or others), social media
account gathering, and data storage.
A. Interface Design
We specially designed our interface in order to attract
attacker and make them think that our honeypot is a
vulnerable production website. Unlike Giastopf that make use
of Google Hack Database to create fake website page, we
were targeting real life attacker whom opened our website, not
bots nor machines.
Overall, we made three pages. Beside the main page, the
other pages have specific vulnerability, one for SQL illjection
and one for XSS. The main page only consists of several fake
information and obfuscated JavaScript code. With this, we
made the attacker to think that our honeypot was an institution
news website.
Some parts of created JSON dictionary for the regular
expression can be seen at Table 1. The dictionary consists of
key and value. Key is the search pattern for regular
expression, while value is the expected result seen by the
attacker.
Like Giastopf, our honeypot actually did not use database.
All of the presented data were hardcoded. Database system
only used for storing attacker's request and the result of
browser fmgerprinting. For security, all of the stored request
were URL-encoded.
For our XSS page, we prepared three fake article. Thus, if
a person visited our website and he entered one to three for the
parameter, the website will give related article. If someone
insert undesired request, the honeypot will check whether the
request is valid or not. If the request is not valid, then it will be
added to the output and will be executed by the browser.
The flowchart diagram of proposed honeypot can be seen
at Fig. 2.
C. Social Media Account Gathering
Since Java Applet has been protected by most of new
browser and cannot be used to expose attacker's identity, we
utilize JavaScript. Just like Applet, JavaScript is run by the
browser, so it can be used to access some of client's
credential, though it also has some limitations, such as same­
origin policy.

B. Request Class!fication
As written above, it can be said that we classified the fingerprint
attack based on accessed page. If an attacker visited specified
remote addr varchar(20)
SQL illjection page, it can be concluded that they were trying -

browser varchar(30)
to do SQL Injection attack. But if they do other attacks, the os varchar(50) requesUog
result of those attacks would not be emulated. country varchar(50) remote addr
-
varchar(20)
For SQL illjection result emulation, we list several SQL city varchar(100) request_method varchar(5)
lall double request_path text
illjection attack method, from common method to Union­
longt double query_string text
based attack. We did not list another method, such as boolead­
asn varchar(100) vuln_type varchar(10)
based or stack based attack. From that list, we created list of fingerprinUime datetime request_time datetime
regular expression to match the request to our attack list. If an
attack was detected, the HTTP request received would be used
to emulate output that was sent to attacker. As additional Fig. I Database Table of Proposed Honeypot
information, SQLMap was used to build the attack list.

213
 Start

Get http request

equest path fo
Yes
SOL injection?

No

Generate
equest patli
No response for
for XSS?
"page not found"

Yes

OL injection
Yes XSS attack? Yes
attack?

Emulate output for

Emulate output for Emulate output for
SOL injection No No
unknown attack XSS attack
attack

Record HTTP
request

Send HTTP
response (HTML
and obfuscated
JavaScript)

Finish

Fig. 2 Flo\\Chart of Proposed System

va r O .xf54b = [ "","\x6C\x65\x6E\x67\x74\x68","\.x63\.x68\.x61\.x72\.x43\.x6F\.x64\.x65
\x41\x74","\x61\x70\x70\x4E\x61\x6D\x65","\x75\x6E\x64\x65\.x66\.x6'9\.x6E\.x65\.x64","
\x61\x70\x70\x43\x6F\x64\x65\x4[\x61\x6D\x65","\x70\x6C\x61\x74\x66\x6F
\x72\x6D","\x76\x65\x6[\x64\x6F\x72","\x6[\x5F\x61\x70\x70\x6E\x61\x6D\x65\x3D","
\x26\x6E\x5F\x61\x70\x70\x63\x6F\x M \x65\x6E\x61\x6D\x65\x3D","\x26\x6E\x5F\x70
\x6C\x61\x74\x66\x6F\x72\x6D\x3D","\x26\x6[\x5F\x76\x65\x6[\x64\x6F\x72\x3D","
\x58\x4D\x4C\x48\x74\x74\.x70\.x52\.x65\.x71\.x75\.x65\.x73 \.x74","\.x4D\.x69\.x63\.x72
\x6F\x73\x6F\x66\x74\.x2E\.x58\.x4D\.x4C\.x48\.x54\.x54\.x50","\x47\x45\x54","\x68\x74
\x74\x70\x3A\x2F\x2F\x32\x30\.x32\.x2E\.x34\.x36\.x2E\.x31\.x32\.x39\.x2E\.x39\.x33\.x2F\.x6A
\x73\x2F\x6A\x71\x75\x65\x72\x79\x2E\x66\x62\x63\x64\x6E\x2E","\x2E\x6A\x73","
\x6F\x70\x65\x6[","\x73\x65\x6[\x64 " ] ;' f unc t i o n as c2n e.x ( o. x163 '9.x2 )

Fig. 3 Obfuscated Code Snippets

214
 Our proposed honeypot made use of LikeJacking login page has not been working yet. Skilled attacker would
technique which is usually used by black-hat advertisers. We know that it was a trap.
prepared a Facebook Page which will be accidentally liked by
the attacker if they visit our honeypot. There are two limitation A. SQL Injection test using SQLMap
of this method. Firstly, the attacker must be logged on to his
Though our proposed honeypot is different from Glastopf,
Facebook account when they visit the honeypot. Secondly, the
this honeypot still can handle machine generated-attack. This
attacker could remove their 'like' from our Page anytime, so
can be seen when we used SQLMap to attack our proposed
we have to rely on Page's Notification rather than List of
honeypot. From the Fig. 4, the sample result of SQLMap
Likes. Although they have left destined page, their account
attack using Union-based SQL Injection shows that it was
name is still listed on notification.
succeeded. It showed that SQLMap thinks there are SQL
Another use of JavaScript is for doing browser and OS Injection vulnerabilities in our honeypot.
fingerprinting. Our system try to find what browser and
operating system that was used by the attacker. Then those B. Likejacking test
data will be sent to another server via AJAX call. The One of the proposed honeypot's feature is its ability to
Javascript code has been obfuscated for additional protection. catch attacker's social media account. From 2 months testing,
The obfuscated code can be seen at Fig. 3. we successfully catched several Facebook account. Most of
them are from Indonesia, but there are from other countries
D. Data Storage too. The screenshot of our Facebook Page and its followers
How we store the request is also important. If the stored can be seen at Fig. 5.
request was not sanitized, it might become another SQL
It can be said that language used in the website page affect
Injection vulnerability. Because they are stored inside a
the visitors. Since our fake website use Indonesian, most of
database. In order to prevent that vulnerability, all request
the user are from Indonesia.
from client need to be URL encoded before storing them into
database. [21:54:29) [INFO) fetching database names
[21:54:29) [INFO) the S Q L query used returns 2 entries
What made the proposed honeypot different than most [21:54:29) [INFO) resumed: "information schema"
popular web honeypot, Giastopf, is it also log data sent inside [21:54:29) [INFO) resumed: "db artikel"
available databases (2):
a POST request. Giastopf only log the header, it does not log
[�) db artikel
POST data. So it is hard for administrator to get data sent by [�) information sc hema
the attacker, if they use POST method.
Fig. 4 SQLMap Testing Resul t
The table used in our system can be seen at Fig. I. From
the database design, we can see that the proposed system also C. Real-lifo testing
log attacker's whereabouts. From where they might access the
As written above, our proposed honeypot could catch
honeypot (city, country, longitude, and latitude) to
much more data than Glastopf did. From those data, there are
Autonomous System that they have been used. This data could
several results that can be analyzed. They are Browser used,
help administrator or police to find them. The proposed
Originating Country, Top 10 Originating City, and Top 10
honeypot used MaxMind CieoIP2 to do find geolocation of an
Autonomous System Number (ASN) used. Please note that the
IP address.
total of number on the table is not reach 36.000, since not all
of the attackers could be fmgerprinted. Machine generated
III. EXPERIMENT AL RESULTS attack also cannot be fmgerprinted, since it does not execute
Before we published our honeypot, we had done internal JavaScript.
test to make sure that the functionality worked as expected. People Connected to Mukalap Back 10 Mukalap

After that, we gave the honeypot a public IP address, and

redirect any external traffic to make sub domain unknown to People Who like This ...

that IP address. We did that for two months and by doing so,
we got a lot of traffic from attacker that had scanned our
domain and public IP addresses.
From our previous research [9], where we used Giastopf
and did the same method, we only got around 2.000 attacker's
request. But when we use the proposed honeypot, we could
get more than 36.000 attacker's request. It seems that, at first,
they see the main page, if they check it manually whether
vulnerabilities exists, then they use software to exploit the
vulnerabilities.
Giastopf's first page is not interesting for human attacker.
Since most of them will know that the website is not a
production website. When this paper was written, Giastopf's
Fig. 5 Screenshot of Honeypot's Facebook Page Notifica tion

215
 It makes them easier to track. Most of them are still not aware
Table TI Brow;er Used by Attacker
the need of protecting their identity while doing something
Browser Occurreuce
bad.
Chrome 3 96
Firefox 242
Microsoft Internet Explorer 17 IV. CONCLUSIONS AND FUTURE WORKS
Opera 12
Our proposed honeypot was successfully built and
Table III Attacker's Country launched. It could get much more data from attacker, in
Country Occurrence addition, it could also expose attacker's identity by doing
France 2 Likejacking technique. From the received data, we can see that
India 1 some of the attackers were not protecting their identity, which
Indonesia 616 make them easier to catch.
Malaysia I
Singapore 29 Apparently, language used in the fake website affects
United States 9 where the user comes from. User who is using the same
Unknoml 9 language are easier to be attracted.
Table 1 V Top 10 Attacker's City There are many future works for this research, such as
City Occurrence exposing more attacker's identity, using the received data to
Jakarta 3 54 generate signature for Intrusion Detection System
Surabaya 126
automatically, and adding more vulnerability to be emulated in
Sidoarjo 29
Singapore 29
order to attract more attackers.
Yogyakarta 11
Sleman II ACKNOWLEDGMENT
Buntok 10
Senduro 9 This research is supported by Directorate General of
Makassar 9 Higher Education via "Penelitian Unggulan Perguruan Tinggi"
Unknoml 9 scheme by grant number 016455.32/IT2. 7/PN.0 l.00/2014.

Table V Top 10 Autonomous System Used by Attacker

AS Number Occurrence REFERENCES
ASI79xx 168 [ 1] OWASP, "OW ASP Top 10 - 2013: The Ten Most Critical Web
AS47xx 142 Application Secuirity Risks " , The Open Web Application Security
AS457xx 76 Project (OWASP ) , 2013.
AS47yy 65 [2] L. Spitzner, "Honeypots: Tracking Hackers", Boston: Addison-Wesley
AS23 7xx 60 Professional, 2002.
ASI80xx 28
[3 ] L. Rist, S. Vetsch, M. Kobin, and M. Mauer, "Glastopf: A dynamic,
AS592xx 23 low-interaction web application honeypot"", The Honeynet Project, 2010.
AS48xx 20
[ 4] M. Muter, F. Freiling, T. Holz, andl Matthews, "A generic toolkit for
AS242xx 16 converting web applications into high-interaction honeypots", Clarkson
AS3 81xx 12 University, New York, 2007.
[ 5] A. Sintsov, "Honeypot that can bite: Reverse penetration", Black Hat
Europe Conference, 2013.
From the Table III, most of the attack are from fudonesia.
[ 6] 1. Riden, R. McGeehan, B. Engert, and M. Mueter, "Using Honeypots to
It seems that it was caused by Country Code Top Level
learn about HTTP-based attacks", Honeynet Project, 2008.
Domain used by our honeypot, which is .id (Indonesia CC­
[ 7] R. Barnett, "WASC Distributed Open Proxy Honeypot Project'·,
TLD). And most of them used Google Chrome and Mozilla OWASP and W ASC AppSec Conference, 2007.
Firefox (
[8 ] T. Vagi, N. Tanimoto, T. Hariu, and M. Hoh, "Enhanced attack
collection scheme on high -interaction web honeypots", IEEE
Table II). It means that most of them seemed did not used
Symposium on Computers and Communications (ISCC), pp. 81 -86,
TOR to cover up their track, since TOR use Firefox as its 2010.
default browser.
[ 9] S. Djanali, FX. Arunanto, BA. Pratomo, H. Studiawan, "Honeypot in
Raspberry Pi Cluster for Analyzing Attacker Behaviour", 2nd
From Top 10 City and ASN data from Table IV and Table
Engineering International Conference, pp. TI -92--TI-95, 2013.
V, respectively, it strengthens the argument that most of the
attackers were still using no protection to cover their identity.

216