OS X Incident Response

Scripting and Analysis

Jaron Bradley

• Publisher: Syngress
• Year: 2016
• Print ISBN: 9780128044568
• eBook ISBN: 9780128045039
• Topic: Computer Science
• Subtopic: Cyber Security
• Index: Computer Science

OS X Incident Response: Scripting and Analysis is written for analysts who are looking to expand their understanding of a lesser-known operating system. By mastering the forensic artifacts of OS X, analysts will set themselves apart by acquiring an up-and-coming skillset. Digital forensics is a critical art and science. While forensics is commonly thought of as a function of a legal investigation, the same tactics and techniques used for those investigations are also important in a response to an incident. Digital evidence is not only critical in the course of investigating many crimes but businesses are recognizing the importance of having skilled forensic investigators on staff in the case of policy violations. Perhaps more importantly, though, businesses are seeing enormous impact from malware outbreaks as well as data breaches. The skills of a forensic investigator are critical to determine the source of the attack as well as the impact. While there is a lot of focus on Windows because it is the predominant desktop operating system, there are currently very few resources available for forensic investigators on how to investigate attacks, gather evidence and respond to incidents involving OS X. The number of Macs on enterprise networks is rapidly increasing, especially with the growing prevalence of BYOD, including iPads and iPhones. Author Jaron Bradley covers a wide variety of topics, including both the collection and analysis of the forensic pieces found on the OS. Instead of using expensive commercial tools that clone the hard drive, you will learn how to write your own Python and bash-based response scripts. These scripts and methodologies can be used to collect and analyze volatile data immediately. For online source codes, please visit: https://github.com/jbradley89/osx_incident_response_scripting_and_analysis - Focuses exclusively on OS X attacks, incident response, and forensics - Provides the technical details of OS X so you can find artifacts that might be missed using automated tools - Describes how to write your own Python and bash-based response scripts, which can be used to collect and analyze volatile data immediately - Covers OS X incident response in complete technical detail, including file system, system startup and scheduling, password dumping, memory, volatile data, logs, browser history, and exfiltration

Chapter 1

Introduction

Abstract

This chapter begins by discussing why we will see OS X targeted more in the upcoming years as it gains popularity. We then dive into what defines the incident response process. It then goes on to discuss what the Cyber Kill Chain is as well as how it can apply to the OS X operating system. This chapter finishes by describing the scenario that is used for the analysis sections throughout the rest of the chapters.

Keywords

OS X Kill Chain

Cyber Kill Chain

OS X Incident Response

Is there really a threat to OS X?

In 1986 a man named Clifford Stoll was appointed as a systems manager at Berkeley University and tasked with finding the source of an odd accounting error in their system usage logs. You see, back then each researcher had to pay for the time they spent on the internet while at the University. The timer would start when they logged in and stop when they logged out. Stoll noticed that a user named Hunter was constantly leaving a small balance without paying it. When he searched for Hunter in the school records, he discovered nobody by that name attended Berkeley. Refusing to let this error go unnoticed, Stoll began investigating what was reasonably suspected to be a software glitch. His persistence and analytical skills eventually led to the discovery of a German adversary who was obtaining and selling sensitive US military data to Russia’s Committee for State Security, the KGB. The German, a man named Markus Hess, was using guest credentials to move across systems in the Berkeley environment (as well as other environments) and stealing emails, research, and other valuable data that he encountered. Root permissions were easily acquired from the guest account thanks to a privilege escalation exploit in the GNU Emacs editor.

Stoll documented this intrusion and his findings in his book “The Cuckoo’s Egg,” the tale of the first recorded incident in cyber espionage history. AT&T’s Unix platform was one of the most popular operating systems at the time of this incident. Microsoft had released DOS about 5 years earlier and Mac OS had only existed for 2 years. Berkeley University’s labs were used extensively for research and their systems were Unix based.

So why is this story relevant? The Berkley intrusion showed us that the operating systems targeted in intrusion campaigns were not based on operating system type, but rather their popularity. Adversaries have always adapted their attack methods as needed, but due to the rise of Microsoft’s market share in later years, it made sense that attackers focused the majority of their efforts on studying and exploiting Windows systems. Now times are changing. Although Windows continues to dominate the majority of workstations, OS X is making a rise in workplace environments. CEOs are swapping out their old Windows machines for sleek new MacBooks. Companies are offering traveling employees the lightweight MacBook Air. iPads, iPhones, and Apple TVs are being used in the work environment for convenient sharing and conference meetings. Start-ups, web design, and marketing companies are trying to create Mac only based environments. Apple devices are on the rise inside major corporations and although OS X malware is seen infrequently inside targeted intrusions, there are signs that show we will be seeing more of it in the future. Incident responders and security analysts spend years learning the internal operations of the Windows operating system. How will responders perform analysis on a fundamentally different system? To continue effectively fighting the adversary we need to stay one step ahead of them. Working in the incident response field you will find that although vulnerabilities, exploits, and technology change, many adversary tactics and goals stay the same. This is true even across different operating systems.

What is OS X

