IR Prep and Detection

Engineering: When the

Cloud is your Data
Center
Don Murdoch, GSE #99
SEC 530 Instructor
Oct 3,4 2022 SANS Blue Team Summit
Scottsdale AZ (V2)
Numerous stories adapted from FOR 509, SEC 540, SEC 541, SEC 504, Real Life, the news,
Twitter
Abstract
 Public clouds have changed how organizations build their data
centers, moving from on-prem to the browser and API calls
over the commodity Internet. Attackers are determined to
find your weaknesses and mistakes. This presentation will go
over major attacks, highlight lessons learned, and provide you
with a road map for evaluating your public cloud usage to
improve your operational posture to minimize exposure and
your threat profile. Topics: MITRE ATT&CK Cloud Matrix, Top
Cloud Attack Kill Chains and disruption, Common attacker
activity, and log configuration within Azure and AWS to detect
these patterns.
Agenda
 Cloud Security Incident Case Studies
 Top Ten Cloud Security Issues
 Patterns and IR Focused Detections
 Logs and Incident Response
 Microsoft 365 and Application Notes
 Azure
 AWS

 Note: Lots of URL’s in the speaker notes sections

Cloud Incident Case Studies : Data Breach

 A Few representative data breaches, as listed by UpGuard, a

cybersecurity rating service
 Yahoo (8/17): 3B user accounts breached 8/13 at 1B accounts;
identity information and security questions exfiltrated
 Aadhar,1.1B people’s unique biometric data affected through a state
owned utility company
 Data breaches are becoming routine...
 Hot Poll – How many of you have gotten a breach notice in the past ..
6 months?
1 week?
Cloud Incident Case Studies : CodeSpaces

 CodeSpaces: PaaS service focused on software developers

(Q3/2014)
 Believed to be a credential leak, most likely discovered through
an active scan: Git repository, contents of S3 buckets
 Attacker found a console and had credentials and a default or
unconfigured app that has significant rights
 Attacker leveraged credentials to delete data, used an EC2
control panel, and ran a DDoS attack.
 IR determined attacker did not have private keys, changed
credentials, but attacker had backdoor access and conducted a
burn down at the speed of code
Cloud Incident Case Studies : Tesla Kubernetes
 Tesla (Winter 2017)
 Research group RedLock found hundreds of Kubernetes front end
dashboard / web consoles were exposed to the Internet and
improperly configured
 Cluster had stored “long term” credentials
 Cluster ran on virtual machines, not using
a native service
 Attackers found the open cluster,
leveraged it, and setup a BitCoin Miner farm
using a nonstandard port
 Cleaned up next day by Tesla
Cloud Incident Case Studies : Capital One SSRF Attack
 Capital One (3/19)
 Discovered that an S3 bucket was breached, exposing About 100M credit card
apps/numbers, 140,000 Social Security numbers of customers, and 80,000
linked bank account numbers of secured credit card customers
 Active scan to find a vulnerable web application or a potentially
misconfigured Web Application Firewall and leveraged SSRF to run a
command as the web server
 Attackers pivoted through an EC2 instance
 From the VM, the token service issues a short term credential for a token which came
back to the Web GUI and found the EC2 could read from S3 buckets
 http://169.254.169.254/latest/meta-data/

 Individual was caught and arrested because they bragged on chat boards
 Result: an $80M fine was levied by the Office of the Comptroller of
the Currency (Treasury)
python aws_inventory.py

Example Attacks that are Common in Cloud

 Password brute force, Credential discovery activity
 Exposed SSH, RDP (yes, people really do that), Web UI’s brute force
attacks, read GitHub, open object storage, Blogs, etc. to find key
exposure
 Lateral Movement once initial access is gained
 Accessing platform level accounts is a new attack vector
 Discovery tools like Pacu, ‘python aws_inventory.py’,
‘aws_public_ips’, etc .. make exploration quick
 Exfiltration
 Bucket/Blob storage provides an intermediate drop point, so it is a
great way to exfiltrate data for the attacker. Must enable storage
monitoring!
“Top Ten” Cloud Attacks
 Static Credential Exposure due to
insufficient management
 User, API, Access Keys, SSH keys
 Sever Compromise through exposed
remote access: SSH, RDP, Web
Console
 Database compromise via
Inadvertent exposure
 Insecure Object Storage
 S3, Azure BLOB
 Server Side Request Forgery
Ref: Rich Mogull / Disrupt Ops and Shawn Harris / StarBucks; CheckPoint; CSO Online.
 Leveraging accounts for financial
