PERSISTENT DATA-ONLY MALWARE:
Function Hooks without Code
Presented by Ben
Summers for CSCI 780
OUTLINE
 Introduction
 Resident Malware
 Persistent Malware
 Data-only Malware
 Background
 Protection Mechanisms
 ROP (Return-Oriented Programming)
 Data-only Malware
 Hardware Mechanisms of ROP
 Software Mechanisms of ROP
 POC and Discussion
 Summary
RESIDENT MALWARE
https://c1.staticflickr.com/3
/2245/2077361447_2d2ee
0e834.jpg
 “Any malware that has the ability to continue to achieve its objective
without any human interaction despite a reboot or power cycle”
 It “lives in” the target’s system autonomously. It actively subverts
detection by executing and exploiting code on the system.
 It distinguishes itself from Persistent Malware because resident malware
operates using at least some code.
 It’s the “mouse in the house.” While it may take some digging to get into
the system, it can use inside or outside resources to achieve its goals
and ensure its survivability.
PERSISTENT AND NON-PERSISTENT MALWARE
 “Makes permanent changes in memory and permanently changes the
control flow within a system such that it continue to achieve its
objective.”
 Persistent Malware is a hijacker. It replaces function pointers with a
pointer to a malicious function, plugging in the data that was meant for
the original function.
 Once a persistent malware grabs ahold of a system, it is worried about
keeping control.
 Non-Persistent Malware is malware that makes
permanent changes to the system but leaves the control
flow intact. Does not permanently affect the control flow.
http://www.nyrock.com/images/contop.jpg
DATA-ONLY MALWARE
 “Introduces specially crafted data into the system with the intent on
manipulating the control flow without changing or introducing new
code.”
 It is also a hijacker but the instruction pointer (IP) never points to any
code introduced by the malware, unlike persistent malware.
 Data-only Malware makes the computer work against itself. It uses
the pre-existing software and libraries such as libc
to achieve its goals.
 It makes the computer “hit itself” with its own
power and resources.
http://blog.zennioptical.com/wp-content/uploads/2014/05/Zenni-71.jpg
OUTLINE
 Introduction
 Resident Malware
 Persistent Malware
 Data-only Malware
 Background
 Protection Mechanisms
 ROP (Return-Oriented Programming)
 Data-only Malware
 Hardware Mechanisms of ROP
 Software Mechanisms of ROP
 POC and Discussion
 Summary
PROTECTION MECHANISMS
 Canary values stop overwrites as any buffer attach that overwrites the return values





must overwrite the canary value, which is initialized with a random number – useless
against Data-only malware
The Linux kernel loads external libraries to addresses beginning with ‘\0’ which is
handled as a string terminator – can be useful against Data-only montage
Marks pages as writable or executable but never as both, which prevents an attacker
from introducing new code – useless against Data-only malware
Loads specific code section in random offsets – hard counter to Data-only malware
Processor will not allow execution in code in user space while operating in kernel
mode – useful against data-only malware
Checks digitally signed binaries before loading code – used for kernel protection and
not that useful against Data-only malware.
RETURN-ORIENTED PROGRAMMING
(ROP) DIAGRAM
http://cs.ucla.edu/classes/fall10/cs111/scribe/15b/index_html_4c4ae2c6.png
ROP SEQUENCES AND ADVANTAGES
 ROP can get around many protection mechanisms but needs a control
structure that determines the execution order and the sequence must
end with a ret (return) instruction.
 The ROP redirects the pointer to execute sequences of instructions
(gadgets) as each gadget ends with a ret instruction.
 The stack pointer (SP) must initial point to a control structure which
can be achieved by either copying the gadget chain into the stack or
copy the ROP chain somewhere else and point the SP to that address.
 Large code libraries such as libc can give the attacker many gadgets to
build arbitrary functions.
STACK PIVOT
 Copy the ROP chain somewhere else in memory and point the SP the
SP to the location.
 This is usually very difficult as it is often only possible if the attacker has
