Browse Source

These are no longer relevant. Artemis has been superseded by Imperial Intelligence, as has the team-building exercise. White-hat Demo is now its own repo.

DarkFeather 4 months ago
Signed by: DarkFeather GPG Key ID: 1CC1E3F4ED06F296
3 changed files with 0 additions and 172 deletions
  1. +0
  2. +0
  3. +0

+ 0
- 50
Classes/ View File

@@ -1,50 +0,0 @@
This group is dedicated to playing [ Artemis Spaceship Bridge Simulator], learning teamwork to overcome challenges and improve communication, within a fun, science-fiction atmosphere.

# About the Game

## Instructions to Install
* If you are an [[User:DarkFeather/Sandbox#Stations|LO]], purchase [ a bridge license] and download the 2.4.0 installer -- otherwise, get a copy of the installer from your captain.
* Install Artemis for all users on your system.
* Get a copy of the mod from [ the AniNIX].
* Copy the contents of the mod to "C:\Program Files (x86)\Artemis\dat". You should be prompted whether you want to replace files; confirm the replacement.
* Launch Artemis from "C:\Program Files (x86)\Artemis\Artemis.exe". You should see yellow LCARS-like buttons rather than the standard blue and advanced models.

## Stations
Every ship requires a commanding crew; while it is possible to command a ship alone, greater challenges can be beaten with a crew. Each crew should strive for a five-person command staff, though if a crew is short personnel some stations may be overloaded. The LO will be be one such position that's always overloaded.
* Helm: The helm officer (HO) controls the course and speed of the ship, managing maneuvering, impulse, and warp or jump drives. Helm also has access to shield and mainscreen control. All vessels require a HO.
* Weaponry: The weapons officer (WO) controls all weaponry onboard. They are in charge of loading or unloading torpedo tubes and phaser targeting. All vessels require a WO.
* Engineering: The engineering officer (EO) controls power distribution throughout the ship for all systems and the damage control teams.
* Science: The science officer (SO) is in charge of gathering information and managing the sensors. Science provides shield harmonics to the WO and a course to the HO.
* Captain: The captain is in charge of coordinating the other officers and monitoring communications.
* Licensing: These individuals have purchased a bridge license. To accomodate the developer's licensing requests, each crew should have at least one licensing officer (LO). This position should overloaded with another station.
* Commander Air Group: The CAG is in charge of the fighter stations on board vessels with a fighter complement. This station may be overloaded or a dedicated one on carrier-class vessels.

## Backstory
Multiple timelines have converged as a shared threat in the temporal cold war. The nexus is a stellar nursery. The Federation [ Starfleet] has led the charge to prevent damage to the timeline, and now both factions have setup up a dense network of stations in the stellar nursery, supported by civilians. The opposing factions have been raiding the border, and temporal operatives from Starfleet have contacted other factions for help. It is still unknown who is leading the opposing factions against Starfleet, though there is suspicion of an [ Iconian] influence.

Allied factions:
* [ Romulan Republic]
* [ Klingon Empire]
* [ Rangers]
* [ Independent Planets]
* [ Colonial Fleet]

Opposing factions:
* [ Orion Syndicate]
* [ Dominion]
* [ Borg Collective]
* [ Cardassian Union]

Native (and hostile) species to the nursery:
* [ The Dragon Race]
* [ The Biomechs]

# Roster

## LOs
* Mark Jambor
* Connor Ford

## Static Crews

## Enlisted Personnel

+ 0
- 42
Classes/ View File

@@ -1,42 +0,0 @@
This is in support of team-building between [[TeamRed]] and [[TeamBlue]] staff, or any other group. ARGs like [ Seek] and puzzle rooms also offer good opportunities, but this paradigm works for a geodiverse staff. It's good to use these games as a kick-off to penetration testing, as a way to familiarize the teams with each other's communication styles before given their assignments.

The AniNIX domain has rules in its [[AniNIX::Shadowfeed]] to support running these simulations. Geodiverse teams may want to use TeamSpeak, Discord or Skype for voice relay.

# Team Purple Anectdote
Some organizations have noticed a tendency in red-team and blue-team crews to become combative with one another. Sites in this situation have found it useful to randomly shuffle the teams between assignments, so that personnel operate as a mixed "Team Purple", with red- and blue-team prefixes only applicable to the individual assignment.

# Basis
A number of recent scifi series have been focusing on small crews operating out of a mobile fully-complete base of operations, a starship. This makes for a very interesting model -- real-world penetration testing teams may use small Sprinter-style vans rigged with a complete [[Service_and_Host_Layout|AniNIX clone domain]] onboard, rigged into the roof. Living space can be rigged in the back with the crew riding forward.

Some example shows include:
* [ StarGate Atlantis]
* [ Dark Matter]
* [ Star Trek: Enterprise]

## Space-based naval engagements
Space operations are supplied by the [ Artemis Starship Bridge Simulator]. Crews operate a starship in scenarios and naval battle simulations with diverse roles.

## Ground special operations
Ground operations are supplied by the [ Unvanquished freeware]. This is a mixed base building and small-team game -- TeamBlue will operate with classic Human ranged weapons, while TeamRed aliens focus on melee attacks and unconventional warfare.

# Example layout
Here we have some basic layouts to provide structure for the operation -- creative teams can add their own story and intrigue. Space operations require more coordination than ground operations, but here are the default roles. Additional teammates can be added as generic infantry/fighterpilot roles.

* Commanding officer: Starship engineer and ground engineer
* Executive Officer: Starship weapons officer and ground heavy weapons specialist
* Intel Agent: Science/Comms officer and ground overwatch
* Specialist: Starship helmsman and ground recon infantryman

:<b>Note</b>: If any team is to be at a numerical disadvantage, it should be TeamRed. TeamBlue should have 1-2 more players in unbalanced scenarios. This lets them rush on the ground while protecting their base and to use fighter support in space combat to intercept nuclear weapons. Artemis is particularly vulnerable to weak weapons officer getting overwealmed and missing an incoming nuke, while Unvanquished also has trouble with phase balancing between the teams allowing well-timed rushes. This weighting thus matches real-world manpower discrepancies.

## TeamBlue onboard the TSS Nakhimov
Named for [ Admiral Pavel Nakhimov], Team Blue operates out of a warp-drive [ Terran juggernaut] with a [ human away team]. These crews should focus on maintaining close unit integrity and defensive base security, slowly marching the whole of their firepower into range with a well-researched strategy. Strong coordination and well-rehearsed close-quarters procedures keep the crew alive and out of TeamRed's easy reach.

## TeamRed onboard the XSS Qahirah
Named for the [ Abbasid conquerors'] capital now known as Cairo, Team Red operates out of a jump-drive [ Ximni battleship] with an [ alien away team]. These crews should focus on unconventional ambush tactics -- ground crews should use early dretch units to probe for weaknesses, focusing on picking off stragglers with predatory tactics later. In space, the scanning abilities of the ship should be used to identity gaps in the cover being used by TeamBlue to make calculated jumps.

## AI Support
Individual teams can manage team-building exercises for their role with Artemis scenarios and Unvanquished [ navmesh bots] to take the place of the other team.


+ 0
- 80
Classes/ View File

@@ -1,80 +0,0 @@
I want to emphasize the importance of cybersecurity by showing how a few bad practices can disclose supposedly secure information. Moreover, I want to emphasize the tools that

# This Demo is Not...
* How to hack your friend’s FaceBook
* How to become an evil hacking mastermind
* How to control the Matrix

# Materials
* Control of Wifi network and wifi's DNS, if using physical hardware, or some method of controlling routing.
* Demo computer (VM or physical)
* For easy installation, install [[ShadowArch#How_to_Install_ShadowArch|ShadowArch]] with a graphical environment and a Holocron layout.
* Run the following. This Makefile is viewable in [ the ConfigPackages git repo]. <pre>make -C /usr/local/src/ConfigPackages/WhiteHatDemo democlient</pre>
* You will still need to sync /etc/hosts with the demo server.
* Users can access a virtualized demo client with VNC over [[SSH]].
* Demo server with lighttpd, telnet server, ftp server, OpenSSH server, Wireshark.
* For easy installation, install ShadowArch with the GUI option, and run the following: <pre>make -C /usr/local/src/ConfigPackages/WhiteHatDemo demoserver</pre>
* Lighttpd should be configured with both unsecured and secured traffic.
* Lighttpd will need one URL that is auth protected -- simple auth is sufficient.
* There should be a remote-capable user "testuser" with a preset initial password.
* You should also sync /etc/hosts with any demo clients.
* [ Kali Linux] iso -- if you're using physical hardware for the demo, use a [[Holocron]] flashdrive
* A demo user with a read-write VNC view of the democlient, a pentester with physical access to the server and client, and a class with read-only VNC sessions watching the client.

# Exercises
## Account Credentials
<!-- This should be updated to be a BurpSuite assault -->[[Category:TODO]]
* An obviously dumb password should be set in the server's /etc/lighttpd/.lighttpdpassword and disclosed to the demouser.
* The pentester "guesses" the password and discloses why it's weak.
* Talk about [ strong passwords].
### Mobile PIN Break
* Talk about how PINs are important
* Talk about guessing pins from smudges
* Financial data, email accounts, text messages, and such are all accessible.
* Talk about [ phisihing] via a captured phone with SMS
## Encrypted network traffic
The key takeaway is to encrypt all network traffic. While a [ VPN] and similar network encryption models help, these tools are very simple and controllable.
### Browsers
[ SSL] allows us to validate that we are talking to the site we expect to.
* Use wget to mirror a login page to the demo server. The Makefile defaults to
* Redirect the traffic to unsecured traffic
* Have the demo user connect to the site over unsecured HTTP.
* Have a user connect to the same site over HTTPS and see the warning message.
* Optionally, remove the diverted routing and have the user reconnect to the site over HTTPS without seeing the warning.
* Capture traffic on [ Wireshark] and ask the demo user to confirm their password in the capture.
* Talk about SSL chain of trust.

SSL encryption also prevents capturing session information.
* Have the demo user go to the demoserver's web server over unsecured HTTP.
* The root page will have a POST HTML form.
* Use Wireshark to capture the data and show the TCP stream.
* Have the demo user repeat the process over HTTPS.
* SSL will prevent following the stream.

### Telnet/FTP
* Have the demo user reset his password on the server with telnet.
* Capture traffic with Wireshark and show the password.
* Have the demo user pull down a file over FTP, change it, and put it back up.
* Capture traffic with Wireshark and show the change.
* Explain SFTP/SSH correlation to HTTPS -- encryption matters.

## Storage bypass w/ iso
[ Disk encryption] makes it harder to access data. While physical access is death, strong encryption can delay access beyond heat death of the universe, which is long enough.
* Have the demo user set the root password and add a file in /root.
* Power off the machine and have the pentester take control.
* Ask the class if the files are secure.
* Boot the machine with the iso instead and find the file.
* Optionally, set the root password and boot the original system.
* Talk about encrypted storage and how this recovery would be harder.
### File recovery
Just because a system has files deleted from it doesn't mean that the data is lost.
* dd 0's onto small partition on demo server
* Create ext4 filesystem
* Have the demouser create a file, display its contents, and delete it.
* The pentester "steals" the hardware and boots with a Kali iso
* Run "extundelete <disk> --restore-all -o /root" to recover the file
* Talk about secure deletion with shred or similar programs and the added difficulty of disk encryption.