Meridian Corp

The engagement

You have been engaged by Meridian Corp to perform an authorized penetration test of their network. This page is the client brief: who they are, what they want to know, what you are permitted to touch, and how the work is judged.

Nothing on this page tells you what you will find. It tells you where you are permitted to look. The hosts, the services, the accounts, and the weaknesses in Meridian’s estate are yours to discover, and discovering them is what the milestones grade.

The client

Meridian Corp is a regional engineering and facilities-services firm with about six hundred staff — a head office, four field offices, and crews who work from customer sites. It designs, installs, and maintains building systems for hospitals, school districts, and municipal clients, most of them under multi-year contracts.

Meridian runs its own IT with a small internal team. It publishes a handful of services to the internet for customers and applicants, keeps staff accounts and shared office services on an internal Windows network, and holds the working record of the business — contracts, drawings, schedules, payroll, and customer site details — on internal servers.

Two things brought them to this engagement. Their cyber-insurance renewal now requires an independent penetration test each year, and a firm in the same sector spent eleven days rebuilding after a ransomware incident last quarter. Meridian’s board asked a question the IT team could not answer from the inside, and this test exists to answer it.

What Meridian is asking

If someone with no access, no credentials, and no help from an insider gets a foothold on something we publish, how far into this company can they get, what could they take or break once they are there, and would we have seen any of it?

Your report answers that in three parts:

Reach: how far an attacker starting outside the estate can get, and what stops them — or fails to.
Consequence: what that access means for the business in the client’s own terms, not in tool output.
Visibility: what a defender watching Meridian’s own logs would have seen while you did it.

Flags are a convenience, not the objective. Submitting one proves you reached a location; it is not a finding, and no rubric criterion is satisfied by a score. Everything you are graded on is in the document you hand the client.

Your role

You are an independent penetration tester working this engagement alone. Your instructor acts for the client: they issue your assignment sheet, they are the authorizing official on your authorization form, and they are the contact who can stop the test.

Your authority to touch anything at all comes from that signed authorization, and it begins when the form is countersigned — not when you can reach the network. Everything you hand in is a client deliverable and is read as one.

You test alone, and your work is your own. The network is identical for every student in the cohort, so an address proves nothing about who produced a result; your proof token and your issued account are what tie evidence to you.

What you are given

The authorized segments: Three network segments, by CIDR. Every address inside them is in scope except the exclusions below.
A tester workstation: Your own Kali box. It is the single source address the client agreed to, which is what makes your traffic attributable and everyone else’s not your problem.
A proof token: Yours alone. It is how a proof artifact shows the client that you reached the target rather than that somebody did.
One ordinary user account: A real, low-privilege account on a client application, issued to you and to no one else so your activity appears in that application’s own access log under your name. Use it wherever an activity calls for authenticating as an ordinary user.
An engagement window and a stop signal: The dates you may test in, and the contact who can halt the test. Both belong in your Rules of Engagement.

What you are not given

A host inventory, a count of live systems, or a network diagram. Building one is M1.
A list of services, versions, or open ports.
Any credential beyond the single user account above — no administrator account, no service account, no key.
A list of known weaknesses, a prior report, or the client’s own scan results.
Any indication of where evidence or flags are to be found.

Scope

Your assignment sheet is authoritative and your own Rules of Engagement are what you are held to. Both restate the same set the lab page shows you in its banner:

In scope

DMZ — 10.10.10.0/24
Server LAN — 10.10.20.0/24
User LAN — 10.10.30.0/24

Every address inside those three segments is in scope, with the exceptions below. You are not told which of them are live — that is M1’s work.

Out of scope

Any backup servers found on the networks are out of scope. You may scan them, but interacting with them will cost you points.

The management network 10.10.99.0/24, including its jump host, and the 10.10.98.0/26 Cloud Run egress subnet.

Do not attack any other student workstation. Student Kali boxes are out of scope.

None of these is blocked by a firewall. They answer traffic and they will appear in a broad sweep. Your Rules of Engagement are the only thing keeping them out of your evidence, which is the point of writing them.

Ground rules

Test from your assigned workstation and nowhere else: The client agreed to traffic from one source address. Anything originating from your laptop, a cloud shell, or a classmate’s box is outside the authorization you were granted — and unattributable to you if it is questioned later.
No denial of service, and no destructive change: This is a live estate doing real work; the client did not agree to an outage. That includes an outage caused as a side effect of an aggressive scan, and it includes deleting data, disabling a service you did not need to disable, or clearing a log to hide your own activity.
Pace your scans: Published limits are in the student guide, and M1 grades your justification of them. The practical reason is nearer than professionalism: a saturated host answers nothing, and a host that answers nothing lands in your evidence as a host that does not exist.
Observing an excluded system is not a violation; acting on it is: An out-of-scope address that turns up in a DNS answer, an ARP cache, a route, or a log line is a finding you may record. Sending it a packet, authenticating to it, or citing it as a target is a violation.
Disclose an accident; do not hide it: If you touch something out of scope, stop, record what happened and when in your evidence log, and say so in the milestone you were working on. Disclosure is not penalized. A violation you did not disclose is penalized twice.
The client’s data stays in the lab: Credentials, hashes, and business documents you recover are Meridian’s, not yours. Your Rules of Engagement state how you will store, transmit, redact, and dispose of them, and you are held to what you wrote.

The environment you are working in

These are properties of the engagement, not hints about the estate. Each one is here because not knowing it leads to a wrong conclusion rather than a slow one.

