Defending Your Data against Cryptoviral Extortion – CryptoLocker

If you’re running Windows XP through Windows 8, chances are you’ve heard of CryptoLocker by now. If not, for some background, check out this from 6LABS post.

Now that you know what it is, it’s time to defend your network against it. There are several defense techniques, and I will try to touch on as many as I can. First and foremost, from an Incident Response point of view, if your network is finding indicators of CryptoLocker, best practice is as follows:

Standard Forensic Evidence Preservation Techniques

  • Create forensic image of infected systems – both file system and volatile memory (if needed).
  • Preserve all Firewall/IPS/AD logs.
  • Capture ingress/egress network traffic in .pcap



Identification of Cryptolocker

Location of CryptoLocker binaries:

  • %AppData%\<random>.exe
  • %LocalAppData%\<random>.exe

If the malware has executed, one or more of the following registry keys will be present:

  • HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run “CryptoLocker”
  • HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run “CryptoLocker_<version>”
  • HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce “*CryptoLocker”
  • HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run “<Random>”

Containing CryptoLocker

Stop the binaries from executing by applying GPO to block the following:

  • %appdata%\*.exe
  • %appdata%\*\*.exe
  • %localappdata%\*.exe
  • %localappdata%\*\*.exe

It is also possible to stop execution by creating a Software Restriction Policy (SRP).

For more information on Software Restriction Policies, please visit here. Below are SRP rules to assist in blocking CryptoLocker. You may have to tweak some of these rules for your environment.


Block CryptoLocker executable in %AppData%

Path: %AppData%\*.exe
Security Level: Disallowed
Description: Don’t allow executable to run from %AppData%.

Block CryptoLocker executable in %LocalAppData%.

Path if using Windows XP: %UserProfile%\Local Settings\*.exe
Path if using Windows Vista/7/8: %LocalAppData%\*.exe
Security Level: Disallowed
Description: Don’t allow executable to run from %AppData%.

Block executable run from archive attachments opened with WinRAR:

Path if using Windows XP: %UserProfile%\Local Settings\Temp\Rar*\*.exe
Path if using Windows Vista/7/8: %LocalAppData%\Temp\Rar*\*.exe
Security Level: Disallowed
Description: Block executables run from archive attachments opened with WinRAR.

Block executable run from archive attachments opened with 7zip:

Path if using Windows XP: %UserProfile%\Local Settings\Temp\7z*\*.exe
Path if using Windows Vista/7/8: %LocalAppData%\Temp\7z*\*.exe
Security Level: Disallowed
Description: Block executables run from archive attachments opened with 7zip.

Block executable run from archive attachments opened with WinZip:
Path if using Windows XP: %UserProfile%\Local Settings\Temp\wz*\*.exe
Path if using Windows Vista/7/8: %LocalAppData%\Temp\wz*\*.exe
Security Level: Disallowed
Description: Block executables run from archive attachments opened with WinZip.

Block executable run from archive attachments opened using Windows built-in Zip support:

Path if using Windows XP: %UserProfile%\Local Settings\Temp\*.zip\*.exe
Path if using Windows Vista/7/8: %LocalAppData%\Temp\*.zip\*.exe
Security Level: Disallowed
Description: Block executables run from archive attachments opened using Windows built-in Zip support.


Identifying if your system has already begun encrypting files:

The following PowerShell script will list all files that are currently encrypted on the local system. To execute this, run PowerShell as administrator and paste the following code:

(Get-Item HKCU:\Software\CryptoLocker\Files).GetValueNames().Replace(“?”,”\”) | Out-File CryptoLockerFiles.txt -Encoding unicode


Options once CryptoLocker has infected and encrypted a system:

When a system is infected with CryptoLocker, it is best to disconnect it from the network as soon as possible. At this point, you need to decide if you plan on paying the ransom or not. We suggest cutting your loses and restoring from a backup.

Should you decide to pay the ransom, we’ve seen a large amount of success with the decryption process. Follow the directions on the malware pop up to pay either via BitCoin or prepaid cards. If you are going to pay the ransom, you should NOT remove the infection from the %AppData% folder. If you delete these files, it is significantly more difficult to decrypt your data.

Once you pay the ransom, the application will begin decrypting your files. A screen will be displayed with a message stating that the malware is verifying payment. This can take up to a few hours. Once verification is completed, the decryption process will begin. This is a very slow process, and it might take several hours to a day to complete decryption.

If you make the decision to remove the infection without paying, it is strongly recommended to restore the system from a trusted, known good media. You can disable CryptoLocker by removing the binaries and deleting the registry keys referenced above. Please keep in mind, removing the files rather than restoring from known good media could result in re-infection. In addition, CryptoLocker is often found coupled with other malware, such as Zeus, which could also steal your data. 

Recovering your data without paying the ransom

