Digital Forensic Analysis - Foundation Level Wiki

Tags: #<Tag:0x00007f8a214e6d28> #<Tag:0x00007f8a214e6c60> #<Tag:0x00007f8a214e6b98> #<Tag:0x00007f8a214e6aa8> #<Tag:0x00007f8a214e69e0>

This is a draft Wiki article about the relationship between Computer Security Incident Response and approaches from modern Digital Forensics.

It includes a beginner-level technical focus on Information Security aspects and excludes Case Forensics topics, such as formality requirements for evidence acquisition like these infamous Chain Of Evidence issues.

The intention is to have an easily accessible Wiki page, and not another “eCrime Forensics” reference standard, written by someone who “never did it”. – Just some perspective. Feel free to share your’s.


##Summary:

Investigation methodology

A good investigation follows an independent methodology, which is focused on revealing high quality evidence.

Whether it’s traditional crime or digital intrusion analysis. Whether it’s information security incident response or threat hunting. Analysts focus on facts, which can be used to narrow down what happened, and how impactful it is.
This is valid for Incident Response (IR) as well as for the Digital Forensics (DF).
– Therefore we call the topics around the investigation methodology DFIR (Digital Forensics and Incident Response).

  • In IR the focus is on eradicating threat from the environment.
  • In DF it may not be so different after all. However DF, in a strict definition, will not change the environments in scope

The technical methods in DFIR differ between Operating Systems and environments. The foundational forensic workflows do not.

The following steps are common:

  1. goal number 1 is to get a timeline of the entire environment (activities). What happened? When did it happen? Who caused it? From where was it caused. Back in the days, when we had mainframes and monolithic servers, forensics focused on one system at a time. Nowadays systems are distributed.
  2. is the activity common for Malware, eCrime or scenarios with disgruntled employees (the Why)? Is this an accidental insider with too much access, who got targeted by a Malware?
  3. Based on 1.) and 2.) can we derive a possible motivation for the attacker / “threat actor”? Was there a monetary incentive? In many cases we cannot attribute the incident to a certain person. That is not a problem, as long as we refrain from unprofessional guesswork. If there is a grey area, we can report it as such.

Incident Response and acquisition - foundation and Domino effect

99 % of Forensic Analysis focuses on 1 % of the data.

How we acquire artefacts in order to carve out the existing evidence via the proper analysis steps is most important. If we make mistakes during these initial phases, the rest of our analysis can suffer from a Domino effect of cascading failures, leading to wrong or incomplete assessments.

  • in IR this means, that you need to pay close attention to the way the respective software works
    • there are softwares for Enterprise Detect and Response (EDR), that store the artefacts (traces for timeline analysis) on the local system only. Threat actors can manipulate this.
  • in DFIR this means, that writes to the systems under investigation must be avoided. For certain scenarios there is emphasis on hardware and software writer-blockers. Often these have to be certified.

In Incident Response an incomplete eradication of an infected enterprise network means, that the attackers are likely to return; with better techniques, and they will be harder to detect. Due to this the IR team will have to define new Indicators of Compromise (IoCs), because the threat actors have learned to evade the security team. And at some point it can become unclear whether they are gone, or whether the detection just failed. This is a grey area.

In Digital Forensics an incomplete assessment may mean, that doubt cannot be eliminated: In dubio pro reo. Sometimes it’s not possible to get back to the acquisition of evidence. Cases get closed. Anti-Forensics may have gotten applied. A re-investigation is always harder, because the more time passes, the less likely it is that new evidence appears.

A side note on EDR tooling in enterprise environments under the GDPR

In order to enable Incident Response Readiness (to be able to react to threat actors) organisations tend to introduce security tools. EDR tools can only be effective if they send the security traces to a central server, so that they cannot be tampered with locally.

However these security traces may contain Personally Identifiable Information (PII). Under GDPR / DS-GVO and other EU-wide privacy laws these information have to be protected, and users have Individual Rights. {1}. Furthermore the collection of PII is supposed to be reduced.

The key is GDPR Article 28, Article 33 and 34. Incidents must be reported within a time period (usually about 72 hours) and systems that have PII must be protected.

Usually EDR software aims to collect system data (like Microsoft Sysinternals tools), and no Personal Data or Intellectual Property. We need to be careful what we kind of EDR we select. Generally though GDPR is not an obstacle for EDR. On the contrary: EDR software is used to help in DFIR to quantify data-breaches, even on an individual basis.

