Открыть список
Как стать автором
Обновить

Комментарии 28

Вывод. Видите в процессах касперского — бейте тревогу )))
Особенно, если каспера у вас до этого не было=)
Какая есть реальная необходимость подобным объектам иметь доступ в инет или подключать к ним левые носители данных?
Необходимость в удобствах и скорости. Из личного опыта, работал на мебельной фабрике с двумя станками с ЧПУ. До момента пока у меня дошли руки, сотрудник носил программы на дискетке (начало 2000х) в цех (в одну сторону 50-100м). Причём работал так не один год и считал, что так всё и должно быть. Потом, примерно после года работы, во время ремонта сварщики обрезали витую пару… на всё предприятие стоял вой «я не могу работать».
С другой стороны не все предприятия имеют отдел информационной безопасности, который бы боролся с угрозами.
С третьей стороны, даже там, где такой отдел есть, зачастую на требования этого отдела забивают болт. Типа «а чё такого если пол предприятия знает учётки и пароли друг друга».
И самое главное — каждый считает, что его пронесёт…
интернет для этого не нужен же
А там же стоял VPN, значит была какая-то необходимость удалённого подключения.
Подумалось: раньше удалённые подключения шли по номеру телефона, через модем, и было гораздо безопаснее. Это достигалось за счёт того, что канал передачи отделялся от передаваемой информации. А сейчас и канал VPN организуется по IP, и внутренние данные тоже по IP.
А сейчас что простыми средствами позволит увеличить безопасность удалённого подключения, даже если средства удалённого доступа содержат уязвимости? Разве только длинный псевдослучайный IPv6 адрес, который не отвечает на traceroute/ping, и не подбирается перебором, и с которого нет исходящих подключений, чтобы он нигде в инете не засветился.
Или port knocking какой-нибудь, но это уже дополнительные какие-то приложения нужны. IPv6 адрес раз выдал, вбил, и пользуйся.
Либо специфические средства вроде VPN на уровне провайдера (а не через интернет), или выделенного APN у мобильного оператора.
Заголовок конечно радует… шифровальщики наступают… А по факту ломанули систему где минимум два года не платили за обновления. Надо купить касперсокго, не обновлять его два года, а потом можно уже и статью написать о то как из-за него проблемы возникли.
Т.е. по сути весь посыл статьи в жлобстве выделения денег на безопасность, но никак не в шифровальщиках.
Ми скууузи, а зачем ставить [.] в IP адреса?
[.] в IP адреса

Чтобы антивирусы и прочие программы безопасности не ругались на то, что якобы нашли в тексте статьи этого зловреда.
Очень был рад когда шифровальщик пошифровал файлы на одном из серверов но не тронул единственное что было самое важное там — базу данных, потому что расширение файла выбрал для нее нестандартное.
Мы так бэкапы оберегали путем архивирования с каким-нибудь расширением типа *.xyz1

А кто мешает вирусописателю проверить не расширение, а заголовок файла. Вот если бы после сжатия еще и рандомизировать файл — уже меньше вероятности попасть в выборку для шифрования вируса

Никто не мешает, только надо времени побольше — рандомно скакать по всему диску, а надо же максимально быстро, чтобы никто не понял что случилось.
Полагаю свою долю попавших шифровальщик и так возьмет, незачем заморачиваться и пытаться найти все по содержимому
Ну так это у них надо спросить что им мешает. Они этого не делают и ищут конкретные расширения — это факт
Разрешен запуск исполняемого кода из темповых каталогов — это пять.
Хранение бэкапов на источнике бэкапа — суперпять.

Многие программы при установке распаковываются в темп, потом запускаются. Ну а здесь — была команда от администратора домена, поэтому вполне себе легальная операция.

