Developing and connecting cybersecurity leaders globally



Yüklə 62,48 Kb.
Pdf görüntüsü
tarix14.04.2018
ölçüsü62,48 Kb.
#38344


ISSA  

DEVELOPING AND CONNECTING 

CYBERSECURITY LEADERS GLOBALLY

CryptoLocker

14 – ISSA Journal | April 2016

Abstract

Attackers have developed a 

way to monetize files already 

on a victim’s computer. They 

accomplish this through en-

crypting select files and then 

charging for access to the 

key. This type of malware 

has spawned a new classifica-

tion, cryptoransomware, but 

is more commonly known by 

the name of most prevalent 

version, CryptoLocker, or its 

variants TeslaCrypt and CryptoWall. This article will discuss 

how it works, how it happens, and most importantly what 

enterprises can do to protect themselves above and beyond 

IDS/IPS and antivirus systems. Prescriptive guidance for ba-

sic prevention, detection, mitigation, and recovery controls 

is offered.

CryptoLocker basics

T

he idea of a ransom attack against computer files is 



relatively new, but attackers are raking in millions 

doing just that. Rather than cracking the perimeter, 

taking over a system, or extracting and selling data, the data 

at rest is encrypted using public key infrastructure.

The files in each mapped, removable, and locally installed 

drive are enumerated and specific files are encrypted. The 

target is typically common document storage formats like 

Office, PDF, CSV, etc. The private key needed to decrypt the 

data is held by the attacker and must be purchased by the vic-

tim to regain access to the files. The victim is presented with 

a ransom note when logging on to the system and attempting 

to access files.

Attacks are usually three part. A compromised site or doc-

ument includes an exploit kit like Nuclear or Angler, which 

directs the browser to download the malware from a shad-

owed domain. The malware executes and encrypts the files. 

As the files are encrypted, ransom notes are written in each 

This article discusses CryptoLocker ransomware, how it works, how it happens, 

and most importantly what enterprises can do to protect themselves above and 

beyond IDS/IPS and antivirus systems.

By Carl Saiyed

 – ISSA member, Greater Spokane Chapter

Figure 1 – Typical CryptoLocker ransom note

CryptoLocker



 

©2016 ISSA • www.issa.org • editor@issa.org  • All rights reserved.




Some reports suggest that up to .4% [2] of enterprises and 

home users will pay the ransom. In some cases, even police 

departments have been victims and, due to lack of proper 

backups, have had to pay the ransom to retrieve their files. 

The FBI reports that between April 2014 and June 2015, vic-

tims reported losses of over $18 million [3].

If the victim can restore from backup, this is ideal. But for 

home users, this is not always the case. Many users choose to 

backup to removable media such as a USB hard drive. These, 

directory (see figure 1). Often, a randomly generated 

registry key is created and keeps a record of all en-

crypted files.

Once infected, a user has four options: 

1.  Pay the ransom

2.  Restore from backup

3.  Lose the files

4.  Brute force the key 

To brute force the key would require factoring 

617-digit numbers, which would take about 6.4 

quadrillion years on a standard desktop computer 

[1]. This effectively takes brute forcing off the menu 

for most environments. The attack relies on public 

key cryptography, in which the private key needed 

to decrypt the data never actually exists on the vic-

tim’s machine. The public key used to encrypt is all 

but worthless as it relates to decrypting the files. The 

cryptographic strength of the RSA algorithm is by 

design and is ordinarily used to secure web commu-

nications. For purposes of this article, brute forcing 

the key is not considered a legitimate recovery con-

trol.

If the victim decides to pay, the attacker typically 



requests payment using Bitcoin. At the time of this 

writing, the average ransom was between $500-750 USD. The 

value of the ransom will change depending on the number of 

encrypted files. If the victim fails to pay within the allotted 

time, the ransom will double or triple. Some versions offer 

to decrypt one file for free. Most variants offer free technical 

support if the victim is unable to decrypt after paying. Most 

variants do actually return the private key once the ransom is 

paid. Users can access the ransom page from the link in the 

ransom note (see figure 2).



Figure 2 – Typical CryptoLocker ransom page

April 2016 | ISSA Journal – 15



CryptoLocker

 | Carl Saiyed



 

©2016 ISSA • www.issa.org • editor@issa.org  • All rights reserved.




if left attached, will ordinarily also be encrypted with the in-

fection. A USB drive attached to the computer but turned off 

