- Форензика в Linux. Дампим память, диски и сетевые коннекты для дальнейшего поиска улик
- Содержание статьи
- Некоторые особенности форензики в Linux
- Общий чек-лист проверки
- WARNING
- Снимаем образ HDD
- Продолжение доступно только участникам
- Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте
- Linux Forensics — Philip Polstra.pdf
- Short Description
- Description
Форензика в Linux. Дампим память, диски и сетевые коннекты для дальнейшего поиска улик
Содержание статьи
Первая задача в цифровой криминалистике — это сбор информации, конкретно — получение образов жестких дисков и оперативной памяти, а также, если это может помочь, дампов сетевых соединений. В этой статье мы посмотрим, что нужно сделать для получения всего этого на машинах с Linux, а заодно научимся и другим полезным навыкам.
Это новая часть цикла по форензике для новичков, в котором мы рассказываем о том, что такое цифровая форензика, разбираем наиболее популярные инструменты анализа, изучаем несколько кейсов на устройствах с Android и расследуем хищение денежных средств из системы ДБО на ноутбуке с Windows 10.
Предыдущие статьи цикла:
Есть много вариантов создания дампа содержимого жесткого диска или оперативной памяти. При этом можно использовать и нативные утилиты, входящие в состав дистрибутива, и сторонние программы — как со свободной лицензией, так и коммерческие. Я по возможности сосредоточусь на наиболее известных, максимально простых и рабочих инструментах.
Первым делом на «живые» системы я рекомендую ставить утилиту Auditd — с ее помощью можно получить детальные сведения об изменениях системы в режиме аудита.
Прежде всего нас будут интересовать такие события, как:
- запуск и завершение работы системы (перезагрузка, остановка);
- чтение/запись системных файлов и изменение прав доступа к ним;
- инициация сетевого соединения и изменение сетевых настроек;
- изменение информации о пользователе или группе;
- изменение даты и времени;
- установка, удаление, запуск и остановка программ и демонов;
- выполнение системных вызовов.
Также рекомендую настроить системный syslog.conf и скорректировать правила сбора сообщений: увеличить глубину собираемых алертов (уровень 7) и пул источников (диапазон от 0 до 15). Это все позволит наблюдать за изменениями системы в реальном времени.
Некоторые особенности форензики в Linux
В прошлой статье, которая была посвящена кейсу с хищением денежных средств в ДБО на Windows 10, мы по возможности использовали в качестве инструментария программы с графическим интерфейсом. Если не брать проприетарные решения, такие, к примеру, как EnCase Forensic или Belkasoft Evidence Center, то на Linux большинство рабочих утилит идет в режиме командной строки.
Использование тестовых команд существенно экономит время на манипуляции с софтом, но, с другой стороны, может оказаться слишком сложным для новичков. Однако форензикой новички обычно и не занимаются! 😀
Помимо отдельных утилит, есть целые дистрибутивы, предназначенные для цифровой криминалистики. Это прежде всего DEFT, CAINE, Sumuri PALADIN, Helix, ну и, конечно же, всем известный Kali Linux. Полный обзор дистрибутивов и тулкитов для форензики можно прочитать в статье «Тулкит для форензики. Выбираем дистрибутив и набор софта для криминалистического анализа».
Из литературы по форензике в Linux я бы в первую очередь порекомендовал едва ли не единственную полноценную книгу об этом. Ее написал Филип Полстра, а называется она Linux Forensics Paperback. Во вторую очередь — издание UNIX and Linux Forensic Analysis DVD Toolkit Криса Пога и других. Ну и в-третьих, Digital Forensics with Kali Linux.
Общий чек-лист проверки
Для поиска и сбора криминалистических доказательств мы первым делом создадим образы (дампы) следующих объектов наших систем:
- оперативная память (системные и пользовательские процессы, демоны, возможно запущенный вредоносный код и так далее);
- жесткий диск (посекторная копия HDD, включающая удаленные разделы, неразмеченные области диска, потертые файлы, скрытые файлы и директории и прочее);
- сетевой стек (поднятые коннекты, открытые порты, «неизвестные» сервисы на портах, паразитный трафик).
В рамках самой операционной системы мы будем обращать особое внимание в первую очередь:
- на список пользователей, группы, привилегии;
- запущенные от имени root процессы;
- задачи, запускаемые по расписанию (cron jobs);
- файлы с установленным битом SUID и SGID;
- состав файла /etc/sudoers;
- скрытые файлы и директории;
- файлы, открытые на чтение в системе;
- сетевые интерфейсы, соединения, порты, таблицу маршрутизации;
- логи iptables, fail2ban (Reports, Alarms, Alerts);
- конфигурацию /etc/ssh/sshd_config ;
- логи демона Syslog (проверим на типичные алерты);
- состояние SELinux;
- список загруженных модулей ядра.
Ну и в качестве дополнительной опции можно собрать контрольные суммы с основных системных файлов (к примеру, утилитой TripWire), а позже сравнить их с эталонными значениями в исходном дистрибутиве. Но этот процесс весьма нетривиален и требует большого запаса времени и нервных клеток. Поэтому подробности мы любезно опустим.
Поскольку железо, на котором крутится вся ферма, находится в надежном дата-центре, сразу отметается поиск артефактов, связанных с сетевой ФС (NFS), локально смонтированными устройствами и подключенными по USB девайсами.
WARNING
Всегда хорошо обдумывай, какое именно действие и для какой цели ты делаешь. Неправильное использование приведенных в тексте статьи программ может привести к потере информации (артефактов) или искажению полученных данных (криминалистических доказательств). Ни автор, ни редакция не несут ответственности за любой ущерб, причиненный при неправильном использовании материала данной статьи.
Снимаем образ HDD
Посекторную копию жесткого диска вполне можно снять, не прибегая к дополнительным утилитам. Мы будем использовать старую и проверенную в работе нативную тулзу dd. Она позволяет создавать точные побитовые копии — как целых дисков, так и отдельных разделов и даже просто файлов.
Продолжение доступно только участникам
Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте
Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее
Источник
Linux Forensics — Philip Polstra.pdf
Short Description
Download Linux Forensics — Philip Polstra.pdf.
Description
Linux Forensics Philip Polstra
Linux Forensics Copyright (c) 2015 by Pentester Academy All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, distributed, or transmitted in any form or by any means, including photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher, except in the case of brief quotations embodied in critical reviews and certain other noncommercial uses permitted by copyright law. Although every precaution has been taken to verify the accuracy of the information contained herein, the author and publisher assume no responsibility for any errors or omissions. No liability is assumed for damages that may result from the use of information contained within. First published: July 2015 Published by Pentester Academy, a division of Binary Security Innovative Solutions Pvt. Ltd. http://www.PentesterAcademy.com First Edition
Dedicated to my wife of twenty five years
Contents Acknowledgements Author Biography Foreword Scripts, Videos, Teaching Aids, Community Forums and more Introduction
CHAPTER 1 First Steps INFORMATION IN THIS CHAPTER: WHAT IS FORENSICS? TYPES OF FORENSICS WHY LINUX FORENSICS? GENERAL PRINCIPLES Maintaining Integrity Chain of Custody Standard Practices Documentation PHASES OF INVESTIGATION Evidence Preservation and Collection Evidence Searching Reconstruction of Events HIGH-LEVEL PROCESS Every Child is Perfect, Just Ask The Parents BUILDING A TOOLKIT Hardware Software Running live Linux in a virtual machine SUMMARY
CHAPTER 2 Determining If There Was an Incident INFORMATION IN THIS CHAPTER: OPENING A CASE
TALKING TO USERS DOCUMENTATION If you are using a virtual machine, older may be better MOUNTING KNOWN-GOOD BINARIES MINIMIZING DISTURBANCE TO THE SUBJECT SYSTEM Using a USB drive to store data Using Netcat Sending data from the subject system Sending files USING SCRIPTING TO AUTOMATE THE PROCESS Scripting the server Scripting the client Short circuiting is useful in many places INTRODUCING OUR FIRST SUBJECT SYSTEM COLLECTING VOLATILE DATA Date and time information Operating system version Network interfaces Network connections Open ports Programs associated with various ports Open Files Running Processes Routing Tables Mounted filesystems Loaded kernel modules Users past and present Putting it together with scripting SUMMARY
CHAPTER 3 Live Analysis INFORMATION IN THIS CHAPTER:
THERE WAS AN INCIDENT: NOW WHAT? GETTING FILE METADATA USING A SPREADSHEET PROGRAM TO BUILD A TIMELINE EXAMINING USER COMMAND HISTORY GETTING LOG FILES COLLECTING FILE HASHES DUMPING RAM RAM acquisition methods Building LiME Using LiME to dump RAM SUMMARY
CHAPTER 4 Creating Images INFORMATION IN THIS CHAPTER: SHUTTING DOWN THE SYSTEM Normal shutdown Pulling the plug IMAGE FORMATS Raw format Proprietary format with embedded metadata Proprietary format with metadata in a separate file Raw format with hashes stored in a separate file USING DD USING DCFLDD HARDWARE WRITE BLOCKING SOFTWARE WRITE BLOCKING Udev rules Live Linux distributions CREATING AN IMAGE FROM A VIRTUAL MACHINE CREATING AN IMAGE FROM A PHYSICAL DRIVE SUMMARY
CHAPTER 5 Mounting Images
INFORMATION IN THIS CHAPTER: PARTITION BASICS MASTER BOOT RECORD PARTITIONS EXTENDED PARTITIONS GUID PARTITIONS MOUNTING PARTITIONS FROM AN IMAGE FILE ON LINUX USING PYTHON TO AUTOMATE THE MOUNTING PROCESS MBR-based primary partitions Scripting or Programming Language MBR-based extended partitions GPT partitions SUMMARY
CHAPTER 6 Analyzing Mounted Images INFORMATION IN THIS CHAPTER: GETTING MODIFICATION, ACCESS, AND CREATION TIMESTAMPS IMPORTING INFORMATION INTO LIBREOFFICE IMPORTING DATA INTO MySQL When tools fail you CREATING A TIMELINE EXAMINING BASH HISTORIES EXAMINING SYSTEM LOGS EXAMINING LOGINS AND LOGIN ATTEMPTS OPTIONAL – GETTING ALL THE LOGS SUMMARY
CHAPTER 7 Extended Filesystems INFORMATION IN THIS CHAPTER: EXTENDED FILESYSTEM BASICS SUPERBLOCKS EXTENDED FILESYSTEM FEATURES Compatible Features Incompatible features
Read-only compatible features USING PYTHON Reading the superblock Reading block group descriptors Combining superblock and group descriptor information FINDING THINGS THAT ARE OUT OF PLACE INODES Reading inodes with Python Inode extensions and details Going from an inode to a file Extents Directory entries Extended attributes JOURNALING SUMMARY
CHAPTER 8 Memory Analysis INFORMATION IN THIS CHAPTER: VOLATILITY CREATING A VOLATILITY PROFILE GETTING PROCESS INFORMATION PROCESS MAPS AND DUMPS GETTING BASH HISTORIES VOLATILITY CHECK COMMANDS GETTING NETWORKING INFORMATION GETTING FILESYSTEM INFORMATION MISCELLANEOUS VOLATILITY COMMANDS SUMMARY
CHAPTER 9 Dealing with More Advanced Attackers INFORMATION IN THIS CHAPTER: SUMMARY OF THE PFE ATTACK THE SCENARIO
INITIAL LIVE RESPONSE MEMORY ANALYSIS FILESYSTEM ANALYSIS LEVERAGING MYSQL MISCELLANEOUS FINDINGS SUMMARY OF FINDINGS AND NEXT STEPS SUMMARY
CHAPTER 10 Malware INFORMATION IN THIS CHAPTER: IS IT MALWARE? The file command Is it a known-bad file? Using strings Listing symbol information with nm Listing shared libraries with ldd I THINK IT IS MALWARE Getting the big picture with readelf Using objdump to disassemble code DYNAMIC ANALYSIS Tracing system calls Tracing library calls Using the GNU Debugger for reverse engineering OBFUSCATION SUMMARY
CHAPTER 11 The Road Ahead INFORMATION IN THIS CHAPTER: NOW WHAT? COMMUNITIES LEARNING MORE CONGREGATE CERTIFY
Acknowledgements First and foremost I would like to thank my wife and children for allowing me to take the time to write this book. This book would never have happened without their support. Many thanks to Vivek Ramachandran and the whole Pentester Academy team for honoring me twice. First, I had the privilege of being the first external trainer for Pentester Academy. Second, I was granted the ability to author the first book ever published by Pentester Academy. My deepest thanks go to Dr. Susan Baker for graciously offering to read this entire book and serve as copy editor. Finally, I would like to my many supportive friends in the information security community who have provided encouragement to me throughout the years.
Author Biography Dr. Philip Polstra (known to his friends as Dr. Phil) is an internationally recognized hardware hacker. His work has been presented at numerous conferences around the globe including repeat performances at DEFCON, BlackHat, 44CON, GrrCON, MakerFaire, ForenSecure, and other top conferences. Dr. Polstra is a well-known expert on USB forensics and has published several articles on this topic. He has developed a number of video courses including ones on Linux forensics, USB forensics, and reverse engineering. Dr. Polstra has developed degree programs in digital forensics and ethical hacking while serving as a professor and Hacker in Residence at a private university in the Midwestern United States. He currently teaches computer science and digital forensics at Bloomsburg University of Pennsylvania. In addition to teaching, he provides training and performs penetration tests on a consulting basis. When not working, he has been known to fly, build aircraft, and tinker with electronics. His latest happenings can be found on his blog: http://polstra.org. You can also follow him at @ppolstra on Twitter.
Foreword Hello All! Phil and I met online around five years back through SecurityTube.net and we’ve been great friends ever since. Over the years, we discussed interesting projects we could collaborate on and information security education was on top of our list as expected. Based on our discussions, Phil created an excellent “USB Forensics” and “Linux Forensics” video series for Pentester Academy! Both the video series were fantastic and well received by our students. I’d always wanted to convert our online video series into books and Phil’s “Linux Forensics” video course seemed like the best place to start this adventure! And so we have! I’d like to take this opportunity to wish Phil and my publishing team at Pentester Academy bon voyage on this new endeavor! Finally but most importantly, I’d like to thank the SecurityTube.net and Pentester Academy community and our students for their love and support over the years! We would not be here today without you guys! You’ve made all our dreams come true. We cannot thank you enough. Vivek Ramachandran Founder, SecurityTube.net and Pentester Academy
Scripts, Videos, Teaching Aids, Community Forums and more Book website We’ve created two mirror websites for the “Linux Forensics” book: http://www.pentesteracademy.com/books http://www.linuxforensicsbook.com
Scripts and Supporting Files All Python and shell scripts have been made available for download on the website. We’ve tried our best to ensure that the code works and is error free but if you find any bugs please report them and we will publicly acknowledge you on the website.
Videos We are Pentester Academy and we love videos! Though the book is completely selfsufficient we thought it would be fun to have videos for a select few labs by the book author himself! You can access these for FREE on the book website.
Community Forums We would love to connect with our book readers – get their feedback and know from them firsthand what they would like to see in the next edition? Also, wouldn’t it be great to have a community forum where readers could interact with each other and even with the author! Our book community forums do just that! You can access the forums through the website mentioned above.
Teaching Aids Are you a professor or a commercial trainer? Do you want to use this book in class? We’ve got your covered! Through our website, you can register as a trainer and get access to teaching aids such as presentations, exercise files and other teaching aids.
Linux Forensics Book Swag! Visit the swag section on our website and get your “Linux Forensics” T-Shirts, mugs, keychains and other cool swags!
Introduction Information in This Chapter: What this book is about Intended audience How this book is organized
What this book is about This book is about performing forensic investigations on subject systems running the Linux operating system. In many cases Linux forensics is something that is done as part of incident response. That will be the focus of this book. That said, much of what you need to know in order to perform Linux incident response can also be applied to any Linux forensic investigation. Along the way we will learn how to better use Linux and the many tools it provides. In addition to covering the essentials of forensics, we will explore how to use Python, shell scripting, and standard Linux system tools to more quickly and easily perform forensic investigations. Much of what is covered in this book can also be leveraged by anyone wishing to perform forensic investigations of Windows subjects on a Linux-based forensics workstation.
Intended audience This book is primarily intended to be read by forensics practitioners and other information security professionals. It describes in detail how to investigate computers running Linux. Forensic investigators who work primarily with Windows subjects who would like to learn more about Linux should find this book useful. This book should also prove useful to Linux users and system administrators who are interested in the mechanics of Linux system breaches and ensuing investigations. The information contained within this book should allow a person to investigate the majority of attacks to Linux systems. The only knowledge a reader of this book is assumed to have is that of a normal Linux user. You need not be a Linux system administrator, hacker, or power user to learn from this book. Knowledge of Linux system administration, Python, shell scripting, and Assembly would be helpful, but definitely not required. Sufficient information will be provided for those new to these topics.
How this book is organized This book begins with a brief introduction to forensics. From there we will delve into answering the question, “Was there an incident?” In order to answer this question, various live analysis tools and techniques will be presented. We then discuss the creation and analysis of forensic filesystem and memory images. Advanced attacks on Linux systems and malware round out our discussion.
Chapter 1: First Steps Chapter 1 is an introduction to the field of forensics. It covers the various types of forensics and motivation for performing forensics on Linux systems. Phases of investigations and the high-level process are also discussed. Step-by-step instructions for building a Linux forensics toolkit are provided in this chapter.
Chapter 2: Was there an incident? Chapter 2 walks you through what happens from the point where a client who suspects something has happened calls until you can be reasonably sure whether there was or was not an incident. It covers opening a case, talking to users, creating appropriate documentation, mounting known-good binaries, minimizing disturbance to the subject system, using scripting to automate the process, and collecting volatile data. A nice introduction to shell scripting is also provided in this chapter.
Chapter 3: Live Analysis Chapter 3 describes what to do before shutting down the subject system. It covers capturing file metadata, building timelines, collecting user command histories, performing log file analysis, hashing, dumping memory, and automating with scripting. A number of new shell scripting techniques and Linux system tools are also presented in this chapter.
Chapter 4: Creating Images Chapter 4 starts with a discussion of the options for shutting down a subject system. From there the discussion turns to tools and techniques used to create a forensic image of a filesystem. Topics covered include shutting down the system, image formats, using dd and dcfldd, hardware and software write blocking, and live Linux distributions. Methods of creating images for different circumstances are discussed in detail.
Chapter 5: Mounting Images Chapter 5 begins with a discussion of the various types of partitioning systems: Master Boot Record (MBR) based partitions, extended partitions, and GUID partition tables. Linux commands and techniques used to mount all types of partitions are presented. The chapter ends with an introduction to Python and how it can be used to automate the process of mounting partitions.
Chapter 6: Analyzing Mounted Images Chapter 6 describes how to analyze mounted filesystem images. It covers file metadata, command histories, system logs, and other common information investigated during dead analysis. Use of spreadsheets and MySQL to enhance investigations is discussed. Some new shell scripting techniques are also presented.
Chapter 7: Extended Filesystems
Chapter 7 is the largest chapter in this book. All aspects of Linux extended filesystems (ext2, ext3, and ext4) are discussed in detail. An extensive set of Python and shell scripts are presented in this chapter. Advanced techniques for detecting alterations of metadata by an attacker are provided in this chapter.
Chapter 8: Memory Analysis Chapter 8 introduces the new field of memory analysis. The Volatility memory analysis framework is discussed in detail. Topics covered include creating Volatility profiles, getting process information, process maps and dumps, getting bash histories, using Volatility check plugins, retrieving network information, and obtaining in-memory filesytem information.
Chapter 9: Dealing with More Advanced Attackers Chapter 9 walks you through a more sophisticated attack in detail. The techniques described up to this point in the book are applied to a new scenario. Reporting of findings to the client is also discussed.
Chapter 10: Malware Chapter 10 provides an introduction to Linux malware analysis. It covers standard tools for investigating unknown files such as the file utility, hash databases, the strings utility, nm, ldd, readelf, objdump, strace, ltrace, and gdb. Obfuscation techniques are discussed. Safety issues are presented. An introduction to Assembly is also provided.
Chapter 11: The Road Ahead In this final chapter several suggestions for further study are provided. General tips are also given for a successful career involving forensics.
Conclusion Countless hours have been spent developing this book and accompanying scripts. It has been a labor of love, however. I hope you enjoy reading and actually applying what is in this book as much as I have enjoyed writing it. For updates to this book and also my latest happenings consult my website http://philpolstra.com. You can also contact me via my Twitter account, @ppolstra. Downloads related to the book and other forms of community support are available at Pentester Academy http://pentesteracademy.com.
1 First Steps INFORMATION IN THIS CHAPTER: What is forensics? Types of forensics Why Linux forensics? General principles Phases of investigation High-level process Building a toolkit
WHAT IS FORENSICS? A natural question to ask yourself if you are reading a book on Linux forensics is: What is forensics anyway? If you ask different forensic examiners you are likely to receive slightly different answers to this question. According to a recent version of the Merriam-Webster dictionary: “Forensic (n) belonging to, used in, or suitable to courts of judicature or to public discussion and debate.” Using this definition of the word forensic my definition of forensic science is as follows: Forensic science or forensics is the scientific collection of evidence of sufficient quality that it is suitable for use in court. The key point to keep in mind is that we should be collecting evidence of sufficient quality that we can use it in court, even if we never intend to go to court with our findings. It is always easier to relax our standards than to tighten them later. We should also act like scientists, doing everything in a methodical and technically sound manner.
TYPES OF FORENSICS When most people hear the term forensics they think about things they might have seen on shows such as CSI. This is what I refer to as physical forensics. Some of the more commonly encountered areas of physical forensics include fingerprints, DNA, ballistics, and blood spatter. One of the fundamental principles of physical forensics is Locard’s Transfer (or Exchange) Principle. Locard essentially said that if objects interact, they transfer (or exchange) material. For example, if you hit something with your car there is often an exchange of paint. As further examples, when you touch a surface you might leave fingerprints and you might take dirt with you on your shoes when you leave an area. This book covers what I would refer to as digital forensics. Some like the term computer
forensics, but I prefer digital forensics as it is much broader. We live in a world that is increasingly reliant on electronic devices such as smart phones, tablets, laptops, and desktop computers. Given the amount of information many people store on their smart phones and other small devices, it is often useful to examine those devices if someone is suspected of some sort of crime. The scope of this book is limited to computers (which could be embedded) running a version of Linux. There are many specializations within the broader space of digital forensics. These include network forensics, data storage forensics, small device forensics, computer forensics, and many other areas. Within these specializations there are further subdivisions. It is not unusual for forensic examiners to be highly specialized. My hope is that by the time you finish this book you will be proficient enough with Linux forensics to perform investigations of all but the most advanced attacks to Linux systems.
WHY LINUX FORENSICS? Presumably if you are reading this you see the value in learning Linux forensics. The same may not be true of your boss and others, however. Here is some ammunition for them on why you might benefit from studying Linux forensics. While Linux is not the most common operating system on the desktop, it is present in many places. Even in the United States, where Windows tends to dominate the desktops, many organizations run Linux in the server room. Linux is the choice of many Internet Service Providers (ISP) and large companies such as Google (they even have their own flavor of Linux). Linux is also extremely popular in development organizations. Linux is the standard choice for anyone working in information security or forensics. As the operating systems “by programmers for programmers,” it is very popular with black hat hackers. If you find yourself examining the black hat’s computer, it is likely running Linux. Many devices all around us are running some version of Linux. Whether it is the wireless access point that you bought at the local electronics store or the smart temperature controller keeping your home comfortable, they are likely running Linux under the hood. Linux also shares some heritage and functionality with Android and OS X. Linux is also a great platform for performing forensics on Windows, OS X, Android or other systems. The operating system is rich with free and open source tools for performing forensics on devices running virtually every operating system on the planet. If your budget is limited, Linux is definitely the way to go.
GENERAL PRINCIPLES There are a number of general guiding principles that should be followed when practicing forensics. These include maintaining the integrity of evidence, maintaining the chain of custody, following standard practice, and fully documenting everything. These are discussed in more detail below.
Maintaining Integrity It is of the utmost importance that evidence not be altered while it is being collected and examined. We are fortunate in digital forensics that we can normally make an unlimited number of identical copies of evidence. Those working with physical forensics are not so lucky. In fact, in many cases difficult choices must be made when quantities of physical evidence are limited as many tests consume evidence. The primary method of insuring integrity of digital evidence is hashing. Hashing is widely used in computer science as a way of improving performance. A hash function, generally speaking, takes an input of variable size and outputs a number of known size. Hashing allows for faster searches because computers can compare two numbers in one clock cycle versus iterating over every character in a long string which could require hundreds or thousands of clock cycles. Using hash functions in your programs can add a little complication because more than one input value can produce the same hash output. When this happens we say that a collision has occurred. Collisions are a complication in our programs, but when we are using hashes for encryption or integrity checking the possibility of many collisions is unacceptable. To minimize the number of collisions we must use cryptographic hash functions. There are several cryptographic hash functions available. Some people still use the Message Digest 5 (MD5) to verify integrity of images. The MD5 algorithm is no longer considered to be secure and the Secure Hash Algorithm (SHA) family of functions is preferred. The original version is referred to as SHA1 (or just SHA). SHA2 is currently the most commonly used variant and you may encounter references to SHA2 (224 bits), SHA256 (256 bits), SHA384 (384 bits), and SHA512 (512 bits). There is a SHA3 algorithm, but its use is not yet widespread. I normally use SHA256 which is a good middle ground offering good performance with low chances of collisions. We will discuss the details of using hashing in future chapters. For now the high level process is as follows. First, calculate a hash of the original. Second, create an image which we will treat as a master copy. Third, calculate the hash of the copy and verify that it matches the hash of the original. Fourth, make working copies of your master copy. The master copy and original should never be used again. While it may seem strange, the hash on working copies should be periodically recalculated as a double check that the investigator did not alter the image.
Chain of Custody Physical evidence is often stored in evidence bags. Evidence bags either incorporate a chain of custody form or have such a form attached to them. Each time evidence is removed from the bag the form is updated with who touched the evidence and what was done. The collection of entries on this form make up the chain of custody. Essentially the chain of custody is a guarantee that the evidence has not been altered and has been properly maintained.
In the case of digital forensics the chain of custody is still important. While we can make unlimited digital copies, we must still maintain the integrity of the original. This is also why a master copy should be made that is never used to for any other purpose than creating working copies as it prevents the need to touch the original other than for the onetime event of creating the master copy.
Standard Practices Following standard practices makes your investigation easier. By following a written procedure accurately there is less explaining to do if you should find yourself in court. You are also less likely to forget something or make a mistake. Additionally, if you follow standard practices there is less documentation that has to be done. It used to be said that “nobody was ever fired for buying IBM.” Similarly, no forensic investigator ever got into trouble using written procedures that conform to industry standard practice.
Documentation When in doubt document. It never hurts to overdo the documentation. As mentioned previously, if you follow standard written procedures you can reference them as opposed to repeating them in your notes. Speaking of notes, I recommend handwritten notes in a bound notebook with numbered pages. This might sound strange to readers who are used to using computers for everything, but it is much quicker to jot notes onto paper. It is also easier to carry a set of handwritten notes to court. The bound notebook has other advantages as well. No power is required to view these notes. The use of a bound notebook with numbered pages also makes it more difficult to alter your notes. Not that you would alter them, but a lawyer might not be beyond accusing you of such a thing. If you have difficulty finding a notebook with numbered pages you can number them yourself before use. If you can work with someone else it is ideal. Pilots routinely use checklists to make sure they don’t miss anything. Commercial pilots work in pairs as extra insurance against mistakes. Working with a partner allows you to have a second set of eyes, lets you work more quickly, and also makes it even harder for someone to accuse you of tampering with evidence. History is replete with examples of people who have avoided conviction by accusing someone of evidence tampering and instilling sufficient doubt in a jury. Few people love to do documentation. This seems to be true to a greater extent among technical people. There are some tools that can ease the pain of documenting your findings that will be discussed in later chapters of this book. An investigation is never over until the documentation is finished.
PHASES OF INVESTIGATION There are three phases to a forensic investigation: evidence preservation, evidence searching, and event reconstruction. It is not unusual for there to be some cycling between the phases as an investigation proceeds. These phases are described in more detail below.
Evidence Preservation and Collection Medical professionals have a saying “First do no harm.” For digital forensics practitioners our motto should be “Don’t alter the data.” This sounds simple enough. In actuality it is a bit more complicated as data is volatile. There is a hierarchy of volatility that exists in data found in any system. The most volatile data can be found in CPU registers. These registers are high speed scratch memory locations. Capturing their contents is next to impossible. Fortunately, there is little forensic value in these contents. CPU caches are the next level down in terms of volatility. Like registers they are hard to capture and also, thankfully, of little forensic value. Slightly less volatile than storage in the CPU are buffers found in various devices such as network cards. Not all input/output devices have their own storage buffers. Some lowspeed devices use main system memory (RAM) for buffering. As with data stored in the CPU, this data is difficult to capture. In theory, anything stored in these buffers should be replicated in system memory assuming it came from or was destined for the target computer. System memory is also volatile. Once power has been lost, RAM is cleared. When compared to previously discussed items, system memory is relatively easy to capture. In most cases it is not possible to collect the contents of system memory without changing memory contents slightly. An exception to this would be hardware-based memory collection. Memory acquisition will be discussed in greater detail in a later chapter. Due to limitations in technology, until recently much of digital forensics was focused on “dead analysis” of images from hard drives and other media. Even when dealing with nonvolatile media, volatility is still an issue. One of the oldest questions in computer security and forensics is whether or not to pull the plug on a system you suspect has been compromised. Pulling the plug can lead to data loss as anything cached for writing to media will disappear. On modern journaling filesystems (by far the most common situation on Linux systems today) this is less of an issue as the journal can be used to correct any corruption. If the system is shut down in the normal manner some malware will attempt to cover its tracks or even worse destroy other data on the system. Executing a normal shutdown has the advantage of flushing buffers and caches. As previously mentioned, the orderly shutdown is not without possible disadvantages. As with many things in forensics, the correct answer as to which method is better is, “it depends.” There are methods of obtaining images of hard drives and other media which do not require a system shutdown which further complicates this decision. Details of these methods will be presented in future chapters.
Evidence Searching Thanks to the explosion of storage capacity it becomes harder to locate evidence within
the sea of data stored in a typical computer with each passing year. Data exists at three levels, data, information, and evidence, as shown in Figure 1.1.
FIGURE 1.1 The data hierarchy.
As shown in Figure 1.1, the lowest level of data is just raw data. Raw data consists of bits, normally organized as bytes, in volatile or non-volatile storage. In this category we find things such as raw disk sectors. It can be a challenge to use data at this level and on most modern systems there is plenty of data out there to pick through. Above raw data we have information. Information consists of raw data with some sort of meaning attached to it. For example, an image has more meaning to a human than the bits that make up a JPEG file used to store the image. Even text files exist at this level in our hierarchy. Bringing many bytes of ASCII or Unicode values together gives them meaning beyond their collection of bytes. At the highest level in or hierarchy is evidence. While there may be thousands or millions of files (collections of information) it is unlikely that the bulk of them have any relevance to an investigation. This leads us to ponder what it means for information to be relevant to an investigation. As previously mentioned, forensics is a science. Given that we are trying to do science, we should be developing hypotheses and then searching for information that supports or refutes a hypothesis. It is important to remain objective during an investigation as the same piece of evidence might be interpreted differently based on people’s preconceived notions. It is extremely important that investigators do not become victims of confirmation bias. Put simply, confirmation bias is only looking at information that supports what you
believe to be true while discounting anything that would refute what you believe. Given the amount of data that must be examined in a typical investigation a hypothesis or two concerning what you think you will find is good (the owner of the computer did X, this computer was successfully exploited, etc.) to help guide you through the searching process. Don’t fall into the trap of assuming your hypothesis or hypotheses are correct, however.
CONFIRMATION BIAS IN ACTION Every Child is Perfect, Just Ask The Parents One of the best stories to describe confirmation bias goes as follows. Johnny loved magicians. One day his parents took him to see a famous magician, Phil the Great. At the end of the show the parents told Phil how much their son loved magic. Phil then offered to show them a trick. Johnny eagerly accepted. The magician proceeded to pull out a coin and move it back and forth between both hands then closed his fists and held out his hands. He asked Johnny to identify the hand containing the coin, which he did correctly. Now guessing correctly one time is not much of a feat, but this game was repeated many times and each time Johnny correctly guessed the hand containing the coin. While this was going on the magician made comments like, “You must have excellent vision to see which hand contains the coin,” and “You must be an expert on reading my facial expressions and that is how you know where the coin is.” Eventually Johnny had correctly identified the hand with the coin fifty times in a row! His parents were amazed. They called the grandparents and told all of their friends about it on Facebook, Twitter, and other social media sites. When they finally thanked the magician and turned to leave, he shouted, “goodbye,” and waved with both hands. Each hand contained a coin. It was the parents’ confirmation bias that lead them to believe what they wanted to believe, that Johnny was a savant, and distracted them from the truth, that the magician was indeed tricking them. Remain objective during an investigation. Don’t let what you or your boss want to be true keep you from seeing contrary evidence.
Reconstruction of Events In my mind trying to reconstruct what happened is the most fun part of an investigation. The explosion in size of storage media might make the searching phase longer than it was in the past, but that only helps to make the reconstruction phase that much more enjoyable. It is very unlikely that you will find all the evidence you need for your event reconstruction in one place. It is much more common to get little pieces of evidence from multiple places which you put together into a larger picture. For example, a suspicious process in a process list stored in a memory image might lead you to look at files in a
filesystem image which might lead you back to an open file list in the memory image which in turn points toward files in the filesystem image. Putting all of these bits together might allow you to determine when and by whom a rootkit was downloaded and when and by which user it was subsequently installed.
HIGH-LEVEL PROCESS While not every Linux forensic investigation is part of an incident response, it will be the focus of this book. The justification for this is that the vast majority of Linux forensic investigations are conducted after a suspected breach. Additionally, many of the items discussed in this book will be relevant to other Linux investigations as well. The high level process for incident response is shown in Figure 1.2.
FIGURE 1.2 High-level Process for Linux Incident Response
As can be seen in Figure 1.2, it all begins with a call. Someone believes that a breach (or something else) has occurred and they have called you to investigate. Your next step is to determine whether or not there was a breach. A small amount of live analysis might be required in order to make this determination. If no breach occurred, you get to document what happened and add this to your knowledge base. If there was an incident, you would normally start with live analysis before deciding whether or not dead analysis is justified. If you deem it necessary to perform the dead analysis you need to acquire some images and then actually perform the analysis. Whether or not you performed a dead analysis it isn’t over until the reports are written. All of these steps will be discussed in detail in future chapters.
BUILDING A TOOLKIT In order to do Linux forensics effectively you might want to acquire a few tools. When it comes to software tools you are in luck as all of the Linux forensics tools are free (most are also open source). In addition to the notebook discussed previously, some hardware and software should be in every forensic investigator’s tool kit.
Hardware You will likely want one or more external hard drives for making images (both RAM and hard disks). External hard drives are preferred as it is much easier to share with other investigators when they can just plug in a drive. USB 3.0 devices are the best as they are significantly faster than their USB 2.0 counterparts. A write blocker is also helpful whenever an image is to be made of any media. Several hardware write blockers are available. Most of these are limited to one particular interface. If your budget affords only one hardware write blocker, I would recommend a SATA blocker as this is the most common interface in use at this time. Software write blockers are also a possibility. A simple software write blocker is presented later in this book.
Software Software needs fall into a few categories: forensic tools, system binaries, and live Linux distributions. Ideally these tools are stored on USB 3.0 flash drives and perhaps a few DVDs if you anticipate encountering systems that cannot boot from a USB drive. Given how cheap USB flash drives are today, even investigators with modest budgets can be prepared for most situations. There are a number of ways to install a set of forensics tools. The easiest method is to install a forensics oriented Linux distribution such as SIFT from SANS (http://digitalforensics.sans.org/community/downloads). Personally, I prefer to to run my favorite Linux and just install the tools rather than be stuck with someone else’s themes and sluggish live system performance. The following script will install all of the tools found in SIFT on most Debian or Ubuntu based systems (unlike the SANS install script that works only on specific versions of Ubuntu). #!/bin/bash # Simple little script to load DFIR tools into Ubuntu and Debian systems # by Dr. Phil Polstra @ppolstra # create repositories echo “deb http://ppa.launchpad.net/sift/stable/ubuntu trusty main” \ > /etc/apt/sources.list.d/sift-ubuntu-stable-utopic.list echo “deb http://ppa.launchpad.net/tualatrix/ppa/ubuntu trusty main” \ > /etc/apt/sources.list.d/tualatrix-ubuntu-ppa-utopic.list #list of packages pkglist=”aeskeyfind afflib-tools afterglow aircrack-ng arp-scan autopsy binplist
bitpim bitpim-lib bless blt build-essential bulk-extractor cabextract clamav cryptsetup dc3dd dconf-tools dumbpig e2fslibs-dev ent epic5 etherape exif extundelete f-spot fdupes flare flasm flex foremost g++ gcc gdb ghex gthumb graphviz hexedit htop hydra hydra-gtk ipython kdiff3 kpartx libafflib0 libafflib-dev libbde
libbde-tools libesedb libesedb-tools libevt libevt-tools libevtx libevtx-tools libewf libewf-dev libewf-python libewf-tools libfuse-dev libfvde libfvde-tools liblightgrep libmsiecf libnet1 libolecf libparse-win32registry-perl libregf libregf-dev libregf-python libregf-tools libssl-dev libtext-csv-perl libvshadow libvshadow-dev libvshadow-python libvshadow-tools libxml2-dev maltegoce md5deep nbd-client netcat netpbm nfdump ngrep ntopng okular openjdk-6-jdk
p7zip-full phonon pv pyew python python-dev python-pip python-flowgrep python-nids python-ntdsxtract python-pefile python-plaso python-qt4 python-tk python-volatility pytsk3 rsakeyfind safecopy sleuthkit ssdeep ssldump stunnel4 tcl tcpflow tcpstat tcptrace tofrodos torsocks transmission unrar upx-ucl vbindiff virtuoso-minimal winbind wine wireshark xmount zenity regripper cmospwd
ophcrack ophcrack-cli bkhive samdump2 cryptcat outguess bcrypt ccrypt readpst ettercap-graphical driftnet tcpreplay tcpxtract tcptrack p0f netwox lft netsed socat knocker nikto nbtscan radare-gtk python-yara gzrt testdisk scalpel qemu qemu-utils gddrescue dcfldd vmfs-tools mantaray python-fuse samba open-iscsi curl git system-config-samba libpff
libpff-dev libpff-tools libpff-python xfsprogs gawk exfat-fuse exfat-utils xpdf feh pyew radare radare2 pev tcpick pdftk sslsniff dsniff rar xdot ubuntu-tweak vim” #actually install # first update apt-get update for pkg in $
Briefly, the above script works as described here. First, we run a particular shell (bash)
using the special comment construct #!
THIS IS TAKING TOO LONG Running live Linux in a virtual machine If you decide to create a bootable SIFT (or similar) USB drive you will quickly find that it takes hours to install the packages from SIFT. This can tie up your computer for hours preventing you from getting any real work done. There is a way to build the USB drive without tying up the machine, however. What you need to do is set up a virtual machine that can be run from a live Linux distribution on a USB drive. The following instructions assume you are running VirtualBox on a Linux host system. VirtualBox ships with several tools. One of these is called vboxmanage. There are several commands vboxmanage supports. Typing vboxmange –help in a terminal will give you a long list of commands. This will not list the command that we need, however, as it is one of the internal commands. In order to create a virtual disk that points to a physical device you must execute the following command as root: vboxmanage internalcommands createrawvmdk -filename rawdisk . For example, if your thumb drive is normally mounted as /dev/sdb the following command could be used: vboxmanage internalcommands createrawvmdk -filename /root/VirtualBox\ Vms/usb.vmdk -rawdisk /dev/sdb. Note that you cannot just sudo this command as the regular user will have permission problems trying to run the virtual machine later. Creating this virtual drive and running VirtualBox is shown in Figure 1.3. Once the virtual disk file has been created, set up a new virtual machine in the normal manner. Depending on the live Linux you have chosen, you may need to enable EFI support as shown in Figure 1.7. The creation of the live Linux virtual machine is shown in Figure 1.4 through Figure 1.6. The virtual machine running for the first time is shown in Figure 1.8.
FIGURE 1.3 Creating a virtual disk file that points to a physical USB drive.
FIGURE 1.4 Creating a virtual machine that runs a live Linux distribution from a USB drive.
FIGURE 1.5 Setting up memory for the live Linux virtual machine. Be certain to select the maximum amount of memory for better performance running a live distribution as everything is run from RAM.
FIGURE 1.6 Selecting the USB physical drive for the live Linux virtual machine.
FIGURE 1.7 Enabling EFI support in VirtualBox.
FIGURE 1.8 Running a virtual machine from a USB drive.
SUMMARY In this chapter we have discussed all the preliminary items that should be taken care of
before arriving on the scene after a suspected incident has occurred. We covered the hardware, software, and other tools that should be in your go bag. In the next chapter we will discuss the first job when you arrive, determining if there was an incident.
2 Determining If There Was an Incident INFORMATION IN THIS CHAPTER: Opening a case Talking to users Documentation Mounting known-good binaries Minimizing disturbance to the subject system Using scripting to automate the process Collecting volatile data
OPENING A CASE This chapter will address the highlighted box from our high-level process as shown in Figure 2.1. We will come to learn that there is often much involved in determining whether or not there was an incident. We will also see that some limited live response may be necessary in order to make this determination.
FIGURE 2.1 The High-level Investigation Process.
Before you do anything else, when you arrive on the scene, you should open a case file. This is not as complicated as it sounds. You could literally create a folder on your laptop with a case number. What should you use for a case number? Whatever you want. You might want a case number that is a year-number or you might prefer to use the date for a case number under the assumption that you won’t be starting multiple cases on the same day. You could always append a number to the date if you had multiple cases in a given day. You might also consider starting a new entry in your bound notebook (with the numbered pages). Some might prefer to wait until they are sure there was an incident before consuming space in their notebooks for a false alarm. My personal feeling on this is that notebooks are cheap and it is easier and cleaner if you start taking notes in one place from the very beginning.
TALKING TO USERS Before you ever think about touching the subject system you should interview the users. Why? Because they know more about the situation than you will. You might be able to determine that it was all a false alarm very quickly by talking to the users. For example, perhaps it was a system administrator that put a network card in promiscuous mode and not malware or an attacker. It would be far better for everyone if you found this out by talking to the administrator now than after hours of investigating. You should ask the users a series of questions. The first question you might ask is, “Why did you call me?” Was there an event that led to your being called in? Does the organization lack a qualified person to perform the investigation? Does the organization’s policy on possible incidents require an outside investigator? The second question you might ask is, “Why do you think there is a problem or incident?” Did something strange happen? Is the network and/or machine slower than normal? Is there traffic on unusual ports? Unlike Windows users, most Linux users don’t just shrug off strange behavior and reboot. Next you want to get as much information as you can about the subject (suspected victim) system. What is the system normally used for? Where did the system come from? Was it purchased locally or online, etc? As many readers are likely aware, it has come to light that certain government entities are not above planting parasitic devices inside a computer that has been intercepted during shipment. Has the computer been repaired recently? If so, by whom? Was it an old, trusted friend or someone new? Malicious software and hardware are easily installed during such repairs.
DOCUMENTATION As previously mentioned, you cannot over do the documentation. You should write down what the users told you during your interviews. In addition to the advantages already mentioned for using a notebook, writing notes in your notebook is a lot less distracting and intimidating for the users than banging away at your laptop keyboard or even worse filming the interviews.
You should also write down everything you know about the subject system. If it seems appropriate you might consider taking a picture of the computer and screen. If you suspect that physical security has been breached, it is an especially good idea. You are now ready to actually touch the subject system.
VIRTUAL COMPLICATIONS If you are using a virtual machine, older may be better I have previously recommended the use of a USB 3.0 drive for performance reasons. If you are using a virtual machine to practice while you are going through this book, a USB 2.0 drive might be preferred. The reason for this is that some of the virtualization software seems to have issues dealing with USB 3.0 devices. At the time of this writing USB 2.0 devices seem to cause less problems. Regardless of the type of drive you have, the host operating systems will initially try to lay claim to any attached device. If you are using VirtualBox, you will need to check the appropriate device from the USB Devices submenu under Devices as shown in Figure 2.2.
FIGURE 2.2 Selecting a USB Drive. If your subject system is running inside a virtual machine you will need to pass the device along to the virtual machine by selecting the device as shown here.
MOUNTING KNOWN-GOOD BINARIES In most cases if you insert your USB drive with known-good binaries, it will be automounted. If this isn’t the case on the subject system, you will need to manually mount the drive. Once your drive is mounted you should run a known-good shell located on your drive. You are not done after you run this shell, however. You must set your path to only point at the directories on your USB drive and also reset the LD_LIBRARY_PATH variable to only reference library directories on the USB drive. The first thing you will want to do is to check that your filesystem has in fact been mounted. Some versions of Linux will not automatically mount an extended (ext2, ext3, or ext4) filesystem. Most Linux systems will automount a FAT or NTFS filesystem, however. Recall that your system binaries must be housed on an extended filesystem in order to preserve their permissions. The easiest way to check if something is mounted is to execute the mount command. The results of running this command with my Linux forensics response drive are shown in Figure 2.3. Notice that my drive is mounted as /dev/sdb with three partitions. The first two partitions are a FAT and ext4 partition for a live version of Linux (SIFT in this case) and the third partition contains 64-bit system binaries.
FIGURE 2.3 Verifying That a USB Drive Is Mounted. In this figure the three highlighted partitions from the USB drive (/dev/sdb) have all been automatically mounted.
If you are unsure what drive letter will be assigned to your incident response drive the dmesg command can often help. The results of running dmesg after inserting a USB drive are shown in Figure 2.4. The portion that demonstrates the drive has been assigned to
/dev/sdb is highlighted.
FIGURE 2.4 Result of running dmesg command. The portion that shows drive letter /dev/sdb has been assigned is highlighted.
If you need to manually mount your drive first create a mount destination by running sudo mkdir /mnt/
FIGURE 2.5 Executing the known-good bash shell.
FIGURE 2.6 Making the path point to known-good binaries.
FIGURE 2.7 Making the library path point to known-good files.
MINIMIZING DISTURBANCE TO THE SUBJECT SYSTEM Unfortunately, it is impossible to collect all the data from a running system without causing something to change. Your goal as a forensic investigator should be to minimize this disturbance to the subject system. There are two things you should never do if you can avoid it. First, do not install anything on the subject system. If you install new software it will substantially change the system when configuration files, libraries, and executables are saved to the subject’s media. The worst possible situation would be to compile something from source code as it will cause many temporary files to be created and will also consume memory (possibly pushing out other more interesting information) and affect a memory image should you choose to make one. The second thing you should avoid is creating new files on the system. If you must use a tool that is not installed, have it on your response USB drive. Don’t create memory or disk images and then store them on the subject system either! You will definitely alter what is in RAM when you investigate a system. You should try to minimize your memory footprint, however. There are a couple of ways that you might accomplish these goals. Two popular solutions are to store data on USB media (which could be your response drive) or to use the netcat utility.
Using a USB drive to store data Attaching a USB drive to the subject system is minimally invasive. This will cause some new entries in a few temporary pseudo filesystems such as /proc and /sys and the creation of a new directory under /media on most versions of Linux. A few larger USB 3.0 backup
drives should be in your toolkit for just such occasions. It might be best to copy your system binaries to this drive first should you end up going this route to avoid having to mount more than one external drive. Once the USB drive has been attached you can use the techniques described earlier to operate with known-good system binaries and utilities. Log files and other data discussed in this chapter can be stored to the USB drive. Techniques described in later chapters can be used to store images on the USB drive. Even if you used the netcat utility (described next), having some USB backup drives on hand can make sharing images much easier. Naturally, whatever you do should be documented in your bound notebook.
Using Netcat While using a USB drive meets our goals of not installing anything or creating new files on the subject system (with the exceptions noted above) it does not minimize our memory footprint. Copying to slow USB storage devices (especially USB 2.0 drives) is likely to result in a significant amount of caching which will increase our memory footprint. For this reason, the use of netcat is preferred when the subject system is connected to a network of reasonable speed and reliability. Wired gigabit Ethernet is the most desirable media. If you are forced to use wireless networking, do your best to ensure your forensics workstation has a strong signal from the access point. If neither of these are an option, you may be able to connect your forensics laptop directly to the subject system via a crossover cable. Realize that the subject system is probably set up to use Dynamic Host Configuration Protocol (DHCP) so you will either need to use static IP addresses on both ends or install a DHCP server on your forensics laptop if you go the crossover cable route. If the subject system has only one network interface that must be disconnected I recommend against using the crossover cable as it will disturb the system too much. To temporarily setup a static IP on each end of your crossover cable issue the command sudo ifconfig
receiving the end-of-file (EOF) marker. The -k option for netcat will keep the listener alive until you press Control-C in the terminal where you started netcat. The command to start the log file listener is netcat -k -l
FIGURE 2.8 Running a netcat listener on the forensics workstation.
Sending data from the subject system Now that you have a listener on the forensics workstation it is easy to send data across the network using netcat. The general sequence for sending something for logging is
FIGURE 2.9 Using netcat to send information to the forensics workstation.
FIGURE 2.10 Results received by listener from commands in Figure 2.9.
Sending files It is not unusual to extract suspicious files from a subject system for further study. Netcat
is also handy for performing this task. In order to receive a file you should start a new listener on the forensics workstation that doesn’t use the -k option. In this case you want to end the listener after the file has been transmitted. The command is nc -l
This script starts with the special comment “#!” also known as the she-bang which causes the bash shell to be executed. It is important to run a particular shell as users who are allowed to pick their own might select something incompatible with your script. A # anywhere on a line begins a comment which terminates at the end of the line. The first several lines are comments that describe the script. After the comments a function called usage is defined. To define a function in a shell script simply type its name followed by a space, empty parentheses, another space, and then enclose whatever commands make up the function in curly brackets. Unlike compiled languages and some scripting languages, shell scripts require white space in the proper places or they will not function correctly. The $0 in the line echo “usage: $0 ” is a variable that is set to the first command line parameter that was used to run the script, which is the name of the script file. Note the use of double quotes in the echo commands. Anything enclosed in double quotes is expanded (interpreted) by the shell. If single quotes are used, no expansion is
performed. It is considered a good programming practice to define a usage function that is displayed when a user supplies command line arguments that do not make sense. The line if [ $# -lt 1 ] ; then begins an if block. The logical test is enclosed in square brackets. Note that there must be white space around the brackets and between parts of the logical test as shown. The variable $# is set to the number of command line arguments passed in to the script. In this script if that number is less than 1, the usage function is called, otherwise a message about starting a case is echoed to the screen. The variable $1 is the first command line parameter passed in (right after the name of the script) which is meant to be the case name. Observe that the if block is terminated with fi (if spelled backwards). The conditional statement in the if block that starts with if [ ! -d $1 ] ; then checks to see if the case directory does not yet exist. The -d test checks to see that a directory with the name that follows exists. The ! negates (reverses) the test so that the code inside the if block is executed if the directory doesn’t exist. The code simply uses mkdir to create the directory. Next the line `nc -k -l 4444 >> $1/log.txt` & starts a listener on port 4444 and sends everything received to a file in the case directory named log.txt. Note the command is enclosed in back ticks (backward single quotes). This tells the shell to please run the command. The & causes the command to be run in the background so that more things may be executed. The next line simply echoes a banner which is piped to the listener in order to create a header for the log file. Finally, another script is also run in the background. This scripts starts the file listener process. This script is described next. #!/bin/bash # # start-file-listener.sh # # Simple script to start a new file # listener. Intended to be # used as part of initial live response. # by Dr. Phil Polstra (@ppolstra) as developed for # PentesterAcademy.com. # When a filename is sent to port 5555 a transfer on 5556 # is expected to follow. usage () < echo “usage: $0 ” echo “Simple script to start a file listener” exit 1 ># did you specify a case name?
if [ $# -lt 1 ] ; then usage fi while true do filename=$(nc -l 5555) nc -l 5556 > $1/$(basename $filename) done
This script starts with the standard she-bang which causes the bash shell to be used. It also defines a usage function which is called if a case name is not passed in to the script. The real work in this script is in the while loop at the end. The line while true causes an infinite loop which is only exited when the user presses Control-C or the process is killed. Note that unlike the if block which is terminated with fi, the do block is terminated with done (not od). The first line in the loop runs a netcat listener on port 5555 and sets the filename variable equal to whatever was received on this port. Recall that we have used this trick of running a command inside of $() to set a variable equal to the command results in the previous script. Once a filename has been received a new listener is started on port 5556 (nc -l 5556 on the next line) and the results directed to a file with the same name in a directory named after the case name (> $1/$(basename $filename) on the second half of the line). The first command line argument, which should be the case name, is stored in $1. The basename command is used to strip away any leading path for a file that is sent. Once a file has been received, the infinite loop starts a new listener on port 5555 and the cycle repeats itself. The loop exits when the cleanup script, to be described next, is executed. The client side scripts that send log information and files will be discussed later in this chapter. #!/bin/bash # # close-case.sh # # Simple script to start shut down listeners. # Intended to be used as part of initial live response. # by Dr. Phil Polstra (@ppolstra) as developed for # PentesterAcademy.com. echo “Shutting down listeners at $(date) at user request” | nc localhost 4444 killall start-case.sh killall start-file-listener.sh killall nc
This is our simplest script yet. First we echo a quick message to our log listener on port
4444, then we use the killall utility to kill all instances of our two scripts and netcat. If you are wondering why we need to kill netcat since it is called by the scripts, recall that in some cases it is run in the background. Also, there could be a hung or in-process netcat listener or talker out there. For these reasons it is safest just to kill all the netcat processes.
Scripting the client Now that we have a server (the forensics workstation) waiting for us to send information, we will turn our attention toward scripting the client (subject system). Because it would be bothersome to include the forensics workstation IP address and ports with every action, we will start by setting some environment variables to be used by other client scripts. A simple script to do just that follows. # setup-client.sh # # Simple script to set environment variables for a # system under investigation. Intended to be # used as part of initial live response. # by Dr. Phil Polstra (@ppolstra) as developed for # PentesterAcademy.com. usage () < echo “usage: source $0 [log port] [filename port] [file transfer port]” echo “Simple script to set variables for communication to forensics workstation” exit 1 ># did you specify a file? if [ $# -lt 1 ] ; then usage fi export RHOST=$1 if [ $# -gt 1 ] ; then export RPORT=$2 else export RPORT=4444 fi if [ $# -gt 2 ] ; then export RFPORT=$3 else export RFPORT=5555 fi
if [ $# -gt 3 ] ; then export RFTPORT=$4 else export RFTPORT=5556 fi
Notice that there is no she-bang at the beginning of this script. Why not? Recall that you want to run your known-good version of bash, not the possible vandalized one in the /bin directory. Another reason this script is she-bang free is that it must be sourced in order for the exported variables to be available in new processes in your current terminal. This is done by running the command source ./setup-client.sh