Imposter Syndrome

Imposter Syndrome. 

This is something many of us have experienced to one degree or another, at various times. Many have experienced, some have overcome it, others may not be able to and wonder why.

HealthLine tells us, "Imposter feelings represent a conflict between your own self-perception and the way others perceive you." I would modify that slight to, "...the way we believe others perceive us." Imposter syndrome is something internalized, and has very little to do with the outside world.

I wanted to take the opportunity to share with you, the reader, what I've learned over the years about what's really happening in the world when we're having those feelings of imposter syndrome.

Perception: I don't want to present at a conference, or ask a question at a conference, because everyone knows more than I do, and will ask questions I don't know the answer to.

Reality: Have you ever stood in the back of the room at a conference and just...watched? Most people you see aren't even listening the presentation. Some are on social media (Twitter, Discord, Slack, etc.), and some are on their phones.

When someone asks a question about a presentation, calm yourself so instead of the ringing of fear in your ears, you actually hear the question. Does the question have anything to do with the presentation? I ask, because in my experience, I've gotten a few questions following a presentation, and some of those questions have been way off topic. Looking back, what seems to happen is that someone hears a term that they're familiar with, or something that strikes a chord, and they take it way out in left field. 

My point is simply that, at conferences, the simple reality a lot of people aren't really paying attention. This can be very important, even critical, when the fear behind imposter syndrome is that you're under a microscope.

I've found that I've had to engage with people directly to get a reaction. When I worked for CrowdStrike, I was involved with a number of public speaking engagements, and for the last 5 or so months, the events were about 3 1/2 hrs long. Across the board, almost no one actually asked questions. For those who did, it took time for them to do so; some wouldn't ask questions until the 2 1/2 or 3 hr mark. Some would ask questions, but only after I'd goaded someone else into asking a question.

Perception: I could never write a book or blog post, no matter how prepared I am, because the moment it's published it'll torn apart, and I'll be eviscerated and exposed as the fraud that I am.

Reality: Most people don't actually read books and blog posts. My experience in writing books is that some will purchase the books, but few are willing to actually read the books, and even fewer will write reviews. It's the same with blog posts...you put work into the topic and content, and if you don't share a link to the post on social media, very few actually see the post. If you do share it on social media, you may get "likes" and retweets, but no one actually comments, neither on the tweet nor the post.

My overall point is that imposter syndrome is an internal dialog that prevents us from being our best and reaching our potential. We can overcome it by replacing it with a dialog that is more based on reality, on what actually happens, in the real world. 

My perspective on this is based on experience. In 2005, Cory Altheide and I published a paper discussing the artifacts associated with the use of USB devices on Windows systems (at the time, primarily Windows XP). After the paper was published, I spoke on the topic at a conference in my area, one primarily attended by law enforcement, and got a no questions. Several years later, I was presenting at another conference, and had mistakenly opened the wrong version of presentation; about halfway through, there was a slide with three bullets that all said, "blah blah blah". At the end of the presentation, three attendees congratulated me on a "great presentation". 

Distros and RegRipper

Over the years, every now and then I've taken a look around to try to see where RegRipper is used. I noticed early on that it's included in several security-oriented Linux distros. So, I took the opportunity to compile some of the links I'd found, and I then extended those a bit with some Googling. I will admit, I was a little surprised to see how, over time, how far RegRipper has gone, from a "here, look at this" perspective.

Not all of the below links are current, some are several years old. As such, they are not the latest and greatest; however, they may still apply and they may still be useful/valuable.

RegRipper on Linux (Distros) 
Kali, Kali GitLab 
SANS SIFT 
CAINE  
Installing RegRipper on Linux 
Install RRv2.8 on Ubuntu 
CentOS RegRipper package 
Arch Linux  
RegRipper Docker Image 
Install RegRipper via Chocolatey 

Forensic Suites
Something I've always been curious about is why the value of RegRipper being incorporated into and maintained through a forensic analysis suite isn't more of "a thing", but that fact doesn't prevent RegRipper and tools like it from being extremely valuable in a wide range of analyses.

RegRipper is accessible via Autopsy 
OSForensics Tutorial 
Launching RegRipper via OpenText/EnCase

When I worked for Nuix, I worked with Dan Berry's developers to build extensions for Yara and RegRipper (Nuix RegRipper Github) giving users of the Workstation product access to these open source tools in order to extend their capabilities. While both extensions really do a great deal to leverage the open source tool for use by the investigator, I was especially happy to see how the RegRipper extension turned out. The extension would automatically locate hive files, regardless of the Windows version (including the AmCache.hve file), automatically run the appropriate plugins against the hive, and then automatically incorporate the RegRipper output into the case file. In this way, the results were automatically incorporated into any searches the investigator would run across the case. During testing, we added images of Windows XP, Windows 2008 and Windows 7 systems to a case file, and the extension ran flawlessly.

It seems that RegRipper (as well as other tools) have been incorporated into KAPE, particularly into the Registry and timelining modules. This means that whether you're using KAPE freely, or you're using the enterprise license, you're likely using RegRipper and other tools I've written, to some extend.

