Re: Process running under Adminstrator account

Gregg Hill wrote:
Lanwench,

When I first asked this question, it was in a thread about stopping,
or finding the source of, an attack on the RWW port of SBS.
Basically, my question was related to that and asked regarding
attacks on a terminal server's external 3389 port, assuming all other
ports are firewalled.
Under that condition, if an attack took place from the WAN, would not
a changed admin name be of benefit, requiring a guess of both the
name and the password, instead of just an attack on "administrator"
until a password is guessed (assuming one had a weak password)? Am I
to understand that an LDAP lookup can occur from the WAN with only
port 3389 open?
In other words, obscuring the administrator account by a name change
would help protect against WAN attacks, correct?

Gregg Hill

We probably don't want to go too far down the "how to crack into..." road
here.

Your statement is correct within the context, but in practicality, not *all*
ports but 3389 are going to be blocked. Also 3389 isn't inherently secure by
itself and likely there are other ways in or methods to suggest the value of
the renamed administrator.

Is it a benefit? I wouldn't argue that it wasn't. Perhaps only how much of a
benefit.

Admin rename really should be used as a stall / detection mechanism. All the
other best practices should be in place as well.





"Lanwench [MVP - Exchange]"
<lanwench@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message news:uIC%235mT%23HHA.1168@xxxxxxxxxxxxxxxxxxxxxxx
Gregg Hill <bogus@xxxxxxxxxxx> wrote:
So in the case I presented, i.e., a terminal server on 3389, would
not the changed admin name be of some security benefit?

It sounds as though the attack mentioned by Lanwench is an attack
from the LAN, not the WAN.

Or did I just completely miss the point?

Gregg Hill

Anyone who is authenticated as a user (or computer, I think) can do
the LDAP lookup.....meaning, any end user account that's compromised
can do this.


"kj [SBS MVP]" <KevinJ.SBS@xxxxxxxxxxxxxxxxxx> wrote in message
news:OI$0e8O%23HHA.4732@xxxxxxxxxxxxxxxxxxxxxxx
Gregg Hill wrote:
Lanwench,

You mentioned the well-known SID issue in a reply to someone on
9/1/07 in this same newsgroup ("Tracing a break-in attempt"). I
asked some more questions, but they got missed, so here they are
again. I did not realize the SID was all that was needed (or is
it?). However, let's say one has a terminal server with 3389 open
to the Internet (I know a VPN first or firewall authentication
first would help). How does the hacker try to get into the TS?
Don't they just start with "administrator" and a dictionary or
other attack? In that case, would not the changing of the admin
name help? How does the "well-known SID" factor into such an attack?

Renaming the account does not change the SID. The Administrator SID
always ends in -500. So, a simple ldap search of the AD sids
locates the renamed administrator account and provides the account
name to target for hacking. However, anonymous ldap AD searches
are blocked by default in 2003,
so now an authenticated account needs to make the ldap query
(users, computers, or services accounts).





"Lanwench [MVP - Exchange]"
<lanwench@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote
in message news:OslDm0G%23HHA.5980@xxxxxxxxxxxxxxxxxxxxxxx
Ryan <Ryan@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
I disabled the administrator account for security reasons. At
the same time the event log shows failed administrator logon
attempts. Attempts repeat every 2 till 5 hours. The calling
process has PID 944 which I looked up as svchost process.
This refers to the following services:

svchost.exe 944 AeLookupSvc, AppMgmt, BITS,
Browser, CryptSvc, dmserver,
EventSystem, helpsvc,

lanmanserver,
lanmanworkstation, Netman,

Nla, RasMan, RemoteAccess,
Schedule, seclogon, SENS, ShellHWDetection,
winmgmt,
wuauserv

I can not find any service that starts with Administrator
account. Does someone have any suggestions?

As Susan said, you need to re-enable it.

I don't bother to rename the admin account anymore, either.
Security by obscurity = pretty useless, as anyone trying to hack
into your server is going after the well-known SID anyway.

--
/kj

--
/kj


.

Relevant Pages

  • RE: Mysterious "Support" account created on Win2k server
    ... Once a worm/trojan or an attacker successfully connect to a system via port ... Once a system is compromised with an administrator account, ... > for guessing admin ids and passwords. ...
    (Incidents)
  • Re: Stop having to do the authentication check in OS X?
    ... Not if he has an admin account with no password, it isn't secure. ... the contents of the old administrator home folders contents to the new ... In other words can an attack happen no ...
    (comp.sys.mac.system)
  • Re: Process running under Adminstrator account
    ... It sounds as though the attack mentioned by Lanwench is an attack ... I did not realize the SID was all that was needed. ... Renaming the account does not change the SID. ... The Administrator SID ...
    (microsoft.public.windows.server.sbs)
  • Re: Administrator account renamed
    ... NT 4.0 and the "redbutton" attack. ... since "Administrator" account uses one of several "well known SID's". ... >> How can I reinstate the original adminidtrator account name ??? ...
    (microsoft.public.windowsxp.security_admin)
  • Re: Process running under Adminstrator account
    ... an attack on the RWW port of SBS. ... obscuring the administrator account by a name change would ... I did not realize the SID was all that was needed. ...
    (microsoft.public.windows.server.sbs)