or without power is likely safe, provided it is not powered over 

USB. Most users and enterprises will elect to lose the files that 

cannot be recovered from backup.

No matter what method is used post-infection—paying the 

ransom, restoring the files from backup, or deciding to lose 

the files—the operating system of the infected computer 

should always be re-installed in order to ensure a clean start.

How it happens

What is especially impressive is not just that attackers would 

be so bold as to launch the attack, charge for the key, and pro-

vide technical support, but the relative ease with which these 

attacks succeed. This has become a true revenue stream, and 

the attackers are able to develop very sophisticated, clever 

ways to deliver their malware. The most common infection 

mechanisms are malicious Office documents and drive-by 

downloads.

Email is still a vector

The malicious office documents typically are part of an email 

claiming to be a fax or an invoice. The user opens the docu-

ment and the text of the document claims that the document 

is protected and cannot be viewed. However, the document 

comes to the rescue with instructions on how to enable the 

content: just follow the steps to enable macros (see figure 3). 

Once the user follows the steps, the macro runs, the payload 

is delivered, and infection will commence. A variant of this is 

to include a zipped copy of the malicious script in hopes the 

user has a file association that will run the script when un-

zipped. Both versions rely heavily on script obfuscation tech-

niques, so a manual or automated code review won’t catch 

these. In some cases, the Office document is zipped; in some 

cases it is attached directly. Usually the filename includes .doc 

to mask the actual extension, .docm.



It’s not just “bad” sites anymore

With the advent of content aggregating sites, users are in-

creasingly able to visit a vast array of sites in relatively short 

order. Frequently, this includes personal blogs used to share 

ideas, most of which are built with standard templates and 

are not held to the same rigorous security standards that 

many corporate websites are held to. These sites have legit-

imate content and in and of themselves are not only harm-

less but often useful (see figure 4). Users aren’t typically on 

guard with sites like these because they appear to be totally 

innocent. These, along with ads, are a typical source of drive-

by downloads. Attackers need only infect a blog and wait for 

users to visit that page. Typically, the compromised site will 

include JavaScript that loads a malicious Flash movie that 

runs in the background, takes advantage of an exploit within 

Flash, and downloads the malware. 

In both cases, the actual malware is usually delivered from 

a randomly generated subdomain of a legitimate domain. 

Attackers will compromise the DNS account for a domain 

and register different subdomains, then use those for attack. 

Often, these subdomains are only used once. This has been 

dubbed “domain shadowing” by Nick Biasini [4]. 



Defense strategies

Preventing this type of infection is difficult. The attackers 

go to great length to hide the actual malware from analysis. 

The code is obfuscated. Shadowed domains are typically only 

used once for a given victim’s public IP. The infection bina-

ry is removed when the encryption is complete. Most of the 

owners of sites actually delivering the malware have no idea 

that an infection has even occurred. Typical antivirus suites 

are ineffective until the machine is well beyond the 

event horizon.

Assuming an enterprise already has appropriate, up-

dated email security and web browsing mechanisms 

in place, there are few additional protection steps that 

can be taken. Some firewall/IPS/IDS and web proxy 

solutions can be effective but leave an enterprise in the 

middle of the cat-and-mouse game of attacker-vs-ven-

dor, waiting for updated signatures or definitions. 

Rather, it can be useful to employ a more active pos-

ture against this type of attack, of which there are four 

main protection mechanisms. To this end, I offer the 

following prescriptive guidance.

Figure 3 – An malicious Word document with instructions to enable macros

Figure 4 – A personal blog that suffered an attack that delivered 

 CryptoLocker to visitors

16 – ISSA Journal | April 2016

CryptoLocker

 | Carl Saiyed



 

©2016 ISSA • www.issa.org • editor@issa.org  • All rights reserved.




Preventive controls

First, if at all possible, disallow Flash for untrusted websites. 

This has some initial overhead while whitelisted websites are 

identified, but the ActiveX filtering feature in Internet Explor-

er has proven to be effective. Couple this with disabling Flash 

in Chrome and Firefox. Identify and implement a formal 

help-desk process to add sites to the whitelist. Ensure only 

knowledgeable personnel can approve adding to the whitelist.

Second, filter inbound email for attached ZIP and Microsoft 

Office documents. Consider blocking macro-enabled Office 

documents altogether. Often, the majority of inbound emails 

that match this filter are malicious and never need to reach a 

