Currently, the majority of HTTP traffic uses TLS (HTTPS) [1]. This is in part due to free and easy to manage certificates from Let's Encrypt, but also due to HTTP Strict Transport Security, an HTTP header that will tell browsers to only connect to your site via HTTPS [2].

For email, we typically use TLS to connect from our mail client to our mail server. But for email, the weak link is connections between mail servers as they forward email. Years ago, STARTTLS became a popular feature. It does allow servers to discover that the other server supports TLS, and upgrades can happen "on the fly". The system is very simple and efficient, but suffers a major shortcoming: The initial connection is in the clear without TLS, and an adversary may easily alter the content, removing the TLS header, so users will never know that their server sent the email in the clear [3].

More recently, two new standards emerged: MTA-STS (SMTP MTA Strict Transport Security) which can be used to advertise that your mail server supports STARTTLS [5], and SMTP TLS Reporting which allows other mail servers to send you reports about whether or not your mail server responded properly to TLS.

Implementing these standards for your domain is a bit tricky. In this post, I will talk about implementing MTA-STS and TLS Reporting for your domain. I will not talk about how to tell your mail server to verify MTA-STS as it sends email, or how to send TLS reports.

There are two parts to these standards: DNS TXT records that advertise that you are supporting them, and a policy file with details that is served via HTTPS.

Step 1:

