DAMM - Differential Analysis of Malware in Memory

项目说明

DAMM

An open source memory analysis tool built on top of . It is meant as a proving ground for interesting new techniques to be made a to the community. These techniques are an attempt to speed up the in process through data reduction and codifying some expert knowledge.

Table of Contents

* Features
* Usage
* Supported plugins
* Example
* Differencing
* Unique ID Manipulation
* Filtering
* Warnings
* Finally

Features <a name="features"/>

* ~30 plugins combined into ~20 DAMM plugins (e.g., pslist, psxview and other elements are combined into a 'processes' plugin)
* Can run multiple plugins in one in
* The option to store plugin results in SQLite databases for preser or for "cached" analysis
* A filtering/type system that allows easily filtering on attributes like pids to see all information related to some process and exact or partial matching for strings, etc.
* The ability to show the differences between two databases of results for the same or similar machines and manipulate from the cmdline how the differencing operates
* The ability to warn on certain types of suspicious behavior
* Output for terminal, tsv or grepable

Usage <a name="usage"/>

Supported plugins <a name="plugins"/>

See #python damm.py --info

apihooks callbacks connections de dlls e handles idt injections messagehooks mftentries modules mutants pri processes services sids timers

Example <a name="example"/>

Supply a profile as in , a memory image and a list of plugins to run (or 'all') to get terminal output:

To make these results persist in a SQLite db, just supply a filename for the db:

This will print results to the terminal as well as store them in 'my_results.db'

To see the results again:

(Note that you no longer need the memory image or to specify a profile, and the listing will come out pretty close to instantly regardless of how long the original processing took.)

If you later wish to see processes and other plugins:

Will:
1. consult the db for the 'processes' output
2. run the 'dlls' and 'modules' plugins
3. display the results
4. store the new results in the db

Once you ha some data in a db, you can query it with the -q switch

Plugins ha that can ha for filtering, e.g., for processes:
(use --info to see for all plugin attributes)

These attributes and types can be le by the differencing and filtering functions of DAMM

Differencing <a name="differencing"/>

To use the differencing engine, create 2 databases from 2 distinct memory images, such as one from before and one from after a piece of malware is executed

Then use the --diff option for the baseline db (here, the db from the uninfected memory image).

The results look similar to the 'processes' plugin output above, but there are some differences:
* Only results that are new in 'after.db' or that are in both dbs but have some attributes that changed from 'before.db' are displayed (the output here is snipped).
* Results that are only in the 'after.db' have 'New' in the first ('Status') column
* Results in that ha between the dbs have a 'Status' of 'Changed', and, importantly, denote the changes DAMM detected with '->': in the last line of output above the number of threads has changed.

Unique ID Manipulation <a name="unique-id"/>

In order to determine which processes exist in both memory captures abo the scenes certain attributes of processes are used to make a unique identifier for each. For example, by default DAMM used the pid, ppid, name, and start time as the unique identifier of a process. This makes sense as these things are unlikely to (shouldn't? can't?) change over the life of the process, as opposed to attributes like the number of threads and handles, which change constantly. This default set works fine for comparisons of objects from memory images from the same boot of the same machine (e.g., using ), but what about comparing across memory images taken from different boots of the machine? Or e machines? The pid, and ppid will likely not be the same, but the name, image path and command line should be.

Comparing a stock XPSP2x86 memory image with our image after some malware ran:

Results in every process being tagged as 'New' (except System) becuase by default we use the pid and ppid to make the unique identifier.

Because of this, DAMM allows the user to specify which attributes of some object can be used to create a unique identifier. If we tell DAMM to just use process name, image_path_name, and command_line, we get much more reasonable results:

DAMM now identifies fewer processes as 'New' (including the malware process), allowing the in to focus their efforts on these processes.

Filtering <a name="filtering"/>

With all plugins run on a small memory sample, we get ~14,000 memory objects: processes, dlls, modules, etc. What if we ha identified some process or string of interest? Grep can be problematic, especially when searching for pids, so DAMM includes a simple type and filtering system. To filter on objects that have a pid attribute of a certain value:

This can give a nice o of the objects associated with a process.

Even more powerful, diff and filtering can be used in conjunction. I have a memory sample from before a tdl3 infection and one after. Searching for the string 'tdl' in the before db results in ~600 hits. In the after infection db, there are ~730 hits. (Note that ntdll.dll contain the string tdl.) Using diff and filtering in conjunction as below results in only ~180 hits - a significant reduction. Note that for string and pid filtering, DAMM defaults to exact matching. Using the --filtertype partial option changes the fileterming to partial matching.

Warnings <a name="warnings"/>

In an attempt to make the triage process e, DAMM has an experimental warning system built in to sniff out signs of malicious activity including:

For certain Windows processes:
* incorrect parent/child relationships
* hidden processes
* incorrect binary path
* incorrect default priority
* incorrect session

For all processes, and loaded DLLs and modules:
* loaded/run from temp directory

For DLLs:
* bogus extensions
* hidden DLLs

Plus more!
* PE headers in injections
* SIDs giving domain access
* debug pri
...

See the warnings.py file for much more information on what DAMM checks for.

Thanks to the team for the Art of Memory Forensics book as well as the cheat sheet where many of these warning ideas came from!

Finally <a name="finally"/>

For questions or comments:
For bug reports, please use the github issue tracker.

项目信息

开发语言：Python

Star 数：214

技术要点

该项目属于病毒分析方向的开源资源，代码结构清晰，适合安全研究人员学习参考。项目围绕Differential Analysis of Malware in Memory展开，提供了可运行的实现，对理解相关安全机制、工具原理与攻防技术具有较高的研究价值。

从技术实现角度看，此类项目的核心在于对底层原理的深入理解与工程化落地。开发者在研究过程中可以结合官方文档与社区讨论，梳理项目的初始化流程、核心模块职责与数据流转，逐步掌握其中的技术细节与设计思路。

使用与学习建议

1. 下载源码压缩包，解压到本地环境。

2. 根据项目类型准备对应的运行环境与依赖。

3. 按照 README 中的步骤完成配置与部署。

4. 在隔离的测试环境中运行验证，避免影响生产系统。

免责声明

本资源来源于开源社区，仅供安全研究、技术学习与合法授权范围内的攻防演练使用，请勿用于任何非法或侵害他人权益的用途。使用本项目产生的一切后果由使用者自行承担。