Sality goes for broke

We’ve seen continued activity from our old file-infector Sality, and a few weeks ago we saw a variant with some new tricks up its sleeve … but at the price of stability.

The author used to keep track of the viral version number in his code but has stopped doing that in the last few variants. I’d say this might mark a trend towards more buggy code, except Sality’s bad habit of breaking some of the files it infects is not new and, while new versions of the virus fix some of these problems, they also introduce buggy features.

The two most common breakages we’ve seen in recent variants are;

1) Virus code gets written across section boundaries.

This is an old bug, but one that’s lingered – Sality often writes its starting code near the end of a section, and then doesn’t notice that this code sprawls off into the next section too. Bytes in different sections that are next to each other on disk are usually far apart when the file is loaded to memory, usually with the result that the infected file doesn’t run.

2) Dummy calls don’t point to the right place.

A new “feature” in the latest Salitys is that the virus searches the host for occurrences of the byte 0xC3. In assembly this represents a return instruction, and during infection the virus writes calls which point to the C3s it found, with the intention of returning back immediately and maybe throwing people off its scent. However due to poor coding the search for the C3s is buggy, and often the virus ends up calling entirely different code than it intended.

Files that are broken in these ways tend not to run – the virus code doesn’t execute properly, the host never gets called at the end of the virus, and disinfection becomes a much more difficult task than it should be.

In a minority of cases the virus messes up the infection so badly that the host just isn’t able to be restored, but we do detect and disinfect broken samples where possible, and we have a number of tricks up our sleeves to help us. Usually we detect infected files as W32/Sality-AM, but we also have Mal/Sality-A and Mal/Sality-B in our arsenal to pick up and disinfect stragglers, while Sus/Sality-A helps identify Sality-like files that are worth further investigation. Plus of course we’ve got HIPS runtime analysis rules to identify the virus in the first place, which we’ve seen working very effectively in the past.

I imagine the virus author will stop writing broken code eventually, although I can only hope that he’ll stop writing code altogether.