Address gaps in Process Activity and Memory Activity wrt process injection.

[davemcatcisco]

Related Issue:

#1041: Process Activity and Memory Activity cannot adequately describe common injection-related behaviours

Description of changes:

• Added entry to injection_type_id enum in dictionary.json to cover queueing of an asynchronous procedure call (APC).
• Added entry to activity_id enum in events/system/memory.json to cover mapping of shared memory object.

[davemcatcisco]

It says that I should put labels on this but the ability to do that seems to be disabled for me. The labels I would use if I could would be process_activity, memory_activity, non_breaking, and v1.2.0_and_later.

[mikeradka]

This is a great catch, @davemcatcisco. One minor thing, could you change the branch to be merged to as main instead of ocsf:v1.2.0?

EDIT: This is TBD based on how things go with the 1.2.0 RC

[pagbabian-splunk]

For process_activity we are adding an additional injection type, is this the more specific way people think of process injection via memory activity? In other words, is the same situation representable as both process activity or memory activity?

[davemcatcisco]

For process_activity we are adding an additional injection type, is this the more specific way people think of process injection via memory activity? In other words, is the same situation representable as both process activity or memory activity?

Thanks, Paul. I'm not sure I fully understand your question but I'll just say this in case it helps. Process injection broadly speaking requires two distinct things to happen:

1. Memory pages containing the code that the attacker process wishes to execute and/or the data upon which that code will operate must be present in the virtual memory space of the victim process with the appropriate page protections. There are various ways to achieve this, represented in OCSF by a Memory Activity event.

2. The attacker process must initiate execution of that code by a thread running within the context of the victim process. This can be achieved either by re-purposing an existing thread (temporarily or permanently) or by creating an entirely new thread for this purpose. In OCSF, this type of activity is represented by a Process Activity event.

It is important, I think, that these continue to be treated as two distinct activities because each can be used in isolation for other purposes, some benign and some not.

The base branch was changed.

[davemcatcisco]

Closing as this PR has now been superseded by #1060.