Ethical Hacking & Penetration Testing

Chapter 9
Network, Wireless and Cryptographic Security Testing

Diploma in Cybersecurity
Ethical Hacking & Penetration Testing   •   Diploma

Network, Wireless and Cryptographic Security Testing

Introduction and Context

Modern organisations depend on interconnected systems: web applications communicate through networks, employees connect through wireless access points, and remote users access internal resources through virtual private networks (VPNs). These technologies improve availability and productivity, but they also create security dependencies. A weakness in a network service, firewall rule, wireless configuration, authentication mechanism, or cryptographic implementation may expose confidential information or permit unauthorised access.

Network, wireless and cryptographic security testing evaluates these controls in an authorised and controlled manner. The purpose is not to attack systems indiscriminately, but to determine whether security protections operate as intended, identify realistic risks, and provide evidence-based recommendations. Testing should be performed only with written permission, defined scope, agreed methods, and appropriate safeguards for availability and privacy.

This chapter focuses on practical foundations for diploma-level penetration testing. It explains how to assess common network services, firewalls, VPNs, segmentation, Wi-Fi deployments, authentication, traffic exposure and cryptographic controls without treating tools as substitutes for professional judgement.

Learning Objectives

By the end of this chapter, you should be able to:

  1. Explain the security properties and common risks of network services and protocols.
  2. Plan authorised tests of firewalls, VPNs and network segmentation.
  3. Evaluate wireless security configurations and authentication choices.
  4. Recognise insecure authentication, exposed traffic and weak cryptographic implementation.
  5. Distinguish vulnerability discovery from exploit validation and risk assessment.
  6. Document evidence, limitations, remediation and retesting requirements professionally.

1. A Security Testing Model

A useful assessment model separates the environment into five related layers:

LayerMain concernTypical evidence
Asset and service layerWhat systems and services exist?Asset inventory, service banners, configuration records
Control layerWhat prevents unwanted access?Firewall rules, ACLs, VPN policy, NAC settings
Communication layerWhat traffic is permitted or exposed?Packet captures, flow records, protocol settings
Authentication and cryptography layerHow are identity and confidentiality protected?Authentication logs, certificate chains, cipher settings
Governance layerIs testing lawful, controlled and repeatable?Rules of engagement, approvals, reports, retest records

Testing normally follows a cycle: scope and authorise, discover, analyse, validate safely, report, remediate and retest. Discovery should be proportionate. For example, a tester may identify open TCP or UDP services using approved scanning from an agreed source address, then confirm findings through configuration review or a low-impact connection. Destructive actions, password spraying, denial-of-service testing and collection of real credentials require explicit separate approval, if they are permitted at all.

Risk-oriented thinking

A finding is not automatically a critical vulnerability merely because a port is open. Risk depends on exploitability, exposure, affected assets, business impact, existing compensating controls and evidence quality. A useful qualitative model is:

Risk ≈ Likelihood × Impact

Likelihood and impact are ordinal assessment categories rather than physical measurements in this model. The relationship is a prioritisation aid, not a universal probability equation. Organisations should use their approved risk methodology and record assumptions.

2. Testing Network Services and Protocols

2.1 Service exposure and attack surface

A network service is a process that accepts or initiates communications, commonly through a protocol and port. Examples include DNS, HTTP/S, SSH, SMTP, SMB, LDAP, database services and remote administration interfaces. A service becomes a security concern when it is unnecessary, incorrectly configured, outdated, weakly authenticated or reachable from an inappropriate network zone.

A professional service assessment asks:

  • Is the service required for a documented business purpose?
  • Is it reachable from the Internet, user networks, guest Wi-Fi or only an administration network?
  • Is the software and protocol version supported and patched?
  • Does it expose unnecessary information through banners, errors or metadata?
  • Does it enforce authentication and authorisation correctly?
  • Is traffic protected in transit?
  • Are logs generated, protected and reviewed?

A port number is only an indication, not proof of the service or its security. Service identification should be corroborated with configuration, authenticated inspection where approved, and packet or application evidence.

