eSentinel Rules
Academic Edition



Competition Play

eSentinel is a timed competition event.  At the beginning of the competition, common resources are available for teams to scan, assess, and penetrate.  To claim ownership of a service, teams must plant their token, an assigned hexadecimal string, inside the banner of the service or inside specified files.  An automated scanner detects ownership changes and awards points for each service to the team whose token appears in the service banner or file.  At random intervals, an automated scoring engine checks the status and functionality of all critical services.  If a team has ownership of a functional critical service during a successful service check, that team is awarded points for owning and maintaining a critical service.  Teams accumulate points for each critical service they control and continue to accumulate points as long as they own and maintain those critical services.  Teams that fail to secure resources and services they have captured may have them taken away by rival teams.  Throughout the competition new resources are added to the common pool, forcing teams to choose between defending existing assets and going after new assets.  The team with the highest point total at the end of the competition wins.

 

1.    Team Composition

a.      Teams must consist of between two and four members.

b.      Once a competition has begun, team members may not be substituted or replaced.

c.      Each team will designate a Team Captain for the duration of the competition to act as the team liaison between the competition staff and the team before and during the competition.

 

2.     Eligibility

a.      Team members must be a registered student of the institution they are representing at the time of the competition.

b.      Team members may only compete on a single team per season.

c.      Team members must have less than two years of paid, professional experience in the fields of network assessments and penetration testing

 

3.     Team Coaches/Sponsors

a.      Coaches/sponsors may not assist or advise their team during any competition.

b.      Coaches/sponsors may not use provided VPN credentials or access the virtual environment during any competition.

c.      Coaches/sponsors must not interfere with any other competing team.

4.    Software

a.      Teams are allowed to use any open source, freeware, or trial ware products provided there is no fee for using or registering the product.

b.      No commercial software may be used during the competition unless the software costs no money to use or register and is freely available to any team should they choose to use it.

c.      Teams are free to develop and use their own scripts, tools, and utilities.

d.      Teams are free to use archives of patches, tools, scripts, utilities, web pages, and so on stored on team systems, removable media, or USB drives.

e.      Teams may install software on resources they have captured including patches, applications, firewalls, and so on provided there is no fee for using or registering the software being installed.

5.    Competition Conduct

a.      Teams are prohibited from conducting offensive operations against any White Team system including but not limited to scoring systems, display systems, scoreboards, and the core network.

b.      Teams are prohibited from conducting offensive operations against any other team's personal systems. Teams are encouraged to attack targets owned by other teams.

c.      Teams must compete without “outside assistance” from non-team members which includes team advisors and sponsors.  All private communications (calls, emails, chat, directed emails, forum postings, conversations, requests for assistance, etc) with non-team members including team sponsors that would help the team gain an unfair advantage are not allowed and are grounds for disqualification.

d.      Teams are allowed to use active response mechanisms such as TCP resets when responding to suspicious/malicious activity.  Any active mechanisms that interfere with the functionality of the scoring engine or manual scoring checks are exclusively the responsibility of the teams.  Any firewall rule, IDS, IPS, or defensive action that interferes with the functionality of the scoring engine or manual scoring checks are exclusively the responsibility of the teams.

e.      Team members must conduct themselves in a professional manner at all times.  Sexual harassment, inappropriate language, and inappropriate conduct can result in the disqualification of team members.  Competitors disqualified for harassment or inappropriate conduct will be banned from future competitions for a period of no less than 12 months.

f.      The use of viruses, worms, or any other self-propagating malware is prohibited and grounds for disqualification.

g.        Teams may not use network flooding or ARP spoofing attacks during the competition.

6.     Scoring

a.      Teams will receive points for each successful check on a service they own at the time the scoring check is run.

b.      Each service has an associated service level agreement.  When a service is in violation of the service level agreement, the entire system that service resides on will be reset to the starting configuration.  For example, if the SLA is 6 scoring checks and a service is scored as “down” for 6 consecutive checks, the system that service resides on will be reset to its original configuration.  Service level agreements will be published at the start of each competition.

c.       All identified critical services must be accessible to “the public” at all times.  Failure to maintain public access to critical services will result in the system being reset to its starting configuration.

