I consider DNS one of the great success stories as far as internet protocols go. I remember (for a short time) updating host files and the emergence of DNS. DNS was created for a very different type of Internet then what we have today. It assumed a more "friendly" and cooperative Internet. Without amplified DDoS attacks, MITM attacks, and spoofing. Overall, DNS has survived pretty much in its original form with a couple of relatively small additions like EDNS 0 and DNSSEC (which nobody uses).

But recently, in particular, pushed by the need for more privacy and the more bold and unregulated data trading ISPs participate in, the need has come up for more privacy. Also, the failure of DNSSEC to gain substantial traction has led other, simpler, ideas to provide most of the benefit of DNSSEC.

In this article, I want to highlight two changes that I see showing up in DNS traffic:

1 - DNS Cookies

DNS Cookies have been introduced in RFC 7873 [1]. They try to address many of the problems that DNSSEC tried to solve (like cache poisoning), and they are addressing issues like spoofed DNS amplification attacks that DNSSEC didn't prevent. In some cases, DNSSEC may have made these attacks worse. To make it a total "win": DNS cookies are much easier to implement than DNSSEC. The security afforded by DNS cookies is supposed to be similar to the security gained by using TCP instead of UDP. To successfully spoof TCP, an attacker needs to guess a 32-bit sequence number. DNSSEC is much harder to break. So DNS cookies are not as good as DNSSEC. But they may be "good enough."

So how does it work?

A client sending a DNS request will attach a cookie as an option. The cookie is a hash of client IP, server IP, and a secret. So the server will see consistent cookies from a particular client. The secret should be at least 64 Bits long. The details do not matter as long as the cookie is consistent with a specific server/client combination.

The server cookie uses the server IP address, the client cookie and again a secret that is only known to the server. The client IP is not used since it may change due to NAT. Using the client cookie instead will again lead to consistent cookies for a particular server-client combination.

A client that supports cookies will send them with all requests. This *should* not cause any problems. Unsupported options will be ignored. But some testing has shown in the past that there are non-compliant DNS servers that may reject the request as malformed. This test from a few years ago showed that 10% of name servers had problems. Not sure what this looks like right now, but the number is likely smaller.

The client will include a server cookie if it communicated with this server in the past.

Once a server receives a request with client cookie, one of several options may occur:

1. If the server doesn't support cookies, then it will respond as usual ignoring the cookie.
2. If the server does support cookies, and the client sent a request with only a client cookie, then the server will respond, but it may not include anything but the server cookie. Now the client may re-send the query and include the server cookie. However, servers may also send a complete response and apply different rate limits for server-cookie-less requests. Servers may also be more lenient responding to TCP requests that do not include the cookie.
3. If the client included a server cookie, and the cookie is genuine, then the server will send a response.

For a badly formatted cookie, an error is returned (FORMERR). Requests that include an invalid server cookie are treated like requests that do not include a server cookie at all. This feature allows a client to recover if IP addresses changed, or if the server restarted and selected a new secret.

Cookies have been implemented in BIND 9.11. If you installed Ubuntu 18.04 LTS, you may have seen BIND use them. In BIND, cookies are enabled by default, but they are not enforced by default. Also, the "dig" tool now supports cookies with the +cookie option. 

Here is a quick sample packet showing the cookie option in a DNS request. I haven't found any of the large DNS providers supporting the option yet, but I haven't tested them all.

To filter for these queries, you can use the Wireshark display filter "dns.opt.code == 10". There is no great BPF expresion for it, but "tcpdump -r dns -n 'udp[18:2]>0 && udp[10]&0x80=0'" will show all queries with DNS options (some may just be the EDNS option 0).

Packet capture: DNS packets with cookies as Ubuntu 18.04 boots. 

https://isc.sans.edu/diaryimages/dnscookies.pcap

2 - DNS over TLS

The second DNS innovation I see more and more is DNS over TLS. Unlike DNS cookies, DNS over TLS attempts to solve the privacy issue in DNS. It has found more followers after Cloudflare's "1.1.1.1" DNS service started to support it. I set it up in my PFSense firewall and am including some sample packets below.

The protocol is pretty "straightforward": Setup a TCP TLS connection, then send the DNS query across this TLS tunnel. The problem is that the TLS connection takes quite a bit of overhead to establish. But it can be reused for multiple queries to limit the overhead. In real life, I find the TLS connections to last only a very short time, so the overhead is substantial as far as the number of packets exchanged goes. Also, note that the TLS endpoint will be able to inspect all your queries. Cloudflare states that they will not use the data. 

The tricky part with DNS over TLS is that it renders many enterprise systems blind that take advantage of DNS traffic. Your best bet is to block DNS over TLS (it uses port 853/TCP) and to require users use an internal recursive DNS server. You can then do all the logging you need on that DNS server, and you may even use DNS over TLS from the recursive DNS server to an entity like Cloudflare if you trust them more then you do trust your ISP. Based on my observation, DNS over TLS also doesn't use the ALPN or the SNI options in TLS, which are used by more "regular" TLS connections like HTTPS.

Packet capture: DNS over TLS sample from PFSense to Cloudflare (anonymized IPs) https://isc.sans.edu/diaryimages/dnstlsanon.pcap

[1] https://tools.ietf.org/html/rfc7873 

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

I’m sure most of our readers (me included) have been telling users for years to always check the existence of the lock icon when entering sensitive data in a browser. This was always an easy way to check at least if data in transit is secure, provided that the user did not blindly click on Accept when a popup about an incorrect certificate appeared.

