T10 Basic Operator Course
Graded Practicals Guidelines v14
Course Rules
Students are not permitted to discuss any portion of these practicals with other students via any communication method. Students must report any incidents related to academic integrity, even if they only overhear a conversation about it. Students are only permitted to speak to identified instructors/facilitators while plans and operations are being conducted. Students are not permitted to log into the Instructors Admin Box.
Any violation of these rules will result in immediate failure of the course.
Students will be provided with one Kali OpStation in which all practice ops and graded evaluations will be conducted from. Every single thing you do will be done from your opstation (or an approved Listening Post {LP}). At no point should you run ssh/scp commands from a target machine. SSH control sockets are the only means of tunneling that you will use during these evaluations. All things 'cloudinit' need to be ignored and left alone, this is a remnant of Openstack. Students will complete all 8 evaluations to the best of their abilities; there will be no 'taking a knee' or 'tapping out' after 5 successful completions (Note: Special circumstances do happen and will be handled accordingly).
SPECIAL NOTE:
Students will NOT remove, alter, or unset their bash history on any target. This is for grading purposes.
Every student will start with four points on every practical. Making mistakes will either cost the student some of their points or all of them. Having 0 or negative points on an op results in a failed operation. Students must pass five out of eight evaluated operations to be considered for course graduation. (Passing 5 of 8 evaluated operations does NOT guarantee course graduation.)
Operations
Every Operation will consist of multiple immediate failure situations. These situations will be used as the initial grading points.
These include, but are not limited to:
- Not following the Mission Plan
- Not identifying Security products installed on the device such as:
- SELinux
- Anti-Virus Software
- Active firewall
- Not identifying abnormal/irregular logging such as:
- Remote logging
- Process accounting
- Network monitoring software
- Anything else that could log actions on target
- Not identifying malware such as:
- Non-standard scripts running
- Actual malware to include rootkits and keyloggers
- Not identifying logged in privileged users such as:
- root
- administrator
- any user logged into the console directly
- NOTE: You will ignore other students' activities.
- Not following information provided by instructors and/or evaluators
- Insecure Operating Practices
- Actions which compromise the operation
- Actions that may potentially compromise your activity on target
- Microwaving fish (please don't)
Op Station
Immediate Failure:
- Not following before and after operation steps
- Script all windows used for the op, excluding windows used for your opnotes and NSDB file
- Verify IPs prior to op
- Ensuring all files are included in the tarball at the end of the op
- Verifying tarball made it to correct post-processing directory
Point deductions:
- Missing start time, end time, time of each connection to each target, timestamping mando commands in opnotes (-1 per instance)
- Missing full malware, security product, abnormal logging reports in NSDB File (-2 per report)
- Missing logged in privileged user information in the MISREP (-2 per instance)
Reporting
Immediate Failure:
- Not adhering to reporting instructions
- Students must follow the entire reporting template listed below
- Failure to follow any mandatory reporting instructions to SWO
- Failure to follow any mandatory reporting instructions to MC
Point deductions:
- Reporting incorrect information to the MC (up to -4) - Can earn points back if corrected
- Reporting incorrect information to the SWO (-1)
- Not reporting Survey completion to Analyst (-1 per instance)
- Not reporting target's MAC address to Analyst upon connection (-1 per instance)
Targets
Immediate Failure:
- Not running all of your vetting commands on every target
- Leaving files on disk behind
- Place device in unusable state - shutdown / reboot, etc.
- Collecting, redirecting, or conducting the Analyst Survey before 'clearing' the target
- This means reporting any risk (i.e. Security products, abnormal logging, malware, or privledged users)
- Not utilizing correct credentials provided in the mission plan / by the analyst (not mistype)
- Violating specific instructions for a device in the mission plan (ex: plan says don't access the device on a specific port, or don't run a particular survey command due to logging)
- Not using both the -o StrictHostKeyChecking=no and -o UserKnownHostsFile=/dev/null options on SSH connections.
- Not reaching target 2 within 3 hours of your evaluation
- Accepting instructor assistance in order to access a target you are unable to reach on your own
Point deductions:
- Not accessing a target on the mission plan (-2)
- Not completing a target action after accessing device, not to include a T10 action (-2 per instance)
- Losing connection due to Operator action (-2)
- Mistyping targets credentials (-2)
- Authenticating more than once to a target (-2 per instance)
- Failure to report connection or disconnection to a device (-2 per instance)
- Maintaining simultaneous connections to targets that use the same pivot (-2 per connection after the first)
Mission
Immediate Failure:
- Accessing devices not on the mission plan without prior approval
- This includes IPs to devices that may or may not exist
- Accessing devices out of order of the mission plan without prior approval
- Not delivering the desired T10 effect
- Not verifying T10 effect with MC before delivery
- Accessing target network before approved operation start time
- Still in the target network after the completion time.
- Failure to follow any guidance on the 'Daily Reads' page
Point deductions:
- Scanning Operations:
- Missing Target IP (-1 perinstance)
- Missing Target OS (-0.5 per instance)
- Missing Target's ssh port(s) (-0.5 per instance)
ENVIRONMENT PREP
Before the Operation
Below are the requirements of the Operator before conducting an operation. Failure to do so may result in immediate failure.
- Review mission plan
- Power on OpStation
- Create STUDENT DIRECTORY: /<lastname>_<dd-mm-yy>_<op#>
- cd into STUDENT DIRECTORY
- Create an opnotes file with: vim notes_<dd-mm-yy>
- Create a NSDB file with: vim NSDB_<dd-mm-yy>
- Script all target terminal windows with: script -af termscreen.$$
- Do NOT script your 'Op Notes' or 'NSDB' terminal windows.
- Conduct pre-brief/IP verification with MC
- Inform SWO of mission start
Reports
Mandatory Reporting Instructions
Students must ensure communication with their Operational Team. Any of the below situations must be reported to the proper Team member. Any instruction marked with an "AI" will require the operator to Await Instructions, after reporting, before performing mission objectives (collection, deliver effects, etc) OR moving to the next identified target.
Students will communicate with SWO/MC/Analyst on the identified medium. Personnel assigned to these roles will not provide answers to critical tasks, command line syntax, or assistance with technical issues.
SWO
- Mission Start
- Mission End
MC
- Pre-Brief: Verify all IP addresses on mission plan before beginning operation AI
- All connections to each target
- All disconnections from each target
- Collecting a file that exceeds 10MB in size AI
Total downloads should not exceed 100MB per Operation
- Logged on Privileged (root;admin) Users AI
- Unknown binaries/processes/files/jobs AI
- Removing anything from a target device AI
- Placing any file on target AI
- Adding an IP to the mission plan AI
- Encountering an unexpected operating system
- Any form of abnormal/irregular/remote logging AI
- Changing anything on a target device AI
- Verification of T10 effect immediately before emplacing it AI
- Taking any action not identified in the mission plan AI
- Provide details for MISREP after operation
- MISREP Template is provided at the bottom of this document
- MUST include 1 sentence per target, as well as logged in privileged user information
Analyst
- Survey completion
- Target's MAC address upon connection
Reporting Security Product Guidelines
Students will follow the below guidelines when reporting security products to the MC. All reports will include the Target number and the IP Address. Students will report directly to the MC with items 1 and 2 below (having all 7 will make things move along faster, MC may require more info depending on the Security Product). If you are reporting a security product on a *nix machine, replace registry key with /etc configuration location and/or install directory location. All of the below must be in NSDB File.
- Name and version of the product
- Primary registry key
- Installation folder
- Directory location of associated logs
- Timestamp of all associated log files
- Cloud based?; yes or no
- Can we read the logs?; yes or no
- If Yes, put the most recent 5 lines of logs in your NSDB File
- If No, why?
Reporting Security Product Template
*****Security Product Report*****
Target: <T# and IP >
Name - <>
Version - <>
Primary registry key - <>
*****End of Report*****
Reporting Malware Guidelines
Students will follow the below guidelines when reporting suspected malware to the MC. All reports will include the Target number and the IP Address. Students will report directly to the MC with items 1, 2, 3, 4 and 9 below (having all 9 will make things move along faster, MC may require more info depending on the malware). All of the below must be in NSDB File.
- Provide process name/options, PID, Parent ID, user, and hash
- Provide file type of malware binary and supporting files
- Provide any associated logs generated by malware
- Provide location and lines of any persistence mechanisms
- Provide full path of malware files or support files
- Provide any network connections opened/established by malware
- Provide any identifiable text
- Provide any/all modules loaded by malware
- Provide brief description of malware purpose/actions and capabilities
Reporting Malware Template
*****Malware Report*****
Target: <T# and IP >
Name - <>
Hash - <>
PID - <>
PPID - <>
User - <>
File type - <>
Supporting files - <>
Associated Logs - <>
Persistence - <>
Description - <>
*****End of Report*****
Reporting Abnormal Logging Guidelines
Students will follow the below guidelines when reporting abnormal, irregular or remote logging to the MC. All reports will include the Target number and the IP Address. Students will report directly to the MC with all items below. All of the below must also be in the NSDB File.
- Provide process name/options, PID, Parent ID, user
- Provide location of configuration file and it's abnormal or irregular contents
- Provide hostname or IP of where logs are being sent
- Provide any network connections opened/established by abnormal logging
- Provide brief description of the abnormal, irregular or remote logging
Reporting Abnormal Logging Template
*****Abnormal Logging Report*****
Target: <T# and IP >
Name - <>
PID - <>
PPID - <>
User - <>
Location of config file - <>
Remote hostname or IP - <>
Network connections - <>
Description - <>
*****End of Report*****
Commands
Vetting Commands
During every operation, operators will be required to vet every device they connect to and conduct a minimal OPSEC review before disconnecting from a device. Not running one of the commands (or their equivalent), detailed below, will result in an automatic failure of the operation. Students will not utilize scripts to automatically run all of these commands (or redirect a script through their secure tunnel). Command options can be added to, but not subtracted from each command.
Use of unauthorized scripts is prohibited and will result in automatic failure of the operation.
Windows
Upon Connection:
- date /t
- time /t
- tasklist /V
- auditpol /get /category:*
- ipconfig /all
- netstat /anob
- netsh advfirewall show allprofiles
- net share
- reg query hklm\software\microsoft\windows\currentversion\run
- reg query hklm\software\microsoft\windows\currentversion\runonce
- reg query hklm\software
- at
- schtasks /query /v
- dir /o:d /t:w c:\
- dir /o:d /t:w c:\windows\temp
- dir /o:d /t:w c:\windows\
- dir /o:d /t:w c:\windows\system32
- dir /o:d /t:w c:\windows\system32\winevt\logs
- dir /o:d /t:w "%appdata%\microsoft\windows\start menu\programs\startup"
- wevtutil qe security /c:25 /rd:true /f:text (whatever has updated from previous dir)
Before Disconnect
- dir /o:d /t:w c:\windows\temp
- dir /o:d /t:w c:\windows\system32\winevt\logs
- wevtutil qe security /c:25 /rd:true /f:text (whatever has updated from previous dir)
- netstat /anob
- tasklist
Linux
Upon Connection:
- ls -latr /
- ls -latr /tmp
- ls -latr .
- ls -latr ..
- ls -latr /root
- ps -elf
- ifconfig
- netstat -auntp
- w
- ls -latr /var/spool/cron
- tail -n 1000 <files in /var/spool/cron/>
- date; date -u
- uname -a
- df
- ls -latr /var/*acc*
- ls -latr /var/*log*/
- ls -latr /var/log/*
- cat out relevant files (grep for your logged in user account)
- ls -la /etc/*syslog* read all the config files
- for user in $(cut -f1 -d: /etc/passwd); do echo "###### $user crontab is:"; cat /var/spool/cron/{crontabs/$user,$user} 2>/dev/null; done
- cat /etc/crontab
- ls -la /etc/cron.*
- As needed, examine the files/scripts shown in the directory listing of the cron.* directories
- find / \( -path /proc -prune -o -path /sys -prune \) -o -mmin -<duration since initial connection> -type f -print0 | xargs -0 ls -latr (NOTE there is a "-" a.k.a minus symbol preceding the "<duration since initial connection">
- sestatus OR getenforce
- cat /root/.bash_history
- cat ~/.bash_history
Before Disconnect:
- ls -latr /tmp
- ps -elf
- netstat -lptn
- ls -latr /var/log
- w
- find / \( -path /proc -prune -o -path /sys -prune \) -o -mmin -<yourminutesontarget> -type f -print0 | xargs -0 ls -latr
Unexpected OS (Not Windows or *Nix)
Research the below commands and confirm with analyst before executing
- Research how to identify IP address
- Research how to identify Operating System
- Research how to identify routes
- Research how to identify network connections
- Research how to identify updated logs
- Research how to identify user presence
- Research how to identify uptime
- Research how to identify running processespriv
- Research how to identify common storage locations and what they contain
Analyst Survey Commands
Some operations will call for the student to conduct an analyst-survey on a device. Students will not utilize scripts to automatically run these commands (or redirect a script through their secure tunnel). Below are the list of commands required during an analyst-survey for operations. Command options can be added to, but not subtracted from each command. Note that survey commands may also be useful in finding more information about suspected malware.
Students will copy the commands and output into a seperate file in their STUDENT DIRECTORY named "Survey_<IP_Address>".
Windows
- systeminfo
- net user
- net localgroup
- net session
- net start
- type %systemroot%\system32\drivers\etc\hosts
- arp -a
- route print
- driverquery /v
- wmic baseboard get Manufacturer, Model, PRoduct, SerialNumber, Version
- wmic cpu get deviceID, Addresswidth, MaxClockSpeed, Name, Manufacturer
- wmic logicaldisk get name, freespace, systemname, filesystem, size, volumeserialnumber
- wmic path Win32_VideoController get caption, CurrentHorizontalResolution, CurrentVerticalResolution, Description, DriverVersion, AdapterRAM /format:list
- wmic printer list full
- wmic path win32_pnpentity where "ConfigManagerErrorCode<>0" get Name, PNPDeviceID
- wmic qfe list full
- wmic service list full
- wmic product get Caption, InstallDate, Vendor
- wmic useraccount where "LocalAccount='TRUE'" get Caption, Disabled, Domain, Lockout, PasswordExpires, SID, Status
- tree c:\
Linux
- mount
- lsmod
- uname -a
- ls -latr /etc/*release*
- cat /etc/*release*
- cat /proc/cpuinfo
- services --status-all || systemctl status --no-pager (depending on systemd vs not systemd)
- cat /proc/meminfo
- cat /etc/shadow
- cat /etc/passwd
- lspci -vv
- arp -a
- lsusb
- lsblk
- fdisk -l
- free -m
- dmidecode -t bios
- ls -alR / (make sure scrollback limit is set to MAX on terminal)
Notes
Mandatory Note Taking
Students are required to keep a log of actions taken inside of the opnotes file. These notes are required to include:
Op Notes
- Mission start time
- Mission end time
- Time of each connection and disconnection to each target
- Start and end timestamps of "Upon Connection" and "Before Disconnect" vetting command sections
- Full output of vetting commands is not required
NSDB Notes
- Students are required to keep a log of all non standards that are encountered throughout an operation inside of the NSDB File. These notes are required to include:
- Timestamp of Non Standard discovery
- Full malware, security product, and abnormal logging reports
- Include an operator recommendation for every nonstandard report (what you think we should do with that target/mission)
Survey Notes
- Start and end timestamps of "Analyst Survey Commands"
- Students will create a seperate file for every device they survey with the full output of the survey commands. Naming convention will be "Survey_<IP_Address>".
Other Required Submissions
After an Operation
Below are the requirements of the Operator after completing or failing to complete an operation.
- Mission stop reported to SWO
- All files collected, edited, used by student must be located in STUDENT DIRECTORY
- MISREP reported to MC
- See below for MISREP Template
- cd out of the STUDENT DIRECTORY: cd ..
- Zip everything up: tar -cvf <studentdir>.tar <studentdir>
- Push tar to server: scp <studentdir>.tar student##@10.50.25.176:~
- Password: password##
MISREP Template
Operator: <your name>
Operation: <name of operation>
MC: <name of MC>
Analyst: <name of analyst>
Description: <two-three sentence overall description of operation followed by a minimum of one sentence per target.>
EXAMPLE:
Operator: SSG(P) Ryan Jay McGuinn
Operation: DryRun1
MC: Sergeant First Class Chandler II
Analyst: SFC Jonathan Cortez
Description: Goal of operation was to collect email from EMAIL3. Mission was overall successful. Operator redirected through EXT_RTR to ADMIN1 to EMAIL3. Admin was logged into T2 running a security product. ClamAV was found on EMAIL3, MC provided guidance and email was collected.
Home Academic Integrity Daily Read NSDB
© H@x0r Publishing, 2009