Cyber Investigations

Introduction

In ancient Greek kubernao meant “steer a ship” and kubernetes was a steersman. Homer tells how the gods smote Odysseus’s ship, so that the toppling mast crushed the steersman’s head, kuberneteo kephalen.

The normal Latin transliteration of kubernetes gives us “cybernetes” - though practical seafaring Romans worried less about the rules and turned kubernao into guberno, from which we get “govern”.

Plato used “kubernetika” to mean skill in steering, and in the 1940s the American mathematician, Norbert Wiener, derived from it “cybernetics” to mean “control and communication theory, whether in the machine or in the animal”.^[1]

The term cyber is ubiquitous in today’s political and business world. One can hear of cyber policy, cyber intelligence, cyber security and most relevant to this handbook, cyber-attacks and cyber investigations. The term itself is generally used to mean concerned with or enabled by computers.

The following quote, although about cyber security in general, can also be applied to cyber investigation, though it may be tempting to leave them entirely to the corporate IT department, there should be some level of involvement and cooperation from corporate investigations and other stakeholders, like legal, compliance, etc.

‘Cybersecurity is not an IT problem, it is an enterprise-wide risk management topic that requires attention’.^[2]

This chapter will discuss the scope of cyber-focused investigations, describing some different investigation types, with some practical information around each; then we will discuss some aspects of governance, followed by some important considerations for building a cyber investigations capability. Finally, we outline some problems that should be anticipated, if not solved.

What is a cyber investigation?

Today, almost all investigations undertaken in the corporate setting can have a cyber element, from abusive or inappropriate email and instant messaging conversations between employees; through cyber criminals deploying ransomware, with financial motivation, to network intrusions by sophisticated state-sponsored ‘threat-actors’, engaged in espionage, etc.

For the purposes of this chapter we will focus on investigations where the cyber element is the primary focus, though we will touch on assisting corporate investigators with the computerised element of more conventional investigation types. Note that there is some overlap in the content of this chapter and chapter 13 and readers are encouraged to refer to that chapter for detailed information about the employment of digital forensics in corporate investigations.

Cyber investigations or Incident response nexus

As a discipline, cyber investigations share a great deal with cyber Incident Response (IR), in terms of knowledge and skills, as well as tools. Some IR frameworks and methodologies can inform the process of a Cyber Investigation.

An important difference between the two is the primary motivation. In a corporate setting the focus of IR is usually to gain a quick understanding of the problem and how to contain and remediate it, in order to bring the impacted business assets back to a working state.

A corporate cyber investigations team may be a participant in the response and recovery, but might also be tasked with deeper analysis of compromised or misused systems, etc. after the emergency is largely over and the incident response team has moved onto other things. By doing so, the conclusions reached during the frenetic response can be verified and additional useful information may be brought to light. The IR team could be compared to be akin to a SWAT team who do the initial work of remediating an incident and the Investigations team akin to the FBI who do the long term investigation in to what took place regarding a cyber incident.

A division of roles and responsibilities, between corporate investigators and incident responders in a given organisation should be clearly defined, through a dialogue between the two groups, and those in upper management ultimately responsible for the two functions, and any other parties involved. For example, you should consider the following:

• Incident responders should understand the principles of evidence collection. They should know if and when to collect data in a way that would not invalidate it later, should it be needed as evidence. They may be well aware of such principles, but even so there should be consistency in thought and understanding between IR and corporate investigations teams.
• IR and corporate investigators should have clear escalation paths for each other. Both are likely to discover things, during their work that would be of interest to the other group. Referrals between the groups should inform a pre-arranged list of individuals or email distribution lists. They should carry a thorough summary of any analysis work already done, data collected, etc., and there should be ready means to share or transfer potentially large data sets between the two groups.
• Each group should understand and agree on the types of matters that will likely result in work for the other, whether it be full or partial handover of work. When such issues occur, communication with the other group should start as early as possible e.g. the other group should have the option to attend meetings and conference calls prior to actual referral of work.

Ultimately the groups will need to reconcile what might be different investigative priorities – will their focus be on catching and punishing individual bad actors (be they internal or external, the latter being much more difficult), or finding and closing control gaps to bolster the organisational security posture. These are not always mutually exclusive, but what kind of balance can be struck between them?

Beyond digital forensic analysis of a single computer system

It is important to note that modern cyber investigations will frequently go beyond digital forensic analysis of a single computer system. Largely gone are the days when one might physically seize a computer, extract the hard disk drive and subject it to the forensics process in isolation, with reasonable confidence that it would contain all evidence pertinent to the case. Although you still might find your ‘smoking gun’ on that hard drive, on corporate networks there is likely to be a wealth of other relevant data to add to the picture.

Some examples would be centralised logs of internet browsing activity; e.g. enterprise systems, management and inventory systems, insider threat monitoring systems, centralised anti-virus logs, document management and classification systems. These can not only help you to get to pertinent data quickly but can also be used to assess what is normal in your company, i.e. you can baseline activity using these systems, in order to verify what you think may be an anomaly on system under investigation.

