Create your own awesome maps

Even on the go

with our free apps for iPhone, iPad and Android

Get Started

Already have an account?
Log In

Malware by Mind Map: Malware
5.0 stars - 4 reviews range from 0 to 5

Malware

Spreading mechanism

sequentiell

random

hitlist

via special searchengine terms

predefined list of (favorite) targets

Debugging

Breakpoints

3 different types, Soft BP, most common, replaces first byte of original instruction, original byte must be stored in table, single bye interrupt 3 instruction (0xCC), 2 different types, one-shot soft bp, int3 gets replaced by stored byte, persistent bp, int3 is restored after execution of original byte, drawbacks, calculations based on program code will fail, CRC is changed, some malware or programs check if the crc is correct, breakpoint will not be hit if program overwrites parts of itself, Hardware BP, done at CPU level via registers, DR0 - DR3, addresses of breakpoints, DR4 - DR5, reserved, DR6, status register; determines type of debugging event triggered when hit, DR7, on/off switch, stores breakpoint conditions, break on execution, break on write, break on read or write (not exec), raises interrupt 1 (like single stepping), limitations, only 4 BPs at a time, max 4 bytes of data per BP, Memory BP, not really BPs, just changes page permissions, set guard page flag for memory page, results in exception and process halting on hit, also used to ensure memory doesn't grow above boundaries and heap-stack seperation, the program code isn't changed, doesn't affect CRC checks and the like

halting process to inspect variables, stack and memory

Stack

LIFO structure

grows from high memory addresses to low

Registers

General Purpose, EAX, accumulator register, holds function return values, used for performing calculations, EDX, data register, extension for EAX, used for example for multiplication or division, ECX, count register, used for loops, always counts downward, ESI, source index, location of input data stream, loops processing data, EDI, destination index, location of output data stream, ESP, stack pointer, top of the stack, EBP, base pointer, bottom of the stack, EBX, nothing specific, extra storage

EIP, instruction pointer, points to current instruction being executed

Rootkits

stealth

trying to ring no bells so that a real forensic analysis is never applied

a rootkit is a set of programs and code that allows a permanent or consistent, undetectable presence on a computer

2 primary functions

remote command and control, control over files, command shell, general system access and control like reboots

software eavesdropping, sniffing packets, intercepting keystrokes, reading mails/documents, capture passwords, gain cryptokeys

rootkits usually use deifferent modification methods

patching, replacing parts of binaries to change their behaviour

source-code modifications, built in hidden backdoor by developer, may be disguised as a bug

spyware modifications, e.g. hooking into existing programs

Vulnerability Classes

Buffer Overflows

Stack Overflows, caused by neglect to perform bounds checking on incoming data, stack variables have fixed size, cuz compiler preallocates space in machine code, preallocates max expected data, problem, how to determine correct return address to injected code, each run stack allocated in same place, padding with NOPs, spraying the stack?, possibilities to overtake process, overwriting return address, change function pointers, change execution chain of exception handlers, automated finding, 1. search for large stack frames, 2. find where pointer is used, 3. make sure access is aware of the size, protection, using a stack canary, placing a cookie of random value between return address and variables, it's possible to circumvent by taking over the program before reaches the canary check, nonexecutable memory, define memory pages to only store data and not being executable to the processor, can be overcome, most popular "return-to-libc", return address points to well-known function, which is provided with parameters to enable the attacker gaining control

Heap Overflows, same idea as stack overflow, copying data into too small buffers, may also cause a takeover of the system, utilize linked list to overwrite memory in process's address space, less common than stack overflow, heap blocks have dynamic sizes, therefore aren't handled wrong that frequently, heap is usually organized as a linked list, entries store pointers to next and prev entries, main problem: miscalculation of buffer size, possibility to overwrite data structures of adjacent heap blocks, variables, function pointer, security tokens, any important data structure stored in heap, detection, program notices not until affected heap blocks are accessed by the program, e.g. windows allows developers to activate heap verification, keeps track of dynamic heap operations and breaks instantly on heap corruption

Integer Overflows

result from incorrect treatment of integers

can lead to buffer overflows

