public static string tXmat8k68AD15JNkI0ZLvLcbh9NKczW8BvlBZb0NKczW8BvlBZbAmBtKbwu6wn6A()
    {
        // compiler generated "on error resume next" code excised
        byte[] hgrghk = new byte[24] { 46, 248, 3, 205, 79, 223, 48, 194, 157, 28, 73, 207,
            64, 110, 193, 246, 239, 23, 169, 135, 200, 121, 110, 230 };
        byte[] tmpwebshell = new byte[24] { 118, 67, 213, 247, 212, 109, 179, 250, 185,
            125, 44, 82, 118, 64, 226, 0, 125, 212, 185, 61, 135, 177, 30, 246 };
        byte[] carrier = new byte[24] { 85, 196, 232, 151, 14, 97, 20, 134, 82, 26, 214,
            184, 145, 233, 79, 79, 57, 122, 131, 156, 209, byte.MaxValue, 197, 11 };
        return Secrets.DecryptString(hgrghk, tmpwebshell, carrier);
    }

public sealed class Secrets
{
    internal static string DecryptString(byte[] hgrghk, byte[] tmpwebshell, byte[] carrier)
    {
        string s;
        byte[] bytes;
        
        bytes = Module7.DecryptData(hgrghk, Module8.GetMasterTDESKey(),
            Module8.GetMasterTDESIV());
        s = Encoding.Unicode.GetString(bytes);
        if (!string.IsNullOrEmpty(s) && Encoding.Unicode.GetBytes(s).SequenceEqual(bytes))
            return s;

        bytes = Module7.DecryptData(tmpwebshell, Module8.GetMasterTDESKey(),
            Module8.GetMasterTDESIV());
        s = Encoding.Unicode.GetString(bytes);
        if (!string.IsNullOrEmpty(s) && Encoding.Unicode.GetBytes(s).SequenceEqual(bytes))
            return s;
    
        bytes = Module7.DecryptData(carrier, Module9.GetMasterTDESKey(),
            Module9.GetMasterTDESIV());
        s = Encoding.Unicode.GetString(bytes);
        if (!string.IsNullOrEmpty(s) && Encoding.Unicode.GetBytes(s).SequenceEqual(bytes))
            return s;

        return "";
    }

    // ...

• let E be the byte array to be decrypted
  
• let M be a sequence of bytes (master key)
  
• let K be MD5(M)
  
• let IV be SHA256(M)
  
• let P be 3DES-CBC(K, IV, E)
  