Now, we can probably debate till tomorrow about how good or bad this is – there are many, many attacks that can abuse such naïve users – Moxie’s sslstrip (https://moxie.org/software/sslstrip/) probably being the most commonly used: when hijacking HTTP traffic it will silently supply a favicon file that looks like the lock icon in order to fool users into thinking that everything is OK. And this is just one (cool) example.

Back in February, Google announced that sometime in July, with Chrome version 68, all HTTP sites will be marked as “not secure”. This is Google’s initiative to move everything to HTTPS, which is nice – since SSL/TLS certificates can be now obtained for free (see Let’s Encrypt https://letsencrypt.org/ but also be aware that also bad guys can get them for free), there is no more reason not to have your site accessible (only) via HTTPS. Indeed – if you haven’t done so already, make sure that you do this as priority.

If you want to test this feature, you can download Chrome Canary (version 69 currently - https://www.google.com/chrome/browser/canary.html) and simply open a non-HTTPS site and you will get this:

About 2 weeks ago, there was a new post about Chrome’s security indicators at https://blog.chromium.org/2018/05/evolving-chromes-security-indicators.html. It seems that Google will again change security indicators, this time with Chrome 70, which is supposed to be released in September.

With this version, HTTP sites will be additionally marked with a red warning sign when a user starts entering data in a form. I like this feature.
However, I’m not sure what to think about the second change they will probably introduce: Chrome will no longer mark HTTPS sites as Secure. Google’s reasoning behind this is that the default unmarked state will be secure, and that they will show non-secure warnings to users.

This is kind of odd from a user education perspective. There are two potential issues here:

• First, users might get confused about not seeing the lock icon and the Secure text any more. Not too big of an issue though – they are at least secure.
• This is what I don’t like though: once users get used to everything being “secure” by default, what happens if they go to a machine with an old version of Chrome (or a different browser)? I recently did a penetration test in an enterprise that had all users running Chrome 44 – the reason being that this was the last version with NPAPI (read: Java) support. While we can discuss how bad this is, it can certainly be problematic for a user that gets used to behavior of Chrome 70 and then ends up with Chrome 44.

Google is sure aggressive with updating Chrome, but can we make sure that everything is updated? I think we all know the answer.

As always, time will tell if this was a good decision or not. 

What do you think about these changes? Good or bad? Let us know!

--
Bojan
@bojanz
INFIGO IS

You probably heard the advice given earlier this week to reset your router due to some malware referred to as "VPNFilter" infecting a large number of routers. I do not want to second guess this advice, but instead, outline a couple of issues with "resetting" a router.

First of all: Pretty much all router malware (Mirai variants, TheMoon and various Linux Perl/bash scripts affecting routers) will not survive a simple power cycle of the router. However, the vulnerability that allowed access to the malware will. Secondly, some configuration changes may survive. In particular changes to DNS settings that are often done without actual malware, but by using CSRF vulnerabilities in the routers web-based admin interface.

My main problem with having thousands of users reset their routers to factory default settings is that they inadvertently may reset it to use a simple default password.

So here are some generic step-by-step instructions on what to do:

1. Write down any important configuration changes that you made to the router. For example any changes to the default IP addresses or DNS settings. Safe any VPN connection settings that you need. In addition, backup your configuration via the router's admin interface as a backup, but we do not expect to use it (you do not want to restore any compromised settings)
2. Download the latest and greatest firmware for your router. Even if you think you already run this particular version. Verify the firmware's integrity, which can be difficult. But maybe some vendors publish hashes. I do not think any vendor publishes PGP signatures. If you can not find a legit way to verify the integrity, then download it several times, using different networks, and different devices and compare hashes. Just for giggles: Call the manufacturers customer support number and ask for the hash. Maybe they will publish them if enough people complain. Most routers will do some integrity checking before applying the firmware but remember, we assume the router is compromised. Also, try to avoid the built-in "self-update" or "auto update" at this point.
3. Disconnect the router from the internet (unplug the network cable).
4. Reboot the router
5. Reset the router to the factory default settings. It is very important that you do this while the router is disconnected from the internet. It will likely reset the router to use some simple default password. Keep the router disconnected from the Internet.
6. Apply the latest firmware. Some routers may refuse to do that if they already have this version installed.
7. Configure your router using the notes you took in step 1. A couple of points to consider:
   1. set a strong admin password
   2. make sure the password is required if you access the router locally.
   3. Disable all remote admin interfaces (http, telnet, ssh...) unless you really really really need them (and if you do: consider using the router as a VPN endpoint if you can)
   4. if possible, change the administrator user name
   5. change the IP address scheme. For example, instead of 192.168.1.0/24, use 10.123.21.0/24 (pick random octets). It doesn't do much, but every bit helps.
   6. If you do not like your ISPs default DNS server, then pick some of the known good public once (Google, OpenDNS, Quad9, Cloudflare ...). Maybe mix two of them by using 8.8.8.8 and 9.9.9.9 ?
8. If you are really paranoid, then repeat the steps.
9. If you are not so paranoid (brave?): reconnect the router to the internet.
10. Post the firmware checksum to any support forums to help others verify their firmware (or learn that your firmware was compromised)

For a simple reset that will take care of > 99% of malware I see on routers:

1. Reboot the router
2. Verify that you use a strong password (even for access from your own network)
3. Disable remote admin features
4. Verify the DNS settings

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

When I need to do a quick binary analysis, Radare2 is my framework of choice. Radare2 consists of multiple tools that will assist you during analysis:

Radare2 runs on many platforms, supports local native and remote debugging, many architectures, advanced scripting (python, javascript, go, etc), patching, code (block) emulation and analysis. Each of the tools deserves an individual post, but I'll highlight a few features which I use often. 

Converting and evaluating expressions using rax2, converting test into its hex value.

$ rax2 -S test
74657374

Generating hashes for 38 algorithms at once, using rahash2.

$ rahash2 -a all ./traur.bin
./traur.bin: 0x00000000-0x000373ff md5: edccfe5ef48de6b0f3bbf53cc1012533
Upload.exe: 0x00000000-0x0007d8cf sha1: 6e24eb2ad12990b617b2287aedd57ba5686a85f6
Upload.exe: 0x00000000-0x0007d8cf sha256: eb9553ddb141d5281b49dac4b50a6f626902c4e14dc3532fafb737f85e667915
Upload.exe: 0x00000000-0x0007d8cf sha384: 911dc5810ecf6e8c5fc77f7b05f25ef74e4e276589675ad8c7b2c90d04af25321a4ef58f33798f976ba87b6194d6dc08
Upload.exe: 0x00000000-0x0007d8cf sha512: cc5d1907c897d46b77dda8fb44da6585147079402ad5d3f36a577f6a6e83aa5a2d02eef7a52e38319a4c56d29abe518f9b7a7ecfd8d2bcd70a376790177d97e6
Upload.exe: 0x00000000-0x0007d8cf md4: 387c58ff2ac57565706e9c1bd0543578
Upload.exe: 0x00000000-0x0007d8cf xor: 74
....

A quick assessment of a binary using rabin2:

$ rabin2 -I ./Upload.exe
arch     x86
binsz    514256
bintype  pe
bits     32
canary   false
class    PE32
cmp.csum 0x000894e8
compiled Fri Apr 16 07:47:33 2010
crypto   false
endian   little
havecode true
hdr.csum 0x00000000
linenum  false
lsyms    false
machine  i386
maxopsz  16
minopsz  1
nx       false
os       windows
overlay  true
pcalign  0
pic      false
relocs   true
signed   false
static   false
stripped true
subsys   Windows GUI
va       true
 

Extract string section information using rabin2:

$ rabin2 -z ./Upload.exe
000 0x00044c0a 0x004bb20a   5  12 (.rsrc) utf16le SOUND
001 0x00044c16 0x004bb216   6  14 (.rsrc) utf16le FINISH
002 0x00044c68 0x004bb268   4   5 (.rsrc) ascii }}}K

