Posts Tagged business

How Safe Are Your Docker Images?, (Thu, Apr 22nd)

Today, I don’t know any organization that is using Docker today. For only test and development only or to full production systems, containers are deployed everywhere! In the same way, most popular tools today have a “dockerized” version ready to use, sometimes maintained by the developers themselves, sometimes maintained by third parties. An example is the Docker container that I created with all Didier’s tools[1]. Today, we are also facing a new threat: supply chain attacks (think about Solarwinds or, more recently, CodeCov[2]). Let’s mix the attraction for container technologies and this threat, we realize that  Docker images are a great way to compromise an organization! 

When we deploy Docker images, we have to take care of two things:

  • Vulnerabilities present in the software installed in the image.
  • Potential malicious changes (implementation of a backdoor, extra SSH keys, exfiltration of data, etc…)

Many Docker images have already been detected as malicious[3] and are more difficult to detect but how to address “common” vulnerabilities? When you are implementing a vulnerability scanning process in your organization (note that I say “process” and not “tool”!), there are components that are difficult to scan like virtual machines in suspended mode and… Docker images!

Here is an interesting tool that you can add to your arsenal to quickly scan Docker images for vulnerabilities: grype[4]. Written in Go, the tool is very easy to deploy and use:

[email protected]:/# docker images|grep ssl
drwetter/       latest     699c2c42986f   7 weeks ago     48.5MB
jumanjiman/ssllabs-scan   latest     2a46bf22e388   10 months ago   5.66MB
[email protected]:/# grype docker:drwetter/
 - Vulnerability DB        [no update available]
 - Loaded image
 - Parsed image
 - Cataloged packages      [36 packages]
 - Scanned image           [2 vulnerabilities]
openssl  1.1.1j-r0            CVE-2021-3450  High
openssl  1.1.1j-r0            CVE-2021-3449  Medium

grype scans the contents of the Docker image to find know vulnerabilities at the operating system level (Alpine, Busybox, Ubuntu, …) but also language-specific issues (Ruby, Java, Python, …). Personally, I like the JSON output (--output=json) to process the results with other tools or index them.

My advice is to scan all your new Docker images, especially the ones that you downloaded from 3rd party websites. 

And you? How do you scan/audit your Docker images? Please share your tools/processes in the comments.


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

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

A Case for Lockdown and Isolation (and not the Covid kind), (Wed, Apr 21st)

A reader wrote in expressing concerns over a vendor software management platform that had 3rd party module vulnerabilities [1]. Reasonable risk assessment if you ask me. This comes along with the two “One Liners” we posted yesterday [2] [3]. This sounds like a case for isolation and or lockdown. Considering 2021’s climate, let’s be clear here, Digital not Physical :).

The problem space is the attack surface. Good thing, we’ve known about this for years. Bad thing, human behavior has not changed (that we are aware of) for a very long time [4]. Given that we have something we can affect and something that is HARD to change? How do we approach the risk of vulnerabilities in our management plane? Lets also add into this problem space the idea that we cannot isolate everything (again, only talking digital here). 

Now that I’ve said something that most of us have heard over and over and over and …….. over? What can we do?

The Model: Zero Trust (micro-segmentation, take your pick, but you get the idea)
note: Not all Zero Trust interpretations are equal, I use John’s (shameless name drop) [5] [6]

The Use-Case: Critical Asset that is Vulnerable
In this example we will use a device that is still running ‘telnet’ and can’t be patched nor upgraded. And before you ask? YES, in 2021, this still happens! The device type really does not matter, could be an old accounting mainframe that still is in production, or a critical building management system, and or legacy networking hardware that ‘just cannot be pulled yet.’
Risk analysis can help in replacing this asset, but that is a different road and a layer 8+ problem [7]. 

A Solution:
Put simply? STICK something in front of it. Not all something’s are equal, so let’s get into the details of one way (yes, I’ve done this) to solve it. It is possible, using off the shelf technology, to put an encrypted layer with Multi-Factor Authentication (MFA) and allowing access by user/group. 

– –  

The clientless VPN solutions would be configured to use the organization’s regular IDaM infrastructure with full group / user restrictions. This would point to an HTML5 proxy that provides a TLS interface to the telnet client. As long as the VPN / Firewall solution supports it, SAML becomes possible, along with MFA [8].

This is not easy, but also not impossible and remember, just because MFA is being “picked on” (probably with good reason) doesn’t stop us from using it [9]. A wise Groot once said ‘It’s better than 11%’…

Those highly vulnerable critical assets can be protected, and this risk can be mitigated. The best solution would be to replace these devices, however, we know that is not always feasible. Find your most fragile devices and architect a Zero Trust posture around THOSE assets. The question that John Kindervag has told me he gets the most is “Where do I start?” and your most fragile assets seem like a good place as any. 

“Perfection is a road, not a destination” Chiun, Remo Williams