I look back on this section, and I really have to wonder why, given how I've extended RegRipper since last year, why there is no desire to incorporate RegRipper into (and maintain it through) a commercial forensic analysis suite. Seriously.

Presentations/Courses
I've covered RegRipper as a topic in this blog, as well as in my books. I've also given presentations discussing the use of RegRipper, as have others. Here are just a few links:

OSDFCon 2020 - Effectively Using RegRipper (video)
PluralSight Course 

RegRipper in Academia
Okay, I don't have a lot of links here, but that's because there were just so many. I typed "site:edu RegRipper" into a Google search and got a LOT of hits back; rather than listing the links, I'm just going to give you the search I ran and let you do with it what you will. Interestingly, the first link in the returned search results was from my alma mater, the Naval Postgraduate School; specifically, Jason Shaver's thesis from 2015.

On Writing DFIR Books, pt II

Part I of this series kicked things off for us, and honestly I have no idea how long this series will be...I'm just writing the posts without a specific plan or outline for the series. In this case, I opted to take an organic approach, and wanted to see where it would go.

Content
Okay, so you have an idea for a book, but about...what? You may have a title or general idea, but what's the actual content you intend to write about? Is it more than a couple of paragraphs; can you actually create several solid chapters without having to use a lot of filler and fluff? Back when I was actively writing books, this was something on the forefront of my mind, not only because I was writing books, but later I got a question or two from others along these lines.

In short, I write about stuff I know, or stuff I've done. Not everything I've written about came from work; a good bit of what I've written about came from research I'd done, either following up on something I'd seen or based on an idea I had. For example, during one period not long after we'd transitioned to Windows 7, I wanted to follow up on creating, using and detection NTFS alternate data streams (ADSs), and I'd found some content that provided alternate means for launching executables written to ADSs. I wanted to see if ADSs were impacted by scripting languages, and I added the results of what I found to the book content.

A number of years ago, I had access to an MSDN account, and that access was used to install operating systems and applications, and then to "see" the toolmarks or artifact constellations left behind by various activities, particularly identifying the impact of different applications and configurations. Unfortunately, the MS employee who'd provided me with the account moved on, and the license eventually expired, which was unfortunate, as I was able to see the impact of different activities not only with respect to the operating system, but also with respect to different application suites.

Sources of content can include (and in my case, have included) just about anything; blog posts, blog post drafts, presentation materials, the results of ad hoc testing, etc. 

Outline
Something I've learned over the years is that the easiest way to get started writing book content is to start with an outline. The outline allows (or forces) you to organize your thoughts into a structured format, and allows you to see the flow of the book from a high level. This also allows you to start adding flesh to the bones, if you will, seeing where there structure is and adding that content we talked about. It also allows you see where there is value in consistency, in doing the same or similar writing (or testing) in different locations in the book (i.e., "chapters") in order to be as complete as possible. A well-structured outline will allow you to see gaps.

Further, if you have a well-structured outline that you're working from, the book almost writes itself. 

Tips for DFIR Analysts, pt II

On the heels of my first post with this subject, I thought I'd continue adding tips as they came to mind...

I've been engaged with EDR frameworks for some time now. I first became aware of Carbon Black before it was "version 1.0", and before "carbonblack.com" existed. Since then, I've worked for several organizations that developed EDR frameworks (Secureworks, Nuix, CrowdStrike, Digital Guardian), and others that made use of frameworks created by others. I've also been very happy to see the development and growth of Sysmon, and used it in my own testing.

One thing I've been acutely aware of is the visibility afforded by EDR frameworks, as well as the extent of that visibility. This is not a knock against these tools...not at all. EDR frameworks and tools are incredibly powerful, but they are not a panacea. For example, most (I say "most" because I haven't seen all EDR tools) track process creation telemetry, but not process exit codes. As such, it can be detrimental to assume that because the EDR telemetry shows a process being created, that the process successfully executed and completed. Some EDR tools can block processes based on specific criteria...I saw a lot of this at CrowdStrike, and shared more than a few examples in public speaking events. 

In other instances, the process may have failed to execute all together. For example, it may be been detected by AV shortly after it started executing. I've actually been caught by Windows Defender; prior to initiating testing, I'll disable real-time monitoring, but leave Defender untouched other than that. I'll then go about my testing, and then at some point in the future (sometimes around 4 hrs), I'll be continuing my testing, only to have Windows Defender recover (real-time monitoring is automatically re-enabled), and what I was working on was quarantined.

Did the executable throw an error shortly after launch, with a WER record, or an Application PopUp message, being generated in the Windows Event Log? 

Were you able to validate the impact of the executable or command? For example, if the threat actor was seen running a command that would impact the Windows Registry and result in Windows Event Log records being generated, were those artifacts validated and observed on the system?

The overall point is that while EDR frameworks provide a tremendous amount of visibility, but they do not provide ALL visibility.

What's Old Is New Again
Something a bit more on the deeper forensicy-technical side...