2.2 Common protocol weaknesses

Telnet and unencrypted remote administration. Telnet transmits commands and credentials without adequate confidentiality. It should normally be replaced with SSH or another managed secure administration method. SSH itself requires secure configuration, including current versions, strong host-key management, restricted administrative access, and preferably phishing-resistant or certificate-based authentication.

HTTP without transport protection. Plain HTTP exposes requests, responses and often session identifiers to parties able to observe the path. Redirecting HTTP to HTTPS is useful but does not replace a secure HTTPS configuration, because the initial request may still be intercepted or modified.

FTP and legacy file transfer. Traditional FTP separates control and data channels and does not provide adequate confidentiality. Secure alternatives include SFTP or appropriately configured managed file transfer. Anonymous access must be explicitly justified and tightly restricted.

DNS. DNS is essential, but risks include unauthorised zone transfer, excessive information disclosure, weak separation between internal and external views, cache poisoning exposure, and inadequate monitoring. Testing must distinguish authoritative servers, recursive resolvers and forwarding services. Recursion should not be available broadly when it is not required.

Email protocols. SMTP, POP3 and IMAP require careful review of transport encryption, authentication, relay restrictions and downgrade behaviour. An Internet-facing mail server should not act as an open relay. Certificate validation and modern TLS settings should be tested from approved locations.

SMB and directory services. File-sharing and directory protocols often carry high privilege. Testing should examine signing or channel protection, guest access, obsolete protocol versions, share permissions, LDAP encryption, service-account privileges and network reachability. Enumerating usernames or shares should be limited to the approved scope because such information may be sensitive.

2.3 Safe validation

A vulnerability should be validated with the least intrusive method that establishes its existence. Examples include:

  • confirming that a legacy protocol is enabled through configuration or a negotiated connection;
  • demonstrating that a test account can access only its authorised share;
  • verifying that a certificate is expired or issued to the wrong name;
  • observing, in a controlled test, whether a session cookie is sent without the Secure attribute;
  • confirming that a firewall permits a prohibited connection from an approved test host.

Avoid extracting production data or proving access by altering records. Use test accounts, synthetic data and snapshots where possible. Evidence should include timestamp, source and destination, method, result and confidence.

3. Firewalls, Access Control and Segmentation

3.1 Firewall functions

A firewall enforces traffic policy between interfaces, zones or hosts. Controls may be based on source and destination addresses, ports, protocols, user identity, application attributes or connection state. Stateful inspection tracks connections, whereas stateless filtering evaluates individual packets. Next-generation firewalls may add application identification, malware inspection or identity integration, but these features must be configured and monitored correctly.

A firewall review should examine:

  1. Default behaviour: Is traffic denied unless explicitly permitted?
  2. Rule necessity: Does each rule have an owner, business justification and expiry or review date?
  3. Scope: Are source and destination ranges narrower than necessary?
  4. Services: Are broad protocols or all-port rules avoided?
  5. Direction: Are inbound, outbound and inter-zone flows considered?
  6. Administration: Is management restricted and strongly authenticated?
  7. Logging: Are denied and important permitted events logged without overwhelming the monitoring system?
  8. Change control: Are emergency and temporary rules reviewed and removed?

The principle of least privilege applies to network flows: permit only the communication required for a defined function.

3.2 Rule-order and shadowing problems

Many firewalls process rules from top to bottom. A broad rule placed above a specific deny rule may make the deny ineffective. A later rule may be unreachable because earlier rules match the same traffic. Testing therefore requires both policy inspection and representative connection tests from relevant network locations.

A compact rule review can classify each rule as:

ClassificationMeaningAction
Required and narrowNecessary and appropriately restrictedRetain and monitor
Required but broadBusiness need exists, scope is excessiveNarrow or add compensating controls
Unused or ownerlessNo evidence of current needRemove after approval
Conflicting or shadowedPolicy does not operate as intendedReorder or redesign
Temporary and expiredTime limit has passedRemove immediately through change control

3.3 Segmentation and trust boundaries

