homepage
Open menu Go one level top
  • Train and Certify
    • Get Started in Cyber
    • Courses & Certifications
    • Training Roadmap
    • Search For Training
    • Online Training
    • OnDemand
    • Live Training
    • Summits
    • Cyber Ranges
    • College Degrees & Certificates
    • NICE Framework
    • DoDD 8140
    • Specials
  • Manage Your Team
    • Overview
    • Security Awareness Training
    • Voucher Program
    • Private Training
    • Workforce Development
    • Skill Assessments
    • Hiring Opportunities
  • Resources
    • Overview
    • Reading Room
    • Webcasts
    • Newsletters
    • Blog
    • Tip of The Day
    • Posters
    • Top 25 Programming Errors
    • The Critical Security Controls
    • Security Policy Project
    • Critical Vulnerability Recaps
    • Affiliate Directory
  • Focus Areas
    • Blue Team Operations
    • Cloud Security
    • Digital Forensics & Incident Response
    • Industrial Control Systems
    • Leadership
    • Offensive Operations
  • Get Involved
    • Overview
    • SANS Community
    • CyberTalent
    • Work Study
    • Instructor Development
    • Sponsorship Opportunities
    • COINS
  • About
    • About SANS
    • Why SANS?
    • Instructors
    • Cybersecurity Innovation Awards
    • Contact
    • Frequently Asked Questions
    • Customer Reviews
    • Press Room
  • Log In
  • Join
  • Contact Us
  • SANS Sites
    • GIAC Security Certifications
    • Internet Storm Center
    • SANS Technology Institute
    • Security Awareness Training
  • Search
  1. Home >
  2. Blog >
  3. Computer Forensics: Identifying Disk Differences #8212: Broken Mirrors
Dave Hull

Computer Forensics: Identifying Disk Differences #8212: Broken Mirrors

August 12, 2010

One Friday afternoon I was greeted by a large package from FedEx. Inside the giant box was supposed to be a hard disk drive on which I was to conduct digital forensic analysis. Opening the box and removing a few handfuls of packing peanuts revealed a bubble-wrapped Dell Tower. Obviously, the clients, like most non-computer folks, didn't know they could remove the actual hard disk drive from the tower and send those my way.

After grabbing the paperwork for this job, filling out my own chain-of-custody documentation and evidence receipt, I cracked open the tower and saw the following inside:

D1andD2.jpg
Image 1: Double SATA, Double Fun

This job suddenly got more interesting and possibly less profitable for me. I wondered if the clients knew when they hired me for the job that the system contained two disks. I disconnected the lower drive from the system, added it to my evidence inventory as D1 and connected it to my write-blocker and then to the SIFT Workstation.

After gathering the mmls output for the image, I started the imaging process. The output from mmls looked something like this (actually, it looked nothing like this. I'm not going to expose details of the client's system. For our purposes, this works):

DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors

     Slot    Start        End          Length       Description
