Get the Preplance app for a seamless learning experience. Practice offline, get daily streaks, and stay ahead with real-time interview updates.
Get it on
Google Play
4.9/5 Rating on Store
Wipro · Ethical hacking
Practice Ethical hacking questions specifically asked in Wipro interviews – ideal for online test preparation, technical rounds and final HR discussions.
Questions
51
Tagged for this company + subject
Company
Wipro
View company-wise questions
Subject
Ethical hacking
Explore topic-wise practice
Go through each question and its explanation. Use this page for targeted revision just before your Wipro Ethical hacking round.
SYN scan sends a SYN and reads the response without completing the handshake. It is fast and common for discovery.
nmap -sS 10.10.10.0/24
For complete preparation, combine this company + subject page with full company-wise practice and subject-wise practice. You can also explore other companies and topics from the links below.
Pick passive to avoid touching the target and to move fast using third-party sources. Choose active when you have approval to probe and want deeper coverage with brute force, alterations, and DNS resolution checks. Many teams start passive, then confirm with limited active steps.
amass enum -passive -d example.com amass enum -brute -active -d example.com
Abuse testing can lock out users or flood logs. Use a test account, tiny volumes, and rate limits agreed in advance to avoid user impact.
authTest: account=test_user; maxAttempts=20; rate=1/min; stopOnAlert=true
Authorization proves consent and sets legal and safety limits. A good scope lists in-scope assets, time windows, contact paths, and what is out of bounds. This avoids accidental disruption and legal trouble.
Scope: targets=[api.example.com, 203.0.113.0/24]; OOS=[prod-db]; window=Sat 01:00–05:00; emergency=+1-555-0100
DoS can disrupt business. Most engagements forbid it unless there is an approved window, a lab environment, and explicit sign-off.
if (!scope.flags.allowDoS) { skip("no-DoS"); }NIST guidance emphasizes planning and authorization, then structured testing, analysis, and mitigation. This turns results into action and controls risk.
steps = ["plan", "test", "analyze", "mitigate"]
First, do no harm: prefer low-risk tests and avoid disruption. Second, respect privacy: minimize data collection and handle any sensitive data carefully. Third, act with integrity: be transparent, stay within scope, and report issues promptly. These build trust and keep testing both safe and useful.
Principles: minimize_impact; protect_data; follow_scope
Passive methods use third-party sources like search engines, C T logs, and public datasets. Active methods send probes to the target such as pings, scans, or HTTP requests.
Passive: site:example.com filetype:pdf Active: nmap -sV example.com
The site operator limits to a domain. The filetype operator limits to a specific document format, such as P D F.
site:careers.example.com filetype:pdf "confidential"
Metadata can leak creator names, tool versions, timestamps, and geo tags that support pivoting and social engineering.
exiftool report.pdf exiftool image.jpg | grep GPS
The capital letter O turns on OS detection using TCP and ICMP probes and fingerprint matching.
sudo nmap -O 10.10.10.10
Timing templates range from T0 to T5. T4 speeds up scans but may trigger controls. Use slower templates on fragile networks.
nmap -sS -T4 10.10.10.0/24
Scripts like smb-enum-shares and smb-enum-users query SMB services for share lists and account info when permissions allow.
nmap -p445 --script smb-enum-shares,smb-enum-users target
Fetch headers and titles, detect tech, and crawl a little. Probe for robots and common paths. Note redirects and status codes. Then run focused scripts or tools if allowed.
httpx -l hosts.txt -title -status-code -tech-detect curl -I https://site nikto -h https://site (only if approved)
Security misconfiguration covers things like verbose errors in production, open S three buckets, default accounts, and forgotten admin panels. The OWASP Top 10 describes this risk as common and easy to exploit when safe defaults and hardening aren’t applied.
# Example: nginx shows autoindex on prod
location /backup { autoindex on; }Keep an inventory of components, generate SBOMs, pin hashes, and apply timely updates. Add automated dependency scanning in CI. OWASP puts this category in the Top 10 because unpatched libraries are an easy path to compromise.
npm ci # uses lock file # add SCA step in pipeline
Encode output based on context. For HTML, attribute, and JavaScript contexts, use the correct encoder. Avoid innerHTML with untrusted data. Prefer textContent or safe templating. On the server, validate and normalize input, but do not rely on filtering alone. Add a Content Security Policy to limit script execution and third-party sources. Test with both reflected and DOM flows. Review risky sinks like eval, document.write, and innerHTML. OWASP’s XSS cheat sheets give concrete do and don’t rules you can follow.
result.textContent = userInput; // safer than innerHTML Content-Security-Policy: default-src 'self'
B O L A happens when the server does not check ownership for each object access. If the endpoint trusts a user supplied ID without verifying that the caller owns that object, attackers can simply swap the ID and access other users’ records. The fix is simple in idea but hard in practice: enforce server side authorization on every object access. Do not rely on hidden fields or client logic.
GET /api/orders/123 // attacker swaps to /api/orders/124 // Server must check: does caller own order 124?
Many leaks happen because APIs serialize entire objects. This can expose internal IDs, flags, and private data. A better pattern is to map data to a view model for each role and endpoint. Only include what a given caller needs. This also makes change control easier. New internal fields do not leak by accident because the projection is explicit.
// Good: map to view
{ "id": 123, "name": "Ana", "plan": "pro" }Rate limits, bursts, and quotas protect both users and systems. They make brute force and automation expensive and noisy. Pair them with lockouts, IP reputation, and user specific limits for stronger defense. Always communicate limits in headers so clients can handle retries gracefully.
HTTP/1.1 200 OK X-RateLimit-Limit: 100 X-RateLimit-Remaining: 42 Retry-After: 60
First, map the surface. List hosts, versions, and documented endpoints. Capture requests from a proxy and save example calls. Keep this passive and read only at the start. Next, probe with low risk checks: auth required, role rules, and object access. Try simple ID swaps to check for B O L A. Then review responses for extra fields and attempt property fuzzing to check for B O P L A or mass assignment. Finish with rate limit tests and error handling checks. Always stay within scope and use a test account.
1) Map endpoints 2) Check auth and roles 3) ID swap 4) Field fuzz 5) Rate limits 6) Error model
A gateway centralizes cross cutting controls: rate limits, authentication, TLS, request size caps, and basic schema checks. This reduces noise and protects fragile services. But it should not replace service side authorization and validation. Keep business rules inside the service so each call is still checked properly. The gateway handles the front door; the service enforces the house rules.
Gateway: authn, DDoS shield, size limits Service: authZ, field rules, business logic
Strong validation is a cheap shield. If you only accept known fields with the right types and ranges, many attacks never reach business logic. This also simplifies logging and analytics because inputs are predictable. Use the same schemas for docs, tests, and enforcement so drift does not creep in.
POST /users { email: string, name: string } // extra fields rejected
// Implement with JSON Schema or framework validatorsThink of it like dominos. One low-impact issue opens the door to the next issue, and so on. For example, info leak gives a secret, which lets you bypass auth, which then exposes an admin panel. Chaining small findings is how real attacks are built, so always ask, what does this enable next?
Example chain: info leak → weak token → admin panel → file upload → R C E
If a server deserializes data from the user without strict checks, attacker-controlled objects can trigger dangerous code paths. Safer designs use signed tokens, strict formats like JSON with schema checks, or a deny-by-default type binder.
Safer plan: JSON + schema validate → map to DTO → business object
First, confirm scope and the approved window. Use a dedicated test account or non-production path if possible. Start with a harmless probe that changes only the response, like echoing a token or adding a very small time delay. Do not read sensitive files, do not spawn shells, and do not change system state. Capture the exact request and response as evidence. Stop after minimal proof. Share impact, fix, and reproduction notes with the owner. Your goal is to prove risk, not to maximize it.
color=blue; echo SAFE_TOKEN_123 // look for SAFE_TOKEN_123 in response or logs
Start by reviewing server responses and storage paths. Try only benign file types first. Check if uploads are served back from a public path. If you suspect execution, ask for explicit approval before attempting any dynamic file. Use a harmless marker file to see if the server interprets it or just stores it. Never attempt dangerous payloads without written consent, and never overwrite existing files. If risk is confirmed, recommend strong controls: strict allowlist, magic-byte checks, storage outside web root, and a download proxy.
1) Upload benign.jpg → fetch via random URL 2) Verify no execution, only download behavior 3) Report evidence and propose controls
Credential stuffing is about replaying real pairs from past leaks. Brute force is about trying many guesses that the victim never used elsewhere. Defenses differ. For stuffing, use breach checks, rate limits, and multi factor. For brute force, use password policies and throttling.
Defend: MFA + rate limit + breached-password check
A per user salt makes identical passwords hash to different values. That kills precomputed tables and cross user comparisons. It does not replace a slow hash. You still need bcrypt, scrypt, or Argon two i d.
store: user, salt, argon2id_hash(salt + password)
First, verify scope, storage rules, and the allowed time budget. Identify the hash type. Then start with a strong wordlist and a few proven rules. Move to masks for company patterns, like season plus year. Keep logs of every attempt. Stop when you reach the agreed limit. Report cracked samples with redaction and immediately rotate or reset them with the owner. The goal is to measure risk, not to collect secrets.
hashcat -m 1000 hashes.txt rockyou.txt -r rules/best64.rule hashcat -m 3200 hashes.txt ?l?l?l?l?l?d?d
Revoke all old sessions and tokens. Rotate refresh tokens. Invalidate magic links. Ask the user to sign in again on all devices. Notify the user by email or push so they can spot abuse. Log the event with a trace id so support can help quickly.
onPasswordChange: revokeAllSessions(userId); rotateTokens(userId); sendSecurityNotice(userId)
Slow down and learn where you are. Confirm the host is in scope, note user, hostname, OS, network, and controls. This keeps the test safe and guides next steps.
whoami && hostname && ipconfig /all # Windows whoami && hostname && ip a # Linux
After a foothold, attackers pivot to new systems to reach targets. Ethical tests simulate this step with permissions and approvals in place.
Map paths: host A → share on host B → service token → host C
Built-in commands like PowerShell, WMIC, net, bash, or curl can help you enumerate with less friction. Use them ethically and only as scoped.
Windows: whoami; ipconfig; net use Linux: id; ip r; ss -tuna
Confirm identity and host details. List users, groups, scheduled tasks, running services, and listening ports. Check patch level and installed software. Look for misconfigurations like writable service paths or weak permissions. Keep commands read-only when possible and avoid heavy scripts. Take notes with timestamps so others can replay your steps.
Windows: whoami /all; systeminfo; tasklist; netstat -abno Linux: id; uname -a; ps aux; ss -tuna; crontab -l
Pick a low-impact, reversible method that is already approved, such as creating a disabled test user or a scheduled task that writes a harmless marker file. Document every step, set a short lifetime, and remove it during the same window. The goal is to help defenders validate detections, not to hide access.
Windows demo: schtasks /Create /SC ONCE /TN POC_Task /TR "cmd /c echo POC> C:\POC.txt" /ST 23:00 Cleanup: schtasks /Delete /TN POC_Task /F; del C:\POC.txt
Segmentation testing checks that boundaries hold. Guest, user, server, and admin networks should be isolated. If a low-trust zone can touch a crown-jewel host or port, that is a high-risk finding.
From guest → attempt TCP 1433 to DB Expected: blocked Observed: blocked or allowed → report
Dynamic ARP inspection checks ARP packets against trusted DHCP bindings. Combined with DHCP snooping and port security, it helps prevent simple spoofing on access segments.
Enable: dhcp snooping (trusted uplinks) → dynamic arp inspection on access
Port security limits how many MACs can appear on a port and what to do if a violation occurs. It reduces casual piggybacking and unmanaged hubs.
switchport port-security switchport port-security maximum 2 switchport port-security violation restrict
Work with the owner to list approved destinations like updates, identity, and CDN hosts. Send a handful of small, benign requests to a few disallowed categories to verify blocks. Log results with timestamps and source IP. Check if DNS allows external resolvers or only the corporate resolver. Recommend egress allow-lists and DNS egress pinning if gaps are found.
Test: curl https://blocked.example (expect deny) DNS: dig @8.8.8.8 example.com (expect blocked)
PSS policies block privileged containers, host mounts, and risky capabilities. Start with baseline and aim for restricted for most workloads.
kubectl label ns prod pod-security.kubernetes.io/enforce=restricted
Limit outbound so a compromised pod cannot freely reach metadata, unknown hosts, or exfil paths. Allow only the domains your app needs.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
spec:
podSelector: {}
policyTypes: [Egress]
egress:
- to:
- namespaceSelector: { matchLabels: { name: dns } }Require auth for pull and push. Enforce signed images. Scan on push and block critical findings. Use immutable tags or content digests. Prune old images on a schedule. Keep secrets out of build args and labels. Monitor download patterns to catch abuse.
Policy: signed-only, immutable tags, block HIGH/CRITICAL, retention 90 days
Robots guidelines sometimes include sensitive or obsolete paths that hint at admin or backup areas. It is a hint, not an access control.
curl -s https://example.com/robots.txt
Broken access control is number one because many apps fail to enforce ownership checks and authorization rules consistently. Typical signs are IDOR or BOLA issues, forced browsing to admin paths, and missing server-side checks. The OWASP Top 10 page highlights why this category moved to A zero one and why it maps to many CWEs across real apps.
GET /api/invoices/12345 // served without verifying the user owns 12345
WSTG is a community handbook with testing objectives, how-to steps, and references. It covers everything from mapping the app to detailed checks for input handling and authentication. Use it as a playbook for interviews and real projects.
WSTG sections: - Auth testing - Input validation - Config and deployment
Local File Inclusion stays within the host, like reading logs or config files. Remote File Inclusion lets the server fetch and sometimes execute remote content. Tight include logic and allowlists prevent both.
LFI probe: ?page=../../../../var/log/app.log
In relay, the attacker sits in the middle and forwards the handshake to a target. In pass the hash, the attacker uses the NT L M hash as if it were the password. SMB signing, LDAP signing, and Kerberos only help reduce both risks.
Mitigate: enforce SMB signing; restrict delegation; use Kerberos where possible
Use 802.1X with per-user credentials or certificates. Prefer WPA3-Enterprise and robust EAP methods. Avoid shared PSKs and legacy ciphers.
EAP-TLS or PEAP-MSCHAPv2 (with strong password policy and TLS checks)
Metadata services often hold tokens and role details for the instance. If an app allows server-side request forgery, attackers may reach metadata and fetch credentials. Lock down egress and use modern metadata protections.
AWS IMDSv2 example: curl -X PUT http://169.254.169.254/latest/api/token -H 'X-aws-ec2-metadata-token-ttl-seconds: 21600' TOKEN=... curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/
Security Groups remember connections per host and simplify rules. Network ACLs work at the subnet boundary and require explicit inbound and outbound entries.
aws ec2 describe-security-groups aws ec2 describe-network-acls