gain such as Cryptomining
 Network level attack / DDoS
 Compromised Secrets in an
instance/VM
 Novel (new) cloud exposure, data
exfiltration
 Subdomain Takeover
 Insider Threat (holding accounts
hostage)
Dig In: Static Credential Exposure
Average time from leak to usage is very short.
 Break this Cyber Attack Kill Chain
 Search/Scan GitHub, BitBucket, images, your internal network, shell history, apps,
and any other place where your code is published/stored
 Static analysis tools should search in the CI/CD pipeline
 Minimize the use of static credentials – use secret managers
 Tooling: eDiscovery, PoSH, AWS MACIE, GitLab secret detection, ...
 AWS: Tightly manage AWS IAM roles and federation
 Azure
 Implement Managed Service Identities
 Keep Primary Key tokens in key vault, use managed service identity for access
 Applications can use managed identities to obtain Azure AD tokens without having
to manage any credential
Time-Based Security : Critical for CSP’s
 Reproducible method to understand how much security a
product or technology provides
 How long are systems exposed?
 How long before we detect a compromise?
 How long before we respond?
 P – how long our protection works
 D – how long it takes us to detect
 R – how long it takes us to react

You Want: P > D + R

 TBS : Architecting for Prevention, Detection,
and Response

While
If the
prevention
attacker
works,
steals the
detecting and
safe and
responding
brings it
early help to
home, he
mitigate
eventually
impact.
wins. It’s a
matter of
time.
So why this so important? Turns out …
 It takes hackers 1 minute to find and abuse credentials
exposed on GitHub.
 PAUL BISCHOFF Set up a honeypot by publishing AWS
credentials in public GitHub repositories to find out how
attackers find and abuse them.
 DescribeInstances and GetAccountAuthorizationDetails API calls
 547 unique source IP’s
 Ref: article @pabischoff
October 1, 2020 on
www.comparitech.com
 Detection Engineering Defined Sort of...
 Humio:
 Detection engineering is the process of identifying threats before they can
do significant damage.
 SpectreOps:
 In detection engineering, we define high-value entities as classified
intellectual property or critical portions of production infrastructure. With
this definition in mind, detection engineers can focus on the high-risk or
high-value objects within an environment to narrow the focus of detection
to a specific scope of unique objects within the environment.
 Florian Roth:
 Detection engineering transforms an idea of how to detect a specific
condition or activity into a concrete description of how to detect it.
Don’s Working Definition

Detection Engineering is a systematic

process of identifying valuable assets and
their protection mechanisms in order to
determine how to detect activity in order
to identify threat actors before they can
damage or disrupt the asset.
Breaking Detection Engineering Down to its Core
Components
 Subject Matter Expertise
 You: The person who understands the problem space
 Observable and measurable behavior, enabled through instrumentation
 Atomic, Statistical, Behavioral
 Detection Engine enabled through telemetry
 Tooling that can evaluate a source against a pattern and send readings, with understanding
 Both human and machine readable output (JSON, XML, CSV, TSV, …)
 An area of focus
 Digital forensic analysis (memory, disk, network)
 Incident Response, Malware analysis, Security Operations
 Descriptive Language that can find an “event of interest”
 YARA, YARA-L, Sigma, OpenIOC, OSQuery, Snort, Suricata, SIEM rules, RegEx, …
Dig In : Observable behavior
 Atomic
A specific indicator or event
 An IoC: Recently malicious IP/Domain, malware hash
 Initial indicators are used on org wide searches as they are uncovered
 MX DNS queries from a non email server
 Statistical
 Outlier found through reviewing event / log data
 DNS: spike in domain TXT domain queries, “high” NXDomain returned, high
entropy domains
 Behavioral
 Multiple events or patterns, tracked across multiple data sources, bringing
several events together that violate a threshold
MITRE ATT&CK(TM) Cloud Matrix
Macro Level Analysis
Flow for CSP IR
Common CSP Log Analysis Hierarchy for IR

 Highest Priority to Lowest in terms of Detection Engineering,

Threat hunting, and Incident Detection
1. Identity and Access Management: Need to discover abused
acct/role, keys as early as possible due to the power user
keys provide
2. Cloud Platform
3. Resource Management – Create, start, delete, start / stop
4. Resource Provisioning
5. Applications
Microsoft Office 365
Microsoft Unified Audit Log is the Primary Source
 UAL contains numerous sources
 Exchange, SharePoint, Teams, Yammer, and limited One Drive w/ 30 min
