Helpful Navigation Toolbar

Monday, September 8, 2014

Spending $$$ on hardware won't fix the first have to understand what the problem is

As more and more organizations experience data breaches that are specifically targeting credit card processing programs, many in the sales and marketing areas are quick to say "If Organization X had only spent $5,000,000 on our latest greatest virtualized cyber cloud threat mitigation machine learning device..." More than likely the sales pitch contained some of those buzzwords and probably others as well. It also seems that many in the managed services (including some individuals within the incident response realm) are also attempting to convince anyone who will listen that some very expensive hardware or software (or both) solutions and costly services retainers will prevent these breaches from happening. The simple fact of the matter is that regardless of whether you possess the secretive schematics on how the flux capacitor works or if your company processes 749,392 credit card transactions every minute, a single solution will NOT stop your organization from being targeted

There seems to be a disturbing trend that the individuals responsible for the protection of the environment no longer have a full understanding of "what" is on the system/network and are increasingly relying on these very expensive products to generate an alert to tell them when something has occurred. While the amount of data and devices that the team(s) within your organization has to monitor is increasing, and these expensive products can help monitor the environment, a grass-roots, "back to basics" approach would help those responsible for security within an organization be able to recognize and detect threats more rapidly and more efficiently and can even help potentially minimize the depth and severity of a breach when it occurs.

Scenario using Goodwill data breach malware

In this particular case, I am going to cover a hypothetical scenario using malware that was utilized in the Goodwill data breach in which roughly 868,000 credit cards were compromised during a period from February 10, 2013 through August 14, 2014. By pairing free and available tools with commonly recommended security practices, the system administrator(s) could have easily detected and identified system(s) that were infected with this malware and potentially have stopped the breach shortly after the malware was installed on the system(s). In fact, based off the processes that the malware itself searches for, if the administrators had renamed the primary card processing software/services to something non-descript, it is possible that the breach may have not even occurred in the first place. 

In an attempt to replicate the environment, I renamed "notepad.exe" to "pms.exe" and pasted in modified Track data so that the malware will find the data, since (according to the Symantec writeup and strings within the file itself) that is one of the executables the program searches for). 

Strings in ncsvr32.exe. Note the regular expression looking for Track data at the top and the executable names the malware searches for at the bottom

Once that has been completed, I then loaded the malware onto my test system and ran it. The malware is very basic and not sophisticated at all. In fact, if there is a space in the path where the malware was run (for example, if you placed the malware in C:\Documents and Settings\Administrator\Local Settings\Performance Monitor") the malware will run and the folder and file (if there is data collected) will be created, however, subsequent writes to that file cannot be completed because the author(s) did not account for spaces in file paths. 

It appears the author(s) forgot to account for spaces in file paths

Secondly, the malware opens a command prompt window that actually lists all of the data that it captures. 
This window is open on every device infected with this malware. You can minimize it, but if you close it the program stops and it has to be manually restarted again

If you simply close the command prompt window, the logging process completely stops. While the window is open, the malware collects data from processes every 60 seconds. Based off of my own triage analysis, there did not appear to any persistence mechanisms, so once the executable is stopped it has to be manually restarted in order to start again. If a system administrator, security analyst, or even a non-technical employee had noticed the window open on a machine and had closed it, it would have stopped this sample of malware from collecting credit card information.

With the sample that I downloaded, the Track data is saved to the output file titled "data-pms.exe-2224.dmp". The data contained within this file is plain-text and there does not appear to be any encryption or additional obfuscation techniques used.

Plain-text Track data stored in the logging file. No encryption or any obfuscation attempted

The malware used in this case appears to be VERY unsophisticated, however as I have pointed out in the past, attackers will use malware that is only as advanced as it needs to be in order to accomplish their goals. In this case, this very basic and poorly written malware stole credit card transaction data from the Goodwill environment for over 19 months and resulted in nearly 868,000 compromised credit card numbers before it was stopped. It is paramount that network administrators/security engineers/incident response teams (or whatever name your organization labels your security teams) understand what is on the network and systems and what is supposed to be there prior to spending large amounts of money on hardware and network monitoring devices. All of the monitoring hardware in the world could have been in place and the Goodwill breach probably would have continued to go unnoticed in part because the attacker(s) probably used legitimate credentials to gain access to the network, the malware did not appear to use any network connectivity, and the malware was very basic and unsophisticated. This is my own speculation based on past experiences, but more than likely the attacker(s) managed to get credentials that allowed access to the network and after some reconnaissance, they were able to figure out where the data they wanted was stored and came up with an easy way to capture that data. Then, the attackers(s) probably either exfiltrated the data in an automated fashion (possibly a script) or the attackers remotely accessed the system(s) again to remove the data (based on the presence of an unencrypted logging file).

Without the understanding of what should be on these systems and monitoring the systems for items such as additional running processes, sluggish performance, open command prompt windows, etc. it does not matter how much money you spend on the high priced hardware and software solutions. Those solutions MUST compliment the understanding and comprehension of your security team. These solutions are not a replacement for practicing some of the fundamentals of information security.

Here are some quick tips you can take to reduce the possibility of experiencing a credit card breach, inside of your organization:

  • Rename your payment application to something non-descript
    • Instead of pms.exe, change it to chrome.exe or firefox.exe or itunes.exe. Or something else unique but not easily associated with "what" the program is doing. While calling your payment processing program "OMGItsSoFluffy.exe" is non-descript, having a very unique name can also sometimes be an indicator that something is important.
  • Perform periodic triage analysis on key systems and components
  • Strive to exceed PCI/DSS compliance standards, such as:
    • Segregate and segment your payment processing network from the rest of your network. Don't have your payment processing application running on the same system (and network) where your employees are checking Facebook
    • Change ALL software/hardware defaults, including application names and third party provider passwords. YOU should create a unique username/password for remote access if it is required. That reduces the chance of credentials reuse. DO NOT ONLY use simple dictionary words, your store name and number, etc.
    • Implement strong password policies and require password changes periodically
  • Look into freely available tools to help diagnose your current environment like:
    • noriben - A portable, simple, malware analysis sandbox
    • PEStudio - Static malware analysis tool
    • Online malware analysis services, such as anubis
    • Live Response collection - Allows gathering of volatile data from Windows, OSX, and *nix based systems

AUTHOR'S NOTE: Here is another good article from an author seems to be just as frustrated and shares similar opinions on this topic!

Wednesday, September 3, 2014

Many small updates to the Windows Live Response collection

Good morning readers! Over the past few days I have had a little bit of free time, which I used to update several of the applications contained within the Windows Live Response collection.  cports, LastActivityView, md5deep, nmap, and PEStudio all were updated. I ended up removing both "full" versions of FTK Imager and just kept FTK Imager Lite as I felt having three FTK Imager options to choose from was a bit much. I also updated WinAudit to 3.0.8, but retained 2.2.9 just in case anyone had used that extensively and had written parser(s) for the data it presented. I also added an Excel spreadsheet in the Windows collection that lists the tool, the date uploaded, and the original website where the tool came from. - download here 

MD5: 8603e36be474e8b69c652e5dc86adc2e
SHA-256: ec79422ce2e7218a7bc57b0caf52a5eae2eca98810ac466dddac1115aade493e 

Updated: December 12, 2016