Free4all

New Member
Joined
Aug 17, 2012
Messages
2
Hello all, I work in IT and I run into a problem quite often where we know how to fix the issue but we are unable to because they cannot get connected to the network. We use static IP's as a standard for all computers in order to organize and prevent from being able to used outside of the facilities. I would like to add that DHCP is not a possible solution. For example, the default gateway is incorrectly set or ip is incorrectly set. This would be easy to fix by instructing the users what to type in BUT they do not have admin rights to do this. Which causes them having to ship in the pc and costs the company more money when it could be fixed without being shipped.

Is it possible to create a basic script or program with local admin privileges embedded that sets a one time password to an admin account based on an algorithm. For example the user opens the script and it generates a random number such as 12345 I could enter 12345 on my computer and it would show me what the one time password is and I would give that to them. Or even have it to where the password automatically changes depending on the date. Like if it is Jan/1/2013 I could pull up a list and see what the password of the day is.

If at all possible without expensive programming tools a algorithm based OTP would be more ideal since I could just reset the admin password to a default password that only the helpdesk knows with a simple script.

I am open to all ideas, tips, suggestions, etc.

Thanks!!
 
Solution
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...
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.
 
Last edited by a moderator:
Solution