Real-World Incidents
Since the second edition of this book, published over 10 years ago, the world of cybercrime has rapidly evolved. Not only have the attackers’ methodologies and tools changed, but so have the types of systems and applications that are being compromised. In addition to the evolution of cybercrime, the tools, methods, and disciplines we use to perform incident response have evolved as well. However, some organizations have taken a complacent, perhaps even reckless position on cybercrime. Some choose to ignore the issues, accepting the risk or categorizing cybercrime as a cost of doing business. Others choose to spend large sums of money on solutions they feel will fix it, paying little attention to details. Finally, some blame the government for not protecting them. But, as the late science communicator Carl Sagan would say, “…the more likely we are to assume that the solution comes from the outside, the less likely we are to solve our problems ourselves.” This book is our attempt to help you to be part of the solution.
For this book to be useful, you will need to understand what constitutes an incident, what incident response is, where we are now, and why you should care. In this chapter, we address these topics, followed by two case studies that help to connect those questions to real-world incidents.
WHAT CONSTITUTES AN INCIDENT?
The Computer Security Resource Center (CSRC) of the National Institute of Standards and Technology (NIST) defines both events and incidents in Special Publication 800-61, the Computer Security Incident Handling Guide. Whereas an event is described simply as “any observable occurrence in a system or network,” an incident is defined as “violation or threat of violation of computer security policies, acceptable use policies, or standard security practices.”
GO GET IT ON THE WEB
A great number of government agencies, partner organizations, contractors, and supporting businesses have IT Security departments that rely on NIST guidelines for internal policy. Although it is important to note the existence of these definitions, whether they apply to your organization or not, for our purposes they do not describe enough the varied technical facets of potential incidents.
In the second edition of this book, we defined a computer security incident as “any unlawful, unauthorized, or unacceptable action that involves a computer system or computer network.” We then provided some examples such as theft of trade secrets, e-mail spam, unauthorized or unlawful intrusions into computer systems, and embezzlement. This is still a good definition. However, the industry has changed, and the definition of an “incident” needs to change as well. We’d like to expand this definition to “any unlawful, unauthorized, or unacceptable action that involves a computer system, cell phone, tablet, and any other electronic device with an operating system or that operates on a computer network.” This expanded definition is necessary because of the interconnected nature of our world. Cars, televisions, Xboxes, and even refrigerators and toasters all now have the ability to connect to the Internet. This means that these devices are all now potential targets for cybercriminals.
 |