As anyone reading this book probably knows, OS X is the operating system developed by Apple Inc. The X in OS X stands for “ten” as this is the tenth edition of the operating system. As you can imagine, Apple went through many different stages and changes to get to this point. Before OS X, the operating system was referred to as Mac OS. Before Mac OS it was simply referred to as “System Software.” System Software 1.0 (or just System 1.0), released in 1984, was in fact the first operating system to use a Graphical User Interface (GUI) where the user had both mouse and keyboard to navigate the system. Before this, all computers were command line based. This innovation changed personal computing as we know it. Using a personal computer without a GUI is unheard of today. System Software evolved rapidly releasing version two, three, and four based on individual software package changes. Eventually, Apple changed to bundled updates. The first of these was System Software Five released in 1987. It wasn’t until halfway through System 7 that Apple began advertising the Operating System as Mac OS. As time continued major updates were added. Multithreading, the HFS1 file system, multiuser capabilities, Applescript, a nanokernel, 64-bit support, and a massive amount of other changes brought the operating system to where it is today. In 2001 Apple released OS X and starting with OS X Mountain Lion (10.6) dropped the name Mac OS entirely. Modern day OS X operating systems even meet the necessary requirements set by The Open Group to be registered as a Unix Product Standard. As a company, Apple’s success story is a bit of a roller coaster that goes from being a world innovation leader, all the way down to accepting $150 million from Microsoft to avoid bankruptcy (1997) and finally bouncing back stronger than ever.

The XNU Kernel

The Kernel running on OS X has always been a fairly unique one. Before we get into it, make note that to understand Incident Response you do not need to have a complete understanding on the deepest workings of the kernel. Of course, any additional understanding you may have will always help under the right circumstances. Anytime you hear the term XNU used with Apple, this refers to the Kernel. The XNU Kernel is a hybrid of the Mach microkernel and the BSD Kernel. The idea was to build a kernel that brings the best of both worlds together. The BSD interface is used to handle the BSD system calls as well as a large number of other BSD features like ownership, permissions, networking, and the virtual file system. The Mach portion of the kernel handles many tasks as well. Among these tasks are the scheduler, virtual memory-management, and Mach inter-process communication (IPC). Mach ports can be used for IPC allowing processes to communicate with each other or with the kernel. For example, if a user browses to a website using Google Chrome, the DNS lookup may come directly from Chrome itself. Alternatively, an application developer may choose to use Apple APIs to perform DNS lookups. Doing so would cause the application to use a Mach port to communicate with the mDNSResponder process which then performs the DNS lookup for the application. The same may apply to other tools that are built using Apple’s APIs.

Finally, the last major piece of the XNU Kernel is I/O Services. I/O Kit is Apple’s framework used to build device drivers. These device drivers can be built to reside in the kernel. A few examples of drivers that might require kernel access are Ethernet, audio, thunderbolt, graphics, and networking drivers. The Apple Developer Library encourages users to avoid loading extensions into the kernel if possible since many tasks can be accomplished without kernel access when using I/O Kit.

Digging deeper

When it comes to understanding the ins and outs of the OS X operating system the best reference is probably the Apple Developer Library where a massive amount of documentation can be found. If there are any topics mentioned in this book that you would like additional details on I highly recommend you start there. If you’re looking for a piece of information that cannot be found in the developer library it’s probably because Apple left it out on purpose. Although many details of OS X are shared much of the operating system remains closed source. The Apple Developer Library can be found at developer.apple.com.

Requirements

This book was written for anyone interested in OS X security, but the reader should have a number of prerequisite skills before starting the first chapter. The most important of these skills will be common knowledge of command line tools and how to bring these tools together using scripting. A background in bash scripting is not required but will certainly help in understanding the scripts used to collect forensic data. Common knowledge of the OS X operating system will also be beneficial. Users who have learned to use terminal commands on any Unix platform should feel right at home in the OS X environment.

Knowledge of python is also preferred if the reader wants to take the scripts and ideas proposed in this book and tweak them to work in their best interest. Python will mainly be used to perform analysis on the data collected by bash scripts. A grasp of any programming language should suffice as Python is known for being readable and easy to understand.

Forensically sound versus incident response

Before we get started, the reader should be aware that this book does not take an approach that is considered forensically sound. That is to say, it does not take an approach that an analyst would use when trying to bring criminal evidence to court. For that, many extra precautions outside the scope of this book need to be taken such as creating a full disk image using a write-blocker. The data that this book will focus on collecting and analyzing is specific to malware-based intrusions. Analysts who were hoping for a more forensically sound approach should still have a lot that can be taken away from this book.

Incident response process

Due to the constant rise of data breaches, companies all over the world have started developing their own security teams. These teams are not only dedicated to enforcing best practices to keep hackers out, but also the best ...

Table of contents

• Cover
• Title page
• Table of Contents
• Copyright
• Acknowledgments
• Chapter 1: Introduction
• Chapter 2: Incident Response Basics
• Chapter 3: Bash Commands
• Chapter 4: File System
• Chapter 5: System Startup and Scheduling
• Chapter 6: Browser Analysis
• Chapter 7: Memory Analysis
• Chapter 8: Privilege Escalation & Passwords
• Chapter 9: Exfiltration
• Chapter 10: The Timeline
• Chapter 11: Advanced Malware Techniques and System Protection
• Subject Index