Under Construction

Migrated to a new hosting company… will take a few weeks to get setup.

Top Maliciously Used APIs

Today I’m going to be discussing the top APIs imported from a large number of confirmed malware samples. This all started out of a curiosity and a lack of research published surrounding the topic. I’m not 100% sure I reached any concrete conclusions after completing this experiment but here are my results and the conclusions I drew.

The Experiment
Download the largest collections of malware that I could find (making sure all samples were unique and confirmed on VirusTotal) then proceed to retrieve the imports of all of the PE files. I ended up with 549,035 PE samples with a final uncompressed size of just over 5TB. Once I retrieved all of my samples (thanks to virusshare.com and my own personal collection) I proceeded to write a multi-threaded python script (yes it was terribly slow) that would retrieve all the imports and count the number of times each sample uniquely imported an API. The script then racked and stacked the results to show which APIs were imported the most.

The Results
There was a final total of 120,126 uniquely imported APIs. A much larger number than I would have predicted. There was a total of 21,043 samples with no imports at all compared to 527,992 samples that did import at least one API. There were a number of interesting findings. I’m attaching a PDF with the all of the imports at the end.

Finding #1
The first result that I found interesting was that only 3.8% of the samples had no imports at all. That means that less than 5% of the files were either packed with no imports, statically included their dlls, or were using their own methods for finding and importing APIs outside of the PE import table. This is fairly interesting and not personally what I’ve seen in the wild.

Top Ten Imported APIs

#1  GetProcAddress		394546
#2  LoadLibraryA		344607
#3  GetModuleHandleA            305054
#4  ExitProcess			301073
#5  VirtualAlloc		244900
#6  WriteFile			223855
#7  GetModuleFileNameA	        221006
#8  CloseHandle			220358
#9  RegCloseKey			213748
#10 VirtualFree			211790

Finding #2
The second and most important result was the top ten imported APIs. If you compare the top ten APIs vs. the remaining imported APIs there’s a significant drop off. I expected some APIs such as WinExec to have a much larger import (one of my personal favorite APIs) but it was only imported 31,943 times, this is a significantly smaller number than the number one import. Even from the number one import to the number three import there is a fairly significant difference. What this tells me is that there is a significant number of malicious files that are dynamically loading their own libraries at run time (good potential for being packed), a very interesting result. Attached is a graph showing the large drop off after GetProcAddress and LoadLibraryA (only top 100 imported APIs are graphed).