In cyber intrusion investigations it is likely that attackers will want to move beyond the computer system they initially compromise to gain access to your organisation, referred to as ‘lateral movement’, in order to reach their real target. Likewise, in internal misuse investigations involving insiders with privileged access, systems administrators or developers, you may find that they have used a trail of systems in pursuit of their goals.

Required domains of coverage

The scope of different evidence source for our cyber investigation may include the following, beyond singular desktop or server computers. Each may offer its own challenges in terms of what is relevant evidence and where and how to collect that evidence. You are likely to have to rely on technical teams in your organisation to either implement centralised aggregation of data, in a way that is conducive to analysis, or to obtain the evidential data for you, on a case-by-case basis.

Networks and network traffic

An intruder in your network, or indeed an insider threat, may be interested not only in compromising your corporate laptops, desktops and server systems, but also the infrastructure that ties them all together. This could be network devices like routers and switches. There are ways to attack such systems that allow an attacker to subvert the traffic flow around your network, so that they may cause all the traffic from your CEO’s laptop to flow through a computer under their control, allowing them to eavesdrop and even alter elements of that traffic, e.g. they may steal a one-time password, or an encryption key to gain access to protected intellectual property.

Your organisation may have a network team that deploys devices for troubleshooting network connectivity problems, that are capable of capturing full traffic data, speak to them about when, where and how to deploy these devices if there is an investigative need.

Larger organisations may employ full capture of traffic for IR purposes, or they may capture what is called ‘net-flow’; this is metadata about which computers are talking to one another, without the full content, analogous to a phone bill, a list of both numbers, at each end of a phone call, the duration, etc.

Enterprise applications

In a large corporate environment the investigator is likely to come across many internal applications, each of which could be composed of many computer systems with different roles. Some applications will be new and under active development, some will have been around for many years.

In a mature organisation one can hope to find a catalogue of all the corporation’s applications, e.g. including relevant business contacts for each, the classification of data the application deals with, information security risk associated with the application. Quick access to such information is vital in the early stages of an investigation, where you must engage the relevant stakeholders to understand the implications of a data leak or compromise; assess the need for containment actions against the application etc. If such a database of contacts is not known to you, consider the organisation’s continuity of business department or disaster recovery and their emergency call-trees. Failing that, you may have to make your own list.

Business applications are also likely to have several environments. Production for the actual live data and everyday business use, as well as User Acceptance Testing (UAT), where improvements or fixes to the application are tested before deployment to production, and finally, the development environment where programmers are free to make changes at will. Note that, often, in the latter two, known as ‘lower environments’, progressively fewer security controls may be in place and more people may have higher levels of access. For this reason it is bad practice to use real production data in the development environment and developers should not have access to the production environment. These sometimes happen and since controls are most lax in such environments, this can often be where leaks or compromises occur.

Remember to consider that attackers may exploit internal systems for sharing information among teams to gain valuable insights about how your organisation works, e.g. project management systems and internal intranet sites with documentation. Business users can often make incorrect assumptions about the usefulness of such data to a malicious insider or intruder. Or they may assume that only they and others with a need to know can access such systems, when those systems are not properly restricted.

Tiered architectures

In modern e-commerce applications, it is common and best practice, to employ tiered architectures. An example of this might be a web application that requires information from a corporate database to function, e.g. customer account information.

The most important data to protect here is the database containing customer data which is the information that would cause reputational damage if compromised. The corporation has a duty of care to protect it; however this is an internet-facing application so by definition some component must be publicly accessible. The result is that we have one or more web servers, behind an internet firewall and then we have another layer of firewalls that protect the database server. The web server may only communicate with the database server, using the specific protocol required to retrieve the data needed for the application to work. A frequent mistake is to place the database server on the corporate internal network. This can allow an intruder all the way in, should they find a flaw that allows them to run commands on the database through the web application.

The above explanation is somewhat over-simplified, but it is all to say that should such a compromise occur, there are now several computers involved and the evidence required to tell the story is already distributed. The method, or ‘exploit’ used by the attacker to compromise the web server, providing the web page, and possibly the attacker’s IP address, will likely be recorded in the logs on the web server. The database server may need to be assessed to see if data has been changed, which will likely require specific expertise, that of a Database Administrator, (DBA). If the attacker has moved to other internal network systems from the database server, evidence of that lateral movement may be in, amidst others, logs on the database server, or network traffic logs.

Locations of logs

As in the previous example, where we discussed the locations of different pertinent data logs can be centralised, as a best practise your company may have a Security Event Incident Management (SIEM) product that receives logs from disparate sources and normalises them for fast searching, correlation etc. Even so, log volume might be too high to send everything. Perhaps your organisation needs to only forward the most important logs to a central point based on certain criteria. If such selective central log aggregation is the model being used then it may be important to go back to the source and retrieve remaining logs for additional context.

