Jobs
A job is the way for Red Kite to find new information. It is started by Red Kite and runs in a contained environment. Different jobs will generate different findings. It is possible to reference a Finding's output variable as a job parameter. A job parameter is one of a job's input variables.
When referencing a Finding's output variable by name (ex: ${domainName}), the variable name is case insensitive.
A job can generate multiple findings of one or many finding types.
Types of Jobs
Multiple types of jobs are supported in Red Kite.
The types of jobs are:
More information about the implementation of jobs is available in the development section of the documentation.
Python Job
| Type | Language |
|---|---|
| Code | Python |
A python job is the standard way of making a job. It gives you full flexibility, but you have to implement it yourself.
The python jobs come with a built-in SDK to help you properly output findings and logs.
Nuclei Job
| Type | Language |
|---|---|
| Nuclei | Yaml |
A Nuclei job uses Project Discovery's Nuclei to run Nuclei templates and output findings that Red Kite understands. It comes with a built-in parser, but if it does not suit your needs, you can specify a custom finding handler. This custom finding handler will be responsible for parsing the Nuclei Findings as well as outputing the Red Kite compatible findings. It is implemented in python. Don't worry though, a template, a custom class and the python SDK are avalailable to help you.
Built-in Jobs
Red Kite comes preloaded with a robust selection of built-in jobs directly sourced from our official jobs repository.
Built-in jobs are managed by Red Kite and therefore cannot be modified. If you wish to tweak one of our jobs, you may simply duplicate it and edit the copy. When you are ready, use the copy and disable the original.
| Name | Description | Type | Language |
|---|---|---|---|
| DomainNameResolvingJob | Resolves a domain name to an IP address | Code | Python |
| TcpPortScanningJob | Scans the tcp ports of an IP address | Code | Python |
| TcpIpRangeScanningJob | Scan an IP range for open ports | Code | Python |
| BannerGrabbingJob | Identifies the service running on a port | Code | Python |
| WebsiteCrawlingJob | Crawls a website for its valid endpoints | Code | Python |
| LoginDetectionJob | Detects login portals on websites | Nuclei | Yaml |
| WebsiteScreenshotJob | Takes a screenshot of a web page. | Code | Python |
| AmassDomainDiscoveryJob | Leverages Amass to find domain related information | Code | Python |
While
DomainNameResolvingJob
A DomainNameResolvingJob takes a domain name and resolves it to one or more IP address.
Input variables :
| Variable Name | Type | Value Description |
|---|---|---|
| domainName | string | An FQDN to resolve to an IP address |
Possible generated findings :
- HostnameIpFinding
TcpPortScanningJob
Scans the TCP ports of a host.
Input variables :
| Variable Name | Type | Value Description |
|---|---|---|
| targetIp | string | The Host's ipv4 address to scan. |
| threads | number | The number of active threads to scan. 1 <= t <= 1000 |
| socketTimeoutSeconds | number | How long the scanner waits before declaring a port as closed and timing out, in seconds. A floating point number. 0 < t <= 3 |
| portMin | number | The first port to scan. 1 <= portMin < portMax |
| portMax | number | The last port to scan. portMin < portMax <= 65535 |
| ports | number[] | A JSON array. Every port mentionned in it will be scanned. Ex: [3389, 8000, 8080, 8443] |
Possible generated findings :
- PortFinding
TcpIpRangeScanningJob
Scans an IP range (ex: 1.2.3.4/24) for open ports. It discovers hosts that way and reports the ports as open.
Input variables :
| Variable Name | Type | Value description |
|---|---|---|
| targetIp | string | The range's IP to scan |
| targetMask | number | The range's mask, like 16 for /16 |
| rate | number | Masscan's scanning rate (packets/second) |
| portMin | number | The first port to scan. 1 <= portMin < portMax |
| portMax | number | The last port to scan. portMin < portMax <= 65535 |
| ports | number[] | A JSON array. Every port mentionned in it will be scanned. Ex: `[3389, 8000, 8080, 8443] |
Possible generated findings :
- HostFinding
- PortFinding
BannerGrabbingJob
Identifies the service running on a port and grabs the banner. It may occasionally find which OS the host is running on and sometimes other domain names as well.
Input variables :
| Variable Name | Type | Value description |
|---|---|---|
| targetIp | string | The IP address to check |
| ports | number[] | The ports to check for a service |
| nmapOptions | string | A long string containing the options given to nmap |
Possible generated findings :
- PortServiceFinding
- HostnameIpFinding
- OperatingSystemFinding
WebsiteCrawlingJob
Crawls a website for its differents valid endpoints. It can also find website technology information.
Input variables :
| Variable Name | Type | Value description |
|---|---|---|
| targetIp | string | The website's IP address |
| port | number | The website's port |
| domainName | string | The website's domain name |
| path | string | The website's base path |
| ssl | bool | If the website is https |
| maxDepth | number | The depth to crawl |
| crawlDurationSeconds | number | The max amount of time to crawl in seconds |
| fetcherConcurrency | number | The number of concurrent fetchers to get data |
| inputParallelism | number | The number of concurrent inputs pprocessor |
| extraOptions | string | Katana extra options to adapt execution |
Possible generated findings :
- WebsitePathFinding
- WebsiteTechnologyFinding
LoginDetectionJob
Detects a login page based on regex and word match.
Input variables :
| Variable Name | Type | Value description |
|---|---|---|
| targetIp | string | The website's IP address |
| port | number | The website's port |
| domainName | string | The website's domain name |
| path | string | The website's base path |
| ssl | bool | If the website is https |
| endpoint | string | The website's endpoint to target |
Possible generated findings :
- WebsiteLoginPortal
- Login
WebsiteScreenshotJob
Takes a screenshot of a web page.
Input variables :
| Variable Name | Type | Value description |
|---|---|---|
| targetIp | string | The website's IP address |
| port | number | The website's port |
| domainName | string | The website's domain name |
| path | string | The website's base path |
| ssl | bool | If the website is https |
| endpoint | string | The website's endpoint to target |
| finding | string | (Optional, default: WebsiteScreenshotFinding) The name of the emitted finding |
| findingTitle | string | (Optional, default: Website screenshot) The title of the emitted finding |
Possible generated findings :
- WebsiteScreenshotFinding
AmassDomainDiscoveryJob
This feature is part of our Enterprise version, offering advanced tools and premium support to elevate your workflow. Get in touch today and discover how we can help you achieve more!
Leverages OWASP's Amass to find domain relationships, subdomains, IP addresses, organizations, etc.
Input variables :
| Variable Name | Type | Value Description |
|---|---|---|
| domainNames | string[] | An FQDN array to resolve to IP addresses |
| timeoutMinutes | number | A timeout for Amass, in minutes |
Possible generated findings :
- HostnameFinding
- HostnameIpFinding
- IpFinding
- AmassDomainReportFinding
- AmassHostReportFinding
- RirOrgFinding
Also, Amass uses the datasources.yaml file to store the API keys of several possible data sources. To use this feature in Red Kite's job, you can dynamically provide the datasources.yaml values as parameters from Red Kite secrets by following the proper syntax.
Setting a datasource API key for Amass
To set an API key in the datasources.yaml content from a Red Kite parameter, simply follow the variable naming convention s_NAME_path_to_key, which consits of the prefix s_, the targeted datasource name in place of NAME, an underscore _, and then the full yaml path to the API key to set. The job looks for parameters named that way to dynamically fill the yaml file.
As an example, the API key for the Shodan datasource will be set:
First, create a secret containing Shodan's API key. Use a meaningful name like ShodanApiKey.
Second, use the ShodanApiKey secret in a job parameter. To do so, we need to locate where in the datasources.yaml file structure the key is located.
Here is, for reference, part of the datasources.yaml file where we want to set the Shodan API key :
datasources:
- name: 360PassiveDNS
ttl: 3600
creds:
account:
apikey: null
# [...]
- name: Shodan # The targeted datasource name
ttl: 10080
creds:
account:
apikey: null # Where we set the API key
- name: Spamhaus
ttl: 1440
creds:
account:
username: null
password: null
# [...]
global_options:
minimum_ttl: 1440
The full file structure is available on the repository.
Here, to set Shodan's API key, you would have to name your job parameter s_Shodan_creds_account_apikey and set the value from the created secret ShodanApiKey.
For an ad-hoc job launch, your parameters would therefore look like the following:
parameters:
- name: domainNames
value:
- example.com
- www.example.com
- name: timeoutMinutes
value: 120
- name: s_Shodan_creds_account_apikey # The variable name referencing the location in datasources.yaml
value: ${ secrets.ShodanApiKey } # The injection of the secret value
To include your ShodanApiKey secret in the subcription that launches this job (named Extended discovery for domain names), include it in its parameters in the same way.