A newly discovered attack method targeting ArgoCD and Kubernetes that could give red-teamers fresh ammo and blue-teamers fresh headaches.
This technique lets an attacker abuse Kubernetes DNS to steal powerful Git credentials from ArgoCD, potentially taking over entire Git accounts.
Why Target ArgoCD and Kubernetes?
In 2025, data exfiltration attacks are a major threat in cybersecurity, especially as attackers hunt for secrets stored in automation tools and continuous delivery pipelines.
ArgoCD is widely considered the gold standard for GitOps and Kubernetes CI/CD, making it a popular target.
Raise awareness of a new exfiltration method and show how attackers might use Kubernetes’ internal DNS to compromise Git credentials stored in ArgoCD, especially those that give access to private source code and secrets.
While ArgoCD is the most famous GitOps tool, others offering similar integration could also be vulnerable to variations of this attack, as per a report by Security Researcher.
Kubernetes orchestrates containers and automates scaling, failover, and resource management. The control plane manages cluster states, while worker nodes run containerized applications in pods.
Kubernetes uses CoreDNS for service discovery inside clusters, creating DNS records for every pod and service.
When a pod wants to connect to an external domain (like github.com), it resolves the DNS name internally first before forwarding the request. If an attacker can manipulate these DNS records, they can hijack traffic meant for Git servers.
CoreDNS, running in the kube-system namespace, is critical for these operations. If attackers can create malicious DNS records either by controlling CoreDNS or faking a service with names matching external domains, they can redirect connections originally meant for external servers (e.g., GitHub) to their own services.
ArgoCD uses Git credentials (such as passwords, access tokens, or GitHub app integrations) to fetch Kubernetes manifests for deployment.
Once a repository is connected, the credentials are stored and hidden for security reasons even the user who connected them cannot view them again.
But ArgoCD does allow custom SSL/TLS certificates and internal connections, which opens the door for some creative mischief.
Here’s an outline of the attack:
- Attacker Gains Access: The attacker compromises an ArgoCD user account with privileges to create certificates and applications.
- DNS Record Trick: They set up a Kubernetes service with the same name and namespace (github in namespace com). This service gets a DNS record that matches requests for github.com.
- Certificate Setup: The attacker adds a certificate for github.com to ArgoCD, making it trust connections to the fake service over HTTPS.
- Repo Server Connection: When the ArgoCD repo server tries to update or sync application manifests, it resolves github.com to the internal attacker’s service, passing along the secret credentials.
- Exfiltration: The attacker’s service intercepts the request, grabs the credentials, and proxies it to the real GitHub to avoid suspicion. Credentials (such as usernames, passwords, or GitHub tokens) are typically sent in headers and can be easily extracted and logged.
For GitHub App integrations, attackers can steal JWT tokens and access tokens, which can be used to access or modify private repositories for hours.
Attack Requirements and Impact
To pull this off, attackers need to compromise an account with these ArgoCD policies:
- Ability to create certificates and applications
- Ability to get clusters, repositories, and projects
- Certificate creation is critical to intercept HTTPS traffic
If these permissions exist, attackers can set up a rogue service, intercept Git traffic, and capture the credentials, sometimes without any immediate trace in ArgoCD, especially if malicious applications are deleted but the underlying service remains active in Kubernetes.
This attack demonstrates the danger of insecure DNS configurations and excessive user permissions within ArgoCD and Kubernetes.
Defenders should tighten RBAC controls, restrict certificate creation, monitor unexpected service names, and regularly audit DNS records and network traffic for suspicious redirections.
Find this Story Interesting! Follow us on LinkedIn and X to Get More Instant Updates.
Source link
