Metasploit Weekly Wrap-Up 01/12/24

Post Syndicated from Christopher Granleese original https://blog.rapid7.com/2024/01/12/metasploit-weekly-wrap-up-01-12-24/

New module content (1)

Windows Gather Mikrotik Winbox "Keep Password" Credentials Extractor

Metasploit Weekly Wrap-Up 01/12/24

Author: Pasquale ‘sid’ Fiorillo
Type: Post
Pull request: #18604 contributed by siddolo
Path: windows/gather/credentials/winbox_settings

Description: This pull request introduces a new post module to extract the Mikrotik Winbox credentials, which are saved in the settings.cfg.viw file when the "Keep Password" option is selected in Winbox.

Enhancements and features (7)

  • #18515 from errorxyz – This PR adds a Java target for the ManageEngine ServiceDesk Plus exploit CVE-2022-47966 using the payload mentioned in this blogpost and deletes the log file that records the error due to the exploit to make it more stealthy.
  • #18672 from h00die – Fix spelling mistakes in Metasploit’s library folder.
  • #18673 from h00die – Fix spelling mistakes in Metasploit’s scripts folder.
  • #18674 from h00die – Fix spelling mistakes in Metasploit’s plugins folder.
  • #18675 from h00die – Fix spelling mistakes in Metasploit’s tools folder.
  • #18679 from h00die – Fix spelling mistakes in Metasploit’s auxiliary modules.
  • #18691 from zeroSteiner – Metasploit console now requires an installed version of apktool greater than or equal to v2.9.2.

Bugs fixed (5)

  • #18656 from dwelch-r7 – Enforces all modules to be loaded as part of reload_all when the defer_module_loads feature is enabled.
  • #18666 from zeroSteiner – Fixes a crash when running the save command to save Metasploit’s configuration.
  • #18667 from zeroSteiner – Re-adds the #sysinfo instance method for sessions.
  • #18669 from sjanusz-r7 – Updates the favorites command to no longer output an empty message when a chosen module does not have custom datastore values available.
  • #18690 from sjanusz-r7 – Ensures that a target’s default payload is correctly chosen when selecting a module from the search command.

Documentation

You can find the latest Metasploit documentation on our docsite at docs.metasploit.com.

Get it

As always, you can update to the latest Metasploit Framework with msfupdate
and you can get more details on the changes since the last blog post from
GitHub:

If you are a git user, you can clone the Metasploit Framework repo (master branch) for the latest.
To install fresh without using git, you can use the open-source-only Nightly Installers or the
commercial edition Metasploit Pro

Linux Mint 21.3 “Virginia” released

Post Syndicated from jake original https://lwn.net/Articles/958162/

The Linux Mint distribution has announced the release of Linux Mint 21.3, which is codenamed “Virginia”. It has the Cinnamon 6.0 desktop, “comes with full support for SecureBoot and compatibility with a wider variety of BIOS and EFI implementation“, has added new features to the Hypnotix TV-viewer application, and more. See the release notes for even more information about it.

Linux Mint 21.3 “Virginia” released

Post Syndicated from jake original https://lwn.net/Articles/958162/

The Linux Mint distribution has announced the release of Linux Mint 21.3, which is codenamed “Virginia”. It has the Cinnamon 6.0 desktop, “comes with full support for SecureBoot and compatibility with a wider variety of BIOS and EFI implementation“, has added new features to the Hypnotix TV-viewer application, and more. See the release notes for even more information about it.

Изкуственият интелект и персонализираната медицина

Post Syndicated from original https://www.toest.bg/izkustveniyat-intelekt-i-personaliziranata-meditsina/

Изкуственият интелект и персонализираната медицина

Изкуственият интелект (ИИ) използва сложни изчисления, позволяващи на системата да разсъждава, да се учи и да стига до определени изводи, които са от полза на лекарите при вземане на решения. Служейки си с информация като медицински изображения, биомаркери, медицински данни на пациенти и използвайки инструменти като конволюционни невронни мрежи* и регресионни модели, той има за цел да създаде персонализации, адаптирани към всеки пациент, с приложение в реалната клинична практика.

Въпреки че ИИ има голям потенциал в областта на медицината, етичната сложност на приложението му изисква допълнителни анализи и доказателства за медицинската му ефикасност и икономическата му стойност, както и създаването на мултидисциплинарни методи за по-широкото му внедряване в клиничната практика.

Персонализирана медицина

