It loads a virtual driver on startup which does the monitoring on a low-level. So it doesn't have to inject anything in other processes.
On http://www.decuslib.com/decus/vmslt00a/nt/filemon.htm there's a short explanation about how FileMon, one of ProcMon's predecessors, works.
How Filemon Works
For the Windows 9x driver, the heart of Filemon is in the virtual
device driver, Filevxd.vxd. It is dynamically loaded, and in its
initialization it installs a file system filter via the VxD service,
IFSMGR_InstallFileSystemApiHook, to insert itself onto the call chain
of all file system requests. On Windows NT the heart of Filemon is a
file system driver driver that creates and attaches filter device
objects to target file system device objects so that Filemon will see
all IRPs and FastIO requests directed at drives.
When Filemon sees an
open, create or close call, it updates an internal hash table that
serves as the mapping between internal file handles and file path
names. Whenever it sees calls that are handle based, it looks up the
handle in the hash table to obtain the full name for display. If a
handle-based access references a file opened before Filemon started,
Filemon will fail to find the mapping in it hash table and will simply
present the handle's value instead.
Information on accesses is dumped into an ASCII buffer that is
periodically copied up to the GUI for it to print in its listbox.
Likewise, Regmon another predecessor is similar:
How Regmon Works
The heart of Regmon on Windows 9x is in the virtual device driver,
Regvxd.vxd. It is dynamically loaded, and in its initialization it
uses VxD service hooking (see our May 1996 Dr. Dobb's Journal article
on VxD service hooking for more information) to insert itself onto the
call chain of 16 registry access functions in the Windows 95 kernel
(Virtual Machine Manager). All registry activity, be it from 16-bit
programs, Win32 applications, or device drivers, are directed at these
routines, so Regmon catches all registry activity taking place on a
machine.
On Windows NT the Regmon loads a device driver that uses a technique
we developed for NT called system-call hooking. When a user-mode
component makes a privileged system call, control is transfered to a
software interrupt handler in NTOSKRNL.EXE (the core of the Windows NT
operating system). This handler takes a system call number, which is
passed in a machine register, and indexes into a system service table
to find the address of the NT function that will handle the request.
By replacing entries in this table with pointers to hooking functions,
it is possible to intercept and replace, augment, or monitor NT system
services. Regmon, which obviously hooks just the Registry-related
services, is merely one example of this capability in action.
When Regmon sees an open, create or close call, it updates an internal
hash table that serves as the mapping between key handles and registry
path names. Whenever it sees calls that are handle based, it looks up
the handle in the hash table to obtain the full name for display. If a
handle-based access references a key opened before Regmon started,
Regmon will fail to find the mapping in it hash table and will simply
present the key's value instead.
Information on accesses is dumped into an ASCII buffer that is
periodically copied up to the GUI for it to print in its listbox.
If you like reading code, here's the source code of FileMon and RegMon: http://www.wasm.ru/baixado.php?mode=tool&id=283 (from http://forum.sysinternals.com/topic8038_page1.html)
