Archive for October, 2019

EML attachments in O365 – a recipe for phishing, (Thu, Oct 31st)

I’ve recently come across interesting behavior of Office 365 when EML files are attached to e-mail messages, which can be useful for any red teamers out there but which can potentially also make certain types of phishing attacks more successful.

Office 365, just like any other e-mail gateway with security features, uses a number of complex anti-phishing mechanisms and filters to catch malicious messages. This means that if we try to send an e-mail to a “Target User” which looks like a message from Paypal, but the embedded link points to a phishing site, O365 will correctly identify it as phishing/spam and catch it. The following example, where the link points to, instead of, illustrates this behavior nicely.

Before we move forward, let’s take a quick look at EML files. These are used to save e-mail messages by many e-mail clients (AKA Mail User Agents) and even Outlook and most other e-mail clients, which do not use EML as the default format for saving messages, at least have the ability to open and display them. EML files have a very simple internal structure – EML is basically just a MIME standard e-mail saved in a text file – and therefore an arbitrary one may be crafted quite easily as the following example shows.

MIME-Version: 1.0
Content-Type: text/html; charset=UTF-8
Date: Thu, 31 Oct 2019 10:29:47 +0100
From: Dracula 
To: Jan Kopriva 
Subject: Halloween

Hi Jan,

Just wanted to let you know I'll see you tonight... ;)



This is the reason why e-mail gateways are sometimes configured to either mark messages containing EML attachments as potentially dangerous, scan such attachments or block them outright. Office 365 seems to do an anti-malware scan of EML attachments, but it doesn’t run them through anti-phishing filters… And you can probably see where this is heading.

If we were to craft an EML with the same contents as the first e-mail we looked at (which O365 caught as phishing) and sent it as an attachment, it would get through. If we put a text along the lines of “We’ve noticed you didn’t respond to our original message, so we’re sending it to you again” in the body of the main e-mail, there is quite a good chance that the intended recipient would at least open the attached EML.

But it gets better than that – nothing is stopping us from changing the sender in the EML to a legitimate Paypal (or other) address. The same EML may, of course, bypass other e-mail security gateway scans as well, depending on how they are configured. But with O365, here is (at least to my mind) the best part – if we send such an e-mail, as soon as our Target User opens the attachment in O365, Outlook will helpfully even put a Paypal logo next to the sender address. Thanks to this, the message really starts to look trustworthy.

I’ve informed Microsoft of this behavior of O365 and since they usually don’t consider similar behavior a vulnerability, the reply I got from them was exactly the one I expected (i.e. “Unfortunately your report appears to rely on social engineering to accomplish, which would not meet the bar for security servicing”).

Although I don’t assume attackers to start using this technique en masse, I would still recommend considering automatically marking e-mail messages with EML attachments as potentially dangerous and adding a short warning about the potential risks of EML attachments into end-user security/phishing awareness courses.

If you find this technique interesting and would like to take a closer look at couple of others, consider joining us for a talk dedicated to this subject at SANSFIRE 2020 – we will go through many more tricks and techniques, some of which are not (yet) used in the wild.

Jan Kopriva
Alef Nula

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Keep an Eye on Remote Access to Mailboxes, (Wed, Oct 30th)

BEC or “Business Email Compromize” is a trending thread for a while. The idea is simple: a corporate mailbox (usually from a C-level member) is compromized to send legitimate emails to other employees or partners. That’s the very first step of a fraud that could have huge impacts.

This morning, while drinking some coffee and reviewing my logs, I detected a peak of rejected authentications against my mail server. There was a peak of attempts but also, amongst the classic usernames, bots tested some interesting alternatives. If the username is “firstname”, I saw attempts to log in with:


And also the classic generic mailboxes (‘noreply’, ‘info’, webmaster’, ‘admin’, etc)

The peak of activity was interesting:

Email remains an easy attack vector and is often very easy to compromise. Access to a corporate mailbox can be disastrous based on what people store in their mailbox (documents, passwords, pictures, etc) and mail servers remain often available in the wild. Keep an eye on remote accesses to mailboxes, especially for sensitive accounts! (Do you remember my diary about considering people as IOC’s?[1])


Xavier Mertens (@xme)
Senior ISC Handler – Freelance Cyber Security Consultant

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Generating PCAP Files from YAML, (Tue, Oct 29th)

