Monday, December 28, 2015

LogRhytm: How to recover SA password on Microsoft SQL Server 2008 R2

This article will come very handy if you ever end up in a situation like I did.
MS SQL Server installed (while installing LogRhythm) without prompting me to pick a password for SA account. Guess what - cant login.
Have a read, if you cant fins the article, DM, I'll send you a PDF.


Wednesday, December 23, 2015

SIEM - LogRhythm Installation

This document shows the installation process for LogRhythm XM after the MS SQL server has been completely
installed and updated to SP3.

Run the Installation Wizard

For XM, select ALL of the options and click on Install

  All Green. Click on Exit. 

Tuesday, December 22, 2015

Monday, December 21, 2015

Monday, December 7, 2015


Analysing and Reverse Engineering Ransomware
Vishal Thakur GIAC-GREM


Ransomware (CryptoLocker, CryptoWall, TeslaCrypt - many versions exist) has been the biggest and most effective malware type in recent years and apart from being quite effective and wide-spread, has also been one of the biggest money-makers for malware writers in the recent history of commercial-grade malware.
It is a widely accepted that the encryption caused by these malware is impossible to break. Which does not leave the victim with much choice other than paying the ransom and hope the they get the decryption keys as promised (if they do not have a working copy of the backup for encrypted data) or simply forget about the data that has been lost and move on.
While that maybe true for most cases - there are copies of these ransomware where the system is not relying on AES encryption based solely on Private and Public keys. I have come across ransomware that is using its own encryption engines (which is harder to protect against in some cases, as these do not rely on Microsoft’s CryptoAPIs at all). The one positive in this case is that it is possible to reverse these executables and find out what type of encryption is being used, which allows us to dig deeper and find out how to find the decryption keys. In some cases, the key is actually generated during execution (infection phase) and then sent back to the C2 servers. This makes it even easier to extract the artifacts that may contain the actual key (voila!) or at least lead us in the right direction.
Keep all of the above in mind, I decided to spend some time and effort in reversing an executable file derived from a ransomware code that encrypts data on the victim’s computer and then asks them to pay ransom in exchange of the decryption key. In the following sections, I provide step by step information on how the reversing was done and how the information can be used to get the decryption key.


For the purpose of this paper, we’ll call the executable ‘vishuwerehere.exe’. This file, when executed, targets the victim’s user directories and encrypts the data (a list of certain file extensions) using AES. It then creates a text file letting the victim know that their data has been encrypted and they need to pay the ransom if they want the decryption key.


  1. First step is to find out if the exe has been packed or not. Every reverse-engineer has his favorite tool for this purpose. I usually go for something like ExeInfo PE.
  1. As we can see, this one doesnt seems to be packed. We’ll find out in the next step if that is the case or not.
  2. Running the exe in BinText quickly confirms that - I get more than 200 strings, usually this would mean that the chances of this being packed are remote. We can also use something as simple as strings or strings2 for this and the result will be the same.
  1. Time to do what most reverse-engineers do next. Run it in IDA and then in Olly!
  2. In IDA, I’ll be looking for ‘interesting’ strings. Let’s take a quick look.


First things first
PeStudio gives you the functions that you are looking for in order to confirm what’s really happening here. ‘EncryptFile’ leaps out straightaway.
‘get_MachineName’ is being used to grab the computer name to identify the victim.
‘userName’ can be used in order to target data to be encrypted. Then there are the usual suspects - SHA256 (hashing) etc.  
Next, we look at the other strings that could give away more about the nature of the malware in question.
AES_Encrypt’ could mean two things. One of them is pretty bad and one of them could possibly be not so bad. Bad news is that the malware is using Asymmetric encryption to do the job - very hard to decrypt without the key. Not so bad news is that it is possible that the malware is not using a private key in the background for encryption. Why is it not so bad news? It could mean that the malware is generating the key locally and then sending  it off to the C2 - which means that there is a slight possibility that we can try to extract the key from memory or from the traffics that is going out over the network. Not essentially an easy task but nonetheless, it does provide some hope!
encryptDirectory’ is another string  that stands out. This simply means what it says.

Other than the obvious ones that I have mentioned above, there are a few more that sound interesting - more so from a curiosity angle than anything else.


This is where the fun begins! I have exclusively used OllyDbg for this one. There is a lot in this exe that needs to be looked at but here are a few that stand out and should be enough for us to get started and get a handle on this malware.
Most of the functions below are self-explanatory.

He is trying to get the computer name

Creating process - pretty basic stuff

There goes your sandbox

He doesn't wants to target certain OS versions

Now, that would be pretty helpful....

As I mentioned above, some of the functions above are pretty obvious and self-explanatory. 


Finding out the C2 connection that is being made is the easiest part. I call it the 3-step approach:
  1. Execute (in sandbox - most malware will run)
  2. Capture (use your fav tool)
  3. Analyse (Follow the stream and you’ll be served the complete URL on a platter)
More important than that (in most cases, the damage has already been done, you can only use the URL to block traffic to and from it into your network), you can reverse the malware and see if there is a chance that it was using a locally created key to encrypt the files rather than a public key based on a private key being held by the bad actors.
If you end up finding that the malware is relying on creating a local key, you still are in the game and there is a possibility of complete data recovery.
I have come across this scenario quite a few times in the past so it is definitely worth exploring and spending some time on trying to reverse engineer the malware. If nothing else, it will give you a better understanding of the threats that ransomware poses to your network.

Happy reversing!!