-
Notifications
You must be signed in to change notification settings - Fork 353
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add application_execution tag to certain Amcache entries #4105
base: main
Are you sure you want to change the base?
Conversation
data/tag_windows.txt
Outdated
@@ -11,6 +11,7 @@ application_execution | |||
data_type is 'windows:registry:mrulistex' AND entries contains '.exe' | |||
data_type is 'windows:registry:userassist' AND value_name contains '.exe' | |||
data_type is 'windows:tasks:job' | |||
parser is 'winreg/amcache' AND data_type is 'windows:registry:key_value' AND values contains 'BundleManifestPath' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can you add a test for this as well in https://github.com/log2timeline/plaso/blob/main/tests/data/tag_windows.py
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please add missing test coverage
Yes. The test would probably look something like this: from plaso.containers import windows_events
...
# Test: parser is 'winreg/amcache' AND
# data_type is 'windows:registry:key_value' AND
# values contains 'BundleManifestPath'
event = events.EventObject()
event.timestamp = self._TEST_TIMESTAMP
event.timestamp_desc = definitions.TIME_DESCRIPTION_MODIFICATION
event_data = windows_events.WindowsRegistryEventData()
event_data.values = 'BundleManifestPath: [REG_SZ]'
event_data.parser = 'winreg/amcache'
storage_writer = self._TagEvent(event, event_data, None)
self._CheckLabels(storage_writer, ['application_execution']) Although I realized that I need to study this a little bit further. I'm trying to read this paper and am still somewhat confused in what cases AMCache has logged execution (which we're after) and when it's an installation. There's probably also a better search term than |
Codecov Report
@@ Coverage Diff @@
## main #4105 +/- ##
==========================================
- Coverage 85.59% 85.56% -0.03%
==========================================
Files 398 394 -4
Lines 33772 33488 -284
==========================================
- Hits 28907 28655 -252
+ Misses 4865 4833 -32
Continue to review full report at Codecov.
|
event_data.key_path = '\\Root\\InventoryApplicationFile\\7z.exe|afe683e0fa522625' | ||
event_data.parser = 'winreg/amcache' | ||
storage_writer = self._TagEvent(event, event_data, None) | ||
self._CheckLabels(storage_writer, ['application_execution']) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not use _CheckTaggingRule
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No real reason. I saw it written like this in other tests. Should I change it to _CheckTaggingRule
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, please, unless there is a specific reason not to, also see my comment about AMCacheFileEventData. The current filter rule is fragile since it tests a path as a string, not as a path using using PATH()
Looking bit closer at this why not filter on AMCacheFileEventData ('windows:registry:amcache') instead of the generic 'windows:registry:key_value' ? |
Because this particular artifact has that data type. |
Not really, it should create And AMCacheFileEventData which you could base your filter on as well, which would only trigger on events generated from data under the InventoryApplicationFile key in an AMCache.hve file https://github.com/log2timeline/plaso/blob/main/plaso/parsers/winreg_plugins/amcache.py#L448 |
Also none of the AMCacheFileEventData are "execution" events plaso/plaso/parsers/winreg_plugins/amcache.py Line 206 in 9172034
From: https://www.ssi.gouv.fr/uploads/2019/01/anssi-coriin_2019-analysis_amcache.pdf
where
so only for one of the categories to me this reads like, reproducible tests would be quite beneficial here. |
@pyllyukko any updates? |
No updates. I should take the time to look deeper into this and provide some example data for testing. Sorry for leaving this hanging and I'll try to find the time in the near future to get this finalized. |
Yes that would be great. I'll leave this PR open for now with the blocked and pending input tags. |
As I said earlier, the events this filter is after are not of that type. Here's an example event from the #3701 PR {
"__container_type__": "event",
"__type__": "AttributeContainer",
"data_type": "windows:registry:key_value",
"date_time": {
"__class_name__": "Filetime",
"__type__": "DateTimeValues",
"timestamp": 132210024057296460
},
"display_name": "OS:/data/evidences/win10-Amcache.hve",
"filename": "/data/evidences/win10-Amcache.hve",
"inode": "-",
"key_path": "\\Root\\InventoryApplicationFile\\csrss.exe|a9363ee544229f11",
"message": "[\\Root\\InventoryApplicationFile\\csrss.exe|a9363ee544229f11] BinFileVersion: [REG_SZ] 10.0.18362.1 BinProductVersion: [REG_SZ] 10.0.18362.1 BinaryType: [REG_SZ] pe64_amd64 FileId: [REG_SZ] 00002038501676866b87cee4514ceff77daea9729f30 IsOsComponent: [REG_DWORD_LE] 1 IsPeFile: [REG_DWORD_LE] 1 Language: [REG_DWORD_LE] 1033 LinkDate: [REG_SZ] 04/26/2034 22:06:31 LongPathHash: [REG_SZ] csrss.exe|a9363ee544229f11 LowerCaseLongPath: [REG_SZ] c:\\windows\\system32\\csrss.exe Name: [REG_SZ] csrss.exe ProductName: [REG_SZ] microsoft® windows® operating system ProductVersion: [REG_SZ] 10.0.18362.1 ProgramId: [REG_SZ] 0000f519feec486de87ed73cb92d3cac802400000000 Publisher: [REG_SZ] microsoft corporation Size: [REG_QWORD] 17808 Usn: [REG_QWORD] 0 Version: [REG_SZ] 10.0.18362.1 (winbuild.160101.0800)",
"parser": "winreg/amcache",
"pathspec": {
"__type__": "PathSpec",
"location": "/data/evidences/win10-Amcache.hve",
"type_indicator": "OS"
},
"timestamp": 1576528805729646,
"timestamp_desc": "Content Modification Time",
"values": "BinFileVersion: [REG_SZ] 10.0.18362.1 BinProductVersion: [REG_SZ] 10.0.18362.1 BinaryType: [REG_SZ] pe64_amd64 FileId: [REG_SZ] 00002038501676866b87cee4514ceff77daea9729f30 IsOsComponent: [REG_DWORD_LE] 1 IsPeFile: [REG_DWORD_LE] 1 Language: [REG_DWORD_LE] 1033 LinkDate: [REG_SZ] 04/26/2034 22:06:31 LongPathHash: [REG_SZ] csrss.exe|a9363ee544229f11 LowerCaseLongPath: [REG_SZ] c:\\windows\\system32\\csrss.exe Name: [REG_SZ] csrss.exe ProductName: [REG_SZ] microsoft® windows® operating system ProductVersion: [REG_SZ] 10.0.18362.1 ProgramId: [REG_SZ] 0000f519feec486de87ed73cb92d3cac802400000000 Publisher: [REG_SZ] microsoft corporation Size: [REG_QWORD] 17808 Usn: [REG_QWORD] 0 Version: [REG_SZ] 10.0.18362.1 (winbuild.160101.0800)"
} So to my understanding this could be an execution event. Here's RegRipper output for the same data/event:
But I'm still confused about the paper's "three categories" and in which circumstances they happen and how we distinguish between those. Any thoughts how to handle this? |
that is why reproducible test data is so critical. This is not my top priority at the moment but I'll give it some thought when time permits. |
One line description of pull request
Add
application_execution
tag to certain Amcache entries.Description:
More
application_execution
tags. I compared this tagging to RegRipper's output and with the test data I was using they produced the same results.Notes:
All contributions to Plaso undergo code
review. This makes sure
that the code has appropriate test coverage and conforms to the Plaso style
guide.
One of the maintainers will examine your code, and may request changes. Check off the items below in
order, and then a maintainer will review your code.
Checklist: