[auditbeat][windows] file changes events are generated although no changes

[fixed77]

auditbit generates change events for some files, although there were no file changes.
Below is an example of an event.
The time it takes to create and modify the file is different from the time of the event. I found the initial_scan event of this file in logs. All fields are completely identical, including the sha1 hash of the file.

Created event:

{
  "_index": "auditbeat-xxx_log-2020.03.28",
  "_type": "_doc",
  "_id": "v6l0HnEBt3RRCzaXyPfB",
  "_score": 1,
  "_source": {
    "@timestamp": "2020-03-28T00:05:00.922Z",
    "fields": {},
    "@version": "1",
    "service": {
      "type": "file_integrity"
    },
    "file": {
      "ctime": "2019-07-12T12:50:34.645Z",
      "owner": "NT SERVICE\\TrustedInstaller",
      "mtime": "2019-03-06T12:24:00.000Z",
      "size": 5296128,
      "type": "file",
      "uid": "S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464",
      "inode": "562949953792977",
      "path": "C:\\Windows\\assembly\\GAC_64\\System.Web\\2.0.0.0__b03f5f7f11d50a3a\\System.Web.dll"
    },
    "hash": {
      "sha1": "f2aa8ee7aeb421ff2723ae6a428b235f75e57898"
    },
    "event": {
      "module": "file_integrity",
      "dataset": "file",
      "action": [
        "updated"
      ]
    },
    "host": {
      "name": "win1"
    }
  },
  "fields": {
    "@timestamp": [
      "2020-03-28T00:05:00.922Z"
    ],
    "file.mtime": [
      "2019-03-06T12:24:00.000Z"
    ],
    "file.ctime": [
      "2019-07-12T12:50:34.645Z"
    ]
  }
}

Auditbeat configuration:

auditbeat.modules:
- module: file_integrity
  paths:
  - C:/windows
  - C:/windows/system32
  - C:/Program Files
  - C:/Program Files (x86)
  recursive: true
- module: system
  datasets:
    - process 
  state.period: 12h


#----------------------------- Logstash output --------------------------------
output.logstash:
  # The Logstash hosts
  hosts: ["x.x.x.x:5044"]

Versions:

• auditbeat version 7.6.1 (amd64), libbeat 7.6.1 [c1c4943 built 2020-02-28 23:09:20 +0000 UTC]
• Windows 10 Version 1909 (OS Build 18363.720)

[elasticmachine]

Pinging @elastic/siem (Team:SIEM)

[mgovolt]

I'm having the same issue is a large way. 4-5 event.action:update's an hour. All the Sha1 hashes are the same. file.ctime is different. It looks to be triggering the update on file.ctime which seems wrong.
Any update?
Version 7.8.0

[mgovolt]

An update: I've found that the only difference in the file is file.mtime was updated. To me, it looks like the file integrity module is flagging a change if file.mtime is different, when it should be only triggering on the hash.

[andrewkroh]

It does consider mtime.

beats/auditbeat/module/file_integrity/event.go

Lines 378 to 381 in 56ba9d0

	// For files consider mtime and size.
	if n.Type == FileType && (!o.MTime.Equal(n.MTime) || o.Size != n.Size) {
	result |= AttributesModified
	}

What event.action value is contained in the events where only mtime changed?

I think those events should contain a single action of attributes_modified which you could use to drop events where there were no content changes.

beats/auditbeat/module/file_integrity/action.go

Line 47 in 56ba9d0

AttributesModified: "attributes_modified",

[mgovolt]

event.action is "updated" in this scenario, which we all agree it should not be.
I have plenty of logs if you need to see them. I figure that the OS is buggy because why would file.mtime change change if the hash didnt change? Haven't checked every OS but can confirm my issues happening on 10.0.18362.1082 (WinBuild.160101.0800) . Regardless, auditbeat is not setting it to AttributeModified as it should.
I will also note that file.ctime is not changing.

[andrewkroh]

My ideal solution would be to have event.action contain only attributes_modified when it's just mtime that changes. That's pretty simple to make happen by relying on the info that Auditbeat has stored about file and comparing it to the new state of the file. But the problem with that solution is that is disregards all of "actions" that the OS API told Auditbeat about the changes.

For example there are edge cases around moves/deletes or when the OS coalesces multiple changes into a single event (e.g. echo "foo" >> bar.txt && rm bar.txt creates an event.action with created,updated,deleted). You don't want to rely solely on data based on the state based diff because you'd lose some information.

So perhaps we can add another field that specifically indicates what changed based on the stored state and the current file (e.g. attributes, contents).

[botelastic]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.