UGN Security Forums
My ProfileMember DirectoryLogin
Search our ForumsView our FAQView our Site Rules
View our CalendarView our Active TopicsGo to our Main Page

UGN Security Store
 

Network Sites UGN Security, The GoNix Initiative, Elite Web Gamers, Back of the Web, EveryDay Helper, VNC Web Design & Development
August
Su M Tu W Th F Sa
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31
Sponsored Links
Latest Postings
Latest Reviews
Topic Options
Rate This Topic
#6805 - 07/27/04 06:52 PM Questions
lyanna Offline
Junior Member

Registered: 07/27/04
Posts: 1
Loc: Chicago
Hy guys. I am a newbie at hacking and I am trying to improve myself. I do have the networking knowledge but I need the tools now.
I tried of course googling but I have never found a site worth bookmarking and I know that neither you are hanging on those sites
Can you help me with a few good sites where I can find some up to date tools worth downloading?

Top
Sponsored Links
      
#6806 - 07/27/04 11:26 PM Re: Questions
Infinite Offline



Registered: 03/09/02
Posts: 1041
Loc: Canada eh

Top
#6807 - 07/31/04 04:09 AM Re: Questions
Rican Havock Offline
Junior Member

Registered: 06/04/04
Posts: 30
Loc: Machine City
try writing your own....
u will find it much more worthwhile

here r a few links that might Aid U

http://astalavista.box.sk/

http://www.textfiles.com/

http://www.grc.com/port_0.htm

use GRC to learn basiclly the function of everyport. They also have a ton of other security tools (mostly webbased) that u can gain networking knowledge
_________________________
Programming it is like sex anyone can do it but only a few of us will ever master it and satisfy all parties envoled :-)

Top
#6808 - 08/10/04 11:32 PM Re: Questions
Digital Geek Offline
UGN Super Poster

Registered: 09/18/02
Posts: 553
Loc: Cluj-Napoca, Romania
before using grc and their tools to gain networking knowledge visit grcsucks.com to find out the truth about grc.com

Top
#6809 - 08/17/04 10:48 AM Re: Questions
blink1nce182 Offline
Junior Member

Registered: 08/17/04
Posts: 1
Loc: Yukon Territory
[Edited by Gizmo; We do not endorse nor condone hacking websites.]

Top
#6810 - 01/03/05 12:56 PM Re: Questions
max_ice Offline
Junior Member

Registered: 01/03/05
Posts: 1
Loc: hfel
this question is for experienced admins/hackers only

ok, in windows, i found the LM hash file, right the weaker hash that can be copied and changed right so i can oh say log in as admin on the computer, right.
well they have the computer locked down, but it in a public area around maybe 50 other computers no cameras and few wandering admins. so i have the time and the seclusion to mess with it for several hours
w/ out question, or bother. ok, i cannot get into the bios, ahh now you see the problem. thus i cannot boot of off a disk, because it isnt set to, and obviously w/ o bios i cannot change that. so w/ o access to the bios how can i log in as amin?
or any other things i have over looked? any answers would be much appriciated. my e-mail is [email protected] well one of them. any suggestions or whatever
_________________________
Max I. Mason

Top
#6811 - 01/05/05 01:42 PM Re: Questions
sinetific Offline
nobody

Registered: 03/02/02
Posts: 815
Loc: Ann Arbor
This will explain how lanmanager hash encryption works.

