The Masquerade Ball: Train Yourself to Detect Spoofed Files

Image

Masquerading is a technique used in which a file name is maliciously named something similar to one which may be trusted. This specific technique is outlined in detail in the MITRE ATT&CK framework, as well. For example, a file named explorer.exe may seem more benign than one called explor3r.exe. However, file names may not be so easy to spot like that. Let’s go through a quick exercise and test your masquerading chops. Which of the following executables is the malicious one?

• Conhost.exe
• Explorer.exe
• Lsalso.exe
• Lsass.exe
• Rdpclip.exe
• Spoolsv.exe
• Svchost.exe
• Svhost.exe

Some of these may seem more familiar than others, such as conhost, explorer, and lsass. Others might be somewhat new to you, such as lsalso or rdpclip. The tricky part for most comes with the final three. Spoolsv is the print spooler service. Svchost is a system process used to launch Windows Services. Svhost is the malicious outlier that is trying to hide by using “sv” for service as used by the spoolsv executable rather than the expected “svc” for service as used by the proper executable. It is quite common to see malicious binaries named like their benign counterpart with a single letter removed, added or modified. Another trick used by attackers is to reuse the benign file name but execute it from a new location. Let’s test your detection skills again. Which of the following is the malicious application?

• C:\Windows\System32\calc.exe
• C:\Windows\System32\explorer.exe
• C:\Windows\System32\notepad.exe
• C:\Windows\notepad.exe

When looking at the file names alone, they all appear to be correct. The file paths they are running in all look to be trusted locations, so an untrained eye can just pass right by all of these when inspecting a system. However, you know you’re being tested, and you know one of these is bad. Three of these are user applications, but they are in different locations. Some executables reside in C:\Windows, C:\Windows\System32 as well as C:\Windows\SysWOW64. Notepad.exe is one of the executables that is in all three locations. Likewise, calc is also expected in the system32 directory, but not the Windows root directory. The malicious executable here is explorer.exe, which should only be in the Windows root directory. If you were to be whitelisting applications by only file name, for example, then an attack like this would bypass your defenses. A few years ago, I discussed how you can bypass AppLocker and described the advantages and disadvantages of blocking by file hash, file path or publisher. The same thought process still holds true when trying to mitigate against this type of attack. When detecting abuse of this technique, the strategy remains relatively the same. Comparing file hashes will be the most accurate test. Creating a list of known good file hashes will be easier to maintain than trying to compare against a list of known bad. However, keeping a list of known good file hashes will need to be continuously curated each month as new patches come out. When pulling a list of files, it may not be possible or efficient to look up the signatures of who signed the file. Benign files may also not be signed by their author, making it difficult to compare good versus bad. In this case, comparing a list of known good file names with their expected file paths is a decent balance between maintainability and accuracy. Using something like the NIST National Software Reference Library will help with comparing file names or hashes. However, the list is not updated very often, so file hashes for recent updates are going to be missing. Also, the NSRL only contains file names and not their full paths, so any malware using known file names will not help, either. It’s best to just create your own list that is unique to your environment. The best place is to create this from a golden image or other system that is not yet in production. To create a simple list, you can use a built-in scripting language like VBS or PowerShell to iterate over the file system and write the names to a list. If you have an endpoint tool such as Tripwire Enterprise, this can be quickly done by gathering the file names and writing them to a file in a central location. If you have multiple platforms, curating a list in a central location is ideal to avoid additional overhead of de-duplicating any gathered file names. As new files are detected on the endpoints, they should be compared against the list of known good files. In the examples above, very quickly you can ignore files that are in known good locations and focus on svhost.exe and C:\Windows\System32\explorer.exe. From a defender’s perspective, having to review two files compared to twelve frees them to focus on other more important tasks. In looking at Windows specifically, monthly patches update critical files on the endpoint each time they are installed. More often than not, the same set of files are updated. Only occasionally are new files written to the OS. When these new files appear, they will be quickly exposed. From here, an analyst can do additional research if they are expected as part of a patch cycle or send the binary to a threat intelligence platform for further analysis. For Tripwire Enterprise customers, all of the features mentioned above are available. A “Promote-By-Match Action” will take the files gathered by any number of rules and compare them to a list of files stored on the Tripwire Enterprise server. Creating that baseline list is as easy as creating another “Execution Action” and running that against a golden image. For the outliers not found in the golden image list, integrate with Tripwire Malware Detection service to send file hashes or even binary files for further analysis and provide results directly back into the console.