{
	"id": "c288f05f-5e99-494f-9005-eebce153a175",
	"created_at": "2026-04-06T00:10:53.958835Z",
	"updated_at": "2026-04-10T13:13:01.802815Z",
	"deleted_at": null,
	"sha1_hash": "36fc6b2d55cb4b2cb9ecd5f37892ff5297f85f66",
	"title": "Analyzing malware by API calls",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 702716,
	"plain_text": "Analyzing malware by API calls\r\nBy Pieter Arntz\r\nPublished: 2017-10-30 · Archived: 2026-04-05 18:40:13 UTC\r\nOver the last quarter, we’ve seen an increase in malware using packers, crypters, and protectors—all methods used\r\nto obfuscate malicious code from systems or programs attempting to identify it. These packers make it very hard,\r\nor next to impossible to perform static analysis. The growing number of malware authors using these protective\r\npackers has triggered an interest in alternative methods for malware analysis.\r\nLooking at API calls, or commands in the code that tell systems to perform certain operations, is one of those\r\nmethods. Rather than trying to reverse engineer a protectively packed file, we use a dynamic analysis based on the\r\nperformed API calls to figure out what a certain file might be designed to do. We can determine whether a file\r\nmay be malicious by its API calls, some of which are typical for certain types for malware. For example, a typical\r\ndownloader API is URLDownloadToFile. The API GetWindowDC is typical for the screen-grabbers we\r\nsometimes see in spyware and keyloggers.\r\nLet’s look at an example to clarify how this might be helpful.\r\nTrojan example\r\nOur example is a well-known Trojan called 1.exe with\r\nSHA256 0213b36ee85a301b88c26e180f821104d5371410ab4390803eaa39fac1553c4c\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/10/analyzing-malware-by-api-calls/\r\nPage 1 of 5\n\nThe file is packed (with VMProtect), so my disassembler doesn’t really know where to start. Since I’m no expert\r\nin reverse engineering, I will try to figure out what the file does by looking at the API calls performed during the\r\nsandboxed execution of the file.\r\nArticle continues below this ad.\r\nThis is the list of calls that we got from the sandbox (Deepviz):\r\nFor starters, let’s have a look at what all these functions do. Here’s what I found out about them on Microsoft:\r\nGetModuleHandle function\r\nRetrieves a module handle for the specified module. The module must have been loaded by the calling process.\r\nGetModuleHandleA (ANSI)\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/10/analyzing-malware-by-api-calls/\r\nPage 2 of 5\n\nGetProcAddress function\r\nRetrieves the address of an exported function or variable from the specified dynamic-link library (DLL).\r\n_wtoi\r\nConvert a string to integer.\r\nCreateStreamOnHGlobal function\r\nThis function creates a stream object that uses an HGLOBAL memory handle to store the stream contents.  This\r\nobject is the OLE-provided implementation of the IStream interface.\r\nStrStr function\r\nFinds the first occurrence of a substring within a string. The comparison is case-sensitive. StrStrA (ANSI)\r\nwsprintf function\r\nWrites formatted data to the specified buffer. Any arguments are converted and copied to the output buffer\r\naccording to the corresponding format specification in the format string. wsprintfA (ANSI)\r\nWinHttpOpen function\r\nThis function initializes, for an application, the use of WinHTTP functions and returns a WinHTTP-session\r\nhandle.\r\nGetModuleFileName function\r\nRetrieves the fully qualified path for the file that contains the specified module. The module must have been\r\nloaded by the current process. GetModuleFileNameW (Unicode)\r\nLoadLibrary function\r\nLoads the specified module into the address space of the calling process. The specified module may cause other\r\nmodules to be loaded. LoadLibraryA (ANSI)\r\nLocalAlloc function\r\nAllocates the specified number of bytes from the heap.\r\nLocalFree function\r\nFrees the specified local memory object and invalidates its handle.\r\nGetModuleFileName function\r\nRetrieves the fully qualified path for the file that contains the specified module. The module must have been\r\nloaded by the current process. GetModuleFileNameA (ANSI)\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/10/analyzing-malware-by-api-calls/\r\nPage 3 of 5\n\nExitProcess function\r\nEnds the calling process and all its threads.\r\nThe key malicious indicators\r\nNot all of the functions shown above are indicative of the nature of an executable. But the API WinHttpOpen tells\r\nus that we can expect something in that area.\r\nFollowing up on this function, we used URL Revealer by Kahu Security to check the destination of the traffic and\r\nfound two URLs that were contacted over and over again.\r\nGET http://twitter.com/pidoras6\r\nPOST http://www.virustotal.com/vtapi/v2/file/scan\r\nThis POST is what the VirusTotal API expects when you want to submit a file for a scan.\r\nThe link to an old and abandoned Twitter handle was a bigger mystery, until I decided to use the Advanced Search\r\nin Twitter and found this Tweet that must have been removed later on.\r\nIn base64, this Tweet says: https://w0rm.in/join/join.php. Unfortunately that site no longer resolves, but it used to\r\nbe an underground board where website exploits were offered along with website hacking services around the\r\nsame time the aforementioned Twitter profile was active.\r\nThis was a dead end on trying to figure out what the malware was trying to GET. So we tried another approach by\r\nfiguring out what it was trying to scan at VirusTotal and used Wireshark to take a look at the packets.\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/10/analyzing-malware-by-api-calls/\r\nPage 4 of 5\n\nIn the packet, you can see the API key and the filename that were used to scan a file at the VirusTotal site. So,\r\nreconstructing from the API calls and from the packets we learned that the malware was submitting copies of itself\r\nto VirusTotal, which is typical behavior for the Vflooder family of Trojans. Vflooder is a special kind of Flooder\r\nTrojan. Flooder Trojans are designed to send a lot of information to a specific target to disrupt the normal\r\noperations of the target. But I doubt this one was ever able to make a dent in the VirusTotal infrastructure. Or the\r\none on Twitter for that matter.\r\nThe Vflooder Trojan is just a small and relatively simple example of analyzing API calls. It’s not always that easy:\r\nWe’ve even seen malware that added redundant/useless API calls just to obfuscate the flow. But analyzing API\r\ncalls is a method to consider for detecting malware trying to hide itself. Just keep in mind that the bad guys are\r\naware of it too.\r\nSource: https://blog.malwarebytes.com/threat-analysis/2017/10/analyzing-malware-by-api-calls/\r\nhttps://blog.malwarebytes.com/threat-analysis/2017/10/analyzing-malware-by-api-calls/\r\nPage 5 of 5",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://blog.malwarebytes.com/threat-analysis/2017/10/analyzing-malware-by-api-calls/"
	],
	"report_names": [
		"analyzing-malware-by-api-calls"
	],
	"threat_actors": [],
	"ts_created_at": 1775434253,
	"ts_updated_at": 1775826781,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/36fc6b2d55cb4b2cb9ecd5f37892ff5297f85f66.pdf",
		"text": "https://archive.orkl.eu/36fc6b2d55cb4b2cb9ecd5f37892ff5297f85f66.txt",
		"img": "https://archive.orkl.eu/36fc6b2d55cb4b2cb9ecd5f37892ff5297f85f66.jpg"
	}
}