References

{1} GDPR summary

The relevance of evidence categories for Timeline Analysis

Before we get to Timeline Analysis we need to establish the basics. Everyone wants to derive the timeline from “the digital evidence”, but patience is key to forensic works.

– Forensic tools have limits. If you don’t understand these limits, you don’t understand the timeline.

There are two kinds of File System images:

  • a Disk Image (1:1 copy) and
  • a Triage Image (relevant artifacts).

It might not always be necessary to acquire a full Disk Image. These can be multiple terabytes in size and hard to archive due to this. Whether or not we need a Disk Image depends on the evidence categories we aim for.

Examples of triage focus areas:

User Communication may reside in select history files, such as the Browser History, or Chat Client files. Commonly these artefacts would reside in the respective Windows User directory.

File Downloads often get stored at a default directory in the User directory.

Program Executions are recorded in Logs (Eventlog, Syslog); or on Windows systems they may also be in the Windows Registry. There are also certain Windows folders with cache data, to reduce the load times. These files will contain information about the recent activity.

USB Key Usage can be tracked via various means, including the Windows Disk Signature.

Depending on the focus of the investigation it may be faster and simpler to create a Timeline from a Triage Image, which is built with only the relevant artefacts. Now how do you determine which artefacts matter for the assessment at hand? – Experience.

File Systems Acquisition and Analysis - in short

For File System forensics the usual terminology is:

  • Physical Layer – disk drive itself. This is rarely analysed, because a physical data reconstruction is very costly, and requires laboratory access.
  • File-System Layer – partition information. There is the GUID Partition Table (GPT) standard, or the older Master Boot Record (MBR) standard. When Apple migrated Mac OS X to the Intel x86 architecture the Apple Partition Map (APM) standard became deprecated.
  • Data Layer – usually a file system addresses entire clusters, which group sectors. Depending on the file system standards, this works differently (often there are parameter options).
    A sector is a logical segment of information on a particular track, and is the smallest addressable unit of storage on a disk. A block is defined as a group of bytes handled, stored, and accessed as a logical data unit, such as an individual file record. There are different imaging approaches for the Data Layer, which need to be considered: for example sector-wise, block-wise or file-wise.
  • Metadata Layer – structure infos and organization, like ext3/4, FAT, NTFS, HFS+, AFS…
  • File Name Layer – names of files, directory hierarchy

Examples:

  • Forensic identification can be simple if the NTFS partition stats at sector 63, because it’s (99% likely to be) Windows XP. Sector 0 … 63 represent the MBR on such deprecated systems.
    The MBR contains boot instances and the partition table entry lists. There you can find the number of sectors per partition and the type flag (which may not match).

  • An MBR uses 512 Bytes. It allows partition sizes up to 2 TB. A GPT uses 4096 Bytes, allows up to 16 TB. GUID is known to be more reliable, and it can handle more than 4 partitions; without having to use extended partitions {1} {2}.

Lab Example: diskpart belongs to Windows systems (since Windows 2000).

DISKPART> list disk

  Disk ###  Status         Size     Free     Dyn  Gpt
  --------  -------------  -------  -------  ---  ---
  Disk 0    Online          238 GB    17 MB        *
  Disk 1    Online          465 GB  1024 KB        *

DISKPART> select DISK 0

Disk 0 is now the selected disk.

DISKPART> DETAIL DISK

NVMe THNSN5256GPUK NV
Disk ID: {8E9EE789-161D-4B81-B254-...}
Type   : RAID
Status : Online
Path   : 1
Target : 0
LUN ID : 0
Location Path : PCIROOT(0)#PCI(1700)#RAID(P01T00L00)
Current Read-only State : No
Read-only  : No
Boot Disk  : Yes
Pagefile Disk  : Yes
Hibernation File Disk  : No
Crashdump Disk  : Yes
Clustered Disk  : No

  Volume ###  Ltr  Label        Fs     Type        Size     Status     Info
  ----------  ---  -----------  -----  ----------  -------  ---------  --------
  Volume 0     C   OS           NTFS   Partition    224 GB  Healthy    Boot
  Volume 1         ESP          FAT32  Partition    500 MB  Healthy    System
  Volume 2                      NTFS   Partition    982 MB  Healthy    Hidden
  Volume 3         Image        NTFS   Partition     12 GB  Healthy    Hidden