delay
 Azure AD, Power Apps, Power automate w/ up to 24 hr. delay
 Enabled by default since Oct 2021 (need to check any account
prior)
 E5 license holder get 1 yr. retention, others get 90d
 Setup access in:
 MSFT 365 Compliance Center and MS Exchange Admin Center
 Same Group name needs to be in both with “View Only Audit Logs” role
 For PowerShell access: Install modules, use credential in the “Audit” group
https://compliance.microsoft.com/

Data is contained
in the “AuditData”
field when you
download the CSV
You might like this instead...
Use PowerShell to get the logs into a CSV
Search-UnifiedAuditLog -StartDate 5/1/2018 -EndDate 5/8/2018
-SessionId "UnifiedAuditLogSearch 05/08/17" -SessionCommand
ReturnLargeSet
Or Better Yet
# Outputs json AuditData strings (un-parsed) for the past
week, using an interval window of 120 minutes.:

PS C:\> Get-UnifiedAuditLog -StartDate (Get-Date).AddDays(-

7) -IntervalMinutes 120 -Verbose -WarningAction 'Continue' |
Select-Object -ExpandProperty AuditData | Out-File
.\o365.logs.json -Encoding UTF8
UAL Field Details of Note
 Key fields:
 Time, UserID, Workload, Operation, ResultStatus
 WorkLoad – Activity source; drives further field names
 Teams: Auto Starts on most Corp systems, can track computers when
‘off network’
 ResultStatus – not always populated
 Operation – can be somewhat vague
 Not every audit log has every field defined
FOSS Tools That Make Parsing Easier

 Tesorion CERT UAL Extractor (link)

 .\2-Get-AuditData.ps1 -StartDate 02/26/2022 -EndDate 04/26/2022 -
IntervalMinutes 720 -UserIds account1@company.onmicrosoft.com,
account2@company.onmicrosoft.com,account3@company.onmicrosoft.com
 Dark Quasar Azure Hunter (link)
 Has two playbooks built in; assumes logs are exported as CSV
 $RecordArray = Import-Csv .\my-exported-records.csv
 Invoke-AzHunterPlaybook -Records $RecordArray -Playbooks
'AzHunter.Playbook.UAL.LogonAnalyser’
 SOF ELK has import scripts
M365 Application Notes
 MS Teams – For integrated apps, activity shows up in the source
cloud system / application itself, not Teams
 SharePoint Online and OneDrive for Business overlap
 Many actions log in both: File/Folder activities, Sharing, and Synch
 MS Exchange
 Will see system and user activities
 MailItemAccessed – only logged in E5 licensed tenants
 Delete Process can log up to three records
 MoveToDeletedItems
 SoftDelete
 HardDelete
Azure AD logs
 Security and Activity logs are different
 Security
is useful for risky activity and identifying potential
compromises
 Activity is general audit history at tenant level and change user
 System generated events will have a MSFT Source IP
 Result_status – key field
 UserAgent – should be well known browsers for portal login
 MS Graph API
 Read calls are not usually logged. Where as “write” are often logged
to UAL or other Azure logs
Incident Detection for Office 365 (1/2)
 Change in the audit status
 To see current audit status: PoSH: Get-OrganizationConfig | Format-List
AuditDisabled should be false (yes, that is counter intuitive)
 Who read who’s mail? Was it expected?
 Exec’s may have admins; other than that, its one person’s mail
 Alert when someone is granted access to another's mailbox and/or calendar
 Non approved mail clients
 Visible through “Client=” field
 Note: OWA, IMAP, and POP3 clients use “bind” events
 Audit events drop at 1,000 for Bind ops
Incident Detection for Office 365 (2/2)

 Forwarding – Attackers like to setup forwards! This should not

happen.
 Key event: UpdateInboxRules – inbox rule added, deleted, changed
 Change permission on a mailbox with a Add-MailboxPermissions event
 Watch for “DeliverToMailboxForward” or “ForwardingAddress” rule
changes
 Sitecan also block this at the domain level, so look for “Drop” event
being registered
 OneDrive – “Excessive” file updates or deletes
More Example Detections (1/2)

 Activity Spikes
 Sudden uptick in OWA Bind (MailAccessType) can indicate a compromised
user’s mail is being read en masse by an attacker
 Business Email Compromise: Find the deviation from “normal”
 Users normally use the same UserAgent (phone, Outlook)
 Home/Office users access messaging platforms from the same ASN, network
