It is really odd the way it properly parses the login credentials but
won't accept the same credentials when one tries to map to a share,
remote regedit, computer management, etc (all rejected "access denied")

--
Peter van Houten

On the 14 May, 2010 01:43, Jon Harris wrote the following:
Sorry was not paying attention to that.  It sounds like it is time to
get a ticket and pack a bag unless he has someone closer that could go
do the work.
Jon

On Thu, May 13, 2010 at 7:41 PM, James Hill
<james.h...@superamart.com.au <mailto:james.h...@superamart.com.au>> wrote:

    He covered that one.

                What can't be done / makes no difference:

                4) Map drives to *any* shares from another box

    *From:* Jon Harris [mailto:jk.har...@gmail.com
    <mailto:jk.har...@gmail.com>]
    *Sent:* Friday, 14 May 2010 9:40 AM

    *To:* NT System Admin Issues
    *Subject:* Re: XP Box inaccessible

    What about just mapping the drive's admin share and pulling what you
    need?

    Jon

    On Thu, May 13, 2010 at 7:34 PM, Peter van Houten
    <peter...@gmail.com <mailto:peter...@gmail.com>> wrote:

    Well ironically, it is far from "hung" but I know what you mean. There
    are a number of bugs that have this effect; the less elaborate just
    overwrite files such as userinit.exe with their own code, make a few reg
    changes and cause the login problem.

    Type in the login and password, off it goes..."loading your personal
    settings"...but then instead of going to the desktop, it simply logs
    off.

    So the computer is "running" and one can observe certain
    processes remotely as I pointed out. One just can't get any %$#&@(&$!
    work done!

    --
    Peter van Houten

    On the 14 May, 2010 01:21, Jon Harris wrote the following:

    So what you have is a hung box some where between logon and logoff?
    Jon

    On Thu, May 13, 2010 at 7:09 PM, Peter van Houten
    <peter...@gmail.com <mailto:peter...@gmail.com>

    <mailto:peter...@gmail.com <mailto:peter...@gmail.com>>> wrote:

        Thanks Jon; I probably didn't lay out my explanation properly
    but I do
        have remote access; it simply goes through the same login-logoff
    routine
        as a local login.

        --
        Peter van Houten

        On the 14 May, 2010 00:58, Jon Harris wrote the following:

            Isn't there a GPO that would turn on remote access for Domain
            Admins?
            If it is part of a domain and you have access to the Domain
            Controller
            then just have it restarted once or twice and you should be good
            to go.
            Jon

            On Thu, May 13, 2010 at 6:26 PM, Peter van Houten
    <peter...@gmail.com <mailto:peter...@gmail.com>
    <mailto:peter...@gmail.com <mailto:peter...@gmail.com>>

    <mailto:peter...@gmail.com <mailto:peter...@gmail.com>
    <mailto:peter...@gmail.com <mailto:peter...@gmail.com>>>> wrote:

                I have a XP Pro [fully patched :-) ] box on a network that
            has been
                infected (probably Virut). It is the classic login...loading
            your
                personal settings...logging off scenario.

                Recovering the data and fixing the malware problem is easy.
            The real
                problem is that the box is 300 miles away, so I am trying to
            avoid
                flying there tomorrow, just before the weekend.

                What can't be done / makes no difference:
                -----------------------------------------------------------
                1) Login locally (admin credentials make no difference)
                2) Login remotely using RDP or VNC, directly via VPN or via
            another box
                on the remote network (goes through the motions as above).
                2) Start in any form of safe mode.
                3) Restore to earlier date, last known good config.
                4) Map drives to *any* shares from another box
                5) Use any clever login scripts on the server
                6) Use psexec to run anything remotely.
                7) Instruct the user to step through anything technical :-(

                What can be done:
                --------------------------
                1) Ping the box
                2) Netbios is enabled, so it shows in network
                3) Scan the IP and show ports 139 and 445 open
                4) Open and close a null RPC connection (enum, etc not
    helping)

                My hope is that one of you boffins has a script that will,
            via RPC turn
                on the telnet server, open port 23 and let me copy a
            document from the
                desktop [aarrgh] to USB. Or something equally as clever...

                TIA but please no advice on malware,

                --
                Peter van Houten

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

Reply via email to