Ok, now the partition information:

DISKPART> list partition

  Partition ###  Type              Size     Offset
  -------------  ----------------  -------  -------
  Partition 1    System             500 MB  1024 KB
  Partition 2    Reserved           128 MB   501 MB
  Partition 3    Primary            224 GB   629 MB
  Partition 4    Recovery           982 MB   225 GB
  Partition 5    Recovery            12 GB   226 GB

DISKPART> select partition 2

Partition 2 is now the selected partition.

DISKPART> detail partition

Partition 2
Type    : e3c9e316-0b5c-4db8-811337-...
Hidden  : Yes
Required: No
Attrib  : 0X8000000000000000
Offset in Bytes: 525336576

There is no volume associated with this partition.

– Wow, a hidden partition. Do we have a criminal here, who is using anti-forensics tactics. Time for the handcuffs?

No… it’s the SYSTEM UEFI partition. If you are interested in this, check the next section on the UEFI. Hidden partitions are standard to avoid, that users destroy their computers.

Volume 2 and Volume 3 could be interesting. - Anyone can set any type flag in a GPT. But in this case it’s simply the recovery image for the Original Equipment Manufacturer (OEM). In other words: this is a common computer system, like the vendor sold it. Don’t get your hopes up too early. :wink:

  • Windows (7, 8.1, 10, 2008 Server, 2016 Server, …) creates a (hidden) SYSTEM_DRV with utilities and the Boot Configuration Data (BCD) Registry Hive. This is useful for Bitlocker and / or TPM, for example. But this also means that Bitlocker isn’t Full Disk Encryption per definition. The SYSTEM_DRIVE does not get encrypted.
    • Bitlocker needs two logical partitions. This is one of the indicators to forensically determine the type of disk encryption, that is being used.

So far: from this lab exercise we know the following:
– if the hidden partition is for the system, it’s
a) not encrypted
b) flagged with the SYSTEM type in GPT
c) about 500 MB in size.

We also know that recovery partitions a) aren’t supposed to be extra large, because users want to use their disks. 1-2 Gb and 12 - 20 Gb are typical, depending on the amount of extra software. b) flagged as RESERVED c) usually they are the last partitions on the OS disk.

Windows can be installed drives other than C:. But this would be configured in the bootloader, which resides with the UEFI; speaking of modern systems.

References

{1} Forensic Analysis of GPT Disks and GUID Partition Tables, by Bruce J. Nikkel (2009)

{2} GPT in Windows

The UEFI

Modern systems may have a Unified Extensible Firmware Interface (UEFI). On Windows the UEFI can be mounted (with elevated privileges). The following example assumes that X:\ is not used.

mountvol X: /S
X:\EFI>ls
Boot  Dell  Microsoft

X:\EFI>ls *
Boot:
bootx64.efi

Dell:
logs

Microsoft:
Boot  Recovery

Usually there are no hidden files there. But you should consider that this is a hidden 500 MB partition!

image

There are images in this directory:

X:\EFI\Microsoft\Boot>file SecConfig.efi
SecConfig.efi: PE32+ executable x86-64, for MS Windows

As you can see this is a 64 bit PECOFF {1} executable for Windows. This is part of the Windows bootmgr.efi. These utilities are like Lilo or Grub2 in so far that they pass parameters to the kernel.

On a Windows system you’d configure the Boot process with bcdedit. Sometimes Rootkits instantiate their functions and manipulate the boot process in order to inject themselves early (before the integrity checks). If you suspect something like this, you should take a look at Hivex and deepen the investigation.

You can also quickly hash the files. These should be similar throughout the organization, depending on the hardware / OS. That might be fast way to determine if it’s worth to check out this part of the system.

References

{1} PE standard for Windows

Encrypted Disk Detector

Magnet’s Encrypted Disk Detector (EDD.exe) is sometimes mistakenly described as a part of the Microsoft Sysinternals suite. It is not from Microsoft.

It is a standalone utility, that is freely available. It’s a standard component of a Forensics tool-set, and using it is straight forward. Hint: I don’t use it, and here is why:

Example:

The lab system uses Bitlocker on C: and a mounted VeraCrypt volume is online. There are a bunch of remote file systems (“Cloud file systems”). C: and S: are encrypted volumes. The following example uses a newline and a λ and as the prompt separator for cmd.exe.