Note that although SIEM systems are most often associated with Enterprise Information Security monitoring, etc., they are also well suited for fraud monitoring and detection, Gartner 2008.^[3] Any process that generates a large amount of structured log data, like building security access systems, could be fed into a SIEM for analysis by investigators. This data can also be enriched from other sources when ingested. For example, geo-location data can be added to electronic transactions, to flag the country of origin of a purchase; or to alert when an employee logs in from one location, then from another within a short space of time. This type of data point, gleaned through correlation of temporal and location data is referred to as ‘impossible travel’, and can indicate either compromise of an employee’s credentials, or sharing of those credentials.

Types of cyber investigation

Misuse

Misuse investigations focus on employees performing actions that are against policy or are damaging to the corporation in some way. These actions may be intentionally malicious, or perhaps well-intentioned but due to lack of training, or perhaps just negligence. Cyber investigations of this type are generally around data, leakage of data, unauthorised viewing of data, or data being where it should not be.

Prevention of data loss

Email

Monitoring and restriction of outbound communications, in order to identify intellectual property, can be expected to result in incidents that may fall within the remit of a cyber investigations team.

Your organisation may have a system for the classification and protective marking of documents and files, that may be partially automated, e.g. by add-on software that forces a user to apply a classification whenever they save a new Microsoft Office document, or which applied a classification automatically based on a set of rules. Even if this is the case, it should be born in mind that the business unit that owns the data should be consulted to understand the true implications of losing particular files or data. Consider consulting the direct manager of the investigation subject, e.g. the sender of the email containing confidential data, in order to verify the appropriateness of a protective marking or classification.

Also consider the organisation’s responsibility to guard and properly handle Personally Identifiable Information (PII) and the need to properly report its exposure or loss.

Credential exposure on public sites

Modern software development practices involve the use of centralised ‘code repositories’ for collaboration, versioning and tracking. Your corporate developers may have internal repositories that they are supposed to use, but may favour and attempt to use public implementations instead.

A popular implementation of this is a system called Git, and the Microsoft-owned GitHub.com is the most popular public web-hosted repository for Git. A surprisingly common, industry-wide problem is the, usually, mistaken including of secrets, e.g. passwords and access keys in code stored on GitHub by corporate developers, that are then available to the public.

Malicious actors are well aware of this possibility and actively scan for credentials included in public repositories. One test performed in 2020, posted a set of credentials for accessing an Amazon Web Services (AWS) account on GitHub. They observed an attempt to use those same credentials within one minute of posting them, likely an automated process put in place for the express purpose of finding and exploiting posted credentials.^[4]

Intelligence vendors can be engaged to perform automated scans for such credentials associated with your own organisation. If these are reported, the temptation will be to reset them immediately to prevent them being used. If they are in the repository as a component of an application, the credentials may be used by that application, rather than a person. As such, resetting them may break that application’s ability to access data, with unforeseen consequences for the business process the application supports. Balance this with the security aspect of protecting the data, and obtain proper approvals from the relevant stakeholders before performing the reset of passwords, etc.

Removable media

Organisations should weigh the benefit of allowing end users to use portable storage devices. If your organisation decides to allow their use, then you should be aware of what monitoring takes place of files copied to or from devices. Without monitoring software designed to record such activity, it is difficult to track files copied to an attached USB thumb drive, for example.

A forensic examination of the computer may be able to tell you if an employee opened one or more files from a thumb drive, after copying them, but the act of copying the files may not be recorded at all. For example, imagine a collection of fifty Excel spreadsheets containing financial models and Word documents describing the design of those models, likely very valuable intellectual property, are copied to an attached device and only one of them is opened from the destination. It is likely that a digital forensic examination of the computer used, assuming that you do not have access to the USB stick, may only tell you about the single file that was opened. This is because forensic examinations often rely on analysing mechanisms that exist to help the user. In this case, the computer creates a ‘link file’, also known by its extension ‘ink’, so that it can present the computer user with the choice of re-opening that same file later. This is one way that a Microsoft Windows computer maintains the recent documents section, in the start menu. It does not track individual or groups of, copied files in the same way. See chapter 10 for additional details on digital forensic artefacts.

Proof of life

A relatively simple, but most likely very urgent, request may come to your cyber investigations team. For example, to provide evidence of the last time an employee used corporate systems as a way to know the last action attributable to them, should they go incommunicado for any reason.

An example might be a business traveller, who colleagues have unexpectedly been unable to contact. You might do this by searching for logs of their most recently sent email, or their most recent connection to the corporate VPN. The source IP address of such a connection may give a rough geographical location usually accurate to the city the connecting device is in, assuming no measures to mask location have been taken.

If your company uses a Mobile Device Management (MDM) system to administer corporate mobile phones or other devices, you may be able to determine the last time that device synchronised data or configuration settings, or even GPS coordinates, if that capability is enabled. Establishing what type of data and capabilities are available and for whom, e.g. VIPs only, before an event.

