Microsoft Azure Commercial Penetration Test Report 20190613

Company Sensitive and Proprietary
Microsoft Azure Commercial

FedRAMP Penetration Test Report
Prepared By:
Kratos Technology & Training

Solutions
10680 Treena Street, 6th Floor
San Diego, CA 92131
Offered through its cybersecurity division:
Kratos SecureInfo
14130 Sullyfield Circle, Suite H
Chantilly, VA 20151
888.677.9351
Company Sensitive and Proprietary

6/13/2019 Penetration Test Report
Executive Summary
Background
Microsoft retained Kratos SecureInfo to perform a FedRAMP (Federal Risk and Authorization
Management Program) penetration test of Azure Commercial. The Azure Commercial penetration test
is a representation of the security posture as of the end date of penetration testing, prior to any
mitigation. This report provides the results of the activities performed and serves as a permanent record
of the penetration testing activities. The effort was performed offsite remotely from the Kratos
SecureInfo lab in Alexandria, Virginia between 1/21/2019 and 5/10/2019. The testing included
automated and manual activities using the penetration testing guidance found in the “FedRAMP
Penetration Test Guidance, version 2.0” document.
Findings
There were zero (0) high, one (1) moderate, six (6) low and six (6) false positive findings identified
during the penetration test. The findings by impact level chart summarize the findings by impact level.
Detailed information about the findings is in “Appendix A – Findings”.
3 6 6
1
1
0 0
HIGH MODERATE LOW FALSE POSITIVE
Penetration Test Findings by Impact Level
Company Sensitive and Proprietary Page 1

Document Revision History

Date Pages Description Author
5/17/2019 All Draft Deliverable Kratos SecureInfo
6/7/2019 All Final Deliverable Kratos SecureInfo
Update to document repeat finding PF-
6/13/2019 16, 46 Kratos SecureInfo
2017-02
Updated accreditation boundary, per
11/11/2019 8 Kratos SecureInfo
JAB comments received on 11/4/2019.

Table of Contents
Executive Summary............................................................................................................................1
Background ............................................................................................................................................... 1
Findings ..................................................................................................................................................... 1
Document Revision History ................................................................................................................2
Table of Contents ...............................................................................................................................3
Table of Figures .................................................................................................................................5
Table of Tables...................................................................................................................................6
1. Overview .......................................................................................................................................7
1.1. Timeline.............................................................................................................................................. 9
1.2. Scope .................................................................................................................................................. 9
1.3. Attack Vectors .................................................................................................................................... 9
2. Web Application .......................................................................................................................... 12
2.1. Web Application Overview .............................................................................................................. 12
2.2. Web Application Testing: Microsoft Azure Commercial Suite ......................................................... 12
2.2.1. Web Application Azure Commercial Discovery ........................................................................ 15
2.2.1.1. Publically Available Information ........................................................................................ 15
2.2.1.2. Application Architecture .................................................................................................... 15
2.2.1.3. Accounts, Roles, and Authorization Bounds ...................................................................... 15
2.2.1.4. Content and Functionality ................................................................................................. 16
2.2.1.5. User-Controlled Inputs....................................................................................................... 17
2.2.1.6. Server Configuration Checks .............................................................................................. 17
2.2.2. Web Application Azure Commercial Exploitation ..................................................................... 19
2.2.2.1. Un-credentialed exploitation of Azure Commercial .......................................................... 19
2.2.2.2. Authentication and Session Management......................................................................... 19
2.2.2.3. Authorization ..................................................................................................................... 27
2.2.2.4. Tenant to Tenant ............................................................................................................... 27
2.2.2.5. Application Logic ................................................................................................................ 27
2.2.2.6. Input Validation ................................................................................................................. 27
2.2.3. Web Application Azure Commercial Post-Exploitation ............................................................ 27
3. Mobile Application ....................................................................................................................... 28
3.1. Mobile Application Overview........................................................................................................... 28
4. Network....................................................................................................................................... 29
4.1. Network Overview ........................................................................................................................... 29
4.2. Network Discovery ........................................................................................................................... 29
4.2.1. Publically Available Information ............................................................................................... 29
4.2.2. Endpoint Enumeration .............................................................................................................. 30
4.2.3. Service Enumeration ................................................................................................................. 30
4.2.4. Operating System Fingerprinting .............................................................................................. 31

4.2.5. Vulnerability Identification ....................................................................................................... 31

4.3. Network Exploitation ....................................................................................................................... 31
4.3.1. External Attack .......................................................................................................................... 31
4.3.2. Tenant to Tenant ...................................................................................................................... 34
4.4. Network Post-Exploitation ............................................................................................................... 34
5. Social Engineering ........................................................................................................................ 35
5.1. Social Engineering Overview ............................................................................................................ 35
5.2. Social Engineering Discovery............................................................................................................ 35
5.3. Social Engineering Exploitation ........................................................................................................ 36
6. Internal Attack ............................................................................................................................. 38
6.1. Internal Attack Overview ................................................................................................................. 38
6.2. Internal Attack Discovery ................................................................................................................. 38
6.2.1. Scoping ...................................................................................................................................... 38
6.2.2. Vulnerability Identification ....................................................................................................... 38
6.3. Internal Attack Exploitation ............................................................................................................. 39
6.3.1. Escalate to Administrative Privileges ........................................................................................ 39
6.3.2. Scanning of Azure Cloud Assets ................................................................................................ 41
7. Physical Security .......................................................................................................................... 42
7.1. Physical Security Overview .............................................................................................................. 42
7.2. Physical Security Discovery .............................................................................................................. 42
7.3. Physical Security Vulnerabilities....................................................................................................... 43
Appendix A – Findings ...................................................................................................................... 44
Appendix B – False Positives ............................................................................................................. 45
Appendix C – Evidence ..................................................................................................................... 46

Table of Figures
Figure 1-1: Architecture Diagram ................................................................................................................. 8
Figure 2-1: Before Azure Web App Login Screen ........................................................................................ 19
Figure 2-2: Azure Web App Login Screen.................................................................................................... 20
Figure 2-3: Request for two-factor authentication..................................................................................... 20
Figure 2-4: Session Token Set ..................................................................................................................... 21
Figure 2-5: Session Cookie Set Correctly..................................................................................................... 22
Figure 2-6: Identifying WS-Federation Module .......................................................................................... 23
Figure 2-7: Request showing setting of arbitrary origin ............................................................................. 24
Figure 2-8: Response showing origin set .................................................................................................... 25
Figure 2-9: Browser setting origin in request headers and shown in response headers ........................... 26
Figure 2-10: Authorization Matrix .............................................................................................................. 27
Figure 4-1: Network Frequency Analysis .................................................................................................... 32
Figure 4-2: Host Discovery .......................................................................................................................... 32
Figure 4-3: Service Ping Discovery .............................................................................................................. 33
Figure 4-4: Directory listing......................................................................................................................... 33
Figure 4-5: Core Smoke test ........................................................................................................................ 34
Figure 4-6: Runtime Error ........................................................................................................................... 34
Figure 5-1: Spear Phishing Click through Chart........................................................................................... 37

