{
	"id": "95d6b7d1-5082-46dc-b4b8-e4e66c988891",
	"created_at": "2026-04-06T00:06:24.489936Z",
	"updated_at": "2026-04-10T03:20:29.697132Z",
	"deleted_at": null,
	"sha1_hash": "a5755989451fae6b2fa2b842491c8ff74e7d4c93",
	"title": "The Hidden Bee infection chain, part 1: the stegano pack | Malwarebytes Labs",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1950461,
	"plain_text": "The Hidden Bee infection chain, part 1: the stegano pack |\r\nMalwarebytes Labs\r\nBy hasherezade\r\nPublished: 2019-08-14 · Archived: 2026-04-05 18:33:04 UTC\r\nDetection of any of the features suggesting a VM results in termination of the component.\r\nDownloading new modules\r\nThe next elements of HiddenBee are downloaded over the custom “STLP” protocol.\r\nThe raw TCP socket created to communicate using the SLTP protocol:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 1 of 265\n\nThe communication is encrypted. We can see that the expected output is a shellcode that is loaded and executed:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 2 of 265\n\nThe way in which it is loaded reminds me of the elements we described recently in “Hidden Bee: Let’s go down\r\nthe rabbit hole“. The current module loads a list of functions that will be passed to the next module. It is a\r\nminimalistic, custom version of Import Table. It also passes the memory with the downloaded filesystem to be\r\nused for further loading of components.\r\nThe !rcx package\r\nThis element retrieves the custom filesystem used by this malware. As we know from previous analysis, Hidden\r\nBee uses its own, custom filesystems that are mounted in the memory of the malware and passed to its\r\ncomponents. This filesystem is important for the execution flow because it contains many other components that\r\nare supposed to be installed on the attacked system in order to continue the infection.\r\nAs mentioned before, unpacking the JPG gave us an !rcx package. After this package is downloaded, and its\r\nSHA256 checksum is validated, it is repackaged. First, at the end of the !rcx package, the list of URLs (JPG,\r\nPNG) from the previous module is copied. Then, the ARIA key is copied. The size of the module and its SHA256\r\nhash are updated. Then, the execution is redirected to the first stage shellcode fetched from the !rcx.\r\nThis shellcode was the one that we saw at first, after decoding the !rcx package from the JPG. Yet, looking at this\r\npart, we do not see anything malicious. The elements that are more important are well protected and revealed at\r\nthe next execution stages.\r\nThe shellcode from the !rcx package is executed in two stages. The first one unpacks and prepares the second.\r\nFirst, it loads its own imports using hardcoded names of libraries.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 3 of 265\n\nThe checksums of the functions that are going to be used are stored in the module and compared with the names\r\ncalculated by the function:\r\nIt uses the functions from kernel32.dll: GetProcessHeap, VirtualAlloc, VirtualFree, and from ntdll.dll:\r\nRtlAllocateHeap, RtlFreeHeap, NtQueryInformationProcess.\r\nThe repackaged !rcx module is supposed to be supplied as one of the arguments at the Entry Point of the first\r\nshellcode. It is most important because the second stage shellcode will be unpacked from the supplied !rcx\r\npackage.\r\nA new memory area is allocated, and the second stage shellcode is unpacked there.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 4 of 265\n\nInside the second shellcode, we see strings referencing further components of the Hidden Bee malware:\r\n/bin/i386/preload /bin/i386/coredll.bin\r\nThe role of the second stage is unpacking another part from the !rcx: an !rdx package.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 5 of 265\n\nFrom our previous experience, we know that the !rdx package is a custom filesystem containing modules. Indeed,\r\nafter the decryption is complete, the custom filesystem is revealed:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 6 of 265\n\nSo the part that was hidden in the JPG is, in reality, a package that decrypts the custom filesystem and deploys the\r\nnext stage modules: /bin/i386/preload and\r\n/bin/i386/coredll.bin\r\n. This filesystem has even more elements that are loaded at later stages of the infection. Their full functionality\r\nwill be described in the next article in our series.\r\nEven more hidden\r\nFrom the beginning, Hidden Bee malware has been well designed and innovative. Looking at one year of its\r\nevolution, we can be sure that the authors are serious about making it even more stealthy—and they don’t stop\r\nimproving it.\r\nAlthough the initial dropper uses components analogous to ones observed in the past, revealing their encrypted\r\ncontent now takes many more steps and much more patience. The additional difficulty in the analysis is\r\nintroduced by the fact that the URLs and encryption keys are never reused, and work only for a single session.\r\nThe team behind this malware is skilled and determined. We expect that the Hidden Bee malware won’t be going\r\nextinct anytime soon.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 7 of 265\n\nIt converts the PNG into byte content and decrypts it with the help of ARIA cipher. The result should be a CAB\r\nformat. The unpacked CAB is supposed to contain a module “bin/i386/core.sdb” that also occurred in our previous\r\nencounters with Hidden Bee.\r\nThe authors are careful not to reuse URLs as well as encryption keys. That’s why the Aria key is different for\r\nevery unique payload. It is stored just after the end of the 0x10000401 module :\r\nDuring the module’s loading, the key is rewritten into another memory area, from which it is used to decrypt the\r\ndownloaded module.\r\nThe CAB file retrieved from the PNG is available here: 001bdc26b2845dcf839f67a8760c6839\r\nIt contains core.sdb (d1a2fdc79c154b120a0e52c46a73478d). That is a second module in Hidden Bee’s custom\r\nformat.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 8 of 265\n\nInside core.sdb\r\nThis module (retrieved from the PNG) is a second downloader component in the 0x10000401 format. This time, it\r\nuses a custom TCP-based protocol, referenced by the authors as SLTP. (This protocol was also used by the\r\nanalogical component seen one year ago). The embedded links:\r\nsltp://dns.howtocom.site:1108/minimal.bin?id=998 sltp://bbs.favcom.space:1108/setup.bin?id=999\r\nExecution flow\r\n1. Checks for blacklisted processes. If any are detected, exits.\r\n2. Removes functions:\r\nDbgBreakPoint\r\n,\r\nDbgUserBreakPoint\r\nby overwriting their beginning with the RET instruction.\r\n3. Checks if the malware is already installed. If yes, exits.\r\n4. Creates an installation mutex\r\n{71BB7F1C-D700-4487-B9C6-6DD9863DFE91}-ins.\r\n5. If the module was run with the flag==1:\r\n1. Connects to the first address:\r\nsltp://dns.howtocom.site:1108/minimal.bin?id=998\r\n2. Sets an environment variable\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 9 of 265\n\nINSTALL_SOURCE\r\nto the value given as an argument.\r\n3. Runs the downloaded next stage module.\r\n6. If the module was run with the flag!=1:\r\n1. Performs checks against VM. If detected, exits.\r\n2. Connects to the second address:\r\nsltp://bbs.favcom.space:1108/setup.bin?id=999\r\n. This time, appends the victim’s fingerprint to the URL. Format:\r\n\u0026sid=\u0026sz=\u0026os=\u0026ar=\r\n3. Runs the downloaded next stage module.\r\nDefensive checks\r\nAt this stage, many anti-analysis checks are deployed. First, there are checks to detect if any of the blacklisted\r\nprocesses are running. The enumeration of the processes is implemented using a low-level function:\r\nNtQuerySystemInformation with a parameter 5 (\r\nSystemProcessInformation\r\n).\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 10 of 265\n\nThe blacklist contains popular debuggers and sniffers:\r\n“devenv.exe” , “wireshark.exe”, “vmacthlp.exe”, “procmon.exe”, “ollydbg.exe”, “idag.exe”,\r\n“ImmunityDebugger.exe”, “windbg.exe”\r\n“EHSniffer.exe”, “iris.exe”, “procexp.exe”, “filemon.exe”, “fiddler.exe”\r\nThe names of the processes are obfuscated, so they are not visible on the strings list. If any of those processes are\r\ndetected, the execution of the module terminates.\r\nAnother function deploys a set of anti-VM checks. The anti-VM checks include:\r\nCPUID with EAX=40000000 (a check for Hypervisor’s Brand):\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 11 of 265\n\nThe VMWAre I/O Port (more details [here]):\r\nVPCEXT instruction (more details [here])\r\nChecking the list of common VM vendors:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 12 of 265\n\nChecking the BIOS versions typical for virtual environments:\r\nDetection of any of the features suggesting a VM results in termination of the component.\r\nDownloading new modules\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 13 of 265\n\nThe next elements of HiddenBee are downloaded over the custom “STLP” protocol.\r\nThe raw TCP socket created to communicate using the SLTP protocol:\r\nThe communication is encrypted. We can see that the expected output is a shellcode that is loaded and executed:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 14 of 265\n\nThe way in which it is loaded reminds me of the elements we described recently in “Hidden Bee: Let’s go down\r\nthe rabbit hole“. The current module loads a list of functions that will be passed to the next module. It is a\r\nminimalistic, custom version of Import Table. It also passes the memory with the downloaded filesystem to be\r\nused for further loading of components.\r\nThe !rcx package\r\nThis element retrieves the custom filesystem used by this malware. As we know from previous analysis, Hidden\r\nBee uses its own, custom filesystems that are mounted in the memory of the malware and passed to its\r\ncomponents. This filesystem is important for the execution flow because it contains many other components that\r\nare supposed to be installed on the attacked system in order to continue the infection.\r\nAs mentioned before, unpacking the JPG gave us an !rcx package. After this package is downloaded, and its\r\nSHA256 checksum is validated, it is repackaged. First, at the end of the !rcx package, the list of URLs (JPG,\r\nPNG) from the previous module is copied. Then, the ARIA key is copied. The size of the module and its SHA256\r\nhash are updated. Then, the execution is redirected to the first stage shellcode fetched from the !rcx.\r\nThis shellcode was the one that we saw at first, after decoding the !rcx package from the JPG. Yet, looking at this\r\npart, we do not see anything malicious. The elements that are more important are well protected and revealed at\r\nthe next execution stages.\r\nThe shellcode from the !rcx package is executed in two stages. The first one unpacks and prepares the second.\r\nFirst, it loads its own imports using hardcoded names of libraries.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 15 of 265\n\nThe checksums of the functions that are going to be used are stored in the module and compared with the names\r\ncalculated by the function:\r\nIt uses the functions from kernel32.dll: GetProcessHeap, VirtualAlloc, VirtualFree, and from ntdll.dll:\r\nRtlAllocateHeap, RtlFreeHeap, NtQueryInformationProcess.\r\nThe repackaged !rcx module is supposed to be supplied as one of the arguments at the Entry Point of the first\r\nshellcode. It is most important because the second stage shellcode will be unpacked from the supplied !rcx\r\npackage.\r\nA new memory area is allocated, and the second stage shellcode is unpacked there.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 16 of 265\n\nInside the second shellcode, we see strings referencing further components of the Hidden Bee malware:\r\n/bin/i386/preload /bin/i386/coredll.bin\r\nThe role of the second stage is unpacking another part from the !rcx: an !rdx package.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 17 of 265\n\nFrom our previous experience, we know that the !rdx package is a custom filesystem containing modules. Indeed,\r\nafter the decryption is complete, the custom filesystem is revealed:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 18 of 265\n\nSo the part that was hidden in the JPG is, in reality, a package that decrypts the custom filesystem and deploys the\r\nnext stage modules: /bin/i386/preload and\r\n/bin/i386/coredll.bin\r\n. This filesystem has even more elements that are loaded at later stages of the infection. Their full functionality\r\nwill be described in the next article in our series.\r\nEven more hidden\r\nFrom the beginning, Hidden Bee malware has been well designed and innovative. Looking at one year of its\r\nevolution, we can be sure that the authors are serious about making it even more stealthy—and they don’t stop\r\nimproving it.\r\nAlthough the initial dropper uses components analogous to ones observed in the past, revealing their encrypted\r\ncontent now takes many more steps and much more patience. The additional difficulty in the analysis is\r\nintroduced by the fact that the URLs and encryption keys are never reused, and work only for a single session.\r\nThe team behind this malware is skilled and determined. We expect that the Hidden Bee malware won’t be going\r\nextinct anytime soon.\r\nObfuscation used\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 19 of 265\n\nThis time, authors decide to obfuscate all the strings used inside the module. Now all the strings are decoded just\r\nbefore use.\r\nThe decoding algorithm is simple, based on XOR:\r\nInside the images downloader\r\nLet’s look inside the first module in the 0x10000401 format that we encountered. This module is an initial stage,\r\nand its role is to download and unpack the other components. One such component is in a CAB format (that’s why\r\nwe can see the Cabinet.dll among the imported DLLs).\r\nThe role of this module is similar to the first “WASM” mentioned in our post a year ago. However, the current\r\nversion is not only better protected, but also comes with some improvements. This time the downloaded content is\r\nhidden in the images. So, analyzing this element can help us to understand how the used stenography works.\r\nFirst, we can see that the URLs are retrieved from their Base64 form:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 20 of 265\n\nThis string decodes to a list containing URLs of the PNG and JPG files that are going to be downloaded. For each\r\nsample, this set is unique. None of the URLs can be reused: the server gives a response only once. An example of\r\na URL set:\r\nhttp://38.75.137.9:9088/pubs/wiki.php?id=937a4eadd6f5a94b3738a58dcc79ca13 http://38.75.137.9:9088/ima\r\nSo, we can confirm that this module is the one responsible for downloading and processing the observed images.\r\nIndeed, inside we can find the functions responsible for their decoding.\r\nDecoding the JPG\r\nAfter the payload is retrieved, the JPG header is validated.\r\nThen, the payload is decoded by simply using an XOR with the last byte. The decoded content is expected to start\r\nfrom the !rcx magic ID.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 21 of 265\n\nAfter decoding the content, the hash of the !rcx module is validated with the help of SHA256 hash. The valid hash\r\nis stored in the module’s header and compared with the calculated hash of the file content.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 22 of 265\n\nIf the validation passed, the shellcode stored in the !rcx module is loaded. More details about the execution flow\r\nwill be given later.\r\nThe !rcx package has a simple header:\r\nDecoding the PNG\r\nRetrieving the content from the PNG is more complex.\r\nFirst, after downloading, the PNG header is checked:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 23 of 265\n\nThe function decoding the PNG has the following flow:\r\nIt converts the PNG into byte content and decrypts it with the help of ARIA cipher. The result should be a CAB\r\nformat. The unpacked CAB is supposed to contain a module “bin/i386/core.sdb” that also occurred in our previous\r\nencounters with Hidden Bee.\r\nThe authors are careful not to reuse URLs as well as encryption keys. That’s why the Aria key is different for\r\nevery unique payload. It is stored just after the end of the 0x10000401 module :\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 24 of 265\n\nDuring the module’s loading, the key is rewritten into another memory area, from which it is used to decrypt the\r\ndownloaded module.\r\nThe CAB file retrieved from the PNG is available here: 001bdc26b2845dcf839f67a8760c6839\r\nIt contains core.sdb (d1a2fdc79c154b120a0e52c46a73478d). That is a second module in Hidden Bee’s custom\r\nformat.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 25 of 265\n\nInside core.sdb\r\nThis module (retrieved from the PNG) is a second downloader component in the 0x10000401 format. This time, it\r\nuses a custom TCP-based protocol, referenced by the authors as SLTP. (This protocol was also used by the\r\nanalogical component seen one year ago). The embedded links:\r\nsltp://dns.howtocom.site:1108/minimal.bin?id=998 sltp://bbs.favcom.space:1108/setup.bin?id=999\r\nExecution flow\r\n1. Checks for blacklisted processes. If any are detected, exits.\r\n2. Removes functions:\r\nDbgBreakPoint\r\n,\r\nDbgUserBreakPoint\r\nby overwriting their beginning with the RET instruction.\r\n3. Checks if the malware is already installed. If yes, exits.\r\n4. Creates an installation mutex\r\n{71BB7F1C-D700-4487-B9C6-6DD9863DFE91}-ins.\r\n5. If the module was run with the flag==1:\r\n1. Connects to the first address:\r\nsltp://dns.howtocom.site:1108/minimal.bin?id=998\r\n2. Sets an environment variable\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 26 of 265\n\nINSTALL_SOURCE\r\nto the value given as an argument.\r\n3. Runs the downloaded next stage module.\r\n6. If the module was run with the flag!=1:\r\n1. Performs checks against VM. If detected, exits.\r\n2. Connects to the second address:\r\nsltp://bbs.favcom.space:1108/setup.bin?id=999\r\n. This time, appends the victim’s fingerprint to the URL. Format:\r\n\u0026sid=\u0026sz=\u0026os=\u0026ar=\r\n3. Runs the downloaded next stage module.\r\nDefensive checks\r\nAt this stage, many anti-analysis checks are deployed. First, there are checks to detect if any of the blacklisted\r\nprocesses are running. The enumeration of the processes is implemented using a low-level function:\r\nNtQuerySystemInformation with a parameter 5 (\r\nSystemProcessInformation\r\n).\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 27 of 265\n\nThe blacklist contains popular debuggers and sniffers:\r\n“devenv.exe” , “wireshark.exe”, “vmacthlp.exe”, “procmon.exe”, “ollydbg.exe”, “idag.exe”,\r\n“ImmunityDebugger.exe”, “windbg.exe”\r\n“EHSniffer.exe”, “iris.exe”, “procexp.exe”, “filemon.exe”, “fiddler.exe”\r\nThe names of the processes are obfuscated, so they are not visible on the strings list. If any of those processes are\r\ndetected, the execution of the module terminates.\r\nAnother function deploys a set of anti-VM checks. The anti-VM checks include:\r\nCPUID with EAX=40000000 (a check for Hypervisor’s Brand):\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 28 of 265\n\nThe VMWAre I/O Port (more details [here]):\r\nVPCEXT instruction (more details [here])\r\nChecking the list of common VM vendors:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 29 of 265\n\nChecking the BIOS versions typical for virtual environments:\r\nDetection of any of the features suggesting a VM results in termination of the component.\r\nDownloading new modules\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 30 of 265\n\nThe next elements of HiddenBee are downloaded over the custom “STLP” protocol.\r\nThe raw TCP socket created to communicate using the SLTP protocol:\r\nThe communication is encrypted. We can see that the expected output is a shellcode that is loaded and executed:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 31 of 265\n\nThe way in which it is loaded reminds me of the elements we described recently in “Hidden Bee: Let’s go down\r\nthe rabbit hole“. The current module loads a list of functions that will be passed to the next module. It is a\r\nminimalistic, custom version of Import Table. It also passes the memory with the downloaded filesystem to be\r\nused for further loading of components.\r\nThe !rcx package\r\nThis element retrieves the custom filesystem used by this malware. As we know from previous analysis, Hidden\r\nBee uses its own, custom filesystems that are mounted in the memory of the malware and passed to its\r\ncomponents. This filesystem is important for the execution flow because it contains many other components that\r\nare supposed to be installed on the attacked system in order to continue the infection.\r\nAs mentioned before, unpacking the JPG gave us an !rcx package. After this package is downloaded, and its\r\nSHA256 checksum is validated, it is repackaged. First, at the end of the !rcx package, the list of URLs (JPG,\r\nPNG) from the previous module is copied. Then, the ARIA key is copied. The size of the module and its SHA256\r\nhash are updated. Then, the execution is redirected to the first stage shellcode fetched from the !rcx.\r\nThis shellcode was the one that we saw at first, after decoding the !rcx package from the JPG. Yet, looking at this\r\npart, we do not see anything malicious. The elements that are more important are well protected and revealed at\r\nthe next execution stages.\r\nThe shellcode from the !rcx package is executed in two stages. The first one unpacks and prepares the second.\r\nFirst, it loads its own imports using hardcoded names of libraries.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 32 of 265\n\nThe checksums of the functions that are going to be used are stored in the module and compared with the names\r\ncalculated by the function:\r\nIt uses the functions from kernel32.dll: GetProcessHeap, VirtualAlloc, VirtualFree, and from ntdll.dll:\r\nRtlAllocateHeap, RtlFreeHeap, NtQueryInformationProcess.\r\nThe repackaged !rcx module is supposed to be supplied as one of the arguments at the Entry Point of the first\r\nshellcode. It is most important because the second stage shellcode will be unpacked from the supplied !rcx\r\npackage.\r\nA new memory area is allocated, and the second stage shellcode is unpacked there.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 33 of 265\n\nInside the second shellcode, we see strings referencing further components of the Hidden Bee malware:\r\n/bin/i386/preload /bin/i386/coredll.bin\r\nThe role of the second stage is unpacking another part from the !rcx: an !rdx package.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 34 of 265\n\nFrom our previous experience, we know that the !rdx package is a custom filesystem containing modules. Indeed,\r\nafter the decryption is complete, the custom filesystem is revealed:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 35 of 265\n\nSo the part that was hidden in the JPG is, in reality, a package that decrypts the custom filesystem and deploys the\r\nnext stage modules: /bin/i386/preload and\r\n/bin/i386/coredll.bin\r\n. This filesystem has even more elements that are loaded at later stages of the infection. Their full functionality\r\nwill be described in the next article in our series.\r\nEven more hidden\r\nFrom the beginning, Hidden Bee malware has been well designed and innovative. Looking at one year of its\r\nevolution, we can be sure that the authors are serious about making it even more stealthy—and they don’t stop\r\nimproving it.\r\nAlthough the initial dropper uses components analogous to ones observed in the past, revealing their encrypted\r\ncontent now takes many more steps and much more patience. The additional difficulty in the analysis is\r\nintroduced by the fact that the URLs and encryption keys are never reused, and work only for a single session.\r\nThe team behind this malware is skilled and determined. We expect that the Hidden Bee malware won’t be going\r\nextinct anytime soon.\r\nThe configuration file (config.cfg) contains the URL to another WAV file.\r\nThe payload is padded with NOP (0x90) bytes, and the parameters, including the configuration, are filled there\r\nbefore the payload runs.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 36 of 265\n\nThe shellcode: downloading the second WAV\r\nThe second WAV, in contrast to the first one, is always downloaded and never embedded. It is retrieved by the\r\n“PayloadWin32” shellcode (9aec11ff93b9df14f060f78fbb1b47a2), deployed after the successful exploitation.\r\nLooking inside this shellcode, we find the function that is responsible for downloading and decrypting another\r\nWAV. The shellcode uses parameters that were filled by the previous layer. This buffer contains the URL that will\r\nbe queried and the key that will be used for decryption of the payload. It loads functions from wininet.dll using\r\ntheir checksums. After the initialization steps, it queries the supplied URL. The expected result is a buffer with a\r\nheader typical for WAV files.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 37 of 265\n\nAs we already suspected, the data of the WAV (starting from the offset 0x2C) contains the encrypted content.\r\nIndeed, blocks that are 8 bytes long are decrypted in a loop:\r\nAfter the decryption is complete, the next module will be revealed. It is interesting to take a look at the expected\r\nheader of the payload to learn which format is used for the output element. This time, the decoded data is\r\nsupposed to start with the following magic numbers: 0x01, 0x04, …, 0x10.\r\nThe second WAV: an executable in proprietary format\r\nOn the illustration below, we can see how the data of the WAV looks after being decrypted\r\n(9b37c9ec19a53007d450b9b9c8febbe2):\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 38 of 265\n\nThis is an executable component that is loaded into Internet Explorer. After it decodes the imports, it starts to look\r\nmuch more familiar:\r\nWe can see that it follows an analogical structure to the one described in last year’s article.\r\nThis module is first executed within Internet Explorer. Then, it creates another process (dllhost.exe) in a\r\nsuspended state:\r\nIt injects its original copy there (769a05f0eddd6ef2ebdd13618b244758):\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 39 of 265\n\nThen it redirects execution to its loading function. Below, we can see the Entry Point of the implanted module\r\nwithin dllhost.exe.\r\nA detailed analysis of the execution flow of this module and its format will be given later in the article.\r\nAt this point, it is important to note that the dllhost.exe is the module that further downloads the aforementioned\r\nimages.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 40 of 265\n\nThe modules with the custom format\r\nThe module with the custom format is analogous to the one described before. However, we can see that it has\r\nsignificantly evolved.\r\nThere are changes in the header, as well as improvements in the implementation.\r\nChanges in the custom format\r\nThe new header is similar to the previous one. The few details that have changed are: the magic number at the\r\nbeginning (from 0x10000301 to 0x10000401), and the format in which the DLLs are stored (the length of a DLL\r\nname has been added). That’s why we will refer to this format as “0x10000401 format.”\r\nAnother change is that now the names of the DLLs are obfuscated by a simple XOR with 1 byte character. They\r\nare deobfuscated just before being loaded.\r\nSumming up, we can visualize the new format in the following way:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 41 of 265\n\nObfuscation used\r\nThis time, authors decide to obfuscate all the strings used inside the module. Now all the strings are decoded just\r\nbefore use.\r\nThe decoding algorithm is simple, based on XOR:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 42 of 265\n\nInside the images downloader\r\nLet’s look inside the first module in the 0x10000401 format that we encountered. This module is an initial stage,\r\nand its role is to download and unpack the other components. One such component is in a CAB format (that’s why\r\nwe can see the Cabinet.dll among the imported DLLs).\r\nThe role of this module is similar to the first “WASM” mentioned in our post a year ago. However, the current\r\nversion is not only better protected, but also comes with some improvements. This time the downloaded content is\r\nhidden in the images. So, analyzing this element can help us to understand how the used stenography works.\r\nFirst, we can see that the URLs are retrieved from their Base64 form:\r\nThis string decodes to a list containing URLs of the PNG and JPG files that are going to be downloaded. For each\r\nsample, this set is unique. None of the URLs can be reused: the server gives a response only once. An example of\r\na URL set:\r\nhttp://38.75.137.9:9088/pubs/wiki.php?id=937a4eadd6f5a94b3738a58dcc79ca13 http://38.75.137.9:9088/ima\r\nSo, we can confirm that this module is the one responsible for downloading and processing the observed images.\r\nIndeed, inside we can find the functions responsible for their decoding.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 43 of 265\n\nDecoding the JPG\r\nAfter the payload is retrieved, the JPG header is validated.\r\nThen, the payload is decoded by simply using an XOR with the last byte. The decoded content is expected to start\r\nfrom the !rcx magic ID.\r\nAfter decoding the content, the hash of the !rcx module is validated with the help of SHA256 hash. The valid hash\r\nis stored in the module’s header and compared with the calculated hash of the file content.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 44 of 265\n\nIf the validation passed, the shellcode stored in the !rcx module is loaded. More details about the execution flow\r\nwill be given later.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 45 of 265\n\nThe !rcx package has a simple header:\r\nDecoding the PNG\r\nRetrieving the content from the PNG is more complex.\r\nFirst, after downloading, the PNG header is checked:\r\nThe function decoding the PNG has the following flow:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 46 of 265\n\nIt converts the PNG into byte content and decrypts it with the help of ARIA cipher. The result should be a CAB\r\nformat. The unpacked CAB is supposed to contain a module “bin/i386/core.sdb” that also occurred in our previous\r\nencounters with Hidden Bee.\r\nThe authors are careful not to reuse URLs as well as encryption keys. That’s why the Aria key is different for\r\nevery unique payload. It is stored just after the end of the 0x10000401 module :\r\nDuring the module’s loading, the key is rewritten into another memory area, from which it is used to decrypt the\r\ndownloaded module.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 47 of 265\n\nThe CAB file retrieved from the PNG is available here: 001bdc26b2845dcf839f67a8760c6839\r\nIt contains core.sdb (d1a2fdc79c154b120a0e52c46a73478d). That is a second module in Hidden Bee’s custom\r\nformat.\r\nInside core.sdb\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 48 of 265\n\nThis module (retrieved from the PNG) is a second downloader component in the 0x10000401 format. This time, it\r\nuses a custom TCP-based protocol, referenced by the authors as SLTP. (This protocol was also used by the\r\nanalogical component seen one year ago). The embedded links:\r\nsltp://dns.howtocom.site:1108/minimal.bin?id=998 sltp://bbs.favcom.space:1108/setup.bin?id=999\r\nExecution flow\r\n1. Checks for blacklisted processes. If any are detected, exits.\r\n2. Removes functions:\r\nDbgBreakPoint\r\n,\r\nDbgUserBreakPoint\r\nby overwriting their beginning with the RET instruction.\r\n3. Checks if the malware is already installed. If yes, exits.\r\n4. Creates an installation mutex\r\n{71BB7F1C-D700-4487-B9C6-6DD9863DFE91}-ins.\r\n5. If the module was run with the flag==1:\r\n1. Connects to the first address:\r\nsltp://dns.howtocom.site:1108/minimal.bin?id=998\r\n2. Sets an environment variable\r\nINSTALL_SOURCE\r\nto the value given as an argument.\r\n3. Runs the downloaded next stage module.\r\n6. If the module was run with the flag!=1:\r\n1. Performs checks against VM. If detected, exits.\r\n2. Connects to the second address:\r\nsltp://bbs.favcom.space:1108/setup.bin?id=999\r\n. This time, appends the victim’s fingerprint to the URL. Format:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 49 of 265\n\n\u0026sid=\u0026sz=\u0026os=\u0026ar=\r\n3. Runs the downloaded next stage module.\r\nDefensive checks\r\nAt this stage, many anti-analysis checks are deployed. First, there are checks to detect if any of the blacklisted\r\nprocesses are running. The enumeration of the processes is implemented using a low-level function:\r\nNtQuerySystemInformation with a parameter 5 (\r\nSystemProcessInformation\r\n).\r\nThe blacklist contains popular debuggers and sniffers:\r\n“devenv.exe” , “wireshark.exe”, “vmacthlp.exe”, “procmon.exe”, “ollydbg.exe”, “idag.exe”,\r\n“ImmunityDebugger.exe”, “windbg.exe”\r\n“EHSniffer.exe”, “iris.exe”, “procexp.exe”, “filemon.exe”, “fiddler.exe”\r\nThe names of the processes are obfuscated, so they are not visible on the strings list. If any of those processes are\r\ndetected, the execution of the module terminates.\r\nAnother function deploys a set of anti-VM checks. The anti-VM checks include:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 50 of 265\n\nCPUID with EAX=40000000 (a check for Hypervisor’s Brand):\r\nThe VMWAre I/O Port (more details [here]):\r\nVPCEXT instruction (more details [here])\r\nChecking the list of common VM vendors:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 51 of 265\n\nChecking the BIOS versions typical for virtual environments:\r\nDetection of any of the features suggesting a VM results in termination of the component.\r\nDownloading new modules\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 52 of 265\n\nThe next elements of HiddenBee are downloaded over the custom “STLP” protocol.\r\nThe raw TCP socket created to communicate using the SLTP protocol:\r\nThe communication is encrypted. We can see that the expected output is a shellcode that is loaded and executed:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 53 of 265\n\nThe way in which it is loaded reminds me of the elements we described recently in “Hidden Bee: Let’s go down\r\nthe rabbit hole“. The current module loads a list of functions that will be passed to the next module. It is a\r\nminimalistic, custom version of Import Table. It also passes the memory with the downloaded filesystem to be\r\nused for further loading of components.\r\nThe !rcx package\r\nThis element retrieves the custom filesystem used by this malware. As we know from previous analysis, Hidden\r\nBee uses its own, custom filesystems that are mounted in the memory of the malware and passed to its\r\ncomponents. This filesystem is important for the execution flow because it contains many other components that\r\nare supposed to be installed on the attacked system in order to continue the infection.\r\nAs mentioned before, unpacking the JPG gave us an !rcx package. After this package is downloaded, and its\r\nSHA256 checksum is validated, it is repackaged. First, at the end of the !rcx package, the list of URLs (JPG,\r\nPNG) from the previous module is copied. Then, the ARIA key is copied. The size of the module and its SHA256\r\nhash are updated. Then, the execution is redirected to the first stage shellcode fetched from the !rcx.\r\nThis shellcode was the one that we saw at first, after decoding the !rcx package from the JPG. Yet, looking at this\r\npart, we do not see anything malicious. The elements that are more important are well protected and revealed at\r\nthe next execution stages.\r\nThe shellcode from the !rcx package is executed in two stages. The first one unpacks and prepares the second.\r\nFirst, it loads its own imports using hardcoded names of libraries.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 54 of 265\n\nThe checksums of the functions that are going to be used are stored in the module and compared with the names\r\ncalculated by the function:\r\nIt uses the functions from kernel32.dll: GetProcessHeap, VirtualAlloc, VirtualFree, and from ntdll.dll:\r\nRtlAllocateHeap, RtlFreeHeap, NtQueryInformationProcess.\r\nThe repackaged !rcx module is supposed to be supplied as one of the arguments at the Entry Point of the first\r\nshellcode. It is most important because the second stage shellcode will be unpacked from the supplied !rcx\r\npackage.\r\nA new memory area is allocated, and the second stage shellcode is unpacked there.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 55 of 265\n\nInside the second shellcode, we see strings referencing further components of the Hidden Bee malware:\r\n/bin/i386/preload /bin/i386/coredll.bin\r\nThe role of the second stage is unpacking another part from the !rcx: an !rdx package.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 56 of 265\n\nFrom our previous experience, we know that the !rdx package is a custom filesystem containing modules. Indeed,\r\nafter the decryption is complete, the custom filesystem is revealed:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 57 of 265\n\nSo the part that was hidden in the JPG is, in reality, a package that decrypts the custom filesystem and deploys the\r\nnext stage modules: /bin/i386/preload and\r\n/bin/i386/coredll.bin\r\n. This filesystem has even more elements that are loaded at later stages of the infection. Their full functionality\r\nwill be described in the next article in our series.\r\nEven more hidden\r\nFrom the beginning, Hidden Bee malware has been well designed and innovative. Looking at one year of its\r\nevolution, we can be sure that the authors are serious about making it even more stealthy—and they don’t stop\r\nimproving it.\r\nAlthough the initial dropper uses components analogous to ones observed in the past, revealing their encrypted\r\ncontent now takes many more steps and much more patience. The additional difficulty in the analysis is\r\nintroduced by the fact that the URLs and encryption keys are never reused, and work only for a single session.\r\nThe team behind this malware is skilled and determined. We expect that the Hidden Bee malware won’t be going\r\nextinct anytime soon.\r\nThe first WAV: a Flash exploit\r\nThe decoded WAV contains a package with two elements embedded: a Flash file (movies.swf) and the\r\nconfiguration file (config.cfg). The decrypted data starts from the magic DWORD 0xCAFEBABE, which we\r\nnoticed in the code of the previous SWF.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 58 of 265\n\nThe Flash file (movies.swf) contains an embedded exploit. In the analyzed case, the exploit used is CVE-2015-\r\n5122, however, a different exploit may be used on a different machine:\r\nThe payload (shellcode) is stored in form of an array (binary version available here:\r\n9aec11ff93b9df14f060f78fbb1b47a2):\r\nThe configuration file (config.cfg) contains the URL to another WAV file.\r\nThe payload is padded with NOP (0x90) bytes, and the parameters, including the configuration, are filled there\r\nbefore the payload runs.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 59 of 265\n\nThe shellcode: downloading the second WAV\r\nThe second WAV, in contrast to the first one, is always downloaded and never embedded. It is retrieved by the\r\n“PayloadWin32” shellcode (9aec11ff93b9df14f060f78fbb1b47a2), deployed after the successful exploitation.\r\nLooking inside this shellcode, we find the function that is responsible for downloading and decrypting another\r\nWAV. The shellcode uses parameters that were filled by the previous layer. This buffer contains the URL that will\r\nbe queried and the key that will be used for decryption of the payload. It loads functions from wininet.dll using\r\ntheir checksums. After the initialization steps, it queries the supplied URL. The expected result is a buffer with a\r\nheader typical for WAV files.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 60 of 265\n\nAs we already suspected, the data of the WAV (starting from the offset 0x2C) contains the encrypted content.\r\nIndeed, blocks that are 8 bytes long are decrypted in a loop:\r\nAfter the decryption is complete, the next module will be revealed. It is interesting to take a look at the expected\r\nheader of the payload to learn which format is used for the output element. This time, the decoded data is\r\nsupposed to start with the following magic numbers: 0x01, 0x04, …, 0x10.\r\nThe second WAV: an executable in proprietary format\r\nOn the illustration below, we can see how the data of the WAV looks after being decrypted\r\n(9b37c9ec19a53007d450b9b9c8febbe2):\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 61 of 265\n\nThis is an executable component that is loaded into Internet Explorer. After it decodes the imports, it starts to look\r\nmuch more familiar:\r\nWe can see that it follows an analogical structure to the one described in last year’s article.\r\nThis module is first executed within Internet Explorer. Then, it creates another process (dllhost.exe) in a\r\nsuspended state:\r\nIt injects its original copy there (769a05f0eddd6ef2ebdd13618b244758):\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 62 of 265\n\nThen it redirects execution to its loading function. Below, we can see the Entry Point of the implanted module\r\nwithin dllhost.exe.\r\nA detailed analysis of the execution flow of this module and its format will be given later in the article.\r\nAt this point, it is important to note that the dllhost.exe is the module that further downloads the aforementioned\r\nimages.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 63 of 265\n\nThe modules with the custom format\r\nThe module with the custom format is analogous to the one described before. However, we can see that it has\r\nsignificantly evolved.\r\nThere are changes in the header, as well as improvements in the implementation.\r\nChanges in the custom format\r\nThe new header is similar to the previous one. The few details that have changed are: the magic number at the\r\nbeginning (from 0x10000301 to 0x10000401), and the format in which the DLLs are stored (the length of a DLL\r\nname has been added). That’s why we will refer to this format as “0x10000401 format.”\r\nAnother change is that now the names of the DLLs are obfuscated by a simple XOR with 1 byte character. They\r\nare deobfuscated just before being loaded.\r\nSumming up, we can visualize the new format in the following way:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 64 of 265\n\nObfuscation used\r\nThis time, authors decide to obfuscate all the strings used inside the module. Now all the strings are decoded just\r\nbefore use.\r\nThe decoding algorithm is simple, based on XOR:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 65 of 265\n\nInside the images downloader\r\nLet’s look inside the first module in the 0x10000401 format that we encountered. This module is an initial stage,\r\nand its role is to download and unpack the other components. One such component is in a CAB format (that’s why\r\nwe can see the Cabinet.dll among the imported DLLs).\r\nThe role of this module is similar to the first “WASM” mentioned in our post a year ago. However, the current\r\nversion is not only better protected, but also comes with some improvements. This time the downloaded content is\r\nhidden in the images. So, analyzing this element can help us to understand how the used stenography works.\r\nFirst, we can see that the URLs are retrieved from their Base64 form:\r\nThis string decodes to a list containing URLs of the PNG and JPG files that are going to be downloaded. For each\r\nsample, this set is unique. None of the URLs can be reused: the server gives a response only once. An example of\r\na URL set:\r\nhttp://38.75.137.9:9088/pubs/wiki.php?id=937a4eadd6f5a94b3738a58dcc79ca13 http://38.75.137.9:9088/ima\r\nSo, we can confirm that this module is the one responsible for downloading and processing the observed images.\r\nIndeed, inside we can find the functions responsible for their decoding.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 66 of 265\n\nDecoding the JPG\r\nAfter the payload is retrieved, the JPG header is validated.\r\nThen, the payload is decoded by simply using an XOR with the last byte. The decoded content is expected to start\r\nfrom the !rcx magic ID.\r\nAfter decoding the content, the hash of the !rcx module is validated with the help of SHA256 hash. The valid hash\r\nis stored in the module’s header and compared with the calculated hash of the file content.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 67 of 265\n\nIf the validation passed, the shellcode stored in the !rcx module is loaded. More details about the execution flow\r\nwill be given later.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 68 of 265\n\nThe !rcx package has a simple header:\r\nDecoding the PNG\r\nRetrieving the content from the PNG is more complex.\r\nFirst, after downloading, the PNG header is checked:\r\nThe function decoding the PNG has the following flow:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 69 of 265\n\nIt converts the PNG into byte content and decrypts it with the help of ARIA cipher. The result should be a CAB\r\nformat. The unpacked CAB is supposed to contain a module “bin/i386/core.sdb” that also occurred in our previous\r\nencounters with Hidden Bee.\r\nThe authors are careful not to reuse URLs as well as encryption keys. That’s why the Aria key is different for\r\nevery unique payload. It is stored just after the end of the 0x10000401 module :\r\nDuring the module’s loading, the key is rewritten into another memory area, from which it is used to decrypt the\r\ndownloaded module.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 70 of 265\n\nThe CAB file retrieved from the PNG is available here: 001bdc26b2845dcf839f67a8760c6839\r\nIt contains core.sdb (d1a2fdc79c154b120a0e52c46a73478d). That is a second module in Hidden Bee’s custom\r\nformat.\r\nInside core.sdb\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 71 of 265\n\nThis module (retrieved from the PNG) is a second downloader component in the 0x10000401 format. This time, it\r\nuses a custom TCP-based protocol, referenced by the authors as SLTP. (This protocol was also used by the\r\nanalogical component seen one year ago). The embedded links:\r\nsltp://dns.howtocom.site:1108/minimal.bin?id=998 sltp://bbs.favcom.space:1108/setup.bin?id=999\r\nExecution flow\r\n1. Checks for blacklisted processes. If any are detected, exits.\r\n2. Removes functions:\r\nDbgBreakPoint\r\n,\r\nDbgUserBreakPoint\r\nby overwriting their beginning with the RET instruction.\r\n3. Checks if the malware is already installed. If yes, exits.\r\n4. Creates an installation mutex\r\n{71BB7F1C-D700-4487-B9C6-6DD9863DFE91}-ins.\r\n5. If the module was run with the flag==1:\r\n1. Connects to the first address:\r\nsltp://dns.howtocom.site:1108/minimal.bin?id=998\r\n2. Sets an environment variable\r\nINSTALL_SOURCE\r\nto the value given as an argument.\r\n3. Runs the downloaded next stage module.\r\n6. If the module was run with the flag!=1:\r\n1. Performs checks against VM. If detected, exits.\r\n2. Connects to the second address:\r\nsltp://bbs.favcom.space:1108/setup.bin?id=999\r\n. This time, appends the victim’s fingerprint to the URL. Format:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 72 of 265\n\n\u0026sid=\u0026sz=\u0026os=\u0026ar=\r\n3. Runs the downloaded next stage module.\r\nDefensive checks\r\nAt this stage, many anti-analysis checks are deployed. First, there are checks to detect if any of the blacklisted\r\nprocesses are running. The enumeration of the processes is implemented using a low-level function:\r\nNtQuerySystemInformation with a parameter 5 (\r\nSystemProcessInformation\r\n).\r\nThe blacklist contains popular debuggers and sniffers:\r\n“devenv.exe” , “wireshark.exe”, “vmacthlp.exe”, “procmon.exe”, “ollydbg.exe”, “idag.exe”,\r\n“ImmunityDebugger.exe”, “windbg.exe”\r\n“EHSniffer.exe”, “iris.exe”, “procexp.exe”, “filemon.exe”, “fiddler.exe”\r\nThe names of the processes are obfuscated, so they are not visible on the strings list. If any of those processes are\r\ndetected, the execution of the module terminates.\r\nAnother function deploys a set of anti-VM checks. The anti-VM checks include:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 73 of 265\n\nCPUID with EAX=40000000 (a check for Hypervisor’s Brand):\r\nThe VMWAre I/O Port (more details [here]):\r\nVPCEXT instruction (more details [here])\r\nChecking the list of common VM vendors:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 74 of 265\n\nChecking the BIOS versions typical for virtual environments:\r\nDetection of any of the features suggesting a VM results in termination of the component.\r\nDownloading new modules\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 75 of 265\n\nThe next elements of HiddenBee are downloaded over the custom “STLP” protocol.\r\nThe raw TCP socket created to communicate using the SLTP protocol:\r\nThe communication is encrypted. We can see that the expected output is a shellcode that is loaded and executed:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 76 of 265\n\nThe way in which it is loaded reminds me of the elements we described recently in “Hidden Bee: Let’s go down\r\nthe rabbit hole“. The current module loads a list of functions that will be passed to the next module. It is a\r\nminimalistic, custom version of Import Table. It also passes the memory with the downloaded filesystem to be\r\nused for further loading of components.\r\nThe !rcx package\r\nThis element retrieves the custom filesystem used by this malware. As we know from previous analysis, Hidden\r\nBee uses its own, custom filesystems that are mounted in the memory of the malware and passed to its\r\ncomponents. This filesystem is important for the execution flow because it contains many other components that\r\nare supposed to be installed on the attacked system in order to continue the infection.\r\nAs mentioned before, unpacking the JPG gave us an !rcx package. After this package is downloaded, and its\r\nSHA256 checksum is validated, it is repackaged. First, at the end of the !rcx package, the list of URLs (JPG,\r\nPNG) from the previous module is copied. Then, the ARIA key is copied. The size of the module and its SHA256\r\nhash are updated. Then, the execution is redirected to the first stage shellcode fetched from the !rcx.\r\nThis shellcode was the one that we saw at first, after decoding the !rcx package from the JPG. Yet, looking at this\r\npart, we do not see anything malicious. The elements that are more important are well protected and revealed at\r\nthe next execution stages.\r\nThe shellcode from the !rcx package is executed in two stages. The first one unpacks and prepares the second.\r\nFirst, it loads its own imports using hardcoded names of libraries.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 77 of 265\n\nThe checksums of the functions that are going to be used are stored in the module and compared with the names\r\ncalculated by the function:\r\nIt uses the functions from kernel32.dll: GetProcessHeap, VirtualAlloc, VirtualFree, and from ntdll.dll:\r\nRtlAllocateHeap, RtlFreeHeap, NtQueryInformationProcess.\r\nThe repackaged !rcx module is supposed to be supplied as one of the arguments at the Entry Point of the first\r\nshellcode. It is most important because the second stage shellcode will be unpacked from the supplied !rcx\r\npackage.\r\nA new memory area is allocated, and the second stage shellcode is unpacked there.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 78 of 265\n\nInside the second shellcode, we see strings referencing further components of the Hidden Bee malware:\r\n/bin/i386/preload /bin/i386/coredll.bin\r\nThe role of the second stage is unpacking another part from the !rcx: an !rdx package.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 79 of 265\n\nFrom our previous experience, we know that the !rdx package is a custom filesystem containing modules. Indeed,\r\nafter the decryption is complete, the custom filesystem is revealed:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 80 of 265\n\nSo the part that was hidden in the JPG is, in reality, a package that decrypts the custom filesystem and deploys the\r\nnext stage modules: /bin/i386/preload and\r\n/bin/i386/coredll.bin\r\n. This filesystem has even more elements that are loaded at later stages of the infection. Their full functionality\r\nwill be described in the next article in our series.\r\nEven more hidden\r\nFrom the beginning, Hidden Bee malware has been well designed and innovative. Looking at one year of its\r\nevolution, we can be sure that the authors are serious about making it even more stealthy—and they don’t stop\r\nimproving it.\r\nAlthough the initial dropper uses components analogous to ones observed in the past, revealing their encrypted\r\ncontent now takes many more steps and much more patience. The additional difficulty in the analysis is\r\nintroduced by the fact that the URLs and encryption keys are never reused, and work only for a single session.\r\nThe team behind this malware is skilled and determined. We expect that the Hidden Bee malware won’t be going\r\nextinct anytime soon.\r\nLooking at the decompiled code, we see some interesting constants. For example, –889275714 in hex is\r\n0xCAFEBABE. As we found during analysis of other Hidden Bee elements, this DWORD was used by the same\r\nauthors before as a magic number identifying one of the custom formats.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 81 of 265\n\nInternally, there are references to a function from another module: E_ENCRYPT_process_bytes(). Inside this\r\nfunction, we see calls suggesting that the Rabbit Cipher has been used:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 82 of 265\n\nRabbit uses a 128-bit key (the same length as the MD5 hash that was mentioned before) and a 64-bit initialization\r\nvector. (In different runs, a different encryption algorithm may be selected.)\r\nAfter the decoding process is complete, the revealed content is loaded:\r\nThe first WAV: a Flash exploit\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 83 of 265\n\nThe decoded WAV contains a package with two elements embedded: a Flash file (movies.swf) and the\r\nconfiguration file (config.cfg). The decrypted data starts from the magic DWORD 0xCAFEBABE, which we\r\nnoticed in the code of the previous SWF.\r\nThe Flash file (movies.swf) contains an embedded exploit. In the analyzed case, the exploit used is CVE-2015-\r\n5122, however, a different exploit may be used on a different machine:\r\nThe payload (shellcode) is stored in form of an array (binary version available here:\r\n9aec11ff93b9df14f060f78fbb1b47a2):\r\nThe configuration file (config.cfg) contains the URL to another WAV file.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 84 of 265\n\nThe payload is padded with NOP (0x90) bytes, and the parameters, including the configuration, are filled there\r\nbefore the payload runs.\r\nThe shellcode: downloading the second WAV\r\nThe second WAV, in contrast to the first one, is always downloaded and never embedded. It is retrieved by the\r\n“PayloadWin32” shellcode (9aec11ff93b9df14f060f78fbb1b47a2), deployed after the successful exploitation.\r\nLooking inside this shellcode, we find the function that is responsible for downloading and decrypting another\r\nWAV. The shellcode uses parameters that were filled by the previous layer. This buffer contains the URL that will\r\nbe queried and the key that will be used for decryption of the payload. It loads functions from wininet.dll using\r\ntheir checksums. After the initialization steps, it queries the supplied URL. The expected result is a buffer with a\r\nheader typical for WAV files.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 85 of 265\n\nAs we already suspected, the data of the WAV (starting from the offset 0x2C) contains the encrypted content.\r\nIndeed, blocks that are 8 bytes long are decrypted in a loop:\r\nAfter the decryption is complete, the next module will be revealed. It is interesting to take a look at the expected\r\nheader of the payload to learn which format is used for the output element. This time, the decoded data is\r\nsupposed to start with the following magic numbers: 0x01, 0x04, …, 0x10.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 86 of 265\n\nThe second WAV: an executable in proprietary format\r\nOn the illustration below, we can see how the data of the WAV looks after being decrypted\r\n(9b37c9ec19a53007d450b9b9c8febbe2):\r\nThis is an executable component that is loaded into Internet Explorer. After it decodes the imports, it starts to look\r\nmuch more familiar:\r\nWe can see that it follows an analogical structure to the one described in last year’s article.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 87 of 265\n\nThis module is first executed within Internet Explorer. Then, it creates another process (dllhost.exe) in a\r\nsuspended state:\r\nIt injects its original copy there (769a05f0eddd6ef2ebdd13618b244758):\r\nThen it redirects execution to its loading function. Below, we can see the Entry Point of the implanted module\r\nwithin dllhost.exe.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 88 of 265\n\nA detailed analysis of the execution flow of this module and its format will be given later in the article.\r\nAt this point, it is important to note that the dllhost.exe is the module that further downloads the aforementioned\r\nimages.\r\nThe modules with the custom format\r\nThe module with the custom format is analogous to the one described before. However, we can see that it has\r\nsignificantly evolved.\r\nThere are changes in the header, as well as improvements in the implementation.\r\nChanges in the custom format\r\nThe new header is similar to the previous one. The few details that have changed are: the magic number at the\r\nbeginning (from 0x10000301 to 0x10000401), and the format in which the DLLs are stored (the length of a DLL\r\nname has been added). That’s why we will refer to this format as “0x10000401 format.”\r\nAnother change is that now the names of the DLLs are obfuscated by a simple XOR with 1 byte character. They\r\nare deobfuscated just before being loaded.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 89 of 265\n\nSumming up, we can visualize the new format in the following way:\r\nObfuscation used\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 90 of 265\n\nThis time, authors decide to obfuscate all the strings used inside the module. Now all the strings are decoded just\r\nbefore use.\r\nThe decoding algorithm is simple, based on XOR:\r\nInside the images downloader\r\nLet’s look inside the first module in the 0x10000401 format that we encountered. This module is an initial stage,\r\nand its role is to download and unpack the other components. One such component is in a CAB format (that’s why\r\nwe can see the Cabinet.dll among the imported DLLs).\r\nThe role of this module is similar to the first “WASM” mentioned in our post a year ago. However, the current\r\nversion is not only better protected, but also comes with some improvements. This time the downloaded content is\r\nhidden in the images. So, analyzing this element can help us to understand how the used stenography works.\r\nFirst, we can see that the URLs are retrieved from their Base64 form:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 91 of 265\n\nThis string decodes to a list containing URLs of the PNG and JPG files that are going to be downloaded. For each\r\nsample, this set is unique. None of the URLs can be reused: the server gives a response only once. An example of\r\na URL set:\r\nhttp://38.75.137.9:9088/pubs/wiki.php?id=937a4eadd6f5a94b3738a58dcc79ca13 http://38.75.137.9:9088/ima\r\nSo, we can confirm that this module is the one responsible for downloading and processing the observed images.\r\nIndeed, inside we can find the functions responsible for their decoding.\r\nDecoding the JPG\r\nAfter the payload is retrieved, the JPG header is validated.\r\nThen, the payload is decoded by simply using an XOR with the last byte. The decoded content is expected to start\r\nfrom the !rcx magic ID.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 92 of 265\n\nAfter decoding the content, the hash of the !rcx module is validated with the help of SHA256 hash. The valid hash\r\nis stored in the module’s header and compared with the calculated hash of the file content.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 93 of 265\n\nIf the validation passed, the shellcode stored in the !rcx module is loaded. More details about the execution flow\r\nwill be given later.\r\nThe !rcx package has a simple header:\r\nDecoding the PNG\r\nRetrieving the content from the PNG is more complex.\r\nFirst, after downloading, the PNG header is checked:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 94 of 265\n\nThe function decoding the PNG has the following flow:\r\nIt converts the PNG into byte content and decrypts it with the help of ARIA cipher. The result should be a CAB\r\nformat. The unpacked CAB is supposed to contain a module “bin/i386/core.sdb” that also occurred in our previous\r\nencounters with Hidden Bee.\r\nThe authors are careful not to reuse URLs as well as encryption keys. That’s why the Aria key is different for\r\nevery unique payload. It is stored just after the end of the 0x10000401 module :\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 95 of 265\n\nDuring the module’s loading, the key is rewritten into another memory area, from which it is used to decrypt the\r\ndownloaded module.\r\nThe CAB file retrieved from the PNG is available here: 001bdc26b2845dcf839f67a8760c6839\r\nIt contains core.sdb (d1a2fdc79c154b120a0e52c46a73478d). That is a second module in Hidden Bee’s custom\r\nformat.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 96 of 265\n\nInside core.sdb\r\nThis module (retrieved from the PNG) is a second downloader component in the 0x10000401 format. This time, it\r\nuses a custom TCP-based protocol, referenced by the authors as SLTP. (This protocol was also used by the\r\nanalogical component seen one year ago). The embedded links:\r\nsltp://dns.howtocom.site:1108/minimal.bin?id=998 sltp://bbs.favcom.space:1108/setup.bin?id=999\r\nExecution flow\r\n1. Checks for blacklisted processes. If any are detected, exits.\r\n2. Removes functions:\r\nDbgBreakPoint\r\n,\r\nDbgUserBreakPoint\r\nby overwriting their beginning with the RET instruction.\r\n3. Checks if the malware is already installed. If yes, exits.\r\n4. Creates an installation mutex\r\n{71BB7F1C-D700-4487-B9C6-6DD9863DFE91}-ins.\r\n5. If the module was run with the flag==1:\r\n1. Connects to the first address:\r\nsltp://dns.howtocom.site:1108/minimal.bin?id=998\r\n2. Sets an environment variable\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 97 of 265\n\nINSTALL_SOURCE\r\nto the value given as an argument.\r\n3. Runs the downloaded next stage module.\r\n6. If the module was run with the flag!=1:\r\n1. Performs checks against VM. If detected, exits.\r\n2. Connects to the second address:\r\nsltp://bbs.favcom.space:1108/setup.bin?id=999\r\n. This time, appends the victim’s fingerprint to the URL. Format:\r\n\u0026sid=\u0026sz=\u0026os=\u0026ar=\r\n3. Runs the downloaded next stage module.\r\nDefensive checks\r\nAt this stage, many anti-analysis checks are deployed. First, there are checks to detect if any of the blacklisted\r\nprocesses are running. The enumeration of the processes is implemented using a low-level function:\r\nNtQuerySystemInformation with a parameter 5 (\r\nSystemProcessInformation\r\n).\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 98 of 265\n\nThe blacklist contains popular debuggers and sniffers:\r\n“devenv.exe” , “wireshark.exe”, “vmacthlp.exe”, “procmon.exe”, “ollydbg.exe”, “idag.exe”,\r\n“ImmunityDebugger.exe”, “windbg.exe”\r\n“EHSniffer.exe”, “iris.exe”, “procexp.exe”, “filemon.exe”, “fiddler.exe”\r\nThe names of the processes are obfuscated, so they are not visible on the strings list. If any of those processes are\r\ndetected, the execution of the module terminates.\r\nAnother function deploys a set of anti-VM checks. The anti-VM checks include:\r\nCPUID with EAX=40000000 (a check for Hypervisor’s Brand):\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 99 of 265\n\nThe VMWAre I/O Port (more details [here]):\r\nVPCEXT instruction (more details [here])\r\nChecking the list of common VM vendors:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 100 of 265\n\nChecking the BIOS versions typical for virtual environments:\r\nDetection of any of the features suggesting a VM results in termination of the component.\r\nDownloading new modules\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 101 of 265\n\nThe next elements of HiddenBee are downloaded over the custom “STLP” protocol.\r\nThe raw TCP socket created to communicate using the SLTP protocol:\r\nThe communication is encrypted. We can see that the expected output is a shellcode that is loaded and executed:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 102 of 265\n\nThe way in which it is loaded reminds me of the elements we described recently in “Hidden Bee: Let’s go down\r\nthe rabbit hole“. The current module loads a list of functions that will be passed to the next module. It is a\r\nminimalistic, custom version of Import Table. It also passes the memory with the downloaded filesystem to be\r\nused for further loading of components.\r\nThe !rcx package\r\nThis element retrieves the custom filesystem used by this malware. As we know from previous analysis, Hidden\r\nBee uses its own, custom filesystems that are mounted in the memory of the malware and passed to its\r\ncomponents. This filesystem is important for the execution flow because it contains many other components that\r\nare supposed to be installed on the attacked system in order to continue the infection.\r\nAs mentioned before, unpacking the JPG gave us an !rcx package. After this package is downloaded, and its\r\nSHA256 checksum is validated, it is repackaged. First, at the end of the !rcx package, the list of URLs (JPG,\r\nPNG) from the previous module is copied. Then, the ARIA key is copied. The size of the module and its SHA256\r\nhash are updated. Then, the execution is redirected to the first stage shellcode fetched from the !rcx.\r\nThis shellcode was the one that we saw at first, after decoding the !rcx package from the JPG. Yet, looking at this\r\npart, we do not see anything malicious. The elements that are more important are well protected and revealed at\r\nthe next execution stages.\r\nThe shellcode from the !rcx package is executed in two stages. The first one unpacks and prepares the second.\r\nFirst, it loads its own imports using hardcoded names of libraries.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 103 of 265\n\nThe checksums of the functions that are going to be used are stored in the module and compared with the names\r\ncalculated by the function:\r\nIt uses the functions from kernel32.dll: GetProcessHeap, VirtualAlloc, VirtualFree, and from ntdll.dll:\r\nRtlAllocateHeap, RtlFreeHeap, NtQueryInformationProcess.\r\nThe repackaged !rcx module is supposed to be supplied as one of the arguments at the Entry Point of the first\r\nshellcode. It is most important because the second stage shellcode will be unpacked from the supplied !rcx\r\npackage.\r\nA new memory area is allocated, and the second stage shellcode is unpacked there.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 104 of 265\n\nInside the second shellcode, we see strings referencing further components of the Hidden Bee malware:\r\n/bin/i386/preload /bin/i386/coredll.bin\r\nThe role of the second stage is unpacking another part from the !rcx: an !rdx package.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 105 of 265\n\nFrom our previous experience, we know that the !rdx package is a custom filesystem containing modules. Indeed,\r\nafter the decryption is complete, the custom filesystem is revealed:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 106 of 265\n\nSo the part that was hidden in the JPG is, in reality, a package that decrypts the custom filesystem and deploys the\r\nnext stage modules: /bin/i386/preload and\r\n/bin/i386/coredll.bin\r\n. This filesystem has even more elements that are loaded at later stages of the infection. Their full functionality\r\nwill be described in the next article in our series.\r\nEven more hidden\r\nFrom the beginning, Hidden Bee malware has been well designed and innovative. Looking at one year of its\r\nevolution, we can be sure that the authors are serious about making it even more stealthy—and they don’t stop\r\nimproving it.\r\nAlthough the initial dropper uses components analogous to ones observed in the past, revealing their encrypted\r\ncontent now takes many more steps and much more patience. The additional difficulty in the analysis is\r\nintroduced by the fact that the URLs and encryption keys are never reused, and work only for a single session.\r\nThe team behind this malware is skilled and determined. We expect that the Hidden Bee malware won’t be going\r\nextinct anytime soon.\r\nThe algorithms used to encrypt the content of the first WAV may vary and sometimes the algorithm is supplied as\r\none of the parameters. After the content is fetched, the data from the WAV files is decoded using one of the\r\navailable algorithms:\r\nWe can see that the expected content is a Flash file that is then loaded:\r\nThe “decode” function\r\nThe function “decode” is imported from the package “com.google”:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 107 of 265\n\nThe full decompiled code is available here.\r\nWhen we look inside, we see that the code is slightly obfuscated:\r\nLooking at the decompiled code, we see some interesting constants. For example, –889275714 in hex is\r\n0xCAFEBABE. As we found during analysis of other Hidden Bee elements, this DWORD was used by the same\r\nauthors before as a magic number identifying one of the custom formats.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 108 of 265\n\nInternally, there are references to a function from another module: E_ENCRYPT_process_bytes(). Inside this\r\nfunction, we see calls suggesting that the Rabbit Cipher has been used:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 109 of 265\n\nRabbit uses a 128-bit key (the same length as the MD5 hash that was mentioned before) and a 64-bit initialization\r\nvector. (In different runs, a different encryption algorithm may be selected.)\r\nAfter the decoding process is complete, the revealed content is loaded:\r\nThe first WAV: a Flash exploit\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 110 of 265\n\nThe decoded WAV contains a package with two elements embedded: a Flash file (movies.swf) and the\r\nconfiguration file (config.cfg). The decrypted data starts from the magic DWORD 0xCAFEBABE, which we\r\nnoticed in the code of the previous SWF.\r\nThe Flash file (movies.swf) contains an embedded exploit. In the analyzed case, the exploit used is CVE-2015-\r\n5122, however, a different exploit may be used on a different machine:\r\nThe payload (shellcode) is stored in form of an array (binary version available here:\r\n9aec11ff93b9df14f060f78fbb1b47a2):\r\nThe configuration file (config.cfg) contains the URL to another WAV file.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 111 of 265\n\nThe payload is padded with NOP (0x90) bytes, and the parameters, including the configuration, are filled there\r\nbefore the payload runs.\r\nThe shellcode: downloading the second WAV\r\nThe second WAV, in contrast to the first one, is always downloaded and never embedded. It is retrieved by the\r\n“PayloadWin32” shellcode (9aec11ff93b9df14f060f78fbb1b47a2), deployed after the successful exploitation.\r\nLooking inside this shellcode, we find the function that is responsible for downloading and decrypting another\r\nWAV. The shellcode uses parameters that were filled by the previous layer. This buffer contains the URL that will\r\nbe queried and the key that will be used for decryption of the payload. It loads functions from wininet.dll using\r\ntheir checksums. After the initialization steps, it queries the supplied URL. The expected result is a buffer with a\r\nheader typical for WAV files.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 112 of 265\n\nAs we already suspected, the data of the WAV (starting from the offset 0x2C) contains the encrypted content.\r\nIndeed, blocks that are 8 bytes long are decrypted in a loop:\r\nAfter the decryption is complete, the next module will be revealed. It is interesting to take a look at the expected\r\nheader of the payload to learn which format is used for the output element. This time, the decoded data is\r\nsupposed to start with the following magic numbers: 0x01, 0x04, …, 0x10.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 113 of 265\n\nThe second WAV: an executable in proprietary format\r\nOn the illustration below, we can see how the data of the WAV looks after being decrypted\r\n(9b37c9ec19a53007d450b9b9c8febbe2):\r\nThis is an executable component that is loaded into Internet Explorer. After it decodes the imports, it starts to look\r\nmuch more familiar:\r\nWe can see that it follows an analogical structure to the one described in last year’s article.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 114 of 265\n\nThis module is first executed within Internet Explorer. Then, it creates another process (dllhost.exe) in a\r\nsuspended state:\r\nIt injects its original copy there (769a05f0eddd6ef2ebdd13618b244758):\r\nThen it redirects execution to its loading function. Below, we can see the Entry Point of the implanted module\r\nwithin dllhost.exe.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 115 of 265\n\nA detailed analysis of the execution flow of this module and its format will be given later in the article.\r\nAt this point, it is important to note that the dllhost.exe is the module that further downloads the aforementioned\r\nimages.\r\nThe modules with the custom format\r\nThe module with the custom format is analogous to the one described before. However, we can see that it has\r\nsignificantly evolved.\r\nThere are changes in the header, as well as improvements in the implementation.\r\nChanges in the custom format\r\nThe new header is similar to the previous one. The few details that have changed are: the magic number at the\r\nbeginning (from 0x10000301 to 0x10000401), and the format in which the DLLs are stored (the length of a DLL\r\nname has been added). That’s why we will refer to this format as “0x10000401 format.”\r\nAnother change is that now the names of the DLLs are obfuscated by a simple XOR with 1 byte character. They\r\nare deobfuscated just before being loaded.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 116 of 265\n\nSumming up, we can visualize the new format in the following way:\r\nObfuscation used\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 117 of 265\n\nThis time, authors decide to obfuscate all the strings used inside the module. Now all the strings are decoded just\r\nbefore use.\r\nThe decoding algorithm is simple, based on XOR:\r\nInside the images downloader\r\nLet’s look inside the first module in the 0x10000401 format that we encountered. This module is an initial stage,\r\nand its role is to download and unpack the other components. One such component is in a CAB format (that’s why\r\nwe can see the Cabinet.dll among the imported DLLs).\r\nThe role of this module is similar to the first “WASM” mentioned in our post a year ago. However, the current\r\nversion is not only better protected, but also comes with some improvements. This time the downloaded content is\r\nhidden in the images. So, analyzing this element can help us to understand how the used stenography works.\r\nFirst, we can see that the URLs are retrieved from their Base64 form:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 118 of 265\n\nThis string decodes to a list containing URLs of the PNG and JPG files that are going to be downloaded. For each\r\nsample, this set is unique. None of the URLs can be reused: the server gives a response only once. An example of\r\na URL set:\r\nhttp://38.75.137.9:9088/pubs/wiki.php?id=937a4eadd6f5a94b3738a58dcc79ca13 http://38.75.137.9:9088/ima\r\nSo, we can confirm that this module is the one responsible for downloading and processing the observed images.\r\nIndeed, inside we can find the functions responsible for their decoding.\r\nDecoding the JPG\r\nAfter the payload is retrieved, the JPG header is validated.\r\nThen, the payload is decoded by simply using an XOR with the last byte. The decoded content is expected to start\r\nfrom the !rcx magic ID.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 119 of 265\n\nAfter decoding the content, the hash of the !rcx module is validated with the help of SHA256 hash. The valid hash\r\nis stored in the module’s header and compared with the calculated hash of the file content.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 120 of 265\n\nIf the validation passed, the shellcode stored in the !rcx module is loaded. More details about the execution flow\r\nwill be given later.\r\nThe !rcx package has a simple header:\r\nDecoding the PNG\r\nRetrieving the content from the PNG is more complex.\r\nFirst, after downloading, the PNG header is checked:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 121 of 265\n\nThe function decoding the PNG has the following flow:\r\nIt converts the PNG into byte content and decrypts it with the help of ARIA cipher. The result should be a CAB\r\nformat. The unpacked CAB is supposed to contain a module “bin/i386/core.sdb” that also occurred in our previous\r\nencounters with Hidden Bee.\r\nThe authors are careful not to reuse URLs as well as encryption keys. That’s why the Aria key is different for\r\nevery unique payload. It is stored just after the end of the 0x10000401 module :\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 122 of 265\n\nDuring the module’s loading, the key is rewritten into another memory area, from which it is used to decrypt the\r\ndownloaded module.\r\nThe CAB file retrieved from the PNG is available here: 001bdc26b2845dcf839f67a8760c6839\r\nIt contains core.sdb (d1a2fdc79c154b120a0e52c46a73478d). That is a second module in Hidden Bee’s custom\r\nformat.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 123 of 265\n\nInside core.sdb\r\nThis module (retrieved from the PNG) is a second downloader component in the 0x10000401 format. This time, it\r\nuses a custom TCP-based protocol, referenced by the authors as SLTP. (This protocol was also used by the\r\nanalogical component seen one year ago). The embedded links:\r\nsltp://dns.howtocom.site:1108/minimal.bin?id=998 sltp://bbs.favcom.space:1108/setup.bin?id=999\r\nExecution flow\r\n1. Checks for blacklisted processes. If any are detected, exits.\r\n2. Removes functions:\r\nDbgBreakPoint\r\n,\r\nDbgUserBreakPoint\r\nby overwriting their beginning with the RET instruction.\r\n3. Checks if the malware is already installed. If yes, exits.\r\n4. Creates an installation mutex\r\n{71BB7F1C-D700-4487-B9C6-6DD9863DFE91}-ins.\r\n5. If the module was run with the flag==1:\r\n1. Connects to the first address:\r\nsltp://dns.howtocom.site:1108/minimal.bin?id=998\r\n2. Sets an environment variable\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 124 of 265\n\nINSTALL_SOURCE\r\nto the value given as an argument.\r\n3. Runs the downloaded next stage module.\r\n6. If the module was run with the flag!=1:\r\n1. Performs checks against VM. If detected, exits.\r\n2. Connects to the second address:\r\nsltp://bbs.favcom.space:1108/setup.bin?id=999\r\n. This time, appends the victim’s fingerprint to the URL. Format:\r\n\u0026sid=\u0026sz=\u0026os=\u0026ar=\r\n3. Runs the downloaded next stage module.\r\nDefensive checks\r\nAt this stage, many anti-analysis checks are deployed. First, there are checks to detect if any of the blacklisted\r\nprocesses are running. The enumeration of the processes is implemented using a low-level function:\r\nNtQuerySystemInformation with a parameter 5 (\r\nSystemProcessInformation\r\n).\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 125 of 265\n\nThe blacklist contains popular debuggers and sniffers:\r\n“devenv.exe” , “wireshark.exe”, “vmacthlp.exe”, “procmon.exe”, “ollydbg.exe”, “idag.exe”,\r\n“ImmunityDebugger.exe”, “windbg.exe”\r\n“EHSniffer.exe”, “iris.exe”, “procexp.exe”, “filemon.exe”, “fiddler.exe”\r\nThe names of the processes are obfuscated, so they are not visible on the strings list. If any of those processes are\r\ndetected, the execution of the module terminates.\r\nAnother function deploys a set of anti-VM checks. The anti-VM checks include:\r\nCPUID with EAX=40000000 (a check for Hypervisor’s Brand):\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 126 of 265\n\nThe VMWAre I/O Port (more details [here]):\r\nVPCEXT instruction (more details [here])\r\nChecking the list of common VM vendors:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 127 of 265\n\nChecking the BIOS versions typical for virtual environments:\r\nDetection of any of the features suggesting a VM results in termination of the component.\r\nDownloading new modules\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 128 of 265\n\nThe next elements of HiddenBee are downloaded over the custom “STLP” protocol.\r\nThe raw TCP socket created to communicate using the SLTP protocol:\r\nThe communication is encrypted. We can see that the expected output is a shellcode that is loaded and executed:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 129 of 265\n\nThe way in which it is loaded reminds me of the elements we described recently in “Hidden Bee: Let’s go down\r\nthe rabbit hole“. The current module loads a list of functions that will be passed to the next module. It is a\r\nminimalistic, custom version of Import Table. It also passes the memory with the downloaded filesystem to be\r\nused for further loading of components.\r\nThe !rcx package\r\nThis element retrieves the custom filesystem used by this malware. As we know from previous analysis, Hidden\r\nBee uses its own, custom filesystems that are mounted in the memory of the malware and passed to its\r\ncomponents. This filesystem is important for the execution flow because it contains many other components that\r\nare supposed to be installed on the attacked system in order to continue the infection.\r\nAs mentioned before, unpacking the JPG gave us an !rcx package. After this package is downloaded, and its\r\nSHA256 checksum is validated, it is repackaged. First, at the end of the !rcx package, the list of URLs (JPG,\r\nPNG) from the previous module is copied. Then, the ARIA key is copied. The size of the module and its SHA256\r\nhash are updated. Then, the execution is redirected to the first stage shellcode fetched from the !rcx.\r\nThis shellcode was the one that we saw at first, after decoding the !rcx package from the JPG. Yet, looking at this\r\npart, we do not see anything malicious. The elements that are more important are well protected and revealed at\r\nthe next execution stages.\r\nThe shellcode from the !rcx package is executed in two stages. The first one unpacks and prepares the second.\r\nFirst, it loads its own imports using hardcoded names of libraries.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 130 of 265\n\nThe checksums of the functions that are going to be used are stored in the module and compared with the names\r\ncalculated by the function:\r\nIt uses the functions from kernel32.dll: GetProcessHeap, VirtualAlloc, VirtualFree, and from ntdll.dll:\r\nRtlAllocateHeap, RtlFreeHeap, NtQueryInformationProcess.\r\nThe repackaged !rcx module is supposed to be supplied as one of the arguments at the Entry Point of the first\r\nshellcode. It is most important because the second stage shellcode will be unpacked from the supplied !rcx\r\npackage.\r\nA new memory area is allocated, and the second stage shellcode is unpacked there.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 131 of 265\n\nInside the second shellcode, we see strings referencing further components of the Hidden Bee malware:\r\n/bin/i386/preload /bin/i386/coredll.bin\r\nThe role of the second stage is unpacking another part from the !rcx: an !rdx package.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 132 of 265\n\nFrom our previous experience, we know that the !rdx package is a custom filesystem containing modules. Indeed,\r\nafter the decryption is complete, the custom filesystem is revealed:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 133 of 265\n\nSo the part that was hidden in the JPG is, in reality, a package that decrypts the custom filesystem and deploys the\r\nnext stage modules: /bin/i386/preload and\r\n/bin/i386/coredll.bin\r\n. This filesystem has even more elements that are loaded at later stages of the infection. Their full functionality\r\nwill be described in the next article in our series.\r\nEven more hidden\r\nFrom the beginning, Hidden Bee malware has been well designed and innovative. Looking at one year of its\r\nevolution, we can be sure that the authors are serious about making it even more stealthy—and they don’t stop\r\nimproving it.\r\nAlthough the initial dropper uses components analogous to ones observed in the past, revealing their encrypted\r\ncontent now takes many more steps and much more patience. The additional difficulty in the analysis is\r\nintroduced by the fact that the URLs and encryption keys are never reused, and work only for a single session.\r\nThe team behind this malware is skilled and determined. We expect that the Hidden Bee malware won’t be going\r\nextinct anytime soon.\r\nAlternative case: two WAV files\r\nSometimes, rather than embedding the WAV containing the Flash exploit, authors use another model of delivering\r\nit. They store the URL to the WAV, and then they retrieve the file.\r\nIn the below example, we can see how this model is applied to Hidden Bee. The salt, along with the WAV URL,\r\nare both stored in the Javascript embedded in the HTML:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 134 of 265\n\nThe Flash file first loads it and then decodes as the next step:\r\nLooking at the traffic capture, we can see that in this case, not one, but two WAV files are downloaded:\r\nThe algorithms used to encrypt the content of the first WAV may vary and sometimes the algorithm is supplied as\r\none of the parameters. After the content is fetched, the data from the WAV files is decoded using one of the\r\navailable algorithms:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 135 of 265\n\nWe can see that the expected content is a Flash file that is then loaded:\r\nThe “decode” function\r\nThe function “decode” is imported from the package “com.google”:\r\nThe full decompiled code is available here.\r\nWhen we look inside, we see that the code is slightly obfuscated:\r\nLooking at the decompiled code, we see some interesting constants. For example, –889275714 in hex is\r\n0xCAFEBABE. As we found during analysis of other Hidden Bee elements, this DWORD was used by the same\r\nauthors before as a magic number identifying one of the custom formats.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 136 of 265\n\nInternally, there are references to a function from another module: E_ENCRYPT_process_bytes(). Inside this\r\nfunction, we see calls suggesting that the Rabbit Cipher has been used:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 137 of 265\n\nRabbit uses a 128-bit key (the same length as the MD5 hash that was mentioned before) and a 64-bit initialization\r\nvector. (In different runs, a different encryption algorithm may be selected.)\r\nAfter the decoding process is complete, the revealed content is loaded:\r\nThe first WAV: a Flash exploit\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 138 of 265\n\nThe decoded WAV contains a package with two elements embedded: a Flash file (movies.swf) and the\r\nconfiguration file (config.cfg). The decrypted data starts from the magic DWORD 0xCAFEBABE, which we\r\nnoticed in the code of the previous SWF.\r\nThe Flash file (movies.swf) contains an embedded exploit. In the analyzed case, the exploit used is CVE-2015-\r\n5122, however, a different exploit may be used on a different machine:\r\nThe payload (shellcode) is stored in form of an array (binary version available here:\r\n9aec11ff93b9df14f060f78fbb1b47a2):\r\nThe configuration file (config.cfg) contains the URL to another WAV file.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 139 of 265\n\nThe payload is padded with NOP (0x90) bytes, and the parameters, including the configuration, are filled there\r\nbefore the payload runs.\r\nThe shellcode: downloading the second WAV\r\nThe second WAV, in contrast to the first one, is always downloaded and never embedded. It is retrieved by the\r\n“PayloadWin32” shellcode (9aec11ff93b9df14f060f78fbb1b47a2), deployed after the successful exploitation.\r\nLooking inside this shellcode, we find the function that is responsible for downloading and decrypting another\r\nWAV. The shellcode uses parameters that were filled by the previous layer. This buffer contains the URL that will\r\nbe queried and the key that will be used for decryption of the payload. It loads functions from wininet.dll using\r\ntheir checksums. After the initialization steps, it queries the supplied URL. The expected result is a buffer with a\r\nheader typical for WAV files.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 140 of 265\n\nAs we already suspected, the data of the WAV (starting from the offset 0x2C) contains the encrypted content.\r\nIndeed, blocks that are 8 bytes long are decrypted in a loop:\r\nAfter the decryption is complete, the next module will be revealed. It is interesting to take a look at the expected\r\nheader of the payload to learn which format is used for the output element. This time, the decoded data is\r\nsupposed to start with the following magic numbers: 0x01, 0x04, …, 0x10.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 141 of 265\n\nThe second WAV: an executable in proprietary format\r\nOn the illustration below, we can see how the data of the WAV looks after being decrypted\r\n(9b37c9ec19a53007d450b9b9c8febbe2):\r\nThis is an executable component that is loaded into Internet Explorer. After it decodes the imports, it starts to look\r\nmuch more familiar:\r\nWe can see that it follows an analogical structure to the one described in last year’s article.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 142 of 265\n\nThis module is first executed within Internet Explorer. Then, it creates another process (dllhost.exe) in a\r\nsuspended state:\r\nIt injects its original copy there (769a05f0eddd6ef2ebdd13618b244758):\r\nThen it redirects execution to its loading function. Below, we can see the Entry Point of the implanted module\r\nwithin dllhost.exe.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 143 of 265\n\nA detailed analysis of the execution flow of this module and its format will be given later in the article.\r\nAt this point, it is important to note that the dllhost.exe is the module that further downloads the aforementioned\r\nimages.\r\nThe modules with the custom format\r\nThe module with the custom format is analogous to the one described before. However, we can see that it has\r\nsignificantly evolved.\r\nThere are changes in the header, as well as improvements in the implementation.\r\nChanges in the custom format\r\nThe new header is similar to the previous one. The few details that have changed are: the magic number at the\r\nbeginning (from 0x10000301 to 0x10000401), and the format in which the DLLs are stored (the length of a DLL\r\nname has been added). That’s why we will refer to this format as “0x10000401 format.”\r\nAnother change is that now the names of the DLLs are obfuscated by a simple XOR with 1 byte character. They\r\nare deobfuscated just before being loaded.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 144 of 265\n\nSumming up, we can visualize the new format in the following way:\r\nObfuscation used\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 145 of 265\n\nThis time, authors decide to obfuscate all the strings used inside the module. Now all the strings are decoded just\r\nbefore use.\r\nThe decoding algorithm is simple, based on XOR:\r\nInside the images downloader\r\nLet’s look inside the first module in the 0x10000401 format that we encountered. This module is an initial stage,\r\nand its role is to download and unpack the other components. One such component is in a CAB format (that’s why\r\nwe can see the Cabinet.dll among the imported DLLs).\r\nThe role of this module is similar to the first “WASM” mentioned in our post a year ago. However, the current\r\nversion is not only better protected, but also comes with some improvements. This time the downloaded content is\r\nhidden in the images. So, analyzing this element can help us to understand how the used stenography works.\r\nFirst, we can see that the URLs are retrieved from their Base64 form:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 146 of 265\n\nThis string decodes to a list containing URLs of the PNG and JPG files that are going to be downloaded. For each\r\nsample, this set is unique. None of the URLs can be reused: the server gives a response only once. An example of\r\na URL set:\r\nhttp://38.75.137.9:9088/pubs/wiki.php?id=937a4eadd6f5a94b3738a58dcc79ca13 http://38.75.137.9:9088/ima\r\nSo, we can confirm that this module is the one responsible for downloading and processing the observed images.\r\nIndeed, inside we can find the functions responsible for their decoding.\r\nDecoding the JPG\r\nAfter the payload is retrieved, the JPG header is validated.\r\nThen, the payload is decoded by simply using an XOR with the last byte. The decoded content is expected to start\r\nfrom the !rcx magic ID.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 147 of 265\n\nAfter decoding the content, the hash of the !rcx module is validated with the help of SHA256 hash. The valid hash\r\nis stored in the module’s header and compared with the calculated hash of the file content.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 148 of 265\n\nIf the validation passed, the shellcode stored in the !rcx module is loaded. More details about the execution flow\r\nwill be given later.\r\nThe !rcx package has a simple header:\r\nDecoding the PNG\r\nRetrieving the content from the PNG is more complex.\r\nFirst, after downloading, the PNG header is checked:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 149 of 265\n\nThe function decoding the PNG has the following flow:\r\nIt converts the PNG into byte content and decrypts it with the help of ARIA cipher. The result should be a CAB\r\nformat. The unpacked CAB is supposed to contain a module “bin/i386/core.sdb” that also occurred in our previous\r\nencounters with Hidden Bee.\r\nThe authors are careful not to reuse URLs as well as encryption keys. That’s why the Aria key is different for\r\nevery unique payload. It is stored just after the end of the 0x10000401 module :\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 150 of 265\n\nDuring the module’s loading, the key is rewritten into another memory area, from which it is used to decrypt the\r\ndownloaded module.\r\nThe CAB file retrieved from the PNG is available here: 001bdc26b2845dcf839f67a8760c6839\r\nIt contains core.sdb (d1a2fdc79c154b120a0e52c46a73478d). That is a second module in Hidden Bee’s custom\r\nformat.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 151 of 265\n\nInside core.sdb\r\nThis module (retrieved from the PNG) is a second downloader component in the 0x10000401 format. This time, it\r\nuses a custom TCP-based protocol, referenced by the authors as SLTP. (This protocol was also used by the\r\nanalogical component seen one year ago). The embedded links:\r\nsltp://dns.howtocom.site:1108/minimal.bin?id=998 sltp://bbs.favcom.space:1108/setup.bin?id=999\r\nExecution flow\r\n1. Checks for blacklisted processes. If any are detected, exits.\r\n2. Removes functions:\r\nDbgBreakPoint\r\n,\r\nDbgUserBreakPoint\r\nby overwriting their beginning with the RET instruction.\r\n3. Checks if the malware is already installed. If yes, exits.\r\n4. Creates an installation mutex\r\n{71BB7F1C-D700-4487-B9C6-6DD9863DFE91}-ins.\r\n5. If the module was run with the flag==1:\r\n1. Connects to the first address:\r\nsltp://dns.howtocom.site:1108/minimal.bin?id=998\r\n2. Sets an environment variable\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 152 of 265\n\nINSTALL_SOURCE\r\nto the value given as an argument.\r\n3. Runs the downloaded next stage module.\r\n6. If the module was run with the flag!=1:\r\n1. Performs checks against VM. If detected, exits.\r\n2. Connects to the second address:\r\nsltp://bbs.favcom.space:1108/setup.bin?id=999\r\n. This time, appends the victim’s fingerprint to the URL. Format:\r\n\u0026sid=\u0026sz=\u0026os=\u0026ar=\r\n3. Runs the downloaded next stage module.\r\nDefensive checks\r\nAt this stage, many anti-analysis checks are deployed. First, there are checks to detect if any of the blacklisted\r\nprocesses are running. The enumeration of the processes is implemented using a low-level function:\r\nNtQuerySystemInformation with a parameter 5 (\r\nSystemProcessInformation\r\n).\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 153 of 265\n\nThe blacklist contains popular debuggers and sniffers:\r\n“devenv.exe” , “wireshark.exe”, “vmacthlp.exe”, “procmon.exe”, “ollydbg.exe”, “idag.exe”,\r\n“ImmunityDebugger.exe”, “windbg.exe”\r\n“EHSniffer.exe”, “iris.exe”, “procexp.exe”, “filemon.exe”, “fiddler.exe”\r\nThe names of the processes are obfuscated, so they are not visible on the strings list. If any of those processes are\r\ndetected, the execution of the module terminates.\r\nAnother function deploys a set of anti-VM checks. The anti-VM checks include:\r\nCPUID with EAX=40000000 (a check for Hypervisor’s Brand):\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 154 of 265\n\nThe VMWAre I/O Port (more details [here]):\r\nVPCEXT instruction (more details [here])\r\nChecking the list of common VM vendors:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 155 of 265\n\nChecking the BIOS versions typical for virtual environments:\r\nDetection of any of the features suggesting a VM results in termination of the component.\r\nDownloading new modules\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 156 of 265\n\nThe next elements of HiddenBee are downloaded over the custom “STLP” protocol.\r\nThe raw TCP socket created to communicate using the SLTP protocol:\r\nThe communication is encrypted. We can see that the expected output is a shellcode that is loaded and executed:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 157 of 265\n\nThe way in which it is loaded reminds me of the elements we described recently in “Hidden Bee: Let’s go down\r\nthe rabbit hole“. The current module loads a list of functions that will be passed to the next module. It is a\r\nminimalistic, custom version of Import Table. It also passes the memory with the downloaded filesystem to be\r\nused for further loading of components.\r\nThe !rcx package\r\nThis element retrieves the custom filesystem used by this malware. As we know from previous analysis, Hidden\r\nBee uses its own, custom filesystems that are mounted in the memory of the malware and passed to its\r\ncomponents. This filesystem is important for the execution flow because it contains many other components that\r\nare supposed to be installed on the attacked system in order to continue the infection.\r\nAs mentioned before, unpacking the JPG gave us an !rcx package. After this package is downloaded, and its\r\nSHA256 checksum is validated, it is repackaged. First, at the end of the !rcx package, the list of URLs (JPG,\r\nPNG) from the previous module is copied. Then, the ARIA key is copied. The size of the module and its SHA256\r\nhash are updated. Then, the execution is redirected to the first stage shellcode fetched from the !rcx.\r\nThis shellcode was the one that we saw at first, after decoding the !rcx package from the JPG. Yet, looking at this\r\npart, we do not see anything malicious. The elements that are more important are well protected and revealed at\r\nthe next execution stages.\r\nThe shellcode from the !rcx package is executed in two stages. The first one unpacks and prepares the second.\r\nFirst, it loads its own imports using hardcoded names of libraries.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 158 of 265\n\nThe checksums of the functions that are going to be used are stored in the module and compared with the names\r\ncalculated by the function:\r\nIt uses the functions from kernel32.dll: GetProcessHeap, VirtualAlloc, VirtualFree, and from ntdll.dll:\r\nRtlAllocateHeap, RtlFreeHeap, NtQueryInformationProcess.\r\nThe repackaged !rcx module is supposed to be supplied as one of the arguments at the Entry Point of the first\r\nshellcode. It is most important because the second stage shellcode will be unpacked from the supplied !rcx\r\npackage.\r\nA new memory area is allocated, and the second stage shellcode is unpacked there.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 159 of 265\n\nInside the second shellcode, we see strings referencing further components of the Hidden Bee malware:\r\n/bin/i386/preload /bin/i386/coredll.bin\r\nThe role of the second stage is unpacking another part from the !rcx: an !rdx package.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 160 of 265\n\nFrom our previous experience, we know that the !rdx package is a custom filesystem containing modules. Indeed,\r\nafter the decryption is complete, the custom filesystem is revealed:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 161 of 265\n\nSo the part that was hidden in the JPG is, in reality, a package that decrypts the custom filesystem and deploys the\r\nnext stage modules: /bin/i386/preload and\r\n/bin/i386/coredll.bin\r\n. This filesystem has even more elements that are loaded at later stages of the infection. Their full functionality\r\nwill be described in the next article in our series.\r\nEven more hidden\r\nFrom the beginning, Hidden Bee malware has been well designed and innovative. Looking at one year of its\r\nevolution, we can be sure that the authors are serious about making it even more stealthy—and they don’t stop\r\nimproving it.\r\nAlthough the initial dropper uses components analogous to ones observed in the past, revealing their encrypted\r\ncontent now takes many more steps and much more patience. The additional difficulty in the analysis is\r\nintroduced by the fact that the URLs and encryption keys are never reused, and work only for a single session.\r\nThe team behind this malware is skilled and determined. We expect that the Hidden Bee malware won’t be going\r\nextinct anytime soon.\r\nWe will start our journey of Hidden Bee analysis by looking at these files. Then, we will move to see the code\r\nresponsible for processing them in order to reveal their hidden purpose.\r\nThe roadmap of the full described package:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 162 of 265\n\nThe downloaded WAV\r\nThe WAV file sounds like grey noise, and we suspect that it is meant to hide some binary belonging to the\r\nmalware.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 163 of 265\n\nThe data is unreadable, probably encrypted or obfuscated:\r\nWe also found a repeating pattern inside, which looks like an encrypted padding. The size of the chunk is 8 bytes.\r\nThis time, using the repeating pattern as an XOR key didn’t help in getting a readable result, so probably some\r\nmore complex block cipher was used.\r\nThe JPG\r\nBelow is a sample JPG, downloaded from the URL in the format: /views/[unique_string].jpg\r\nIn contrast to the WAV content, the JPG always looks like a valid image. (Interestingly, all the JPGs we observed\r\nhave a consistent theme of manga-styled girls.) However, if we take a closer look at the image, we can see that\r\nsome data is appended at the end.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 164 of 265\n\nLet’s analyze the JPG and try to extract the payload.\r\nFirst, I opened the image in a hexeditor (i.e. HxD). The size of the full image is 156,005 bytes. The last 118,762\r\nbytes belong to the malware. So, we need remove the first 37,243 bytes (156,005-118,762=37,243) in order to get\r\nthe payload.\r\nThe payload does not look like a valid code, so it is probably obfuscated. Let’s try the easiest option first and see\r\nif there are any candidates for the XOR key. We can see that the payload has padding at the end:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 165 of 265\n\nLet’s try to apply the repeating character (in the given example it is 0xE5) as an XOR key. This is the result\r\n(1953032199142ea8c5872107da8f2297):\r\nRepeating the experiment on various payloads, we can see that the result always start from the keyword !rcx . As\r\nwe know from analyzing other elements of Hidden Bee, the authors of this malware decided to use various custom\r\nformats named after 64-bit Intel registers. We also encountered packages starting from\r\n!rbx\r\nand !rsi at different layers. So, this is the first element in the chain that uses this convention.\r\nWhen we load the !rcx module into IDA, we can confirm that it contains valid code. More detailed explanation\r\nabout the\r\n!rcx\r\nformat will be given later on in this article.\r\nThe PNG\r\nLet’s have a look at a sample PNG, download from the “captcha.png” (URL format: ):\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 166 of 265\n\nAlthough it is a PNG in a valid format, it looks like noise. It probably represents bytes of some encrypted data. An\r\nattempt of converting PNG to raw bytes didn’t give any readable results. We need to analyze the code in order to\r\ndiscover what it hides.\r\nCode analysis: the initial SWF file\r\nThe initial SWF file is embedded on the website and responsible for serving the exploit. If we look inside it, we\r\nwill not find anything malicious at first. However, among the binary data we can find another suspicious WAV as\r\nan audio asset:\r\nThe beginning of the file:\r\nThis SWF file also contains a decoder for it:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 167 of 265\n\nThe function “decode” takes four parameters. The first of them is the byte array containing the WAV asset: That is\r\nthe content to be decoded. The second argument is an MD5 (the “setup” function is an MD5 implementation)\r\nmade of concatenation of the AppId and the AppToken: That is probably the encryption key. The third parameter\r\nis a salt (probably the initialization vector of the crypto).\r\nThe salt is fetched from the HTML page, where the Flash component is embedded:\r\nAlternative case: two WAV files\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 168 of 265\n\nSometimes, rather than embedding the WAV containing the Flash exploit, authors use another model of delivering\r\nit. They store the URL to the WAV, and then they retrieve the file.\r\nIn the below example, we can see how this model is applied to Hidden Bee. The salt, along with the WAV URL,\r\nare both stored in the Javascript embedded in the HTML:\r\nThe Flash file first loads it and then decodes as the next step:\r\nLooking at the traffic capture, we can see that in this case, not one, but two WAV files are downloaded:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 169 of 265\n\nThe algorithms used to encrypt the content of the first WAV may vary and sometimes the algorithm is supplied as\r\none of the parameters. After the content is fetched, the data from the WAV files is decoded using one of the\r\navailable algorithms:\r\nWe can see that the expected content is a Flash file that is then loaded:\r\nThe “decode” function\r\nThe function “decode” is imported from the package “com.google”:\r\nThe full decompiled code is available here.\r\nWhen we look inside, we see that the code is slightly obfuscated:\r\nLooking at the decompiled code, we see some interesting constants. For example, –889275714 in hex is\r\n0xCAFEBABE. As we found during analysis of other Hidden Bee elements, this DWORD was used by the same\r\nauthors before as a magic number identifying one of the custom formats.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 170 of 265\n\nInternally, there are references to a function from another module: E_ENCRYPT_process_bytes(). Inside this\r\nfunction, we see calls suggesting that the Rabbit Cipher has been used:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 171 of 265\n\nRabbit uses a 128-bit key (the same length as the MD5 hash that was mentioned before) and a 64-bit initialization\r\nvector. (In different runs, a different encryption algorithm may be selected.)\r\nAfter the decoding process is complete, the revealed content is loaded:\r\nThe first WAV: a Flash exploit\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 172 of 265\n\nThe decoded WAV contains a package with two elements embedded: a Flash file (movies.swf) and the\r\nconfiguration file (config.cfg). The decrypted data starts from the magic DWORD 0xCAFEBABE, which we\r\nnoticed in the code of the previous SWF.\r\nThe Flash file (movies.swf) contains an embedded exploit. In the analyzed case, the exploit used is CVE-2015-\r\n5122, however, a different exploit may be used on a different machine:\r\nThe payload (shellcode) is stored in form of an array (binary version available here:\r\n9aec11ff93b9df14f060f78fbb1b47a2):\r\nThe configuration file (config.cfg) contains the URL to another WAV file.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 173 of 265\n\nThe payload is padded with NOP (0x90) bytes, and the parameters, including the configuration, are filled there\r\nbefore the payload runs.\r\nThe shellcode: downloading the second WAV\r\nThe second WAV, in contrast to the first one, is always downloaded and never embedded. It is retrieved by the\r\n“PayloadWin32” shellcode (9aec11ff93b9df14f060f78fbb1b47a2), deployed after the successful exploitation.\r\nLooking inside this shellcode, we find the function that is responsible for downloading and decrypting another\r\nWAV. The shellcode uses parameters that were filled by the previous layer. This buffer contains the URL that will\r\nbe queried and the key that will be used for decryption of the payload. It loads functions from wininet.dll using\r\ntheir checksums. After the initialization steps, it queries the supplied URL. The expected result is a buffer with a\r\nheader typical for WAV files.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 174 of 265\n\nAs we already suspected, the data of the WAV (starting from the offset 0x2C) contains the encrypted content.\r\nIndeed, blocks that are 8 bytes long are decrypted in a loop:\r\nAfter the decryption is complete, the next module will be revealed. It is interesting to take a look at the expected\r\nheader of the payload to learn which format is used for the output element. This time, the decoded data is\r\nsupposed to start with the following magic numbers: 0x01, 0x04, …, 0x10.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 175 of 265\n\nThe second WAV: an executable in proprietary format\r\nOn the illustration below, we can see how the data of the WAV looks after being decrypted\r\n(9b37c9ec19a53007d450b9b9c8febbe2):\r\nThis is an executable component that is loaded into Internet Explorer. After it decodes the imports, it starts to look\r\nmuch more familiar:\r\nWe can see that it follows an analogical structure to the one described in last year’s article.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 176 of 265\n\nThis module is first executed within Internet Explorer. Then, it creates another process (dllhost.exe) in a\r\nsuspended state:\r\nIt injects its original copy there (769a05f0eddd6ef2ebdd13618b244758):\r\nThen it redirects execution to its loading function. Below, we can see the Entry Point of the implanted module\r\nwithin dllhost.exe.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 177 of 265\n\nA detailed analysis of the execution flow of this module and its format will be given later in the article.\r\nAt this point, it is important to note that the dllhost.exe is the module that further downloads the aforementioned\r\nimages.\r\nThe modules with the custom format\r\nThe module with the custom format is analogous to the one described before. However, we can see that it has\r\nsignificantly evolved.\r\nThere are changes in the header, as well as improvements in the implementation.\r\nChanges in the custom format\r\nThe new header is similar to the previous one. The few details that have changed are: the magic number at the\r\nbeginning (from 0x10000301 to 0x10000401), and the format in which the DLLs are stored (the length of a DLL\r\nname has been added). That’s why we will refer to this format as “0x10000401 format.”\r\nAnother change is that now the names of the DLLs are obfuscated by a simple XOR with 1 byte character. They\r\nare deobfuscated just before being loaded.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 178 of 265\n\nSumming up, we can visualize the new format in the following way:\r\nObfuscation used\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 179 of 265\n\nThis time, authors decide to obfuscate all the strings used inside the module. Now all the strings are decoded just\r\nbefore use.\r\nThe decoding algorithm is simple, based on XOR:\r\nInside the images downloader\r\nLet’s look inside the first module in the 0x10000401 format that we encountered. This module is an initial stage,\r\nand its role is to download and unpack the other components. One such component is in a CAB format (that’s why\r\nwe can see the Cabinet.dll among the imported DLLs).\r\nThe role of this module is similar to the first “WASM” mentioned in our post a year ago. However, the current\r\nversion is not only better protected, but also comes with some improvements. This time the downloaded content is\r\nhidden in the images. So, analyzing this element can help us to understand how the used stenography works.\r\nFirst, we can see that the URLs are retrieved from their Base64 form:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 180 of 265\n\nThis string decodes to a list containing URLs of the PNG and JPG files that are going to be downloaded. For each\r\nsample, this set is unique. None of the URLs can be reused: the server gives a response only once. An example of\r\na URL set:\r\nhttp://38.75.137.9:9088/pubs/wiki.php?id=937a4eadd6f5a94b3738a58dcc79ca13 http://38.75.137.9:9088/ima\r\nSo, we can confirm that this module is the one responsible for downloading and processing the observed images.\r\nIndeed, inside we can find the functions responsible for their decoding.\r\nDecoding the JPG\r\nAfter the payload is retrieved, the JPG header is validated.\r\nThen, the payload is decoded by simply using an XOR with the last byte. The decoded content is expected to start\r\nfrom the !rcx magic ID.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 181 of 265\n\nAfter decoding the content, the hash of the !rcx module is validated with the help of SHA256 hash. The valid hash\r\nis stored in the module’s header and compared with the calculated hash of the file content.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 182 of 265\n\nIf the validation passed, the shellcode stored in the !rcx module is loaded. More details about the execution flow\r\nwill be given later.\r\nThe !rcx package has a simple header:\r\nDecoding the PNG\r\nRetrieving the content from the PNG is more complex.\r\nFirst, after downloading, the PNG header is checked:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 183 of 265\n\nThe function decoding the PNG has the following flow:\r\nIt converts the PNG into byte content and decrypts it with the help of ARIA cipher. The result should be a CAB\r\nformat. The unpacked CAB is supposed to contain a module “bin/i386/core.sdb” that also occurred in our previous\r\nencounters with Hidden Bee.\r\nThe authors are careful not to reuse URLs as well as encryption keys. That’s why the Aria key is different for\r\nevery unique payload. It is stored just after the end of the 0x10000401 module :\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 184 of 265\n\nDuring the module’s loading, the key is rewritten into another memory area, from which it is used to decrypt the\r\ndownloaded module.\r\nThe CAB file retrieved from the PNG is available here: 001bdc26b2845dcf839f67a8760c6839\r\nIt contains core.sdb (d1a2fdc79c154b120a0e52c46a73478d). That is a second module in Hidden Bee’s custom\r\nformat.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 185 of 265\n\nInside core.sdb\r\nThis module (retrieved from the PNG) is a second downloader component in the 0x10000401 format. This time, it\r\nuses a custom TCP-based protocol, referenced by the authors as SLTP. (This protocol was also used by the\r\nanalogical component seen one year ago). The embedded links:\r\nsltp://dns.howtocom.site:1108/minimal.bin?id=998 sltp://bbs.favcom.space:1108/setup.bin?id=999\r\nExecution flow\r\n1. Checks for blacklisted processes. If any are detected, exits.\r\n2. Removes functions:\r\nDbgBreakPoint\r\n,\r\nDbgUserBreakPoint\r\nby overwriting their beginning with the RET instruction.\r\n3. Checks if the malware is already installed. If yes, exits.\r\n4. Creates an installation mutex\r\n{71BB7F1C-D700-4487-B9C6-6DD9863DFE91}-ins.\r\n5. If the module was run with the flag==1:\r\n1. Connects to the first address:\r\nsltp://dns.howtocom.site:1108/minimal.bin?id=998\r\n2. Sets an environment variable\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 186 of 265\n\nINSTALL_SOURCE\r\nto the value given as an argument.\r\n3. Runs the downloaded next stage module.\r\n6. If the module was run with the flag!=1:\r\n1. Performs checks against VM. If detected, exits.\r\n2. Connects to the second address:\r\nsltp://bbs.favcom.space:1108/setup.bin?id=999\r\n. This time, appends the victim’s fingerprint to the URL. Format:\r\n\u0026sid=\u0026sz=\u0026os=\u0026ar=\r\n3. Runs the downloaded next stage module.\r\nDefensive checks\r\nAt this stage, many anti-analysis checks are deployed. First, there are checks to detect if any of the blacklisted\r\nprocesses are running. The enumeration of the processes is implemented using a low-level function:\r\nNtQuerySystemInformation with a parameter 5 (\r\nSystemProcessInformation\r\n).\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 187 of 265\n\nThe blacklist contains popular debuggers and sniffers:\r\n“devenv.exe” , “wireshark.exe”, “vmacthlp.exe”, “procmon.exe”, “ollydbg.exe”, “idag.exe”,\r\n“ImmunityDebugger.exe”, “windbg.exe”\r\n“EHSniffer.exe”, “iris.exe”, “procexp.exe”, “filemon.exe”, “fiddler.exe”\r\nThe names of the processes are obfuscated, so they are not visible on the strings list. If any of those processes are\r\ndetected, the execution of the module terminates.\r\nAnother function deploys a set of anti-VM checks. The anti-VM checks include:\r\nCPUID with EAX=40000000 (a check for Hypervisor’s Brand):\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 188 of 265\n\nThe VMWAre I/O Port (more details [here]):\r\nVPCEXT instruction (more details [here])\r\nChecking the list of common VM vendors:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 189 of 265\n\nChecking the BIOS versions typical for virtual environments:\r\nDetection of any of the features suggesting a VM results in termination of the component.\r\nDownloading new modules\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 190 of 265\n\nThe next elements of HiddenBee are downloaded over the custom “STLP” protocol.\r\nThe raw TCP socket created to communicate using the SLTP protocol:\r\nThe communication is encrypted. We can see that the expected output is a shellcode that is loaded and executed:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 191 of 265\n\nThe way in which it is loaded reminds me of the elements we described recently in “Hidden Bee: Let’s go down\r\nthe rabbit hole“. The current module loads a list of functions that will be passed to the next module. It is a\r\nminimalistic, custom version of Import Table. It also passes the memory with the downloaded filesystem to be\r\nused for further loading of components.\r\nThe !rcx package\r\nThis element retrieves the custom filesystem used by this malware. As we know from previous analysis, Hidden\r\nBee uses its own, custom filesystems that are mounted in the memory of the malware and passed to its\r\ncomponents. This filesystem is important for the execution flow because it contains many other components that\r\nare supposed to be installed on the attacked system in order to continue the infection.\r\nAs mentioned before, unpacking the JPG gave us an !rcx package. After this package is downloaded, and its\r\nSHA256 checksum is validated, it is repackaged. First, at the end of the !rcx package, the list of URLs (JPG,\r\nPNG) from the previous module is copied. Then, the ARIA key is copied. The size of the module and its SHA256\r\nhash are updated. Then, the execution is redirected to the first stage shellcode fetched from the !rcx.\r\nThis shellcode was the one that we saw at first, after decoding the !rcx package from the JPG. Yet, looking at this\r\npart, we do not see anything malicious. The elements that are more important are well protected and revealed at\r\nthe next execution stages.\r\nThe shellcode from the !rcx package is executed in two stages. The first one unpacks and prepares the second.\r\nFirst, it loads its own imports using hardcoded names of libraries.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 192 of 265\n\nThe checksums of the functions that are going to be used are stored in the module and compared with the names\r\ncalculated by the function:\r\nIt uses the functions from kernel32.dll: GetProcessHeap, VirtualAlloc, VirtualFree, and from ntdll.dll:\r\nRtlAllocateHeap, RtlFreeHeap, NtQueryInformationProcess.\r\nThe repackaged !rcx module is supposed to be supplied as one of the arguments at the Entry Point of the first\r\nshellcode. It is most important because the second stage shellcode will be unpacked from the supplied !rcx\r\npackage.\r\nA new memory area is allocated, and the second stage shellcode is unpacked there.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 193 of 265\n\nInside the second shellcode, we see strings referencing further components of the Hidden Bee malware:\r\n/bin/i386/preload /bin/i386/coredll.bin\r\nThe role of the second stage is unpacking another part from the !rcx: an !rdx package.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 194 of 265\n\nFrom our previous experience, we know that the !rdx package is a custom filesystem containing modules. Indeed,\r\nafter the decryption is complete, the custom filesystem is revealed:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 195 of 265\n\nSo the part that was hidden in the JPG is, in reality, a package that decrypts the custom filesystem and deploys the\r\nnext stage modules: /bin/i386/preload and\r\n/bin/i386/coredll.bin\r\n. This filesystem has even more elements that are loaded at later stages of the infection. Their full functionality\r\nwill be described in the next article in our series.\r\nEven more hidden\r\nFrom the beginning, Hidden Bee malware has been well designed and innovative. Looking at one year of its\r\nevolution, we can be sure that the authors are serious about making it even more stealthy—and they don’t stop\r\nimproving it.\r\nAlthough the initial dropper uses components analogous to ones observed in the past, revealing their encrypted\r\ncontent now takes many more steps and much more patience. The additional difficulty in the analysis is\r\nintroduced by the fact that the URLs and encryption keys are never reused, and work only for a single session.\r\nThe team behind this malware is skilled and determined. We expect that the Hidden Bee malware won’t be going\r\nextinct anytime soon.\r\nThe WAV files are downloaded by iexplore.exe, the browser where the exploit is run. In contrast, the images are\r\ndownloaded at later stages of infection. For example, the JPG is always downloaded from the dllhost.exe process.\r\nThe PNG is often downloaded from yet another process.\r\nIn some runs, we observed the PNG to be downloaded instead of the JPG:\r\nWe will start our journey of Hidden Bee analysis by looking at these files. Then, we will move to see the code\r\nresponsible for processing them in order to reveal their hidden purpose.\r\nThe roadmap of the full described package:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 196 of 265\n\nThe downloaded WAV\r\nThe WAV file sounds like grey noise, and we suspect that it is meant to hide some binary belonging to the\r\nmalware.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 197 of 265\n\nThe data is unreadable, probably encrypted or obfuscated:\r\nWe also found a repeating pattern inside, which looks like an encrypted padding. The size of the chunk is 8 bytes.\r\nThis time, using the repeating pattern as an XOR key didn’t help in getting a readable result, so probably some\r\nmore complex block cipher was used.\r\nThe JPG\r\nBelow is a sample JPG, downloaded from the URL in the format: /views/[unique_string].jpg\r\nIn contrast to the WAV content, the JPG always looks like a valid image. (Interestingly, all the JPGs we observed\r\nhave a consistent theme of manga-styled girls.) However, if we take a closer look at the image, we can see that\r\nsome data is appended at the end.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 198 of 265\n\nLet’s analyze the JPG and try to extract the payload.\r\nFirst, I opened the image in a hexeditor (i.e. HxD). The size of the full image is 156,005 bytes. The last 118,762\r\nbytes belong to the malware. So, we need remove the first 37,243 bytes (156,005-118,762=37,243) in order to get\r\nthe payload.\r\nThe payload does not look like a valid code, so it is probably obfuscated. Let’s try the easiest option first and see\r\nif there are any candidates for the XOR key. We can see that the payload has padding at the end:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 199 of 265\n\nLet’s try to apply the repeating character (in the given example it is 0xE5) as an XOR key. This is the result\r\n(1953032199142ea8c5872107da8f2297):\r\nRepeating the experiment on various payloads, we can see that the result always start from the keyword !rcx . As\r\nwe know from analyzing other elements of Hidden Bee, the authors of this malware decided to use various custom\r\nformats named after 64-bit Intel registers. We also encountered packages starting from\r\n!rbx\r\nand !rsi at different layers. So, this is the first element in the chain that uses this convention.\r\nWhen we load the !rcx module into IDA, we can confirm that it contains valid code. More detailed explanation\r\nabout the\r\n!rcx\r\nformat will be given later on in this article.\r\nThe PNG\r\nLet’s have a look at a sample PNG, download from the “captcha.png” (URL format: ):\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 200 of 265\n\nAlthough it is a PNG in a valid format, it looks like noise. It probably represents bytes of some encrypted data. An\r\nattempt of converting PNG to raw bytes didn’t give any readable results. We need to analyze the code in order to\r\ndiscover what it hides.\r\nCode analysis: the initial SWF file\r\nThe initial SWF file is embedded on the website and responsible for serving the exploit. If we look inside it, we\r\nwill not find anything malicious at first. However, among the binary data we can find another suspicious WAV as\r\nan audio asset:\r\nThe beginning of the file:\r\nThis SWF file also contains a decoder for it:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 201 of 265\n\nThe function “decode” takes four parameters. The first of them is the byte array containing the WAV asset: That is\r\nthe content to be decoded. The second argument is an MD5 (the “setup” function is an MD5 implementation)\r\nmade of concatenation of the AppId and the AppToken: That is probably the encryption key. The third parameter\r\nis a salt (probably the initialization vector of the crypto).\r\nThe salt is fetched from the HTML page, where the Flash component is embedded:\r\nAlternative case: two WAV files\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 202 of 265\n\nSometimes, rather than embedding the WAV containing the Flash exploit, authors use another model of delivering\r\nit. They store the URL to the WAV, and then they retrieve the file.\r\nIn the below example, we can see how this model is applied to Hidden Bee. The salt, along with the WAV URL,\r\nare both stored in the Javascript embedded in the HTML:\r\nThe Flash file first loads it and then decodes as the next step:\r\nLooking at the traffic capture, we can see that in this case, not one, but two WAV files are downloaded:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 203 of 265\n\nThe algorithms used to encrypt the content of the first WAV may vary and sometimes the algorithm is supplied as\r\none of the parameters. After the content is fetched, the data from the WAV files is decoded using one of the\r\navailable algorithms:\r\nWe can see that the expected content is a Flash file that is then loaded:\r\nThe “decode” function\r\nThe function “decode” is imported from the package “com.google”:\r\nThe full decompiled code is available here.\r\nWhen we look inside, we see that the code is slightly obfuscated:\r\nLooking at the decompiled code, we see some interesting constants. For example, –889275714 in hex is\r\n0xCAFEBABE. As we found during analysis of other Hidden Bee elements, this DWORD was used by the same\r\nauthors before as a magic number identifying one of the custom formats.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 204 of 265\n\nInternally, there are references to a function from another module: E_ENCRYPT_process_bytes(). Inside this\r\nfunction, we see calls suggesting that the Rabbit Cipher has been used:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 205 of 265\n\nRabbit uses a 128-bit key (the same length as the MD5 hash that was mentioned before) and a 64-bit initialization\r\nvector. (In different runs, a different encryption algorithm may be selected.)\r\nAfter the decoding process is complete, the revealed content is loaded:\r\nThe first WAV: a Flash exploit\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 206 of 265\n\nThe decoded WAV contains a package with two elements embedded: a Flash file (movies.swf) and the\r\nconfiguration file (config.cfg). The decrypted data starts from the magic DWORD 0xCAFEBABE, which we\r\nnoticed in the code of the previous SWF.\r\nThe Flash file (movies.swf) contains an embedded exploit. In the analyzed case, the exploit used is CVE-2015-\r\n5122, however, a different exploit may be used on a different machine:\r\nThe payload (shellcode) is stored in form of an array (binary version available here:\r\n9aec11ff93b9df14f060f78fbb1b47a2):\r\nThe configuration file (config.cfg) contains the URL to another WAV file.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 207 of 265\n\nThe payload is padded with NOP (0x90) bytes, and the parameters, including the configuration, are filled there\r\nbefore the payload runs.\r\nThe shellcode: downloading the second WAV\r\nThe second WAV, in contrast to the first one, is always downloaded and never embedded. It is retrieved by the\r\n“PayloadWin32” shellcode (9aec11ff93b9df14f060f78fbb1b47a2), deployed after the successful exploitation.\r\nLooking inside this shellcode, we find the function that is responsible for downloading and decrypting another\r\nWAV. The shellcode uses parameters that were filled by the previous layer. This buffer contains the URL that will\r\nbe queried and the key that will be used for decryption of the payload. It loads functions from wininet.dll using\r\ntheir checksums. After the initialization steps, it queries the supplied URL. The expected result is a buffer with a\r\nheader typical for WAV files.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 208 of 265\n\nAs we already suspected, the data of the WAV (starting from the offset 0x2C) contains the encrypted content.\r\nIndeed, blocks that are 8 bytes long are decrypted in a loop:\r\nAfter the decryption is complete, the next module will be revealed. It is interesting to take a look at the expected\r\nheader of the payload to learn which format is used for the output element. This time, the decoded data is\r\nsupposed to start with the following magic numbers: 0x01, 0x04, …, 0x10.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 209 of 265\n\nThe second WAV: an executable in proprietary format\r\nOn the illustration below, we can see how the data of the WAV looks after being decrypted\r\n(9b37c9ec19a53007d450b9b9c8febbe2):\r\nThis is an executable component that is loaded into Internet Explorer. After it decodes the imports, it starts to look\r\nmuch more familiar:\r\nWe can see that it follows an analogical structure to the one described in last year’s article.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 210 of 265\n\nThis module is first executed within Internet Explorer. Then, it creates another process (dllhost.exe) in a\r\nsuspended state:\r\nIt injects its original copy there (769a05f0eddd6ef2ebdd13618b244758):\r\nThen it redirects execution to its loading function. Below, we can see the Entry Point of the implanted module\r\nwithin dllhost.exe.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 211 of 265\n\nA detailed analysis of the execution flow of this module and its format will be given later in the article.\r\nAt this point, it is important to note that the dllhost.exe is the module that further downloads the aforementioned\r\nimages.\r\nThe modules with the custom format\r\nThe module with the custom format is analogous to the one described before. However, we can see that it has\r\nsignificantly evolved.\r\nThere are changes in the header, as well as improvements in the implementation.\r\nChanges in the custom format\r\nThe new header is similar to the previous one. The few details that have changed are: the magic number at the\r\nbeginning (from 0x10000301 to 0x10000401), and the format in which the DLLs are stored (the length of a DLL\r\nname has been added). That’s why we will refer to this format as “0x10000401 format.”\r\nAnother change is that now the names of the DLLs are obfuscated by a simple XOR with 1 byte character. They\r\nare deobfuscated just before being loaded.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 212 of 265\n\nSumming up, we can visualize the new format in the following way:\r\nObfuscation used\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 213 of 265\n\nThis time, authors decide to obfuscate all the strings used inside the module. Now all the strings are decoded just\r\nbefore use.\r\nThe decoding algorithm is simple, based on XOR:\r\nInside the images downloader\r\nLet’s look inside the first module in the 0x10000401 format that we encountered. This module is an initial stage,\r\nand its role is to download and unpack the other components. One such component is in a CAB format (that’s why\r\nwe can see the Cabinet.dll among the imported DLLs).\r\nThe role of this module is similar to the first “WASM” mentioned in our post a year ago. However, the current\r\nversion is not only better protected, but also comes with some improvements. This time the downloaded content is\r\nhidden in the images. So, analyzing this element can help us to understand how the used stenography works.\r\nFirst, we can see that the URLs are retrieved from their Base64 form:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 214 of 265\n\nThis string decodes to a list containing URLs of the PNG and JPG files that are going to be downloaded. For each\r\nsample, this set is unique. None of the URLs can be reused: the server gives a response only once. An example of\r\na URL set:\r\nhttp://38.75.137.9:9088/pubs/wiki.php?id=937a4eadd6f5a94b3738a58dcc79ca13 http://38.75.137.9:9088/ima\r\nSo, we can confirm that this module is the one responsible for downloading and processing the observed images.\r\nIndeed, inside we can find the functions responsible for their decoding.\r\nDecoding the JPG\r\nAfter the payload is retrieved, the JPG header is validated.\r\nThen, the payload is decoded by simply using an XOR with the last byte. The decoded content is expected to start\r\nfrom the !rcx magic ID.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 215 of 265\n\nAfter decoding the content, the hash of the !rcx module is validated with the help of SHA256 hash. The valid hash\r\nis stored in the module’s header and compared with the calculated hash of the file content.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 216 of 265\n\nIf the validation passed, the shellcode stored in the !rcx module is loaded. More details about the execution flow\r\nwill be given later.\r\nThe !rcx package has a simple header:\r\nDecoding the PNG\r\nRetrieving the content from the PNG is more complex.\r\nFirst, after downloading, the PNG header is checked:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 217 of 265\n\nThe function decoding the PNG has the following flow:\r\nIt converts the PNG into byte content and decrypts it with the help of ARIA cipher. The result should be a CAB\r\nformat. The unpacked CAB is supposed to contain a module “bin/i386/core.sdb” that also occurred in our previous\r\nencounters with Hidden Bee.\r\nThe authors are careful not to reuse URLs as well as encryption keys. That’s why the Aria key is different for\r\nevery unique payload. It is stored just after the end of the 0x10000401 module :\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 218 of 265\n\nDuring the module’s loading, the key is rewritten into another memory area, from which it is used to decrypt the\r\ndownloaded module.\r\nThe CAB file retrieved from the PNG is available here: 001bdc26b2845dcf839f67a8760c6839\r\nIt contains core.sdb (d1a2fdc79c154b120a0e52c46a73478d). That is a second module in Hidden Bee’s custom\r\nformat.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 219 of 265\n\nInside core.sdb\r\nThis module (retrieved from the PNG) is a second downloader component in the 0x10000401 format. This time, it\r\nuses a custom TCP-based protocol, referenced by the authors as SLTP. (This protocol was also used by the\r\nanalogical component seen one year ago). The embedded links:\r\nsltp://dns.howtocom.site:1108/minimal.bin?id=998 sltp://bbs.favcom.space:1108/setup.bin?id=999\r\nExecution flow\r\n1. Checks for blacklisted processes. If any are detected, exits.\r\n2. Removes functions:\r\nDbgBreakPoint\r\n,\r\nDbgUserBreakPoint\r\nby overwriting their beginning with the RET instruction.\r\n3. Checks if the malware is already installed. If yes, exits.\r\n4. Creates an installation mutex\r\n{71BB7F1C-D700-4487-B9C6-6DD9863DFE91}-ins.\r\n5. If the module was run with the flag==1:\r\n1. Connects to the first address:\r\nsltp://dns.howtocom.site:1108/minimal.bin?id=998\r\n2. Sets an environment variable\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 220 of 265\n\nINSTALL_SOURCE\r\nto the value given as an argument.\r\n3. Runs the downloaded next stage module.\r\n6. If the module was run with the flag!=1:\r\n1. Performs checks against VM. If detected, exits.\r\n2. Connects to the second address:\r\nsltp://bbs.favcom.space:1108/setup.bin?id=999\r\n. This time, appends the victim’s fingerprint to the URL. Format:\r\n\u0026sid=\u0026sz=\u0026os=\u0026ar=\r\n3. Runs the downloaded next stage module.\r\nDefensive checks\r\nAt this stage, many anti-analysis checks are deployed. First, there are checks to detect if any of the blacklisted\r\nprocesses are running. The enumeration of the processes is implemented using a low-level function:\r\nNtQuerySystemInformation with a parameter 5 (\r\nSystemProcessInformation\r\n).\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 221 of 265\n\nThe blacklist contains popular debuggers and sniffers:\r\n“devenv.exe” , “wireshark.exe”, “vmacthlp.exe”, “procmon.exe”, “ollydbg.exe”, “idag.exe”,\r\n“ImmunityDebugger.exe”, “windbg.exe”\r\n“EHSniffer.exe”, “iris.exe”, “procexp.exe”, “filemon.exe”, “fiddler.exe”\r\nThe names of the processes are obfuscated, so they are not visible on the strings list. If any of those processes are\r\ndetected, the execution of the module terminates.\r\nAnother function deploys a set of anti-VM checks. The anti-VM checks include:\r\nCPUID with EAX=40000000 (a check for Hypervisor’s Brand):\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 222 of 265\n\nThe VMWAre I/O Port (more details [here]):\r\nVPCEXT instruction (more details [here])\r\nChecking the list of common VM vendors:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 223 of 265\n\nChecking the BIOS versions typical for virtual environments:\r\nDetection of any of the features suggesting a VM results in termination of the component.\r\nDownloading new modules\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 224 of 265\n\nThe next elements of HiddenBee are downloaded over the custom “STLP” protocol.\r\nThe raw TCP socket created to communicate using the SLTP protocol:\r\nThe communication is encrypted. We can see that the expected output is a shellcode that is loaded and executed:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 225 of 265\n\nThe way in which it is loaded reminds me of the elements we described recently in “Hidden Bee: Let’s go down\r\nthe rabbit hole“. The current module loads a list of functions that will be passed to the next module. It is a\r\nminimalistic, custom version of Import Table. It also passes the memory with the downloaded filesystem to be\r\nused for further loading of components.\r\nThe !rcx package\r\nThis element retrieves the custom filesystem used by this malware. As we know from previous analysis, Hidden\r\nBee uses its own, custom filesystems that are mounted in the memory of the malware and passed to its\r\ncomponents. This filesystem is important for the execution flow because it contains many other components that\r\nare supposed to be installed on the attacked system in order to continue the infection.\r\nAs mentioned before, unpacking the JPG gave us an !rcx package. After this package is downloaded, and its\r\nSHA256 checksum is validated, it is repackaged. First, at the end of the !rcx package, the list of URLs (JPG,\r\nPNG) from the previous module is copied. Then, the ARIA key is copied. The size of the module and its SHA256\r\nhash are updated. Then, the execution is redirected to the first stage shellcode fetched from the !rcx.\r\nThis shellcode was the one that we saw at first, after decoding the !rcx package from the JPG. Yet, looking at this\r\npart, we do not see anything malicious. The elements that are more important are well protected and revealed at\r\nthe next execution stages.\r\nThe shellcode from the !rcx package is executed in two stages. The first one unpacks and prepares the second.\r\nFirst, it loads its own imports using hardcoded names of libraries.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 226 of 265\n\nThe checksums of the functions that are going to be used are stored in the module and compared with the names\r\ncalculated by the function:\r\nIt uses the functions from kernel32.dll: GetProcessHeap, VirtualAlloc, VirtualFree, and from ntdll.dll:\r\nRtlAllocateHeap, RtlFreeHeap, NtQueryInformationProcess.\r\nThe repackaged !rcx module is supposed to be supplied as one of the arguments at the Entry Point of the first\r\nshellcode. It is most important because the second stage shellcode will be unpacked from the supplied !rcx\r\npackage.\r\nA new memory area is allocated, and the second stage shellcode is unpacked there.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 227 of 265\n\nInside the second shellcode, we see strings referencing further components of the Hidden Bee malware:\r\n/bin/i386/preload /bin/i386/coredll.bin\r\nThe role of the second stage is unpacking another part from the !rcx: an !rdx package.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 228 of 265\n\nFrom our previous experience, we know that the !rdx package is a custom filesystem containing modules. Indeed,\r\nafter the decryption is complete, the custom filesystem is revealed:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 229 of 265\n\nSo the part that was hidden in the JPG is, in reality, a package that decrypts the custom filesystem and deploys the\r\nnext stage modules: /bin/i386/preload and\r\n/bin/i386/coredll.bin\r\n. This filesystem has even more elements that are loaded at later stages of the infection. Their full functionality\r\nwill be described in the next article in our series.\r\nEven more hidden\r\nFrom the beginning, Hidden Bee malware has been well designed and innovative. Looking at one year of its\r\nevolution, we can be sure that the authors are serious about making it even more stealthy—and they don’t stop\r\nimproving it.\r\nAlthough the initial dropper uses components analogous to ones observed in the past, revealing their encrypted\r\ncontent now takes many more steps and much more patience. The additional difficulty in the analysis is\r\nintroduced by the fact that the URLs and encryption keys are never reused, and work only for a single session.\r\nThe team behind this malware is skilled and determined. We expect that the Hidden Bee malware won’t be going\r\nextinct anytime soon.\r\nAbout a year ago, we described the Hidden Bee miner delivered by the Underminer Exploit Kit.\r\nHidden Bee has a complex and multi-layered internal structure that is unusual among cybercrime toolkits, making\r\nit an interesting phenomenon on the threat landscape. That’s why we’re dedicating a series of posts to exploring\r\nparticular elements and updates made during one year of its evolution.\r\nRecently, we decided to revisit this interesting miner, describing its loader that starts the infection from a single\r\nmalicious executable. This post will present an alternative loader that is deployed when the infection starts from\r\nthe Underminer Exploit Kit. It is analogous to the loader we described in the following posts from 2018: [1] and\r\n[2].\r\nThe dropped payloads: an overview\r\nThe first time we spotted Hidden Bee, it started the infection from a flash exploit. It downloaded and injected two\r\nelements with WASM extensions that in reality were executable modules in a custom format. We described them\r\nin detail here.\r\nThose elements were the initial loaders, responsible for initiating the infection chain that at the end installed the\r\nminer.\r\nNowadays, those elements have changed. If we take a look at the elements dropped by the same EK today, we will\r\nno longer find those WASM extensions. Instead, we encounter various multimedia files: a WAV (alternatively two\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 230 of 265\n\nWAVs), a JPEG, and a PNG.\r\nThe WAV files are downloaded by iexplore.exe, the browser where the exploit is run. In contrast, the images are\r\ndownloaded at later stages of infection. For example, the JPG is always downloaded from the dllhost.exe process.\r\nThe PNG is often downloaded from yet another process.\r\nIn some runs, we observed the PNG to be downloaded instead of the JPG:\r\nWe will start our journey of Hidden Bee analysis by looking at these files. Then, we will move to see the code\r\nresponsible for processing them in order to reveal their hidden purpose.\r\nThe roadmap of the full described package:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 231 of 265\n\nThe downloaded WAV\r\nThe WAV file sounds like grey noise, and we suspect that it is meant to hide some binary belonging to the\r\nmalware.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 232 of 265\n\nThe data is unreadable, probably encrypted or obfuscated:\r\nWe also found a repeating pattern inside, which looks like an encrypted padding. The size of the chunk is 8 bytes.\r\nThis time, using the repeating pattern as an XOR key didn’t help in getting a readable result, so probably some\r\nmore complex block cipher was used.\r\nThe JPG\r\nBelow is a sample JPG, downloaded from the URL in the format: /views/[unique_string].jpg\r\nIn contrast to the WAV content, the JPG always looks like a valid image. (Interestingly, all the JPGs we observed\r\nhave a consistent theme of manga-styled girls.) However, if we take a closer look at the image, we can see that\r\nsome data is appended at the end.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 233 of 265\n\nLet’s analyze the JPG and try to extract the payload.\r\nFirst, I opened the image in a hexeditor (i.e. HxD). The size of the full image is 156,005 bytes. The last 118,762\r\nbytes belong to the malware. So, we need remove the first 37,243 bytes (156,005-118,762=37,243) in order to get\r\nthe payload.\r\nThe payload does not look like a valid code, so it is probably obfuscated. Let’s try the easiest option first and see\r\nif there are any candidates for the XOR key. We can see that the payload has padding at the end:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 234 of 265\n\nLet’s try to apply the repeating character (in the given example it is 0xE5) as an XOR key. This is the result\r\n(1953032199142ea8c5872107da8f2297):\r\nRepeating the experiment on various payloads, we can see that the result always start from the keyword !rcx . As\r\nwe know from analyzing other elements of Hidden Bee, the authors of this malware decided to use various custom\r\nformats named after 64-bit Intel registers. We also encountered packages starting from\r\n!rbx\r\nand !rsi at different layers. So, this is the first element in the chain that uses this convention.\r\nWhen we load the !rcx module into IDA, we can confirm that it contains valid code. More detailed explanation\r\nabout the\r\n!rcx\r\nformat will be given later on in this article.\r\nThe PNG\r\nLet’s have a look at a sample PNG, download from the “captcha.png” (URL format: ):\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 235 of 265\n\nAlthough it is a PNG in a valid format, it looks like noise. It probably represents bytes of some encrypted data. An\r\nattempt of converting PNG to raw bytes didn’t give any readable results. We need to analyze the code in order to\r\ndiscover what it hides.\r\nCode analysis: the initial SWF file\r\nThe initial SWF file is embedded on the website and responsible for serving the exploit. If we look inside it, we\r\nwill not find anything malicious at first. However, among the binary data we can find another suspicious WAV as\r\nan audio asset:\r\nThe beginning of the file:\r\nThis SWF file also contains a decoder for it:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 236 of 265\n\nThe function “decode” takes four parameters. The first of them is the byte array containing the WAV asset: That is\r\nthe content to be decoded. The second argument is an MD5 (the “setup” function is an MD5 implementation)\r\nmade of concatenation of the AppId and the AppToken: That is probably the encryption key. The third parameter\r\nis a salt (probably the initialization vector of the crypto).\r\nThe salt is fetched from the HTML page, where the Flash component is embedded:\r\nAlternative case: two WAV files\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 237 of 265\n\nSometimes, rather than embedding the WAV containing the Flash exploit, authors use another model of delivering\r\nit. They store the URL to the WAV, and then they retrieve the file.\r\nIn the below example, we can see how this model is applied to Hidden Bee. The salt, along with the WAV URL,\r\nare both stored in the Javascript embedded in the HTML:\r\nThe Flash file first loads it and then decodes as the next step:\r\nLooking at the traffic capture, we can see that in this case, not one, but two WAV files are downloaded:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 238 of 265\n\nThe algorithms used to encrypt the content of the first WAV may vary and sometimes the algorithm is supplied as\r\none of the parameters. After the content is fetched, the data from the WAV files is decoded using one of the\r\navailable algorithms:\r\nWe can see that the expected content is a Flash file that is then loaded:\r\nThe “decode” function\r\nThe function “decode” is imported from the package “com.google”:\r\nThe full decompiled code is available here.\r\nWhen we look inside, we see that the code is slightly obfuscated:\r\nLooking at the decompiled code, we see some interesting constants. For example, –889275714 in hex is\r\n0xCAFEBABE. As we found during analysis of other Hidden Bee elements, this DWORD was used by the same\r\nauthors before as a magic number identifying one of the custom formats.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 239 of 265\n\nInternally, there are references to a function from another module: E_ENCRYPT_process_bytes(). Inside this\r\nfunction, we see calls suggesting that the Rabbit Cipher has been used:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 240 of 265\n\nRabbit uses a 128-bit key (the same length as the MD5 hash that was mentioned before) and a 64-bit initialization\r\nvector. (In different runs, a different encryption algorithm may be selected.)\r\nAfter the decoding process is complete, the revealed content is loaded:\r\nThe first WAV: a Flash exploit\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 241 of 265\n\nThe decoded WAV contains a package with two elements embedded: a Flash file (movies.swf) and the\r\nconfiguration file (config.cfg). The decrypted data starts from the magic DWORD 0xCAFEBABE, which we\r\nnoticed in the code of the previous SWF.\r\nThe Flash file (movies.swf) contains an embedded exploit. In the analyzed case, the exploit used is CVE-2015-\r\n5122, however, a different exploit may be used on a different machine:\r\nThe payload (shellcode) is stored in form of an array (binary version available here:\r\n9aec11ff93b9df14f060f78fbb1b47a2):\r\nThe configuration file (config.cfg) contains the URL to another WAV file.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 242 of 265\n\nThe payload is padded with NOP (0x90) bytes, and the parameters, including the configuration, are filled there\r\nbefore the payload runs.\r\nThe shellcode: downloading the second WAV\r\nThe second WAV, in contrast to the first one, is always downloaded and never embedded. It is retrieved by the\r\n“PayloadWin32” shellcode (9aec11ff93b9df14f060f78fbb1b47a2), deployed after the successful exploitation.\r\nLooking inside this shellcode, we find the function that is responsible for downloading and decrypting another\r\nWAV. The shellcode uses parameters that were filled by the previous layer. This buffer contains the URL that will\r\nbe queried and the key that will be used for decryption of the payload. It loads functions from wininet.dll using\r\ntheir checksums. After the initialization steps, it queries the supplied URL. The expected result is a buffer with a\r\nheader typical for WAV files.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 243 of 265\n\nAs we already suspected, the data of the WAV (starting from the offset 0x2C) contains the encrypted content.\r\nIndeed, blocks that are 8 bytes long are decrypted in a loop:\r\nAfter the decryption is complete, the next module will be revealed. It is interesting to take a look at the expected\r\nheader of the payload to learn which format is used for the output element. This time, the decoded data is\r\nsupposed to start with the following magic numbers: 0x01, 0x04, …, 0x10.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 244 of 265\n\nThe second WAV: an executable in proprietary format\r\nOn the illustration below, we can see how the data of the WAV looks after being decrypted\r\n(9b37c9ec19a53007d450b9b9c8febbe2):\r\nThis is an executable component that is loaded into Internet Explorer. After it decodes the imports, it starts to look\r\nmuch more familiar:\r\nWe can see that it follows an analogical structure to the one described in last year’s article.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 245 of 265\n\nThis module is first executed within Internet Explorer. Then, it creates another process (dllhost.exe) in a\r\nsuspended state:\r\nIt injects its original copy there (769a05f0eddd6ef2ebdd13618b244758):\r\nThen it redirects execution to its loading function. Below, we can see the Entry Point of the implanted module\r\nwithin dllhost.exe.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 246 of 265\n\nA detailed analysis of the execution flow of this module and its format will be given later in the article.\r\nAt this point, it is important to note that the dllhost.exe is the module that further downloads the aforementioned\r\nimages.\r\nThe modules with the custom format\r\nThe module with the custom format is analogous to the one described before. However, we can see that it has\r\nsignificantly evolved.\r\nThere are changes in the header, as well as improvements in the implementation.\r\nChanges in the custom format\r\nThe new header is similar to the previous one. The few details that have changed are: the magic number at the\r\nbeginning (from 0x10000301 to 0x10000401), and the format in which the DLLs are stored (the length of a DLL\r\nname has been added). That’s why we will refer to this format as “0x10000401 format.”\r\nAnother change is that now the names of the DLLs are obfuscated by a simple XOR with 1 byte character. They\r\nare deobfuscated just before being loaded.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 247 of 265\n\nSumming up, we can visualize the new format in the following way:\r\nObfuscation used\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 248 of 265\n\nThis time, authors decide to obfuscate all the strings used inside the module. Now all the strings are decoded just\r\nbefore use.\r\nThe decoding algorithm is simple, based on XOR:\r\nInside the images downloader\r\nLet’s look inside the first module in the 0x10000401 format that we encountered. This module is an initial stage,\r\nand its role is to download and unpack the other components. One such component is in a CAB format (that’s why\r\nwe can see the Cabinet.dll among the imported DLLs).\r\nThe role of this module is similar to the first “WASM” mentioned in our post a year ago. However, the current\r\nversion is not only better protected, but also comes with some improvements. This time the downloaded content is\r\nhidden in the images. So, analyzing this element can help us to understand how the used stenography works.\r\nFirst, we can see that the URLs are retrieved from their Base64 form:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 249 of 265\n\nThis string decodes to a list containing URLs of the PNG and JPG files that are going to be downloaded. For each\r\nsample, this set is unique. None of the URLs can be reused: the server gives a response only once. An example of\r\na URL set:\r\nhttp://38.75.137.9:9088/pubs/wiki.php?id=937a4eadd6f5a94b3738a58dcc79ca13 http://38.75.137.9:9088/ima\r\nSo, we can confirm that this module is the one responsible for downloading and processing the observed images.\r\nIndeed, inside we can find the functions responsible for their decoding.\r\nDecoding the JPG\r\nAfter the payload is retrieved, the JPG header is validated.\r\nThen, the payload is decoded by simply using an XOR with the last byte. The decoded content is expected to start\r\nfrom the !rcx magic ID.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 250 of 265\n\nAfter decoding the content, the hash of the !rcx module is validated with the help of SHA256 hash. The valid hash\r\nis stored in the module’s header and compared with the calculated hash of the file content.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 251 of 265\n\nIf the validation passed, the shellcode stored in the !rcx module is loaded. More details about the execution flow\r\nwill be given later.\r\nThe !rcx package has a simple header:\r\nDecoding the PNG\r\nRetrieving the content from the PNG is more complex.\r\nFirst, after downloading, the PNG header is checked:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 252 of 265\n\nThe function decoding the PNG has the following flow:\r\nIt converts the PNG into byte content and decrypts it with the help of ARIA cipher. The result should be a CAB\r\nformat. The unpacked CAB is supposed to contain a module “bin/i386/core.sdb” that also occurred in our previous\r\nencounters with Hidden Bee.\r\nThe authors are careful not to reuse URLs as well as encryption keys. That’s why the Aria key is different for\r\nevery unique payload. It is stored just after the end of the 0x10000401 module :\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 253 of 265\n\nDuring the module’s loading, the key is rewritten into another memory area, from which it is used to decrypt the\r\ndownloaded module.\r\nThe CAB file retrieved from the PNG is available here: 001bdc26b2845dcf839f67a8760c6839\r\nIt contains core.sdb (d1a2fdc79c154b120a0e52c46a73478d). That is a second module in Hidden Bee’s custom\r\nformat.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 254 of 265\n\nInside core.sdb\r\nThis module (retrieved from the PNG) is a second downloader component in the 0x10000401 format. This time, it\r\nuses a custom TCP-based protocol, referenced by the authors as SLTP. (This protocol was also used by the\r\nanalogical component seen one year ago). The embedded links:\r\nsltp://dns.howtocom.site:1108/minimal.bin?id=998 sltp://bbs.favcom.space:1108/setup.bin?id=999\r\nExecution flow\r\n1. Checks for blacklisted processes. If any are detected, exits.\r\n2. Removes functions:\r\nDbgBreakPoint\r\n,\r\nDbgUserBreakPoint\r\nby overwriting their beginning with the RET instruction.\r\n3. Checks if the malware is already installed. If yes, exits.\r\n4. Creates an installation mutex\r\n{71BB7F1C-D700-4487-B9C6-6DD9863DFE91}-ins.\r\n5. If the module was run with the flag==1:\r\n1. Connects to the first address:\r\nsltp://dns.howtocom.site:1108/minimal.bin?id=998\r\n2. Sets an environment variable\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 255 of 265\n\nINSTALL_SOURCE\r\nto the value given as an argument.\r\n3. Runs the downloaded next stage module.\r\n6. If the module was run with the flag!=1:\r\n1. Performs checks against VM. If detected, exits.\r\n2. Connects to the second address:\r\nsltp://bbs.favcom.space:1108/setup.bin?id=999\r\n. This time, appends the victim’s fingerprint to the URL. Format:\r\n\u0026sid=\u0026sz=\u0026os=\u0026ar=\r\n3. Runs the downloaded next stage module.\r\nDefensive checks\r\nAt this stage, many anti-analysis checks are deployed. First, there are checks to detect if any of the blacklisted\r\nprocesses are running. The enumeration of the processes is implemented using a low-level function:\r\nNtQuerySystemInformation with a parameter 5 (\r\nSystemProcessInformation\r\n).\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 256 of 265\n\nThe blacklist contains popular debuggers and sniffers:\r\n“devenv.exe” , “wireshark.exe”, “vmacthlp.exe”, “procmon.exe”, “ollydbg.exe”, “idag.exe”,\r\n“ImmunityDebugger.exe”, “windbg.exe”\r\n“EHSniffer.exe”, “iris.exe”, “procexp.exe”, “filemon.exe”, “fiddler.exe”\r\nThe names of the processes are obfuscated, so they are not visible on the strings list. If any of those processes are\r\ndetected, the execution of the module terminates.\r\nAnother function deploys a set of anti-VM checks. The anti-VM checks include:\r\nCPUID with EAX=40000000 (a check for Hypervisor’s Brand):\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 257 of 265\n\nThe VMWAre I/O Port (more details [here]):\r\nVPCEXT instruction (more details [here])\r\nChecking the list of common VM vendors:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 258 of 265\n\nChecking the BIOS versions typical for virtual environments:\r\nDetection of any of the features suggesting a VM results in termination of the component.\r\nDownloading new modules\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 259 of 265\n\nThe next elements of HiddenBee are downloaded over the custom “STLP” protocol.\r\nThe raw TCP socket created to communicate using the SLTP protocol:\r\nThe communication is encrypted. We can see that the expected output is a shellcode that is loaded and executed:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 260 of 265\n\nThe way in which it is loaded reminds me of the elements we described recently in “Hidden Bee: Let’s go down\r\nthe rabbit hole“. The current module loads a list of functions that will be passed to the next module. It is a\r\nminimalistic, custom version of Import Table. It also passes the memory with the downloaded filesystem to be\r\nused for further loading of components.\r\nThe !rcx package\r\nThis element retrieves the custom filesystem used by this malware. As we know from previous analysis, Hidden\r\nBee uses its own, custom filesystems that are mounted in the memory of the malware and passed to its\r\ncomponents. This filesystem is important for the execution flow because it contains many other components that\r\nare supposed to be installed on the attacked system in order to continue the infection.\r\nAs mentioned before, unpacking the JPG gave us an !rcx package. After this package is downloaded, and its\r\nSHA256 checksum is validated, it is repackaged. First, at the end of the !rcx package, the list of URLs (JPG,\r\nPNG) from the previous module is copied. Then, the ARIA key is copied. The size of the module and its SHA256\r\nhash are updated. Then, the execution is redirected to the first stage shellcode fetched from the !rcx.\r\nThis shellcode was the one that we saw at first, after decoding the !rcx package from the JPG. Yet, looking at this\r\npart, we do not see anything malicious. The elements that are more important are well protected and revealed at\r\nthe next execution stages.\r\nThe shellcode from the !rcx package is executed in two stages. The first one unpacks and prepares the second.\r\nFirst, it loads its own imports using hardcoded names of libraries.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 261 of 265\n\nThe checksums of the functions that are going to be used are stored in the module and compared with the names\r\ncalculated by the function:\r\nIt uses the functions from kernel32.dll: GetProcessHeap, VirtualAlloc, VirtualFree, and from ntdll.dll:\r\nRtlAllocateHeap, RtlFreeHeap, NtQueryInformationProcess.\r\nThe repackaged !rcx module is supposed to be supplied as one of the arguments at the Entry Point of the first\r\nshellcode. It is most important because the second stage shellcode will be unpacked from the supplied !rcx\r\npackage.\r\nA new memory area is allocated, and the second stage shellcode is unpacked there.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 262 of 265\n\nInside the second shellcode, we see strings referencing further components of the Hidden Bee malware:\r\n/bin/i386/preload /bin/i386/coredll.bin\r\nThe role of the second stage is unpacking another part from the !rcx: an !rdx package.\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 263 of 265\n\nFrom our previous experience, we know that the !rdx package is a custom filesystem containing modules. Indeed,\r\nafter the decryption is complete, the custom filesystem is revealed:\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 264 of 265\n\nSo the part that was hidden in the JPG is, in reality, a package that decrypts the custom filesystem and deploys the\r\nnext stage modules: /bin/i386/preload and\r\n/bin/i386/coredll.bin\r\n. This filesystem has even more elements that are loaded at later stages of the infection. Their full functionality\r\nwill be described in the next article in our series.\r\nEven more hidden\r\nFrom the beginning, Hidden Bee malware has been well designed and innovative. Looking at one year of its\r\nevolution, we can be sure that the authors are serious about making it even more stealthy—and they don’t stop\r\nimproving it.\r\nAlthough the initial dropper uses components analogous to ones observed in the past, revealing their encrypted\r\ncontent now takes many more steps and much more patience. The additional difficulty in the analysis is\r\nintroduced by the fact that the URLs and encryption keys are never reused, and work only for a single session.\r\nThe team behind this malware is skilled and determined. We expect that the Hidden Bee malware won’t be going\r\nextinct anytime soon.\r\nSource: https://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nhttps://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/\r\nPage 265 of 265\n\n https://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/     \nThe communication is encrypted. We can see that the expected output is a shellcode that is loaded and executed:\n   Page 2 of 265",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/"
	],
	"report_names": [
		"the-hidden-bee-infection-chain-part-1-the-stegano-pack"
	],
	"threat_actors": [],
	"ts_created_at": 1775433984,
	"ts_updated_at": 1775791229,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/a5755989451fae6b2fa2b842491c8ff74e7d4c93.pdf",
		"text": "https://archive.orkl.eu/a5755989451fae6b2fa2b842491c8ff74e7d4c93.txt",
		"img": "https://archive.orkl.eu/a5755989451fae6b2fa2b842491c8ff74e7d4c93.jpg"
	}
}