First of all, make sure your systems are configured correctly and are using proper TLS certificates. In particular mail servers often use bad certificates as you can get away with it. But once you have MTA STS enabled, all these checks need to pass. As a quick check, I recommend hardenize.com (I found the cache doesn't always get cleared if you re-test, so you may wait a while or do some manual checks after the initial check with hardenize). Hardenize was created by Ivan Ristic who also created the famous ssllabs test. But unlike ssllabs, hardenize goes beyond just https and beyond just basic TLS issues.

After you pass all the tests, it is time to get started on MTA-STS

Step 2: 

Setup a virtual host at "mta-sts.example.com". The hostname has to be "mta-sts". You could add this host name to your existing web server, but it may be cleaner to set up a distinct server (virtual host) for this hostname. It has to support TLS, so make sure to setup TLS and probably a Let's Encrypt certificate with it.

Step 3:

Create the policy file. The policy file has to live in mta-sts.example.com/.well-known/mta-sts.txt . The file is a simple text file. For example:

version: STSv1
mode: testing
mx: isc.sans.edu
mx: mail.dshield.org
max_age: 600

The version should always be "STSv1". The mode can be "testing" (do not enforce the policy), "enforce" or "none". Starting with "testing" is recommended. Next, you list your mail servers. The max_age indicates how many seconds the policy is cashed. Start with something short like 10 minutes until you got it all right.

Test that the policy can be retrieved and it should be returned with a Content-Type of "text/plain".

Step 4:

Next, you need to add two DNS entries. One for MTA-STS and one for SMTP TLS Reporting:

_mta-sts.example.com TXT "v=STSv1; id=201904131609"

Again, the version is always STSv1. The ID can be any string. It is used to detect if the policy changed.

_smtp._tls.example.com TXT "v=TLSRPTv1; rua=mailto:postmaster@example.com"

The version is again fixed. the "rua" part indicates where to send the reports. you may list multiple email addresses separated by a comma. It is also possible to specify an http(s) URI to receive the reports. The reports are small JSON files like (thanks to "S J" for sharing this report received from Google):

{"organization-name":"Google Inc.","date-range":{"start-datetime":"2019-04-12T00:00:00Z","end-datetime":"2019-04-12T23:59:59Z"},"contact-info":"smtp-tls-reporting@google.com","report-id":"2019-04-12T00:00:00Z_domain.com","policies":[{"policy":{"policy-type":"no-policy-found"},"summary":{"total-successful-session-count":1}}]}

And that should be it. Let me know how it goes or add a comment with any additional tips you have. Check Hardenize.com after you are done to make sure all of this works nicely.

[1] https://letsencrypt.org/stats/
[2] https://tools.ietf.org/html/rfc6797
[3] https://www.eff.org/deeplinks/2014/11/starttls-downgrade-attacks
[4] https://tools.ietf.org/html/rfc8561
[5] https://tools.ietf.org/html/rfc8560

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS Technology Institute
Twitter|

If you ever heard me talk about DNS, you will know that I am a big fan of monitoring DNS queries, and I think DNS query logs are the best "band for the buck" log source to detect anomalous behavior. Everything that happens on your network, good or bad, tends to be reflected in DNS.

But there are a couple common "odd" DNS request types that are often mistaken for malicious, or unusual but are actually quite normal. Here are my favorite once:

- Anti Malware Checks:

I got an example from Sophos Anti Virus here, but other vendors use a similar technique:

0.0.3.0.0.0.0.0.0.2.0.0.0.0.1.01.00.sfi_unknown.f.01.mac.sophosxl.net
0.0.0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.sfi_unknown.b.f.01.mac.sophosxl.net
3.1o19sr00s2s17s4qp3759pn9ro30n2n4n941on29s3s35qppp742380s6487np3.poqp0r741pn37393648s20n65203rn4o44387s5831o276q6s5rqsr16n809qp4.86752ss34q9sns005o.35n2s0s521p9rn7o75q0r479rpqq7o0oq6r6o20p.i.01.mac.sophosxl.net
3.1o18sr00s2s17s4qp3759pn9ro30n2n4n941on29s3s35qppp742380s6487np3.poqp0r741pn37393648s2779qp6or2108n4o66o276n931p8287709r73q098rp.86752ss34q9sns005o3pp76q83qr6344r79q7rpns9.485n1675n4750q4n.i.01.mac.sophosxl.net
0.0.3.0.0.0.0.0.0.2.0.0.0.0.1.01.00.sfi_unknown.f.01.mac.sophosxl.net
0.0.0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.sfi_unknown.b.f.01.mac.sophosxl.net
3.1o19sr00s2s17s4qp3759pn9ro30n2n4n941on29s3s35qppp742380s6487np3.poqp0r741pn37393648s20n65203rn4o44387s5831o276q6s5rqsr16n809qp4.86752ss34q9sns005o.35n2s0s521p9rn7o75q0r479rpqq7o0oq6r6o20p.i.01.mac.sophosxl.net
3.1o18sr00s2s17s4qp3759pn9ro30n2n4n941on29s3s35qppp742380s6487np3.poqp0r741pn37393648s2779qp6or2108n4o66o276n931p8287709r73q098rp.86752ss34q9sns005o3pp76q83qr6344r79q7rpns9.485n1675n4750q4n.i.01.mac.sophosxl.net

At first sight, you may mistake these requests for typical DNS covert channels. But they are actually associated with Sophos Antivirus. The reason for these queries is that Anti-Malware uses DNS to check if certain files are malicious. The software will send a hash of the file to the vendor and receive back an indication if the file is malicious or not. This will also allow the vendor to compile statistics on the popularity of certain software which will then often be used to compile risk scores (sorry... feed a machine learning AI engine that will protect you from 0-day attacks... or something like this if you read the vendor ads for various products like this). In some ways, this is an exfiltration activity. Just not malicious.

- Mail Servers

We all know that clients usually try to resolve A or AAAA records. But let's take a look at the snapshot below of the records types from a quick query log sample (collected via bro in this case):

The high percentage of PTR records may appear odd. In this case, however, the network includes a busy mail server. Mail servers, for anti-spam filtering, often resolve IP addresses to match forward and reverse resolution.

- Other .arpa hostnames

Talking about PTR records. Pretty much everybody reading this, probably knows about in-addr.arpa and ipv6.arpa and how it is used for reverse resolution. But these are not the only ".arpa" records you see. One record I see more and more is ipv4only.arpa. This record is used to detect if the host is on an IPv6 only network, and DNS64 is used to map IPv4 addresses to IPv6. This record should resolve to 192.0.0.170/171. Only the A record exists. For a AAAA query, you will not get an answer unless your name servers (do to DNS64), is making one up. There are actually a few more .arpa hostnames but this is the one I usually see quite frequently.

- develooper.com

When I saw this first, it looked like a typosquatting domain to me. But the company behind this domain is an active contributor to a number of open source projects, and in my case, it was their contribution of resources to perl.org that triggered the DNS requests.

Any odd DNS requests that you ran down to only find them to be harmless?

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS Technology Institute
Twitter|

Keeping an organization’s IT assets secure in this day and age is a challenge.  The sands of the information security landscape are constantly shifting, and it can be difficult for practitioners to find solid footing; to identify those initiatives that will net the greatest return on security spend.  Each day seems to bring another emerging concern in the threat landscape.  The organization itself often seems to work against us, wanting to expand our already too-broad attack surface by embracing new technologies, connecting with partners, or acquiring other businesses entirely. 

In such a climate it can be easy to allow our attention to be drawn to the expanding edge or our environment and the newest threats to be found there.  Advanced Persistent Threats (APT), supply chain risks, and cloud/container platform issues, to name a few, are more recent additions to our list of concerns.  And let’s be honest, as technologists we are drawn to the new, the novel, the esoteric – because it is interesting.  While there are real risks to be addressed here, they may not represent the greatest area of exposure for your users and information assets or the best ROI. 

Over the past four years of performing research for monthly threat briefings there are three themes that constantly arise which, if mastered, can greatly reduce the information security risk to the enterprise.  These are:

1. Keep systems and software components up to date.  This includes regular patching as well as upgrading platforms when they are no longer supported.  Two key components of a success patching program are making sure that all devices in the environment are (1) identified and (2) under management.
2. Enforce the principle of least privilege.  User accounts, applications, service accounts and network resource permissions must all be taken into account and kept up to date.  The use of segmentation and micro-segmentation strategies are an excellent additional layer of control to apply. 
3. Constantly train users on security culture and safe computing practices.  User training and awareness cannot be limited to phishing emails or social engineering alone.  Topics should include physical security related issues (locking doors, desks, and cabinets), challenging strangers for credentials when appropriate, responsible data distribution practices and how to report suspected oversights.  Ultimately this must be a paradigm shift; an exercise in building an organizational culture that emphasizes security and the priority of reporting suspected indicators of incidents in a consequence-free climate.

Often, the root cause of a security incident can be traced back to failures associated with one or more of these three points rather than some fringe security exposure.  Environments are dynamic, and it is unlikely we can ever be certain that we have 100% coverage for any security practice or solution we put in place; especially over time.   As a result, when asked by customers what they should be focusing on, I always recommend they consider these practices critical, foundational elements of their security program and work to validate and improve upon the effectiveness of these capabilities on an ongoing basis.   

The truth is that such core security practices not particularly interesting and focusing on the fringe of the threat landscape is far more appealing.  The idea that we are on the front lines, in a fight against cybercrime syndicates and cabals of foreign intelligence agents, can add a certain mystique to the information security role.  As though we are a combination of Elliot Ness and James Bond ready to win the day. 

The trick is not to under-invest resources in those often-mundane components of the security program while we look to the horizon.  Perhaps a better role model for the information security function is Wall-E; the trash-compacting protagonist who spends his days cleaning up the mess and trying to put things in order despite the overwhelming scope of the problem.   While not as dashing a self-portrait, Wall-E accomplished something that James Bond never did: he introduced new concepts to people, driving awareness, which ultimately invoked a widespread and long-term cultural change for the better.  And that is a pretty good day’s work.

Continuing with my preliminary exploration of Ghidra. If we continue with the call to RegOpenKeyExA from last time (yes, I know this code is unreachable as we discussed last time, but let's keep going anyway).

If we look back up at the first parameter, we see 0x80000001. Off the top of my head, I don't remember which key that is (well, actually, I've been doing this long enough that I do, but let's pretend that I don't). In IDA, I'd right-click on that hex value and choose 'Use standard symbolic constant' to replace that with the constant definition from one of the Windows header files that defines those. It turns out, Ghidra lets us do this, too. In Ghidra, right click and choose 'Set Equate' and it pops up a dialog box similar to IDA's from which you can choose the proper constant to use in place of the hex value.

Just like in IDA, if you know the constants for registry keys start with 'HKEY_' (or you looked it up on MSDN, now known as, docs.microsoft.com) you could start typing that and it would narrow down the choices. In this case, it is easily visible. So, double-click on 'HKEY_CURRENT_USER' or click and choose OK and the constant is replaced. Notice that you have the option here to just do the substitution for this one instance or across the entire program. I'm going to leave this at the default, but there may be times when you want to replace the hex value with the symbolic constant everywhere (nearly every time I teach FOR610 a student will ask me if IDA has that capability and, if it does, I'm not aware of it).