Table of Tables
Table 1-1: FedRAMP Attack Vector Matrix ................................................................................................. 10
Table 2-1: Microsoft Azure OSINT............................................................................................................... 15
Table 2-2: Azure Commercial Architecture ................................................................................................. 15
Table 2-3: Azure Commercial Account Roles .............................................................................................. 16
Table 2-4: Configuration Vulnerabilities ..................................................................................................... 18
Table 4-1: Network OSINT........................................................................................................................... 30
Table 4-2: Externally Accessible Hosts ........................................................................................................ 30
Table 4-3: CSP External Services ................................................................................................................. 30
Table 4-4: Externally Identifiable Operating Systems ................................................................................. 31
Table 4-5: External Vulnerability Identification Data.................................................................................. 31
Table 5-1: OSINT ......................................................................................................................................... 35
Table 5-2: Employee Social Network Profiles Related to CSP ..................................................................... 36
Table 5-3: Public information...................................................................................................................... 36
Table 6-1: Potential Simulated Attack Vectors ........................................................................................... 38
Table 6-2: Internal Network Scan Results ................................................................................................... 39
Table 7-1: Physical Penetration Test Location Information ........................................................................ 43

1. Overview
Federal Risk and Authorization Management Program (FedRAMP) is a government-wide program that
provides a standardized approach to security assessment, authorization, and continuous monitoring for
Cloud Service Providers (CSP). Testing FedRAMP mandated security controls, specifically through
penetration tests, is an integral part of the FedRAMP process. Penetration tests are mandated by the
FedRAMP program for initial accreditation or to maintain certification under continuous monitoring.
Microsoft hereinafter referred to as “CSP” retained Kratos SecureInfo, an accredited FedRAMP
independent 3PAO, to perform penetration testing of the Azure Commercial hereinafter referred to as
“CSP service” using current FedRAMP penetration testing guidance. Kratos SecureInfo conducted a
proactive and authorized FedRAMP penetration test to validate FedRAMP security controls
implemented on the CSP service. The primary goal for the FedRAMP penetration test includes:
✓ Gaining access to sensitive information

✓ Circumventing access controls and privilege escalation
✓ Exploiting vulnerabilities to gain access to systems or information
✓ Confirming that remediated items are no longer a risk
The CSP service is categorized as a FedRAMP Software as a Service (SaaS) Cloud Service Model and is
offered by Microsoft to quickly build, test, deploy, and manage their applications, services, and product
development across a network of Microsoft-managed datacenters within the United States. The
Microsoft Azure platform exports savings to the customer by delivering the software, platform, and
information technology (IT) infrastructure resources where and when it is needed via the Internet.
The following CSP service architectural diagram provides a visual depiction of the system network
components that constitute the portions undergoing the FedRAMP penetration test.

Azure Commercial
Accreditation Boundary
MSFT CORPNet
Customer Customer Azure

User Admin Operator
Legend
Azure
FedRAMP Accreditation Boundary
Operator Connectivity
TLS Physical Boundary
(Management Portal & Admin Apps
Storage Service)
Logical Boundary
Subsystem (see off page ref)
Admin Interfaces
ADFS
Customer defined
Interface
B Express Route
Internet Commercial
Azure Datacenter
Azure Core Network
A10 DDOS
Core Router Core Router
Datacenter Fabric Network Microsoft 1st Party Network

Q10 Routing DLA Routing Q10 Routing DLA Routing
(L2 & L3) (L2 & L3) (L2 & L3) (L2 & L3)
C C C C
Customer IaaS Azure Shared Services MSFT 1st Party (Office, CRM, Bing, Xbox, etc)
Storage, Compute,
Storage, Compute, VNets
Vnets, PaaS A
Bare Bare Bare Bare

D D Metal
VMs: Storage, Compute, Metal Metal Metal
Servers Servers Servers Servers
VNets
Customer Access Options
1 Over Internet - Customers can access resources from the internet

through customer defined interfaces (Webapps or Webportals)
2 Through Express Route - Customers can access resources over

private connections through Express Route
Figure 1-1: Architecture Diagram

During the penetration test, Kratos SecureInfo attempted to identify exploitable security weaknesses of
the CSP service including cloud service and application flaws, improper configurations, and end-user
behavior to evaluate the CSP’s security policy compliance, employees’ security awareness, and the
organization’s ability to identify and respond to security incidents. Findings were then validated,
documented, and given an appropriate impact rating which can be found in the “Appendix A – Findings”.
1.1. Timeline
The testing was performed remotely from the Kratos SecureInfo lab in Alexandria, Virginia between
1/21/2019 and 5/10/2019.
1.2. Scope
The scope for penetration testing included the agreed upon FedRAMP attack vectors detailed in Table
1-1: FedRAMP Attack Vector Matrix, and authorized in the signed and approved Rules of Engagement
(RoE) submitted as part of the Security Assessment Plan (SAP) for the CSP service offering. In-scope
resources tested include, but were not limited to: Network infrastructure, Internet facing services such
as web applications, Social engineering efforts directed at designated corporate employees, Hosts, and
Datacenter Physical Security.
During the engagement, Kratos SecureInfo did not perform any tests that would knowingly result in a
denial of service (DoS) to operations, networks, servers, or telephone systems. Additional detail can be
found in the CSP service penetration test RoE.
1.3. Attack Vectors

Based on threat modeling, FedRAMP has defined Six (6) attack vectors in addition to a physical
penetration test. The attack vectors are potential avenues of compromise that signal a degradation of
system integrity, confidentiality, or availability. For the CSP service penetration test, Kratos SecureInfo
mapped each FedRAMP attack vector to affected technology sections based on threat perspectives, as
shown in Table 1-1. Visually, Table 1-1 identifies if a particular FedRAMP attack vector is applicable for
the CSP service, and if so, further lists the technology sections tested. For each technology section
tested, a Test Case was created for the CSP service penetration test. Using this method, both the CSP
and Kratos SecureInfo explored potential vulnerabilities, threats, and mitigation strategies.

