Mike Pilkington mpilking

SFTP Upload-Only Configuration

The goal of this configuration is the following:

Create a user named uploaduser that is able to SFTP to a dedicated server to upload files to a directory at /sftp/uploads/uploaduser
The user can upload, but should be unable to download, list, or delete/overwrite files in this location or any other
Shell (SSH) access must be disabled for the user
The user should be able to authenticate with either a password or SSH key (if key-only auth is preferred, that's easy to update in /etc/ssh/sshd_config)
The uploaded files should be accessible by any standard users who are added to a new group named analysts (i.e., specified users shouldn't require superuser/sudo rights to access and manage the uploaded files)

Simple No-Security Tactical Elastic Install

The primary purpose of this gist is to setup a simple Elasticsearch and Kibana install on a Linux host using docker and docker-compose. There are a few notes at the end about setting it up on Windows instead.

Note: Security is disabled (no passwords, no encryption) because the intention is to ingest data and review it on a standalone system (likely in an analysis VM).

Install on Linux with Docker

Prereqs:

Generating New PKI for Velociraptor Server Config

Update: The process below no longer works for the later versions of Velociraptor. The certificates created do not include Subject Alternative Nmes, which are now a requirement for later version of Go (and therefore Velociraptor). I tried briefly to get the right openssl config to add a proper SAN, but it wasn't working. So now in class, we'll just use the recommended way to update the server's certificate with the following command: velociraptor --config server.config.yaml config rotate_key > new_server.config.yaml (Ref: https://docs.velociraptor.app/docs/deployment/troubleshooting/#debugging-client-communications & https://docs.velociraptor.app/knowledge_base/tips/rolling_certificates/)

!!! WARNING -- This process is not for production use. This is for training purposes only.

The following process is not at all recommended for the creation and handling of Velociraptor keys and certificates in production. I had a specific need to create long-

	name: MacOS.Collection.AftermathLocal
	author: Wes Lambert -- @therealwlambert, Mike Pilkington, Claude
	description: \|
	This is a simple artifact that leverages Aftermath to collect many different forensic artifacts from a macOS host, then uploads the results to the Velociraptor server. This artifact is based on the original version from Wes Lambert which downloads Aftermath binary from the Velociraptor server. That version is available in the Artifact Exchange at https://docs.velociraptor.app/exchange/artifacts/pages/macos.collection.aftermath

	This variant uses a copy of the Aftermath binary that is already
	pre-installed on the endpoint (by default `/usr/local/bin/aftermath`,
	e.g. deployed via MDM or a package) instead of downloading and serving
	the binary from the Velociraptor server.

	#!/bin/bash

	logfile=/tmp/460-ewb-fix.log

	# Remove lock file that is preventing git pull
	rm /mnt/c/SANS/.git/refs/remotes/origin/main.lock >> $logfile 2>&1

	# Next command is needed to match the proper OS and DOCROOT variables in existing update script
	sed -i 's/Microsoft/3.4.0/g' /mnt/c/SANS/resources/workbook-update.sh >> $logfile 2>&1