Segmentation separates systems according to function, sensitivity or trust. Typical zones include Internet, public services, user devices, servers, management, backups, development and guest wireless. Segmentation is not proved by different VLAN names. It must be demonstrated by effective traffic restrictions, routing controls, identity policy and monitoring.

A segmentation test should sample paths such as guest-to-user, user-to-database, workstation-to-management, production-to-development and server-to-backup. The test plan should identify both prohibited and required flows. A failed connection is not sufficient evidence if a different path, IPv6 route, wireless bridge, remote-management channel or cloud connection bypasses the intended boundary.

Microsegmentation and software-defined controls can reduce lateral movement, but complexity may create policy inconsistencies. Review should include exceptions, inherited policies, identity groups and failure behaviour.

4. VPN and Remote Access Security

A VPN creates a protected logical connection over an untrusted or less trusted network. It does not automatically make the endpoint trustworthy or grant appropriate authorisation.

4.1 VPN assessment areas

  • Authentication: Is multi-factor authentication required? Are shared accounts prohibited? Are recovery and reset processes secure?
  • Cryptography: Are supported protocols, strong algorithms and valid certificates used? Are weak or deprecated options disabled?
  • Authorisation: Does each group receive only the routes and applications required?
  • Endpoint posture: Are unmanaged or unpatched devices restricted? Is device identity verified?
  • Split tunnelling: If enabled, can an endpoint bridge trusted and untrusted networks? Is the risk accepted and controlled?
  • Session management: Are idle timeouts, reauthentication, revocation and concurrent-session rules appropriate?
  • Monitoring: Are login, failure, privilege and configuration events recorded and correlated?

A remote-access VPN should be tested from an approved external location and from relevant internal contexts. Test accounts should represent ordinary users, contractors and administrators without using real privileged credentials. The tester should verify that a user cannot reach unrelated subnets merely because the VPN connection succeeds.

4.2 VPN limitations

VPN encryption protects traffic between defined endpoints; it does not protect data after it reaches the endpoint or destination service. Malware on a client can use the tunnel legitimately. A compromised VPN gateway can expose traffic or credentials. Consequently, VPN security must be combined with endpoint protection, identity governance, segmentation, monitoring and application-layer encryption.

5. Wireless Security Testing

Wireless networks extend the attack surface beyond physical cabling. Radio signals may be received outside the building, and attackers may attempt unauthorised association, impersonation or traffic observation. Testing must account for safety, privacy and the possibility of disrupting operational devices.

5.1 Wireless architecture and terminology

An access point (AP) provides wireless connectivity. A service set identifier (SSID) is the network name advertised or used by clients. A basic service set identifier (BSSID) identifies a particular AP radio. Wireless clients authenticate and associate, after which traffic is commonly bridged or routed into a wired network.

Important distinctions include:

  • Open network: No link-layer authentication or encryption; unsuitable for sensitive access unless an appropriate higher-layer control exists.
  • Personal mode: Uses a shared passphrase. Security depends heavily on passphrase secrecy and strength.
  • Enterprise mode: Uses an authentication server, commonly through 802.1X and EAP methods, enabling individual identities and stronger control.
  • Guest network: Should be isolated from internal resources and monitored separately.

5.2 Wireless configuration review

A controlled review should examine:

  • WPA2 or WPA3 configuration and whether obsolete protocols are disabled;
  • enterprise authentication method, certificate validation and server-name checking;
  • protection against downgrade and unauthorised rogue access points;
  • management-frame protection where supported;
  • separation of guest, corporate, voice, Internet-of-Things and administrative networks;
  • client isolation and firewall enforcement;
  • default administrator credentials and firmware status;
  • SSID disclosure, beacon information and unnecessary management exposure;
  • logging of associations, authentication failures and unusual access points.

Hidden SSIDs do not provide meaningful security because network identifiers can often be learned from normal wireless traffic. MAC-address allowlists are also weak as a primary control because addresses can be observed and imitated. A strong enterprise design uses individual authentication, certificate validation, role-based authorisation and network segmentation.