    internal static void InitializeMasterKey()
    {
        MasterKeyBits[0] = WasDebuggerDetected();
        MasterKeyBits[1] = AreRunExeOrGhkExeOrStkrExeInstalled();
        MasterKeyBits[2] = ApplicationHasExeExtension();
        MasterKeyBits[3] = ApplicationDoesSystemAutorun();
        MasterKeyBits[4] = RunningFromDesktop();
        MasterKeyBits[5] = RunningFromDocuments();
        MasterKeyBits[6] = RunningFromSystem();
        MasterKeyBits[7] = RunningFromTemp();
        MasterKeyBits[8] = StartedManuallySoonAfterDrop();
        MasterKeyBits[9] = StartedByAutorun();
        MasterKeyBits[10] = ApplicationHasTmpExtension();
        MasterKeyBits[11] = RunningInVMAndApplicationOlderThan5Days();
        MasterKeyBits[12] = Module9.GetExeHasBasename1();
        MasterKeyBits[13] = Module5.CachedDoesHardwareIdFileExist();
    }

• WasDebuggerDetected: was a debugger ever attached to this process? if we don't know yet, is a debugger attached right now? predictably, this must always be false: if we attach a debugger, this flag will eventually go true (and stay true until the process terminates), the key will go bad, none of the sensitive strings will ever decrypt again and the malware will stop working, hindering analysis. it's a simple but really clever idea that completely kills automated deobfuscation through symbolic execution, and makes analyzing a live sample a real pain in the rear end
  
• AreRunExeOrGhkExeOrStkrExeInstalled: I mentioned that the sample I analyzed seems to be a simple dropper. it can drop up to three executables, internally named run.exe, ghk.exe and stkr.exe (on disk, they have different names - for example, run.exe can be called vasqy.exe, vrtdrv.exe, winxdrv.exe etc.). this check returns true if any of the three is currently installed in the system directory (windows\system32). surprisingly, bruteforcing the key reveals that this check must return true, which means an apparent chicken-and-egg problem: how can the dropper download those executables, if downloading them requires them to be already installed? well, if you read the code of DecryptString carefully, you'll see that there is, in fact, a second, distinct master key, used to decrypt the third byte array ("carrier"). we'll look at this in detail, later
  
• ApplicationHasExeExtension: whether the program's executable file is something.exe. true for "hgrghk", false for "tmpwebshell". this is our first hint that hgrghk, tmpwebshell and carrier are three distinct agents of this malware, sharing a common code base, but fulfilling different roles
  
• ApplicationDoesSystemAutorun: whether the currently running program is configured to autorun from the system-wide Run registry key. true for "hgrghk", false for "tmpwebshell", which suggests that hgrghk is the persistent agent
  
• RunningFromDesktop: whether we're running from the desktop folder, or a subfolder of the desktop. must always be false. a really simple anti-analysis roadblock
  
• RunningFromDocuments: same except from the documents folder
  
• RunningFromSystem: whether we're running from the system32 directory. predictably, true for "hgrghk", false for "tmpwebshell"
  
• RunningFromTemp: whether we're running from %tmp%. unsurprisingly, false for "hgrghk", true for "tmpwebshell"
  
• StartedManuallySoonAfterDrop: a relatively complex check. the process start time must be within 2 minutes from the executable's last write time, and the executable must not be configured for autorun. false for "hgrghk", true for "tmpwebshell", meaning that tmpwebshell agents are downloaded to %tmp%, executed immediately and must not autorun at logon. an anti-analysis trick to ensure that agents only work in a restricted set of expected circumstances
  
• StartedByAutorun: another non-trivial - and pretty clever - check. it finds a process named explorer.exe, takes it start time, adds 2 minutes, and returns true if the current process was started before then and if the current executable is configured to autorun. pretty much ensures that a malware analyst can't run an unmodified copy of this malware without some awkward gymnastics. mirrors the previous check, and must be true for "hgrghk" and false for "tmpwebshell"
  
• ApplicationHasTmpExtension: whether the program's executable file is something.tmp. false for "hgrghk", true for "tmpwebshell"
  
• RunningInVMAndApplicationOlderThan5Days: eyepyramid has a couple checks against running in a vm, and this is one of them. it queries wmi namespace root\cimv2 with query SELECT * FROM Win32_ComputerSystemProduct, which returns an object that represents the computer hardware. it queries this object's Name property, and sees if it contains the substring "virtual", which typically indicates a virtual machine (try it yourself in a windows vm, using builtin utility wbemtest). then, it takes the main executable's version number, x.y.z.w, and extracts the z and w fields, and uses them to build a timestamp (jan 1st 2000 + z days + w * 2 seconds). my sample has version 4.5.5519.26999, which comes out to february 10th 2015, two seconds to 3 PM, which agrees with the linker timestamp (Tue Feb 10 15:03:13 2015) and is almost certainly the build timestamp. RunningInVMAndApplicationOlderThan5Days takes these two values, and checks whether we're currently running in a VM and it's at least 5 days from when the malware was built. this check is expected to be false: we can only run in a VM within 5 days from the build time. probably both an anti-analysis check and a way for the malware author to do some in-house testing before deployment
  
• Module9.GetExeHasBasename1: whether the program's executable file is named plfyp.exe, pming.exe, etc. (see the trend micro article for the full list). perhaps surprisingly the expected value of this check is false, meaning that those names are reserved for the "carrier" agent
  
• Module5.CachedDoesHardwareIdFileExist: whether a file that uniquely identifies the current machine exists. must be true. this file is just an infection token, it contains 33 bytes of random garbage, and its name is the sha1 hash (in hex) of the utf-16 encoding of the hexadecimal representation of the sha1 hash of the utf-16 encoding of a concatenation of processor id, disk signature, computer system name and motherboard serial number (whew!). eyepyramid is this strange mix of pretty solid knowledge of malware development and analysis, and borderline inept use of .net. like how it's entirely written in procedural vb.net, using on error resume next and byref function arguments, using utf-16 instead of utf-8 (which I guess is entirely because the utf-16 codec class is called UnicodeEncoding, and the author was looking for the shortest, most obvious path from string to byte array). I'll hazard the guess that the author (or well, one of the authors) is an old school virus writer who never learned much about windows or high level programming languages, and taught himself vb.net for this project. he probably hadn't done any serious malware development in a while, but it's clear that he was somewhat on top of the state of the art of malware analysis
  

Where Your Count

hackbunny fucked around with this message at 05:19 on Jan 24, 2017

