Appreciate it! The share function must get clobbered by the bug. If it is Virut, then according to the blurb, plenty of executables become infected. I have tried all the hidden shares and the RPC$ facility, which was the only one I had success with. I'm not a programmer but from what I understand, it is possible to effect change on a remote system via the RPC mechanism.
-- Peter van Houten On the 14 May, 2010 01:58, Jon Harris wrote the following:
Could the share be restricted some other way? Hey trying to hand you a straw that might become a rope. Jon On Thu, May 13, 2010 at 7:53 PM, Peter van Houten <[email protected] <mailto:[email protected]>> wrote: 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 <[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>> 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:[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>] *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 <[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>> 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 <[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>> <mailto:[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>>> 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 <[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>> <mailto:[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>> <mailto:[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>> <mailto:[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>>>> 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/> ~
