Title
#general
n

Nate Bondurant

12/01/2021, 10:19 PM
Hello. I'm hoping to clarify the status of an open issue - https://github.com/osquery/osquery/issues/6673. Our engineers at VMware recently encountered this issue and posted a feature request - https://github.com/osquery/osquery/issues/7389. Are there any known plans around this issue? Thanks in advance!
puffycid

puffycid

12/02/2021, 12:07 AM
I have a PR open that partially addresses the some of the limits/shortcomings of the registry table https://github.com/osquery/osquery/pull/7261 Its not specifically about recursion And it doesnt fix the
registry
table in regards to the issue about recursion But it provides another table to query all the registry files and could be used to solve the issues above
s

seph

12/02/2021, 12:09 AM
It would be better to fix the table, or not support recursive, than to bring in raw registry parsing.
puffycid

puffycid

12/02/2021, 12:22 AM
hmm pulling back all registry key entries seems like a useful ability to have? either in the original table
registry
or new one? i think adding it in the
registry
or new one could be useful the current
registry
table is limited to logged in accounts (and specific registry files) so its not able to query registry files of accounts not logged in which is kind of major limitation? so adding a new table may be better? i think raw registry parsing can also avoid any possible rootkits/malware installed on a system that can potentially intercept/interfere with registry api calls? when using osquery to investigate malicious activity in addition, raw registry parsing provides a way to parse data that the registry api is not able to such as Amache. there are many EDR/security/forensic/IR tools out there that can parse raw registry files i think it would be great if osquery also had that capability either through an implementation written from scratch or using a library (just my two cents)