    internal static void InitializeMasterKey()
    {
        MasterKeyBits[0] = Module8.WasDebuggerDetected();
        MasterKeyBits[1] = GetExeHasBasename1();
        MasterKeyBits[2] = Module8.ApplicationHasExeExtension();
        MasterKeyBits[3] = Module8.ApplicationDoesSystemAutorun();
        MasterKeyBits[4] = Module8.RunningFromDesktop();
        MasterKeyBits[5] = Module8.RunningFromDocuments();
        MasterKeyBits[6] = Module8.RunningFromSystem();
        MasterKeyBits[7] = Module8.RunningFromTemp();
        MasterKeyBits[8] = Module8.StartedManuallySoonAfterDrop();
        MasterKeyBits[9] = Module8.StartedByAutorun();
        MasterKeyBits[10] = Module8.ApplicationHasTmpExtension();
        MasterKeyBits[11] = Module.GetSmallHardDiskAndNotXP();
        MasterKeyBits[12] = IsBuildOlderThan20150211();
        MasterKeyBits[13] = IsBuildOlderThan8Days();
        MasterKeyBits[14] = DateTimeUtils.IsClockAccurate();
        MasterKeyBits[15] = Module4.Computer.Network.IsAvailable;
    }

• WasDebuggerDetected: obviously false
  
• GetExeHasBasename1: true, as I expected. from now on, I can call the nebulously named "Basename1" entity "CarrierBasename", as it's the set of valid on-disk filenames (minus the .exe extension) for "carrier" type agents, making the decompiled code a little more readable. this newfound readability emboldens me to state that the sample I analyzed is a "carrier" type agent, and that, therefore, a "carrier" agent is a dropper that downloads other agents and executes them (including updates to itself)
  
• ApplicationHasExeExtension: true
  
• ApplicationDoesSystemAutorun: true
  
• RunningFromDesktop: false, as expected
  
• RunningFromDocuments: same
  
• RunningFromSystem: true, but it pretty much followed from ApplicationHasExeExtension being true
  
• RunningFromTemp: false, by exclusion. if the key was larger and bruteforcing impractical, I could slash the key space a bit by ensuring that only one of the RunningFrom flags could be true at the same time, reducing 16 possible cases to 5 and almost halving the key space twice
  
• StartedManuallySoonAfterDrop: false. this pretty much followed from ApplicationDoesSystemAutorun being true
  
• StartedByAutorun: true, predictably. mostly noting this to myself for future reference
  
• ApplicationHasTmpExtension: can't be true because ApplicationHasExeExtension is true
  
• GetSmallHardDiskAndNotXP: hey, now, this is an interesting check. it checks if the system disk is smaller than 50 GB and if the operating system name does not contain the string "Microsoft Windows XP"; expected value is false. I'm positive that this is an anti-vm check: if the disk is unrealistically small, and the machine isn't old enough to justify it, then we're probably running in a fake environment of some kind and not a real target
  
• IsBuildOlderThan20150211: false. what a weird check! it compares two static dates: the build timestamp encoded in the version number, and february 11th, 2015 (the next day). always evaluates to false, regardless of when, where and how the code is executed. very confusing
  
• IsBuildOlderThan8Days: false. it seems carrier agents are timebombed and automatically die if they can't update themselves after 8 days
  
• DateTimeUtils.IsClockAccurate(): I expected this to be true, and it was. what this check does is, every 5 hours, download the front page of a randomly chosen major website (among which amazon, aol, google and youtube), and derive the current date and time from the Date http header field. if the local clock is within 60 minutes of the remote time, then the check returns true. I have no idea why the carrier cares so much about this
  
• Module4.Computer.Network.IsAvailable: true. since the previous check defaults to true if the network isn't available, this ensures that true means we actually checked. I have never used vb.net so I'm not sure what's the meaning of the automatically generated module and all the machinery behind the "Computer" variable which is, in fact, a static property getter based on a, dunno, some kind of singleton based on System.Activator. I suspect com fuckery. I should use vb.net to see exactly what makes the compiler generate this kind of code
  

• a considerable amount of planning
  
• a certain degree of opsec (although with glaring mistakes that eventually killed the whole operation)
  
• knowledge of how malware is analyzed by malware experts and automated software
  
• a unusual and clever "store and forward" model of c&c where all communication between agents and console happens through a third party (specifically, wbem folders, imap folders and emails)
  
• self-updating software
  
• non-trivial features like provisioning x509 certificates
  
• a rather complex console that can push updates and receive operational logs from agents... written in vb.net
  

• vb.net for christ's sake, and entirely procedural vb.net at it. I found like one lambda function though, as a linq "where" expression
  
• clearly unfamiliar with medium-advanced programming concepts like encryption and unicode
  
• use of a commercial obfuscator that can be trivially defeated
  
• misuse of a commercial obfuscator in fact, as third party libraries like SevenZip and MailBee were left unobfuscated. reminder that this made it trivial for investigators to realize that the string "MN600-...-0E8C" was a MailBee license, which was tracked back to the occhioneros and led to their arrest. well if I get bored, I could try to crack MailBee's license key scheme
  

Bhodi fucked around with this message at 05:24 on Jan 24, 2017

Chalks fucked around with this message at 09:54 on Jan 24, 2017