I ran across a couple of things recently that reminded me that what I found fascinating and dug into deeply twenty years ago may not be that well known today. For example, last year, Windows Defender/MpCmdRun.exe was identified as an LOLBin, and that was accompanied by the fact that files could be written to alternate data streams (ADSs). 

I also ran across something "new" regarding the "zone.identifier" ADSs associated with downloads (Edge, Chrome); specifically, the ZoneID ADSs are no longer 26 or 29 bytes in size, now they're much larger because they include more information, including HostURL and RefererURL entries, as illustrated in fig 1.

Fig 1: ZoneID ADS contents

This clearly provides some useful information regarding the source of the file. The ADS illustrated in fig 1 is from a PDF document I'd downloaded to my desktop via Chrome; as such, it wasn't found in my Downloads folder (a dead giveaway for downloads...), but the existence and contents of the ADS clearly demonstrate that the file was indeed downloaded to the system.

Now, we'll just need to see if other means for downloading files...BITS jobs, LOLBins, etc...produce similar results.

On Writing DFIR Books, pt I

During my time in the industry, I've authored 9 books under three imprints, and co-authored a tenth.

There, I said it. The first step in addressing a problem is admitting you have one. ;-)

Seriously, though, this is simply to say that I have some experience, nothing more. During the latter part of my book writing experience, I saw others who wanted to do the same thing, but ran into a variety of roadblocks, roadblocks I'd long since navigated. As a result, I tried to work with the publisher to create a non-paid liaison role that would help new authors overcome many of those issues, so that a greater portfolio of quality books became available to the industry. By the time I convinced one editor of the viability and benefit of such a program, they had decided to leave their profession, and I had to start all over again, quite literally from the very beginning.

Authoring a book has an interesting effect, in that it tends to create a myth around the author, one that they're not aware of at first. It starts with someone saying, "...you wrote a book, so you must X..". Let "X" be just about anything. 

"Of course you're good at spelling, you wrote a book." Myth.

"You must be rolling in money, you wrote a book." Myth.

All of these things are assumptions, myths built up only to serve as obstacles. The simple fact is that if you feel like you want to write a book, you can. There's nothing stopping you, except...well...you. To that end, I thought I'd write a series of posts that dispel the myths and provide background and a foundation for those considering the possibility of writing a book.

There are a number of different routes to writing books. Richard Bejtlich has authored or co-authored a number of books, the most recent of which have been reprints of his Tao Security blog posts. Emma Bostian tweeted about her success with "side projects", the majority of which consisted of authoring and marketing her ebooks.

The Why
So, why write books at all? In an email that Gen Jim Mattis (ret) authored that later went viral, he stated:

By reading, you learn through others’ experiences, generally a better way to do business, especially in our line of work where the consequences of incompetence are so final for young men.

Yes, Gen Mattis was referring to warfighting, but the principle equally well for DFIR work. In his book, "Call Sign Chaos", Mattis further stated:

...your personal experiences alone aren't broad enough to sustain you.

This is equally true in DFIR work; after all, what is "analysis" but the analyst applying the sum total of their knowledge and experience to the amassed data? As such, the reason to write books is that no one of us knows everything, and we all have vastly different experiences. Even working with another analyst on the same incident response engagement, I've found that we've had different experiences due in large part to our different perspectives.

The simple fact is that these different perspectives and experiences can be profoundly valuable, but only if they're shared. A while back, I engaged in an analysis exercise where I downloaded an image and memory sample provided online, and conducted analysis based on a set of goals I'd defined. During this exercise, I extracted significantly different information from the memory sample using two different tools; I used Volatility to extract information about netstat-style network connections, and I also used bulk_extractor to retrieve a PCAP file, built from the remnants of actual packets extracted from memory. I shared what I'd done and found with one other analyst, and to be honest, I don't know if they ever had the chance to try it, or remembered to do so the next time the opportunity arose. Since then, I have encountered more than a few analysts to whom this approach never occurred, and while they haven't always seen significant value from the effort, it remains a part of their toolkit. I also included the approach in "Investigating Windows Systems", where it is available, and I assume more than one analyst has read it and taken note.

Speaking for myself, I began writing books because I couldn't find what I wanted on the shelves of the bookstore. It's as simple as that. I'd see a title with the words "Windows" and "forensics" in the title, and I'd open it, only to find that the dive did not go deep enough for me. At the time, many of the books related to Windows forensics were written by those who'd "grown up" using Linux, and this was clearly borne out in the approach taken, as well as the coverage, in the books.

The First Step
The first step to successfully writing a book is to read. That's right...read. By reading, we get to experience a greater range of authorship, see and decide what we enjoy reading (and what we pass on), and then perhaps use that in our own writing.

My first book was "Windows Forensics and Incident Recovery", published in 2004. The format and structure of chapter 6 of that book is based on a book I read while I was on active duty in the military titled "The Defense of Duffer's Drift". I liked the way that the author presented the material so much that I thought it would be a useful model for sharing my own story. As it turned out, that was the one chapter that my soon-to-be wife actually read completely, as it is the only chapter that isn't completely "technical".

With that, thoughts, comments and questions are, as always, welcome. Keep an eye open for more to come!