Windows registry fieldset

[rw-access]

We need to add a fieldset for Windows registry event. Both Sysmon/winlogbeat and Endgame/Elastic endpoint can collect these. I'm less focused on the creation of registry keys, but thinking more about the creation/modification of values. For more background on how the registry works, here's the wikipedia page.

Here's an example event collected from Endgame

{
  "bytes_written": "QwA6AFwAcgB0AGEAXAByAGUAZABfAHQAdABwAFwAYgBpAG4AXABtAHkAYQBwAHAALgBlAHgAZQAAAA==",
  "bytes_written_count": 58,
  "bytes_written_string": "C:\\rta\\red_ttp\\bin\\myapp.exe",
  "event_subtype_full": "registry_modify_event",
  "event_type_full": "registry_event",
  "hostname": "RTA-TESTING",
  "key_path": "\\REGISTRY\\MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Image File Execution Options\\normalprogram.exe\\Debugger",
  "key_type": "sz",
  "opcode": 1,
  "pid": 9108,
  "process_name": "python.exe",
  "process_path": "C:\\Python27\\python.exe",
  "serial_event_id": 77803,
  "timestamp": 131762384629155140,
  "timestamp_utc": "2018-07-16 18:14:22Z",
  "unique_pid": 77788,
  "user_name": "tester",
  "user_sid": "S-1-5-21-4215045029-3277270250-148079304-1004"
}

Some of the keys worth adding to the field set:

• hive: If we stick with the abbreviated names, the values are HKLM, HKCC, HKCR, HKCU, HKU. if we go unabbreviated names, this means HKEY_LOCAL_MACHINE, HKEY_CURRENT_CONFIG, etc. in the above example, this is HKLM / HKEY_LOCAL_MACHINE
• key: the hive relative path to the key. this doesn't include the value name. this is somewhat analogous to a directory path in na file system. in the above example this is SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Image File Execution Options\\normalprogram.exe
• value: the name of the value written to. this is somewhat analogous to a file name. in the above example, this is Debugger
• path: the full path, including hive, key, and value. essentially key_path in the above example

It also may be worth nesting a field set at registry.data which contains

• type: the representation of the data. basically tells you how to interpret the bytes written. possible values are: REG_NONE, REG_SZ, REG_EXPAND_SZ, REG_DWORD, etc. in the above example, this is REG_SZ.
• int_value: open for naming suggestions, but we could store (+/- careful casting) DWORD/QWORD as i64, or long within ES
• string_values: type: array[string] again, open for a better name, but this would store the strings for any string types -- REG_SZ, REG_EXPAND_SZ, REG_LINNK, REG_MULTI_SZ. in the above example, we would store ["C:\\rta\\red_ttp\\bin\\myapp.exe"]
• num_strings: type: long. this would be the number of strings for REG_MULTI_SZ. I'm not sure how often this would need to be queried over, so this could be derived with length(string_values)
• original_bytes: type string - I'm not sure the best representation, but this could be base64 to store arbitrary bytes without worrying about unicode. this would be most used for REG_BINARY, but could be stored for any data type.

[rw-access]

An example for what Sysmon reports

{
  "ProcessId": "2288",
  "EventId": 13,
  "Details": "DWORD (0x00000000)",
  "TargetObject": "HKU\\.DEFAULT\\Software\\Microsoft\\Windows\\CurrentVersion\\Internet Settings\\ZoneMap\\UNCAsIntranet",
  "ProcessGuid": "{365ABB72-F5D9-5C7F-0000-00100ACA5600}",
  "UtcTime": "2019-03-06 16:31:42.855",
  "Image": "C:\\Windows\\Installer\\MSI1957.tmp",
  "RuleName": null,
  "EventType": "SetValue"
}

[webmat]

Thanks for opening this, Ross!

keys

• registry.hive (keyword): I would prefer the abbrev here, like HKLM.
• registry.key (keyword) & registry.path (keyword):
  • I like the semantics you propose, where registry.key is without the hive prefix and registry.path includes the hive prefix. Gives users both ways to look at this.
  • I also agree that path should go all the way and include the value name.

data

For the data capture and appropriate types, here's my take on it, and there's differences vs what you outline. Let me know if it makes sense:

• registry.data.original (keyword or index: false): base64 of the raw value. Should always be filled, no matter what the registry datatype.
• registry.data.type (keyword): also always filled, with the registry datatype as you describe.
• registry.data.integer (keyword):
  • only filled when it's a numeric, like REG_WORD & REG_DWORD
  • since long is signed 64 and there's currently no bigger int in ES, I think keyword would be better here. Do you think the capabilities of a numeric field would be necessary here? (e.g. numeric sorting rather than lexical)
  • field content could be the decimal or hex representation of the number. Or perhaps we define two field, one for each? (e.g. .numeric.hex and numeric.dec). Open to discussion.
• registry.data.strings (array of keyword):
  • only filled when it's a string, like REG_SZ, REG_EXPAND_SZ, REG_MULTI_SZ
• For now I would not add the string counter. If we need to query for it, we can add it later. But if it's only used at visualization time, this can be implemented via a scripted field in Kibana, or calculated by the client application.

I think for a first stab at this we can stop here, WDYT?

[webmat]

cc @neu5ron @NeilADesai @dainperkins