Investigate SIP/IRC identity and configuration clues

Needs: Application-specific request format; permitted registration/channel/configuration access

SIP

These source-site topics contain only first-pass reconnaissance. Treat them as application-identification branches, not default exploitation paths.

# SIP
nmap -Pn -sU -sV --script sip-methods -p 5060 TARGET
nmap -Pn -sT -sV --script sip-methods -p 5060 TARGET

# IRC
nmap -Pn -sV --script irc-info -p PORT TARGET
nc -nv TARGET PORT

Decisive output: a SIP response and supported methods. open|filtered without application response remains ambiguous. Do not run sip-brute until the exact registrar, known test identities, lockout policy and explicit authorization are established.

Minimal registration for an authorized test client

# Minimal registration for an authorized test client
NICK testnick
USER testuser 0 * :Test User
QUIT

Decisive output: IRC numeric replies, server/network name, version/capabilities or authentication requirement. Do not use irc-brute as identification; authenticate only with legitimately acquired credentials.

Verify → Retain protocol responses and distinguish product clues from confirmed vulnerabilities.

If it fails → A generic banner or denied registration leaves access unproven; return to version/configuration matching. More detail ↓

If → then

A product/version clue, advisory or component-specific public PoC → Match a public exploit to the actual component and configuration
Needs: Exact vulnerable build/configuration, required access and endpoint behavior; reviewable source and a verifiable expected effect
A password tied to a plausible user and service → Validate known passwords and context-specific reuse
Needs: Correct local/domain/application identity, reachable compatible service, accepted authentication and account state
A listener has a port-based label or uncertain version → Identify applications and validate selected NSE checks
Needs: A reachable selected port; scripts must match the application and permitted assessment behavior

No useful finding → another task in this topic. Failed check → resolve the failure before ruling out the path.

Explanation & examples

Investigate SIP/IRC identity and configuration clues

USE WHEN: A confirmed SIP or IRC application
STARTING ACCESS: A confirmed reachable application; anonymous context or one identified credential
RESULT: Service capabilities, identity clues or an evidence-matched exploit candidate

Recognize the clue

Classify the unusual listener, then use its normal greeting/registration behavior and the owning procedure's bounded protocol checks.

nmap -Pn -sV -p PORT TARGET
nc -nv TARGET PORT

SYNTHETIC EXAMPLE OUTPUT

PORT/tcp open irc APPLICATION_VERSION
:HOSTNAME NOTICE AUTH :registration required

Means: The real protocol and registration state determine the next client operation; the expected port label is insufficient.

Confirm: Verify application/version, accepted interaction and exact exploit/access conditions.

After validation: Normal protocol interaction exposes useful configuration or an exact vulnerable component: follow that candidate.
Ruled out in this context: The listener speaks another protocol: remove the SIP/IRC assumption.
Still inconclusive: A silent client-first or UDP service requires an appropriate protocol request; no greeting is not a version conclusion.

Troubleshooting: A generic banner or denied registration leaves access unproven; return to version/configuration matching.

Additional prerequisite checks

nmap -Pn -sV -p PORT TARGET

These source-site topics contain only first-pass reconnaissance. Treat them as application-identification branches, not default exploitation paths.

SIP

Commonly UDP/TCP 5060 or TLS 5061; follow protocol evidence.

Decisive output: a SIP response and supported methods. open|filtered without application response remains ambiguous. Do not run sip-brute until the exact registrar, known test identities, lockout policy and explicit authorization are established.

IRC

Minimal registration for an authorized test client:

Decisive output: IRC numeric replies, server/network name, version/capabilities or authentication requirement. Do not use irc-brute as identification; authenticate only with legitimately acquired credentials.

Why it works

Protocol identification and configuration may expose useful users or product versions. Do not replace application evidence with the expected service at a conventional port.

Worked example · hypothetical

Observation: a nonstandard port responds as IRC. Test: inspect its normal registration/banner behavior. Illustrative output: a named build and accessible channel information. Interpretation: record identity clues and verify any public exploit's exact prerequisites.

New identity, privilege, host or route? Re-enumerate → All topic tasks →

Study guide ↗Full procedure ↗Cheatsheet ↗