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

I totally agree Christian.

You cannot follow best practices at all times, as that would make it too easy! :smileywink:

Seriously though, it is difficult as you need to be constantly checking e-mail notifications or using SEC to keep an eye on everything. And then you need to make a choice of authorising or submitting a sample. If it is a sample being sent off that comes back clean, people will grumble about that too (regardless of the turn around).

However, where an outbreak of sorts has been spotted, its the perfect quick fix. You can prevent further infection in a reasonable time and submit samples to Sophos whilst the majority of people will be unaware of any changes made to their policies.

I personally am lucky that it causes little extra effort in my role, but we're safe knowing that as long as we have pro-active/zero-day detection we'll be pretty much clear :smileyvery-happy: Though finally, it is always down to personal experience and having been crippled by the Win32/Sohana-BQ we're a little more clued up at how to manage our policies "in the moment" now

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

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 answer is Troj/Mdrop-CMS and Troj/Agent-NAX.

Christian

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

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...

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

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

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.

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

Christian