Security

Sleeper servers lurking in data centers of 139 US retailers

Many business networks that include many US retailers have sleeper servers in contact with remote command and control servers.
 
servers.jpg
 Photo: iStock
 

Two reports announce that a significant number of business networks, including retailers, have sleepers, also known as compromised servers, that are in contact with remote command and control servers.

“Based on our analysis of 139 U.S. retailers from November 1, 2013 through January 12, 2014 we found 1,035 distinct infections communicating out from corporate networks, 7.5 on average per company," according to BitSight’s 2014 Risk Management Blog.

 

malware1.jpg
 Photo: BitSight
 

That announcement is a bit unnerving having witnessed the Target breach up close and personal. The BitSight chart (above) graphs the types of malware versus the number of infections emanating from the 139 retailers.

Ready for some more? Page 48 of Cisco’s 2014 Annual Security Report states:

“In a recent project reviewing Domain Name Service (DNS) lookups originating from inside corporate networks, Cisco threat intelligence experts found that in every case, organizations showed evidence that their networks had been misused or compromised.”

 

malware2.jpg
 Photo: Cisco
 

The chart (above) included in the Cisco report punctuates the point made in the quote by proclaiming 100 percent of the corporate networks Cisco checked had traffic going to websites that host malware. It seems the title I chose for this article was more than a ploy to grab your attention.

How is it possible?

When I first started working on this article, the big unknown to me was how attackers first gain access to corporate networks. In the case of Target, the way in was recently revealed. Attackers stole login information from a Target-approved HVAC contractor that was authorized to access certain non-retail Target websites. Brian Krebs provided an in-depth report of what investigators determined:

“Multiple sources close to the investigation now tell this reporter that those credentials were stolen in an email malware attack at Fazio that began at least two months before thieves started stealing card data from thousands of Target cash registers.”

It is hard to comprehend that Target most likely will be facing years of litigation costing the company hundreds of millions of dollars all because of a phishing email.

What happened next?

Readers have asked me to explain what happens when attackers gain access to these giant corporate networks. More to the point, how do they get control of PoS systems, and steal shoppers’ financial information? To answer their questions, I talked to Gary Warner, director of research in computer forensics at the University of Alabama, Birmingham, and founder/CTO of Malcovery Security.

Gary prepared a detailed investigative report of what he and other experts feel were the steps taken by the attackers once they gained a foothold in Target’s corporate network.

During my call with Gary, he walked me through the intricate details that culminated in the attackers stealing the financial and personal information of more than 100 million Target shoppers. Gary first wanted me to mention that the Target breach is still an ongoing investigation, meaning much information is still sequestered. The attack scenario proposed by Gary is based his extensive experience in computer forensics and the initial data from iSight, a company involved in the U.S. Secret Service investigation into the Target data breach. (For unknown reasons, the files were no longer available soon after Gary downloaded them.)

Target “hacker tools” provide breach insight

The first thing Gary and his team at Malcovery did was find all of the hashes in the data from iSight. Hashes are fingerprints of files and executables, and in this case, good indicators of what attackers installed on the Target servers. Once Gary gathered all the likely candidates, he submitted them to VirusTotal, a service that analyzes suspicious files to determine if they are indeed related to malware. All of the hashes were deemed safe by VirusTotal, meaning that antimalware applications would not flag them or alert system administrators of their presence.

It seems most of the 14 identifiable tools Gary found are commonly used by system and network administrators in their daily tasks. One of the tools is PsExec.exe. Gary said, “PsExec.exe is a tool, originally by SysInternals, now owned and marketed by Microsoft, which allows a system administrator to export a list of password hashes from a Windows computer.”

The next step was to determine how the attackers used the executable files. Malcovery created tables (example below) that display the hash, and the executable’s likely purpose.

 

malware 3.jpg
 In the report, Gary explained each of the tools, and why it was important to the attack. Put simply, the attackers quietly installed network tools on a Target internal server, allowing them to explore the corporate network, and after sufficient reconnaissance setup systems inside Target’s network to exfiltrate shoppers’ financial information to remote servers.

Lessons learned

I asked Gary why he went through this detailed exercise. He replied he was concerned that parties in the know were not releasing information that might help other organizations—potentially in the same situation as Target—check their infrastructure. Remember the bleak conclusions reached by the BitSight and Cisco reports.