If this topic is interesting, please comment and I can dive deeper (what vendors I used, how I deployed it, results (good btw)…

Let us know in the comments.

[2] SonicWall releases Security Notice: Email Security Zero-Day Vulnerabilities
[3] PluseSecure Out of Cycle Advisory:


(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Hunting phishing websites with favicon hashes, (Mon, Apr 19th)

HTTP favicons are often used by bug bounty hunters and red teamers to discover vulnerable services in a target AS or IP range. It makes sense – since different tools (and sometimes even different versions of the same tool) use different favicons[1] and services such as Shodan calculate MurmurHash values[2] for all favicons they discover and let us search through them, it can be quite easy to find specific services and devices this way.

But while the use of favicon hashes is common in the “red” community, significant number of blue teamers don’t use them at all. Which is unfortunate, given that – among their other uses – they can provide us with a simple way of identifying IPs hosting phishing kits. After all, this was the reason why searches using HTTP favicon hashes have been introduced into Shodan in the first place[3].

As an example, we will show how to detect IPs hosting phishing pages by looking for sites that try to pass themselves of as login portals for O365 and other Microsoft services, however the same principle would work for any other service as well. One could therefore for example calculate hashes of unique favicons used by systems specific to a company one is trying to protect (e.g. favicon from a company website) and use periodical lookups of these on Shodan and other services in order to implement a – admittedly fairly simple – phishing detection/brand protection mechanism…

So how would one look for fake Microsoft login portals? First, we need to calculate a MurmurHash value of a favicon that we expect might be reused on a phishing website to make it look more trustworthy. Looking at official Microsoft websites, it seems that they use the favicon located at

Its hash can be easily calculated using Python code that may be found on GitHub[4]:

import requests,mmh3,base64
response = requests.get('')
favicon = base64.encodebytes(response.content)
hash = mmh3.hash(favicon)

If we run this script, we will get the hash -2057558656.

Now that we have a hash to look for, we can query Shodan to get the list of all IP addresses where it found a favicon with the same one. We may use the filter http.favicon.hash to do so.

As we can see, the number of results is quite high. This is hardly surprising though, given that they conain all servers – malicious as well as legitimate – where the favicon is used. In order to discover only the suspicious ones, we would need to further refine the search. One would do this differently for one’s own favicons, but in order to search for suspicious Microsoft login portals, we could extend our search to look only for IPs with web pages looking like log in portals (http.html:”Sign in”) and that are not hosted on Microsoft infrastructure (-org:”Microsoft Corporation” -org:”Microsoft Azure”) but are running an Apache web server (product:”Apache httpd”). Taken together, our search might look like this:

http.favicon.hash:-2057558656 -org:"Microsoft Corporation" -org:"Microsoft Azure" product:"Apache httpd" http.html:"Sign in"

If we ran this updated search, the number of results would be significantly lower.

Not all IPs identified in this way would necessarily turn out to host a phishing website, but most of them almost certainly would (or would at least turn out to have done so recently). In any case, all of them would unquestionably be worth investigating, and it probably wouldn’t take too long to discover something interesting. In our search, for example, the following web site was hosted on the very first IP that Shodan returned.

As we’ve mentioned, the same approach can be used to identify phishing web sites using any other favicon as well.

Given how easy it is to implement automatic periodic lookups (for example against Shodan API) for a list of specific hashes (e.g. the ones that are used on our company log in pages/in our products), favicons can provide a cheap and simple way to detect phishing sites targeting either one’s company or its customers. Even if one decided not to automate them, favicon hash lookups can still provide us with additional information useful, for example, for “long tail” threat hunting or enrichment of other data.

In any case, if you are on the “blue” side and don’t use favicon hashes in any way, consider whether they might not provide you with at least some value.


Jan Kopriva
Alef Nula

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Decoding Cobalt Strike Traffic, (Sun, Apr 18th)

In diary entry “Example of Cleartext Cobalt Strike Traffic (Thanks Brad)” I share a capture file I found with unencrypted Cobalt Strike traffic. The traffic is unencrypted since the malicious actors used a trial version of Cobalt Strike.

This weekend I carried on with the analysis of that traffic, you can see my findings in this video and read the diary entry below.

Reader binarysheperds posted a comment to point out packet 8241, that looks like containing output of a UAC bypass command:

Yesterday I took a closer look at the binary protocol, started to see some patterns (like an epoch value), and then I found Python code on Github that handles Cobalt Strike’s encrypted traffic.

This allowed me to write a decoding tool: It takes the pcap file as argument and relies on Python module pyshark to parse the pcap file. I then extract the traffic and parse it. The parsing code is still incomplete because of inciomplete understanding of the protocol.

Here is the output of my tool for the UAC bypass:

First, with an HTTP response, commands are delivered to the beacon: download a DLL and do a UAC bypass.

Second, the output (text) is send to the C2 with an HTTP POST request.

This DLL is a reflective loader to perform a UAC bypass:

I also found portscanning activity. You can watch the complete analysis in this video:

And here are 2 videos by Cobalt Strike developer Raphael Mudge on portscanning and UAC bypass.

Didier Stevens
Senior handler
Microsoft MVP

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →
Page 1 of 399 12345...»