7

I'm seeing a strange anomaly in some systems I support.

GMER flags the cdd.dll thread in csrss.exe, and when I run Process Explorer with Elevated Admin rights, I am:

  1. unable to view any loaded DLLs in either csrss.exe process
  2. unable to view actual thread start addresses (instead of winsrv.DLL and CSRSRV.dll, I see either 0x0 or !RtlUserThreadStart
  3. unable to view any csrss.exe thread's stack
  4. unable to suspend or kill any thread in csrss.exe
  5. Strings in memory show "Error opening process"

Photo

According to the 6th Edition of Windows Internals, this is what one would see in Process Explorer when trying to view the threads of "protected process"...

...Process Explorer is unable to show the Win32 thread start address and instead displays the standard thread start wrapper inside Ntdll.dll. If you try clicking the Stack button, you'll get an error, because Process Explorer needs to read the virtual memory inside the protected process, which it can't do.

However, csrss.exe is NOT a protected process. Also, even if were, one can normally still suspend "protected processes", which is not possible in this case.

For reference, this is what it normally looks like in Process Explorer...taken from a freshly installed system.

enter image description here

No other tool I've ran detects anything malicious. However, Process Hacker is able to access the threads, and they look like what I would expect to see...

enter image description here

2 things I know, I think:

  1. This is abnormal behavior (most other systems I look at give Elevated Admin full access to csrss.exe threads, strings, etc.)
  2. This seems consistent with rootkit-like hiding behavior. According to this quote from the book "Malware Analyst's Cookbook":

If a rootkit finds a reliable way to hide or prevent access to csrss.exe without causing system instability, then that could cause an issue. In fact, the author of CsrWalker found that some hackers tried to prevent CsrWalker from working by hooking ZwOpenProcess and preventing the detection tool from reading the memory of csrss.exe.

Can anyone explain why an Admin running PE with elevated rights would see these anomalies, other than an unknown rootkit?

  • As a starting point, file.net has some useful info about this file and other regular Windows files. [file.net](http://www.file.net/process/csrss.exe.html) –  Feb 02 '15 at 18:36
  • Have a look at [this](http://superuser.com/questions/833914/how-to-determine-what-is-running-in-dllhost-exe-thats-missing-processid-switch) Super User question – I say Reinstate Monica Feb 04 '15 at 02:58
  • Thanks Icaro...I hadn't thought about confirming the file size, but it does appear to be running out of the correct folder...C:\Windows\system32. I'll check the file file size. – Craig Cummings Feb 04 '15 at 23:40
  • Hi Twisty...I have tried some of the tools mentioned in that article, including some offline scanners booted from USB. However, the only tools that show me anything suspicious are GMER and Process Explorer. The anomalies do persist in SMWN. Unlike the SuperUser question you posted, I do not see any TCP/IP connections. I wish I did, because a quick whois would easily confirm my suspicions. – Craig Cummings Feb 05 '15 at 00:01
  • What OS is this? Any idea why the first CSRSS.EXE process was started 1/5/15 and the other 12/10/14? One thing I find odd is that that the Dec 10th instance has only 29 context switches. Unless it's doing *everything* in the kernel, that seems low for a process that's been around almost two months. – I say Reinstate Monica Feb 05 '15 at 01:59
  • Wow. I hadn't even noticed that, but that definitely seems odd. This is a Windows 8.1 system. For comparison, I have a fresh install of 8.1 running in a VM, and the start date and time for the 2 csrss.exe processes are exactly the same down to the minute. The context switches in my VM are little more in-line with what I'm seeing on the suspect system. The csrss.exe that contains the cdd.dll thread has 22,550 and counting. The other only has 5 so far, but it's only been running for about an hour. Thanks for pointing out yet another unexplained anomaly. :-) Any ideas/recommendations? – Craig Cummings Feb 05 '15 at 02:20
  • Upon closer inspection...those start times (and context switches) are for the individual threads...not the processes, and it's normal for threads to be destroyed and created within a running process. So, I'm not sure if those differences mean anything or not... – Craig Cummings Feb 05 '15 at 02:34
  • Ah, good observation. What are the start times of the processes themselves, and how do those times correlate to the system start time? – I say Reinstate Monica Feb 05 '15 at 03:23
  • The `CDD.DLL` is the Canonical Display Driver which according to [this MS Security Bulletin](https://technet.microsoft.com/en-us/library/security/ms10-043.aspx) it's *"used by desktop composition to blend GDI and DirectX drawing. CDD emulates the interface of a Windows XP display driver for interactions with the Win32k GDI graphics engine."* So my question: How are you accessing this system? Via physical console or some other method? – I say Reinstate Monica Feb 05 '15 at 20:50
  • Yes, via physical console, logged in with Standard User (run PE as Admin) or logged in with full Admin rights. Either way, same results. It also persists in SMWN. These system are for a new customer of mine, and I don't have remote access set up yet. I'm planning to make an image next time I'm there so I can load it up in a VM an poke at it some more. Will update the question as soon as I get a look at those process start times. – Craig Cummings Feb 05 '15 at 21:39
  • Do you have any AV or softwares like Digital Guardian installed? These tend to hook up at kernel level and block access to things like killing processes, reading specific files or registry i.e. they are legit but behave like rootkits. – Ganesh R. Apr 02 '15 at 16:47

2 Answers2

1

CSRSS is a standard Microsoft service: https://en.wikipedia.org/wiki/Client/Server_Runtime_Subsystem

It is basically a intermediary function that goes between the userspace and kernelspace.

Having kernel level authority you cannot access it's memory map from a normal userspace program. This is a safety mechanism to prevent malicious programs from using the memory map of programs with access to kernelspace, such as csrss as a means to scan kernelspace memory looking for ways to gain authority escalation.

There is a widespread hoax that it is a virus or Trojan . This hoax is utilized by many unscrupulous sites who try to get you to download Trojans, Spyware or Adware in the attempt to remove it. NEVER download system scanners, or any executable files for that matter, from an untrusted website.

0

For your information (as mention here):

csrss.exe is a process which is registered as a Trojan. This Trojan allows attackers to access your computer from remote locations, steal passwords, Internet banking and personal data. This process is a security risk and should be removed from your system. We strongly recommend that you run a FREE registry scan to identify csrss.exe related errors.

kenorb
  • 24,736
  • 27
  • 129
  • 199
yoututs.tv
  • 11
  • 2
  • 1
    Needs more info. This depends very much on identifying the right process. Managing to delete the wrong one (or references to it) based on the above will likely result in a crash and boot loop. – ǝɲǝɲbρɯͽ Apr 06 '15 at 16:49