homepage
Open menu
Go one level top
  • Train and Certify
    Train and Certify

    Immediately apply the skills and techniques learned in SANS courses, ranges, and summits

    • Overview
    • Courses
      • Overview
      • Full Course List
      • By Focus Areas
        • Cloud Security
        • Cyber Defense
        • Cybersecurity and IT Essentials
        • DFIR
        • Industrial Control Systems
        • Offensive Operations
        • Management, Legal, and Audit
      • By Skill Levels
        • New to Cyber
        • Essentials
        • Advanced
        • Expert
      • Training Formats
        • OnDemand
        • In-Person
        • Live Online
      • Course Demos
    • Training Roadmaps
      • Skills Roadmap
      • Focus Area Job Roles
        • Cyber Defense Job Roles
        • Offensive Operations Job Roles
        • DFIR Job Roles
        • Cloud Job Roles
        • ICS Job Roles
        • Leadership Job Roles
      • NICE Framework
        • Security Provisionals
        • Operate and Maintain
        • Oversee and Govern
        • Protect and Defend
        • Analyze
        • Collect and Operate
        • Investigate
        • Industrial Control Systems
      • European Skills Framework
    • GIAC Certifications
    • Training Events & Summits
      • Events Overview
      • Event Locations
        • Asia
        • Australia & New Zealand
        • Latin America
        • Mainland Europe
        • Middle East & Africa
        • Scandinavia
        • United Kingdom & Ireland
        • United States & Canada
      • Summits
    • OnDemand
    • Get Started in Cyber
      • Overview
      • Degree and Certificate Programs
      • Scholarships
      • Cyber Aces
    • Cyber Ranges
  • Manage Your Team
    Manage Your Team

    Build a world-class cyber team with our workforce development programs

    • Overview
    • Why Work with SANS
    • Group Purchasing
    • Build Your Team
      • Team Development
      • Assessments
      • Private Training
      • Hire Cyber Professionals
      • By Industry
        • Health Care
        • Industrial Control Systems Security
        • Military
    • Leadership Training
  • Security Awareness
    Security Awareness

    Increase your staff’s cyber awareness, help them change their behaviors, and reduce your organizational risk

    • Overview
    • Products & Services
      • Security Awareness Training
        • EndUser Training
        • Phishing Platform
      • Specialized
        • Developer Training
        • ICS Engineer Training
        • NERC CIP Training
        • IT Administrator
      • Risk Assessments
        • Knowledge Assessment
        • Culture Assessment
        • Behavioral Risk Assessment
    • OUCH! Newsletter
    • Career Development
      • Overview
      • Training & Courses
      • Professional Credential
    • Blog
    • Partners
    • Reports & Case Studies
  • Resources
    Resources

    Enhance your skills with access to thousands of free resources, 150+ instructor-developed tools, and the latest cybersecurity news and analysis

    • Overview
    • Webcasts
    • Free Cybersecurity Events
      • Free Events Overview
      • Summits
      • Solutions Forums
      • Community Nights
    • Content
      • Newsletters
        • NewsBites
        • @RISK
        • OUCH! Newsletter
      • Blog
      • Podcasts
      • Summit Presentations
      • Posters & Cheat Sheets
    • Research
      • White Papers
      • Security Policies
    • Tools
    • Focus Areas
      • Cyber Defense
      • Cloud Security
      • Digital Forensics & Incident Response
      • Industrial Control Systems
      • Cyber Security Leadership
      • Offensive Operations
  • Get Involved
    Get Involved

    Help keep the cyber community one step ahead of threats. Join the SANS community or begin your journey of becoming a SANS Certified Instructor today.

    • Overview
    • Join the Community
    • Work Study
    • Teach for SANS
    • CISO Network
    • Partnerships
    • Sponsorship Opportunities
  • About
    About

    Learn more about how SANS empowers and educates current and future cybersecurity practitioners with knowledge and skills

    • SANS
      • Overview
      • Our Founder
      • Awards
    • Instructors
      • Our Instructors
      • Full Instructor List
    • Mission
      • Our Mission
      • Diversity
      • Scholarships
    • Contact
      • Contact Customer Service
      • Contact Sales
      • Press & Media Enquiries
    • Frequent Asked Questions
    • Customer Reviews
    • Press
    • Careers
  • Contact Sales
  • SANS Sites
    • GIAC Security Certifications
    • Internet Storm Center
    • SANS Technology Institute
    • Security Awareness Training
  • Search
  • Log In
  • Join
    • Account Dashboard
    • Log Out
  1. Home >
  2. Blog >
  3. Protecting Privileged Domain Accounts: Network Authentication In-Depth