control of the register or can place a ROP chain near the SP so that it
can be pointed to be modifying the offset. Thankfully, the predictable
state of most machines make it so that it is easier to point to the ROP
chain.
 The eax command and commands to control the offset are often used
to manipulate the SP.
 The instruction sequence to modify the SP are not standard and must
be adapted to the machine state.
DATA-ONLY MALWARE
 Prerequisites:
 Instructions – System must contain the instruction sequences that are required for
the malware
 Vulnerability – Requires a vulnerability within the victim’s system
 Memory – The software contains the vulnerability must provide a mechanism to load
the required control structure into memory
 Control – The vulnerability must provide the attacker with control of the instructor
pointer (IP) and enable them to activate the necessary control structure; Not every
vulnerability will work.
 Non-persistent Data-only Malware is the same except it DOES NOT
permanently change the control flow of a system. Non-persistent
malware cannot place hooks and thus cannot intercept events that
occur within the host. It relies on an external entity to run.
PERSISTENT DATA-ONLY MALWARE
 Two Stages to permanently altering control flow:
 Initialization
 Vulnerability is exploited and initialization control structure performs bootstrapping of
malware.
 Persistent stage
 Implements the persistent functionality of the malware
 Steps to persistent stage: find a memory location, protect against
overwrite, resume control flow, and activating the control structure.
 The stack is usually not best suited for the ROP chain but if it is small, it
can fit.
CHALLENGES TO PERSISTENT MALWARE
 Most ROP stacks need to be located in a place outside the stack and
must be stored in a memory location. This area must never be
deallocated.
 The data structure has to be protected against overwrites and have a
predictable structure so that the malware executes correctly. Selfinduced overwrites (Ex: address is pushed and some of the gadget used
by call) and interrupt-induced overwrites, which are triggered by
uncontrollable external events, are the main challenges of ROP success.
Most interrupt-induced overwrites take place in the kernel space.
 Have to guarantee that execution continues normally after the malware
has run. Register or memory values must not be overwritten.
 Switching sequence must fire to point to the ROP sequence.
DESCRIPTION OF THE ROP CHAIN
 Since the chain is stored in memory and not the stack, the first instruction
sequence must modify the SP to point to the memory location where the
ROP chain is stored. This is called “switching the stack.”
 This is a requirement for persistent (which stay active) data-only malware.
 Because the attack set the return address of a function to the ROP chain,
the attacker controlled code will be executed. Since we know the return
address of our changed function, we can determine what functions are
executed before the overwritten return address is used.
 Persistent data-only malware needs to find a way using a gadget to stack
switch without corrupting register or memory values used later on.
 The attack must hand back the hook to the previous function.
OUTLINE
 Introduction
 Resident Malware
 Persistent Malware
 Data-only Malware
 Background
 Protection Mechanisms
 ROP (Return-Oriented Programming)
 Data-only Malware
 Hardware Mechanisms of ROP
 Software Mechanisms of ROP
 POC and Discussion
 Summary
ROP HARDWARE MECHANISMS SYSENTER
 Sysenter instruction – an interrupt-based system call mechanism that
relies on model-specific registers
 IA32_SYSENTER_CS – defines the target code segment that will be used after the
context switch
 IA32_SYSENTER_EIP – holds the IP that will be used after the context switch
occurred
 IA32_SYSENTER_ESP – holds the SP that will be used after the context switch
 Manipulation of EIP and ESP allows the attack to control SP and IP. The
malware also monitors which hooks is the result of a real system call or
the result of a function hook.
ROP HARDWARE MECHANISMS - TSS
 Task State Segment (TSS) are not used by most OSs but TSS perform
context switches between processes.
 A malware may control the IP and SP during invocation of a hook but must
first set up a TSS descriptor which is pointed to by the function hook. The
TSS descriptor are saved so that the malware can easily restore old
execution context.
 This technique is restricted to 32-bit systems. In 64 and 86 bit systems, the
TSS can control the SP through the Interrupt Stack Table (IST), which
contains the memory region that can be used as a stack region.
 To do this, the first gadget must increase the SP by the size of the interruptstack-frame and then the hook has to be set to a gadget to invoke the
