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).

Any IP in the 10.50.0.0/16 is considered to be a Public IP for this course.

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:

Op Station

        Immediate Failure:

Reporting

        Immediate Failure:

Targets

        Immediate Failure:

Mission

        Immediate Failure:

        Point deductions:


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.


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

MC

Analyst


Reporting Security Product Guidelines

Security products are well-defined software programs that are either deault to the operating system or are installed by the computer owner for the strict purpose of finding/blocking/removing malicious (as seen by the computer administrator) software.

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.

  1. Name and version of the product
  2. Primary registry key
  3. Installation folder
  4. Directory location of associated logs
  5. Timestamp of all associated log files
  6. Cloud based?; yes or no
  7. Can we read the logs?; yes or no

Reporting Security Product Template

*****Security Product Report*****

Target: <T# and IP >

Name - <>

Version - <>

Primary registry key - <>

*****End of Report*****


Reporting Malware Guidelines

Malware is defined as any software that is installed on a computer unknown to the system administrator and weakens the overall security posture of the system.

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.

  1. Provide process name/options, PID, Parent ID, user, and hash
  2. Provide file type of malware binary and supporting files
  3. Provide any associated logs generated by malware
  4. Provide location and lines of any persistence mechanisms
  5. Provide full path of malware files or support files
  6. Provide any network connections opened/established by malware
  7. Provide any identifiable text
  8. Provide any/all modules loaded by malware
  9. 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

Abnormal logging is defined as any logging that occurs outside of the operating system's default values and includes remote logging, network logging, process logging, et cetera.

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.

  1. Provide process name/options, PID, Parent ID, user
  2. Provide location of configuration file and it's abnormal or irregular contents
  3. Provide hostname or IP of where logs are being sent
  4. Provide any network connections opened/established by abnormal logging
  5. 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:

Before Disconnect

Linux

Upon Connection:

Before Disconnect:

Unexpected OS (Not Windows or *Nix)

Research the below commands and confirm with analyst before executing


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

Linux


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

NSDB Notes

Survey Notes


Other Required Submissions

After an Operation

Below are the requirements of the Operator after completing or failing to complete an operation.

DEBRIEF 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: SFC 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 (T1) to ADMIN1 (T2) to EMAIL3 (T3). There were no issues found on EXT_RTR (T1) that were not already expected. Admin was logged into T2 running a security product that was deemed to be of no impat to the current or future mission. Configuration files were collected as a precaution. ClamAV was found on EMAIL3 (T3); MC provided guidance and email was collected according to SOP. Exiting went smoothly.



Home   Academic Integrity   Daily Read   NSDB

© H@x0r Publishing, 2009