Blog

Archive for February, 2020

Hazelcast IMDG Discover Scan, (Sat, Feb 29th)

Today my honeypot has been capturing scans for the Hazelcast REST API. I checked my logs for the past 2 years and these only started today. The last vulnerability published for Hazelcast was CVE-2018-10654 and related to “There is a Hazelcast Library Java Deserialization Vulnerability in Citrix XenMobile Server 10.8 before RP2 and 10.7 before RP3.”[3]

There was some discussion regarding this issue at the end of Sep 2019 that got fixed at the end of Nov 2019 [5] where /hazelcast/rest/cluster HTTP endpoint returns HTTP 500 status. If you are seeing similar discovery scans and when they started, we would like to hear from you.

[1] https://docs.hazelcast.org/docs/management-center/3.9.2/manual/html/Clustered_REST_via_Management_Center.html
[2] https://vulmon.com/searchpage?q=hazelcast
[3] https://vulmon.com/vulnerabilitydetails?qid=CVE-2018-10654&scoretype=cvssv2
[4] https://github.com/hazelcast/hazelcast/issues/15635
[5] https://github.com/hazelcast/hazelcast/pull/16150
[6] https://isc.sans.edu/forums/diary/Citrix+ADC+Exploits+Overview+of+Observed+Payloads/25704

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

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

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Show me Your Clipboard Data!, (Fri, Feb 28th)

Yesterday I’ve read an article[1] about the clipboard on iPhones and how it can disclose sensitive information about the device owner. At the end of the article, the author gave a reference to an iPhone app[2] that discloses the metadata of pictures copied to the clipboard (like the GPS coordinates).

This is true, our clipboards may contain sensitive information like… passwords, private URLs, confidential text, and man more! About passwords, many password managers use the clipboard to make the user’s life easier. You just need to paste data exported by the password manager in the password field. Some of them implement a technique to restore the content of the clipboard with previous data. This is very convenient but it is NOT a security feature. Once data has been copied into the clipboard, it can be considered as “lost” if other applications are monitoring its content.

Note that some Password managers are more “mature” and offer a browser add-on that communicates directly with the main application and bypass the clipboard.

This gave me the idea: let’s write a few lines of PowerShell to monitor the content of the clipboard on a Windows 10 host. Here is the very simple code based on Get-Clipboard[3]:

$data = Get-Clipboard;
while($true)
{
    $updated = $false;
    $olddata = $data;
    $data = Get-Clipboard;
    if ($olddata -ne $data) {
        $updated = $true;
    }

    if ($updated) {
        Write-Host “New clippboard data detected: $data”
    }
    Start-Sleep -Milliseconds 100;
} 

It just grabs the content of the clipboard every 0.1 seconds and, if changed, displays the content (note that I’m just handling basic text, binary content is ignored).

Let’s run it and continue to work as usual. We see the history of all data copied into the clipboard:

New clippboard data detected: clipboard
New clippboard data detected: 563068
New clippboard data detected: 177888
New clippboard data detected: https://blog.rootshell.be/2020/02/27/sans-isc-offensive-tools-are-for-blue-teams-too/
New clippboard data detected: lwi0b!nui8hAMTlG
New clippboard data detected: 'list' object has no attribute 'keys'
New clippboard data detected: https://www.youtube.com

You can guess that we have some 2FA tokens, passwords, error messages (that are usually pasted to Google, etc).

My Windows host is virtualised and, for more ease of use, the VM is not isolated:

This means that I can copy/paste between the host and the VM. Let’s test from a shell on the host:

xavier : ~ $ whoami|pbcopy
xavier : ~ $ pbpaste
uid=501(xavier) gid=20(staff) groups=20(staff),12(everyone),61(localaccounts),79(_appserverusr),80(admin),81(_appserveradm),98(_lpadmin),399(com.apple.access_ssh),701(com.apple.sharepoint.group.1),33(_appstore),100(_lpoperator),204(_developer),250(_analyticsusers),395(com.apple.access_ftp),398(com.apple.access_screensharing),400(com.apple.access_remote_ae)