user’s inbox. Additionally, continue the message and inform 

the user that the attachment was filtered; identify and imple-

ment a formal help-desk process whereby users can request 

the attachment after it has been screened. An enterprise may 

consider whitelisting for this as well.

Third, disable macros within the Office suite. It may be ap-

propriate to enable with notification or disable altogether. 

The former will give the user the ability to override and exe-

cute the macro, while the latter requires administrator inter-

vention. Both can be installed using Group Policy.

Fourth, and most difficult to implement, is application wh-

itelisting. There are several commercial products that can 

help with this. These can be restricted to only allow certain 

binaries to execute. This has the highest level of overhead to 

implement and should be a last line of defense.

Detective controls

Detecting the incident based on a user noticing is not reliable 

and spends precious time.

The ransom note doesn’t open automatically for the user until 

the encryption process is complete. Depending on the speed 

of the infected machine and the resources to which it has 

access, the actual encryption process can take days. Worse 

yet, the encryption happens in the background and the user 

might leave for vacation. Frequently, IT isn’t notified until the 

user calls because his computer isn’t working properly. Such 

an infection can avoid detection longer than some backups 

are held. Effective detection mechanisms can help stop an 

attack earlier. There are two primary detective mechanisms.

The first mechanism is an enterprise data management solu-

tion. Most CryptoLocker variants will leave small traces be-

hind in each directory where encryption has taken place, usu-

ally a variant of files name “HELP_DECRYPT.” Enterprise 

data management solutions can monitor for the creation of 

these files and even take an action such as disabling the user’s 

Active Directory account if these files are detected. 

These systems can also detect substantial data access patterns, 

consistent with CryptoLocker enumerating directories look-

ing for files to encrypt. Lastly, they can assist with post-infec-

tion investigations, including identifying the time and date of 

the infection and which files were encrypted.

The second is a quality intrusion detection system. These 

usually aren’t able to detect the actual payload on its way to 

the host but can often recognize the pattern and alert an ad-

ministrator. A savvy administrator 

or help desk can help to quickly 

contain an infection based on such 

alerts. Consider coupling an intru-

sion detection with a SEIM to better 

investigate attacks.



Mitigation controls

It seems almost a foregone conclu-

sion that an enterprise will have 

at least some exposure to Crypto-

Locker and variants. Thankfully, the mitigation and recov-

ery strategies are nothing new to seasoned IT professionals. 

These tactics are effective policies, principle of least privilege, 

and adequate backups. These concepts are at the core of de-

fending against countless attacks.

A policy regarding storage of important data on network 

shares can ease this burden in two ways. A centralized back-

up is a lot easier to schedule and restore rather than individu-

al workstations and can relieve the IT department of trying to 

restore files lost on an actual infected desktop. Typically, files 

lost to CryptoLocker on a network share are covered by an 

enterprise backup solution and are relatively easy to recover 

while the files on the local desktop are lost. Try to tip the odds 

Detecting the 

incident based on a 

user noticing is not 

reliable and spends 

precious time.

April 2016 | ISSA Journal – 17



CryptoLocker

 | Carl Saiyed

See how. Visit us at www.illumio.com/ISSA

Adaptive 

Segmentation 

Eliminates the 

Attack Surface.

 

©2016 ISSA • www.issa.org • editor@issa.org  • All rights reserved.




References

1.  The Math behind Estimations to Break a 2048-bit Certif-

icate, Digicert – 

https://www.digicert.com/TimeTravel/

math.htm

.

2.  Lee Mathews, CryptoLocker Malware Masterminds 



Make around $30 Million in Ransom in 100 days, Geek.

com – 


http://www.geek.com/news/CryptoLocker-mal-

ware-masterminds-make-around-30-million-in-ran-

som-in-100-days-1580168/

.

3.  Darrell Foxworth, FBI Warns Public of Cryptowall Ran-



somware schemes, FBI – 

https://www.fbi.gov/sandiego/

press-releases/2015/fbi-warns-public-of-cryptowall-ran-

somware-schemes

.

4.  Nick Biasini, Angler Lurking in the Domain Shadows, 



Iron Geek – 

http://www.irongeek.com/i.php?page=vid-

eos/bsideslasvegas2015/cg04-angler-lurking-in-the-do-

main-shadows-nick-biasini

.

General references

—Haws, John, US local Police Department Pays Crypto-

Locker Ransom, Sophos – 

https://nakedsecurity.sophos.

