Firstly, you simply CANNOT grant admin privileges from a non-admin account. If you could there would be some serious security flaws with that lol.
Admin privileges in the context of that user account would be as high as the UAC can give permissions, which is really nothing on a network level. Now, to ask the question, if I was on a computer in that network, if I knew, the administrator credentials, would I be able to logon as the administrator? Is there a user account I can log into on that specific computer that would allow me to log on as the admin?
If so, then there may be a solution, but it's not as simple as most people tend to believe without much programming knowledge
Actually a couple solutions...
1) You could create a System service that would be able to act as the link between the admin and user account in a direct sense. The service itself would interact with the system service running on the admin account, and also act as a firewall to only allow the user to do what they need to do with interaction to the admin account on the network, enabling you to let the system service provide the means to fix the person's computer in whatever strategy it needs to take to do so.
2) You could provide an application, that would create a process under the user login tokens and metadata for the credentials of that Admin account, and just that one program itself would run on the Admin account virtually, but be seen as though it was running on that user's desktop environment. I created a test application in C++ for doing this with the Guest account, but nothing past creating a new instance of cmd.exe so I could fool around with the Guest account's terminal
Here was a snippet of my code:
Code:
int main(int argc, TCHAR** argv) {
PROCESS_INFORMATION procInfo;
STARTUPINFO startupInfo;
memset(&startupInfo, 0, sizeof(startupInfo));
memset(&procInfo, 0, sizeof(procInfo));
startupInfo.cb = sizeof(startupInfo);
if (CreateProcessWithLogonW(L"Guest", NULL, NULL, LOGON_WITH_PROFILE,
L"C:\\Windows\\System32\\cmd.exe", NULL, CREATE_DEFAULT_ERROR_MODE, NULL, NULL, &startupInfo, &procInfo))
{
CloseHandle(procInfo.hThread);
CloseHandle(procInfo.hProcess);
}
return 0;
}
And here is my proof of concept:
The first thing to note is that smss.exe (Windows Session Manager) manages the active Windows user sessions.
The second thing to note is that an instance of winlogon.exe is created for the user logon process.
With only these files though, how do we define what session is to be created upon a successful logon attempt? The answer to that would be Tokens. Obviously there is some kind of data or information which is used for initializing an instance of a Windows session in order to define what user account we create the session for. Otherwise winlogon.exe itself would not be able to create the session for multiple logins, because there's no unique data being given to it for it to differentiate between one user account or another to create a session for it.
In order to create a process in your current Windows session as LocalSystem though, you'll have to duplicate an instance of winlogon.exe with the specific tokens that would define that user session, however, you cannot start a process in a different session even if you are authenticated as LocalSystem when outside of Windows SID 0. Because LocalSystem should already exist. No duplicate sessions can be created and access to LocalSystem as far as I know is limited because of it's high high privileges. Though I may be wrong in some cases.
Ancient methods to achieve session to session interaction involve temporary Windows service installations to manage any launched programs, thus allowing the service to decide and help administer things on that active session for you. PsExec actually utilizes such methodologies.
Now instead of that, you could actually do something different, and start a remote thread, injecting binary code into a virtual address block for a given process running inside session 0 as LocalSystem, and execute it from there. You'd inherit the permissions identical to the host process, and bypass the need for starting a Windows service.
What I've done here is basically create the merger for 2 sessions inside of one for the interaction between my current local account, and the activated system's Guest account inside of it's domain by replicating it's token. You see the process start inside of my current session, but in reality it's only interaction is with the Guest account.