Over the years, different means have been used to discuss the DFIR analysis process, and one of those has been artifact categories. This is where categories are created and artifacts placed in the various columns, as they relate to those categories. One such example is the SANS IR poster, which provides a great visual reminder for folks looking to employ this approach. Honestly, it is a good way to approach analysis...looking at even a single system image, artifacts have grown over the years as the versions of Windows have progressed from XP to Win7, through to Win10, and as such, it benefits a large portion of the community to have a repeatable approach to analysis.
However, when using approaches such as this, we need to keep in mind the context of the category titles. Yes, the artifacts of "program execution" provide an indication of applications that were launched on a system, but what does that mean?
At this point, I can guess what you're thinking...wait, what?? And believe me, I get it. "Program execution" means exactly that...that a program was executed. End of story. But wait...is that what it really means?
Consider this for a second...someone unfamiliar with a program or application might "open" it on their first try, to see what it does. Command line tools, for example, often contain information about their usage, which we can see by either typing the name of the program at the command prompt (no arguments), or by adding "/?" or "-h" ("--help" for Linuxphiles). This causes the program to run, but not in the sense that the functionality of the program is actually used.
As an example, I opened a command prompt, and changed directories to the C:\Windows\Prefetch folder. Most analysts who've been in the industry for some time are familiar with the application prefetch files, often referred to as simply "Prefetch". Specifically, these are files are widely known as an artifact of "program execution".
I first typed "dir ftp*.pf" to see if there were any Prefetch files that appeared to point to the use of ftp.exe, and got the expected result: File Not Found. Next, I typed "ftp /?" at the prompt, which displayed the usage syntax of the application.
I then retyped (actually, I hit the up arrow twice...) the 'dir' command, and this time, I found that there was a file named FTP.EXE-7BA637EA.pf, which was 2,685 bytes in size.
So, what happened? I ran the program, but only to the point where I could read the usage syntax. I didn't actually use the program to transfer files or exfil data in any way. However, the artifacts of program execution were populated.
Now, the same thing applies to GUI applications, maybe even more so. You can launch a GUI application, look around at the interface, maybe click a few of the options to see what functionality is available, and then close the UI without ever having employed the functionality provided by the application.
Case in point...consider this analysis of the DefCon 2018 CTF file server image. Other publicly available write-ups addressed the question of interest (which application was used to delete forensic artifacts?) with various findings. One was the result of the itempos.pl RegRipper plugin; not an artifact normally associated with program execution, but rather that the application was resident on the desktop. The two other write-ups went with the UserAssist artifacts, widely associated with program execution; however, there was no verification that the application was actually used to, as stated in the CTF question, delete forensic artifacts. As such, the GUI application could have been launched, closed, and then something else could have been used to take the specified actions. In fact, the actions in question were never verified.
As such, something to consider going forward is, when artifacts of program execution are found, what do they really mean?
Finally, a question...there is a way to make use of the FTP protocol on Windows workstations (XP, 7, 8, 10) that does not leave the 'normal' artifacts of program execution (i.e., Prefetch file, UserAssist entry) that does not involve disabling any default functionality. What is it, and how would you determine/verify it?
Addendum, 18 Aug: So far, there's only been one attempt to answer the final question. I know that there's more out there...check the comments to see the answer, but there's at least one more, and maybe even more than one!
19 comments:
Interesting thoughts Harlan. Just because a program was executed, doesn't mean it was used, is something that gets overlooked a lot. I think, from my experience I would try and find additional artifacts from the program being used such as files created or other files modified. Hopefully these would show up in a timeline analysis of the system and possibly application specific event logs. Just another reason why when an analyst makes a statement in a report, they need at least 2 pieces of evidence to back it up.
Chris,
Great comment, and I fully agree.
Beyond assumption (i.e., there's an artifact of program execution, so it *must* have been run...), there's also the issue of data/artifact misinterpretation, with AppCompatCache time stamp being perhaps the most misunderstood artifact.
For the FTP question: the first thing that comes to mind is using the [System.Net.FtpWebRequest]::Create function in Powershell to create the connection.
In my enviroment, I'd use our EDR to look at powershell commands that are run, and proxy logs to see the network connection.
James,
Great answer!
There's still another way, or perhaps more accurately, likely other ways...but that's a great answer. This would leave or modify a Prefetch file for PowerShell, but not for ftp.exe.
Go to FTP://REMOTE_IP in your browser, that should leave iexplorer.exe in the Prefetch. Check firewall/proxy logs to see if FTP was used?
Jassim,
That's a great solution, and it's getting closer to what I had in mind.
Also, there would be a value added to the TypedURLs key, and depending upon the version of Windows, a corresponding value in the TypedURLsTime key.
Again, great solution, and you're getting closer!
To add ---- In Windows, event ID for process execution (4688) does not mean it was executed. You need to refer to the process exit (4688) related to that PID its status code in order to see if it was really executed.. This thing is always missed by SOC (they always reported its executed without referring to the process exit event)
One way is the use of bitsadmin.exe to transfer a file. For example:
Upload: bitsadmin /transfer /upload
Download: bitsadmin /transfer /download
Some ways to detect:
- Monitor execution of bitsadmin for specific command-line arguments (Endpoint)
- Parse Windows Event Log - Microsoft-Windows-Bits-Client/Operational (Endpoint)
- Look for User Agent String: Microsoft BITS/x.x in web proxy logs (Network)
Just thought of using putty to ftp to a remote server. Prefetch will log putty.exe
Taking a quick guess..:-p If using a solid state drive the enableprefetcher default setting will not create prefetch. The extra write operation would affect performance.
Great comments!
Anonymous, I don't believe that bitsadmin uses the FTP protocol, but yes, it can be used to download (and upload) files.
Jassim, great answer!
Greywolf570, great answer!
There's still another way, though! ;-)
Hey Harlan, nice post! Thanks for sharing as always. On the FTP question, one example that comes to mind is using Windows Explorer to access an FTP site. In that case, you could take a look at the shellbags to see references to the interaction with the FTP server.
yawnz... ftp works via Windows Explorer
Jason Hale was the first to provide the answer I was looking for, and anonymous/yawnz followed up with the same answer!
However, neither one provided the "how would you determine/verify it?" part of the answer...any thoughts??
yawnz... HKCU\Software\Microsoft\FTP\Accounts + possibly MRU + possibly NTFS artifacts (if file was copied/downloaded) + memdump analysis could show file transfers
1C76188233DAF93F4DE192708AFC83AACF671365C5D363477F09EB2F8CEA8691
yawnz...good guesses, but that's what they are...guesses. ;-)
I connected to an anonymous FTP server using Windows (NOT Internet) Explorer, and there were no entries beneath HKCU\Software\Microsoft\FTP.
There was, however, this:
Explorer\ftp://ftp.cs.brown.edu [Sat Aug 17 20:22:10 2019] [Desktop\12\0\]
The answer is 'shellbags'. ;-)
yawnz... they are not guesses, but actual artifacts that can be found - you just need to do more tests :-)
To claim they are guesses is not forensically sound.
I just confirmed HKCU\Software\Microsoft\FTP with a FileZilla Server installed on a localhost and with no network connections. If you google this Registry key you will find plenty of references online.
Interestingly, I have not seen the shellback artifact you mentioned either, so here we are talking about two non-reproducible scenarios... :)
To further obfuscate, you can map FTP shares as drives in Windows - shellbags would still track, but would require knowledge of the mount point's underlying destination (HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2\ for those playing along at home).
Great stuff, Mike!!
Post a Comment