So when running the deep dive on a target where i know that one of the fuzz words should resolve they are all marked as failed. I did change something previously about string sanitizing related to injection. Maybe i did something or changed something.

But now when it resolves it's not getting the correct classes set. Therefore breaking the functionality.

Added new toolbox item "Hash Attacking" that lookup a hash it can detect and tries to find the reverse text. Also known as hash brute forcing. We don't actually do any brute forcing as we use an external site.

This is not yet hook into the "privacy mode" so even if privacy mode is enabled this tool will still work. This needs to be fixed in a future update.

Also we fixed some problems with the resource monitor showing wrong numbers for "MEM Used"

We need to have a toolbox lookup item for crackfoo.net. The do have an api interface but to keep the app free of api key settings for every e terns service for now I would rather have we parsed the results directly on the sites.

Included is example in such solution

curl -sX POST "http://crackfoo.net/?algo=$2" -d "hash=$1&sa=Search" | grep SUCCESS | awk '{print$9":"$13 }'

So whats new ?

• TXT records now do fingerprinting for vendor verification strings !
• Fingerprint json file completion
• Adding new fingerprint issue for (things not added yet)
• Internal whois client bug fixes (now supports timeout and tells you about it)
• Added Discord community link to README
• Changed Streamer mode to Privacy mode. Better name. (For anyone who dont know, privacy mode disabled any api calls the application makes. Not the "intel" items but public ip api call etc.)

New overhaul on store defaults/scheme validation. Now there is proper config validation and default values to return if config file is out of sync etc.

More work on DNS deep dive redjoust item. It now does Host subdomain fuzzing ! With a static limited list and also custom list via config file. So you can have your own custom fuzz words you always fuzz for even if i change up the static list.

In the Fuzz grid output list, you can see if a subdomain resolves to IPv4 (A) and/or IPv6 (AAAA). Also if you click one that resolves you will set that "subdomain/fuzz".oldtarget as your new target ! Makes it easy to traverse down the rabbit hole :D

Also the MX lookup is now done.

When adding more than 50 (default) targets next time you start Redjoust it's supposed to clean up the history list of old targets. Removing so there is only the last 50 targets saved. Obviously it should remove old-targets first :)

Behavior expected / Reproduce

• Add "target 1"
• Add 49 more
• Add "target 51"
• Expect on next startup that "target 1" is removed

Actual behavior

• "target 51" is removed

I know that iknowwhatyoudownload.com requires API, so i will instead build a crawler and parse the site live. This will no doubt mean more work and things fail when ever they change up their site :) But it also means that i can keep the application from the need to etc share an api key or that the "user" suddenly is responsible for getting an API key in order for that item-lookup to work.

This is still just a "nice to have" idea. Would obviously be a "passive" item under "IP target".

I know that abuseipdb.com requires API, so i will instead build a crawler and parse the site live. This will no doubt mean more work and things fail when ever they change up their site :) But it also means that i can keep the application from the need to etc share an api key or that the "user" suddenly is responsible for getting an API key in order for that item-lookup to work.

This is still just a "nice to have" idea. Would obviously be a "passive" item under "IP target".

Overall "Recon Items" list for needed startup passive,active and redteam items

Ths is the overall list that we want to fufill before releaseing the first beta test client of Redjoust. We want a few items in each category before we start up. Please remember we have 3 target types and 3 item types. So if we list it as seen from item types then you need to provide what target types it supports

PASSIVE items

For now we start with a total of 5 passive items showing

