I wanted to understand what a careful, low-impact reconnaissance process looks like before any deeper security testing begins. The goal was not to “attack” a system, but to build an accurate map of publicly observable assets: domains, live hosts, technologies, directories, URLs, and authentication-related routes.

This exploration used Playtika’s authorized bug-bounty scope as the example. The in-scope target was the wildcard *.playtika.com, with the important restriction that only assets explicitly included by the program should be considered. Everything below focuses on discovery and documentation—not exploitation.

Problem statement

A large organization rarely has a single website. It may have APIs, shops, content sites, staging systems, CDN hosts, game services, administrative applications, and older endpoints spread across many subdomains. Looking only at the main homepage can therefore miss most of the observable attack surface.

The practical problem was to answer six questions:

  • Which subdomains can be identified from public sources?
  • Which of those hosts respond over HTTP or HTTPS?
  • What technologies and version clues are exposed?
  • Which directories and URLs are visible through normal discovery and crawling?
  • Which assets deserve attention based on function and naming?
  • Can an AI-assisted wordlist organize what has already been observed without inventing unsupported names?

Step-by-step reconnaissance workflow

1. Confirm the authorization boundary

Before running tools, I recorded the target and scope:

Program: Playtika bug bounty
Target: *.playtika.com
Rule: include only assets listed by the program; exclude anything outside the published scope
Enter fullscreen mode Exit fullscreen mode


Caption: Capture the program page showing the authorized `.playtika.com` wildcard and the exclusion notice for domains or applications not specifically included.*

This scope check matters because a wildcard alone does not automatically authorize every related service, third-party hostname, or discovered dependency.

2. Enumerate subdomains with Subfinder

I used Subfinder to collect publicly discoverable subdomains, then sorted and deduplicated the results:

subfinder -d playtika.com -silent | sort -u | tee playtika_subdomains.txt
Enter fullscreen mode Exit fullscreen mode

The document shows examples such as api.playtika.com, account.hof-dsa.playtika.com, admin.cc-api-dsa.playtika.com, assets.wsop.playtika.com, and many CDN, API, pre-production, and game-related names.


Caption: Capture the first visible portion of the Subfinder output, including several discovered subdomains.

Caption: Capture the terminal command that writes sorted unique results to playtika_subdomains.txt.

To count the result set, I used:

wc -l playtika_subdomains.txt
Enter fullscreen mode Exit fullscreen mode

The recorded result was 447 unique subdomains.

Caption: Capture the wc -l output showing 447 playtika_subdomains.txt.

3. Probe for live HTTP and HTTPS hosts

Next, I reduced the subdomain list to hosts that responded to web probes:

httpx-toolkit -l playtika_subdomains.txt -silent -o playtika_live_hosts.txt
Enter fullscreen mode Exit fullscreen mode

The document records 95 live HTTP/HTTPS hosts.


Caption: Capture the live URLs produced by the HTTP probing step.


Caption: Capture the command and output showing 95 playtika_live_hosts.txt.

For a more useful first-pass fingerprint, I also collected status codes, page titles, and detected technologies:

httpx-toolkit -l playtika_live_hosts.txt -silent -status-code -title -tech-detect -o playtika_tech.txt
Enter fullscreen mode Exit fullscreen mode

Examples in the output included:

  • cdn-shop.playtika.com returning 200, with HTTP/3 and HSTS indicators.
  • events.playtika.com returning 200, with Cloudflare, HTTP/3, HubSpot, HubSpot CMS Hub, and LinkedIn Ads indicators.
  • octopus.playtika.com returning 200, titled Octopus Ad Manager.
  • Several hosts returning 301, 404, or Access Denied, which is still useful context during inventory building.


Caption: Capture representative lines from playtika_tech.txt showing status codes, titles, and technology fingerprints.

4. Review technology fingerprints

The identified technologies included:

  • Cloudflare and Cloudflare Bot Management
  • HTTP/3 and HSTS
  • Nginx and Varnish
  • Bootstrap, jQuery, jQuery UI, and Slick
  • HubSpot CMS Hub
  • Google Cloud/CDN and Platform.sh
  • Hugo 0.125.7
  • Nginx 1.22.0
  • OneTrust

Version clues are not vulnerabilities by themselves. They are useful for understanding the stack, checking documentation, and deciding where careful, authorized review may be appropriate.

5. Run conservative directory discovery with FFUF

I tested the main web host with FFUF using the SecLists common directory wordlist and matched common successful or redirect status codes:

ffuf -u https://ww.playtika.com/FUZZ \
  -w /usr/share/seclists/Discovery/Web-Content/common.txt \
  -Mmc 200,204,301,302,307,308 \
  -o playtika_dirs.json -of json
Enter fullscreen mode Exit fullscreen mode

The recorded scan used 40 threads, a 10-second timeout, and completed 4,750 wordlist requests without errors.


Caption: Capture FFUF’s URL, wordlist, matcher, thread count, timeout, and completed scan summary.

I also ran a second pass with a smaller directory-focused wordlist:

