Search the Community

Cum as putea sa vad modulele importate de un executabil intr-un mod automat si rapid a unui executabil windows? Am niste fisiere/executabile care in fisier raw nu are importate anumite dll-uri pe care le folosesti si am nevoie sa stiu ce dll-uri sau functii de winapi foloseste in executia lui; Se poate vedea asta intr-o anumita masura si sa se poata face asta intr-un mod automat(gen script python sau commandline tool)? Pana acum am gasit dependency walker dar nu pare sa pot automatiza procesul si dureaza un pic pana obtin lista de dll-uri, respectiv listdlls de la sysinternals, dar e pentru procese care ruleaza deja, nu pentru fisiere/executabile statice

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). top100apis 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 (FFmpeg: libavcodec/avpacket.c File Reference). 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 Resources Virus Share Paper on AV evasion with APIs MSDN Script Junkie’s Blog Source : https://www.bnxnet.com/top-maliciously-used-apis/