5.3 Safe wireless testing

Wireless testing should use a defined physical area, approved radio channels and a test device. Avoid deauthentication or interference techniques unless explicitly authorised, legally permitted and scheduled to prevent impact on safety-critical or operational systems. Prefer passive observation, configuration review and controlled association tests. Do not capture or retain personal communications unnecessarily. If packet capture is required, minimise collection, protect the files and destroy them according to the engagement agreement.

6. Cryptographic Security Testing

Cryptography supports confidentiality, integrity, authentication and non-repudiation, but these properties depend on implementation and key management. Using a modern algorithm does not compensate for poor key storage, incorrect certificate validation or insecure protocol negotiation.

6.1 Core security properties

  • Confidentiality: Unauthorised parties cannot feasibly learn protected content.
  • Integrity: Unauthorised modification can be detected.
  • Authentication: The identity of a communicating party or message origin can be verified.
  • Freshness: Replayed old messages can be detected where freshness matters.
  • Availability: Cryptographic controls do not guarantee availability; key loss or certificate failure can cause outages.

6.2 Encryption, hashing and encoding

Encryption is reversible with an appropriate key. Hashing produces a fixed-length digest intended for integrity or lookup purposes and is not encryption. Encoding, such as Base64, provides representation compatibility but no confidentiality.

For password storage, systems should use a dedicated password-hashing or key-derivation function with a unique salt and an appropriate work factor. A salt is not a secret; it prevents identical passwords from producing identical stored values and makes precomputed attacks less useful. Passwords should not be stored using unsalted fast hashes such as plain SHA-256.

6.3 Symmetric and asymmetric cryptography

Symmetric cryptography uses the same secret key for encryption and decryption. It is efficient for bulk data but requires secure key distribution. Asymmetric cryptography uses a key pair: a public key and a private key. It supports authentication and key establishment, but is computationally more expensive and depends on private-key protection and certificate validation.

Authenticated encryption with associated data (AEAD) provides confidentiality and integrity for plaintext plus protected metadata. Correct nonce or initialization-vector management is essential. Reusing a nonce with the same key in modes that require uniqueness can seriously undermine security. Testers should inspect implementation documentation and configuration rather than assuming that an algorithm name proves safe use.

6.4 TLS and certificates

Transport Layer Security (TLS) protects application traffic when correctly negotiated and validated. A TLS assessment should check:

  • certificate validity period and trusted issuing chain;
  • subject name or subject-alternative-name matching;
  • private-key protection and certificate permissions;
  • protocol versions and cipher-suite policy;
  • secure renegotiation and session handling where relevant;
  • protection against downgrade;
  • whether sensitive applications enforce certificate validation;
  • whether internal services use encryption consistently.

Certificate warnings should not be normalised. A user who routinely bypasses warnings may accept an impersonated service. Internal certificates require the same lifecycle discipline as public certificates: inventory, issuance, renewal, revocation and ownership.

6.5 Cryptographic key management

A key-management review considers generation, distribution, storage, use, rotation, backup, revocation and destruction. Keys should be accessible only to authorised processes and personnel. High-value keys may require hardware security modules or managed key-vault services. Backups must be protected because an encrypted database is not secure if its keys are stored beside it without adequate controls.

7. Authentication and Traffic Exposure

Authentication weaknesses frequently connect network and cryptographic findings. Common examples include reusable passwords, shared administrator accounts, missing multi-factor authentication, insecure password recovery, unlimited login attempts and credentials transmitted through unprotected channels.

Testing should distinguish:

  • Identification: claiming an identity, such as entering a username;
  • Authentication: proving control of an identity factor;
  • Authorisation: determining what the authenticated identity may do;
  • Accounting: recording relevant actions and events.

A secure channel does not make weak authentication acceptable, and strong authentication does not protect traffic after a session is established if session tokens are exposed. Review cookie flags, token lifetime, logout invalidation, device binding where appropriate, and protection against replay.

