Rhadamanthys and the 40 thieves - the nuts, bolts, and lineage of a multimodular stealer

Presented at Insomni'Hack: https://www.insomnihack.ch/talks-2024/#KCNGHJ

Transcript

1. Rhadamanthys & the 40 thieves The nuts, bolts and lineage of the multimodular stealer
2. What’s this talk about • Rhadamanthys stealer • a complex malware that appeared in 2022 • containing a large set of modules • interesting internal design
3. Contents 1. Quick Hands On Rhadamanthys: • Its earlier history & weirder features • Analyzing its stealers directly from a broken memdump 2. Untangling the complexity: • the logic behind the Rhadamanthys design • all the flavors of Rhadamanthys modules (native modules, LUA runner, plugins, and more)
4. Who are we? • Aleksandra „Hasherezade” Doniec • https://hasherezade.net • Ben Herzog • @bh11235@infosec.exchange
5. Earlier History & Weirder Features
6. Setting the Stage
7. Director of First Impressions
8. Initial Victomology & Success
9. Drive-by Danger
10. F U N C T I O N A L I T Y
11. Peak Targeting (1)
12. Peak Targeting (2)
13. Endless Productivity
14. From broken memdump to direct RE of infostealing
15. Fundamentals of RE
16. Expectation vs Reality
17. The other school of RE
18. The Goal in Sight
19. Strings?...
20. Aye, There's the Rub
21. So close, yet…
22. A Desperate Effort
23. Kludging a Copy of the DLL
24. Now for the Hard Part
25. Guess the DLL?..
26. Delta Hunting
27. Delta Hunting - Script
28. Delta Hunting - Results
29. Readable DB
30. Untangling the complexity The logic behind the Rhadamanthys design
31. Untangling the complexity
32. Untangling the complexity
33. Untangling the complexity • Rhadamanthys consists of modules • The core malicious modules will be downloaded only after the environment was checked • Only the first component is a PE: all the vital functionality is implemented in form of “shellcodes”
34. Untangling the complexity • Rhadamanthys consists of modules • It is organized in the way that the real malicious modules will be downloaded only after the environment is checked • Only the first component is a PE: all the vital functionality is implemented in form of shellcodes – well, not really. It uses custom formats, with a structure analogous to PE, yet completely reworked by the author to not resemble it
35. The custom formats • It is a form of obfuscation, which: • Is meant to mislead tools used for automated dumping (no artifacts that resemble PE can be found in memory – only code) • Makes the life of the analyst harder: unpacking and understanding of the important components require some reconstructive work • Components cannot be parsed by typical analysis tools
36. The staged loader • The first component is a standard PE (exe) Only the first module is a PE
37. The staged loader • The exe carries configuration and a package containing other modules The configuration including the C2 address A package with multiple other modules
38. The staged loader • The bootstrap shellcode is loaded In the version 0.5.0 the shellcode loaded from the package is filled into .textbss section. In other versions it may be loaded into a private memory
39. The staged loader • The shellcode loads the next component (Stage 2) The component in a custom format
40. The staged loader • The custom module continues with the loading The component in a custom format - another part of loding chain
41. The staged loader • Stage 2 loads other components from the package The next loader uses the configuration, and the passed package Loads more components from the package
42. The staged loader • The modules check the environment against monitoring tools the custom modules responsible for environment checks
43. The staged loader • The next module is run only if the environment is clean netclient: downloading and decrypting the next stage
44. The staged loader • The C2 should respond with a media file, carrying the payload The C2 is queried after all the environment checks passed The URL is retrieved
45. The staged loader • The media file: WAV or JPG Two options available: JPG or WAV Contains encrypted package Earlier version of RH used the following JPG
46. The staged loader • There is still a bit more complexity… Runs under the cover of one of the following : • credwiz.exe • OOBE-Maintenance.exe • openwith.exe • dllhost.exe • rundll32.exe
47. The final stage: components Module path Type Role /bin/i386/coredll.bin /bin/amd64/coredll.bin XS2 Main stealer module /bin/i386/stubmod.bin /bin/amd64/stubmod.bin XS2 Prepares a .NET environment inside the process, to load other .NET modules /bin/i386/taskcore.bin /bin/amd64/taskcore.bin XS2 Manages additional modules for the tasks supplied by the C2 /bin/i386/stubexec.bin /bin/amd64/stubexec.bin XS2 Injects into regsvr32.exe, and remaps the module into a new process /bin/KeePassHax.dll PE (.NET) Steals KeePass credentials /bin/runtime.dll PE (.NET) Runs PowerShell scripts and plugins in the form of .NET assemblies /bin/loader.dll PE (.NET) General purpose .NET assemblies runner Package #2 carries the components for the final stage
48. The XS format • Since version 0.4.5 Rhadamanthys uses a custom format with XS magic(two variants, XS1 and XS2) struct xs1_format { _WORD magic; _WORD nt_magic; _WORD sections_count; _WORD imp_key; _WORD header_size; _WORD unk_3; _DWORD module_size; _DWORD entry_point; xs1_data_dir imports; xs1_data_dir exceptions; xs1_data_dir relocs; xs_section sections[SECTIONS_COUNT]; };
49. The XS format • How it differs from the PE? Custom, unfamiliar header Atypical sections layout Customized data directories: relocations, imports, etc Obfuscated imports
50. The XS format • We were able to create a tool that can convert an XS component, dumped from memory, into a PE Reconstructed PE header Normalized sections layout Converted data directories: relocations, imports, etc Deobfuscated, easily parsable imports Converter: https://github.com/hasherezade/hidden_bee_tools/ tree/master/bee_lvl2_converter
51. The XS format • The XS header is a minimalist rework of PE header Deobfuscated, easily parsable imports struct xs1_format { _WORD magic; _WORD nt_magic; _WORD sections_count; _WORD imp_key; _WORD header_size; _WORD unk_3; _DWORD module_size; _DWORD entry_point; xs1_data_dir imports; xs1_data_dir exceptions; xs1_data_dir relocs; xs_section sections[SECTIONS_COUNT]; }; new field: XOR key for deobfuscation PE fields PE fields PE fields
52. The XS header obfuscation • After the loading completed, the header is overwritten with random bytes Before After
53. The XS format - sections • Not all sections that are in the raw format are to be loaded. It is determined by a flag if the section is to be loaded or not. Section #1 Section #2 PAGE_NOACCESS Section #3 PAGE_NOACCESS Inaccessible pages between sections make dumping contiguous memory harder
54. The XS format • Only 3 data directories Deobfuscated, easily parsable imports struct xs1_format { _WORD magic; _WORD nt_magic; _WORD sections_count; _WORD imp_key; _WORD header_size; _WORD unk_3; _DWORD module_size; _DWORD entry_point; xs1_data_dir imports; xs1_data_dir exceptions; xs1_data_dir relocs; xs_section sections[SECTIONS_COUNT]; };
55. The XS format - relocations struct xs_relocs { DWORD count; xs_relocs_block blocks[1]; }; struct xs_relocs_block { DWORD page_rva; DWORD entries_count; }; struct xs_relocs_block { DWORD page_rva; DWORD entries_count; }; struct xs_relocs_block { DWORD page_rva; DWORD entries_count; }; struct xs_reloc_entry { BYTE field1_hi; BYTE mid; BYTE field2_low; }; after the list of reloc blocks, there are entries in the following format: Relocations are stores as pairs, condensed into 3 bytes: • 1st byte, 1st nibble from the 2nd byte • 2nd nibble from the 2nd byte, and 3rd byte 0x184 ; 0x188
56. The XS format - imports struct xs1_import { _DWORD dll_name_rva; _DWORD first_thunk; _DWORD original_first_thunk; _BYTE obf_dll_len[4]; }; struct xs1_format { _WORD magic; _WORD nt_magic; _WORD sections_count; _WORD imp_key; _WORD header_size; _WORD unk_3; _DWORD module_size; _DWORD entry_point; xs1_data_dir imports; xs1_data_dir exceptions; xs1_data_dir relocs; xs_section sections[SECTIONS_COUNT]; }; The functions are resolved by checksums, that are stored in place of thunks The DLL names are obfuscated with the XOR- based algorithm, using the key from XS header The key from the main header is used to deobfuscate the DLL, and also in checksum calculation
57. The XS format- exceptions Registering the exception handlers in Rhadamanthys (64- bit)
58. The XS format- exceptions set additional flag: ImageDispatchEnable (make the custom module to be treated as MEM_IMAGE)
59. The lineage of the custom formats Malware Format Customized PE header? Customized imports? Customized relocations? Customized exception handling? RH >= 0.4.5 XS RH < 0.4.5 HS partial RH < 0.4.5 RS
60. The lineage of the custom formats Malware Format Customized PE header? Customized imports? Customized relocations? Customized exception handling? RH >= 0.4.5 XS RH < 0.4.5 HS partial RH < 0.4.5 RS Identical implementation of custom exception handling can be found in HiddenBee
61. The Hidden Bee miner diagram of the stages - source: https://www.trendmicro.com/en_us/research/18/g/new- underminer-exploit-kit-delivers-bootkit-and- cryptocurrency-mining-malware-with-encrypted-tcp- tunnel.html Diagram of the header of “BABECAFE” filesystem (based on ROM FS), containing a module in a custom NS format. Source: https://www.malwarebytes.com/blog/news/2019/05/hidd en-bee-lets-go-down-the-rabbit-hole The “NS” custom executable
62. The XS header obfuscation • NS (Hidden Bee) • HS (Rhadamanthys) Comparing the layout of the full header we can see a significant overlap
63. The lineage of the custom formats Malware Format Customized PE header? Customized imports? Customized relocations? Customized exception handling? RH >= 0.4.5 XS RH < 0.4.5 HS partial RH < 0.4.5 RS HiddenBee NS partial partially customized import table; same as in HS format
64. Similar modular design • The custom packages, having not only analogous structure, but even the same paths to the components! Rhadamanthys Hidden Bee
65. Similar modular design • Submodules referenced by paths in a format: /bin/amd64/[module_name] or /bin/i386/[module_name], often with .bin extension • The components may be injected into other processes, and loaded with the help of additional shellcodes • Overlap is so significant that Virus Total identified some of the Rhadamanthys shellcodes as Hidden Bee components
66. Who is the Rhadamanthys author? • Both Hidden Bee and Rhadamanthys seem to be a work of the same entity •A team? One skilled person? •Uses ideas and PoCs of others, but with good understanding •Also has his own, original ideas •Iteratively improve his work
67. Managing the army of thieves All the flavors of Rhadamanthys modules
68. Types of the modules • Native (XS format, delivered in the package) • LUA scripts (package) • The Plugin system: extendibility by custom .NET modules, following API • The runners for: • Custom .NET modules • PowerShell scripts • VBS an JScripts • and more…
69. The chief in command • The main module (core.bin) comes with a hardcoded set of stealers + allows to run submodules • Some modules are runners for other plugins and scripts: taskcore.bin, runtime.dll, loader.dll • communicates with the submodules over the named pipe, collects and sends the results • However: some modules can also speak directly to the C2
70. The hardcoded stealers • The stealers hardcoded in core.bin can be divided into two groups: Passive – parsing found configuration files Active – interfering with running processes
71. The LUA runner ID Type W wallets E e-mails F FTP N note-keeping apps M messengers V VPN 2 authentication related, password managers, etc. Example: DashCore wallet stealer Each ID represents a type of a target
72. The LUA runner • It can run up to 100 LUA scripts – of which we found 59 to be implemented Fetching LUA scripts
73. The LUA runner and the 59 scripts Armory AtomicDEX AtomicWallet Authy Desktop AzireVPN BinanceWallet BinanceWallet BitcoinCore CheckMail Clawsmail Clawsmail CuteFTP Cyberduck DashCore Defichain-Electrum Dogecoin Electron-Cash Electrum-SV Electrum EMClient Exodus Frame FtpNavigator FlashFXP FTPRush GmailNotifierPro Guarda Jaxx Litecoin-Qt Litecoin-Qt LitecoinCore Monero MyCrypto MyMonero NordVPN Notefly Notezilla SSH Outlook Pidgin PrivateVPN ProtonVPN Psi+ PuTTY Qtum-Electrum Qtum RoboForm Safepay SmartFTP Solar Wallet The Bat TokenPocket Total Commander Tox TrulyMail WinAuth WalletWasabi WindscribeVPN Zap all observed LUA stealers
74. .NET and PowerShell support • Although the core components are native code, Rhadamanthys puts a lot of emphasis on .NET and PowerShell • There are few different components that allow to run .NET and PowerShell plugins
75. .NET and PowerShell support • Bypasses AMSI and Event tracing via patching the responsible functions patch at the beginning of the function makes it exit immediately, returning a desired status
76. Integration of .NET and native modules • The whole .NET environment is manually created within the native Rhadamanthys module stubmod.bin
77. Integration of .NET and native modules Stubmod may be injected into different processes. It is used to run i.e. the KeePass stealer int __cdecl to_read_write_to_pipe( int seed, DWORD numberOfBytesToWrite, BYTE *data, int data_size ) Seed is a number required to recreate the pipe name
78. The simplest PowerShell runner The simplest version, replaced in 0.5.0 by much more complex Runtime.dll
79. The plugin system: runtime.dll • Since the release 0.5.0, there is a .NET module supporting the plugins with their own API The author announced SDK support, and provided documentation on his channel
80. The plugin system: runtime.dll • The new .NET module supports the plugins with their own API The plugins are .NET assemblies following the API Runtme.dll: the manager of .NET plugins
81. The native plugin runner: taskcore.bin • One more addition of 0.5.0 was introduction of yet another plugin runner: taskcore.bin
82. The native plugin runner: taskcore.bin • The module is implemented as XS (native Intel code) The central function within taskcore.bin works as dispatcher of commands with particular types
83. The native plugin runner: taskcore.bin • Running of the scripts (JScript, WScript, PowerShell) is implemented via COM interface (IActiveScript) The name “Rhadamanthys” is used as an identifier
84. Conclusions • Rhadamanthys is complex, and keeps evolving - we still didn’t cover it fully • Understanding the design helps reaching out parts that interest us the most •It’s easy to get lost in details: try to start with some concrete questions to answer
85. Read more… https://research.checkpoint .com/2023/rhadamanthys- v0-5-0-a-deep-dive-into- the-stealers-components/ https://research.checkpoint.co m/2023/from-hidden-bee-to- rhadamanthys-the-evolution- of-custom-executable-formats/ https://research.checkpoint .com/2023/rhadamanthys- the-everything-bagel- infostealer/