This is for Windows (XP, 7, or 8) related question.
Is it possible to get processes exec path without admin rights?
If possible, can you advice?
UPDATE:
Sample working code:
#RequireAdmin
#include <array.au3>
Dim $proc[1][3]
Dim $i = 0
$WMI = ObjGet("winmgmts:\\.\root\CIMV2")
$result = $WMI.ExecQuery("SELECT * FROM Win32_Process", "WQL",0x10 + 0x20)
If IsObj($result) Then
For $res In $result
$Proc[UBound($proc)-1][0] = $res.Name
$Proc[UBound($proc)-1][1] = $res.Handle
$Proc[UBound($proc)-1][2] = $res.ExecutablePath
ReDim $proc[UBound($proc) + 1][3]
Next
ReDim $proc[UBound($proc) - 1][3]
Else
Msgbox(0,'Result','No result found')
Endif
_ArrayDisplay($Proc,'Process List')][1]
Output:
If you have a process ID, use OpenProcess() to get a HANDLE to the process, then use GetProcessImageFileName() or QueryFullProcessImageName() to get the filename of the process.
If you need the command-line parameters that were passed to the process, that is much harder to do. You have to use NtQueryInformationProcess() to get the address of the process's PEBstructure and then use ReadProcessMemory() to read the contents of the PEB's ProcessParameters.CommandLine member, which is a UNICODE_STRING structure. Note that this will fail if you try to access processes that belong to other user accounts, or running with higher privileges, unless your process has the SeDebugPrivilege privilege, such as by enabling it with AdjustTokenPrivileges().
Related
We are using Redemption Library to access our e-mails. Scripts are automated on server and triggered by Task Scheduler at regular intervals. After server reboots we usually experience the problem with Session.Logon, since the user needs to log on again.
To avoid this problem, we are trying now to use LogonHostedExchangeMailbox Session method. Due to unknown reason the script gets stuck at this command. Could anyone advise what the reason might be? Here is the sample:
set Session = CreateObject("Redemption.RDOSession")
InboxName = "xxx#domain.com"
Session.LogonHostedExchangeMailbox InboxName,InboxName, "pwd" 'the script gets stuck here and does not throw any errors.
set oFolder = Session.GetFolderFromPath("\\"&InboxName&"\Inbox")
set items = oFolder.items
i = items.count
do until i = 0
if items.count > 0 then
set Mail = Items.Item(i)
wscript.echo Mail.Subject
'wscript.echo Mail.Body
end if
i = i - 1
loop
Session.Logoff
Thanks.
My organization uses a piece of software that has a printer name hard-coded into it PRN1.
Users are spread out through multiple locations; so it is impossible to just rename a single printer. Our networked printers are mapped by computer location via a login script; and some computers have locally attached printers.
The current proposed solution is to remote into each computer with the user logged in; re-map the users default printer; and manually rename it (Right click->Printer Prop...).
I'm trying to avoid this as we do not use roaming profiles and some users do move from location to location; and the users wouldn't understand why it suddenly isn't working.
Ideally I'd like to create a script that will automatically duplicate the users default printer; and name it PRN1.
$AllPrinters = gwmi win32_printer
$DefaultPrinter = $AllPrinters | where {$_.Default -eq $true}
rundll32 printui.dll,PrintUIEntry /ga /n $DefaultPrinter.SystemName + "\" + $DefaultPrinter.ShareName /z /b"PRN1"
Above is what I currently have; I know I'm not using the rundll32 command properly as the printer isn't being duplicated with the new name.
Any help or assistance would be greatly appreciated.
I use that rundll32 command here and there but never have solid luck with it.
You could do something like this by using wmi entirely. You may want to wrap a try catch around a large chunk of this to suppress errors and log output if users do end up having issues.
$Name = "PRN"
$AllPrinters = gwmi win32_printer
$DefaultPrinter = $AllPrinters | where {$_.Default -eq $true}
$objHelper = [WMICLASS]"\\localhost\root\cimv2:Win32_SecurityDescriptorHelper"
$print = [WMICLASS]"\\localhost\root\cimv2:Win32_Printer"
$print.Scope.Options.EnablePrivileges = $true
$newprinter = $print.createInstance()
$newprinter.drivername = $DefaultPrinter.DriverName
$newprinter.PortName = $DefaultPrinter.PortName
$newprinter.Shared = $false
$newprinter.Location = $DefaultPrinter.Location
$newprinter.Comment = $DefaultPrinter.Comment
$newprinter.DeviceID = $Name
$newprinter.PrintProcessor = $DefaultPrinter.PrintProcessor
$newprinter.PrintJobDataType = $DefaultPrinter.DataType
$newprinter.RawOnly = $DefaultPrinter.RawOnly
$result = $newprinter.Put()
Goal: Add a local user account share-level Read/Write permissions to an existing file share.
I'm hitting a roadblock in developing this. Apparently Microsoft wants you to add your user's ACE to the DACL and then back into the security descriptor of the share. (1). (No, NET SHARE /ADD is not available for existing shares, I was surprised.)
In theory that should be simple enough, but my main fear is doing it wrong and losing the existing share permissions (lots of network users, specific groups). This solution needs to scale to a few thousand shares. I'm developing the solution to output data about the existing DACL in case I need to back out. I should write code to interpret that log and be prepared to add them back en-masse should anything go wrong.
At the moment I'm using VBscript-- I feel PowerShell might be a bit stronger of an approach but VBscript/WMI is a known quantity.
Research:
(1) http://blogs.msdn.com/b/helloworld/archive/2008/07/22/editing-share-permission.aspx
Copy the existing ACEs to an array:
rc = shareSec.GetSecurityDescriptor(sd)
ReDim acl(UBound(sd.DACL)+1) '+1 for the new ACL we're going to add
For i = 0 To UBound(sd.DACL)
Set acl(i) = sd.DACL(i)
Next
Add the new ACE to that array:
Set acl(UBound(acl)) = NewACE(NewTrustee(username, domain), 2032127)
The functions NewTrustee() and NewACE() encapsulate the instructions for creating the trustee and the ACE. The number is the access mask for Full Control.
Create a new security descriptor and assign it to the share:
Set sd = wmi.Get("Win32_SecurityDescriptor").SpawnInstance_
sd.ControlFlags = flags
sd.DACL = acl
rc = shareSec.SetSecurityDescriptor(sd)
Check this page for a lot more detail information about security descriptors, trustees, ACLs and ACEs.
Full script:
Const FullControl = 2032127
' modify these variables according to your requirements:
computer = "."
share = "..."
username = "..."
domain = CreateObject("WScript.Network").UserDomain
Set wmi = GetObject("winmgmts:{impersonationLevel=impersonate}!//" _
& computer & "/root/cimv2")
Set shareSec = GetObject("winmgmts:Win32_LogicalShareSecuritySetting.Name='" _
& share & "'")
Function NewTrustee(name, domain)
Dim trustee, account
Set trustee = wmi.Get("Win32_Trustee").SpawnInstance_
trustee.Name = name
trustee.Domain = domain
Set account = wmi.Get("Win32_UserAccount.Domain='" & domain & "',Name='" _
& name & "'")
trustee.Properties_.Item("SID") = wmi.Get("Win32_SID.SID='" & account.SID _
& "'").BinaryRepresentation
Set NewTrustee = trustee
End Function
Function NewACE(trustee, permissions)
Dim ace : Set ace = wmi.Get("Win32_Ace").SpawnInstance_
ace.Properties_.Item("AccessMask") = permissions
ace.Properties_.Item("AceFlags") = 3
ace.Properties_.Item("AceType") = 0
ace.Properties_.Item("Trustee") = trustee
Set NewACE = ace
End Function
' copy existing ACEs
rc = shareSec.GetSecurityDescriptor(sd)
flags = sd.ControlFlags
ReDim acl(UBound(sd.DACL)+1) '+1 for the new ACL we're going to add
For i = 0 To UBound(sd.DACL)
Set acl(i) = sd.DACL(i)
Next
Set sd = Nothing
' add new ACE
Set acl(UBound(acl)) = NewACE(NewTrustee(username, domain), FullControl)
' prepare new security descriptor
Set sd = wmi.Get("Win32_SecurityDescriptor").SpawnInstance_
sd.ControlFlags = flags
sd.DACL = acl
' assign new security descriptor
rc = shareSec.SetSecurityDescriptor(sd)
I have a vbscript that creates a registry entry on a Windows Server 2003 machine. This script has been working fine for about a year now, but recently it just stopped working. I am thinking that a windows update must have changed something, maybe a security setting, whereby this script is no longer permitted to execute. The script uses the following function to create an entry in HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI\ for new ODBC connections:
Function CreateRegKey (sComputer, hTree, sKey)
Dim oRegistry
Dim lResult
Set oRegistry = GetObject("winmgmts:{impersonationLevel=impersonate}//" & sComputer & "/root/default:StdRegProv")
lResult = oRegistry.CreateKey(hTree, sKey)
If (lResult = 0) And (Err.Number = 0) Then
CreateRegKey = 0
Else
CreateRegKey = 1
msgbox("Create Key " & sKey & " Failed")
End If
Set oRegistry = Nothing
End Function
This function is called as follows:
Const HKEY_LOCAL_MACHINE = &H80000002
sPath = "SOFTWARE\ODBC\ODBC.INI\" & DataSourceName
'Create ODBC entry
If (0 = CreateRegKey(sComputer, HKEY_LOCAL_MACHINE, sPath)) Then
....
Else
....
End If
Does anyone know of a windows update that could have caused this script to suddenly stop working? The script stops on the following line:
lResult = oRegistry.CreateKey(hTree, sKey)
It does not give an error or anything. It just stops on that line.
Anyone got an idea what is going wrong here and how I could fix it? Thanks.
EDIT: I now get the error number returned by CreateKey. It returns the following:
Err.Number: -2147023533
Err.Description: Cannot start a new logon session with an ID that is already in use
Does anyone know what is causing this and how to work around it? Thanks.
The description for the error code -2147023533 (0x80070553) is:
Cannot start a new logon session with an ID that is already in use.
A search for this code and description reveals:
hotfix KB2283089 for fixing the error,
an assumption that the error is caused by KB979683,
a suggestion to reinstall service packs in order to fix the error.
Give these a try and see if it helps.
Solution (kinda):
Turns out this impersonation with .NET's security only allows application-level access. Since the COM object is at the system level, the impersonated user still cannot instantiate it. I figured this out by right-clicking the executable and selecting "Run As...", the program functioned fine. I found out that launches the program with system access (assuming the user you are running it with has those credentials). Now I am in the process of creating an external program that will launch this application using this method.
Thanks for the tips :D
I have a windows XP installation on a virtual machine. It is part of my domain, but the logged in user is a local user only. Obviously, if I try to access a network share it will prompt for a user/password:
The program I am testing out on the virtual machine uses a COM object to interface with data from another program. If I do not impersonate, I get errors because I do not have the proper credentials.
I did some research into the matter and found a number of websites that had a decent amount of VB.NET information. The problem I am having with the code I wrote is I can access the network resources, but I cannot instantiate the COM object.
If I fill and submit the credential prompt (above) before attempting to instantiate it, it works fine. That leads me to believe there must be something that the WinXP credential prompt is doing that I am not. Below is the code I am using for Impersonation:
Public Sub BeginImpersonation()
Const LOGON32_PROVIDER_DEFAULT As Integer = 0
Const LOGON32_LOGON_INTERACTIVE As Integer = 2
Const SecurityImpersonation As Integer = 2
Dim win32ErrorNumber As Integer
_tokenHandle = IntPtr.Zero
_dupeTokenHandle = IntPtr.Zero
If Not LogonUser(_username, _domainname, _password, LOGON32_LOGON_INTERACTIVE, LOGON32_PROVIDER_DEFAULT, _tokenHandle) Then
win32ErrorNumber = System.Runtime.InteropServices.Marshal.GetLastWin32Error()
Throw New ImpersonationException(win32ErrorNumber, GetErrorMessage(win32ErrorNumber), _username, _domainname)
End If
If Not DuplicateToken(_tokenHandle, SecurityImpersonation, _dupeTokenHandle) Then
win32ErrorNumber = System.Runtime.InteropServices.Marshal.GetLastWin32Error()
CloseHandle(_tokenHandle)
Throw New ImpersonationException(win32ErrorNumber, "Unable to duplicate token!", _username, _domainname)
End If
Dim newId As New System.Security.Principal.WindowsIdentity(_dupeTokenHandle)
_impersonatedUser = newId.Impersonate()
_impersonating = True
End Sub
I have also tried sending different flags to the impersonator method, but nothing seems to be working. Here are the different flags I found:
Enum LOGON32_LOGON
INTERACTIVE = 2
NETWORK = 3
BATCH = 4
SERVICE = 5
UNLOCK = 7
NETWORK_CLEARTEXT = 8
NEW_CREDENTIALS = 9
End Enum
Enum LOGON32_PROVIDER
[DEFAULT] = 0
WINNT35 = 1
WINNT40 = 2
WINNT50 = 3
End Enum
Enum SECURITY_LEVEL
Anonymous = 0
Identification = 1
Impersonation = 2
Delegation = 3
End Enum
I have run into this before, and used two different soloution - the easiest was using a third party app: TqcRunas: http://www.quimeras.com/Products/products.asp which allows you to package the required creentials in an encrypted file. However is a pain if the password is forced to expire.
The other solution that I have used is to call a new process with alternative credentials:
Dim myProcessStartInfo As ProcessStartInfo = New ProcessStartInfo
With myProcessStartInfo
.FileName = "file path and name"
.Domain = "domainname"
.UserName = "username"
'password needs to be a SerureString
Using NewPassword As New Security.SecureString
With NewPassword
For Each c As Char In "password".ToCharArray
.AppendChar(c)
Next c
.MakeReadOnly()
End With
.Password = NewPassword.Copy
End Using
'UseShellExecute must be false for impersonated process
.UseShellExecute = False
End With
Using Process As New System.Diagnostics.Process
With Process
.StartInfo = myProcessStartInfo
.Start()
End With
End Using
With your definitions, I use
LogonUser(_username, _domainname, _password, LOGON32_LOGON_NEW_CREDENTIALS, LOGON32_PROVIDER_WINNT50, _tokenHandle)
in my code that is authenticating across the network. I am impersonating a local user on the remote box, as you are. It was so long ago that I don't remember the rationale for using these values, however.
I do a similar thing to map network drives for copying files between machines. I didn't write the code but it's pretty much the same as yours, except for two things:
After the Impersonate method returns I close both tokens using the CloseHandle routine, before I exit my impersonator method.
At the top of the impersonator the first thing that happens is a call to RevertToSelf, presumably to cancel any previous impersonation.
I don't know if they would make a difference but it's worth a try. Here are the relevant declarations:
Declare Auto Function CloseHandle Lib "kernel32.dll" (ByVal handle As IntPtr) As Long
Declare Auto Function RevertToSelf Lib "advapi32.dll" () As Long