Traffic exposure can be assessed through controlled packet captures, proxy inspection of test sessions, switch configuration review and log correlation. Sensitive data may be exposed through plaintext protocols, verbose error messages, DNS queries, metadata, backups, monitoring exports or improperly protected cloud links. Captures must be handled as confidential evidence because they may contain credentials or personal information.

8. A Professional Testing Workflow

8.1 Preparation

The rules of engagement should specify authorised systems, source addresses, testing windows, permitted techniques, emergency contacts, data-handling requirements, stop conditions and reporting recipients. Scope should include third-party services and cloud boundaries where relevant; permission for one organisation does not automatically authorise testing another provider.

8.2 Discovery and enumeration

Build an asset and communication map from approved scanning, documentation, configuration exports and interviews. Record uncertainty. An asset that is not detected is not necessarily absent; filtering, load balancing, IPv6 and cloud services can produce incomplete observations.

8.3 Analysis and validation

Compare observed behaviour with policy and expected architecture. Validate only high-value questions, using test accounts and synthetic data. The goal is to establish exploitability and business relevance, not to maximise the number of commands executed.

8.4 Reporting

A useful finding contains a title, affected asset, condition, evidence, risk, business impact, likelihood, remediation, references, limitations and retest criteria. Evidence should be reproducible but should not reveal unnecessary secrets. Screenshots should redact tokens, personal data and private keys.

8.5 Retesting

Retesting verifies that remediation addresses the root cause and has not introduced a bypass. It should repeat the relevant test from the relevant network location and confirm both positive and negative requirements—for example, that an approved application still works while an unauthorised zone remains blocked.

Applied Case: Illustrative Regional Health Provider Assessment

Background

The fictional Northbridge Health Provider operates a patient portal, internal clinical systems, guest Wi-Fi and remote-access VPN. A previous audit identified inconsistent firewall documentation but did not test wireless isolation or internal encryption.

Problem

Management needed to know whether a compromised guest device could reach clinical systems and whether remote users received more access than required. The assessment also needed to evaluate certificate management without collecting patient data.

Analysis

The approved scope included one guest SSID, one corporate SSID, the VPN gateway, selected firewall rules and test accounts. Production patient records, denial-of-service activity and credential attacks were excluded. The testers mapped expected flows and created synthetic accounts for a receptionist, contractor and administrator.

Testing showed that guest clients could reach the DNS resolver and Internet, as intended, but a firewall exception also permitted access to an internal management interface. The VPN contractor profile received a route to a broad server subnet rather than only the documented application. The corporate wireless network used enterprise authentication, but several test devices did not validate the authentication server certificate. An internal laboratory service accepted unencrypted HTTP from a user VLAN.

Approach and solution

The team stopped after confirming the management-interface exposure and did not attempt administrative login. Firewall rules were narrowed to the required destination and source groups. VPN routes were replaced with application-specific access through a controlled gateway. Mobile-device configuration was corrected to require certificate validation, and the authentication server was tested with a managed pilot group before wider deployment. The laboratory service was migrated to HTTPS, with monitoring for remaining HTTP requests.

Outcome

Retesting confirmed that guest clients could no longer reach management interfaces, contractors could access only approved applications, and test devices rejected an untrusted authentication certificate. The service owner retained a documented exception for a legacy instrument that could not immediately support HTTPS, placing it in a restricted segment with compensating controls and a retirement date.

Learning points

  1. Segmentation must be tested from the actual source networks, not inferred from diagrams.
  2. VPN connection success does not prove least-privilege access.
  3. Enterprise wireless authentication is weakened when clients fail to validate the server.
  4. Legacy exceptions require ownership, isolation, monitoring and an end date.
  5. Safe validation can demonstrate serious exposure without accessing sensitive records.

Challenges, Limitations and Governance

Network testing provides a point-in-time view. Dynamic cloud infrastructure, mobile devices, software-defined networking and temporary firewall changes may alter results. Scanners can misidentify services, miss filtered assets or produce false positives. Packet captures may be incomplete, and encrypted traffic limits content inspection. These limitations should be stated explicitly.

