FTCODE – HOW RECOVER INFECTED FILES

See to believe. I remember you that the entire sequence will always be the same, not just the first number.

For example, let’s transcribe the following instructions into a PowerShell script:

$xx=get-random -minimum 100 -maximum 999999 -SetSeed 1950

Write-Output $xx

$xx=get-random -minimum 100 -maximum 999999

Write-Output $xx

The first line initializes the seed with the value 1950 and requests a number between 100 and 999999.

I bet that your PC with PowerShell 2.0 will return the value of 455659!
Then the third line asks for a second random number without initializing the seed.
Even here I bet that the value returned to you is 983630.
So the sequence, with the same number of seeds, is always the same.
Returning to the malware, I notice that the get-random call to generate the password is not the first one but the second one. At the beginning the script downloads from the web the script to infect the computer. The script is temporarily named with a random number.
So the password call is the second one. Good.
Following this logic the main problem is to define which value (TickCount) to use as the initial seed.
The hacker made a second mistake.
In the script it saves some files in the infected PC file system. It stores them precisely in the folder: C:\UsersPublic\OracleKit.

The file, always the same, is called w00log03.tmp. It contains, just for your information, the GUID code used by the hacker to link the password generated in your PC. But this content is not necessary for the recovery of lost files.
The date and time of creation of this file is our keystone.
Now you have to try to remember the time your computer was turned on or you can read the actual switch-on time from the system events. Then we can roughly define the TickCount value at the activation of the malware.
Let’s move towards a fairly valid range, let’s say about half an hour.
We are talking about around 1,800,000 milliseconds. Much less likely to force the 50-character password.
Then you can write the decryption procedure by taking a corrupt file of which you have also an uncorrupted copy.
If you don’t have this possibility, you should use another technique, a little more complex, but which would surely guarantee the success of recovering the infected files. For example a zip file where the first 4 bytes are always the same.
In our tests we distributed the decryption work on four machines, all more or less with the same CPU performance. We have highlighted a recovery time of about 20/30 seconds every 1000 tests. So the result was 1,800 tests for 30 seconds, divided the four machines.
We calculate 54,000 seconds, 900 minutes: 15 hours in whole. If we divide the total time by the 4 machines we are in the order of 3 hours and a half for each one.
In our case the solution arrives after about 2 hours. The password found, of 50 characters, has therefore also been verified on other files with the same positive result.
From here the following is normal routine: we have recovered all the files on the computer, fortunately for the server we had the backup.
For your information this is the part of PowerShell code, you have to run only in environment 2.0, to perform the file decryption:

function DecryptFile($bytebuffer, $password){

$salt=”BXCODE hack your system”
$init=”BXCODE INIT”
$RijndaelObject = New-Object System.Security.Cryptography.RijndaelManaged
$bytepassword = [Text.Encoding]::UTF8.GetBytes($password)
$salt = [Text.Encoding]::UTF8.GetBytes($salt)
$RijndaelObject.Key = (New-Object Security.Cryptography.PasswordDeriveBytes $bytepassword, $salt, “SHA1”, 5).GetBytes(32)
$RijndaelObject.IV = (New-Object Security.Cryptography.SHA1Managed).ComputeHash( [Text.Encoding]::UTF8.GetBytes($init) )[0..15]

$RijndaelObject.Padding=”Zeros”
$RijndaelObject.Mode=”CBC”
$dy = $RijndaelObject.CreateDecryptor()
$ms = New-Object IO.MemoryStream
$cs = New-Object Security.Cryptography.CryptoStream $ms,$dy,”Write”
$cs.Write($bytebuffer, 0,$bytebuffer.Length)
$cs.Close()
$ms.Close()
$RijndaelObject.Clear()
return $ms.ToArray()
}