You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
MetricBeat uses gosigar for ProcMem and ProcArgs. Both of these calls request PROCESS_QUERY_LIMITED_INFORMATION | PROCESS_VM_READ which can trigger credential dumping false positives in third-party security software. We can avoid this problem with two simple changes, reducing SDH, customer headache, and vulnerabilities/blindspots created through customer exceptions in their security software. As a benefit, we'll be able to collect some data that we couldn't collect previously.
ProcMem::Get()
ProcMem::Get() requests PROCESS_QUERY_LIMITED_INFORMATION | PROCESS_VM_READhere. The handle is for GetProcessMemoryInfo. The docs for GetProcessMemoryInfo state that PROCESS_VM_READ is only needed for XP and Server 2003. Agent no longer supports either of those platforms, so let's stop requesting/requiring PROCESS_VM_READ.
Another important point is that we will never successfully acquire a PROCESS_VM_READ handle on any Protected Process or PPL, meaning this function will always fail on those processes. Since it's unnecessary for GetProcessMemoryInfo, then this function is failing needlessly on such processes. As a simple test for this, check whether you are getting memory information for services.exe which always runs as PPL.
ProcArgs::Get()
ProcArgs::Get() requests PROCESS_QUERY_LIMITED_INFORMATION | PROCESS_VM_READhere. lsass.exe never has a meaningful command line (screenshot below), so can we skip calling ProcArgs::Get() on lsass.exe?
Its PID can be found in the registry. We can query that value once and cache the value because it will never change until reboot. This LSA exclusion logic may be better put outside of gosigar itself.
gabriellandau
changed the title
MetricBeat is Triggering Credential Dumping False Positives
MetricBeat is Triggering Avoidable Credential Dumping False Positives
Oct 23, 2024
MetricBeat uses gosigar for ProcMem and ProcArgs. Both of these calls request
PROCESS_QUERY_LIMITED_INFORMATION | PROCESS_VM_READ
which can trigger credential dumping false positives in third-party security software. We can avoid this problem with two simple changes, reducing SDH, customer headache, and vulnerabilities/blindspots created through customer exceptions in their security software. As a benefit, we'll be able to collect some data that we couldn't collect previously.ProcMem::Get()
ProcMem::Get()
requestsPROCESS_QUERY_LIMITED_INFORMATION | PROCESS_VM_READ
here. The handle is forGetProcessMemoryInfo
. The docs forGetProcessMemoryInfo
state thatPROCESS_VM_READ
is only needed for XP and Server 2003. Agent no longer supports either of those platforms, so let's stop requesting/requiringPROCESS_VM_READ
.Another important point is that we will never successfully acquire a
PROCESS_VM_READ
handle on any Protected Process or PPL, meaning this function will always fail on those processes. Since it's unnecessary forGetProcessMemoryInfo
, then this function is failing needlessly on such processes. As a simple test for this, check whether you are getting memory information forservices.exe
which always runs as PPL.ProcArgs::Get()
ProcArgs::Get()
requestsPROCESS_QUERY_LIMITED_INFORMATION | PROCESS_VM_READ
here.lsass.exe
never has a meaningful command line (screenshot below), so can we skip callingProcArgs::Get()
onlsass.exe
?Its PID can be found in the registry. We can query that value once and cache the value because it will never change until reboot. This LSA exclusion logic may be better put outside of gosigar itself.
For confirmed bugs, please report:
The text was updated successfully, but these errors were encountered: