Announcement

Collapse
No announcement yet.

more detail from procmon needed

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • more detail from procmon needed

    having a problem where a .asp is attempting to instantiate an installed .dll component(createobject), program blows up can't see anything
    Ran procmon with default filters (see in the attachment) Got an access violation message at the point of instantiation but hoping I can get
    more detail on the specifics of the access violation.
    should I remove some or all of the filters? procmon is so verbose I'm hesitant on getting it more detailed. Also just not sure how much detail is available for access violation.

    from the procmon log:
    41:29.2 w3wp.exe 7852 RegOpenKey HKCR\MyProg.clsMyProg ACCESS DENIED
    41:29.2 w3wp.exe 7852 RegOpenKey HKU\S-1-5-20_CLASSES\MyProg.clsMyProg NAME NOT FOUND
    41:29.2 w3wp.exe 7852 RegOpenKey HKCR\MyProg.clsMyProg ACCESS DENIED
    Attached Files

  • #2
    Re: more detail from procmon needed

    Why not audit access to the registry key(s) in question? Information about the account and access involved will be logged to the Security event log.

    You can enable object access auditing in Local Security Policy (Local Policy > Audit Policy > Audit object access) or you can use a GPO. Audit settings for individual registry keys can be set using Regedit.

    Comment


    • #3
      Re: more detail from procmon needed

      thanks this looks like a great tip to find the problem, however.............
      this is a web iis application, and the user acct invoked for web transactions is the 'IUSR...' account, so I set the audit for the registry keys in question to full control for both success and fail. but there are no entries in the security events or any other events, maybe i have misunderstood what you are suggesting?

      Comment


      • #4
        Re: more detail from procmon needed

        You're saying the registry keys in question exist, and you enabled auditing of all events (and enabled "Object Access" auditing in the local security policy), and still nothing was logged to the security log? If so, that's beyond odd.

        There's nothing particular about the "IUSR_<something>" account, other than it being the account used by IIS to serve anonymous requests. If your web application contains a component that needs to access a registry key, the relevant IUSR_<blah> account will have to be granted at least read permissions to that key.

        Comment


        • #5
          Re: more detail from procmon needed

          thanks for ongoing with this thread.
          There are 3 different keys that the component .dll's would need to read, I set what I think is the audit for the 2 'IUSR...' accounts I can find for the folders where the keys reside. for IIS there is also an 'IWAM...' account but I don't think that one would be used for these registry reads. see attacment, (in the pic its not the iusr acct, this is just to show what I did). it seems odd for all those permissions that I'm setting up to audit there is no simple 'read'
          Attached Files

          Comment


          • #6
            Re: more detail from procmon needed

            Unless these keys are regularly accessed by a number of different processes, you might as well enable auditing for "Everyone" or "Authenticated Users". That way, you're guaranteed to find out exactly which account is doing (or attempting to do) what.

            Comment


            • #7
              Re: more detail from procmon needed

              ahh, good idea, but will have to wait until monday, will post back then, should be interesting to what accounts are doing what

              Comment

              Working...
              X