Technology Sections
Attack Vector Description Implemented?
Tested by Attack Vector
External Untrusted to Internal ☐ Web Application
Untrusted. An internet-based ☐ Mobile
attack attempting to gain Application
EXTERNAL TO useful information about or
Implemented ☐ Network
CORPORATE access the target cloud system
through an external corporate ☒ Social
network owned and operated by Engineering
the CSP. ☐ Internal Attack
☒ Web Application
External Untrusted to External ☐ Mobile
Trusted. An internet-based Application
EXTERNAL TO attack as an un-credentialed
Implemented ☒ Network
TARGET SYSTEM third party attempting to gain
unauthorized access to the ☐ Social
target system. Engineering
☐ Internal Attack
☒ Web Application
External Trusted to Internal ☐ Mobile
TARGET SYSTEM Trusted. An external attack as Application
TO CSP a credentialed system user
Implemented ☐ Network
MANAGEMENT attempting to access the CSP
SYSTEM management system or ☐ Social
infrastructure. Engineering
☐ Internal Attack
External Trusted to External
Trusted. An external attack as ☒ Web Application
a credentialed system user, ☐ Mobile
originating from a tenant Application
TENANT TO
environment instance, Implemented ☐ Network
TENANT
attempting to access or ☐ Social
compromise a secondary tenant Engineering
instance within the target ☐ Internal Attack
system.
Internal Untrusted to Internal ☐ Web Application
Trusted. An internal attack ☐ Mobile
attempting to access the Application
CORPORATE TO
target management system from
CSP MANAGEMENT Implemented ☐ Network
a system with an identified or
SYSTEM ☐ Social
simulated security weakness on
the CSP corporate network that Engineering
mimics a malicious device. ☒ Internal Attack
External Untrusted to External ☐ Web Application
Trusted. An attack that ☒ Mobile
emulates a mobile application Application
MOBILE Not
user attempting to access the ☐ Network
APPLICATION Implemented*
CSP target system or the CSP’s ☐ Social
target system’s mobile Engineering
application. ☐ Internal Attack
External Untrusted to Internal
Trusted. Ensure Datacenter
security doors are locked,
PHYSICAL
security alarms work, and
PENETRATION Implemented
security guards are present
TESTING
and alert as required by the
CSP organization’s security
policies and procedures.
Table 1-1: FedRAMP Attack Vector Matrix

Kratos SecureInfo, in collaboration with the CSP, determined that the Mobile Application FedRAMP
attack vector is not applicable. As per the SSP, the offering does not provide Mobile services and is not
included in this report.
Kratos SecureInfo, in collaboration with the CSP, determined that the Physical penetration testing is
applicable Microsoft being responsible for the security controls impacting the physical environment of
Azure. Physical security penetration tests will attempt to simulate an attack by an external untrusted
individual, including any rogue, untrusted Microsoft employee, against each datacenter processing
Azure data. Therefore, the physical penetration testing portion is included in this report.

