Item 1iam_root_mfa_enabledPriority 65manual action
Root account has no MFA device
arn:aws:iam::123456789012:root · us-west-2 · iam
Stable item ID: 8a55a1d0-40fa-5e17-9bde-afee5be5196f
What was observed
Fictional example: No MFA device is registered for the fictional account root user. An authorized account owner must review and complete enrollment.
Recommended approach
The AWS root identity has active credentials but Prowler did not observe multi-factor authentication enabled for that identity.
Root credentials have unrestricted account authority. A second authentication factor reduces the chance that a stolen password alone leads to account takeover.
An authorized account owner should enroll an MFA device for a standalone root user, or review centralized root access for an Organizations member account and remove unneeded member-account root credentials.
Potential impact
The account owner must preserve secure recovery access and update the documented break-glass procedure. Losing both the MFA device and recovery path can delay emergency access.
Validation
Not validated against your environment. Review and adapt before applying.
Assumptions and inputs
- The finding does not establish whether the account is standalone or uses centralized root access in AWS Organizations.
- MFA enrollment requires control of the root sign-in and a physical or virtual authenticator; no Terraform snippet can safely perform that ceremony.
Review and next steps
- Confirm whether this is a standalone account, an Organizations management account, or a member account with centralized root access.
- For a root identity that remains sign-in capable, sign in through the AWS root-user flow and assign a securely controlled MFA device.
- For an eligible member account, review centralized root access and removal of unnecessary root credentials instead of recreating persistent root access.
- Document device custody and recovery, remove root access keys, avoid routine root use, and rerun the Prowler check.
- AWS root-user and MFA reference: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#id_root-user_manage_mfa
Item 2s3_bucket_level_public_access_blockPriority 60needs context
Invoice archive is missing bucket-level public access blocks
arn:aws:s3:::northstar-demo-invoices · us-west-2 · s3
Stable item ID: a00eea4b-ca66-5503-9128-3349a62288b1
What was observed
Fictional example: The northstar-demo-invoices bucket stores generated invoice exports. BlockPublicAcls and IgnorePublicAcls are disabled. This finding alone does not establish that any objects are publicly accessible.
Recommended approach
The bucket-level S3 Block Public Access check failed, so one or more of the four bucket controls is absent or disabled.
Those controls prevent new public ACLs or policies and suppress access granted by existing public ACLs or policies. They reduce accidental disclosure risk, but the scan result does not show whether public delivery is intentional.
After confirming the bucket is intended to be private, manage all four bucket-level Block Public Access flags as true. The snippet manages only the public-access-block configuration; it does not create or replace the bucket.
Potential impact
Public S3 website access can stop. CloudFront delivery can also stop if it still depends on public access rather than Origin Access Control or Origin Access Identity. RestrictPublicBuckets may also block cross-account access from a policy AWS considers public.
Validation
Not validated against your environment. Review and adapt before applying.
Suggested Terraform
Review and adapt before applying.
# Suggested Terraform — review and adapt before applying.
variable "bucket_name" {
description = "Existing general-purpose S3 bucket to protect"
type = string
default = "northstar-demo-invoices"
}
resource "aws_s3_bucket_public_access_block" "recommended" {
bucket = var.bucket_name
block_public_acls = true
block_public_policy = true
ignore_public_acls = true
restrict_public_buckets = true
}
Assumptions and inputs
- The bucket input default came from the validated observation value 'northstar-demo-invoices'.
- Bucket ownership, Terraform state ownership, website hosting, CloudFront origin design, ACLs, and bucket policy were not inferred from this observation.
- Account- and organization-level Block Public Access may impose stricter effective settings.
Review and next steps
- Confirm the bucket owner and whether the bucket intentionally serves a public website or another public workload.
- Review bucket and access-point policies, ACLs, CloudFront origin access, and effective account/organization Block Public Access before selecting flags.
- If this public-access-block resource is already managed by Terraform, update that resource rather than adding a duplicate.
- If it exists in AWS but is outside Terraform, import it only after confirming the target workspace owns it; otherwise add this resource for the existing bucket.
- Run terraform plan in the customer workspace, review access loss and cross-account effects, apply through the customer's process, then rerun the Prowler check.
- AWS behavior reference: https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html
- Terraform resource reference: https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/s3_bucket_public_access_block
Item 3cloudtrail_multi_region_enabledPriority 46needs context
Audit trail only covers one AWS region
northstar-demo-audit · us-west-2 · cloudtrail
Stable item ID: 07e555ac-09a5-532c-9adb-b66fc1ad3954
What was observed
Fictional example: The northstar-demo-audit trail is configured for us-west-2 only. The fictional team also deploys services in us-east-1.
Recommended approach
Prowler did not observe an actively logging CloudTrail trail covering every enabled AWS Region. Event history alone is not a durable multi-Region trail.
A coverage or logging gap reduces the audit record available for detection and investigation of account activity.
Create or update a trail so logging is enabled and all enabled Regions plus global service events are covered. The snippet is intentionally minimal and requires an existing log-delivery bucket input.
Potential impact
CloudTrail and S3 storage charges may increase. A wrong bucket policy, KMS policy, home Region, or organization/account choice can prevent delivery or create a second, overlapping trail.
Validation
Not validated against your environment. Review and adapt before applying.
Suggested Terraform
Review and adapt before applying.
# Suggested Terraform — review and adapt before applying.
variable "trail_name" {
description = "Name of the CloudTrail trail to create or manage"
type = string
default = "northstar-demo-audit"
}
variable "cloudtrail_s3_bucket_name" {
description = "Existing S3 bucket configured to accept CloudTrail log delivery"
type = string
}
resource "aws_cloudtrail" "recommended" {
name = var.trail_name
s3_bucket_name = var.cloudtrail_s3_bucket_name
enable_logging = true
is_multi_region_trail = true
include_global_service_events = true
}
Assumptions and inputs
- The trail name default came from the validated observation value 'northstar-demo-audit'.
- The CloudTrail S3 bucket name is unknown and therefore has no generated default.
- Bucket policy, KMS encryption, log retention, event selectors, organization ownership, account scope, home Region, and Terraform state require review.
- The snippet covers management events; service data events require a separate event-selector decision and may add cost.
Review and next steps
- Decide whether to update an existing trail, create an account trail, or use an organization trail from its management or delegated administrator account.
- Choose the trail home Region and a protected S3 destination, then configure the required CloudTrail bucket policy and any KMS key policy before creating the trail.
- If the trail is already managed by Terraform, update it there. If it exists outside Terraform, import it only after confirming the workspace should own the complete trail configuration.
- Review management and data event scope, retention, encryption, duplicate-event cost, and delivery health; then plan, apply through the customer's process, and rerun the Prowler check.
- AWS trail reference: https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail-by-using-the-aws-cli-create-trail.html
- Terraform resource reference: https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/cloudtrail