Digital Forensics¶

Git History¶

Given a backup of a git repo, what sort of information can be gleaned?

git log -p

git log --all

- git log: Shows commits from the current branch. - git log -p: Shows commits from the current branch along with the changes (diffs) introduced by each commit. - git log --all: Shows commits from all branches, including those that are not on the current branch.

Depending on what was listed in the message when the "git commit -m 'updating passwords'" was run, you may be able to find speific commits of interest. Once you find a commit of interest and you want to see more details, you can run:

git show 20771a8fb517900793be6c8d1d9269978a0866de

Compressed PNG Files¶

Sometimes files include other files. Running exiftool helps identify if some files might be hiding. exifHiddenFiles

This creates an "extracted" directory where the original file's extracted files can be found. After examining the extracted files, running strings on executables like .exe or .bin files can sometimes help understand more.

File Forensics Commands¶

file file.pdf

Identifies the file type by analyzing its magic number (signature). It determines whether the file is a PDF, image, binary, etc., based on its internal structure, not just its file extension.

exiftool file.pdf

Extracts metadata from a file (such as a PDF). This can include author information, creation date, software used, GPS coordinates, and other details that may be hidden in the file’s properties.

strings file.pdf

Searches for and extracts human-readable strings from a file. This can help reveal hidden text, URLs, error messages, or passwords embedded within the file.

binwalk -e file.pdf

Analyzes and extracts embedded files or data from a binary (like a PDF). It’s commonly used to detect and extract hidden files or compressed data that are embedded within the file.

strace ./binaryName

Traces system calls and signals made by a binary during execution. It provides insight into the program’s interaction with the OS, such as file access, network connections, and memory usage.

ltrace ./binaryName

Traces library calls (e.g., malloc, free, printf) made by a binary. It helps to analyze how the program interacts with shared libraries and which functions are called during execution.

gdb ./binaryName

Starts the GNU Debugger (GDB) for a binary, allowing you to debug the program. You can inspect variables, control execution flow, set breakpoints, and view assembly code to understand how the program operates.

Altered File¶

Does the file extension match the file type that shows when running file or exiftool? Do the magic bytes of the file match the filetype?
What sort of information does strings return?

Editing the file in HexEd.it allows you to modify magic bytes and export as a new filetype.

Hidden File¶

.docx files are actually zip files containing .xml documents that support features/functions of Word so you can unzip a .docx file in order to see the xml files it holds.

Windows Memory Forensics¶

memdump files are memory dump files for a Windows OS. Sometimes these files are gzip files while other times they are xzip. In order to examine the contents, you'll first have to decompress.

xz -d memdump.mem.xz

or

gunzip memdump.raw.gz

Using Volatility3¶

Finding the right command for what you need to answer (example: finding the operating system info)

vol -h | grep "OS"

vol -f memdump.mem windows.info.Info

Tells you about the host environment:

vol -f memdump.mem windows.envars.Envars

Note the computername, username, etc. from these results. Files of interest

vol -f memdump.mem windows.filescan | grep liber8hacker

There will be several "AppData" file paths, but these indicate what programs were being used and not files of interest. To eliminate these, you can always:

vol -f memdump.mem windows.filescan | grep liber8hacker | grep -v "AppData"

This helps narrow the focus.

virtaddr

This next command uses the virutal address for the file of interest in order to pull the actual file contents from memory.

mkdir dump && vol -f memdump.mem -o dump windows.dumpfiles.DumpFiles --virtaddr 0xe0003d624b90

Now we can check what type of file we have extracted:

file dump/file.0xe0003d624b90.0xe0003f47b990.DataSectionObject.black_book.db.dat

dump/file.0xe0003d624b90.0xe0003f47b990.DataSectionObject.black_book.db.dat: SQLite 3.x database, last written using SQLite version 3035005, file counter 6, database pages 4, 1st free page 3, free pages 1, cookie 0x8, schema 4, UTF-8, version-valid-for 6

In this instance it's a sqlite3 file.

Show Tables

.tables

Results

aliases books

Show Schema (Structure) of a Table .schema aliases

Show the contents of each table

SELECT * from aliases;

SELECT * from book;

Binary Files¶

If you've got a binary file such as an ELF program, it is advisable to examine it using Linux-specific tools, many of which are baked into Kali Linux already. strace, ltrace, and gdb (GNU Debugger) are all Linux-specific tools.