The war in Ukraine is an example of a situation where this kind of capability might be needed unexpectedly and on a large scale.

Network intrusions and malicious software

These investigation types may intersect with the domain of the Information Security department of a given organisation. However, if your investigations group are able to operate when a matter is decided to fall under legal privilege, consult your legal department, then a corporate investigator may find they are involved. Even if the responsibility is purely managing the activities of third party vendors, brought in to investigate, a base level of understanding is important.

There follow brief descriptions of several case types, with some examples, and basic considerations for each. Covering all varieties of malware is beyond the scope of this chapter.

Supply chain attacks

There have been a number of very successful supply chain attacks in recent years. Two interesting examples are ‘NotPetya’ 2017, a supposed ransomware attack on users of Ukrainian accounting software; and ‘SolarWinds’ 2020, software for managing large fleets of computers and network devices, used by many large corporations and even government departments.

In both of these examples, malicious code was implanted in software, at source, that was otherwise trusted by the organisations using it. Both attacks are thought to be attributable to state sponsored groups.

In the case of NotPetya, the intention seems to have been to deliver a destructive payload, encrypting the contents of hard drives of computers the malware spreads to, initially masquerading as ransomware, an electronic ransom note was displayed, but there was no way to obtain a decryption key by paying the ransom. Investigating a NotPetya infection would focus on the identification of computers running the MeDoc accounting software, as the likely entry point or point into your corporate network, and the tracking of the spread of the malware, to ensure that all affected systems were cleaned.

For the SolarWinds attack, the investigation could be considerably more complex. In this case and in other large-scale incidents like it, intelligence vital to any affected company’s internal investigation is published by a variety of vendors and government bodies. This could include the results of reverse engineering of the malware that yields indicators of compromise you can use to search your own systems and networks to find computers that have been impacted. Being able to consume such shared intelligence and make it useable by internal investigators avoids them having to repeat difficult and time-consuming analysis tasks.

Ransomware

Ransomware is a type of malware that usually attempts to encrypt files on an infected computer, often on network shared drives the computer user has access to, and then displays a ransom note on the computer screen. The ransom note attempts to convince the reader of the futility of attempting to decrypt the files without the decryption keys that can only be obtained by paying the ransom. Instructions for paying the ransom using cryptocurrency, like BitCoin, usually follow.

In its 2021 review,^[5] the UK National Cyber Security Centre (NCSC) defined ransomware as ‘the most significant cyber threat facing the UK this year’, citing the Colonial pipeline attack, among others.

A response to this type of attack will usually have four focus areas or stages,^[6] note that these overlap with other related investigation life-cycle stages;

• containment or isolation of infected systems;
• triage of those systems;
• full or more comprehensive analysis of infected systems; and
• recovery, informed by the results of the investigation.

Containment is largely the job of a corporation’s Security Operations Centre (SOC), which may also perform the triage stage, which is about scoping the impact of the attack, and learning the tools techniques and procedures (TTPs) used, identifying the variant of ransomware or analysing it if it is a variant not previously seen and its effect on the infected computer, etc. It is in the triage stage that additional activity of note could first be identified, beyond the rote encryption of files. Perhaps the triage identifies the capability of the ransomware to not only encrypt files but to upload them to a server, on the internet, controlled by the attackers. This may indicate that the attackers have extortion in mind, based on the contents of the files. Perhaps the uploads are even selective in terms of the data they are looking for. This may call for a deeper dive beyond the incident response focussed analysis, including memory and full disk forensics, in order to gain a better understanding of what the attackers may have in their possession and to corroborate the understanding of their methods and motives gained previously.

Investigators will need to gain full understanding of way the ransomware was first deployed into the organisation. It may surprise some to know that criminals deploying ransomware will often gain hands-on control of multiple corporate systems before manually triggering the ransomware malware, rather than deploying it directly through email attachments, or other delivery methods. One motive for going to this extra trouble is so that they can learn about a company’s data backup strategy in order to make sure those are also affected, making recovery much more difficult. Additionally, it is vital that, at both triage and full forensic examination stages, investigators look for secondary methods of access created by the attackers. It is common for ransomware victims, even those or especially those who pay, to face a second attack and the presence of such a backdoor may indicate that intention.

Network intrusions

Intrusions are one of the most serious incident types your investigation team may be called upon to participate in and one that requires full interaction with most of the other teams in your organisation responsible for network security monitoring, cyber intelligence, etc. Examples of how such intrusion can be detected might be:

• outgoing command and control communication traffic to known attacker infrastructure, or data exfiltration to unauthorised websites;
• detection of known attacker tools on a system on your network; and
• detection of a data cache on an internal system, where an attacker is gathering information taken from other systems, prior to exhilarating it, for example a copy of your Windows Active Directory database, on a workstation used by a public facing employee.