• [ ] DNS Deep-Dive ( #23 )
  • Show on domain target
  • Show on host-name target
• [ ] Certificate Transparency (CT) Lookup ( #24 )
  • Show on domain target
• [x] Whois
  • Show on domain target
  • Show on IP target

ACTIVE items

For now we start with a total of 4 active items showing

• [ ] Simple service detector (port-scanning)
  • Build up overview of each target and save result for them
  • Show on host-name target
  • Show on domain target
• [ ] HTTP/Web Digger
  • Available if sub-target port 80,443 found in service results (Not sure how this will work)
  • Show on host-name target
  • Show on domain target

REDTEAM items

For now we start with a total of 1 redteam items showing

• [ ] Web Fuzz (Simple)
  • Available if sub-target port 80,443 found in service results (Not sure how this will work)
  • Show on host-name target
  • Show on domain target

Certificate Transparency (CT) Searching/Lookup item

I need to construct the last passive item module i need for the first beta test release. Then i need to move on to the active items. But for now we need a CT lookup item.

I will try to make it so that at least it's showing the same as my recon-ct script.

Fingerprinting vendor verification strings

This might be a long "task" as it's ever growing. All fingerprints i find along the way will be added here and once added to the JSON file with regexp, descriptions and a title it can be checked as done for each one. This list does not include the already 25 fingerprints i have added. So please before adding new string here, check if it's already in the file by doing a:

Want to contribute ? This is the file we are working on: https://github.com/kawaiipantsu/redjoust/blob/dev/assets/json/online-service-provider-fingerprint.json

The steps to help: Basically the task is to choose a verification-string from below and then do the following research:

• Figure out who it belongs to
• Figure out the specific service/product it belongs to
• Figure out the simplest regex to uniqliy identify it
  • 1. a test regexp
  • 2. a match regexp (that matches the hash/data)
• Use the JSON template and add it to the file :)

JSON Template for new fingerprint

{
    "fingerprintName": "<short 40-70chars detailed output string for fingerprint>",
    "inCategoeries": [0],
    "serviceProvider": {
        "name": "<company name>",
        "desc": "<company short info>",
        "url": "<company/product link>"
    },
    "serviceHash": {
        "original": "<verification string as seen in the wild/from the task list)>",
        "comment": "",
        "regexp": {
            "test": "/^<regexp-test>/i",
            "match": "/^<regexp-match (.+)>/i"
        }
    }
}

# To list all known test strings
cat online-service-provider-fingerprint.json | jq '.knownFingerprints[].serviceHash.regexp.test'

# To search for a specific string
cat online-service-provider-fingerprint.json | jq '.knownFingerprints[].serviceHash.regexp.test' | grep "string"

Vendor verification strings seen in the wild

This is the list of evergrowing strings seen in the wild that i would love to be able to fingerprint :) So digg in !!