interrupt which includes the TSS descriptor to trigger the hook.
OUTLINE
 Introduction
 Resident Malware
 Persistent Malware
 Data-only Malware
 Background
 Protection Mechanisms
 ROP (Return-Oriented Programming)
 Data-only Malware
 Hardware Mechanisms of ROP
 Software Mechanisms of ROP
 POC and Discussion
 Summary
ARCHITECTURE OF PERSISTENT DATAONLY MALWARE
SOFTWARE MECHANISMS FOR
SWITCHING THE STACK
 Attack doesn’t control a register nor a buffer on the stack.

If the persistent control structure is put above the stack, which means that the control
structure must be loaded at an address that is smaller than the original stack minus the
maximum stack size of the process.
 This allows the control structure to not be destroyed during program
execution.
 The stack offset does not have to point directly to control structure as it can use a NOP
sled to enter the control structure.
 May overwrite the stored address (per_cpu) so that when it switches the
user space to kernel space, it will load the overwritten address.
 May overwrite multiple function points to make a function pointer chain
 Library pointers are called as function pointers that are offsets within a global table (GOT)
ARCHITECTURE OF PERSISTENT DATAONLY MALWARE - INITIALIZATION
 Initialization Chain
 Must be loaded using a vulnerability
 Only executed once – more like traditional ROP exploit
 Does not require an exclusive memory area or affected by overwrites
 (1) places a hook, (2) setups a switching mechanism, (3) copy the copy chain into
memory exclusively owned by the malware. The malware may have to create a global
state to be stored across multiple invocations.
 The memory region which is used to contain the state
must be own exclusively by the malware (so as to not get
overwritten)
RESULTS: Hook is placed on a now infected system
https://3.bp.blogspot.com/MtueiTTzaQQ/UlN8aUdArOI/AAAAAAAACGk/S_qVr8_HOkc/s320/ROP.png
ARCHITECTURE OF PERSISTENT DATAONLY MALWARE – COPY CHAIN
 Copy Chain –
 Invoked every time the hook placed by the initialization chain is triggered
 Saves the values of all general purpose registers in order to be able to restore the
original register values.
 Initially extremely limited gadgets but every register adds functionality.
 Still, the copy chain must execute with interrupts disabled and cannot invoke external
functions.
 Creates a separate dynamic component upon each invocation to create dynamic
control structure.
 Disabling interrupts avoids dynamic components being overwritten but my constrain
the malware’s control structure.
 RESULTS: Values are saved to be restored after the payload has been delivered
ARCHITECTURE OF PERSISTENT DATAONLY MALWARE – DISPATCHER CHAIN
 Dispatcher Chain –
 Required whenever concurrent threads can invoke a hook.
 A dispatcher chain creates an individual process for each process
 Allocates a memory area for each process and copies payload chain
 Creates an individual state for each process
 Guarantees that a specific payload chain will always have access to the same state
area.
 Interrupts must remain disabled while dispatcher is executing.
 RESULT: Each process has a individual persistent state and unique payload
ARCHITECTURE OF PERSISTENT DATAONLY MALWARE – PAYLOAD CHAIN
 Payload chain –
 Contains the functionality of the malware.
 Not affected by rewrites (self-induced or interrupt-induced).
 The malware may, at the payload, invoke any external function and make use of any
register that has been saved by the copy chain.
 The payload chain is a traditional ROP chain and is only limited by the gadgets
provided by the victim’s system.
 RESULTS: The payload must restore the original register values saved by the copy
chain which have been placed into the process state by the dispatcher state. It must
restore the original Stack Pointer.
OUTLINE
 Introduction
 Resident Malware
 Persistent Malware
 Data-only Malware
 Background
 Protection Mechanisms
 ROP (Return-Oriented Programming)
 Data-only Malware
 Hardware Mechanisms of ROP
 Software Mechanisms of ROP
 POC and Discussion
 Summary
ATTACK AND IMPLEMENTATION INITIALIZATION
 POC assumes that the attacker has root privileges but since the attack
