Honeypots

Introduction

A honeypot is a trap set to detect, deflect, or in some manner counteract

attempts at unauthorized use of information systems

They are the highly flexible security tool with different applications for
security. They don't fix a single problem. Instead they have multiple uses, such
as prevention, detection, or information gathering

A honeypot is an information system resource whose value lies in

unauthorized or illicit use of that resource
 What is a Honey Pot?
• A Honey Pot is an intrusion detection technique used to study hackers
movements
 What is a Honey Pot?(cont.)

• Virtual machine that sits on a network or a client

• Goals
 Should look as real as possible!
 Should be monitored to see if its being used to launch a massive
attack on other systems
 Should include files that are of interest to the hacker
 Classification
By level of interaction
• High
• Low
By Implementation
• Virtual
• Physical
By purpose
• Production
• Research
 Interaction
Low interaction Honeypots
• They have limited interaction, they normally work by emulating services and operating
systems
• They simulate only services that cannot be exploited to get complete access to the
honeypot
• Attacker activity is limited to the level of emulation by the honeypot
• Examples of low-interaction honeypots include Specter, Honeyd, and KFsensor
 Interaction
High interaction Honeypots
• They are usually complex solutions as they involve real operating systems and
applications
• Nothing is emulated, the attackers are given the real thing
• A high-interaction honeypot can be compromised completely, allowing an adversary to
gain full access to the system and use it to launch further network attacks
• Examples of high-interaction honeypots include Symantec Decoy Server and Honeynets
 Implementation

• Physical
• Real machines
• Own IP Addresses
• Often high-interactive
• Virtual
• Simulated by other machines that:

– Respond to the traffic sent to the honeypots

– May simulate a lot of (different) virtual honeypots at the
same time
 Production

• Production honeypots are easy to use, capture only limited information, and
are used primarily by companies or corporations
• Prevention
• To keep the bad elements out
• There are no effective mechanisms
• Deception, Deterrence, Decoys do NOT work against automated
attacks: worms, auto-rooters, mass-rooters
• Detection
• Detecting the burglar when he breaks in
• Response
• Can easily be pulled offline
 Research

• Research honeypots are complex to deploy and maintain, capture extensive

information, and are used primarily by research, military, or government
organizations.
• Collect compact amounts of high value information
• Discover new Tools and Tactics
• Understand Motives, Behavior, and Organization
• Develop Analysis and Forensic Skills
 Advantages

• Small data sets of high value.

• Easier and cheaper to analyze the data
• Designed to capture anything thrown at them, including tools or
tactics never used before
• Require minimal resources
• Work fine in encrypted or IPv6 environments
• Can collect in-depth information
• Conceptually very simple
 Disadvantages

• Can only track and capture activity that directly interacts with
them
• All security technologies have risk
• Building, configuring, deploying and maintaining a high-
interaction honeypot is time consuming
• Difficult to analyze a compromised honeypot
• High interaction honeypot introduces a high level of risk
• Low interaction honeypots are easily detectable by skilled attackers
Working of Honeynet – High – interaction honeypot

• Honeynet has 3 components:

 Data control
 Data capture
 Data analysis
Working of Honeyd – Low – interaction honeypot

 Open Source and designed to run on

Unix systems
 Concept - Monitoring unused IP space
 Conclusion

• Not a solution!
• Can collect in depth data which no other technology can
• Different from others – its value lies in being attacked, probed or
compromised
• Extremely useful in observing hacker movements and preparing
the systems for future attacks
Rootkit-based Attacks and Defenses
 What are
rootkits?
Rootkits == Stealthy
Rootkits Stealthy malware
malware

• Tools used by attackers to conceal their

presence on a compromised system
• Typically installed after attacker has
obtained root privileges
• Stealth achieved by hiding accompanying
malicious user-level programs
 Rootkit‐based attack
scenario
Rootkits hide malware from anti-malware tools

Anti virus Key Logger