Actually decrypting your data isn’t really possible at the moment (CryptoLocker uses very strong RSA-2048 bit encryption), but if you have Shadow Volume Copies enabled on the system, it might be possible to attempt to recover the files from shadow copies. This has worked with older variants of CryptoLocker. It is rumored that new variants are looking for those files and deleting them. Some users have used an application called Shadow Explorer to restore files from backup. 


It seems this type of malware is here for the long haul, and it won’t be long before even more variants are released into the wild. End users and businesses alike need to be sure to backup data frequently. Ensure proper network monitoring is in place and use a layered approach to defending your network. These actions will help stop the infection before it begins.



How to Reset A Forgotten Windows 2008/2012 Server Admin Password with a Windows CD

As an IT Professional, you might find yourself blessed with the unfortunate scenario of working on a Windows server that is not able to authenticate to the domain and the cached domain credentials are no longer working. In addition to this predicament, you learn that there is no documentation for the local administrator password. Either the client who you’re working for doesn’t know the local administrator password or the previous engineer who built the server is no longer working for your company and the standard passwords aren’t working. A 3rd party password cracker application will allow you to reset the local administrator password. But if you want to use a 3rd party password cracker application, you can follow the steps below and use the Ease of Access Exploit to change the local administrator password.

The Ease of Access Exploit modifies the windows system files to enable you to open a command prompt at the windows login screen. This command prompt also runs as the system account, allowing you to add, create, or edit local accounts. The only tool needed for this exploit is a Windows CD. It can be a Windows Vista, Windows 7, Windows 8, Server 2008 R2, Server 2008, Server 2012 or a Server 2012 R2 CD. Even though a Windows Server 2008 CD is used in this example, Linux distributions and Ultimate Boot CD will also work as well. The commands would be the same; the only difference would be the way you get to the command prompt.

How to reset your admin password

To get started, boot the server to a Windows CD.  Browse to the repair section and open up the command line tool.

Inside the command line, change directories to the windows installation directory. It will usually be the C, D, or E drive. In this example the D drive contains the Windows system files. Type the following commands:


Cd Windows/system32

Ren utilman.exe utilman.exe.old

Copy cmd.exe utilman.exe

This will change directories to the system32 directory and rename the Utilman.exe file, which is the executable file that allows users to open up the Ease of Access menu. This menu allows users to modify the contrast of the screen and access features such as the Magnifier and Narrator. After renaming the utilman.exe file, cmd.exe is copied and renamed as “utilman.exe”. Now when users click on the ease of access tool at the windows login, the command prompt will appear instead of the normal menu.

Reboot the host and start up normally. At the login screen click on the ease of access button in the lower left corner. A command prompt running as the system account will appear.

Now you can either enable and reset the local administrator password or create an additional account and add it to the local administrators group.

Change the Local Administrator Password

Type the following commands to change the local administrator password and enable the account if it’s disabled:

Net user administrator newpassword

Net user Administrator /active:yes

Create an Additional Local Administrator Account

Type the following commands add another local administrator account

Net user newadmin P@ssw0rd /add

Net localgroup administrators newadmin /add

You can now login to the server with the new local administrator password or with an additional admin account. Once logged in, make sure to revert the Ease of Access menu back to normal by typing the following commands:

Copy utilman.exe.old utilman.exe

What if I Am Using Windows Server Core?

Windows server core is an installation option that is available during the initial install of Windows Server 2008 and higher. Essentially this will install windows without the graphical user interface. Read “Benefits of a Windows Server 2012 R2 Core Installation by Andy Syrewicze for more information on why Server Core should be used. The Utilman.exe file is not included in the install of server core. So when you boot to the windows CD you can skip the part where you back up the utilman.exe executable. Type in the following commands:


Cd Windows/system32

Copy cmd.exe utilman.exe

This will copy the command line executable and rename it as the utilman.exe file. When the host is rebooted, it will think the utilman.exe file exists and the Ease of Access button will respond by opening the command prompt when clicked on.

How Do I Protect My Server Against This Exploit?

The easiest and most inexpensive way to protect against this exploit is to set a BIOS password and change the boot order to exclude CD-ROMs and USB drives. This would protect against an internal attacker that compromises the out-of-band management utility.  However, if the attacker gains physical access to the server, they can reset the BIOS password and still use this exploit. This is why access to the server room should always be secured. For more information on securing Hyper-V, be sure to check out “7 Keys to Hyper-V Security” by Eric Siron.

This article was written specific for Hyper-v, but this applies to physical and virtual systems.

You can find the original article in the following link, Altaro

Best Windows Reset Password, in my opinion | All Windows Versions

Hi all,

