OSCP ADSet v5: svc_mssql, u.gregory & MSSQL Attack Path

The OSCP ADSet v5 svc_mssql u.gregory scenario is a useful example of how Active Directory identities, MSSQL, service accounts, credential discovery, and Windows privilege escalation can connect into a single attack path.

The important lesson is not memorizing a sequence of commands. Instead, focus on the relationship between u.gregory, svc_mssql, SQL Server, the underlying Windows host, and the wider Active Directory environment.

A simple way to visualize the methodology is:

u.gregory → Credential Discovery → svc_mssql → MSSQL → Windows Host → Privilege Escalation → AD Re-enumeration

The exact path can vary between lab environments, but this relationship-driven mindset is what makes ADSet practice valuable for OSCP+ preparation.

Understanding OSCP ADSet v5

Two identities immediately stand out in this scenario:

u.gregory — a domain user that may provide authenticated visibility or access to resources.
svc_mssql — a service account associated with Microsoft SQL Server.

Neither username proves privilege by itself.

Instead, determine what each identity can actually access.

For u.gregory, investigate authenticated SMB access, shares, files, groups, scripts, scheduled tasks, application configuration, and other resources that become visible after authentication.

For svc_mssql, focus on MSSQL authentication, SPNs, server roles, database permissions, linked servers, impersonation rights, and the Windows privileges associated with the SQL Server service.

Maintain a simple relationship map:

Finding	Question
`u.gregory`	What resources become visible after authentication?
`svc_mssql`	Where is this service account used?
MSSQL	Who can authenticate and with what permissions?
SPN	Is the account tied to a Kerberos-enabled service?
Credential	Where else is it valid?
Windows access	What local privileges are available?

This is more useful than running every tool immediately after discovering a username.

Enumeration: Connect u.gregory to svc_mssql

The first objective in the OSCP ADSet v5 svc_mssql u.gregory scenario is understanding how the identities and services relate.

Useful enumeration areas include:

SMB & Files: Look for readable shares, scripts, configuration files, backups, application directories, and documents containing infrastructure information.

Active Directory: Map users, groups, computers, service accounts, SPNs, and relevant permissions.

MSSQL: Determine whether SQL Server is reachable and which identities can authenticate.

Kerberos: Identify whether svc_mssql has an SPN and how the service participates in domain authentication.

Credential Sources: Pay attention to application configuration, deployment scripts, scheduled tasks, database connection strings, and stored credentials.

Whenever a credential appears, document it as:

Credential → Identity → Source → Valid Service → Privilege → Next Target

This prevents the assessment from becoming a collection of disconnected findings.

Preparing for OSCP+ AD Sets?

Practice the complete workflow instead of collecting isolated commands. Our OSCP+ resources include ADSet material, standalone scenarios, walkthroughs, and exam-focused preparation resources.

✓ Instant digital delivery · ✓ Free updates · ✓ Multiple OSCP+ ADSet resources

→ Get OSCP+ ADSet Exam Material

MSSQL as an Attack-Path Pivot

MSSQL is particularly important in this scenario because database access may expose more than stored data.

After obtaining authorized MSSQL access, determine:

current SQL identity;
server roles;
database permissions;
impersonation possibilities;
linked servers;
accessible databases;
whether operating-system interaction is permitted.

xp_cmdshell deserves attention because, when enabled and available to the current SQL security context, it can allow operating-system commands to be executed through SQL Server.

But do not assume it is available.

The correct methodology is:

MSSQL Access → SQL Privileges → Server Configuration → OS Interaction → Windows Context

Likewise, linked servers should be mapped rather than blindly used.

A linked SQL Server may reveal another authentication context or system relationship that changes the attack surface.

The value of MSSQL in an AD set is therefore not simply:

“I found a database.”

It is:

“What does this database relationship give me access to next?”

From svc_mssql to Windows Privilege Escalation

If SQL Server provides operating-system execution, identify the Windows security context before attempting anything else.

Check the effective user and privileges, then investigate:

service-account privileges;
local groups;
service configurations;
scheduled tasks;
accessible credentials;
writable paths;
installed applications;
network interfaces;
internal routes.

One privilege that may become relevant in Windows service contexts is SeImpersonatePrivilege.

Its presence does not automatically provide SYSTEM access, but it tells you that token-related privilege-escalation paths may deserve investigation in an authorized lab.

Likewise, service misconfigurations, credential reuse, scheduled tasks, and overly permissive filesystem locations can create alternative paths.

Avoid assuming there is only one intended escalation technique.

Think:

Current Identity → Available Privilege → Misconfiguration → Higher Context

After changing privilege level, enumerate again.

New privileges may expose credentials, files, services, or network relationships that were previously inaccessible.

Kerberos, SPNs and svc_mssql

Because svc_mssql is a service-style account, check whether it has a Service Principal Name.

An SPN links a domain account with a network service and can make Kerberos authentication particularly relevant.

In an authorized AD lab, investigate:

Account → SPN → Service → Kerberos Relationship → Account Security

If the environment exposes a service-ticket attack path, the important lesson is not simply obtaining material for offline analysis.

The real question is what happens after the service account is compromised.

Does svc_mssql have:

SQL Server privileges?
remote authentication rights?
access to another host?
membership in an interesting group?
access to sensitive files?
control over another service?

This is where Active Directory enumeration and MSSQL enumeration meet.

A credential is valuable because of the access behind it.

Re-Enumerate Active Directory After Every Discovery

The OSCP ADSet v5 svc_mssql u.gregory scenario becomes much easier to reason about when enumeration is treated as a loop:

Enumerate → Authenticate → Gain Access → Re-enumerate → Correlate → Repeat

For example:

u.gregory access

→ inspect authenticated resources

→ identify information related to svc_mssql

→ investigate MSSQL

→ obtain a different execution context

→ enumerate Windows privileges

→ recover additional domain information

→ re-enumerate Active Directory

The important part is that every new identity changes what you can see.

If u.gregory provides authenticated SMB access, revisit shares.

If svc_mssql becomes available, revisit MSSQL and domain relationships.

If you gain local administrative or SYSTEM-level access, revisit stored credentials and network configuration.

If another domain account appears, repeat authenticated domain enumeration.

This is one of the most transferable habits you can develop for OSCP AD sets.

Common ADSet v5 Mistakes

Ignoring MSSQL because it looks like “just a database.” SQL Server can connect application, Windows, and Active Directory security contexts.

Assuming svc_mssql is automatically privileged. The username is a clue. Verify the account’s actual rights.

Testing credentials randomly. Build a credential matrix and test against logically relevant services.

Ignoring SPNs. Service accounts can expose useful Kerberos relationships.

Stopping after command execution. A shell is a new enumeration point, not the end of the assessment.

Failing to inspect Windows privileges. Always understand the security context of newly obtained execution.

Not re-enumerating after u.gregory or svc_mssql access. A new identity can reveal resources that were invisible earlier.

Treating AD machines independently. The purpose of an AD set is to understand how access to one system affects the next.

A Compact OSCP ADSet v5 Workflow

Use this workflow instead of trying random commands:

1. Enumerate the environment. Map hosts, SMB, MSSQL, domain information, users, services, and accessible resources.

2. Understand u.gregory. Determine groups, shares, files, authentication scope, and relationships.

3. Map svc_mssql. Identify SPNs, SQL Server relationships, group membership, and authentication possibilities.

4. Enumerate MSSQL. Review roles, databases, impersonation, linked servers, and available server functionality.

5. Identify the Windows context. If OS execution becomes available, determine the account and its privileges.

6. Enumerate privilege escalation. Investigate service configuration, tokens, tasks, credentials, filesystem permissions, and other evidence-driven paths.

7. Return to Active Directory. Use each new identity or privilege level to repeat domain enumeration.

8. Document the chain. Capture how u.gregory, svc_mssql, MSSQL, Windows access, and subsequent AD findings connect.

That last step matters. OffSec’s current authoritative objectives assign 33% to documenting findings, while Active Directory accounts for 26%.

Want More OSCP ADSet Practice?

Compare multiple ADSet scenarios instead of memorizing a single path. This helps build the enumeration and attack-path reasoning needed when usernames, hosts, and services change.

→ Explore OSCP+ ADSet & Exam Resources

Why ADSet v5 Matters for OSCP+ Preparation

The value of the OSCP ADSet v5 svc_mssql u.gregory scenario is the relationship between several security layers:

Active Directory

↓

Domain User

↓

Service Account

↓

MSSQL

↓

Windows Security Context

↓

Privilege Escalation

↓

Lateral Movement / Domain Progression

That structure closely matches the skills OffSec currently expects candidates to understand. The official OSCP+ objectives explicitly include domain enumeration, account enumeration, lateral movement, attacks against AD authentication, and achieving high-privileged domain access.

The current OSCP+ exam also includes a three-machine Active Directory set worth 40 points, and candidates are provided an initial username and password to simulate an assumed-breach scenario.

For current exam requirements and objectives, use the official OffSec OSCP+ Exam Guide as the authoritative reference.

OSCP ADSet v5 FAQ

What is svc_mssql in OSCP ADSet v5?

svc_mssql represents a service-style domain identity associated with MSSQL. Its importance depends on its SPNs, SQL Server permissions, Windows privileges, group membership, and relationships with other systems.

Why is u.gregory important?

u.gregory represents a domain-user context that may provide authenticated access to shares, files, domain information, or other resources. Its value comes from what becomes visible after authentication.

Why is MSSQL important in an Active Directory set?

MSSQL can connect database access with Windows and domain identities. Depending on configuration and permissions, it may expose additional credentials, linked systems, impersonation relationships, or operating-system interaction.

Should I check svc_mssql for an SPN?

Yes. Service accounts commonly interact with Kerberos through SPNs. Identify the actual configuration and determine what security implications exist rather than assuming the account is vulnerable.

What is the main lesson from this ADSet?

Follow relationships. u.gregory, svc_mssql, MSSQL, Windows privileges, and Active Directory should be treated as parts of one environment rather than independent targets.

Final Thoughts

The OSCP ADSet v5 svc_mssql u.gregory scenario demonstrates a central OSCP+ principle: small discoveries become valuable when they are connected.

u.gregory may provide the first useful identity.

That identity may expose information related to svc_mssql.

svc_mssql may connect to MSSQL.

MSSQL may expose a new Windows security context.

That host may reveal another credential, privilege, route, or domain relationship.

So instead of asking:

“Which exploit do I run next?”

ask:

“What did my latest access reveal that I could not see before?”

That mindset turns enumeration into an attack path.

Ready to Practice OSCP+ AD Sets?

Get access to our OSCP+ preparation collection with ADSet v5 material, additional Active Directory sets, standalone scenarios, walkthrough resources, and exam-focused preparation material.

✓ Instant digital delivery
✓ Free updates included
✓ Multiple ADSet scenarios
✓ Practical OSCP+ preparation resources