Documente Academic
Documente Profesional
Documente Cultură
2016 IEEE
IEEE International
International Conference
Conference on
on Cloud
Cloud Engineering
Engineering Workshops
Workshop
AbstractHoneypots, i.e. networked computer systems specially designed and crafted to mimic the normal operations
of other systems while capturing and storing information
about the interactions with the world outside, are a crucial
technology into the study of cyber threats and attacks that
propagate and occur through networks. Among them, highinteraction honeypots are considered the most efcient because
the attacker (whether automated or not) perceives realistic
interactions with the target machine. In the case of automated
attacks, propagated by malware, currently available honeypots
alone are not specialized enough to allow the analysis of
their behaviors and effects on the target system. The research
presented in this paper shows how high-interaction honeypots
can be enhanced by powering them with specic features that
improve the reverse engineering activities needed to effectively
analyze captured malicious entities.
Keywords-Honeypots; malware detection; malware analysis;
reverse engineering; network security
I. I NTRODUCTION
Nowadays, an ever growing number of systems and devices interoperate and cooperate over the Internet which has
become a huge and very complex open distributed system.
Being open is one of the features that brought Internet to
the role it plays into the current IT scenario. However, this
expose the interconnected services and devices to the risk
of being the target of Internet-enabled malicious entities
also known as malware. A challenging goal of the research
efforts directed in the Cyber Security eld is the devising
of effective techniques and tools able to face and defeat
the attacks coming from such entities. Hence, it is crucial
to analyze and understand a malware behavior in order to
identify the vulnerabilities it exploits and to take the suitable
countermeasures. Malware activities are often detected a
lot of time after the victim system has been violated and
then it is very difcult to trace back the actions that have
been executed. A malware usually modies le systems,
978-1-5090-3684-4/16
/16
$31.00 2016 IEEE
$31.00 2016 IEEE
DOI 10.1109/IC2EW.2016.16
65
C1
File system
C2
P
R
O
X
Y
Network
.
.
.
Process
execution
Cn
HEReSy
Logger
Figure 1.
HERES Y architecture
Verify protocol
protocol not
handled
Refuse connection
protocol
handled
Build environment
Traffic redirection
Handle disconnection
Traffic dump
Organize
captured
information
Start
process
monitor
Destroy
environment
Start
versioning
filesystem
Detect new
process
Detect
filesystem
access
not Malicious
Malicious
Log
modifications
Hijack
Commit
updates
no modifications
Malicious
Figure 2.
HERES Y process
A. Proxy module
Once a connection attempt reaches the system, if the
proxy has been congured to handle the requested service, a
fresh new container is built on the y and all the attackers
66
Tracer daemon
logCmd(R1)
hashRunningBinary(Pn)
XOR
Verified?
Figure 3.
Trace
Figure 4.
Not trace
Dump
ready to be used.
B. Filesystem module
C. Network module
Trafc generated by attackers or malicious software is of
course fundamental to track where the malicious activities
start and where they try to propagate. For each environment
a complete network trafc dump is performed, so a clean
data representation of the network ow is given to the threat
67
SSH bruteforcing
Bruteforce failed
Access
gained
Self replicate on
the filesystem
III. E XPERIMENTS
HERES Y has been tested by distributing it inside a
/16 network (i.e. a campus network). Thousands of attacks
targeting various protocols have been detected. Among them,
the most targeted were FTP, SSH, TELNET, HTTP and
SMB. Independently from the kind of attack, the system
is able to recognize and log all the spawned commands. If
the executed binaries belong to the attacked environment,
their execution is just logged, otherwise, i.e. the process
is recognized alien, the dynamic binary instrumentation
module begins tracing it. All the instructions executed are
saved in a separate log for each traced process. Furthermore,
an experimental process dumper takes periodic snapshots
saving all the information regarding le descriptors, memory,
registers, and so on. All the le system accesses, which
concern modications, are saved on a versioning basis.
All this workow allowed to observe almost completely
the behavior of various malware and permitted to accelerate the reverse engineering process. The vast majority
of the captured attacks comes from the BRIC area, most
of them targeting embedded systems, many others have as
target common platforms like x86_64 and others were
equipped of multi-platform droppers written in common
script languages such as bash, Python, etc. The deployment
of HERES Y instances in various machines inside this big
network permitted to observe that the behavior of some
malware is also iterative, in the sense that an attack on a
low IP address inside the same network reached high IP
number addresses just some minutes later. So, we observed
basically that this kind of malware tries to reproduce itself
enumerating many IP addresses and searching for the same
vulnerability.
Execute
Delete itself
open a connection
to a remote FTP
server
Search for files
to upload
Upload
file found
Figure 5.
no more files
Disconnect
A. A simple malware
During the testing phase of HERES Y, we captured a
series of malware. In this section, we will describe the most
simple of them. We analyzed its behavior by extracting
the data captured by HERES Y. The malware entered the
honeypot through a brute force attack to the SSH protocol.
Once it guessed the password, it reproduced itself on a
specic location of the le system. So we tracked the copy of
the malicious binary inside our le system replica. Then, the
network module sniffed all the connections to a malicious
FTP server performed by the malware and controlled by an
attacker. By looking at the memory dump of the malware,
68
IV. C ONCLUSIONS
[9] M. Kumar and M. Hanumanthappa. Scalable intrusion detection systems log analysis using cloud computing infrastructure. In Proceedings of 2013 IEEE International Conference
on of Computational Intelligence and Computing Research
(ICCIC), pages 14, Tamilnadu, India, Dec. 2013.
[10] A. Mairh, D. Barik, K. Verma, and D. Jena. Honeypot in
network security: A survey. In Proceedings of the 2011
International Conference on Communication, Computing &
Security, ICCCS 11, pages 600605, New York, NY, USA,
2011. ACM.
[11] I. Mavridis and E. Karatza. Log le analysis in cloud with
Apache Hadoop and Apache Spark. In Proceedings of 2nd
International Workshop on Sustainable Ultrascale Computing
Systems (NESUS 2015), Krakow, Poland, Sept. 2015.
[12] S. McCanne and V. Jacobson. The BSD packet lter: A new
architecture for user-level packet capture. In Proceedings of
the Winter USENIX 1993, pages 259270, San Diego (CA),
January, 25-29 1993. USENIX Association.
[13] I. Mokube and M. Adams. Honeypots: concepts, approaches,
and challenges. In Proceedings of the 45th annual southeast
regional conference, pages 321326. ACM, 2007.
[14] T. Schurmann. Save and restore linux processes with CRIU.
ADMIN Magazine, 22, 2014.
V. ACKNOWLEDGMENTS
[15] L. Spitzner. Honeypots: catching the insider threat. In Proceedings of the 19th Annual Computer Security Applications
Conference, 2003, pages 170179, Dec 2003.
This work has been partially supported by the National Operative Programme for Research and Competitiveness 2007-2013, Technological District on Cyber Security
(PON03PE 00032 2 02), funded by the Italian Ministry of
Education, University and Research, and the Italian Ministry of Economic Development.
R EFERENCES
[1] Filesystem in userspace. http://fuse.sourceforge.net/.
[2] gitFS. https://www.presslabs.com/gitfs/docs/.
[4] D. Bruening, T. Garnett, and S. Amarasinghe. An infrastructure for adaptive dynamic optimization. In Proceedings of
International Symposium on Code Generation and Optimization (CGO 2003), pages 265275, 2003.
69