safe integer checking is not as trivial as it seems, signedness, JG indicates signed integer comparison, JA indicates unsigned integer comparison, signed buffer length variables make no sense, there is nothing as a negative buffer, functions with buffer size can't use signed int, signed int will be treated as very large int, arithmetic operations, arithmetics with user supplied length, e.g. adding header size preceding user buffer in new buffer, overflown integer will be truncated by processor, resulting in small int, if size of buffer is used to copy data into the new buffer created with overflown int, the new buffer will be overflown, solution, use variable type that is definitely able to hold largest possible result of arithmetics

Type Conversion Errors

occurs on mishandling of incoming data types and incorrect conversions on them

in C(++) signed will be converted to larger data type as signed no matter what target data type is, called signed extending

solution, usage of signed and unsigned integers consistently

Format String Attacks

%n enables to write data to memory

%s enables to read memory until a NULL byte is hit

Exploit Counter Measures

detect memory corruption

GS, Guard Stack, stack cookies/canaries, see Stack Overflows

SEH chain validation

heap corruption detection

stop common exploitation patterns

ASLR, Address Space Layout Randomization, Stack, Heap, images?, special structures like TEB and PEB on windows, the attacker cannot know where exactly stuff is

DEP, Data Execute Prevention, NX bit, tells processor which memory isn't executable

SafeSEH, Safe Structured Exception Handler, Exception function is checked if registered in function table in application

Anti-Reversing Methods

virtual machine detection

changed system behaviour in virtualised environment, nonvirtualizabel instructions, popf instruction, unpriviliged changes ALU flags, priviliged changes ALU AND system flags, resource discrepancies, TLB (translation look-aside buffer), measure size before and after VMM invocation, in VMM TLB will appear smaller afterwards, timing discrepancies, latency of any two operations may change over time, resources (like a pci device register) may be available in only a single cycle instead of maybe hundreds cuz of caching

virtual devices may leak information of being in virtual environment, name of driver/manufacturer, values set in device, mac address of network card registered to VM product or unregistered at all, BIOS versions

some VMs have I/O backdoors to communicate with outside

failures in exactly implementing cpu behaviour, easter eggs, using CPUID with EAX 0x8FFFFFFF on AMD K8 returns IT'S HAMMER TIME in EBX, ECX and EDX

debugger detection

often platform or debugger specific

IsDebuggerPresent API in PEB, SystemKernelDebuggerInformation for kernel debuggers

check if exceptions are "swallowed"

code checksums, code is changed when soft breakpoints are set

anti-debugger code

perform operations that would somehow damage or disable a debugger

software breakpoint detection

hardware breakpoint detection

?

anti-disassembler tricks

linear sweep disassembler traverse code from top to bottom

recursive traversal take jumps into account when disassembling, opaque predicates, filling junk bytes in nonreachable branches

eliminating symbolic information

bytecode programs usually contain many textual informations from the source code

export all functions by ordinals rather than name

obfuscation

control flow transformations, inserting opaque predicates, one branch is never reached, table interpretation, break code sequence into multiple short chunks, loop through conditional code sequence that decides to jump to which chunk, inlining functions, outlining, create new function for code sequence, interleaving code, split functions into segments and interleave them with opaque predicates, ordering transformations, randomly reorder non-codependent operations to confuse the reverser

data transformations, modifying variable encoding, e.g. shifting loop counter variables all one bit to the left, can this be done in automated fashion?, restructuring arrays, modify arrays preserving functionality but confuse reverser, merge several arrays to one, split up array into several

packing/encrypting code

creates another hurdle for reverser needing to first decrypt or unpack program

Malware Analysis

automated malware must be analyzed in an automated fashion to keep up

3 criteria

automatically, no user intervention needed, generating detailed analysis report, machine readable report may be used to initiate automated repsonse procedures like new IDS signatures, techniques, static analysis, dynamic analysis

