- May 14, 2016
- 1,597
I read the news on a website, few days ago, and today I've seen , added at the end :
"UPDATED 18:55 2016-06-21
Necurs has just begun spamming a new Locky campaign, this time with a clean binary featuring updated anti-vm code, so you could probably say both Necurs and Locky are definitely not dead."
An interesting sample :
https://www.virustotal.com/fr/file/...81812d677d576f2d133d5a20a65885538a0/analysis/
15/55
I found a very good analyse/tutorial with this sample as example.
Below, a small part, to make you wonder to go and read the full analyse.
malcat wrote :
"So our first layer of obfuscation becomes clear: a variable is declared and a string value containing the body of JavaScript to be executed is built, joined together, and reversed.
While my first avenue to make this more readable was to replace the eval function at the end with console.log, a helpful friend pointed out that it was far simpler to use a quick Python one liner. So that’s what we will do!
We can write out the value of the above variable to a file by first declaring it, and then using the following:
with open(“locky_reversed.js”, “w”) as outfile:
outfile.write(avG1mfH[::-1])
This will open the variable (avG1mfH), reverse it, and write it to the file locky_reversed.js. The output should look similar to this:
It burns us! We need to js-beautify this monstrosity post-haste.
That’s much better. At least, until we look closer at it and realize it’s not better at all; it’s still completely unreadable. Let’s take a look at a few of the tactics used here:
First, there are a ton of variables initialized which are never referenced in the code. These are, based upon my analysis, there simply to confuse analysts who want to look at the sample and understand what it is doing. The first thing we can do is find variables which are initialized but never called later in the script and strike them down where they stand! As far as I can tell, they serve no purpose. Your methodology here will vary; I opted for the way of pain, and used Notepad++’s find/replace functionality.
Second, we will see a number of functions declared that appear to do nothing but return the same parameters fed to them. Here’s an example:
Later in the script, we’ll see the same function called with a different parameter; all it will do is return whatever parameter is fed to it when it is called. Let’s look at an example for the above function EOSu0:
"EOSu0(writ)
This will return the value “writ”. Keep this in mind as we proceed.
...
...
"
To read more (full analyse) : Return of Locky – Malcat! Mew!
"UPDATED 18:55 2016-06-21
Necurs has just begun spamming a new Locky campaign, this time with a clean binary featuring updated anti-vm code, so you could probably say both Necurs and Locky are definitely not dead."
An interesting sample :
https://www.virustotal.com/fr/file/...81812d677d576f2d133d5a20a65885538a0/analysis/
15/55
I found a very good analyse/tutorial with this sample as example.
Below, a small part, to make you wonder to go and read the full analyse.
malcat wrote :
"So our first layer of obfuscation becomes clear: a variable is declared and a string value containing the body of JavaScript to be executed is built, joined together, and reversed.
While my first avenue to make this more readable was to replace the eval function at the end with console.log, a helpful friend pointed out that it was far simpler to use a quick Python one liner. So that’s what we will do!
We can write out the value of the above variable to a file by first declaring it, and then using the following:
with open(“locky_reversed.js”, “w”) as outfile:
outfile.write(avG1mfH[::-1])
This will open the variable (avG1mfH), reverse it, and write it to the file locky_reversed.js. The output should look similar to this:
It burns us! We need to js-beautify this monstrosity post-haste.
That’s much better. At least, until we look closer at it and realize it’s not better at all; it’s still completely unreadable. Let’s take a look at a few of the tactics used here:
First, there are a ton of variables initialized which are never referenced in the code. These are, based upon my analysis, there simply to confuse analysts who want to look at the sample and understand what it is doing. The first thing we can do is find variables which are initialized but never called later in the script and strike them down where they stand! As far as I can tell, they serve no purpose. Your methodology here will vary; I opted for the way of pain, and used Notepad++’s find/replace functionality.
Second, we will see a number of functions declared that appear to do nothing but return the same parameters fed to them. Here’s an example:
Later in the script, we’ll see the same function called with a different parameter; all it will do is return whatever parameter is fed to it when it is called. Let’s look at an example for the above function EOSu0:
"EOSu0(writ)
This will return the value “writ”. Keep this in mind as we proceed.
...
...
"
To read more (full analyse) : Return of Locky – Malcat! Mew!
Last edited:
