Reversing NMHH "Vegleges torles" app

Recently https://veglegestorles.hu/ was introduced by NMHH as a means to "compliant removal of sensitive data from devices" which you can only use by pasting a ?one-time? code found on your newly bought device. Knowing NER and friends, we expected with reason that the whole thing is yet another (remember pegasus?) stunt to promote malware. Let's check out the insides.

The first funny thing is how they didn't even bother to hide their thirdparty "dependence" (if not straight up license infringement, who knows):

First, to download the installer, you don't need a valid code from a device. One option is to go https://certussoftware.hu/ or get the direct link from main.js by searching for https keywords:       

 cutDownloadUrl: 'https://' + window.location.hostname + '/download/products/ceceut/hu/cece_usb_tool_setup.msi'

Static Analysis

Extracting this file with 7z results in CECE_USB_Tool.exe and dd.exe (LOL).

Pulling CECE_USB_TOOL.exe into r2 resulted in no standard winapi symbols which was a sign for me that it's a shitty C# project.... and I was right. I put it into an IL decompiler and saw that it was processed trough Fody+Costura.
The executable also had some anti-reversing and anti-debug features like allocating writable memory to unpack shit and isDebuggerPresent. Not a good start for something that's supposed to be "Compliant to data privacy and security laws".

The first two files I was interested in is ofc main.cs and DownloadUpdate.cs as these two are most likely to do something fishy over the internet. main.cs is desperately trying to connect to the internet in a loop but no shady behavior overall.

As for the update mechanism (`DownloadUpdate.cs + SelectDeviceControl.cs`), while downloads do check a checksum I would expect an embedded public key and a signature check instead. While I can forge a hash with no auditable binding information to Certus, I cannot do the same with an EUF-CMA signature:

     if (string.Equals(writeVersion.FileChecksum, GetChecksum(path + filename), StringComparison.OrdinalIgnoreCase))

Next up is just pure laziness:

  private bool check_secure_boot()
  {
   string str = "powershell Confirm-SecureBootUEFI";
   ProcessStartInfo val = new ProcessStartInfo();
   val.set_UseShellExecute(false);
   val.set_CreateNoWindow(true);
   val.set_WorkingDirectory("C:\\Windows\\System32");
   val.set_FileName("C:\\Windows\\System32\\cmd.exe");
   val.set_Arguments("/c " + str);
   val.set_RedirectStandardOutput(true);
   val.set_WindowStyle((ProcessWindowStyle)1);
   Process obj = Process.Start(val);
   obj.WaitForExit();
   return bool.Parse(obj.get_StandardOutput().ReadToEnd());
  }

I wonder how this was not caught by virustotal? Running powershell commands in a cmd subprocess? C# has a builtin API for this...

Dynamic Analysis

But to my biggest surprise I haven't found any suspicious code from the static analysis so far. If there is anything going on with deletion behind the scenes it has to be through the Costura embededd DLLs:

static AssemblyLoader()
  {
   assemblyNames.Add("costura", "costura.costura.dll.compressed");
   assemblyNames.Add("fontawesome.sharp", "costura.fontawesome.sharp.dll.compressed");
   assemblyNames.Add("microsoft.aspnetcore.http.abstractions", "costura.microsoft.aspnetcore.http.abstractions.dll.compressed");
   assemblyNames.Add("microsoft.aspnetcore.http.features", "costura.microsoft.aspnetcore.http.features.dll.compressed");
   assemblyNames.Add("microsoft.bcl.asyncinterfaces", "costura.microsoft.bcl.asyncinterfaces.dll.compressed");
   assemblyNames.Add("microsoft.extensions.primitives", "costura.microsoft.extensions.primitives.dll.compressed");
   assemblyNames.Add("microsoft.windowsapicodepack", "costura.microsoft.windowsapicodepack.dll.compressed");
   assemblyNames.Add("microsoft.windowsapicodepack.shell", "costura.microsoft.windowsapicodepack.shell.dll.compressed");
   assemblyNames.Add("syroot.knownfolders", "costura.syroot.knownfolders.dll.compressed");
   assemblyNames.Add("system.buffers", "costura.system.buffers.dll.compressed");
   assemblyNames.Add("system.memory", "costura.system.memory.dll.compressed");
   assemblyNames.Add("system.numerics.vectors", "costura.system.numerics.vectors.dll.compressed");
   assemblyNames.Add("system.runtime.compilerservices.unsafe", "costura.system.runtime.compilerservices.unsafe.dll.compressed");
   assemblyNames.Add("system.security.principal.windows", "costura.system.security.principal.windows.dll.compressed");
   assemblyNames.Add("system.text.encodings.web", "costura.system.text.encodings.web.dll.compressed");
   assemblyNames.Add("system.text.json", "costura.system.text.json.dll.compressed");
   assemblyNames.Add("system.threading.tasks.extensions", "costura.system.threading.tasks.extensions.dll.compressed");
   assemblyNames.Add("system.valuetuple", "costura.system.valuetuple.dll.compressed");
}

As I do not know, nor do I wish to learn how Costura compresses these DLLs, I resorted to dynamic analysis with https://cuckoosandbox.org/

I imported my cuckoo report so you can check it out: https://cuckoo.cert.ee/analysis/2517487/summary/

4.6 out of 10.

A concerning amount of malware-like behaviour. You can justify the anti-debug finding with your classic "sOfTwArE iNteLlEcTuAl pRoPeRtY" bullshit, but that doesn't explain why a removal tool takes screenshots.

Unfortunately I wasn't able to extract which exact screenshot rule cuckoo is using with YARA

Next up in the dynamic adventures is a series of findings that triggered my sniffer meter.

First is the MODIFICATION OF SYSTEM CERTIFICATES:

This is a common way for malware for the preparation of sniffing TLS encrypted traffic. If your external stuff is expected to be encrypted, and hardware access is likely to be UACed by the user, why not place your own root certs into the system ¯\_(ツ)_/¯

Heck it even modified the System Security Policy settings:

And as the last step to set up the sniffNER, it changed our system proxy settings:

So in order: Modify System security policies -> Place new Root Certificate in system -> Set new system-wide proxy :)

Another interesting key that gets accessed:
HKCU\SOFTWARE\MICROSOFT\INTERNET EXPLORER\SECURITY:: DISABLESECURITYSETTINGSCHECK

But disabling IE security check is only the cherry on top after a system-wide sniffer is deployed.

Conclusion

Even though static analysis did not result in any findings, my original hunch that the packed DLLs might have been injected is more likely to be correct now. I haven't interacted with an actual USB stick during this dynamic analysis, but the order of logic in which the registry values were overwritten is an undeniable sign of sniffing. No suspicious network traffic was detected, most likely due to my lack of interaction with an actual device. In overall the dynamic findings triggered my NER meter :)