CSA 4.5.1 Windows Registry Alerts

owensgl · ‎11-02-2005

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.

mcvosi · ‎11-02-2005

I have not seen this on my domain controllers (Win2k3).

Do you have any other applications running (besides those specific to AD like DNS)?

piltze · ‎11-21-2005

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.

bfinley · ‎11-21-2005

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.

Thanks,

Bill

owensgl · ‎11-22-2005

I had the above event and i copied the policy rename the policy and disabled the event because it is a false positive.

bfinley · ‎11-22-2005

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.

tsteger1 · ‎11-22-2005

Since the server host is processing the print job or whatever it's doing for the remote client, there could be a local process you could use in a dynamic application class.

Then when the remote client process triggers the local process, an allow registry access rule could be used as an exception for those remote clients while denying all others.

Might be more trouble to investigate than it's worth but it would be interesting to find out.

Tom S

bfinley · ‎11-22-2005

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?

tsteger1 · ‎11-22-2005

No, I don't think so. I think it would be feasable only if:

- there was a local process associated with the remote client access.

and

- it could distinguish which remote client was triggering the process.

That would be the tough investigative part.

I'm not sure it's savvy enough to do that and it sounds like you and they came to the same conclusion.

Tom S