2. Web Application
2.1. Web Application Overview
The FedRAMP penetration test of the CSP service included Internet-based attacks attempting to gain
unauthorized access to the CSP service web applications and the underlying Application Program
Interface (API). Specifically, Three (3) test cases cover at a minimum:
✓ A simulated Internet attack by an external un-credentialed entity (e.g. public) against the CSP
service web application(s).
✓ A simulated Internet attack by an external credentialed entity (e.g. customer) against the CSP
service management infrastructure.
✓ A simulated Internet attack by an external credentialed entity (e.g. customer #1) on a primary
tenant against a secondary tenant (e.g. customer #2).
2.2. Web Application Testing: Microsoft Azure Commercial Suite

The Microsoft Azure Commercial suite consists of multiple services that include web applications. A
breakdown of the sites below:
URLs in Scope
https://account.activedirectory.windowsazure.com/
adnotifications.windowsazure.com
service.activedirectory.windowsazure.com
service-tip.activedirectory.windowsazure.com
https://acis.engineering.core.windows.net
https://acis-beta.engineering.core.windows.net
https://accounts.accesscontrol.windows.net
data-prod-cus.vaultcore.azure.net
data-prod-eas.vaultcore.azure.net
data-prod-eau.vaultcore.azure.net
data-prod-ejp.vaultcore.azure.net
data-prod-eu2.vaultcore.azure.net
data-prod-eus.vaultcore.azure.net
data-prod-neu.vaultcore.azure.net
data-prod-sau.vaultcore.azure.net
data-prod-sbr.vaultcore.azure.net
data-prod-scu.vaultcore.azure.net
data-prod-sea.vaultcore.azure.net
data-prod-weu.vaultcore.azure.net
data-prod-wjp.vaultcore.azure.net
data-prod-wus.vaultcore.azure.net
https://vault.azure.net
BL2PrdApp01-t1-dsts.dsts.core.windows.net

BN1PrdApp02-t1-dsts.dsts.core.windows.net
BY1PrdApp06-t1-dsts.dsts.core.windows.net
CH1PrdApp10-t1-dsts.dsts.core.windows.net
CH3PrdApp09-T1-dsts.dsts.core.windows.net
DM1PrdApp02-t1-dsts.dsts.core.windows.net
SN2PrdApp07-t1-dsts.dsts.core.windows.net
SN3PrdApp11-T1-dsts.dsts.core.windows.net
SN3PrdApp12-T1-dsts.dsts.core.windows.net

https://login.microsoftonline.com/
https://fabriclogs.cloudapp.net/
account.activedirectory.windowsazure.com
account-tip.activedirectory.windowsazure.com
https://icm.ad.msft.net/
https://jitaccess.security.core.windows.net/
https://jitaccess-validation.security.core.windows.net/
https://firstparty.monitoring.windows.net/
https://monitoring.windows.net/
https://production.billing.monitoring.core.windows.net/
https://production.diagnostics.monitoring.core.windows.net
https://production.runners.monitoring.core.windows.net
https://admin.core.windows.net
https://cache1.ext.azure.com
https://cache2.ext.azure.com
https://portal.aadrm.com
https://portal.azurerms.com
https://production.secretstore.core.windows.net
https://passwordreset.microsoftonline.com/
https://wanetmon.cloudapp.net
https://dm1prdstr06b.stamp-diagnostics.store.core.windows.net/cws/
https://dm1prdstr06b.stamp-diagnostics.store.core.windows.net/sds/
https://dm1prdstr06b.stamp-diagnostics.store.core.windows.net/
https://location.core.windows.net
https://storageaccount.core.windows.net
https://xlocationch3prod.location-diagnostics.store.core.windows.net/
However, many applications were not accessible. Therefore, the list below portrays which web
applications could be accessed:
Accessible URLs
https://account.activedirectory.windowsazure.com/
https://acis.engineering.core.windows.net
https://acis-beta.engineering.core.windows.net
https://accounts.accesscontrol.windows.net
https://passwordreset.microsoftonline.com/
https://wanetmon.cloudapp.net
https://portal.azurerms.com
https://login.microsoftonline.com/
https://fabriclogs.cloudapp.net/
account.activedirectory.windowsazure.com
account-tip.activedirectory.windowsazure.com
https://jitaccess.security.core.windows.net/
https://jitaccess-validation.security.core.windows.net/
https://firstparty.monitoring.windows.net/

https://monitoring.windows.net/
https://production.billing.monitoring.core.windows.net/
https://production.diagnostics.monitoring.core.windows.net
2.2.1. Web Application Azure Commercial Discovery
2.2.1.1. Publically Available Information

Publicly available Internet searches were performed in an attempt to leverage useful insight into attacks
against Azure Commercial. Internet searches were performed to identify documentation, cached pages,
and any vulnerability information about Microsoft Azure. Search engine results from the most common
sources (Bing, Google, and Yahoo!) engines provided both current and cached page information. The
“Shodan” tool was used to collect data about the types of systems deployed (routers, servers, etc.) using
meta-data sent back to the client. Similarly, internet archiving projects, such as https://archive.org, were
used to identify snapshots of previous application content. Lastly, common websites and blogs such as
NVD, CVE, OSVDB, www.exploit-db.org, full-disclosure, etc. were searched for public indicators of
compromise. Table 2-1 shows the resultant public data identified.
Source Query Result

site:microsoft.com
Administrative Azure
info:azure filetype:xlsx
templates along with other
Google
Azure deployment templates
site:Microsoft.com
were found. No findings.
info:azure
dig dig Microsoft.com ANY No findings.
https://www.shodan.io/searc
Many servers are reported
h?query=microsoft.com
to be running on
shodan
Apache/Microsoft IIS httpd.
No findings.
h?query=azure.microsoft.com
Table 2-1: Microsoft Azure OSINT
2.2.1.2. Application Architecture

Table 2-2 displays the Azure Commercial architecture stack, including application servers, databases,
middleware, and other technologies employed by the web application. The information was gathered
using a variety of sources and depicts the Internet facing technology stack; useful data which was
leveraged against the penetration testing of Azure Commercial.
Architecture Version
[To be inserted in the final version]
Table 2-2: Azure Commercial Architecture
2.2.1.3. Accounts, Roles, and Authorization Bounds

Table 2-3 identifies the account roles along with the associated authorization boundaries of Microsoft
Azure Commercial.

Account Role Authorization(s) Comments

Microsoft Domain Vendor Microsoft Azure Internal Account Name:
Account Consumption v-elhasa@microsoft.com
Microsoft Domain Vendor Microsoft Azure Internal Account Name:
Account Consumption v-alham@microsoft.com
Table 2-3: Azure Commercial Account Roles
2.2.1.4. Content and Functionality

Content mapping during penetration tests used a combination of manual browsing and automated
mapping via the Burp Suite attack proxy tool. A full mapping of Microsoft Azure Commercial content is
included in “Appendix C - Evidence”.
Finding ID: Outdated JavaScript Libraries Low

PF-2017-02 (repeat) CVSS: 3.9
Vector String: CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L/E:P/RL:O/RC:C
Description
Impacted Hosts: portal.azurerms.com, icm.ad.msft.com, account.activedirectory.windowsazure.com
The following JavaScript libraries, which are all out of date, are included on the server.
• angularjs 1.3.0 (portal.azurerms.com)
• angular-translate 2.7.2 (portal.azurerms.com)
• angular-translate 2.11.1 (icm.ad.msft.com)
• bootstrap 3.3.6 (icm.ad.msft.com)
• FastClick 0.6.12 (portal.azurerms.com)
• jQuery 1.12.1 (icm.ad.msft.com)
• jQuery 1.12.2 (account.activedirectory.windowsazure.com)
• jquery cookie plugin 1.4.1 (portal.azurerms.com)
• modernizr 3.0.0pre (icm.ad.msft.com)
• momentjs 2.10.6 (portal.azurerms.com)
• placeholder 2.0.9 (portal.azurerms.com)
• sizzle css 2.2.0-pre (portal.azurerms.com)
Testers were not able to confirm with certainty that the vulnerable functions were implemented in an
unsafe manner. A temporal CVSS score was documented to reflect this uncertainty.
Exploitation Proof of Concept

Screenshots showing the version on each host are included in PT-006.
Recommendation
Updating JS libraries is typically trivial. However, testing should be conducted to ensure any changes to
the code, especially major version changes. JS libraries typically do not contain major security
vulnerabilities, but should be kept up to date regardless to prevent exploitation when one does occur. A
web vulnerability scanner or library manager should also be utilized to detect when software becomes
out of date to aid in updating the software.

2.2.1.5. User-Controlled Inputs

User-controlled input entries on the web application were identified by reviewing application mappings
and identifying the dynamic/static URLs containing sections for parameter input. User-controlled input
along with the content was used to identify fuzz test points and leverage attacks against Microsoft Azure
Commercial. A full listing of the web application user-controlled inputs is included in “Appendix C -
Evidence”.
2.2.1.6. Server Configuration Checks

The Burp Suite tool was used to identify server configurations and subsequently harvest potential
vulnerabilities. During testing automated checks were used to identify misconfigurations of SSL, cookies,
sharing policies, etc. Detailed information about these findings can be found in Table 2-4: Configuration
Vulnerabilities as well was “Appendix A – Findings”.

Title Summary Affected Hosts Additional

Information
https://accounts.access
control.windows.net/
https://fabriclogs.clou
dapp.net/
https://firstparty.moni
toring.windows.net/
The application https://icm.ad.msft.net
fails to prevent /
PF-2019-02: Strict SEE ARTIFACT PT-
users from https://monitoring.wind
transport security 004 under Appendix
connecting to it ows.net/
not enforced (Low) C - Evidence
over unencrypted https://passwordreset.m
connections. icrosoftonline.com/
https://production.bill
ing.monitoring.core.win
dows.net
https://production.diag
nostics.monitoring.core
.windows.net
The following RFC
1918 IP addresses
were disclosed in
the response:
10.223.115.10
10.223.115.11
10.223.115.12
10.223.115.13
10.223.115.14
10.223.115.5
PF-2019-03: Private SEE ARTIFACT PT-
10.223.115.6
IP Address https://icm.ad.msft.net 004 under Appendix
10.223.115.7
Disclosure (Low) C - Evidence
10.223.115.8
10.223.115.9
10.27.11.125
10.42.94.105
Furthermore,
10.42.94.105 and
10.27.11.125 are
revealed to be
virtual IPs for an
SQL server.
The application
accepts user-
PF-2019-04: SEE ARTIFACT PT-
controlled input
Reflected Open https://icm.ad.msft.net 004 under Appendix
into the target of
redirection (Low) C - Evidence
a redirection in
an unsafe way.
The application
implements an
HTML5 cross-origin
PF-2019-05: Cross- resource sharing
SEE ARTIFACT PT-
origin resource (CORS) policy for
https://icm.ad.msft.net 004 under Appendix
sharing: unencrypted this request which
C - Evidence
origin trusted trusts websites
accessed using
unencrypted
communications
Table 2-4: Configuration Vulnerabilities

2.2.2. Web Application Azure Commercial Exploitation
2.2.2.1. Un-credentialed exploitation of Azure Commercial

Testers confirm there were no vulnerabilities discovered during the attempt to gain unauthorized access
to the Azure Commercial web application without the use of credentials. Other than the login page, no
access to other pages or content is available. No findings discovered.
2.2.2.2. Authentication and Session Management

The Microsoft Azure system uses a two-factor authentication Single-Sign on method for its web
applications. This two-factor authentication method consists of a “something you know” and
“something you have” combination. In order to gain access to its web applications, a user must enter
their username/password along with providing a token. Sample screenshots below display the process
of logging into one of their applications.
Figure 2-1: Before Azure Web App Login Screen

Figure 2-2: Azure Web App Login Screen
Figure 2-3: Request for two-factor authentication

The token needed for two-factor authentication can be gained by direct phone call, or by utilizing
Microsoft Authenticator as a means to verify the login. Once that is completed, a session token along
with a session cookie is created. Figure 2-4 and Figure 2-5 show the identified session token along with
the session cookie being set as well as its proper flags.
Figure 2-4: Session Token Set

Figure 2-5: Session Cookie Set Correctly
Microsoft Azure Commercial suite utilizes the WS-Federation Authentication Module as shown Figure
2-6 below. The WS-Federation module allows federated authentication to ASP.NET applications. Testers
did not discover any findings with the WS-Federation Authentication Module being used with the
Microsoft Azure suite authentication process.

Figure 2-6: Identifying WS-Federation Module

Finding ID: Cross-Origin Resource Sharing Moderate

PF-2019-06 (CORS): Arbitrary Origin Trusted CVSS: 4.3
Vector String: CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
Description
Impacted Host: IcM Application
Cross-origin resource sharing vulnerabilities arise when web application trust arbitrary origins, allowing
two-way interaction by third-party web sites. The site specifies the header Access-Control-Allow-
Credentials: true, which gives an attacker the potential to carry out privileged actions and retrieve
sensitive information.
Exploitation Proof of Concept

The request/response shown in Figure 2-7 and Figure 2-8 illustrates an attacker’s ability to arbitrarily set
an origin:
Figure 2-7: Request showing setting of arbitrary origin

Figure 2-8: Response showing origin set
An attacker can use a CORS html page along with a valid domain and website. Figure 2-9 shows the
browser setting the origin to the domain that makes the request while the user is in session in the
following screenshots shown below.

Figure 2-9: Browser setting origin in request headers and shown in response headers
After successfully making a CORS request, an attacker can utilize this method in order to obtain
privileged application information.
Recommendation
Rather than using a wildcard or programmatically verifying supplied origins, the recommended course of
action would be to use a whitelist of trusted domains in order to prevent any untrusted third-party
domains from making a cross-site request.

2.2.2.3. Authorization
The Microsoft Azure Commercial defined roles were tested in an attempt to determine if privilege
enforcement issues exist. For example, the testers were given their vendor accounts as means to gain
user access to the Microsoft Azure Commercial suite. Testers attempted to gain and maintain privilege
escalation in order to make unauthorized administrative changes. However, the testers were
unsuccessful. No findings were discovered.
2.2.2.4. Tenant to Tenant

Testers attempted to gain leverage and/or access of one tenant with the access of a given tenant. In
order to do so, testers attempted to use well-formed HTTP requests while using another tenant’s
authenticated session cookie to make any user changes. These attempts were unsuccessful. Figure 2-10
below displays the results of the authorization matrix testing that was performed to suggest any cross-
tenant vulnerabilities. No findings were discovered.
Figure 2-10: Authorization Matrix
2.2.2.5. Application Logic

Microsoft Azure commercial logic patterns and user-input error handling were tested in order to
determine any unexpected errors or to bypass integrity controls that could have led to any negative
impact on application data. No findings were discovered.
2.2.2.6. Input Validation

Customized manual injection attacks against select user input points of the Microsoft Azure commercial
suite were conducted to identify common weaknesses in user controlled input filtering including Cross
Site Scripting and database injection attacks. Additionally, the Microsoft Azure commercial logic patterns
and application flows were tested in an attempt to circumvent data integrity controls or cause
unexpected errors that could have an impact on confidentiality or availability of data. No findings were
discovered.
2.2.3. Web Application Azure Commercial Post-Exploitation

No Post-Exploitation activities were warranted during the web application engagement.

3. Mobile Application
3.1. Mobile Application Overview
The FedRAMP defined mobile application attack vector emulates a malicious mobile user attempting to
access the CSP service offering, specifically targeting the mobile application infrastructure offered by the
tenant. Mobile application authorization boundaries are determined by the System Security Plan (SSP)
and the CSP service penetration test Rules of Engagement (RoE). For this engagement it was determined
that the mobile attack vector was not applicable. Further information as to why this vector was not
included can be found in the Attack Vectors section above.

4. Network
4.1. Network Overview
The FedRAMP penetration test of the CSP service included external public Internet testing the network
infrastructure and external security posture. The focus was to gain unauthorized access to the CSP
service via the network infrastructure. Specifically, tests simulated an external attack by an external un-
credentialed entity (e.g. public) against the CSP service network infrastructure, as configured in a
production environment. In addition to Network penetration test case(s), FedRAMP required the
following activities to be performed:
✓ Network discovery
✓ Network exploitation
✓ Network post-exploitation, if exploitation was successful
Successful exploitation of the external CSP service did not lead to new access path(s). FedRAMP required
post-exploitation activities to explore overall risk of a vulnerability to the CSP service as a whole. By
performing post-exploitation, it was possible to assess confidence that any impact of the vulnerability is
valid.
4.2. Network Discovery

4.2.1. Publically Available Information
Publicly available Internet searches were performed in an attempt to leverage useful insight into attacks
against the CSP service network infrastructure. Internet searches were performed to identify network
documentation, archived posts and emails by administrators and other key staff, usernames and
passwords, and any vulnerability information about the CSP service public-facing external network.
Search engine results from the most common sources (Bing, Google, and Yahoo!) engines provided both
current and cached page information. The “Shodan” tool was used to collect data about the types of
systems deployed (routers, servers, etc.) using meta-data sent back to the client. Similarly, internet
archiving projects, such as https://archive.org, were used to identify snapshots of previous network
content. Lastly, common websites and blogs such as NVD, CVE, www.exploit-db.org, full-disclosure, etc.
were searched for public indicators of compromise. Table 4-1 shows significant publicly available data
identified about the CSP service network.

Source Query Result

site:microsoft.com
Administrative Azure
info:azure filetype:xlsx
templates along with other
Google
Azure deployment templates
site:Microsoft.com
were found. No findings.
info:azure
dig dig Microsoft.com ANY No findings.
Many servers are reported
h?query=microsoft.com
to be running on
shodan
Apache/Microsoft IIS httpd.
No findings.
h?query=azure.microsoft.com
Table 4-1: Network OSINT
4.2.2. Endpoint Enumeration

Mapping [enumerating] the CSP service involved efforts to create the most complete listing of all the
active nodes on the externally facing Internet as possible. The effort also entails extracting the security
posture of the CSP service via probing for assets such as finding network, system, and endpoint
information protected by filtering, proxies, or Intrusion Prevention Systems. Initially, a standard Ping is
issued to the hosts followed by a more intrusive “service ping” in an attempt to bypass ping filters.
Service pings tickle the most common services offered using open-frequencies statistics collected by
IANA and insecure.org data. Service pings test both SYN and ACK against most common service ports to
bypass common boundary filtering and provide a more accurate account of the boundary protections
implemented by the CSP service, even if the standard services are blocked. The goal is to identify hosts
heavily filtered behind a firewall but still offering port services.
Description Method of Scan Result

Host Discovery (Service SEE ARTIFACT PT-002 under
NMAP
Ping) Appendix C - Evidence
Host Discovery (Service SEE ARTIFACT PT-002 under

Nessus
Ping) Appendix C - Evidence
Table 4-2: Externally Accessible Hosts
4.2.3. Service Enumeration

The services offered by the CSP service were mapped externally using various scanning techniques
directed toward network service ports. The effort involved a complete probe and attempted fingerprint
identification of reachable services offered by the common TCP and UDP network protocols. Table 4-3
shows the results for service probes on Azure Commercial.
Publicly identified
NMAP
services HTTP_Services.csv
Table 4-3: CSP External Services

4.2.4. Operating System Fingerprinting

OS fingerprinting was performed in an effort to obtain information about the underlying infrastructure.
Identified operating
NMAP
systems OS_Detect.csv
Table 4-4: Externally Identifiable Operating Systems
4.2.5. Vulnerability Identification

Prior to network exploitation, an un-credentialed vulnerability scan was conducted against the devices
at the edge of the CSP service defined boundary perimeter. Table 4-5: External Vulnerability
Identification Data shows the associated vulnerabilities and CSP service assets affected.
Finding Summary Affected Hosts Additional Information

No findings
Table 4-5: External Vulnerability Identification Data
4.3. Network Exploitation

A network-level exploitation of CSP service was completed to analyze the risks of identified
vulnerabilities. The penetration tests focused on external attacks against CSP service hosts to determine
the sensitivity any information retrieved if exploitation is successful. Attack scenario(s) were created to
exercise the security of CSP service with the intent of gaining access to the hosts/systems and elevating
privileges, if possible. If exploitation of the scenario was unsuccessful, the scenario also discussed
reasons why exploitation failed and what protections (if any) prevented the exploitation. The next
section(s) cover the network exploitation of the CSP service external boundary.
4.3.1. External Attack

Testers broke out the scope into two categories, IANA reserved and publicly routable. Reserved
addresses are in the 192.168.0.0/16, the 10.0.0.0/8 and the 100.64.0.0/10 networks and are not
routable over the public internet. A breakdown of the defined scope into these networks is shown in
Figure 4-1: Network Frequency Analysis.

100%
90% 85.90%
80%
70%
60%
50%
40%
30%
20% 12.53%
10% 1.18% 0.07%
0%
Public 10.0.0.0 192.168.0.0 100.64.0.0
Figure 4-1: Network Frequency Analysis
As shown by the Frequency analysis the IP address space available over the public internet is limited to
1.18% of the overall scope demonstrating a limited surface of public exposure. The testers used multiple
discovery techniques and different tools in an attempt to gain externally available information however
no such information was identified. Sample scan output demonstrating discovery is shown in Figure 4-2:
Host Discovery and Figure 4-3: Service Ping Discovery.
Figure 4-2: Host Discovery

Figure 4-3: Service Ping Discovery
Discovery identified two publicly accessible web servers. Testers reviewed these available services to
identify any vulnerabilities. One host identified returned a directory listing containing 2 ASP.net files and
a web configuration file. The directory listing is demonstrated in Figure 4-4: Directory listing.
Figure 4-4: Directory listing
Reviewing the CoreSmoke ASP.Net file disclosed a few installed components however no version
numbers were identified as well as no way to interact with the file beyond viewing its results. The test
results are shown in Figure 4-5: Core Smoke test.

Figure 4-5: Core Smoke test
Testers attempted to review the configuration file however an application error was returned and no
sensitive data was able to be obtained. This error is demonstrated in Figure 4-6: Runtime Error.
Figure 4-6: Runtime Error
After reviewing the contents of the web services as well as the version information remotely disclosed
testers were unable to identify and paths of exploitation.
4.3.2. Tenant to Tenant

Testers repeated the testing performed in Section 4.3.1 with a machine deployed into the Azure
environment. Results of this testing did not provided any additional information to the testers. No
vulnerabilities were identified through this testing.
4.4. Network Post-Exploitation

No post exploitation activity was applicable under the scope.

5. Social Engineering
5.1. Social Engineering Overview
The FedRAMP penetration test of the CSP service included an Internet-based attack attempting to gain
useful information about the CSP service offering. The primary goal of the social engineering effort is to
access the CSP service through the corporate network owned and operated by the CSP. The penetration
test attempted to simulate an attack by an external untrusted entity (i.e. public) against designated in-
scope CSP service personnel. A comprehensive Open Source Intelligence (OSINT) discovery process
along with a coordinated, but unannounced, spear phishing exercise was accomplished. The principle
reasoning is to gain insight into the possibility of exploiting weaknesses in the human factor coupled
leveraging corporate trust relationships to obtain an access path into the CSP service. Only employees,
who are affiliated with the CSP service and as determined by Open Source Intelligence (OSINT)
information, are targeted in this test. The vector primarily involves public information gathering of any
data of value to facilitate an attack against the CSP Service, followed by an unannounced spear phishing
campaign. As stated in the RoE, CSP service personnel were not targeted specifically to disclose Personal
Identifiable Information (PII), as defined by NIST Special Publication 800-122. The scope of the CSP
service phishing reconnaissance includes CSP service personnel with approved access to environments
within the CSP service accreditation boundary. The actual scope of the exercise was determined during
the CSP service Penetration Test RoE creation. During Open Source Intelligence (OSINT) efforts,
employees affiliated with the CSP service are identified and included in the Social Engineering
exploitation phase, which may additionally include an agreed upon sample of accounts provided by the
CSP. In such cases, those personnel were incorporated into Social Engineering spear phishing campaign.
If an employee is determined to be no longer employed by the CSP, although reported, such personnel
were removed from the scope.
5.2. Social Engineering Discovery

The penetration test began with Open Source Intelligence (OSINT) information gathering which includes
various attempts to discover key words and phrases related to the business conducted by the CSP,
specifically CSP service employees. Such employee-focused information gathering may concentrate on
publicly available information based on employee relationships, email lists, website posts, and social
networks. Interesting CSP service information was harvested publicly from various Open Source tools
and is identified in Table 5-1.
Source Query Result

Shodan Microsoft.com See PT-003 in Appendix C
WHOIS Microsoft.com See PT-003 in Appendix C
Contact information lookup Microsoft.com See PT-003 in Appendix C
Table 5-1: OSINT
Table 5-2 shows searches and results of possible employee social networking profiles associated with
the CSP service.

Source Query Result

Harvested based off of
Recon-ng See PT-003 in Appendix C
OSINT information
Table 5-2: Employee Social Network Profiles Related to CSP
Table 5-3 shows publicly available employee contact information associated with the CSP Service. Note
that the information depicted is “as harvested” and may be inaccurate. Raw data collected during Social
Engineering is located in “Appendix C – Evidence”.
Description Result
Harvested Public information

individuals_identified
.csv
Table 5-3: Public information
5.3. Social Engineering Exploitation

The Spear Phishing campaign is an electronic communication attempt, typically email, directed at
specific individuals of the CSP service in order to gain/maintain access or disclose sensitive information.
Kratos SecureInfo defined an acceptable email campaign based on a customized email template. During
the interview process, the CSP indicated that a total of 165 users with administrator access to the CSP
service infrastructure. Of these, a total of 165 of the CSP administrators were targeted during the
phishing campaign.
Social Engineering post-exploitation activities are not required by FedRAMP. Collection of statistics of
the unannounced spear phishing campaign toward the CSP service system administrators on the
approved list is, however, reportable to FedRAMP. The Spear Phishing campaign was unannounced and
launched from the Kratos SecureInfo lab on 4/29/2019 at 16:45 EST. Spear Phishing ended on 5/3/2019
at 23:59 EST.

Spear Phishing Results

1%
Targeted Administrators (Did

not click Phish)
Targeted Administrators
(Clicked Phish)
99%
Figure 5-1: Spear Phishing Click through Chart

6. Internal Attack
6.1. Internal Attack Overview
The FedRAMP penetration tests included representative corporate assets to determine the security
posture against threats to the CSP originating from the corporate environment. The focus was to
identify and exploit vectors on corporate assets to access systems within the CSP service boundary.
Specifically, tests exploited any trust relationships between the CSP service and corporate environment
by simulating an internal attack by an internal credentialed entity against the CSP service management
infrastructure. In addition to the Internal Attack penetration test case(s), FedRAMP required the
following activities to be performed:
✓ Internal Attack discovery

✓ Internal Attack exploitation
Internal Attack discovery involved a scoped identification of attack chains with the assumption that an
internal CSP service user was compromised via social engineering attack(s). Additionally, a credentialed
vulnerability scan of the representative workstation(s) was completed to identify publicly available
vulnerabilities and privilege escalation vectors. Internal Attack exploitation involved testing potentially
exploitable attack vulnerabilities on the representative workstation that could allow escalation and
pivoting. FedRAMP does not require post-exploitation activities. Post-exploitation is not applicable
under the Internal Attack vector; testing assumes a corporate breach with management access into the
CSP corporate network has already occurred given that penetration testing is able to identify privilege
escalation, pivoting avenues, and effective attack chains.
6.2. Internal Attack Discovery

6.2.1. Scoping
Kratos SecureInfo performed a scoping exercise to determine potential attack vectors into the CSP
service management environment. The scoping exercise identified possible privilege escalation, pivoting
avenues, and attack chains. The attack chain(s) assume that an internal CSP user/employee was
compromised by a successful social engineering attack. Table 6-1 describes various scenarios and
applicable attack chains.
Scenario Attack Chain

Insider Threat Scenario Laptop Privilege Escalation
Insider Threat Scenario Unauthorized Personnel Attack
Table 6-1: Potential Simulated Attack Vectors
6.2.2. Vulnerability Identification

The penetration test of the CSP service included credentialed vulnerability scans of the representative
corporate workstation(s). Detailed information about the findings is in “Appendix A – Findings”.

Title Name Description Affected Hosts Impact

The laptop
issued to the
Kratos
SecureInfo
penetration
testing team
was vulnerable
Privilege
PF-2019-01 to an exploit Lenovo ThinkPad Low
Escalation
which allowed
for the local
administrator
account to be
accessed by the
penetration
testing team.
Table 6-2: Internal Network Scan Results
6.3. Internal Attack Exploitation

6.3.1. Escalate to Administrative Privileges
Over the course of the penetration test, one goal was to obtain administrator access on the laptop
issued to the penetration testing team by the Azure team. An exploit path was discovered on the laptop
that allowed the penetration testing team to obtain Administrator access using an exploit commonly
known as the “sticky keys exploit.” Sticky keys are an accessibility feature built into the Windows
operating system that is on by default, and is executed by pressing the Shift key five times. Once done, a
prompt will appear asking if the user would like to use sticky keys.
Figure 6-1: Sticky Keys Present on Microsoft-Issued Laptop

This exploit is done by booting the windows machine to an installation copy of Windows 10. From the
initial installation screen, by pressing Shift + F10, a Command Prompt window will appear.
Figure 6-2: Booted Windows 10 Installation to Run Command Prompt
Once inside command prompt, the penetration test team changed directories to the internal drive “C:”
and copied the executable that runs when Shift is pressed five times. This executable is named
“sethc.exe.” By copying the Administrator command prompt, located at C:\windows\system32\cmd.exe,
and replacing the “sethc.exe” with this “cmd.exe” executable, the penetration test team was able to
execute an Administrator command shell from the login screen of the Windows operating system.
Multifactor authentication was required to access the laptop. An approved VPN was required to access
the environment. Just-in-time (JIT) access is required to access any asset within the environment,
scoping the potential targets (beyond the actual laptop, which is a corporate asset) for compromise
down to only include the Azure Jump Boxes. Risk is still present, but these mitigations and reduced
scope of potential targets lowers the likelihood of exploitation. This vulnerability is addressed as PF-
2019-1 in Appendix A.

Figure 6-3: Administrator Command Prompt on Windows Host
Once an Administrator command prompt was obtained, the penetration test team used the “net user”
commands to reset the Administrator password to “MsftPassword1” and proceeded to log in as the
local Administrator on the Azure laptop.
6.3.2. Scanning of Azure Cloud Assets

Over the course of the penetration test, the testers attempted to scan the Azure Cloud assets on the
laptop issued to the testers using Nessus Vulnerability Scanner. These assets were present on the VPN,
to which the testers had access. Due to the nature of the VPN, malformed packets were prevented from
being sent across the VPN. This is intended behavior, and is a mitigation strategy used in preventing
information gathering of the Azure Cloud assets.
Figure 6-4: Network Interface Does Not Support Packet Forgery

7. Physical Security
7.1. Physical Security Overview
The FedRAMP penetration test of the CSP service included physical security tests attempting circumvent
datacenter physical security to gain unauthorized access to critical CSP service assets. Physical security
penetration tests attempt to simulate an attack by an external untrusted individual, such as an
untrusted CSP employee, against each datacenter processing CSP service data. The CSP service
environment has 33 separate datacenters in the Commercial Cloud offering. The full datacenter reports
are available for review as part of the evidence package provided with this report. The scope of physical
security testing is described in the CSP service Penetration Testing RoE document attached as artifact
PT-001 in “Appendix C – Evidence”. Detailed information about the datacenters is listed in Table 7-1.
7.2. Physical Security Discovery

FedRAMP defined Physical Penetration Testing is described in the CSP service Penetration Test Rules of
Engagement (RoE) document. This selection covers datacenters listed in Table 7-1.
Location Datacenter Name Datacenter Designation Management Type

Ashburn, VA Blue Ridge BL3 Leased
Ashburn, VA Blue Ridge BLU2 Fully Managed
Boydton, VA Boydton BN1 Fully Managed
Bristow, VA Blue Ridge BLU Fully Managed
Cheyenne, WY Cheyenne CYS01 Fully Managed
Cheyenne, WY Cheyenne CYS04 Fully Managed
Elk Grove Village, IL Chicago CH3 Leased
Franklin Park, IL Chicago CH20 Leased
Northlake, IL Chicago CH1 Fully Managed
Quincy, WA Columbia CO1 Fully Managed
Quincy, WA Columbia CO2 Fully Managed
Qunicy, WA MWH MWH01 Fully Managed
San Antonio, TX San Antonio IDC SN1 Fully Managed
San Antonio, TX San Antonio IDC SN3 Leased
Santa Clara, CA BY BY1 Fully Managed
Santa Clara, CA BY BY2 Fully Managed
Santa Clara, CA BY BY22 Leased


Sterling, VA Blue Ridge BL20 Leased
West Des Moines, IA Des Moines DM1 Fully Managed
West Des Moines, IA Des Moines DSM05 Fully Managed
Table 7-1: Physical Penetration Test Location Information
7.3. Physical Security Vulnerabilities

No penetration testing related vulnerabilities were identified during the datacenter assessments.

Appendix A – Findings
Findings File
Please see Appendix A -
2019 Azure Commercial
This Excel Spreadsheet Contains Penetration Test
Penetration Test
Findings.
Findings.xlsx in the
provided package

Appendix B – False Positives

Please see the following table for the list of findings deemed false positive that were discovered during
penetration testing.
Discovery Source Vulnerability Justification

Timing based attacks were
being triggered due to no
response to the request.
Burp Suite Professional SQL Injection
Request is mitigated by
displaying an HTTP 404
error page.
Although no XSRF-Token is
Burp Suite Professional Cross-Site Request Forgery established, request is
non-state changing.
Request is mitigated by a
Client-side HTTP Parameter redirection to an error
Burp Suite Professional
Pollution screen. Redirects to safe
page.
Using the Internet Explorer
Content type incorrectly web browser, the page
stated displayed is an HTTP 404
error message.
The SSL certificate being
Burp Suite Professional SSL Certificate
used is owned by Microsoft.
The JavaScript action
Open redirection (DOM- object encodes the path/URI
based) before it is queried by the
xmlRequest function.

Appendix C – Evidence
Evidence ID Description Test Section Artifact
This artifact
Please see PT-001
contains the Rules
Rules of
of Engagement (RoE)
PT-001 Other Engagement.pdf in the
signed between
provided evidence
Kratos SecureInfo
package.
and CSP.
Please see PT-002
This artifact
Network in the
PT-002 contains scanning Networking
provided evidence
evidence.
package.
Please see PT-003
This artifact
Reconng.html in the
PT-003 contains the recon- Social Engineering
provided evidence
ng report
package.
This artifact
contains the Web Please see PT-004
Application Burp Burp Evidence in the
PT-004 Web Application
Report and intruder provided evidence
attack used to package.
discover FPD.
Please see PT-005
This artifact
Dig.txt in the
PT-005 contains the Dig Other
provided evidence
results.
package.
This artifact Please see PT-006
contains the Outdated JavaScript
PT-006 screenshots showing Web Application Libraries.zip in the
JavaScript library provided evidence
versions. package.

Microsoft Azure Commercial Penetration Test Report 20190613

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Microsoft Azure Commercial Penetration Test Report 20190613

Uploaded by

Copyright:

Available Formats

Company Sensitive and Proprietary

Microsoft Azure Commercial

Kratos Technology & Training

Offered through its cybersecurity division:

Company Sensitive and Proprietary

Penetration Test Findings by Impact Level

Company Sensitive and Proprietary Page 1

Document Revision History

Company Sensitive and Proprietary Page 2

Company Sensitive and Proprietary Page 3

4.2.5. Vulnerability Identification ....................................................................................................... 31

Company Sensitive and Proprietary Page 4

Company Sensitive and Proprietary Page 5

Company Sensitive and Proprietary Page 6

✓ Gaining access to sensitive information

Company Sensitive and Proprietary Page 7

Customer Customer Azure

Azure Core Network

Datacenter Fabric Network Microsoft 1st Party Network

Bare Bare Bare Bare

Customer Access Options

1 Over Internet - Customers can access resources from the internet

2 Through Express Route - Customers can access resources over

Company Sensitive and Proprietary Page 8

1.3. Attack Vectors

Company Sensitive and Proprietary Page 9

Company Sensitive and Proprietary Page 10

Company Sensitive and Proprietary Page 11

2.2. Web Application Testing: Microsoft Azure Commercial Suite

Company Sensitive and Proprietary Page 12

Company Sensitive and Proprietary Page 13

Company Sensitive and Proprietary Page 14

2.2.1. Web Application Azure Commercial Discovery

2.2.1.1. Publically Available Information

Source Query Result

2.2.1.2. Application Architecture

2.2.1.3. Accounts, Roles, and Authorization Bounds

Company Sensitive and Proprietary Page 15

Account Role Authorization(s) Comments

2.2.1.4. Content and Functionality

Finding ID: Outdated JavaScript Libraries Low

Exploitation Proof of Concept

Company Sensitive and Proprietary Page 16

2.2.1.5. User-Controlled Inputs

2.2.1.6. Server Configuration Checks

Company Sensitive and Proprietary Page 17

Title Summary Affected Hosts Additional

Company Sensitive and Proprietary Page 18

2.2.2. Web Application Azure Commercial Exploitation

2.2.2.1. Un-credentialed exploitation of Azure Commercial

2.2.2.2. Authentication and Session Management

Figure 2-1: Before Azure Web App Login Screen

Company Sensitive and Proprietary Page 19

Figure 2-2: Azure Web App Login Screen

Figure 2-3: Request for two-factor authentication

Company Sensitive and Proprietary Page 20

Figure 2-4: Session Token Set

Company Sensitive and Proprietary Page 21

Figure 2-5: Session Cookie Set Correctly

Company Sensitive and Proprietary Page 22

Figure 2-6: Identifying WS-Federation Module

Company Sensitive and Proprietary Page 23