none
Блокировка учетных записей при эпидемии Kido (Conficker) RRS feed

  • Общие обсуждения

  • Подскажите пожалуйста, почему могут лочиться акаунты при эпидемии Kido? Все патчи на серверах стоят, на контроллерах домена инфекций не вижу, но в логах возникает вот такой Event 644 причем без всяких инвалид аттемпт логонов просто Locked Out и все тут. Сразу и бесповоротно. 

    User Account Locked Out:
      Target Account Name: da8
      Target Account ID: DOMAIN\imuhina
      Caller Machine Name: MKRYLOVA
      Caller User Name: DC01$
      Caller Domain: DOMAIN
      Caller Logon ID: (0x0,0x3E7)

    Я уже убрал политику которая накладывалась для блокирования учетных записей после 10 попыток, но почему-то все равно блокируются многие учетные записи. Подскажите где копать. Рабочие станции обрабатываются в данный момент антивирусной утилитой КК, но почему контроллеры лочат акаунты кто нибудь может мне тупому объяснить? Причем лочат они не всегда свои акаунты под которыми зарегистрирован пользователь, а откуда-то берут даже те акаунты пользователей которых вообще не было отродясь на этих машинах и они в данный момент ни где не залогинены, как например в приведенном примере с машины MKRYLOVA с акаунтом imuhina заблокировна запись da8
    22 июля 2009 г. 6:45

Все ответы

  • Воспользуйтесь вот этим инструментом для поиска причины блокирования аккаунтов: http://support.microsoft.com/kb/824209
    Поможем друг другу стать лучше! Отметим правильные ответы и полезные сообщения!
    22 июля 2009 г. 7:00
    Модератор
  • Kido использует несколько путей для своего распространения.

    1. Атака служб RPC на непропатченных машинах.
        Предотвращается своевременной установкой обновлений.
    2. Атака компьютеров локальной сети с заражённой машины посредством перебора паролей учётных записей.
        Для получения списка учётных записей Kido умеет анализировать список папок локальных профилей и запрашивать домен.
        Предотвращается своевременной настройкой политики Account Lockout + применением passprop для защиты администраторов. Отключение этой политики делает сеть уязвимой для множества разнообразных атак. Epic Fail.

        Что мне непонятно в вопросе - как могут быть заблокированы пользователи, которых "отродясь не было". Их же нет.

    3. Атака посредством autorun.inf на сменных носителях.
        Предотвращается настройкой политик Software Restriction Policies.
    4. Классическое вирусное распространение.
        Предотвращается строгим запретом на работу с административными привилегиями. Рядовой пользователь заразить систему или напортачить в реестре не сможет - нет прав.



    Что делать дальше?

    - Отключать защитные механизмы - исключено. Бейте по рукам того, кто это предлагает делать.
    - Искать поражённые машины, в событиях Event Log вы можете найти IP-адреса или имена этих машин.
       Такие системы форматировать и переинсталлировать с нуля, ибо некоторые штаммы Kido используют технологию rootkit. Такое даже не надейтесь найти и обезвредить, только уничтожать под корень.
    - Применить указанные выше методики (обновления, Account Lockout и SRP) для предотвращения заражения. Не пытаться что-то "лечить", когда лечить уже, в общем-то, уже нечего.
    - Не надеяться на антивирусные программы, ибо они не защищают от вирусов. Фундамент по-настоящему эффективной защиты от вирусов - работа с ограниченными привилегиями.

    22 июля 2009 г. 7:10
    Отвечающий
  • Cпасибо, но следствие я вижу и без инструмента - просто возникает Event 644 и все. Никаких попыток вломиться куда нибудь под этим логином нету. Я не мог понять почему вообще логин блокируется, ведь на контроллерах стоят все патчи и инфекции не обнаружено.
    22 июля 2009 г. 8:44
  • Это я в курсе насчет перебора, но меня смущает то, что никаких переборов я по логам не вижу. Сразу возникает эвент 644 и Failure эвентов я не вижу вообще. Которых "отродясь не было" - имелось ввиду что эти пользователи на эти машины сроду не заходили и откуда спрашивается оно может знать их имена пользователей?

    Насчет форматировать и переинсталировать это как-то круто помоему - оно же вычищается успешно утилитой касперского и по крайней мере на запатченой и почищеной машине больше пока не проявлялось. 

    За советы в любом случае спасибо
    22 июля 2009 г. 8:50
  • Если идет перебор паролей, то учетки будут блокироваться. Если вирус подобрал пароль, то он использует взломанную учетку для распространения по сети.
    Сазонов Илья http://www.itcommunity.ru/blogs/sie/
    22 июля 2009 г. 8:51
    Модератор
  • Почему тогда я по логам не вижу Failure эвентов которые обычно есть при подборе паролей? 
    22 июля 2009 г. 8:58
  • А где смотрите? Учетки просто так не блокируются же....
    Сазонов Илья http://www.itcommunity.ru/blogs/sie/
    22 июля 2009 г. 10:44
    Модератор
  • Вот и мне так как казалось. Смотрю Security Log включен аудит account management, logon events, accounts logon events success & failure. Но ни одного Failure я почему-то не вижу. Более того политика которая блокирует записи через 10 попыток сейчас отключена. 
    22 июля 2009 г. 10:48
  • есть подозрение, что смотрите не в той политике.
    Посмотрите Group Policy Results для этой машины - можка, на самом деле и аудит другой, и локаут тоже.
    22 июля 2009 г. 11:34
    Отвечающий
  • Смотрел. Уже все что можно в аудите включил - нету Failure по крайней мере массовых точно нету. Тут мысль в голову пришла, что мог быть подобран пароль администратора домена и с помощью него оно тупо лочит акаунты, буду трясти инженеров владеющих правами - может действительно кто-то накосячил. Но одного я так и не понял, каким образом пароль блокируется с разных машин с акаунтов юезров у которых вообще прав никаких нету. Насколько я знаю искуственным интеллектом Conficker не обладает и между собой инфицированные машины вроде бы не общаются :)
    23 июля 2009 г. 3:33