ffuf -u https://ww.playtika.com/FUZZ \
  -w /usr/share/seclists/Discovery/Web-Content/common_directories.txt \
  -mc 200,204,301,302,307,308 \
  -o playtika_dirs2.json -of json
Enter fullscreen mode Exit fullscreen mode


Caption: Capture the second FFUF command using common_directories.txt and its completed run.

The important result was negative: these FFUF scans did not produce additional matching directories in the recorded work. That does not prove that no other paths exist; it only describes what these wordlists and response filters found.

6. Check robots.txt and sitemap.xml directly

Public metadata files often reveal useful navigation information without brute forcing. I checked their status and final URL first:

curl -s -o /dev/null -w "%{http_code} %{url_effective}\n" \
  https://ww.playtika.com/robots.txt

curl -s -o /dev/null -w "%{http_code} %{url_effective}\n" \
  https://ww.playtika.com/sitemap.xml
Enter fullscreen mode Exit fullscreen mode

Both returned HTTP 200.


Caption: Capture the two curl checks showing successful responses for robots.txt and sitemap.xml.

I then read their contents:

curl -s https://ww.playtika.com/robots.txt
curl -s https://ww.playtika.com/sitemap.xml
Enter fullscreen mode Exit fullscreen mode

The robots file pointed to the sitemap. The sitemap exposed paths including:

  • /careers/
  • /get-to-know-us/
  • /games/
  • /life-at-playtika/
  • /in-the-press/
  • /press-releases/
  • /careers/security-it/
  • /careers/data-science/
  • /careers/research-development/

The paths most worth reviewing next were /careers/, /games/, /get-to-know-us/, /press-releases/, and /careers/security-it/. The next safe step would be to inspect links, forms, parameters, JavaScript references, and access controls without attempting to bypass them.

7. Crawl URLs and application routes with Katana

To discover links and client-side resources exposed through the web application, I crawled the main host with Katana:

katana -u https://www.playtika.com -silent -o playtika_katana.txt
Enter fullscreen mode Exit fullscreen mode


Caption: Capture the Katana command and representative URLs returned by the crawl.

The crawl produced 1,330 unique URLs:

sort -u playtika_katana.txt | wc -l
Enter fullscreen mode Exit fullscreen mode 
1330
Enter fullscreen mode Exit fullscreen mode


Caption: Capture the deduplication/count command and the 1330 result.

I also filtered the collected URLs for JavaScript resources:

sort -u playtika_katana.txt | grep -Fi '\.js' | head -50
Enter fullscreen mode Exit fullscreen mode

The results included JavaScript from contactus.playtika.com, news.playtika.com, Cloudflare Rocket Loader, OneTrust, jQuery, Bootstrap, Slick, and other application resources. JavaScript files can reveal route names and integration points, but they should be treated as clues for authorized review—not as an invitation to probe unrelated services.


Caption: Capture the filtered list of .js resources, including application-hosted and third-party scripts.

The most notable application paths were under contactus.playtika.com, including login, SSO, password-reset, and other .do routes. The later summary identified examples such as:

/contact
/amb_login.do
/login_locate_sso.do
Enter fullscreen mode Exit fullscreen mode

These routes were considered interesting because authentication and account-recovery workflows are security-sensitive, not because their names alone demonstrate a flaw.

8. Build an AI-assisted wordlist from observed terms

I extracted terms from the discovered subdomains by removing the base domain, splitting on dots and hyphens, and sorting unique values:

cat playtika_subdomains.txt \
  | sed 's/\.playtika\.com//g' \
  | tr '.-' '\n' \
  | sort -u > playtika_terms.txt

wc -l playtika_terms.txt
Enter fullscreen mode Exit fullscreen mode

The initial file contained 297 terms. I then filtered it to clean alphabetic/underscore-style entries:

grep -E '^[a-zA-Z][a-zA-Z0-9_]*$' playtika_terms.txt \
  | sort -u > playtika_clean_terms.txt

wc -l playtika_clean_terms.txt
head -50 playtika_clean_terms.txt
Enter fullscreen mode Exit fullscreen mode

The cleaned file contained 290 terms.


Caption: Capture the commands producing playtika_terms.txt, the count of 297, and representative extracted terms.


Caption: Capture the filtering command, the count of 290 cleaned terms, and the beginning of the cleaned list.

The prompt used for organization was intentionally restrictive:

You are assisting with authorized bug-bounty reconnaissance for an in-scope wildcard target: *.playtika.com.

Below is a list of terms extracted from discovered subdomains:
[insert the contents of playtika_clean_terms.txt]

Create a clean, categorized reconnaissance wordlist using only terms supported by the provided data.

Categories:
1. API/authentication
2. Administrative/management
3. Development/staging
4. Web/content
5. Cloud/infrastructure
6. Game/application-specific
7. General useful terms

Remove obvious noise, duplicates, and meaningless fragments.
Do not invent organization-specific terms that are not supported by the input.
Return only the categorized wordlist.
Enter fullscreen mode Exit fullscreen mode