Legal and ethical duties include authorisation, privacy protection, proportionality, minimum necessary data collection and responsible disclosure. Regulatory requirements may apply to personal data, health information, payment data, telecommunications and critical infrastructure. The tester should preserve chain of custody for sensitive evidence and should never retain credentials or traffic longer than necessary.

Artificial intelligence can assist with asset classification, log summarisation, anomaly detection and prioritisation. However, AI-generated conclusions require human verification. Sensitive captures and configuration data should not be uploaded to unapproved services. Automated tools may reproduce bias, misunderstand business context or generate unsafe test actions; governance must therefore include approved models, access controls, logging and review.

Best-Practice Checklist

  • Obtain written authorisation and define scope before testing.
  • Maintain an accurate asset, service and trust-boundary inventory.
  • Prefer deny-by-default firewall policy and least-privilege flows.
  • Test segmentation from each relevant source zone, including IPv6 where deployed.
  • Use individual, strongly authenticated VPN and wireless identities.
  • Require certificate validation and protect private keys.
  • Disable obsolete protocols and remove unnecessary services.
  • Use modern authenticated encryption and safe key-management practices.
  • Protect captures, screenshots and logs as potentially sensitive evidence.
  • Validate safely with test accounts and synthetic data.
  • Record limitations, exceptions, owners and remediation deadlines.
  • Retest both the fix and the continued operation of required services.

Chapter Summary

Network, wireless and cryptographic security testing examines whether communications, boundaries, identities and protective technologies operate as intended. Effective assessment begins with authorisation and scope, followed by proportionate discovery, policy comparison, safe validation, reporting and retesting. Network-service reviews consider necessity, exposure, protocol security, authentication and monitoring. Firewall and segmentation testing evaluates rule order, least privilege, trust boundaries and bypass paths. VPN testing addresses authentication, routes, endpoint posture, session management and monitoring. Wireless testing examines enterprise authentication, certificate validation, encryption, isolation and rogue-device risk. Cryptographic testing distinguishes encryption, hashing and encoding and evaluates TLS, authenticated encryption, certificates and key management. Throughout, professional testers protect privacy, minimise disruption, document limitations and connect technical findings to business risk.

Key Terms

Asset inventory: A maintained record of systems, services, owners and relevant attributes.

Authenticated encryption: Encryption that provides confidentiality and integrity, commonly including protected associated data.

BSSID: The identifier of a particular wireless access-point radio.

Certificate validation: Verification that a certificate is trusted, current and valid for the intended service.

Cryptographic key: Secret or private information used by a cryptographic algorithm.

Firewall: A control that permits, rejects or inspects network traffic according to policy.

Least privilege: Granting only the access necessary for an authorised task.

Microsegmentation: Fine-grained separation of workloads or identities using network policy.

Network segmentation: Dividing a network into zones with controlled communication between them.

Nonce: A value intended to be used according to algorithm-specific uniqueness requirements.

Packet capture: Recorded network traffic used for authorised analysis.

Rogue access point: An unauthorised wireless access point connected to or impersonating an organisation’s network.

Rule shadowing: A condition in which an earlier firewall rule prevents a later rule from being evaluated as intended.

Service exposure: The availability of a network service to a particular source or zone.

Split tunnelling: VPN operation in which some endpoint traffic does not traverse the VPN tunnel.

TLS: Transport Layer Security, a protocol for protecting application communications.

Trust boundary: A point at which access assumptions or security policy change.

VPN: A virtual private network that creates a logical protected connection across another network.

WPA2/WPA3: Wireless security standards providing link-layer authentication and protection options.

Zero trust: A security approach that continuously evaluates identity, device, context and authorisation rather than trusting network location alone.

Review Questions

Short Answer Questions

  1. Why is an open port not, by itself, proof of a critical vulnerability?
  2. What is the difference between authentication and authorisation?
  3. Why are hidden SSIDs and MAC allowlists weak primary security controls?
  4. What security properties can authenticated encryption provide?
  5. Why must VPN routes be tested after successful user authentication?

