It sounds (from the comments) like you’re just launching another process and not interacting with it after that, right? In that case, there isn’t any direct communication between the processes at all! Instead, your process tells the OS “hey, I want to create a process, here are the details including args”, and then the OS creates a process including setting up its initial variables (environment variables and command-line arguments). The OS will also return some details to your process (notably the PID of the new process and a HANDLE to it, which a framework such as .NET wraps for you) but that’s sent back by the OS, not by the other process.
Talking about a “tunnel” doesn’t make any sense in this scenario, because at the time of the “communication”, the “recipient” doesn’t even exist yet! For it to make sense, you’d have to launch the new process in a way where it can communicate with your process once the new one is running. Sometimes this is an option – some programs can take data from
stdin in place of command line args, or can read their arguments out of a file (which might theoretically be a pipe, although many won’t like that). However, that depends on how the program is written, and you said you don’t control that.
I assume your goal is protect the command line arguments from being captured by an attacker. I have good news and bad news.
The bad news is that command line args are generally not secret. You can see them in Task Manager, for example, if you enable the relevant column in Details view. Processes owned by other users won’t have readable command line args unless you’re an Administrator, but anything running as you-the-user will have access if it wants. Of course, it doesn’t even matter whether the args are directly exposed; any process running with the same privileges as any other process (or running as admin) can simply read the other process’ address space directly, pulling any desired secrets right out of memory (the relevant APIs are usually used for debuggers).
The good news is that, assuming you don’t have malicious software running on your machine (or at least not with sufficient privileges), the command line args aren’t exposed to interception anywhere. They might get stored in a Windows system log (depending on logging settings) but they aren’t transmitted over the network or anything like that. The creator process invokes a system call or two (
NTCreateProcess on Windows, something like
clone followed by
execve on *nix systems) which passes the parameters directly to the kernel. It is in theory possible to intercept this, but if your attacker can interfere with system calls you have Much Bigger Problems, as that means they have already taken over either your process or your entire kernel! The kernel then creates the new process and sets its memory such that it sees the arguments you passed it; this is only interceptable if the entire machine is already compromised.
Now, of course, what the new process does with those arguments is entirely up to it! You seem to be starting something that wants a remote host and credentials to access it, which suggests that the credentials will be sent over the network. That’s the part you should be worried about, unless you expect your user (the person running your software) to be malicious or to have malicious code running with their privileges… in which case there’s nothing to be done, game over.