-
Notifications
You must be signed in to change notification settings - Fork 422
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 process.command_line #599
Conversation
to the executable, and all arguments. | ||
|
||
Some arguments may be filtered to protect sensitive information. | ||
example: "/usr/bin/ssh -l user 10.0.0.16" |
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.
When do we use process.command_line
vs process.args
? They seem a little redundant.
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.
I totally agree they are redundant.
Having the args as an array is exceptionally powerful (more than I initially realized) when detections are looking for an exact term in a command.
However especially in the context of endpoint detections, many of them will still have to rely on fuzzier searches e.g. with wildcards, to detect some attack patterns such as obfuscated commands, base64 decoding, webshells & so on.
So both fields are actually needed, in order to perform each class of detections.
Also unrelated to detections, displaying process.command_line
in Kibana will be much nicer :-)
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.
Yeah exactly.
I think process.args will have more utility for search than process.command_line, but process.command_line gives us full recoverability of the original command line as presented to the OS. For one odd edge case, cmd.exe essentially puts 2 spaces between arg[0] and arg[1], but arg parsing is lossy, so we lose that artifact.
No description provided.