If you identify what you believe to be a successful intrusion onto your network by a threat actor, especially if you believe them to be state sponsored or affiliated, threat group such as a so-called Advanced Persistent Threat (APT), contact your legal team and consult them about legal privilege in addition seriously consider bringing in outside help. This can not only provide you with expertise and experience in dealing with the intrusion but can also be helpful in terms of legal liability.

Lateral movement

Investigative questions to be answered in such cases include:

• How did the initial compromise occur? Who, or what, was ‘patient zero’, the first employee or computer to be affected? To find out it may be necessary to work backwards from activity by which the intrusion was detected. An example might be that a particular IT administrator’s credentials were used to send data out to an external website and those credentials fell into an attacker’s hands, when the administrator connected to a business person’s computer that had been first compromised by attackers using a phishing email with a malicious link to a piece of malware. Perhaps the attackers have induced the business user to call the helpdesk, knowing that an administrator will connect, or perhaps they are just patient.
• Have the intruders developed their access beyond the computers you already know about, or is a malicious insider using other computers he or she should not be? Moving to other computers or controlling them remotely is known as ‘lateral movement’. There are many techniques for doing so, with purpose built tool sets such as Metasploit^[7] or Cobalt Strike.^[8] These are ostensibly built for the use of Penetration testers, or Red Teams, but stolen copies are used by malicious threat groups. Both allow for attackers to control many computers within a target organisation, they have software components that must be installed on each victim system, which are designed to be stealthy, but can be detected by Anti-Virus software. Alternatively, attackers may choose to try to avoid purpose build software that might be detected as malware and, instead, use the same tools and techniques as your organisation’s IT group. This is known as ‘living off the land’, and can make them harder to detect. Here the focus in investigating must shift from finding uncommon software or attack tools, to observing and analysing the behaviour of computer users. A good starting point for analysing lateral movement is a poster published by SANS; this describes various artefacts that an investigator can look for, on both the source and destination computer involved in unauthorised lateral movement.^[9]

Support for other corporate investigation types

If you have a group of investigators primarily responsible for non-cyber investigations your cyber team may be enlisted to help them with aspects of their cases that demand technical skills. Consider creating regular training courses and drills for these colleagues, to enable them to act as first responders if computer systems need to be seized and secured for investigation.

An example of when this may be necessary is if your company has offices with low bandwidth network connections that make remote collection or examinations less practical, i.e. in countries with low-grade infrastructure. You may want to consider maintaining a dedicated investigation computer in such an office that your investigators can remote control when needed. The logic here is that the data-flow of evidence collection is from one computer on a local office network to another on that same internal office network, rather than over an expensive wide area network link.

Wide Area Network (WAN) links in some countries may be using technologies that can only just support the amounts of data throughput for business applications to communicate between offices, or may be scoped that way to keep costs low. Collecting a full forensic image of a hard drive can saturate such a link, potentially blocking or slowing down communications for legitimate business processes.

If your organisation has a hotline that can be used to submit anonymously report policy breaches, legal issues, etc. some of the resulting investigations may require the involvement of your cyber investigations team in some capacity.

Be aware that if you are using tools to gather data that are shared with other groups, like systems management tools used by IT, the computers you target for collection may be visible to non-investigators who also use that system, impacting the confidentiality of your investigation.

Consider this, if the identity of the reporting person must be protected, as it may need to be certain case-type, e.g. when they are raising ethics concerns. Note that some such tools may even leave a trace in system logs on the target computer that may telegraph some aspect of the investigation to a technically savvy investigation subject. For example, a search using the types of tools used by an organisation’s Security Operations Centre (SOC), which cyber investigators may make use of when broader searches are needed, may leave queries containing revealing keywords in the target computer’s security log. This may have the effect of tipping off the subject.

See Chapter 12 for additional information on support for corporate investigations.

Governance

Lifecycle of a cyber investigation

The investigation lifecycle should be something of a feedback loop with the outcome of the investigation, including lessons-learned for the investigations team and tracking of any enterprise processes for addressing identified systemic issues. This section lists the high-level stages of conceptual a cyber investigation lifecycle. These stages are not prescriptive in terms of actual process, but are intended to represent a high-level view of how an organisation might handle the lifecycle.

Note that some of the described stages may occur concurrently or in a different order to that below, e.g. the remediation stage may last longer than the investigation itself.

Who to work with

It is important to ensure, as early as possible, that the people who need to know about an investigation are briefed, and are then kept updated at regular intervals. However, choose your stakeholders with care, and with regard to timing of evidence collection, preparation for investigative interviews, etc. It is an unfortunate truth that people-managers, informed of wrongdoing on the part of a direct report, often find it hard to resist – albeit usually with the best intentions—taking the investigation subject to task personally. This can have implications for your investigation, including giving the subject time to anticipate and plan answers to your questions, and event to spoil evidence or disrupt collection.

In addition to the management structure within and above your cyber investigations group, consider informing:

• heads of business units related to the subject involved, or who own the data involved;
• human resources;
• groups or individuals responsible for an application or system that is affected by the incident;
• legal, especially for network intrusions or other, larger incidents; and
• representatives of other teams involved in incident management or crisis management.

Establish a standard, documented process for selection of these stakeholders, a target deadline to inform them, and a cadence for ongoing updates.

Consider the importance of socialising your cyber investigations teams with technical support teams within your organisation, so that those teams understand the importance of waiting for a signal before rebuilding systems that are involved in an incident.

Frameworks

There are frameworks that can be helpful to guide a cyber investigation, consistent and proper use of which can help an organisation’s investigation capability to mature quickly. Those described here are popular examples, others are available.

One popular model is the Lockheed Martin Cyber Kill Chain,^[10] developed by investigators at the US defence contractor to guide them in identifying the stages adversaries must complete in order to achieve their objectives. The model has seven identified stages. The first is reconnaissance, where adversaries are conducting probing scans of your organisation’s public-facing infrastructure, or attempting to find email addresses to send phishing emails to. Later stages include command and control, where an external party is able to control computers or devices inside your network, and actions on objectives. Where the attacker has finally gained access to the corporate resources they are attempting to steal or disrupt. A full description of all seven stages is beyond the scope of this chapter, but the model’s usefulness comes partly in trying to account for, or rule out activity at all of the stages. If you have identified malicious communications traffic leaving, command and control, there must have been a prior stage where adversary tools were installed and attackers are likely to be moving to the next stage, e.g. finding material of interest and taking destructive actions. Cyber investigators may build a full picture of an attack by ensuring they understand the activity at all stages.

The MITRE ATT&CK,^[11] Attack framework is a knowledge base of offensive Tactics Techniques and Procedures (TTPs) used by cyber threat groups, organised around a matrix of fourteen tactics, similar in principle to the stages of the Cyber Kill Chain model, described above. Each tactic has a number of techniques under it, for example the ‘initial access’ tactic, contains nine techniques, two of which are Phishing and Supply Chain Compromise. Under each technique there are examples of procedures using the techniques, with examples of their use by specific threat groups, examples of how to mitigate the technique and how to detect it. One of the strengths of the model, from a cyber investigation perspective, is that the investigators can use the knowledge base to ensure they are abreast of the methods used by real world attackers. Investigators can profile the threat groups known to specifically target their organisation’s industry and determine whether the investigation team’s own documentation, tools and processes are able to accurately find use of those methods. Being able to document this process and show that the team is ready to investigate malicious activity known to be effective against industry peers is a way to demonstrate the team’s value to management. Further, the team can contribute to assessing the readiness of the wider organisation to respond to such a threat and can positively influence the organisational security posture by helping to consult on appropriate preventative and detective security controls.

The Vocabulary for Event Recording and Incident Sharing^[12] (VERIS) framework is ‘a set of metrics designed to provide a common language for describing security incidents in a structured and repeatable manner’, having a consistent taxonomy for describing incidents in progress.

Major categories of events are referred to as Threat Actions: Malware, Hacking, Social, Misuse, Physical, Error and Environmental. These Threat Actions have different varieties, for example, under the Misuse action, perhaps the types of events most likely to involve traditional Corporate Investigators are twelve varieties, including the following examples:

• Knowledge abuse;
• Abuse of private or entrusted knowledge;
• Privilege abuse: Abuse of system access privileges;
• Embezzlement: Embezzlement, skimming, and related fraud; and,
• Data mishandling: Handling of data in an unapproved manner.

Using taxonomy like VERIS to categorise cyber investigation cases promotes consistency for statistical analysis, trending and reporting.

Building capability

Chapter 12 includes a tiered model for building a digital forensic capacity, depending on the needs and resources of an organisation. That model applies to cyber investigations too.

People and skills

When recruiting your investigators, you may find that the market for properly trained and experienced Cyber investigators competitive. Applicants to join your team that may come with varying from different backgrounds that may include the following:

Previous law enforcement experience:

• Investigation skills and experience, e.g. interviewing, handling evidence, exposure to variety of wrongdoing and perpetrators, etc.
• Courtroom testimony experience - this can be an infrequent requirement for Cyber Investigations in the corporate setting, but should be planned for.

Previous enterprise IT experience:

• Investigation of complex multi-tiered enterprise applications can be very different to individual systems, with complex architectures involving many systems and network devices, etc. People with these skills may be useful, especially if they are recruited from within your organisation, in which case they may come with valuable institutional knowledge.
• New graduates from the increasing number of higher education courses focused on digital forensics and cyber investigations.

You will have to decide on the balance of such skills you need among your team. A mixture of the above may work best, so that the team members’ different areas of expertise can complement one another. Also consider the availability of different training resources in your organisation, are you more readily able to train an already highly technical person in missing investigative skills, or the opposite?

Tools, equipment and capabilities

Chapter 12 covers digital forensic tools and considerations for how different types of digital evidence are examined. This section goes into some additional detail on some of the tools that are relevant to the case types discussed in this chapter.