Finding #3
One of the most interesting results from this experiment was the large number of APIs imported (120,126). I wasn’t expecting this so I began look through some of the imports to look for any common trends that stuck out. What became clear is that a number of APIs were being imported from 3rd party dll’s. For example av_dup_packet was imported from an audio dll (http://ffmpeg.org/doxygen/0.6/avpacket_8c.html). After some discussion with my friend Matt Weeks (scriptjunkie – website linked below), it’s likely that these APIs are being used to break AntiVirus sandboxes (and potentially malware sandboxes like Cuckoo). Further there are a number of imports that are just aliases to Windows APIs such as vlc_memset (alias to memset). These are two interesting techniques that would work great for evading a heuristic or signature based AV product that’s examining imports. To read more about these techniques I included a link in the Resources section at the bottom.

Finding #4
There were a large number of Windows SystemFunction APIs imported (undocumented Windows APIs). Specifically there were 38 SystemFunction imports, ranging from being imported 122 times to just 10. While this is not unexpected, I did find some of their imports interesting. I expected the largest number of imports to be from function to help with retrieving passwords or hashes from the system but it doesn’t appear that was the case (at least from my knowledge of the methods used to retrieve passwords or hashes from Windows). The most imported SystemFunction was SystemFunction040 which is an alias for RtlEncryptMemory according to the MSDN. More interestingly, SystemFunction006 was the third most imported SystemFunction, this is used in the current version of Mimikatz (Google if you don’t know what Mimikatz does).


There were some remaining imports which struck me as interesting but overall nothing I didn’t expect. For example one file imported an API from the SKIDROW dll. SKIDROW is a notorious cracker group of commercial protection in PC games, I can only imagine what this sample was trying to do.

Feel free to draw your own conclusion from these results, I’d love to hear any thoughts on these findings.

Findings PDF
Attached here are the results of the findings in a PDF. If you’d like the excel file to perform your own analysis on please email me at nullbnx@bnxnet.com.

Malware APIs Results PDF

Virus Share
Paper on AV evasion with APIs
Script Junkie’s Blog

The Windows API for Hackers and Reverse Engineers

The Windows API is one of the “must know” areas for most reverse engineers and exploit writers. It’s an area than the more I use the APIs the more that I find myself looking up speific APIs and wishing that I would have known what I know now about these sometimes vague and/or mysterious functions.

Why should someone who’s in the INFOSEC community care about these APIs? Well to put it shortly, they can make your life considerably easier. If you do incident response, are just getting starting writing exploits, or anything related, then you’ve likely seen these APIs mentioned before. They’re a crucial part of everything from shellcode design to malware analysis.

One of the most common places you’ll run into these APIs is in malware analysis. The Windows APIs are crucial to nearly every piece of software that runs on Windows. Without these APIs malware authors would be left writing a considerable amount more code, which few malware authors want to do. Knowing that these are going to be the malware’s link to Windows itself, just examining the APIs can give you great clues about what the malware is trying to do. (Note: malware authors could statically compile their code, which would not need to import the APIs, this is not common and would leave the malware sample significantly larger)

There are endless tools which will show you which APIs are being imported. Some of the most common tools are OllyDbg, Immunity Debugger, IDA Pro, MASTIFF, and countless other tools and scripts. Let’s take a look at a malware sample’s imports.

kernel32.dll        	DeleteCriticalSection         0x4090dc  
kernel32.dll        	LeaveCriticalSection          0x4090e0  
kernel32.dll        	EnterCriticalSection          0x4090e4  
kernel32.dll        	VirtualFree                   0x4090e8  
kernel32.dll        	LocalFree                     0x4090ec  
kernel32.dll        	GetCurrentThreadId            0x4090f0  
kernel32.dll        	GetStartupInfoA               0x4090f4  
kernel32.dll        	GetCommandLineA               0x4090f8  
kernel32.dll        	FreeLibrary                   0x4090fc  
kernel32.dll        	ExitProcess                   0x409100  
kernel32.dll        	WriteFile                     0x409104  
kernel32.dll        	UnhandledExceptionFilter      0x409108  
kernel32.dll        	RtlUnwind                     0x40910c  
kernel32.dll        	RaiseException                0x409110  
kernel32.dll        	GetStdHandle                  0x409114  
user32.dll          	GetKeyboardType               0x40911c  
user32.dll          	MessageBoxA                   0x409120  
advapi32.dll        	RegQueryValueExA              0x409128  
advapi32.dll        	RegOpenKeyExA                 0x40912c  
advapi32.dll        	RegCloseKey                   0x409130  
kernel32.dll        	TlsSetValue                   0x409138  
kernel32.dll        	TlsGetValue                   0x40913c  
kernel32.dll        	TlsFree                       0x409140  
kernel32.dll        	TlsAlloc                      0x409144  
kernel32.dll        	LocalFree                     0x409148  
kernel32.dll        	LocalAlloc                    0x40914c  
wsock32.dll         	closesocket                   0x409154  
wsock32.dll         	WSACleanup                    0x409158  
wsock32.dll         	recv                          0x40915c  
wsock32.dll         	send                          0x409160  
wsock32.dll         	connect                       0x409164  
wsock32.dll         	htons                         0x409168  
wsock32.dll         	socket                        0x40916c  
wsock32.dll         	WSAStartup                    0x409170  
wsock32.dll         	gethostbyname                 0x409174  
advapi32.dll        	RegSetValueExA                0x40917c  
advapi32.dll        	RegCreateKeyA                 0x409180  
advapi32.dll        	RegCloseKey                   0x409184  
advapi32.dll        	AdjustTokenPrivileges         0x409188  
advapi32.dll        	LookupPrivilegeValueA         0x40918c  
advapi32.dll        	OpenProcessToken              0x409190  
user32.dll          	GetForegroundWindow           0x409198  
user32.dll          	wvsprintfA                    0x40919c  
kernel32.dll        	CloseHandle                   0x4091a4  
kernel32.dll        	RtlMoveMemory                 0x4091a8  
kernel32.dll        	RtlZeroMemory                 0x4091ac  
kernel32.dll        	WriteProcessMemory            0x4091b0  
kernel32.dll        	ReadProcessMemory             0x4091b4  
kernel32.dll        	VirtualProtect                0x4091b8  
kernel32.dll        	Sleep                         0x4091bc  
kernel32.dll        	GetTickCount                  0x4091c0  
kernel32.dll        	MoveFileExA                   0x4091c4  
kernel32.dll        	ReadFile                      0x4091c8  
kernel32.dll        	WriteFile                     0x4091cc  
kernel32.dll        	SetFilePointer                0x4091d0  
kernel32.dll        	FindClose                     0x4091d4  
kernel32.dll        	FindFirstFileA                0x4091d8  
kernel32.dll        	DeleteFileA                   0x4091dc  
kernel32.dll        	CreateFileA                   0x4091e0  
kernel32.dll        	GetPrivateProfileIntA         0x4091e4  
kernel32.dll        	GetPrivateProfileStringA      0x4091e8  
kernel32.dll        	WritePrivateProfileStringA    0x4091ec  
kernel32.dll        	SetFileAttributesA            0x4091f0  
kernel32.dll        	GetCurrentProcessId           0x4091f4  
kernel32.dll        	GetCurrentProcess             0x4091f8  
kernel32.dll        	Process32Next                 0x4091fc  
kernel32.dll        	Process32First                0x409200  
kernel32.dll        	Module32Next                  0x409204  
kernel32.dll        	Module32First                 0x409208  
kernel32.dll        	CreateToolhelp32Snapshot      0x40920c  
kernel32.dll        	WinExec                       0x409210  
kernel32.dll        	lstrcpyA                      0x409214  
kernel32.dll        	lstrcatA                      0x409218  
kernel32.dll        	lstrcmpiA                     0x40921c  
kernel32.dll        	lstrcmpA                      0x409220  
kernel32.dll        	lstrlenA                      0x409224  
kernel32.dll        	lstrlenA                      0x40922c  
kernel32.dll        	lstrcpyA                      0x409230  
kernel32.dll        	lstrcmpiA                     0x409234  
kernel32.dll        	lstrcmpA                      0x409238  
kernel32.dll        	lstrcatA                      0x40923c  
kernel32.dll        	WriteProcessMemory            0x409240  
kernel32.dll        	VirtualProtect                0x409244  
kernel32.dll        	TerminateThread               0x409248  
kernel32.dll        	TerminateProcess              0x40924c  
kernel32.dll        	Sleep                         0x409250  
kernel32.dll        	OpenProcess                   0x409254  
kernel32.dll        	GetWindowsDirectoryA          0x409258  
kernel32.dll        	GetTickCount                  0x40925c  
kernel32.dll        	GetSystemDirectoryA           0x409260  
kernel32.dll        	GetModuleHandleA              0x409264  
kernel32.dll        	GetCurrentProcessId           0x409268  
kernel32.dll        	GetCurrentProcess             0x40926c  
kernel32.dll        	GetComputerNameA              0x409270  
kernel32.dll        	ExitProcess                   0x409274  
kernel32.dll        	CreateThread                  0x409278  
user32.dll          	wvsprintfA                    0x409280  
user32.dll          	UnhookWindowsHookEx           0x409284  
user32.dll          	SetWindowsHookExA             0x409288  
user32.dll          	GetWindowThreadProcessId      0x40928c  
user32.dll          	GetWindowTextA                0x409290  
user32.dll          	GetForegroundWindow           0x409294  
user32.dll          	GetClassNameA                 0x409298  
user32.dll          	CallNextHookEx                0x40929c

Looking over these imported API functions may at first seem useless to the untrained analyst. However, if you begin to dissect what some of the APIs can be used for you can begin to make assumptions about the function of this malware. For example GetTickCount is a very common API for detecting debuggers. AdjustTokenPrivileges and LookupPrivilegeValueA are both commonly used in accessing the Windows security tokens. RegSetValueExA, RegCreateKeyA, and RegCloseKey are used when accessing and altering a registry key. Taking just these APIs into consideration you could begin to make some interesting hypothesis about the capabilities of this specific sample.

I’ve noticed that analysts who don’t totally understand these API function will typically ignore them. For that fact I’m creating a “cheat sheet” for the Windows API functions. The “pre-final” release is attached below.

Please don’t forget that Microsoft did not build these APIs for malicious use and are very commonly used by Windows programmers (unless it’s an undocumented API). Thus analyzing just the imported APIs may not tell you if a sample is malicious or not (but is very useful if you already know a sample is malicious).

Over the past month I’ve also been working on analyzing what is now over 5TB of malware to gather the most frequently used Windows APIs. This data will likely continue to process for close to another month. Once this is done I’ll work on completing this cheat sheet based on those findings and write another post about my discoveries. Keeping that in mind this list is not final and if you have any feedback, comments, questions, or recommendations please make them!

In the course of developing the current list I used multiple resources, I’d just like to highlight a few. These are also great resources if you’re looking to learn more.

Practical Malware Analysis – great book on reverse engineering malware
MSDN – where to go if you’re curious about a specific Windows API
Windows PE File Details – Great article that describes the fundamentals of the PE file and more details surrounding PE file imports

Cheat Sheet Version .5 :


Offensive Security Cracking the Perimeter (CTP) Review

Summary : Great Offensive Security Course & Certification — Just make sure you’re prepared!


Before I start diving into this review I should start by saying I did have a background in writing exploits and Reverse Engineering before I got into Cracking the Permitter (CTP). While this didn’t necessarily help me in every aspect, my knowledge of x86 Assembly definitely did. This influences my perspective on the course.

This is definitely one of those courses you need some sort of background before starting. Completing the OSCP is a great start. I highly recommend knowing x86 Assembly at least on some basic level, have an understanding of the Windows API, and have a background in web applications (php, etc). The more of a background you have the easier the course will be. I believe one of the reasons for the high failure rates on the certification is due to the fact that people don’t have the background required (it’s hard to learn the things I mentioned and the course material at the same time).


This course is focused on the code side of exploitation. You’re working to find bugs at the code level and then take advantage of them (rather than depend on a bug someone else found and using their exploit). You spend your time looking for web vulnerabilities (php, etc) and windows application vulnerabilities (x86). This course picks up where PWB (see this review) left off. The web vulnerabilities you work on in the course range from cross site scripting to remote and local file inclusions.

The majority of the course is focused on Windows exploit development and discovery (fuzzing). This ranges from simple SEH overwrites to more complicated scenarios (encoding, bad characters, small space for shellcode, etc). Offsec does a good job of keeping the course material interesting by throwing a variety of situations at you.

The only complaint I had about the material is that some of it is dated. For example there is some dated material on Anti Virus avoidance. Most of these techniques don’t work today with modern AV. It does however challenge you to think about new and innovative ways to evade AV. This course also doesn’t go into any details about the latest exploit techniques (ROP, heap spraying, etc). These techniques are covered in Offsec’s Advanced Windows Exploitation. Personally it makes sense, there’s a lot to be covered in this course and you need to be proficient in intermediate exploits before moving to more advanced (walking before you run).

Of course the exam is hard. Offsec’s courses are some of the only IT security courses that force you to exhibit true mastery of the material. I’ve found that no matter how prepared you are for the course you’ll still end up learning a lot in the exam. I was lucky enough to pass the exam on the first attempt. I would challenge everyone to take the exam and continue to do so until you pass!

Offsec Courses in General:

Aside from this specific course it’s worth mentioning the overall value of Offsec’s courses and certifications. In today’s over saturated market of mostly useless certifications there are a few that stand out. Offsec’s courses are one of the companies out there that have put together extremely high quality material that translates into real world knowledge and application. I’m not saying you’ll be an expert after one of Offsec’s courses but you will have a solid foundation in the material.

People are often curious about what certifications you should take to further your abilities in IT security and/or push yourself to learn something new and challenging. My answer is almost always an Offsec certification. One of the best parts about their courses is that they don’t just give you material and expect you to memorize it. The Offsec team specifically forces you to learn how to use and put the course material into action. They also force you to take it further, much the same approach that a security researcher does. Then they give you an exam, which some consider quite challenging, which only continues to force you to “Try Harder”.

If you plan on reciting facts about IT security, take a random certification, if you want to actually practice IT security, take an Offsec course.

Corelan Tutorials
The Gray Corner Vulnserver Tutorials

Malware in the Clouds – EverRat

In my day to day work I primarily focus on defensive cyber and countering the advanced actors. Thus I find myself dreaming about what the next major threats will look like. With today’s defensive posture on most networks it’s pretty clear that getting malicious code on a target machine isn’t normally that hard. Short of a few defensive techniques (i.e. whitelisting) the infections keep happening and corporations rely on the network sensors to detect and block connections back to the malware’s communications channels. For this posting I’m going to assume that this is true (assume powershell or some executable not on any anti-virus list is used against the host).

Assuming that, let’s look at some of the current public malware C2 methods.

Current State of Malware C2

Web C2 –

Most of the “everyday” malware has been using this for years. There have been evolutions from imbedded data in the website, only using https connections, and also the newer watering hole attacks. These techniques can be varied but if the malware is calling out to any sort of hard coded domain, these connections usually are easy to detect, monitor, and block.


At Defcon 19 Itzik Kotler and Iftach Ian Amit gave a talk about creating a VOIP based bonnet. This idea helped motivate me in my work. However there are a number of problems with VOIP based connections. Does the network allow VOIP connections in and out, how are their VOIP services configured, etc? A VOIP controlled botnet is more complicated and can often be unreliable. This technique hasn’t really been seen in the wild. For more information check out their talk at the link listed.


Myspace/Twitter –

Over the years there have been multiple implementations of using social networking sites for C2. These are great from the fact that they are usually not blocked at the network level. They also generate a lot of traffic on a daily basis so a large number of connections during the work day would not stand out for more advanced traffic analysis. The problems lie with the social networking sites. It can be difficult for the malware author to transfer a lot of data and conceal what they are doing from the public (i.e. twitter feed being viewable) and from the site’s security admins themselves. If detected it also becomes very easy for Twitter/Myspace/Facebook to disable the accounts.


This has been been a classic C2 method for a number of years. There have been numerous implementations of this technique. They are traditionally fairly complicated. The major problem of DNS C2 is that to not be detected you have to be very slow. A large amount of DNS activity to a specific domain is very apparent and not normal in a network. The speed here can cause major issues if you’re trying to upload or download from a target host.

IPV6 –

If you were to design an advanced C2 method that has nearly no way of detection currently, IPV6 is the way to go. The problem for network defenders is that IPV6 is currently turned on out of the box for most host and network appliances. The even bigger problem for network defenders is that there currently aren’t very many products that support network monitoring on IPV6 (and nearly no legacy systems support it). If the targeted organization has left IPV6 on then an attacker has the perfect C2 method. I may research more about IPV6 C2 channels in the future, as it’s a great C2 method.

Gmail C2 –

A few months back when I started investigating advanced malware C2 I found a piece of malware on contagio (link below). I was pointed to this malware by scriptjunkie (www.scriptjunkie.us). After doing a full reversing of the malware (can share IDA notes if anyone is curious), it became clear that this malware was using Gmail for it’s C2. What stood out was it wasn’t trying to hide anything. This is interesting because the malware itself is advanced and the technique had not been seen before. As indicated on contagio you can just run strings to get the credentials for the gmail account. This tells me that this malware technique was only being tested or very targeted, as most advanced malware uses some sort of encoding or encryption. Aside from this specific malware sample, this C2 method poses two major problems. One is managing the email account to use it effectively as a C2 node and the other is Google itself. Google is very good at finding and tracking advanced threats, thus once the email address was identified the account was quickly shutdown.


All of these techniques have their plusses and minuses. During the research of these techniques an even better C2 method quickly came to mind. Why not use some of the cloud storage services?

Cloud Based Malware/Botnets

There are a number of benefits of using cloud-based storage for malware C2. The first is most networks openly allow these services. They’re regularly used and sometimes are a core part of the company’s processes. Next is the open API model most of these services have. If you look the Dropbox, Evernote, etc API they are incredibly easy to use. Most include sample scripts and show you how to get started. The third great part about these services is that the APIs already integrate SSL (Oauth2 is pretty standard). Perfect for a covert channel. Lastly and obviously, these services were built for downloading and uploading large amounts of data. This is great for interacting with a target.

While researching I tried to find if anyone had written about this previously. I found a few discussions with network admins trying to decide whether or not to allow these services on their networks. Here’s some screenshots of what I found.




All this information led me to developing EverRat.


About six months ago I started developing EverRat. I wrote EverRat in python to make it platform independent. I didn’t want to write anything likely to be used by malware authors against organizations so I only added basic features to prove the feasibility of this C2 method. It uses Evernote note’s to communicate. At the network level it looks no different than a standard Evernote connection.

Here’s a brief video showing the RAT working.

This should clearly illustrate the problem to network defenders.

The most complicated code in the script is the synchronization methods. After these issues were resolved it’s quite easy to add features. Due to the robust APIs the executable or script is quite small. To make this even better for a pentesting scenario it would be awesome to switch this over to powershell and perhaps integrate with @Obscuresec’s powershell bot (http://www.obscuresecurity.blogspot.com/2013/02/shmoocon-firetalks-and-epilogue.html).

If someone wants a copy of the code please email me at nullbnx@bnxnet.com. I’m not posting the code because I don’t want this used by anyone other than pentesters. I have also stopped work on this code as it was just a research project.


These threats are not likely go away. As cloud based storage becomes more and more popular it’s safe to assume that advanced threats may start moving more and more to techniques like EverRat.

When I began working on this research project I was planning on giving this as a talk at a security conference. Instead I gave it as a brief talk at the San Antonio Hackers Association. This was largely due to the fact that a few weeks ago (months after I started my research) the first sample was published that was utilizing the exact techniques I was researching. The link is below.


This is just the start of a new generation of malware C2, we need to start planning on how to best defend against it!

Note: This is for educational purposes only. This does NOT illustrate any vulnerability with Evernote (or any mentioned cloud storage services). If Evernote, Dropbox or any other cloud based storage service would like details on how they might be able to fight malicious users from using their services in future malware please contact me at nullbnx@bnxnet.com.