[agent] POC Ability to choose non-system user to execute a payload #14
Conversation
savacano28
added
needs triage
savacano28
changed the title
savacano28
force-pushed
the
issue/1179-poc
branch
from
49f17ca
to
b9d28a7
Compare
…ermissions for the non-system user on the execution directory
savacano28
changed the title
| @@ -58,11 +58,16 @@ function .onInit | |||
| ${GetParameters} $R0 | |||
| ${GetOptions} $R0 ~OPENBAS_URL= $ConfigURL | |||
| ${GetOptions} $R0 ~ACCESS_TOKEN= $ConfigToken | |||
| ${GetOptions} $R0 ~NON_SYSTEM_USER= $ConfigNonSystemUser | |||
| ${GetOptions} $R0 ~NON_SYSTEM_PWD= $ConfigNonSystemPwd | |||
| functionEnd | |||
|
|
|||
There was a problem hiding this comment.
Finally, do we let the installer create the user account ?
Not the agent to have too much power
This facilitates the agent deployment workflow.
There was a problem hiding this comment.
No, these params are not used to create a user account, they are used to execute scripts (dep. Elevated privilege)
| wide | ||
| } | ||
|
|
||
| fn run_as_user_command(username: &str, domain: &str, password: &str, script_file_path: &PathBuf) -> Option<u32> { |
There was a problem hiding this comment.
Comment a maximum the path choose and why this one.
| FileWrite $4 "non_system_user = $\"$ConfigNonSystemUser$\"$\r$\n" | ||
| ${EndIf} | ||
| ${If} $ConfigNonSystemPwd != "" | ||
| FileWrite $4 "non_system_pwd = $\"$ConfigNonSystemPwd$\"$\r$\n" |
There was a problem hiding this comment.
Clear password in config, thats a no go
There was a problem hiding this comment.
The credentials for users without elevated privilege are not mandatory so for that I set this condition. I'm not sure where I clear pwd, t'y!
| icacls $directory /grant "${NON_SYSTEM_USER}:(OI)(CI)F" /T | ||
|
|
||
| Stop-Service -Force -Name "OBAS Agent Service"; Invoke-WebRequest -Uri "${OPENBAS_URL}/api/agent/package/openbas/windows/${architecture}" -OutFile "openbas-installer.exe"; ./openbas-installer.exe /S ~OPENBAS_URL="${OPENBAS_URL}" ~ACCESS_TOKEN="${OPENBAS_TOKEN}" ~NON_SYSTEM_USER="${NON_SYSTEM_USER}" ~NON_SYSTEM_PWD="${NON_SYSTEM_PWD}"; Start-Sleep -Seconds 1.5; rm -force ./openbas-installer.exe; |
There was a problem hiding this comment.
Not sure about that, agent must always run as an admin.
There was a problem hiding this comment.
The agent run as admin, these params are used later for running the implant scripts
| Stop-Service -Force -Name "OBAS Agent Service"; Invoke-WebRequest -Uri "${OPENBAS_URL}/api/agent/package/openbas/windows/${architecture}" -OutFile "openbas-installer.exe"; ./openbas-installer.exe /S ~OPENBAS_URL="${OPENBAS_URL}" ~ACCESS_TOKEN="${OPENBAS_TOKEN}" ~NON_SYSTEM_USER="${NON_SYSTEM_USER}" ~NON_SYSTEM_PWD="${NON_SYSTEM_PWD}"; Start-Sleep -Seconds 1.5; rm -force ./openbas-installer.exe; |
There was a problem hiding this comment.
Not sure about that, agent must always run as an admin.
|
|
||
| $directory = (Get-Location).Path |
There was a problem hiding this comment.
I think its more about the agent to adapt the rights of the implant directory.
There was a problem hiding this comment.
Sure, It was my first try (agent modifies rights on directory) but I had some difficulties writing the code so for that I include it here (I'm going to ask to modify it), ty.
| } | ||
| } else { | ||
| // Execute the command as a specific user | ||
| if let Some(pid) = run_as_user_command(non_system_user, "WORKGROUP", non_system_pwd, &script_file_name) { |
There was a problem hiding this comment.
Not sure about WORKGROUP will be something working across customers.
|
|
||
| // Call CreateProcessWithLogonW | ||
| let result = unsafe { | ||
| CreateProcessWithLogonW( |
There was a problem hiding this comment.
A bit surprise about the fact we need to use this kind of low level api.
What i have seen for now.
PS C:\Users\JulienRichard> $user = "Administrator"
PS C:\Users\JulienRichard> $pwd = ConvertTo-SecureString "MyP@55w0rd" -AsPlainText -Force
PS C:\Users\JulienRichard> $cred = New-Object System.Management.Automation.PSCredential($user,$pwd)
PS C:\Users\JulienRichard> powershell.exe -executionpolicy Bypass -file script.ps1 -Credentials $cred
There was a problem hiding this comment.
Yes, indeed, I tried this at first. However, since I executed only a few simple injects, I wondered if we might need more control. I will add the other code, ty!!
Proposed changes
Related issues
Checklist
Further comments
If this is a relatively large or complex change, kick off the discussion by explaining why you chose the solution you did and what alternatives you considered, etc...