Memory analysis

Computer memory can be thought of as the working consciousness of the computer, any document being displayed on the screen for viewing or editing, any behind the scenes configuration data or settings for applications, must be read into memory from storage, e.g. the hard drive, a network location, or a USB device. The contents of memory can be captured using specialist tools, including some commercial and some open source, usually free for non-commercial use. Capture and analysis of memory is often associated with malware and intrusion investigations. Some malware, known as ‘fileless’^[13] malware is designed not to be written to the hard drive, existing only in memory, or being stored in an unusual location; perhaps crammed into a location usually used to store configuration settings.

With the right tools and timing, e.g. if the memory is captured during the commission of malicious activity, or at least prior to the next computer restart, memory analysis can also tell the investigator a great deal about the computer user’s activity, that might be difficult to learn otherwise. Some practical examples of information that could persist in memory:

• notes typed into an open text file or document, or changes made to a document that were not saved; or
• contents of files that are encrypted when saved to disk, that the computer user was viewing at the time the memory was collected.

Incident response versus forensics tools

There is naturally some overlap between tools designed with IR in mind, and tools specifically designed for investigation. A corporate incident response or information security team might deploy a class of tools called Endpoint Detection and Response (EDR) which Gartner^[14] defines as:

…solutions that record and store endpoint-system-level behaviours, use various data analytics techniques to detect suspicious system behavior, provide contextual information, block malicious activity, and provide remediation suggestions to restore affected systems.”

Such tools record all the ‘goings-on’ on a monitored computer, i.e. network endpoint, and make usually rich and detailed logs available in a central searchable database. Such tools can often answer some of the questions a cyber investigator would want to ask about what a person was doing on a computer. The main shortcoming is that what is made available to the investigator is usually in the form of log data, or metadata, EDR tools do not make it as easy, as traditional forensic tools to access the content documents, e.g. pictures and spreadsheets, of the computer system under analysis.

Problems to anticipate

As with any investigation, cyber investigations might include interviewing employees and these inherently bring their own potential pitfalls. Please consider GDPR and employment law issues when interviewing employees and guidance from within your own organisation in methods of doing this. Below are potential of technical problems which the investigator might find and it is not an exhaustive list.

Encryption

Encryption can protect corporate data but if your workforce have access to encryption software that does not centrally store keys, or have a corporate master key facility those investigators can access, through a controlled process, then you may be unable to decrypt and inspect the data. Ensure you know the person who has access to the master key, in a windows environment this would typically be the BitLocker key repository and would likely be someone within your organisations IT team.

Bring Your Own Device (BYOD)

BYOD is attractive to some organisations and workers alike, workers get to use their brand-new technology and the organisation potentially saves money on the cost of laptops, tablets, mobile phones, etc. However, one drawback from an investigative perspective is that you may not have the right to seize and examine the device if it is owned by the employee and not the company. Doing so, even with the permission of the employee or owner may also carry risk. What do you do if you find evidence of other crimes on the device? Or there is intellectual property owned by the employee’s spouse’s business, etc. What if, during the process of examining the device, it breaks? Could the company be held liable? These and more questions should be anticipated before accepting a non-corporate owned device for examination, whether it is an employee’s device or a customer’s device. Such issues and problems should be anticipated in a form of a policy or guidance when obtaining BYOD’s devices and made clear to the employee handing over the device.

Moving data around your network

The logistics of collecting data like artefacts from a computer under investigation, or the contents of a network shared drive, must be evaluated for improperly stored Personally Identifiable Information (PII) and moving it to your investigators must be carefully considered in terms of geographic restrictions.

The logistics of such transfers can also be problematic, consider your offices in countries with low-grade telecommunications infrastructure. Inter-office communications links that can only support low bandwidth communications may prolong the process of collecting investigative data and may even require you to change the scope of or minimise the data collected, in order to reach conclusions within an acceptable timeframe.

Be mindful that you may need specific legal agreement, in order to transfer data between specific countries, and this may need to inform where you employ members of your cyber investigations team. Consult your legal team to ensure you are compliant with the laws of all applicable countries.

Reliance on other teams for evidence collection

There may be situations where there are compelling reasons to entrust teams outside your investigations group to assist in the collection of digital evidence. For example, modern corporations increasingly use virtual desktops instead of conventional desktop and laptop computers; perhaps on the employee’s desk there is just a small box to which the keyboard, mouse and screen attach. The actual computing is happening on a server in a data centre which is also serving multiple other employees. Depending on the implementation the individual employee’s computer may still have distinct files that represent its hard drive data and memory. Asking the team who manages the infrastructure to supply those files to the investigation team can be significantly faster than using forensic tools to remotely collect a full hard disk image, but this places a significant part of the evidence collection capability on that team, who may regard this as a secondary responsibility. Defining playbooks for them to follow in the event that they need to do this is important, as is ensuring they are appropriately drilled and trained on using the playbook.

