Forem: Chapin Bryce

1 minute Canaries

Chapin Bryce — Sun, 16 Oct 2022 13:54:53 +0000

Visibility is everything in cyber security. Let's increase the visibility of suspicious activity in your environment in 1 minute.

Ready?

Step 1: Visit https://canarytokens.org

Step 2: Select the type of canary token that matches your system or your risk. For example, you may choose an Excel or Word document on a corporate device, or AWS keys or a MySQL dump on a developer or server. There are a lot of options here, freely available for your use.

Step 3: Enter the contact email address or a web hook URL (or both!) to notify when your canary is used.

Step 4: Click "Create my Canarytoken" to generate the token to place wherever you like!

The site provides some recommendations, though feel free to get creative - put a token in an email, in a file named passwords.docx, on a file share, in your ~/.aws/credentials file, or if you're crazy enough, you can put them on your website.

[default]
aws_access_key_id = AKIAYVP4CIPPHKZTDHPV
aws_secret_access_key = s5Qi2UmF8jZoES/9q7+/jN6c0uAieT7gZn5Vb9oW
output = json
region = us-east-2

That's all! Now you will get a heads up when someone is snooping around or accessing resources. Have fun with it, share your creative use cases, and pass along this tip to a friend.

Two-minute InfoSec — Shell History Timestamps

Chapin Bryce — Thu, 05 Mar 2020 11:31:29 +0000

Two-minute InfoSec — Shell History Timestamps

A new series with a goal on sharing quick wins that can assist organizational security, forensic investigations, incident response and more that you can implement within two minutes or less.

Photo by Kaitlyn Baker on Unsplash

Today’s post is focused on a a feature of nearly any shell — command history. This file is a rich source of evidence for prior user activity, especially on Linux/Unix/macOS systems. One major draw back is that by default, this file does not store timestamps, making analysis of the data difficult and cost a lot of valuable investigative time.

In this post we will cover how to quickly implement timestamps in some common shells including:

Bash
Zsh
Fish

Not all Linux/Unix/macOS platforms are made the same! These are general ways to accomplish this goal, but always test before putting things into production.

Bash

To add for user accounts, modify the ~/.bashrc or ~/.bash_profile files and add the below:

export HISTTIMEFORMAT ="%F %T %z "

This same line can be placed in /etc/bashrc to load across user profiles.

Source: https://linux.die.net/man/1/bash

Zsh

For user accounts, add the below line to ~/.zshrc or /etc/zshrc for system wide implementation.

setopts EXTENDED_HISTORY

This will not only place a timestamp of execution but also the duration of execution — a very handy data point in investigations! Some Z shells, such as csh, though it doesn’t hurt to check!

Source: http://zsh.sourceforge.net/Doc/Release/Options.html#Options

Fish

Enabled by default! Though check your history file is located at:

~/.local/share/fish/fish_history

Have another shell you use and prefer? Or maybe an alternative implementation on a specific OS? Comment and we can add it in to this post for ease of future reference!

3-Step RDP Honeypot: Step 3 | Build the Bot

Chapin Bryce — Sat, 15 Feb 2020 14:26:44 +0000

In this mini-series, we have setup our honeypot, extracted valuable features from our PCAP data, and now we operationalize this intel.

Continue reading on Medium »

3-Step RDP Honeypot: Step 2 | Operationalize PCAPs

Chapin Bryce — Sat, 15 Feb 2020 13:03:14 +0000

With our RDP Honeypot PCAP data captured, let’s analyze it. We will leverage Moloch to assist us with extracting valuable PCAP features.

Continue reading on Pythonic Forensics »

3-Step RDP Honeypot: Step 1 | Honeypot Setup

Chapin Bryce — Sat, 15 Feb 2020 13:02:31 +0000

Step 1 in our process is creating our Honeypot service and start capturing the request data. This brief post dives into building the most…

Continue reading on Medium »

3-Step RDP Honeypot: Step 0 | Introduction

