{
	"id": "c31df719-738e-4111-9918-d8469c703336",
	"created_at": "2026-04-06T00:16:52.122742Z",
	"updated_at": "2026-04-10T03:22:04.033153Z",
	"deleted_at": null,
	"sha1_hash": "99cc761065391538b648a60e7bda2f9ff293bc52",
	"title": "H1N1: Technical analysis reveals new capabilities",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1712547,
	"plain_text": "H1N1: Technical analysis reveals new capabilities\r\nBy Josh Reynolds\r\nPublished: 2016-09-13 · Archived: 2026-04-05 23:39:56 UTC\r\nThis blog is the first in a 3 part series that will provide an in-depth technical analysis on the H1N1 malware. I’ll be\r\nlooking at how H1N1 has evolved, its obfuscation, analyzing its execution including new information stealing and\r\nuser account control bypass capabilities, and finally exploring how we are both using and influencing security\r\ntools with this research.\r\nOverview\r\nThrough the use of general characteristics exhibited by malware authors we are able to broadly categorize and\r\npositively identify malicious samples. These characteristics, discussed in The General Behavior of Ransomware\r\nare indexed in a database, which allows us to identify patterns, outliers and obtain greater visibility and insight\r\ninto various threats.\r\nH1N1’s evolution: past and present\r\nThese data sets provide insight into the ever-growing attack vectors that affect our customers, which include\r\nmalware delivery mechanisms. In this blog series we highlight newly added functionality to a malware variant that\r\nstarted out as being a ‘loader’ (strictly provides capabilities of loading other more complex malware variants)\r\nknown as H1N1, and has now evolved into an information stealing variant.\r\nThroughout the data mining exercises conducted by my colleagues and I on the AMP Threat Grid Research \u0026\r\nEfficacy Team (RET) we have observed a widely distributed campaign using VBA macros to infect machines with\r\na variant of information-stealing malware. Based on the initial characteristics observed by AMP Threat Grid we\r\nbelieved these malicious documents were distributing a Ransomware variant; however, we later found the dropped\r\nexecutables to be a variant of the H1N1 loader. H1N1 is a loader malware variant that has been known to deliver\r\nPony DLLs and Vawtrak executables to infected machines. Upon infection, H1N1 previously only provided\r\nloading and system information reporting capabilities.1,2\r\nKey findings from our analysis include:\r\nUnique obfuscation techniques\r\nA novel DLL hijacking vulnerability resulting in a User Account Control bypass\r\nAdded information stealing capabilities\r\nSelf-propagation/lateral movement capabilities\r\nBackground\r\nhttp://blogs.cisco.com/security/h1n1-technical-analysis-reveals-new-capabilities\r\nPage 1 of 11\n\nH1N1 has added a plethora of new functionality in comparison to earlier reports. Throughout this blog series we\r\nwill be analyzing the capabilities of H1N1 including: obfuscation, a User Account Control (UAC) bypass,\r\ninformation stealing, data exfiltration, loader/dropper, and self-propagation/lateral movement techniques used by\r\nthis variant.1,2\r\nInfection Vector\r\nThe use of Visual Basic macros is nothing new, however, in recent months they have become one of the most\r\npopular infection vectors for all malware types, especially for Ransomware campaigns. These macros vary in\r\nsophistication from performing the download and execution of hosted binaries, to dropping the binaries\r\nthemselves. In this campaign we see the latter where the document ships an entire encoded binary within the text\r\nbox of a VBA macro form. All documents throughout this campaign have used a common naming convention in\r\nthe following formats:\r\n[domain]_card_screenshot.doc\r\nconfirmation_[random integers].doc\r\nbank_confirmation_[random integers].doc\r\ndebit_request_[random integers].doc\r\ncreditcard_statement_[random integers].doc\r\ninsurance_[random integers].doc\r\ninventory_list_[random integers].doc\r\ndebt_[random integers].doc\r\nThe domains for the first format observed include the financial, energy, communications, military and government\r\nsectors. Unsurprisingly, these documents are delivered through spear-phishing e-mail campaigns. A number of\r\nsubject headings can be observed in VirusTotal:\r\nFigure 1.0: Attached e-mail subject headings in VirusTotal for identified documents\r\nAlthough the specified domain in the filename differentiates between targets, the lure message within the phishing\r\ne-mail does not vary drastically, for example:\r\nhttp://blogs.cisco.com/security/h1n1-technical-analysis-reveals-new-capabilities\r\nPage 2 of 11\n\nFigure 2.0: Example phishing message within attached e-mail\r\nThe remaining formats appear to simply seem enticing enough to open being related finance, corporate or personal\r\ninformation.\r\nUpon opening the document, the attacker attempts to social engineer the user into executing the malicious macro\r\ncontent by stating it will adjust to their version of Microsoft Word:\r\nFigure 3.0: Social engineering content of document to open macros\r\nhttp://blogs.cisco.com/security/h1n1-technical-analysis-reveals-new-capabilities\r\nPage 3 of 11\n\nDropper Obfuscation\r\nThe VBA macro is highly obfuscated, making use of many VBA tricks to hide its true intent. These include the\r\nuse of string functions: StrReverse, Ucase, Lcase, Right, Mid, and Left. For example, the following gets the\r\n%temp% path:\r\nFigure 4.0: String obfuscation mechanisms to get %temp%\r\nMid is used here to produce “.Scripting”, Ucase and StrReverse are used to produce “FIleSystemObject”, which is\r\nused to create a VBA FileSystemObject, that is then used with GetSpecialFolder, and some basic arithmetic\r\nresulting in “2” to get %temp%.As mentioned, the binary to be executed is extracted from a VBA form text box:\r\nFigure 5.0: VBA form containing obfuscated PE within text box\r\nThe text box content is set into a variable, which is then passed off to a de-obfuscation function. The core de-obfuscation functionality is a two steps process. The first is an XOR loop with a fixed byte key of 0xE, which\r\nproduces a base64 encoded portable executable (PE):\r\nhttp://blogs.cisco.com/security/h1n1-technical-analysis-reveals-new-capabilities\r\nPage 4 of 11\n\nFigure 6.0: XOR decoding/de-obfuscation loop\r\nThe second is a VBA implementation of base64 that decodes it to produce a final Portable Executable (PE):\r\nFigure 7.0: VBA Base64 implementation\r\nThe de-obfuscated executable is then written to %temp% and executed. We can follow the execution flow through\r\nthe use of process visualization in AMP Threat Grid. What this provides is graphed process interactions (child-parent relationships) for the entirety of the run. In the case of the H1N1 malicious document, it is very apparent\r\nthat WINWORD.EXE is executing a separate binary:\r\nhttp://blogs.cisco.com/security/h1n1-technical-analysis-reveals-new-capabilities\r\nPage 5 of 11\n\nFigure 8.0: Process graph showing execution of dropped executable from Microsoft Word\r\nUnpacking\r\nThe binary has a total of three routines responsible for unpacking and injection. The first routine injects via the\r\nfollowing steps:\r\nUnpacking algorithm unpacks code to be written\r\nCreates a suspended process of the executable written to %temp% from the document with CreateProcessA\r\nWrites to that image with WriteProcessMemory\r\nhttp://blogs.cisco.com/security/h1n1-technical-analysis-reveals-new-capabilities\r\nPage 6 of 11\n\nUses GetThreatContext, SetThreadContext and ResumeThread to execute at the EP of the unpacked\r\nexecutable. On the call to WriteProcessMemory we see the lpBuffer address points to a complete PE, as is\r\nindicated by the MZ header:\r\n9.0: First MZ from WriteProcessMemory lpBuffer argument\r\nWe can then dump this to disk for analysis of the next unpacking stage. The next routine makes use of the\r\ninjection method used by Duqu to write its unpacked image3:\r\nCreateProcessW is called to create a suspended ‘Explorer.exe’ process\r\nUse the handle from PROCESS_INFORMATION produced by CreateProcessW with\r\nZwQueryInformationProcess to get Explorer.exe PEB and ImageBaseAddress\r\nAllocate and write up to 500 bytes of of the Explorer.exe process using ReadProcessMemory\r\nGet actual image size from PE header, allocated this size, and write entire Explorer.exe image into memory\r\nUse UnMapViewOfSection with ImageBaseAddress and process handle of Explorer.exe from step 2 to un-map the current section in order to avoid STATUS_CONFLICTING_ADDRESSES upon mapping of the\r\nnew section\r\nOverwrite image sections of Explorer.exe with unpacked (of the current step) executable code\r\nUse MapViewOfSection to map the manipulated Explorer.exe using the process handle from step 2\r\nCall ResumeThread to start execution of unpacked code (of the current step)\r\nhttp://blogs.cisco.com/security/h1n1-technical-analysis-reveals-new-capabilities\r\nPage 7 of 11\n\nIn order to continue to trace the execution of this code (to what we discovered was more unpacking code) we\r\nwrote 0xEBFE (relative JMP to offset 0) to the entry point of the newly written Explorer.exe. This causes\r\nExplorer.exe to spin until we can attach to this process with a debugger.\r\nBreaking on the first VirtualAlloc performed by the injected process enabled us to see a large allocation occur, and\r\nsetting a breakpoint on writing to this memory location makes it apparent that an entire DLL is written to this\r\nmemory location by the (current) unpacking code:\r\nFigure 10.0: Upack MZ to be injected\r\nLooking at the PE header the string “UpackByDwing” is apparent which indicates that this packer is being used\r\non the final binary. Opening up this code with a disassembler (in this case IDA Pro) showed the following jump\r\nthat could not be followed when the functions were graphed:\r\nhttp://blogs.cisco.com/security/h1n1-technical-analysis-reveals-new-capabilities\r\nPage 8 of 11\n\nFigure 11.0: Function graph for final Upack unpacking stage\r\nThere is an infamous POPAD prior to this jump, which for those seasoned unpackers, is indicative of leading to\r\nthe OEP of an unpacked binary due to restoring of the register state prior to the unpacked code being called. If a\r\nbreakpoint is set on the OEP identified and we continue to trace through the injected code within Explorer.exe, it\r\nbecomes clear that this address is eventually called from the unpacking code. At this point, once the breakpoint is\r\nhit, we can dump the unpacked binary to disk.\r\nOne final hurdle is required in order to get an independent executable that can be debugged. When the binary is\r\nwritten and jumped to, a pointer argument is passed on the stack that is later dereferenced within the binary. This\r\nis provided when the binary is unpacked from the injected Explorer.exe, however a null pointer is passed when the\r\nbinary is executed independently. This argument points to a size value of 0x31DB used for a call to VirtualAlloc.\r\nWe can edit the unpacked code in-line to point to a known address with this value:\r\nFigure 12.0: In-line edits to allow independent binary execution\r\nI’m only going to cover the obfuscation techniques used by H1N1 in this blog. The remaining analysis of H1N1\r\nwill be posted in my next blog.\r\nObfuscation\r\nUpon opening the binary in a disassembler (in this case IDA Pro) we see that imports are resolved dynamically\r\nusing hashing of DLLs and exports, and a string obfuscation technique used throughout the binary.\r\nString Obfuscation\r\nThe string obfuscation technique makes use of SUB, XOR, and ADD with fixed DWORD values, and the result of\r\neach step using is stored using STOSD. The result of each operation is then used as the input (within EAX) for\r\neach subsequent step. For example:\r\nhttp://blogs.cisco.com/security/h1n1-technical-analysis-reveals-new-capabilities\r\nPage 9 of 11\n\nFigure 13.0: String obfuscation technique example\r\nThe result of these operations produces the path to the WOW64 version of svchost.exe. We’ve written an\r\nIDAPython script to automatically decode these strings from a provided address starting with the XORing of\r\nEAX, performing operations on the DWORDs involved up to a certain “depth” (as strings vary in length), and\r\nadding the resulting string as a comment next to the next instruction head.4\r\nImport Obfuscation (via Import Hashing)\r\nHashed imports can be resolved by hashing the library export names ourselves. Import name strings are\r\nobfuscated using the technique mentioned above, and export names from each library are hashed by walking the\r\nexport table and performing a simple XOR and ROL loop over each name:\r\nfor(i = 0; i \u003c strlen(export_name); i++) {\r\nr = rol32(r, 7);\r\nr ^= export_name[i];\r\n}\r\nWe’ve replicated the hashing algorithm and all exports can be hashed from a given DLL. These hash values can be\r\nmapped within IDA using a C header file generated by our python script.5\r\nTo be continued…\r\nIn the next blog I’ll provide the analysis of H1N1’s execution. Stay tuned!\r\n[1] https://www.proofpoint.com/tw/threat-insight/post/hancitor-ruckguv-reappear\r\n[2] https://www.arbornetworks.com/blog/asert/wp-content/uploads/2015/06/blog_h1n1.pdf\r\n[3] http://blog.w4kfu.com/tag/duqu\r\nhttp://blogs.cisco.com/security/h1n1-technical-analysis-reveals-new-capabilities\r\nPage 10 of 11\n\n[4] https://communities.cisco.com/docs/DOC-69444\r\n[5] https://communities.cisco.com/docs/DOC-69443\r\nSource: http://blogs.cisco.com/security/h1n1-technical-analysis-reveals-new-capabilities\r\nhttp://blogs.cisco.com/security/h1n1-technical-analysis-reveals-new-capabilities\r\nPage 11 of 11",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"http://blogs.cisco.com/security/h1n1-technical-analysis-reveals-new-capabilities"
	],
	"report_names": [
		"h1n1-technical-analysis-reveals-new-capabilities"
	],
	"threat_actors": [],
	"ts_created_at": 1775434612,
	"ts_updated_at": 1775791324,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/99cc761065391538b648a60e7bda2f9ff293bc52.pdf",
		"text": "https://archive.orkl.eu/99cc761065391538b648a60e7bda2f9ff293bc52.txt",
		"img": "https://archive.orkl.eu/99cc761065391538b648a60e7bda2f9ff293bc52.jpg"
	}
}