Extract imports using rabin2:

$ rabin2 -i ./Upload.exe
[Imports]
   1 0x004c37ac    NONE    FUNC KERNEL32.DLL_LoadLibraryA
   2 0x004c37b0    NONE    FUNC KERNEL32.DLL_GetProcAddress
   3 0x004c37b4    NONE    FUNC KERNEL32.DLL_VirtualProtect
   4 0x004c37b8    NONE    FUNC KERNEL32.DLL_VirtualAlloc
   5 0x004c37bc    NONE    FUNC KERNEL32.DLL_VirtualFree
...
 

Disassembly of entry0 using r2:

$ r2 ./Upload.exe
 -- Can you stand on your head?
[0x004ba3c0]> aaaa
[x] Analyze all flags starting with sym. and entry0 (aa)
[x] Analyze function calls (aac)
[x] Analyze len bytes of instructions for references (aar)
[x] Emulate code to find computed references (aae)
[x] Analyze consecutive function (aat)
[x] Constructing a function name for fcn.* and sym.func.* functions (aan)
[x] Type matching analysis for all functions (afta)
[0x004ba3c0]> pd
            ;-- eip:
/ (fcn) entry0 436
|   entry0 ();
|           0x004ba3c0      60             pushal
|           0x004ba3c1      be00604700     mov esi, 0x476000           ; section.UPX1
|           0x004ba3c6      8dbe00b0f8ff   lea edi, [esi - 0x75000]
|           0x004ba3cc      57             push edi
|       ,=< 0x004ba3cd      eb0b           jmp 0x4ba3da
        |   0x004ba3cf      90             nop
|       |   ; CODE XREF from 0x004ba3e1 (entry0)
 

Find the differences between two binaries using radiff2.

$ radiff2 -g main /bin/true /bin/false | xdot -

Cutter is the Qt based GUI of Radare2.

When you want to get started, it is being advised to use Radare2 from Docker or source. 

References
* http://radare.org/
* http://radare.today/
* https://github.com/radareorg/cutter
* https://radare.gitbooks.io/radare2book/
* https://radare.gitbooks.io/radare2book/content/radiff2/binary_diffing.html
* https://www.megabeets.net/a-journey-into-radare-2-part-1/

Can you imagine being pleased to learn that the pilot of your next flight had anything less than full visibility into the operation of the next airplane you board? Why would you settle for anything less for your Security Operations Center (SOC)? How long can your you stand for your SOC team to not know there is a problem in your environment? 

When building a SOC several years ago, I recall making screens ready in the event of an unexpected, yet necessary VIP tour. The intent of these is to impress those dignitaries by displaying cool things that are happening on your network. After you have finished impressing your VIPs, what actionable information should be displayed in your SOC to help them respond to threats in your environment?

Consider spending time this week ensuring your SOC wall is populated with meaningful screens that add value to your SOC by asking these questions.

• Which security controls are not sending data to your SOC?
• Would your SOC know when your most critical systems stopped sending their logs?
• What is the baseline of traffic volume in and out of your sensitive network zones?
• What is the health status of your security agents?

Share what you find valuable on your SOC wall!

Russell Eubanks

ISC Handler

@russelleubanks

SANS Instructor

Learn more at the upcoming SOC Summit!

