Category: Linux

Profiling Linux Binary

Posted on by randrada

Profiling Binaries in Linux Systems

Linux commands used in this demo.

      • ls
      • readelf
      • stat
      • cat
      • fdisk
      • istat
      • debugfs
    •  

An effective analyst must be able to conduct investigations on any operating system and knows how to retrieve on-disk evidence.

Scenario: A suspicious file was found on /tmp/mal_dir and you are tasked to perform live forensics on one of your organization’s Linux systems to investigate the file and gather its metadata.

In this demo, we will tackle about binary profiling in Linux systems and understand when the binary first existed on the system.

In Linux systems, we are limited to perform the investigation using only the terminal console.

First, let us check the directory where the binary was discovered using the built-in command “ls -al” is the first step in performing triage.

In our case, we can see a non-directory file named “credstealer“.

Next, we can check the binary’s file header by using “readelf -h” command.

In our case, readelf reveals us the binary’s header. 

Key Points to Remember:

Magic Number = 7f 45 4c .. .. (ELF Magic Number)

Class = ELF64 (MZ Dos in Windows, means credstealer is a x64bit executable)

Type = EXEC (executable file)

Entry Point = 0x4006e0

The stat command gives information about the file and filesystem’s size, access permission, user ID, group ID, birth time, access time and modified time of the file.

We can use this command to profile our binary by running the command “stat credstealer“.

Key Points to Remember:

Size: 8280

Inode: 1836028 (What inode does is it keeps track of all the files and directories within Linux System.)

Uid – 1000/linux-analyst (User = 1000, Root = 0)

Gid – 1000/linux-analyst (Group = 1000, Root = 0)

Access, Modify, Birth and Change Time (This provides valuable information when it comes to timelining an attack)

Note: Notice that birth time is blank which gives us less info when the file was first existed on disk.

In the previous steps, we extracted file’s metadata which reveals the Inode of the file.

Now, let’s use the Inode to extract additional information.

First, list mounted disk information by using “fdisk“. #command: sudo fdisk -l | grep sda

Next, Use Sleauthkit’s istat tool. #command: sudo istat /dev/<diskname> <inode>

Note: Sleauthkit’s istat displays the uid, gid, mode, size, link number, modified, access, changed times, and all the disk units a structure has allocated.

At this moment, we have revealed additional information but we still don’t know when the file first existed in the disk.

To answer this, we can use the tool “debugfs“. command: sudo debugfs -R ‘stat <inode>’ /dev/<diskname>

In this case, crtime or birthime reveals that on Aug 12 17:35:26 2022 the file “credstealer” was created in the disk.

Note: The debugfs program is an alternative file system debugger. It can be used to examine and change the state of an ext2, ext3, or ext4 file system.

In real world scenario, crtime/birthtime information can be used as starting point to perform your triage during incident response on Linux systems. This is information can also be used to correlate to different data sources (e.g., Network, System, and Event logs)

Live forensics should be done after duplicating the system’s volatile image/disk to avoid tampering and maintain the system’s integrity.

Dumping Linux Module

Posted on by randrada

Dumping Modules Associated with a Process in Linux Systems

Linux commands used to pull process modules.

      • pmap -d <PID>

Dumping process modules command: 

      • gcore -o <dest> <pid>

In this demonstration, we’ll use the built-in Linux tool “gcore” to dump an example process named bash with the process ID: 5885.

Scenario: We are instructed to examine this process on a live system under the assumption that bash:5885 is connecting a known malicious domain.

First, begin by using the command “ps aux | grep <target_process> ” to list every process that is currently active.

Next, run “sudo gcore -o <dir filename> <PID> ” after that. In this instance, 5885

Now, run “strings <dumped process> | grep .so” command.

#Tip: On Windows systems,.so, which stands for shared object, is similar to.dll.

#Tip: keep an eye out for unusual uses of common objects. search for anomalies. (For instance, the bash process makes use of the.so connection protocol to the internet.)

#Tip: Before doing live forensics, make a copy of the system’s volatile image.

Note: When a Linux system is vital and cannot be shut down for dead box forensics, live forensics is the only alternative.

Pulling Linux Modules

Posted on by randrada

How to Pull Modules and Libraries Associated with
a process in Linux Systems

Linux command used to pull modules history.

  pmap -d <PID>

Linux command used to pull process info.
      • ps aux
      • top
      • htop
 
    •  

Similar to Windows, when a Linux system exhibits unusual behavior, it is thought that an executable file, a malicious process, or a malicious library may be at play.

The analyst must be able to look at the Linux process and its related libraries during this occurrence.

When it comes to malware analysis, the most frequent disk artifacts that malware leaves behind on a compromised system are the launched processes, produced modules, and libraries.

Before we dive into main topic, let’s discuss first the difference between .dll and .so files.

DLL – Dynamic Link Library

SO – Shared Object

In Windows systems, a process’s related modules and libraries will have the.dll extension (e.g., wininit.dll)

The related modules and libraries of a process on Linux systems have the extension.so (e.g., libc.so)

These executables have a set of features that are required by the process for smooth execution.

To pull all the associated modules and libraries from a Linux process we use a built-in tool called “pmap“.

First, identify the malicious process using the command ps or top.

Next, identify the PID or Process ID.

Now, use pmap command to pull the modules.

>>script: pmap -d <PID>

Linux Script

Posted on by randrada

How to Document Script Execution in Linux Systems

Linux commands used to pull command history.

      • cat /home/<user>/.bash_history
      • history

Other commands used in this demo: 

      • script
      • md5sum

The analyst must record all the commands required to carry out the analysis while dealing on Linux systems.

Using a Linux built-in tool called “typescript” is one method of doing documentation.

This command records all keystrokes made on the terminal along with their results.

Simply enter “script” on the terminal to execute this command.

If typescript is already installed, a file named “typescript.txt” will be created on your desktop.

It is now able to capture every command script that will be run inside the terminal session.

Enter “exit” in the terminal to stop the logging session and save this file.

The typescript command is probably comparable to Linux’s “Bash History” and “History” commands, which keep track of all the scripts that have been run within the terminal.

Bash history can be found at: /home/<user>/.bash_history 

In this case, we can run the script below for demonstration.

>>script: cat /home/linux-analyst/.bash_history

>>script: history

Next, we can open our “typescript.txt” file.

We may now view logs that match those in our bash_history file.

It is necessary to record and protect the integrity of the files utilized by the analyst who completed the work while producing the report.

 

One of the investigator’s guiding principles is to record everything, and one method to achieve this is to use the built-in Linux function “md5sum” to hash the stored “typescript.txt” file.

>>script: md5sum typescript.txt