The speed advantage described above could have a corollary. Although the speed of evidence collection is greater when you can just collect a file that represents the computer’s hard disk, a virtual disk, these systems may work differently than real physical hard drives in important ways. For example, in digital forensics deleted file recovery relies on the fact that, for efficiency, when the computer user deletes a file or document the file data is not actually removed from the hard disk, instead the area is marked as free and available for use. When the area is needed to store a new file, the new content overwrites the old but, until then, the previous content is still readable and recoverable with the right tools. With virtual disks these ‘free’ areas may not be preserved when the virtual disk file is copied for investigators, and so data recovery tools may not work on the collected virtual hard drive. Test your own implementation to determine whether all expected data:

• is deleted file content still accessible as you would expect; and
• is available and plan to collect in this this capability accordingly.

Knowing when to stop investigating

Deciding when you have done enough and can stop looking can be a problem with the amount of data concerned, especially in a situation where you believe a number of systems were compromised, but you have cut off the intruder’s access to your network. Or perhaps you receive intelligence that prompts you to initiate investigations of several systems out of an abundance of caution. Such intelligence can sometimes be vague and may not lead to any findings, so when have you done enough to draw a line under a certain matter and close the investigation?

A useful approach is to define specific exit criteria for an investigation

This might be based on what is sometimes referred to as the ‘blast radius’ around a particular computer or employee, based on potential or actual access to other systems connected to one that has been compromised or misused.

You might define a set of checks based on identifying, or ruling out, lateral movement to or from those other systems, along with other activity related to the matter under investigation. If no predefined indicators or behaviours are found, perhaps you may decide that that is enough to declare the incident properly contained and the investigation completed. Note that this always has to be judged in the context and circumstances of the particular investigation.

Resource constraints

Even if you decide to dedicate significant resources to build a fully-fledged cyber investigations team, there may be incidents for which they are not sufficiently trained, experienced, or numerous to handle the workload.

To be prepared for this eventuality, consider retaining the services of a vendor who can quickly supply you with experienced investigators or responders, to scale up when the need arises. Explore the possibility of having specific vendor staff who can periodically spend some time on-site, with you and your team, before a crisis occurs, in order to gain some familiarity with your technology stack, environment and staff. This will allow them to hit the ground running, when the time comes.

New paradigms

Currently large and small corporations are increasingly taking advantage of cloud computing. From a cyber investigations perspective this can manifest in several ways.

• Cloud storage: companies may find some benefit in allowing the use of cloud storage mechanisms, like Dropbox and Google Drive, or indeed, realise that employees have been using them without permission. This aspect is discussed in detail in Chapter 12.
• Cloud Computing: companies like Amazon, Microsoft and Google offer the ability for corporations large and small, to have some, or almost all, of their IT infrastructure hosted in the cloud. Essentially this just means that if you need the use of a server, or ten, you can easily commission and start one within the cloud provider’s network. The computer you are starting will not be a real physical one, but a virtual machine, essentially a software simulation of a separate computer running, along with others inside a much bigger, physical computer. Much more detail on how this works is beyond the scope of this chapter. Suffice it to say that the advantages of this are that you don’t need to order, or pay for new hardware, wait for it to arrive at your facility and then have technicians spend something in the order of days or weeks preparing it for use in your own corporate network. It is easy to scale up and down your fleet of servers as needed, in terms of demand. Computing power can be added and removed quickly, and if you only need five servers instead of ten on weekends, you can simply terminate the five unneeded machines on Friday evening and create five new ones on Monday morning.

With cloud computing the implications for cyber investigators, is that the ephemeral nature of cloud-based computers may mean that the particular computer they are interested in, i.e. one of the five terminated on Friday, may no longer exist, even a short time after the incident under investigation. This concept of replaceable computers, managed ‘en masse’ in the form of descriptive code templates and replaced if they exhibit problems, is explained in an analogy of ‘cattle, not pets,’^[15] systems are not given cute names and coddled by IT staff, they are treated as a herd and culled rather than nursed through problems. All this is to say that finding evidence of activities that happened weeks or months ago, as is often possible in traditional IT environments, is less likely in this new way of working.

You cannot count on having access to anything that existed within the hard drive of the computer in question. Retaining logs of activity from your herd of server cattle in a central location is therefore important and the investigations group should ensure that logged activity is pertinent to investigations and not just IT troubleshooting. Some Cloud providers offer services that facilitate aspects of log collection, storage, and even artificial intelligence based analytics. Training and drilling is a must for investigators to understand how those services work.

The cyber investigations team must be involved with cloud development teams, preferably as early as possible in the organisational move to using cloud computing to ensure that their needs are met. A priority should be developing automation of the collection of, full, investigative data from these systems that can be triggered immediately on detection of malicious activity or misuse, in order to keep up with the pace of change in the Cloud environment.

Legally reviewed by Christoph Haid (Schoenherr ­– Vienna).

Footnotes