Archive for July 23rd, 2019

May People Be Considered as IOC?, (Wed, Jul 24th)

That’s a tricky question! May we manage a list of people like regular IOC’s? An IOC (Indicator of Compromise) is a piece of information, usually technical, that helps to detect malicious (or at least suspicious) activities. Classic types of IOC are IP addresses, domains, hashes, filenames, registry keys, processes, mutexes, … 

There exists plenty of lists of usernames that must be controlled. Here is a short list or typical accounts used to perform (remote) administrative tasks or belong to default users:


If the activity of such kind of users must be logged and controlled (admin users, system accounts), let’s think about “real” people now. It could be very interesting to keep an eye on the activity of “high profiles” inside the organization like the board of directors (whose are always juicy targets). But, don’t forget the opposite with “low profiles”. Non-tech people who perform daily dangerous tasks. Can we consider them as “IOC”?

Let me tell you a story: A  few years ago, when ransomware waves were not very popular, a customer faced a security incident and several Windows shares were encrypted after a user opened a malicious attachment. The person was not to blame: (s)he was responsible for the “[email protected]” mailbox. A daily task was to process all emails sent to this address. Chances to see the profile of this person compromized is much higher than a regular user. Can we track him/her as an IOC? What if suddenly we detect a lot of logon attempts with his/her credentials?

How will behave less security-aware people when they are facing a threat? The same applies to specific departments, like human resources, where one of the tasks is to open and read candidates’ resume based on Office or PDF documents.  May we assign a “score” to people? In many organizations, people can try to bypass security controls and behave in an unsafe way (I call them “mad-clickers”). More they appear in security reports, their score gets higher and could attract our attention.

Of course, all this process must be performed with respect of privacy. The goal is NOT to spy them!

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) →

Verifying SSL/TLS configuration (part 1), (Tue, Jul 23rd)

One of very important steps when performing penetration tests is to verify configuration of any SSL/TLS services. Specifically, the goal of this step is to check which protocols and ciphers are supported. This might sound easier than it is – so this will be a series of diaries where I will try to explain how to verify configuration but also how to assess risk.

We cover this in the SEC542 course (Web App Penetration Testing and Ethical Hacking), but verifying configuration is not limited only to web applications – we should do it in both external and internal penetration tests.

While one could create a small script around the openssl command to verify for all supported protocols and ciphers, it is much easier to use some of the following tools. Let’s dive in:


While some people might use nmap only for port scanning (Trinity used it for OS fingerprinting as well – good job Trinity), in last couple of years I became a huge fan of Nmap’s scripts. NSE (Nmap Scripting Engine) allows creation of scripts in the embedded Lua programming language. There are ~600 NSE scripts which are distributed with nmap today and some of them should be your everyday tools – especially for checking SSL/TLS configuration. Here they are:

ssl-enum-ciphers.nse – this is the most powerful NSE script for SSL/TLS checking. It will verify which protocols are supported (SSL3 and above) and then enumerate all cipher algorithms. Besides this, ssl-enum-ciphers will also give you a rating (score) on how good or bad a cipher is. Do not take this for granted, although generally the scores are good.

Below we can see ssl-enum-ciphers executed against my mail server. The output is pretty self-explanatory and you can see that I tried to lock the configuration a lot by supporting only TLSv1.2 and using strong ciphers, with preferred PFS (Perfect Forward Secrecy) algorithms. All of these will be explained in future diaries.

$ nmap -Pn -sT -p 443 –script ssl-enum-ciphers
Starting Nmap 7.70SVN ( ) at 2019-07-23 09:29 UTC
Nmap scan report for (
Host is up (0.087s latency).
rDNS record for

443/tcp open  https
| ssl-enum-ciphers:
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) – A
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) – A
|       TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 2048) – A
|       TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 2048) – A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) – A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) – A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) – A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) – A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 2048) – A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) – A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 2048) – A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) – A
|       TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) – A
|       TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) – A
|       TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) – A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) – A
|       TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) – A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) – A
|       TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 2048) – A
|       TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) – A
|       TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 2048) – A
|       TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) – A
|     compressors:
|       NULL
|     cipher preference: server
|_  least strength: A

sslv2.nse – while the ssl-enum-ciphers script is amazing, it does not support SSLv2. Keep this in mind – because when you scan a network with it, it will not report usage of SSLv2 so you might miss it. This is why we have the sslv2 script, so make sure you run it everywhere.

ssl-cert.nse – this is a nice small script that will retrieve information about the X.509 certificate used on the target web site – perfect for easy collection and examination of this information on wide range of targets. We can see it running here:

$ nmap -Pn -sT -p 443 –script ssl-cert
Starting Nmap 7.70SVN ( ) at 2019-07-23 09:32 UTC
Nmap scan report for (
Host is up (0.039s latency).
rDNS record for

443/tcp open  https
| ssl-cert: Subject:
| Subject Alternative Name:,
| Issuer: commonName=Let’s Encrypt Authority X3/organizationName=Let’s Encrypt/countryName=US
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha256WithRSAEncryption
| Not valid before: 2019-05-27T07:47:53
| Not valid after:  2019-08-25T07:47:53
| MD5:   f31d bf25 01d3 c303 e762 e1e3 bb86 9c5b
|_SHA-1: 3835 540e 9d14 2537 7c7f b9be 0abb ba37 161a cc4e

ssl-dh-params.nse – finally, this is the last script I use when checking SSL/TLS configuration. This script will analyse Diffie-Hellman MODP group parameters and report if weak DH parameters are used (i.e. CVE 2015-4000 and other weaknesses).

Finally, just keep one thing in mind – whenever you use nmap make sure that you have the latest version installed (I actually pull the one from Subversion and compile it manually). Many Linux distributions come with ancient nmap versions so not only you might be missing features and bug fixes, but the scores for ciphers might be wrong.

Another great resource for SSL/TLS configuration testing is the script. This script comes with its own, statically precompiled version of openssl which supports every possible protocol and cipher. This way the author ensures that nothing will be missed (there was a huge hiccup with Kali Linux and SSLv2 support back in 2013 when they removed it and a lot of penetration testers got burned).

My suggestion is to clone from github to make sure you have the latest version – no compilation is needed. Just run it against the target web site and you will see nice coloured results as shown in the screenshot below for my server:

Qualys SSL Labs:

Finally, the last great online resource is the Qualys SSL Labs SSL Server Test done by @ivanristic. SSL Server Test will perform a bunch of different tests and generate a very, very detailed report on SSL/TLS configuration, together with the final score – and everyone will try to achieve A+ of course (we all like green, A+ grades).

SSL Server Test is available at so, obviously, you can use it only for publicly available web sites. Additionally, don’t forget to select the “Do not show the results on the boards” box so your test will not be shown on the web site.


As we can see, there is a plethora of good tools we can use. But besides running tools, we need to be able to interpret the results as well. For example, if 3DES is used on your Microsoft Terminal Server (RDP), is that a bad thing or not? Can we live with it?
I will cover all these cases in future diaries – let us know if there is something specific you would like us to write about.

And I almost forgot – if you want to hear more about this, there is a nice (I hope!) SANS Webcast this Thursday, July 25th, 2019 at 10:30 AM EDT (14:30:00 UTC), “A BEAST and a POODLE celebrating SWEET32” where I will be demoing some of SSL/TLS vulnerabilities.

An even longer presentation will be at the BalCCon2k19 conference this year so let me know if you are around! 


(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) →