-
-
[转帖]The Missing LNK — Correlating User Search LNK files
-
发表于: 2020-2-20 18:15 2155
-
Original link: https://www.fireeye.com/blog/threat-research/2020/02/the-missing-lnk-correlating-user-search-lnk-files.html
Forensic investigators use LNK shortcut files to recover metadata about recently accessed files, including files deleted after the time of access. In a recent investigation, FireEye Mandiant encountered LNK files that indicated an attacker accessed files included in Windows Explorer search results. In our experience, this was a new combination of forensic artifacts. We’re excited to share our findings because they help to paint a more complete picture of an attacker’s actions and objectives on targeted systems. Further, these findings can also be leveraged for insider threat cases to determine the path used to locate and subsequently open a file.
Windows LNK Format
The .lnk extension is associated with a class of files known as Shell Items. These binary format files contain information that can be used to access other data objects in the Windows shell (the graphical user interface).
LNK shortcut files are one type of Shell Item. They are created by the Windows operating system automatically when a user accesses a file from a supported application but can also be created by the user manually. LNK shortcut files typically contain metadata about the accessed file, including the file name and size, the original path, timestamps, volume and system information (ex. drive type and system hostname), and network information (ex. network share path). Fortunately, there are tools available that can parse these files. While internally at Mandiant we leverage FireEye Endpoint Security to parse LNK files and identify suspicious user search terms, for the purposes of this blog post we will be using LECmd by Eric Zimmerman. Figure 1 shows the command line options for LECmd.exe.
Figure 1: LECmd.exe command line options
Parsed metadata within LNK shortcut files is relevant to forensic investigations for multiple use cases, including profiling user activity on a system or searching for references to malware that has since been deleted.
User Search LNK files
Recently, Mandiant encountered LNK files whose format we did not initially recognize. The files came from a Windows Server 2012 R2 system and had paths like those shown in Figure 2. We guessed that they were LNK shortcut files based on their extension and file path; however, their content was not familiar to us.
C:\Users\<user>\AppData\Roaming\Microsoft\Windows\Recent\passw.lnk C:\Users\<user>\AppData\Roaming\Microsoft\Windows\Recent\gov.lnk
Figure 2: Full file path of the unfamiliar LNK files
In the previous examples, a forensic investigator would use the LNK shortcut filename to conclude that a user opened a file named passw or gov. Then, they would use a tool like LECmd to recover additional metadata. This would provide them with the full file path of the accessed file and the timestamps of the file at the time it was accessed - among other forensic information.
However, the previous LNK files did not reveal expected metadata. Figure 3 shows the output of LECmd for passw.lnk (some information omitted for clarity).
LECmd version 1.3.2.1 Author: Eric Zimmerman (saericzimmerman@gmail.com) https://github.com/EricZimmerman/LECmd --- Header --- Target created: Target modified: Target accessed: File size: 0 Flags: HasTargetIdList, IsUnicode, DisableKnownFolderTracking File attributes: 0 Icon index: 0 Show window: SwNormal (Activates and displays the window. The window is restored to its original size and position if the window is minimized or maximized.) --- Target ID information (Format: Type ==> Value) --- Absolute path: Search Folder\passw -Users property view ==> Search Folder >> Property store (Format: GUID\ID Description ==> Value) d5cdd505-2e9c-101b-9397-08002b2cf9ae\AutoList ==> VT_STREAM not implemented (yet) See extension block section for contents for now d5cdd505-2e9c-101b-9397-08002b2cf9ae\AutolistCacheTime ==> 1849138729510 d5cdd505-2e9c-101b-9397-08002b2cf9ae\AutolistCacheKey ==> Search Results in Local Disk (C:)0 -Variable: Users property view ==> passw >> Property store (Format: GUID\ID Description ==> Value) 1e3ee840-bc2b-476c-8237-2acd1a839b22\2 (Description not available) ==> VT_STREAM not implemented 1e3ee840-bc2b-476c-8237-2acd1a839b22\8 (Description not available) ==> passw 28636aa6-953d-11d2-b5d6-00c04fd918d0\11 Item Type ==> Stack 28636aa6-953d-11d2-b5d6-00c04fd918d0\25 SFGAO Flags ==> 805306372 b725f130-47ef-101a-a5f1-02608c9eebac\10 Item Name Display ==> passw --- End Target ID information --- --- Extra blocks information --- >> Property store data block (Format: GUID\ID Description ==> Value) (Property store is empty)
Figure 3: LECmd.exe output for passw.lnk
Of note, none of the expected information for LNK shortcut files is present. However, there were strings of interest in the Target ID Information section including Search Folder\passw as well as Search Results in Local Disk (C:). For comparison, Figure 4 highlights output for a standard LNK shortcut file using a test file. Notice that the target file timestamps, file size, full file path, and other expected file metadata are present (some information omitted for clarity).
LECmd version 1.3.2.1 Author: Eric Zimmerman (saericzimmerman@gmail.com) https://github.com/EricZimmerman/LECmd --- Header --- Target created: 2020-01-21 19:34:28 Target modified: 2020-01-21 19:34:28 Target accessed: 2020-01-22 21:25:12 File size: 4 Flags: HasTargetIdList, HasLinkInfo, HasRelativePath, HasWorkingDir, IsUnicode, DisableKnownFolderTracking File attributes: FileAttributeArchive Icon index: 0 Show window: SwNormal (Activates and displays the window. The window is restored to its original size and position if the window is minimized or maximized.) Relative Path: ..\..\..\..\..\Desktop\test.txt Working Directory: C:\Users\<username>\Desktop --- Link information --- Flags: VolumeIdAndLocalBasePath >>Volume information Drive type: Fixed storage media (Hard drive) Serial number: <serial number> Label: OSDisk Local path: C:\Users\<username>\Desktop\test.txt --- Target ID information (Format: Type ==> Value) --- Absolute path: My Computer\Desktop\test.txt -Root folder: GUID ==> My Computer -Root folder: GUID ==> Desktop -File ==> test.txt Short name: test.txt Modified: 2020-01-21 19:34:30 Extension block count: 1 --------- Block 0 (Beef0004) --------- Long name: test.txt Created: 2020-01-21 19:34:30 Last access: 2020-01-21 19:34:32 MFT entry/sequence #: 108919/8 (0x1A977/0x8) --- End Target ID information --- --- Extra blocks information --- >> Tracker database block Machine ID: <hostname> MAC Address: <mac address> MAC Vendor: INTEL Creation: 2020-01-21 15:19:59 Volume Droid: <volume> Volume Droid Birth: <volume> File Droid: <file> File Droid birth: <file>
Figure 4: LECmd.exe output for standard LNK shortcut file test.txt
Fortunately, during the investigation we also parsed the user’s NTUSER.DAT registry file (using Harlan Carvey’s RegRipper) and reviewed the WorldWheelQuery key which details user Explorer search history. The passw.lnk file suddenly became more interesting! Figure 5 shows the entries parsed from the registry key. Note that the search history includes the same term we observed in the LNK file: passw.
wordwheelquery v.20100330 (NTUSER.DAT) Gets contents of user's WordWheelQuery key Software\Microsoft\Windows\CurrentVersion\Explorer\WordWheelQuery LastWrite Time Wed Nov 13 06:51:46 2019 (UTC) Searches listed in MRUListEx order 14 Secret 6 passw 13 ccc 12 bbb 11 aaa 10 *.cfg 9 apple 8 dni 7 private 4 gov 5 air 3 intelsat 2 adhealthcheck 1 *.ps1 0 global
Figure 5: WorldWheelQuery key extracted from the user’s NTUSER.DAT registry file
Via the WorldWheelQuery registry key, we identified passw as the second most recent term in the user’s Explorer search history according to the MRUListEx order. MRUListEx is a registry value that lists the order in which other values have most recently been accessed—essentially, the order in which terms were searched in Explorer. passw also matched the filename of the unusual LNK file that contained the string Search Results in Local Disk (C:) (see Figure 3). These details seemed to suggest that LNK files were being created as a result of user Explorer searches. Therefore, we’ve started calling these “user search LNK files”.
Nuance and Interpretation
After searching the system for LNK files with the terms listed in the user’s Explorer search history, we found that not all terms had associated user search LNK files. Figure 6 displays LNK files and their accompanying file creation and modification timestamps that we identified as a result of this search. Note that while we found 15 searches via the WorldWheelQuery registry key, there are only four (4) user search LNK files.
2019-11-09 08:33:14 Created Modified C:\Users\<user>\AppData\Roaming\Microsoft\Windows\Recent\gov.lnk 2019-11-09 09:29:11 Created 2019-11-09 09:29:37 Modified C:\Users\<user>\AppData\Roaming\Microsoft\Windows\Recent\private.lnk 2019-11-09 08:38:29 Created 2019-11-13 06:47:56 Modified C:\Users\<user>\AppData\Roaming\Microsoft\Windows\Recent\passw.lnk 2019-11-13 06:57:03 Created 2019-11-13 06:57:25 Modified C:\Users\<user>\AppData\Roaming\Microsoft\Windows\Recent\Secret.lnk
Figure 6: LNK files with associated WorldWheelQuery Explorer search terms
Additionally, we noticed pairs of LNK files created at the same time that had similar names. As an example, Figure 7 lists two LNK files that were both created at 2019-11-09 08:38:29 UTC.
C:\Users\<user>\AppData\Roaming\Microsoft\Windows\Recent\passw.lnk C:\Users\<user>\AppData\Roaming\Microsoft\Windows\Recent\password.lnk
Figure 7: LNK files created at the same time
After further testing, we determined that the system created user search LNK files as a result of Explorer searches where the user opened one of the files produced as a result of this search. User search LNK files were not created if the user did not open a file returned by the search.
In this example, the password.lnk file contained target file metadata, as would be expected for LNK shortcut files, and referenced a target file named password.txt located in the T:\ directory. passw.lnk, as previously discussed, only contained expected metadata for a user search LNK file, including the absolute path Search Folder\passw with reference to Search Results in Local Disk (C:). However, this discrepancy in directory—the user search LNK file search context of Search Results in Local Disk (C:) and the LNK shortcut file located in the T:\ drive—is actually as expected.
LNK shortcut files contain metadata for the most recently accessed file, and we found the same to be true for user search LNK files. Based on differing creation and modification timestamps for passw.lnk, we know the user searched for passw in at least one other instance (we’re not able to conclude whether a search happened between these two points in time) and opened a file from the search results. This is seen in the timestamps for the passw user search LNK file in Figure 8.
2019-11-09 08:38:29 Created 2019-11-13 06:47:56 Modified C:\Users\<user>\AppData\Roaming\Microsoft\Windows\Recent\passw.lnk
Figure 8: passw.lnk creation and modification timestamps
The second occurrence of a search for passw occurred on November 13, 2019. In this instance, the user again searched for the term passw using Windows Explorer search, but this time searched within the context of the C:\ drive (Search Results in Local Disk (C:)), and subsequently clicked on a document named password2.txt. The results from LECmd for password2.lnk can be seen in Figure 9 (some information omitted for clarity and to protect client information). Notice the information embedded in user search LNK files is also embedded within the LNK shortcut file that is created simultaneously with the user search LNK file (underlined text). The search context for passw.lnk and full file path location for password2.lnk both match: C:.
LECmd version 1.3.2.1 Author: Eric Zimmerman (saericzimmerman@gmail.com) https://github.com/EricZimmerman/LECmd --- Header --- Target created: 2015-11-09 22:14:10 Target modified: 2010-01-11 16:57:11 Target accessed: 2015-11-09 22:14:10 File size: 19 Flags: HasTargetIdList, HasLinkInfo, HasRelativePath, HasWorkingDir, IsUnicode, DisableKnownFolderTracking File attributes: FileAttributeArchive Icon index: 0 Show window: SwNormal (Activates and displays the window. The window is restored to its original size and position if the window is minimized or maximized.) Relative Path: ..\..\..\..\..\..\..\<file path>\password2.txt Working Directory: C:\<file path> --- Link information --- Flags: VolumeIdAndLocalBasePath, CommonNetworkRelativeLinkAndPathSuffix >>Volume information Drive type: Fixed storage media (Hard drive) Serial number: <serial number> Label: (No label) Network share information Share name: \\<hostname>\<top level folder> Provider type: <provider type> Share flags: ValidNetType Local path: C:\<top level folder>\ Common path: <file path>\password2.txt --- Target ID information (Format: Type ==> Value) --- Absolute path: Search Folder\passw\password2 -Users property view ==> Search Folder >> Property store (Format: GUID\ID Description ==> Value) d5cdd505-2e9c-101b-9397-08002b2cf9ae\AutoList ==> VT_STREAM not implemented (yet) See extension block section for contents for now d5cdd505-2e9c-101b-9397-08002b2cf9ae\AutolistCacheTime ==> 1849138729510 d5cdd505-2e9c-101b-9397-08002b2cf9ae\AutolistCacheKey ==> Search Results in Local Disk (C:)0 -Variable: Users property view ==> passw >> Property store (Format: GUID\ID Description ==> Value) 1e3ee840-bc2b-476c-8237-2acd1a839b22\2 (Description not available) ==> VT_STREAM not implemented 1e3ee840-bc2b-476c-8237-2acd1a839b22\8 (Description not available) ==> passw 28636aa6-953d-11d2-b5d6-00c04fd918d0\11 Item Type ==> Stack 28636aa6-953d-11d2-b5d6-00c04fd918d0\25 SFGAO Flags ==> 805306372 b725f130-47ef-101a-a5f1-02608c9eebac\10 Item Name Display ==> passw -Variable: Users property view ==> password2 >> Property store (Format: GUID\ID Description ==> Value) 49691c90-7e17-101a-a91c-08002b2ecda9\3 Search Rank ==> 0 28636aa6-953d-11d2-b5d6-00c04fd918d0\25 SFGAO Flags ==> 1077936503 28636aa6-953d-11d2-b5d6-00c04fd918d0\32 Delegate ID List ==> VT_VECTOR data not implemented (yet) See extension block section for contents for now 28636aa6-953d-11d2-b5d6-00c04fd918d0\11 Item Type ==> .txt 28636aa6-953d-11d2-b5d6-00c04fd918d0\24 Parsing Name ==> password2.txt 446d16b1-8dad-4870-a748-402ea43d788c\100 Thumbnail Cache Id ==> 7524032674880659487 1e3ee840-bc2b-476c-8237-2acd1a839b22\12 (Description not available) ==> Null 1e3ee840-bc2b-476c-8237-2acd1a839b22\20 (Description not available) ==> 1 1e3ee840-bc2b-476c-8237-2acd1a839b22\3 (Description not available) ==> document 1e3ee840-bc2b-476c-8237-2acd1a839b22\17 (Description not available) ==> {1685D4AB-A51B-4AF1-A4E5-CEE87002431D}.Merge Any 1e3ee840-bc2b-476c-8237-2acd1a839b22\8 (Description not available) ==> C:\<file path>\password2.txt b725f130-47ef-101a-a5f1-02608c9eebac\4 Item Type Text ==> Text Document b725f130-47ef-101a-a5f1-02608c9eebac\10 Item Name Display ==> password2 b725f130-47ef-101a-a5f1-02608c9eebac\12 Size ==> 19 b725f130-47ef-101a-a5f1-02608c9eebac\14 Date Modified ==> 01/11/2010 16:57:11 006fdbaa-864f-4d1c-a8e8-e62772e454fe\11 (Description not available) ==> 59 006fdbaa-864f-4d1c-a8e8-e62772e454fe\13 (Description not available) ==> 1077936423 cf5be8c0-236c-4ad3-bace-cd608a2748d7\100 (Description not available) ==> True e3e0584c-b788-4a5a-bb20-7f5a44c9acdd\6 Item Folder Path Display ==> C:\<file path> --- End Target ID information --- --- Extra blocks information --- >> Property store data block (Format: GUID\ID Description ==> Value) (Property store is empty) >> Tracker database block Machine ID: <hostname> MAC Address: <mac address> MAC Vendor: VMWARE Creation: 2019-11-13 04:29:24 Volume Droid: <volume> Volume Droid Birth: <volume> File Droid: <file> File Droid birth: <file>
Figure 9: LECmd.exe output for password2.lnk
The takeaway here is that user search LNK files are only related to the search term and not search context. This means later searches for the same search term, e.g. passw, when the user subsequently opens a search result, but in a different drive or directory changes the modification timestamp for the user search LNK file as well as the search context contained in the user search LNK file. This keeps in step with LNK shortcut files, which are dependent on a simple filename—not the full file path.
Timestamp Interpretation
Historically, due to the structure of the WorldWheelQuery registry key and available timestamps in the Windows Registry, investigators could only determine the search time of the most recent term using the last modification time of the registry key. With user search LNK files, new timestamps are available to determine the times a user searched for a specific term when the user subsequently opened a file from the search. Going further, we can combine evidence from the user search LNK files and the WorldWheelQuery MRUlistEx registry key value to infer the order of searches completed by the user. For instance, since the user searched for gov (WorldWheelQuery search index 4), passw (index 6), and private (index 7), we can infer they also searched for air (index 5) but didn't open any files resulting from this search.
Conclusion
LNK shortcut files have been a reliable method to determine user access to files and the associated file metadata at the time of access. With user search LNK files, we can now enrich our Windows Explorer search history findings and gain a more detailed picture of user activity through additional timestamps of user Explorer searches with subsequent access to files from the search.
Acknowledgements
Thank you to Phillip Kealy and William Ballenthin for technical review and providing feedback on overall presentation.
[培训]内核驱动高级班,冲击BAT一流互联网大厂工作,每周日13:00-18:00直播授课