C:\Users\marius\Downloads
λ  .\EDD.exe

Encrypted Disk Detector v2.1.1
Copyright (c) 2009-2017 Magnet Forensics Inc.
http://www.magnetforensics.com

* Checking physical drives on system... *

PhysicalDrive0, Partition 1 --- GPT Partition(s)

PhysicalDrive1, Partition 1 --- GPT Partition(s)

* Completed checking physical drives on system. *
* Now checking logical volumes on system... *

Drive C: is located on PhysicalDrive0, Partition #3.
Drive D: is located on PhysicalDrive1, Partition #2.
Drive E: appears to be a virtual disk
  - possibly a TrueCrypt or PGP encrypted volume
Drive F: appears to be a virtual disk
  - possibly a TrueCrypt or PGP encrypted volume
Drive G: appears to be a virtual disk
  - possibly a TrueCrypt or PGP encrypted volume
Drive H: appears to be a virtual disk
  - possibly a TrueCrypt or PGP encrypted volume
Drive S: appears to be a virtual disk
  - possibly a TrueCrypt or PGP encrypted volume
Drive X: is located on PhysicalDrive0, Partition #1.

* Completed checking logical volumes on system. *
* Now checking for running processes... *
* Completed checking running processes. *

*** Encrypted volumes and/or processes were detected by EDD. ***

We can see that EDD has limits: a) it still refers to Truecrypt (this is the newest version, of 2018). Truecrypt is a discontinued product. b) It mistakes Cloud-mounts for encrypted file-systems. c) does not even notify of the possible use of Bitlocker. In other words: it has failed. Horribly.

We can use dd on Windows to enumerate the volumes in a more verbose fashion to understand the reason for this:

C:\Users\marius\Downloads>dd --list
rawwrite dd for windows version 0.5.
Written by John Newbigin <[email protected]>
This program is covered by the GPL.  See copying.txt for details
Win32 Available Volume Information
\\.\Volume{546813eb-366f-4a61-9d58-...}\
  link to \\?\Device\HarddiskVolume3
  fixed media
  Mounted on \\.\c:

\\.\Volume{0fa36f1e-29b0-4a27-9180-...}\
  link to \\?\Device\HarddiskVolume11
  fixed media
  Mounted on \\.\d:

[...]

\\.\Volume{5110c8a1-def2-11e6-bd1e-...}\
  link to \\?\Device\VeraCryptVolumeS
  fixed media
  Mounted on \\.\s:

NT Block Device Objects

Virtual input devices
 /dev/zero   (null data)
 /dev/random (pseudo-random data)
 -           (standard input)
[...]

Now this looks quite interesting. VeraCrypt sounds like we already have identified an encrypted disk. Check.
Bitlocker was not identified. Fail.

Due to this we need to double check the results of EDD and dd. Forensic tools have limits.

Windows artefacts matter

  • Win XP and 2k3 share many artefacts
  • Win 7 and 2k8
  • Win 8(.1), 10, 2012 and 2016 Server

This is also relevant for volatile (RAM) data acquisition. Before we go further into File System forensics, which is relatively straight forward, we can take a practical peek at applied Memory Analysis on a Windows 10 lab system.

Beyond the myth of all-powerful Memory Analysis

The forensic term I use for “RAM dumping” is volatile memory acquisition, or in short “memory analysis”. It’s important to know what Memory Analysis can be used for:

  • Analysis and reverse-engineering of File-less / Memory-only Malware. This kind of Malware often comes with injection methods, that do not make use of persistent file changes.
  • Detection of Anti-Forensics. Sometimes suspects may use Privacy Cleaners and other methods to hide evidence.
  • Crypt-analysis against an implementation, that caches secrets. RAM is a shared resource on a modern computer system. Dealing with secrets in cryptologic implementations is hard, because you need to allocate the data structures which hold the secrets, while keeping this aspect in mind.
  • Detection of Code Injection. Code Injection may happen as part of a Software Exploit, that hijacks the execution flow of a target program, and rewrites parts of its structures in order to inject foreign functions in stages. For example an exploit may have a stage 1 payload, that gets written into the target app’s process memory. The stage 1 payload may load a stage 2 backdoor or some sort of covert channel to exfiltrate data or intelligence from the compromised system.
  • Rootkit analysis. Rootkits exist in various forms. They can make use of Process Hollowing and DLL Injection in order to patch or replace User Mode or Kernel Mode calls or functions.