00:  Meta    0000000000   0000000000   0000000001   Primary Table (#0)
01:  -----   0000000000   0000000062   0000000063   Unallocated
02:  00:00   0000000063   0000210923   0000210861   Dell Utilities FAT (0xde)
03:  Meta    0000210924   0007952615   0007741692   Win95 Extended (0x0F)
04:  Meta    0000210924   0000210924   0000000001   Extended Table (#1)
05:  -----   0000210924   0000210986   0000000063   Unallocated
06:  01:00   0000210987   0007952615   0007741629   NTFS (0x07)


Based on the interviews with my clients and the information I had about the case, I knew that the NTFS partition would be the primary focus of my investigation. I started the disk imaging process and went out for a walk-about.

After dc3dd finished imaging and hashing the disk image. I returned D1 to the Dell tower and removed the second hard disk drive, added it to the evidence inventory as D2 and repeated the process above.

Running mmls on D2 revealed the following information:

DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors

     Slot    Start        End          Length       Description
00:  Meta    0000000000   0000000000   0000000001   Primary Table (#0)
01:  -----   0000000000   0000000062   0000000063   Unallocated
02:  00:00   0000000063   0000210923   0000210861   Dell Utilities FAT (0xde)
03:  Meta    0000210924   0007952615   0007741692   Win95 Extended (0x0F)
04:  Meta    0000210924   0000210924   0000000001   Extended Table (#1)
05:  -----   0000210924   0000210986   0000000063   Unallocated
06:  01:00   0000210987   0007952615   0007741629   NTFS (0x07)


Astute readers will note that D2's partition table matches D1's exactly. I breathed a sigh of relief as it appeared that D1 and D2 were a mirrored pair likely running in RAID1 configuration. This meant that I could limit my analysis to a single drive and probably finish the job on the original time line I'd promised and without losing money on the gig.

Rather than image D2, I took an MD5 hash of it to verify that it matched D1. Sadly, it did not. If the drives were supposed to be a mirrored pair, the synchronization was apparently broken. At this point, I mounted the NTFS partition on the SIFT workstation and viewed the contents of the root directory and compared them to the contents of the root directory of the NTFS image I'd collected already. Everything in the root directory was the same, file names, sizes, time stamps, sub-directory names and so on. My theory that this was a mirrored pair out of sync had some life in it. I started imaging D2 and thought about ways of quickly isolating differences between the two disks.

My first thought was to run Jesse Kornblum's ssdeep against the disk images to see how similar they were. I tried this, but ssdeep complained, "Value too large for defined data type."

Next I decided to carve out each partition and calculate MD5 hashes and compare them. One by one, the partitions were carved and their MD5 hashes compared. In the end, each partition's hash matched except for the NTFS partition.

Knowing that one of the options for dc3dd is the hashwindow option, which can be used for piecewise hashing, I decided to use it to determine how similar the two disks were. Here are the commands I used:

dc3dd if=D1_ntfs.img hash=md5 hashwindow=10M hashlog=D1.hashlog of=/dev/null
dc3dd if=D2_ntfs.img hash=md5 hashwindow=10M hashlog=D2.hashlog of=/dev/null

Note the output file is /dev/null. I didn't need to create new images, I'd already carved them out. All I wanted from this operation was to locate which portions of the two disk images were different. The result of running these two commands was a couple of text files containing MD5 hashes for 10 MB sections of the NTFS partitions. Here's a sample of the output:

md5 0- 10485760: fdfd6a607ebef09871c3c51140e9eb40
md5 10485760- 20971520: f1c9645dbc14efddc7d8a322685f26eb
md5 20971520- 31457280: f1c9645dbc14efddc7d8a322685f26eb
md5 31457280- 41943040: f1c9645dbc14efddc7d8a322685f26eb
md5 41943040- 52428800: f1c9645dbc14efddc7d8a322685f26eb
...
md5 482344960- 492830720: f1c9645dbc14efddc7d8a322685f26eb
md5 492830720- 503316480: 00254e8b9cf9c6d3a1f6ba8040cf4782
md5 503316480- 513802240: 348b1f2236220e4ab71e335385cb80fe
md5 513802240- 524288000: f1c9645dbc14efddc7d8a322685f26eb
...

The first column of output shows us the hashing algorithm that was used, then the starting and ending byte offsets, followed by the MD5 sum for the bytes in that range. Note that the first 10 MB section of the partition contained data, the next 470 MBs of the partition contained no data, thus the MD5 sums for each 10 MB section were the same until finally, between 470 and 480 MBs, the partition contained something other than nulls, hence the MD5 sums started to vary again.

I was curious to see how different the two sets of hashlogs were. So I ran ssdeep against the first hashlog file and saved the result, then ran ssdeep against the second hashlog, comparing its result against the first:

ssdeep D1.hashlog > D1.hashlog.ssdeep
ssdeep -m D1.hashlog.ssdeep D2.hashlog
/cases/20100808/D2.hashlog matches D1.hashlog.ssdeep:/cases/20100808/D1.hashlog (88)


The hashlogs from these two partitions are 88% alike according to ssdeep. I now had more evidence that these two partitions were (at one point in time) a mirrored pair. The next step was to locate the differences between the two partitions. To do that, I used the diff command:

diff D1.hashlog D2.hashlog 
1c1
< md5 0- 10485760: fdfd6a607ebef09871c3c51140e9eb40
---
> md5 0- 10485760: ef9f993a60a6a77114aab999091597ce
48c48
< md5 492830720- 503316480: 00254e8b9cf9c6d3a1f6ba8040cf4782
---
> md5 492830720- 503316480: 547bd7c44930a1911cd6ce6f85b606df
51c51
< md5 524288000- 534773760: 705c8fc001d91cc32919d34d83127df6
---
> md5 524288000- 534773760: 64772837bbb0502f98af41261bb3743e
53c53
< md5 545259520- 555745280: 272594145001e58f0b1dfba6e7a36ce1
---
> md5 545259520- 555745280: 3497c9365449e8339c550b161ea98535
55,56c55,56
< md5 566231040- 576716800: b20266a7591cac2f2cfa9f8375a71761
< md5 576716800- 587202560: f9b18be13c774fa009717101ec495afc
---
> md5 566231040- 576716800: 58638effcded45e272d555def45351f8
> md5 576716800- 587202560: c366890edd98ed67c381adc7c294dfb5
58,61c58,61
< md5 597688320- 608174080: 9a30b16c50fdd1e6b46c621cabde0ecd
< md5 608174080- 618659840: 59f55c57bc15467e1734d8eab837b02c
< md5 618659840- 629145600: cdcb01a465f188cff6e08b5189413f2e
< md5 629145600- 639631360: 7981b144a85149fcac7fce2161d44278
---
> md5 597688320- 608174080: dedffa8e94b137914ae70ee64d02ec5b
> md5 608174080- 618659840: 9261d04130b4802a9ee6cfe50e5b3f2a
> md5 618659840- 629145600: 46f66e9d9711815a521a3429179f3e42
> md5 629145600- 639631360: 5696f83cead6b1fc80bf5b7819535f99
63c63
< md5 650117120- 660602880: 43aadd02600598fab034d091684c9dff
---
> md5 650117120- 660602880: 9d6db2c17acc1c321493bd054510c1d1
190c190
< md5 1981808640- 1992294400: c8a0dc3bcbedc485c3ebfd06087a34d8
---
> md5 1981808640- 1992294400: b6a289e4342258a016223eb4400f1c8c
380c380
< md5 TOTAL: a347712cc414e2f7ea23baedd929d620
---
> md5 TOTAL: 2ba46718f54169305073b0bc469bc1e9

If you're anything like me, that may look like mind numbing output. Let's review a few lines of the output line-by-line. First is the diff command itself, simple enough, compare D1.hashlog to D2.hashlog. The next line, "1c1" refers to line number one in each file, the "c" means that line number one in the second file has "changed" compared to the first file. The next several lines of diff output follow this same format, then we see

55,56c55,56
< md5 566231040- 576716800: b20266a7591cac2f2cfa9f8375a71761
< md5 576716800- 587202560: f9b18be13c774fa009717101ec495afc
---
> md5 566231040- 576716800: 58638effcded45e272d555def45351f8
> md5 576716800- 587202560: c366890edd98ed67c381adc7c294dfb5


This means that lines 55 through 56 of file one have changed in file two, based on this explanation, you can make sense of the rest of the file. Given diff's output, we've narrowed down the differences between the two ~4 GB files to 120 MBs. We can now narrow in on the differences even more by repeating the process above using a smaller hashwindow and restricting dc3dd to those sections of the NTFS images where we know the differences reside.

The output in the hashlog files contains byte offsets. When we run dc3dd, we'll be working with blocks. We can specify our block size and divide the byte offsets given in diff's output and drill down to the specific portions of each 10 MB section to more precisely locate the differences. Here's an example:

dc3dd bs=512 if=D1_ntfs.img of=/dev/null count=20 hashwindow=1M hash=md5 hashlog=diff_1_D1.dd.hashlog
warning: sector size not probed, assuming 512
dc3dd 6.12.3 started at 2010-08-08 21:47:49 -0400
command line: dc3dd bs=512 if=D1_ntfs.img of=/dev/null count=20 hashwindow=1M hash=md5 hashlog=diff_1_D1.dd.hashlog
compiled options: DEFAULT_BLOCKSIZE=32768
sector size: 512 (assumed)
md5 0- 1048576: d5c912a902d74371aa06aafefe21674a                   
md5 1048576- 2097152: b6d81b360a5672d80c27430f39153e2c             
...

dc3dd bs=512 if=D2_ntfs.img of=/dev/null count=20 hashwindow=1M hash=md5 hashlog=diff_1_D2.dd.hashlog
warning: sector size not probed, assuming 512
dc3dd 6.12.3 started at 2010-08-08 21:50:17 -0400
command line: dc3dd bs=512 if=D2_ntfs.img of=/dev/null count=20 hashwindow=1M hash=md5 hashlog=diff_1_D2.dd.hashlog
compiled options: DEFAULT_BLOCKSIZE=32768
sector size: 512 (assumed)
md5 0- 1048576: 042a76d72aaf721c2d49246a40d974df                   
md5 1048576- 2097152: b6d81b360a5672d80c27430f39153e2c     
...

I've abbreviated the output, but you can see that where previously we knew that there was a difference in the first 10 MBs, now we know that difference is actually in the first MB. Now we're getting somewhere. Let's zoom in on the first MB from each file and see how we can pinpoint the difference.

dc3dd bs=512 if=D1_ntfs.img of=/dev/null hash=md5 hashwindow=512 count=20 hashlog=D1_1MB.hashlog
dc3dd bs=512 if=D2_ntfs.img of=/dev/null hash=md5 hashwindow=512 count=20 hashlog=D2_1MB.hashlog

These dc3dd commands collect the MD5 hashes for every 512 bytes of data for the first 1 MB of each NTFS partition. Running diff on the two resulting hashlog files, we get the following result:

diff D1_1MB.hashlog D2_1MB.hashlog 
17c17
< md5 8192- 8704: 590693b0719f5a66787565fa3d795e05
---
> md5 8192- 8704: dc1196943e31869bbcf12fe86f7d896c

Now we know the difference in the first MB of the NTFS partitions is somewhere between byte offset 8192 and 8704. At this point, we can easily carve out this section of each file and compare them.

dc3dd if=D1_ntfs.img of=D1_8192-8704.img bs=512 skip=16 count=1 hash=md5
warning: sector size not probed, assuming 512
dc3dd 6.12.3 started at 2010-08-08 22:18:22 -0400
command line: dc3dd if=D1_ntfs.img of=D1_8192-8704.img bs=512 skip=16 count=1 hash=md5
compiled options: DEFAULT_BLOCKSIZE=32768
sector size: 512 (assumed)
md5 TOTAL: 590693b0719f5a66787565fa3d795e05                        
1+0 sectors in
1+0 sectors out
512 bytes (512) copied (100%), 0.00191684 s, 261 K/s        
dc3dd completed at 2010-08-08 22:18:22 -0400

dc3dd if=D2_ntfs.img of=D2_8192-8704.img bs=512 skip=16 count=1 hash=md5
warning: sector size not probed, assuming 512
dc3dd 6.12.3 started at 2010-08-08 22:18:42 -0400
command line: dc3dd if=D2_ntfs.img of=D2_8192-8704.img bs=512 skip=16 count=1 hash=md5
compiled options: DEFAULT_BLOCKSIZE=32768
sector size: 512 (assumed)
md5 TOTAL: dc1196943e31869bbcf12fe86f7d896c                        
1+0 sectors in
1+0 sectors out
512 bytes (512) copied (100%), 0.00155415 s, 322 K/s        
dc3dd completed at 2010-08-08 22:18:42 -0400

Let's review our dc3dd command above. We specify our blocksize (bs) as 512 bytes and we want to skip to byte offset 8192 and collect a single block. Skip and count both take blocks as arguments so we divide 8192 by 512 and get 16 for our skip value. Note also that our MD5 sums for each of the 512 byte sections we've carved out, match the previous MD5 sums.

Now to pinpoint the differences in these 512 byte sections, I run them through xxd, dumping them as hexadecimal files and then diff those two files:

xxd -g1 -u D1_8192-8704.img > D1_8192-8704.img.xxd
xxd -g1 -u D2_8192-8704.img > D2_8192-8704.img.xxd
diff D1_8192-8704.img.xxd D2_8192-8704.img.xxd 
1c1
< 0000000: FF FF 00 07 00 00 00 00 7E 37 01 03 00 00 00 00  ........~7......
---
> 0000000: FF FF 00 07 00 00 00 00 FF 3F 00 00 00 00 00 00  .........?......

That's it, repeat this process and determine if the differences between the two disks are relevant to the case. And of course, in true SANS fashion, now that you've seen the difficult way to do something like this, you should know that the SIFT Workstation includes vbindiff, which can solve this problem for you and in a much more elegant way, though you may still run into instances where the files you are working with are too large for vbindiff. Here's a screen capture of vbindiff showing the above difference:

vbindiff.png
Image 2: vbindiff D1_ntfs.img D2_ntfs.img

Dave Hull is an incident responder and forensic investigator for a Fortune 10000 CIRT where he enjoys being the dumbest person in the room. Over the years he has worn many hats and still dons them from time to time. When he's not flipping bits, he enjoys teaching for the SANS Institute.

Share:
TwitterLinkedInFacebook
Copy url Url was copied to clipboard
Subscribe to SANS Newsletters
Join the SANS Community to receive the latest curated cybersecurity news, vulnerabilities, and mitigations, training opportunities, plus our webcast schedule.
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
Kingdom of Saudi Arabia
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
Senegal
Serbia
Seychelles
Sierra Leone
Sint Maarten
Slovakia (Slovak Republic)
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

Tags:
  • Digital Forensics and Incident Response

Related Content

Blog
SUMMIT_Free_SANS_2021_Summits_Teaser.jpg
Digital Forensics and Incident Response, Cyber Defense Essentials, Industrial Control Systems Security, Purple Team, Blue Team Operations, Penetration Testing and Ethical Hacking, Cloud Security, Security Management, Legal, and Audit
November 30, 2020
Good News: SANS Virtual Summits Will Be FREE for the Community in 2021
They’re virtual. They’re global. They’re free.
Emily Blades
read more
Blog
En.png
Digital Forensics and Incident Response
November 24, 2020
SANS DFIR Presenta Nuevos Webcasts en Español
SANS DFIR presenta sus nuevos episodios en Español! En este blog podrás ver todos los episodios con concluciones y con recursos para aprender DFIR
SANS DFIR
read more
Blog
shutterstock_1473864617.jpg
Digital Forensics and Incident Response
October 14, 2020
Defense Spotlight: Finding Hidden Windows Services
Attackers can make a Window services disappear from view. Fortunately these services can still be found, through unconventional discovery techniques.
370x370_Joshua-Wright.jpg
Joshua Wright
read more
  • Register to Learn
  • Courses
  • Certifications
  • Degree Programs
  • Cyber Ranges
  • Job Tools
  • Security Policy Project
  • Posters
  • The Critical Security Controls
  • Focus Areas
  • Blue Team Operations
  • Cloud Security
  • Cybersecurity Leadership
  • Digital Forensics
  • Industrial Control Systems
  • Offensive Operations
Subscribe to SANS Newsletters
Join the SANS Community to receive the latest curated cybersecurity news, vulnerabilities, and mitigations, training opportunities, plus our webcast schedule.
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
Kingdom of Saudi Arabia
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
Senegal
Serbia
Seychelles
Sierra Leone
Sint Maarten
Slovakia (Slovak Republic)
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
  • © 2021 SANS™ Institute
  • Privacy Policy
  • Contact
  • Twitter
  • Facebook
  • Youtube
  • LinkedIn