Recently I was on site with a customer whom we were working with to provide an extra level of support configuring LogRhythm to target and detect attacks specific to the retail industry.
This includes activity such as deviant behavior in the point of sale environment, potential theft of customer data from corporate IT resources, etc…
We began the process by looking for the malicious activity this module is designed to detect in order to identify anything that had taken place prior to implementation.
During the course of this investigation, we identified a set of activity that indicated there was communication on a known bad channel. This prompted an immediate investigation into the activity to identify all the relevant details surrounding this event so that we could provide forensic evidence of a data breach if necessary. Over the next few days, I will be explaining this process in greater detail.
Step 1. Identifying a potential breach.
In this first installment, I’ll explain how we initially identified the activity that immediately raised concerns that a breach might have take place. It started with an alarm that indicated some entity was utilizing a known malicious command shell port within this network.
LogRhythm Alert Metasploit detected
The destination port number 4444 is the default Metasploit “Command Shell” communication port. To a hacker using Metasploit for this type of attack the command shell might display communication from the attacker to the target host like this:
Figure 1: http://www.offensive-security.com/metasploit-unleashed/Exploits
In this particular instance we used LogRhythm to quickly drill down and locate the specific log messages which identified this attack. It seems as though a connection was made to a few internal Customer Servers. Then something more alarming was revealed when we saw that the last connection was made to a server in Japan.
The FTP server seen making connection 2 and 3 (see image below), are potential prime targets for malicious activity. This server frequently receives remote retail store inventory in the form of PDF’s files via FTP. This makes it a prime target to package a Metasploit Trojan in the form of a PDF file that will wait dormant until someone mistakenly executes it.
Metasploit Log Detail
Note: This retail store chain only has business in the United States. It seems that whomever created this connection was a little bit deliberate in their attempts to mask this traffic.
The origin source for connection one and two, and found in the second to last column. They do not originate from a random high number port as one would expect. Instead those connections are masking themselves as the service ports for their respective host jobs.
After the forensic investigation was complete, LogRhythm learned there was a corporate relationship between the offending entity and has chosen to mask the public destination IP.
Since we needed more information, we performed a quick, right click correlation within LogRhythm:
Right Click -> Correlate on OHost = FTP(MaskedData)
This quickly brought back an hour’s worth of log data detailing the origin host’s recent activity.
A visual baseline clearly identified that one host communicating with the corporate network was geographically district from typical network traffic.
Another right click correlation pulled up the destination coordinates for the communication path.
Additional questions arose. What is this server? Who owns it? What is that IP address doing? The investigation led us to open a browser to see if it server had a publically facing website, which it did.
This is an externally facing default Apache Tomcat Server. Doing nothing. Often times, in this line of work, un-configured servers mean that someone was in a hurry to quickly stand something up that can receive data quickly and with little configuration. For example: A cyber attacker needing a place to upload a whole bunch of your corporate data quickly.
In addition to searching for originating IP address, we had started a virus scan on the FTP server. Zero results returned.
If this were an attack, you would think we’d see something on the server from the AV scan, so this was initially confusing. However, a quick investigation showed that a process was running tied to a legitimate Windows executable (Metasploit) being used to perform suspicious activity, which may not be picked up by an AV scan.
Based on our research we were able to provide the customer with the follow options going forward. Continue the investigation with an endpoint forensics tool, block the attack from happening in the future via firewall rules, or add a packet capture device and keep the investigation going.