Summary (MacOS, iOS, tvOS, watchOS)

MacOS / OS X

iOS

Apple Watch

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

I was speaking with a client about securing desktop operating systems, and his immediate comment to me was "of course, we could limit execution to only signed code" as one of his first planned steps to restrict malware execution.  By "signed" he of course refers to authenticode signing, where a software author can "sign" their code with a trusted certificate, just like we use certificates to websites.  You commonly see certificates on .exe, .cab, .dll, .ocx, .xpi, and .ps1 files - really anything that can be executed can be signed.

I hear the "restrict to signed code" position a lot, and it does sound like a great plan to start restricting access to trusted code!  But how would that work in today's Windows 10?  So I decided to do some preliminary poking around ....

First, let's collect all exe, dll and ps1 files in c:\windows.  You'd think that this would look something like (while running as administrator):
$allfilez = Get-ChildItem C:\Windows -Recurse -ErrorAction SilentlyContinue

However, when you look at the resulting file count just for .exe's , this looks a tad low.  I turns out that this combination of switches on GCI just plain skips entire trees in c:\windows, "because permissions"
 
$f = $allfilez | Where-Object { ($_.extension.tolower() -eq '.exe') }
$f.count
3226

So, after some time trying to figure this out (and not getting to a better place on this), I fell back to the "dir" command (which I KNOW will work without any back-chat).  We'll collect just the exe, dll and ps1 files:

$filez = iex "cmd /c dir c:\windows\*.exe,c:\windows\*.dll,c:\windows\*.ps1 /s/b/a-d"
Note that this just collects the filenames (with paths), where "get-childitem" would collect way more information about each file.

Now, let's grab the authenticode certificates for each of these:
$certz = $filez | get-authenticodeSignature

Looking at what fields are in a certificate:
$certz | gm

   TypeName: System.Management.Automation.Signature

Name                   MemberType Definition                                                                                  
----                   ---------- ----------                                                                                  
Equals                 Method     bool Equals(System.Object obj)                                                              
GetHashCode            Method     int GetHashCode()                                                                           
GetType                Method     type GetType()                                                                              
ToString               Method     string ToString()                                                                           
IsOSBinary             Property   bool IsOSBinary {get;}                                                                      
Path                   Property   string Path {get;}                                                                          
SignatureType          Property   System.Management.Automation.SignatureType SignatureType {get;}                             
SignerCertificate      Property   System.Security.Cryptography.X509Certificates.X509Certificate2 SignerCertificate {get;}     
Status                 Property   System.Management.Automation.SignatureStatus Status {get;}                                  
StatusMessage          Property   string StatusMessage {get;}                                                                 
TimeStamperCertificate Property   System.Security.Cryptography.X509Certificates.X509Certificate2 TimeStamperCertificate {get;}

Or at the expanded certificate metadata for one file:
$certz[12] | fl

SignerCertificate      : [Subject]
                           CN=Microsoft Windows, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
                         
                         [Issuer]
                           CN=Microsoft Windows Production PCA 2011, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
                         
                         [Serial Number]
                           33000001733031072665B8B9B3000000000173
                         
                         [Not Before]
                           8/11/2017 4:23:35 PM
                         
                         [Not After]
                           8/11/2018 4:23:35 PM
                         
                         [Thumbprint]
                           14590DC5C3AAF238FCFD7785B4B93F4071402C34
                         
TimeStamperCertificate : [Subject]
                           CN=Microsoft Time-Stamp Service, OU=nCipher DSE ESN:2137-37A0-4AAA, OU=AOC, O=Microsoft Corporation,
                         L=Redmond, S=Washington, C=US
                         
                         [Issuer]
                           CN=Microsoft Time-Stamp PCA 2010, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
                         
                         [Serial Number]
                           33000000AF358FFFD32245764B0000000000AF
                         
                         [Not Before]
                           9/7/2016 1:56:56 PM
                         
                         [Not After]
                           9/7/2018 1:56:56 PM
                         
                         [Thumbprint]
                           D8EAAC152D6F2EA52DA6FD020350E2801BFE4E23
                         
Status                 : Valid
StatusMessage          : Signature verified.
Path                   : C:\windows\write.exe
SignatureType          : Catalog
IsOSBinary             : True

Let's expand '$filez' to include our target files across all of c:, collect some 'information of interest' for each file, then poke at it some more with excel (because nothing spells patterns faster than a sorted list, a pivot table or few graphics) and sed (because my fingers still know sed faster than the equivalent powershell):

