[New Rule] Potential Password Spraying Attack via SSH

[Aegrah]

Summary

This rule detects potential password spraying attacks via SSH by identifying multiple failed login attempts from a single source IP address targeting various user accounts within a short time frame. Password spraying is a technique where an attacker attempts to gain unauthorized access by trying a few commonly used passwords against many different accounts, rather than targeting a single account with multiple password attempts.

[github-actions]

Rule: New - Guidelines

These guidelines serve as a reminder set of considerations when proposing a new rule.

Documentation and Context

• Detailed description of the rule.
• List any new fields required in ECS/data sources.
• Link related issues or PRs.
• Include references.

Rule Metadata Checks

• creation_date matches the date of creation PR initially merged.
• min_stack_version should support the widest stack versions.
• name and description should be descriptive and not include typos.
• query should be inclusive, not overly exclusive, considering performance for diverse environments. Non ecs fields should be added to non-ecs-schema.json if not available in an integration.
• min_stack_comments and min_stack_version should be included if the rule is only compatible starting from a specific stack version.
• index pattern should be neither too specific nor too vague, ensuring it accurately matches the relevant data stream (e.g., use logs-endpoint.process-* for process data).
• integration should align with the index. If the integration is newly introduced, ensure the manifest, schemas, and new_rule.yaml template are updated.
• setup should include the necessary steps to configure the integration.
• note should include any additional information (e.g. Triage and analysis investigation guides, timeline templates).
• tags should be relevant to the threat and align/added to the EXPECTED_RULE_TAGS in the definitions.py file.
• threat, techniques, and subtechniques should map to ATT&CK always if possible.

New BBR Rules

• building_block_type should be included if the rule is a building block and the rule should be located in the rules_building_block folder.
• bypass_bbr_timing should be included if adding custom lookback timing to the rule.

Testing and Validation

• Provide evidence of testing and detecting the expected threat.
• Check for existence of coverage to prevent duplication.

[tradebot-elastic]

⛔️ Test failed

Results

• ❌ Potential Password Spraying Attack via SSH (esql)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta

[w0rk3r]

Suggested change

	from "logs-system.auth-*" metadata _id, _index, _version
	from logs-system.auth-*

[Aegrah]

Discussed this on Slack, although not necessary (as metadata is dropped after stats), we are enforcing metadata in unit tests soon for non-stats queries, and I think it's better for consistency to just add it, as it does no harm (as far as I know), and makes all rules similar.

[w0rk3r]

Suggested change

	| keep
	@timestamp,
	_id,
	_index,
	_version,
	event.category,
	event.action,
	event.outcome,
	source.ip,
	process.name,
	user.name,
	event.dataset,
	data_stream.namespace,
	agent.id,
	user.id

Everything that is not used in the stats is dropped, makes more sense to do the KEEP after stats

[Aegrah]

Adding KEEP after stats also makes no sense, because stats will only keep all fields within the by clause or used in the stats function, so it would not really do much. I mostly add keeps because the unit tests expect them. Think it is good to have a broader discussion about this in the new year.

[terrancedejesus]

There are pros and cons for enforcing KEEP and placement. Performance (if any) for aggregation-based (use it before aggregating for performance). Otherwise by does a KEEP in theory. Non-aggregation-based, it can be used but forces limitations on fields that appear in the alert doc which I don't believe we want to practice doing. Maybe we follow-up with ES on the subject and if it is still best practice given our scenarios and rule examples.

[w0rk3r]

Suggested change

	| where Esql.user_name_count_distinct > 10 and Esql.event_count >= 30
	| where Esql.user_name_count_distinct > 10 and Esql.event_count >= 30
	| keep Esql.*, source.ip

[tradebot-elastic]

⛔️ Test failed

Results

• ❌ Potential Password Spraying Attack via SSH (esql)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta

[tradebot-elastic]

⛔️ Test failed

Results

• ❌ Potential Password Spraying Attack via SSH (esql)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta

[Mikaayenson]

One question that comes to mind is the bustiness of this. I think it's >10 unique users and >=30 failures in 1 min bucket? I wonder if we should expand the bucket e.g. 5 min or lower the counts?

[tradebot-elastic]

⛔️ Test failed

Results

• ❌ Potential Password Spraying Attack via SSH (esql)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta

[tradebot-elastic]

⛔️ Test failed

Results

• ❌ Potential Password Spraying Attack via SSH (esql)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta

[tradebot-elastic]

⛔️ Test failed

Results

• ❌ Potential Password Spraying Attack via SSH (esql)
  • coverage_issue: no_rta
  • stack_validation_failed: no_rta

[Aegrah]

@Mikaayenson expanded the interval slightly.