Book Review: Effective Threat Investigation for SOC Analysts

I recently had an opportunity to review the book, Effective Threat Investigation for SOC Analysts, by
Mostafa Yahia. 

Before I start off with my review of this book, I wanted to share a little bit about my background and perspective. I started my grown-up "career" in 1989 after completing college. I had a "technical" (at the time) role in the military, as a Communications Officer. After earning an MSEE degree, I left active duty and started consulting in the private sector...this is to say that I did not stay with government work. I started off by leading teams conducting vulnerability assessments, and then over 22 yrs ago, moved over to DFIR work, exclusively. Since then, I've done FTE and consulting work, I ran a SOC, and I've written 9 books of my own, all on the topic of digital forensic analysis of Windows systems. Hopefully, this will give you some idea of my "aperture".

My primary focus during my review of Mostafa's book was on parts 1, 2, and 4, as based on my experience I am more familiar with the material covered in part 2. My review covers about 7 of the 15 listed chapters, not because I didn't read them, but because I wanted to focus more on areas where I could best contribute.

That being said, this book serves as a good introduction to materials and general information for those looking to transition to being a SOC analyst, or those newly-minted SOC analysts, quite literally in their first month or so. The book addresses some of the data sources that a SOC analyst might expect to encounter, although in my experience, this may not always be the case. However, the familiarization is there, with Mostafa demonstrating examples of each data source, and how to use them, addressed in the book.

I would hesitate to use the term "effective" in the title of the book, as most of what's provided in the text is introductory material, and should be considered intended for familiarization, as it does not lay the groundwork for what I would consider "effective" investigations.

Some recommendations, specifically regarding the book:

Be consistent in terminology; refer to the Security Event Log as the "Security Event Log", rather than as "Security log file", the "security event log file", etc. 

Be clear about what settings are required for various records and fields within those records to be populated. 

Take more care in the accuracy of statements. For example, figure 6.5 is captioned "PSReadline file content", but the name of the file is "consolehost_history.txt". Figure 7.1 illustrates that Run key found within the Software hive, but the following text of the book incorrectly states that the malware value is "executed upon user login".

Some recommendations, in general:

Windows event IDs are not unique; as such, records should be referred to by their source/ID pair, rather than solely by event ID. While the Microsoft-Windows-Security-Auditing/4624 event refers to a successful login, the EventSystem/4624 event refers to something completely different. 

What's logged to the Security Event Log is heavily dependent upon the audit configuration, which is accessible via Group Policies, the Local Security Editor, or auditpol.exe. As such, many of the Security Event Log event IDs described may not be available on the systems being examined. Just this year (2023), I've examined systems where successful login events were not recorded.

Analysts should not view artifacts (in this case, Windows Event Log records, Run key values, etc.) in isolation. Instead, viewing artifacts or data sources together, based on time stamps (i.e., timelining) from the beginning of an investigation, rather than manually developing a timeline in a spreadsheet at the end of an investigation, is a much more efficient, comprehensive, and effective process.

Multiple data sources, including multiple Windows Event Logs, can provide insight into various activities, such as user logins, etc. Do not focus on a single artifact, such as an event ID, but instead look to develop artifact constellations. For example, with respect to user logins, looking to the Security Event Log can prove fruitful, as can the LocalSessionManager/Operational, User Profile Service, Shell-Core/Operational, and TaskScheduler Event Logs. Developing a timeline at the beginning of the investigation is a great process for developing, observing, and documenting those constellations.