The latest BackOff PoS malware is nothing new if you practice the Malware Management Framework

Proof if you were practicing the "Malware Management Framework" and reading the analysis from BlackPoS that took out Target and Neiman Marcus, you would have been prepared for BackOff that hit 600 retailers. Yes, 600 retailers!

SC Magazine article on 600 retailers affected by "BackOff" malware.

As Trustwave accurately concluded, this malware is not sophisticated. It is noisy and would have set off many of the alarms I have previously covered HERE and HERE and HERE.

Behavior of most malware share many common triggers on Windows based systems, NIX too. So why isn't anyone detecting this stuff? Small shops have no staff, PoS vendors don't use their own stuff or work with larger users to monitor for malware funkiness they can pass on. Large companies don't know how, or as I often state, "They are chasing and filing out compliance paperwork and not doing enough security engineering and defense and detective security, focused at looking for, tweaking and READING actionable alerts.

So if you read other malware analysis, because you're practicing the "Malware Management Framework" you have have set the following items and detected the malware.

1. %AppData% - C:\Users\\AppData\Roaming. If you enabled auditing of created files in this directory (Local & LocalLow too), you would have caught the malware (nsskrnl.exe & winserv.exe). Files just don't get created here normally.

2. %AppData% - C:\Users\\AppData\Roaming. The directory "OracleJava" was created and "Javaw.exe" created... If you know what is normally installed, you would find this was NOT normal for your systems, let alone a static PoS system or server. This is often a trick to create a directory or two deep to obfuscate the malware to look normal.

3. HKCU Runkey had values of #1 & #2 above.

4. HKLM & HKCU Active Setup keys were used, a little more sneaky, but known key to monitor.

As the Trustwave analysis shows there was already a Snort Sig that matched this malware. If you had reviewed this malware and tweaked your defenses, other than the names, this malware is the same... Proof the Malware Management Framework would help you discover new and advanced malware.

The Trustwave analysis did not discuss the behavior aspects of the malware, how it got there, spread, etc., but the following Windows Event ID's being logged, harvested and alerted on would have detected this malware.

1. 4688 - New Process - the executables discussed above, and probably net.exe, CMD.exe and maybe PSExec.exe as they hopped around and spread the malware.

2. 4624 - some account logged in. What accounts did and what accounts at what times are normal?

3. 5140 - A share was accessed. They most likely connected to the C$ share.

4. 4634 - A share was disconnected. Your looking for behavior of share connections.

5. 7045 - A new service is installed. Static systems don't get new services except at patch time and new installs. Change Management anyone?

6. 4663 - File auditing must be enabled on directories you want to monitor. The new files above would show up. Yes, there are ways to write to disk without Event logs being triggered in PowerShell and .NET, but this is rare.

These 6 events would have detected this and many, if not most attacks. There are many other things to enable and monitor, but practicing the Malware Management Framework from the Target breach would have prepared you for this attack and many others.

Like I always say, "If your not logging these, you're not doing it right".

For more logging to monitor, read the definitive "Windows Logging Cheet Sheet" I put together for Windows logging here for tips on what to enable, configure, gather and harvest.

Trustwave Analysis of BackOff malware

#InfoSec #HackerHurricane #malware #LogsRock #MalwareManagementFramework