The CPTS Trilocor Guide below focuses on one of the most important skills you need when working through a realistic penetration testing environment: understanding how seemingly unrelated hosts, users, services, and credentials can form a complete attack path.
The Trilocor Robotics environment is interesting because the challenge is not simply finding another vulnerable service. You need to understand the relationship between the trilocor.local Active Directory domain, development infrastructure, Gogs repositories, user accounts, service accounts, and systems such as prototype-beta.trilocor.local.
That distinction matters.
Finding a host is enumeration. Understanding why that host matters to the rest of the network is attack-path analysis.
This guide examines the Trilocor environment from that perspective while also highlighting techniques that are useful when preparing for the HTB Certified Penetration Testing Specialist (CPTS) certification.
What Is the CPTS Trilocor Environment?
Trilocor Robotics resembles the type of mixed infrastructure penetration testers regularly encounter during internal assessments.
Instead of presenting a single isolated target, the environment contains several pieces that need to be correlated:
- Active Directory infrastructure
- Standard domain users
- Administrative accounts
- Service accounts
- Internal web applications
- Development and QA systems
- Gogs repositories
- Prototype infrastructure
- Credentials and configuration data
- Potential lateral movement opportunities
This makes the environment especially useful for practicing attack-path thinking.
A hostname discovered during enumeration may initially appear insignificant. A repository may contain information that gives that hostname context. A username found inside the repository may then correspond to an Active Directory account.
Each discovery changes the value of the information you already have.
This is also consistent with the broader CPTS methodology: successful penetration testing depends on enumeration, exploitation, Active Directory assessment, pivoting, lateral movement, post-exploitation, and the ability to connect multiple weaknesses rather than treating each finding in isolation.
CPTS Trilocor Attack Surface at a Glance
Before attempting exploitation, create an inventory of everything discovered.
In the Trilocor environment, interesting entities include systems and accounts such as:
trilocor.local
gogs-qa0001.trilocor.local
prototype-beta.trilocor.local
rhinkle
dev_user1
svc_adconnect
fjenkins_adm
The important question is not immediately:
“Which one can I exploit?”
A better first question is:
“How are these assets related?”
That change in mindset prevents one of the most common penetration testing mistakes: attacking every exposed service individually without understanding the network around it.
Understanding the trilocor.local Active Directory Domain
The trilocor.local domain provides the identity layer connecting much of the environment.
Once Active Directory becomes visible, enumeration should move beyond simply collecting usernames.
You want to understand:
- Which accounts are normal users?
- Which accounts belong to developers?
- Which accounts appear administrative?
- Which accounts run services?
- Which machines are associated with those users?
- Which users can authenticate to which systems?
- Where might credentials be reused?
- What groups and permissions exist?
- Which accounts could provide lateral movement opportunities?
A list of usernames by itself has limited value.
The relationships between those usernames, hosts, groups, applications, and permissions are what eventually reveal an attack path.
Categorizing Trilocor Users Before Attacking Them CPTS Trilocor Guide
One useful technique in the CPTS Trilocor Guide methodology is to classify accounts as soon as they are discovered.
Consider several examples from the environment.
rhinkle
An account such as rhinkle initially looks like a standard user.
That does not make it unimportant.
Normal user accounts frequently become useful because they can provide:
- Domain authentication
- SMB access
- Internal application access
- Additional LDAP visibility
- Kerberos information
- Remote service access
- Access to files or shares unavailable anonymously
A low-privileged account should therefore be viewed as an enumeration upgrade, not simply as an account that lacks administrator privileges.
dev_user1
dev_user1 deserves a different classification.
The name strongly suggests a development-related account.
Development users are especially interesting when development infrastructure is also present because they may interact with:
- Git repositories
- CI/CD systems
- QA environments
- internal APIs
- staging applications
- prototype servers
- configuration files
That creates an obvious correlation point with the Gogs infrastructure discovered elsewhere in Trilocor.
fjenkins_adm
The _adm naming convention makes fjenkins_adm worthy of investigation as a potentially privileged account.
However, identifying a privileged-looking username does not mean you should immediately attack that account.
Instead ask:
- Where is this account used?
- Which systems does it administer?
- Is it referenced in scripts or repositories?
- Does another account have access to files created by it?
- Are credentials or authentication artifacts exposed elsewhere?
Often the path to an administrator account begins somewhere completely different.
Gogs Enumeration in the CPTS Trilocor Environment
One of the most interesting assets in the environment is:
gogs-qa0001.trilocor.local
Gogs is a self-hosted Git service. In penetration tests, source-control platforms deserve immediate attention because repositories frequently reveal much more about an environment than their developers intended.
Do not restrict Gogs enumeration to searching for passwords.
Look for:
- usernames
- internal hostnames
- database connection strings
- application configuration
- API endpoints
- API keys
- access tokens
- deployment scripts
- service account references
- environment variables
- backup files
- historical commits
- removed secrets
- internal network information
Repository history is particularly important.
A secret removed from the current version of a configuration file may still exist in an older commit.
The current source tree tells you what developers use now.
Git history can tell you what they used before.
Both can matter during a penetration test.
Why Repository Enumeration Matters
Imagine finding an internal hostname in a repository.
By itself:
prototype-beta.trilocor.local
may simply look like another DNS record.
But suppose the same repository contains:
- application configuration referencing that hostname,
- a username associated with the application,
- information about authentication,
- deployment scripts,
- or credentials used during testing.
Suddenly the hostname has context.
This is why source-code repositories can become important nodes in an attack graph.
The useful discovery is not necessarily:
Gogs → vulnerability → shell
It may instead be:
Gogs → information → credentials → internal application → additional access
That is a much more realistic way to think about enterprise penetration testing.
Analyzing prototype-beta.trilocor.local CPTS Trilocor Guide
Another important Trilocor asset is:
prototype-beta.trilocor.local
Names such as prototype, dev, test, staging, and beta should always attract attention during an internal penetration test.
But avoid assuming they are vulnerable simply because of their names.
Instead, treat the hostname as a prioritization signal.
A prototype system may differ from production in several ways:
- weaker authentication
- verbose error messages
- debugging functionality
- test credentials
- incomplete access controls
- additional API endpoints
- development configuration
- outdated application components
The correct approach is to enumerate the system and determine which of these conditions actually exists.
Correlating Gogs and prototype-beta
The real value appears when information discovered in Gogs can be correlated with prototype-beta.trilocor.local.
Suppose enumeration produces three separate findings:
Finding 1: an internal application hostname.
Finding 2: a development account.
Finding 3: application configuration stored in a repository.
These should not remain three isolated notes.
Combine them.
Ask whether the account is associated with the application, whether the configuration reveals an authentication mechanism, and whether credentials discovered in development infrastructure work elsewhere.
This process is the foundation of CPTS attack path analysis.
Credential Analysis: Never Stop at “Password Found”
Finding credentials is only the beginning.
Whenever you discover a username/password pair, token, key, or authentication artifact, build a small credential matrix.
Record:
Credential → Source → User → Service → Result
For example:
credential A → Gogs → dev_user1 → prototype-beta → valid/invalid
Then expand testing only within the authorized scope.
Potential authentication surfaces may include:
- SMB
- WinRM
- SSH
- web applications
- Git services
- database services
- internal APIs
- Active Directory authentication
This makes credential testing structured instead of random.
It also prevents you from forgetting credentials discovered earlier in the assessment.
Credential Reuse Across the Trilocor Environment CPTS Trilocor Guide
Credential reuse is especially important when an environment combines development systems and Active Directory.
Developers may need access to multiple internal resources.
Applications may rely on domain accounts.
Automation scripts may contain credentials.
Testing systems may use authentication copied from another environment.
For every valid credential, ask:
- Where was it discovered?
- What account does it belong to?
- Where else might that account authenticate?
- Does the account have different privileges on another system?
- Can the credential reveal another part of the network?
The goal is not to spray credentials blindly.
The goal is to make evidence-driven authentication attempts based on relationships already discovered.
Active Directory Enumeration After Initial Access
Once valid domain credentials become available, repeat enumeration from the new security context.
This step is easy to underestimate.
Information unavailable anonymously may become visible after authentication.
Depending on the environment and authorized scope, useful enumeration can include:
- domain users
- domain groups
- computer accounts
- SMB shares
- accessible files
- Kerberos service accounts
- group memberships
- remote management access
- ACL relationships
- logged-on user information
- trust relationships
Every new credential effectively creates a new perspective on the network.
Do not assume your initial enumeration represents everything that exists.
Service Account Analysis: svc_adconnect
One account that deserves special attention is:
svc_adconnect
The svc_ prefix commonly indicates a service account, while adconnect suggests a relationship with directory synchronization or an AD-connected service.
That naming convention is useful intelligence, but it should not be treated as proof of specific privileges.
This distinction is important.
Do not automatically assume that an account called svc_adconnect has replication rights, Domain Admin privileges, or access to sensitive credentials.
Verify its actual permissions.
Useful questions include:
- Which groups contain the account?
- Which host uses it?
- Does it have local administrative access anywhere?
- Which services run under the account?
- What ACL permissions does it have?
- Where is it referenced?
- Are its credentials stored in configuration files or scripts?
Service accounts become dangerous when their actual permissions and exposure create an escalation path.
The account name alone does not establish that path.
Mapping the CPTS Trilocor Attack Path
At this point, stop thinking in terms of individual vulnerabilities.
Start building a graph.
A conceptual attack path might contain relationships such as:
External/Internal Service
↓
Gogs / Development Infrastructure
↓
Repository Enumeration
↓
Internal Hostname or Credential Discovery
↓
Development Account
↓
prototype-beta.trilocor.local
↓
Additional Credential or Access
↓
Active Directory Enumeration
↓
Service or Privileged Account Relationship
↓
Privilege Escalation / Lateral Movement
This is deliberately a methodology rather than a claimed exact solution sequence.
Your actual path should be based on evidence collected from the environment.
That distinction makes the analysis much more useful: instead of memorizing a walkthrough, you learn how to reconstruct the path yourself.
Build an Attack Graph, Not a List of Hosts CPTS Trilocor Guide
A simple pentest notebook might look like this:
10.x.x.x - SMB
10.x.x.x - HTTP
gogs-qa0001 - Gogs
prototype-beta - web app
dev_user1
rhinkle
That inventory is useful, but incomplete.
A better representation captures relationships:
dev_user1 → Gogs
Gogs → repository
repository → prototype-beta
credential → domain user
domain user → host
host → service account
service account → privileged resource
Now you can see possible paths.
This is one of the most transferable lessons from the CPTS Trilocor Guide: relationships are usually more valuable than isolated findings.
Re-Enumerate After Every Meaningful Discovery
A common mistake is performing enumeration once and then moving permanently into exploitation.
Real penetration tests rarely work that way.
The better cycle is:
Enumerate → Gain Access → Re-enumerate → Correlate → Test → Repeat
For example, gaining access to a repository should trigger another enumeration phase.
Obtaining domain credentials should trigger another.
Accessing an internal host should trigger another.
Discovering a new network segment should trigger another.
Each new privilege level changes what you can see.
Common Mistakes When Working Through Trilocor
Treating Gogs as Just Another Website
Source-control systems contain information about the infrastructure behind applications.
Read repositories as infrastructure documentation, not merely source code.
Ignoring Git History
Deleted credentials may remain inside previous commits.
Always consider repository history when investigating secrets.
Assuming Account Privileges From Names
svc_adconnect sounds important.
fjenkins_adm sounds privileged.
Those names provide hypotheses—not proof.
Verify privileges through enumeration.
Attacking Admin Accounts Too Early
Knowing an administrator username does not automatically give you a practical attack path.
Look for indirect relationships first.
Ignoring Development Infrastructure
QA, beta, staging, and prototype systems can reveal information unavailable through production-facing assets.
Failing to Re-Enumerate
Every new credential, host, repository, or shell should trigger another enumeration cycle.
A Better CPTS Trilocor Workflow
When approaching an environment like Trilocor, use a repeatable methodology.
1. Build the Asset Inventory
Record discovered hosts, services, domains, applications, and users.
2. Categorize Accounts
Separate:
- standard users
- developers
- service accounts
- administrative accounts
3. Investigate Development Infrastructure
Pay particular attention to:
- Gogs
- repositories
- QA systems
- prototype systems
- configuration files
4. Extract Relationships
Do not simply record information.
Connect it.
Which user belongs to which application?
Which repository references which server?
Which credential belongs to which service?
5. Validate Credentials Carefully
Test credentials against logically related services within scope.
6. Re-Enumerate Active Directory
New credentials may expose additional domain information.
7. Map Privilege Relationships
Look for:
- group memberships
- local administrator rights
- ACL relationships
- service-account permissions
- remote access
- credential exposure
8. Build the Attack Path CPTS Trilocor Guide
Convert isolated discoveries into:
Access → Information → Credential → Host → Privilege → Next Asset
9. Document Everything
Record the evidence needed to reproduce the path and explain its security impact.
Why Trilocor Is Relevant to CPTS Preparation
Trilocor is useful because the broader methodology matches skills assessed by HTB CPTS.
According to Hack The Box, CPTS covers areas including:
- information gathering and reconnaissance
- Windows and Linux attacks
- Active Directory penetration testing
- web application penetration testing
- manual and automated exploitation
- vulnerability assessment
- pivoting and lateral movement
- post-exploitation enumeration
- privilege escalation
- vulnerability and risk reporting
More importantly, CPTS expects candidates to correlate findings and identify exploitation opportunities rather than simply search for known CVEs.
That makes attack-path analysis one of the most useful habits you can develop during preparation.
CPTS Exam Preparation: Think Like a Penetration Tester
If you are preparing for CPTS, avoid reducing every target to:
Which exploit should I run?
Instead ask:
What does this asset tell me about the rest of the environment?
A Gogs server might reveal source code.
Source code might reveal an internal hostname.
That hostname might reveal another application.
The application might accept previously discovered credentials.
Those credentials might belong to Active Directory.
Active Directory enumeration might reveal another privilege relationship.
The important skill is following the evidence.
This approach is useful far beyond the CPTS Trilocor Guide because it reflects how multi-stage penetration tests are actually performed.
CPTS Trilocor Guide FAQ
What is Trilocor in CPTS?
Trilocor Robotics refers to an environment associated with CPTS-related penetration testing scenarios and discussions. From a learning perspective, its value comes from analyzing relationships between Active Directory, users, development infrastructure, repositories, credentials, and internal systems rather than treating each target independently.
Why is Gogs important in the Trilocor environment?
Gogs is a self-hosted Git service. Repositories can expose source code, internal hostnames, configuration files, usernames, deployment information, and potentially sensitive historical data. This information can help identify additional attack paths.
What should I look for in Gogs repositories?
Prioritize configuration files, commit history, usernames, internal URLs, API endpoints, credentials, tokens, database connections, deployment scripts, environment files, and references to other infrastructure.
Why is prototype-beta.trilocor.local interesting?
The hostname suggests a prototype or beta application. That makes it worth prioritizing during enumeration, particularly when other evidence connects it to developers, repositories, credentials, or internal infrastructure. The name itself, however, does not prove that the system is vulnerable.
Is svc_adconnect automatically a privileged account?
No. The name suggests a service account associated with an AD-connected service, but its privileges must be verified. Account naming conventions provide useful clues; they are not evidence of specific permissions.
How should I approach Active Directory in CPTS?
Treat Active Directory enumeration as an iterative process. Map users, groups, computers, services, accessible shares, authentication relationships, and permissions, then repeat enumeration whenever you obtain new credentials or privileges.
What is the most important lesson from Trilocor?
Correlation.
Do not treat hosts, credentials, repositories, and users as isolated discoveries. Map the relationships between them and use those relationships to construct evidence-based attack paths.
Does CPTS require Active Directory knowledge?
Yes. Active Directory penetration testing is explicitly included among the knowledge domains assessed by HTB CPTS, alongside web exploitation, pivoting, lateral movement, post-exploitation, privilege escalation, and professional reporting.
Final Thoughts
The most valuable lesson from this CPTS Trilocor Guide is not a particular credential, hostname, or exploit.
It is methodology.
The trilocor.local domain, gogs-qa0001.trilocor.local, prototype-beta.trilocor.local, accounts such as rhinkle and dev_user1, and potentially sensitive accounts such as svc_adconnect and fjenkins_adm become useful only when you understand their relationships.
Enumerate thoroughly.
Correlate what you discover.
Re-enumerate whenever your access changes.
Verify assumptions instead of trusting names.
And build the attack path from evidence rather than trying to guess the final exploit.
That is the mindset that turns a collection of hosts and usernames into a penetration test.
For the official certification scope, requirements, and current CPTS information, see the Hack The Box Certified Penetration Testing Specialist certification page.
If you want additional structured preparation material, you can also explore our HTB CPTS Exam Preparation resources and related CPTS guides on CyberServices.Store.
Vendor: https://academy.hackthebox.com/preview/certifications/htb-certified-penetration-testing-specialist
Buy this dump: If you are preparing for the exam, check out our HTB CPTS Exam Preparation pack
See also: the same Trilocor lab from the web-exploitation side in the HTB CWES Trilocor guide (admin panel and port 8088), and for the Active Directory users-and-credentials stage on HTB, the HTB CAPE Active Directory guide.