Almost 4 years ago, I wrote a python version of mac-robber. I use it fairly regularly at $dayjob. This past week, one of my co-workers was using it, but realized that it hashes large files a little too slowly. He decided to use mac-robber.py to collect the MAC times and do the hashing separately so he could limit the hashes to to files under a certain size. That sounded reasonable, so I've added a switch (-s or --size). If hashing is turned on the new switch will limit the hashing to files under the given size.

To see it in action, see the next figure.

I hope others find this new feature useful. If anyone has more suggestions for new features, you can let me know via comments here, e-mail, or our contact form. The tool can be found at the same place as before: 

https://github.com/att/docker-forensics/blob/master/mac-robber.py

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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Over the past 60 days, I have observed scanning activity to discover FortiGate SSL VPN unpatched services. Fortinet has fixed several critical vulnerabilities in SSL VPN and web firewall this year from Remote Code Execution (RCE) to SQL Injection, Denial of Service (DoS) which impact the FortiProxy SSL VPN and FortiWeb Web Application Firewall (WAF) products [1][2]. Two weeks ago, US-CERT [4] released an alert re-iterating that APT actors are looking for Fortinet vulnerabilities to gain access to networks. Additional information to look for signs of this activity available here.

Fortinet Scanning Activity

Here is a sample of what can be seen in the logs:

20210611-053716: 192.168.25.9:8443-203.159.80.226:58521 data
GET /remote/fgt_lang?lang=/../../../..//////////dev/cmdb/sslvpn_websession
HTTP/1.1
Host: 70.XX.XXX.XXX:8443
Connection: close
Accept-Encoding: gzip, deflate
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0rnAccept-Language: en-US,en;q=0.5
Upgrade-Insecure-Requests: 1

[1] https://www.fortiguard.com/psirt?date=01-2021
[2] https://www.fortinet.com/blog/psirt-blogs/patch-vulnerability-management
[3] https://us-cert.cisa.gov/ncas/current-activity/2021/04/02/fbi-cisa-joint-advisory-exploitation-fortinet-fortios
[4] https://us-cert.cisa.gov/ncas/current-activity/2021/05/28/fbi-update-exploitation-fortinet-fortios-vulnerabilities
[5] https://www.ic3.gov/Media/News/2021/210527.pdf

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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Devices and applications used to provide remote access are juicy targets. I've already been involved in many ransomware cases and most of the time, the open door was an unpatched VPN device/remote access solution or weak credentials. A good example, the recent attack against the Colonial Pipeline that started with a legacy VPN profile[1].

A group of attackers is targeting Sonicwall devices through the vulnerability described in %%cve:2019-7481%%. Yes, a vulnerability from 2019! It affects Sonicwall SRA ("Secure Remote Access") 4600 devices running firmware versions 8.x and 9.x. Crowdstrike published a nice blog post about this vulnerability[2].

If you run a Sonicwall device affected by this vulnerability, please review your current firmware and patch!

[1] https://www.hsgac.senate.gov/imo/media/doc/Testimony-Blount-2021-06-08.pdf
[2] https://www.crowdstrike.com/blog/how-ecrime-groups-leverage-sonicwall-vulnerability-cve-2019-7481/

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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

With Python getting more and more popular, especially on Microsoft Operating systems, it's common to find malicious Python scripts today. I already covered some of them in previous diaries[1][2]. I like this language because it is very powerful: You can automate boring tasks in a few lines. It can be used for offensive as well as defensive purposes, and… it has a lot of 3rd party "modules" or libraries that extend its capabilities. For example, if you would like to use Python for forensics purposes, you can easily access the registry and extract data:

This snippet of code starts with an import line. First, I need to load a specific module (in this case winreg) that will add to Python all the required code to manipulate the OS registry hives.

Let's switch back to the "dark side". When an attacker needs to write a piece of code to perform specific tasks, he will search for existing modules and not reinvent the wheel. To search for Python modules, the best place is to visit pypi.org[3]. Let's take another example: injection of code. Python is able to use all the Windows API calls with the help of the ctypes module:

In this example, I'm using the ctypes modules to call the Windows API VirtualAlloc() and allocated 1KB of memory with the flag "0x04" (which means that the memory will be allowed to contain executable code).

ctypes is not a common module used in simple scripts to automate tasks like System Administrators could write. It could be categorized as "suspicious". Let's have another example. I found this malicious script that implements a keylogger. It uses another not common Python module:

The suspicious module is pyHook which "provides callbacks for global mouse and keyboard events in Windows" as the documentation says.

Want more? Let' use now wave and sounddevice to use the host microphone and record some conversations…

Other interesting modules?  Use pyscreenshot to take screenshots or pynput to build another type of keylogger.

The question is now, from a defender's perspective, how can we detect suspicious Python modules?

If you have access to the host, you can always use the "pip" command (the utility to manage modules):

pip will list the modules that have been installed "manually" (could be done by an attacker). To get a full list of modules, you can use the help() command in the Python interpreter:

As you can see, it's interesting to spot malicious Python code just by having a look at the imported modules! If you would like to hunt, you can create a YARA rule to search for interesting modules inside text files…

[1] https://isc.sans.edu/forums/diary/Python+and+Risky+Windows+API+Calls/26530
[2] https://isc.sans.edu/forums/diary/From+Python+to+Net/27366
[3] https://pypi.org

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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

In my last diary, we went over the impact of different Base encodings on the ability of anti-malware tools to detect malicious code[1]. Since results of our tests showed (among other things) that AV tools in general still struggle significantly more with detecting 64-bit malicious code then 32-bit malicious code, I thought it might be interesting to discuss another factor that might impact the ability of AVs to detect malware – specifically the choice of a compiler.

Since compilers can differ significantly in terms of their internal functionality and the use of various optimization techniques, it makes sense why they generate slightly (or significantly) different output from the same initial code. But do these differences have any impact in terms of hindering the ability of anti-malware to correctly identify malicious code? To try and answer this question, I devised a simple test.

I would start with 3 C++ programs:

• one that would write a benign text file do disk (i.e. a “control” program that would allow us to identify the number of false-positive detections),
• one that would drop the EICAR test file[2] on disk and
• a program that would execute a staged Meterpreter reverse-tcp payload.

I would then compile each of these programs with 2 different compilers (TDM-GCC and Microsoft Visual C++) into both 32 and 64-bit binaries and use VirusTotal to find out whether would be any significant differences in their detections.

I used the following very simple code for both the “control” program and the EICAR dropper:

#include <iostream>
#include <fstream>
using namespace std;

int main() {
  ofstream OutFile([filename]);
  OutFile << [file contents];
  OutFile.close();
}

In the benign file, I’ve used the string “This is a benign string” as the contents. For the malicious program that would execute Meterpreter, I’ve used the same code as last time.

After all the binaries were compiled, it turned out that their VirusTotal detection scores did indeed differ – quite significantly in the case of our only “real” malicious file.

Besides a significant difference in the number of detections of the same 32-bit and 64-bit code, the chart seems to show that overall, the use Microsoft’s compiler might have negative impact on the ability of anti-malware tools to detect malicious code, at least when compared with TDM-GCC… But this isn’t actually true.

Even a small change to the initial code might result in significant changes to the resulting binary (and the ability of AVs to detect it) and these changes would be different for every compiler.

This can be seen quite clearly in the following chart, which shows detection scores of the original Meterpreter binaries and the scores for binaries that were compiled from the same source code, in which the only change was an increase (by about 1k) of the amount of memory allocated for the Meterpreter shellcode (which would not affect the basic function of the binary in this instance).

As we can see, the use of Visual C++ compiler over TDM-GCC does not always result in lower detection scores, as it might have appeared from the first chart. What is obvious from both charts, however, is that the choice of a compiler truly does make an impact when it comes to the ability of AVs to detect malicious code.

Even so, this is far from the whole story, since the choice of a compiler is not the only thing that affects the contents of a resulting binary. Use of different optimization settings might go a long way to change the result as well and the same might be true for use of different linkers. Given how simple our test code was, the differences caused by the use of different linkers should not be too significant here, but in the case of more complex code, it could certainly be noticeable… and there are many other factors as well. That will, however, be a topic for another time.

[1] https://isc.sans.edu/forums/diary/All+your+Base+arenearly+equal+when+it+comes+to+AV+evasion+but+64bit+executables+are+not/27466/
[2] https://www.eicar.org/?page_id=3950

———–
Jan Kopriva
@jk0pr
Alef Nula

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Eventually, we all have an accident or get hacked. And when we do, backups are often the only way to recover. Backups are cheap and easy; make sure you are backing up all of your personal information at home (such as family photos) on a regular basis.

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

The highlight this time, of course, goes to the 6 zero-days: an elevation of privileges vulnerability on Microsoft DWM Core Library (CVE-2021-33739) – the only previously disclosed, an elevation of privilege vulnerability on Windows NTFS (CVE-2021-31956), an information disclosure vulnerability on Windows Kernel (CVE-2021-31955), an elevation of privilege vulnerability on Microsoft Enhanced Cryptographic Provider (CVE-2021-31201 and CVE-2021-31199) and, more importaltly, a remote code execution vulnerability affecting Windows MSHTML Platform (CVE-2021-33742).

Apart from the zero-days, there is an important security feature bypass Vulnerability Kerberos AppContainer (CVE-2021-31962). According to the advisory, in an enterprise environment this vulnerability might allow an attacker to bypass Kerberos authentication, to authenticate to an arbitrary service principal name. This vulnerability was associated to the highest CVSS this month: 9.4.

There is also a remote code execution affecing Windows Defender (CVE-2021-31985). According to the advisory, this vulnerability is more likely to be exploited, requires no authentication and the attack complexity is low.

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

—
Renato Marinho
Morphus Labs| LinkedIn|Twitter

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.