Memory Analysis is not limited to just string or byte searches any more. But still, devs rarely obfuscate strings or even hardcoded secrets. And I don’t refer to Malware authors as devs.

In opposite to traditional File-System image analysis Memory analysis cannot always get you complete

  • System Information
  • Volume Information
  • Logged On Users
  • File listings
  • Autostart Persistence information
  • Encryption Detection (apart from residual keys in memory, as mentioned)
  • Network Config
  • ARP Tables
  • DNS Cache
  • NetBIOS cache
  • Files opened on the system remotely

Due to this Memory Analysis is very useful, but we need to be aware of its limitations. It may not be complete, and help to identify parts of the information.

In order to chose the right tool for the job, take a look at the compatibility information.

Example with FTK Imager Lite

It’s mentioned in a later section as well: for Incident Response acquisition please start FTK from a USB stick, and not from the local system.

Go to File → Capture Memory:

image

Preferably the destination is on the USB stick as well, which should have enough free space. I don’t recommend to dump the memory to a CIFS share, for obvious reasons.

image

You will also see that the FTK AD1 format is offered to immediately image the dumped RAM. Whether or not you are required to do this depends. This is related to “Hashing” of the data, and to keeping the evidence. RAM cannot be hashed like a file, because it remains in a state of continuous change.

If you want to conduct an analysis of the RAM image, you can load it into volatility, for example. There are many tools for this.

From FTK Imager Lite into Volatility - with SANS SIFT

The SANS DFIR community maintains a Linux distribution / appliance called SIFT. It comes with a recent version of the volatility framework. It’s useful for timeline analysis.

How does Memory Analysis get applied on Smartphones, like iPhones or Androids

iOS and Android are the most common Smartphone Operating systems. They do have in common, that they share similarities with Unix.

But they are locked down, e.g. with read only file systems, and usually users do not have administrative privileges; ignoring jailbroken systems. In following this paragraph will focus on iOS, to keep things simple.

Recovery Mode based acquisition from Apple devices - in short

Usually you have to reset the Apple device into Recovery Mode, just to acquire some File System data from the Smartphone directly {1} (ignoring that you can grab backups and other files from another system {5}). Also ignoring jailbroken iOS devices.

  • As far as I know UFED (User Lock Code Recovery Tool) Touch based acquisition does not work against iOS 11. Celebrite for example only supports the iPhone <= 5 and iPad <= 4 (up to) {2} {5}.
  • We can use IEF’s Physical Analyzer on newer Smartphones, but the results depend on the model {5}.

I don’t think that it is possible to get memory images from locked iOS devices without a physical or a kernel exploit {5}. There are no JTAG ports, and you cannot “just” Chip-Off the memory, and perform a Cold Boot Attack. There are such approaches, but I highly doubt that this is legal since this destroys someone’s property.

So we need to unlock the device.

iOS File System imaging takes time {3}. A modern iPhone may have over 200 GB disk space. But do we really need a Disk Image? Can’t we use a Triage Image?

  • Most Apps today (WhatsApp, FB, SnapChat…) use Sqlite DBs, which can be extracted for Forensic analysis. Once you have access to the device, you may be able to use XCode to download the Sqlite files.
    • Then you can use Frida and fridump. Then you may have a memory image, to bypass other controls, which may have their own authentication schemes.
  • Smartphones upload everything to the Clouds. Generally network interception may yield fast and useful results, with reasonable effort. Because few App devs pin TLS / SSL certs.
    Note that iCloud backups usually are limited to WiFi connections, but modern iPhones don’t auto-join open Hotspots.
    • So you probably want something like a PWNPlug with Evil AP, or a WiFi Pineapple. Then you may get a valid SSID.

Summary: Yes, we can! But these days (early 2018) we may refer to other techniques in our Forensic repertoire. Like cracking a Smartphone Pin, intercepting network traffic and using backup files… the usual stuff. This is the Foundation Level Wiki post.

References

{1} Elcomsoft iOS Forensic Toolkit - Logical acquisition

{2} Forensics Wiki for iOS

{3} Versatile iPad forensic acquisition using the Apple Camera Connection Kit

{4} Forensic Analysis of iOS devices

{5} iOS FORENSICS: WHERE ARE WE NOW AND WHAT ARE WE MISSING? (2016)