Chapin Bryce — Sat, 15 Feb 2020 13:01:56 +0000

Easily set up your own RDP Honeypot, capture bots scanning for vulnerable systems, and operationalize the data to help the InfoSec…

Continue reading on Medium »

Build your own RDP Honeypot

Chapin Bryce — Wed, 20 Nov 2019 01:46:08 +0000

This is a short post, largely inspired by alt3kx and their awesome post here:

Build an easy RDP Honeypot with Raspberry PI 3 and observe the infamous attacks as (BlueKeep) CVE-2019–0708 | by alt3kx | Medium

alt3kx ・ Jun 5, 2019 ・
Medium

Please go check it out!

Where this post differs is implementing on a Debian cloud instance of your choice and adding in email reporting. We will run through all the steps just to have a cohesive post, though most of the steps do mirror those in the aforementioned post.

# Requirements

We will be setting up in a virtual/cloud-based environment. This has pros/cons (versus your own RaspberryPi or other hardware), though we can save that for the comments ;)

Access to a Windows 2008 R2 server that you don’t mind making insecure temporarily. One option is to spin up an EC2 instance in a new security group just for this sole use. You can also use Azure/other platforms supporting Windows 2008 R2 images.
A Debian based compute instance on your cloud hosting provider of choice. This will actually host our honeypot, so we will want to set this up separate from everything else. This guide won’t walk thru a hosting provider specific setup, as there are too many to cover. You will also want to ensure you have X11 forwarding configured over SSH.

# Windows 2008 Setup

Spin up both your Windows 2008 R2.
RDP into the Windows 2008 R2 instance and disable “Network Level Authentication” (this guide walks through the process).

# Debian/Honeypot Setup

This setup has a few more stages:

## Installing and configuring RDPY

This honeypot will leverage the GitHub project RDPY, as it covers the tooling needed to setup an RDP listener on a Linux host. This can be installed using a Python 2.7 version of pip.

pip install rdpy

We will also need to install a few more tools using apt install python-qt4 xauth screen freerdp2-x11. You may need to install pip as well.

Once these are setup (and X11 forwarding is configured for your SSH session) we will generate the fake RDP prompt that will show on connection.

I recommend using screen for this part, though you can also open a second SSH connection to the host.

In one terminal, run the below command, where 1.1.1.1 is the IP address of your Windows 2008 R2 host:

rdpy-rdpymitm.py -o ./ 1.1.1.1

In the second terminal, we will use our xfreerdp client to connect to our MiTM proxy, providing the username Administrator and forcing the client not to use Network Level Authentication:

xfreerdp --no-nla -u Administrator 127.0.0.1

In this case we do want to use the IP address 127.0.0.1

A window should pop up and show the xfreerdp interface with a prompt to select a user account. There is no need to interact with the interface at this point and we can close out.

Feel free to use ctrl-c in the terminal with our MiTM script. You should see a new file in the same directory as the script, with the extension rss. This file contains a play back (which for bonus points you can view with rdpy-rssplayer.py) needed for the honeypot script.

At this point we will want to use screen or nohup to start our honeypot and keep it running on disconnect (so we don’t have to keep our connection alive for the honeypot to remain up).

We can safely destroy our Windows 2008 R2 instance now and save on the cloud hosting fees!

Now we are ready to run the honeypot script, it is as simple as the below, where you provide the name of your RSS file as the only argument:

rdpy-rdpyhoneypot.py \*.rss

Congrats! The honeypot is live!

## Getting intel out of your honeypot

This next step is where we can automate a few tasks to send reports to our mailbox.

To start, we will want a few tools to capture, process, and report on the activity. Let’s install them:

apt install tcpdump bro bro-aux zip

We first will use tcpdump to capture all traffic on TCP/3389 into a PCAP file:

tcpdump tcp port 3389 -i eth0 -vvX -w ‘rdp.%FT%H-%M-%S.pcap’ -C 500 -G 86400 -W 10