Since Gary had access to the iSight report before it was pulled, he felt obligated to share his conclusions, hence the Malcovery report, and the following suggestions:

  • Have a process for identifying “Administrative Tools” that are stored in the wrong places.
  • Restrict servers from accessing the Internet.
  • Inventory “authorized services” for company servers.
  • Check system folders for new or changed files.
  • Check for unusual protocols and ports being used for internal LAN communications.
  • Use internal network honeypots to look for port-scanning and other signs of an intruder.

About

Information is my field...Writing is my passion...Coupling the two is my mission.

13 comments
bobp
bobp

It sounds like only Microsoft based servers were checked. It would interesting what statistics were available for Linux and other Unix based servers - assuming they could be obtained and that Linux and/or other Unix OSs are used in sufficient quantities by retailers for the statistics to be meaningful.

pjboyles
pjboyles

Gary Warner with the statement “PsExec.exe is a tool, originally by SysInternals, now owned and marketed by Microsoft, which allows a system administrator to export a list of password hashes from a Windows computer” lost all credibility.


PSEXEC is a remote execution tool.  This tool cannot export anything.  If he had stated that the malicious attacker used it to remotely run malware on systems which gathered the information, then he would have been correct and factual.


This is how tools necessary to managing and maintaining large environments become maligned.


It should be noted that to use this tool, you must have a valid ID and Password with administrative access.  Once you have that, you have the keys to the kingdom.


As a side note, this tool is not required to gather the information that was stolen.  There are several administrative tools and processes available for a malicious person to abuse.  Calling out this tool, its creator and that Microsoft currently provides the tool was disingenuous and clouds the real issues.

Michael Kassner
Michael Kassner

@bobp  


Good point, Bob. I suspect it is because of the "low hanging fruit" adage. Why work any harder than you have to when there is an abundance of opportunities. 

brian
brian

I thought the same thing when I read the article.  PSEXEC is used to run a command remotely on another machine, similar to rexec on Linux.  That's almost like saying "I hacked your computer using DIR".

Michael Kassner
Michael Kassner

@pjboyles  


You may want to watch the video linked in the slide. I believe it shows that PsExec is used.

Michael Kassner
Michael Kassner

@pjboyles  


Thank you for bring this up. I have a call into Gary, and hopefully we will get this straightened out. If you look at the slide it mentions that PsExec is part of a kit: 

PsExec.exe (included in password cracking 

kits such as “mimikatz_trunk.zip” 

demonstrated in this YouTube video: 

www.youtube.com/watch?v=leKRxe4bZ6M

but more commonly seen associated with 

SysInternals tools.)


adam_dup
adam_dup

@pjboyles  +1 to this.  Please edit this article to explain what PsExec actually does.

Michael Kassner
Michael Kassner

@brian  


If you look at the slide, it mentions that PsExec was part of a tool kit. The only recognizable hash in the tool kit was PsExec, so it was used to locate errant applications on the servers. You might like watching the video linked in the slide. 

brian
brian

@Michael Kassner This tutorial already requires full administrative rights on the local machine in order to add privilege flags and inject code into an already running process.  There is nothing magical about this at all.

Michael Kassner
Michael Kassner

@adam_dup @pjboyles  


I believe that PsExec is part of the tool kit that is mentioned in the slide. PsExec has the only recognizable hash so researchers focus on that. 

Craig_B
Craig_B

From TechNet:

PsExec is a light-weight telnet-replacement that lets you execute processes on other systems, complete with full interactivity for console applications, without having to manually install client software.

michael
michael

Michael Kassner,

I too was confused on the role of PsExec in this breach.

I watched the video, and while it demonstrates the use of MimiKatz to grab the Windows password, I don't see any use of or reference to PsExec.

So I'm still confused... while PsExec may be included in the MimiKatz package (I didn't check that), it's existence on a server is not neccessarily a red flag.  As PJBoyles noted above, to execute a program on a remote machine using PsExec you still need the user name and password, and once you have that it's Game Over.

Perhaps MimiKatz could be run on a remote machine using PsExec to get you to that remote machine, but since the video specifies that you need to run MimiKatz in an elevated, administrator command-prompt window then that probably work without already knowing the user name and password.

I wonder if Gary would care to elaborate for us the role of PsExec in this attack.

Editor's Picks