Looking above that at the second parameter, I usually want to know which particular subkey is being opened. In IDA, I just hover over the label for the string and it shows me the entire string. In Ghidra, if I hover over it, it shows me part of the string, but not the whole thing. Hmm... That is a bit of a problem. If I double-click on the label, both IDA and Ghidra take me to the place in memory where the string is located, but again, Ghidra doesn't show me the entire string. In the hex column it only shows me the first 9 bytes in hex and then gives me the ellipsis, but in the string part, it still doesn't show the whole thing. It shows the first 40-something characters and then the ellipsis.

In hunting around, I was not able to find a setting to increase that, though I'm sure there must be a way somewhere. If not in a setting, then in the code itself (which is now available on github). You can see the entire string though, if you go through the Search menu (choosing 'For Strings...' option). In this case, since I could see the CurrentVersion substring, I just searched for that and found the following.

In the end, though, I realized I didn't need to go to that much effort, there was a much easier way to see the string. Just go back to the decompiler window. As I mentioned in the previous diary, one way that the decompiler makes our lives as malware analysts much easier is it saves us the effort of having to try to match up the PUSHes or MOVes to figure out which parameter is which. This is especially true when you get into 64-bit malware on Windows which uses a lot more fastcall and the MOVes into registers may not appear in the order you expect. So, when I glance over into the decompiler window, I see this.

Very nice, it has my symbolic constant, it shows the entire string. That's just about everything I think I need to know about that API call.