The estate is segmented, and you start outside all of it: What you can reach depends on where you are standing, and it changes as the engagement goes on. A segment you cannot reach yet is in scope but not yet accessible — never treat it as out of scope, and never record it as empty because a scan from the wrong place found nothing.
The client’s systems have no route to the internet: Nothing inside the estate can download anything. A payload that fetches its next stage from a public host will fail here for reasons that have nothing to do with whether it would work in the real world. Serve what you need from your own workstation.
A compromised host can only call back to a short list of ports: The client’s egress policy allows a handful of ports back to your workstation subnet and denies the rest. A callback that never arrives is far more often the port than the payload; the list is in the student guide.
Real people appear to be working in this estate: Background activity is generated continuously: sessions open and close, files are touched, mail moves. It is not yours, it is not staged for you, and it will be interleaved with your own traffic in every log you read. Attributing an event to yourself is part of M4, not a given.
Everything you do is recorded somewhere: Host and authentication logging is on and configured to capture command lines, logons, and credential use. M4 grades how honestly you read that record — including the actions you can find no trace of, which are a legitimate result when you say what you looked at.
The whole cohort shares one copy of the estate: There is no private instance. A host you crash, a file you overwrite, and a service you stop belong to everyone else in the cohort at the same time. Leave the estate the way a client would want it left, and use the dashboard’s rebuild control rather than leaving a host broken.
Evidence is perishable; capture it when you have it: A host may be rebuilt, the range powers off when the last person leaves, and flag values are reissued between milestones. Take the screenshot and save the transcript at the moment of the result, not the night the milestone is due.

The engagement, milestone by milestone

The six milestones, their weight in the project grade, what each delivers, and the client question each answers.

M0 — Scoping & Rules of Engagement10% of the grade

You deliver: Scope document, Rules of Engagement, signed authorization, methodology plan, ethics statement

It answers: What are you authorized to do, and how will you hold yourself to it?

M1 — Reconnaissance & Scanning15% of the grade

You deliver: Host and service inventory, network map, attack-surface analysis, evidence log

It answers: What does the client actually have exposed, and where is it?

M2 — Enumeration & Vulnerability Analysis15% of the grade

You deliver: Vulnerability register ranked by analyzed risk, with CVSS v3.1 vectors

It answers: Which of it is weak, how sure are you, and which weakness matters most?

M3 — Exploitation & Gaining Access20% of the grade

You deliver: Numbered, reproducible procedures, proof artifacts carrying your token, impact analysis, failed attempts

It answers: Can that weakness actually be used, by whom, and to what effect?

M4 — Post-Exploitation15% of the grade

You deliver: Escalation and lateral-movement evidence, persistence with a cleanup procedure, detection analysis

It answers: How far does that access reach, and would anyone have noticed you?

M5 — Final Report & Debrief25% of the grade

You deliver: Client report, two-part debrief, one-page self-assessment

It answers: What should the client fix first, and why that first?

M0 is a gate, not a warm-up: your Google account is granted access to your workstation when your instructor approves it, and until then the lab controls are visible but disabled. Nothing else in the engagement can start.

Methodology

Work to a recognized methodology and say which one. M0 asks you to choose a framework, justify the choice, and map its phases onto the milestones yourself — a quarter of that milestone is that mapping, so it is not printed here. Any of these is accepted:

PTES — the Penetration Testing Execution Standard
NIST SP 800-115 — Technical Guide to Information Security Testing and Assessment
The CEH methodology

Naming a framework and then not following it is a named deduction. The framework you pick should be visible in how M1 through M4 are actually structured.

What good work looks like here

Write the evidence as you go. Every entry carries a UTC timestamp, the target host name and address, the exact command, and its full output. Evidence reconstructed from memory reads like it, and unsupported technical claims earn nothing.
Put your proof token in the same capture as the result it proves. An artifact showing a target address and no token proves that somebody reached the target, not that you did.
Say how you know. A version number, a user list, or a service name asserted without the output that produced it is graded as unsupported, however correct it happens to be.
Record what did not work. M3 gives credit for significant failed attempts with the reasoning; a clean narrative in which everything worked first time is neither believable nor how the work went.
Distinguish “not there” from “did not answer”. A host that reports down under load, a service that rate-limited you, and a segment you could not reach from where you were standing are three different results, and only one of them is a finding.
Translate every finding into the client’s business. You know what Meridian does and what it holds; “an attacker could read the contract and payroll records for every municipal client” is impact, and “critical severity” is not.
Keep to scope when it costs you something. Scope discipline is graded for the whole term, and the estate contains convincing material in places a careless sweep reaches.

Where the documents are

Your assignment sheet: Issued by your instructor, acting for the client. It is authoritative over every value on this page — your identity, your workstation, the exact scope, and the engagement window.
~/meridian-course/templates/: On your workstation: the scope document, Rules of Engagement, authorization form, evidence log, vulnerability register, report, detection analysis, cleanup notes, debrief outline, and self-assessment.
~/meridian-course/rubrics/: The rubric for every milestone, criterion by criterion with its weight. Read the rubric for a milestone before you start it, not after.
The student guide: How the range works: signing in, powering the lab on, connecting to your workstation, scan-rate guidance, callback ports, rebuilding a broken host, where the logs are, and what to check before concluding the range is broken.

This page is the framing. The operational detail — how to sign in, start the lab, reach your workstation, pace a scan, get a callback, rebuild a host you broke, and read the logs — is in the student guide, and it is the first thing to check when something looks wrong.