In this section we will be analyzing a Visual Basic script. To start things of, lets open the sample in Visual Studio to take a closer and clearer look at the code.

To start things off, there is a shell object created that will allow us to run “things” in a more primitive level (invoking system commands, that would otherwise need access to cmd.exe), which is the reason why (most likely) Visual Basic is chosen as well. After that, the object created will be called, in order to execute a couple of commands, the first two being the decoding of the two extra files found in the sample , and saving the outputs to two files in the \\public\\documents directory, and the last one being a call to cmd.exe in order to execute the first file that was created in the \\public\\documents directory. 

To continue the analysis, as seen above, the VBScript has to be ran in order to generate the decoded files, and give out something for analysis. 

one.vbs

Taking a quick look into one.vbs it is quite easy to understand that there is some sort of obfuscation going on with the a, aa, aaa and aaaa variables. The first two appear to be initialized in a kind of obfuscated fashion, and the other two are used to de-obfuscate them and use them later on. The de-obfuscation happens with the call to the `update` function. Moving on, a new object is created with the “new: XXXXXX” string, and that object is used to shell execute the contents of the aaa and aaaa with `runas` as a parameter. After that, the `update` function is being created, which essentially takes in two arguments, the first one being the variable that is going to be “updated” and the second one being the characters that will be updated. By the looks of it, the characters that will be “updated” will always be changed to “”, essentially deleting them, and giving back a “non-obfuscated” string. 

With that in mind, we can use the Find & Replace function of visual studio code to see what the a and aa strings actually look like. 

So the new object that is created as a COM class, will execute MSBuild.exe with xml.xml as a parameter. The `0` at the end of the API call means that it will execute with a hidden window. 

Taking a look at the xml.xml that is being passed as an argument to MSBuild.exe, we can see that some C# code is being passed bytecode (in hex) that is afterwards being executed, and if we use cyberchef to translate the hexadecimal to something more human readable, the bytecode essentially created a user which then adds to local administrators group and the users that are allowed to use RDP to connect onto that computer.