readelf: Use this command to analyze ELF files and their structure, including headers and sections.
```
readelf -h executable
readelf -S executable
```
objdump: Another tool for disassembling binaries. You can use it to view assembly instructions and even extract strings from a binary.
```
objdump -d executable  # Disassemble binary
objdump -s executable  # View all strings
```
nm: Lists symbols in the binary. This can help identify exported functions, static variables, and more.
```
nm executable
```
strings: Extracts readable strings from a binary file, which can sometimes reveal sensitive information like hardcoded passwords or paths.
```
strings executable
```

strace¶

strace is a tool used to trace system calls and signals made by a program. It is useful for understanding the system interactions of a binary, such as file I/O, memory allocation, and network connections. It helps in debugging and reverse engineering, particularly when trying to understand how an executable interacts with the operating system.

Trace system calls made by a program¶

strace ./program

Trace system calls of an already running process¶

strace -p <PID>

Save the strace output to a file¶

strace -o output.txt ./program

Show only specific system calls¶

strace -e trace=<syscall> ./program

Filtering and Analyzing Specific System Calls¶

strace -e trace=read,write ./program

Count the number of times each system call is invoked¶

strace -c ./program

Suppress the output of certain system calls¶

strace -e !trace=write ./program

Vulns you may see when using `strace`¶

Unusual File Access: Look for excessive file reads or writes that might indicate a vulnerability like privilege escalation (e.g., writing to sensitive files).
Network connections: Connections to unexpected IP addresses could indicate remote code execution or data exfiltration vulnerabilities.
Unusual system calls: System calls such as mmap with overly large regions or execve with unknown arguments could signal exploit attempts like buffer overflows.

ltrace¶

ltrace is similar to strace but focuses on library calls (e.g., malloc, free, printf). It's useful for debugging how a binary interacts with shared libraries and dynamically linked code. While strace traces system calls, ltrace focuses on the function calls within the program itself.

Trace function calls made by a program¶

ltrace ./program

Trace function calls for an already running process¶

ltrace -p <PID>

Filter specific functions to trace¶

ltrace -e "malloc,free" ./program

Save the ltrace output to a file¶

ltrace -o output.txt ./program

Show only the function call names without arguments¶

ltrace -n ./program

Vulns you may see when using `ltrace`¶

Memory leaks: If a program allocates memory using malloc but never frees it with free, ltrace can be used to detect memory leaks that could lead to denial of service (DoS).
Improper use of library functions: Calling functions like strcpy or gets without proper bounds checking can lead to buffer overflow vulnerabilities.
Insecure library interactions: Look for interactions with insecure or outdated libraries which could introduce arbitrary code execution vulnerabilities.

GNU Debugger (GDB)¶

gdb is a powerful debugger that allows you to inspect and modify the execution of a program. It provides a rich set of features for disassembling, stepping through, and interacting with a program while it's running. It’s invaluable for reverse engineering, exploit development, and understanding how a binary works at a low level.

Debug an executable¶

gdb ./executable

Disassemble the main function¶

(gdb) disassemble main

List available functions¶

(gdb) info functions

Set a breakpoint at main¶

(gdb) break main

Call a function manually¶

(gdb) call functionName

Attach a process to gdb¶

gdb -p <PID>

Debug with a core file¶

gdb -c core ./executable

Execute given GDB commands upon start¶

gdb -ex "commands" ./executable

Start gdb and pass arguments to the executable¶

gdb --args ./executable argument1 argument2

Vulns often seen by examining binary in `gdb`:¶

Buffer Overflows: You can manually examine stack buffers, set breakpoints, and inspect memory to find places where unchecked buffers might overflow (e.g., through gets, strcpy).
Return-Oriented Programming (ROP): GDB can help identify vulnerable code paths that could be exploited through ROP chains, where an attacker hijacks the program’s control flow using small snippets of code (gadgets).
Heap Corruption: If the program uses dynamic memory allocation (via malloc), gdb can help identify vulnerabilities like double-free or use-after-free, which are common in heap management bugs.
Format String Vulnerabilities: GDB allows you to trace the format strings passed to functions like printf. If these strings are not sanitized, they can lead to format string vulnerabilities (e.g., arbitrary code execution via %n).