THREE STARTING POINTS
Ares supports red team operations that begin from different positions. Uncredentialed and authenticated testing answer different questions, and both belong in an application security program.
Starting position
What it helps investigate
Coverage boundary
No supplied credentials
Anonymous pages, endpoints, client-side code, exposed files, and supported authentication weaknesses.
Reachability does not guarantee access behind login.
Supplied test identities
Authenticated workflows, user separation, privilege boundaries, and business logic.
Coverage depends on successful login and the identities supplied.
Discovered access
Whether a recovered capability supports a relevant follow-on test.
Validity, use, and resulting impact need evidence. Scope does not expand.
AUTHENTICATION METHODS
Choose a supported credential configuration and test it before relying on the assessment. Application-specific options include login endpoints, request fields, encoding, session verification, CSRF handling, and credential headers.
Method
How Ares supports it
Username and password
Establish a supported application login and use its resulting session.
Password with TOTP MFA
Generate current codes from the authenticator setup secret you provide.
Okta Login
Use a dedicated username/password account with its supported Google Authenticator TOTP factor and setup key.
HTTP Basic
Send the configured identity through Basic authentication.
API key
Apply a supplied key through the supported target-specific configuration.
Bearer token or JWT
Use supplied token material. JWT-aware testing examines supported token-validation weaknesses.
OAuth2 client
Configure the supported client identity, secret, token endpoint, and scopes.
Session cookie
Use a supplied application session cookie.
Interactive login
Let an operator complete a supported browser or mobile sign-in.
Activation or invitation code
Supply a supported onboarding code where required.
MFA DECISION GUIDE
MFA-compatible login is not MFA bypass. The application and its identity provider still enforce the account’s authentication policy.
Factor or flow
Assessment approach
Important condition
Supported TOTP login
Generate codes from the supplied setup secret.
The login flow and policy must support the configured method.
Dedicated Okta TOTP
Use the supported account and Google Authenticator factor.
This is not automatic Okta Verify push or number matching, and does not establish mobile Okta automation.
Push, number challenge, SMS or email code
An operator completes the factor through supported interactive login.
Ares does not automatically approve pushes or read code inboxes.
Hardware key, passkey, or device compliance
Confirm compatibility during setup.
Device-bound factors, Conditional Access, CAPTCHA, or policy may block the remote mission environment.
INTERACTIVE SESSION HANDOFF
For applications that redirect to Microsoft Entra ID, Okta, or another supported provider, an operator completes the normal sign-in in the live mission browser. Ares then adopts the usable application session.
01 / SIGN IN
Follow redirects and complete the required information and compatible MFA step.
02 / HAND OFF
Supported browser handoff includes application cookies, storage, and sign-in headers.
03 / CONTINUE
Ares uses the resulting access for supported browser and HTTP testing. Review actual authenticated reach.
Recognized sign-in hosts include Microsoft Entra and Microsoft accounts, Okta, Google, OneLogin, Auth0, Duo, Ping, and JumpCloud. Custom provider hostnames can be configured. Recognition is not a guarantee for every provider policy.
Provider connections enable authentication to your application; they do not add the provider to attack scope. Supported browser campaigns can request re-login after session loss. Mobile interactive sign-in has different device and session-lifecycle behavior.
CREDENTIAL DISCOVERY
Ares examines supported sources with the access appropriate to each lane. An exposed value is a lead to investigate, not proof that it is valid or exploitable.
Source
What can be examined
Boundary
Client-side JavaScript
Code and assets delivered to the browser.
Public secret observations can remain unverified.
Exposed files and responses
Reachable configuration artifacts, downloads, and response content.
Discovery does not authorize third-party account or service testing.
Connected repositories
Supported source and configuration files with an authorized connection.
Repository access is separate. Automatic transfer of every secret into runtime testing is not implied.
Mobile packages
Supported Android and iOS artifacts for embedded secrets and configuration.
Captured runtime evidence can show use, not necessarily necessity.
In supported web and API chaining workflows, recovered credentials, tokens, or signing material can inform relevant authorized tests. If another finding results, review the recorded connection and whether it was observed or inferred.
IDENTITY BOUNDARIES
Provide separate test identities to compare access to records and functions. Ares can use the available identities and explicitly test an anonymous position.
ANONYMOUS → USER
Does a function return protected data without an identity?
USER A → USER B
Can one user read or change another user’s records?
USER → ADMINISTRATOR
Can an ordinary user reach a function intended for a privileged role?
These are illustrative assessment questions, not demonstrated results. Review requests and identity context with the resulting findings.
RECURRING ACCESS
Saved credentials support recurring campaigns. Prefer a supported method that can establish a usable session at launch, and keep the account and factor valid.
Access option
Operational consideration
Supported unattended login
Test credentials and verify the account, factor, and login configuration remain usable.
Pasted token or cookie
Session material can expire and reduce authenticated coverage.
Interactive login
Requires a person and is not carried into scheduled campaigns.
Private application
Confirm the campaign agent can reach the application and its sign-in provider.
A completed campaign does not guarantee complete authenticated coverage. Review credential testing, actual reach, session loss, and schedule outcomes together.
HOW IT WORKS
Tie the assessment’s conclusions to the identity and reach it actually used.
Step
Action
01 / Choose
Begin without supplied credentials, attach test identities, or enable supported interactive login.
02 / Prepare
Configure authentication, MFA, login settings, and the required network reach.
03 / Investigate
Assess reachable functionality and supported sources for additional exposure.
04 / Follow
Pursue supported follow-on opportunities within the authorized scope.
05 / Review
Distinguish exposed material from observed use and confirmed impact.
FREQUENTLY ASKED QUESTIONS
Authentication is a means of reaching the application, not a guarantee of coverage or a change in authorization.
TALK TO ASSAIL
Tell us how your applications authenticate. We will help you plan uncredentialed coverage, test identities, MFA setup, and interactive sign-in.
Your environment. Your objectives. A mission built around both.
