This article is contributed. See the original author and article here.
CISA, the Federal Bureau of Investigation (FBI), U.S. Cyber Command Cyber National Mission Force (CNMF), the United Kingdom’s National Cyber Security Centre (NCSC-UK), and the National Security Agency (NSA) have issued a joint Cybersecurity Advisory (CSA) detailing malicious cyber operations by Iranian government-sponsored advanced persistent threat (APT) actors known as MuddyWater.
MuddyWater is conducting cyber espionage and other malicious cyber operations as part of Iran’s Ministry of Intelligence and Security (MOIS), targeting a range of government and private-sector organizations across sectors—including telecommunications, defense, local government, and oil and natural gas—in Asia, Africa, Europe, and North America.
Note: this advisory uses the MITRE Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK®) framework, version 10. See the ATT&CK for Enterprise for all referenced threat actor tactics and techniques.
The Federal Bureau of Investigation (FBI), the Cybersecurity and Infrastructure Security Agency (CISA), the U.S. Cyber Command Cyber National Mission Force (CNMF), and the United Kingdom’s National Cyber Security Centre (NCSC-UK) have observed a group of Iranian government-sponsored advanced persistent threat (APT) actors, known as MuddyWater, conducting cyber espionage and other malicious cyber operations targeting a range of government and private-sector organizations across sectors—including telecommunications, defense, local government, and oil and natural gas—in Asia, Africa, Europe, and North America. Note: MuddyWater is also known as Earth Vetala, MERCURY, Static Kitten, Seedworm, and TEMP.Zagros.
MuddyWater is a subordinate element within the Iranian Ministry of Intelligence and Security (MOIS).[1] This APT group has conducted broad cyber campaigns in support of MOIS objectives since approximately 2018. MuddyWater actors are positioned both to provide stolen data and accesses to the Iranian government and to share these with other malicious cyber actors.
MuddyWater actors are known to exploit publicly reported vulnerabilities and use open-source tools and strategies to gain access to sensitive data on victims’ systems and deploy ransomware. These actors also maintain persistence on victim networks via tactics such as side-loading dynamic link libraries (DLLs)—to trick legitimate programs into running malware—and obfuscating PowerShell scripts to hide command and control (C2) functions. FBI, CISA, CNMF, and NCSC-UK have observed MuddyWater actors recently using various malware—variants of PowGoop, Small Sieve, Canopy (also known as Starwhale), Mori, and POWERSTATS—along with other tools as part of their malicious activity.
This advisory provides observed tactics, techniques, and procedures (TTPs); malware; and indicators of compromise (IOCs) associated with this Iranian government-sponsored APT activity to aid organizations in the identification of malicious activity against sensitive networks.
FBI, CISA, CNMF, NCSC-UK, and the National Security Agency (NSA) recommend organizations apply the mitigations in this advisory and review the following resources for additional information. Note: also see the Additional Resources section.
FBI, CISA, CNMF, and NCSC-UK have observed the Iranian government-sponsored MuddyWater APT group employing spearphishing, exploiting publicly known vulnerabilities, and leveraging multiple open-source tools to gain access to sensitive government and commercial networks.
As part of its spearphishing campaign, MuddyWater attempts to coax their targeted victim into downloading ZIP files, containing either an Excel file with a malicious macro that communicates with the actor’s C2 server or a PDF file that drops a malicious file to the victim’s network [T1566.001, T1204.002]. MuddyWater actors also use techniques such as side-loading DLLs [T1574.002] to trick legitimate programs into running malware and obfuscating PowerShell scripts [T1059.001] to hide C2 functions [T1027] (see the PowGoop section for more information).
Additionally, the group uses multiple malware sets—including PowGoop, Small Sieve, Canopy/Starwhale, Mori, and POWERSTATS—for loading malware, backdoor access, persistence [TA0003], and exfiltration [TA0010]. See below for descriptions of some of these malware sets, including newer tools or variants to the group’s suite. Additionally, see Malware Analysis Report MAR-10369127.r1.v1: MuddyWater for further details.
PowGoop
MuddyWater actors use new variants of PowGoop malware as their main loader in malicious operations; it consists of a DLL loader and a PowerShell-based downloader. The malicious file impersonates a legitimate file that is signed as a Google Update executable file.
According to samples of PowGoop analyzed by CISA and CNMF, PowGoop consists of three components:
A DLL file renamed as a legitimate filename, Goopdate.dll, to enable the DLL side-loading technique [T1574.002]. The DLL file is contained within an executable, GoogleUpdate.exe.
A PowerShell script, obfuscated as a .dat file, goopdate.dat, used to decrypt and run a second obfuscated PowerShell script, config.txt [T1059.001].
config.txt, an encoded, obfuscated PowerShell script containing a beacon to a hardcoded IP address.
These components retrieve encrypted commands from a C2 server. The DLL file hides communications with MuddyWater C2 servers by executing with the Google Update service.
Small Sieve
According to a sample analyzed by NCSC-UK, Small Sieve is a simple Python [T1059.006] backdoor distributed using a Nullsoft Scriptable Install System (NSIS) installer, gram_app.exe. The NSIS installs the Python backdoor, index.exe, and adds it as a registry run key [T1547.001], enabling persistence [TA0003].
MuddyWater disguises malicious executables and uses filenames and Registry key names associated with Microsoft’s Windows Defender to avoid detection during casual inspection. The APT group has also used variations of Microsoft (e.g., “Microsift”) and Outlook in its filenames associated with Small Sieve [T1036.005].
Small Sieve provides basic functionality required to maintain and expand a foothold in victim infrastructure and avoid detection [TA0005] by using custom string and traffic obfuscation schemes together with the Telegram Bot application programming interface (API). Specifically, Small Sieve’s beacons and taskings are performed using Telegram API over Hypertext Transfer Protocol Secure (HTTPS) [T1071.001], and the tasking and beaconing data is obfuscated through a hex byte swapping encoding scheme combined with an obfuscated Base64 function [T1027], T1132.002].
Note: cybersecurity agencies in the United Kingdom and the United States attribute Small Sieve to MuddyWater with high confidence.
See Appendix B for further analysis of Small Sieve malware.
Canopy
MuddyWater also uses Canopy/Starwhale malware, likely distributed via spearphishing emails with targeted attachments [T1566.001]. According to two Canopy/Starwhale samples analyzed by CISA, Canopy uses Windows Script File (.wsf) scripts distributed by a malicious Excel file. Note: the cybersecurity agencies of the United Kingdom and the United States attribute these malware samples to MuddyWater with high confidence.
In the samples CISA analyzed, a malicious Excel file, Cooperation terms.xls, contained macros written in Visual Basic for Applications (VBA) and two encoded Windows Script Files. When the victim opens the Excel file, they receive a prompt to enable macros [T1204.002]. Once this occurs, the macros are executed, decoding and installing the two embedded Windows Script Files.
The first .wsf is installed in the current user startup folder [T1547.001] for persistence. The file contains hexadecimal (hex)-encoded strings that have been reshuffled [T1027]. The file executes a command to run the second .wsf.
The second .wsf also contains hex-encoded strings that have been reshuffled. This file collects [TA0035] the victim system’s IP address, computer name, and username [T1005]. The collected data is then hex-encoded and sent to an adversary-controlled IP address, http[:]88.119.170[.]124, via an HTTP POST request [T1041].
Mori
MuddyWater also uses the Mori backdoor that uses Domain Name System tunneling to communicate with the group’s C2 infrastructure [T1572].
According to one sample analyzed by CISA, FML.dll, Mori uses a DLL written in C++ that is executed with regsvr32.exe with export DllRegisterServer; this DLL appears to be a component to another program. FML.dll contains approximately 200MB of junk data [T1001.001] in a resource directory 205, number 105. Upon execution, FML.dll creates a mutex, 0x50504060, and performs the following tasks:
Deletes the file FILENAME.old and deletes file by registry value. The filename is the DLL file with a .old extension.
Resolves networking APIs from strings that are ADD-encrypted with the key 0x05.
Uses Base64 and Java Script Object Notation (JSON) based on certain key values passed to the JSON library functions. It appears likely that JSON is used to serialize C2 commands and/or their results.
Communicates using HTTP over either IPv4 or IPv6, depending on the value of an unidentified flag, for C2 [T1071.001].
Reads and/or writes data from the following Registry Keys, HKLMSoftwareNFCIPA and HKLMSoftwareNFC(Default).
POWERSTATS
This group is also known to use the POWERSTATS backdoor, which runs PowerShell scripts to maintain persistent access to the victim systems [T1059.001].
CNMF has posted samples further detailing the different parts of MuddyWater’s new suite of tools— along with JavaScript files used to establish connections back to malicious infrastructure—to the malware aggregation tool and repository, Virus Total. Network operators who identify multiple instances of the tools on the same network should investigate further as this may indicate the presence of an Iranian malicious cyber actor.
The following script is an example of a survey script used by MuddyWater to enumerate information about victim computers. It queries the Windows Management Instrumentation (WMI) service to obtain information about the compromised machine to generate a string, with these fields separated by a delimiter (e.g., ;; in this sample). The produced string is usually encoded by the MuddyWater implant and sent to an adversary-controlled IP address.
The newly identified PowerShell backdoor used by MuddyWater below uses a single-byte Exclusive-OR (XOR) to encrypt communications with the key 0x02 to adversary-controlled infrastructure. The script is lightweight in functionality and uses the InvokeScript method to execute responses received from the adversary.
MuddyWater has used Daniel Bohannon’s Invoke-Obfuscation framework and obfuscated PowerShell scripts. The group has also used other obfuscation methods, including Base64 obfuscation of VBScripts and PowerShell commands.
MuddyWater has disguised malicious executables and used filenames and Registry key names associated with Windows Defender. E.g., Small Sieve uses variations of Microsoft (Microsift) and Outlook in its filenames to attempt to avoid detection during casual inspection.
MuddyWater has used C2 infrastructure to receive exfiltrated data.
Mitigations
Protective Controls and Architecture
Deploy application control software to limit the applications and executable code that can be run by users. Email attachments and files downloaded via links in emails often contain executable code.
Identity and Access Management
Use multifactor authentication where possible, particularly for webmail, virtual private networks, and accounts that access critical systems.
Limit the use of administrator privileges. Users who browse the internet, use email, and execute code with administrator privileges make for excellent spearphishing targets because their system—once infected—enables attackers to move laterally across the network, gain additional accesses, and access highly sensitive information.
Phishing Protection
Enable antivirus and anti-malware software and update signature definitions in a timely manner. Well-maintained antivirus software may prevent use of commonly deployed attacker tools that are delivered via spearphishing.
Be suspicious of unsolicited contact via email or social media from any individual you do not know personally. Do not click on hyperlinks or open attachments in these communications.
Consider adding an email banner to emails received from outside your organization and disabling hyperlinks in received emails.
Train users through awareness and simulations to recognize and report phishing and social engineering attempts. Identify and suspend access of user accounts exhibiting unusual activity.
Adopt threat reputation services at the network device, operating system, application, and email service levels. Reputation services can be used to detect or prevent low-reputation email addresses, files, URLs, and IP addresses used in spearphishing attacks.
Vulnerability and Configuration Management
Install updates/patch operating systems, software, and firmware as soon as updates/patches are released. Prioritize patching known exploited vulnerabilities.
For information and resources on protecting against and responding to ransomware, refer to StopRansomware.gov, a centralized, whole-of-government webpage providing ransomware resources and alerts.
The joint advisory from the cybersecurity authorities of Australia, Canada, New Zealand, the United Kingdom, and the United States: Technical Approaches to Uncovering and Remediating Malicious Activity provides additional guidance when hunting or investigating a network and common mistakes to avoid in incident handling.
CISA offers a range of no-cost cyber hygiene services to help critical infrastructure organizations assess, identify, and reduce their exposure to threats, including ransomware. By requesting these services, organizations of any size could find ways to reduce their risk and mitigate attack vectors.
The U.S. Department of State’s Rewards for Justice (RFJ) program offers a reward of up to $10 million for reports of foreign government malicious activity against U.S. critical infrastructure. See the RFJ website for more information and how to report information securely.
The information you have accessed or received is being provided “as is” for informational purposes only. The FBI, CISA, CNMF, and NSA do not endorse any commercial product or service, including any subjects of analysis. Any reference to specific commercial products, processes, or services by service mark, trademark, manufacturer, or otherwise, does not constitute or imply their endorsement, recommendation, or favoring by the FBI, CISA, CNMF, or NSA.
Purpose
This document was developed by the FBI, CISA, CNMF, NCSC-UK, and NSA in furtherance of their respective cybersecurity missions, including their responsibilities to develop and issue cybersecurity specifications and mitigations. This information may be shared broadly to reach all appropriate stakeholders. The United States’ NSA agrees with this attribution and the details provided in this report.
Appendix A: IOCs
The following IP addresses are associated with MuddyWater activity:
Small Sieve is distributed as a large (16MB) NSIS installer named gram_app.exe, which does not appear to masquerade as a legitimate application. Once executed, the backdoor binary index.exe is installed in the user’s AppData/Roaming directory and is added as a Run key in the registry to enabled persistence after reboot.
The installer then executes the backdoor with the “Platypus” argument [T1480], which is also present in the registry persistence key: HKCUSoftwareMicrosoftWindowsCurrentVersionRunOutlookMicrosift.
Configuration
The backdoor attempts to restore previously initialized session data from %LocalAppData%MicrosoftWindowsOutlookDataPlus.txt.
If this file does not exist, then it uses the hardcoded values listed in table 4:
Table 4: Credentials and Session Values
Field
Value
Description
Chat ID
2090761833
This is the Telegram Channel ID that beacons are sent to, and, from which, tasking requests are received. Tasking requests are dropped if they do not come from this channel. This value cannot be changed.
Bot ID
Random value between 10,000,000 and 90,000,000
This is a bot identifier generated at startup that is sent to the C2 in the initial beacon. Commands must be prefixed with /com[Bot ID] in order to be processed by the malware.
Telegram Token
2003026094: AAGoitvpcx3SFZ2_6YzIs4La_kyDF1PbXrY
This is the initial token used to authenticate each message to the Telegram Bot API.
Tasking
Small Sieve beacons via the Telegram Bot API, sending the configured Bot ID, the currently logged-in user, and the host’s IP address, as described in the Communications (Beacon format) section below. It then waits for tasking as a Telegram bot using the python-telegram-bot module.
Two task formats are supported:
/start – no argument is passed; this causes the beacon information to be repeated.
/com[BotID] [command] – for issuing commands passed in the argument.
The following commands are supported by the second of these formats, as described in table 5:
Table 5: Supported Commands
Command
Description
delete
This command causes the backdoor to exit; it does not remove persistence.
download url””filename
The URL will be fetched and saved to the provided filename using the Python urllib module urlretrieve function.
change token””newtoken
The backdoor will reconnect to the Telegram Bot API using the provided token newtoken. This updated token will be stored in the encoded MicrosoftWindowsOutlookDataPlus.txt file.
disconnect
The original connection to Telegram is terminated. It is likely used after a change token command is issued.
Any commands other than those detailed in table 5 are executed directly by passing them to cmd.exe /c, and the output is returned as a reply.
Defense Evasion
Anti-Sandbox
Figure 1: Execution Guardrail
Threat actors may be attempting to thwart simple analysis by not passing “Platypus” on the command line.
String obfuscation
Internal strings and new Telegram tokens are stored obfuscated with a custom alphabet and Base64-encoded. A decryption script is included in Appendix B.
Communications
Beacon Format
Before listening for tasking using CommandHandler objects from the python-telegram-bot module, a beacon is generated manually using the standard requests library:
Figure 2: Manually Generated Beacon
The hex host data is encoded using the byte shuffling algorithm as described in the “Communications (Traffic obfuscation)” section of this report. The example in figure 2 decodes to:
admin/WINDOMAIN1 | 10.17.32.18
Traffic obfuscation
Although traffic to the Telegram Bot API is protected by TLS, Small Sieve obfuscates its tasking and response using a hex byte shuffling algorithm. A Python3 implementation is shown in figure 3.
Figure 3: Traffic Encoding Scheme Based on Hex Conversion and Shuffling
Detection
Table 6 outlines indicators of compromise.
Table 6: Indicators of Compromise
Type
Description
Values
Path
Telegram Session Persistence File (Obfuscated)
%LocalAppData%MicrosoftWindowsOutlookDataPlus.txt
Path
Installation path of the Small Sieve binary
%AppData%OutlookMicrosiftindex.exe
Registry value name
Persistence Registry Key pointing to index.exe with a “Platypus” argument
To report suspicious or criminal activity related to information found in this joint Cybersecurity Advisory, contact your local FBI field office at www.fbi.gov/contact-us/field-offices, or the FBI’s 24/7 Cyber Watch (CyWatch) at (855) 292-3937 or by email at CyWatch@fbi.gov. When available, please include the following information regarding the incident: date, time, and location of the incident; type of activity; number of people affected; type of equipment used for the activity; the name of the submitting company or organization; and a designated point of contact. To request incident response resources or technical assistance related to these threats, contact CISA at CISAServiceDesk@cisa.dhs.gov. For NSA client requirements or general cybersecurity inquiries, contact the Cybersecurity Requirements Center at Cybersecurity_Requests@nsa.gov. United Kingdom organizations should report a significant cyber security incident: ncsc.gov.uk/report-an-incident (monitored 24 hours) or for urgent assistance call 03000 200 973.
This article is contributed. See the original author and article here.
With briefcases and suitcases in tow, business-to-business (B2B) sellers have always traveled the distance to meet buyers wherever they are. Buyers are going digital in a big way, so sellers can put away their bags (at least part of the time) and step into digital or hybrid selling. This dramatic shift in B2B buyingmore digital, more self-servicehas led to a steady decrease in the amount of time buyers spend with sellers. To adapt to this new omnichannel reality, sales teams are reinventing their go-to-market strategies.
B2B selling has truly changed much faster and more dramatically than anyone could have imagined. Buyers now use routinely use up to 10 different channelsup from just five in 2016.1 A “rule of thirds” has emerged: buyers employ a roughly even mix of remote (e.g. videoconferencing and phone conversations), self-service (e.g. e-commerce and digital portals), and traditional sales (e.g. in-person meetings, trade-shows, conferences) at each stage of the sales process.1 The rule of thirds is universal. It describes responses from B2B decision makers across all major industries, at all company sizes, in every country.
Although digital interactions, both remote and self-serve, are here to stay, in-person selling still plays an important role. Buyers aren’t ready to give up face-to-face visits entirely. Buyers view in-person interactions as a sign of how much a supplier values a relationship and can play an especially pivotal part in establishing or re-establishing a relationship. Today’s B2B organizations require a new set of digital-first solutions to navigate the complex and unfamiliar terrain. Microsoft Dynamics 365 Customer Insights can help.
Omnichannel presents new challenges
Increased opportunities to engage involve increased complexity. First, data ends up scattered across many different systems like customer relationship management (CRM), partner relationship management (PRM), e-commerce, web analytics, trials and demos, online chat, mobile, email, event management, and social networking. Assembling those pieces into a complete picture of a buyer or account is a complicated task that few B2B organizations and their existing systems can handle. Second, customer experiences are becoming increasingly fragmented as organizations struggle to maintain consistency from one touchpoint to the next. This issue is particularly acute for sellers when they don’t have critical context like previous interactions conducted on other channels such as content viewed, product trials initiated, online transactions, and product issues. Giving sellers visibility to the data is a start, but that would still require sellers to digest huge amounts of data to make sense of it all, hampering swift action.
But there are new possibilities
To deliver seamless omnichannel experiences, B2B organizations need a customer data platform (CDP) like Dynamics 365 Customer Insights that’s designed to maintain a persistent and unified view of the buyer across channels. The enterprise-grade CDP creates an adaptive profile of each buyer and account, so organizations can rapidly orchestrate cohesive experiences throughout the journey. Leading B2B organizations rely on unified data as a single source of truth as well as to unlock actionable insights that increase sales alignment and conversion, including account targeting, opportunity scoring, recommended products, dynamic pricing, and churn prevention. For example, sales teams can proactively prioritize accounts based on predictive scoring that takes into account firmographics and all past transactional data as well as behavioral insights like trial usage across all contacts at the account. Or a seller knows it’s the right time to engage since a buyer has just signaled high intent through website activities like viewing multiple pieces of content. Insights like these widen the gap between omnichannel sales leaders and the rest of the field.
The profiles and resulting analytics from Dynamics 365 Customer Insights can be leveraged across every function and systemsincluding sales force automation (SFA), account-based management (ABM), and e-commerce platforms, so that every person and system that the buyer engages with has the context to provide proactive and personalized experiences at precisely the right moment. This flexible design enables sales organizations to stay agile and future-proof their data foundation even when new sales tools are inevitably added to the mix.
Importantly, sales organizations can ensure that consent is core to every engagement. Privacy and compliance are crucial when it comes to customer data. In this new privacy-first world, consent funnels are as important as purchase funnels. It’s no longer only about collecting and unifying data. When companies build targeted and personalized experiences, customer consent must be infused across all workflows that use customer data. Dynamics 365 Customer Insights is designed from the ground up to be consent-enabled, allowing sales organizations to automatically honor customer consent and privacy, and build trust, across the entire journey.
A next-gen customer data platform can help
The next normal for B2B sales is here, and there’s no looking back. The buyer’s move to omnichannel isn’t as simple as shifting all transactions online. Omnichannel with e-commerce, videoconference, and face-to-face are all a necessary part of the buyer’s journey. What B2B buyers want is nuanced, and so are their views about the most effective way to engage. B2B organizations must continue to adapt to meet this new omnichannel reality. To learn how a CDP can help delight your customers while helping your sales team navigate omnichannel selling to lower the cost of selling, extend reach, and improve sales effectiveness, visit Dynamics 365 Customer Insights.
This article was originally posted by the FTC. See the original article here.
If you went to DeVry, you might have already gotten money back from the FTC. That’s thanks to a 2016 FTC settlement with the school over allegations that it didn’t tell the truth about how likely it was that its grads could get jobs in their field, or how much they’d earn compared to grads from other colleges. But now, you might be eligible to get your DeVry federal student loan debt discharged, thanks to recent actions taken by the Department of Education.
In 2017 and 2019, the FTC sent nearly $50 million in refunds to about 173,000 students that DeVry deceived — and, thanks to the case, DeVry also forgave $50.6 million that students owed to DeVry. But that’s not the end of the story. Just last week, the Department of Education announced that it has discharged the federal student loan debt of about 1,800 former DeVry students who were deceived by DeVry’s job claims. But those are just the people who’ve already submitted a claim to the Department of Education (ED) so far, through an application process called “borrower defense to repayment.” If you already submitted a claim to get your DeVry federal loans discharged, check your status under “Manage My Applications” on ED’s borrower defense page.
That’s still not the end of the story. If you’re a DeVry student who believed the school’s job claims, and your decision to go to DeVry was influenced by them, you can still apply to have your federal loans forgiven. You’ll need your FSA ID to get started at ED’s borrower defense page. Fill out the form, tell your story, and explain how those job placement claims affected your decision. Then submit.
But wait, there’s still more to the story! If you already got a refund from the FTC’s DeVry settlement fund, you can still apply for federal loan discharge from ED. In fact, be sure to mention it when you fill out your claim form.
We are excited to announce a new suite of features entering into public preview for Microsoft Sentinel. This suite of features will contain:
Basic ingestion tier: new pricing tier for Azure Log Analytics that allows for logs to be ingested at a lower cost. This data is only retained in the workspace for 8 days total.
Archive tier: Azure Log Analytics has expanded its retention capability from 2 years to 7 years. With that, this new tier for data will allow for the data to be retained up to 7 years in a low-cost archived state.
Search jobs: search tasks that run limited KQL in order to find and return all relevant logs to what is searched. These jobs search data across the analytics tier, basic tier. and archived data.
Data restoration: new feature that allows users to pick a data table and a time range in order to restore data to the workspace via restore table.
Basic Ingestion Tier:
The basic log ingestion tier will allow users to pick and choose which data tables should be enrolled in the tier and ingest data for less cost. This tier is meant for data sources that are high in volume, low in priority, and are required for ingestion. Rather than pay full price for these logs, they can be configured for basic ingestion pricing and move to archive after the 8 days. As mentioned above, the data ingested will only be retained in the workspace for 8 days and will support basic KQL queries. The following will be supported at launch:
where
extend
project – including all its variants (project-away, project-rename, etc.)
parse and parse-where
Note: this data will not be available for analytic rules or log alerts.
During public preview, basic logs will support the following log types:
The archive tier will allow users to configure individual tables to be retained for up to 7 years. This introduces a few new retention policies to keep track of:
retentionInDays: the number of days that data is kept within the Microsoft Sentinel workspace.
totalRetentionInDays: the total number of days that data should be retained within Azure Log Analytics.
archiveRetention: the number of days that the data should be kept in archive. This is set by taking the totalRetentionInDays and subtracting the workspace retention.
Data tables that are configured for archival will automatically roll over into the archive tier after they expire from the workspace. Additionally, if data is configured for archival and the workspace retention (say 180 days) is lowered (say 90 days), the data between the original and new retention settings will automatically be rolled over into archive in order to avoid data loss.
Configuring Basic and Archive Tiers:
In order to configure tables to be in the basic ingestion tier, the table must be supported and configured for custom logs version 2. For steps to configure this, please follow this document. Archive does not require this but it is still recommended.
Currently there are 3 ways to configure tables for basic and archive:
REST API call
PowerShell script
Microsoft Sentinel workbook (uses the API calls)
REST API
The API supports GET, PUT and PATCH methods. It is recommended to use PUT when configuring a table for the first time. PATCH can be used after that. The URI for the call is:
Note: null is used when telling the API to not change the current retention setting on the workspace.
PowerShell
A PowerShell script was developed to allow users to monitor and configure multiple tables at once for both basic ingestion and archive. The scripts can be found here and here.
To configure tables with the script, a user just needs to:
Run the script.
Authenticate to Azure.
Select the subscription/workspace that Microsoft Sentinel resides in.
Select one or more tables to configure for basic or archive.
Enter the desired change.
Workbook
A workbook has been created that can be deployed to a Microsoft Sentinel environment. This workbook allows for users to view current configurations and configure individual tables for basic ingestion and archive. The workbook uses the same REST API calls as listed above but does not require authentication tokens as it will use the permissions of the current user. The user must have write permissions on the Microsoft Sentinel workspace.
To configure tables with the workbook, a user needs to:
Go to the Microsoft Sentinel GitHub Repo to fetch the JSON for the workbook.
Click ‘raw’ and copy the JSON.
Go to Microsoft Sentinel in the Azure portal.
Go to Workbooks.
Click ‘add workbook’.
Clicl ‘edit’.
Click ‘advanced editor’.
Paste the copied JSON.
Click save and name the workbook.
Choose which tab to operate in (Archive or Basic)
Click on a table that should be configured.
Review the current configuration.
Set the changes to be made in the JSON body.
Click run update.
The workbook will run the API call and will provide a message if it was successful or not. The changes made can be seen after refreshing the workbook.
Search jobs allow users to specify a data table, a time period, and a key item to search for the in the data. As of now, Search jobs use simple KQL, which will support more complex KQL over time. In terms of what separates Search jobs from regular queries, as of today a standard query using KQL will return a maximum of 30,000 results and will time out at 10 minutes of running. For users with large amounts of data, this can be an issue. This is where search jobs come into play. Search jobs run independently from usual queries, allowing them to return up to 1,000,000 results and up to 24 hours. When a Search job is completed, the results found are placed in a temporary table. This allows users to go back to reference the data without losing it and being able to transform the data as needed.
Search jobs will run on data that is within the analytics tier, basic tier, and also archive. This makes it a great option for bringing up historical data in a pinch when needed. An example of this would be in the event of a widespread compromise that has been found that stems back over 3 months. With Search, users are able to run a query on any IoC found in the compromise in order to see if they have been hit. Another example would be if a machine is compromised and is a common player in several raised incidents. Search will allow users to bring up historical data from the past int the event that the attack initially took place outside of the workspace’s retention.
When results are brought in, the table name will be structured as so:
Table searched
Number ID
SRCH suffix
Example: SecurityEvents_12345_SRCH
Data Restoration:
Similar to Search, data restoration allows users to pick a table and a time period in order to move data out of archive and back into the analytics tier for a period of time. This allows users to retrieve a bulk of data instead of just results for a single item. This can be useful during an investigation where a compromise took place months ago that contains multiple entities and a user would like to bring relevant events from the incident time back for the investigation. The user would be able to check all involved entities by bringing back the bulk of the data vs. running a search job on each entity within the incident.
When results are brought in, the results are placed into a temporary table similar to how Search does it. The table will take a similar naming scheme as well:
Table restored
Number ID
RST suffix
Example: SecurityEvent_12345_RST
Performing a Search and Restoration Job:
Search
Users can perform Seach jobs by doing the following:
Go to the Microsoft Sentinel dashboard in the Azure Portal.
Go to the Search blade.
Specify a data table to search and a time period it should review.
In the search bar, enter a key term to search for within the data.
Once this has been performed, a new Search job will be created. The user can leave and come back without impacting the progress of the job. Once it is done, it will show up under saved searches for future reference.
Note: Currently Search will use the following KQL to perform the Search: TableName | where * has ‘KEY TERM ENTERED’
Restore
Restore is a similar process to Search. To perform a restoration job, users need to do the following:
Go to the Microsoft Sentinel dashboard in the Azure Portal.
Go to the Search blade.
Click on ‘restore’.
Choose a data table and the time period to restore.
While Search, Basic, Archive, and Restore are in public preview, there will not be any cost generated. This means that users can begin using these features today without the worry of cost. As listed on the Azure Monitor pricing document, billing will not begin until April 1st, 2022.
Search
Search will generate cost only when Search jobs are performed. The cost will be generated per GB scanned (data within the workspace retention does not add to the amount of GB scanned). Currently the price will be $0.005 per GB scanned.
Restore
Restore will generate cost only when a Restore job is performed. The cost will be generated per GB restored/per day that the table is kept within the workspace. Currently the cost will be $.10 per GB restored per day that it is active. To avoid the recurring cost, remove Restore tables once they are no longer needed.
Basic
Basic log ingestion will work similar to how the current model works. It will generate cost per GB ingested into Azure Log Analytics and also Microsoft Sentinel if it is on the workspace. The new billing addition for basic log ingestion will be a query charge for GB scanned for the query. Data ingested into the Basic tier will not count towards commitment tiers. Currently the price will be $.50 per GB ingested in Azure Log Analytics and $.50 per GB ingested into Microsoft Sentinel.
Archive
Archive will generate a cost per GB/month stored. Currently the price will be $.02 per GB per month.
Learn More:
Documentation is now available for each of these features. Please refer to the links below:
This article is contributed. See the original author and article here.
Across industries, companies are finding practical ways to bridge physical reality and digital experiences using hands-free headsets and augmented reality solutions to inform decisions and action on insights produced by smart, connected solutions.
Mixed realitya set of technologies that superimposes digital data and images in the physical worldbrings new opportunities that have become instrumental to how we tap into unique real-world, human capabilities. This technology is becoming more widely used across organizations today and has proven to be transformative to task performance, learning and retention, and collaboration. In fact, the augmented and virtual reality market is expected to reach $372.1 billion by the end of 2022, and swell to $542.8 billion by the end of 2025 according to new data from the IDC.1
Microsoft HoloLens 2 and mixed reality solutions are driving material ROI across industries
Based on the Microsoft-commissioned Forrester Total Economic Impact (TEI) report, Microsoft HoloLens 2 is delivering 177 percent return on investment (ROI) and a net present value (NPV) of $7.6 million over three years with a payback of 13 months.2 Customers across leading industries are realizing significant value from deploying mixed reality solutions in their most common, critical work scenarios.
Manufacturing
Manufacturing companies deploying Microsoft HoloLens 2 and mixed reality applications to train their workforces, accelerate employee proficiency, and build more agile factories. Using Microsoft mixed reality, Manufacturers reduced training time by 75 percent, at an average savings of $30 per labor hour.2
Common scenarios in which manufacturers benefit from mixed reality on Microsoft HoloLens 2:
Guided assembly and training: Empower employees to learn new skills and complex assembly tasks with holographic step-by-step instructions, no instructor necessary.
Remote inspection and audits: Enable remote employees to solve business problems in real time, using 3D annotations to access, share, and bring critical information into view.
Connected field service: Connect field technicians with remote experts to collaborate seamlessly, heads-up and hands-free with content capture abilities, interactive annotations, and contextual data overlays.
“When you describe a problem, imagine that we are speaking different languages. When you explain it, someone on the other side may not understand precisely what’s happening, but when you show it in real time with the HoloLens, people understand.”Eaton Vehicle Group. Read more about the Eaton Vehicle Group customer story.
Education
Educators are turning to Microsoft HoloLens 2 and mixed reality applications to help students embrace a new way of learning. For example, education institutions reduced 520 annual hours of instruction per expert by 15 percent.2
Common scenarios in which educators benefit from mixed reality on Microsoft HoloLens 2:
Augmented teaching: Captivate students and bring education to life with impressionable, high-impact 3D visualization models that enable virtual collaboration and instruction.
Experiential learning: Enable educators to build an experience-based lesson plan, integrating textbook concepts into physical environments to create a simple “learn by doing” approach for studentshands-on and unmediated.
Scaled learning and research: Develop a scalable research collaboration model that improves efficiency of research, lab work, and medical training.
“We did a trial back with our medical students. The students that had been in the HoloLens lab scored 50 percent better compared to the rest of the med school class.”Case Western. Read more about the Case Western customer story.
Healthcare
Mixed reality is empowering providers, payors, and health science experts to reimagine healthcare by accelerating diagnoses, reducing time-to-care, and enabling personalization. Using Microsoft mixed reality, healthcare providers reduced average consumables by 80%, saving $4,000 per trainee.2
Common scenarios in which healthcare providers benefit from mixed reality on Microsoft HoloLens 2:
Holographic patient consultation: Enable healthcare providers to project 3D holographic visualizations of patients’ internal systems that provide procedural understandingbuilding confidence in upcoming procedures and/or treatments.
Remote expert consultation: Support remote consultation and enable medical staff to consult colleagues with heads-up and hands-free through an interactive collaborative experience from anywhere in the world.
Training simulations: Train medical staff with holographic step-by-step guidance without subject matter experts being physically present.
“Using Dynamics 365 Remote Assist, doctors wearing HoloLens, can hold “hands-free” and “heads-up” Teams video calls with colleagues and experts anywhere in the world. They can receive advice, interacting with the caller and the patient at the same time, while medical notes and X-rays can also be placed alongside the call in the wearer’s field of view.”Imperial College Healthcare NHS Trust. Read more about the Imperial College Healthcare NHS Trust customer story.
Architecture, engineering, and construction
With Mixed Reality, architecture, engineering, and construction (AEC) firms are empowered to overcome design, modeling, collaboration, and building site challenges to enhance project quality, decision-making, improve productivity. For example, AEC firms have reduced rework by 75 percent, saving $44 per hour.2
Common scenarios in which AEC organizations benefit from mixed reality on Microsoft HoloLens 2:
Clash detection: Enable onsite workers to preemptively identify issues, detect clashes, and gain buy-in of onsite workers and key stakeholders with overlay designs on physical locations. This mitigates late-stage design changes that could result in rework, budget overrun, and project delays.
3D plan and model demonstrations: Empower project leaders, designers, and engineers and improve customer service and sales with 3D demonstration and immersive visualizations.
Self-guided learning: Equip onsite workers to view task instructions, essential data, and model visualizations while in the flow of work, increasing speed, quality, and safety.
“We use Dynamics 365 Remote Assist on HoloLens 2 to work more effectively and share expertise at critical milestones. This not only saves us money but also helps us construct datacenters for our customers more quickly.”Microsoft. Read the full customer story.
The Forrester TEI study validates how mixed reality solutions on Microsoft HoloLens 2 are empowering enterprises across industries to achieve more. We believe these technologies have offered not only innovative results, but long-term and sustainable solutions for training, remote collaboration, inspections and audits, field service, and more.
Next steps
We look forward to continuing this blog series with a deep dive spotlight on each of these leading industries. In the meantime, learn more about mixed reality applications on Microsoft HoloLens 2 and get started today:
Request a Dynamics 365 Mixed Reality demo on Microsoft HoloLens 2. Book an appointment with our Microsoft Stores team today. Select ‘Other’ under Choose topic and reference HoloLens 2 demo in “What can we help with”.
This article is contributed. See the original author and article here.
Summary
The Sandworm actor, which the United Kingdom and the United States have previously attributed to the Russian GRU, has replaced the exposed VPNFilter malware with a new more advanced framework.
The United Kingdom’s (UK) National Cyber Security Centre (NCSC), the Cybersecurity and Infrastructure Security Agency (CISA), the National Security Agency (NSA), and the Federal Bureau of Investigation (FBI) in the U.S. have identified that the actor known as Sandworm or Voodoo Bear is using a new malware, referred to here as Cyclops Blink. The NCSC, CISA, and the FBI have previously attributed the Sandworm actor to the Russian General Staff Main Intelligence Directorate’s Russian (GRU’s) Main Centre for Special Technologies (GTsST). The malicious cyber activity below has previously been attributed to Sandworm:
Cyclops Blink appears to be a replacement framework for the VPNFilter malware exposed in 2018, and which exploited network devices, primarily small office/home office (SOHO) routers and network attached storage (NAS) devices.
This advisory summarizes the VPNFilter malware it replaces, and provides more detail on Cyclops Blink, as well as the associated tactics, techniques and procedures (TTPs) used by Sandworm. An NCSC malware analysis report on Cyclops Blink is also available.
It also provides mitigation measures to help organizations defend against malware.
A series of articles published by Cisco Talos in 2018 describes VPNFilter and its modules in detail. VPNFilter was deployed in stages, with most functionality in the third-stage modules. These modules enabled traffic manipulation, destruction of the infected host device, and likely enabled downstream devices to be exploited. They also allowed monitoring of Modbus SCADA protocols, which appears to be an ongoing requirement for Sandworm, as also seen in their previous attacks against ICS networks.
VPNFilter targeting was widespread and appeared indiscriminate, with some exceptions: Cisco Talos reported an increase of victims in Ukraine in May 2018. Sandworm also deployed VPNFilter against targets in the Republic of Korea before the 2018 Winter Olympics.
In May 2018, Cisco Talos published the blog that exposed VPNFilter and the U.S. Department of Justice linked the activity to Sandworm and announced efforts to disrupt the botnet.
Activity since its exposure
A Trendmicro blog in January 2021 detailed residual VPNFilter infections and provided data which showed that although there had been a reduction in requests to a known C2 domain, there was still more than a third of the original number of first-stage infections.
Sandworm has since shown limited interest in existing VPNFilter footholds, instead preferring to retool.
Cyclops Blink
Active since 2019
The NCSC, CISA, the FBI, and NSA, along with industry partners, have now identified a large-scale modular malware framework (T1129) which is targeting network devices. The new malware is referred to here as Cyclops Blink and has been deployed since at least June 2019, fourteen months after VPNFilter was disrupted. In common with VPNFilter, Cyclops Blink deployment also appears indiscriminate and widespread.
The actor has so far primarily deployed Cyclops Blink to WatchGuard devices, but it is likely that Sandworm would be capable of compiling the malware for other architectures and firmware.
Note: Note that only WatchGuard devices that were reconfigured from the manufacturer default settings to open remote management interfaces to external access could be infected
Malware overview
The malware itself is sophisticated and modular with basic core functionality to beacon (T1132.002) device information back to a server and enable files to be downloaded and executed. There is also functionality to add new modules while the malware is running, which allows Sandworm to implement additional capability as required.
Post exploitation, Cyclops Blink is generally deployed as part of a firmware ‘update’ (T1542.001). This achieves persistence when the device is rebooted and makes remediation harder.
Victim devices are organized into clusters and each deployment of Cyclops Blink has a list of command and control (C2) IP addresses and ports that it uses (T1008). All the known C2 IP addresses to date have been used by compromised WatchGuard firewall devices. Communications between Cyclops Blink clients and servers are protected under Transport Layer Security (TLS) (T1071.001), using individually generated keys and certificates. Sandworm manages Cyclops Blink by connecting to the C2 layer through the Tor network.
Mitigations
Cyclops Blink persists on reboot and throughout the legitimate firmware update process. Affected organizations should therefore take steps to remove the malware.
WatchGuard has worked closely with the FBI, CISA, NSA and the NCSC, and has provided tooling and guidance to enable detection and removal of Cyclops Blink on WatchGuard devices through a non-standard upgrade process. Device owners should follow each step in these instructions to ensure that devices are patched to the latest version and that any infection is removed.
If your device is identified as infected with Cyclops Blink, you should assume that any passwords present on the device have been compromised and replace them (see NCSC password guidance for organizations.
You should ensure that the management interface of network devices is not exposed to the internet.
This advisory has been compiled with respect to the MITRE ATT&CK® framework, a globally accessible knowledge base of adversary tactics and techniques based on real-world observations.
The actors most likely deploy modified device firmware images by exploiting an externally available service
Execution
T1059.004
Command and Scripting Interpreter: Unix Shell
Cyclops Blink executes downloaded files using the Linux API
Persistence
T1542.001
Pre-OS Boot: System Firmware
Cyclops Blink is deployed within a modified device firmware image
T1037.004
Boot or Logon Initialization Scripts: RC Scripts
Cyclops Blink is executed on device startup, using a modified RC script
Defense Evasion
T1562.004
Impair Defenses: Disable or Modify System Firewall
Cyclops Blink modifies the Linux system firewall to enable C2 communication
T1036.005
Masquerading: Match Legitimate Name or Location
Cyclops Blink masquerades as a Linux kernel thread process
Discovery
T1082
System Information Discovery
Cyclops Blink regularly queries device information
Command and Control
T1090
Proxy
T1132.002
Data Encoding: Non-Standard Encoding
Cyclops Blink command messages use a custom binary scheme to encode data
T1008
Fallback Channels
Cyclops Blink randomly selects a C2 server from contained lists of IPv4 addresses and port numbers
T1071.001
Application Layer Protocol: Web Protocols
Cyclops Blink can download files via HTTP or HTTPS
T1573.002
Encrypted Channel: Asymmetric Cryptography
Cyclops Blink C2 messages are individually encrypted using AES-256-CBC and sent underneath TLS
T1571
Non-Standard Port
The list of port numbers used by Cyclops Blink includes non-standard ports not typically associated with HTTP or HTTPS traffic
Exfiltration
T1041
Exfiltration Over C2 Channel
Cyclops Blink can upload files to a C2 server
A Cyclops Blink infection does not mean that an organization is the primary target, but it may be selected to be, or its machines could be used to conduct attacks.
Organizations are advised to follow the mitigation advice in this advisory to defend against this activity, and to refer to indicators of compromise (not exhaustive) in the Cyclops Blink malware analysis report to detect possible activity on networks.
UK organizations affected by the activity outlined in should report any suspected compromises to the NCSC at https://report.ncsc.gov.uk/.
Further Guidance
A variety of mitigations will be of use in defending against the malware featured in this advisory:
About This Document
This advisory is the result of a collaborative effort by United Kingdom’s National Cyber Security Centre (NCSC), the United States’ National Security Agency (NSA), the Federal Bureau of Investigation (FBI), and Department of Homeland Security (DHS) Cybersecurity and Infrastructure Security Agency (CISA).
CISA, FBI, and NSA agree with this attribution and the details provided in the report.
This advisory has been compiled with respect to the MITRE ATT&CK® framework, a globally accessible knowledge base of adversary tactics and techniques based on real-world observations.
Disclaimers
This report draws on information derived from NCSC and industry sources. Any NCSC findings and recommendations made have not been provided with the intention of avoiding all risks and following the recommendations will not remove all such risk. Ownership of information risks remains with the relevant system owner at all times.
DISCLAIMER OF ENDORSEMENT: The information and opinions contained in this document are provided “as is” and without any warranties or guarantees. Reference herein to any specific commercial products, process, or service by trade name, trademark, manufacturer, or otherwise, does not constitute or imply its endorsement, recommendation, or favoring by the United States Government, and this guidance shall not be used for advertising or product endorsement purposes.
For NSA client requirements or general cybersecurity inquiries, contact the Cybersecurity Requirements Center at 410-854-4200 or Cybersecurity_Requests@nsa.gov.
Contact Information
To report suspicious or criminal activity related to information found in this joint Cybersecurity Advisory:
U.S. organizations contact your local FBI field office at fbi.gov/contact-us/field-offices, or the FBI’s 24/7 Cyber Watch (CyWatch) at (855) 292-3937 or by email at CyWatch@fbi.gov. When available, please include the following information regarding the incident: date, time, and location of the incident; type of activity; number of people affected; type of equipment used for the activity; the name of the submitting company or organization; and a designated point of contact. To request incident response resources or technical assistance related to these threats, contact CISA at Central@cisa.gov.
Australian organizations should report incidents to the Australian Signals Directorate’s (ASD’s) ACSC via cyber.gov.au or call 1300 292 371 (1300 CYBER 1).
U.K. organizations should report a significant cyber security incident: ncsc.gov.uk/report-an-incident (monitored 24 hrs) or for urgent assistance, call 03000 200 973.
This article is contributed. See the original author and article here.
We’re releasing a new service sample to help you build secure voice, video, and chat applications. This sample provides you with an easy to deploy, trusted authentication service to generate Azure Communication Services identities and access tokens. It is available for both node.js and C#.
Azure Communication Services is designed with a bring-your-own-identity (BYOI) architecture. Identity and sign-on experiences are core to your unique application. Apps like LinkedIn have their own end-user identity system, while healthcare apps may use identity providers as part of existing middleware, and other apps may use 3rd party providers such as Facebook.
We’ve designed the ACS identity system to be simple and generic, so you have the flexibility to build whatever experience you want.
This new sample uses Azure App Service to authenticate users with Azure Active Directory (AAD), maps those users to ACS identities using Graph as storage, and finally generates ACS tokens when needed. We chose AAD for this sample because it’s a popular access management back-end, recognized for its security and scalability. It also integrates with 3rd party identity providers and OpenID interfaces. But you can use this sample as a launching point for integrating whatever identity provider or external system you want.
The sample provides developers a turn-key service which uses the Azure Communication Service Identity SDK to create and delete users, and generate, refresh, and revoke access tokens. The data flows for this sample are diagrammed below, but there is a lot more detail in GitHub with both node.js and C#repositories. An Azure Resource Manager (ARM) template is provided that generates the Azure subscription and automate deployment with a few clicks.
This article was originally posted by the FTC. See the original article here.
Every year, people report fraud, identity theft, and bad business practices to the FTC and its law enforcement partners. In 2021, 5.7 million people filed reports and described losing more than $5.8 billion to fraud — a $2.4 billion jump in losses in one year. You can learn about the types of fraud, identity theft, and marketplace issues people reported by state, and how scammers took payment — including $750 million in cryptocurrency — in the FTC’s new Consumer Sentinel Network Data Book. Here are some of the highlights:
More than 2.8 million people reported spotting a fraud, and one in four said they also lost money. Their combined losses were over $5.8 billion. Imposter scams, when someone pretended to be a trusted person or business, led to losses of $2.3 billion.
Almost 600,000 people filed reports about credit bureaus in 2021, an increase of more than 80 percent over the previous year. This jump in reports made credit bureaus, information furnishers, and report users the #3 most-reported category of 2021, behind imposter scams (#2) and identity theft (#1).
People ages 20-29 reported losing money to fraud more often than people ages 80 and over. While younger people lost money 41 percent of the time they experienced fraud, older adults lost money only 17 percent of the time. But when older people did lose money, they lost a median amount of $1,500, or three times the median amount younger people lost.
NOTE – The static web app Pipeline Task currently only works on Linux machines. When running the pipeline mentioned below, please ensure it is running on a Linux VM.
Create a static web app project in Bitbucket
NOTE – If you have an existing app in your repository, you may skip to the next section.
After creating a new project, select Create repository and then click on Import repository.
Select Import repository to import the sample application.
In the Create your first pipeline screen, select Starter pipeline.
Copy the following YAML and replace the generated configuration in your pipeline with this code.
pipelines:
branches:
main:
- step:
name: Deploy to test
deployment: test
script:
- pipe: microsoft/azure-static-web-apps-deploy:dev
variables:
APP_LOCATION: '$BITBUCKET_CLONE_DIR/src'
API_LOCATION: '$BITBUCKET_CLONE_DIR/api'
OUTPUT_LOCATION: '$BITBUCKET_CLONE_DIR'
API_TOKEN: $deployment_token
NOTE – If you are not using the sample app, the values for APP_LOCATION, API_LOCATION, and OUTPUT_LOCATION need to change to match the values in your application. Note that you have to give the values for APP_LOCATION, API_LOCATION, and OUTPUT_LOCATIONonly after $BITBUCKET_CLONE_DIR as shown above. i.e. $BITBUCKET_CLONE_DIR/<APP_LOCATION>
The API_TOKEN value is self-managed and is manually configured.
Property
Description
Example
Required
app_location
Location of your application code.
Enter/ if your application source code is at the root of the repository, or /app if your application code is in a directory called app.
Yes
api_location
Location of your Azure Functions code.
Enter /api if your app code is in a folder called api. If no Azure Functions app is detected in the folder, the build doesn’t fail, the workflow assumes you don’t want an API.
No
output_location
Location of the build output directory relative to the app_location.
If your application source code is located at /app, and the build script outputs files to the /app/build folder, then set build as the output_location value.
No
Select Add variables.
Add a new variable in Deployments section.
Name the variable deployment_token (matching the name in the workflow).
Copy the deployment token that you previously pasted into a text editor.
Paste in the deployment token in the Value box.
Make sure the Secured checkbox is selected.
Select Add.
Select Commit file and return to your pipelines tab.
You can see that the pipeline run is in progress with name Initial Bitbucket Pipelines configuration.
Once the deployment is successful, navigate to the Azure Static Web Apps Overview which includes links to the deployment configuration. Note how the Source link now points to the branch and location of the Bitbucket repository.
Select the URL to see your newly deployed website.
Clean up resources
Clean up the resources you deployed by deleting the resource group.
From the Azure portal, select Resource group from the left menu.
Enter the resource group name in the Filter by name field.
Select the resource group name you used in this tutorial.
Recent Comments