I am not a specialist in malware removal but have done my fair share. Therefore, my methods are my own and I do not recommend anyone following the procedures I outline below unless they are very comfortable with what they are doing.
I searched and searched for someone experiencing a similar problem but found only one hit without fruit. The rest resulted in mshta.exe infections from long ago, this was not that. I run a small MSP businesses and use both Webroot and Malwarebytes Pro on all systems. Two computers from different locations recently reported infected files (some .TMP, some .DLL) They were always classified by Webroot as General Malware or Dropper. They came back each day even after being removed successfully. The computer would appear fine otherwise. But a few things on close inspection...
Running CMD netstat -aon showed a dozens of HTTP/S connections to outside IPs. The PIDs would show Explorer and SVCHOST processes doing the activity. Using prefetch_info.exe to look in the Windows\Prefetch directory at DLLHOST and CONHOST I could tell something was amiss because it was called by files in the user profile temp directories. But everything that accessed it from a temp locations had already disappeared. Short lived worker files?
I ran CleanUp, ccleaner, TDSKiller, FRST, HiJackThis, GMER, Malwarebytes and Webroot full scans. Everything came up clean with two exceptions.
FRST and HiJackThis showed the following cryptic results in the registry (example from HJT)
RegEdit gave me an error trying to access any of the Run Keys shown above because they contain invalid characters. When looking at the keys, they looked normal. Through LogMeIn I could search the registry and see the "default" key had the values presented, but I could not rename or delete them. Also, looking further in the string you can see the keys e6e3af07 which I could find. If I deleted them they came back immediately. This is where it got fun! Roll up your sleeves and get ready for battle!
I brought up SysInternals ProcessMonitor (procmon) and filtered by Operation 'RegCreateKey'. Deleted the e6e3af07 key in the registry and looked for the process that brought it back. Start SysInternals ProcessExplorer and find the process in question and SUSPEND it. We aren't out of the wood yet! These guys work in packs! Double-click on the suspended process and look to see what spawned it (Parent). In some cases the process no longer exists, it will tell you there. If it still exists, go and suspend that one and repeat until the trail ends (I had svchost, explorer, and msiexec on one machine). All these processes also had a reference to counters.dat in the user's profile which you could see in ProcessExplorer (view>show lower pane), so you could do a spot check if you wish. Then repeat deleting the e6e3af07 registry key. If it reappears find it in Procmon and suspend it in ProcessExplorer. Once it stays gone we have it stapled to the wall. Keep ProcessExplorer running. We rest, for only a moment, in the eddie.
Now to keep it from returning...
I struggled for a while trying to figure out why HJT couldn't delete the keys and I couldn't see them. In fact HJT had more results in HKLM\..\Run than I could see. This is where I learned about virtualization in the registry. A cloaking device! (for backward compatibility I think..). Opening a CMD prompt I typed..
reg flags HKLM\Software\Microsoft\Windows\CurrentVersion\Run set DONT_VIRTUALIZE /s
and if it is a 64-bit machine..
reg flags HKLM\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Run set DONT_VIRTUALIZE /s
I still got the error when clicking on the Run key but I could see everything that was legitimate. How I chose to approach this was to Export the Run Key, delete it, then Import the key. Because the cryptic key used invalid characters and was not visible, it wasn't exported. The imported key was clean. I repeated this process for all the Run locations (including Explorer !). Reran HJT to make sure all of them were gone. Lastly, I returned to Process Explorer and KILLED the suspended processes. Ran CleanUp and CCleaner to make sure temp folders were empty.
Now the big question is.. what did I encounter?! It seems to me that the registry keys created the infected file using the information in the value. How it is that an invalid character in a registry value can cause so many problems, not be detected by AV, but still function properly? Has anyone else ran into this and know if I am missing anything?
Thanks for listening,
Since this is my first post I am not familiar with how to add pictures or I would have. I just wanted to get the story out there.