Code:
   Modifying Windows NT Logon Credentials
       
                                                        HernŠn Ochoa
   
                                                     [email protected]
   
   
   Introduction
   
   
   A common attack against Windows NT consists in obtaining usernames and LM/NT password hashes using tools such as
   L0phtCrack, or tcpdump-smb. These are then used to gain unauthorized access to file and printer shares on the attacked
   server.
   
   
   To be able to use this username/hashes pairs instead of the commonly used username/password pairs, the attacker must
   use some kind of modified SMB client.
   
   
   SAMBA, a Unix implementation of the SMB/CIFS protocol, is normally used by attackers due to the availability of its
   source code, what makes its modification to conform to their needs extremely simple.
   
   
   However, its use also limits the attack to file and printer shares. Although SAMBA in its latest versions began to
   implement the MS RPC protocol, it doesn't implement yet all the funcionality given by Windows NT common administration
   utilites, and probably never will.
   
   
   This paper describes how to change the logon credentials of a logged on user on a Windows NT Server/Workstation, which
   automatically lets the attacker take advantage of any native Windows NT application that makes use of the user's
   username and hashes for authentication, such as the Registry Editor (regedt32.exe), User Manager for Domains
   (usrmgr.exe), Service Control Manager etc.
   
   
   Windows NT Logon and Authentication Model
   
   
   There are three basic components that take part in the NT logon and authentication model: logon processes, the LSA
   server process, and authentication packages.
   
     * Logon Processes: A logon process is a component trusted by the operating system to monitor I/O devices for logon
       attempts (A network is considered to be a device).
       
   
     * The LSA (Local Security Authority) Server Process: A user-mode process (LSASS.EXE) that is responsible for the
       local system security policy, user authentication, and sending security audit messages to the Event Log.
       
   
     * Authentication Packages: This components (implemented as DLLs) are responsible for performing the actual user's
       credentials authentication, creating a new LSA Logon Session for the user and returning a set of SIDs and other
       information appropiate for inclusion in a Token object. This represents the user's security context for access to
       NT operations. Also, the authentication package may associate one or more supplementary pieces of credential
       information with the user's logon session for later reference.
       
   
   The LSA links to these DLLs at system startup by reading the entries in the registry key
       \HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa under AuthenticationPackages.
       
   Logon processes receives logon attempts and send the user's credentials to the LSA for authentication. This
   authentication is carried out by the authentication packages. Each logon process must register itself to the LSA at
   startup, and at that moment it selects a certain authentication package to use.
   
   
   The API that authentication packages must implement, and the API available to logon processes are documented in the
   LSAAUTH.HLP help file from the Windows NT DDK.
   
   
   WinLogon and MsV1_0
   
   
   The Windows NT default logon process for interactive logons is called Winlogon (WINLOGON.EXE) , it intercepts logon
   attempts from the keyboard.
   
   
   At startup, WinLogon registers itself to the LSA as a logon process calling the function LsaRegisterLogonProcess. This
   gives it back a Lsa logon process handle and establishes a LPC connection with the LSA authentication port
   (\LsaAuthenticationPort) that will be used for exchanging information during logon, logoff, and password operations.
   
   
   Then it obtains an association ID for the default authentication package, MSV1_0 (MSV1_0.DLL) by calling
   LsaLookupAuthenticationPackage. This is the package that it will use to authenticate the user's credentials.
   
   
   Everytime WinLogon wants to logon a user to the system, it calls LsaLogonUser, specifying its own LSA logon process
   Handle, the Package ID of Msv1_0 and the user's username and password in the call.
   
   
   This ends up in LsaApLogonUserEx implemented in MSV1_0.DLL, here the user's username and password are authenticated
   using the SAM Database (local or remote), and if the authentication was successfull, a logon session is created calling
   LsaCreateLogonSession assigning to it a LogonId (LUID) generated by the package.
   
   
   After this, MSv1_0 adds supplementary credentials to the logon session by calling LsaAddCredential, this credentials
   happen to be the user's username, domain name and LM/NT hashes of his/her password.
   
   
   This information is then used by the LAN Manager and other services when the user attempts to access remote nodes and
   it is the information we need to change in order to use the stolen username and hashes in the attack.
   
   
   Msv1_0 also obtains from the SAM Database the SID of the user account and the groups the account belongs to and passes
   this to the LSA Server Process., which obtains a list of privileges associated with the account and groups, gathers all
   this information and calls the NT Executive to create an Access Token for the user.
   
   A handle to this toke is then returned to WinLogon who starts a shell program, normally EXPLORER.EXE.
   
   
   An Access Token is linked to the Lsa Logon Session it belongs to by its AuthenticationId, which is no other than the
   LogonId generated by the authentication Package.
   
   
   Modifying MSV1_0 Credentials
   
   
   The approach chosen to modify these credentials was to figure out the undocumented structures the LSA
   
   Server Process uses to store the logon sessions and their associated credentials. Knowing this we can proceed to
   directly edit in memory the current user's credentials and change them for the ones of the user we want to impersonate.
   
   
   Keep in mind this is guesswork, and some things might be innacurate:
   
   
   The LSA Server Process keeps the logon sessions in a single-linked list. There is a global structure where it keeps a
   pointer to this list and the number of logon sessions created (there isn't a straightforward way to obtain the location
   of this structure, it resides somewhere in LSASRV.DLL, a dynamic link library used by the LSA where the logon session
   functions and structures are implemented).
   
   
   struct LsaLogonSessionArray {
   
   
   // Pointer to the linked list
   
   uint32_t pLogonSessionsList;
   
   // number of logon sessions
   
   uint32_t logonSessionsCount;
   
   };
       
   pLogonSessionsList is a pointer to the single-linked list of logon sessions, this is the format of an item of that
   
   list:
   
   
   struct LsaLogonSession {
   
   // Pointer to next logon session
   
   uint32_t pNextLogonSession;
   
   // LogonId (LUID)
   
   uint32_t logonIDLow;
   
   uint32_t logonIDHigh;
   
   // Pointer to the username in Unicode format
   
   uint32_t pUNICODE_USERNAME;
   
   // Pointer to the user's domain name in Unicode format
   
   uint32_t pUNICODE_DOMAINNAME;
   
   // Unkown. It appears to be a pointer to another structure where among other things
       // the RID of the user is stored.
       
   uint32_t unkown1;
   
   // It appears to be a a reference count of the logon session.
   
   uint32_t referenceCount;
   
   // Pointer to an array of credentials
   
   uint32_t pLsaCredentialsArray;
   
   };
       
   pLsaCredentialsArray points to another structure which i called LsaCredentialsArray. if pLsaCredentials == 0 then the
   logon session doesn't have any associated credentials.
   
   
   struct LsaCredentialsArray {
       
   // Unkown
   
   uint32_t unkown1;
   
   // Unkown
   
   uint32_t unkown2;
   
   // pointer to the credentials
   
   uint32_t pLsaCredentials[];
   
   };
       
   During the research i didn't observed logon sessions with more than one set of credentials but i decided to call this
   an array anyway.
   
   
   pLsaCredentials lead us finally to the credentials added by authentication packages.
   
   
   struct LsaCredentials {
       
   // Unkown
       uint32_t unkown1;
       // Value of the Primary Key of the credentials
       STRING PrimaryKey;
       // Credentials
       STRING Credentials;
       
   };
   
   
   STRING has this format:
   
   
   struct STRING {
       
   USHORT Length;
       
   USHORT MaximumLength;
   
   PCHAR Buffer;
   
   };
       
   Every set of credentials must be given a Primery Key value, this is a string the authentication package can later use
   to reference to this credentials when calling LsaGetCredentials. MSv1_0 uses "Primary" as the Primary Key value.
   
   
   Credentials is not neccesary a characters string. In the case of Msv1_0, Credentials.Buffer points to a structure like
   this:
   
   
   struct MsvCredentials {
       
   UNICODE_STRING UNICODE_DOMAIN;
       UNICODE_STRING UNICODE_USERNAME;
       uint8_t NTHash[16];
       uint8_t LMHash[16];
       UCHAR domainname[UNICODE_DOMAIN.Length];
       UCHAR username[UNICODE_USERNAME.Length];
       
   };
   
   
   This is the information that is used by LAN Manager and other services that uses the Msv1_0 authentication package when
   accessing remote nodes. Changing this allow us to perform SMB/CIFS/MS RPC attacks based on stolen username/password
   hashes from a Windows NT Workstation/Server.
   
   
   UNICODE_DOMAIN and UNICODE_USERNAME are not normal unicode strings, its Buffer member isn't a direct pointer to the
   unicode string, but an offset from the beggining of the MsvCredentials structure address.
   
   
   This is arranged in this way by Ms1_0 when it calls LsaAddCredential to make this information independent of a process
   address space.
   
   
   Another thing to notice, is that Section 4.2 MsV1_0 Credential Formats of LSAAUTH.HLP states that the credentials
   stored by Msv1_0 don't include the Domain Name, but they do.
   
   
   Knowing all this, the procedure to change the current user logon credentials is:
   
   
     * Obtain the current user's Access Token AuthenticationId. This can easily be done using the WIN32 API:
       
   
   // We obtain the current process access token
       
       OpenProcessToken( GetCurrentProcess(), TOKEN_QUERY, &hToken);
       
       // We obtain from that token the statistics information
       
       GetTokenInformation( hToken,
       TokenStatistics,
       &tokenstats,
       sizeof(tokenstats),
       &len)
       // the AuthenticationId member of the returned structure of type TOKEN_STATISTICS
       // contains the logon ID associated with this token.
       
       logonID = tokenstats.AuthenticationId;
       
     * Obtain the pointer to the LsaLogonSessionArray. As mentioned above, there isn't a straightforward way to obtain
       this pointer, this is the method I used:
       
   
          + I obtain a hProcess handle to the LSA Server Process executable image using OpenProcess with
            PROCESS_ALL_ACCESS (you need to have debug privileges to do this).
       
   
          + I inject a DLL into LSASS.EXE process address space creating a remote thread. This DLL contains a function
            that will do all the work .
       
   
          + This function calls GetModuleHandle to obtain a hModule to the MSV1_0.DLL and obtains the address of the
            function LsaApInitializePackage using GetProcAddress().
       
   
   LsaApInitializePackage
       is a function every authentication package must implement, and it is called by the LSA after loading the package's
       DLL. In this call the authentication package receives a pointer to a LsaDispatchTable. This
       table contains pointers to the LSA's functions available to authentication packages, such as LsaAddCredential and
       LsaGetCredentials (these functions are implemented in LSASRV.DLL).
       
          + Adding 38h to the LsaApInitializePackage address I obtain the address of a variable where msv1_0.dll stores a
            pointer to the function LsaAddCredential.
       
   
          + I obtain the address of LsaAddCredential from this variable and I add 4h to it.
       
       This gives me the address of a CRITICAL_SECTION object LSASRV.DLL uses to synchronize accesses to the
       LsaLogonSessionArray structure.
       
          + By adding 1Ch to this address we finally obtain the pointer to LsaLogonSessionArray.
       
   
   The LsaLogonSessionArray is placed in memory following the previously mentioned CRITICAL_SECTION object.The value 1Ch
       results from adding the CRITICAL_SECTION object size (18h) plus 4 bytes, which is the size of
       another variable LSASRV.DLL uses, located just between the CRITICAL_SECTION object and the LsaLogonSessionArray.
       
          + Once I have the LsaLogonSessionArray address the function in the remote thread sends it back to me using a
            named pipe.
       
   
     * Having the LsaLogonSessionArray address, I walk the single-linked list searching for a LsaLogonSession with a
       LogonID equal to the token's AuthenticationId. This is done using ReadProcessMemory and the hProcess of LSASS.EXE.
       
   
     * Finally, All that's left to do is changing the MsV1_0 credentials associated with that LsaLogonSession.
       
   
   This is the less intrusive way to change the credentials, and will only allow you to change the LM and NT hashes of the
       user. Why? because they are of fixed length (16 bytes each) and overwriting them in memory is enough, but the
       user's Username and Domain are Unicode strings of variable length and you need to reallocate the whole credentials
       block to be able to replace them with longer ones. (For example, if the Username is "MyUser" and you want to change
       it for "MyAnotherUser", you need a bigger buffer for the new Unicode string.)
       
       The suggested approach here consists in injecting again a DLL into LSASS.EXE process address space and calling
       LsaDelCredential and LsaAddCredential just like MsV1_0 would do, to replace the whole credentials with a new ones
       containing the new Username and Domain.
       
       
   Conclusion
   
   
   The modification of the logon credentials lets the attacker use Windows NT in stolen username/hashes based attacks. It
   makes possible the remote manipulation of the attacked server in a way that couldn't be done before without the
   plain-text passwords.
   
   
   It does not represent a new security hole by itself, but there are no doubts it extends the range of action of
   intruders.
Micorsoft also has a method for defeating this attack.

Top

Moderator:  Infinite 
Featured Member
Registered: 08/21/13
Posts: 1
Forum Stats
2146 Members
46 Forums
33851 Topics
69018 Posts

Max Online: 1567 @ 04/25/10 10:20 AM
Top Posters
UGN Security 27014
Gremelin 7192
§intå× 3255
SilentRage 1273
Ice 1146
pergesu 1136
Infinite 1041
jonconley 955
Girlie 908
unreal 860
Newest Members
Devo60, ali, lavos, Zanvin Green, Daktologist
2145 Registered Users
Who's Online
0 registered (), 308 Guests and 327 Spiders online.
Key: Admin, Global Mod, Mod
Latest News


Donate
  Get Firefox!
Get FireFox!