Backdoor
Applications
Kernel Rootkit-infected kernel
Kernel code Kernel data

Internet

Sensitive information
Credit card: 4358654606
SSN: 543106789
 Significance of the problem
• Microsoft reported that 7% of all infections
from client machines are because of
rootkits.
• Rootkits are the vehicle of choice for botnet-
based attacks: e.g., Torpig, Storm.
– Allow bot-masters to retain long-term control
• A number of high-profile cases based on
rootkits:
– Stuxnet (2010), Sony BMG (2005), Greek
wiretapping scandal (2004/5)
 Evolution of rootkits

Focus of this System

talk:binaries
Kernel-level rootkits
/usr/bin/ls
/usr/bin/ps Shared Libraries
USER SPACE /usr/bin/login
System call table IDT
Process Lists

Kernel Code
KERNEL SPACE

Hypervisor‐based rootkits  
(Subvirt, Bluepill)
BELOW OS KERNEL

Device/Firmware rootkits  
BELOW HYPERVISOR (Stuxnet)
5
 Manipulating control
data
• Change function pointers: Linux Adore rootkit

sys_open(...)
{
int main() ...
{ }
open(…)
... esvyisl__ooppeenn
return(0)
}
evil_open(...)
{
...
System call table }

USER SPACE KERNEL

2
1
 Manipulating non‐control
data
• Change non-control data: Windows Fu rootkit
run-list

Process A Hidden process Process B Process C

run_list run_list run_list run_list

next_task next_task next_task next_task

all-tasks

2
2
 Manipulating non-control data
• Goal: Attack the kernel’s pseudorandom number
generator (PRNG) [Baliga et al., 2007]

The
The operating
operating system kernel presents
presents
Secondary
a avast
vastattack
attacksurface
surfacefor
forrootkits.
rootkits.
Entropy Pool
(128 bytes) /dev/random
External Entropy Primary
Sources Entropy Pool
(512 bytes)

Urandom
Entropy Pool /dev/urando
(128
m bytes)

8
 Detecting rootkits: Main
idea
• Observation: Rootkits operate by
maliciously modifying kernel data structures
– Modify function pointers to hijack control flow
– Modify process lists to hide malicious processes
– Modify polynomials to corrupt output of PRNG

Continuously monitor
Continuously monitor the
the integrity
integrity
of kernel data
data structures
structures
 Continuously
Continuously monitor
monitor the
the integrity
integrity
of kernel data
of kernel structures
data structures

Process lists
Kernel Kernel
Code Data PRNG pools
System call table

Data structure integrity monitor

• Challenge: Data structure integrity monitor

must be independent of the monitored system
• Solution: Use external hardware, such as a
coprocessor, or a hypervisor to build the
monitor
 Continuously
Continuously monitor
monitor the
the integrity
integrity
of kernel data
of kernel structures
data structures

Process lists
Kernel Kernel
Code Data PRNG pools
System call table

Data structure integrity monitor

• Challenge: Must monitor kernel code,

control and non-control data structures
• Solution: Periodically fetch and monitor all
of kernel memory
 Continuously
Continuously monitor
monitor the
the integrity
integrity
of kernel data
of kernel structures
data structures

Process lists
Kernel Kernel
Code Data PRNG pools
System call table

Data structure integrity monitor

• Challenge: Specifying properties to monitor

• Solution: Use anomaly detection
– Inference phase: Infer data structure invariants
– Detection phase: Enforce data structure
invariants
 Rootkit detection using invariants

sys_open(...)
{
int main() ...
{ }
open(…)
... evil_open
return(0)
}
evil_open(...)
{
...
System call table }

Function pointer
Invariant: Function pointervalues
valuesin
in
system call table
table should
should not
notchange
change
 Rootkit detection using invariants
run-list

Process A Hidden process Process B Process C

run_list run_list run_list run_list

next_task next_task next_task next_task

all-tasks

Invariant: run-list all-tasks