7.     Password Changes

a.       The scoring engine does utilize user level accounts for some services. The scoring system does not use "administrator" or "root" accounts to check services.  Teams wanting to change the passwords on user level accounts (not root or administrator) may do so, but must supply the password changes to the judges in a text file.  The file must be formatted with “userid,password” with one account per line.  Example:

Bob,abc123

Sally,rflkj2

 

Gameplay

At the start of the event there will be a number of virtual machines running as targets for your team and other teams to probe and break into.  These are the “resources” you need to control.  Everyone will be trying to break into and control the same set of targets.  The services and operating system on each target varies so it could be a Windows 2003 server running DNS or a Solaris server running Apache and SSH.  Each target will have one or more critical services on it – these are the services that you need to keep operational when you take over a target.  The IP address and critical service(s) on that IP will be published on the competition portal so you won’t have to guess what/where they are.  p>

 

Once you’ve gained access to a target, you’ll need to show you have access by marking the critical service with your team’s unique token (which we will assign to your team the day of the event).  For an FTP service you’ll need to plant your team’s token inside the FTP banner – so it will say “Welcome to FTP ABC123” instead of “Welcome to FTP”.  For an HTTP service you’ll create a file called “ownership.html” in the top level web directory with your team’s token inside the file. If the ownership.html files exists, simply replace the string of 8 zeroes with your token.  Due to the nature of how different services operate, here’s how you’ll mark ownership for each critical service type (please note that not all of these services may appear at this competition):

 

  • HTTP and HTTPS:  You’ll need to create a file called “ownership.html”, put your team’s token in that file, and place that file on the top level of the web directory (same place you’d put index.html).
  • FTP:  You need to put your team’s token inside the FTP banner.  If the FTP service reads “Welcome to FTP” you need to modify it to read “Welcome to FTP ABC123” where ABC123 is your team’s unique token.
  • Windows File Share and SAMBA Shares:  You need to create a file called “ownership.txt”, put your team’s token in that file, and place that file on the top level of the file share.
  • NFS:  You need to create a file called “ownership.txt”, put your team’s token in that file, and place that file on the top level of the file share.
  • SSH:  You’ll need to create or modify the welcome banner of the SSH service so it includes your team’s unique token.
  • SMTP:  You’ll need to modify the greeting message the mail service displays when connections are made to it and place your team’s unique token inside the greeting message.
  • POP3:  You’ll need to modify the greeting message the POP3 service displays when connections are made to it and place your team’s unique token inside the greeting message.  You must allow plain text authentication on POP3 services.
  • Telnet:  You’ll need to create or modify the welcome banner of the Telnet service so it includes your team’s unique token.
  • DNS:  You have to create a reverse lookup entry that responds to DNS queries with an IP address of 1.1.1.1 and your team’s token in the name.  For example, if I do an nslookup of 1.1.1.1 using the DNS server you control it should respond with something like “Name: ABC123  Address: 1.1.1.1” where ABC123 is your team’s unique token.
  •  

    After you’ve marked a critical service and claimed it as your own, you have to keep it running and defend it against the other teams.  You may have to adjust the configuration of the service, patch the operating system, reset passwords, etc. to keep it safe but know that other teams will be trying to break into the target you’ve claimed and take your service from you.  Why?  Because you only score points if you have control of a critical service and that service is still working properly.

     

    We’ll be running a scoring engine that looks at each critical service at random intervals.  The critical service has to be running and functional – in other words the content has to match what was there at the beginning.  So an HTTP service still needs to display the original website, an FTP service still needs to serve up the files, a DNS service has to resolve queries, etc.  When you take ownership of a service, you can’t destroy the content that was there while you’re taking ownership and once you own it you can’t let an opposing team destroy the content of your service.  When the scoring engine checks a service, it will also determine who owns that service.  If your team owns that service and the service is still functioning, you’ll get points.  You get points every time the scoring engine checks one of the services you own if that service is still working properly.  The more targets and services you control – the more points you score.  High score at the end wins.

     

    © eSentinel 2018. All Rights Reserved.

    University of Texas San Antonio