Between January 15 and 20, Morphisec identified a significant campaign targeting multiple German customers in manufacturing. Targeted personnel were redirected to compromised websites that were, and still are, delivering advanced fileless downloaders that eventually lead to an Osiris client with a bundled mini-Tor communicating to a C2 onion Tor panel.
After an additional investigation we shared some of the TTPs with the security community. We were then notified of additional targeted countries, including the United States and Korea, which were delivered REvil and other payloads using the same delivery mechanism as described in the report.
In this blog, we go over every stage of the attack chain in the German campaign.
The attack chain is composed of five main stages;
Figure 1: The Osiris attack chain.
The victim receives a link to a compromised website that contains a download link to a malicious zip file, which then contains a JS file. , the web page and the file name translates to “collective agreement on-call remuneration ig metal.”
The download as well as the rest of the attack chain communication will be available only to an IP located in Germany.
Figure 2: The compromised website.
The screen shot above is taken from the compromised website.
The JavaScript file inside the zip archive:
Figure 3: The JavaScript file.
The screenshot below is a formatted view of the malicious Javascript:
Figure 4: A formatted view of the malicious JavaScript
As seen above, the Javascript code is composed of dictionary generated code and includes real words in order to evade the static file scan used by AV solutions for obfuscation detection. It’s important to note that for every new download of javascript, the JS code won’t be exactly the same, but it will have a similar structure.
In order to deobfuscate the embedded code in all Javascript stages, the following code snippet can be used:
Figure 5: Deobfuscating the JavaScript
The “prove” variable (the long obfuscated string) actually contains the embedded next step obfuscated Javascript code that deobfuscates itself into:
Figure 6: The "prove" variable.
Note that for every new download of Javascript, the unique id is represented by the registry path generated within the “HKCU/<Random 5 letters>.” The “create” function is then called with the Javascript code execution in the next step.
As seen on the screenshot below, the Javascript contains three domains that the code attempts to communicate with. It’s worth mentioning that they are also compromised (those domains change every couple of days).
Figure 7: The three compromised domains the code communicates with.
The parameter for ‘search’ is also unique per download. The script identifies if the machine is located in a domain by expending the environment variable %USERDNSDOMAIN%. Depending on what it receives, it sends a different get request to the compromised website with a high possibility for a different malware.
The second stage formatted Javascript is delivered only to German IP addresses. The code already includes its next stage .NET code, which will be persisted into registry.
Figure 8: The second stage formatted JavaScript.
Figure 9: The JavaScript executing 32-bit Powershell
As seen above, the Javascript code will execute 32-bit Powershell using cmd. It identifies the OS architecture by validating the program files directory name extension.
The executed Powershell command reflectively loads the next stage .NET executable from registry represented by “HKCU:\SOFTWARE\<username>1”, but not before applying a minimalistic deobfuscation replacement algorithm on the value of the registry :
Figure 10: Reflective loading of the next stage.
A simple search in VirusTotal that is based on the replacement function “chba” will lead to previous versions of the Powershell that are dependent on “HKCU:\SOFTWARE\<machine name>1.”
As seen from the previous stages, the .NET loader is a small size code that is written to the registry by the second stage Javascript and is loaded to the memory by the third stage Powershell reflective loader
Figure 11: The .NET loader
The .NET loader will add additional persistence and is responsible for decoding the next step .NET hollower variant, which is located under “HKCU:\SOFTWARE\<machine name>” (without the 1).
Figure 12: The .NET hollower variant.
The .NET code under <username> is obviously much larger than the loader as it includes both the hollowing functionality and the Osiris code.
Figure 13: The .NET code containing hollowing and Osiris.
This .NET hollower injects the Osiris executable into a legitimate “ImagingDevice” executable that comes preinstalled with Windows as part of the Windows Photo Viewer software.
Figure 14: The .NET hollower injecting Osiris.
Following the hollowing, the Osiris executable uses its bundled mini-Tor component to communicate with a Tor panel. As can be seen below, the banking trojan still implements many of its original banker functionalities.
Figure 15: The Osiris executable uses a bundled mini-Tor.
Figure 16: Osiris retains some banker functionality.
Figure 17: Some banker functionality in Osiris.
Artifact file - bundled mini-Tor.
Figure 18: A bundled mini-Tor.
The Osiris trojan attacking German IP addresses continues the trojan’s historical use. The Morphisec platform blocks Osiris with a zero-trust default-deny approach to endpoint security, powered by moving target defense. Customers of Morphisec are thus protected from Osiris, regardless of what defense evasion techniques the authors deploy.
EC936B6BB7497FFB11577C14A9AB2860EC1DD705DC18225BBDAB5BF57804BDBC - JS
72C5EEB8807A4576340485377CACC582A3CA651C4632DB06903C125BE6692968 - .NET module <username1>
63C62D6086A6CF2FCBB22A16C06EB0BC870CDB2F0BB029390D3BC815C06A6C6B - .NET module <username>
2FC970B717486762F6C890F525329962662074EB632F0827C901FB1081CBD98F - Osiris
91F1023142B7BABF6FF75DAD984C2A35BDE61DC9E61F45483F4B65008576D581 - Minitor www.underregnbuen[.]dk/?p=5739 - the compromised website
hxxp://ylnfkeznzg7o4xjf[.]onion/kpanel/connect.php - Osiris C2