Based on a Twitter thread from 19 Feb 2020, during which Phill Moore made the request, I updated RegRipper to check for "dirty" hives, and provided a warning that RegRipper does NOT automatically process Registry transaction logs. This can be an important component of your investigation, and so per Phill's request, I updated RegRipper (both the UI and rip.pl/.exe) to provide the warning, as well as check to see if the hive is 'dirty'.
If you decide that you need to process the transaction logs, there are a couple of options available. One is using yarp (from Maxim Suhanov) along with registryFlush.py (per this blog post). Written in Python, this provides a cross-platform approach, if you need that flexibility. Another method is to use Eric Zimmerman's rla.exe (part of Registry Explorer/RECmd) tool, which is Windows-based.
So, to re-iterate, RegRipper 2.8 does NOT automatically process transaction logs. I haven't developed the code to do so, and there are a number of variables to doing so. For example, the current RegRipper repo contains plugins either intended just for XP systems (i.e., acmru.pl), and also contains plugins that can process data from hives from XP through Win10 (i.e., appcompatcache.pl, shimcache.pl). Transaction logs from older systems (XP, etc.) follow a different format that more modern (Win8.1+) systems, and as such, would require additional code to address those files.
Also, don't forget about the update made to RegRipper on 4 Jan 2020, fixing the issue that began as of 1 Jan 2020 where Registry key LastWrite times were incorrectly reported as "0". The updated code was added to one of the core module files (i.e., Base.pm), which is available in the RegRipper Github repo.
These updates have been "compiled" into the Windows executables for the RegRipper tools (rr.exe, rip.exe), but if you're looking to install RegRipper on Linux, be sure to read the RegRipper readme file and update the Perl modules files according.
Thursday, February 20, 2020
Monday, February 17, 2020
RID Hijacking
I read a fascinating blog post recently that described something called RID hijacking, which can be used as a method for maintaining elevated privileges on a system. The PenTestLabs article not only outlines how to perform RID hijacking manually, but also using MetaSploit, Empire, a Powershell module, and then using the module via POSHC2. In short, there are no shortage of ways to go about performing RID hijacking from an offensive perspective.
But how would this look from a blue team perspective? I made a minor tweak to the output of one of the RegRipper plugins (the data was already available) so that the output appears as follows (run against a SAM hive from a Win2000 system):
Username : Guest [501]
Full Name :
User Comment : Built-in account for guest access to the computer/domain
Account Type :
Account Created : Fri Sep 27 03:32:48 2002 Z
Name :
Last Login Date : Never
Pwd Reset Date : Never
Pwd Fail Date : Sat Aug 25 09:21:50 2012 Z
Login Count : 0
Embedded RID : 501
--> Password does not expire
--> Account Disabled
--> Password not required
--> Normal user account
I added the emphasis on the "Embedded RID" entry. Again, the data itself was available in the plugin, all I did was add the line to display the RID from within the F value data (as described in the PenTestLab article). I also added a bit of logic to compare the embedded value with the RID value from the Username field (in the brackets) and if they aren't same, print out a warning message.
I can't say that I've ever intentionally looked for this sort of thing during an investigation, as there was nothing that pointed to something like RID hijacking having occurred. For example, there were no indications of no suspicious actions involving the Guest account, and subsequently the Guest account being used to log into the system and perform actions requiring Admin privileges.
I have seen threat actors establish multiple means for returning to systems. I've seen threat actors hit an RDP server, enable Sticky Keys, and then create an account, add it to the Administrators group (as well as the Remote Users group) and then add that account to the "SpecialAccounts\UserList" key path so that the icon for the account does not appear on the Welcome screen.
Given that this capability is available, and not only via popular offensive security toolsets, I'd recommend checking for RID hijacking during investigations. Automating the checking means that it's done every time, regardless of who runs the process.
But how would this look from a blue team perspective? I made a minor tweak to the output of one of the RegRipper plugins (the data was already available) so that the output appears as follows (run against a SAM hive from a Win2000 system):
Username : Guest [501]
Full Name :
User Comment : Built-in account for guest access to the computer/domain
Account Type :
Account Created : Fri Sep 27 03:32:48 2002 Z
Name :
Last Login Date : Never
Pwd Reset Date : Never
Pwd Fail Date : Sat Aug 25 09:21:50 2012 Z
Login Count : 0
Embedded RID : 501
--> Password does not expire
--> Account Disabled
--> Password not required
--> Normal user account
I added the emphasis on the "Embedded RID" entry. Again, the data itself was available in the plugin, all I did was add the line to display the RID from within the F value data (as described in the PenTestLab article). I also added a bit of logic to compare the embedded value with the RID value from the Username field (in the brackets) and if they aren't same, print out a warning message.
I can't say that I've ever intentionally looked for this sort of thing during an investigation, as there was nothing that pointed to something like RID hijacking having occurred. For example, there were no indications of no suspicious actions involving the Guest account, and subsequently the Guest account being used to log into the system and perform actions requiring Admin privileges.
I have seen threat actors establish multiple means for returning to systems. I've seen threat actors hit an RDP server, enable Sticky Keys, and then create an account, add it to the Administrators group (as well as the Remote Users group) and then add that account to the "SpecialAccounts\UserList" key path so that the icon for the account does not appear on the Welcome screen.
Given that this capability is available, and not only via popular offensive security toolsets, I'd recommend checking for RID hijacking during investigations. Automating the checking means that it's done every time, regardless of who runs the process.
Saturday, February 15, 2020
Using Intrusion Intelligence
In his book, "Call Sign Chaos", Jim Mattis made the statement that 'your own personal experiences are not enough to sustain you." This statement was made in the context of reading for professional development, and it applies to much more than just warfighting. It also applies equally well in the DFIR field, including DFIR analysis, threat hunting, and developing intrusion intelligence. This is due to the fact that our own experiences are not enough to sustain us, neither as individual analysts nor as teams. None of us want to go to an auto mechanic or a neurosurgeon who stopped their education the moment they received their diploma; as such, it's incumbent upon each of us to further our education and professional development through whatever means works for us. Sometimes, that's as simple as reading...really reading...what someone else has written, and then incorporating what we learn into our own analysis process or methodology.
I recently read this excellent article from the Elastic team regarding their insights into the Gamaredon Group. I found that the article included a good bit of detail, not just in how the Elastic team goes about running down an incident, but also detail with respect to findings written in a manner that can be incorporated into threat hunting and DFIR analysis methodologies with little effort.
I've written and spoken often on the topic of threat actors modifying the target environment to meet their needs. This has been about much more than just modifying the Windows firewall to allow an application to access the Internet; threat actors have been observed making what appear to be subtle changes to target environments, but when those changes are fully understood, they're actually very significant. From enabling systems to store credentials in memory in plain text to disabling security tools, threat actors have been observed making significant modifications to the target environment.
In figure 12 in the Elastic article, we see where, via the macro, the actors modified the infrastructure to permit the execution of untrusted macros, as well as disabled warnings. However, this is nothing new. Mari discussed the VBAWarnings Registry value in Feb, 2016, and the value was mentioned on TechNet as far back as 2012.
As stated in the Elastic article, These small changes can end up having larger implications, and defenders can look for them as symptoms of more serious security issues. This is absolutely the case. The article goes on to identify additional entities that have been observed modifying target environments in a similar manner.
Okay...so what?
Well, there are a number of ways you can make use of this information...and this isn't all of the information from the article. There are a total of 25 figures in the article, and the information discussed above is from three of those figures, two of which are EQL queries. Depending upon the EDR solution you're using, you can monitor for modifications to the Registry, and specifically for that key path, and those values. If you're in a position where you're not able to employ an EDR solution, or if you're limited to just DFIR analysis or retro-active threat hunting, you can check that the values exist, and if so, their data, in order to see if there is or was an issue. If you do find the value data set in accordance with the article, the key LastWrite time may provide a suitable pivot point for analysis.
I recently read this excellent article from the Elastic team regarding their insights into the Gamaredon Group. I found that the article included a good bit of detail, not just in how the Elastic team goes about running down an incident, but also detail with respect to findings written in a manner that can be incorporated into threat hunting and DFIR analysis methodologies with little effort.
I've written and spoken often on the topic of threat actors modifying the target environment to meet their needs. This has been about much more than just modifying the Windows firewall to allow an application to access the Internet; threat actors have been observed making what appear to be subtle changes to target environments, but when those changes are fully understood, they're actually very significant. From enabling systems to store credentials in memory in plain text to disabling security tools, threat actors have been observed making significant modifications to the target environment.
In figure 12 in the Elastic article, we see where, via the macro, the actors modified the infrastructure to permit the execution of untrusted macros, as well as disabled warnings. However, this is nothing new. Mari discussed the VBAWarnings Registry value in Feb, 2016, and the value was mentioned on TechNet as far back as 2012.
As stated in the Elastic article, These small changes can end up having larger implications, and defenders can look for them as symptoms of more serious security issues. This is absolutely the case. The article goes on to identify additional entities that have been observed modifying target environments in a similar manner.
Okay...so what?
Well, there are a number of ways you can make use of this information...and this isn't all of the information from the article. There are a total of 25 figures in the article, and the information discussed above is from three of those figures, two of which are EQL queries. Depending upon the EDR solution you're using, you can monitor for modifications to the Registry, and specifically for that key path, and those values. If you're in a position where you're not able to employ an EDR solution, or if you're limited to just DFIR analysis or retro-active threat hunting, you can check that the values exist, and if so, their data, in order to see if there is or was an issue. If you do find the value data set in accordance with the article, the key LastWrite time may provide a suitable pivot point for analysis.
Thursday, February 13, 2020
Update: Prefetch + Stealth ADS Analysis
Not long ago, I took at look at an image that Dr. Ali Hadi had put together to demonstrate an aspect of digital analysis to his students. Dr. Hadi's blog post describes how the use of the ADSs, particularly when launching programs from ADSs, bypasses "normal" analysis methodologies which can tend to focus on one, or just a few, artifacts. I completely understand and agree with the point that Dr. Hadi made, and wanted to demonstrate the value of analysis that incorporates a corpus of artifacts, or 'artifact clusters'. As we saw in my previous post, there were a number of areas (file system metadata, BAM key, AppCompatCache data, SRUM data) where red flags related to the specific activity could be found, all of which were separate from the artifacts on which Dr. Hadi's article focused.
I decided to take a further look at data sources on the system to see if there were other artifacts that would serve as pivot points in analysis. For example, I found that the AmCache.hve file contained the following entry:
c:\users\ieuser\desktop\creepy\welcome.txt:putty.exe
LastWrite: Sun May 26 08:41:35 2019
Hash: 2662d1bd840184ec61ddf920840ce28774078134
Interestingly, the hash maintained in the AmCache entry is for putty.exe, rather than welcome.txt, and was detected by 47 engines on VT. I say "interestingly" because in some cases where hashes have been generated, they've been for the carrier file, not the ADS.
From the user's ActivitiesCache.db file, specifically the Activity table, I saw this entry in the ContentInfo column (the Executable column listed notepad.exe):
C:\Users\IEUser\Desktop\creepy\welcome.txt (file:Unmapped GUID: //C:/Users/IEUser/Desktop/creepy/welome.txt?VolumeId={20B25A2A-0000-0000-0000-100000000000}&ObjectId={0282E6B5-7F90-11E9-A75B-000C29C3F036}&KnownFolderId=ThisPCDesktopFolder&KnownFolderLength=23)
I added the bold text for a rather obvious misspelling that jumped out; however, there's nothing in the entry that specifically stands out as being associated with the ADSs.
I also took some other parsing steps that were not fruitful. For example, I parsed out all of the unallocated space from the NTUSER.DAT, and also merged the transaction logs into the hive, and re-ran several RegRipper plugins. Like I said, neither were fruitful, in this case.
I'm not sharing this because I disagree with Dr. Hadi's thesis...in fact, I completely agree with him. Too often, we may find ourselves focusing on just one artifact, and as Dr. Hadi pointed out, we can get caught off-guard by some variation of that artifact with which we weren't familiar. I've shared these articles, and the artifacts in them, in order to illustrate the value of using multiple data sources, and being able to find pivot points in your analysis.
I decided to take a further look at data sources on the system to see if there were other artifacts that would serve as pivot points in analysis. For example, I found that the AmCache.hve file contained the following entry:
c:\users\ieuser\desktop\creepy\welcome.txt:putty.exe
LastWrite: Sun May 26 08:41:35 2019
Hash: 2662d1bd840184ec61ddf920840ce28774078134
Interestingly, the hash maintained in the AmCache entry is for putty.exe, rather than welcome.txt, and was detected by 47 engines on VT. I say "interestingly" because in some cases where hashes have been generated, they've been for the carrier file, not the ADS.
From the user's ActivitiesCache.db file, specifically the Activity table, I saw this entry in the ContentInfo column (the Executable column listed notepad.exe):
C:\Users\IEUser\Desktop\creepy\welcome.txt (file:Unmapped GUID: //C:/Users/IEUser/Desktop/creepy/welome.txt?VolumeId={20B25A2A-0000-0000-0000-100000000000}&ObjectId={0282E6B5-7F90-11E9-A75B-000C29C3F036}&KnownFolderId=ThisPCDesktopFolder&KnownFolderLength=23)
I added the bold text for a rather obvious misspelling that jumped out; however, there's nothing in the entry that specifically stands out as being associated with the ADSs.
I also took some other parsing steps that were not fruitful. For example, I parsed out all of the unallocated space from the NTUSER.DAT, and also merged the transaction logs into the hive, and re-ran several RegRipper plugins. Like I said, neither were fruitful, in this case.
I'm not sharing this because I disagree with Dr. Hadi's thesis...in fact, I completely agree with him. Too often, we may find ourselves focusing on just one artifact, and as Dr. Hadi pointed out, we can get caught off-guard by some variation of that artifact with which we weren't familiar. I've shared these articles, and the artifacts in them, in order to illustrate the value of using multiple data sources, and being able to find pivot points in your analysis.
Subscribe to:
Posts (Atom)