Windows Triage Disk Image

As mentioned: Triage Images are important to focus. We are looking for certain activity related kinds of data on Windows systems. Please take the following table as a cheat sheet, and not as a comprehensive listing.

Acquisition item Where? - Example “Unix” pendant References
Boot Configuration Data Hive hidden partition in /boot refer to the UEFI section
Registry Hive
LNK files these are links
Jump Lists - recently accessed files and tools e.g. %APPDATA%\ Microsoft\Windows\Recent\ AutomaticDestinations
Prefetch data - trace of file activity (slide 55) %SystemRoot%\Prefetch
Eventlogs / Plug & Play logs - including USB device history %SystemRoot%\System32\Winevt\Logs
Browser data
Recycle bin
Master File Table
NTFS logs
Journal log
Pagefile
Hibernation file
Crash dumps (see the diskpart section - there is a disk dedicated for crash dumps)

Related to a subsequent section on Forensic Live Response, I want to leave it as a recommendation to triage through artifacts of possibly still infected systems. Given that modern Endpoint Protection / AntiVirus tools often fail to kill the processes and too often only kill the Downloader or Dropper stub.

Forensic Live Response

  • Sysinternals has a list of tools, which can be used for Live Response. It can be used in conjunction with cmd.exe or Powershell. If there is a .exe suffix in the following table, this indicates that it’s a Sysinternals tool.
  • The Mobile column refers to Apple iOS only for now, because I don’t work with Android these days
  • The Memory column, this refers to volatile data acquisition

System State Acquisition tools - Windows

The following table is not meant as a copy & paste reference. If you have to gather the data from an infected system, you may have to use a read-only USB stick with a trusted cmd.exe. You would redirect the output to file(s) for log2time / plaso or similar investigation tools.

Nowadays most Microsoft Windows Endpoints do have Powershell. The mentioned utilities are still relevant.

