Avoiding threshold alerts through time based enumeration
Many SOC environments use threshold scores on risk objects to raise alerts over a given period of time i.e. 6,8,12,24, 48 hours. Typical enumeration modules run a ton of commands over a short period of time. This methodology is great in CTFs or for nonexistent/sleeping SOC teams but against a hardened environment the way these modules are currently being used is guaranteed to trigger an alert.
Any detection engineering team that is half way decent will have risk based alerts based on an accumulation of risk points over a period of time, in order to avoid these alerts the time frame for enumeration needs to be lengthened over a given period of time. Ideally this would allow enumeration modules to be run in the background as a job, with the developer deciding to come back and check after X hours to see the enumeration result.
The persistence mixin was great, and I believe this feature would best be implemented as a mixin that can be included in all future enumeration modules. Once the mixin is complete and tested on one module a process for standardizing all existing enumeration modules can begin.
An EnumEvasion module would implement two features 1) allow users to set an option that specifies the amount of time in seconds that they would like to run enumeration commands within, 2) store each enumeration command in an array and 3) choose a random interval between zero and the final time in which to run each command which will be accomplished by looping through the array.
Let me know if this is a good idea and any other suggestion for adding evasion features to current enumeration modules. Thank you!
Avoiding threshold alerts through time based enumeration
Many SOC environments use threshold scores on risk objects to raise alerts over a given period of time i.e. 6,8,12,24, 48 hours. Typical enumeration modules run a ton of commands over a short period of time. This methodology is great in CTFs or for nonexistent/sleeping SOC teams but against a hardened environment the way these modules are currently being used is guaranteed to trigger an alert.
Any detection engineering team that is half way decent will have risk based alerts based on an accumulation of risk points over a period of time, in order to avoid these alerts the time frame for enumeration needs to be lengthened over a given period of time. Ideally this would allow enumeration modules to be run in the background as a job, with the developer deciding to come back and check after X hours to see the enumeration result.
The persistence mixin was great, and I believe this feature would best be implemented as a mixin that can be included in all future enumeration modules. Once the mixin is complete and tested on one module a process for standardizing all existing enumeration modules can begin.
An
EnumEvasionmodule would implement two features 1) allow users to set an option that specifies the amount of time in seconds that they would like to run enumeration commands within, 2) store each enumeration command in an array and 3) choose a random interval between zero and the final time in which to run each command which will be accomplished by looping through the array.Let me know if this is a good idea and any other suggestion for adding evasion features to current enumeration modules. Thank you!