370x370_Mike-Pilkington.jpg
Mike Pilkington

Protecting Privileged Domain Accounts: Network Authentication In-Depth

September 18, 2012

[Author's Note: This is the 5th in a multi-part series on the topic of "Protecting Privileged Domain Accounts". My primary goal is to help incident responders protect their privileged accounts when interacting with comprised hosts, though I also believe this information will be useful to anyone administering and defending a Windows environment.]

To coincide with my recent SANS webcast on Protecting Privileged Domain Accounts, I decided it was time to get to work and publish my findings on network authentication. So here goes!

Just to recap this journey, I started out with a discussion on how to protect Windows password hashes. Then I took a short diversion to look closer at the LM hash, and in particular, the fact that it is stored in memory even if you implemented all of Microsoft's protection features to disable it. Next was a discussion on a relatively new discovery in the InfoSec world?the fact that our passwords are stored in memory in a form that can be easily dumped out to plaintext. My last article was a discussion of access tokens and how they can, in some circumstances, allow an attacker to impersonate you on the network. In this article, I will cover network authentication in a Windows domain.

Microsoft Network Authentication Protocols

The purpose of a network authentication protocol is to provide a method to authenticate a user or computer against a remote credentials store. Ideally, the protocol will provide strong cryptography to protect the authenticating credentials from exposure to eavesdropping and replay attacks.

Many remote authentication protocols are based on a challenge-response mechanism, where a client makes a request to a server, the server issues a challenge, and the client answers that challenge based on a secret that both the client and server know. This is the basic architecture for the legacy Microsoft network authentication protocols. Other network authentication protocols use a trusted third-party system, which is the architecture for Microsoft's current core authentication protocol, Kerberos.

Let's look at a quick summary of the native Microsoft network authentication protocols:

LM (Lan Manager) Challenge-Response

Introduced in the late 80's with OS/2, this was the primary remote authentication protocol for Windows versions prior to Windows NT. The answer (response) that a client provides to the server challenge is generated from the weak LM hash.

NTLM Challenge-Response

Introduced with Windows NT, the primary difference is the inclusion of a second response using the NT hash. If the account's password supports an LM hash, the NTLM response from the client will include 2 answers: an answer based on the LM hash and another based on the NT hash. If the password is a strong password that breaks the LM hashing algorithm, only an answer based on the NT hash will be provided.

NTLMv2 Challenge-Response

Introduced in Windows NT 4.0 SP4, a number of security improvements were introduced, most notably mutual authentication. You may also see LMv2 discussed with NTLMv2. LMv2 is effectively the same protocol as NTLMv2, except it uses a truncated client challenge to better support "pass-through" domain authentication on legacy clients (I'll discuss "pass-through" authentication shortly). The main take away is that both LMv2 & NTLMv2 use only the NT hash to calculate the response to the server and they both implement mutual authentication.

Kerberos

Introduced with Windows 2000, this is a ticket-based system with its origins at MIT. It requires the NT hash to complete authentication. Much more to say on Kerberos soon.

A great single resource for these protocols is the book Implementing CIFS: The Common Internet File System by Chrisopher Hertel. The book is available free online, and the chapter on Authentication is where you'll find a very thorough discussion of all of these protocols.

All versions of Windows, up to and including Windows 8, support all previous legacy network authentication protocols. Of course there are some problems with the older protocols, which led to the development of the newer protocols. Let's look at some of these problems and how Microsoft addressed them?and why we need to be wary of them.

Problem 1: Lack of Mutual Authentication

A major issue with the first version of LM and NTLM challenge-response protocols is that the only entity that gets authenticated is the client. This means that when using these protocols, it is quite possible to reveal sensitive authentication information to a rogue server. Here's how the LMv1/NTLMv1 challenge-response process works (note that for simplicity's sake, this diagram depicts a client authenticating to a server using a local account on the server rather than a domain account?I'll discuss "pass-through" domain authentication shortly):

image.png
  1. The client needs to connect to the server, so a logon request is made to authenticate to the server.
  2. The server says, sure, no problem, just answer this challenge based on your password hash.
  3. The client has the password hash (LM hash for LM challenge-response as well as NT hash for NTLM challenge-response), so it computes the response to the challenge based on the password hashes.

When this is a legitimate server, the server calculates the answer just like the client, since it also knows the correct hashes (for a local account). It compares its answer with the client's answer and if they match, the client has successfully authenticated.

However, when the server is rogue, it has gained sensitive information for this account. It doesn't have the raw password hash that was used to calculate the answer, but now it has all the information it needs to guess the password hash?it has the challenge it issued and the correct answer from the client. In practice, rather than blindly guessing password hashes, the most fruitful attack is for the rogue server to issue a static challenge for which it has already pre-calculated many possible hashes (and corresponding passwords) for that challenge. In other words, the malicious server can issue a static challenge and the attacker can use a pre-computed Rainbow Table to determine the password hash (and password) that resulted in the correct answer. There are free LM challenge-response Rainbow Tables available for the static 8-byte challenge of 1122334455667788 and tools such as Metasploit's smb_sniffer module as well as Cain and Abel will use this challenge by default. To see this attack in action, check out this excellent article by Tim Medin. Tim sets up fake SMB and HTTP services with Metasploit and once the victim answers the static challenge, Tim shows how to crack it to get the password.

Microsoft addressed this issue with the introduction of NTLMv2, and LMv2 which is a slight variation specifying a shorter client challenge for purposes of backward compatibility. The updated versions fix the problem by including a client challenge to provide mutual authentication. Here's how it works:

image.png

Steps 1 & 2 are the same as before. However, in step 3, the client returns an answer to the server that is based on the server's challenge AND a challenge provided by the client. If the server is legitimate, it can easily verify the answer using the hash, its challenge, and the client's challenge. On the other hand, if the server is rogue and doesn't know the password hash to calculate the answer, it can no longer utilize a pre-computed Rainbow Table attack because there is randomness introduced in the form of the client challenge. It is still possible for the attacker to leverage a brute-force attack against the challenges & response, but it's no longer feasible to pre-compute these guesses with a Rainbow Table attack.

As I'll discuss shortly, Kerberos is the best option for network authentication, but there are times when it will not function and Windows will revert to an LM/NTLM-based protocol. In these situations, we want to make sure we're using NTLMv2 for the security benefits of mutual authentication. The Recommendations section at the end of this article discusses how to enforce NTLMv2.

Problem 2: Reflective and Relay Attacks

These two attacks are very clever. The Reflective Attack has been addressed, but the related Relay Attack is still a concern for us. Let's look at the Reflective Attack first:

image.png

I won't talk you through the steps, but to summarize this attack, the rogue server effectively turns the tables on the client and forces the client to inadvertently provide the authentication answer to the rogue server which allows it to connect right back to the client machine.

This particular issue has been resolved with Microsoft patch MS08-068. The patch prevents an SMB client from answering challenges that its own SMB server service has recently issued. This works well in this particular use case. However, this turns out to be a specific solution to a more general problem, as the Relay Attack demonstrates.

The Relay Attack still co-opts the client to answer a challenge, but this time the rogue server passes the answer to a 3rd machine in order to gain access, as shown here:

image.png

Relaying tools have been around for a while, including SmbRelay3 and Metasploit's smb_relay module. Those tools are very effective, however they only support NTLMv1. A recent Metasploit module from Rich Lundeen provides NTLM relaying for NTLMv2. Another new tool called ZackAttack by Zack Fasel does it as well.

With the previous Reflective Attack, the fix was for the client to make sure it doesn't answer any challenges that it recently issued from its own server service. Unfortunately that solution will not help us with this issue because it would not be feasible for all clients in a particular domain to keep track of each other's challenges.

So what is the fix? Well, many people argue that the fix is SMB signing. I disagree for at least a couple of reasons. I don't want to bog down this part of the article with a bunch of extraneous details, so I will add a few comments at the end of the article as footnotes to this section. For now, suffice it to say that one of the biggest reasons why SMB signing is not a solution is due to the fact that there are other services besides SMB that utilize LM/NTLM authentication, which couldn't possibly be protected by SMB signing even if it worked perfectly for protecting the authentication exchange for SMB (which it doesn't).

The most complete protection against the relay attack is a feature called "Extended Protection for Authentication" (EPA). In a nutshell, EPA provides the following to NTLMv2 authentication:

  • EPA embeds the Service Principal Name of the target service with an integrity hash signed by the account's credentials in the logon request. (The Service Principal Name is the name by which a client uniquely identifies an instance of a service on a specific host.)
  • Extended Protection works because only domain controllers and machines where the user directly enters the password can compute/validate the integrity hash. Therefore, new requests cannot be created by a rogue server because it cannot sign the new request.
  • A rogue server also cannot forward (relay) a request sent to it because the 3rd host would recognize that the request had a destination Service Principle Name of the rogue server rather than itself.

This article describes how to enable EPA for SMB, this article for IIS, and this article for SQL Server.

This feature protects the authentication layer. A very robust implementation for SMB would include both EPA and SMB signing, preventing the forwarding of credentials (EPA) as well the altering of SMB traffic (SMB signing).

The tough part about implementing EPA effectively (or SMB signing for that matter) is that it needs to be required throughout the domain to be truly effective. If it is optional, the attacker can simply craft a request that tells the server it doesn't support the more secure settings. Another complication is that EPA is implemented on a per-service basis, so there's no single switch to make it all "just work". Nevertheless, EPA is the best overall solution for protecting NTLMv2 authentication from the relay attack.

The Big Problem: Poor Design

The thing that makes LM/NTLM challenge-response protocols so difficult to secure in a domain environment is that they use "pass-through" authentication. This allows a rogue server to be "man-in-the-middle" of the authentication exchange, as shown here:

image.png

As you can see from this diagram, in a domain environment, the server sends the challenge to the client and then receives the answer. Once it does, a legitimate server will package the challenge and response and send it to the domain controller for verification, since the domain controller has the password hashes and can calculate the answer for verification. The problem is that the answer is still sensitive, and when the server is compromised, the domain credentials are at risk by exposing the answer.

So what is the best solution? Avoid LM/NTLM protocols and use Kerberos instead!

The Big Fix: Kerberos to the Rescue

With Kerberos, there is no more pass-through authentication. We now have a trusted third-party architecture where the authentication happens directly between the client and the authentication store (the DC). Upon successful authentication, a ticket is granted to the client, who then presents it to the server for access.

image.png

This sounds great! We should just use Kerberos and completely disable LM/NTLM protocols, don't you think? Well, unfortunately it's unlikely that you can completely eliminate NTLM in your environment. The following situations still require NTLM, as outlined in Wikipedia:

  • The client is authenticating to a server using an IP address.
  • The client is authenticating to a server that belongs to a different Active Directory forest that has a legacy NTLM trust instead of a transitive inter-forest trust
  • The client is authenticating to a server that doesn't belong to a domain.
  • Where a firewall would otherwise restrict the ports required by Kerberos (of which there are quite a few)

The first one is a real trouble spot in most environments. There are a number of situations where you might want to use a specific IP address when connecting to a host. For example, if DNS records have not been properly updated, you may need to reach a host by IP. Another common scenario is the use of scripts or tools that sweep entire IP network ranges.

According to Jesper Johansson in Protect Your Windows Network From Perimeter to Data, the reason that Windows reverts to NTLM when the IP address is used is because "Kerberos is based on host names. Because Windows DNS does not create reverse lookup zones by default, the protocol cannot rely on a way to resolve IP addresses to host names. Therefore, it always falls back to either NTLM or NTLMv2 in that situation."

Nevertheless, we want to enforce the use of Kerberos whenever possible. This is particularly true on our IR workstations. Luckily, with Windows 7 and Server 2008 R2, we have the ability to do this via policy. Here is an example policy which denies outgoing NTLM authentication to all servers, with the configured exception of 192.168.6.12:

image.png

Being able to exclude certain trusted IP addresses on your IR workstation, such as a proxy server for example, is a very helpful feature. Notice that there are several settings available for adjusting the level of NTLM blocking and auditing. A good resource for learning about this feature is the Microsoft TechNet article "NTLM Blocking and You: Application Analysis and Auditing Methodologies in Windows 7".

Here is the result of some testing that demonstrates the NTLM blocking feature:

image.png

And here's the Event Log entry from the blocked NTLM attempt to 192.168.6.11 (found in Event Viewer under Applications and Services Logs > Microsoft > Windows > NTLM):

image.png

In my testing with PsExec, NET USE, and WMIC, 2 of the 3 will use Kerberos by default. I'm not sure why, but I've found that WMIC needs some prodding to use Kerberos. Luckily, there is a switch?albeit an ugly, painful switch?to force WMIC to utilize Kerberos instead of NTLM. It is /AUTHORITY:"kerberos:domain\computer". Here it is in action?notice the first attempt fails because the NTLM restriction blocked it:

image.png

I told you it was ugly?but at least it works! If you're interested, here's a simple batch script you can use as a shortcut so you don't have to type all that in each time:

SET /P PCNAME=Hostname to query:
SET /P PCDOMAIN=Domain of host:
SET /P WMICCMD=WMIC command to run:
wmic /node:"%PCNAME%" /AUTHORITY:"kerberos:%PCDOMAIN%\%PCNAME%" %WMICCMD%

Name it with a ".bat" extension AND make sure the batch file (and any like it) is editable only by your privileged account. Otherwise a non-privileged user could add nefarious commands to it without your knowledge and then when you run it with your privileged account, bad things would happen.

Recommendations for Strong Network Authentication

First off, make sure that you are using Windows 7 as your IR workstation and enable the feature to block NTLM authentication where possible. One common IR situation where this will cause problems is when you need to authenticate to an IP address because the hostname has not registered in DNS. If this is the case, you can trick your workstation into using Kerberos by temporarily adding an entry in your "hosts" file (Windows\System32\drivers\etc\hosts) for the system you need to connect to. Then remove it when done.

In situations where you must use NTLM, make sure to enforce NTLMv2 in the Local Security Policy (secpol.msc) by setting "Network security: LAN Manager authentication level" to "Send NTLMv2 response only/refuse LM & NTLM", as shown here:

image.png

If you must further lower your settings, be sure that you are using a password greater than 14 characters (which you should do anyway). This will prevent the storage of the LM hash and therefore the worst you can do is NTLMv1, rather than LMv1. Furthermore, by having such a long password, it makes a Rainbow Table or brute-force attack against your NTLMv1 challenge/response difficult (I don't know of any Rainbow Tables currently available for NTLMv1?though that doesn't mean the APT doesn't have them).

If neither NTLMv1 nor NTLMv2 work, then you really have to consider the fact that this could be a downgrade attack. Be very suspicious of any hosts that require you to authenticate with LM challenge-response.

Finally, remember that the LM/NTLM challenge-response protocols are vulnerable to the relay attack, no matter the hash or strength of password. While SMB signing is helpful, consider implementing Extended Protection for Authentication for more complete protection. Given that there are several situations that limit the use of Kerberos, it may well be worth the time and effort to enable EPA in your environment.

That's all for now, other than some lengthy footnotes on SMB signing. While this was what I considered to be the last "major" piece of the puzzle for protecting privileged domain accounts, there are certainly additional ideas and issues to consider, so I'll be back with more on this subject in the coming weeks. Thanks for reading!

Footnotes on SMB Signing

As mentioned above, some consider SMB signing a solution for the relay attack. I don't think it is sufficient for a couple of reasons:

  1. It only protects SMB services.
  2. There's a flaw in Microsoft's implementation which could allow an attacker to effectively bypass SMB signing under certain circumstances.

The first issue is pretty straightforward. In a perfect SMB signing implementation, SMB signing protects against relaying the response to a 3rd victim SMB server by forcing SMB messages to be signed by a session key created from the account's password hash. A rogue server can't generate the session key because it doesn't have the password hash, so it can't send SMB messages to a 3rd server requiring SMB signing. However, this only protects the SMB service. If there were a tool available that would allow a rogue SMB server to relay the NTLM authentication to a non-SMB service, such as an HTTP server requiring NTLM authentication, the SMB signing feature would provide no protection.

There are a number of tools that implement NTLM relaying against non-SMB services. Kurt Grutzmacher wrote a tool called Squirtle which allows a web client's NTLM-authentication exchange to be relayed to an SMB server, which would fail if SMB signing is required. However, his code is open source and there is no reason that it couldn't be modified to allow a connecting SMB client to relay to non-SMB services such as an HTTP server (for example SharePoint or OWA) or other non-SMB services such as Exchange (MAPI/MSRPC) or MS SQL (Windows Integrated Authentication). A recent Metasploit module from Rich Lundeen provides similar capabilities to Squirtle, but with some additional features including the ability to relay NTLMv2. Another new tool called ZackAttack promises even more functionality and flexibility. So even if SMB signing worked as advertised, there are still a number of situations where our credentials would be at risk for NTLM relaying.

My second issue with SMB signing is that it doesn't work as advertised under certain circumstances. There is a limitation as implemented by Microsoft which could allow for privilege escalation against the victim SMB server in the relay attack even with signing enforced. As described on page 2 of this write-up from Juniper on the implications of SMB signing and WAN acceleration, the session key that is used to protect the client-server SMB communications may not need to be re-created if another user has recently established a connection between the client and server. In particular, it states: "The very first real login sets up the MAC key for a CIFS flow [CIFS = Microsoft's SMB implementation]. When the user logs out and logs in again with different usernames, this client/server CIFS flow will be signed with the MAC key that was previously computed." Juniper uses this to their advantage by having the customer create a "virtual user" on the domain that the WAN accelerator can use to establish a connection to the server before the legitimate client in order to get the session key for signing. It is then able to exchange signed SMB messages without knowing the real user's credentials (which would be necessary if the SMB client/server had to re-create the session key).

So how can this allow for privilege escalation? If an attacker has control of a system with a non-privileged domain user, he can then play the part of the "virtual user" in the Juniper solution. He can first set up an SMB connection to the victim SMB server with the non-privileged user in order to get the session key. He can then wait for the privileged user to establish an SMB connection to the compromised host, at which point the attacker can now forward the challenge/response and use the already established session key for signing. Now the attacker has an SMB connection to the victim server as the privileged domain user! Perhaps it is far-fetched for an attacker to go to these lengths (unless a tool becomes available to make it easy), but it is certainly possible until Microsoft addresses this issue.

Now with all that said, I certainly don't want to imply that SMB signing is useless. If it is required by servers and clients, it will certainly raise the bar, helping protect your SMB communications in most cases, and in all cases if Microsoft addresses the loophole leveraged by Juniper. So if you have it enforced in your environment, certainly don't disable it, but look to Extended Protection for Authentication for a more complete solution to the NTLM relay problem.

Mike Pilkington is a Sr. Information Security Analyst and Incident Responder for a Fortune 500 company in Houston, TX, as well as a SANS Mentor and Community Instructor. Mike will be teaching FOR408: Computer Forensic Investigations - Windows In-Depth in Reston, VA, Nov 12-17, 2012.

Share:
TwitterLinkedInFacebook
Copy url Url was copied to clipboard
Subscribe to SANS Newsletters
Receive curated news, vulnerabilities, & security awareness tips
United States
Canada
United Kingdom
Spain
Belgium
Denmark
Norway
Netherlands
Australia
India
Japan
Singapore
Afghanistan
Aland Islands
Albania
Algeria
American Samoa
Andorra
Angola
Anguilla
Antarctica
Antigua and Barbuda
Argentina
Armenia
Aruba
Austria
Azerbaijan
Bahamas
Bahrain
Bangladesh
Barbados
Belarus
Belize
Benin
Bermuda
Bhutan
Bolivia
Bonaire, Sint Eustatius, and Saba
Bosnia And Herzegovina
Botswana
Bouvet Island
Brazil
British Indian Ocean Territory
Brunei Darussalam
Bulgaria
Burkina Faso
Burundi
Cambodia
Cameroon
Cape Verde
Cayman Islands
Central African Republic
Chad
Chile
China
Christmas Island
Cocos (Keeling) Islands
Colombia
Comoros
Cook Islands
Costa Rica
Croatia (Local Name: Hrvatska)
Curacao
Cyprus
Czech Republic
Democratic Republic of the Congo
Djibouti
Dominica
Dominican Republic
East Timor
East Timor
Ecuador
Egypt
El Salvador
Equatorial Guinea
Eritrea
Estonia
Ethiopia
Falkland Islands (Malvinas)
Faroe Islands
Fiji
Finland
France
French Guiana
French Polynesia
French Southern Territories
Gabon
Gambia
Georgia
Germany
Ghana
Gibraltar
Greece
Greenland
Grenada
Guadeloupe
Guam
Guatemala
Guernsey
Guinea
Guinea-Bissau
Guyana
Haiti
Heard And McDonald Islands
Honduras
Hong Kong
Hungary
Iceland
Indonesia
Iraq
Ireland
Isle of Man
Israel
Italy
Jamaica
Jersey
Jordan
Kazakhstan
Kenya
Kiribati
Korea, Republic Of
Kosovo
Kuwait
Kyrgyzstan
Lao People's Democratic Republic
Latvia
Lebanon
Lesotho
Liberia
Liechtenstein
Lithuania
Luxembourg
Macau
Macedonia
Madagascar
Malawi
Malaysia
Maldives
Mali
Malta
Marshall Islands
Martinique
Mauritania
Mauritius
Mayotte
Mexico
Micronesia, Federated States Of
Moldova, Republic Of
Monaco
Mongolia
Montenegro
Montserrat
Morocco
Mozambique
Myanmar
Namibia
Nauru
Nepal
Netherlands Antilles
New Caledonia
New Zealand
Nicaragua
Niger
Nigeria
Niue
Norfolk Island
Northern Mariana Islands
Oman
Pakistan
Palau
Palestine
Panama
Papua New Guinea
Paraguay
Peru
Philippines
Pitcairn
Poland
Portugal
Puerto Rico
Qatar
Reunion
Romania
Russian Federation
Rwanda
Saint Bartholemy
Saint Kitts And Nevis
Saint Lucia
Saint Martin
Saint Vincent And The Grenadines
Samoa
San Marino
Sao Tome And Principe
Saudi Arabia
Senegal
Serbia
Seychelles
Sierra Leone
Sint Maarten
Slovakia
Slovenia
Solomon Islands
South Africa
South Georgia and the South Sandwich Islands
South Sudan
Sri Lanka
St. Helena
St. Pierre And Miquelon
Suriname
Svalbard And Jan Mayen Islands
Swaziland
Sweden
Switzerland
Taiwan
Tajikistan
Tanzania
Thailand
Togo
Tokelau
Tonga
Trinidad And Tobago
Tunisia
Turkey
Turkmenistan
Turks And Caicos Islands
Tuvalu
Uganda
Ukraine
United Arab Emirates
United States Minor Outlying Islands
Uruguay
Uzbekistan
Vanuatu
Vatican City
Venezuela
Vietnam
Virgin Islands (British)
Virgin Islands (U.S.)
Wallis And Futuna Islands
Western Sahara
Yemen
Yugoslavia
Zambia
Zimbabwe

By providing this information, you agree to the processing of your personal data by SANS as described in our Privacy Policy.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Tags:
  • Digital Forensics and Incident Response

Related Content

Blog
blog_340x340_Digital_Forensics_Salary_Skills_and_Career_Path.jpg
Digital Forensics and Incident Response
March 30, 2023
Digital Forensics Salary, Skills, and Career Path
How to become a digital forensic analyst
thomas.jpg
Thomas Wolfe
read more
Blog
N2C_Blog_Image.png
Penetration Testing and Red Teaming, Cyber Defense, Cybersecurity and IT Essentials, Open-Source Intelligence (OSINT), Digital Forensics and Incident Response
March 14, 2023
A Visual Summary of SANS New2Cyber Summit 2023
Check out these graphic recordings created in real-time throughout the event for SANS New2Cyber Summit 2023
370x370-person-placeholder.png
Alison Kim
read more
Blog
Untitled_design-43.png
Digital Forensics and Incident Response, Cybersecurity and IT Essentials, Industrial Control Systems Security, Purple Team, Open-Source Intelligence (OSINT), Penetration Testing and Red Teaming, Cyber Defense, Cloud Security, Security Management, Legal, and Audit
December 8, 2021
Good News: SANS Virtual Summits Will Remain FREE for the Community in 2022
They’re virtual. They’re global. They’re free.
370x370-person-placeholder.png
Emily Blades
read more
  • Register to Learn
  • Courses
  • Certifications
  • Degree Programs
  • Cyber Ranges
  • Job Tools
  • Security Policy Project
  • Posters & Cheat Sheets
  • White Papers
  • Focus Areas
  • Cyber Defense
  • Cloud Security
  • Cybersecurity Leadership
  • Digital Forensics
  • Industrial Control Systems
  • Offensive Operations
Subscribe to SANS Newsletters
Receive curated news, vulnerabilities, & security awareness tips
United States
Canada
United Kingdom
Spain
Belgium
Denmark
Norway
Netherlands
Australia
India
Japan
Singapore
Afghanistan
Aland Islands
Albania
Algeria
American Samoa
Andorra
Angola
Anguilla
Antarctica
Antigua and Barbuda
Argentina
Armenia
Aruba
Austria
Azerbaijan
Bahamas
Bahrain
Bangladesh
Barbados
Belarus
Belize
Benin
Bermuda
Bhutan
Bolivia
Bonaire, Sint Eustatius, and Saba
Bosnia And Herzegovina
Botswana
Bouvet Island
Brazil
British Indian Ocean Territory
Brunei Darussalam
Bulgaria
Burkina Faso
Burundi
Cambodia
Cameroon
Cape Verde
Cayman Islands
Central African Republic
Chad
Chile
China
Christmas Island
Cocos (Keeling) Islands
Colombia
Comoros
Cook Islands
Costa Rica
Croatia (Local Name: Hrvatska)
Curacao
Cyprus
Czech Republic
Democratic Republic of the Congo
Djibouti
Dominica
Dominican Republic
East Timor
East Timor
Ecuador
Egypt
El Salvador
Equatorial Guinea
Eritrea
Estonia
Ethiopia
Falkland Islands (Malvinas)
Faroe Islands
Fiji
Finland
France
French Guiana
French Polynesia
French Southern Territories
Gabon
Gambia
Georgia
Germany
Ghana
Gibraltar
Greece
Greenland
Grenada
Guadeloupe
Guam
Guatemala
Guernsey
Guinea
Guinea-Bissau
Guyana
Haiti
Heard And McDonald Islands
Honduras
Hong Kong
Hungary
Iceland
Indonesia
Iraq
Ireland
Isle of Man
Israel
Italy
Jamaica
Jersey
Jordan
Kazakhstan
Kenya
Kiribati
Korea, Republic Of
Kosovo
Kuwait
Kyrgyzstan
Lao People's Democratic Republic
Latvia
Lebanon
Lesotho
Liberia
Liechtenstein
Lithuania
Luxembourg
Macau
Macedonia
Madagascar
Malawi
Malaysia
Maldives
Mali
Malta
Marshall Islands
Martinique
Mauritania
Mauritius
Mayotte
Mexico
Micronesia, Federated States Of
Moldova, Republic Of
Monaco
Mongolia
Montenegro
Montserrat
Morocco
Mozambique
Myanmar
Namibia
Nauru
Nepal
Netherlands Antilles
New Caledonia
New Zealand
Nicaragua
Niger
Nigeria
Niue
Norfolk Island
Northern Mariana Islands
Oman
Pakistan
Palau
Palestine
Panama
Papua New Guinea
Paraguay
Peru
Philippines
Pitcairn
Poland
Portugal
Puerto Rico
Qatar
Reunion
Romania
Russian Federation
Rwanda
Saint Bartholemy
Saint Kitts And Nevis
Saint Lucia
Saint Martin
Saint Vincent And The Grenadines
Samoa
San Marino
Sao Tome And Principe
Saudi Arabia
Senegal
Serbia
Seychelles
Sierra Leone
Sint Maarten
Slovakia
Slovenia
Solomon Islands
South Africa
South Georgia and the South Sandwich Islands
South Sudan
Sri Lanka
St. Helena
St. Pierre And Miquelon
Suriname
Svalbard And Jan Mayen Islands
Swaziland
Sweden
Switzerland
Taiwan
Tajikistan
Tanzania
Thailand
Togo
Tokelau
Tonga
Trinidad And Tobago
Tunisia
Turkey
Turkmenistan
Turks And Caicos Islands
Tuvalu
Uganda
Ukraine
United Arab Emirates
United States Minor Outlying Islands
Uruguay
Uzbekistan
Vanuatu
Vatican City
Venezuela
Vietnam
Virgin Islands (British)
Virgin Islands (U.S.)
Wallis And Futuna Islands
Western Sahara
Yemen
Yugoslavia
Zambia
Zimbabwe

By providing this information, you agree to the processing of your personal data by SANS as described in our Privacy Policy.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
  • © 2023 SANS™ Institute
  • Privacy Policy
  • Contact
  • Careers
  • Twitter
  • Facebook
  • Youtube
  • LinkedIn