Tag Archives: SANS

Wireshark 3.2.5 Released, (Sun, Jul 5th)

This post was originally published on this site

Wireshark version 3.2.5 was released.

It has a vulnerability fix and bug fixes.

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

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

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

Happy FouRth of July from the Internet Storm Center, (Sat, Jul 4th)

This post was originally published on this site

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

Russ McRee | @holisticinfosec

Red

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

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

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

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

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

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

#Firework

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

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

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

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

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

Setting up the Dshield honeypot and tcp-honeypot.py, (Wed, Jul 1st)

This post was originally published on this site

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ISC Snapshot: SpectX IP Hitcount Query, (Tue, Jun 30th)

This post was originally published on this site

SpectX was the subject of an ISC post on SpectX4DFIR back in late April. Raido from SpectX provides us with a query to count hits from IPs during different time intervals.

This can be one way of detecting possible bots and automated queries. Running the query below will tell you:

  1. On how many different days do we have hits from a particular IP (column ‘days’)?
  2. On how many different days did we see this IP every hour, 24 hours in a row (column ‘full_days’)?
  3. During how many different hours did we get hits from this IP? (column ‘hours’)?

I ran the query below, slightly modified from Raido’s original, against the April 2020 log file for holisticinfosec.io. You can run this on any log file that contains timestamps and IP-addresses, just change the path, pattern and field names accordingly.

LIST('file:/C:/logs/holisticinfosec.io-ssl_log-Apr-2020') 
| parse(pattern:$[/user/patterns/apache/apacheLog.sxp])
| select(hour:timestamp[1 hour], clientIp) 
| group(hour, clientIp) 
| select(day:hour[24 hour], clientIp, hours:count(*))
| group(day, clientIp)
| select(clientIp, days:count(*), full_days:count(hours = 24), hours:sum(hours))
| group(clientIp)
| sort(full_days desc)

The results as seen in Figure 1 provided immediate insights.

Figure 1: SpectX IP hitcount query result

As promised, these IPs as noted in the results per Figure 1 are all making constant calls to my site, all day, every day. Each are calling my index.xml file, some appear to be RSS readers or scrapers, which is fairly routine. Seems like a lot of needless connect and compute cycles for a low traffic, static site such as mine.
Some of these IPs are definitely of ill repute however. 173.212.239.212, originating out of Nuremberg, Bavaria scored a near perfect 99 of 100 for fraudulent behavior and malicious activity based on recent actions according to IPQSFigure 2 bears this out.

Figure 2: IPQS declares badness

This is useful little query to quickly detect possible bots and automated queries. Hopefully you’ve already downloaded SpectX and given a try after a last post. Load it back up and feed a log. If you want a copy of the log as utilized for this post, let me know via socials or email.

Cheers…until next time.

Russ McRee | @holisticinfosec

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

Sysmon and Alternate Data Streams, (Mon, Jun 29th)

This post was originally published on this site

Sysmon version 11.10, released a couple of days ago, adds support for capturing content of Alternate Data Streams.

When the content of an ADS is text and less than 1 Kb, the content will be logged in the event log.

Here is an example with a download of a file using Microsoft Edge: an ADS named Zone.Identifier will be created for the downloaded file.

With modern browsers, the Zone.Identifier ADS also contains the referrer (ReferrerUrl) and URL for the download (HostUrl), which can be useful for forensics.

I used the following config file for my tests:

<Sysmon schemaversion=”4.32″>
  <HashAlgorithms>md5,sha256</HashAlgorithms>
  <DnsLookup>False</DnsLookup>
  <ArchiveDirectory>sysmonarchive</ArchiveDirectory>

  <EventFiltering>
    <FileCreateStreamHash onmatch=”exclude”/>

    <CreateRemoteThread onmatch=”include”/>
    <DnsQuery onmatch=”include”/>
    <DriverLoad onmatch=”include”/>
    <FileCreate onmatch=”include”/>
    <FileCreateTime onmatch=”include”/>
    <FileDelete onmatch=”include”/>
    <ImageLoad onmatch=”include”/>
    <NetworkConnect onmatch=”include”/>
    <PipeEvent onmatch=”include”/>
    <ProcessAccess onmatch=”include”/>
    <ProcessCreate onmatch=”include”/>
    <ProcessTerminate onmatch=”include”/>
    <RawAccessRead onmatch=”include”/>
    <RegistryEvent onmatch=”include”/>
    <WmiEvent onmatch=”include”/>
  </EventFiltering>
</Sysmon>

 

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

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

tcp-honeypot.py Logstash Parser & Dashboard Update, (Sun, Jun 28th)

This post was originally published on this site

This is an update for logstash and dashboard published in January for Didier’s tcp-honeypot.py honeypot script. The parser has been updated to follow the Elastic Common Schema (ECE) format, parsing more information from the honeypot logs that include revised and additional dashboards.

tcp-honeypot Log Analysis from Discover

tcp-honeypot Dashboard Summary

The file tcp-honeyport parser can be downloaded here and the dashboard JSON here.

[1] https://isc.sans.edu/forums/diary/ELK+Dashboard+and+Logstash+parser+for+tcphoneypot+Logs/25702
[2] https://www.elastic.co/guide/en/ecs/current/ecs-reference.html
[3] https://handlers.sans.edu/gbruneau/elastic.htm

———–
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.

Video: YARA’s BASE64 Strings, (Sat, Jun 27th)

This post was originally published on this site

In diary entry YARA’s BASE64 Strings, I explain the new BASE64 feature in YARA (we’re at version 4.0.2 now).

Here is a video showing this new feature:

 

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

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