com/2013/11/19/us-local-police-department-pays-Crypto-

Locker-ransom/

.

—IBM, IBM X-Force Threat Intelligence Quarterly, 1Q 2015, 



IBM – 

http://public.dhe.ibm.com/common/ssi/ecm/wg/en/

wgl03073usen/WGL03073USEN.PDF

.

—Jeffers, Dave, Crime Pays Very Well: CryptoLocker 



GRosses up to $30 Million in Ransom, PCworld – 

http://


www.pcworld.com/article/2082204/crime-pays-very-well-

CryptoLocker-grosses-up-to-30-million-in-ransom.html

.

—NSA, Application Whitelisting Using Software Restriction 



Policies, NSA Information Assurance Directorate – 

https://


www.nsa.gov/ia/_files/os/win2k/Application_Whitelist-

ing_Using_SRP.pdf

.

—Snow, John, TeslaCrypt: Round Three, Kaspersky Labs – 



https://blog.kaspersky.com/teslacrypt-strikes-again/10860/

.

—Villeneuve, Nart, TeslaCrypt: Following the Money Trail 



and Learning the Human Costs of Ransomware, FireEye 

– 

https://www.fireeye.com/blog/threat-research/2015/05/



teslacrypt_followin.html

.

—Zorabedian, John, Anatomy of a Ransomware Attack, 



Sophos –

https://blogs.sophos.com/2015/03/03/anato-

my-of-a-ransomware-attack-CryptoLocker-cryptow-

all-and-how-to-stay-safe-infographic/

.

—Zorabedian, John, Did the FBI Really Say “Pay Up” for 



Ransomware? Sophos – 

https://nakedsecurity.sophos.

com/2015/10/28/did-the-fbi-really-say-

pay-up-for-ransomware-heres-what-

to-do/

.

About the Author



Carl Saiyed, CISSP, is a full-time security 

analyst in critical infrastructure sectors. 

Find Carl on Twitter (@nothackingyou) 

or LinkedIn. He may be reached at 

carlsaiyed@gmail.com

.

in your favor by requiring users to store important files where 



they are most easily backed up and restored.

Users with low-permission accounts will simply lack the 

write privileges required to perform the delete and encrypt 

functions that CryptoLocker relies on. A user lacking vast 

permissions will only be able to commit a small amount of 

damage. Apply only the minimum amount of permissions re-

quired for users to complete their job function. Consider cre-

ating separate accounts to be used for high-privilege opera-

tions and documenting their appropriate use. Enterprise data 

management can help provide a framework to understand 

data ownership and over-permissive folders and accounts.

Recovery controls

Lastly, frequent and reliable backups are key. Once the attack 

is successful, this is the most reliable recovery mechanism. 

Ensure that a recovery point objective has been considered 

for network files and shares. A careful review may show that 

this area has been overlooked and is actually mission critical. 

Consider both the files that could be lost as well as the loss 

of availability of the share, drive, or server. Once the critical 

file resources are identified, implement appropriate backup 

mechanisms. Ensure restore mechanisms are tested and staff 

responsible for restoring data are properly trained.

Conclusion

Persistent attackers have created a lucrative and effective 

threat. The right combination of prevention, detection, miti-

gation, and recovery strategies can help ensure that a would-

be disaster is instead an annoyance. Hopefully, enterprises 

armed with an understanding of CryptoLocker fundamen-

tals and practical security measures will be better poised to 

defend against it.



Don’t Miss This Web Conference!

The Sky Is Falling... 

CVE-2016-9999(nth)?

2-Hour Live Event: Tuesday, April, 2016

9a.m. US-Pacific/ 12p.m. US-Eastern/ 5p.m. London

Since its creation the US National Vulnerability 

Database there have been 75,451 CVEs posted. So 

far this year there have been 846 CVEs. When will 

it stop? Are there any strategies to mitigate the 

impact of the vulnerabilities?

REGISTER TODAY!

For more information on this or other webinars:

ISSA.org => Web Events => International Web Conferences

18 – ISSA Journal | April 2016

CryptoLocker

 | Carl Saiyed



 

©2016 ISSA • www.issa.org • editor@issa.org  • All rights reserved.



Yüklə 62,48 Kb.

Dostları ilə paylaş:




Verilənlər bazası müəlliflik hüququ ilə müdafiə olunur ©genderi.org 2024
rəhbərliyinə müraciət

    Ana səhifə