Персонализираната медицина е медицински модел, който има за цел да предостави специално разработени стратегии за превенция и лечение. Съветът на здравните министри на ЕС дефинира персонализираната медицина като

медицински модел, използващ характеризиране на фенотипове и генотипове на индивиди (чрез молекулярно профилиране, медицински изображения, информация за начина на живот и др.) за избор на терапевтична стратегия при конкретен пациент в определен период от живота му, за определяне на предразположеност към дадено заболяване, за навременна и целенасочена профилактика.

Персонализираната медицина все още се развива и пред нея стоят много предизвикателства преди пълното ѝ приложение в системите за здравеопазване. Новите генетични технологии, обобщавани с термина „омик“ технологии, позволяват на учените да използват генетичната информация на пациентите, за да определят по-добре правилното лекарство, доза и период на прием. Използването на тези технологии ни доближава по-близо до персонализираната медицина.

Изкуствен интелект

През 1956 г. Джон Маккарти въвежда термина „изкуствен интелект“ на конференция, посветена на компютърните науки в колежа „Дартмут“. По-късно същата година Алън Нюел, Дж. К. Шоу и Хърбърт Саймън създават Logic Theorist, първата работеща софтуерна програма за ИИ.

В най-простата си форма ИИ е област, която съчетава компютърни науки и огромен набор от данни, за да даде възможност за решаване на проблеми. Той също така обхваща част от машинното обучение и дълбокото обучение (machine learning, deep learning), споменавани често, когато става въпрос за ИИ. Тези дисциплини са изградени от ИИ алгоритми, които създават системи, правещи прогнози или класификации въз основа на входирани данни.

Приложение на изкуствения интелект в медицината

В момента ИИ в медицинските среди се използва основно за анализ на изображения от медицински изследвания. Стандартите за използването на ИИ в медицината все още са в процес на дефиниране. Възможността ИИ да бъде от по-значима полза за лекарите, изследователите и пациентите нараства експоненциално. В бъдеще той ще е основна част от цифровите здравни системи, които ще формират и поддържат съвременната медицина.

Моделите на машинно обучение може да се използват за наблюдение на жизнените показатели на пациенти. Докато медицинските устройства от типа на сърдечните монитори проследяват жизнените показатели, ИИ може да събира данните от тези устройства и да извършва анализ с цел търсене на заболявания. Изследванията показват, че ИИ, захранван от изкуствени невронни мрежи, може да бъде също толкова ефективен, колкото лекарите при откриване на симптоми например на рак на гърдата.

Първоначалното синтезиране на лекарства често е един от най-дългите и най-скъпи етапи при разработването на лекарствени продукти. Тук ИИ може да помогне за намаляване на разходите основно по два начина: създаване на по-добър дизайн на лекарства и откриване на нови комбинации от лекарствени препарати.

Къде се срещат ИИ и персонализираната медицина?

Геномиката, биотехнологиите и ИИ поставят отделния пациент в центъра на избора на лечение, създават големи бази данни за анализ и са основата на прецизната медицина

Падането на цената на секвениране на генома, усъвършенстването на биотехнологиите и навлизането на приложенията за смартфони, които проследяват здравето ни, водят до редица предизвикателства в съвременната медицина, свързани с необходимост от допълнително обучение на медицинския персонал и невъзможност за обработване на огромното количество данни. В ролята на помощници влизат алгоритмите за задълбочено обучение, които за кратко време анализират и интерпретират т.нар. big data.

През последните години няколко компании работят по въвеждането на ИИ в медицината. Google има изследователски клон, свързан с ИИ, който работи по проекта DeepMind Health. Идеята е да се събират и анализират данни от медицински досиета, за да се подобрят медицинските услуги. Google участва и в съвместен проект с фондацията на клиниката по очни болести Moorfields NHS Foundation Trust. Moorfields споделят с DeepMind един милион анонимни резултата от изследвания с очен скенер, придружени с информация за здравословното състояние на очите на пациентите и наличието на очни заболявания.

IBM работят по програмата Medical Sieve, насочена към радиологията и кардиологията. Идеята им е в бъдеще радиолозите да разглеждат само най-комплексните случаи, при които е необходимо човешко наблюдение. Компанията Deep Genomics работи върху търсенето на модели в големи бази данни от генетична информация и медицински досиета. Целта е установяване на мутации и връзката им с определени заболявания.

Въпреки ползите от внедряването на ИИ в персонализираната медицина, алгоритмите може да не са достатъчно ефективни при поява на нови, неописани странични ефекти от лекарства или новоустановена резистентност към дадено лечение. Изкуственият интелект трябва да е средство за помощ на лекаря, а не е предназначен да замени традиционната връзка лекар–пациент. Отменяйки лекаря в някои рутинни, повтарящи се моменти от работата, ИИ би могъл да предостави възможност на медиците да обръщат по-задълбочено внимание на пациентите си, което безспорно ще подобри връзката помежду им. Подобни задачи може да се делегират на ИИ само при условие че остане безопасен, регулиран и достатъчно ефикасен като средство за усъвършенстване на здравеопазването.

Етична рамка при използването на ИИ в медицината

Повдигат се редица етични въпроси, свързани със събирането и обработката на данни на пациентите в една система на здравеопазване, която теоретично би могла да се управлява от ИИ. Как ще се гарантират поверителността и сигурността на информацията? Пациентите трябва да са информирани как ще бъдат използвани техните данни от ИИ приложения, и е редно да им се предостави възможност за отказ.

От друга страна, нужно е работещите в здравеопазването да са добре запознати с новите отговорности, които биха носили при възникване на грешки в процесите на съхраняване и споделяне на данни, получени чрез ИИ. Освен това здравните специалисти трябва да оценяват критично препоръките, дадени от инструментите с ИИ. И не на последно място, медиците следва да бъдат откровени с пациентите си относно използването му в здравеопазването.

В САЩ съществува закон за преносимост и отчетност на здравното осигуряване, който определя стандарти за поверителност и сигурност на здравните данни на пациентите. Американската администрация по храните и лекарствата също има свой набор от разпоредби, осигуряващи регулация на начина, по който софтуер, включително приложения с ИИ, се използва в здравеопазването. Европейският съюз е въвел Общ регламент за защита на данните (GDPR), включващ правила за обработката на данни на пациенти с инструментите на ИИ.

Индивидуален vs. популационен подход

Напредъкът на персонализираната медицина заедно с навлизането на ИИ в здравеопазването цели внедряване на индивидуален подход за контрол на заболявания в замяна на настоящия популационен подход. Персонализираната медицина, ИИ и подробната информация за болестните състояния представляват значителен шанс за намаляване на разходите при използването на универсален подход в общественото здраве.

Предимствата, които са предоставени от ИИ моделите за анализиране на обширна, сложна биомедицинска информация, имат огромен потенциал за ускоряване на израстването и развитието на генетичната медицина. Въпреки това трябва да бъдат преодолени многобройни препятствия, в случай че ИИ оправдае високите очаквания за революция в геномната медицина.


* Конволюционна невронна мрежа – мрежова архитектура за deep learning, която се учи директно от данни, като се премахва необходимостта от ръчно извличане на функции.

[$] The first half of the 6.8 merge window

Post Syndicated from corbet original https://lwn.net/Articles/957188/

The 6.8 merge window has gotten off to a relatively slow start; reasons for
that include a significant scheduler performance regression that Linus
Torvalds stumbled
into
and has spent time tracking down. Even so, 4,282 non-merge
changesets have found their way into the mainline repository for the 6.8
release as of this writing. These commits have brought a number of
significant changes and new features.

Detect, mask, and redact PII data using AWS Glue before loading into Amazon OpenSearch Service

Post Syndicated from Michael Hamilton original https://aws.amazon.com/blogs/big-data/detect-mask-and-redact-pii-data-using-aws-glue-before-loading-into-amazon-opensearch-service/

Many organizations, small and large, are working to migrate and modernize their analytics workloads on Amazon Web Services (AWS). There are many reasons for customers to migrate to AWS, but one of the main reasons is the ability to use fully managed services rather than spending time maintaining infrastructure, patching, monitoring, backups, and more. Leadership and development teams can spend more time optimizing current solutions and even experimenting with new use cases, rather than maintaining the current infrastructure.

With the ability to move fast on AWS, you also need to be responsible with the data you’re receiving and processing as you continue to scale. These responsibilities include being compliant with data privacy laws and regulations and not storing or exposing sensitive data like personally identifiable information (PII) or protected health information (PHI) from upstream sources.

In this post, we walk through a high-level architecture and a specific use case that demonstrates how you can continue to scale your organization’s data platform without needing to spend large amounts of development time to address data privacy concerns. We use AWS Glue to detect, mask, and redact PII data before loading it into Amazon OpenSearch Service.

Solution overview

The following diagram illustrates the high-level solution architecture. We have defined all layers and components of our design in line with the AWS Well-Architected Framework Data Analytics Lens.

os_glue_architecture

The architecture is comprised of a number of components:

Source data

Data may be coming from many tens to hundreds of sources, including databases, file transfers, logs, software as a service (SaaS) applications, and more. Organizations may not always have control over what data comes through these channels and into their downstream storage and applications.

Ingestion: Data lake batch, micro-batch, and streaming

Many organizations land their source data into their data lake in various ways, including batch, micro-batch, and streaming jobs. For example, Amazon EMR, AWS Glue, and AWS Database Migration Service (AWS DMS) can all be used to perform batch and or streaming operations that sink to a data lake on Amazon Simple Storage Service (Amazon S3). Amazon AppFlow can be used to transfer data from different SaaS applications to a data lake. AWS DataSync and AWS Transfer Family can help with moving files to and from a data lake over a number of different protocols. Amazon Kinesis and Amazon MSK also have capabilities to stream data directly to a data lake on Amazon S3.

S3 data lake

Using Amazon S3 for your data lake is in line with the modern data strategy. It provides low-cost storage without sacrificing performance, reliability, or availability. With this approach, you can bring compute to your data as needed and only pay for capacity it needs to run.

In this architecture, raw data can come from a variety of sources (internal and external), which may contain sensitive data.

Using AWS Glue crawlers, we can discover and catalog the data, which will build the table schemas for us, and ultimately make it straightforward to use AWS Glue ETL with the PII transform to detect and mask or and redact any sensitive data that may have landed in the data lake.

Business context and datasets

To demonstrate the value of our approach, let’s imagine you’re part of a data engineering team for a financial services organization. Your requirements are to detect and mask sensitive data as it is ingested into your organization’s cloud environment. The data will be consumed by downstream analytical processes. In the future, your users will be able to safely search historical payment transactions based on data streams collected from internal banking systems. Search results from operation teams, customers, and interfacing applications must be masked in sensitive fields.

The following table shows the data structure used for the solution. For clarity, we have mapped raw to curated column names. You’ll notice that multiple fields within this schema are considered sensitive data, such as first name, last name, Social Security number (SSN), address, credit card number, phone number, email, and IPv4 address.

Raw Column Name Curated Column Name Type
c0 first_name string
c1 last_name string
c2 ssn string
c3 address string
c4 postcode string
c5 country string
c6 purchase_site string
c7 credit_card_number string
c8 credit_card_provider string
c9 currency string
c10 purchase_value integer
c11 transaction_date date
c12 phone_number string
c13 email string
c14 ipv4 string

Use case: PII batch detection before loading to OpenSearch Service

Customers who implement the following architecture have built their data lake on Amazon S3 to run different types of analytics at scale. This solution is suitable for customers who don’t require real-time ingestion to OpenSearch Service and plan to use data integration tools that run on a schedule or are triggered through events.

batch_architecture

Before data records land on Amazon S3, we implement an ingestion layer to bring all data streams reliably and securely to the data lake. Kinesis Data Streams is deployed as an ingestion layer for accelerated intake of structured and semi-structured data streams. Examples of these are relational database changes, applications, system logs, or clickstreams. For change data capture (CDC) use cases, you can use Kinesis Data Streams as a target for AWS DMS. Applications or systems generating streams containing sensitive data are sent to the Kinesis data stream via one of the three supported methods: the Amazon Kinesis Agent, the AWS SDK for Java, or the Kinesis Producer Library. As a last step, Amazon Kinesis Data Firehose helps us reliably load near-real-time batches of data into our S3 data lake destination.

The following screenshot shows how data flows through Kinesis Data Streams via the Data Viewer and retrieves sample data that lands on the raw S3 prefix. For this architecture, we followed the data lifecycle for S3 prefixes as recommended in Data lake foundation.

kinesis raw data

As you can see from the details of the first record in the following screenshot, the JSON payload follows the same schema as in the previous section. You can see the unredacted data flowing into the Kinesis data stream, which will be obfuscated later in subsequent stages.

raw_json

After the data is collected and ingested into Kinesis Data Streams and delivered to the S3 bucket using Kinesis Data Firehose, the processing layer of the architecture takes over. We use the AWS Glue PII transform to automate detection and masking of sensitive data in our pipeline. As shown in the following workflow diagram, we took a no-code, visual ETL approach to implement our transformation job in AWS Glue Studio.

glue studio nodes

First, we access the source Data Catalog table raw from the pii_data_db database. The table has the schema structure presented in the previous section. To keep track of the raw processed data, we used job bookmarks.

glue catalog

We use the AWS Glue DataBrew recipes in the AWS Glue Studio visual ETL job to transform two date attributes to be compatible with OpenSearch expected formats. This allows us to have a full no-code experience.

We use the Detect PII action to identify sensitive columns. We let AWS Glue determine this based on selected patterns, detection threshold, and sample portion of rows from the dataset. In our example, we used patterns that apply specifically to the United States (such as SSNs) and may not detect sensitive data from other countries. You may look for available categories and locations applicable to your use case or use regular expressions (regex) in AWS Glue to create detection entities for sensitive data from other countries.

It’s important to select the correct sampling method that AWS Glue offers. In this example, it’s known that the data coming in from the stream has sensitive data in every row, so it’s not necessary to sample 100% of the rows in the dataset. If you have a requirement where no sensitive data is allowed to downstream sources, consider sampling 100% of the data for the patterns you chose, or scan the entire dataset and act on each individual cell to ensure all sensitive data is detected. The benefit you get from sampling is reduced costs because you don’t have to scan as much data.

PII Options

The Detect PII action allows you to select a default string when masking sensitive data. In our example, we use the string **********.

selected_options

We use the apply mapping operation to rename and remove unnecessary columns such as ingestion_year, ingestion_month, and ingestion_day. This step also allows us to change the data type of one of the columns (purchase_value) from string to integer.

schema

From this point on, the job splits into two output destinations: OpenSearch Service and Amazon S3.

Our provisioned OpenSearch Service cluster is connected via the OpenSearch built-in connector for Glue. We specify the OpenSearch Index we’d like to write to and the connector handles the credentials, domain and port. In the screen shot below, we write to the specified index index_os_pii.

opensearch config

We store the masked dataset in the curated S3 prefix. There, we have data normalized to a specific use case and safe consumption by data scientists or for ad hoc reporting needs.

opensearch target s3 folder

For unified governance, access control, and audit trails of all datasets and Data Catalog tables, you can use AWS Lake Formation. This helps you restrict access to the AWS Glue Data Catalog tables and underlying data to only those users and roles who have been granted necessary permissions to do so.

After the batch job runs successfully, you can use OpenSearch Service to run search queries or reports. As shown in the following screenshot, the pipeline masked sensitive fields automatically with no code development efforts.

You can identify trends from the operational data, such as the amount of transactions per day filtered by credit card provider, as shown in the preceding screenshot. You can also determine the locations and domains where users make purchases. The transaction_date attribute helps us see these trends over time. The following screenshot shows a record with all of the transaction’s information redacted appropriately.

json masked

For alternate methods on how to load data into Amazon OpenSearch, refer to Loading streaming data into Amazon OpenSearch Service.

Furthermore, sensitive data can also be discovered and masked using other AWS solutions. For example, you could use Amazon Macie to detect sensitive data inside an S3 bucket, and then use Amazon Comprehend to redact the sensitive data that was detected. For more information, refer to Common techniques to detect PHI and PII data using AWS Services.

Conclusion

This post discussed the importance of handling sensitive data within your environment and various methods and architectures to remain compliant while also allowing your organization to scale quickly. You should now have a good understanding of how to detect, mask, or redact and load your data into Amazon OpenSearch Service.


About the authors

Michael Hamilton is a Sr Analytics Solutions Architect focusing on helping enterprise customers modernize and simplify their analytics workloads on AWS. He enjoys mountain biking and spending time with his wife and three children when not working.

Daniel Rozo is a Senior Solutions Architect with AWS supporting customers in the Netherlands. His passion is engineering simple data and analytics solutions and helping customers move to modern data architectures. Outside of work, he enjoys playing tennis and biking.

Information on the SourceHut outage

Post Syndicated from corbet original https://lwn.net/Articles/958125/

Users of SourceHut will have noticed that the site has been unreachable;
Drew DeVault has now posted a report on
what is happening
(it’s a distributed denial-of-service attack) and
what is being done to recover.

We deal with ordinary DDoS attacks in the normal course of
operations, and we are generally able to mitigate them on our
end. However, this is not an ordinary DDoS attack; the attacker
posesses considerable resources and is operating at a scale beyond
that which we have the means to mitigate ourselves. In response,
before we could do much ourselves to understand or mitigate the
problem, our upstream network provider null routed SourceHut
entirely, rendering both the internet at large, and SourceHut
staff, unable to reach our servers.

Security updates for Friday

Post Syndicated from jake original https://lwn.net/Articles/958124/

Security updates have been issued by Debian (kernel, linux-5.10, php-phpseclib, php-phpseclib3, and phpseclib), Fedora (openssh and tinyxml), Gentoo (FreeRDP and Prometheus SNMP Exporter), Mageia (packages), Red Hat (openssl), SUSE (gstreamer-plugins-rs and python-django-grappelli), and Ubuntu (dotnet6, dotnet7, dotnet8, openssh, and xerces-c).

2023 Ransomware Stats: A Look Back To Plan Ahead

Post Syndicated from Christiaan Beek original https://blog.rapid7.com/2024/01/12/2023-ransomware-stats-a-look-back-to-plan-ahead/

2023 Ransomware Stats: A Look Back To Plan Ahead

2023 Ransomware Stats: A Look Back To Plan Ahead

Last year was not a year for the faint of heart. Organizations of every size found themselves faced with ransomware attacks at varying levels of sophistication, yet every one of them was damaging. And as we step into 2024, the first victims of ransomware attacks are already being reported. What can the 2023 ransomware stats tell us about the year that was, and how can we use them to plan for the year ahead?

In this blog we will dissect the multifaceted dimensions of ransomware attacks observed in 2023, providing insights and looking a bit forward to what 2024 might bring. For our data analytics, we make use of publicly available data (like posts from the ransomware groups themselves) and 2023 ransomware incident data from our MDR team, both of which we’ve enriched with context from the data gathered in Rapid7 Labs.

The 2023 Ransomware Landscape

Most ransomware groups have leak sites where they announce victims of their campaigns. These leak sites are a tactic to put more pressure on their victims to pay the ransom; if the ransom is not paid, they will leak the compromised data via that site. The frequency of posts is a good indicator of how often and which groups are active, but the ransomware landscape is larger than that.

The number of unique ransomware families these groups utilized in 2023 decreased by more than half, from 95 new families in 2022 to 43 in 2023. This tells us that the “current” ransomware families and models are working/profitable and there’s no need to develop something brand new.

Our combined sources uncovered nearly 5200 reported ransomware cases throughout the course of 2023. In reality, we believe that number was actually higher because it doesn’t account for the many attacks that likely went unreported.

Coveware, a security consulting firm, found that the average ransom payment for Q3 2023 was $850,700 USD. That is only the amount paid for the ransom; the real costs for recovering of a ransomware incident are based on a range of factors that include:

  • Downtime
  • Damage to reputation
  • Lost business
  • Labour hours
  • Increased insurance coverage costs
  • Legal counseling and settlement fees

The same report mentioned a staggering 41% of victims opted to pay the ransom.

The below scatter plot shows the number of ransomware incidents attributed to the top 20 ransomware groups for 2023, based on leak site communications, public disclosures, and Rapid7 incident response data.

2023 Ransomware Stats: A Look Back To Plan Ahead

Zooming in on the most active groups (supported by a large ecosystem of initial access brokers), the top 5 groups we identified are:

  • Alphv aka BlackCat ransomware
  • BianLian
  • Cl0P
  • Lockbit(3)
  • Play

The below polar-bar chart visualizes these groups’ frequency of postings per month on their leak sites:

2023 Ransomware Stats: A Look Back To Plan Ahead

2023 Ransomware Attacks

Rapid7 Labs conducted an analysis of the 2023 ransomware attacks using data sourced from both external and internal reports. We compared the modus operandi of these attacks and mapped them out against the MITRE ATT&CK model. The results are visualized in the following diagram:

2023 Ransomware Stats: A Look Back To Plan Ahead

This diagram effectively encapsulates the common patterns and methodologies observed in the majority of ransomware attacks. It serves as a visual representation, outlining the sequence of steps typically followed by attackers from initial breach to final ransom demand. In our statistics, exploiting a public facing application and having a valid account are the top initial attack vectors we observed in ransomware-focused attacks in 2023.

Ransomware Groups That Came and Went

In 2023, several ransomware groups ceased their operations or underwent significant transformations. Hive ransomware marked the year’s start with its disruption in January. BlackByte, after briefly reappearing with a new white logo, went offline for the last two months of 2023.

Royal ransomware rebranded itself as Black Suit, as evidenced by the matching binaries.They took down their victim portal and started posting more on their Black Suit leak site.

Vice Society, another group, became inactive for over three months, taking down their main and backup leak sites.

NoEscape, previously known as Avaddon, executed an exit scam, further indicating the volatile and shifting landscape of ransomware groups in 2023. An “exit scam” is a fraudulent scheme where a business or individual collects funds or assets from customers or investors and then suddenly ceases operations, disappearing with the collected funds.