requires a vulnerability, it can be loaded without requiring root
privileges.
 The three ROP chains execute and payload is deployed.
 FP is pointed to the initial ROP-chain, which will be loaded into the SP by the leave
instruction.
 The attacker triggers the exploit by executing an int <interrupt>; command. Trigger
of the hook is NOT normally controlled by an attacker but in POC, attacker
controls the FP.
 Memory is allocated for the copy chain and copy chain is copied into memory
INITIALIZATION STAGE
Gains root (or
exploits a
vulnerability)
Leave moves
the current FP
into the SP and
pops the
current value
to the top of
the stack
Trigger the
interrupt
handler by
provoking an
exception
Have the FP
point to the
ROP-chain,
which will be
loaded into the
SP by leave
command.
Memory is
allocated and
address of
state is loaded
into every
location within
copy and
dispatch chain.
Copy Chain is
copied into the
memory area.
Stack switching
mechanism is
triggered and
hooks are set
with the
sysenter
command.
ATTACK AND IMPLEMENTATION –
PERSISTENT STAGE
 Hooks are set and any call to read or getdents call sysenter, which switches the





stack and is independent of hooks for system calls.
Copy chain is activated after the stack is switched. Copy chain saves the state of the
CPU and stores the values of critical registers for future restoration.
Dispatcher chain is copied into memory area and execution is transferred to the
dispatcher chain.
Dispatcher chain obtains the data structure by grabbing the per_cpu data structure.
The dispatcher copies the values of the registers that have been saved by the copy
chain. Then it copies the payload chain into the newly allocated region.
Payload executes the desired functionality (which is a keylogger in the POC). The
rootkit will execute the command and delete data within the buffer or write the
data entered by the user to the kernel log.
Restore registers and return stored values back to the corresponding registers. The
original value of the FP is also restored.
PERSISTENT STAGE
PROTECTION MECHANISMS REVISITED
 Data-only malware is not affected by many protection measures such as
code-signing, code integrity approaches, or many overwrite mechanisms.
 Stack canaries and ASLR must be circumvented but can be bypassed
depending on the vulnerability used for the initialization.
 Stack canaries can be beat by controlling a pointer variable to change data without
having to modify the canary

Can override a pointer to an interrupt handler to defeat ASLR
 The persistent data-only malware does not require the circumvention
of additional security measures.
 Non-persistent and persistent malware are equally likely of a threat.
COUNTERMEASURES
 Function pointer is overwritten to permanently change control flow.
ASLR is a constraint on malware but has its own weaknesses.
 ROP is achieved by looking for inconsistencies on the stack when ret
instruction is executed. It takes a snapshot of the stack and checks
whether the changes are consistent with normal operations.
 Attempt to remove usable ret instructions or encrypt addresses used
for returns or jumps.
 The only protection mechanisms that must be circumvented are exploit
prevention mechanisms such as stack canaries and ASLR.
 Stack Canaries can be defeated by controlling a pointer without modifying the
canary.
 ASLR is defeated by overwriting a pointer to an interrupt handler.
RESIDENCE OF MALWARE
 In order to survive a reboot, the malware must automatically execute
the initialization stage of the malware, which also re-exploits the
malware’s vulnerability.
 The vulnerability must be contained in a program that runs at boot and
must be self-triggering. It must fulfill all requirements for the
initialization step.
 To fulfill all requirements, a multi-stage initialization step may be used. It
is possible that the residence may be achieved by introducing code and
the malware’s persistence is achieved by data-only means.
CONCLUSION
 ROP detection is key to defending against persistent data-only malware.
 Persistent data-only malware permanently changes the control flow of
the host without introducing instructions. It leverages OS and hardware
features to place hooks in software.
 The paper demonstrates that the ROP attack proposed by the paper
can execute a persistent data-only malware that also circumvents
current security mechanisms.
Future Work: new methods for detecting or hindering persistent data-only
malware.
SOURCES
 ”Persistent Data-only Malware: Function Hooks without Code",
H.Sebastian Vogl, Jonas Pfoh, Thomas Kittel, and Claudia Eckert,
Technische University Munchen, 2014.