Offline, yet still exploited

The Hacker Series

By Bhaumik Merchant, Information Security Research Consultant, Indusface

Introduction:

This article demonstrates a unique kind of communication technique between an attacker machine and a victim machine during the exploitation of any victim machine .In a general scenario, while an attacker exploits the remote machine and gets the remote command prompt (remote shell), the attacker is only able to execute commands till the session from the remote machine is opened (established). While exploiting the machine in a normal way, both the attacker and the victim machine should be online if the attacker wants to execute some commands in the remote machine (victim’s machine). This paper is going to demonstrate methodologies where an attacker can attack a remote victim without being online (i.e. the attacker may be online and the victim may or may not be online).

Overview:

During the exploitation of a vulnerable remote machine (victim’s machine) by an attacker, after a vulnerability injection, the attacker sends a payload and gets a remote command prompt on his/her machine. In this case of normal payload, the limitation for an attacker is that once the session is expired or the shell is terminated, the attacker can’t execute commands in a remote machine (victim’s machine). This white paper demonstrates a new type of payload by using which an attacker can execute a command in a remote machine (victim machine) without actually directly connecting to the victim’s machine.

Methodology:

In a general scenario, if an attacker gets a remote command prompt and executing a command using that current session then there is a direct communication (connection) between the attacker and the victim machine. But by using this paper’s mechanism we can prevent direct communication (connection) between the attacker and the victim. For this, we use an intermediate server (zombie) that is up and running all time (24×7). In our case, we use this zombie as an email service like Gmail, Yahoo, MSN, etc. So the whole machine works as explained below:

The attacker infects a remote machine with an executable, which can be infected by one of the methods below:

1. By autorun.inf
2. During Metasploit exploitation
3. Physical access of the victim’s machine

Now once the executable is up and running in the remote machine (victim’s machine), when the victim connects to the internet then it first checks the instruction set in the Gmail inbox by an attacker. Now let’s say if an attacker wants to execute the command ‘ipconfig’ in the remote machine (victim’s machine) then the attacker has to send an email with the subject ‘ipconfig’ to his own email address. Because the username and password are already encrypted in the executable file in the remote machine (victim’s machine), and as the victim comes online, that executable file automatically logs into the victim’s Gmail account and reads all command instructions which is loaded by the attacker.

It executes the commands of the attacker’s choice and attaches the results to the attacker’s Gmail account. Attackers simply have to download the attachment which contains command output from the victim’s machine. As a result, there is an email service (Gmail) between the attacker and the victim’s machine. This shows that the attacker can execute a command in the victim’s machine but there is no direct connection between the attacker and the victim’s machine, And if the attacker uses Tor ( The Onion Router Browser ) or Anonymizers for accessing the Gmail account then the attacker can never be caught (any reverse traces).It is something like Attacker <->email service <->Victim <->. The life cycle is as shown below :

Hands-On-Approach :

Stage-I

Let’s say you have an infected remote machine with this exe and you want the account , drive and network information from the remote machine (victim’s machine) , then you have to send an email to your own account (note : which is also being listened and shared by the injected exe in the remote machine) with subject containing account_info, driveinfo ,networkinfo as shown in the figure below.

Stage-II

Now once the email with an appropriate subject is sent to your account, now it is time for the remote machine (victim’s machine) to come online and fetch the instructions given by the intruder (in this approach ,”Attacker “). As the victim’s machine comes online , it executes appropriate commands of the attacker’s need, redirecting command output to .data file and finally automatically attaches this file to your email account .Hence , by simply downloading this file you will get all the cmd output in attached .data file as shown in below figure.

Here in the above figure you can clearly see that, all required outputs are attached in your email address!

Advantages:

1. The attacker is never going to get caught if he/she uses the browser like TOR , Anonymizer , VPNs or any proxy…. for accessing the gmail account used for attacking purposes.
2. No Antivirus can detect the instruction data because all traffic is going to  come from HTTPS, Antivirus Software and Network Intrusion Detection Software which detects simply an outbound connection with gmail.
3. Only a single email account of gmail is going to be used for both sides. Attacker and victim’s machine are both going to connect to the same account which the attacker knows about, but the victim does not.

Disadvantages:

If the victim has a habit of checking the current connections using commands like ‘netstat –n’ then there is a possibility to detect a gmail connection when actually there is no browser activity. This is tough to detect, because the process is running in a hidden mode.

Conclusion:

The countermeasures against these kind of attacks should be taken by e-mail providers (like Gmail, yahoo, msn etc). They can prevent these kind of attacks by monitoring unusual behaviour of the host who is making automated API calls (from compromised host to their Servers). Also monitoring User-Agent Strings and email attachments are useful in order to prevent this kind of attacking method.

Stay tuned for more relevant and interesting security articles. Follow Indusface on Facebook, Twitter, and LinkedIn.