has anyone seen the below before on a Windows Domain Controller.
TESTMODE: The process '<remote application>' (as user NT AUTHORITY\SYSTEM) attempted to access the registry key '\REGISTRY\MACHINE\SYSTEM\ControlSet001\Control\ComputerName' and value ''. The attempted access was an open (operation = OPEN/KEY). The operation would have been denied.
I have seen a few variations of this, it seems to occur for us on print servers when printing to specific printers. The errors I've been seeing are:
TESTMODE: The process '' (as user DOMAIN\user) attempted to access the registry key '\REGISTRY\USER\.DEFAULT\Control Panel\International' and value ''. The attempted access was an open (operation = OPEN/KEY). The operation would have been denied.
TESTMODE: The process '' (as user DOMAIN\user) attempted to access the registry key '\REGISTRY\USER\.DEFAULT\SOFTWARE\MICROSOFT\SystemCertificates' and value ''. The attempted access was a write (operation = CREATE/KEY). The operation would have been denied.
TESTMODE: The process '' (as user DOMAIN\user) attempted to access the registry key '\REGISTRY\USER\.DEFAULT\SOFTWARE\Microsoft' and value ''. The attempted access was a write (operation = CREATE/KEY). The operation would have been denied.
We're seeing the exact same thing. It's rule number 124 of the system hardening module which blocks all registry access from remote clients. We haven't yet been able to create an exception rule to allow this without allowing remote clients all access to the registry. If anyone has been able to create a exception rule please pass on the info.
Yeah, I guess technically you could call this a "false positive" although the rule is doing what it is set up to do. That is, block all remote clients from attempting to access the registry. I have a TAC case opened on this issue. CISCO pretty much suggests doing what I have already done. Disable this rule altogether. There are other rules in place that will block an attacker from writing to certain registry keys like HKLM/microsoft/software/windows/currentversion/run. Since this rule is part of the system hardening module you have to balance functionalilty with security. Although disabling this rule opens up security holes I don't think it's a major risk.
I've been e-mailing back and forth with TAC on this. From what I was told there is no way to determine exactly what application is attempting to access the registry. CSA only knows that it is a remote application but can't determine what the exact application is. In order to create an exception rule you would have to allow registry access to all remote clients. I've been told that this has been changed in CSA 5.0 which is scheduled to come out in the first quarter of 2006.
I'm curious though, would setting up an exception rule using a local process in a dynamic application class work if CSA is unable to determine what remote application is trying to access the registry? Would you still have to set up the exception rule to allow all remote clients access?
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...