-
Похожий контент
-
От ZombOs
Столкнулся с вирусом при попытке проверить файл на Вирус тотал. При просмотре диспетчера, заметил подозрительный процесс под именем "COM Surrogate", который дублировал сам себя и потреблял большой ресурс процессора. При попытке отключения процесса через диспетчер задач, процесс завершается и происходит резкий выход из диспетчера. При попытке перейти по расположению файла открывается проводник, после диспетчер и проводник резко закрываются. При попытке найти папку через безопасный режим ее нет на месте. А с подключением в интернет вовсе не работает безопасны режим. При попытке скачать антивирус пишеь, "Операция отменена из-за ограничений, действующих на этом компьютере. Обратитесь к системному администратору". На форма нашел пост, где говорится про программу AV block remover. Скачав ее через USB, запустил ее и получил следующие файл https://vk.com/away.php?to=https%3A%2F%2Fdrive.google.com%2Fdrive%2Ffolders%2F1tFVD4TYYqrMnXJZRZQbLncv3C9BjLZDK%3Fusp%3Dsharing&utf=1. В посте указали данный форм для обращения за помощью.
delminer.txt
-
От iaroslav
Я подозреваю что у меня майнер или троян так как у меня не открываются параметры( все способы перепробовал) а также при открытии например панели управления выскакивает табличка: операция отменена из за огранечений..... Обратитесь к администратору хотя я и есть администратор. Перед этим я использовал AVbr и только потом AutoLogger
AV_block_remove_2025.02.02-17.03.log report2.log report1.log CollectionLog-2025.02.02-17.19.zip
-
От Ivan Serov
Приветствую. Спокойно сидел в пк, как вдруг завис экран на одной картинке, звук непрерывный и потом компьютер перезагрузился. Стоит запись "Дамп памяти ядра". При необходимости могу скинуть.
Компьютер был перезагружен после критической ошибки. Код ошибки: 0x0000007e (0xffffffffc0000005, 0xfffff80454f90e36, 0xffff968309bf5d28, 0xffff968309bf5560). Дамп памяти сохранен в: C:\WINDOWS\MEMORY.DMP. Код отчета: e629bc3c-8a0e-450c-a73a-9176ef5d590d.
Прикладываю малый дамп, сведения о системе и DxDiag.
Desktop.zip
-
От KL FC Bot
Примерно год назад произошел масштабнейший ransomware-инцидент — атака на гиганта американского медицинского страхования, компанию UnitedHealth Group. Взлом имел настолько многочисленные и серьезные последствия, что все прошедшее с момента атаки время появлялись новые подробности о ходе атаки и ее итогах. К годовщине инцидента мы решили собрать все теперь уже доступные данные в одном материале.
Ransomware-атака на UnitedHealth Group
Сперва дадим контекст, который будет в особенности полезен для тех, кто не очень хорошо знаком с данной организацией. UnitedHealth Group — это крупнейшая компания на рынке медицинского страхования и медицинских услуг США. Ее капитализация составляет примерно $500 миллиардов. При этом UnitedHealth Group занимает девятое место по выручке среди всех корпораций мира, следуя в этом списке сразу после Apple.
В состав UnitedHealth Group входят две компании. Первая из них, UnitedHealthcare, занимается медицинским страхованием. Вторая, Optum, специализируется на предоставлении разнообразных медицинских услуг — от фармацевтики и собственно медицинского обслуживания до ИТ-систем, используемых в здравоохранении.
Последним занимается OptumInsight — одно из трех подразделений Optum, причем самое высокомаржинальное из них. Осенью 2022 года в OptumInsight вошла приобретенная UnitedHealth Group платформа Change Healthcare. Эта цифровая площадка обрабатывает заявления на получение страховых выплат, выступая в роли финансового посредника между пациентами, поставщиками медицинских услуг и страховщиками.
Собственно, Change Healthcare и стала непосредственной целью атаки вымогателей: 21 февраля в ее системах начал работать шифровальщик, из-за чего платформа стала недоступна. Это вызвало настоящий хаос в американской системе здравоохранения: из-за невозможности быстрой обработки заявлений на страховые выплаты многие пациенты вынуждены были оплачивать лекарства и медицинские услуги из своего кармана. А медицинским учреждениям пришлось перейти в ручной режим обработки счетов.
Восстановление пострадавших систем заняло многие месяцы: к примеру, клиринговый сервис Change Healthcare возобновил работу лишь в ноябре. В UnitedHealth Group даже создали специальный сайт, на котором можно следить за восстановительными работами. Даже сейчас, спустя год после атаки, на этом сайте публикуются регулярные обновления, а некоторые системы до сих пор имеют статус «доступна частично».
View the full article
-
От KL FC Bot
Чуть больше года назад в посте Google OAuth и фантомные аккаунты мы уже обсуждали, что использование опции «Вход с аккаунтом Google» в корпоративные сервисы дает возможность сотрудникам создавать фантомные Google-аккаунты, которые не контролируются администратором корпоративного Google Workspace и продолжают работать после оффбординга. Недавно выяснилось, что это не единственная проблема, связанная с OAuth. Из-за недостатков этого механизма аутентификации любой желающий может получить доступ к данным многих прекративших деятельность организаций, перерегистрировав на себя брошенные компаниями домены. Рассказываем подробнее об этой атаке.
Как работает аутентификация при использовании «Вход с аккаунтом Google»
Некоторые могут подумать, что, доверяя опции «Вход с аккаунтом Google», компания получает надежный механизм аутентификации, использующий продвинутые технологии Google и широкие возможности интернет-гиганта по мониторингу пользователей. Однако на деле это не так: при входе с Google OAuth применяется достаточно примитивная проверка. Сводится она, как правило, к тому, что у пользователя есть доступ к почтовому адресу, который привязан к Google Workspace организации.
Причем, как мы уже говорили в предыдущем материале о Google OAuth, это вовсе не обязательно Gmail — ведь привязать Google-аккаунт можно совершенно к любой почте. Получается, что при использовании «Входа с аккаунтом Google» доступ к тому или иному корпоративному сервису защищен ровно настолько надежно, насколько защищен почтовый адрес, к которому привязан Google-аккаунт.
Если говорить несколько более подробно, то при аутентификации пользователя в корпоративном сервисе Google OAuth отправляет этому сервису следующую информацию:
В теории в ID-токене Google OAuth есть уникальный для каждого Google-аккаунта параметр sub, но на практике из-за проблем с его использованием сервисы проверяют лишь домен и адрес электронной почты. Источник
View the full article
-
Рекомендуемые сообщения
Пожалуйста, войдите, чтобы комментировать
Вы сможете оставить комментарий после входа в
Войти