I think that's enough for this diary, I have at least one more to come (probably next week). Again, as I mentioned in the first 2 entries in this series, this is all just from a very brief time playing with Ghidra. I haven't had a lot of time to dig deep yet, but so far, I'm liking what I'm finding. If you have any thoughts, comments, corrections, or tips of your own, please e-mail me or use the comments below.

---------------
Jim Clausing, GIAC GSE #26
jclausing --at-- isc [dot] sans (dot) edu

I found an interesting phishing email which was delivered with a malicious attachment: an UDF image (.img). UDF means “Universal Disk Format” and, as said by Wikipedia[1], is an open vendor-neutral file system for computer data storage. It has supplented the well-known ISO 9660 format (used for burning CD & DVD) that was also used in previous campaign to deliver malicious files[2].

Here is a copy of the mail:

From: <redacted>
To: <redacted>
Subject: Overdue Invoice
Valued customer,
Attached is your invoice as scheduled, your credit/debit card will be charged. Your bill will be delivered along with your ordered items(s).
Please review the receipt at your earliest convenience and get back to us in case of anomalies.

Thank you for your continued patronage.

Warm regards.

The attached files was called "invoice#003.img" with the SHA256 hash: 886338ebc04e728338874b07365d4fd337998e1786893b680065358e815a6d02. At the moment, the file is flagged by 23 AV on Virustotal[3]. To read the content of the archive safely, you can use the ‘loop’ driver on a Linux system:

# mount -o loop /tmp/invoice\#003.img /mnt/malicious/
# ls -l /mnt/malicious
total 1296
-r-xr-xr-x 1 nobody nogroup 1325568 Apr 14 23:45 invoice#003.exe
# shasum -a 256 /tmp/malicious/invoice*
b3aef0e1d7a71edbc858a81e66f354be1974aafdd4449f2972e4dae1c82f2b8a  /mnt/malicious/invoice#003.exe

Here, the VT score is 35[4], it’s a classic malware written in AutoIT, nothing special. It tries to connect to kingdevil[.]ddns[.]net:4156.
Let’s have a look at the UDF image:

00008220: 2020 2020 2020 2020 2020 2020 2020 2020
00008230: 2020 2020 2020 2020 2020 2020 2020 494d                IM
00008240: 4742 5552 4e20 5632 2e35 2e38 2e30 202d  GBURN V2.5.8.0 -
00008250: 2054 4845 2055 4c54 494d 4154 4520 494d   THE ULTIMATE IM
00008260: 4147 4520 4255 524e 4552 2120 2020 2020  AGE BURNER!
00008270: 2020 2020 2020 2020 2020 2020 2020 2020
00008280: 2020 2020 2020 2020 2020 2020 2020 2020
00008290: 2020 2020 2020 2020 2020 2020 2020 2020
000082a0: 2020 2020 2020 2020 2020 2020 2020 2020
000082b0: 2020 2020 2020 2020 2020 2020 2020 2020
000082c0: 2020 2020 2020 2020 2020 2020 2020 2020
000082d0: 2020 2020 2020 2020 2020 2020 2020 2020
000082e0: 2020 2020 2020 2020 2020 2020 2020 2020
000082f0: 2020 2020 2020 2020 2020 2020 2020 2020
00008300: 2020 2020 2020 2020 2020 2020 2020 2020
00008310: 2020 2020 2020 2020 2020 2020 2020 2020
00008320: 2020 2020 2020 2020 2020 2020 2032 3031               201
00008330: 3930 3431 3530 3034 3635 3430 300c 3230  9041500465400.20
00008340: 3139 3034 3135 3030 3436 3534 3030 0c30  19041500465400.0
00008350: 3030 3030 3030 3030 3030 3030 3030 3000  000000000000000.
00008360: 3030 3030 3030 3030 3030 3030 3030 3030  0000000000000000
00008370: 0001 0049 6d67 4275 726e 2076 322e 352e  ...ImgBurn v2.5.
00008380: 382e 3000 0000 0000 0000 0000 0000 0000  8.0.............

ImgBurn is a well-known Windows tool used to create CD/DVD images[5] and guess what? A stock Windows handle this type of file without any extra tool:

So be careful with .img files! They should also be added to the list of prohibited file extensions in your mail relays or change the file association in your Windows environments to NOT open them Windowd Explorer.

[1] https://en.wikipedia.org/wiki/Universal_Disk_Format
[2] https://isc.sans.edu/forums/diary/Malicious+iso+Attachments/22636
[3] https://www.virustotal.com/#/file/886338ebc04e728338874b07365d4fd337998e1786893b680065358e815a6d02/relations
[4] https://www.virustotal.com/#/file/b3aef0e1d7a71edbc858a81e66f354be1974aafdd4449f2972e4dae1c82f2b8a/detection
[5] https://www.imgburn.com

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