• [ ] _spf.q4press.com.
• [ ] 126953328-4422040
• [ ] 688162515-4422037
• [ ] 8RPDXjBzBS9tu7Pbysu7qCACrwXPoDV8ZtLfthTnC4y9VJFLd84it5sQlEITgSLJ4KOIA8pBZxmyvPujuUvhOg==
• [ ] 9rHeUd6AiQ30jFgENxeGX6CKgbSmFB/NeV5oCOQS5PbafVN66NOLFLcsuixmOo1krFPgHLMt7TCEL3iJOUF1mQ==
• [ ] d1xTs9+kADZZSz3bPphLpkMXXxBGjqn5vsQHhi2M6lo0r8AdIbm6j8LfQXPujsywVgeGSP+AXWX0vO9Iep5cUg==
• [ ] zpSH7Ye/seyY61hH8+Rq5Kb+ZJ9hDa+qeFBaD/6sPAAg+2POkGdP0byHb1pFVK9uZgYF2AIosUSZq4MB17oydQ==
• [ ] SUyD3kNWX8BcKENoplaQAU6nSMzvEsoota+RWH5YYE3xC7oadZybEhbiad16zkVvg0H/hifubMBuZS50OVuBgQ==
• [ ] 907D-6CE2-7BD0-FF0C-7E83-E21D-AD2B-DD27
• [ ] 926723159-3188410
• [ ] adobe-aem-verification=www-idev-cloud.cisco.com/24859/366204/1b990ef7-ff88-4938-bdd9-8458cc152f57
• [x] adobe-idp-site-verification=c900335b8b825859b51473b9943a3880ae795df47426483b0a67630377a902f5
• [ ] aliyun-site-verification=47b62ce6-8506-41f0-bb2f-07b3a645d506
• [ ] apple-domain-verification=qOInipPgso3W8cmK
• [ ] asv=ac90e11808e87cfbf8768e69819b1aca
• [ ] bugcrowd-verification=4cb12e80d1cc53286a15726ee4bf8f6e
• [ ] c900335b8b825859b51473b9943a3880ae795df47426483b0a67630377a902f5
• [ ] campaign.dev.lcorigins.lego.com=l8qgvnfp0t9totd0c69s4t988i
• [x] cloudhealth=1659ead7-5c47-4817-a0d3-94b456169734
• [ ] d365mktkey=4d8bnycx40fy3581petta4gsf
• [ ] docker-verification=c9680cb5-881b-4f8b-a803-42a918cdcf57
• [ ] duo_sso_verification=ntfsmAmvYMYMnwjgk6SpssPl5t7hZADsv9NCBLtCS7AnylaapsIfsFB9k6PItJVr
• [ ] Dynatrace-site-verification=e1eb3fe5-f14a-4a0c-b8b6-1c5f380cb804__dfadqbk4o2ngu8n8bho3kom0t
• [x] fastly-domain-delegation-w049tcm0w48ds-341317-20210209
• [ ] identrust_validate=JnSSfW+y58dEQju6mVBe8lu1MGFepXI50P27OE1ZZQmL
• [ ] intercom-domain-validation=8806e2f9-7626-4d9e-ae4d-2d655028629a
• [ ] mailigen-site-verification=58788cc4908d5697c6ea4801a7fea3f6
• [ ] mbnfb6mopftl3f3t2it9tbev6e
• [ ] miro-verification=53bf5ccd47cb6239fe5cf14c3b328050dd5679ac
• [ ] mixpanel-domain-verify=2c6cb1aa-a3fb-44b9-ad10-d6b744109963
• [ ] mixpanel-domain-verify=612e2914-a7fb-4965-95d5-19acc02797df
• [ ] mongodb-site-verification=mtrxHeW3jOzWtwEwnOLpeQo9NXh6Lqas
• [ ] MS=B03F616C5688CE657CC2FA94EF4E72109431092B
• [ ] NS_monitor
• [ ] onetrust-domain-verification=20345dd0c33946f299f14c1498b41f67
• [ ] OSSRH-65508
• [ ] pbcpcw84sfk7w4nhm7dwyg2k3gx0t4xr
• [ ] prod-bec-dk.azurewebsites.net
• [ ] QuoVadis=94d4ae74-ecd5-4a33-975e-a0d7f546c801
• [ ] SFMC-o7HX74BQ79k7glpt_qjlF2vmZO9DpqLtYxKLwg87
• [ ] site24x7-signals-domain-verification=df57290b9f0e5eb1fbcaca5849cc43b5
• [ ] sonatype-verification=OSSRH-58518
• [ ] sprig-site-verification=p7Xa5X9lnBvzD3plB6lcrXfhabY2uX3NAwyEGPm4C98
• [ ] stripe-verification=c52e56dae78932924b24e718a7850f861712da65458f8c40bab37393ccb56854
• [ ] t7sebee51jrj7vm932k531hipa
• [ ] teamviewer-sso-verification=db1a05bb09054296b4fad49caec6cdc9
• [ ] wiz-domain-verification=af241e6396696eedf1b361891435f6b21bdebb5621941d99279298c076b5bf5f
• [ ] wrike-verification=MzI3NzM2ODo2NDk5MjE4NjQ2MWJmOTEwMGMxM2MzNzJmNWJlY2U5ZDU4MmVlNzQ2NWU4MTY5OWJjMjlmYjQ4Mjc5M2JiMzky
• [ ] ZOOM_verify_PeuZagN7TzybBaD-uxsGAw
• [ ] Zoom=13284637

The current preferences window is not very useful, so far i have only made it so that it shows the users config file directly as it's loaded by the electron-storage module. We need to make the preferences page into an actual thing that can change the settings.

Task

• It should be able to change all config options (that are use related)
• Dynamically applied, no need for "apply/save"
• Show what is default values
• Extra things that might be cool
  • Option to open config directly in editor for "advanced" operation
  • Import / Export features