range, city, country from one or two devices (Outlook, smartphone).
 Geographically improbable travel, multiple devices are key for BEC
 BEC actor will install a forwarding rule (Set-Mailbox,
ForwardingSMTPAddress), and will “re-read” the mail as they consume it
(spike in Operation=MailItemAccessed, from an E5 license
More Example Detections (2/2)
 Excessive permissions that lead to compromise ALCE events
 Attacker gains some sort of access, creates a new user, adds users to
roles/groups, pulls down / discovers the email list (like Outlook does)
 Then grants access (*.All, *.ReadWrite). and then creates forwarding rules,
or other message rules
 Establish Persistence for a privileged Cloud application
 Application changes as well w/ “UpdateApplication” with a NewValue that
begins with “Certificate”, allowing an attacker to leverage OAuth
 Running a memory snapshot via Microsoft’s AVML via SSM
Investigating Cloud App Integration : Graph API
 Registration Process: These should occur infrequently
 Setup: Register app, configure permissions, Get Global Admin Approval (to
enable).
 Action: App requests access token, calls graph API’s.
 Operation_Name: Records quite a bit of information
 Be aware of risky permissions granted to the service principal
 Global Admin: “Consent to Application”
 These events should be rare
 Should trigger an alert so that the Sec Team has awareness, the App
Portfolio is updated, and new access grants can be integrated in to Sec
Program
Graph Records for Incident Detection
 Azure App Registration Process
 SolarWinds: a compromised certificate was added to a privileged app, which
facilitated oAuth token generation and usage to monitor email through Graph API
 App Reg generates many events:
 Adding a service principal, application, generating a client secret, and Global Admin consent
 operationName = “Add Service Principle”
 Permissions Assignment
 AppRoleAssignment.ReadWrite.All and RoleManagement.ReadWrite.Directory are considered
extremely dangerous
 And permissions that end with an “ * ”
 Assigning Permissions that end with an “ * ” or “.All” may be risky Changes to roles that have
“administrator” in the name (like Global administrator)

 Tools: CISA’s Sparrow & Hawk tools help to assess this area
Amazon Web Services
Log Sources and What they Cover
 Cloud Trail
 Cloud Trail Insights
 Cloud Watch
 CloudWatch Log Insights
 GuardDuty
 VPC Flow
 S3 Server Access
 Route 53
 Load balancer
 Tenant console/API audit Log (90d)
 API usage outside of baseline
 Forwarded logs from apps, endpoints
 Metric/Pattern
 High Value Anomaly detection
 VPC flow (multiple points / levels)
 Logs from web based object storage
 DNS Resolver logs
 From Internet/Front end (you want XFF)
IR Preparation in AWS
 AWS Org – What is outside of the Org structure?
 Nearly all accounts must be in the Org structure, Policies can be applied to sub orgs
 Must be aware of root org accounts and how they are used in sub orgs!
 AWS has an ready to use IR framework that can present an acct outside of the org for
an “IR Org” specific account, outside o/t Org structure
 Granting “Read Only” is significantly easier within an Org structure
 Accounts can (and should) be configured to centrally log
 Cloud trail, API, etc.
 Investigation Process: What keys/accounts were used -> what did their policies
allow them to do -> What did they do (by user, by key ID)
 Use the Policy Simulator to see what the subject’s effective rights are
 Roles are a common target of abuse
 Drop a SANS SIFT system for quick deployment
 Must Get Scripting!

You must get familiar with the ‘aws cli’

aws cloudtrail lookup-events \
--lookup-attributes AttributeKey=EventName,AttributeValue=ListBuckets \
--max-items 10 \
--query 'Events[].{EventId:EventId,EventName:EventName,EventTime:EventTime,Username:Username}' \
--output table
-------------------------------------------------------------------------------------------------------------
| LookupEvents |
+---------------------------------------+--------------+-----------------------------+----------------------+
| EventId | EventName | EventTime | Username |
+---------------------------------------+--------------+-----------------------------+----------------------+
| 1a7825c0-60ea-4fcf-b295-923d566c0d18 | ListBuckets | 2022-06-15T16:28:11-04:00 | i-08c49f945f27055a9 |
| 212a774c-fcf2-466c-b79d-f50e37909602 | ListBuckets | 2022-06-15T09:24:04-04:00 | AWSConfig-Describe |
| 0af609f6-c1c2-4f7b-883d-22ae8564ec8c | ListBuckets | 2022-06-14T21:24:03-04:00 | AWSConfig-Describe |
| 64a4b139-40bc-4f34-9ac0-a022e48efd82 | ListBuckets | 2022-06-14T17:52:03-04:00 | i-0d64ea9a2c8b1ed37 |
+---------------------------------------+--------------+-----------------------------+----------------------+
 Must Learn JQ!
Humans aren’t all that excited reading JSON (I mean, we can do it ... but ...)
aws s3api list-buckets \ | jq .Buckets[].Name
“CoBucket-01cb220-ceodnm01kzqt“
“WebDocs-logs0b6081b1-1ib6zftanf4d4“
“CustPDFs-backups-f6dbb-5yvzozgmlay3“
“CoBucket-tagingbucket-1nbb7l4324unze"
aws cloudtrail lookup-events \
--max-items 100 \
--lookup-attributes AttributeKey=EventName,AttributeValue=ListBuckets | jq
'.Events[]|select((.Username | startswith("i-")) and
(.CloudTrailEvent|fromjson|select(.errorCode=="AccessDenied"))) |
{EventId,Username, CloudTrailEvent: (.CloudTrailEvent|fromjson)} |
"\(.Username)\(.CloudTrailEvent.sourceIPAddress)"'
"i-0ad8b208dc2ce3d44 54.225.48.14"
"i-0ad8b208dc2ce3d44 3.95.251.45"
"i-0d25acd32e06d3c5e 52.90.205.127"
CloudTrail Fields of Note
 eventTime: In UTC, NTP synch’d
 userIdentity: How/who triggered the event
 root, IAMuser, AssumedRole, FederatedUser, AWSAccount, AWSService
 eventSource: AWS service that created the event, use with ‘arn’
 eventName: Action, use with eventType
 resources:
 userAgent:
 signin, console, lambda, aws-cli, browswers, ...
 sessionCredentialFromConsole: When from the web UI
 Self Explanatory:
 awsRegion, sourceIPAddress