In last month i found my self into multiple situations that long time ago i´ve not been into…
Some colleagues of mine, and my self, needed to enter locally into server, but unfortunately we cannot remember the local admin password. So that was an issue, because we cannot enter into server…
After a few minutes in google i´ve found a website with this tool, Offline NT Password & Registry Editor.
For my pleasure it works in every Windows Server, even works in windows 2012 R2 🙂

You have two options, by CD (ISO image), or create a usb boot.

The screenshots below, shows how to change the password of local user, in this case the local administrator.

Press Enter


Select Enter again


Select , Password reset [SAM].


Select 1, Edit user data and passwords.


For this purpose, write 01f4 the RID of administrator, and press enter.



After, select 1, :).



To save changes, press Y.


At this point, the process done. Right now we need to reboot, and boot the O.S. normally.
And MAGIC, you can now enter in O.S. without password :).



That’s it 🙂 .

Certificates, get expiration date, and import into SQL database.

Some weeks ago, a responsible for my team ask me to lead a project to collect some specific information from all windows servers in the company. That specific information is to collect in windows servers would have certificates and when they will expire. He need a process, to collect and import that information into a SQL Database, and create a process to warning every week, which certificates expire in 180 days or less.

The process I’ll describe, is the script to collect the information of the certificate expiration.

The following script, is the most important step of this process. The script is a Batch file. Why? because the multiple versions of operating systems involved.

This process will check if server have IIS role. If dont have IIS, it will create a file with the hostname.txt with 0 kb.

If have IIS role, it will be check the certificates present in that server, and create a file whit the hostname.txt with the necessary information.

######################### Begin Script #########################

echo off


cd %systemdrive%

IF exist temp/nul ( echo temp exists ) ELSE ( mkdir TEMP && echo temp created)

cd temp

IF exist CERTF/nul ( echo CERTF exists ) ELSE ( mkdir CERTF && echo CERTF created)


del *.txt

FOR /F “tokens=1,2,3,4” %%A IN (‘SC.EXE QUERY W3SVC ^| FIND /I “STATE”‘) DO SET STATE=%%D





certutil -store my | findstr /i ” Subject: ” >> issuer.txt

certutil -store my | findstr /i ” NotAfter: ” >> notafter.txt

setlocal EnableDelayedExpansion

< issuer.txt (

for /F “delims=” %%a in (notafter.txt) do (

set /P line1=

echo !line1!;%%a


) > %computername%.txt

ren %computername%.txt %computername%-old.txt

set h=%computername%;

for /f “tokens=* delims= ” %%a in (%computername%-old.txt) do (echo %h%%%a% >> temp.txt)

del %computername%-old.txt

ren temp.txt %computername%.txt

forfiles /M Issuer.txt /C “cmd /c If @fsize==0 copy /y NUL %computername%.txt >NUL



copy /y NUL %computername%.txt >NUL

Rem Until now, the process is done. From here is to send to a central location. In my case i’m sending to a FTP server



del issuer.txt

del notafter.txt

@ftp -i -s:”%~f0″





mput *.txt


goto END


######################### End Script #########################

If you have some tools, which you can manage all your servers, like PSEXEC, you can create a schedule task, to run in all your servers.

After this, in the SQL server you want to import that information, create a task to download from the FTP Server, and compile all files into one. Do not forget to remove some garbage, like certificates Web Management Service, or others that you don’t needed. After you download your files, to your SQL server, you can compile into one file all your information;

Open a Command line into your folder which have all files, and wrote;

type * >> c:\FOLDER-PATH\temp.txt

After that run the following PowerShell script;

######################### Begin Script #########################

(Get-Content “c:\ FOLDER-PATH \temp\temp.txt”) -notmatch “WMSvc” -notmatch “localhost” | out-file c:\ FOLDER-PATH \import.txt

(gc c:\FOLDER-PATH \import.txt) -replace ‘;Subject: CN=’,’;’ -replace ‘; Subject: CN=’,’;’ -replace ‘NotAfter: ‘,’ ‘ -replace ‘; ‘,’;’ -replace ‘; ‘,’;’ | out-file c:\ FOLDER-PATH \import.txt

Get-ChildItem c:\ FOLDER-PATH \servers\ -Recurse | Select-Object -Property Name | out-file c:\ FOLDER-PATH \HOSTNAMES.txt

(gc c:\ FOLDER-PATH\HOSTNAMES.txt) -replace ‘—- ‘,” -replace ‘Name’,” -replace ‘.txt’,” | out-file c:\ FOLDER-PATH \HOSTNAMES.txt

######################### End Script #########################

You need to create two folders, TEMP and Servers into your Folder path.

After this, you have your file ready to be import into your SQL server, and have this appearance.






At this moment, you only need to create process to be alerted in SQL server by creating a routine/SQL Script to alert weekly, 180 days from now you will have some certificates expired.

This process was created, because the client have more than 3000 windows servers :), and that is a lot of servers to check, and remember.

That’s it, enjoy it.