Mal/Generic-L, Sus/CFNBehav-A and sdra64.exe

Same here. Mal/Generic-L was detected quite a few times already. Seems this is a whole new family. Haven't seen Sus/CFNBehav-A though yet.

PS: Thanks for detailed info.

A new IDE will be published which will detect the executable as Troj/Zbot-NZ.

Christian

Gaehn, new ZBOT again... it seems malware authors don't take a break.

I wished suspicious behaviour detections could be send for analysis by rightclicking the client and select "Send to Sophos" or something. Our school district has a 90 minutes driving radius, if i need to go out and collect samples manually, the day would need to have 120 hours instead of 24. The whole process of collecting, then password packing and sending to sophos is pretty cumbersome and time-consuming.

As you can see, Sophos made analysis and protection for Troj/Zbot-NZ available within a few hours. Please note that this thing also modifies the Userinit registry entry. In addition to this modification it also seems to have manipulated userinit.exe (I've sent in this additional sample). After logon explorer.exe fails to start. Surprisingly Windows System File Checker did not complain. When I renamed it SFC immediately restored the - hopefully - clean version and since then everything seems to work again.   

Christian

Final words:

the manipulated userinit.exe is now detected as Troj/Zbot-OA. To recapitulate: generic detection raised suspicion, a subsequent scan with Scan for suspicious files (HIPS) enabled spotted sdra64.exe. I found the other item (userinit.exe) because logon did not work. Now that IDEs are available the files are immediately detected. But IDEs can only be written if someone bothers to dig a little and sends in a sample.  

Guess I won't find out how this junk got onto the machine though - my co-worker's of the prudent type ...

Christian

You're right, suspicious files we as customers experience in our 'real-world' environments should always be send to Sophos. I did that dozens of times already and always with exceptional fast response times (usually within hours and not longer than a day) when it comes to creating new IDEs. But again it would be really nice to be able to send them out of the console instead of collecting it manually, packing and then send it per mail or webinterface.

And you're right too when it comes to finding out how the malware was executed on the machine: "I didn't do anything, i was just browsing the web" is what i always hear. Which makes sense in certain types of malware like drive-by FakeAV using exploitation packs...

Looks like more than flowers and leaves sprouts in spring. A "version" of sdra64.exe (not detected as any known threat) triggered HIPS/RegMod-001, HIPS/RegMod-014, HIPS/ProcInj-001. It was running from the user's Application Data folder and locked. Found the "original" in the Temporary Internet Files folder together with another rogue js and perhaps identified the site visited by the user (loads like molasses by the way). No signs of Mal/Dropper-AB mentioned in this article though.

We'll see what Sophos Labs say.

Christian

 ... the answer is Troj/Mdrop-CMS and Troj/Agent-NAX.

Christian

We've experience something similar here. It was travelling around by USB, and we believe it had been picked up at a twinned school as part of the 6th form - students crossing between sites. From memory it was the same 3 HIPS references you made initially (RegMod-001 + 014 + ProcInj-001) that were detected. Though after submitting some samples Troj/Frethog-P was the released for detection, quickly followed by variants R and T.

It was affecting the user settings, whereby the user couldn't change settings to show hidden files etc. Though the option was there to select it, but by the time all had been okayed, it had kicked in and prevented viewing hidden files again. In all honesty, MalwareBytes Anti Malware did a good job of cleaning all the fragments (but at that point, we were unable to submit the files to Sophos - so MBAM was an added bonus).

We changed from alert only for suspicious behaviour etc to block, and also changed settings to disable autorun, which was all run of the mill - though we haven't seen any further instances of infection since making these changes, BUT we have seen plenty of detections. So all in all, a quick resolution and an IDE within 24 hours, and the promise of a more family orientated IDE to follow. I believe that it overlapped with Mal/Generic-L

The major problem with false positives is that they might occur at undue hours. Some (more or less) application no longer works at a time when no one's around to look into it and authorize it if needed. And since whitelisting may not be feasible in all cases you have to maintain the list of authorized applications. Using automated updates can complicate matters. Therefore it's understandable that one uses alert only for runtime and is reluctant to follow the best practices.

Once you've encountered even a minor outbreak and seen the difference HIPS can make, you start to think differently about it. But it is more effort and also requires communication and cooperation among the IT groups.

Christian