Insight – LABS, 2015/03/06 15:00
0x00 case study 1
How did the nation’s largest brick-and-mortar retail chain have millions of credit card details stolen in three months
[page 8]
The attack, which was similar to several retail attacks in 2014, used legitimate accounts to log into the victim’s system remotely, infiltrated the POS system, and then installed credit-card-stealing malware. They didn’t realize they had been targeted until they were notified by the U.S. government.
0 x01 breakthrough point
The attacker first logged into the retailer’s virtual application server using a legitimate account. This virtual server gives the attacker a virtualized desktop environment with limited permissions. . We found no record of failed logins, indicating that the attacker had obtained a legitimate account before the attack (current evidence does not show how the attacker obtained the account, but it is likely social workers, phishing, etc.).
The hacker then took advantage of a configuration error in the virtual desktop environment to claim access to the shell. Then download a password export tool through FTP and obtain the password of the local administrator. This local administrator password is the same as any other system in the company. All this was done in a matter of minutes.
During the initial attack, the attacker used Metasploit Framework(MSF), a powerful open source penetration testing tool, to navigate the Intranet environment.
Using MSF’s psexec_command module, the attacker executed many commands on the Intranet system using the administrator password previously obtained. This module executed commands by adding Windows services, so it left a record in the system log.
During the infiltration, the attacker targets the domain control server on the enterprise network. The local administrator password of the domain control server is the same as the administrator password of the virtual desktop server obtained by the attacker……
The attacker then obtains the NTDS database and hive registry data of the domain controller through the NTDS Grab module of MSF.
The NTDS of the domain controller stores the hash of the user name and password in the AD. Once the domain administrator’s password has been hashed, the attacker is essentially unimpeded in the domain through them.
At this point, attackers switch from MSF to more traditional late penetration tools, such as Microsoft’s Psexec, RDP and other common management tools. The attacker then uses the domain administrator account to log in to other systems through RDP.
How the psexec_command module works
MSF’s psexec_command module writes the commands to be executed to a batch file, and the results are written to a text file. Both file names are random 16-bit strings. The module then executes the batch program by adding a new randomly named Windows service. Here is what appears in the Windows system log after the service is added:
A service was installed in the system.
Service Name: MRSWxwQmQxFGumEFsW
Service File Name: %COMSPEC% /C echo dir ^>
%SYSTEMDRIVE%\WINDOWS\Temp\TthwsVKvUhydrsNB.txt > \
WINDOWS\Temp\RbhRmgALAHcdyWXG.bat & %COMSPEC% /C
start %COMSPEC% /C \WINDOWS\Temp\RbhRmgALAHcdyWXG.bat
Service Type: user mode service
Service Start Type: demand start
Copy the code0 x02 back door
In an effort to gain lasting control of compromised systems, the attackers planted a backdoor, a driver Trojan targeting Windows XP, into multiple machines.
The Trojan uses advanced kill – free technology, similar to many advanced common malware. The embedded malicious driver first frees code in memory and then generates a new system thread. After the original driver is loaded, a system loading error is prompted because the released code was executed by a different process. Windows does not consider the driver to have been loaded, but the malicious code executed successfully. This technique is often used to prevent the reverse of malware and protect some of the functionality of the backdoor.
This backdoor implements its function in the User space by releasing shellcode (injected into user-level processes after loading from the kernel). This Shellcode gets an XOR encoded shellcode embedded in HTML by sending an HTTP POST to an IP address written in the code.
This trick makes this backdoor very versatile, because to add new functionality you simply add a new Shellcode to the server. While shellcode has been around for a long time, its combination with the driver-level backdoor shows how advanced it is.
Figure 2 Communication mode between the rear door and C2 server
All checkout systems in this retail store are connected to domain servers, which means that anyone who controls the domain controller can control all checkout machines.
After taking over the enterprise domain environment, the hackers began to penetrate the internal network of the retail system.
The internal environment of the retail system looks like this:
The retail domain and the enterprise domain are mutually trusted. Each retail checkout platform running WinXP retail platform XP system joined the retail domain
Such an Intranet environment is common in the retail industry, giving attackers two advantages.
First, because of the two-way trust relationship, as long as you take the administrator rights of one domain, you have the rights of the other domain.
Second, the retail domain is a subdomain of the enterprise domain, which requires special ports to be enabled for the domain controllers of the enterprise domain and subdomain. These open ports bypass the firewall of the retail domain. The attacker uses these open ports to access the retail domain controller and then uses the retail domain controller as a springboard to access other machines in the retail domain.
The attacker pushed a Windows script to all checkout platforms using domain control, which then downloaded malware designed to collect POS card swipes.
The attacker then executed the malware through a Windows scheduled task. The app collects track data from credit cards, including credit card numbers and expiration dates. This information is stored in the MEMORY of the POS application when the card is swiped, and the attacker sells the data to the person who makes the fake card.
The malware that attacked POS machines used OSQL, a software preinstalled on all checkout platforms, to write the collected credit card information to a temporary DATABASE called TEMPDB, which is emptied when the MSSQL restarts. Every day, an attacker exports the tempdb data as a text file and copies it to the domain controller server.
The attacker then packages the collected data and sends it to a workstation on the retail Intranet with an external network connection, and then to an FTP server controlled by the attacker
Figure 3
1. The attacker remotely logs in to the victim's virtual application server using a legitimate account. 2. The attacker escapes from the virtual environment and gradually enters the Intranet. Collect the accounts of the enterprise Intranet environment from there. 3. The attacker uses the domain controller server of the retail domain as a springboard to access the POS host. It then downloaded and executed malware that collected credit card information through a script. 4. The attacker transmits the collected credit card data to the domain controller, then to the workstation with Internet connection, and then to the FTP server controlled by the attacker through FTPCopy the code0x03 Comments and Suggestions
How do you defend yourself against such an attack? You can’t stop every attack, nor can you prevent yourself from being hacked, but there are some basic rules that can prevent an attacker from moving unimpeded through your network. With the right tools and a highly vigilant security team, you can slow down an attacker, giving you enough time to detect, analyze, and respond to an attack before the worst happens.
1. Remote login security
Analyze and examine how employees, temporary workers, and suppliers are remotely connected to your network environment. Make sure you have control over the remote connection, such as how it works, who you can connect to remotely, password requirements, etc. All accounts that can be remotely logged in to should use two-factor authentication. Be sure to actively monitor remote login logs to spot any suspicious activity early.
2. Ensure the security of PCI environment for payment cards
Plan your Intranet environment according to the Payment Card Industry(PCI) and related security certification standards PCIDSS. All logins and connections into the PCI environment are made through a secure fortress machine. Logging in to a Fortress requires two-factor authentication. If possible, separate the enterprise domain environment from the retail domain environment to minimize connections outside the retail domain. In addition, it is best to use a whitelist in the retail domain, where only the machines and addresses in the list can be accessed by systems in the retail domain.
3. Use application whitelists on core systems
Whitelisting of applications should be implemented on all core systems to reduce the chance of malware execution. The core system includes any system that has access to credit card data, fortress servers, domain control servers, etc.
4. Manage high-permission accounts
Attackers target high-privilege accounts such as local administrators, domain administrators, and service accounts. Reduce the number of high-privilege accounts and ensure that each local administrator account has a different, preferably random, password. Use a password management tool to manage accounts. It is best to automatically generate new passwords after each use of these accounts. These technologies can better control the use of high-privilege accounts.