Acquisition item Windows >= XP , Server 2000 Mac OS X, Linux, BSD, Unix Mobile Memory
System date and time date , time date - Possible
System Information PsInfo.exe, systeminfo cat /proc/*info - Possible
Volume Information mountvol , diskpart , vssadmin mount, ls /dev/ , parted - Possible
Autostart (persistent) Autorunsc.exe, msconfig rc.d / systemctl, Desktop env - Possible
Scheduled tasks at , schtasks crontab, at - Possible
Process list PsList.exe , tasklist ps aux - Possible
Process list with full basepath Tlist.exe ps aux - Possible
List of services net, PsService.exe rc.d / systemctl, Desktop env - Possible
Loaded DLLs, SOs Listdlls.exe ldd - Possible
Process handles Handles.exe - - Possible
Drivers Listdrivers.exe modprobe -l , cat .config - Possible
Network config ipconfig /all ifconfig -a, ip addr - No
ARP table arp -a arp -a - No, afaik
Routing table netstat -rn , route PRINT route show - No
DNS cache ipconfig /displaydns nscd is broken, check browser or Systemd - No
NetBIOS cache nbstat -c nbtstat -n -A - No
Network connections and Sockets netstat -an , Openports.exe -fport netstat -tulpen - No
Remote file handles PsFile.exe lsof - No
Users logged on PsLoggedon.exe w, ps aux - Possible
Encryption enumeration EDD.exe ls /dev/luks/ - Residual keys or artifacts with entropy

cmd.exe

Command Example IR Live Use Case
start start D:\IR\cmd.exe Starts trusted cmd.exe (may not work in IR though)
sc sc query type= driver > %Temp%\drivers.txt Enumerates drivers
sc sc query WinHttpAutoProxySvc Enumerates services, specifically WPAD here
type echo DRIVERS && type %TEMP%\drivers.txt print a file
reg reg query HKCU\Software\Microsoft\ Windows\CurrentVersion\Explorer\RunMRU /S Start → Run dialogue history (e.g. for Autohotkey Malware)
control shedtasks - Open up the Task Sheduler GUI, where some Malware might have build a autorun
set set PATH & set USERNAME Did something manipulate the environment? Print PATH and Username, one after another.
echo echo %date% %time% & cd %UserProfile% Use some shortcuts
dir dir /aHD C:\ | find /i "loader.exe" Also list hidden directories, and grep for loader.exe

Mixed Examples

Get a specific line in a file

C:\Users\marius>sc query | findstr /N HTTP
1303:DISPLAY_NAME: WinHTTP Web Proxy Auto-Discovery Service

What I am looking for is in line 1303. So let’s use some Powershell:

 (Get-Content .\services.txt)[1300 .. 1310]

SERVICE_NAME: WinHttpAutoProxySvc
DISPLAY_NAME: WinHTTP Web Proxy Auto-Discovery Service
        TYPE               : 30  WIN32
        STATE              : 4  RUNNING
                                (STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0

It makes no sense to reference the old cmd.exe loops, because XP isn’t supported any more.

Keep in mind

  • On MS Windows . is implicitly part of the PATH. Afaik .com still takes preference over .exe. That means that the suffix matters.

Incident Response investigation and analysis

According to popular reports (Mandiant M-Trends, Trustwave Global Security Report 2017, Verizon DBIR) we have the problem that even Fortune Global 500 organizations with large security teams need more than 90 days to detect an intrusion. The problem is that attackers can cause a lot of harm during this time. Even if we get much better and reduce it by 50%, it’s still more than a month.


  • Did you know that modern Anti-Virus software is signature and behaviour based? - Probably yes. Did you know that the Anti-Virus engines often fail to identify all the artefacts and may leave Malware processes active on the “protected” system? These processes may load other Malware, that does not get detected. It is very common for attackers to “try more often”. Due to this Malware alerts should be reviewed independently of the Anti-Virus vendor ratings.

Many organizations, including Small and Medium Businesses (SMBs), have major issues with Incident Response and timely security incident detection. Getting more versatile and effective detection requires people, process and technology changes in the affected organizations; which include every Fortune Global 500 company and the majority of SMBs.
If you take a look at the ISO 27001 standard, clause 5.1 requires management commitment {1}. The same is true for PCI DSS, depending on the ROC / SAQ level {2}.

  • For companies, which process data of Europeans, GDPR may apply, which has specific requirements for Incident Handling and Data Breach Reporting.

The GDPR separates responsibilities and duties of data controllers and processors, obligating controllers to engage only those processors that provide “sufficient guarantees to implement appropriate technical and organizational measures” to meet the GDPR’s requirements and protect data subjects’ rights. Processors must also take all measures required by Article 32, which delineates the GDPR’s “security of processing” standards.

(Source: IAPP article, references EU GDPR Article 32, 56 et seq.)

Incident Response requires tactics. If you detect an attack, which is using new techniques to gain unauthorized access horizontally and vertically through the entire organization, chances are good that the attackers will regain the access if you don’t have a 100% solution. These kinds of attacks can escalate into subversive multi-vector threats (multiple new exploitation techniques get used), and often get classified as Advanced Persistent Threats. Shutting such attackers down requires a lot of effort and strategy.

Incident Response needs to scale for all endpoints of an organization. Commonly the most likely and impactful threats to an organization are Phishing, Internet browsing and authentication {3}. That being said, all of these tasks are Endpoint related (including Thin Client setups). Doing Forensic Incident Response, with a tactical focus, across 1000s of different Endpoints, is a complex challenge. Generally it’s much better to think about this before the security incident occurs.

Speaking of Forensic Analysis, Incident Responders needs to be familiar with concepts such as Timeline and Memory Analysis. This isn’t part of a common university curriculum. This needs to be trained regularly, and due to the Enterprise’s specific needs it may also require internal training programs. Every service provider will have unique and special services.

Last but not least Malware Analysis is a significant part of Incident Response.

Computer Security Incident Handling

NIST has a Computer Security Incident Handling Guide (Special Publication 800-61). Standards like PCI DSS reference this, in order to suggest a basis for proper policies and procedures.

SANS has published a set of Incident Handling Forms, which can support the implementation of proper handling routines, based on trained processes.

  • There are legal and management tasks related to Incident Response, which we are going to skip here so that this little Wiki post does not become a library section. In order to reference these tasks accordingly a connection to ISO 27k, GDPR and PCI DSS is drawn, which can be followed via the Reference-section links.

Essentially the SOC workflow is:

  1. Preparation - this is the general phase, in which networks, systems and applications get secured; monitored continuously in modern environments with Continuous / Agile practices.
Step Target example Intelligence Strategic steps
Endpoint visibility Gather activity traces Know what is normal Anomaly detection, activity sediment cluster analysis
Central Logging Windows Processes and Apps Enumerate applications Find new / unwanted SW
Database Monitor Service data in DBMS Enumerate queries for information Detect compromise via data tokens, which cannot be requested via the normal app behavior

Security Information (and Event) Management can allow the Security Operations Center (SOC) team to effectively monitor the environments. I use this term in a lose way here, because common Logging Systems may already provide some traceability.

  1. Detection and Analysis - Detection and Analysis happens based on an Alerting scheme. The affected systems need to be identified, enumerated and the response needs to be scoped. It is not advisable to “pull the plug”, because this notifies the attackers of the detection. The analysis needs to conclude with a list of the affected systems, the approaches which have yielded the artifacts, and a clear engagement strategy.

Endpoint Management and Control is the task, which scales Incident Response over the User and Service Endpoints of an organization.

  1. Containment, Eradication and Recovery - with Managed Security Service Providers (MSSPs) you may read, that they advertise response times. Like “From Incident to Detection within 15 minutes.” That sounds much better than what Mandiant and Trustwave state (over a month). How can these MSSPs do that? Magic? - No, read the fine-print. Generally it is not advisable to eradicate partly enumerated incidents, because the re-occurrence can become costly to deal with. Given that most organizations struggle with timely Patch and Update Management, it is very likely that the attackers come back quickly. And that they will be harder to detect next time. Half-baked Incident Response helps no one.
Attack Remediation example Intelligence Strategic steps
Distributed Denial Of Service (DDOS) DNS switch with low TTL, BGP swings Threat Feeds may reveal some intelligence about the botnet(s ) Understand the size and composition to enhance the network traffic filters and speed up the detection
User Endpoint Malware attack (via Phishing) Isolate infected hosts and cleanup the systems, derive an action plan (e.g. password changes, …) Gather Malware telemetry for IOCs Setup an isolation network and record the behavior in order to derive signatures, share the signatures with the security community
Successful SQL injection attack against Web service Prevent data leaving the networks, get DevOps team to patch the issue and deploy asap This is a AppSec / dev issue. Web App Firewalls can only help to delay the attackers Secure Software Development, DLP / WAF signatures, make sure you gather enough evidence to quantify the breach in order to follow legal and compliance obligations

Definition of Indicators of Compromise - after the eradication and recovery organizations want to re-detect the attack, which caused the incident. The lessons, which have been learned, need to be applied. There needs to be some ROI for all that Incident Response work. That is the IOC, which is used to identify the attack based on a signature. There are many different ways to express attack characteristics.

  1. Proactive Threat Hunting - making use of the IOCs on systems, which have been attacked / compromised before. If you are at a point, where you can attribute certain IOCs to specific attackers, you are aware enough of the incidents. Usually SOCs deal with internal and external Thread Indicators, in order to continuously improve the detection quality.
Threat Remediation example Intelligence Strategic steps
New vulnerability or exploit Patching, Mitigating Understand Time-to-Patch Know the patch problems, engage stakeholders
Password compromises Policy & Procedure Password Reuse needs to be detected Limit access for affected employees, introduce login anomaly detection and / or 2-Factor

Configuration of Security Systems, Improvements of ISMS - it is important to learn from security incidents. They are normal. False Positives need to be eliminated. Don’t forget to regress-test for False Negatives. You need to find a balance between the sensitivity of the security systems and the validity of the alerts.

Process Procedure Intelligence Strategic steps
Strengthen Change Management Review approval workflow Score approves Employee training, management sensitivity, e.g. via System Loss Expectation (SLE) - quantitative Risk Assessments
Enhance Network Visibility Focus on IT Asset Management Define proper catalogs Check on management tools, network segregation etc.
References

{1} Section 5, ISO 27001, plain English

{2} PCI DSS 3.2 - prioritized approach, PCI SSC, requirement 12.4.1

{3} Cybersecurity Basics: A Primer on Risk Management, Stratfor

Correlation of Network and Endpoint activity

Today it is not possible to detect attacks, when the transparency is limited to either the endpoint or the network.

Due to this we look at correlation. We want to cross-reference the information between different security systems. However the products of security vendors are rarely compatible to each other. Therefore we have to plan our security architecture in order to fulfil the requirement of Network and Endpoint Correlation. Preferably the security systems are from different vendors and are being developed independently from each other to avoid vendor- or product specific gaps.

TBC (draft)