The Windows NT BlackPaper By

Found at: 0x1bi.net:70/textfiles/file?hacking/MICROSOFT/si_nt.txt

-------------------------------------------[ The Windows NT BlackPaper 
-------------------------------------------[             By Neon Surge               
-------------------------------------------[         for  Shatter Inc.
%%   This file is meant for educational and informational purposses only. This file is not a "How To" guide, any unlawful use of  this file or the information within this file is not the fault of  Neon Surge, Shatter Inc., or the fault of  any owner and/or operator of an internet site and/or webpage where the file may reside.  %%
  Lets jump right in. For those of  you who are not riggers (architecture/network media specialists) let me begin by saying that NT as an operating system is fairly safe and secure. Now you may think to yourself that it isnt, but think about all the Unix related security holes you know of, a ton huh? Anyhow, as with any operating system, NT has holes, lets see what we can learn about these holes, shall we?
 First things first, NT does not support alot of  the normal TCP/IP functions that youre used to. NT does not normally support NFS, SunRPC, NIS, r* commands, Telnet, and some other obscure ones. 
 In order for NT to allow for various system services to be performed on a remote computer, it 
uses RPC, remote procedure calls. Please do not confuse this with SunRPC. You can run NT/RPC's 
over a NetBIOS/SMB session or you can piggie back it directly off of  TCP/IP (or other transport 
protocol, perhaps NWLink IPX/SPX). Unfortunately we dont have any good documentation on what 
inherent services NT provides through native RPC. Complex server type programs (Like Exchange) 
provide their own RPC services in addition to the ones NT provides as an operating system 
--(TCP Port 135 is used as a port-mapper port, we also know that if too much information is fed 
through port 135, you can crash an NT box.). Some client software must access TCP port 135 
before accessing the RPC service itself (hint, hint). Keep in mind that TCP port 135 can be 
blocked. Bummer, eh?
 One problem among the Hacker community is that most hackers dont like to investigate new 
avenues, or explore new methods. They will take the easy way out, using a method thats already 
been documented by someone else. So what if they come across a system that has patched that 
security problem? Will todays hacker try to find a new way in? Nope... most of the slackers I 
know will give up. It is for this reason that alot of the members in the community have never 
heard of SMBs, because its a session level protocol  that is not a Unix standard (although there 
is something somewhat like SMBs for Unix, known as Samba). SMBs are used by Windows 3.X, Win95, 
WintNT and OS/2. The one thing to remember about SMBs is that it allows for remote access to 
shared directories, the registry, and other system services. Which makes it important in our 
line of, uuuhh, work. As stated above, unfortunately, there is no good documentation of the 
services that use SMBs. 
  Now, a couple of Key Points:
      SMBs are used by:
         -Win 3.X
         -Win 95
         -Win NT
      SMBs allow for remote access to:
         -Shared directories
         -The Registry
         -Other system services
  You will find that by default all accounts in NT have complete SMB functionality. This 
includes the Guest account. (In WinNT 3.51, the guest is auto created and active, in WinNT 4.0, 
the guest account is auto created but is not active) Now, 2 things to remember: When it comes to 
login attempt failures, the administrator account IS NEVER locked out after a certain number of 
login attempts (this rule ALWAYS applies), also by default, when windows NT is installed, NONE 
of the accounts have fail login attempt lock out. Also, in order for SMB to work, UDP/TCP ports 
137,138,139 (NetBIOS over TCP) must be open.
---A word about Remote registry alteration: By default the Everyone group in NT has write access 
to much of the registry. In NT 3.51, this was a major issue due to the remote registry access 
feature of RegEdit. Any user could manipulate the registry on any server or workstation on which 
his account (or the guest account) was enabled. WindowsNT fixed the problem with this registry 
Now, true, remote registry editing is not allowed in NT4, but this rule does not apply to 
Administrator (or perhaps other users in the Administrators group.. ::grin::).
 Ok, so far we've covered some pretty good information, but lets go into that new product that 
microsoft loves so much. The product they really hyped.. NTFS (NewTechnologiesFileSystem). First 
of all, NTFS is a rip off of the OS/2 file system, HPFS. No biggie, lets not get pickie. Anyhow, 
NTFS is actually a beautiful thing, if used properly. NTFS allows administrator to not only put 
access permissions on folders, but it also allows for access permissions on individual files 
within that folder. 
Example: Jane and Ralph both have access to the folder 'Shoes'. Theres only one file within the 
'shoes' folder. Only jane has access to this one file, Ralph does not. So when Ralph opens the 
'shoe' folder, it appears empty, but when Jane opens the 'shoe' folder, the file is there. 
Now, If an administrator does not set permissions on files within a folder but you know the 
exact path to the file, you can copy the file out of the folder onto a FAT (File Allocation 
Table) system, successfully bypassing the security. Example:
The folder 'Shoes' has permissions on it. You do not have access permission to the folder, BUT 
if you typed:
      copy c:\shoes\secure.txt a:\
 It would allow you to copy the file. Pretty neat huh?
I have heard that the latest NT4 patches have corrected this problem, I will let ya know when I 
get a chance to test it out.
File Sharing, I love those words. SMB file and print server protocols used by NT are harder to 
spoof than the NFS implementation on Unix systems. It is possible that a gateway (and I dont 
mean the brand name company) machine could spoof an SMB session, then read and write any files 
to which the true user of the session had access. -WARNING- This method is not for the beginner.
Now, windows allows for this wonderful thing called User Profiles. This allows for users to have 
login scripts, personalized desktops, etc etc. Now some very personal information can be 
contained within these profiles. For example, some users put the userid and password that they 
use for Microsoft Mail onto their logon script, this way when they log into the machine, it auto 
logs them into their mailbox. User profiles are stored in the %SYSTEMROOT%\SYSTEM32\CONFIG 
directory and also on a shared directory on the server. 
Lets discuss our little friend, the special share. NT shares the 
%SYSTEMROOT%\SYSTEM32\REPL\IMPORT\SCRIPTS directory, this way, users can read their login 
scripts during login. Under normal default conditions, ANYONE can access this share and read 
anyone elses login script. So whatever juicy pieces of information are in the login script are 
now yours. Some other special shares are created depending on other software installed on NT or 
other servers that NT has to cooperate with. These other shares will probably be discussed in 
another BlackPaper.
Getting lucky with that special account. There is a certain type of NT account that has the 
ability to BackUp and Restore database and account information. Accounts of this type have the 
ability to read, modify and write any file in the system. So, if ya cant get the Admin account, 
who knows... maybe theres a backup operator account. Ya never know.