The final data collection script looks like this:
$filez = iex "cmd /c dir c:\*.exe,c:\*.dll,c:\*.ps1 /s/b/a-d"
$certz = $filez | get-authenticodeSignature
$certz | foreach {
 $cc = new-object -typename psobject -prop (@{'Path'=$_.Path; 'IsOSBinary'=$_.IsOSBinary; 'Status'=$_.Status;'SignatureType'=$_.SignatureType;'SignerIssuer'=$_.SignerCertificate.Issuer;'SignerThumbprint'=$_.SignerCertificate.Thumbprint;"TimeStampSig'=$_.TimeStamperCertificate.Issuer})
$certinfolist += $cc
 }
$certinfolist | Export-Csv \temp\certz-all-of-c.csv

I'll focus on files in the c:\windows directory, plus the files that are part of MS Office (I'm running Office 2013 Pro on this laptop)

There are 6794 Unsigned files, just in c:\windows.  Just with a bit of poking, 127 of those files are easily associated with MS Office (the uniq filename contains the strings office, word, excel, powerpoint or visio)

Certs with the word "Microsoft" in the CN (with the file counts) include:
     62 CN=Microsoft Code Signing PCA 2011, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
   3766 CN=Microsoft Code Signing PCA, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
     34 CN=Microsoft Code Signing PCA, OU=Copyright (c) 2000 Microsoft Corp., O=Microsoft Corporation, L=Redmond, S=Washington, C=US
      2 CN=Microsoft Development PCA 2014, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
      1 CN=Microsoft Digital Media Subordinate CA 2017 1
      1 CN=Microsoft Update Signing CA 2.1, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
    464 CN=Microsoft Windows Hardware Compatibility PCA, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
     24 CN=Microsoft Windows Phone Production PCA 2012, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
  20895 CN=Microsoft Windows Production PCA 2011, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
    331 CN=Microsoft Windows Third Party Component CA 2012, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
     10 CN=Microsoft Windows Third Party Component CA 2014, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
      7 CN=Microsoft Windows Verification Intermediate PCA, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
     46 CN=Microsoft Windows Verification PCA, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
     42 CN=MSIT Test CodeSign CA 6, DC=redmond, DC=corp, DC=microsoft, DC=com

Those all look pretty good, though the "Windows Phone" CA does stand out a bit.  hmmm - except for that last one - - did Microsoft really mean to include executables signed based on a test CA?  Looking at one of these files, we see that it's an internal-use-only CA, untrusted by production Windows:

Taking a closer look at this, we see that they're all part of "Microsoft Office Hub" - most of us would see this as an explicit app mainly on the phone platforms (which maybe also explains that Windows Phone CA), but it's part of the Windows version of Office also.

Let's pull files using that certificate by the signer thumbprint:
$certinfolist | Where-Object { $_.SignerThumbprint -eq "E657C209642F2585756FA612997DA548C82EBFEB" } |  select Path

Path
----
C:\Program Files\WindowsApps\Microsoft.MicrosoftOfficeHub_17.9328.1700.0_x64__8wekyb3d8bbwe\mso20imm.dll
C:\Program Files\WindowsApps\Microsoft.MicrosoftOfficeHub_17.9328.1700.0_x64__8wekyb3d8bbwe\mso30imm.dll
C:\Program Files\WindowsApps\Microsoft.MicrosoftOfficeHub_17.9328.1700.0_x64__8wekyb3d8bbwe\mso40uiimm.dll
C:\Program Files\WindowsApps\Microsoft.MicrosoftOfficeHub_17.9328.1700.0_x64__8wekyb3d8bbwe\mso50imm.dll
.....

Using the same method, we find that all of the files signed from the "Windows Phone" CA are located in: C:\Program Files\WindowsApps\Microsoft.VCLibs.140.00_14.0.24605.0_x86__8wekyb3d8bbwe\

There are a large number of files (6087) that have an authenticode status "UnknownError".  Of these 66 are actually signed with a CA listed.  Of the 66, 42 of those are in that OfficeHub directory.  So there's more than one problem with that component of Office.

When I looked a bit closer at unsigned files, I found file and directory names that included strings like:
ipsecuritybinaries
amd64_microsoft-windows-network-security
amd64_microsoft-windows-security-creds
amd64_microsoft-windows-security-tokenbroker
amd64_microsoft-windows-securitycenter-core
wow64_microsoft-windows-security-netlogon
wow64_microsoft-windows-security-aadauthhelper
(of course there are lots more)

Most of the strings in this list seem to cover authentication and authorization functions, these would seem important enough to sign, at least from my perspective?

Of the 132 files that have the string "hyperv" in the name or path, most (113) are unsigned.  This struck me as ironic as it gets, since that subsystem is integral to the Device Guard feature.  You know, Device Guard, the feature you use to restrict execution to only signed executable files?  More than a bit of irony there....

Want some more irony?  The Host Guardian service is used (in Microsoft's words) to "provide Attestation and Key Protection services that enable Hyper-V to run Shielded virtual machines."  In other words, HGS uses a virtual TPM module to support BitLocker encryption of VMs.  Neat, eh?  And, you guessed it, 15 "hostguard" executable files are unsigned.

Anyway, long story short - - yes, restricting execution to only signed executables is a terrific goal.  Can you do this right out of the box on Windows 10? - short answer is "expect some bumps in the road" - even Windows and MS Office are not consistently signed.

I'll take this a bit further in a future post, I'll try applying that restriction to my laptop and see how things go.  
If you've already gone down this path, by all means post any war stories to our comment section.
Or if you've gotten around that get-childitem issue in c:\windows, I think an answer or a better work-around there would be of interest to lots of people as well !

===============
Rob VandenBrink
Compugen

Here is another interesting file that I found while hunting. It is a malicious Windows batch file (.bat) which helps to exploit a freshly compromised system (or... to be used by a rogue user). I don't have a lot of information about the file origin, I found it on VT (SHA256: 1a611b3765073802fb9ff9587ed29b5d2637cf58adb65a337a8044692e1184f2)[1]. The script is very simple and relies on standard windows system tools and external utilities downloaded when neede.

Here is an overview of the available options. This should give you a good overview of the batch capabilities:

Exploitation
- Add User Account
- Show/hide User Account
- Enable Telent Service
- Enable Psexec Service
- Enable Remote Desktop Service
- Remote Login bypass backdoor (setch.exe or utilman.exe)
- EternalBlue
- MS1710-Psexec

Backdoor
- Meterpreter
- Cmd_shell
- Vnc_Powershell
- Winvnc
- JRrat
- Download/Execute ps1_script
- Download/Execute
- Post_exploits_script command shell
- Persis
- Ammyy Admin Trojan
- Radmin

Gather
- Mimikatz
- Mimikittenz
- Hashdump
- Wifi Password Dump
- Sherlock (Local privilege escalation vulnerabilities Scanner)
- Chrome Passwd Dump
- Firefox Passwd Dump
- Powerup (Vulns Founder)
- Get System info
- Get IPAddress
- Arp Scan
- Port Scanner
- Get Shares List
- Get Net View
- Netstat
- Get Process
- Scan MS17-010 Vulnerablity
- MS1710-Psexec_Scanner
- Port Forword

Privsec
- MS11-046
- Invoke-BypassUAC
- Invoke-WScriptBypassUAC
- Invoke-MS16032
- Invoke-MS16135
- Invoke-EventVwrBypass
- Invoke-EnvBypass
- Invoke-FodHelperBypass
- Invoke-SDCLTBypass
- Invoke-PsUACme
- UAC-TokenMagic
- EventVwrBypass (Win=7,8,8.1,10)

Tools
- Install Python27
- Install Ruby187

Proxy Tunnel
- Setup Proxy Tunnle
- Delete Proxy Tunnle
- Show All Proxy Tunnle

Update

Note the numerous typo errors (I left them as is). The script is a good example of demonstrating how easy it is to interact with a system only from a .bat file. Manipulation of users, registry keys, network, etc. The script has an update feature that fetches files from hxxp://remotebot.000webhostapp[.]com/powershellbot/. Many tools are also fetched from a GitHub repository[2] when needed.

[1] https://www.virustotal.com/intelligence/search/?query=1a611b3765073802fb9ff9587ed29b5d2637cf58adb65a337a8044692e1184f2
[2] https://github.com/cyberhunter00/

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

PCAP data can be really useful when you must investigate an incident but when the amount of PCAP files to analyse is counted in gigabytes, it may quickly become tricky to handle. Often, the first protocol to be analysed is HTTP because it remains a classic infection or communication vector used by malware. What if you could analyze HTTP connections like an Apache access log? This kind of log can be easily indexed/processed by many tools.

Haka[1] isn’t a new tool (the first version was released in 2013) but it remains below the radar for many people. Haka is defined as "an open source security-oriented language which allows to describe protocols and apply security policies on (live) captured traffic”. Based on the LUA[2] programming language, it is extremely powerful to extract information from network flows but also to alter them on the fly (playing a man-in-the-middle role). 

I had to analyze a lot of HTTP requests from big PCAP files and I decided to automate this boring task. I found on the Haka blog an article[3] that explained how to generate an Apache access log from a PCAP file. Unfortunately, it did not work anymore probably due to the evolution of the language. So, I jumped into the code to fix it (with some Google support of course).

Let’s start a docker container based on Ubuntu and install the latest Haka package:

$ docker run -it --name haka --hostname haka ubuntu
root@haka:~# apt-get update && apt-get upgrade
root@haka:~# apt-get install libpcap0.8 # Required by Haka!
root@haka:~# curl http://github.com/haka-security/haka/releases/download/v0.3.0/haka_0.3.0_amd64.deb
root@haka:~# dpkg -i haka_0.3.0_amd64.deb
root@haka:~# akapcap -h
Usage: hakapcap [options] <config> <pcapfile>
Options:
    -h,--help:              Display this information
    --version:              Display version information
    -d,--debug:             Display debug output
    -l,--loglevel <level>:  Set the log level
                              (debug, info, warning, error or fatal)
    -a,--alert-to <file>:   Redirect alerts to given file
    --debug-lua:            Activate lua debugging
    --dump-dissector-graph: Dump dissector internals (grammar and state machine) in file <name>.dot
    --no-pass-through, --pass-through:
                            Select pass-through mode (default: true)
    -o <output>:            Save result in a pcap file

Ready!

Basically, Haka works with hooks that are called when a condition is matched. In our example, we collect traffic from interesting ports:

http.install_tcp_rule(80)
http.install_tcp_rule(3128)
http.install_tcp_rule(8080)

Then we created a hook that will trigger HTTP response detected in the PCAP files:

hook = http.events.response,
    eval = function (http, response) {
        ... your code here ... 
    }

The hook extracts information from the HTTP response to build an Apache log entry:

<clientip> - - [<date>] “<request> HTTP/<version>” <response> <size> “<referer>” "<useragent>”

Let’s try it with a PCAP file generated on a network:

$ docker cp test.pcap haka:/tmp
$ docker exec -it haka bash
root@haka:~# hakapcap http-dissector.lua /tmp/test.pcap | grep “GET /“
192.168.254.222 - - [05/Jun/2018:18:34:13 +0000] "GET /connecttest.txt HTTP/1.1" 200 10 "-" "Microsoft NCSI”
192.168.254.215 - - [05/Jun/2018:18:34:14 +0000] "GET /session/...HTTP/1.1" 200 10 "-" "AppleCoreMedia/1.0.0.15E216 (iPad; U; CPU OS 11_3 like Mac OS X; en_us)"
192.168.254.215 - - [05/Jun/2018:18:34:19 +0000] "GET /session/...m3u8 HTTP/1.1" 200 10 "-" "AppleCoreMedia/1.0.0.15E216 (iPad; U; CPU OS 11_3 like Mac OS X; en_us)"
192.168.254.66 - - [05/Jun/2018:18:34:21 +0000] "GET / HTTP/1.1" 200 0 "-" "check_http/v1.4.16 (nagios-plugins 1.4.16)"

For now, the script returns a request size of ‘10’. It is hardcoded like usernames (default to "- -"). I’m still looking for a way to get the number of bytes per HTTP transaction. Also, you get only the client IP address and not the destination one. If you've improvement ideas, let me know!

My script compatible with Hack 0.3.0 is available on github.com[4].

[1] http://www.haka-security.org/
[2] https://www.lua.org/
[3] http://www.haka-security.org/blog/2014/03/18/transform-a-pcap-to-an-apache-log-file.html
[4] https://github.com/xme/toolbox/blob/master/haka_http_log.lua

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

Twitter is a great place to find interesting things, being shared by fellow security researchers. If you search for keywords like #opendir or hxxp://, you'll get lots of links with open directories containing shells, control panels, sources, phishing sites or malware. Secops is hard, even for people with malicious intents.

Because many of these links are taken down quickly I've created a small application, Lootbox. Lootbox will query twitter for certain keywords, extract the links and recursively download all files. I've been running this tool for a few weeks now and it downloaded some really interesting files:
 
* multi purpose phishing sites source code, against aol, google, office365 and yahoo
* all kind of different phishing source codes like onedrive, paypal, alibaba, blockchain.info
* DiamondFox webpanel source code
* many malicous executables, scripts, installers & documents (word, excel)

The source codes gives insights in modus operandi, actors, potential weaknesses and tactics being using within phishing sites and web panels.

If you want to collect your own loot, Lootbox is opensource and can be found at github.com/dutchcoders/lootbox. If you use docker, just start dockerize.sh to create the image, update run.sh with your configuration and start the container by executing run.sh. Don't forget to mount bind your destination folder to /loot.

References:
* https://github.com/dutchcoders/lootbox

Remco Verhoef (@remco_verhoef)
ISC Handler - Founder of DutchSec
PGP Key

Introduction

As cryptocurrencies have become more popular, criminals have expanded their operations into this area.  This is most obvious with the rise in cryptocurrency miners (coin miners) during the past year or so.  But In recent months, I've also seem more cryptocurrency-themed phishing emails than before.  I already provided one such example last month.  Today's diary provides another recent example.

The email

These phishing emails attempt to obtain login credentials for bitcoin or other cryptocurrency wallets.  This particular email spoofed blockchain.info.

Shown above:  Screenshot of the phishing email.

Email headers for this example follow:

Received: from cl-t040-461cl.privatedns.com ([70.38.4.91])
        by [removed] for [removed];
        Fri, 08 Jun 2018 11:43:54 +0000 (UTC)
Received: from nobody by cl-t040-461cl.privatedns.com with local (Exim 4.80)
    (envelope-from <nobody@cl-t040-461cl.privatedns.com>)
    id 1fRFYT-0004pr-Sy
    for [removed]; Fri, 08 Jun 2018 07:27:42 -0400
To: [removed]
Subject: Ether Payment Received
MIME-Version: 1.0
Content-Type: text/html; 
FROM: Blockchain  <crypto370@blockchain.info> 
Message-Id: <E1fRFYT-0004pr-Sy@cl-t040-461cl.privatedns.com>
Date: Fri, 08 Jun 2018 07:27:41 -0400

The fake login page was quickly taken off-line; however, I got some screenshots of it before it disappeared.

Shown above:  Screenshot of the fake login page when it was still active.

Shown above:  Nothing on the base page but a rude message.

This particular domain was blockpchain.info (notice the "p" between "block" and "chain").  It was originally registered on 2018-05-17, so it's been around approximately 3 weeks as I write this.

Final words

This was not a particularly clever phishing email.  Most people have some sort of phishing awareness and could have spotted the fake login page URL.  Furthermore, the fake Blockchain page had already been taken off-line by the time I attempted an in-depth investigation.

This is just one more example of how phishing emails remain a constant threat, and the criminals continue to adapting to our changing times.

---
Brad Duncan
brad [at] malware-traffic-analysis.net

Introduction

Earlier today, @killamjr informed about a file with this SHA256 hash:

• 4412d28a156716d16eb684ea4699a69f06f0346d99c23cd84065433252f02b99/

It's a JavaScript downloader, and it originated from a wave of malspam with zip attachments.  Upon further investigation, the malspam had an error in the final boundary marker, so the attachment would not properly display in an email client until I fixed it.

Today's diary looks at the malspam and associated infection traffic.

The malspam and attachments

Shown above:  Example of an email from this wave of malspam.

These emails had no message text, and they only contained an attached zip archive.  The zip archive contained a JavaScript (.js) file.  When extracted and double-clicked on a vulnerable Windows host, the .js file caused Windows Script Host to download and install malware.

My infected lab host also turned into a malspambot, and it sent similar messages out.  Below are 20 examples of the senders and subject lines I saw from my infected lab host:

• From: Aida Davis <Aida33@2447.com> - Subject: Is she hot? Take a look at her
• From: Aida Perez <Aida78@5781.com> - Subject: Keep this photo private please
• From: Beulah Johnson <Beulah41@3710.com> - Subject: Rate my new photo please
• From: Billie Roberts <Billie37@6139.com> - Subject: Someone told me it's you???
• From: Blaine Howard <Blaine47@6150.com> - Subject: Someone takes photos from you
• From: Blair Nelson <Blair23@6150.com> - Subject: Your best photo
• From: Bob Brooks <Bob99@5457.com> - Subject: Please rate my picture
• From: Bobbi Bailey <Bobbi03@6591.com> - Subject: Damn I can't get her out my head
• From: Bradford Lewis <Bradford43@6591.com> - Subject: Trumps private photo leaked!
• From: Deanne Thomas <Deanne27@5457.com> - Subject: Is this you?
• From: Debbie Mitchell <Debbie54@8298.com> - Subject: Time for a change
• From: Debora Peterson <Debora09@6591.com> - Subject: Why you took that picture?!
• From: Deena Cook <Deena39@5356.com> - Subject: Unbelivable photo
• From: Delia Wright <Delia16@8298.com> - Subject: Your opinion needed
• From: Goldie Gray <Goldie39@2664.com> - Subject: Photo of my new girlfriend
• From: Gordon Rogers <Gordon67@6943.com> - Subject: Took photo of you
• From: Tania Roberts <Tania15@4347.com> - Subject: I simply love this photo of you!
• From: Tanner Thomas <Tanner95@3432.com> - Subject: LOL seen this photo?
• From: Tara Wood <Tara09@9774.com> - Subject: My love for you
• From: Teresa Cook <Teresa57@5781.com> - Subject: My picture

Each message from my malspambot had the same zip attachment that contained the same .js file.  It had a different file hash than the one I originally infected my lab host with, but it was basically the same file.

Shown above:  Attachment from the malspam.

Traffic from my infected lab host

After double-clicking the .js file, I saw several HTTP requests for malware.  One of the HTTP requests returned a .js file used in attachments from malspam sent by my newly-infected Windows host.  Another HTTP request returned a mailing list of recipients to send the malspam.

In addition to SMTP traffic on TCP port 25, I also saw post-infection traffic for a Monero coin miner (XMRig).

I found an error in the final boundary line at the end of all emails sent by my infected lab host.  That line had an extra dash (3 instead of 2 dashes) to close out the message.  This made the attachment unreadable to any normal email client.  If the message made it to its intended recipient, the recipient would probably see a blank message.

Shown above:  HTTP requests from the infection traffic as seen in Wireshark.

Shown above:  Post-infection traffic for a Monero coin miner.

Shown above:  Following one of the TCP streams for the coin miner traffic.

Shown above:  Filtering on SMTP traffic to find the spoofed sending addresses.

Shown above:  Filtering on SMTP traffic to find spoofed hosts used when contacting the recipient's mail server.

Shown above:  Filtering on smtp contains Subject (case sensitive) shows several emails that were not outright rejected.

Shown above:  Following the TCP stream for one of the malspam messages.

Shown above:  Near the bottom of the TCP stream, you see the error in the closing boundary tag.

Forensics on an infected Windows host

I used a Windows 7 host for the infection traffic.  I was unsuccessful when I tried infecting a Windows 10 host.  My infected Windows 7 host had registry entries to keep the malware persistent.  One of the malware binaries was also saved to a USB drive that happened to be plugged into the infected lab host.

Shown above:  Registry entries on my infected Windows 7 host.

Shown above:  Contents of a USB thumb drive taken from my infected Windows 7 host.

Indicators

The following are indicators found during my investigation:

SHA256 hash: 4412d28a156716d16eb684ea4699a69f06f0346d99c23cd84065433252f02b99

• File size: 26,219 bytes
• File description: Original .js file I was notified about

SHA256 hash: 2e5674a738e1409d32a559d4bddcff3243fdf68b4fc4482b29dff38dfa6e3dc1

• File size: 26,591 bytes
• File location: hxxp://92.63.197.60/d.js
• File description: Malicious JavaScript from malspam sent by my malspambot lab host

SHA256 hash: 3c0fd1377e620229daa0175758112f712f54474db2135c695761afffef6510ea

• File size: 26,733 bytes
• File name: 20186425_642590.jpg.zip
• File description: The actual zip attachment in malspam sent by my malspambot lab host

SHA256 hash: 1be4cbc9f9b6eea7804e08df92cff7453aa72f0bb862b0fb8f118c5e3ffdaad6

• File size: 168,960 bytes
• File location: hxxp://92.63.197.60/c.exe
• File description: malware (unspecified)

SHA256 hash: 73f0880358701566ed1792014b639c02f357da42981344a6ad644aae494d3e36

• File size: 808,960 bytes
• File location: hxxp://92.63.197.60/m.exe
• File description: Cryptocurrency miner (Monero)

SHA256 hash: fdb9eacca47469ddb1d91694171fb1df8f891fb12a6c6a8184a5def539784cc6

• File size: 172,032 bytes
• File location: hxxp://92.63.197.60/o.exe
• File description: malware (unspecified)

SHA256 hash: 1437e8518c62383d57fd38debdad1a76813c229061d3aa060c2f3151eac41027

• File size: 219,648 bytes
• File location: hxxp://92.63.197.60/t.exe
• File description: malware (unspecified)

Network traffic from the infection:

• 92.63.197.60 over TCP port 80 - 92.63.197.60 - follow-up malware and other traffic
• 198.105.244.228 over TCP port 80 - booomaahuuoooapl.ru - attempts at same downloads as seen with 92.63.197.60
• 107.191.99.227 over TCP port 3333 - monerohash.com - XMRig traffic (Monero coin miner)
• various IP addresses over TCP port 25 - SMTP traffic from my newly-infected malspambot host

Final words

As usual, properly-administered and up-to-date Windows hosts are not likely to get infected.  The boundary errors in these malspam messages probably ensured none of the intended recipients even saw the malware.  Furthermore, system administrators and the technically inclined can also implement best practices like Software Restriction Policies (SRP) or AppLocker to prevent these types of infections.

Of note, email headers from this malspam are similar to what I've seen with the "Zero Gand" campaign in previous months.  Today's wave of malspam probably used the same distribution channel as that earlier campaign.

Pcap and malware samples for today's diary can be found here.

---
Brad Duncan
brad [at] malware-traffic-analysis.net