Who To Watch For in 2024

We anticipate that the top 5 groups mentioned will still be active in 2024; however, during the course of 2023, new groups surfaced that are interesting to watch. In random order: Cactus, Rhysida, 8base, Hunters International, Akira, and the recently surfaced Werewolves group are those to keep an eye out for.

On IoT Devices and Software Liability

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2024/01/on-iot-devices-and-software-liability.html

New law journal article:

Smart Device Manufacturer Liability and Redress for Third-Party Cyberattack Victims

Abstract: Smart devices are used to facilitate cyberattacks against both their users and third parties. While users are generally able to seek redress following a cyberattack via data protection legislation, there is no equivalent pathway available to third-party victims who suffer harm at the hands of a cyberattacker. Given how these cyberattacks are usually conducted by exploiting a publicly known and yet un-remediated bug in the smart device’s code, this lacuna is unreasonable. This paper scrutinises recent judgments from both the Supreme Court of the United Kingdom and the Supreme Court of the Republic of Ireland to ascertain whether these rulings pave the way for third-party victims to pursue negligence claims against the manufacturers of smart devices. From this analysis, a narrow pathway, which outlines how given a limited set of circumstances, a duty of care can be established between the third-party victim and the manufacturer of the smart device is proposed.

Каузата на кучето. Архитектурната критика днес

Post Syndicated from Анета Василева original https://www.toest.bg/kauzata-na-kucheto-arhitekturnata-kritika-dnes/

Каузата на кучето. Архитектурната критика днес

Твърди се, че в България архитектурна критика няма. Или пък – че състоянието на съвременната българска архитектура е такова точно защото няма силна архитектурна критика. И винаги нещата се представят по фатално-трагичен начин. 

 Жизнената среда не е такава, каквато трябва да бъде,

пише вероятно най-активният български критик през последните десетилетия арх. Павел Попов в статията си „Каузата на кучето“, публикувана във втория януарски брой на вестник „Култура“ през 1999 г., точно преди 25 години.

Как и защо българските архитекти точно както футболистите преуспяват на гурбет или в емиграция, а на местна почва хич ги няма – до такава степен, че никоя местна сграда не попада в полезрението на света,

продължава той. Поводът за статията е среща, която секция „Теория и критика“ на Съюза на архитектите в България (САБ) организирала по Коледа с представители на радиото, телевизията и вестниците, публикуващи материали за архитектура. Съответно от критиците и теоретиците от САБ дошли всички, но от медиите – почти никой. 

Мрачният рефрен „Няма критика, няма медии, средата е зле“ кънти и през следващите години.

Общоизвестно е, че в България архитектурна критика няма и не може да има,

пише през 2007 г. несъществуващият вече онлайн строителен портал Stroitelstvo.info

Че няма архитектурна критика у нас – това е ясно. Журналистите, които пишат за архитектура, са гола вода и гъзолижат, без да им мигне окото. Обаче ме тревожи изключително много, МНОГО, казвам ви МНОГО, че липсва критичност у колегите архитекти,

коментира през 2009 г. читател с псевдонима „Плужека се възмущава“ под статията SAW по време на свински грип“ на Николай Ангелов в блога на WhATA. Самият автор на статията прави бърз и всъщност пълен архитектурнокритически коментар на второто издание на фестивала Sofia Architecture Week, който формира алтернативната българска архитектурна сцена между първия си форум през 2008 г. в София и последното си издание през 2016 г. в Пловдив. 

Интересното е, че ситуацията се оказва напълно идентична и извън България. 

През 2010 г. финландският архитект и архитектурен редактор Еса Лаксонен пише необичайно емоционална статия за „липсата на архитектурна критика във Финландия“ в независимия холандски академичен журнал OASE. Той нарича това „синдром на малката страна“. „Във Финландия компетентните архитектурни критици се броят на пръстите на ръката“, оплаква се Лаксонен.

А архитектите никак не искат да пишат статии за работата на своите колеги – смята се за неетично. Професионалните кръгове във Финландия са много малки и всяко мнение предизвиква извънмерни реакции. Никой не иска да се въвлича в това. 

Оказва се, че във Финландия този дебат тече от над 30 години. Всички страдат, че критиката е малко, лошо написана – и търсят виновни. Дали ще са големите национални вестници, които изобщо не искат да се занимават с архитектура, камо ли с критика за нея, дали ще са професионалните списания, които нямат никакво влияние върху архитектурната и строителната култура, дали ще е липсата на пари. 

