OSC key terms

Collecting information about a target without sending traffic directly to its systems, for example through public records, search engines, certificate transparency logs, or archived pages. It reduces the chance the target notices the activity.

Probing target systems directly, such as DNS queries, port scans, or banner grabs, to learn about hosts and services. It yields more detail than passive methods but can be logged or trigger alerts.

Open-source intelligence: information gathered from publicly available sources such as websites, social media, job postings, code repositories, and domain registration records. It often reveals technologies, employees, and naming conventions useful for later stages.

Sending packets to ranges of TCP or UDP ports to determine which are open, closed, or filtered. Results map reachable services and guide deeper enumeration and exploitation efforts.

Interacting with a discovered service to identify its product, version, configuration, and exposed functionality. Examples include querying SMB shares, listing SNMP values, or reading an HTTP server header.

Connecting to a service and reading the greeting or header it returns to identify software and version. The banner often narrows which known vulnerabilities are worth testing.

Comparing observed service behavior and responses against known signatures to estimate the exact software build in use. Accurate versions help prioritize exploits and avoid wasting time on patched targets.

The total set of points where an attacker could try to enter or extract data, including exposed services, user accounts, web parameters, and third-party integrations. Mapping it helps focus testing on the most promising paths.

Systematically listing valid resources on a target, such as usernames, shares, groups, routes, or directories, rather than merely detecting that a service exists. The output feeds credential attacks and privilege escalation decisions.

Listing Server Message Block shares, permissions, and sometimes files on a Windows or Samba host. Readable shares may expose credentials, scripts, backup files, or configuration that enable further access.

An unauthenticated SMB connection that some legacy or misconfigured systems allow, letting a client query users, groups, and shares anonymously. It is a classic source of usernames for password attacks.

Automated probing of hosts with a signature or behavior database to list suspected weaknesses, missing patches, and misconfigurations. Results require manual validation because scanners produce false positives and false negatives.

A scanner or tester reports a vulnerability that does not actually exist or is not exploitable in the target's configuration. Confirming findings manually prevents wasted effort and inaccurate reports.

Common Vulnerabilities and Exposures: a public identifier assigned to a specific disclosed vulnerability, such as CVE-2021-44228. The ID lets testers correlate advisories, exploits, and scanner output for the same flaw.

Common Vulnerability Scoring System: a standardized 0 to 10 score reflecting a vulnerability's exploitability and impact. It aids prioritization but does not by itself prove whether a given host is affected.

A minimal, controlled demonstration that a vulnerability can be triggered, such as a crafted request returning sensitive data. It validates a finding before it is reported or used for further access.

The set of updates currently installed on a system, which determines which known vulnerabilities remain unaddressed. Comparing it to vendor advisories is often faster than blind exploitation attempts.

A weakness arising from how software or systems are set up rather than from a coding flaw, such as default credentials, excessive permissions, or verbose error pages. These issues are common and often easy to exploit.

Code or a sequence of actions that takes advantage of a vulnerability to achieve an unintended effect, such as code execution or data disclosure. Reliability and side effects vary widely between exploits.

The action or code delivered after an exploit succeeds, for example a shell, a command to add a user, or a beacon to a command-and-control server. It determines what the attacker can do next.

A connection in which the compromised target initiates a session back to a listener controlled by the tester. It often bypasses inbound firewall rules that block direct connections to the target.

A shell in which the target opens a listening port and the tester connects to it. It works when inbound connections to the target are allowed but outbound connections are restricted.

A process on the tester's machine that waits for and accepts an incoming connection from a target, providing an interactive session. It must be reachable through any intervening firewalls or NAT.

Vendor-supplied usernames and passwords that were never changed, such as admin/admin on an appliance. They are a frequent and low-effort route to initial access on internal services.

Trying a small set of common passwords against many accounts to avoid lockout thresholds. It targets weak password choices across an organization rather than guessing one account's password repeatedly.

Replaying username and password pairs leaked from other breaches against a target, betting that users reused them. It differs from spraying because each account gets its own known password.

Moving from a lower-privileged account or process to one with more rights, such as local administrator or root. It may exploit a bug, abuse a misconfiguration, or steal credentials from a more powerful context.

A Linux executable marked to run with the file owner's permissions, often root. If it is writable, scriptable, or has a known abuse technique, it can yield a root shell.

The commands a Linux user may run as another user through sudo, as defined in sudoers. Overly broad entries, such as permission to run editors or interpreters, often allow a full privilege escalation.

Exploiting scheduled Linux tasks that run as a privileged user, for example by editing a script or directory the task references. The next scheduled run then executes attacker-controlled code with higher rights.

A Windows service whose executable path contains spaces but no quotes, so the system may run an attacker-placed binary from an earlier directory in the path. It can elevate rights if the service runs as SYSTEM.

Abusing a Windows access token, such as one held by a privileged process, to act as that user. Tools like Potato-family exploits and SeImpersonate privileges make this a common escalation route.

Requesting service tickets for accounts with service principal names, then cracking the encrypted ticket offline to recover the account password. Success depends on weak service account passwords and does not require special rights.

Requesting authentication data for accounts that do not require Kerberos preauthentication, then cracking the returned encrypted blob offline. It yields credentials for those accounts without any prior access.

An Active Directory attribute that ties a service instance to an account, allowing Kerberos authentication to that service. Accounts with SPNs are targets for Kerberoasting because tickets can be requested for them.

Authenticating with a captured NTLM password hash instead of the plaintext password, without cracking it. It enables lateral movement wherever the same local administrator hash is reused across hosts.

Moving from one compromised host to another within a network to reach additional data or higher privileges. Techniques include remote service creation, SMB sessions, and remote management protocols using stolen credentials.

Using a compromised host as a relay to reach networks or services that the tester cannot access directly. It typically involves port forwarding or a proxy through the foothold.

An encapsulated channel that carries traffic between the tester and a target network through an intermediary host, such as SSH local or remote forwarding. It extends reach without exposing services publicly.

The channel a compromised host uses to receive instructions and return results, often over HTTPS, DNS, or another permitted protocol. Its design affects stealth, resilience, and detection risk.

Mechanisms that keep access alive across reboots, logoffs, or credential changes, such as scheduled tasks, services, or SSH keys. Testers document them carefully so they can be removed at engagement end.

Activities after initial access, including privilege escalation, credential harvesting, data discovery, and cleanup. The scope should stay within the agreed rules of engagement and be logged for the report.

Transferring sensitive data from a target environment to a location the tester controls, usually to demonstrate impact. It should be minimized, authorized, and handled securely during and after the engagement.

A domain or system setting that disables an account after a number of failed logins within a time window. Knowing the threshold prevents accidental lockouts during password attacks.

A document defining what testing is authorized, which systems and techniques are in or out of scope, timing, and emergency contacts. It protects both tester and client and shapes every later decision.

The specific hosts, domains, accounts, and techniques a test is permitted to touch. Anything outside it must be avoided or explicitly re-authorized before testing.

A label such as critical, high, or medium assigned to a finding based on impact and likelihood, often informed by CVSS plus business context. It helps clients prioritize remediation work.

The concrete fix or mitigation recommended for a finding, such as patching, reconfiguring, or restricting access. Specific, actionable advice makes a report useful rather than merely descriptive.

The opening section of a report that explains overall risk, key themes, and priorities in plain language for non-technical readers. It should stand alone without requiring the technical detail that follows.