The PCAP[1] file format is everywhere. Many applications generate PCAP files based on information collected on the network. Then, they can be used as evidence, as another data source for investigations and much more. There exist plenty of tools[2] to work with PCAP files. Common operations are to anonymize captured traffic and replay it against another tool for testing purposes (demos, lab, PoC).

When you anonymize PCAP files, the goal is to replace IP addresses by other ones (The classic operation is to replace the first byte with a ’10’ value to make the IP address non-routable). However, the payload may contain sensitive data that are more difficult to sanitize. Last week, I attended the[3] conference in Luxembourg and, during the lightning talks session, an interesting tool was demonstrated: pCraft. It can be described as a “PCAP file generator from a scenario described in YAML[4]”. The idea behind this tool is to create a scenario of network actions that will be translated into a fully-working PCAP file. 

Here is a quick example to demonstrate how to test an IDS rule:

start: GenerateNewDomain

  _plugin: GenerateNewDomain
  _next: DNSConnection

  _plugin: DNSConnection
  sleep: {"once-finished": 1}
  _next: HTTPConnection

  _plugin: HTTPConnection
  method: GET
  uri: "/shell?busybox"
  user-agent: "Mozilla/5.0"
  _next: done

The script is easy to understand: We generate a random domain name, we resolve it then we generate an HTTP request to the servers with a suspicious URI.

Let’s generate the PCAP file:

# ./ test.yaml test.pcap
['PCraft/plugins/', 'PCraft/plugins/', 'PCraft/plugins/', 'PCraft/plugins/', 'PCraft/plugins/', 'PCraft/plugins/', 'PCraft/plugins/', 'PCraft/plugins/', 'PCraft/plugins/']
All plugins loaded!
Opening Script File test.yaml
[2019-10-28 18:01:35.324952] Executing: Generate_a_new_domain
[2019-10-28 18:01:35.367461] Executing: DNSConnection
[2019-10-28 18:01:35.368882] Executing: HTTPConnection
[2019-10-28 18:01:36.984010] Executing: done

The PCAP file can now be used to test our IDS or any other application.

Let’s open it in a Wireshark and inspect the HTTP request:

pCraft is written in Python and, if you check the required modules, you see it relies on scapy[5] to generate packets and the PCAP file. Not many types of traffic are supported at the moment but, being based in plugins, it’s easy to expand it. The current list of plugins is:

  • DNSConnection
  • GenerateNewDomain
  • HTTPConnection
  • HTTPPostConnection
  • PCAPImport
  • Ping
  • TcpRst

pCraft has been developed by Sébastien Tricaud and is available on github[6]. Great tool!


Xavier Mertens (@xme)
Senior ISC Handler – Freelance Cyber Security Consultant

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Using scdbg to Find Shellcode, (Sun, Oct 27th)

I’ve written a couple of diary entries about scdbg, a Windows 32-bit shellcode emulator.

If you’re not familiar reading assembly code or machine language, scdbg can help you understand what shellcode is doing, by emulating it and reporting relevant Win32 API calls.

By default, scdbg assumes that the shellcode’s entrypoint is the first instruction, e.g. position 0. That’s not always the case, and you can use option -foff to provide a different position (offset). But this assumes that you know where the shellcode’s entrypoint is. And determining this can be difficult too when you analyze malware.

To help you locate shellcode’s entrypoint, or just find shellcode inside a file, scdbg has an option: -findsc.

As an example, I created a JPEG file that contains shellcode (not an exploit, the shellcode will not execute, it’s just hidden inside a JPEG image).

Giving this file as input to scdbg using option -findsc does the following:

scdbg tries all possible entrypoints to the shellcode in this file, and then reports entrypoints (offsets) that lead to emulations that resulted in a Win32 API call or a long execution (many steps).

In the screenshot above, we see that scdbg found 6 offsets (numbered 0 through 5). Entry 0 looks promising (offset 0x7C2), as this lead to the call of MessageBoxA.

scdbg then prompts for the index of the shellcode’s offset to emulate. I select 0 and get the following result:

This is indeed shellcode that was found at position 0x7C2: it displays a message box and then terminates the host process.


Didier Stevens
Senior handler
Microsoft MVP

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →
Page 1 of 6 12345...»