• it was written in visual basic .net. this is super obvious from the heavy usage of the vb.net runtime library, but also from certain other characteristics of the code (I'll explain later). arguably, by a programmer not terribly familiar with the language
  
• symbols (with some glaring omissions) have been obfuscated into big random strings. I'm unfamiliar with .net obfuscators and can't tell if it's a known commercial obfuscator or not (e: DURRRH it says dotfuscator right there I'm dum)
  
• all strings have been obfuscated with an algorithm that's rather trivial to reverse through symbolic execution. if I had a tool like simplify for .net, I could strip this layer of obfuscation in a matter of seconds. I don't and I'm lazy and nobody is paying me for this, so I did it by hand. symbol names of the deobfuscation code have some irregularities that suggest that the string obfuscation class is part of the same suite as the symbol obfuscator
  
• this is where it gets interesting. sensitive strings, such as phone-home addresses and credentials, have been obfuscated with a second, separate obfuscator, that doubles as an anti-debugging/anti-analysis component. symbolic execution won't help: the deobfuscation key isn't hardcoded, but it's derived from 16 runtime checks (was a debugger detected? is the malware in the autorun list? are we running in a vm? etc. and much more specific and kinda bizarre conditions). since it boils down to a 16 bit 3DES key, it's really easy to blindly bruteforce the entire key space, but still. those fuckers. well, don't come tell me someone with no experience in malware writing came up with this. don't tell me it's a commercial component they bought either, because a bug/omission in the symbol obfuscator left some symbols in cleartext, and by googling them all hits are from earlier variants of eyepyramid
  