Явно обаче синдромът не е само на малката страна. Франция например никак не е малка, но ситуацията според дългогодишната френска критичка и преподавателка Франсоаз Фромоно изглежда също толкова отчайваща.

В тази страна няма алтернатива на луксозните илюстровани списания, когато стане дума за архитектура и урбанизъм. Много трудно ще се намери някой професионален журнал, в който да има внимателно написана статия за малка неизвестна сграда, откровен обзор на политическите игри зад скорошен архитектурен конкурс, рецензия на наскоро излязла книга или приличен независим анализ на поредното постижение на някой стархитект. 

Фромоно е съвсем откровена. Във Франция архитектурната секция в ежедневниците е сведена до минимум, а по-интелектуалните и културно насочени издания смятат архитектурата за прекалено специализирана, техничарска и безинтересна за техните читатели.

Причините за проблемите са много – променената медийна среда, комерсиалните пресгрупи, които доминират, финансовите проблеми на професионалните списания, свели разходите си до минимум, поддържани обикновено от само един щатен редактор, който наема автори на хонорар. Повечето от тях пък не искат или не могат да си позволят да губят време в проучване заради ниските хонорари. Те използват основно подадените пресматериали от пиар пакета на съответната сграда и разчитат на безплатните рекламни пътувания до обекта, организирани от архитектите и техните клиенти. След това на никого не му се рискува да обиди домакините с критичен коментар, защото така поканите ще секнат, а достъпът до информация и чертежи ще стане съвсем труден. Още повече когато критиците са млади и искат да правят и професионална кариера като проектанти или да се развиват академично в някой архитектурен университет – негативната критика им гарантира проблеми. 

Звучи съвсем обезкуражаващо. А годината отново е 2010-та.

На 5 февруари 2015 г. Харвардският магистърски факултет по дизайн (Harvard Graduate School of Design) организира кръгла маса на тема как да се пише за архитектура в епохата на интернет, бърза информация и репортажна архитектурна критика. Професорът по архитектурна теория Майкъл Хейз кани извадка от най-популярните тогава, при това много различни по възраст и подход архитектурни критици от англосаксонския свят – Кристофър Хоторн, архитектурен критик на „Лос Анджелис Таймс“, Майкъл Соркин, легендарния нюйоркски критик, активист и биткаджия, Оливър Уейнрайт, архитектурен критик на британския „Гардиън“. 

Уейнрайт е най-младият от поканените, но пък пише в най-четената и глобално достъпна англоезична медия (в немалка степен и защото британският ежедневник „Гардиън“ продължава да поддържа напълно безплатно онлайн съдържание и достъп до своя архив).

Много съм поласкан, че съм поканен отново (случва ми се вече за шести път през последните две години) да говоря за т.нар. криза на архитектурната критика. И всеки път, когато получа подобна покана, леко паникьосано започвам да се чудя да не би да си върша работата зле,

започва изказването си той. 

Всъщност Уейнрайт показва по забавен начин как идеята, че архитектурна критика няма или пък че тя не работи добре, е глобален феномен, който се повтаря постоянно, когато и да погледнеш назад в архитектурната история. Изглежда, че архитектите не са спокойни, освен ако няма „криза на архитектурната критика“, полушеговито продължава експозето си Уейнрайт в Харвард. 

Оливър Уейнрайт има теза по въпроса:

Чудя се обаче дали т.нар. криза на критиката не е криза на самата архитектура. Архитектурата и целият архитектурен процес в момента са толкова фрагментирани, че ние, архитектите, усещаме как губим авторитет и ставаме параноични, бранейки собственото си поле. Във Великобритания често се обсъждат т.нар. design and build договори [аналог на регламентирания в българския Закон за обществените поръчки „инженеринг“ – б.а.], които оставят архитектите на дъното на хранителната верига вместо на върха ѝ. Ясно е, че архитектите вече не са „архимайсторите“. И е много лесно да обвиним за това критиците.

Уейнрайт е прав. Както са прави Лаксонен и Фромоно, че и Павел Попов в далечната 1999 година. Още по-притеснителното е, че изводите им са напълно валидни и днес, включително за ситуацията в България. Фактът, че изданията, в които се пише професионално, редовно и независимо за архитектура, са пренебрежимо малко, е силно притеснителен. А състоянието на архитектурната критика е много тясно, почти незабележимо, но напълно показателно отражение на състоянието на медиите в страната ни днес.