IR Specific to AWS IAM Logs
 Console users pushing access boundaries
 Particularly relevant if the cred’s are stolen in some manner
 ARN is the logged on account, UserAgent identifies the browser, SourceIPAddress is
where from, and “responeElements” reveals success/failure for the access type
 Common Recon Events: ListRoles, ListGroupsForUser, GetUser, GetPolicy,
ListAttachedGroupPolicies, ListAttachedUserPolicies
 Creation of new API keys because an attacker wants to shift to
automated code
 responseElements tells the username, AccessKeyId, status, and create date
 Exposed key misuse, such as a key in a GitHub project, which would
allow for retrospective review of logs for key usage
 Note: More than two dozen API calls return credential information
Example AWS Incident IR Detection Rules (1/2)
 Root account activity. Root should be rarely used.
 Change in MFA status, Issuing a new API key pair, login to the root account
 Assuming client follows best practice: any login that occurs to the root acct
 Several actions should only occur by auth parties (privileged few), so changes by anyone
other than “Admin A, B, or C”
 New Account Creation, policy create / edit / delete
 Cloud Trail change: removing copy to a separate bucket (if setup). AWS BP’s advise to log to a
separate bucket, one way, to another account’s S3 bucket
 Local User Accounts created within an account
 Several “Admin” level roles exist – Most are candidates for an attacker to manipulate
environment
 S3 Bucket Alerts
 Changing a bucket to become “publicly accessible” (multiple levels)\
 Inverse may also be true, as it could become a denial of service for a statically hosted website
Example AWS Incident IR Detection Rules (2/2)
 Disabling a logging/monitoring function: flow logs, Load balancer logs,
cloud trail replication, an S3 log or Lambda data event
 Any activity that occurs outside of the “Normal Region(s)”
 Any Guard Duty event should cause an alert; most have potential to be
a real incident
 Cluster spin up – ECS and EKS followed by a change in network security
group profile
 SSM: excessive permissions (SSM can give console access)
 Adding resources that allow / support Internet access to accounts that
did not have them such as an Internet GW or a NAT Gateway
 Use AWS Detective for analysis; provides behavior graphs, visualizations
AWS Cloud Trail Threat Hunting Common Patterns
 Impossible travel, change in source IP / country / location access patterns for
a user account
 Account bounds testing – looking for failures
 Keys / Roles accessing the console
 Profile changes, activity that can’t be explained by account holder
 New account creation, following within a few minutes to key creation, then
