Companies using Data.com which is maintained by Salesforce could be in for an infection if they aren’t careful what they click on. These days attack vectors can come from anywhere, even the trusted resources we use. Many would consider data.com a trusted resource, but I’m starting to evaluate exactly what we consider a trusted resource and just how trustworthy are they.
“Data.com Connect gives you instant access to millions of professionals, leads and company lists. They claim on data.com “It’s the fastest way to connect with the right decision maker!“
Recently a sales member was taking stock in the information contained within data.com while performing routine job functions. To get some additional information on a company, Hagerstown Medical Laboratory the user clicked on the Website URL as seen below.
As soon as the URL above hagerstownmedlab.com was clicked, his Chrome browser became unresponsive and was redirected automatically to a different website, http://warning.netsecurityalerts.com warning him that his browser and computer may be compromised. In addition to the click-jack, an audio file (later discovered to be an mp3) was playing in the background.
Here is HTML output of an alert that popped up, highlighted in red
alert (“WARNING: ” + getURLParameter(‘isp’) + ” Customer – Your ” + getURLParameter(‘browser’) + ” browser and computer may be compromised by security threats. Call 1-877-756-4104 now for IMMEDIATE assistance.”);
This user was lucky that one of our CSIRT team members was walking by when this happened. The CSIRT team member took control of the workstation, exited the browser which killed the “scareware” and began monitoring the traffic from that workstation as he began a full investigation of what transpired.
The first tool used in this forensic investigation was the Scrutinizer Incident Response System. Using two identifying URLs and the starting timeframe, an IPFIX report was pulled to learn more about the communication that took place. Applied filters include the timeframe, exporter that exports url/http host (in this case a SonicWALL), and the URLS. With the filters applied, I simply ran the default flow report, conversation Well Known Port (WKP) to identify that IP conversations. The 2 external IPs involved are 69.43.161.179 and 173.197.195.88
NOTE: Only a few vendors export the URL in IPFIX (Cisco, Citrix, Plixer and SonicWALL).
We focused on the suspect URL in question as the starting point. To do this, one of the URL filters was removed. We then needed to gain greater details on what exactly happened when this website was visited. In this case the Endace Packet Capture integration with Scrutinizer was configured. This allows the full capture of the conversation to be exported from the Scrutinizer interface. The image below highlights the click process navigation to Endace:
The Initiator and Target IP are automatically populated along with the TCP protocol. Simply click “Search” and the “Download: pcap | erf” appears. To grab the packets, click on “pcap”
Once in wireshark I looked at the HTTP object list to gain insight at what was called.
When looking at the TCP stream in the figure below, notice in the initial GET that we see Javascript using variable definitions a, b, and c, to perform a redirect to park.above.com/jr.php?gz. Basically, the user thinks they are going to the web site: hagerstownmedlab.com in truth, the link redirects the user a few times where they eventually end up at an infected site. And, if the redirect fails, the user is prompted with “Click here to enter” in an effort to make sure the user makes it to the intended site!
- var c = an encrypted string that redirects the browser
- var b = (61) is simply the ‘=’ sign
- var a = takes the browser to above.com which was hosting the encrypted string containing the malware
Once they visit the above page, there is another page redirection. If we look at the second (last) tcp stream we see a redirect to ze.zeroredirect1.com. If the java script once again failed to redirect the user “Click here to enter” was posted to the user.
As this point we pulled more packets via Endace using Scrutinizer to obtain additional IPs related to the newly discovered URLS. Without getting into all the gory details, several more redirects occurred and the chain of URL redirects ended with this site: warning.netsecurityalerts.com. I have included the virustotal.com URL for this domain, which is currently hosting the fake/rogue AV product.
There were two redirects not shown above that returned 404’s, as they were not currently running. It looks like two of the servers in the chain of exploitation were down at the time, therefore the malware was unsuccessful in completing the mission. I fear that other users may have clicked on this profile because it was last edited over a year ago. To see what I’m talking about, go back to the top and check out the first image. Notice at the bottom: Last Updated AaronBiddar on 11/14/13.
Conclusion: In our case the user was lucky that two of the servers were down and the malware mission was unsuccessful, otherwise this could have ended up very different. Question is: Would Salesforce have been to blame? Better check your end user license agreement.