Основная проблема, что до сих пор, епрст, есть проги, которые, сволочи, требуют права админа. Новые! Которые идут с приборами! Которым сеть нужна, чтоб результаты передавать в ИС.
Вот хочется взять некоторых программистов и… ну вы поняли…
(Хотя самый здец был, когда программа работала только от доменного админа, от локального — фиг. Вот что такого там навернули программисты?
Основная проблема, что, есть проги которые требуют права админа

В чем именно проблема, и как она решила бы данный кейс? Здесь идёт команда от администратора домена, на установку софта (будь то корпоративное обновление софта, или групповых/локальных политик итд). Ответственность полностью на админе, в надежде, что админ знает, что делает.
vviz Если бы запуск скриптов из темпа был запрещен, то хакеры запускали бы скрипты из другой директории, в чем проблема? Они и так получили контролера домена, они могут творить что угодно. Даже системно обратно разрешить запуск скриптов из темп директории, если они были бы запрещены.


Проблема здесь не в бэкапах, или настройках компа, а в том, что они ломанули учётку админа.

В том месте, что Mimikatz работает в том числе путём поиска хранящихся в винде данных аутентификации. То есть чем больше важного софта до сих пор не умеет работать от пользовательской учётки, тем проблемнее построить защищённую систему и не продолбать угрозу…
Точно, cmd-скрипт запустился… А если бы запуск из темпового каталога был запрещен — он бы не запустился… Разве не должно делать так, что бы он не запустился? Или Ваш комент ради комента?

Если запретить все такие скрипты из темпа, то половина прог перестала бы нормально устанавливаться.


Ваш комент ради комента?

Нет

Ваш коментарий как бальзам на рану. Пока есть люди, придерживающиеся такого мнения, я без работы не останусь.
Рад за вас. Но может вы перестанете вести себя как тролль, а предложите решение, которое будет всех устраивать? Ваши оба комментария в стиле «ну даа, вот дураки» не несут конструктива. А вариант «запретить запускать любые проги, даже админам» не устроит всех, очевидно.

Запретить админам логиниться под админской учёткой — как угодно: интерактивно, через VPN? Использовать админскую учётку только для запуска конкретных приложений через runas? (Если что, в университете про такое рассказывают и показывают.)

Ну вот есть у взломщиков доступ к учетке доменного админа или эскалация привилегий до него происходит, как в этом плане какие-то ограничения кому-то помешают?
Да, советы по поводу того, чтоб труднее было утечь учетке доменного админа — хорошие, пока у вас не должно крутится ПО, которое через подобное работает (и не то, которое глючит избирательно — под локальным админом не работает, а под доменным — да).
Но в каком месте это спасёт от случая, когда у злоумышленников есть доступ к доменному админу и из под него происходит установка всего прочего? Запуск из темпа ему запретите? И что?
В одном случае киберпреступникам удалось скомпрометировать учетку доменного администратора организации, которая была атакована. Ну а с этими данными все было уже просто — команда взломщиков воспользовалась фреймворком Cobalt Strike и инструментарием PowerShell для распространения вредоносного ПО внутри сети предприятия.
Запретить логиниться под админской учёткой

Обычно это везде так и есть. Сделано в том числе для того, чтобы случайно слив свой обычный пароль, не занести какую нибудь грязь, тк пароль от админской учётки другой.


Использовать админскую учётку только для запуска конкретных приложений через runas?

По сути, здесь все так и произошло. Был вызов runas, подставилась учетка админа, его пароль и произведен запуск вируса. Только это делалось через powershell, аналог ssh для windows.
Даже если такое можно было бы делать отдельной группе админов, то ничего не мешало злоумышленникам создать новую учётку и выдать ей любого админа, потому что у них суперправа контроллера домена — контроль любой учётки, любого компьютера и любой групповой политики (в ТЧ запрет на запуск чего либо откуда либо).

Ну зато теперь фирма получила урок, что бэкапы на оффлайн хранилке — это хорошо, может до того, что географически разнесённые бэкапы это ещё лучше, сами дойдут без сгорания серверной.
Конечно, когда почки отвалились можно начинать пить боржоми. Все уроки давно расписаны вдоль и поперек — если знания не привлекаются, то значит у руля аникейщик, и произошедшее проникновение предсказуемо.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.