key issue and swapping to key access only with little to no console, then batch
of CLI commands executed
 New EC2 Instance creation
 New instances, new “huge” and GPU enabled instances as well like “g4ad.4xlarge” or
“p4d.24xlarge” or bare metal creation as well (resources very expensive)
 Inbound access
 If there is a load balancer, its logs are needed to see what the Src IP did
 Outbound DNS resolver queries (is Route 53 logging enabled?) is also quite
useful
A Few More Useful Details
 API Key
 ARN: What was used to create the key, use with userName
 responseElements: a JSON structure
 userName, accessKeyID, createDate, status (usually active)
 Self Explanatory
 eventTime, userAgent, sourceIPAddress
 For systems behind load balancers: sourceIP will be the LB. is “X-
Forwarded-for” enabled?
 Spike activity *may* be suspicious
 Be aware: API access is logged in CloudTrail; app access is in the server
access logs (you must enable)
Notes: Reading AWS Logs
 When the userIdentity field has “AWSAccount”, the event was triggered
from outside your account
 UserAgent field should be “mostly stable”, assuming user uses the same
PC/Mac/Boto3 library most of the time. A “very different” user agent
may indicate misuse
 Example: Historical key search
 If a key pair is leaked (GitHub, SourceForge) then search the CloudTrail history for
usage
 Resources created/modified/deleted outside of your normal region.
 Containers
 The metadata service can be leveraged to gain access; queries that use IMDSv1
(AWS link)
EDR Agents, auditd, Sysmon Command Execution, 4688
Command line : Credential Awareness
 AWS keeps the access key / secret ID in the ~/.aws/credentials”
file and your config in ~/.aws/config
 Possible signs of intrusion or misuse:
 If config/credentials files are ‘exported’, uploaded, emailed, copied to
another local account, etc.
 Anything other than the ‘aws’ command accessing, until the user learns to
use Python’s boto3 library of course!
 If this file is accessed / used outside of a “9 hour” work window
 Running various tools
 ‘coldsnap’ may indicate someone is downloading an EC2 snapshot
 Aws cli commands: fully expected by authorized users.
 Microsoft Azure
Thanks to Mark Morowczynski for pushing
out an update to the GIAC AB list,
9/20/22 to the Azure Active Directory
security operations guide – Just in Time!
Azure
 Many of the AWS IR / Detections can be directly applied to Azure
 Fields change names, concepts do not
 There are numerous sensitive roles; additions/deletions are of note
 Most of the rules with “* Administrator” are sensitive
 Use of a legacy protocol to validate credentials
 Logins: Can have successful password and failed MFA validation
 MFA may not be required everywhere (use MFASweep to find)
 Azure builds an “Identity string” to get to the actual resource
 Huge / Graphics machines: “Standard_NV4...” (N = GPU)
 Changing access of a Storage Account from Pub to Private
 Creating Storage is public by default (so, this should be changed ... !) to a “Private
Endpoint”
 Creating a VM that does not log (Windows Azure Diagnostic Extension not installed)
IR Analysis Evidence Notes
 Log Analytics workspaces have prebuilt queries to assist
 Using bash console shell will leave a container in a storage
account with commands in “.bash_history”; not true for
PowerShell console
 Signin/Audit and Activity: Logs have Tenant/Subscription activity
 Example: PW Spray, user account ALCE’s, start/stop VM’s
 Log Analytics will have lower level details, but need to be enabled
ahead of time
 Resource, OS, Application, etc. (details)
 Logs are all named “PT1h.log”, date/time is baked into the path name
MSFT Playbooks, Assessment, and Sec Ops guide
 So Far:
 Phishing identification and investigation
 Password Spray
 API consent grant given using MSFT Graph
 Compromised and Malicious Applications
 AD Sec Ops guide just updated on 9/16
 Added links to Sentinel templates and Sigma rules where possible in
each recommendation.
 Added guidance for the consumer or Azure AD B2C accounts
Cloud Security Roadmap
 Critical Principle:
 You can not copy/paste On Prem PnP’s and use them for CSP’s!
 True, many concepts flow through, but CSP’s are providing consumable IT in
their data center, which you did not design and build
 Begin with the end in mind: Breach, sprawl, budget over run
 Regulatory: Most CSP’s answer the baseline
 You need to articulate how you use, manage, monitor, and dispose
 For each “service”:
 Model threats, establish operational usage,
 Hey! Readymade: https://roadmap.cloudsecdocs.com/
Thanks!