We often talk about websites being compromised and injected with malware that redirect users to exploit kits. We unfortunately don’t give you a complete picture of what the distribution payload is doing on your local machine very often. Today we’ll try to improve that analysis by giving you a more complete picture of the full life cycle of a specific distribution payload.
In this example, we’ll be showing you how an attacker is injecting a site with a dynamic iFrame generator, which then attempts to install a malicious payload on your machine. More importantly, we’ll show you what that file is doing locally.
We were actually very lucky in this instance. Instead of a banking trojan, we were able to get our hands on a payload that is designed to steal not only your Browser information, but your FTP credentials as well. This can then be used to compromise any website you own, completing the life cycle of the injection:
compromised site -> compromised desktop -> stolen FTP passwords -> more compromised sites
1- Compromised sites with auto generated iframes
A WordPress site was hacked via brute forcing their wp-admin admin password. We were able to see in the logs that after multiple login attempts, the attackers succeeded and logged in as administrator and used the theme editor to insert the following code at the top of the header.php of the theme:
If you don’t know PHP, this code will contact the website http://126.96.36.199/config.inc.php and will act as a connection to the command and control server to get confirmation of what it should do. This is done in this part of the code:
Which we can easily replicate using Curl to see what it replies:
As I am writing this post, it returns “httx://andlettherebelight.com/news/faults-ending.php”. The same code will get that URL and inject the following iFrame at the bottom of the website, usually after the closing “
2- From server level code to browser injection
<body asd=123><script>z=eval ; ss=String;
... long long code..
A check shows that the distribution payload is not very well detected by Anti-Virus companies. As you can see on VirusTotal, it is 1/46 for one sample:
This means that out of 46 engines, only 1 detected those samples, AVG on the first one and Fortinet on the second. This doesn’t mean that it you won’t be protected at the end-point, but it does mean that they are not able to detect this distribution payload.
4- Command and control and new URLS
Below is a list of all the sites that have been used in the compromise in the time that we have been monitoring this C&C. They seem to rotate out every few hours and the domain does not replicate, this can be for a number of reasons like evading detection, website is cleared of compromise, etc…
Here is the list of the various domains that have been used:
We wanted to see if they are using the same payload each time, and it appears they are. Unlike most of our other research, we decided to see what it might be doing at the end-point. Special thanks to Jerome Segura of Malwarebytes for the help on this front.
It appears that the attackers are performing a drive-by-download in an effort to steal credentials. We often talk about this, but today we can show you more. In this instance working off Windows OS with IE8, we were able to trigger the payload when the conditions are met. This is what the user was greeted with:
If you’re not aware, this is pretty close to what the old download page looked like. This is what it looks like today:
The first sign of fraud should be the domains. The fake one is coming from hxxp://graphicsspecialistsgroup.com/adobe/ and the real one comes from get.adobe.com/flashplayer. When the user clicks on the download the browser will download a file called update_flash_player.exe. This file is being stored on the compromised server and is located in the same directory mentioned above /adobe.
When the user installs the payload, it performs a silent install. There are not actions required by the user, unclear why but it kills the Windows Rundll32 library, then it goes silent. There is no other action to show that something has occurred and to the unsuspecting user it would seem as the update went flawlessly.
This is where our friend Jerome comes into play, he was able to point us in the direction of a few resources that would help us better diagnose what the payload was doing. Surprisingly, when we checked with VirusTotal to see which end-point solutions would detect the payload, only 10 of the 46 players detected.
Fortunately, there are a few good resources out there and we were able to break down the payload further to understand what it was doing. Here is what we know:
It starts a server listening agent on 0.0.0.0:0
Steals private local information from local internet browsers
Harvest credentials from local FTP client software
Installs itself for auto run at Windows startup
Here is a list of all the domains it touches, or reaches out to, when installed:
Here are a few examples of some of the data points it looks to harvest:
C:Documents and SettingsUserApplication DataGlobalSCAPECuteFTPsm.dat
C:Documents and SettingsUserApplication DataGlobalSCAPECuteFTP*.*
C:Documents and SettingsUserApplication DataGlobalSCAPECuteFTP Prosm.dat
C:Documents and SettingsUserApplication DataGlobalSCAPECuteFTP Pro*.*
C:Documents and SettingsUserApplication DataGlobalSCAPECuteFTP Litesm.dat
C:Documents and SettingsUserApplication DataGlobalSCAPECuteFTP Lite*.*
C:Documents and SettingsUserApplication DataFlashFXP3Sites.dat
C:Documents and SettingsUserApplication DataFlashFXP4Sites.dat
C:Documents and SettingsUserApplication DataFlashFXP3Quick.dat
C:Documents and SettingsUserApplication DataFlashFXP4Quick.dat
C:Documents and SettingsUserApplication DataFlashFXP3History.dat
C:Documents and SettingsUserApplication DataFlashFXP4History.dat
C:Documents and SettingsAll UsersApplication DataFlashFXP3Sites.dat
C:Documents and SettingsAll UsersApplication DataFlashFXP4Sites.dat
C:Documents and SettingsAll UsersApplication DataFlashFXP3Quick.dat
C:Documents and SettingsAll UsersApplication DataFlashFXP4Quick.dat
C:Documents and SettingsAll UsersApplication DataFlashFXP3History.dat
C:Documents and SettingsAll UsersApplication DataFlashFXP4History.dat
C:Documents and SettingsUserApplication DataFileZillafilezilla.xml
C:Documents and SettingsAll UsersApplication DataFileZillasitemanager.xml
C:Documents and SettingsAll UsersApplication DataFileZillarecentservers.xml
C:Documents and SettingsAll UsersApplication DataFileZillafilezilla.xml
C:Documents and SettingsUserLocal SettingsApplication DataFileZillasitemanager.xml
C:Documents and SettingsUserLocal SettingsApplication DataFileZillarecentservers.xml
C:Documents and SettingsUserLocal SettingsApplication DataFileZillafilezilla.xml
C:Documents and SettingsUserLocal SettingsApplication DataBulletProof Software*.*
C:Documents and SettingsUserApplication DataBulletProof Software*.*
C:Documents and SettingsAll UsersApplication DataBulletProof Software*.*
C:Documents and SettingsUserApplication DataSmartFTP*.*
C:Documents and SettingsAll UsersApplication DataSmartFTP*.*
C:Documents and SettingsUserLocal SettingsApplication DataSmartFTP*.*
C:Documents and SettingsUserApplication DataMozillaFirefoxprofiles.ini
C:Documents and SettingsUserApplication DataMozillaFirefoxProfilesvglnv7s6.default*.*
C:Documents and SettingsUserApplication DataMozillaFirefoxProfilesvglnv7s6.defaultbookmarkbackups*.*
C:Documents and SettingsUserApplication DataMozillaFirefoxProfilesvglnv7s6.defaultminidumps*.*
C:Documents and SettingsUserApplication DataMozillaFirefoxProfilesvglnv7s6.defaultsignons.sqlite
C:Program FilesMozilla Firefox
C:Documents and SettingsUserApplication DataMozillaFirefoxProfilesvglnv7s6.default/secmod.db
C:Documents and SettingsUserApplication DataMozillaFirefoxProfilesvglnv7s6.defaultsecmod.db
Any of these names ring a bell? What you have here is a perfect example of a payload looking to harvest the data you are storing in your local clients, both browser and FTP.
When it installs it also makes connection with a number of different sites:
Here you can see two things, the authentication is occurring in the first step against the yaklasim.com site, and the payload is being retrieved from the brozziassicurazioni.it site. If you do some more research you find that that the yaklasim site is actually a known malicious domain. This domain is being used for a number of drive by download attacks ranging from stealing credentials like what I described above, to installing banking trojans. Further research shows that the authentication boxes seem to be originating out of Turkey:
IP Address 188.8.131.52
Location TR, Turkey
5- Cleaning up and preventing
As you can see, this type of malware goes the full circle. It compromises websites and use them to infect desktops. Once a desktop is infected, it will use it as part of their botnets, and if the owner of the desktop also has a website, it will use that to inject malware as well.
Our SiteCheck scanner detects this type of injection so if you suspect your site has been compromised, you can check it in there.
About Daniel Cid
Daniel B. Cid is currently the VP of Engineering at GoDaddy, as well as Founder & CTO of Sucuri and the open source project, OSSEC HIDS. His interests range from intrusion detection, log analysis (log-based intrusion detection), web-based malware research, and secure development. You can find more about Daniel on his site dcid.me or on Twitter: @danielcid
We use tools, such as cookies, to enable essential services and functionality on our site and to collect data on how visitors interact with our site, products and services. By clicking Continue, you agree to our use of these tools for advertising, analytics and support.ContinueRead More