защита паролем
-
Похожий контент
-
От 577kar
Добрый день, обнаружили заархивированные с паролем файлы. Текстовый файл с адресом для запроса пароля для выкупа.
Был открыт RDP порт на роутере для удаленного подключения на сервер, предположительно взлом или подбор паролей.
FRST.7z Mail.7z
-
От KL FC Bot
Когда вам предлагают войти в тот или иной онлайн-сервис, подтвердить свою личность или скачать документ по ссылке, обычно требуется ввести имя и пароль. Это привычная операция, и многие выполняют ее, не задумываясь. Но мошенники могут выманить ваш пароль от почты, сервисов госуслуг, банковских сервисов или соцсетей, сымитировав форму ввода логина-пароля известного сервиса на своем (постороннем) сайте. Не попадайтесь — пароль от почты может проверять только сам почтовый сервис и никто другой! То же касается госуслуг, банков и соцсетей.
Чтобы не стать жертвой обмана, каждый раз при вводе пароля нужно на секунду задуматься и проверить, куда именно вы входите и что за окошко требует вводить данные. Здесь есть три основных варианта: два безопасных и один мошеннический. Вот они.
Безопасные сценарии ввода пароля
Вы входите в свои почту, соцсеть или онлайн-сервис через их собственный сайт. Это самый простой вариант, но нужно убедиться, что вы действительно заходите на легитимный сайт и в его адресе нет никакой ошибки. Если вы заходите в онлайн-сервис, нажав на ссылку в присланном вам сообщении или перейдя по ссылке из результатов поиска, перед вводом пароля внимательно сверьте адрес сайта с названием требуемого сервиса. Почему так важно потратить лишнюю секунду на проверку? Создание фишинговых копий легитимных сайтов — любимый прием мошенников. Адрес фишингового сайта может быть очень похожим на оригинальный, но отличаться от него на одну или несколько букв в названии или располагаться в другой доменной зоне — например, в фишинговом адресе вместо буквы «i» может стоять «l».
А уж сделать ссылку, выводящую совсем не туда, куда написано, и вовсе несложно. Проверьте сами: вот эта ссылка якобы на наш блог kaspersky.ru/blog выводит на другой наш блог — securelist.ru.
На рисунке ниже — примеры оригинальных страниц входа на разные сервисы, на которых можно смело вводить имя и пароль от этого сервиса.
Примеры легитимных страниц входа на разные сервисы. Вводить имя и пароль на них безопасно
Вы входите на сайт при помощи вспомогательного сервиса. Это — вариант для удобного входа без создания лишних паролей: так часто заходят в программы для хранения файлов, совместной работы и так далее. В роли вспомогательного сервиса обычно выступают большие провайдеры почты, соцсетей или государственных услуг. Кнопка входа называется «Вход через Госуслуги», «Войти с VK ID», «Sign in with Google», «Continue with Apple» и так далее.
View the full article
-
От K0st
Здравствуйте! Обнаружили запароленные данные. Архивы по нескольку десятков ГБ. Базы 1С и всё такое. В корне файл с описанием выкупа. Как можно распаковать и всё вернуть?
-
От dexter
Всем привет.
Открыл меню Плюса и увидел сообщение (скрин). Ладно, залез в BIOS и включил виртуализацию и попутно (по совету в одной из профильных статей ЛК) параметр VT-d.
Опять посетил Настройку защиты ввода данных и опять сообщение "... Обнаружено несовместимое устройство или программное обеспечение."
Хорошо. По поводу устройства - ясен пень, имеется в виду модуль TPM . Но он у меня не установлен. Это я знаю точно, поскольку я его не покупал и не устанавливал ( как мне разъяснили в одном из магазинов,
сие устройство запрещено к оф. продаже). Разъём на плате есть, а самого модуля - нету.
Смотрим и читаем дальше много букв в одной из профильных статей от ЛК. И оказывается, что причин о несовместимости программного обеспечения может быть несколько - https://support.kaspersky.ru/common/safemoney/13713#block1
то что вверху написано - не суть важно. Листаем список ниже. И что мы там видим ? А то, что под программным обеспечением имеется в виду в том числе Изоляция ядра и Smart App Control.
У меня, на начальной стадии использования винды-11 Smart App Control отключен, т.к. находится в режиме "Оценка".
А теперь такой вопрос к разработчикам : нельзя как-то решить эту коллизию с Smart App Control , Изоляцией ядра и защитой ввода данных с использованием аппаратной виртуализации ?
Или вы реально решили, что для функционирования Плюса в том виде, как Вы задумали , надо отключить несколько функций по обеспечению безопасности в самой системе ?
-
От KL FC Bot
Сразу после католического Рождества стало известно о многоэтапной атаке на разработчиков популярных расширений Google Chrome. Самой известной целью по иронии судьбы стало ИБ-расширение от компании Cyberhaven, скомпрометированное прямо перед праздниками (о таких рисках мы предупреждали). По мере расследования инцидента список пополнился как минимум 35 популярными расширениями с суммарным числом установок 2,5 млн копий. Целью злоумышленников является похищение данных из браузеров пользователей, которые установили троянизированные обновления расширений. В ходе данной кампании преступники фокусировались на похищении учетных данных от сервисов Meta* с целью компрометации чужих бизнес-аккаунтов и запуска своей рекламы за чужой счет. Но, в теории, вредоносные расширения позволяют похищать и другие данные из браузера. Рассказываем о том, как устроена атака и какие меры принять для защиты на разных ее этапах.
Атака на разработчиков: злоупотребление OAuth
Чтобы внедрить троянскую функциональность в популярные расширения Chrome, преступники разработали оригинальную систему фишинга. Они рассылают разработчикам письма, замаскированные под стандартные оповещения Google о том, что расширение нарушает политики Chrome Web Store и его описание необходимо скорректировать. Текст и верстка сообщения хорошо мимикрируют под типовые аналогичные письма Google, поэтому для жертвы письмо выглядит убедительно. Более того, во многих случаях письмо отправляется с домена, специально зарегистрированного для атаки на конкретное расширение и содержащего название расширения прямо в имени домена.
Клик по ссылке в письме приводит на легитимную страницу аутентификации Google. Пройдя ее, разработчик видит еще один стандартный экран Google, предлагающий авторизоваться по OAuth в приложении Privacy Policy Extension и в рамках входа в это приложение дать ему определенные права. Эта стандартная процедура проходит на легитимных страницах Google, только приложение Privacy Policy Extension запрашивает права на публикацию расширений в Web Store. Если разработчик дает такое разрешение, то авторы Privacy Policy Extension получают возможность публикации обновлений в Web Store от лица жертвы.
В данном случае атакующие не крадут пароль и другие реквизиты доступа разработчика, не обходят MFA. Они просто злоупотребляют системой Google по делегированию прав, чтобы выманить у разработчика разрешение на обновление его расширения. Судя по длинному списку зарегистрированных злоумышленниками доменов, они пытались атаковать гораздо больше, чем 35 расширений. В тех случаях, когда атака проходила успешно, они выпускали обновленную версию расширения, добавляя в него два файла, ответственные за кражу куки-файлов и других данных Facebook** (worker.js и content.js).
View the full article
-
Рекомендуемые сообщения
Пожалуйста, войдите, чтобы комментировать
Вы сможете оставить комментарий после входа в
Войти