• finally, an assembly linker was used to merge external libraries (such as the aforementioned mail component with which the siblings doxxed themselves) into the executable. I can totally believe they did this part themselves because instead of link-then-obfuscate, they obfuscate-then-link, making it trivial to separate the external libraries from the malware and greatly simplifying the analysis
  

  public static void f6J8eFg3YUvv4j3xEUTV3E1CEBj3xEUTV3E1CE0PYUanFmGRebVA0srGwqvHpDYA()
  {
label_0:
    int num1;
    int num2;
    try
    {
      ProjectData.ClearProjectError();
      num1 = 1;
label_1:
      int num3 = 2;
      if (kPd9dIhV/* long name omitted */.hhqKbrLk/* etc. */())
        goto label_8;
label_2:
      num3 = 5;
      if (!erRFjb3s/* ... */.HEKvagU1/* ... */())
        goto label_8;
      else
        goto label_8;
label_4:
      num2 = num3;
      switch (num1)
      {
        case 1:
          int num4 = num2 + 1;
          num2 = 0;
          switch (num4)
          {
            case 1:
              goto label_0;
            case 2:
              goto label_1;
            case 3:
            case 6:
            case 7:
              goto label_8;
            case 4:
            case 5:
              goto label_2;
          }
      }
    }
    catch (Exception ex) when (ex is Exception & (uint) num1 > 0U & num2 == 0)
    {
      ProjectData.SetProjectError(ex);
      goto label_4;
    }
    throw ProjectData.CreateProjectError(-2146828237);
label_8:
    if (num2 != 0)
    {
      ProjectData.ClearProjectError();
    }
    else
    {
      int num3;
      int num4;
      while (num3 == num4)
      {
        num4 = 1;
        int num5 = num4;
        int num6 = num3;
        num3 = num5;
        if (num3 > num6)
          break;
      }
    }
  }

  public static void f6J8eFg3YUvv4j3xEUTV3E1CEBj3xEUTV3E1CE0PYUanFmGRebVA0srGwqvHpDYA()
  {
    ProjectData.ClearProjectError();

    if (kPd9dIhV/* ... */.hhqKbrLk/* ... */())
      goto label_8;

    if (!erRFjb3s/* ... */.HEKvagU1/* ... */())
      goto label_8;
    else
      goto label_8;

label_8:
    return;
  }

  public static void f6J8eFg3YUvv4j3xEUTV3E1CEBj3xEUTV3E1CE0PYUanFmGRebVA0srGwqvHpDYA()
  {
    if (!kPd9dIhV/* ... */.hhqKbrLk/* ... */()) {
      erRFjb3s/* ... */.HEKvagU1/* ... */();
    }
  }

  public static int x4SlgKmPmgp18FZP4R6VdaGkIBKWb9HjgdCqVbAKWb9HjgdCqVbAoM5WyXRRPRuA(bool install = false)
  {
    int num;
    try
    {
      string olw48CagNqKpmDleguA = Xpg7jswb/* ... */.JdKDN9YX/* ... */;
      // ISSUE: explicit reference operation
      // ISSUE: variable of a reference type
      string& keypath = @olw48CagNqKpmDleguA;
      string zkpk2Ax1Q44ZvmyRpA = Xpg7jswb/* ... */.gNqKPmDL/* ... */;
      // ISSUE: explicit reference operation
      // ISSUE: variable of a reference type
      string& keyname = @zkpk2Ax1Q44ZvmyRpA;
      // ...

hackbunny fucked around with this message at 06:31 on Jan 17, 2017

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

    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
  

• vb has byref variables, but c# can only do ref arguments
  
• vb's on error resume next construct yields a spaghetti dish of switches, gotos and try-excepts that no decompiler can currently unravel
  
• vb emits exception catch filters that can't be expressed in c#
  

Microsoft (R) COFF/PE Dumper Version 14.00.23918.0
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file d3ad32bcb255e56cd2a768b3cbf6bafda88233288fc6650d0dfa3810be75f74c.bin

File Type: EXECUTABLE IMAGE

  clr Header:

              48 cb
            2.05 runtime version
           CFF54 [  10DD60] RVA [size] of MetaData Directory
               1 flags
                   IL Only
         600003D entry point token
          1DDCB4 [    6E02] RVA [size] of Resources Directory
               0 [       0] RVA [size] of StrongNameSignature Directory
               0 [       0] RVA [size] of CodeManagerTable Directory
               0 [       0] RVA [size] of VTableFixups Directory
               0 [       0] RVA [size] of ExportAddressTableJumps Directory
               0 [       0] RVA [size] of ManagedNativeHeader Directory


  Summary

        2000 .reloc
       42000 .rsrc
        2000 .sdata
      1E4000 .text

.class /*02000009*/ public auto ansi sealed kYtRMaTKS2nV0kYtRMaTKS2nVAPOcntMo7f1m7A1LkTwxy7wES1A1LkTwxy7wESA
       extends [mscorlib/*23000001*/]System.Object/*01000012*/
{
  .custom /*0C000027:0A000012*/ instance void [Microsoft.VisualBasic/*23000002*/]
Microsoft.VisualBasic.CompilerServices.StandardModuleAttribute
/*01000014*/::.ctor() /* 0A000012 */ = ( 01 00 00 00 ) 
  .method /*0600003D*/ public static void 
          sCmC2l6KkDsh1x8asULRL1PGbAx8asULRL1PGbABAvEd7g8ENYEAFxPIULW8eacA() cil managed noinlining nooptimization
  {
    .entrypoint
    // ...

• lower the security level of office suite applications, including apparently whitelisting dangerous attachments in outlook
  
• lower the security level of internet explorer (or so I assume)
  
• adds several antivirus main executables (avgnt.exe, avguard.exe, etc.) under the DisallowRun group policy. the article mentions this too
  
• disables wpf sandboxing or something like that
  
• disables all security center and windows firewall alerts. nasty!
  
• specifically disables "antivirus disabled" security center alerts for a dozen av products
  
• mucks with a couple security policies: sets EnableLUA to 0 and LocalAccountTokenFilterPolicy to 1. no idea what these do but it can't be anything nice
  
• enables the clearing of the swap file at shutdown. not sure what this is meant to accomplish
  
• disables the security center service for good measure
  
• configures some services for autostart, like CryptSvc, HTTPFilter (server-side https, part of iis), ose (part of the office installer), WebClient (webdav client), wuauserv (Windows update). weird, weird, weird! most of these make sense but what does it care about HTTPFilter or ose?
  
• the weirdest yet: configures the windows time service. default.reg contains a full dump of the configuration from (I assume) the dev's machine, but I'm not sure what are the relevant parameters. some parameters, in fact, seem completely obsolete in windows 10, and I wonder if applying this configuration isn't actually liable to screw up the time service unpredictably. the parameters that I can find on my machine, on the other hand, have identical values, so I wonder if it's just meant as a way to reset the configuration to the default
  

• for each of program files directory, 32-bit program files directory, local app data, common program files:
  • for each subdirectory (Ad-Aware Antivirus, Alice Total Security, AhnLab, etc.), if it exists:
    • recursively grant full access to administrators, users, system. some antivirus software protects itself with restrictive acls and I guess this is supposed to undo that protection
      
    • recursively revoke full access to current user. I suppose this is to (superficially) prevent the user from fixing it
      
    • recursively, for each file: deny access to system, users, administrators. this prevents the targeted antivirus software from running or accessing any of its files
      

hackbunny fucked around with this message at 15:15 on Jan 31, 2017

hackbunny fucked around with this message at 06:10 on Feb 13, 2017