Long Answer Questions

  1. Explain a professional methodology for assessing firewall rules and network segmentation.
  2. Compare personal and enterprise wireless security, including authentication, administration and isolation.
  3. Describe the major areas of a TLS and certificate-management review.
  4. Discuss how poor key management can undermine otherwise strong cryptographic algorithms.
  5. Explain the ethical, privacy and governance requirements for handling packet captures during a penetration test.

Analytical / Application Questions

  1. A guest wireless client can reach an internal DNS resolver and a management web interface, while ordinary users cannot. Analyse the likely control failure and propose a safe validation and remediation plan.
  2. A VPN contractor account authenticates with multi-factor authentication but receives routes to the entire server network. Assess the risk and design a least-privilege test and corrective approach.
  3. During an assessment, a corporate wireless client accepts an authentication server with an invalid certificate. Explain the attack opportunity, evidence that should be collected, immediate mitigation and longer-term control improvement.

Multiple Choice Questions with Answers

Question 1

Which statement best describes the purpose of network segmentation testing?

A. To prove that every host uses the same operating system

B. To verify that permitted and prohibited communication paths match policy

C. To replace the need for endpoint security

D. To identify the fastest Internet connection

Correct Answer: B. To verify that permitted and prohibited communication paths match policy

Question 2

Which firewall practice most directly supports least privilege?

A. Allowing all traffic from internal networks

B. Using broad any-to-any rules for convenience

C. Permitting only documented source, destination and service combinations

D. Disabling firewall logging

Correct Answer: C. Permitting only documented source, destination and service combinations

Question 3

Why is certificate validation important in enterprise Wi-Fi authentication?

A. It increases radio transmission power

B. It helps prevent clients from authenticating to an impersonating server

C. It hides the SSID from all receivers

D. It eliminates the need for user authentication

Correct Answer: B. It helps prevent clients from authenticating to an impersonating server

Question 4

Which item is an example of encoding rather than encryption?

A. Base64 representation

B. AES-GCM encryption

C. TLS session protection

D. Public-key encryption

Correct Answer: A. Base64 representation

Question 5

What is the principal security risk of transmitting credentials through Telnet?

A. The credentials may be exposed because the protocol lacks adequate confidentiality

B. The credentials are automatically converted into certificates

C. The service always prevents authentication

D. The protocol encrypts only usernames

Correct Answer: A. The credentials may be exposed because the protocol lacks adequate confidentiality

Question 6

Which VPN finding most clearly indicates excessive authorisation?

A. The VPN gateway records successful logins

B. A contractor profile can reach unrelated server subnets

C. The VPN uses an idle timeout

D. The gateway presents a valid certificate

Correct Answer: B. A contractor profile can reach unrelated server subnets

Question 7

What is the primary purpose of a unique salt in password storage?

A. To make the password recoverable in plaintext

B. To prevent identical passwords from producing identical stored values

C. To replace the need for a password-hashing function

D. To provide network segmentation

Correct Answer: B. To prevent identical passwords from producing identical stored values

Question 8

Which action is generally the safest initial validation of a suspected unencrypted internal service?

A. Delete the service database

B. Use a controlled test account and confirm the negotiated protocol

C. Publish captured traffic online

D. Perform an unapproved denial-of-service test

Correct Answer: B. Use a controlled test account and confirm the negotiated protocol

Question 9

What does rule shadowing mean in a firewall policy?

A. A firewall has no rules at all

B. An earlier rule prevents a later intended rule from being evaluated

C. A rule is stored in encrypted form

D. A firewall automatically creates wireless networks

Correct Answer: B. An earlier rule prevents a later intended rule from being evaluated

Question 10

Which statement about a VPN is most accurate?

A. A VPN automatically makes every endpoint trustworthy

B. A VPN removes the need for application-layer security

C. A VPN protects traffic between defined endpoints but does not guarantee endpoint or authorisation security

D. A VPN prevents all malware from using a connection

Correct Answer: C. A VPN protects traffic between defined endpoints but does not guarantee endpoint or authorisation security

Ethical Hacking & Penetration Testing
Chapter 9 of 15