Hello and welcome to the second lecture of course.
Same as before we will go through a dynamic and static analysis of another ransomware sample.
Then will reverse engineer the encryption routine and recover the affected files
same as before.
We'll go to the housekeeping rules although already covered.
This is important then it's worth reiterating always run malware or known files in a secure virtual
machine.
Don't risk infecting your host or other machines on the network repair snapshot before the matches.
Otherwise you risk losing your files and time.
Make sure that any shared drives or for that is that the virtual machine has right access to only contain
disposable data do not store anything confidential because you risk being a creepy dolls disable Internet
connectivity of the analyses virtual machine otherwise you risk x guilt rating sensible information
and even tipping off the attackers.
The aim of any creep third is to force the victim to pay a ransom of money in order to have their files
decrypted once they have been infected.
As we've seen in the previous video sometimes it's worth trying to understand what we're dealing with
instead of rushing to pay the ransom.
Although the creators claim strong encryption has been used this is very difficult to do correctly and
easy to myself.
Sometimes there is no incentive for ransom letter writers to even bother if they can be effective even
with simple reversible encryption.
In this session we will analyze our second creator name Blue Dot Exxon.
It is a good practice to obtain the empty five hash of the file.
We want to analyze this way we can search it online on a number of resources like sand boxes and then
deep analytical antivirus scanners.
This second example we're going to look at is also quite simple.
However he does a few new tweaks the analyzing process is the same.
Firstly we are trying to figure out what the program is doing by performing some dynamic analysis.
Start Process Explorer and process monitoring after running the creep.
Third you will notice a suspicious executable running as V.C. hosts the attacks.
Although this name is used by allegedly made familiar windows process this one is clearly deceiving.
Notice the order icon and the path containing Adobe Systems also created to deceive a casual observer.
Another giveaway is that the fake as we see hosts not exit is not signed.
Clearly not the case for our real Windows Service.
Well another tweak is to help the analysis to use Process Explorer suspend the process right click on
its name in the process 3 then select suspend.
This will allow us to see what has happened before and will all the encryption of our files until we
resume its execution process monitor will be flooded with events.
So it's always good to reduce the activity to be analyzed to simplify our war we'll set up the following
to feel thirsty process money thought process name is low that exit operation is right filed by filtering
the right file operations process money Thor and the regional creep third name we will see how the second
stage executable is dropped in the second image we see that's fake as we see holes being written thirty
two kilobytes chunks
legs the dropped SBC holds that they accept binary to run for a beat and then suspended and modify the
filters we've said before in Process Monitor to show all the operations not the operations of the original
file look for any read file and write file events highlighted in the each are the events corresponding
to the encryption of a single file.
We see that there are several are read and write course in this case it is important to pay attention
to the detail column in Process Monitor notice or loop of or read the operation followed by a right
operation.
The offset then linked in the detail tab giveaway.
What has been actually read and rather read them.
You will notice that the lengthy is always equal to one.
Therefore the return is only modifying one bite at a time but different offsets we cannot file the offset
is calculated from the beginning of the file.
Another important observation we can make is that the offset pattern is the same for every file.
Hence even without doing any static analysis we can see that the same bytes will always be encrypted
placing the cursor at offset CDO.
The create the right one bite and the other in the course that is not what offset one then each increment
the offset with 2048 and the jobs to the next location and so on.
So the creep thaw and creeps one bite of the file but the intervals of two thousand forty eight bytes
the events in the each leads to another interesting conclusion.
The files are not fully encrypted.
Even by modifying only certain offsets it would still corrupted say two doubles war documents and the
images which rely on specific file header information.
However text files will still be mostly readable not a very clever and somewhat anyway
let's find out how these single bytes are encrypted and the actual limit to how many durations the encryption
loop has.
The latter is probably easier to determine as we can create a very long text file encrypted and figure
out after what offset the de Loop exits or look for large files in process morning door and see if there
is a maximum of set off to reach the file is closed randomly picking any files that is larger than 50
kilobytes in size.
We notice that the creep does less than created byte will be the offset of twenty thousand four hundred
ninety which suggests that the loop pretty beats ten times divides two thousand four hundred ninety
two two thousand forty eight and you will have the result then Iran's since we know that the byte is
being read and written.
Now Lou we now need to find what happens in between the actual encryption filter and identify the read
file and write file calls using Process Monitor as we did earlier then locate the functions calling
them from the creator.
This is done by double clicking on the vine event.
Example read file then in the back tab shown in the image on the right.
Find the address of the operation with SBC host that they accept that caused the read file function.
In this case it is for all 3 0 7 0 we can now open the creep third dropped file as we see holes.
Ethics and unite will go to that address and see what's happening.
In the previous slide we go to we are the address of the function that caused the read file API.
We then want to find a loop which calls read and write functions from within the creator.
Logically we would have to cross-reference these function and see where it was called from.
To do this you know dark click on the title of the routine sub for all three or four eight then press
X or shortcut growth for cross reference.
Select one of the references and press.
Okay.
In this case there is only one call making the analysis a lot easier.
Noticing these neat bit of gold that we have a lot of functions that are not recognized automatically
by the disassemble.
Don't worry because it's very easy to do it manually.
Just click on any of those sub on with with.
Look at the code and you'll recognize a standard Windows API.
For example if we take sub for all three to c o we will quickly see that it is in fact the wrapper overwrite
file Windows API.
Just above this code there is a condition check for the offset to be higher than five thousand sixty
four hex which is twenty thousand five hundred eighteen decimal.
If it is the loop exists if it's not the iteration it creates another bite.
This is in line with our previous observation that the last encrypted byte will be at the offset of
twenty thousand four hundred ninety.
So what happens actually we should call this obfuscation rather than encryption.
The operations are very simple and identical for each byte being created but the particular offset already
shown by these being read value is negated then XOR with thirty one then negated again and find then
finally export wheat seeks a the modified by D then over written into into the original file decent
creep Sean.
If we can call it that way is actually straightforward.
After analyzing the code so in order to get to the original file we have to perform these four operations
nudie bars for the same offsets as the creator.
To recap In this lecture we've done the following.
We used the process explorer to spot a specious executable dropped by our sample trying to masquerade
as a legitimate window service we checked the file.
The signature of the running process is in process explorer.
We identified how the obfuscation of files he's performed use his process using process money thought
by checking the parameters of the right operations.
We located the obfuscation within neither raw disassemble.
Then finally we reverse engineer the operations and get back to the original files.
This was lecture to.
Thank you.