LuminosityLink – Extracting The Config of 1.0 and 1.1

June 4, 2015

RATS are often not taken seriously in my opinion within malware, I’m not trying to go all APT on everyone here but groups doing large scale operations still use these as a simple and easy way to control systems. Take all these articles with a pinch a salt but it’s evident that it’s not just skids that use Remote Administration Tools. Many will use such tools due to how easy they are to use, they can be a gateway to initial infection, in which a attacker will then launch a more specialist strand of malware into the system to perform the original task.

Article #1

Article #2

Article #3

I decided to look at a emerging “stable” RAT that was released early April. It’s called LuminosityLink, the developer has previous experience in malware with being the author of the malware named “PLASMA HTTP”. I found a XSS vulnerability in this certain strand of malware and was able to takeover some panels and kill some botnets. It slowly dried up, I did not follow it religiously so I’m not fully aware of why they stopped creating updates for PLASMA HTTP. Perhaps they needed a break or did not like coding a HTTP bot, nevertheless, they strayed to RATS, in which LuminosityLink has gained attraction.

The peice of malware is ofcourse written in .NET but uses a custom obfuscator which I assume is why no one has released an article about this yet. I decided to delve in and see what I could find, this first article will show how easy it is to extract the config of LuminosityLink. The author has released 2 versions so far, this method of config extraction works on both, they are relatively the same. There is frequent usage of Confuser and ConfuserEx within .NET malware, but is still trivially bypassed. This is why I assume the developer has decided to either choose a relatively unknown obfsucator or has created their own. In this article I won’t be discussing the obfuscation methods and will be solely looking at the config decryption, first of all here is a screenshot to show what it looks like.

I prefer to use both ILSpy and Net Reflector for reverse engineering as sometimes they spit out different things which is great to compare. In this article I will simply be using ILSpy because it’s free and anyone is able to download it. One thing I knew for sure that was going to be in the config was the host most likely a no-ip domain or something similar. So my main task was to first find the TCP client that was going to be holding the connection, it didn’t take too long to find a call on a TCP client. The first parameter will be the host the second will be the port as we can see they are held somewhere is in the assembly.

bIt was time to search pb.t in pb, It wasn’t long before I found it within a method, it seemed to be part of an array and so I concluded from here that there was a config string or file where some variables were held. I looked around for a while and found that most of the focus was on tb.a which seemed to be where this had come from. The <Module>.c is a method that passes three numbers and decrypts strings from a resource.


I had followed <Module>.c and developed a string decrypter so I could see what was going on, what was interesting is what the second tb.a parameter gave back. For a while I didn’t think it was correct, but yes, it seemed “Specify a Password” was the correct string used for this operation. I was now intrigued at this method and decided to look at what the first parameter was.

dIt looks like the kc.a was the answer to what we were looking at when we saw the variable defined in this first parameter, this is where we should go next to find what is going on to get the config. I now had the suspicion it was going to decrypt since the string “Specify a Password” was used.

eLooks like we were going to go in the resources to find something, I used my string decrypter to find out that we’d be using “SMARTLOGS”. It seems like the config was held in a .NET resource, which made things a little easier I guess.

fWe now have to go back and see what tb.a is doing and work out how to implement this into our own solution. The biggest part that confirmed to me that I was doing this correctly was the base64 decoding, the SMARTLOGS resources was base64 encoded first of all.

gAfter a while I correctly got it working as I was able to decrypt the configuration. Here’s the c# code I hacked about with.

We can see in the code I had a bit of a problem with the length, Net Reflector and ILSpy are great but won’t get everything for you. You have to work out the puzzle and try and see if it works, it was a relatively straight forward solution, I just didn’t think correctly at the time. I eventually got the correct length (128) and was now able to get my SMARTLOGS resource. The SMARTLOGS resource will be available in one of the resource folders, I can’t remember if the name changes, atleast I think so in 1.0 and 1.1, but it’s very easy just to grab the resource out with ILSPY. So the first parameter you should paste the SMARTLOGS string and the second is a static password “Specify a Password”. From my experience every single bin built with LuminosityLink has the config password “Specify a Password”, which is a little comical in my view.

hI blocked some parts out because I haven’t looked through it all yet, one of the things I blocked is a hash, I’m unsure if it’s a unique identifier so I left it out.


One thing to say about this is that people raving about this peice of malware evidently haven’t dissected it. I’m unsure if I’d be happy to have “Specify a Password” as my password, but that’s just me. A decent effort from the author, from what I’ve seen has some interesting features that I’m sure I’ll look into.