Forensic Blogs

An aggregator for digital forensics blogs

May 3, 2022 by Unknown

Putting It All Together

It's great when a plan, or a puzzle, comes together, isn't it? 

I'm not just channeling my inner Hannibal Smith...I'm talking about bringing various pieces or elements together to build a cohesive, clear picture, connecting the dots into a cohesive analysis.

To kick this off, Florian had this to say about threat actors moving to using ISO/IMG files as result of Microsoft disabling VBA macros in docs downloaded from the Internet, a change which results in entirely new artifact constellations. After all, a change in TTPs is going to result in changes as to how the system is impacted, and a change in the resultant constellations. So, this sets the stage for our example.

In this case, the first piece of the puzzle is this tweet from Max_Mal_, which points to the BumbleBee campaign (more info from TAG here), described in the Orion Threat Alert. Per the tweet, the infection looks like this:

Zip -> ISO -> LNK -> rundll32.exe (LOLBin) -> Cobalt Strike

This all starts with a zip archive being delivered to or downloaded by the user; however, what's not mentioned or described here are the system impacts. Downloading the archive often (depending upon the process) results in MOTW being "attached" to the zip archive. This tweet thread by Florian Roth includes a couple of resources that discuss MOTW, one of which is an excellent article by Mike Wolfe that provides a really nice explanation and details regarding MOTW. I've been fascinated by NTFS alternate data streams (ADSs) since I first encountered them, in particular how they're used by the OS, as well as by the adversary. As a result, I've been similarly interested in really leveraging MOTW in every way possible.

The other useful component of Florian's thread is this tweet by Nobutaka Mantani regarding MOTW propagation support in archiver software for Windows. This is huge. What it means is that when the ISO file is extracted from the zip archive by one of the software products that supports MOTW propagation, the extracted file "inherits" MOTW, albeit without the same contents as the original MOTW. Rather, the MOTW attached to the ISO file points back to the zip archive. This then gives us a great deal of insight into the origin of the extracted file, even if the zip archive is deleted.

The benefit is that this may provide us with a detection opportunity, something that depends upon the framework and/or approach you're using. For example, it may be a good idea to alert on files being written to suspicious locations (ProgramData folder, user's StartUp folder, etc.) by one of the archiver software packages, where the target file has a MOTW. Or, we can search for such files, via either proactive or DFIR threat hunting, as a means of locating "badness" on systems or within images. Imagine having an automated process that parses the MFT, either from a triage file collection or from an acquired image, and automatically identifies for the analyst all files with MOTW in suspicious locations. MOTW propagation also appears to occur if the downloaded zip archive includes an LNK file (rather than an ISO file), or a batch file, as well. There have been instances where a batch file is extracted from an archive, to the user's StartUp folder, and has an associated MOTW. As such, automating the detection process, via alerts based on EDR telemetry, or via proactive or DFIR hunting, provides for efficiency and consistency in the analysis process.

So, where we once had to deal with weaponized documents, we're now extracting files from an archive, mounting an ISO or IMG file, and accessing the embedded LNK file within the "new volume". All of this results in a completely new artifact constellation, one that we have to understand in order to fully address coming attacks.

Read the original at: Windows Incident ResponseFiled Under: Digital Forensics

May 1, 2022 by Unknown

Changes In The Use Of LNK Files

Not long ago, I posted regarding how LNK files can be (ab)used; the post refers to LNK file metadata, and how, if the LNK file is sent by the threat actor, that metadata can be used to learn about the threat actor's environment. I first saw this mentioned by JPCERT in 2016, where they included an interesting graph (figure 1) in their post to illustrate the point.
Tony Lambert recently shared via his blog a change in Emotet TTPs, that the threat actor group had moved to using LNK files as an initial delivery mechanism. In the post, Tony described this as "a really interesting TTP change", and that it was "odd but not unexpected". Tony also shared a link to download a copy of the LNK file, as well as metadata parsed from the LNK sample via EXIFTool. I don't often use EXIFTool for this sort of metadata extraction, and I wanted to take a look for myself...here's what I found:
guid        {00021401-0000-0000-c000-000000000046}
shitemidlist    My Computer/C:\/Windows/system32/cmd.exe
**Shell Items Details (times in UTC)**
 C:0          M:0          A:0         Windows (9)  
 C:0          M:0          A:0         system32 (9)  
 C:0          M:0          A:0         cmd.exe (9)  
commandline    /v:on /c findstr "rSIPPswjwCtKoZy.*" Password2.doc.lnk > "%tmp%\VEuIqlISMa.vbs" & "%tmp%\VEuIqlISMa.vbs"
iconfilename    shell32.dll          
hotkey       0x0               
showcmd      0x1               

***LinkFlags***
HasLinkTargetIDList|IsUnicode|HasArguments|HasIconLocation|HasRelativePath

***PropertyStoreDataBlock***
GUID/ID pairs:
{46588ae2-4cbc-4338-bbfc-139326986dce}/4   SID: S-1-5-21-1499925678-132529631-3571256938-1001

***KnownFolderDataBlock***
GUID : {1ac14e77-02e7-4e5d-b744-2eb1ae5198b7}
Folder: CSIDL_SYSTEM
At first glance, this may not seem odd to anyone; however, for me I can see that a great deal of the metadata that researchers would look to has been stripped from the LNK file.
I'm just going to let that soak in.
Okay, so...what we don't see in the above output, and what I verified visually (via UltraEdit), are time stamps. That's right...the time stamps in the LNK file header, as well as the time stamps in the shell items that comprise the relative path, have all been zero'd out. See the lines in the above output that build the path with the folders for "Windows" and "System32", and the file "cmd.exe"? All of these shell items, by default, include time stamps. However, for this LNK file, they're zero'd out.
Remember that JPCERT article from 2016? None of the items we'd expect to find in an LNK file, those elements of metadata mentioned in the JPCERT article...volume serial number, MAC address, machine ID/NetBIOS name...are available in this LNK file. I'm familiar with what it takes to get to this point, having constructed the smallest functioning LNK file (make_lnk.txt) that I could, and one that is missing these same elements of metadata.

