The FireEye folks recently shared a fascinating article regarding a spear-phishing campaign that involved the use of 'weaponized' LNK files, two of which were of particular interest:
1. SPEC-10T-MK2-000-ISS-4.10-09-2018-STANDARD.pdf.lnk
MD5: ec0fb9d17ec77ad05f9a69879327e2f9
2. From the Related Samples section is another LNK file with a filename that includes the Ukranian word for "Conclusion"
MD5: fe198e90813c5ee1cfd95edce5241e25
It turns out there are some similarities in the metadata of the LNK files, but also some odd differences.
Similarities:
Basepath, shellitemIDlist: C:\Windows\System32\mshta.exe
Description: "Type: Text Document"
Iconfilename: ".\128_2_21.docx"
Commandline: Very similar, both point to same domain, although the command line in LNK 1 is base64 encoded, and in LNK 2, it isn't
PropertyStoreDataBlock: both contain the same SID, S-1-5-21-871675894-2481818095-1561791058-1002
Differences:
Volume SN: Volume serial numbers are different both systems
TrackerDataBlock: Both LNK files have different TrackerDataBlocks, including the machineID field.
In the past, similarities in LNK file metadata (machineID, volume serial number, MAC address) have been attributed to a single VM being shared. So, the question becomes, how do different LNK files include the same user SID, but different volume serial numbers, NetBIOS machine names, and MAC addresses?
The MAC address artifact, I get. I can also see how the iconfilename might be the same; personally, I'm a fan of re-using things that work. The description field is entirely optional, and the fact that they're the same between LNK files is interesting. In and of themselves, the different values in the TrackerDataBlock (machine ID, MAC address) are not unusual, but given that the SIDs are the same, that is odd. Could it be the result of something like this? If so, that's pretty darned specific.
Thoughts?
Sunday, April 21, 2019
Monday, April 15, 2019
Registry Transaction Logs, pt II
My previous blog post on this topic was an initial look into what happens (i.e., changes, what 'new' data is available, etc.) when you merge Registry transaction logs into a hive. This started out with me just looking at what tools were available for doing so, and then expanded a bit into, "oh, let's see what changes were made in the hive file...".
In this post, I wanted to provide a bit more information and clarification around what I did and what I found, so that others can more clearly see the process, and hopefully, the value of pursuing this sort of testing and research.
Clarification
My initial testing led to some very interesting findings, one of which was stated as the following:
The del.pl plugin produced some interesting results. When I ran it against the original System hive, it pulled out a number of deleted keys and values; however, running it against the 'new' (i.e., merged) hive, I got nothing. Not one deleted key, not one deleted value.
Now, the assumption here might be that there are no deleted keys and values after the transaction logs have been merged into the hive, and that would be incorrect. The reason that the tool displayed no findings on the second run (and thanks to Maxim for providing insight into this...) is that the plugin only checks the beginning of a free cell for indications of a deleted key or value node; it doesn't traverse and check the entire cell. This is why we have tool testing and verification, and what leads to those of us who write and use such tools to update them.
So, for the sake of clarity, merging the transaction logs into a hive file does not remove all unallocated space and deleted cells. That being said, there is significant value in running tools that check for deleted cells across both the original and the merged hives.
Tools
For testing, I opted for using the LoneWolf scenario image, as it is readily available. Any hives and their corresponding transaction logs can be used, but going with a publicly available image allows for clarity and simplicity in discussions. I opened the image in FTK Imager, and extracted System hive from the system32\config folder, along with the System.log1 and System.log2 transaction log files.
As to merging transaction logs into hives, I tweeted a question regarding tools used to merge hives and transaction logs. I got a response from Maxim, stating "yarp + registryFlush.py". Once I got everything set up and running, this process ran as advertised. I passed the necessary arguments to the script, and ended up with four files in the folder:
03/27/2018 05:45 PM 12,845,056 SYSTEM
09/29/2017 04:45 AM 3,163,136 SYSTEM.LOG1
09/29/2017 04:45 AM 3,211,264 SYSTEM.LOG2
04/08/2019 04:04 PM 12,845,056 system_2019-04-08@160420
At this point, I have the 'dirty' hive and transaction logs extracted from the image, as well as the 'merged' hive file. Note that the file system reports the 'dirty' and 'merged' hives as being the same size.
Deleted Keys/Values
I mentioned checking for deleted keys and values at the beginning of this post; Maxim provided this advice regarding the use of the "yarp-print" tool as the more accurate approach to recovering deleted keys and values.
Specifically, if you're using yarp on Windows, start by opening a command prompt, navigating to the folder where the tools are located, and type:
set PYTHONIOENCODING=utf-8
Then, to parse deleted keys/values from the 'dirty' hive, you can use the following command:
yarp-print --deleted --no-recovery SYSTEM
In this case, you would used the --no-recovery switch as the tool will automatically attempt to discover the transaction log files.
In order to parse the deleted keys and values, incorporating the transaction logs into the process, you'd use the following command line, if you extracted the transaction logs into the same folder as the hive file:
yarp-print --deleted SYSTEM
Again, the yarp tools will attempt to discover the transaction logs for you, and incorporate them into the parsing. This also means that you can use the yarp-print tool to extract deleted keys and values from the merged hive, using the following command:
yarp-print --deleted system_2019-04-08@160420
In this case, you don't have to use the --no-recovery switch, as the tool won't find transaction logs associated with the merged hive.
RegRipper
As I mentioned in my previous post, one of the interesting aspects of this testing was the differences in output from various RegRipper plugins when run against the 'dirty' and 'merged' hives.
The output of the mountdev.pl plugin, when run against the 'merged' hive, included an additional DosDevice entry:
\DosDevices\F:
Drive Signature = 76 d4 59 81
The output of the bam.pl plugin, when run against the 'merged' hive, included two additional entries for the user with RID 1001:
Fri Apr 6 12:27:06 2018 - \Device\HarddiskVolume4\Program Files (x86)\Microsoft Office\root\Office16\EXCEL.EXE
Fri Apr 6 12:41:21 2018 - \Device\HarddiskVolume6\Programs\Imager_Lite_3.1.1\FTK Imager.exe
The same output also included an entry for the Local System account that was not in the 'dirty' hive:
S-1-5-18
Fri Apr 6 12:40:38 2018 - \Device\HarddiskVolume4\Windows\System32\csrss.exe
Take-Aways
Just with this initial testing, using just this one hive, we can begin to see the value of making use of the hive transaction logs. The System hive used in this case was not from a high-use system; that is to say that it was from a forensic challenge scenario system, and not a system used in a corporate environment. Regardless, this limited testing did allow us to see that there is considerable value in incorporating the transaction logs in our Registry parsing process.
Other images are available online which may be used to further this testing. For example, the Mystery Hacked System image includes activity within the user profiles, and as such, may prove to be interesting and provide even more support for this process.
Finally, after merging the transaction logs, I ran some basic diff utilities against the 'dirty' and 'merged' hives, and noted that there were a number of entries that appeared in the 'merged' hive that were not visible in the 'dirty' hive. A method for narrowing this down a bit might be to run RegRipper profiles against both, and then run text-based diff utilities against the results of each of the profile runs.
Next Steps
My next steps are to examine additional tools (specifically, Eric Zimmerman's Registry Explorer and RECmd tools) that can be used in this process, and leveraged to take advantage of the additional data within Registry transaction logs.
References
Maxim - Exploring intermediate states of a registry hive
FireEye - Digging up the past
Other Tools
Regipy - alternative tool for merging transaction logs (note: I'm working with the author...)
RegRippy - RegRipper alternative, written in Python3
In this post, I wanted to provide a bit more information and clarification around what I did and what I found, so that others can more clearly see the process, and hopefully, the value of pursuing this sort of testing and research.
Clarification
My initial testing led to some very interesting findings, one of which was stated as the following:
The del.pl plugin produced some interesting results. When I ran it against the original System hive, it pulled out a number of deleted keys and values; however, running it against the 'new' (i.e., merged) hive, I got nothing. Not one deleted key, not one deleted value.
Now, the assumption here might be that there are no deleted keys and values after the transaction logs have been merged into the hive, and that would be incorrect. The reason that the tool displayed no findings on the second run (and thanks to Maxim for providing insight into this...) is that the plugin only checks the beginning of a free cell for indications of a deleted key or value node; it doesn't traverse and check the entire cell. This is why we have tool testing and verification, and what leads to those of us who write and use such tools to update them.
So, for the sake of clarity, merging the transaction logs into a hive file does not remove all unallocated space and deleted cells. That being said, there is significant value in running tools that check for deleted cells across both the original and the merged hives.
Tools
For testing, I opted for using the LoneWolf scenario image, as it is readily available. Any hives and their corresponding transaction logs can be used, but going with a publicly available image allows for clarity and simplicity in discussions. I opened the image in FTK Imager, and extracted System hive from the system32\config folder, along with the System.log1 and System.log2 transaction log files.
As to merging transaction logs into hives, I tweeted a question regarding tools used to merge hives and transaction logs. I got a response from Maxim, stating "yarp + registryFlush.py". Once I got everything set up and running, this process ran as advertised. I passed the necessary arguments to the script, and ended up with four files in the folder:
03/27/2018 05:45 PM 12,845,056 SYSTEM
09/29/2017 04:45 AM 3,163,136 SYSTEM.LOG1
09/29/2017 04:45 AM 3,211,264 SYSTEM.LOG2
04/08/2019 04:04 PM 12,845,056 system_2019-04-08@160420
At this point, I have the 'dirty' hive and transaction logs extracted from the image, as well as the 'merged' hive file. Note that the file system reports the 'dirty' and 'merged' hives as being the same size.
Deleted Keys/Values
I mentioned checking for deleted keys and values at the beginning of this post; Maxim provided this advice regarding the use of the "yarp-print" tool as the more accurate approach to recovering deleted keys and values.
Specifically, if you're using yarp on Windows, start by opening a command prompt, navigating to the folder where the tools are located, and type:
set PYTHONIOENCODING=utf-8
Then, to parse deleted keys/values from the 'dirty' hive, you can use the following command:
yarp-print --deleted --no-recovery SYSTEM
In this case, you would used the --no-recovery switch as the tool will automatically attempt to discover the transaction log files.
In order to parse the deleted keys and values, incorporating the transaction logs into the process, you'd use the following command line, if you extracted the transaction logs into the same folder as the hive file:
yarp-print --deleted SYSTEM
Again, the yarp tools will attempt to discover the transaction logs for you, and incorporate them into the parsing. This also means that you can use the yarp-print tool to extract deleted keys and values from the merged hive, using the following command:
yarp-print --deleted system_2019-04-08@160420
In this case, you don't have to use the --no-recovery switch, as the tool won't find transaction logs associated with the merged hive.
RegRipper
As I mentioned in my previous post, one of the interesting aspects of this testing was the differences in output from various RegRipper plugins when run against the 'dirty' and 'merged' hives.
The output of the mountdev.pl plugin, when run against the 'merged' hive, included an additional DosDevice entry:
\DosDevices\F:
Drive Signature = 76 d4 59 81
The output of the bam.pl plugin, when run against the 'merged' hive, included two additional entries for the user with RID 1001:
Fri Apr 6 12:27:06 2018 - \Device\HarddiskVolume4\Program Files (x86)\Microsoft Office\root\Office16\EXCEL.EXE
Fri Apr 6 12:41:21 2018 - \Device\HarddiskVolume6\Programs\Imager_Lite_3.1.1\FTK Imager.exe
The same output also included an entry for the Local System account that was not in the 'dirty' hive:
S-1-5-18
Fri Apr 6 12:40:38 2018 - \Device\HarddiskVolume4\Windows\System32\csrss.exe
Take-Aways
Just with this initial testing, using just this one hive, we can begin to see the value of making use of the hive transaction logs. The System hive used in this case was not from a high-use system; that is to say that it was from a forensic challenge scenario system, and not a system used in a corporate environment. Regardless, this limited testing did allow us to see that there is considerable value in incorporating the transaction logs in our Registry parsing process.
Other images are available online which may be used to further this testing. For example, the Mystery Hacked System image includes activity within the user profiles, and as such, may prove to be interesting and provide even more support for this process.
Finally, after merging the transaction logs, I ran some basic diff utilities against the 'dirty' and 'merged' hives, and noted that there were a number of entries that appeared in the 'merged' hive that were not visible in the 'dirty' hive. A method for narrowing this down a bit might be to run RegRipper profiles against both, and then run text-based diff utilities against the results of each of the profile runs.
Next Steps
My next steps are to examine additional tools (specifically, Eric Zimmerman's Registry Explorer and RECmd tools) that can be used in this process, and leveraged to take advantage of the additional data within Registry transaction logs.
References
Maxim - Exploring intermediate states of a registry hive
FireEye - Digging up the past
Other Tools
Regipy - alternative tool for merging transaction logs (note: I'm working with the author...)
RegRippy - RegRipper alternative, written in Python3
Saturday, April 13, 2019
Latest Testing: The Windows Registry, pt I
I've always been interested in and fascinated with the Windows Registry, in large part due to the fact that early in my DFIR career few really seemed to have a good grasp on, or interest in, just how central it is to the Windows operating system. By extension, the grasp, for the community at large, as to the analysis value of the Registry was underestimated. We've seen changes to this attitude over the years, and as the migration to incorporating the Windows Registry into analysis has progressed, so has the development of techniques for deriving even more analysis value from the Registry.
Interest in the Registry as a source of data for digital analysis and incident response has waxed and waned over the years. In the late '90s while I was performing vulnerability assessments, there was considerable utility in querying the Registry from live systems in order to determine the state and attack surface of those systems. We were looking for (and finding) active modems in systems, as well as extracting information about software versions, etc. To a large extent, this remains true today; there is a great deal of data available in the Registry to assist in developing an understanding of not only the state of the system at a given time, but also activity that occurred on the system.
In 2008, Jolanta Thomassen shared her dissertation regarding parsing Windows Registry hive file unallocated space; that is, retrieving deleted keys and values from unallocated space within the hive file itself. She also released regslack.exe, a command line tool for extracting deleted keys and values from hive files. Other tools have followed suit, providing similar functionality. Eventually, RegRipper included this functionality, as well.
In the past couple of years, attention has turned to Registry transaction logs, and incorporating data from those logs directly into hive files in order to achieve a more comprehensive and perhaps 'correct' view of the hive contents. As such, I wanted to determine what tools were available to merge transaction logs into a hive file, and from there, begin looking at the effect of the merge operation.
I installed Python 3.7 on a Windows 10 system. I opted for Python 3.7, as it is required for a tool I'm planning to test, Regipy. I installed yarp on that system, as well. This is the system I'm using as the platform for merging hives with their transaction logs.
I began testing by using yarp + registryFlush.py (thanks to Maxim) to merge the transaction logs (hive.log1, hive.log2) into a hive file, using hives from the LoneWolf scenario due in part to their availability. Once I had successfully merged the transaction logs into the System hive, creating a 'new' System hive file, I used registry-diff.py and regdiff.pl to document the differences between the original and 'new' hives. As an example of differences between the two hives, while they were reported by the file system to be the same size, regdiff.pl found 2561 differences between the original and 'new' hives, many of which pertained to USB devices.
I should note here that this is a very interesting finding. Several years ago, I ran into a situation where I was comparing the System hive from a system to it's 'companion' in the RegBack folder (clearly, this goes back to when the hives in the config folder were being actively backed up). In that case, I found 9 USB devices listed in the System hive, and 13 devices listed in the backed up hive. I did a text search across both folders for one of the device names (one that was unique), and found an entry in one of the .log files, but at the time, there were no tools available for merging the transaction logs into the hive.
I then moved on to looking at differences in the hives via RegRipper. Again, for this initial set of testing, I was focusing on the System hive. As the AppCompatCache (or ShimCache) data is written to the System hive at shutdown, I did not expect to see significant differences between the two hives, and that expectation was borne out by running the appropriate plugin against both hives. However, the BAM and Mounted Devices plugins proved to be a bit more interesting. For example, the output of the mountdev.pl plugin run against the 'new' hive contained a drive signature for an F:\ volume that did not exist in the original hive. The bam.pl plugin showed two additional entries for the user with RID 1001 when run against the 'new' hive. Also, there was an entry for the Local Service account in the 'new' hive (again, via the bam.pl plugin) that was not in the original hive.
The del.pl plugin produced some interesting results. When I ran it against the original System hive, it pulled out a number of deleted keys and values; however, running it against the 'new' (i.e., merged) hive, I got nothing. Not one deleted key, not one deleted value.
So, what does all this mean?
I started this out wanting to simply see what tools and processes could be used to merge transaction logs into their hive file. I posted a tweet to that effect, and Maxim was the first (and only) person to respond (to that query). I do have additional testing to do, not just with this script, but with other tools that are available, as well. Again, what I'm looking at here is simply how to go about merging the transaction logs into a hive, and if successful, looking to see differences between the two in order to demonstrate the value of taking these steps.
Something to keep in mind is that Windows systems no longer appear to be populating (by default) the backup copies of the Registry hives within the config/RegBack folder. As such, merging transaction logs into the hive files prior to any parsing and analysis processes would seem to be a pretty valuable approach, if not simply provide more complete information. From that point, it's a matter of conducting analysis.
As far as a process goes, you'd likely want to either extract the appropriate files, or mount the image with the appropriate tool such that you could access the necessary directories. From there, you'd want to keep the original hive, and create a new version of the hive by merging the transaction logs. The new hive would ideally give you a more complete view of the hive, but the original hive would provide you with historical information, particularly regarding deleted content.
So, more to come...
Resources
I recently became aware of RegRippy, a Python-based alternative to RegRipper.
Interest in the Registry as a source of data for digital analysis and incident response has waxed and waned over the years. In the late '90s while I was performing vulnerability assessments, there was considerable utility in querying the Registry from live systems in order to determine the state and attack surface of those systems. We were looking for (and finding) active modems in systems, as well as extracting information about software versions, etc. To a large extent, this remains true today; there is a great deal of data available in the Registry to assist in developing an understanding of not only the state of the system at a given time, but also activity that occurred on the system.
In 2008, Jolanta Thomassen shared her dissertation regarding parsing Windows Registry hive file unallocated space; that is, retrieving deleted keys and values from unallocated space within the hive file itself. She also released regslack.exe, a command line tool for extracting deleted keys and values from hive files. Other tools have followed suit, providing similar functionality. Eventually, RegRipper included this functionality, as well.
In the past couple of years, attention has turned to Registry transaction logs, and incorporating data from those logs directly into hive files in order to achieve a more comprehensive and perhaps 'correct' view of the hive contents. As such, I wanted to determine what tools were available to merge transaction logs into a hive file, and from there, begin looking at the effect of the merge operation.
I installed Python 3.7 on a Windows 10 system. I opted for Python 3.7, as it is required for a tool I'm planning to test, Regipy. I installed yarp on that system, as well. This is the system I'm using as the platform for merging hives with their transaction logs.
I began testing by using yarp + registryFlush.py (thanks to Maxim) to merge the transaction logs (hive.log1, hive.log2) into a hive file, using hives from the LoneWolf scenario due in part to their availability. Once I had successfully merged the transaction logs into the System hive, creating a 'new' System hive file, I used registry-diff.py and regdiff.pl to document the differences between the original and 'new' hives. As an example of differences between the two hives, while they were reported by the file system to be the same size, regdiff.pl found 2561 differences between the original and 'new' hives, many of which pertained to USB devices.
I should note here that this is a very interesting finding. Several years ago, I ran into a situation where I was comparing the System hive from a system to it's 'companion' in the RegBack folder (clearly, this goes back to when the hives in the config folder were being actively backed up). In that case, I found 9 USB devices listed in the System hive, and 13 devices listed in the backed up hive. I did a text search across both folders for one of the device names (one that was unique), and found an entry in one of the .log files, but at the time, there were no tools available for merging the transaction logs into the hive.
I then moved on to looking at differences in the hives via RegRipper. Again, for this initial set of testing, I was focusing on the System hive. As the AppCompatCache (or ShimCache) data is written to the System hive at shutdown, I did not expect to see significant differences between the two hives, and that expectation was borne out by running the appropriate plugin against both hives. However, the BAM and Mounted Devices plugins proved to be a bit more interesting. For example, the output of the mountdev.pl plugin run against the 'new' hive contained a drive signature for an F:\ volume that did not exist in the original hive. The bam.pl plugin showed two additional entries for the user with RID 1001 when run against the 'new' hive. Also, there was an entry for the Local Service account in the 'new' hive (again, via the bam.pl plugin) that was not in the original hive.
The del.pl plugin produced some interesting results. When I ran it against the original System hive, it pulled out a number of deleted keys and values; however, running it against the 'new' (i.e., merged) hive, I got nothing. Not one deleted key, not one deleted value.
So, what does all this mean?
I started this out wanting to simply see what tools and processes could be used to merge transaction logs into their hive file. I posted a tweet to that effect, and Maxim was the first (and only) person to respond (to that query). I do have additional testing to do, not just with this script, but with other tools that are available, as well. Again, what I'm looking at here is simply how to go about merging the transaction logs into a hive, and if successful, looking to see differences between the two in order to demonstrate the value of taking these steps.
Something to keep in mind is that Windows systems no longer appear to be populating (by default) the backup copies of the Registry hives within the config/RegBack folder. As such, merging transaction logs into the hive files prior to any parsing and analysis processes would seem to be a pretty valuable approach, if not simply provide more complete information. From that point, it's a matter of conducting analysis.
As far as a process goes, you'd likely want to either extract the appropriate files, or mount the image with the appropriate tool such that you could access the necessary directories. From there, you'd want to keep the original hive, and create a new version of the hive by merging the transaction logs. The new hive would ideally give you a more complete view of the hive, but the original hive would provide you with historical information, particularly regarding deleted content.
So, more to come...
Resources
I recently became aware of RegRippy, a Python-based alternative to RegRipper.
Thursday, April 04, 2019
A Look Back...
I was chatting with someone recently with whom I'd crossed paths a bit more than 21 years ago, and throughout the time we chatted, I had this sense of nostalgia. What that led me to was the thought that when you've been in and around any industry for a while, it's interesting to take a step back and reflect on your path.
One example of nostalgia and looking back that comes about pretty regularly is when I meet former Marines. I've met many who were anywhere between toddlers and elementary school when I left active duty, and when we talk about what we did, I have to remember that my MOS (military occupational specialty) no longer exists. I was a Communications Officer, 2502, and the 25xx occfield is something a lot of current and former Marines have never heard of. So, nostalgia.
So, how does this relate to the cyberz? I first read The Cuckoo's Egg years ago, and thought, wow, what must it be like for Clifford and others involved to look back on what they did and the decisions they made? What was it like to revisit the events of that time with someone else who was there, reminiscing with, "...hey, do you remember when...?"
When I started grad school in June 1994, I walked by Gary Kildall's office for about 4 months before he passed. I never met the guy, and to be honest, would not have known who he was; I didn't find out until several years later. At the time, I was use MS-DOS and Windows 3.1, and had transitioned to Windows 3.11 for Workgroups just prior to heading west. I had never heard of CP/M, nor did I know much about operating systems at the time.
While I was in grad school, OS/2 was a thing. I went to Frye's Electronics in Sunnyvale to purchase a copy of OS/2 2.1, in part to install it on my desktop computer (with a 486DX microprocessor), but also to get the $15 off coupon sticker to apply to the purchase of OS/2 Warp 3.0. I'd had to install a second hard drive in the computer, in part due to the fact that drives were so small back then.
To get a sense of perspective of cost, I dropped $500 to upgrade to 16 MB (YES, with an "M") of RAM. When you installed the second hard drive (the ribbon cables only had two connectors), you had to be sure to set the jumpers correctly.
As part of my master's thesis, I wrote an SNMP polling utility in Java. This was just for the data collection phase of my thesis work; this was preceded by setting up a lab environment, using Windows 95 and Windows NT 3.51 servers, with two different network media (10-Base2, 10-BaseT) connected across two Cisco 2514 routers. One of the routers was connected to the campus area network (CAN) via a 10-Base5 vampire tap. I used simple video teleconferencing software to generate traffic across the network, and I used the SNMP polling application to collect traffic volume information over time. Once volumes of data had been collected, I did all of the statistical processing and image display via MatLab. To generate the traffic, I'd sit in front of one of the video cameras eating my lunch, and I'd sit in sight of the other camera. I'd wave my arm to generate frame updates from the second camera.
As an aside, the knowledge I developed of SNMP would serve me quite well, well after I left grad school and the military. Not only could I make recommendations to a network operations team regarding security (i.e., don't allow SNMP or even just UDP through the firewall, etc.) based on that knowledge, but I could also use what I had learned to develop information about systems during pen testing. Yes, you'd be surprised what was accessible from the Internet back then (SNMP , NetBIOS ), and even later.
All of the main terminals in my graduate program were SparcStations running Solaris (NetScape was the browser we used). I'd used TRS-80s in high school (programming PASCAL) and college (programming BASIC), and my family's first home computer was a Timex-Sinclair 1000; the second was an Epson QX-10. During that time (early '80s) I had also taken a course in BASIC programming on the Mac IIe. Somewhere along the line, a friend of mine had a Commodore 64, but I wasn't into playing computer games so I didn't spend much time with it. I never did touch an Amiga, but I did take two courses in grad school that involved using assembly language to program the Motorola 68000 microprocessor.
I was in grad school when SATAN was released (circa 1995). Shortly after it became available, I transitioned to the role of being the student rep from my academic department to the IT board. I sat through more than a few meetings where the IT admins from across campus argued about running the scanner on each other's networks. I never actually ran the tool; I was afraid to even download it. This was due to the fact that I'd downloaded a copy of a file called "crack.c", in order to learn a bit more about C programming (for a course I was taking at the time). I got in "trouble" with the senior sysadmin for the department because I had the file on my system. I argued that I had never compiled it (part of the course was the compilation process), never created an object file, never linked it, etc. None of that mattered to her. Things went really sideways when she'd claimed that I had violated THE security policy; knowing that I'd never signed such a thing, I asked to see the security policy. That's when she turned red and stormed off. Even though the two other admins were on my side, I was in the doghouse with the senior sysadmin. The fact was that it was another year before a new Admiral took of the school as superintendent and there was an actual written security policy. Even what that policy was available, downloading crack.c would not have been a violation.
As my active duty time ended and I was processing out of the military, I was attached to the Marine Detachment at the Army's Defense Language Institute (DLI). My role at the time was to connect the computer systems in the detachment to the Army's CAN, which was token ring. Around that time, the Commandant of the Marine Corps (Chuck Krulak) had stated that Marines were authorized to play "Marine DOOM", and the detachment had purchased 6 Gateway computer systems for that purpose. These systems were set up on a round credenza, connected via a 10-Base2 network, running IPX. At one point, a SSgt joined the unit and decided to make the room his office. To make more room, he had the Marines split the credenza in half and place the flat parts against opposite walls, with 3 stations on either side of the room. To do so, the computers needed to be disconnected. Once everything was in place, the computers were reconnected, and attempts were made to run the game, all of which failed. As the SSgt approached me for assistance, I didn't realize until much later in life that this was my first consulting gig. The SSgt informed me that the computer network had been reassembled EXACTLY as its previous state. I took a look at the system at the end of the network, and realized that the RS-232 connector had been attached directly to the NIC; looking around, I found the T connector and terminator sitting under the keyboard. No one saw me reconnect everything, but I told the SSgt to try again, and the network sprung to life. Within minutes, the Marines were back to playing the game.
In one of my first jobs out of the military, I was doing assessment work. During that time, I spent time in one of the Twin Towers in New York City, doing war dialing work. Our tools of choice were THCScan and ToneLoc. It was pretty exciting for two of us to sit in a cubicle, with the sound turned way down on the laptop we were using, listening to the responses we were getting from remote systems. Most of the time, the phone on the other end would be answered, and we'd hear "hello" come out of the speakers. It really got exciting when we could hear software dial a number, and a phone ring two cubicles down, and the person in that cubicle respond, their "hello" echoing in the speaker of the laptop. When the software dialed the cubicle on either side of us, we threw our jackets over the laptop to ensure that the residents didn't hear us. We got "caught" when the software dialed phones on opposite sides of the mainframe room; the mainframe admin wasn't happy about having to get up and walk across the room apparently, and he called the CIO to report the activity.
I later worked at Trident Data Systems (TDS), where I was doing vulnerability assessments and some light pen testing work. We used ISS's Internet Scanner for our vulnerability assessment work, and while I was there, I began developing a tool we called "NTCAT" to replace the use of ISS's tool. We were getting a good bit of spurious findings from Internet Scanner, most notably with respect to the Windows "AutoAdminLogon" setting, and were learning more about what Internet Scanner was doing. That is, what data it was collecting, and how it was making it's determinations. And this is where we were running into issues, which we were addressing using this new tool. When I wasn't doing assessment work or writing reports, I was connected to the lab, developing and testing NTCAT. This is also where I really started to see the value in graphic representations of data, albeit in a very simple format (i.e., red for bad, green for good). I also began to see, up close, the value of processing data in different ways; getting a quick SWAG while you're on-site, versus a deeper inspection of the data when you had time. Taking it a step further, we were finding out new things and developing new tools to process the data, making things more useful and valuable to the analyst, and subsequently to the customer.
One of the things I pitched to my manager at the time was that once we collected all of this data from the customer, we had it. We'd need to address it legally, through our contracts of course, but we could keep the actual data in a secure manner (encrypted and/or stored offline on a CD), and as we learned new things, run this new processing across the retained data. It's interesting to look back on those discussions, and then look at what we do now with respect to MSS and EDR, particularly regarding data retention times. I've seen some of the same questions and issues from back then in today's world; few EDR tools provide a retrospective look at what happened on a system prior to the installation of the agent or sensor, and as such, IR teams have to use other means to collect this historical data. Things brings up questions of "what do you collect?", "how do you collect it?", as well as "how long can you keep the data?" Times have changed, technology has changed, but we still see some of the same issues.
During my time with TDS, some members of our team were working a pretty big pen test, and had run up against an Internet-connected PBX. They really wanted to get access to this PBX, and worked hard at doing so. At one point, several members of the team went to the loading dock on the first floor of our building for a smoke break, and were talking about what they'd run into. On the first floor of our building was an engineering firm, one that specialized (as it turns out) in that PBX. While our guys were out on their break, one of the engineers was just finishing up a break of his own when he overheard what they were discussing. He walked over and offered them the 15 character password that was hard-coded into the PBX.
In another job, I worked (indirectly) for a security director who'd appeared by name in the book TakeDown. Several years later, while I was attending a conference in Seattle, I saw Kevin Mitnick. I didn't talk to him...he was surrounded by a mob, and I don't do mobs. Also, I wasn't really sure what I'd say.
As time passes, I may write some additional posts, looking back on the things I've seen, as well as folks I've engaged with. We'll see...
One example of nostalgia and looking back that comes about pretty regularly is when I meet former Marines. I've met many who were anywhere between toddlers and elementary school when I left active duty, and when we talk about what we did, I have to remember that my MOS (military occupational specialty) no longer exists. I was a Communications Officer, 2502, and the 25xx occfield is something a lot of current and former Marines have never heard of. So, nostalgia.
So, how does this relate to the cyberz? I first read The Cuckoo's Egg years ago, and thought, wow, what must it be like for Clifford and others involved to look back on what they did and the decisions they made? What was it like to revisit the events of that time with someone else who was there, reminiscing with, "...hey, do you remember when...?"
When I started grad school in June 1994, I walked by Gary Kildall's office for about 4 months before he passed. I never met the guy, and to be honest, would not have known who he was; I didn't find out until several years later. At the time, I was use MS-DOS and Windows 3.1, and had transitioned to Windows 3.11 for Workgroups just prior to heading west. I had never heard of CP/M, nor did I know much about operating systems at the time.
While I was in grad school, OS/2 was a thing. I went to Frye's Electronics in Sunnyvale to purchase a copy of OS/2 2.1, in part to install it on my desktop computer (with a 486DX microprocessor), but also to get the $15 off coupon sticker to apply to the purchase of OS/2 Warp 3.0. I'd had to install a second hard drive in the computer, in part due to the fact that drives were so small back then. To get a sense of perspective of cost, I dropped $500 to upgrade to 16 MB (YES, with an "M") of RAM. When you installed the second hard drive (the ribbon cables only had two connectors), you had to be sure to set the jumpers correctly.
As part of my master's thesis, I wrote an SNMP polling utility in Java. This was just for the data collection phase of my thesis work; this was preceded by setting up a lab environment, using Windows 95 and Windows NT 3.51 servers, with two different network media (10-Base2, 10-BaseT) connected across two Cisco 2514 routers. One of the routers was connected to the campus area network (CAN) via a 10-Base5 vampire tap. I used simple video teleconferencing software to generate traffic across the network, and I used the SNMP polling application to collect traffic volume information over time. Once volumes of data had been collected, I did all of the statistical processing and image display via MatLab. To generate the traffic, I'd sit in front of one of the video cameras eating my lunch, and I'd sit in sight of the other camera. I'd wave my arm to generate frame updates from the second camera.
As an aside, the knowledge I developed of SNMP would serve me quite well, well after I left grad school and the military. Not only could I make recommendations to a network operations team regarding security (i.e., don't allow SNMP or even just UDP through the firewall, etc.) based on that knowledge, but I could also use what I had learned to develop information about systems during pen testing. Yes, you'd be surprised what was accessible from the Internet back then (
All of the main terminals in my graduate program were SparcStations running Solaris (NetScape was the browser we used). I'd used TRS-80s in high school (programming PASCAL) and college (programming BASIC), and my family's first home computer was a Timex-Sinclair 1000; the second was an Epson QX-10. During that time (early '80s) I had also taken a course in BASIC programming on the Mac IIe. Somewhere along the line, a friend of mine had a Commodore 64, but I wasn't into playing computer games so I didn't spend much time with it. I never did touch an Amiga, but I did take two courses in grad school that involved using assembly language to program the Motorola 68000 microprocessor.
I was in grad school when SATAN was released (circa 1995). Shortly after it became available, I transitioned to the role of being the student rep from my academic department to the IT board. I sat through more than a few meetings where the IT admins from across campus argued about running the scanner on each other's networks. I never actually ran the tool; I was afraid to even download it. This was due to the fact that I'd downloaded a copy of a file called "crack.c", in order to learn a bit more about C programming (for a course I was taking at the time). I got in "trouble" with the senior sysadmin for the department because I had the file on my system. I argued that I had never compiled it (part of the course was the compilation process), never created an object file, never linked it, etc. None of that mattered to her. Things went really sideways when she'd claimed that I had violated THE security policy; knowing that I'd never signed such a thing, I asked to see the security policy. That's when she turned red and stormed off. Even though the two other admins were on my side, I was in the doghouse with the senior sysadmin. The fact was that it was another year before a new Admiral took of the school as superintendent and there was an actual written security policy. Even what that policy was available, downloading crack.c would not have been a violation.
As my active duty time ended and I was processing out of the military, I was attached to the Marine Detachment at the Army's Defense Language Institute (DLI). My role at the time was to connect the computer systems in the detachment to the Army's CAN, which was token ring. Around that time, the Commandant of the Marine Corps (Chuck Krulak) had stated that Marines were authorized to play "Marine DOOM", and the detachment had purchased 6 Gateway computer systems for that purpose. These systems were set up on a round credenza, connected via a 10-Base2 network, running IPX. At one point, a SSgt joined the unit and decided to make the room his office. To make more room, he had the Marines split the credenza in half and place the flat parts against opposite walls, with 3 stations on either side of the room. To do so, the computers needed to be disconnected. Once everything was in place, the computers were reconnected, and attempts were made to run the game, all of which failed. As the SSgt approached me for assistance, I didn't realize until much later in life that this was my first consulting gig. The SSgt informed me that the computer network had been reassembled EXACTLY as its previous state. I took a look at the system at the end of the network, and realized that the RS-232 connector had been attached directly to the NIC; looking around, I found the T connector and terminator sitting under the keyboard. No one saw me reconnect everything, but I told the SSgt to try again, and the network sprung to life. Within minutes, the Marines were back to playing the game. In one of my first jobs out of the military, I was doing assessment work. During that time, I spent time in one of the Twin Towers in New York City, doing war dialing work. Our tools of choice were THCScan and ToneLoc. It was pretty exciting for two of us to sit in a cubicle, with the sound turned way down on the laptop we were using, listening to the responses we were getting from remote systems. Most of the time, the phone on the other end would be answered, and we'd hear "hello" come out of the speakers. It really got exciting when we could hear software dial a number, and a phone ring two cubicles down, and the person in that cubicle respond, their "hello" echoing in the speaker of the laptop. When the software dialed the cubicle on either side of us, we threw our jackets over the laptop to ensure that the residents didn't hear us. We got "caught" when the software dialed phones on opposite sides of the mainframe room; the mainframe admin wasn't happy about having to get up and walk across the room apparently, and he called the CIO to report the activity.
I later worked at Trident Data Systems (TDS), where I was doing vulnerability assessments and some light pen testing work. We used ISS's Internet Scanner for our vulnerability assessment work, and while I was there, I began developing a tool we called "NTCAT" to replace the use of ISS's tool. We were getting a good bit of spurious findings from Internet Scanner, most notably with respect to the Windows "AutoAdminLogon" setting, and were learning more about what Internet Scanner was doing. That is, what data it was collecting, and how it was making it's determinations. And this is where we were running into issues, which we were addressing using this new tool. When I wasn't doing assessment work or writing reports, I was connected to the lab, developing and testing NTCAT. This is also where I really started to see the value in graphic representations of data, albeit in a very simple format (i.e., red for bad, green for good). I also began to see, up close, the value of processing data in different ways; getting a quick SWAG while you're on-site, versus a deeper inspection of the data when you had time. Taking it a step further, we were finding out new things and developing new tools to process the data, making things more useful and valuable to the analyst, and subsequently to the customer.
One of the things I pitched to my manager at the time was that once we collected all of this data from the customer, we had it. We'd need to address it legally, through our contracts of course, but we could keep the actual data in a secure manner (encrypted and/or stored offline on a CD), and as we learned new things, run this new processing across the retained data. It's interesting to look back on those discussions, and then look at what we do now with respect to MSS and EDR, particularly regarding data retention times. I've seen some of the same questions and issues from back then in today's world; few EDR tools provide a retrospective look at what happened on a system prior to the installation of the agent or sensor, and as such, IR teams have to use other means to collect this historical data. Things brings up questions of "what do you collect?", "how do you collect it?", as well as "how long can you keep the data?" Times have changed, technology has changed, but we still see some of the same issues.
During my time with TDS, some members of our team were working a pretty big pen test, and had run up against an Internet-connected PBX. They really wanted to get access to this PBX, and worked hard at doing so. At one point, several members of the team went to the loading dock on the first floor of our building for a smoke break, and were talking about what they'd run into. On the first floor of our building was an engineering firm, one that specialized (as it turns out) in that PBX. While our guys were out on their break, one of the engineers was just finishing up a break of his own when he overheard what they were discussing. He walked over and offered them the 15 character password that was hard-coded into the PBX.
In another job, I worked (indirectly) for a security director who'd appeared by name in the book TakeDown. Several years later, while I was attending a conference in Seattle, I saw Kevin Mitnick. I didn't talk to him...he was surrounded by a mob, and I don't do mobs. Also, I wasn't really sure what I'd say.
As time passes, I may write some additional posts, looking back on the things I've seen, as well as folks I've engaged with. We'll see...