Get Started. It's Free
or sign up with your email address
Rocket clouds
Malware by Mind Map: Malware

1. Spreading mechanism

1.1. sequentiell

1.2. random

1.3. hitlist

1.3.1. via special searchengine terms

1.3.2. predefined list of (favorite) targets

2. Debugging

2.1. Breakpoints

2.1.1. 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 drawbacks Hardware BP done at CPU level via registers raises interrupt 1 (like single stepping) limitations Memory BP not really BPs, just changes page permissions set guard page flag for memory page the program code isn't changed

2.1.2. halting process to inspect variables, stack and memory

2.2. Stack

2.2.1. LIFO structure

2.2.2. grows from high memory addresses to low

2.3. Registers

2.3.1. General Purpose EAX accumulator register EDX data register ECX count register ESI source index EDI destination index ESP stack pointer EBP base pointer EBX nothing specific extra storage

2.3.2. EIP instruction pointer points to current instruction being executed

3. Rootkits

3.1. stealth

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

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

3.3. 2 primary functions

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

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

3.4. rootkits usually use deifferent modification methods

3.4.1. patching replacing parts of binaries to change their behaviour

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

3.4.3. spyware modifications e.g. hooking into existing programs

4. Vulnerability Classes

4.1. Buffer Overflows

4.1.1. 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 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 nonexecutable memory

4.1.2. 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 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

4.2. Integer Overflows

4.2.1. result from incorrect treatment of integers

4.2.2. can lead to buffer overflows

4.2.3. 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 functions with buffer size can't use signed int arithmetic operations arithmetics with user supplied length overflown integer will be truncated by processor if size of buffer is used to copy data into the new buffer created with overflown int, the new buffer will be overflown solution

4.3. Type Conversion Errors

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

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

4.3.3. solution usage of signed and unsigned integers consistently

4.4. Format String Attacks

4.4.1. %n enables to write data to memory

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

5. Exploit Counter Measures

5.1. detect memory corruption

5.1.1. GS Guard Stack stack cookies/canaries

5.1.2. SEH chain validation

5.1.3. heap corruption detection

5.2. stop common exploitation patterns

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

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

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

6. Anti-Reversing Methods

6.1. virtual machine detection

6.1.1. changed system behaviour in virtualised environment nonvirtualizabel instructions popf instruction resource discrepancies TLB (translation look-aside buffer) 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

6.1.2. 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

6.1.3. some VMs have I/O backdoors to communicate with outside

6.1.4. 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

6.2. debugger detection

6.2.1. often platform or debugger specific

6.2.2. IsDebuggerPresent API in PEB SystemKernelDebuggerInformation for kernel debuggers

6.2.3. check if exceptions are "swallowed"

6.2.4. code checksums code is changed when soft breakpoints are set

6.3. anti-debugger code

6.3.1. perform operations that would somehow damage or disable a debugger

6.4. software breakpoint detection

6.5. hardware breakpoint detection

6.5.1. ?

6.6. anti-disassembler tricks

6.6.1. linear sweep disassembler traverse code from top to bottom

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

6.7. eliminating symbolic information

6.7.1. bytecode programs usually contain many textual informations from the source code

6.7.2. export all functions by ordinals rather than name

6.8. obfuscation

6.8.1. control flow transformations inserting opaque predicates one branch is never reached table interpretation break code sequence into multiple short chunks 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

6.8.2. data transformations modifying variable encoding e.g. shifting loop counter variables all one bit to the left restructuring arrays modify arrays preserving functionality but confuse reverser merge several arrays to one split up array into several

6.9. packing/encrypting code

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

7. Malware Analysis

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

7.2. 3 criteria

7.2.1. 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

7.2.2. effectively all relevant behaviour must be logged no executed functionality of malware should be overlooked techniques API hooking vm inspection

7.2.3. correctly all logged actions have to be initiated by malware sample techniques DLL code injection

7.3. relevant system behaviour

7.3.1. file creation and modification

7.3.2. registry modifications

7.3.3. loaded DLLs

7.3.4. virtual memory access

7.3.5. created processes

7.3.6. network connections destinations contents

7.4. 2 approaches

7.4.1. code analysis static analysis source/machine code is analysed in contrast to analysing the behaviour sometimes ASCII or UNICODE strings contained in binary reveal functionality and/or insight into MW imported libraries and functions disclose included functionality

7.4.2. behaviour analysis dynamic analysis execution in simulated/sandboxed environment malware is treated as black box is similar to HP anlysis similar to hi interaction HPs executing malware may affect other systems 2 approaches completely automated process

7.5. hashing of binaries can be used for unique sample identification

7.5.1. 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

7.6. using virtual environment

7.6.1. system can be easily brought back into clean state

7.6.2. drawbacks detectable slower execution

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