(pbcopy/pbpaste are MacOS commands to read/write the clipboard, very convenient 🙂

And immediately, on my Windows VM, my scripts reacts:

New clippboard data detected: uid=501(xavier) gid=20(staff) groups=20(staff),12(everyone),61(localaccounts),79(_appserverusr),80(admin),81(_appserveradm),98(_lpadmin),399(com.apple.access_ssh),701(com.apple.sharepoint.group.1),33(_appstore),100(_lpoperator),204(_developer),250(_analyticsusers),395(com.apple.access_ftp),398(com.apple.access_screensharing),400(com.apple.access_remote_ae)  

Even more interesting: I’m an Apple fan and I’ve the complete range of Apple devices, all of them are perfectly integrated…. The clipboard too! (Via iCloud). Let’s test again:

And, once data copied into the iPhone clipboard, I see in the VM host:

New clipboard data detected: Test from iPhone

By design, the clipboard is available to all processes running on the system. This mean also all potential malicious applications and malware. They don’t require any special privileges to access the clipboard. Keep this in mind!

[1] https://www.securitynewspaper.com/2020/02/26/are-you-an-iphone-user-dont-copy-paste-your-card-number-or-passwords-other-apps-can-steal-your-data-from-the-clipboard/
[2] https://www.youtube.com/watch?v=tegfZNv8SBc
[3] https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.management/get-clipboard?view=powershell-7

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

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

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Offensive Tools Are For Blue Teams Too, (Thu, Feb 27th)

Many offensive tools can be very useful for defenders too. Indeed, if they can help to gather more visibility about the environment that must be protected, why not use them? More information you get, more you can be proactive and visibility is key. A good example is the combination of a certificate transparency list[1] with a domain monitoring tool like Dnstwist[2], you could spot domains that have been registered and associated with a SSL certificate: It’s a good indicator that an attack is being prepared (like a phishing campaign).

A tool got more attention recently event if now brand new: “Amass” from the OWASP project[3]. This tool is easy to install, easy to be “Dockerised” and there is also a package available on Kali. Amass is a reconnaissance tool that helps to gather information about your “target” if you’re on the Red side or, if you’re on the Blue side, to have an overview of your Internet exposure.

The tool is easy to setup via a single configuration file. The key point is to configure your API keys and credentials for the available services that will be queried. Some of them (the list of not complete):

  • Spyse
  • Sublist3rAPI
  • ThreatCrowd
  • URLScan
  • ViewDNS
  • VirusTotal
  • Pastebin
  • DNSDB
  • Google
  • Netcraft
  • AlienVault
  • Censys
  • CertSpotter

You use the tool with submodules:

  • iIntel’ to collect OSINT
  • ‘enum’ to perform DNS network mapping
  • ‘viz’ to vizualize gathered data
  • ‘track’ to compare results between executions (this one is key for Blueteamers!)

Many command line arguments are available, please check the documentation for a complete overview[4].

Let’s start with the enumeration of a well-known domain: sans.edu.

[email protected]:/tmp# amass enum -ip -src -brute -min-for-recursive 2 -d sans.edu
Querying Spyse for sans.edu subdomains
Querying Sublist3rAPI for sans.edu subdomains
...
Querying ThreatCrowd for sans.edu subdomains
Querying URLScan for sans.edu subdomains
Querying ViewDNS for sans.edu subdomains
Querying VirusTotal for sans.edu subdomains
[Crtsh]           isc.sans.edu 45.60.103.34,45.60.31.34
[Crtsh]           sans.edu 45.60.31.34,45.60.103.34
[Censys]          www.sans.edu 45.60.33.34
[Crtsh]           apply.sans.edu 72.55.140.155
[Google]          isctv.sans.edu 45.60.103.34,45.60.31.34
Starting DNS queries for brute forcing
[Crtsh]           handlers.sans.edu 74.208.193.6
[ThreatCrowd]     www3.sans.edu 204.51.94.213
[Riddler]         pre-www.sans.edu 204.51.94.213
[Riddler]         search.sans.edu 204.51.94.41
[BufferOver]      s120-www.sans.edu 204.51.94.126
[ThreatCrowd]     pre-isc31.sans.edu 204.51.94.153
[ThreatCrowd]     isc31.sans.edu 204.51.94.153
[IPv4Info]        isc32.sans.edu 204.51.94.154
[ThreatCrowd]     www2.sans.edu 66.35.59.213
Starting DNS queries for altered names
[Alterations]     s123-www.sans.edu 204.51.94.126
[Alterations]     pre-isc3.sans.edu 204.51.94.233
...
[Alterations]     s82-www.sans.edu 204.51.94.126
[Alterations]     s55-www.sans.edu 204.51.94.225
[Riddler]         lyncdiscover.sans.edu 52.112.192.14,2603:1027:0:2::e
[Brute Forcing]   autodiscover.sans.edu 52.97.186.152,52.97.232.216,52.97.186.120,2603:1026:200:3d::8,2603:1026:206:4::8,2603:1026:206:7::8
[Alterations]     s86-www.sans.edu 204.51.94.126
...
[Alterations]     s128-www.sans.edu 204.51.94.126
[Alterations]     s12-www.sans.edu 204.51.94.246
Average DNS queries performed: 1695/sec, DNS names queued: 0
Average DNS queries performed: 1068/sec, DNS names queued: 0
Average DNS queries performed: 4/sec, DNS names queued: 0
OWASP Amass v3.3.1                                https://github.com/OWASP/Amass
--------------------------------------------------------------------------------
71 names discovered - cert: 5, scrape: 5, api: 5, alt: 55, brute: 1
--------------------------------------------------------------------------------
ASN: 19551 - INCAPSULA, US
45.60.103.0/24    3    Subdomain Name(s)
45.60.31.0/24     3    Subdomain Name(s)
45.60.33.0/24     1    Subdomain Name(s)
ASN: 32613 - IWEB-AS, CA
72.55.128.0/18    1    Subdomain Name(s)
ASN: 8560 - ONEANDONE-AS Brauerstrasse 48, DE
74.208.0.0/16     1    Subdomain Name(s)
ASN: 62669 - SANS INSTITUTE (SANSI-1)
66.35.59.0/24     2    Subdomain Name(s)
204.51.94.0/24    61   Subdomain Name(s)
ASN: 8075 - MICROSOFT-CORP-MSN-AS-BLOCK, US
52.112.0.0/14     1    Subdomain Name(s)
2603:1000::/25    4    Subdomain Name(s)
52.96.0.0/12      3    Subdomain Name(s)

You can see that many interesting information are returned. I like the overview of the Autonomous Systems detected. Sometimes, it’s a good indicator to discover that some services are hosted in cloud services!

The next step is to generate some visual representation of data we collected:

[email protected]:/tmp# amass viz -d sans.edu -d3

There are other export formats like a Maltego one. The result is a file called ‘amass_d3.html’ that can be viewed in any browser:

From a Blue team point of view, the ’track’ sub-module is the most interesting because it helps to find changes that occurred between different enumerations:

[email protected]:/tmp# amass track -d sans.edu
--------------------------------------------------------------------------------
Between 02/26 18:33:09 2020 CET -> 02/26 18:36:19 2020 CET
and 02/26 18:14:47 2020 CET -> 02/26 18:33:09 2020 CET
--------------------------------------------------------------------------------
Moved: lyncdiscover.sans.edu
from 52.112.192.14,2603:1027:0:2::e
to 52.112.193.16,2603:1027:0:2::e
Moved: autodiscover.sans.edu
from 40.101.82.72,2603:1026:c0d:20::8,40.101.80.200,2603:1026:c0d:2a::8,2603:1026:c0b:16::8,52.97.176.40
to 2603:1026:207:14f::8,40.101.80.24,40.101.12.24,2603:1026:207:a7::8,2603:1026:206:8::8,40.101.12.136
Found: s13-www.sans.edu 204.51.94.225
Found: s6-www.sans.edu 204.51.94.246
Found: mp3.sans.edu 204.16.246.222
Found: s23-www.sans.edu 204.51.94.225
Found: s8-www.sans.edu 204.51.94.246
Found: s7-www.sans.edu 204.51.94.225
Found: s127-www.sans.edu 204.51.94.126
Found: s25-www.sans.edu 204.51.94.225
Found: s84-www.sans.edu 204.51.94.126
Found: pre-www31.sans.edu 204.51.94.125
Found: s89-www.sans.edu 204.51.94.126
Found: s83-www.sans.edu 204.51.94.126
Found: pre-www2.sans.edu 66.35.59.213
Found: s17-www.sans.edu 204.51.94.225
Found: s78-www.sans.edu 204.51.94.126
Found: s126-www.sans.edu 204.51.94.126
Removed: s90-www.sans.edu 204.51.94.126

Based on this, you can perform a quick scan of all discovered devices:

[email protected]:/tmp# amass db -show -d sans.edu 2>/dev/null | grep sans.edu | while read HOST; do nmap -sC -v -Pn $HOST; done

About the integration with other tools, Amass (in enum mode) can dump results to a JSON file that can be easily re-used (ex: indexed in a Splunk) to maintain a list of assets.

Conclusion, there are many tools around that could have a real value for Blue teams!

Tip: Amass makes an intensive use of DNS! I recommend you to use one of the public DNS servers (1.1.1.1, 8.8.8.8, 9.9.9.9, etc) to not abuse your local resolvers.

[1] https://isc.sans.edu/forums/diary/Using+Certificate+Transparency+as+an+Attack+Defense+Tool/24114
[2] https://dnstwister.report/
[3] https://github.com/OWASP/Amass
[4] https://github.com/OWASP/Amass/blob/master/doc/user_guide.md

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

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

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Quick look at a couple of current online scam campaigns, (Tue, Feb 25th)

Since I was exposed to three different online scam campaigns in the last three weeks, without having to go out and search for them, I thought that today might be a good time to take a look at how some of the current online scams work.

All of the campaigns we’ll mention seemed to target people in the Czech Republic, although not exclusively, as one of the landing pages I found had at least 20 different regional variants set up for countries from all over the world. In cases where I was unable to find an English version of a page, I had Chrome translate it – the results are not always pretty, but should be sufficient for our purposes.

Everything started a couple of weeks ago, when I was searching for a website of a certain small town theater on my phone. Having found it on Google, I tapped the relevant link and was surprised when, my browser didn’t stop at the intended destination, but rather was redirected to a site proclaiming me a “lucky visitor” of the day with a “chance to win Apple iPhone 11 Pro”.

Given all the ad blockers and script filters I usually use, I didn’t see any similar pages or pop-ups similar to this one (not counting phishing pages, of course) for a long time, so I decided to take a closer look at it. After clicking through four questions related to my preference in browsers, I was informed that I had a chance to win a brand new iPhone (although it wasn’t quite obvious that the offer was to enter a contest and not to buy the phone at an incredibly low price, as you may see for yourself).

One interesting part of this page, which deservers a special mention, was the comments section at the end, as it was seemingly populated in real time through JavaScript embedded in the HTML code. That is, all the comments were loaded as part of the original page at the same time, but displayed one at a time. I imagine that having them appear one after another with “like counts” rising while the user watches might look quite convincing to potential victims.

After clicking the button, browser was redirected to another domain where it seemed, once again, as if a user had the option to buy an iPhone for a small fraction of its usual price.

Next, the site asked for some personal information – a full name and an address along with an e-mail and a phone number.

What wasn’t obvious at first glance, but would be really important to anyone actually trying to order the phone, was a small paragraph hidden at the end of the page, explaining that the customer wasn’t actually buying an iPhone, but was merely entering a prize draw for it. By itself, that wouldn’t be so bad, but the rest of the text mentioned that, besides confirming his participation in the contest, the user would be subscribing to an unnamed pre-paid service with a €75 monthly fee.

The last thing required of a user at that point, would be to fill in his credit card details in order to confirm the payment. Not the €75 subscription, which would later be charged against users account, but the “price” for the iPhone (or rather for a participation in the iPhone lottery) of approximately €1.5.

About a week after I found the previously mentioned website, a colleague of mine asked me, laughing, whether I wanted to buy a new iPhone for €2. My first guess was that he managed to end up on the same site I did. This, however, didn’t turn out to be the case as the second campaign was a straightforward phishing. Nevertheless, what caught my attention was the use of the same graphical style I saw in the previous campaign.

Apart from the stripe at the top, the landing page (and other pages, all the way to the payment form) was nearly identical to those used in the first campaign as well.

Unlike in the first campaign, however, there was no paragraph on any of the pages explaining whether the user was actually subscribing to any service, so it is hard to say what unexpected things one might be charged for if one actually tried to buy an iPhone in this way.

Although the second campaign comes much closer to a phishing style of operation than to a classic scam, re-use of the same assets in both campaigns is interesting. Use of the same phishing kits (or “scamas” as they are sometimes called) on multiple sites is not too unusual – many such kits are actually open-sourced and some may even be found on GitHub. Nevertheless, one usually doesn’t expect to see the same kit used twice within a couple of weeks for two different campaigns with different modes of operation…much less three.

On Saturday, I was looking for information about a vulnerability in a certain software product and one of the results, which Google returned, ended up pointing my browser to another site with the same landing page offering iPhones for €2. At first glance, it looked like another campaign simply re-using the same kit, however, after a bit of digging around, I discovered that this campaign was actually much more complex than the previous ones.

The first and second campaigns used couple of forced redirects each to get a user to the landing page.

The third campaign had multiple starting pages on multiple domains redirecting to a couple of domains/IP addresses, which finally redirected to multiple landing pages (or, under some conditions, to Google). I only mapped out a small part of the starting and landing pages, but the following diagram should give you an idea of the inner workings of this campaign.

Since all three parts of the redirection chain were interesting, let’s take a look at each one in turn.

The initial/starting pages used cloaking (i.e. serving different content to search engine spiders than to regular users[1]), which was the reason I landed on one of these pages in the first place – Google had it indexed as containing information which wasn’t actually there. In addition to the cloak, a referrer check was implemented on the servers serving the initial pages to make things a little more complicated. The behavior and responses of the servers did therefore differ quite significantly based on a couple of factors.

  • If a user should manually enter the address of one of the initial pages (for example hxxp://wzhi.buxtex.de/web-shell.html), the server would return a HTTP 404 response.
  • If the same user were to navigate to the same page through a link from a search engine, the server would return a HTTP 302 response and would redirect the browser in the way shown in the diagram above. The server would only provide the 302 response if an address of a well-known search engine (e.g. Google or Bing) was present in the Referer header of the HTTP request. With the Referer header set to any other value, the server would – once again – return a 404 response.
  • Finally, if a search engine spider such as Googlebot were to visit the page, it (or anyone using a User-Agent header set to “Googlebot”) would be served with a clickbait content cobbled together from different sites. In case of web-shell.html for example, one part of the content was taken from an article published on rapid7.com.

Given the behavior of the servers described above, it is almost certain that any real user would be redirected to another URL after visiting one of the initial pages. That would start a chain of multiple forced redirections between the domains and IP addresses mentioned in the diagram above (and potentially others as well).

Although many of these appear to be suspicious at first glance, not all of them are necessarily malicious – one of the domains, ladsblue.com, actually belongs to a commercial advertising network named Adsterra. A quick Google search for Adsterra led to a number of claims that this network doesn’t always operate ethically[2], however, hoping that these claims are not correct, I did let the company know about the misuse of their ad network with the hope that they will block it.

The redirection chain would end on one of a number of different landing pages, chosen based on geolocation of the IP address from which the user was connected (and potentially other factors). It is possible that not all of the pages one might land on after the redirects end are related to scams. One of the redirection chains, for example, led to a page for a certain betting site, and even though Google results seem to indicate that it might not be a completely legitimate service, I can’t be sure of that without further research I wasn’t willing to put in.

The one site we can be quite sure was a scam, however (apart from the site using the “iPhone for €2” kit we saw in the first two campaigns), was hosted at the domain hxxps://financialwealthnow.net. The reason we may be certain of the fraudulent nature of the site is that this site was a copy of the official website of a Czech 24 hour news TV station[3].

This is the real site…

…and this is the fake one.

The text on the site tries to get visitors to register with a cryptocurrency trading platform with promises of instant wealth and with the help of a fake interview with a well-known Czech politician and entrepreneur praising the platform. If you’d like to take a closer look at the contents of the fake page, I wrote a short post about it (in Czech) at untrustednetwork.net[4].

What appears to be even more interesting than the contents of the page themselves is that the site seems to be part of a much larger operation using fake celebrity interviews and deceptive ads, which is run by a group called FizzCore (thanks to @vavkamil for pointing this out to me). The description of (for lack of a better term) TTPs of this actor provided in the analysis published by Confiant[5] fits the fake news page exactly.

Although the last campaign is quite interesting, neither it, nor either one of the previous ones, were unique. Similarly, forced multiple redirects to less than reputable sites are nothing new. Even though both of these statements are true, I found the brief look I was given into the world of current internet scams fairly informative… And I hope that you did as well.

[1] https://en.wikipedia.org/wiki/Spamdexing#Cloaking
[2] https://www.google.com/search?q=adsterra+scam
[3] https://ct24.ceskatelevize.cz/
[4] https://www.untrustednetwork.net/cs/2020/02/22/ct24_podvodna_stranka/
[5] https://blog.confiant.com/fake-celebrity-endorsed-scam-abuses-ad-tech-to-net-1m-in-one-day-ffe330258e3c

———–
Jan Kopriva
@jk0pr
Alef Nula

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

Reposted from SANS. View original.

Posted in: SANS

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