For example, here's a sample from Astaroth, and here are samples of output from LNK files created using various native means. However, all of these LNK files, as well as the LNK files from figs 5 and 6 of the Mandiant APT29 report, contain these items of metadata. The one Tony found does not.
So, many thanks to Tony (LinkedIn, Twitter) for not only pointing out the change in Emotet TTPs, but for also sharing a publicly accessible link to the example LNK file. This was truly a fascinating find!
As a final thought, the lack of metadata does not mean that the same techniques to locate other, similar samples...create a Yara rule and submit as a VT retro-hunt...won't work. In fact, the dearth of the missing metadata (that would be a great title for a blog post series!!) is actually an indicator that we can use for a pretty solid search!

Read the original at: Windows Incident ResponseFiled Under: Digital Forensics

April 29, 2022 by Unknown

Root Cause Analysis

One of the challenges within DFIR, particularly as we've moved to an enterprise approach by leveraging EDR telemetry, is the root cause analysis, or "RCA". In short, the challenge is observing malicious activity and determining the root cause; the challenge itself stems from the fact that EDR telemetry is only partial visibility, or that correlating observed malicious activity with causal data not evident or available via EDR telemetry requires additional context, and by extension, additional effort/expenditure of resources. It also requires an additional "leveling up" of skillsets. 

Yes, many organizations that deploy EDR tooling also include a means for extracting additional files/data from the endpoint, and what to collect isn't usually in question. Rather, how to truly exploit the collected data is the issue, with the exploitation of that data being the "levelling up".

When malicious activity is observed, or the impact of malicious activity is discovered (via threat hunting, etc.), the challenge then becomes, how do we determine the root cause? In the past, when someone has shared suspicious activity with me and sought guidance as to next steps, I've often asked, "...did a reboot or login occur just prior to the activity?" as a means of developing context around the observed activity. Was the executable launched via an auto-start mechanism, such as a Windows service, entry in a Run key, or as a Scheduled Task? The thought process has been to seek causal events for the observed activity, which can be important to not only determine the root cause, but perhaps to also identify a shift in TTPs, once we're to a point where we can arrive at attribution.

There are a lot of different ways for threat actors to persist on Windows systems, some of which were mentioned earlier in this post. Each has their advantages and disadvantages, and both require and provide different levels of access. For example, creating an entry in the user's Run key means that the malware won't start again until the user logs in, and then runs within the user context. However, if the threat actor has Admin privileges, they can create a Windows service or Scheduled Task, which then will run malware with SYSTEM level privileges. As a result, the persistence mechanism used provides a great deal of context beyond just the entry for the malware. 

To provide further insight into this topic, Krz wrote up an excellent blog post not long ago about how a laptop going on battery (unplugged from the power cord) can impact an investigation.

Based on the MITRE "Event Triggered Execution: Screensaver" page, I created a RegRipper plugin for my local repo to parse the screensaver settings out of the NTUSER.DAT hive, and ran it against a hive extracted from my local system, the output of which follows:

Launching screensaver v.20220427
screensaver v.20220427
(NTUSER.DAT) Gets user's screensaver settings
MITRE: T1546.002 (persistence)

Control Panel\Desktop
LastWrite: 2021-11-29 11:53:45Z

Screensaver is active.
SCRNSAVE.exe value not found.

Analysis Tip: Threat actors have been observed using the screen saver as a persistent mechanism.

Ref: https://cocomelonc.github.io/tutorial/2022/04/26/malware-pers-2.html
Now, if the "SCRNSAVE.exe" value (listed above as "not found") was set to something that it shouldn't be, we could then use the Desktop key LastWrite time as a pivot point for further analysis. As the Desktop value contains a number of values, we may not be able to specifically attribute the addition or alteration of the SCRNSAVE.exe value to the modification of the key LastWrite time, but it does provide us with some information we can pivot on and leverage in our analysis. 
Another instance to make clear why this example is so compelling...see Jorge's tweet here, which points us to Wietze's tweet, which in turn points us to a new #LOLBAS. Kind of a circuitous route (also apparently available as far back as 2001, from here), I know, but ultimately what this leads us to is the use of a Control Panel applet (desktop.cpl) to proxy the execution of arbitrary commands. In the example, 'calc.exe' is renamed to 'calc.scr' and launched by calling the "InstallScreenSaver" function of the applet. As a result, this persistence mechanism can be established via reg.exe or rundll32.exe; different command lines with different impacts on the system (re: artifacts associated with their execution) but both achieve the same result.
Further, we now have insight into the level of access achieved by the threat actor, the context under which the malware will run, and when the malware is expected to run. This also provides insights into the sophistication and intent of the threat actor, and can be applied toward attribution.

Read the original at: Windows Incident ResponseFiled Under: Digital Forensics

  • « Previous Page
  • 1
  • 2
  • 3
  • 4
  • …
  • 31
  • Next Page »

About

This site aggregates posts from various digital forensics blogs. Feel free to take a look around, and make sure to visit the original sites.

  • Contact
  • Aggregated Sites

Suggest a Site

Know of a site we should add? Enter it below

Sending

Jump to Category

All content is copyright the respective author(s)