OS X Incident Response: Scripting and Analysis

OS X Incident Response

Scripting and Analysis

Jaron Bradley

Technical Editor

Alexandru Radocea

Table of Contents

Cover

Title page

Copyright

Acknowledgments

Chapter 1: Introduction

Abstract

Is there really a threat to OS X?

What is OS X

The XNU Kernel

Digging deeper

Requirements

Forensically sound versus incident response

Incident response process

The Kill Chain

Applying the Killchain

Analysis environment

Malware scenario

Chapter 2: Incident Response Basics

Abstract

Introduction

Picking a language

Root versus nonroot

Yara

Basic commands for every day analysis

Starting an IR script

Collection

Analysis

Analysis scripts

Conclusion

Chapter 3: Bash Commands

Abstract

Introduction

Basic bash commands

System info

Who info

User information

Process information

Network information

System startup

Additional commands

Miscellaneous

Bash environment variables

Scripting the collection

Analysis

Conclusion

Chapter 4: File System

Abstract

Introduction

Brief history

HFS+ overview

Inodes, timestamps, permissions, and ownership

Extended attributes

File types and traits

OS X specific file extensions

File hierarchy layout

Miscellaneous Files

File artifacts

Key File artifacts

Collection

Collecting File artifacts

Analysis scripting

Analysis

Conclusion

Chapter 5: System Startup and Scheduling

Abstract

Introduction

System boot

Launchd—the beginning and end

Launch agents versus launch daemons

Breaking down a property list

Binary property lists

Launchctl

Listing active property lists with launchctl

Editing property lists using defaults

Property list overrides

Crontab

Persistence via kext

Additional kext commands

Less popular persistence methods

Collection

Analysis

Conclusion

Chapter 6: Browser Analysis

Abstract

Introduction

Safari

Chrome

Firefox

Downloads

Opera

Collection

Analysis

Conclusion

Chapter 7: Memory Analysis

Abstract

Introduction

Analysis tools

Collection

Analysis

Conclusion

Chapter 8: Privilege Escalation & Passwords

Abstract

Introduction

Privileges

Shellshock

Passwords

Collection

Analysis

Conclusion

Chapter 9: Exfiltration

Abstract

Introduction

How valuable data is located

How data is archived

Detecting archived files by timestamp

Compression tools

How attackers transfer data

Collection

Analysis

Conclusion

Chapter 10: The Timeline

Abstract

December 2015 intrusion timeline

Wrapping Up

Chapter 11: Advanced Malware Techniques and System Protection

Abstract

Introduction

Advanced malware techniques

Additional ASEPS

System protection

Conclusion

Subject Index

Copyright

Syngress is an imprint of Elsevier

50 Hampshire Street, 5th Floor, Cambridge, MA 02139, USA

Copyright © 2016 Elsevier Inc. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or any information storage and retrieval system, without permission in writing from the publisher. Details on how to seek permission, further information about the Publisher’s permissions policies and our arrangements with organizations such as the Copyright Clearance Center and the Copyright Licensing Agency, can be found at our website: www.elsevier.com/permissions.

This book and the individual contributions contained in it are protected under copyright by the Publisher (other than as may be noted herein).

Notices

Knowledge and best practice in this field are constantly changing. As new research and experience broaden our understanding, changes in research methods, professional practices, or medical treatment may become necessary.

Practitioners and researchers must always rely on their own experience and knowledge in evaluating and using any information, methods, compounds, or experiments described herein. In using such information or methods they should be mindful of their own safety and the safety of others, including parties for whom they have a professional responsibility.

To the fullest extent of the law, neither the Publisher nor the authors, contributors, or editors, assume any liability for any injury and/or damage to persons or property as a matter of products liability, negligence or otherwise, or from any use or operation of any methods, products, instructions, or ideas contained in the material herein.

Disclaimer

The opinions expressed in this book come solely from the author and do not necessarily express the views or opinions of his employer.

British Library Cataloguing-in-Publication Data

A catalogue record for this book is available from the British Library

Library of Congress Cataloging-in-Publication Data

A catalog record for this book is available from the Library of Congress

ISBN: 978-0-12-804456-8

For information on all Syngress publications visit our website at https://www.elsevier.com/

Acquisition Editor: Chris Katsaropoulos

Editorial Project Manager: Anna Valutkevich

Production Project Manager: Mohana Natarajan

Cover Designer: Mark Rogers

Typeset by Thomson Digital

Acknowledgments

The StackOverflow Community for being a fantastic resource. draw.io for being free and awesome. Andrew Case and the Volatility team for the awesome work they do supporting OS X memory analysis. The guys over at the Rekall Team for supplying the community with a live memory analysis framework and the amazing pmem applications. Anyone who has ever written a blog post or write-up related to OS X security, administration, developer tutorials or unique findings. Kris Merritt for letting me join such an awesome team and putting me in a position where I can learn more about this topic. Brody Nisbet and William Pauley for their recommendations and assistance in cleaning up the introduction chapter. A big thanks to Christopher Schmitt and Adrian Maniatis for their assistance with writing and cleaning up my sloppy Python code. A big thanks to Patrick Wardle at Synack for all the amazing research he’s been working on and presenting across different conferences as well as writing and maintaining the tools at objective-see.com. I referred to your documents, slides, and video’s countless times while writing this book. A huge thanks to my technical reviewer Alex Radocea for his wisdom and guidance on all things OS X and his willingness to work with me nonstop while living in a polar opposite timezone. I could not have done this book without you. Finally, a thank you to my beautiful wife, for encouraging me to take on a new challenge.

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 practices on responding for when they get in. Don’t make the mistake of believing that your security is impenetrable. Each company has its own preferences and processes for responding to an intrusion. For smaller companies that might mean hiring a group of contractors. For naive companies it might mean doing nothing at all, but for companies who have built up a strong incident response team, a high level view of the process should look similar to the following (Fig. 1.1).

Figure 1.1

▪ Prepare

▪ Preparing for a company-wide intrusion does not mean watching old Blackhat videos on YouTube, drinking coffee, and staying hydrated. It means building your toolset, researching attacker methodologies, and developing new ways to catch them. Some may consider the preparation stage as down time, but it should not be treated as so. Preparation is critical to