30,99 €
Incident response is critical for the active defense of any network, and incident responders need up-to-date, immediately applicable techniques with which to engage the adversary. Applied Incident Response details effective ways to respond to advanced attacks against local and remote network resources, providing proven response techniques and a framework through which to apply them. As a starting point for new incident handlers, or as a technical reference for hardened IR veterans, this book details the latest techniques for responding to threats against your network, including:
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 794
Veröffentlichungsjahr: 2020
Cover
Part I: Prepare
CHAPTER 1: The Threat Landscape
Attacker Motivations
Attack Methods
Anatomy of an Attack
The Modern Adversary
Conclusion
CHAPTER 2: Incident Readiness
Preparing Your Process
Preparing Your People
Preparing Your Technology
Conclusion
Part II: Respond
CHAPTER 3: Remote Triage
Finding Evil
Guarding Your Credentials
Conclusion
CHAPTER 4: Remote Triage Tools
Windows Management Instrumentation Command‐Line Utility
Forensically Sound Approaches
PowerShell
Incident Response Frameworks
Conclusion
CHAPTER 5: Acquiring Memory
Order of Volatility
Local Memory Collection
Remote Memory Collection
Live Memory Analysis
Conclusion
CHAPTER 6: Disk Imaging
Protecting the Integrity of Evidence
Dead‐Box Imaging
Live Imaging
Imaging Virtual Machines
Conclusion
CHAPTER 7: Network Security Monitoring
Security Onion
Text‐Based Log Analysis
Conclusion
CHAPTER 8: Event Log Analysis
Understanding Event Logs
Account‐Related Events
Object Access
Auditing System Configuration Changes
Process Auditing
Auditing PowerShell Use
Using PowerShell to Query Event Logs
Conclusion
CHAPTER 9: Memory Analysis
The Importance of Baselines
Sources of Memory Data
Using Volatility and Rekall
Examining Processes
Examining Windows Services
Examining Network Activity
Detecting Anomalies
Conclusion
CHAPTER 10: Malware Analysis
Online Analysis Services
Static Analysis
Dynamic Analysis
Reverse Engineering
Conclusion
CHAPTER 11: Disk Forensics
Forensics Tools
Time Stamp Analysis
Link Files and Jump Lists
Prefetch
System Resource Usage Monitor
Registry Analysis
Browser Activity
USN Journal
Volume Shadow Copies
Automated Triage
Linux/UNIX System Artifacts
Conclusion
CHAPTER 12: Lateral Movement Analysis
Server Message Block
Kerberos Attacks
PsExec
Scheduled Tasks
Service Controller
Remote Desktop Protocol
Windows Management Instrumentation
Windows Remote Management
PowerShell Remoting
SSH Tunnels and Other Pivots
Conclusion
Part III: Refine
CHAPTER 13: Continuous Improvement
Document, Document, Document
Validate Mitigation Efforts
Building On Your Successes, and Learning from Your Mistakes
Improving Your Defenses
Conclusion
CHAPTER 14: Proactive Activities
Threat Hunting
Adversary Emulation
Conclusion
Index
End User License Agreement
Chapter 3
Table 3.1: Common lateral movement connection ports
Chapter 4
Table 4.1: WMIC switches
Table 4.2: Common WMIC aliases
Table 4.3: Common
where
clause WQL operators
Table 4.4:
LIKE
operator wildcards
Table 4.5:
wmic
verbs
Table 4.6: Common cmdlets useful for remote triage
Chapter 5
Table 5.1: Commonly used
winpmem
command switches
Chapter 7
Table 7.1: Protocol‐specific logs created by Zeek
Table 7.2: Additional Zeek logs of interest
Table 7.3: Sample
grep
commands for searching for specific information
Table 7.4: Example uses of
cut
and
sort
commands
Chapter 8
Table 8.1: Default event log fields
Table 8.2: Common Event ID 4768 result codes
Table 8.3: Common Event ID 4776 error code descriptions
Table 8.4: Logon event type code descriptions
Table 8.5: Common logon failure status codes
Table 8.6: Account management events
Table 8.7: Network share event IDs
Table 8.8: Scheduled task events
Table 8.9: Object handle event IDs
Table 8.10: Scheduled task activity event IDs
Table 8.11: Wi‐Fi connection event IDs
Table 8.12: Event ID 4688
Table 8.13: Windows Filtering Platform (WFP) event IDs
Table 8.14: Windows Defender suspicious event IDs
Table 8.15: Event IDs generated by Sysmon
Table 8.16: Example PowerShell event IDs in Microsoft‐Windows‐PowerShell%4Op...
Table 8.17: Example PowerShell event IDs in Windows PowerShell.evtx
Chapter 9
Table 9.1: Default Windows operating system processes
Table 9.2: Sample Rekall/Volatility plug‐ins
Chapter 11
Table 11.1:
NtfsDisableLastAccessUpdate
values
Chapter 12
Table 12.1: Account logon events
Table 12.2: Logon events
Table 12.3: RDP‐specific indicators in the Security event log
Chapter 2
Figure 2.1: The active cyber defense cycle
Figure 2.2: The NIST incident response life cycle
Chapter 3
Figure 3.1: RITA detecting a C2 beacon
Figure 3.2: Autoruns showing various Windows autostart locations
Chapter 4
Figure 4.1: An example of using WMIC to access a remote computer named DC1
Figure 4.2: WMIC help showing the arguments accepted by the
list
verb
Figure 4.3: Using WMIC to find executables running from the
Downloads
folder
Figure 4.4: Listing the updates applied to each system
Figure 4.5: PowerShell ISE IntelliSense feature at work as the user types
Figure 4.6: The PowerShell help system being used to access help on the
Get‐
...
Figure 4.7: The output of
Get‐Process
being piped into
Get‐Member
...
Figure 4.8: Formatting results with the
Format‐Table
cmdlet
Figure 4.9: Remote PowerShell session to computer DC1
Figure 4.10:
Invoke‐Command
in use
Figure 4.11: The
Win32_Process
object viewed through
Get‐Member
Figure 4.12: Selecting specific properties from the
Win32_Process
class
Chapter 5
Figure 5.1: Paladin Toolbox being used to wipe removable media
Figure 5.2: Memory acquisition from Client1 to removable media
Figure 5.3: Metadata from a captured AFF4 file
Figure 5.4: The contents of the AFF4 file archive
Figure 5.5: Using a remote share to store the
winpmem
executable and receive...
Figure 5.6: Remote RAM capture to external media
Figure 5.7: Pushing the memory acquisition tool and running it with WMIC
Figure 5.8: Using PowerShell Remoting to initiate a remote RAM acquisition w...
Figure 5.9: Copying files from the remote system and ending the remoting ses...
Figure 5.10: The F‐Response Management Console
Figure 5.11: Capturing RAM from a remote system with F‐Response
Figure 5.12: Remotely installing Rekall using PowerShell Remoting
Figure 5.13: Running Rekall to analyze live memory on a remote system
Chapter 6
Figure 6.1: Adding an evidence item to FTK Imager
Figure 6.2: Select the type of evidence to add.
Figure 6.3: Select Export Disk Image on the physical device.
Figure 6.4: Selecting the image destination
Figure 6.5: The imaging process underway
Figure 6.6: Creating a bootable Paladin USB
Figure 6.7: Launching the Paladin Toolbox
Figure 6.8: The Paladin Disk Manager
Figure 6.9: The Paladin Imager tool
Figure 6.10: Adding a file to a custom content image
Figure 6.11: Custom content sources are displayed in the lower‐left pane.
Figure 6.12: Creating a custom content source manually
Figure 6.13: Mounting the AD1 image file for analysis
Figure 6.14: Using F‐Response to access storage media on a remote system
Figure 6.15: The ESXi datastore for the example virtual machine
Chapter 7
Figure 7.1: The recommended Security Onion architecture
Figure 7.2: The RealTime Events queue of the Sguil interface
Figure 7.3: Escalating or categorizing an event to remove it from the RealTi...
Figure 7.4: The Sguil GUI's right‐click context menu for pivoting to origina...
Figure 7.5: Pivoting based on the Destination IP address to search for other...
Figure 7.6: Squert web interface to access Sguil data
Figure 7.7: The Squert Summary tab dashboards
Figure 7.8: The Kibana web interface
Figure 7.9: A filtered view of the Zeek (Bro) connection logs
Figure 7.10: The bottom of each dashboard provides a panel to view the logs ...
Figure 7.11: A pinned filter being used to view logs and their associated fi...
Figure 7.12: Bar chart showing geographic locations of external IP addresses...
Figure 7.13: Suspicious Subject details in a server certificate
Chapter 8
Figure 8.1: Event Viewer showing default logs on Windows Server 2019
Figure 8.2: The filter options in Event Viewer
Figure 8.3: A successful interactive logon event
Figure 8.4: The XML representation of an event log record
Figure 8.5: Event ID 7045 showing a malicious service
Figure 8.6: The XML structure of the event‐specific data area of an Event ID...
Chapter 9
Figure 9.1: Default Windows process tree
Figure 9.2: Process Hacker showing child processes in different sessions (la...
Figure 9.3:
tasklist /APPS
showing UWP app‐related processes
Figure 9.4: Entering the Rekall shell to examine live system memory
Figure 9.5: Rekall's
pslist
plug‐in output
Figure 9.6:
netscan
plug‐in in action
Chapter 10
Figure 10.1: Joe Sandbox sample submission page
Figure 10.2: RegShot GUI setup
Figure 10.3: The Process Monitor user interface
Figure 10.4: Process Explorer user interface
Figure 10.5: FLARE VM with monitoring tools in place
Figure 10.6: The malware sample's social engineering ruse
Figure 10.7: Excel launching
msiexec.exe (seen in the last two entries)
Figure 10.8: The Process Monitor Filter window
Figure 10.9: Excel finding and launching
msiexec.exe
as observed by Process ...
Figure 10.10: The Process Monitor event showing the creation of the
msiexec.
...
Figure 10.11: High‐level Cuckoo architecture
Figure 10.12: A basic Cuckoo sandbox setup
Figure 10.13: The Cuckoo Sandbox web interface
Figure 10.14: Cuckoo sandbox analysis options
Figure 10.15: Additional analysis options in Cuckoo
Figure 10.16: CAPE sandbox report example
Figure 10.17: The Ghidra software reverse‐engineering framework
Chapter 11
Figure 11.1: Timeline view in Magnet Axiom
Figure 11.2: A link from a jump list displayed in Magnet Axiom
Figure 11.3: The App history tab of Task Manager displays a portion of the d...
Figure 11.4: The SRUM entry for a PowerShell process displayed on Magnet Axi...
Figure 11.5: The Windows registry as displayed by the Registry Editor
Figure 11.6: The image path of each service's associated executable is found...
Figure 11.7: Registry Explorer used to view the Run key for unauthorized exe...
Figure 11.8:
Amcache.hve
parsed by Magnet Axiom
Figure 11.9: Shellbags as seen in ShellBags Explorer
Figure 11.10: Google Analytics’ first visit cookie viewed in Magnet Axiom
Figure 11.11: The
Zone.Identifier
alternate data stream showing the source o...
Figure 11.12: The location of the USN journal data seen in FTK Imager
Figure 11.13: The
vssadmin list shadows
command showing available volume sha...
Figure 11.14: Volume shadow copies loading into Magnet Axiom
Figure 11.15: The KAPE graphical user interface
Chapter 12
Figure 12.1: Standard account logon and logon event IDs
Figure 12.2: Remote file access account logon and logon event records
Figure 12.3: Event ID 4648 showing explicit credential use
Figure 12.4: An overpass‐the‐hash attack allowing the jlemburg account to im...
Figure 12.5: Event ID 4648 showing both the original and the stolen credenti...
Chapter 13
Figure 13.1: The MITRE ATT&CK matrix
Figure 13.2: The Windows Defender Exploit Guard configuration screen
Chapter 14
Figure 14.1: The threat‐hunting process
Figure 14.2: The ATT&CK Navigator interface
Figure 14.3: The CMSTP technique explanation
Figure 14.4: Additional details about preventing and detecting the CMSTP tec...
Figure 14.5: MITRE ATT&CK also tracks known techniques of threat actor group...
Figure 14.6: Using MITRE ATT&CK Navigator to highlight the techniques used b...
Figure 14.7: Each atomic test is grouped by the associated MITRE technique n...
Figure 14.8: Categorized list of all atomic tests
Figure 14.9: The files needed for the CMSTP tests
Figure 14.10: The markdown document describing technique T1191
Cover
Table of Contents
Begin Reading
iii
1
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
45
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
iv
xiii
xv
xvi
xvii
xviii
xix
xx
xxi
xxii
440
Steve Anson
Chapter 1:
The Threat Landscape
Chapter 2:
Incident Readiness
Before we delve into the details of incident response, it is worth understanding the motivations and methods of various threat actors. Gone are the days when organizations could hope to live in obscurity on the Internet, believing that the data they held was not worth the time and resources for an attacker to exploit. The unfortunate reality is that all organizations are subject to being swept up in the large number of organized, wide‐scale attack campaigns. Nation‐states seek to acquire intelligence, position themselves within supply chains, or maintain target profiles for future activity. Organized crime groups seek to make money through fraud, ransom, extortion, or other means. So no system is too small to be a viable target. Understanding the motivations and methods of attackers helps network defenders prepare for and respond to the inevitable IT security incident.
Attackers may be motivated by many factors, and as an incident responder you'll rarely know the motivation at the beginning of an incident and possibly never determine the true motivation behind an attack. Attribution of an attack is difficult at best and often impossible. Although threat intelligence provides vital clues by cataloging tactics, techniques, procedures and tools of various threat actor groups, the very fact that these pieces of intelligence exist creates the real possibility of false flags, counterintelligence, and disinformation being used by attackers to obscure their origins and point blame in another direction. Attributing each attack to a specific group may not be possible, but understanding the general motivations of attackers can help incident responders predict attacker behavior, counter offensive operations, and lead to a more successful incident response.
Broadly speaking, the most common motivations for an attacker are intelligence (espionage), financial gain, or disruption. Attackers try to access information to benefit from that information financially or otherwise, or they seek to do damage to information systems and the people or facilities that rely on those systems. We'll explore various motives for cyberattacks in order to better understand the mindset of your potential adversaries.
Most organizations rely on some information to differentiate them from their competitors. This information can take many forms, including secret recipes, proprietary technologies, or any other knowledge that provides an advantage to the organization. Whenever information is of value, it makes an excellent target for cyberattacks. Theft of intellectual property can be an end unto itself if the attacker, such as a nation‐state or industry competitor, is able to directly apply this knowledge to its benefit. Alternatively, the attacker may sell this information or extort money from the victim to refrain from distributing the information once it is in their possession.
Most organizations rely on a network of partners, including suppliers and customers, to achieve their stated objectives. With so much interconnectivity, attackers have found that is often easier to go after the supply chain of the ultimate target rather than attack the target systems head on. For example, attacking a software company to embed malicious code into products that are then used by other organizations provides an effective mechanism to embed the attacker's malware in a way that it appears to come from a trusted source. The NotPetya attack compromised a legitimate accounting software company, used the software's update feature to push data‐destroying malware to customer systems, and reportedly caused more than $10 billion in damages. Another way to attack the supply chain is to attack operations technology systems of manufacturing facilities that could result in the creation of parts that are out of specification. When those parts are then shipped to military or other sensitive industries, they can cause catastrophic failures.
One of the earliest motivations for organized cyberattacks, financial fraud is still a common motivator of threat actors today, and many different approaches can be taken to achieve direct financial gain. Theft of credit card information, phishing of online banking credentials, and compromise of banking systems, including ATM and SWIFT consoles, are all examples of methods that continue to be used successfully to line the pockets of attackers. Although user awareness and increased bank responsiveness have made these types of attacks more difficult than in previous years, financial fraud continues to be a common motivation of threat actors.
We briefly mentioned extortion in our discussion of intellectual property theft, but the category of extortion is much broader. Any information that can be harmful or embarrassing to a potential victim is a suitable candidate for an extortion scheme. Common examples include use of personal or intimate pictures, often obtained through remote access Trojans or duplicitous online interactions, to extort money from victims in schemes frequently referred to as “sextortion.” Additionally, damage or the threat of damage to information systems can be used to extort money from victims, as is done in ransomware attacks and with distributed denial‐of‐service (DDoS) attacks against online businesses. When faced with the catastrophic financial loss associated with being taken off line or being denied access to business‐critical information, many victims choose to pay the attackers rather than suffer the effects of the attack.
Whether done to benefit a nation or a company, espionage is an increasingly common motivation for cyberattacks. The information targeted may be intellectual property as previously discussed, or it may be broader types of information, which can provide a competitive or strategic advantage to the attacker. Nation‐states routinely engage in cyber‐espionage against one another, maintaining target profiles of critical systems around the globe that can be leveraged for information or potentially attacked to cause disruption if needed. Companies, with or without the support of nation‐state actors, continue to use cyber‐exploitation as a mechanism to obtain details related to proprietary technologies, manufacturing methods, customer data, or other information that allows them to more effectively compete within the marketplace. Insider threats, such as disgruntled employees, often steal internal information with the intent of selling it to competitors or using it to give them an advantage when seeking new employment.
As militaries increasingly move into the cyber domain, the ability to leverage cyber power in conjunction with kinetic or physical warfare is an important strategy for nation‐states. The ability to disrupt communications and other critical infrastructure through cyber network attacks rather than prolonged bombing or other military activity has the advantages of being more efficient and reducing collateral damage. Additionally, the threat of being able to cause catastrophic damage to critical infrastructure, such as electric grids, that would cause civil unrest and economic harm to a nation is seen as having the potential to act as a deterrent to overt hostilities. As more countries stand up military cyber units, the risk of these attacks becomes increasingly present. As Estonia, Ukraine, and others can attest, these types of attacks are not theoretical and can be very damaging.
Many groups view attacks on information systems as a legitimate means of protest, similar to marches or sit‐ins. Defacement of websites to express political views, DDoS attacks to take organizations off line, and cyberattacks designed to locate and publicize information to incriminate those perceived to have committed objectionable acts are all methods used by individuals or groups seeking to draw attention to specific causes. Whether or not an individual agrees with the right to use cyberattacks as a means of protest, the impact of these types of attacks is undeniable and continues to be a threat against which organizations must defend.
Sometimes an attacker's motivation is as simple as wishing to do harm to an individual or organization. Disgruntled employees, former employees, dissatisfied customers, citizens of other nations, or former acquaintances all have the potential to feel as if they have been wronged by a group and seek retribution through cyberattacks. Many times, the attacker will have inside knowledge of processes or systems used by the victim organization that can be used to increase the effectiveness of such an attack. Open source information will often be available through social media or other outlets where the attacker has expressed his or her dissatisfaction with the organization in advance of or after an attack, with some attackers publicly claiming responsibility so that the victim will know the reason and source of the attack.
Cyber attackers employ a multitude of methods, and we'll cover some of the general categories here and discuss specific techniques throughout the remaining chapters. Many of these categories overlap, but having a basic understanding of these methods will help incident responders recognize and deter attacks.
Denial‐of‐service (DoS) attacks seek to make a service unavailable for its intended purpose. These attacks can occur by crashing or otherwise disabling a service or by exhausting the resources necessary for the service to function. Examples of DoS attacks are malformed packet exploits that cause a service to crash or an attacker filling the system disk with data until the system no longer has enough storage space to function.
One of the most common resources to exhaust is network bandwidth. Volumetric network floods send a large amount of data to a single host or service with the intent of exceeding the available bandwidth to that service. If all the bandwidth is consumed with nonsense traffic, legitimate traffic is unable to reach the service and the service is unable to send replies to legitimate clients. To ensure that an adequate amount of bandwidth is consumed, these types of attacks are normally distributed across multiple systems all attacking a single victim and are therefore called distributed denial‐of‐service (DDoS) attacks. An example of such an attack is the memcached DDoS attack used against GitHub, which took advantage of publicly exposed memcached servers. Memcached is intended to allow other servers, such as those that generate dynamic web pages, to store data on a memcached server and be able to access it again quickly. When publicly exposed over the User Datagram Protocol (UDP), the service enables an attacker to store a large amount of data on the memcached server and spoof requests for that data as if they came from the intended victim. The result is that the memcached server responds to each forged request by sending a large amount of data toward the victim, even though the attacker needs to send only a small amount of data to generate the forged request. This concept of amplifying the attacker's bandwidth by bouncing it off a server that will respond with a larger payload than was sent is called an amplification attack. The amplification ratio for memcached was particularly high, resulting in the largest DDoS attacks by volume to date. Fortunately, since memcached replies originate from UDP port 11211 by default, filtering of the malicious traffic by an upstream anti‐DDoS solution was simplified. The misconfigured servers that allowed these initial attacks to achieve such high bandwidth are also being properly configured to disallow UDP and/or be protected by firewalls from Internet access.
DDoS attacks rely on the fact that they are able to send more data than the victim's Internet service provider (ISP) link is able to support. As a result, there is very little the victim can do to mitigate such attacks within their network. Although an edge router or firewall could be configured to block incoming floods, the link to the organization's ISP would still be saturated and legitimate traffic would still be unable to pass. Mitigation of DDoS attacks is generally provided by ISPs or a dedicated anti‐DDoS provider that can identify and filter the malicious traffic upstream or through a cloud service where far more transmission capacity exists. We won't talk a great deal about incident response to DDoS attacks in this book since most mitigation will occur upstream. With online “Booters” or “Stressors” being commonly advertised on the clear net and dark web for nominal fees, all organizations that rely on the Internet for their business operations should have anti‐DDoS mitigation partners identified and countermeasures in place.
Worms are a general class of malware characterized by the fact that they are self‐replicating. Old‐school examples include the LoveBug, Code Red, and SQL Slammer worms that caused extensive damage to global systems in the early 2000s. Worms generally target a specific vulnerability (or vulnerabilities), scan for systems that are susceptible to that vulnerability, exploit the vulnerable system, replicate their code to that system, and begin scanning anew for other victims to infect. Because of their automated nature, worms can spread across the globe in a matter of minutes. The WannaCry ransomware is another example of a worm, which used the EternalBlue exploit for Windows operating systems to propagate and deliver its encryption payload, reportedly infecting more than 250,000 systems across 115 countries and causing billions of dollars in damage.
Detection of worms is generally not difficult. A large‐scale attack will prompt global IT panic, sending national computer emergency response teams (CERTs) into overdrive, with researchers providing frequent updates to the IT security community on the nature of the attack. From an incident response perspective, the challenge is to adequately contain impacted systems, identify the mechanism by which the worm is spreading, and prevent infection of other systems in a very short amount of time.
Ransomware refers to a category of malware that seeks to encrypt the victim's data with a key known only to the attackers. To receive the key needed to decrypt and therefore recover the impacted data, victims are asked to pay a fee to the ransomware authors. In exchange for the fee, victims are told that they will receive their unique key and be able to decrypt and recover all the impacted data. To encourage payment from as many victims as possible, some ransomware campaigns even provide helpdesk support for victims who are having issues making payments (usually through cryptocurrency) or decrypting the files after the key has been provided.
Of course, there is no guarantee that a payment made through cryptocurrency, which cannot be rescinded once made, will result in the encryption key being provided. For this reason, as well as to discourage these types of attacks in general, IT security practitioners generally advise against paying a ransom. Nonetheless, many organizations that are not adequately prepared and that do not have sufficient disaster recovery plans in place feel they have little choice but to make these payments despite the lack of guarantees.
Ransomware has been a significant threat since at least the mid‐2000s. The CryptoLocker ransomware appeared in 2013 and led to several variants since then. The WannaCry worm, mentioned earlier, did significant damage in 2017. Since then, more targeted ransomware attacks have struck cities including Atlanta, Baltimore, and 23 separate cities in Texas that were targeted in the same campaign. Similar examples of attacks targeting medical and enterprise environments have also occurred in recent years. The GrandCrab ransomware targeted a variety of organizations, including IT support companies to use their remote support tools to infect more victims. Targeted attacks continue to be a common strategy for financially motivated attack groups using ransomware such as SamSam, Sodinokibi, and others. Smaller organizations that are perceived as having less robust business continuity and disaster recovery plans continue to be targeted. The Emotet banking malware evolved its attacks to drop the modular Trickbot trojan, using it to steal sensitive files and move laterally to understand the target environment before then downloading Ryuk ransomware and demanding payment to restore access to critical data. So long as ransomware remains profitable, it will continue to be a threat for which all organizations must prepare.
Phishing attacks have been around for ages, and they remain one of the most common attack vectors for incidents today. Although the quality of phishing emails continues to improve, the general concept is unchanged from previous years. Emails claiming to be from organizations trusted by the victim request that the victim click a link, download an attachment, or provide authentication credentials in order to respond to a reported problem or offer. User awareness has successfully decreased the rate of click‐through for these campaigns, yet the low cost associated with sending tens of thousands of emails, typically through compromised servers or botnets, means that a campaign can be successful even with a very small percentage of recipients falling victim.
A subset of phishing, spear phishing refers to targeted attacks against high‐value individuals. Adversaries will research a target or small group of targets to understand the types of emails that they would routinely receive. By understanding the names and email addresses of associates, their relationship to the victim, and the types of documents they may send on a regular basis, the attacker is able to construct a believable ruse to get the victim to take an action that will compromise his or her systems. Spear phishing attacks may involve elaborate social‐engineering campaigns crossing from email, to social media, Short Message Service (SMS), and even voice calls. The more credible the social‐engineering campaign, the more likely the victim will take the desired action, providing the attacker with a foothold in the target network.
Variations on this theme include business‐email compromise attacks, where an attacker will gain unauthorized access to an email system and use that access to send spear phishing emails to other employees or partner organizations. The fact that they originate from the actual user's account, and the fact that the attacker has access to previous emails to use in constructing a more convincing ruse, make these attacks particularly effective. They are often used in invoice fraud campaigns to trick companies into making payments to the attacker's account, believing that they are paying an invoice from a legitimate partner.
Often done in conjunction with phishing and spear phishing attacks, a watering hole attack directs victims to a website that will deliver a malicious payload to anyone who visits. This is frequently accomplished through malicious ads that are then propagated to legitimate websites, infecting vulnerable browsers who happen to visit that site. By carefully selecting the website to host the malware, or the keywords with which the malicious ad will be associated, the attacker is able to target victims from a specific company, region, or group. Phishing emails or social media posts that contain a link to the watering hole site are also an effective means of targeting these attacks. Compromising a legitimate website that the intended victims are likely to visit and using that legitimate site to launch further attacks against its users is another common tactic. APT38 has been accused of launching several successful watering hole attacks targeting employees of financial institutions to gain access to their bank networks.
Successful watering hole campaigns can lead to multiple employees within a single organization infecting their systems within a short period of time. Rapid identification is therefore important for these types of attacks to minimize the damage caused by the attackers and their subsequent lateral movement to additional systems.
The web attacks category refers to attacks against services that rely on the Hypertext Transfer Protocol (HTTP). Although this traditionally would represent web servers, the rapid adoption of mobile apps and their reliance on web‐based technologies means that these attacks also apply to a large segment of mobile phone activity. Web attacks can take many different forms, including direct exploitation of the servers, cross‐site scripting attacks against browsers, cross‐site request forgeries, and logic attacks against the applications. These attacks are often facilitated by a web application manipulation proxy that can intercept and modify communications between the client and the server. With application programming interfaces (APIs) being an increasingly common means of sharing information between applications, attacks against vulnerabilities in those APIs are common.
The rapid pace of development and change within the mobile app space has resulted in a resurgence of older web application vulnerabilities. Many attacks that were considered old are new again, with web technologies reimagined for low‐cost and rapidly developed mobile applications.
As mobility becomes an increasingly important part of our daily lives, so does our reliance on wireless technologies increase. Naturally, this increases the attack surface for wireless attacks against technologies such as Wi‐Fi, Bluetooth, and even Global System for Mobile Communications (GSM). Although WPA3 (Wi‐Fi Protected Access version 3) will provide additional protections for many wireless networks, the adoption of that protocol as of this writing is still low and vulnerabilities are already being identified. Previous protocols, such as WPA2, offer reasonable levels of protection when properly implemented but are subject to compromise when not carefully deployed. Even mobile telephony systems such as GSM are subject to attacks through Signaling System No. 7 (SS7) signaling vulnerabilities, international mobile subscriber identity (IMSI) catchers, subscriber identity module (SIM) card attacks, and other means.
Access to public Wi‐Fi networks continues to be a common vector for attackers to gain a foothold on a client system. Advanced threat actors, as exemplified by the DarkHotel campaign, have been known to target public Wi‐Fi in hotels or other locations where business users or other VIPs may connect. By compromising the access points or placing themselves between the access point and the Internet connection, attackers can modify data in transit, allowing them to redirect connections or even insert malicious exploits and payloads into otherwise trusted data streams. Use of a virtual private network (VPN) mitigates the risk associated with this type of attack, and VPNs should be used whenever an untrusted network is required; however, any connection to an untrusted wireless network carries some level of risk.
As with attacks on public wireless access points, attackers who are able to insert their system into the stream of a communication are able to intercept or modify the data in transit. An attacker who obtains a foothold within a network can modify Address Resolution Protocol (ARP) cache tables to redirect traffic from its intended recipient to the attacker system. The attacker is then able to view or modify the data and forward it on to the intended recipient, placing the attacker system in a man‐in‐the‐middle (MitM) position. Once such a position is obtained, the attacker can exert ongoing influence within the network; obtain sensitive information, including credentials; and inject malicious payloads where desired.
Another attack vector is the delivery of software to mine for cryptocurrencies, providing any associated cryptocurrency gains to the attacker's accounts. The massive spike in cryptocurrency values in 2017, coupled with the relatively low returns on ransomware attacks, led to a 2018 surge in these types of attacks. The popularity of this type of attacks tends to ebb and flow with the value of cryptocurrencies. These types of attacks frequently favor the Monero cryptocurrency, since the algorithms used to mine this type of currency are well suited for general computer processors rather than graphics processing units (GPUs). Victims generally experience an increase in processor utilization and associated electricity costs but minimal other adverse effects since the malware author wants to avoid detection. Many botnets are enabling crypto‐mining functions as a loadable feature into their botnet clients to allow the system to be rented out on a for‐fee basis for mining along with other uses of botnets, such as DDoS attacks.
Despite the increasing adoption of multifactor authentication, many organizations continue to rely on username and password authentication as the sole means of proving identity. Password attacks include brute‐force password guessing (trying large numbers of possible passwords for an account), password spraying (guessing a small number of passwords against a large number of users to reduce the chance of account lockout), theft of passwords from compromised databases, and cracking stolen or sniffed password representations. Many organizations still store passwords in insecure representations (such as unsalted MD5) or, worse yet, store them in plain text, so when a compromise occurs and the database falls into malicious hands, all the users' passwords become compromised as well.
Despite the availability of password managers and multifactor authentication, far too many users continue to rely on the same password across multiple different sites and services. The problem has become so pervasive that the National Institute of Standards and Technology (NIST) has modified its long‐standing recommendations related to password use and is now recommending the use of passphrases, a combination of random words to provide a longer passphrase that is harder for an attacker to guess but simple for a person to remember. Password complexity rules, such as requiring uppercase and lowercase letters, numbers, and special symbols, failed to provide the variation in passwords that was intended. Users tended to stick to a dictionary word followed by a number and/or a special character at the end in very predictable patterns. The forced rotation of passwords likewise failed to add the necessary entropy to the password structure as users simply incremented a number at the end of the password or made other trivial changes from one password to the next to make it as easy as possible to remember.
Organizations should consider aligning their identity management practices to the updated NIST Special Publication 800‐63B, available at https://pages.nist.gov/800-63-3/sp800-63b.html, and require multifactor authentication throughout the network environment. Individuals should use password management tools and ensure that passwords are unique and not reused between services.
Although each cyberattack may be unique, it is useful to observe some of the general steps that are commonly used by attackers. Just as incident responders must follow a systematic process, so will attackers organize their activities for efficiency and effectiveness. There have been different models put forward over the years to describe the attacker methodology, including the Lockheed Martin Cyber Kill Chain, the Unified Kill Chain proposed by Paul Pols, MITRE ATT&CK, and others. Regardless of the specific model used, the general flow of an attack will generally follow these steps.
For a targeted campaign, this phase is the most important. The dedicated attacker will spend a considerable amount of time conducting open‐source intelligence to determine as much about the target organization and its employees as possible. With client‐side attacks, such as phishing or spear phishing, among the most common attack vectors, an adversary will perform a considerable amount of reconnaissance to construct believable and effective social‐engineering campaigns. It is common for attackers to target the organization's online presence, including corporate or personal websites, social media accounts, and news reports about the organization, as well as its employees in order to facilitate an effective attack.
In addition to open‐source intelligence, an attacker will likely conduct scans of the IT systems of the victim organization. Perimeter defenses will obviously limit initial scans to Internet‐facing devices, but targeted scanning within the network may continue after an initial foothold is established, depending on how stealthy the attacker is trying to be. Scans may be conducted quickly with little regard for detection, or they may be spread out over time and from different source locations in order to avoid potential detection. The sheer number of automated scanners, such as from malware, that target Internet‐connected hosts make effective detection of scans at the perimeter with the Internet challenging.
Dedicated adversaries will attempt to determine the defenses in place by the target organization. Once they understand the products on which the target organization relies, they will customize their attack methodologies and payloads to evade detection by those specific technologies. It is common for endpoint detection bypass to be engineered by an attacker specific to the defenses in place. Although endpoint and network defenses are critically important, it is equally important to understand that no system is infallible and that a dedicated adversary can construct an attack capable of evading automated detection mechanisms. Defense and detection in depth are critical to minimize the impact of such targeted attacks.
Once an attacker understands the target environment, its employees, and its defenses, it is time to gain an initial foothold within the target organization. As IT security teams become more effective at defending their Internet‐facing devices, the use of direct exploitation of vulnerabilities against Internet‐connected systems has become more challenging for attackers. It is frequently easier and more effective to launch client‐side attacks by getting the client to visit a malicious site, execute a malicious attachment, or similar social‐engineering ruse. Alternatively, attackers may seek to exploit client systems when they have left the protective confines of the organization's network perimeter. Attackers may target public Wi‐Fi used by employees of the organization, devices used as parts of “bring your own device” programs, or poorly defended remote offices or cloud services to establish an initial foothold from which to expand their influence.
Web application attacks can also be used as an initial foothold into an organization. Web services will ideally run with limited permissions, but compromise of such servers may provide access to additional sensitive data or backend databases that can be used to further penetrate the network. The use of public and private cloud infrastructure means that the IT resources of target organizations are frequently distributed between different silos, and attackers may therefore seek multiple points of entry to establish a foothold within each relevant data center or cloud service provider.
Unfortunately, many organizations still struggle with effective patch management, resulting in Internet‐exposed systems with known vulnerabilities. Such problems make the initial foothold for the attacker much easier, since known vulnerabilities will frequently have publicly available exploits. The use of such exploits risks detection by signature‐based detection mechanisms, but if an attacker's scans reveal that the perimeter of an organization is full of well‐known but unpatched vulnerabilities, the attacker may assume that the IT security team is not closely monitoring for even obvious attacks. We therefore still see victim organizations where gaining an initial foothold was as simple as lobbing a common exploit payload against an unpatched, Internet‐connected system.
This phase of the attack process has become an active battleground between attackers and defenders. The effectiveness of well‐crafted client‐side attacks and the wide range of attack vectors available have almost ensured that an initial foothold can be established by a dedicated attacker. As a result, IT security departments need to focus on not only preventing initial exploitation of their resources, but also acknowledging that such exploitation may occur and increasing their detection capabilities for malicious activity taking place inside their network environment. Attackers who establish an initial foothold may find themselves on a system of little value with access only to nonprivileged user credentials. They will therefore seek to expand their influence by laterally moving to additional systems and attempting to steal privileged credentials along the way.
Each time an attacker uses malicious software or attacker tools, they risk detection by either network or host‐based defenses. For this reason, attackers will frequently “live off the land,” seeking to use only software that is already present within the victim network. Using operating system features, console commands, and built‐in system administration tools, attackers will seek to leverage valid credentials in order to log into other systems within the environment and spread their influence. This can take the form of Secure Shell (SSH) connections, Server Message Block (SMB) connections, PowerShell Remoting, Remote Desktop Protocol (RDP) connections, or any other mechanisms employed by users and administrators of the target environment to go about their daily tasks. The intent of the attacker is to blend in with normal activity, utilizing tools and protocols already in use within a victim environment, in order to make their malicious behavior blend in with normal network activity.
Unfortunately, the period during which attackers are able to exist within a network without being detected (known as the dwell time) is frequently measured in months. Many IT security teams currently lack the tools and training to detect an adversary who is operating within their environment, often relying on signature‐based detection systems and the adversary's use of malware as the primary mechanism of detection and alerting. This approach leaves defenders blind to the presence of a careful attacker. As a result, this phase of the attack process will receive considerable attention in our discussions of incident response.
At some point, the attacker will be satisfied with their level of access to the victim organization and will get on with whatever malicious intent led them to breach the network in the first place. In the case of an advanced persistent threat (APT), the goal may be to linger within the environment for as long as possible, and any exfiltration of data may occur only in small amounts, spread out over a long time, possibly using covert channels to avoid detection. Other times, an attacker will have accomplished their objective and in one fell swoop will extract massive amounts of data over the course of a single weekend. If system damage was the attacker's goal, the organization's employees may walk in one morning to find all their systems erased, encrypted, or otherwise unavailable.
Most attackers, like most criminals, would prefer not to be caught. Just as a criminal may wipe the fingerprints off a murder weapon, so do cyberattackers seek to hide evidence of their activity. Attackers may clean up their tracks as they go or, in the case of a quick attack, may do so at the end, just prior to disconnecting from the victim organization. If the target organization has taken appropriate steps to build a secure and resilient network, it may be impossible for attackers to access all the systems necessary to delete the evidence of their activities. Attackers will frequently delete log entries from systems that they compromise, attempt to delete history files that may have been generated by their presence, and remove any tools or temporary files that they have placed on impacted systems. In some cases, attackers may even plant false flags, trying to point blame at others for their activities. Alternatively, attackers may simply seek to damage systems so extensively that reconstructing what actions they took becomes difficult.
Attackers understand the value of stealth. Although in years past, attackers may have resembled pirates, all but screaming “Argh!” and firing cannons during their assaults using malware, scanners, and other easy‐to‐detect tools, modern adversaries are usually not so blatant. Instead, they more closely resemble ninjas, stealthily hiding in the shadows, trying to avoid detection while they silently go about the business at hand. Using techniques such as “living off the land” to avoid detection mechanisms, the modern attacker is much more disciplined and professional, requiring that defenders adapt their methods and approaches to this new reality.
Cybercrime has become big business, and it has drawn the attention of organized criminals. Many organized syndicates have fully moved into cybercrime as a business venture, occupying entire buildings with hundreds or thousands of employees, all engaged in a criminal conspiracy to financially benefit from illegal cyber activity. This commercialization of cybercrime has led to a convergence of the methods used by state‐sponsored APTs and those used by financially motivated criminal attackers. As security researchers and incident responders increasingly shine a light on the tactics, techniques, and procedures (TTPs) of advanced threats, organized crime has been watching and learning and have adapted their TTPs to match. The result is a threat landscape where attackers learn from one another and continue an onslaught of advanced techniques launched against a wider array of potential victims.
Many organized attackers invest heavily in research and development, purchasing the same vendor‐provided security devices that their victims rely on for their defense. They employ dedicated teams working to develop bypass techniques to launch attacks that will evade detection by each of these various tools. Skilled black‐hat researchers analyze custom applications, open‐source projects, and proprietary technologies in order to maximize the effectiveness of the exploits and payloads that the adversary will deliver. In the past, these types of advanced techniques were reserved for the realm of state‐sponsored attackers and national security agencies, but the unfortunate reality is that these capabilities are now within the reach and use of organized cybercrime. Attacks that we previously saw only against nation‐states are now being employed against a wide range of corporate environments. It is that shift that made this updated book a necessity, since incident response professionals need to rethink and revise traditional approaches to counter these new threats.
The modern adversary understands the benefit of hiding in plain sight. Each piece of customized malware they deploy increases the likelihood of detection and requires expensive and time‐consuming testing and modifying of code to bypass existing security mechanisms. Use of commodity and publicly available exploits or malware will almost certainly result in detection in all but the least prepared of victim environments. To remain stealthy, attackers seek to obtain valid credentials and reuse those credentials to access new systems.
There are many different ways for an attacker to come by valid credentials. Once an initial foothold is gained, the attacker will pillage that system for any additional intelligence. Looking in the ARP cache, checking log entries, using a network browsing facility, and conducting target scans are common techniques used to help an attacker identify additional systems to which their initial foothold may be able to connect. Once potential new targets are identified, the attacker will need a credential to successfully pivot to that new system. Unfortunately, during the examination of the first victim system, the attacker may simply find additional credentials lying around. Despite the best efforts of IT security teams and employee education programs, some users still leave passwords in plain text, stored in files cleverly named “password.txt,” sitting on their desktop.
Often, it is application developers or system administrators that make the attacker's job all too easy. The media continues to be filled with reports of web service data breaches, where databases of usernames and passwords are compromised. In many of these breaches, the passwords are stored in plain text or, only slightly better, stored in a password representation derived from a weak algorithm. An algorithm that has repeatedly made headlines is unsalted MD5, which can be cracked through the use of rainbow tables or graphics processing unit (GPU)–enabled password cracking tools with minimal time and effort. The problem has become so pervasive that best practices for generating passwords include recommendations to filter candidate passwords against publicly available lists of compromised passwords to ensure that attackers are not able to iterate through lists of previously disclosed password breaches to determine likely passwords in use within the victim environment.
Passwords should never be stored in plain text. Instead, authentication systems should use a password representation that is derived from the plaintext password using a known algorithm. Any system needing to verify whether the user has input the correct plaintext password can simply apply the known algorithm to the user‐provided password and calculate the password representation. The calculated password representation can then be compared to the password representation stored by the authenticator. As long as the two match, that means the original plaintext password was correctly provided. However, if the authenticator's stored password representations are compromised, at least the attacker does not know the associated plaintext password. To make these systems more secure, a salt or pseudorandom value is often added to the password prior to the algorithm being applied to calculate the password representation. This introduces additional entropy and prevents what are called precomputed hash attacks, where an attacker will determine the password representation for a large number of possible passwords in advance and then simply look up any password representations that the attacker is able to compromise in order to determine the associated plaintext password. Rainbow tables are an example of such a precomputed attack. We will explore common attacks against authentication systems in more detail in Chapter 12,”Lateral Movement Analysis.”
Many times, the attacker does not need to determine the full username and password in order to leverage an existing credential to access other systems. In Windows environments, it is the password representation rather than the plaintext password that is used during the authentication process. For this reason, access to the hashed password representation is all that is required for an attacker to leverage that credential and access alternate systems by impersonating that user. One of the most common examples of this type of attack is known as “pass the hash.” To facilitate a single sign‐on experience, when a user logs on to a Windows system the hash that was calculated during authentication is stored in memory. When the user attempts to access a remote resource, Windows conveniently uses that hash on behalf of the user to authenticate to the remote system without further user interaction. Unfortunately, an attacker who is able to compromise a system—through a client‐side attack, for example—can leverage this functionality to request access to other remote systems using the credential that is stored in memory for the user account that was compromised.
If the attackers have local administrator privileges on the compromised system, they can directly access the memory of that system to extract the credentials stored for any interactively logged‐on user. The most well‐known tool to accomplish this type of attack is Mimikatz. Using Mimikatz, an attacker can extract password hashes or Kerberos tickets for currently logged‐on users. These credentials can then be passed to other systems, allowing the attacker to impersonate those users. It is important to note that even when multifactor authentication is in use, theft of credentials from currently logged‐on users provides the attacker with the necessary and sufficient credentials to laterally move within an environment. Once authenticated, users are not queried again for each authentication factor as they attempt to access other systems within the same network. As a result, access to a memory‐resident credential such as a Kerberos ticket provides the attacker with the means to impersonate a user even in the absence of hardware tokens or other multifactor authentication mechanisms. We'll examine the details of attacks such as pass‐the‐hash, pass‐the‐ticket, and overpass‐the‐hash in Chapter 12.
Attacks on credentials are so prevalent that administrators must be made aware of the threats to the network each time they use a privileged credential. If a system is compromised and an administrator accesses that system interactively, the credential the administrator used is exposed to the attacker. Attackers will even go so far as to cause a system issue to lure an administrator to log on to the system to investigate. The attacker will have a running instance of Mimikatz lying in wait on the system and gleefully extract the administrator credential when supplied. Each organization should have strict policies in place regarding the use of privileged credentials. The concept of least privilege should always be used so that if a credential is exposed, the collateral damage of that exposure is reduced. Administrative credentials should be entered only into dedicated and hardened secure administrative workstations, systems that are used only for administration tasks and that are never used for general web browsing, email access, or other high‐risk activities that may compromise the associated host. In addition to protecting credentials, strict discipline in the use of such credentials will make it much easier to differentiate legitimate use from malicious use should an administrative credential be compromised. We'll examine these concepts in more depth throughout this book.
Similarly, incident responders must remain cognizant of this threat when conducting their activities. Although dumping the memory of a compromised system is an important step in the analysis process, logging in interactively to that system with the domain administrator credential to create that image potentially exposes that credential to the attacker. In subsequent chapters, we'll explore mechanisms that incident responders can use to obtain the information necessary without exposing privileged credentials to attackers.