It is important to understand that different organizations will likely have their own definition of what constitutes an “incident.” There will be different tiers of incidents with varying responses based on the tier. Defining an incident and expected response is part of a mature security organization. As part of that definition, we also recommend that you review local laws that define computer crimes. In the United States, Title 18 of the U.S. Code, § 1030, defines federal computer crimes. Another good reference is the U.S. Department of Justice manual titled “Prosecuting Computer Crimes.” |
GO GET IT ON THE WEB
WHAT IS INCIDENT RESPONSE?
Incident response is a coordinated and structured approach to go from incident detection to resolution. Incident response may include activities that:
• Confirm whether or not an incident occurred
• Provide rapid detection and containment
• Determine and document the scope of the incident
• Prevent a disjointed, noncohesive response
• Determine and promote facts and actual information
• Minimize disruption to business and network operations
• Minimize the damage to the compromised organization
• Restore normal operations
• Manage the public perception of the incident
• Allow for criminal or civil actions against perpetrators
• Educate senior management
• Enhance the security posture of a compromised entity against future incidents
The activities and team members that are a part of the incident response will vary based on the goals of the incident response. The goals of an incident response may vary depending on factors such as the severity of the incident, the victim’s needs, the victim’s incident response methodology, the timing of the incident, the intent of the attack group involved in the compromise (if known), the industry or customers impacted, and executive support for the incident response. In general, an incident response consists of an investigation team that determines what happened and performs a damage assessment, a remediation team that removes the attacker from the environment and enhances the victim’s security posture, and some form of public relations (to senior level management, internal employees, business partners, or the public).
WHERE WE ARE NOW
Computer intrusions are more complex than ever before. As the two case studies presented later in this chapter will demonstrate, compromises of corporate environments are no longer just contained to a handful of systems. Computer security incidents now may encompass hundreds of compromised systems physically located anywhere in the world—some of which may not be related to the breached organization, such as hop points that attackers frequently connect through to mask their actual location. Sophisticated attackers are not only taking advantage of network misconfigurations to wreak havoc among victim companies; they are gaining access to network devices and modifying the access control lists (ACLs) to provide themselves with access to restricted areas. Sophisticated attackers are employing malware designed to subvert standard security defenses. Malicious code can no longer be thought of as OS specific; rather, the malicious code, written in a universal language such as Java, can identify the underlying OS before deploying the appropriate, OS-specific malware. Malware authors are spending more time researching antiforensic techniques, especially when it comes to executing in memory only and virtual environment detection, to thwart both forensic and malware analysis techniques. Lastly, sophisticated attackers are aware of many techniques we use to investigate their malicious activity, so they’ve shifted tactics to blend in with legitimate system and network activity. This makes our jobs more difficult as well as increases the cost and time of performing a comprehensive incident response.
The tools, methods, and disciplines used to perform incident response have evolved, just as the types of incidents being investigated have evolved. Incident response teams now have to accomplish their activities faster than ever, and across a wider variety and number of systems, making scalability, automation, and variety of OS support increasingly important in investigative tools. The investigative industry is moving toward tools that allow investigators to “describe” the type of malicious activity they are looking for and search for that activity across all systems in an environment, rather than on one system at a time. These same tools implement automation, such as hashing files loaded into memory, verifying digital certificates, and collecting data pertaining to the many common persistence mechanisms used by malware, among other useful automations. Modern computing environments have shattered geographical barriers, which means investigative tools must be able to perform their analysis regardless of geographical location. This also means that the majority of investigative activity must be able to be performed remotely and must be able to handle slow and unreliable network connections. Finally, investigative tools need to allow an analyst to perform rapid but in-depth remote examinations. We commonly refer to this type of analysis as live response. Live response is conceptually the same as forensic analysis but performed on a live system rather than on a forensic image.
Another reason that the tools, methods, and disciplines used to perform incident response have evolved is because the types of systems and applications being investigated have evolved. Systems have more storage capacity than ever before, so capturing bit-by-bit forensic images of suspected compromised systems throughout a large incident is time consuming and difficult at best. Organizations are logging more data than ever before, and incident responders now need to understand how to normalize, parse, and make sense of large amounts of data. Applications have become more complex, requiring incident responders to interact with subject matter experts (SMEs) in order to ensure that malicious activity is not overlooked. Finally, incident response no longer requires only the IT and security communities; effectively handling an incident requires many business disciplines, including legal, public relations, finance, marketing, and human resources.
In fact, given the entry of legal and public relations (PR) elements into the incident response equation, we have seen an increase in another growing challenge within our field. Many organizations find themselves bound tightly to the notion of “Confidentiality, Integrity, and Availability” (CIA)—wanting to keep their services running and accessible while minimizing the risk of further compromise. As legal and public relations departments move toward minimizing both legal liability and “brand” damage, we see an increasing proclivity to quickly disconnect suspected compromised or infected computers from a network and quickly rebuild or wipe them. Although such actions are understandable and sometimes necessary, this becomes an education issue for the responders. What is the best course of action to maintain CIA, while preserving the evidence and leads that may be your only path to identifying culprits or even additional victims? This is where timely response and effective, efficient tools become critical to the preservation of volatile data.
|
Many of the concepts we talk about in this book may seem to contradict prevailing methods. However, consider that some recent advances in science and technology fly in the face of traditional wisdom. Take, for example, the recent practice of chilling a person’s body after a heart attack. Strangely enough, Hippocrates discovered this technique more than 2,000 years ago. Although that might sound unreliable and dangerous, science and real-world results have shown that this method is much more effective at saving lives than traditional approaches. Similarly, the methods we discuss in this book may sound unwise at first, but our experience has shown that they are effective. |
We receive calls almost every single day from companies that have suffered a cyber-security breach. These cyber intrusions continue to affect virtually every industry, including law firms, financial services, blue chip manufacturers, retailers, the defense industrial base, pizza shops, telecommunications, healthcare, space and satellite and imagery, cryptography and communications, government, mining, software, and many others. We have witnessed the unique threats facing each of these sectors, and we have seen these attacks expand in scope, affecting the private sector, the public sector, corporate enterprises, as well as individual citizens compromised in their own homes. There is little doubt we are in the midst of the largest unlawful transfer of intellectual property in history, and that cyber-espionage is here to stay.
Criminals work with little risks or repercussions while they compromise systems to fraudulently buy goods, steal identities, and make profits from stolen cardholder data or account data. Modern ideological and armed conflicts both have components of the adversarial exchange fought in the cyber-domain. This growing activity of unlawful or unauthorized intrusions requires a constant vigilance, and the sustained application of the skills we outline in this book. Remember, security incidents may be inevitable, but you can apply the lessons we have learned to minimize the impact and consequence. Responding to security breaches is a requirement needed by government agencies and private companies, and it is both fascinating and challenging. In fact, security breaches are so widespread today that experienced and capable incident responders are highly sought after, and incident response career paths have matured.
All of this might sound a little overwhelming, but hopefully we’ve piqued your interest and you’re excited to dive into the remainder of this book! The intent of this book is to arm incident responders with the tools and techniques painstakingly developed and refined over the last ten years by the authors, who have responded to hundreds of large-scale, international, complex, and public incidents.
CASE STUDIES
In this chapter we present you with two case studies that provide an overview of the types of cases that we have investigated. The first case study is about cardholder data theft from a large financial organization. Cardholder data includes both credit cards, debit cards, and associated account information. The second case study involves a technology firm where an attacker uses malware to gain an initial foothold, but then discards it and uses the firm’s virtual private network (VPN) to maintain access and steal sensitive data. We chose these case studies based on the high level of complexity of the compromise and response. We want you to learn from our experience, and we hope you find the two case studies informative. The facts have been changed to protect the victims’ identities because these case studies are real-world incidents.
In early January, an attacker manually exploited a Structured Query Language (SQL) injection vulnerability in a web page hosted on the server named WEB1. WEB1 was located in a demilitarized zone (DMZ) belonging to a small business unit purchased by the victim organization four years prior. This business unit enjoyed full connectivity to the rest of the victim organization’s environment. By exploiting a SQL injection vulnerability on WEB1, the attacker was able to execute commands on the backend database system named DB1; all commands were executed with the privileges of the SQL Server service. In this case, the SQL service was running with local administrator privileges. The attacker used the xp_cmdshell extended stored procedure to execute arbitrary commands and download and execute malware onto DB1. A misconfiguration in the DMZ firewall allowed the attacker to execute SQL commands against a database server named intDB1 located within the corporate environment from DB1. The environment and activity is shown here:
After moving into the corporate environment, the attacker spent the next couple of weeks performing extensive reconnaissance of the environment. At first, the attacker performed this activity using commands issued through SQL injection. One week after gaining access to the internal environment, the attacker implanted a backdoor. The backdoor provided the attacker access to the corporate environment without having to rely on SQL injection. The attacker then extracted and cracked the password hash for the local administrator account on intDB1. This provided the attacker local administrative access to most systems in the environment. In addition to reconnaissance activities, the attacker installed keystroke-logging malware and obtained password hashes from multiple systems belonging to system administrators. One of the systems the attacker was able to extract password hashes from was a domain controller, which stores the passwords for all users on that domain.
By mid-February, the attacker had implanted more than 20 backdoors, spanning three distinct malware families, in the environment. The primary backdoor family will be referred to as the BKDOOR family throughout this chapter. The BKDOOR malware was part of a custom malware creation kit that allowed the attacker to modify the binary enough to avoid antivirus detection as needed. This malware was known to be used by multiple attackers. This family of malware allowed the attacker full control of the victim system, file upload and download capabilities, the ability to tunnel traffic such as the Remote Desktop Protocol (RDP) into the environment, and the ability to proxy network traffic between backdoors. The BKDOOR malware used the RC4 algorithm to encrypt its command-and-control (C2) data. We use the term “C2 data” to describe the instructions an attacker sends to the malware, responses to those instructions, and the associated protocols that are used. A C2 server, referenced later in this chapter, is a server typically outside of a victim environment, is controlled by the attacker, and is used to transfer C2 data to and from the attacker’s malware. The BKDOOR malware maintained persistence through a technique known as “DLL search order hijacking.” You can read more about DLL search order hijacking at the following links:
GO GET IT ON THE WEB
The second family of malware was called PROXY, which proxied connections to a specified destination. The PROXY malware was capable of redirecting connections to the destination address specified in its configuration file or accepting the original destination address from the BKDOOR malware. The third family of malware was called BKDNS, because it tunneled all C2 traffic through DNS queries/responses. The BKDNS family of malware appeared to be for backup access only because the attacker did not use these backdoors during the investigation. The BKDNS malware was very interesting to investigate because the attacker implanted variants of the malware on both Windows and Linux systems. Although the malware was structured slightly differently between the two OSes, the functionality was essentially the same.
Between early January and late March, the attacker stole data on multiple occasions. The attacker first targeted usernames and passwords and then moved to network architecture and other IT-related information. The attacker was able to identify where sensitive networking documentation was stored by exploring files and folders on system administrators’ computer systems. For example, the attacker performed reconnaissance on directories in a share labeled “IT.” Finally, the attacker targeted information about financial systems and how financial data was handled at the organization. The attacker was able to identify where sensitive financial information was stored by enumerating all file shares available on the network and performing manual reconnaissance on the most interesting shares. The attacker also established RDP connections to systems belonging to users in the targeted financial areas and used stolen credentials to log in to various financial applications. This allowed the attacker to understand how the financial applications worked, and how to steal data stored by these applications.
After identifying the data of interest, the attacker stole the data using two different methods. The first method the attacker used was to establish an outbound FTP connection to an attacker-controlled system and upload the data to the FTP server. The second method was to utilize one of the backdoors to transfer the data out of the environment to the backdoor’s C2 server. Advanced attackers do not often use this technique because it increases the chance of detection when large or abnormal data transfers occur. In almost all cases, the attacker compressed the data as a ZIP, RAR, or CAB file; these file types represent common compression methods that reduce the size of files by as much as 50 to 95 percent.
By June, the attacker had discovered the jump server—a tightly controlled system that is the only one allowed to access sensitive resources—used by system administrators to access the restricted segment of the network that handled all sensitive financial data. In this case, the attacker discovered the presence of the jump server (JMPSRV) by monitoring the RDP connections made by one particular system administrator and reviewing the output from the keystroke logging malware. The following depicts the avenue of access into the restricted financial environment:
In this case, the data the attacker was interested in was credit and debit card information, also known as Payment Card Industry (PCI) data or cardholder data. The magnetic stripe on the back of a credit/debit card contains two types of information: track 1 and track 2 data. In general, track 1 data contains enough information to create a cloned card, which allows the card to be used at brick and mortar merchants, also known as a “card present transaction,” and track 2 data contains enough information to allow a malicious person to use the card online, known as a “card not present transaction.” The track 2 data does not include the CVV/CVV2 value embossed on the credit/debit card; however, there are merchants that do not require the shopper to input the CVV/CVV2 value when making purchases online. This financial institution stored track 2 card data in their restricted environment after the card was swiped at the pin pad reader. Criminals use track 2 data to make fraudulent online purchases, or they sell this data on the black market. Going forward, we’ll refer to the credit/debit card track 2 data as “cardholder data.”
The attacker used the BKDOOR malware to establish an RDP connection to the JMPSRV with the domain administrator account “DOMAINadmin.” Unfortunately, only single-factor authentication from a domain administrator account was required to access the jump server, and the attacker had previously compromised multiple domain administrator accounts. After authenticating to JMPSRV, the attacker transferred reconnaissance tools to the system and began performing reconnaissance in the restricted financial environment. The attacker executed a tool designed to extract password hashes from memory on JMPSRV because the financial environment required different credentials than those the attacker had already compromised. The password hash extraction utility allowed the attacker to obtain the password hash to the local administrator account used across the restricted financial environment.
The attacker spent the next two months performing reconnaissance of the financial environment, focusing on the following aspects:
• Systems that processed or stored cardholder information
• Systems that had direct Internet connectivity
The attacker was able to determine the systems involved in the processing and storage of cardholder data by enumerating available network shares, browsing data in directories of interest, and stealing documentation that described the restricted financial environment infrastructure. One of the documents stolen depicted the flow of cardholder data throughout the environment, which clearly identified systems of interest.
Using the stolen documents and information gathered through reconnaissance activity, the attacker discovered the naming convention of the systems that processed or stored cardholder information—PROC_FIN01, PROC_FIN02, STOR_FIN01, STOR_FIN02, and so on. With that information, the attacker performed additional reconnaissance and discovered 90 systems that processed or stored cardholder data. The attacker also learned that the financial environment was configured so that no system had direct access to the Internet. In order to steal cardholder data from all 90 systems that processed or stored cardholder data in a semi-automated fashion, the attacker needed a way to both remotely access the financial environment and to extract data from the environment.
The attacker installed the BKDOOR malware on five seemingly random systems in the financial environment and configured each instance to communicate with the PROXY malware listening on TCP port 88 on JMPSRV. On JMPSRV, the attacker installed the PROXY malware and configured it to proxy inbound connections received on TCP port 88, a common web proxy port, to yet another PROXY instance running on the primary mail exchanger, MAIL. The attacker proxied traffic from JMPSRV to MAIL because MAIL had direct Internet access and JMPSRV did not. The instance of PROXY implanted on MAIL was configured to proxy inbound connections received on TCP port 88 to an attacker-controlled server over TCP port 80, which is the typical HTTP (unencrypted) web traffic port. In this case, the connection being proxied worked bidirectionally (that is, C2 server -> JMPSRV, and JMPSRV -> C2 server). The following graphic shows the network path of the malware the attacker installed and configured to establish remote access to and from the restricted financial environment.
A week after setting up the backdoor infrastructure in the financial environment, the attacker started testing methods to steal cardholder data. The attacker transferred the Sysinternals PsSuite of tools to PROC_FIN01 and a custom binary that saved the memory contents of a running process to a specified file. The attacker first executed “pslist” to determine the running processes, and then executed the custom binary to dump the memory contents of multiple processes. The attacker then created a multipart RAR archive of the data and transferred the multipart RAR archive out of the environment. The attacker was trying to figure out which processes contained cardholder data.
As unlikely as it seems, unencrypted cardholder data often exists on a variety of systems within restricted financial environments—oftentimes called PCI environments, because the PCI Data Security Standard (DSS) establishes the standards these environments must comply with. Some point-of-sale (POS) terminals and POS software process cardholder data in clear text for a fraction of a second in running process memory before encrypting or tokenizing the data. The current industry trend is toward end-to-end encryption (E2EE). This method encrypts cardholder data directly on the card reader, and is only decrypted at the final destination.
Two days after obtaining the memory contents of multiple processes, the attacker accessed PROC_FIN01 again. This time, the attacker transferred a second custom binary, named cardharvest.exe, onto the system. The cardharvest.exe binary was designed to be manually executed and injected itself into a process specified either on the command line or in a configuration file. Once injected into the running process, the malware used a regular expression search term to identify track 2 data within that process’s memory space every 15 seconds. The malware also created a hash of each instance of track 2 data to prevent collection of duplicate data. The malware then encrypted unique instances of track 2 data using the RC4 algorithm with a hard-coded static key and saved the data to a local file.
As a test, the attacker executed cardharvest.exe on PROC_FIN01 for approximately 15 minutes before executing it on another five systems for 15 minutes each. On startup, the malware checked for the presence of the file c:windowssystem32 empstopme. txt. If the file was present, the malware would exit, preventing multiple copies of the same malware from running on the same system. The attacker then executed a script from JMPSRV that mounted a network share to each of the attacker’s six test systems, moved the malware output files to a local directory, and compressed that directory into a password-protected RAR archive. The attacker then retrieved the RAR file using the BKDOOR malware.
Over the next three months, the attacker captured millions of instances of cardholder data from all 90 of the financial systems. The attacker accessed the environment every week or two by tunneling RDP traffic through the established C2 connection between JMPSRV and the C2 server, then executed various scripts to interact with the compromised financial systems. The scripts stopped the cardharvest.exe malware on all compromised systems, collected the output files by copying them to JMPSRV, and created an encrypted RAR file containing the harvest output files. Finally, the attacker issued the “file download” command to the BKDOOR malware to retrieve a copy of the RAR file.
Roughly 10 months since the attacker breached the network, a system administrator discovered that the server named MAIL was communicating over TCP port 80 with an IP address in a foreign country. After performing some initial triage steps, the system administrator realized that the organization had been compromised, and initiated an incident response. The incident response consisted of our team traveling to the client location, working with the client to implement an immediate containment plan, performing a comprehensive incident investigation, and executing an eradication event to remove all traces of the attacker from the environment. The incident response took less than two months from start to finish.
The incident response for this case study was challenging for a multitude of reasons. The investigation team had to:
• Search for indicators of compromise on all systems in the environment
• Analyze Windows, Linux, and Apple OS X systems
• Analyze network traffic from more than 10 Internet points of presence
• Understand complex financial systems and a complex environment in order to fully understand the incident
The remediation team had to:
• Implement an immediate containment plan for the restricted financial environment
• Work with the investigation team to develop a more comprehensive approach to the overall remediation effort
• Implement a sweeping eradication event across the organization within a two-day period
• Work around the real-world impact of affecting financial systems for any length of time
This investigation was a challenge to perform because it required the investigators to take a holistic view of the environment and fully scope the compromise to determine how the attacker was operating. The incident response also required the remediation team to develop a stringent containment plan without fully understanding the environment or the attacker, which is always challenging. The complexity of the financial systems and the environment required our investigation and remediation teams to interact heavily with the local IT teams in order to better understand the environment, to gather data for us, and to help us interpret some of the data.
Case Study #2: Certificate of Authenticity
In mid-May, an attacker sent a spear phishing e-mail that contained a malicious PDF document to 100 users across four different business units at a technology company. None of the 100 users had domain administrator–level privileges; however, the majority of the users had local administrator rights to their systems. The investigation determined that the 100 users were phished because they had a business relationship with individuals who had spoken at an industry-specific conference. The attacker likely researched each business unit the speakers worked for and sent the socially engineered e-mail to all related e-mail addresses that could be harvested from the Internet.
One of the recipients, Bob, unwittingly opened the malicious PDF with a version of Adobe Acrobat that was vulnerable to the embedded exploit. The investigation determined that Bob’s system was the only one compromised by the spear phishing e-mail. The exploit successfully implanted a remote access trojan (RAT) commonly referred to as GH0ST RAT, and opened a legitimate PDF file so Bob would not become suspicious. The GH0ST backdoor immediately started beaconing to its C2 server, notifying the attacker that system BOBSYS01 had been successfully compromised.
The attacker accessed the GH0ST RAT instance implanted on BOBSYS01 two days later. The attacker immediately recognized that the GH0ST RAT instance was running with local administrator rights on the system. The attacker began performing reconnaissance on the system, starting with a review of local user documents. Based on the contents of Bob’s documents, the attacker determined that Bob was an engineer. The attacker also searched common paths for well-known VPN software and certificate information, and determined that Bob worked from home and accessed the corporate environment through a VPN. This technology company implemented a weaker form of two-factor authentication by requiring a machine certificate as well as a username and password.
The attacker obtained the password hash for the local administrator account and successfully cracked the password. The attacker then executed the mimikatz.exe tool to extract Bob’s password and VPN machine certificate. In summary, the attacker obtained:
• Bob’s username
• Bob’s password
• Bob’s machine certificate
• Local administrator password (the same for most systems in the environment)
The attacker now had the ability to authenticate to the company’s VPN while masquerading as a legitimate user account and could access nearly any system in the environment by using the local administrator account. So from this point, the attacker no longer cares about Bob’s system or the malware on it—it’s simply discarded. The attacker did not remove this piece of malware, likely because it functioned as a secondary method of access should the attacker lose access to the VPN.
Less than one week later, the attacker successfully connected to the VPN from a system called HOME3. The attacker’s system name was discovered during forensic analysis of a compromised system; the attacker ended the RDP session by closing the window instead of logging out. This caused an event to be logged in the victim system’s Security event log that captured the actual attacker host name along with the IP address assigned from the VPN pool. Analysis of the VPN logs discovered the IP address the attacker connected from. Geolocation analysis determined that the IP address was registered to a computer network in Texas. That did not necessarily mean the attacker was actually located in Texas; attackers frequently compromise unrelated systems outside of the victim organization and use them as a temporary locations to carry out their cyber attacks.
The attacker spent the next couple of weeks performing reconnaissance in the environment. The attacker’s activities included mapping network shares, performing recursive directory listings, installing keystroke-logging software on critical systems, and using the stolen user credentials to remotely access their e-mail through the company’s Outlook Web Access (OWA) implementation. Other than general reconnaissance data, no evidence was discovered that the attacker stole business-sensitive data during this time frame.
Roughly two weeks later, the attacker started to access business-critical data from a share on file server SENS1. This file share contained sensitive engineering data for a new technology the company was working on. Loss of that data would jeopardize the company’s market advantage. File ACLs were in place to restrict access to only the engineers working on the project, but because the attacker had local administrator access to the server, he modified the ACLs to provide himself access. Remember, the local administrator account password was shared among the majority of systems in the environment. The attacker stole data from the sensitive file share sporadically over the next four weeks. In order to steal the data, the attacker created an encrypted RAR file containing the files of interest, renamed the RAR file to a CAB file, then established an FTP connection to an attacker-controlled server and uploaded the data. After stealing the data, the attacker would delete the RAR file and run the Windows defragmentation utility in an attempt to prevent forensic analysts from recovering the data.
About two weeks after the attacker started to steal business-critical data from the SENS1 server, the company started evaluating a new Security Information and Event Management (SIEM) utility and included VPN logs as one of the data sets for the SIEM to analyze. The SIEM detected that Bob’s user account was logging in to the VPN from more than one system, and from more than one IP address, simultaneously on multiple days. The company’s security staff investigated the VPN traffic and immediately disabled Bob’s account. After this, the attacker started to use a second user’s account, Mary, which the attacker had also compromised. It is likely the attacker compromised multiple user accounts and machine certificates to ensure continued access to the environment.
The SIEM also quickly discovered the malicious use of Mary’s account the same day. This caused the organization to initiate an incident response and reach out to us for help. The company realized they did not understand the full scope of the compromise and that it would be prudent to investigate in more detail prior to performing remedial actions. During the investigation we discovered that one of the IP addresses the attacker used to connect to the VPN from was the same IP address that the GH0ST RAT was beaconing to. This allowed us to identify the GH0ST RAT malware and include BOBSYS01 in the remediation effort. We helped the company perform a comprehensive eradication event and remove the attacker from the environment two weeks after the incident response was initiated.
Two days after the eradication event, the SIEM detected one of the IP addresses the attacker had previously used attempting to access the OWA instance as multiple user accounts. Although the company had changed all user account passwords during the eradication event, the security team quickly realized that not all users had successfully changed their password. The security team initiated a second enterprise-wide password change, disabling accounts that had not changed their passwords within 24 hours. This action removed the attacker’s ability to access OWA. Luckily for this company, the only damage the attacker did was to read e-mails from five different user accounts, all engineers, before the incident response was initiated and the attacker’s access was removed again. The following diagram depicts this activity:
This case was interesting to investigate because the attacker did not implant backdoors other than the initial instance of GH0ST that was used for initial infection. Rather, the attacker relied on the VPN to gain and maintain access to the environment. This made the investigation more difficult because all malicious activity, except for on BOBSYS01, was performed through the VPN; the investigation team had to look for seemingly legitimate activity performed in a malicious fashion. For example, in order to prove that the attacker performed a recursive directory listing on a specific file server, the investigation team had to accomplish one of the following:
• Recover the commands executed by the attacker
• Recover the file the attacker saved the data into
• Find a large number of files accessed sequentially during a time frame of known malicious activity (timeline analysis)
Another major difference in the investigative approach between this case study and the previous is that the investigation team looked for evidence of compromise across the entire environment in the first case study, but only analyzed a specific subset of systems in the second one (following leads). Other than tracking down all recipients of the initial spear phishing e-mail, the investigation team in the second case study followed evidence discovered from analyzing the VPN activity to know which systems needed to be analyzed. The investigation team did not need to look for evidence of compromise on all systems throughout the environment. This was because the attacker only had access to the environment for a limited amount of time and accessed the environment in the same fashion every time, which made the investigation easier. In the first case, however, the investigation team needed to look for indicators of compromise on all systems in the environment due to the length of time the attacker had retained access, the amount of activity the attacker performed, and the sensitivity of the environment to any subsequent malicious activity, in order to fully scope the compromise.
One major difference between the remediation approach in this case study and the first is that this company implemented multiple immediate remediation actions, each in response to something the attacker had done. If the attacker had implanted any backdoors other than the initial GH0ST implant, or if some other avenue of access to the environment was missed, the remediation would not have been successful in removing the attacker’s access to the environment.
Before we end this chapter, we’d like to introduce a concept that we use to help explain the various phases of an attack. We call this concept the “attack lifecycle,” and we use it to demonstrate the various stages of most compromises. We use this concept heavily when planning remediation; however, we felt it belonged in this chapter so that we could use examples from the case studies you just read to illustrate each phase of the attack lifecycle.
CONCEPT OF THE ATTACK LIFECYCLE
The attack lifecycle consists of seven stages common to most intrusions. Not all seven stages are always part of an attack; however, this lifecycle can be adapted to fit any incident. In addition, the phases of an attack do not always follow the order presented in the attack lifecycle. The concept of the attack lifecycle is included in this chapter because it is important to think about incidents in context of the different phases of the lifecycle. Thinking in terms of the various phases will help you to better understand the context of discovered activity as it relates to the overall compromise. In addition, when you are planning for remediation, attacker activity at each of the phases should be addressed. The attack lifecycle is shown here:
The seven stages of the attack lifecycle are briefly described here. We’ve also listed how each stage maps to the case studies you just read.
• Initial compromise The attacker successfully executes malicious code on one or more systems. Initial compromise often occurs through social engineering, such as spear phishing, or by exploiting a vulnerability on an Internet-facing system. Social engineering attacks often exploit a vulnerable third-party application running on an end-user system.
• Case study #1 The attacker used a SQL injection attack against a vulnerable database server.
• Case study #2 The attacker sent a phishing e-mail with an infected PDF attachment.
• Establish foothold The attacker ensures remote access to a recently compromised system. This occurs immediately following the initial compromise. The attacker typically establishes a foothold by installing a persistent backdoor or downloading additional binaries or shellcode to the victim system.
• Case study #1 The attacker installed backdoor malware on a system in the internal environment.
• Case study #2 The infected PDF installed the GH0ST RAT malware on the BOBSYS01 system.
• Escalate privileges The attacker obtains greater access to systems and data than was initially available. Privilege escalation is often obtained through password hash or token dumping, which is followed by password cracking or a pass-the-hash attack, keystroke/credential logging, nonprivileged user exploits, extracting the currently logged-on user’s password from memory, or using privileges held by an application, such as executing commands via Microsoft SQL’s xp_cmdshell extended stored procedure. This phase also includes obtaining access to user accounts that are not necessarily administrative accounts, but have access to files or resources the attacker needs.
• Case study #1 The attacker used password hash dumping and cracked domain administrator passwords.
• Case study #2 The attacker’s initial foothold started with elevated privileges (Bob’s account), but the attacker cracked the local administrator password to ensure elevated privileges to other systems. The attacker also expanded his access by compromising multiple accounts that could be used to remotely connect to the environment via the VPN.
• Internal reconnaissance The attacker explores the victim’s environment to gain a better understanding of the environment, the roles and responsibilities of key individuals, and where key information is stored.
• Case studies #1 and #2 The attackers in both cases manually explored the local user directories that commonly store documents. They performed recursive file listings to identify nonstandard locations of sensitive data. The attackers also used command-line tools to enumerate file shares as well as perform network and service discovery.
|
Attacker internal reconnaissance is often downplayed or glossed over during compromise descriptions. Attackers often perform extensive internal reconnaissance to understand the compromised environment. |
• Move laterally The attacker uses the established foothold to move from system to system within the compromised environment. Common lateral movement methods include accessing network shares, using the Windows Task Scheduler to execute programs, using remote access tools such as PsExec and radmin, or using remote desktop clients such as RDP, Dameware, and virtual network computing (VNC) to access the systems’ graphical user interface.
• Case study #1 The attacker used RDP connections, mapping network shares, and interacting with backdoors.
• Case study #2 The attacker used RDP connections and mapping network shares.
• Maintain presence The attacker ensures continued access to the victim environment. Common methods of maintaining persistence are to install multiple unrelated backdoors (both reverse backdoors and standard backdoors, such as webshells, on Internet-facing systems), gaining access to a VPN, and implementing backdoor code in legitimate applications.
• Case study #1 The attacker implanted multiple variants of two main families of backdoors. Each family of backdoor operated differently than the other, so even if all of the variants were found from one of the families of backdoors, the other family likely would not be detected.
• Case study #2 The attacker compromised multiple user accounts and their machine certificates. This allowed the attacker to successfully authenticate to the VPN as multiple user accounts in case one of the compromised accounts was discovered, the user changed their password, or any of a number of issues occurred to cause the account to no longer work.
• Complete mission The attackers accomplish their goal, which often includes the theft of data or modification of existing data. Once they have completed the mission, most targeted and persistent attackers do not leave the environment, but maintain access in case they are directed to complete a new mission in the target environment. It is not uncommon for an attacker to repeat multiple phases of the attack lifecycle multiple times throughout an incident. For example, an attacker performing credit/debit card fraud needs to both steal data and manipulate data in near real time.
• Case study #1 The attacker stole cardholder data.
• Case study #2 The attacker stole data about a sensitive project.
SO WHAT?
Cyber attacks are here to stay. They are the new normal. If you can be compromised, over time, it is probable you or your organization will be compromised. It is best to be armed and prepared to deal with each incident as effectively as possible. Therefore, investing time to learn the practices and procedures in this book will serve you well at some point in the near future.
Now that we’ve piqued your interest and you’re ready to dive into this book, we want you to start thinking like an incident responder. Do you think the two organizations handled the incidents as efficiently as possible? What do you think these organizations could have done prior to the breach in order to minimize its effects? Pondering these questions is important because one of your jobs as an incident responder will be to think through these and the myriad of other questions that you’re going to receive while working an incident response. You must provide responses that make the organization confident you will solve the incident. Even after performing hundreds of responses, we still learn something every time we respond to an incident, and often look back at how the incident was handled and recognize that certain aspects could have gone better. Hindsight is always 20/20!
QUESTIONS
1. What constitutes an incident?
2. Who should define what constitutes an incident?
3. Is all malware OS specific?
4. In the first case study, what network architecture mistake did the victim company make?
5. How many phases are in the attack lifecycle?
6. Do all attacks encompass all phases of the attack lifecycle?
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.