To start things off, running floss.exe on the binary will provide some fruitful information in regards to what language is it written in, which in turn will give us information on how we will proceed with the analysis. In this case, there is the mscorelib and the .NET FRAMEWORK -version 4.7.2 strings that hint towards C#. With that in mind, we can use dnspy to do static analysis on the binary. Dnspy will provide us with the intermediate code of the binary.
The first interesting finding is that most likely the sample did not have the name as the one downloaded for analysis. The main program consists of two classes, as it seems, so lets jump right in the “Program” class.
Taking a look to the actual C# code, this dll appears to be creating an AES Encrypt/Decrypt password, which then is used to decode and decrypt a base64 string, that is afterwards written on the system in the public documents as `embed.xml` .
After that part, another base64 string is decoded, but not decrypted this time, and is written on the system as `embed.vbs`.
Lastly, the dll tries to create a persistence mechanism by creating a registry key that will run itself at user login.
With this information, and because dlls cannot be run directly, we can use cmd and the built-in binary of rundll32 in order to execute the binary, and generate the mentioned files to take a closer look at them. When using rundll32 there is also the need to put in as an argument the method you want to execute, to do that since we have it in clear text from dnspy, we just put a `,` after the dll file and type in the name of the method we need.
After running the above command, we are given the two files we were looking for, embed.xml in the public directory and embed.vbs in the public documents directory. And also the registry key for `embed.vbs` to be run on user logon. Moving forward, and opening the newly generated files with visual studio code, the visual basic script appears to be doing some basic function of running the `msbuild.exe` binary with the `embed.xml` file as an argument with the use of [`wscript.shell`](<http://wscript.shell>). The xml file is creating a new memory stream, giving a big compressed block of base64 which then appears to be ran as C# also.
Running the vbs script like it would be run each time during user login, while having `fakenet.exe` up and running (to fake a DNS Resolver), we are given this.
Which appears to be some kind of C2 communication, which with the name we have right here, `srv.masterchiefgruntemporium.local` and some google search, we can identify that this is a script for a covenant grunt. And if there is a covenant listener enabled on that C2 server, a grunt will spawn on the infected machine. So at the end of the day, we have a Grunt C2 Dropper, that is build from an `xml` builder script using a VBScript to call that `xml` file and all that is facilitated in the original `dll` file.