Please sub in your own interface (ie eth0) and file naming convention. For full details on this tcpdump command line, check ExplainShell. This capture should also run as an admin in a screen or nohup session to prevent it closing on disconnect. Neither of these solutions will assist in the case of a reboot.

Now we can move to our report generation! For this, we will use bro to generate easy to consume logs from the PCAP files. We will then take these logs and create a summary report that we send via email. This is all possible in the below script (please modify as you see fit!)

You will need to sub in your own information for Mailgun if you want to use that API, otherwise feel free to plug in your own email sending routine.

Now that we have the script setup, we can create a cron job to run it for us daily and fill our inbox with a summary of what we caught in our honeypot!

Please play around with this configuration and fine tune further to your liking. If possible, please share back to the community!

Useful Commands for Log Analysis: Part 2 — Sed

Chapin Bryce — Sat, 06 Oct 2018 17:38:37 +0000

Useful Commands for Log Analysis: Part 2 — Sed

To follow up on the prior post discussing bash tips & tricks here are a few more commands that are useful in text, specifically log, file analysis.

Photo by Bruno Martins on Unsplash

Intro to using sed

In this example, we will use sed to help normalize the data we are processing. This utility is a stream editor, useful in manipulating data. In our scenario below, we will use it to find and replace text strings.

In our example below, we have a squid proxy access log and will work to extract a unique list of domains from the log file. Using a similar process as last time, we will iteratively build out our command to further refine our results. To start, let’s take a look at the format of the log:

$ head -n 3 access.log 
10.53.56.81 - - [26/Nov/2017:14:20:26 +0000] "CONNECT aus5.mozilla.org:443 HTTP/1.1" 200 0 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0" TAG\_NONE:HIER\_DIRECT 
10.53.56.81 - - [26/Nov/2017:14:20:26 +0000] "GET https://aus5.mozilla.org/update/6/Firefox/47.0.2/20161031133903/WINNT\_x86-msvc-x64/en-US/release/Windows\_NT%2010.0.0.0%20(x64)/SSE3/default/default/update.xml HTTP/1.1" 200 946 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0" TCP\_MISS:HIER\_DIRECT 
10.53.56.81 - - [26/Nov/2017:14:20:27 +0000] "GET http://download.mozilla.org/?product=firefox-56.0-complete-bz2&os=win&lang=en-US HTTP/1.1" 302 585 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0" TCP\_MISS:HIER\_DIRECT

As seen above, we have the URL in the 7th column. Using awk, as we did in the prior post, we can isolate this field as shown below by selecting the 7th space delimited column:

$ head -n 3 access.log | awk '{ print $7 }' 
aus5.mozilla.org:443 https://aus5.mozilla.org/update/6/Firefox/47.0.2/20161031133903/WINNT\_x86-msvc-x64/en-US/release/Windows\_NT%2010.0.0.0%20(x64)/SSE3/default/default/update.xml 
[http://download.mozilla.org/?product=firefox-56.0-complete-bz2&os=win&lang=en-US](http://download.mozilla.org/?product=firefox-56.0-complete-bz2&os=win&lang=en-US)

These first three entries are all the same domain, though we need to clean up our URLs to extract just the domains. To start, let’s remove the query string data. Query strings contain parameters passed between pages on a web site and follow the ? character found in the URL. To remove this, let's use awk again, setting the delimiter to ? and displaying the field prior to the character:

$ head -n 3 access.log | awk '{ print $7 }' | awk -F '?' '{ print $1 }' 
aus5.mozilla.org:443 https://aus5.mozilla.org/update/6/Firefox/47.0.2/20161031133903/WINNT\_x86-msvc-x64/en-US/release/Windows\_NT%2010.0.0.0%20(x64)/SSE3/default/default/update.xml 
[http://download.mozilla.org/](http://download.mozilla.org/)

Now that we’ve addressed query strings, let’s remove the protocol statement. This includes http:// and https://, though can be other protocols such as ftp://. Since in this log we only see the HTTP and HTTPS protocols, we will manually specify those to be removed; while there are other methods to do this, let's use sed:

$ head -n 3 access.log | awk '{ print $7 }' | awk -F '?' '{ print $1 }' | sed 's|http\(s\)\*://||' 
aus5.mozilla.org:443 aus5.mozilla.org/update/6/Firefox/47.0.2/20161031133903/WINNT\_x86-msvc-x64/en-US/release/Windows\_NT%2010.0.0.0%20(x64)/SSE3/default/default/update.xml 
download.mozilla.org/

In the above, we have specified a sed substitution expression. The initial s in the sed command executes the substitute function. The syntax following this function is described below (and further in the man page):

| - This character is the delimiter between the substitute function sections. It is generally a / character, but since we are including / as a character in our pattern, we have to use another character. It is common to instead use the | as an alternative.
The first section is the pattern sed will look for. In our case, we are specifying that we want to look for anything that matches the regex http(s)*:// which will match both the http:// and https:// protocol specifiers.
The second section is empty here because we are using sed to remove the string. In other situations, we could put a replacement string between the last two pipe characters.

Our URLs still have page URL paths and port numbers, which we can remove using awk. We will use two awk statements, with different delimiters to remove these values:

$ head -n 3 access.log | awk '{ print $7 }' | awk -F '?' '{ print $1 }' | sed 's|http\(s\)\*://||' | awk -F '/' '{ print $1 }' | awk -F ':' '{ print $1}' 
aus5.mozilla.org 
aus5.mozilla.org 
download.mozilla.org

Great! We are down to subdomains, which we can generate stats on using the usort alias we created in the prior post). To demonstrate this further, lets replace the head -n 3 statement with cat to review the full file.

$ cat access.log | awk '{ print $7 }' | awk -F '?' '{ print $1 }' | sed 's|http\(s\)\*://||' | awk -F '/' '{ print $1 }' | awk -F ':' '{ print $1}' | usort 
1 36cc206a.akstat.io 
1 a.scorecardresearch.com 
1 a.visualrevenue.com 
1 a1.vdna-assets.com 
1 ads.lfstmedia.com 
[...] 
146 cdn.images.express.co.uk 
149 px.moatads.com 
186 pagead2.googlesyndication.com 
205 dt.adsafeprotected.com 
380 [www.google.com](http://www.google.com)

Now that we have this list, we can further process this data in a number of ways:

remove subdomains to get a better count of the number of domains
feeding the domains into an API to gather intelligence (whois, ASN, GeoIP, reputation, etc.)
searching for activity specific to one or more of the domains (ie What searches were made with google.com)
if we add back in the port numbers and/or protocol specifiers we can look into the frequency of those data points in our access log

Originally published at pythonicforensics.com on October 6, 2018.

Useful Commands for Log Analysis

Chapin Bryce — Mon, 01 Oct 2018 01:54:07 +0000

Over the past few months, I’ve been performing more and more analysis in Linux environments and had the opportunity to refine my go-to commands, picking up a few new (to me) tricks. In this post, I’ll share some of the techniques I like to use and encourage you to share other tips/tricks you’ve used to perform analysis on Linux systems, either as your analysis environment or as your target evidence (or both)!

Photo by Daniel Leone on Unsplash

This is written at the introductory level, to help those who may have not have experienced performing analysis within a bash/sh/zsh (or other) command line environment before.

Warning: this post does not contain Python

Spoiler — I didn’t get as far this weekend on this post as I wanted, so I’ll keep this one short and put another one out soon with more tips & tricks.

For those newer to the command line

If you are newer to the bash command line, please use the manual (man) pages for documentation. It takes a little while to understand how they are written and where the detail you are looking for lives, so it is best to start using them early. Here's an example of using the man command to learn more about ls:

Common man pages are found on linux.die.net, though they should be available on the same system as where the command is found, as shown above. There are also great sources such as explainshell.com and Julia Evan's reference illustrations & cheat sheets (such as this on about the man command).

For those experienced with the command line please share your favorite resources!

Working with logs

Log data is not only a very common source of evidence on Linux platforms but is also easier to work with at the command line since it is, generally, semi-structured text data.

Identifying the most interesting content in unknown logs

As part of the process we, in DFIR, like to preview and get a sense of what is useful versus what is noise in a log file. To assist with this data reduction, we can use a few tools and processes to cut down on review time.

One trick I like to employ is the use of less in combination with grep -v. In the example below, we will be looking at a server's auth.log, a common log file, and we are interested in seeing successful authentications. While some of us may know to start looking for strings such as "Accepted publickey" from experience, we will walk through getting to that point using the grep -v method. While grep is a great utility for searching datasets, we want to find the inverse of our pattern and need to use the-v parameter:

As seen above, we add keep adding new log messages to remove from our output, until we see something of interest (ie the Accepted publickey statement). Now, we can instead grep for Accepted publickey as shown below:

A few notes on this method:

We can use OR statements (|) to form one larger grep statement, though do what is most comfortable for you
If the log dataset is small enough it may be best to scroll through the text file
Inversely to this method, we could start by searching for IP addresses, usernames, and timestamps depending on how much of that information is already known (as sometimes we aren’t lucky enough to have any of those indicators up-front)
After identifying what string is useful, go back and confirm you didn’t accidentally over-exclude content through the use of one or more of your patterns
We interchange use fgrep, and egrep in place of grep. These are variations on the standard grep interface, though fgrep is essentially an alias for grep -f
fgrep runs much faster as it only searches fixed strings. It is a good default as a fair amount of the time we are searching for a string without any patterns.
egrep allows for extended patterns and is a bit slower. It changes the behavior of the patterns, further detailed in man re_format

Pulling out useful statistics from log files

Another useful technique is to extract information such as ‘how many IP addresses attempted authentication to the machine’ and related ‘what usernames were they using’. To do this, using the same log as before, we can leverage grep, less, and awk.

Let’s use a pattern we discovered previously, “Invalid user”, to pull these types of answers. The below output shows the first 5 attempts, using head, where we see the username and IP address in the same message.

Since we want to only extract the IP address, for the first part of the question, let’s use the awk command. This command allows us to process text, in this case, printing selected columns of data. By default, awk will split on spaces though we can change the delimiter if needed. While awk has many functions, we will use the print feature to select the column with the IP address. Since awk will split on spaces, we will select the 10th column (column numbering starts at 1).

Great — we now have a list of IP addresses. Let’s now generate some stats using sort and uniq. As the names suggest, we will generate a unique list of IP addresses and gather a count of how many times they appear in those messages:

The new statements sort | uniq -c | sort -rn is what generates our nicely formatted list. The uniq command requires sorted input to properly deduplicate, uniq -c provides a count in addition to a deduplicated list, and finally sort -rn provides a numerically sorted (-n) list in reversed order (-r). Since this is a statement I use fairly often, I have made two aliases that I find useful:

And now I can re-run the prior command using the alias:

A few notes on this method:

Using space delimiters is dangerous, especially in log files. Imagine, for example, if a username (somehow) contained a space character. We would no longer be able to use column 10 as our IP address column for that row and would need to employ a different technique
The aliases provided only read from stdin. This works for my use case but is an important consideration. Worst-case scenario, we can always run cat $file | usort to leverage the alias.
Adding in the username, or any other field, would be as easy as specifying an additional column number in the awk statement. We would have to reconsider how we generate statistics though, as the usort alias will read the whole line when providing the counts.
We can use other tools, such as cut to provide similar functionality to awk. Find the ones you like and can remember and use those :)

One last piece on useful statistics, we can quickly generate larger counts using the wc utility. Leveraging the above command, we will use wc to get a count to the number of lines containing "Invalid user":

$ fgrep Invalid\ user auth.log | wc -l 
3549

This utility allows us to count other values, such as characters and words, but in this case, we specified -l to only get us the number of lines.

Sorry for the abrupt and early stop, but I wanted to memorialize this before it became another multi-weekend project that took too long to release. I hope to continue to put smaller posts like this out, hoping they help someone looking to add more bash/sh/zsh/other shell command line environment into their casework.

Next post ideas:

Working with JSON data at the command line
Writing useful loops
List of useful aliases and one-liners

Thoughts on the above? Leave a comment below!

Originally posted 2018–09–30

Update 2019–01–18 : Since writing this post, I’ve come across a useful tool for prototyping longer or iterative bash statements. The ultimate plumber, up, is a really great tool for testing new statement and saving the final iteration to a script for re-use.

Originally published on October 1, 2018.

Forem: Chapin Bryce

1 minute Canaries

Two-minute InfoSec — Shell History Timestamps

Two-minute InfoSec — Shell History Timestamps

A new series with a goal on sharing quick wins that can assist organizational security, forensic investigations, incident response and more that you can implement within two minutes or less.

Bash

Zsh

Fish

3-Step RDP Honeypot: Step 3 | Build the Bot

3-Step RDP Honeypot: Step 2 | Operationalize PCAPs

3-Step RDP Honeypot: Step 1 | Honeypot Setup

3-Step RDP Honeypot: Step 0 | Introduction

Build your own RDP Honeypot

Build an easy RDP Honeypot with Raspberry PI 3 and observe the infamous attacks as (BlueKeep) CVE-2019–0708 | by alt3kx | Medium

alt3kx ・ Jun 5, 2019 ・
Medium

# Requirements

# Windows 2008 Setup

# Debian/Honeypot Setup

## Installing and configuring RDPY

## Getting intel out of your honeypot

Useful Commands for Log Analysis: Part 2 — Sed

Useful Commands for Log Analysis: Part 2 — Sed

Intro to using sed

Useful Commands for Log Analysis

For those newer to the command line

Working with logs

Identifying the most interesting content in unknown logs

Pulling out useful statistics from log files

Useful Commands for Log Analysis. Over the past few months, I’ve been… | by Chapin Bryce | Pythonic Forensics

Chapin Bryce ・ Jan 19, 2019 ・
Medium

Forem: Chapin Bryce

1 minute Canaries

Two-minute InfoSec — Shell History Timestamps

Two-minute InfoSec — Shell History Timestamps

A new series with a goal on sharing quick wins that can assist organizational security, forensic investigations, incident response and more that you can implement within two minutes or less.

Bash

Zsh

Fish

3-Step RDP Honeypot: Step 3 | Build the Bot

3-Step RDP Honeypot: Step 2 | Operationalize PCAPs

3-Step RDP Honeypot: Step 1 | Honeypot Setup

3-Step RDP Honeypot: Step 0 | Introduction

Build your own RDP Honeypot

Build an easy RDP Honeypot with Raspberry PI 3 and observe the infamous attacks as (BlueKeep) CVE-2019–0708 | by alt3kx | Medium

alt3kx ・ Jun 5, 2019 ・ Medium

# Requirements

# Windows 2008 Setup

# Debian/Honeypot Setup

## Installing and configuring RDPY

## Getting intel out of your honeypot

Useful Commands for Log Analysis: Part 2 — Sed

Useful Commands for Log Analysis: Part 2 — Sed

Intro to using sed

Useful Commands for Log Analysis

For those newer to the command line

Working with logs

Identifying the most interesting content in unknown logs

Pulling out useful statistics from log files

Useful Commands for Log Analysis. Over the past few months, I’ve been… | by Chapin Bryce | Pythonic Forensics

Chapin Bryce ・ Jan 19, 2019 ・ Medium

alt3kx ・ Jun 5, 2019 ・
Medium

Chapin Bryce ・ Jan 19, 2019 ・
Medium