Useful categorized entries included:

  • API/authentication: account, api, auth, capi
  • Administrative/management: admin, analystday, award, center, automation, achievements, challenges
  • Development/staging: alpha, beta, builds, ci, ce
  • Web/content: blog, assets, cdn, chat
  • Cloud/infrastructure: aws, accelerator, ams, autoconfig, autodiscover, cert, analytics
  • Game/application-specific: bestfiends, bingo, bingoblitz, blitz, bonus, card, caesarsgames
  • General: app, android, ads, bot, addub, cc

The AI did not discover a new subdomain or endpoint solely from this wordlist. Its practical value was organization and prioritization of evidence already collected.

9. Prioritize the attack surface without exploiting it

Combining host names, live status, technology clues, and crawled routes produced a practical priority list.

Priority Asset Why it stood out
High contactus.playtika.com Authentication, SSO, password-reset, and .do routes were observed
High api.playtika.com Clearly identified API endpoint
High prod-api-epayments.playtika.com Explicitly payment-related production API hostname
High preprod.playtika.com Pre-production environment
High events.playtika.com Live application with identifiable HubSpot and Cloudflare technology
Medium www.playtika.com Main web application with detailed technology fingerprint
Medium shop.playtika.com Live commercial web application
Medium news.playtika.com Live content application with several JavaScript technologies
Medium one-prod.playtika.com Production-related service hostname
Medium octopus.playtika.com Live application identified as Octopus Ad Manager

Manual review broadly agreed with this AI-assisted prioritization. The strongest recurring signals were authentication, APIs, payment-related naming, production/pre-production separation, and the size of the URL corpus.

How to Verify

Readers reproducing this workflow should use a target they own or a program that explicitly permits the activity.

  1. Confirm the target, wildcard rules, exclusions, rate limits, and reporting requirements.
  2. Install the exact tool versions available in your environment: Subfinder, httpx-toolkit, FFUF, Katana, and SecLists.
  3. Run Subfinder and verify that the output file contains one hostname per line.
  4. Use sort -u and wc -l to reproduce the deduplicated subdomain count.
  5. Probe only in-scope hosts with httpx-toolkit and save the live list.
  6. Compare playtika_tech.txt with the recorded status codes, titles, and technology indicators.
  7. Run FFUF conservatively, keep the thread count and matchers documented, and inspect the JSON output rather than assuming every redirect is a real directory.
  8. Request robots.txt and sitemap.xml directly and compare the listed paths.
  9. Crawl the authorized main host with Katana, then run sort -u ... | wc -l to verify the URL count.
  10. Extract terms only from observed hostnames, apply strict cleaning, and ensure the AI prompt forbids invented entries.
  11. Review the final inventory manually. A priority label is a hypothesis for further authorized review, not proof of a vulnerability.

What I Learned

I learned that reconnaissance is most useful when it is treated as a chain of evidence rather than a collection of disconnected tool outputs. Subfinder showed the breadth of the namespace, httpx-toolkit separated names from reachable web services, and Katana connected those services to real application paths and JavaScript resources.

The sitemap was also a good reminder that straightforward sources can be more valuable than aggressive guessing. FFUF did not add matching directories in this work, while robots.txt and sitemap.xml exposed meaningful content paths.

The AI step was helpful, but not magical. It organized observed terms and highlighted sensible categories; it did not produce a new asset. I also came away with a stronger appreciation for scope checking and documentation. A host that looks interesting is still out of bounds if the program does not include it.

Common Mistakes

Mistake Why It Happens How to Fix
Treating every discovered hostname as authorized Enumeration reveals names outside the actual program boundary Check every asset against the published scope before probing it
Counting duplicate subdomains or URLs Multiple sources and crawl paths produce repeated entries Use sort -u before counting
Assuming a live host is a vulnerability A 200, 301, or identifiable technology only proves reachability or exposure Record it as an observation and perform only permitted follow-up checks
Interpreting version disclosure as an exploit Version strings feel more conclusive than they are Validate context and avoid exploit attempts unless explicitly authorized
Over-trusting FFUF results Wordlists, filters, redirects, and wildcard responses can distort output Compare status, size, title, and baseline responses; review JSON results
Ignoring robots.txt and sitemaps They look too ordinary to be security-relevant Read them early as low-impact sources of application paths
Using AI to invent names A model may fill gaps with plausible-looking terms Provide observed data only and require evidence-backed output
Treating login or password-reset paths as proof of weakness Sensitive functionality is interesting but not automatically insecure Document the route and stop at authorized, non-destructive verification
Running scans too aggressively High concurrency can affect availability and violate program rules Use conservative settings, respect rate limits, and monitor errors

Conclusion

A repeatable reconnaissance workflow can turn a broad wildcard into a structured inventory without crossing into exploitation. In this exploration, Subfinder identified 447 unique subdomains, httpx-toolkit found 95 live HTTP/HTTPS hosts, and Katana collected 1,330 unique URLs. Technology fingerprinting, sitemap review, and JavaScript filtering added context that raw hostnames could not provide.

The most valuable outcome was not a single “magic” finding. It was the combined picture: which services exist, which ones respond, how they are built, where application paths are exposed, and which assets deserve careful authorized review. That is the foundation for responsible security testing.