effectively, all relevant behaviour must be logged, no executed functionality of malware should be overlooked, techniques, API hooking, calls to system API is rerouted and monitored before really called or even omitted, all interaction with system must somehow use this API and is therefore logged, except an API call is not hooked, can be avoided if directly calling kernel code, uncommon in todays malware, needs to know exact os version, sp level and other information and act accordingly, usually automated spreading malware is designed to target a large user base, therefore commonly uses the windows API, several ways of implementation, inline code overwriting, one of the most effective and efficient methods, function code is overwritten directly in process memory, 5 steps to inlince code overwriting, 1. applications is created in suspend mode, loads and initializes application all implicitly linked DLLs, 2. hooked functions code entry points looked up in ExportAddressTable, 3. overwritten bytes are stored and a stub is constructed to perform the overwritten operations and JMP back to the rest of the function code, 4. function code overwritten by JMP or CALL to hooking function, 5. functions enabling loading DLLs dynamically at runtime must be hooked, perform same overwrite as above before calling application can use them, (LoadLibrary and LoadLibraryEx), may be detected by looking for typical redirection pattern in core API functions, function pointer rewriting, change the ImportAddressTable to point used API functions to hooking functions, not considered API hooking, too low level, System Service Hooking, performs hooking on lower level in OS, IDT modification, hooks the interrupt 0x2e, SSDT modification, intercepts syscalls depending on service IDs, almost all syscalls are found in Native API (ntdll.dll), implementation of Native API changes frequently between Windows versions, implementation and interface of regular Windows APIs is almost constant, therefore most user applications use this API, to perform operations on system resources process has to switch from usermode (Ring 3) to kernelmode (Ring 0), transfer to kernelmode is initialized by interrupt 0x2e on Windows, control is transfered to ntoskrnl.exe (core of Windows OS), 0x2e is sysenter on intel and syscall on AMD processors, to set up hooks special process must write in malware processes memory or start new thread in malware process doing it, often DLL injection, vm inspection, doesn't need to change anything in the system directly, everything is monitored by instructed behaviour of vm

correctly, all logged actions have to be initiated by malware sample, techniques, DLL code injection, allows modular and reusable API hooking, special DLL target process is directed to load, actions on DLLs initialization, custom hook functions are loaded into the targets address space, API hooks are installed

relevant system behaviour

file creation and modification

registry modifications

loaded DLLs

virtual memory access

created processes

network connections, destinations, contents

2 approaches

code analysis, static analysis, source/machine code is analysed in contrast to analysing the behaviour, therefore all possible executions of malware can be analysed, even hidden actions only triggered under certain circumstances, source code usually not available, binary itself might have been modified after compilation, especially for machine code analysis is very cumbersome, sometimes decompilation is possible, higher level program can usually be easier understood and faster analysed, malware uses code obfuscation techniques to evade decompilation and analysis, compression, encryption, self-modification, usage of packers or crypters, makes reverse engineering harder, can be very time consuming to unpack binary before real analysis, try to fool disassemblers, e.g. not aligned code with garbage in between, sometimes ASCII or UNICODE strings contained in binary reveal functionality and/or insight into MW, imported libraries and functions disclose included functionality

behaviour analysis, dynamic analysis, execution in simulated/sandboxed environment, malware is treated as black box, result is not necessarily complete, allows only to analyse what is done on execution, functions only triggered under certain conditions will stay undiscovered, is similar to HP anlysis, execute binary in instrumented environment doing data control and analysis to learn about it, similar to hi interaction HPs executing malware may affect other systems, restrictions must be placed at execution environment, 2 approaches, taking system image prior and after execution, easier to implement, more coarse grained results, sometimes sufficient, only analyses cumulative effects, doesn't contain dynamic changes, temporary files or process, general intermediate steps, may not notice changes if hidden properly e.g. by a rootkit, monitoring all actions during execution, utilizing debuggers and/or special tools, harder to implement, more detailed results, completely automated process, if more information is needed manual code analysis can be done afterwards

hashing of binaries can be used for unique sample identification

malware countering AV approach, polymorhpism, encrypting or xoring program with changing keys, therefore changing also signature and hash, metamorphism, change whole program without changing programs behaviour

using virtual environment

system can be easily brought back into clean state

drawbacks, detectable, slower execution

same procedure applied to original process must be applied to all subsequently started processes