├── .gitignore
├── CONTRIBUTORS.md
├── LICENSE
├── README.md
└── techniques
├── abuse_existing_oauth_integrations
├── description.md
└── examples
│ ├── zapier.md
│ └── zapier_integrations.png
├── account_ambushing
├── description.md
└── examples
│ ├── ifttt.md
│ └── ifttt.png
├── account_recovery
├── description.md
└── examples
│ ├── ifttt.md
│ ├── ifttt_1.png
│ └── ifttt_2.png
├── aitm_phishing
└── description.md
├── api_keys
├── description.md
└── examples
│ ├── shortcut.md
│ └── shortcut.png
├── api_secret_theft
├── description.md
└── examples
│ ├── postman.md
│ ├── postman_1.png
│ └── postman_2.png
├── app_directory_lookup
├── description.md
└── examples
│ ├── shortcut.md
│ └── shortcut.png
├── app_spraying
└── description.md
├── automation_workflow_sharing
├── description.md
└── examples
│ ├── microsoft_power_automate.md
│ ├── microsoft_power_automate_1.png
│ ├── microsoft_power_automate_2.png
│ ├── microsoft_power_automate_3.png
│ ├── microsoft_power_automate_4.png
│ ├── microsoft_power_automate_5.png
│ ├── microsoft_power_automate_6.png
│ └── microsoft_power_automate_7.png
├── client-side_app_spoofing
├── description.md
└── examples
│ ├── github_vscode.md
│ ├── github_vscode1.png
│ ├── github_vscode2.png
│ ├── github_vscode3.png
│ ├── github_vscode4.png
│ ├── thunderbird.md
│ └── thunderbird.png
├── consent_phishing
├── description.md
└── examples
│ ├── microsoft.md
│ └── microsoft.png
├── credential_stuffing
├── credential_stuffing.png
└── description.md
├── cross-idp_impersonation
└── description.md
├── device_code_phishing
├── description.md
└── examples
│ ├── microsoft.md
│ ├── ms_devicecode1.png
│ ├── ms_devicecode2.png
│ └── ms_devicecode3.png
├── device_enrollment
└── description.md
├── dns_reconnaissance
├── description.md
└── examples
│ └── txt_hsbc.md
├── email_discovery
├── description.md
└── examples
│ ├── welcome_to.md
│ └── welcome_to.png
├── email_phishing
└── description.md
├── evil_twin_integrations
├── description.md
└── examples
│ ├── hubspot.md
│ ├── hubspot_email_view.png
│ └── hubspot_inboxes.png
├── ghost_logins
├── description.md
└── examples
│ ├── expensify.md
│ ├── expensify_secondary_logins.png
│ ├── shortcut.md
│ └── shortcut_set_password.png
├── guest_access_abuse
└── description.md
├── hijack_oauth_flows
└── description.md
├── im_phishing
├── description.md
└── examples
│ ├── slack.md
│ ├── slack.png
│ ├── teams.md
│ └── teams.png
├── im_user_spoofing
├── description.md
└── examples
│ ├── slack.md
│ └── slack.png
├── in-app_phishing
├── description.md
└── examples
│ ├── github.md
│ ├── image-1.png
│ └── image.png
├── inbound_federation
├── description.md
└── examples
│ ├── okta.md
│ ├── okta1.png
│ ├── okta2.png
│ └── okta3.png
├── link_backdooring
├── description.md
└── examples
│ ├── nuclino.md
│ ├── nuclino_evil_link.png
│ ├── nuclino_legit_link.png
│ └── nuclino_long_evil_link.png
├── link_sharing
├── description.md
└── examples
│ ├── nuclino.md
│ ├── nuclino.png
│ ├── onedrive.md
│ ├── onedrive_1.png
│ └── onedrive_2.png
├── malicious_mail_rules
├── description.md
└── examples
│ ├── office_365.md
│ └── office_365.png
├── mfa_downgrade
└── description.md
├── mfa_fatigue
└── description.md
├── noauth
├── description.md
└── examples
│ ├── azuread.md
│ └── azuread.png
├── oauth_token_enumeration
├── description.md
└── examples
│ ├── google.md
│ ├── google.png
│ ├── microsoft.md
│ └── microsoft.png
├── oauth_tokens
├── description.md
└── examples
│ ├── graph_explorer.md
│ ├── graph_explorer.png
│ ├── slack_api_tester.md
│ └── slack_api_tester.png
├── password_scraping
├── description.md
└── examples
│ ├── canva.md
│ ├── canva_email.png
│ ├── canva_login.png
│ └── okta.md
├── passwordless_logins
├── description.md
└── examples
│ ├── canva.md
│ ├── canva_1.png
│ ├── canva_2.png
│ ├── expensify.md
│ ├── expensify1.png
│ ├── expensify2.png
│ ├── slack.md
│ ├── slack_1.png
│ └── slack_2.png
├── poisoned_tenants
├── description.md
└── examples
│ ├── nuclino.md
│ ├── nuclino_email.png
│ ├── nuclino_invite.png
│ ├── nuclino_sharing.png
│ ├── trello.md
│ └── trello.png
├── saml_enumeration
├── description.md
└── examples
│ ├── expensify.md
│ ├── expensify_saml1.png
│ ├── expensify_saml2.png
│ ├── expensify_saml3.png
│ ├── expensify_saml4.png
│ ├── expensify_saml5.png
│ ├── ramp.md
│ ├── ramp_no_saml.png
│ ├── ramp_saml.png
│ ├── ramp_saml_details.png
│ └── ramp_sso_not_configured.png
├── samljacking
├── description.md
└── examples
│ ├── datadog.md
│ ├── datadog1.png
│ ├── datadog2.png
│ ├── datadog3.png
│ ├── nuclino.md
│ ├── nuclino_login.png
│ ├── nuclino_phishing.png
│ └── nuclino_saml.png
├── session_cookie_theft
└── description.md
├── shadow_workflows
├── description.md
└── examples
│ ├── zapier.md
│ ├── zapier1.png
│ └── zapier2.png
├── slug_tenant_enumeration
├── description.md
└── examples
│ ├── bamboohr.md
│ ├── bamboohr_invalid_slug.png
│ ├── bamboohr_successful_redirect.png
│ └── bamboohr_valid_slug.png
├── subdomain_tenant_discovery
├── description.md
└── examples
│ ├── bamboohr.md
│ └── bamboohr.png
├── system_integrations
├── description.md
└── examples
│ ├── slack.md
│ ├── slack_app_info.png
│ ├── slack_integration.png
│ └── slack_message.png
├── takeout_services
├── description.md
└── examples
│ ├── google.md
│ └── google.png
├── ui_redressing
└── description.md
├── username_enumeration
├── description.md
└── examples
│ ├── expensify.md
│ ├── expensify1.png
│ ├── expensify2.png
│ ├── ramp.md
│ ├── ramp_no_user.png
│ ├── ramp_request.png
│ └── ramp_valid_user.png
├── verification_phishing
└── description.md
└── webhooks
├── description.md
└── examples
└── microsoft_365.md
/.gitignore:
--------------------------------------------------------------------------------
1 | .DS_Store
--------------------------------------------------------------------------------
/CONTRIBUTORS.md:
--------------------------------------------------------------------------------
1 | # Contributors
2 |
3 | Initial research and write-ups by Push Security research team:
4 | * Luke Jennings
5 | * Johann Scheepers
6 | * Jacques Louw
7 |
8 | Special thanks for feedback and advice on early drafts from:
9 | * [UK NCSC](https://www.ncsc.gov.uk/)
10 | * [John Fitzpatrick](https://www.linkedin.com/in/john-fitzpatrick-754a216b/) of [Lab539](https://www.lab539.com/)
11 | * [Dave Hartley](https://www.linkedin.com/in/nmonkee/) of [NCC Group](https://www.nccgroup.com/)
12 | * [Craig Swan](https://www.linkedin.com/in/craig-swan-b4ab3413/)
13 |
14 | Special thanks for contributors to the repository post-release:
15 |
16 | * [@tkalahan](https://twitter.com/tkalahan)
17 | * [@CharanRoot](https://github.com/CharanRoot)
18 |
--------------------------------------------------------------------------------
/LICENSE:
--------------------------------------------------------------------------------
1 | Attribution 4.0 International
2 |
3 | =======================================================================
4 |
5 | Creative Commons Corporation ("Creative Commons") is not a law firm and
6 | does not provide legal services or legal advice. Distribution of
7 | Creative Commons public licenses does not create a lawyer-client or
8 | other relationship. Creative Commons makes its licenses and related
9 | information available on an "as-is" basis. Creative Commons gives no
10 | warranties regarding its licenses, any material licensed under their
11 | terms and conditions, or any related information. Creative Commons
12 | disclaims all liability for damages resulting from their use to the
13 | fullest extent possible.
14 |
15 | Using Creative Commons Public Licenses
16 |
17 | Creative Commons public licenses provide a standard set of terms and
18 | conditions that creators and other rights holders may use to share
19 | original works of authorship and other material subject to copyright
20 | and certain other rights specified in the public license below. The
21 | following considerations are for informational purposes only, are not
22 | exhaustive, and do not form part of our licenses.
23 |
24 | Considerations for licensors: Our public licenses are
25 | intended for use by those authorized to give the public
26 | permission to use material in ways otherwise restricted by
27 | copyright and certain other rights. Our licenses are
28 | irrevocable. Licensors should read and understand the terms
29 | and conditions of the license they choose before applying it.
30 | Licensors should also secure all rights necessary before
31 | applying our licenses so that the public can reuse the
32 | material as expected. Licensors should clearly mark any
33 | material not subject to the license. This includes other CC-
34 | licensed material, or material used under an exception or
35 | limitation to copyright. More considerations for licensors:
36 | wiki.creativecommons.org/Considerations_for_licensors
37 |
38 | Considerations for the public: By using one of our public
39 | licenses, a licensor grants the public permission to use the
40 | licensed material under specified terms and conditions. If
41 | the licensor's permission is not necessary for any reason--for
42 | example, because of any applicable exception or limitation to
43 | copyright--then that use is not regulated by the license. Our
44 | licenses grant only permissions under copyright and certain
45 | other rights that a licensor has authority to grant. Use of
46 | the licensed material may still be restricted for other
47 | reasons, including because others have copyright or other
48 | rights in the material. A licensor may make special requests,
49 | such as asking that all changes be marked or described.
50 | Although not required by our licenses, you are encouraged to
51 | respect those requests where reasonable. More considerations
52 | for the public:
53 | wiki.creativecommons.org/Considerations_for_licensees
54 |
55 | =======================================================================
56 |
57 | Creative Commons Attribution 4.0 International Public License
58 |
59 | By exercising the Licensed Rights (defined below), You accept and agree
60 | to be bound by the terms and conditions of this Creative Commons
61 | Attribution 4.0 International Public License ("Public License"). To the
62 | extent this Public License may be interpreted as a contract, You are
63 | granted the Licensed Rights in consideration of Your acceptance of
64 | these terms and conditions, and the Licensor grants You such rights in
65 | consideration of benefits the Licensor receives from making the
66 | Licensed Material available under these terms and conditions.
67 |
68 |
69 | Section 1 -- Definitions.
70 |
71 | a. Adapted Material means material subject to Copyright and Similar
72 | Rights that is derived from or based upon the Licensed Material
73 | and in which the Licensed Material is translated, altered,
74 | arranged, transformed, or otherwise modified in a manner requiring
75 | permission under the Copyright and Similar Rights held by the
76 | Licensor. For purposes of this Public License, where the Licensed
77 | Material is a musical work, performance, or sound recording,
78 | Adapted Material is always produced where the Licensed Material is
79 | synched in timed relation with a moving image.
80 |
81 | b. Adapter's License means the license You apply to Your Copyright
82 | and Similar Rights in Your contributions to Adapted Material in
83 | accordance with the terms and conditions of this Public License.
84 |
85 | c. Copyright and Similar Rights means copyright and/or similar rights
86 | closely related to copyright including, without limitation,
87 | performance, broadcast, sound recording, and Sui Generis Database
88 | Rights, without regard to how the rights are labeled or
89 | categorized. For purposes of this Public License, the rights
90 | specified in Section 2(b)(1)-(2) are not Copyright and Similar
91 | Rights.
92 |
93 | d. Effective Technological Measures means those measures that, in the
94 | absence of proper authority, may not be circumvented under laws
95 | fulfilling obligations under Article 11 of the WIPO Copyright
96 | Treaty adopted on December 20, 1996, and/or similar international
97 | agreements.
98 |
99 | e. Exceptions and Limitations means fair use, fair dealing, and/or
100 | any other exception or limitation to Copyright and Similar Rights
101 | that applies to Your use of the Licensed Material.
102 |
103 | f. Licensed Material means the artistic or literary work, database,
104 | or other material to which the Licensor applied this Public
105 | License.
106 |
107 | g. Licensed Rights means the rights granted to You subject to the
108 | terms and conditions of this Public License, which are limited to
109 | all Copyright and Similar Rights that apply to Your use of the
110 | Licensed Material and that the Licensor has authority to license.
111 |
112 | h. Licensor means the individual(s) or entity(ies) granting rights
113 | under this Public License.
114 |
115 | i. Share means to provide material to the public by any means or
116 | process that requires permission under the Licensed Rights, such
117 | as reproduction, public display, public performance, distribution,
118 | dissemination, communication, or importation, and to make material
119 | available to the public including in ways that members of the
120 | public may access the material from a place and at a time
121 | individually chosen by them.
122 |
123 | j. Sui Generis Database Rights means rights other than copyright
124 | resulting from Directive 96/9/EC of the European Parliament and of
125 | the Council of 11 March 1996 on the legal protection of databases,
126 | as amended and/or succeeded, as well as other essentially
127 | equivalent rights anywhere in the world.
128 |
129 | k. You means the individual or entity exercising the Licensed Rights
130 | under this Public License. Your has a corresponding meaning.
131 |
132 |
133 | Section 2 -- Scope.
134 |
135 | a. License grant.
136 |
137 | 1. Subject to the terms and conditions of this Public License,
138 | the Licensor hereby grants You a worldwide, royalty-free,
139 | non-sublicensable, non-exclusive, irrevocable license to
140 | exercise the Licensed Rights in the Licensed Material to:
141 |
142 | a. reproduce and Share the Licensed Material, in whole or
143 | in part; and
144 |
145 | b. produce, reproduce, and Share Adapted Material.
146 |
147 | 2. Exceptions and Limitations. For the avoidance of doubt, where
148 | Exceptions and Limitations apply to Your use, this Public
149 | License does not apply, and You do not need to comply with
150 | its terms and conditions.
151 |
152 | 3. Term. The term of this Public License is specified in Section
153 | 6(a).
154 |
155 | 4. Media and formats; technical modifications allowed. The
156 | Licensor authorizes You to exercise the Licensed Rights in
157 | all media and formats whether now known or hereafter created,
158 | and to make technical modifications necessary to do so. The
159 | Licensor waives and/or agrees not to assert any right or
160 | authority to forbid You from making technical modifications
161 | necessary to exercise the Licensed Rights, including
162 | technical modifications necessary to circumvent Effective
163 | Technological Measures. For purposes of this Public License,
164 | simply making modifications authorized by this Section 2(a)
165 | (4) never produces Adapted Material.
166 |
167 | 5. Downstream recipients.
168 |
169 | a. Offer from the Licensor -- Licensed Material. Every
170 | recipient of the Licensed Material automatically
171 | receives an offer from the Licensor to exercise the
172 | Licensed Rights under the terms and conditions of this
173 | Public License.
174 |
175 | b. No downstream restrictions. You may not offer or impose
176 | any additional or different terms or conditions on, or
177 | apply any Effective Technological Measures to, the
178 | Licensed Material if doing so restricts exercise of the
179 | Licensed Rights by any recipient of the Licensed
180 | Material.
181 |
182 | 6. No endorsement. Nothing in this Public License constitutes or
183 | may be construed as permission to assert or imply that You
184 | are, or that Your use of the Licensed Material is, connected
185 | with, or sponsored, endorsed, or granted official status by,
186 | the Licensor or others designated to receive attribution as
187 | provided in Section 3(a)(1)(A)(i).
188 |
189 | b. Other rights.
190 |
191 | 1. Moral rights, such as the right of integrity, are not
192 | licensed under this Public License, nor are publicity,
193 | privacy, and/or other similar personality rights; however, to
194 | the extent possible, the Licensor waives and/or agrees not to
195 | assert any such rights held by the Licensor to the limited
196 | extent necessary to allow You to exercise the Licensed
197 | Rights, but not otherwise.
198 |
199 | 2. Patent and trademark rights are not licensed under this
200 | Public License.
201 |
202 | 3. To the extent possible, the Licensor waives any right to
203 | collect royalties from You for the exercise of the Licensed
204 | Rights, whether directly or through a collecting society
205 | under any voluntary or waivable statutory or compulsory
206 | licensing scheme. In all other cases the Licensor expressly
207 | reserves any right to collect such royalties.
208 |
209 |
210 | Section 3 -- License Conditions.
211 |
212 | Your exercise of the Licensed Rights is expressly made subject to the
213 | following conditions.
214 |
215 | a. Attribution.
216 |
217 | 1. If You Share the Licensed Material (including in modified
218 | form), You must:
219 |
220 | a. retain the following if it is supplied by the Licensor
221 | with the Licensed Material:
222 |
223 | i. identification of the creator(s) of the Licensed
224 | Material and any others designated to receive
225 | attribution, in any reasonable manner requested by
226 | the Licensor (including by pseudonym if
227 | designated);
228 |
229 | ii. a copyright notice;
230 |
231 | iii. a notice that refers to this Public License;
232 |
233 | iv. a notice that refers to the disclaimer of
234 | warranties;
235 |
236 | v. a URI or hyperlink to the Licensed Material to the
237 | extent reasonably practicable;
238 |
239 | b. indicate if You modified the Licensed Material and
240 | retain an indication of any previous modifications; and
241 |
242 | c. indicate the Licensed Material is licensed under this
243 | Public License, and include the text of, or the URI or
244 | hyperlink to, this Public License.
245 |
246 | 2. You may satisfy the conditions in Section 3(a)(1) in any
247 | reasonable manner based on the medium, means, and context in
248 | which You Share the Licensed Material. For example, it may be
249 | reasonable to satisfy the conditions by providing a URI or
250 | hyperlink to a resource that includes the required
251 | information.
252 |
253 | 3. If requested by the Licensor, You must remove any of the
254 | information required by Section 3(a)(1)(A) to the extent
255 | reasonably practicable.
256 |
257 | 4. If You Share Adapted Material You produce, the Adapter's
258 | License You apply must not prevent recipients of the Adapted
259 | Material from complying with this Public License.
260 |
261 |
262 | Section 4 -- Sui Generis Database Rights.
263 |
264 | Where the Licensed Rights include Sui Generis Database Rights that
265 | apply to Your use of the Licensed Material:
266 |
267 | a. for the avoidance of doubt, Section 2(a)(1) grants You the right
268 | to extract, reuse, reproduce, and Share all or a substantial
269 | portion of the contents of the database;
270 |
271 | b. if You include all or a substantial portion of the database
272 | contents in a database in which You have Sui Generis Database
273 | Rights, then the database in which You have Sui Generis Database
274 | Rights (but not its individual contents) is Adapted Material; and
275 |
276 | c. You must comply with the conditions in Section 3(a) if You Share
277 | all or a substantial portion of the contents of the database.
278 |
279 | For the avoidance of doubt, this Section 4 supplements and does not
280 | replace Your obligations under this Public License where the Licensed
281 | Rights include other Copyright and Similar Rights.
282 |
283 |
284 | Section 5 -- Disclaimer of Warranties and Limitation of Liability.
285 |
286 | a. UNLESS OTHERWISE SEPARATELY UNDERTAKEN BY THE LICENSOR, TO THE
287 | EXTENT POSSIBLE, THE LICENSOR OFFERS THE LICENSED MATERIAL AS-IS
288 | AND AS-AVAILABLE, AND MAKES NO REPRESENTATIONS OR WARRANTIES OF
289 | ANY KIND CONCERNING THE LICENSED MATERIAL, WHETHER EXPRESS,
290 | IMPLIED, STATUTORY, OR OTHER. THIS INCLUDES, WITHOUT LIMITATION,
291 | WARRANTIES OF TITLE, MERCHANTABILITY, FITNESS FOR A PARTICULAR
292 | PURPOSE, NON-INFRINGEMENT, ABSENCE OF LATENT OR OTHER DEFECTS,
293 | ACCURACY, OR THE PRESENCE OR ABSENCE OF ERRORS, WHETHER OR NOT
294 | KNOWN OR DISCOVERABLE. WHERE DISCLAIMERS OF WARRANTIES ARE NOT
295 | ALLOWED IN FULL OR IN PART, THIS DISCLAIMER MAY NOT APPLY TO YOU.
296 |
297 | b. TO THE EXTENT POSSIBLE, IN NO EVENT WILL THE LICENSOR BE LIABLE
298 | TO YOU ON ANY LEGAL THEORY (INCLUDING, WITHOUT LIMITATION,
299 | NEGLIGENCE) OR OTHERWISE FOR ANY DIRECT, SPECIAL, INDIRECT,
300 | INCIDENTAL, CONSEQUENTIAL, PUNITIVE, EXEMPLARY, OR OTHER LOSSES,
301 | COSTS, EXPENSES, OR DAMAGES ARISING OUT OF THIS PUBLIC LICENSE OR
302 | USE OF THE LICENSED MATERIAL, EVEN IF THE LICENSOR HAS BEEN
303 | ADVISED OF THE POSSIBILITY OF SUCH LOSSES, COSTS, EXPENSES, OR
304 | DAMAGES. WHERE A LIMITATION OF LIABILITY IS NOT ALLOWED IN FULL OR
305 | IN PART, THIS LIMITATION MAY NOT APPLY TO YOU.
306 |
307 | c. The disclaimer of warranties and limitation of liability provided
308 | above shall be interpreted in a manner that, to the extent
309 | possible, most closely approximates an absolute disclaimer and
310 | waiver of all liability.
311 |
312 |
313 | Section 6 -- Term and Termination.
314 |
315 | a. This Public License applies for the term of the Copyright and
316 | Similar Rights licensed here. However, if You fail to comply with
317 | this Public License, then Your rights under this Public License
318 | terminate automatically.
319 |
320 | b. Where Your right to use the Licensed Material has terminated under
321 | Section 6(a), it reinstates:
322 |
323 | 1. automatically as of the date the violation is cured, provided
324 | it is cured within 30 days of Your discovery of the
325 | violation; or
326 |
327 | 2. upon express reinstatement by the Licensor.
328 |
329 | For the avoidance of doubt, this Section 6(b) does not affect any
330 | right the Licensor may have to seek remedies for Your violations
331 | of this Public License.
332 |
333 | c. For the avoidance of doubt, the Licensor may also offer the
334 | Licensed Material under separate terms or conditions or stop
335 | distributing the Licensed Material at any time; however, doing so
336 | will not terminate this Public License.
337 |
338 | d. Sections 1, 5, 6, 7, and 8 survive termination of this Public
339 | License.
340 |
341 |
342 | Section 7 -- Other Terms and Conditions.
343 |
344 | a. The Licensor shall not be bound by any additional or different
345 | terms or conditions communicated by You unless expressly agreed.
346 |
347 | b. Any arrangements, understandings, or agreements regarding the
348 | Licensed Material not stated herein are separate from and
349 | independent of the terms and conditions of this Public License.
350 |
351 |
352 | Section 8 -- Interpretation.
353 |
354 | a. For the avoidance of doubt, this Public License does not, and
355 | shall not be interpreted to, reduce, limit, restrict, or impose
356 | conditions on any use of the Licensed Material that could lawfully
357 | be made without permission under this Public License.
358 |
359 | b. To the extent possible, if any provision of this Public License is
360 | deemed unenforceable, it shall be automatically reformed to the
361 | minimum extent necessary to make it enforceable. If the provision
362 | cannot be reformed, it shall be severed from this Public License
363 | without affecting the enforceability of the remaining terms and
364 | conditions.
365 |
366 | c. No term or condition of this Public License will be waived and no
367 | failure to comply consented to unless expressly agreed to by the
368 | Licensor.
369 |
370 | d. Nothing in this Public License constitutes or may be interpreted
371 | as a limitation upon, or waiver of, any privileges and immunities
372 | that apply to the Licensor or You, including from the legal
373 | processes of any jurisdiction or authority.
374 |
375 |
376 | =======================================================================
377 |
378 | Creative Commons is not a party to its public licenses.
379 | Notwithstanding, Creative Commons may elect to apply one of its public
380 | licenses to material it publishes and in those instances will be
381 | considered the “Licensor.” The text of the Creative Commons public
382 | licenses is dedicated to the public domain under the CC0 Public Domain
383 | Dedication. Except for the limited purpose of indicating that material
384 | is shared under a Creative Commons public license or as otherwise
385 | permitted by the Creative Commons policies published at
386 | creativecommons.org/policies, Creative Commons does not authorize the
387 | use of the trademark "Creative Commons" or any other trademark or logo
388 | of Creative Commons without its prior written consent including,
389 | without limitation, in connection with any unauthorized modifications
390 | to any of its public licenses or any other arrangements,
391 | understandings, or agreements concerning use of licensed material. For
392 | the avoidance of doubt, this paragraph does not form part of the public
393 | licenses.
394 |
395 | Creative Commons may be contacted at creativecommons.org.
--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
1 |
17 |
18 | # SaaS attack techniques
19 |
20 | This repository is a collection of SaaS-specific attack techniques. It is intended to be a resource for security researchers, red/blue teams, and penetration testers to learn about and share SaaS attack techniques.
21 |
22 | > Quick note: we wanted to start sharing as early as possible, so this is very much a work in progress. Hopefully there is enough to see the shape of things to come, but no doubt there are gaps - we'll be filling them in over the coming weeks and months. If you can help fill in some references, add examples, or point us to missing techniques - please open an issue (or even a PR)! We'll be very sure to credit you.
23 |
24 | For more information on the background to this project, check the following [blog post](https://pushsecurity.com/blog/saas-attack-techniques/)
25 |
26 | The Microsoft BlueHat 2023 "The new SaaS cyber kill chain" presentation that covers a lot of this research can be found below:
27 |
28 | [BlueHat - The new SaaS cyber kill chain](https://www.youtube.com/watch?v=pdDzUTFVIZc)
29 |
30 | For a podcast covering this topic, checkout the DCP Podcast by SpectreOps below:
31 |
32 | [DCP Podcast - Episode 35](https://www.youtube.com/watch?v=NAOE875gAOg)
33 |
34 | ## The SaaS attacks matrix
35 |
36 | We’ve taken inspiration from the MITRE ATT&CK framework (certainly intended as the sincerest form of flattery), but wanted to make a conscious break away from the endpoint-focused ATT&CK techniques and instead focus on techniques that are SaaS-first. In fact, none of these techniques touch endpoints or customer networks - so we’re calling them networkless attacks.
37 |
38 | | Reconnaissance | Initial Access | Execution | Persistence | Privilege Escalation | Defense Evasion | Credential Access | Discovery | Lateral Movement | Exfiltration |
39 | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
40 | |[SAML enumeration](techniques/saml_enumeration/description.md)|[Consent phishing](techniques/consent_phishing/description.md)|[Shadow workflows](techniques/shadow_workflows/description.md)|[API keys](techniques/api_keys/description.md)|[Link backdooring](techniques/link_backdooring/description.md)|[API keys](techniques/api_keys/description.md)|[Password scraping](techniques/password_scraping/description.md)|[Email discovery](techniques/email_discovery/description.md)|[Link backdooring](techniques/link_backdooring/description.md)|[Takeout services](techniques/takeout_services/description.md)|
41 | |[Subdomain tenant discovery](techniques/subdomain_tenant_discovery/description.md)|[Poisoned tenants](techniques/poisoned_tenants/description.md)|[OAuth tokens](techniques/oauth_tokens/description.md)|[OAuth tokens](techniques/oauth_tokens/description.md)|[Abuse existing OAuth integrations](techniques/abuse_existing_oauth_integrations/description.md)|[OAuth tokens](techniques/oauth_tokens/description.md)|[API secret theft](techniques/api_secret_theft/description.md)|[App directory lookup](techniques/app_directory_lookup/description.md)|[Abuse existing OAuth integrations](techniques/abuse_existing_oauth_integrations/description.md)|[Webhooks](techniques/webhooks/description.md)|
42 | |[Slug tenant enumeration](techniques/slug_tenant_enumeration/description.md)|[SAMLjacking](techniques/samljacking/description.md)|[Client-side app spoofing](techniques/client-side_app_spoofing/description.md)|[Evil twin integrations](techniques/evil_twin_integrations/description.md)|[Malicious mail rules](techniques/malicious_mail_rules/description.md)|[Evil twin integrations](techniques/evil_twin_integrations/description.md)||[OAuth token enumeration](techniques/oauth_token_enumeration/description.md)|[API secret theft](techniques/api_secret_theft/description.md)|[Shadow workflows](techniques/shadow_workflows/description.md)|
43 | |[DNS reconnaissance](techniques/dns_reconnaissance/description.md)|[Account ambushing](techniques/account_ambushing/description.md)||[Malicious mail rules](techniques/malicious_mail_rules/description.md)||[Malicious mail rules](techniques/malicious_mail_rules/description.md)|||[Passwordless logins](techniques/passwordless_logins/description.md)|
44 | |[Username enumeration](techniques/username_enumeration/description.md)|[Credential stuffing](techniques/credential_stuffing/description.md)||[Link sharing](techniques/link_sharing/description.md)||[Link sharing](techniques/link_sharing/description.md)|||[Account recovery](techniques/account_recovery/description.md)||
45 | ||[App spraying](techniques/app_spraying/description.md)||[System integrations](techniques/system_integrations/description.md)||[System integrations](techniques/system_integrations/description.md)|||[In-app phishing](techniques/in-app_phishing/description.md)||
46 | ||[Email phishing](techniques/email_phishing/description.md)||[Ghost logins](techniques/ghost_logins/description.md)||[Ghost logins](techniques/ghost_logins/description.md)|||[IM user spoofing](techniques/im_user_spoofing/description.md)||
47 | ||[IM phishing](techniques/im_phishing/description.md)||[Client-side app spoofing](techniques/client-side_app_spoofing/description.md)||[Client-side app spoofing](techniques/client-side_app_spoofing/description.md)|||[Automation workflow sharing](techniques/automation_workflow_sharing/description.md)||
48 | ||[IM user spoofing](techniques/im_user_spoofing/description.md)||[Inbound federation](techniques/inbound_federation/description.md)||[Device code phishing](techniques/device_code_phishing/description.md)|||[SAMLjacking](techniques/samljacking/description.md)||
49 | ||[nOAuth](techniques/noauth/description.md)||[Device enrollment](techniques/device_enrollment/description.md)||[Session cookie theft](techniques/session_cookie_theft/description.md)|||[Inbound federation](techniques/inbound_federation/description.md)||
50 | ||[MFA fatigue](techniques/mfa_fatigue/description.md)||[Cross-idp impersonation](techniques/cross-idp_impersonation/description.md)|||||[Session cookie theft](techniques/session_cookie_theft/description.md)||
51 | ||[Device code phishing](techniques/device_code_phishing/description.md)|||||||||
52 | ||[Hijack OAuth flows](techniques/hijack_oauth_flows/description.md)|||||||||
53 | ||[AiTM Phishing](techniques/aitm_phishing/description.md)|||||||||
54 | ||[Device enrollment](techniques/device_enrollment/description.md)|||||||||
55 | ||[Ghost logins](techniques/ghost_logins/description.md)|||||||||
56 | ||[MFA downgrade](techniques/mfa_downgrade/description.md)|||||||||
57 | ||[Guest access abuse](techniques/guest_access_abuse/description.md)|||||||||
58 | ||[Cross-idp impersonation](techniques/cross-idp_impersonation/description.md)|||||||||
59 | ||[Verification phishing](techniques/verification_phishing/description.md)|||||||||
60 | ||[UI redressing](techniques/ui_redressing/description.md)|||||||||
61 |
62 |
63 | Another divergence from the ATT&CK framework is that these techniques are not solely based on observation. Instead, we’re allowing more exploratory techniques that haven't been seen in the wild. We think this is important because SaaS is a relatively new attack surface, and we want to encourage security researchers to think creatively about how SaaS can be abused to better anticipate future attacks.
64 |
65 | We’ve also removed a few columns that are common in these MITRE-style frameworks, some (like Impact) are so similar they aren't worth duplicating. Others (perhaps most notably the Command & Control phase) because they no longer apply. Since SaaS is delivered directly on the internet, you can’t force an attacker to access it through your web gateway. You can try forcing your own employees through a gateway, but attackers can access it directly like everyone else (there are edge cases here, but they are rare). This means there is generally no need for C2 techniques.
66 |
67 | Finally, some need a slightly broader definition. For example, the Execution phase includes techniques that are not strictly code execution on an endpoint, but achieve an equivalent outcome in the SaaS context.
68 |
69 | ## Scope
70 |
71 | When we started this research project, the first task was to choose an initial scope. Like every good red-teamer, we wanted to start with low-cost techniques, so that means we were looking for techniques that:
72 | * Avoid highly effective controls that are expensive to bypass, especially endpoint controls like EDR - so endpoint malware-based techniques are out
73 | * Look for features that can be abused long-term, rather than bugs that will be patched quickly - so no zero-days
74 | * Go beyond the dozen or so core SaaS apps like O365 and Google Workspace - look to the hundreds of other apps that have primitive security controls and store or have access to highly sensitive data
75 |
76 | While we left out techniques that are endpoint-based attacks that lead to a SaaS compromise (MITRE does a good job of these techniques) we think that it makes sense to add techniques to go from SaaS to the endpoint might make sense to add here. We're still thinking about this, but we'd love to hear your thoughts.
77 |
--------------------------------------------------------------------------------
/techniques/abuse_existing_oauth_integrations/description.md:
--------------------------------------------------------------------------------
1 | # Abuse existing OAuth integrations
2 |
3 | ID: SAT1001
4 |
5 | ## Tactics
6 | * Privilege Escalation
7 | * Lateral Movement
8 |
9 | ## Summary
10 | Some SaaS apps allow OAuth integrations to other apps, which allow the app to gain access to certain data and additional functionality. If an adversary compromises an SaaS account integrated with other apps, they can escalate privileges and move laterally to other apps.
11 |
12 | To abuse apps with existing integrations, that app must expose some usable functionality though the integration back to the user. As an example, an integration with email access scopes, but which does not actually display emails to the user (of the integration) is not very useful to the adversary.
13 |
14 | The challenge then is to identify apps that an employee is using that are both likely to have existing integrations, and expose offensively useful functionality through those integrations. Typical apps that fit this bill are workflow automation apps (see [Shadow automations]) which provide highly flexible integrations. Many sales and marketing apps that integrate with email would grant an adversary effective “webmail” access to integrated mailboxes.
15 |
16 |
17 | ## Examples
18 | * [Zapier](examples/zapier.md)
19 |
20 | ## References
--------------------------------------------------------------------------------
/techniques/abuse_existing_oauth_integrations/examples/zapier.md:
--------------------------------------------------------------------------------
1 | # Abusing exisitng [Zapier](https://zapier.com) OAuth integrations
2 |
3 | In the example below, a Zapier user has set up connections to Google Drive, Microsoft Outlook and Slack. An adversary gaining control of this Zapier account could gain access to data in these apps using these integrations.
4 |
5 | Given the power and flexibility of an app like Zapier, this would allow almost total control of these accounts. For example, it would be possible to continuously read/write files from Google Drive at will, send/receive/modify email in Microsoft Outlook and read and send Slack messages as the user.
6 |
7 | 
--------------------------------------------------------------------------------
/techniques/abuse_existing_oauth_integrations/examples/zapier_integrations.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/abuse_existing_oauth_integrations/examples/zapier_integrations.png
--------------------------------------------------------------------------------
/techniques/account_ambushing/description.md:
--------------------------------------------------------------------------------
1 | # Account ambushing
2 | ID: SAT1002
3 |
4 | ## Tactics
5 | * Initial Access
6 |
7 | ## Summary
8 | Many SaaS apps have features that can be used to effectively backdoor an account, such as the ability to configure multiple login methods or create API keys to access the account programmatically. This makes it possible for an adversary to backdoor user accounts before they are first used by the legitimate user.
9 |
10 | As some apps do not perform email verification during registration, it is often possible for an adversary to sign up for accounts using the potential target user’s email address.
11 |
12 | When the real user attempts to sign up for the app, it will usually produce an error saying the account is already registered and prompt them to recover the account.
13 |
14 | In such cases, the only way for the user to gain access to the app is to perform a password reset. If they do not discover the backdoor methods used by the adversary then the adversary will maintain access to their account and any sensitive data added to the app going forward.
15 |
16 | ## Examples
17 | * [IFTTT](examples/ifttt.md)
18 |
19 | ## References
--------------------------------------------------------------------------------
/techniques/account_ambushing/examples/ifttt.md:
--------------------------------------------------------------------------------
1 | # Account ambushing on IFTTT
2 |
3 | A user can sign up using any email address and then link Apple, Facebook, and Google social accounts to the account to backdoor access. If the real owner of the email address attempts to register, they will be forced to perform a password reset to gain access, but the app will not unlink the social accounts linked previously.
4 |
5 | The process resembles the following:
6 | 1. Register an account for victim@target.com using a password login
7 | 1. Link the account to an Apple or Facebook account
8 | 1. Target attempts sign up and is forced to reset their password in order to gain access
9 | 1. Target begins using account, configures connections to other apps
10 | 1. Adversary authenticates to the target’s account using the Apple or Facebook account
11 |
12 | 
--------------------------------------------------------------------------------
/techniques/account_ambushing/examples/ifttt.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/account_ambushing/examples/ifttt.png
--------------------------------------------------------------------------------
/techniques/account_recovery/description.md:
--------------------------------------------------------------------------------
1 | # Account recovery
2 | ID: SAT1003
3 |
4 | ## Tactics
5 | * Lateral Movement
6 |
7 | ## Summary
8 | Most SaaS apps allow accounts to be recovered via email. This can be through the use of forgotten password functionality via the directly registered email address or via a secondary recovery email address.
9 |
10 | This presents an opportunity for an adversary to laterally move to other SaaS apps if they have gained access to a user’s mailbox and then triggering an account recovery process.
11 |
12 | While this may alert the user through the appearance of password reset emails, a variety of other techniques, such as mail rules or automations, can be used to capture the emails. The adversary can then delete emails automatically before the user sees them.
13 |
14 | ## Examples
15 | * [IFTTT](examples/ifttt.md)
16 |
17 | ## References
--------------------------------------------------------------------------------
/techniques/account_recovery/examples/ifttt.md:
--------------------------------------------------------------------------------
1 | # IFTTT
2 |
3 | The example below shows how to abuse password reset functionality via email for the automation app IFTTT.
4 |
5 | 
6 | 
7 |
--------------------------------------------------------------------------------
/techniques/account_recovery/examples/ifttt_1.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/account_recovery/examples/ifttt_1.png
--------------------------------------------------------------------------------
/techniques/account_recovery/examples/ifttt_2.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/account_recovery/examples/ifttt_2.png
--------------------------------------------------------------------------------
/techniques/aitm_phishing/description.md:
--------------------------------------------------------------------------------
1 | # AiTM Phishing
2 | ID: SAT1042
3 |
4 | ## Tactics
5 | * Initial Access
6 |
7 | ## Summary
8 | Attacker-in-the-Middle (AITM) phishing is a newer variant of phishing that uses dedicated tooling to act as a web proxy between the victim and a legitimate login portal for an application the victim has access to, principally to make it easier to defeat MFA protection.
9 |
10 | As MFA has become more universal, classic password harvesting focused phishing attacks have reduced in effectiveness. Typically, for a full account compromise an MFA push notification or a one-time-passcode (OTP) needs to be entered at the time of login.
11 |
12 | AITM phishing solves this issue by proxying in real-time to the target login portal, making use of entered OTP codes or accepted MFA push notifications to achieve a full authenticated session. This leaves the adversary with access to both a valid password and valid session cookies they can steal and use to hijack the session.
13 |
14 | Additional benefits are that it is relatively quick and easy to target a new application and, once logged-in, a victim user will see all the real data they would expect to see ordinarily (e.g. their own emails/files etc) as it is a proxy of the real application. This reduces their chances of realizing they have been compromised due to the authentic working nature of the proxied application.
15 |
16 | Typical techniques to implement this involve either transparent web proxy techniques that seek to present the application with no noticeable changes (e.g. Evilginx2), or the use of desktop-control techniques to have the victim unknowingly interact with an attacker’s own browser instance (e.g. noVNC based techniques).
17 |
18 | ## Examples
19 |
20 | ## References
21 | * [Evilginx - AITM web proxy](https://github.com/kgretzky/evilginx2)
22 | * [EvilnoVNC - AITM noVNC proxy](https://github.com/JoelGMSec/EvilnoVNC)
23 | * [Modlishka- AITM web proxy](https://github.com/drk1wi/Modlishka)
24 | * [Muraena - AITM web proxy](https://github.com/muraenateam/muraena)
25 | * [NoPhish - AITM noVNC proxy](https://github.com/powerseb/NoPhish)
--------------------------------------------------------------------------------
/techniques/api_keys/description.md:
--------------------------------------------------------------------------------
1 | # API keys
2 | ID: SAT1004
3 |
4 | ## Tactics
5 | * Persistence
6 | * Defense Evasion
7 |
8 | ## Summary
9 | Many SaaS apps let you configure an API key to enable programmatic access. These keys generally do not expire, are not affected by password resets, are not covered by MFA, and are often not even tied to user accounts. As such, they’re an ideal persistence mechanism as they survive the deletion of a compromised account. API actions are also often logged differently to normal user access, which makes them useful for evading monitoring of sensitive actions.
10 |
11 | An adversary that has compromised an account could then read existing API keys from the app settings, if the app allows this, or create a new API key.
12 |
13 | ## Examples
14 | * [Shortcut](examples/shortcut.md)
15 |
16 | ## References
--------------------------------------------------------------------------------
/techniques/api_keys/examples/shortcut.md:
--------------------------------------------------------------------------------
1 | # Creating an API key in Shortcut
2 |
3 | Shortcut, like many SaaS apps, has an API that allows doing almost everything a user can do through the UI. A screenshot below shows how to create an API key:
4 |
5 | 
--------------------------------------------------------------------------------
/techniques/api_keys/examples/shortcut.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/api_keys/examples/shortcut.png
--------------------------------------------------------------------------------
/techniques/api_secret_theft/description.md:
--------------------------------------------------------------------------------
1 | # API secret theft
2 | ID: SAT1005
3 |
4 | ## Tactics
5 | * Credential Access
6 | * Lateral Movement
7 |
8 | ## Summary
9 | Apps that support integrations through API keys (rather than the more common OAuth integrations) will sometimes allow those keys to be read after being set. Adversaries who gain access to apps where these integrations have been created can extract these secrets and use them to laterally move to different apps or contexts.
10 |
11 | In apps that don’t explicitly make these secrets readable to the user, it might be possible to leak them out of the application. This is a typical scenario for build automation or CI/CD apps where build and deployment secrets are often exposed in clear-text inside the build environment.
12 |
13 |
14 | ## Examples
15 | * [Postman](examples/postman.md)
16 |
17 | ## References
18 | * [MITRE ATT&CK - Steal Application Access Token](https://attack.mitre.org/techniques/T1528/)
19 |
--------------------------------------------------------------------------------
/techniques/api_secret_theft/examples/postman.md:
--------------------------------------------------------------------------------
1 | # Postman
2 |
3 | Postman is a great example of an app that stores API secrets for other apps. While it does have functionality and guidance for how to securely manage secrets, it is very common for API secrets to end up embedded directly into API requests or persisted (intentionally or accidentally) via the built-in Postman functionality for managing variables.
4 |
5 | An insecurely stored API call may look something like the following, where the API key has been embedded directly into the request:
6 |
7 | ```
8 | GET /api-call/method1?api_key=mysecretapikeyhere
9 | ```
10 |
11 | On the other hand, the secure way to manage secrets is to use variables with initial and current values, where the initial value is not sensitive. However, if a real API secret is stored in an initial value, the secrets are accessible to an adversary with Postman access.
12 |
13 | 
14 | 
15 |
--------------------------------------------------------------------------------
/techniques/api_secret_theft/examples/postman_1.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/api_secret_theft/examples/postman_1.png
--------------------------------------------------------------------------------
/techniques/api_secret_theft/examples/postman_2.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/api_secret_theft/examples/postman_2.png
--------------------------------------------------------------------------------
/techniques/app_directory_lookup/description.md:
--------------------------------------------------------------------------------
1 | # App directory lookup
2 | ID: SAT1006
3 | ## Tactics
4 | * Discovery
5 |
6 | ## Summary
7 | SaaS apps will generally have a user directory and often this is visible to any user of the app. It may be a direct list of all users of the app or a result of visible group memberships or similar.
8 |
9 | An adversary who has gained a foothold via a SaaS app could download the list of users accessible to them in order to better target attacks against other users. Commonly, usernames or emails for users will be identical on other SaaS apps, potentially helping target users of those apps.
10 |
11 | ## Examples
12 | * [Shortcut](examples/shortcut.md)
13 |
14 | ## References
15 | * [MITRE ATT&CK - Account Discovery](https://attack.mitre.org/techniques/T1087/)
16 |
--------------------------------------------------------------------------------
/techniques/app_directory_lookup/examples/shortcut.md:
--------------------------------------------------------------------------------
1 | # App directory lookup in [shortcut](https://shortcut.com)
2 |
3 | Shortcut is a typical example of a SaaS app that allows non-admin users to view the actual user directory:
4 |
5 | 
--------------------------------------------------------------------------------
/techniques/app_directory_lookup/examples/shortcut.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/app_directory_lookup/examples/shortcut.png
--------------------------------------------------------------------------------
/techniques/app_spraying/description.md:
--------------------------------------------------------------------------------
1 | # App spraying
2 | ID: SAT1007
3 |
4 | ## Tactics
5 | * Initial Access
6 |
7 | ## Summary
8 |
9 | An adversary may attempt to authenticate to a SaaS account by guessing a large number of passwords. However, many apps limit the rate or number of passwords that can be guessed. If you assume a user shares passwords between SaaS apps, the set of passwords to be guessed can be split between all the apps the user has accounts for, circumventing the rate-limits on any one SaaS app.
10 |
11 | This can be particularly effective against heavy SaaS users as it allows an adversary to spread the attack across a large number of SaaS apps.
12 |
13 | ## Examples
14 |
15 | ## References
--------------------------------------------------------------------------------
/techniques/automation_workflow_sharing/description.md:
--------------------------------------------------------------------------------
1 | # Automation workflow sharing
2 | ID: SAT1008
3 |
4 | ## Tactics
5 | * Execution
6 | * Lateral Movement
7 |
8 | ## Summary
9 | Some SaaS automation apps allow pre-configured automations to be shared with other users. These can sometimes be shared directly within the app with other app users.
10 |
11 | Since automations are incredibly powerful, it is possible for an adversary to create an automation that is designed to appear safe but to backdoor it in a way that performs a malicious action on behalf of the target user. If a user does not inspect the configuration of the automation at all, the automation can be more overtly malicious.
12 |
13 | However, by making complicated multi-step automations and making use of built-in logging functionality, it is possible to make automations that can easily pass a cursory examination, while still achieving the adversary’s goals.
14 |
15 | This is the SaaS equivalent of convincing a user to open a malicious attachment or run an executable file.
16 |
17 | ## Examples
18 | * [Microsoft Power Automate](examples/microsoft_power_automate.md)
19 |
20 | ## References
--------------------------------------------------------------------------------
/techniques/automation_workflow_sharing/examples/microsoft_power_automate.md:
--------------------------------------------------------------------------------
1 | # Microsoft Power Automate
2 |
3 | Microsoft Power Automate is a great example of this as it has functionality to “Send a copy” of an automated flow. This is only permitted for other users in your tenant, so it requires a foothold into the environment first.
4 |
5 | However, the example below demonstrates creating an automation that replicates malicious mail rule functionality. The automation forwards emails to an external address and then deletes the emails under certain conditions e.g. security alerts/password resets.
6 |
7 | 
8 |
9 | Sending this to another user results in an email being sent to that user by the Microsoft Power Automate app. If they are already a user then it is one click from the email and one more click to create the flow and then it is operating. If they aren’t already a user and do not have an outlook connection setup then it will prompt them to click to sign-in to create the connection first and then will create the flow.
10 |
11 | 
12 | 
13 | 
14 | 
15 | 
16 | 
17 |
--------------------------------------------------------------------------------
/techniques/automation_workflow_sharing/examples/microsoft_power_automate_1.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/automation_workflow_sharing/examples/microsoft_power_automate_1.png
--------------------------------------------------------------------------------
/techniques/automation_workflow_sharing/examples/microsoft_power_automate_2.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/automation_workflow_sharing/examples/microsoft_power_automate_2.png
--------------------------------------------------------------------------------
/techniques/automation_workflow_sharing/examples/microsoft_power_automate_3.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/automation_workflow_sharing/examples/microsoft_power_automate_3.png
--------------------------------------------------------------------------------
/techniques/automation_workflow_sharing/examples/microsoft_power_automate_4.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/automation_workflow_sharing/examples/microsoft_power_automate_4.png
--------------------------------------------------------------------------------
/techniques/automation_workflow_sharing/examples/microsoft_power_automate_5.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/automation_workflow_sharing/examples/microsoft_power_automate_5.png
--------------------------------------------------------------------------------
/techniques/automation_workflow_sharing/examples/microsoft_power_automate_6.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/automation_workflow_sharing/examples/microsoft_power_automate_6.png
--------------------------------------------------------------------------------
/techniques/automation_workflow_sharing/examples/microsoft_power_automate_7.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/automation_workflow_sharing/examples/microsoft_power_automate_7.png
--------------------------------------------------------------------------------
/techniques/client-side_app_spoofing/description.md:
--------------------------------------------------------------------------------
1 | # Client-side app spoofing
2 | ID: SAT1009
3 |
4 | ## Tactics
5 | * Execution
6 | * Persistence
7 | * Defense Evasion
8 |
9 | ## Summary
10 | Some OAuth integrations intended for use by desktop or mobile clients (rather than typical SaaS-to-SaaS integrations) can be controlled by adversaries. These client integrations tend to either make use of the [public client type](https://oauth.net/2/client-types/) for OAuth (the correct intended flow for this scenario), or the client secret for the OAuth app is directly embedded in the code, which is not considered good security practice and can be extracted by an adversary.
11 |
12 | While an adversary will generally not be able to control the reply/callback URLs to utilize these legitimate integrations in a consent phishing attack, they can perform localhost callbacks to manually consent to permissions themselves for accounts they have already compromised. This is sufficient to conduct a persistence attack to maintain long-term control of the user account, leaving the adversary with tokens they can use to maintain access.
13 |
14 | The adversary can customize the level of access they would like to maintain by requesting more permissions than would be usually used for the integration.
15 |
16 | This technique has the added benefit of appearing more legitimate as the OAuth integration itself will be one known to be associated with a legitimate client of some kind. If the target user already uses the client in question, it will be even more stealthy as the OAuth integration already exists - effectively an [evil twin integration](../evil_twin_integrations/description.md).
17 |
18 | ## Examples
19 | * [Thunderbird](examples/thunderbird.md)
20 | * [GitHub VSCode extension](examples/github_vscode.md)
21 |
22 | ## References
23 |
24 | * [Maintaining persistent access in a SaaS-first world](https://pushsecurity.com/blog/maintaining-persistent-access-in-a-saas-first-world)
--------------------------------------------------------------------------------
/techniques/client-side_app_spoofing/examples/github_vscode.md:
--------------------------------------------------------------------------------
1 | # Spoofing GitHub VSCode extension
2 |
3 | GitHub is another great example of a SaaS app that allows for spoofing of legitimate OAuth apps for persistence. Another interesting aspect of GitHub is that sometimes organizations will accept personal developer GitHub accounts into organizations and that this can introduce issues where persistence has been achieved on a personal account that later gains access to private repositories in a GitHub organization. Even if the organization enforces a password change and a new MFA mechanism as part of admittance, OAuth persistence mechanisms can still potentially enable access to the organization repositories to be inherited by attackers who have compromised the account previously.
4 |
5 | There are many GitHub apps available but VSCode extensions are one very common example. In fact, the very widely used "GitHub Pull Requests and Issues" extension for VSCode makes use of legacy OAuth access via GitHub instead of the newer GitHub applications mechanism. This is much better for persistence from an attacker’s perspective because up to ten tokens can be valid at the same time before they rotate and tokens last for a minimum of a year without activity. This is documented in GitHub docs:
6 |
7 | https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/authorizing-oauth-apps#creating-multiple-tokens-for-oauth-apps
8 | https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/token-expiration-and-revocation#token-expired-due-to-lack-of-use
9 |
10 | For example, if an attacker has gained (temporary) access to a GitHub account then they could impersonate this extension to gain persistence. We’ll show this from the perspective of an attacker using their own VSCode instance below to add the extension but using burp to intercept the requests so we can also get access to the raw tokens in order to make custom API calls in future.
11 |
12 | 
13 |
14 | *Installing the popular GitHub Pull Requests and Issues extensions*
15 |
16 | 
17 |
18 | *Authorizing the GitHub app for this extension to achieve persistence*
19 |
20 | 
21 |
22 | *Capturing the client ID, client secret and access token using Burp*
23 |
24 | We can see from the requests made that the extension makes use of an embedded client secret as well, so we could actually authorize this app without making use of VSCode but for simplicity we’ve shown it from the perspective of the attacker using their own VSCode instance here. In the response we get the access token and then we can either make use of the embedded functionality within the extension in VSCode for ease, or we can use this token to make custom API calls as shown below:
25 |
26 | ```
27 | luke@Lukes-MacBook-Pro % curl -H "Authorization: token gho_Iw33" https://api.github.com/repos/ctrlaltsecure-lab/test/commits
28 | [
29 | {
30 | "sha": "0d86e380d86c02776dc67b4e9a426247210b4f4e",
31 | "node_id": "C_kwDOKWiQ_doAKDBkODZlMzgwZDg2YzAyNzc2ZGM2N2I0ZTlhNDI2MjQ3MjEwYjRmNGU",
32 | "commit": {
33 | "author": {
34 | "name": "Luke Jennings",
35 | "email": "luke-low-priv@ctrlaltsecure.com",
36 | "date": "2023-09-26T14:50:20Z"
37 | },
38 | "committer": {
39 | "name": "Luke Jennings",
40 | "email": "luke-low-priv@ctrlaltsecure.com",
41 | "date": "2023-09-26T14:50:20Z"
42 | },
43 | "message": "test",
44 | "tree": {
45 | "sha": "55994856502256b29e955aaabfc28b4fe1c92820",
46 | "url": "https://api.github.com/repos/ctrlaltsecure-lab/test/git/trees/55994856502256b29e955aaabfc28b4fe1c92820"
47 | },
48 | ```
49 |
50 | If the victim does not use the VSCode extension then they may see that a new application has appeared on their account which is suspicious, though it'll still show as a legitimate and common extension at least. However, this is an especially stealthy technique if the target user is already using this extension as it then effectively operates as an [evil twin integration](/techniques/evil_twin_integrations/description.md).
51 |
52 | In this case, the application would already be there from their own legitimate use and there is no way to list the different tokens that are valid for the application. The only way to see there have been multiple tokens created would be to check the security logs. However, new tokens can be created during normal activity where new permissions are requested as a result of extension use and so even that is not that unusual to see.
53 |
54 | We can see the result of this below. In this case, there are now effectively two valid tokens for GitHub for VSCode, one from the legitimate VSCode instance the victim was using and another that we just created as the attacker after an account compromise. However, only one app is listed and it's not possible to see the two different tokens. Revoking the entire app itself, and thus revoking the legitimate user's token too, is the only method to remove the persistence mechanism:
55 |
56 | 
57 |
--------------------------------------------------------------------------------
/techniques/client-side_app_spoofing/examples/github_vscode1.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/client-side_app_spoofing/examples/github_vscode1.png
--------------------------------------------------------------------------------
/techniques/client-side_app_spoofing/examples/github_vscode2.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/client-side_app_spoofing/examples/github_vscode2.png
--------------------------------------------------------------------------------
/techniques/client-side_app_spoofing/examples/github_vscode3.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/client-side_app_spoofing/examples/github_vscode3.png
--------------------------------------------------------------------------------
/techniques/client-side_app_spoofing/examples/github_vscode4.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/client-side_app_spoofing/examples/github_vscode4.png
--------------------------------------------------------------------------------
/techniques/client-side_app_spoofing/examples/thunderbird.md:
--------------------------------------------------------------------------------
1 | # Spoofing thunderbird desktop client
2 |
3 | There are many examples of this as it applies to a whole class of OAuth authentication. One example would be Mozilla Thunderbird, a cross-platform email client. In this case, Thunderbird uses an embedded client secret for its OAuth integration. An adversary can reuse this for persistence, and even request access to a number of additional permissions (for example file access) beyond typical email and calendar access, as shown below:
4 |
5 | 
--------------------------------------------------------------------------------
/techniques/client-side_app_spoofing/examples/thunderbird.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/client-side_app_spoofing/examples/thunderbird.png
--------------------------------------------------------------------------------
/techniques/consent_phishing/description.md:
--------------------------------------------------------------------------------
1 | # Consent phishing
2 | ID: SAT1010
3 |
4 | ## Tactics
5 | * Initial Access
6 |
7 | ## Summary
8 |
9 | OAuth allows users to grant third-party apps permissions to access their data. Adversaries can abuse this functionality by tricking users into authorizing access for malicious OAuth apps.
10 |
11 | In a consent phishing attack, an adversary sends a phishing link to a target that requests permissions to access sensitive data or permissions to perform dangerous actions. If the target grants consent for the permissions, the adversary gains that level of access over the target’s account. This level of access will bypass MFA and persist through password changes.
12 |
13 | Consent phishing is most commonly associated with attacks aimed at getting access to Microsoft Azure or Google Workspace tenants. However, it has become more common for SaaS apps to implement their own OAuth-authenticated APIs and app stores that can be targeted in the same way.
14 |
15 |
16 | ## Examples
17 | * [Microsoft](examples/microsoft.md)
18 | * [GitHub](https://www.bleepingcomputer.com/news/security/gitloker-attacks-abuse-github-notifications-to-push-malicious-oauth-apps/)
19 |
20 | ## References
21 |
22 | * [Decoding consent phishing - technical blog post](https://www.mwrcybersec.com/decoding-consent-phishing)
23 | * [O365 attack toolkit - perform consent phishing attacks against O365](https://github.com/mdsecactivebreach/o365-attack-toolkit)
24 | * [MITRE ATT&CK - Phishing: Speakphishing Link](https://attack.mitre.org/techniques/T1566/002/)
25 | * [Compromised Microsoft Partner Network accounts used for consent phishing](https://www.bleepingcomputer.com/news/security/microsoft-disables-verified-partner-accounts-used-for-oauth-phishing/)
26 |
--------------------------------------------------------------------------------
/techniques/consent_phishing/examples/microsoft.md:
--------------------------------------------------------------------------------
1 | # Consent phishing on Microsoft
2 |
3 | An example of a consent screen showing for Microsoft Azure and requesting full access to read email and all files is shown below:
4 |
5 | 
6 |
7 | If a target were to click the accept button then the attack would be successful and the attacker would gain those permissions until explicit action was taken to revoke the access.
8 |
--------------------------------------------------------------------------------
/techniques/consent_phishing/examples/microsoft.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/consent_phishing/examples/microsoft.png
--------------------------------------------------------------------------------
/techniques/credential_stuffing/credential_stuffing.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/credential_stuffing/credential_stuffing.png
--------------------------------------------------------------------------------
/techniques/credential_stuffing/description.md:
--------------------------------------------------------------------------------
1 | # Credential stuffing
2 | ID: SAT1011
3 |
4 | ## Tactics
5 | * Initial Access
6 |
7 | ## Summary
8 | Credential stuffing is the re-use of stolen credentials, often from leaked password databases, in an attempt to authenticate to other apps. This is often successful due to the tendency of users to share passwords between multiple systems and accounts.
9 |
10 | This can be particularly effective against heavy users of SaaS apps as the higher the number of systems in use, the greater the chance that a compromised password hasn’t been changed.
11 |
12 | These attacks can be make more effective by matching personal and corporate email addresses, as well as guessing likely similar/incremental passwords.
13 |
14 | 
15 |
16 | ## Examples
17 |
18 | ## References
19 |
20 | * [MITRE ATT&CK - Brute Force: Credential Stuffing](https://attack.mitre.org/techniques/T1110/004/)
21 |
--------------------------------------------------------------------------------
/techniques/cross-idp_impersonation/description.md:
--------------------------------------------------------------------------------
1 | # Cross-IdP Impersonation
2 | ID: SAT1047
3 |
4 | ## Tactics
5 | * Initial Access
6 | * Persistence
7 |
8 | ## Summary
9 |
10 | Cross-IdP impersonation is when an adversary uses an account with the correct target email address but registered with an identity provider that is not in use by the target organization to authenticate to a target SaaS application. This can allow strong SSO authentication measures to be circumvented.
11 |
12 | For example, if a target organization has user@example.com email addresses and uses Microsoft Entra as their identity provider, but an attacker is able to create a user@example.com account with Google somehow, then they can potentially circumvent SSO logins to downstream SaaS applications by using "Login with Google" social logins instead of "Login with Microsoft" or a SAML-based SSO login. This is also affected by the configuration of the downstream SaaS application.
13 |
14 | ## References
15 | * [Technical blog post - Verification phishing and cross-idp impersonation](https://pushsecurity.com/blog/a-new-class-of-phishing-verification-phishing-and-cross-idp-impersonation/)
16 | * [Zendesk vulnerability allows Slack compromise](https://cyberinsider.com/zendesk-vulnerability-allows-slack-takeovers-through-apple-oauth-exploit/)
--------------------------------------------------------------------------------
/techniques/device_code_phishing/description.md:
--------------------------------------------------------------------------------
1 | # Device code phishing
2 | ID: SAT1012
3 |
4 | ## Tactics
5 | * Initial Access
6 | * Defense Evasion
7 |
8 | ## Summary
9 |
10 | OAuth supports multiple different authentication flows that can be used to grant access to an app. One of these is the device authorization grant, which is intended for use with input-constrained devices, such as smart TVs and printers.
11 |
12 | This flow operates by supplying a user with a unique code and instructing them to visit a webpage in a browser on a different device to enter the code in order to authorize the device.
13 |
14 | This can be used by an adversary to conduct a phishing attack against a target by convincing them to visit their authentication provider website and enter a code supplied by the adversary, thereby granting access to their account.
15 |
16 | This shares similar advantages to a consent phishing attack in that it allows access to a target's account without requiring their password or MFA tokens.
17 |
18 | It also has other advantages in that the link the target needs to visit is a legitimate URL and there is no prompt to consent to explicit permissions beyond entering the device code and signing in. Additionally, verified apps can be impersonated in some cases.
19 |
20 | ## Examples
21 | * [Microsoft](examples/microsoft.md)
22 |
23 | ## References
24 | * [Introducing a new phishing technique for compromising Office 365 accounts](https://aadinternals.com/post/phishing/)
25 | * [How to Detect Malicious OAuth Device Code Phishing](https://www.inversecos.com/2022/12/how-to-detect-malicious-oauth-device.html)
26 | * [PhishInSuits - a tool for device code phishing vs SMS](https://github.com/secureworks/PhishInSuits)
27 | * [Microsoft device code documentation](https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-device-code)
28 | * [MITRE ATT&CK - Phishing: Speakphishing Link](https://attack.mitre.org/techniques/T1566/002/)
29 |
--------------------------------------------------------------------------------
/techniques/device_code_phishing/examples/microsoft.md:
--------------------------------------------------------------------------------
1 | # Device code phishing with Microsoft
2 |
3 | The target is encouraged to visit the following link and enter a device code supplied by the adversary. In this example, the OneDrive iOS app is spoofed:
4 |
5 | https://microsoft.com/devicelogin?whatever-adversary-wants-to-put-here-to-add-legitimacy
6 |
7 | 
8 | 
9 | 
10 |
--------------------------------------------------------------------------------
/techniques/device_code_phishing/examples/ms_devicecode1.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/device_code_phishing/examples/ms_devicecode1.png
--------------------------------------------------------------------------------
/techniques/device_code_phishing/examples/ms_devicecode2.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/device_code_phishing/examples/ms_devicecode2.png
--------------------------------------------------------------------------------
/techniques/device_code_phishing/examples/ms_devicecode3.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/device_code_phishing/examples/ms_devicecode3.png
--------------------------------------------------------------------------------
/techniques/device_enrollment/description.md:
--------------------------------------------------------------------------------
1 | # Device Enrollment
2 | ID: SAT1043
3 |
4 | ## Tactics
5 | * Initial Access
6 | * Persistence
7 |
8 | ## Summary
9 | Some attack techniques result in temporary access to an account being obtained, possibly including knowledge of the account password, such as through AiTM phishing that proxies MFA codes or similar. In these situations, the ability to enroll a new device for an account can allow an adversary to maintain long-term access to the account.
10 |
11 | Most commonly, this would be the enrollment of a new MFA device in order to allow the adversary to complete MFA challenges for future authentication. However, it could also involve enrolling adversary-controlled devices into device management software to bypass other controls.
12 |
13 | This persistence form of device enrollment has been observed as a technique used by both [APT29](https://www.ncsc.gov.uk/news/svr-cyber-actors-adapt-tactics-for-initial-cloud-access) and [Scattered Spider](https://www.reliaquest.com/blog/scattered-spider-attack-analysis-account-compromise/)
14 |
15 | In some cases, this can even form part of the initial access phase. For example, if compromising a dormant account using a credential stuffing attack, this may have been previously configured without MFA and newer security settings may prompt for MFA enrollment during the authentication process. In this case, the adversary will need to perform MFA device enrollment in order to successfully complete the attack and gain access to the account. This has been observed in [attacks by APT29 against Azure](https://www.mandiant.com/resources/blog/apt29-continues-targeting-microsoft) in the past.
16 |
17 | ## Examples
18 |
19 | ## References
20 | * [NCSC advisory on cloud attacks by APT29](https://www.ncsc.gov.uk/news/svr-cyber-actors-adapt-tactics-for-initial-cloud-access)
21 | * [Scattered Spider Attack Analysis - Technical Blog](https://www.reliaquest.com/blog/scattered-spider-attack-analysis-account-compromise/)
22 | * [APT29 Attack Analysis - Technical Blog](https://www.mandiant.com/resources/blog/apt29-continues-targeting-microsoft)
23 | * [MITRE - Account Manipulation: Device Registration](https://attack.mitre.org/techniques/T1098/005/)
24 |
--------------------------------------------------------------------------------
/techniques/dns_reconnaissance/description.md:
--------------------------------------------------------------------------------
1 | # DNS reconnaissance
2 | ID: SAT1013
3 |
4 | ## Tactics
5 | * Reconnassiance
6 |
7 | ## Summary
8 | Some SaaS apps require ownership verification for a domain as part of the setup process. A common way to verify ownership is to publish a specific string as a DNS TXT record that the SaaS vendor can verify as proof.
9 | Querying DNS TXT records can reveal which SaaS apps the target organization might be using. MX and SPF records are also useful in discovering SaaS apps used to send and receive mail for the organization.
10 |
11 | ## Examples
12 | * [TXT records](examples/txt_hsbc.md)
13 |
14 | ## References
15 | * [MITRE ATT&CK - DNS](https://attack.mitre.org/techniques/T1590/002/)
16 |
--------------------------------------------------------------------------------
/techniques/dns_reconnaissance/examples/txt_hsbc.md:
--------------------------------------------------------------------------------
1 | # Lookup TXT records for HSBC
2 |
3 | The output from querying for TXT records for the global bank HSBC:
4 |
5 | ```
6 | hsbc.com. 300 IN TXT "c77e0dfe9d1771b49cbbf615650b24e"
7 | hsbc.com. 300 IN TXT "8219-5848-B517-278B-A270-122C-5E8F-C5ED"
8 | hsbc.com. 300 IN TXT "6F33-A96D-4A70-B2F3-8980-0DA9-C687-9C2F"
9 | hsbc.com. 300 IN TXT "5700a0f161c3ee56b1cdb45f8ff0d606"
10 | hsbc.com. 300 IN TXT "v=spf1 include:spf-00299f02.pphosted.com include:spf1.hsbc.com include:spf2.hsbc.com include:spf3.hsbc.com ~all"
11 | hsbc.com. 300 IN TXT "f9fe8b945d159604d4fe56f68fd5a851"
12 | hsbc.com. 300 IN TXT "7c573538-4895-4bd2-90b9-13ecb67623b3"
13 | hsbc.com. 300 IN TXT "mongodb-site-verification=IZGVt2wuFTz4U2KdEQTxNjbTM5MQ4agI"
14 | hsbc.com. 300 IN TXT "docker-verification=2885f98d-883c-4171-88f5-44ebc35fd452"
15 | hsbc.com. 300 IN TXT "_github-challenge-hsbc-ent.hsbc.com=2c0124c517"
16 | hsbc.com. 300 IN TXT "google-site-verification=NI7zII4Ge_p28m0XfsDGMj77Nly4XabBi4MonUEVcUM"
17 | hsbc.com. 300 IN TXT "google-site-verification=vPkZv7fjzUVwP2apQBxXmbtPQb0PAhU5k9KuxnAwr5o"
18 | hsbc.com. 300 IN TXT "google-site-verification=M4iN_PX9kRTMMWq44Gj5N0yCKw21840zwBXdoBk1XJM"
19 | hsbc.com. 300 IN TXT "adobe-idp-site-verification=97bd1b56bb7c1bf2b021fcc1aa99f303be57821beda2e03442612fe631a071e5"
20 | hsbc.com. 300 IN TXT "webexdomainverification.=de5860e7-75ed-4687-9345-095d6298d12b"
21 | hsbc.com. 300 IN TXT "webexdomainverification.=e10dece0-359f-4aa8-85f9-8fd61121b3c1"
22 | hsbc.com. 300 IN TXT "webexdomainverification.JO59=608c80a0-fcc1-4022-8b7f-d99cee31b523"
23 | hsbc.com. 300 IN TXT "webexdomainverification.GVLY=f509eddc-026a-40ff-896d-94a2a7c5089a"
24 | hsbc.com. 300 IN TXT "webexdomainverification.L2W7=69ac8949-902f-4c8c-90d0-4a0d3dcedb1c"
25 | hsbc.com. 300 IN TXT "webexdomainverification.L2W2=72eed45f-93c2-4f58-8c1f-407b22083b6c"
26 | hsbc.com. 300 IN TXT "webexdomainverification.=cf1ab7f9-8d4c-4d37-aff4-4a88b437614c"
27 | hsbc.com. 300 IN TXT "96b06eef013a4fa7ba21975d52f6cea8ba5586141e604aad968e8e8a6a6b0d0c"
28 | hsbc.com. 300 IN TXT "adobe-sign-verification=33807990c7278c58bea18223c41dcf38"
29 | ```
30 |
31 | From this output there is evidence of use of Google, Adobe, MongoDB, Docker, GitHub, Webex and Proofpoint as an email gateway.
32 |
--------------------------------------------------------------------------------
/techniques/email_discovery/description.md:
--------------------------------------------------------------------------------
1 | # Email discovery
2 | ID: SAT1014
3 |
4 | ## Tactics
5 | * Discovery
6 |
7 | ## Summary
8 |
9 | There is generally evidence in a user’s mailbox when they are actively using a SaaS app. At a minimum, there is usually some form of welcome or verification email, if not usage notifications
10 |
11 | Email is a prime source of discovery of other SaaS apps the target is using. If an adversary gains access to a mailbox, they may use this information to perform further attacks and move laterally to other SaaS apps the compromised user is accessing. Email is also a source of general knowledge an adversary can use to conduct further attacks against other users in the organization.
12 |
13 | ## Examples
14 | * [Welcome to search](examples/welcome_to.md)
15 |
16 | ## References
--------------------------------------------------------------------------------
/techniques/email_discovery/examples/welcome_to.md:
--------------------------------------------------------------------------------
1 | # Welcome to keyword search
2 |
3 | Below is a screenshot showing some example welcome emails that can be found simply by searching for common keywords:
4 |
5 | 
--------------------------------------------------------------------------------
/techniques/email_discovery/examples/welcome_to.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/email_discovery/examples/welcome_to.png
--------------------------------------------------------------------------------
/techniques/email_phishing/description.md:
--------------------------------------------------------------------------------
1 | # Email phishing
2 | ID: SAT1015
3 |
4 | ## Tactics
5 | * Initial Access
6 |
7 | ## Summary
8 | Email phishing is the classic social engineering attack that involves an email being sent to a target user with an embedded link or malicious attachment. The email is meant to either convince the target to enter their login credentials or open a malicious attachment.
9 |
10 | SaaS-focused phishing attacks tend to be focused on capturing credentials and MFA codes where necessary, in order to gain access to SaaS apps.
11 |
12 | Traditionally, many organizations would have only had one web-based external endpoint, such as Outlook Web Access. Often phishing attacks would target fake OWA portals and phishing training commonly focus on such scenarios. However, there is a higher number of potential scenarios that could be convincing to a target using a large number of SaaS apps.
13 |
14 | ## Examples
15 |
16 | ## References
17 | * [Evilginx - MITM framework for phishing login credentials](https://github.com/kgretzky/evilginx2)
18 | * [MITRE ATT&CK - Phishing](https://attack.mitre.org/techniques/T1566)
19 |
--------------------------------------------------------------------------------
/techniques/evil_twin_integrations/description.md:
--------------------------------------------------------------------------------
1 | # Evil twin integrations
2 | ID: SAT1016
3 |
4 | ## Tactics
5 | * Persistence
6 | * Defense Evasion
7 |
8 | ## Summary
9 | OAuth apps provide a mechanism for maintaining long-term persistent access to compromised accounts that resist normal recovery actions, such as password resets. However, an in-depth investigation may lead to the discovery of OAuth integrations created by the adversary. Once these malicious integrations are deleted, the adversary would lose their persistence mechanism as soon as the access token expires (within hours or minutes).
10 |
11 | Instead, the attacker could enumerate existing OAuth integrations the user has already granted/installed, find one that exposes useful scopes and functionality, and create a second instance or twin of that integration. These twin integrations look identical to the original integration as SaaS apps don’t display the details of the account on the other side of the integration, and are therefore unlikely to be discovered and deleted.
12 |
13 | This attack relies on the victim having already installed or created an OAuth integration that would be useful to the attacker. Existing integrations with workflow automation / no-code automation platforms are typically the most useful, but other apps that access (and expose) sensitive data like email are common in marketing, sales and customer support tools.
14 |
15 | A demo video of an attack chain combining [shadow workflows](/techniques/shadow_workflows/description.md) with an evil twin integration is given below:
16 |
17 | [](https://www.youtube.com/watch?v=g2EITjjJH1s)
18 |
19 |
20 | ## Examples
21 | * [Hubspot](examples/hubspot.md)
22 |
23 | ## References
24 |
25 | * [Maintaining persistant access in a SaaS-first world - Technical blog post](https://pushsecurity.com/blog/maintaining-persistent-access-in-a-saas-first-world)
26 | * [The shadow workflow's evil twin - Technical blog post](https://pushsecurity.com/blog/nearly-invisible-attack-chain/)
27 |
--------------------------------------------------------------------------------
/techniques/evil_twin_integrations/examples/hubspot.md:
--------------------------------------------------------------------------------
1 | # Hubspot for email access
2 |
3 | Hubspot is a marketing automation app that allows users to connect up an email account to the app. This is a legitimate and verified OAuth integration created by Hubspot. While the adversary does not have access to the OAuth access tokens, they can make indirect use via the functionality available in their Hubspot account.
4 |
5 | In this case, Hubspot has functionality to act like an actual email inbox,so it acts like a lightweight webmail solution. This provides adversaries backdoor-like access to the account’s email, while masquerading as Hubspot.
6 |
7 | 
8 | 
9 |
--------------------------------------------------------------------------------
/techniques/evil_twin_integrations/examples/hubspot_email_view.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/evil_twin_integrations/examples/hubspot_email_view.png
--------------------------------------------------------------------------------
/techniques/evil_twin_integrations/examples/hubspot_inboxes.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/evil_twin_integrations/examples/hubspot_inboxes.png
--------------------------------------------------------------------------------
/techniques/ghost_logins/description.md:
--------------------------------------------------------------------------------
1 | # Ghost logins
2 | ID: SAT1017
3 |
4 | ## Tactics
5 | * Initial access
6 | * Persistence
7 | * Defense Evasion
8 |
9 | ## Summary
10 | A common SaaS app feature allows logins to the same account using multiple methods simultaneously – for example, a standard password-based authentication (local to the SaaS app) and an SSO mechanism, such as an OIDC social login or SAML login. This can be relevant for both initial access and persistence phases.
11 |
12 | For initial access, it's possible users will have configured much weaker authentication mechanisms at some point. For example, a weak single-factor password before SSO was configured or a secondary/recovery address using a personal webmail account. They later migrate to strong SSO but the original methods remain active and attackers can find these weaknesses in future. This was a discussion point during the 2024 Snowflake credential breaches as local passwords were not disabled if migrating Snowflake to SAML SSO authentication.
13 |
14 | For persistence, if an adversary gains access to a SaaS account temporarily, they can configure an alternative authentication method to maintain access to the account, alongside the legitimate user. If the user uses a social login to access the account, an adversary may be able to configure a separate username/password login to access the account or even (though much less commonly) connect a second social account that the adversary controls. This allows the adversary to maintain persistent access to the user account even in the event of password changes or MFA changes.
15 |
16 | This attack will go unnoticed if the victim organization relies on SSO logs for auditing access to SaaS applications. The attack bypasses SSO as the login remains local to the SaaS app or, in the case of an OIDC SSO login, the adversary’s own social account.
17 |
18 |
19 | ## Examples
20 | * [Snowflake](https://www.youtube.com/watch?v=5yeOAM4YCAI)
21 | * [Shortcut](examples/shortcut.md)
22 | * [Expensify](examples/expensify.md)
23 |
24 | ## References
25 | * [MITRE ATT&CK - Use Alternate Authentication Material](https://attack.mitre.org/techniques/T1550/)
26 | * [X thread explaining ghost logins with reference to Snowflake](https://x.com/jukelennings/status/1801985628034281703)
27 | * [Google email verification flaw abused to compromise 3rd party SaaS services](https://krebsonsecurity.com/2024/07/crooks-bypassed-googles-email-verification-to-create-workspace-accounts-access-3rd-party-services/)
28 |
--------------------------------------------------------------------------------
/techniques/ghost_logins/examples/expensify.md:
--------------------------------------------------------------------------------
1 | # Ghost logins on [Expensify](https://www.expensify.com/)
2 |
3 | A user may add other accounts they control as secondary logins. These can then be used to login using passwordless email authentication.
4 |
5 | 
6 |
--------------------------------------------------------------------------------
/techniques/ghost_logins/examples/expensify_secondary_logins.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/ghost_logins/examples/expensify_secondary_logins.png
--------------------------------------------------------------------------------
/techniques/ghost_logins/examples/shortcut.md:
--------------------------------------------------------------------------------
1 | # Setting additional authentication methods on [Shortcut](https://shortcut.com)
2 |
3 | A user may set a Google OIDC social login and set a separate password disconnected from the Google account and login with either. The following is a screenshot of a user logged in with a social login setting a password as well:
4 |
5 | 
--------------------------------------------------------------------------------
/techniques/ghost_logins/examples/shortcut_set_password.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/ghost_logins/examples/shortcut_set_password.png
--------------------------------------------------------------------------------
/techniques/guest_access_abuse/description.md:
--------------------------------------------------------------------------------
1 | # Guest Access Abuse
2 | ID: SAT1046
3 |
4 | ## Tactics
5 | * Initial Access
6 |
7 | ## Summary
8 |
9 | In SaaS platforms like Salesforce, ServiceNow, and Zendesk, misconfigurations related to guest user permissions can lead to unauthorized data access or escalation of privileges. These platforms often allow guest/unauthenticated users limited access for specific purposes. However, if the guest access is not correctly configured, it may grant broader permissions than intended.
10 |
11 | An attacker can exploit such misconfigurations by accessing a guest account and leveraging the excessive permissions to access or manipulate sensitive data, potentially leading to a full account takeover or data breach.
12 |
13 | ## Examples
14 | * [Salesforce guest user misconfiguration allowing data access](https://arstechnica.com/information-technology/2023/04/misconfigured-servers-running-salesforce-software-are-leaking-sensitive-data/).
15 | * [ServiceNow instance where guest users could access PII Data](https://www.csoonline.com/article/572239/nearly-70-of-servicenow-instances-leaking-data.html).
16 |
17 | ## References
18 |
19 | * [Give Secure Access to Unauthenticated Users with the Guest User Profile](https://help.salesforce.com/s/articleView?id=sf.networks_public_access.htm&type=5).
20 | * [General Information | Potential Public List Widget Misconfiguration](https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1553688).
21 |
--------------------------------------------------------------------------------
/techniques/hijack_oauth_flows/description.md:
--------------------------------------------------------------------------------
1 | # Hijack OAuth flows
2 | ID: SAT1040
3 |
4 | ## Tactics
5 | * Initial Access
6 |
7 | ## Summary
8 |
9 | During the OAuth authorization code flow, after a user grants permission to a third-party application, the service provider generates an authorization code and redirects the user's browser back to the third-party application's specified *redirect_uri*. This *redirect_uri* is an endpoint on the third-party application's server where the authorization code will be sent. If the service provider has not been configured with an appropriately restricted allowlist of *redirect_uri* values it is allowed to redirect to, an attacker could modify the *redirect_uri* parameter sent during the initial authorization request to point to a malicious server they control.
10 |
11 | This may allow an adversary to intercept the authorization code and use it to request an access token for the victim's account from the service provider. This access token can then be used to access the victim's resources without their consent.
12 |
13 | ## Examples
14 | * [HackerOne - OAuth redirect_uri bypass using IDN homograph attack resulting in user's access token leakage](https://hackerone.com/reports/861940)
15 | * [HackerOne - Stealing Users OAuth authorization code via redirect_uri](https://hackerone.com/reports/1861974)
16 |
17 | ## References
18 |
19 | * [OWASP - Testing for OAuth Authorization Server Weaknesses](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/05-Authorization_Testing/05.1-Testing_for_OAuth_Authorization_Server_Weaknesses)
20 | * [PortSwigger - OAuth 2.0 authentication vulnerabilities](https://portswigger.net/web-security/oauth#leaking-authorization-codes-and-access-tokens)
21 | * [PortSwigger - Hidden OAuth attack vectors](https://portswigger.net/research/hidden-oauth-attack-vectors)
22 |
--------------------------------------------------------------------------------
/techniques/im_phishing/description.md:
--------------------------------------------------------------------------------
1 | # IM phishing
2 | ID: SAT1018
3 |
4 | ## Tactics
5 | * Initial Access
6 |
7 | ## Summary
8 |
9 | Traditionally, phishing attacks have been mostly email-based. While many organizations have been making use of SaaS-based instant messaging apps, these have been traditionally focused on internal communications, but this is changing rapidly.
10 |
11 | Due to the ubiquity and effectiveness of instant messaging apps, communication with external parties has become more common. Instant messaging apps also lack many of the security controls around malicious links and attachments that have been common in email gateways for many years. This along with the immediacy and real-time nature of IM makes it a great vector for phishing attacks as users are less familiar with these apps as delivery vectors for phishing attacks.
12 |
13 | ## Examples
14 | * [Slack](examples/slack.md)
15 | * [MS Teams](examples/teams.md)
16 |
17 | ## References
18 | * [Slack Attack: A phisher's guide to initial access](https://pushsecurity.com/blog/slack-phishing-for-initial-access/)
19 | * [Slack Attack: A phisher's guide to persistence and lateral movement](https://pushsecurity.com/blog/phishing-slack-persistence/)
20 | * [Jumpsec Advisory: IDOR in Microsoft Teams Allows for External Tenants to Introduce Malware](https://labs.jumpsec.com/advisory-idor-in-microsoft-teams-allows-for-external-tenants-to-introduce-malware/)
21 | * [TeamsPhisher](https://github.com/Octoberfest7/TeamsPhisher)
22 | * [Slack Jack - A tool for Slack bot token abuse](https://github.com/adelapazborrero/slack_jack?tab=readme-ov-file)
23 | * [Evilginx - AITM framework for phishing login credentials](https://github.com/kgretzky/evilginx2)
24 | * [MITRE ATT&CK - Phishing: Spearphishing via Service](https://attack.mitre.org/techniques/T1566/003/)
25 | * [Storm-0324 distributes malware using TeamsPhisher](https://www.microsoft.com/en-us/security/blog/2023/09/12/malware-distributor-storm-0324-facilitates-ransomware-access/)
26 |
--------------------------------------------------------------------------------
/techniques/im_phishing/examples/slack.md:
--------------------------------------------------------------------------------
1 | # IM phishing with Slack
2 |
3 | * [Slack Attack: A phisher's guide to initial access](https://pushsecurity.com/blog/slack-phishing-for-initial-access/)
4 | * [Slack Attack: A phisher's guide to persistence and lateral movement](https://pushsecurity.com/blog/phishing-slack-persistence/)
5 |
6 | Slack Connect has made phishing using the Slack platform far more viable. It’s now possible for one Slack tenant to message other Slack tenants by default. The target user will get a notification via email and via Slack itself and if they accept then it becomes a direct message channel.
7 |
8 | There are some restrictions- full previews for images and links will not load in these Slack connect messages, but for most target users, the DM will appear to be the same (or very similar) as the DMs they are receiving from colleagues.
9 |
10 | An adversary can also edit their message after a successful attack to remove evidence of the original malicious link.
11 |
12 | 
--------------------------------------------------------------------------------
/techniques/im_phishing/examples/slack.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/im_phishing/examples/slack.png
--------------------------------------------------------------------------------
/techniques/im_phishing/examples/teams.md:
--------------------------------------------------------------------------------
1 | # IM phishing with Microsoft Teams
2 |
3 | Teams is a great vector, too. You can direct message another Teams’ tenant by default and the target will get a message request that they can accept or block. There are some restrictions around attachments, but otherwise it’s a fairly standard DM channel.
4 |
5 | 
--------------------------------------------------------------------------------
/techniques/im_phishing/examples/teams.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/im_phishing/examples/teams.png
--------------------------------------------------------------------------------
/techniques/im_user_spoofing/description.md:
--------------------------------------------------------------------------------
1 | # IM user spoofing
2 | ID: SAT1019
3 |
4 | ## Tactics
5 | * Initial Access
6 | * Lateral Movement
7 |
8 | ## Summary
9 | Some instant messaging apps do not strongly control the way a user presents themselves in terms of display names, full names, user handles, photos, and so on.
10 |
11 | Given that instant messaging systems are often focused on internal communications, users usually trust them. An adversary could take advantage of this to use a compromised account, or an external account where the instant messaging app permits cross-tenant communication (e.g. Slack connect or MS Teams), to spoof their identity to increase the success of phishing attacks and other social engineering attempts.
12 |
13 | For example, a compromised user account could be renamed and have the photo changed to match the CEO and attempt CEO fraud by directly messaging members of the finance team. These profile details make CEO impersonation much more credible.
14 |
15 | ## Examples
16 | * [Slack](examples/slack.md)
17 |
18 | ## References
19 | * [Slack Attack: A phisher's guide to initial access](https://pushsecurity.com/blog/slack-phishing-for-initial-access/)
20 | * [Slack Attack: A phisher's guide to persistence and lateral movement](https://pushsecurity.com/blog/phishing-slack-persistence/)
21 |
--------------------------------------------------------------------------------
/techniques/im_user_spoofing/examples/slack.md:
--------------------------------------------------------------------------------
1 | # Slack
2 |
3 | * [Slack Attack: A phisher's guide to initial access](https://pushsecurity.com/blog/slack-phishing-for-initial-access/)
4 | * [Slack Attack: A phisher's guide to persistence and lateral movement](https://pushsecurity.com/blog/phishing-slack-persistence/)
5 |
6 | Slack is a great example of this, since users control almost all of their details by default. You can even pick a Slack handle that existing users are already using, so you could pick the exact same handle as the CEO or whatever employee you would like to impersonate.
7 |
8 |
9 | In an external Slack phishing scenario, you can also control these details and additionally pick your workspace name and logo to replicate the organization you want to spoof.
10 |
11 | 
12 |
--------------------------------------------------------------------------------
/techniques/im_user_spoofing/examples/slack.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/im_user_spoofing/examples/slack.png
--------------------------------------------------------------------------------
/techniques/in-app_phishing/description.md:
--------------------------------------------------------------------------------
1 | # In-app phishing
2 | ID: SAT1020
3 |
4 | ## Tactics
5 | * Initial Access
6 | * Lateral Movement
7 |
8 | ## Summary
9 | It’s possible to conduct phishing and other social engineering attacks, using native features of SaaS apps. This will often result in activity directly within an app the target already uses and/or may result in email notifications being delivered directly to the target but from legitimate email domains associated with the SaaS app. This is a broad area but commonly can be through shared content or collaborations features, such as document sharing and commenting functionality.
10 |
11 | Users will often treat activity within legitimate apps or email notifications from confirmed legitimate SaaS app domains with a much higher level of trust than they would traditional phishing emails and therefore they are more likely to fall victim.
12 |
13 | This can be used as both an initial access method, using SaaS apps that allow communication with external users, or as a lateral movement method once a foothold has been established on a legitimate tenant for the target organization.
14 |
15 | For example, a malicious document could be shared with a target using a document sharing app in an attempt to gain a foothold elsewhere. A different example involving lateral movement might be a ticketing system where comments and ticket creation functionality could be abused to spread malicious links aimed at harvesting further user credentials.
16 |
17 | ## Examples
18 |
19 | * [GitHub](examples/github.md)
20 | * [Monday.com](https://www.bleepingcomputer.com/news/security/mondaycom-removes-share-update-feature-abused-for-phishing-attacks/)
21 |
22 | ## References
23 | * [Jade sleet compromise using GitHub repository collaboration](https://github.blog/2023-07-18-security-alert-social-engineering-campaign-targets-technology-industry-employees/)
24 | * [Evilginx - MITM framework for phishing login credentials](https://github.com/kgretzky/evilginx2)
25 | * [MITRE ATT&CK - Phishing: Spearphishing via Service](https://attack.mitre.org/techniques/T1566/003/)
26 | * [Phishing lures embedded within shared documents](https://www.proofpoint.com/uk/blog/cloud-security/community-alert-ongoing-malicious-campaign-impacting-azure-cloud-environments)
27 | * [GitHub notification phishing](https://www.bleepingcomputer.com/news/security/gitloker-attacks-abuse-github-notifications-to-push-malicious-oauth-apps/)
28 |
--------------------------------------------------------------------------------
/techniques/in-app_phishing/examples/github.md:
--------------------------------------------------------------------------------
1 | # GitHub
2 |
3 | GitHub is an example of a SaaS app that supports links in a variety of locations that can be used for phishing. These do not have to be associated only with repositories that an attacker controls as it's common for issues, discussions and comments on public repositories to be usable by any GitHub user.
4 |
5 | However, one particularly interesting trick afforded to attackers with GitHub is the ability to host a range of file types in URLs for repositories they do not control without the owners even being notified.
6 |
7 | It's possible to upload a file to a GitHub comment and it will automatically be hosted on a URL associated with the given repository and organization. This occurs without even posting the comment while it's still in draft, and the link persists even if the comment is not posted. This enables malicious files to be spread using GitHub URLs that are additionally associated with well-known organizations and repositories, such as Microsoft themselves.
8 |
9 | For example, the image below shows the supported file formats in the error:
10 | 
11 |
12 | This image shows the link being created while the comment is still in draft and providing a link to the file both within the "pushsecurity" organization and within the "saas-attacks" repository
13 |
14 | 
15 |
16 | For further details, checkout the following article:
17 |
18 | https://www.bleepingcomputer.com/news/security/github-comments-abused-to-push-malware-via-microsoft-repo-urls/
--------------------------------------------------------------------------------
/techniques/in-app_phishing/examples/image-1.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/in-app_phishing/examples/image-1.png
--------------------------------------------------------------------------------
/techniques/in-app_phishing/examples/image.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/in-app_phishing/examples/image.png
--------------------------------------------------------------------------------
/techniques/inbound_federation/description.md:
--------------------------------------------------------------------------------
1 | # Inbound federation
2 | ID: SAT1041
3 |
4 | ## Tactics
5 | * Persistence
6 | * Lateral Movement
7 |
8 | ## Summary
9 | Inbound federation allows users to login to a target identity provider by authenticating with a source identity provider. This is often used in scenarios that involve multiple large divisions that form part of a larger parent, such as with conglomerates or during mergers and acquisitions.
10 |
11 | An adversary who has gained administrative control of an application, such as a core identity provider, can use this to both maintain persistent access as well as effectively laterally move to other user accounts by authenticating against an identity provider they control and having those accounts mapped automatically to existing accounts on the target identity provider.
12 |
13 | This shares similarities with [ghost logins](/techniques/ghost_logins/description.md), but affects all users of an application instead of being tied specifically to one user account.
14 |
15 | ## Examples
16 | * [Okta](examples/okta.md)
17 |
18 | ## References
19 | * [Okta Cross-Tenant Impersonation](https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection)
20 |
21 |
--------------------------------------------------------------------------------
/techniques/inbound_federation/examples/okta.md:
--------------------------------------------------------------------------------
1 | # Okta Inbound Federation
2 |
3 | Okta is one example of an identity provider that allows external identity providers to be configured for inbound federation. Combined with automatic account linking, this can be used to configure a downstream identity provider that the adversary controls, which can then be used like a skeleton key to authenticate as any Okta account the attacker chooses.
4 |
5 | Given Okta is an identity management service that allows users access to other applications, this would allow an adversary to easily impersonate any Okta user and then laterally move to other applications.
6 |
7 | This has been observed in real-world compromises of Okta customers as highlighted in the following article published by Okta:
8 |
9 | https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection
10 |
11 | The following screenshots show some of the options for configuring inbound federation using external identity providers, including automatically linking them to pre-existing Okta accounts:
12 |
13 | 
14 | 
15 | 
--------------------------------------------------------------------------------
/techniques/inbound_federation/examples/okta1.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/inbound_federation/examples/okta1.png
--------------------------------------------------------------------------------
/techniques/inbound_federation/examples/okta2.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/inbound_federation/examples/okta2.png
--------------------------------------------------------------------------------
/techniques/inbound_federation/examples/okta3.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/inbound_federation/examples/okta3.png
--------------------------------------------------------------------------------
/techniques/link_backdooring/description.md:
--------------------------------------------------------------------------------
1 | # Link backdooring
2 | ID: SAT1021
3 |
4 | ## Tactics
5 | * Privilege Escalation
6 | * Lateral Movement
7 |
8 | ## Summary
9 | Users have long been trained to be wary of clicking links from external sources such as email. However, they don’t usually exercise the same caution when clicking links within trusted apps.
10 |
11 | Many SaaS apps have functionality to include links to other systems. For example, SaaS-based Office documents may have links in them, tickets in ticket tracking systems and wikis can be especially link-heavy. Often these systems don’t exercise the same link security you would expect in external email, so malicious links can be more easily obfuscated to appear legitimate, even if a user checks.
12 |
13 | An adversary who has gained a foothold into a trusted SaaS app where links are common could automate backdooring links in the app to direct to a phishing site they control. Since users are used to their sessions or SSO logins expiring, they’ve grown accustomed to clicking a (seemingly legitimate) link within a trusted system. This makes sending users to a phishing site within a trusted app that much easier because it looks like the standard SSO login page.
14 |
15 | Wiki-style apps are a particularly interesting target for this type of attack as links are commonplace and individual users can often edit fairly large amounts of content (and links included therein). Adversaries can even use APIs to automate updating these links.
16 |
17 |
18 | ## Examples
19 | * [Nuclino](examples/nuclino.md)
20 |
21 | ## References
22 | * [Evilginx - MITM framework for phishing login credentials](https://github.com/kgretzky/evilginx2)
23 |
--------------------------------------------------------------------------------
/techniques/link_backdooring/examples/nuclino.md:
--------------------------------------------------------------------------------
1 | # Backdooring links on [Nuclino](https://nuclino.com/)
2 |
3 | Nuclino, a SaaS-based wiki, is a great example of a target for URL/link backdooring. By default, all users have read/write access to everything in their workspaces. In practice, that means any single compromised user has the ability to modify a large amount of content.
4 |
5 | Additionally, Nuclino has an API, making it very easy for an adversary to automate the process of backdooring all links or applying some selection criteria.
6 |
7 | Worse, since Nuclino is a trusted system, there is very little link security. The links are not automatically analyzed and reported on and there are multiple ways to obfuscate them. Many users may choose to ctrl+click on links so they never see the real link by hovering over it. This means you can easily hide links as normal text or by obfuscating one link as another, in ways that mail servers would normally alert on.
8 |
9 | 
10 | 
11 |
12 | Even if users are clicking on links to see the link preview and are manually verifying the URL seems legit, it’s still possible to take advantage of the limited space available for a preview to hide the real domain and make use of subdomains to make it seem like the URL matches.
13 |
14 | 
15 |
16 | The link preview above masks the fact that the real URL is the following:
17 |
18 | `https://internal-sharepoint-server.legitcompany.com.myevildomain.com/`
--------------------------------------------------------------------------------
/techniques/link_backdooring/examples/nuclino_evil_link.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/link_backdooring/examples/nuclino_evil_link.png
--------------------------------------------------------------------------------
/techniques/link_backdooring/examples/nuclino_legit_link.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/link_backdooring/examples/nuclino_legit_link.png
--------------------------------------------------------------------------------
/techniques/link_backdooring/examples/nuclino_long_evil_link.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/link_backdooring/examples/nuclino_long_evil_link.png
--------------------------------------------------------------------------------
/techniques/link_sharing/description.md:
--------------------------------------------------------------------------------
1 | # Link sharing
2 | ID: SAT1022
3 |
4 | ## Tactics
5 | * Persistence
6 | * Defense Evasion
7 |
8 | ## Summary
9 | Many SaaS apps offer the ability to share items with third parties through sharing links. A file storage app may allow a document to be shared with a third party either through explicitly sharing with named accounts in a separate tenant or through creation of an anonymous/public-sharing link.
10 |
11 | An adversary can create sharing links to maintain persistent access to data if the password is changed or the compromised account is disabled. Access to resources that have been shared anonymously are usually not logged in the same detail, can’t be attributed to a specific user, and can be used to evade audit controls.
12 |
13 | ## Examples
14 | * [OneDrive](examples/onedrive.md)
15 | * [Nuclino](examples/nuclino.md)
16 |
17 | ## References
--------------------------------------------------------------------------------
/techniques/link_sharing/examples/nuclino.md:
--------------------------------------------------------------------------------
1 | # Public sharing in Nuclino
2 |
3 | You can share any Nuclino page publicly, and, once shared, there is no visual indication the page is shared. Sharing settings for each page would need to be checked individually.
4 |
5 | 
--------------------------------------------------------------------------------
/techniques/link_sharing/examples/nuclino.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/link_sharing/examples/nuclino.png
--------------------------------------------------------------------------------
/techniques/link_sharing/examples/onedrive.md:
--------------------------------------------------------------------------------
1 | # Public sharing in OneDrive
2 |
3 | Given below is an example of sharing links in OneDrive. Documents and folders can either be shared with named external users in other OneDrive tenants or an anonymous link can be copied and distributed.
4 |
5 | In this case, sharing a root level folder means access can be maintained to all future documents and subfolders that are added to it. Shared items are clearly marked when browsing OneDrive but that isn’t always the case across SaaS apps.
6 |
7 | 
8 | 
--------------------------------------------------------------------------------
/techniques/link_sharing/examples/onedrive_1.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/link_sharing/examples/onedrive_1.png
--------------------------------------------------------------------------------
/techniques/link_sharing/examples/onedrive_2.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/link_sharing/examples/onedrive_2.png
--------------------------------------------------------------------------------
/techniques/malicious_mail_rules/description.md:
--------------------------------------------------------------------------------
1 | # Malicious mail rules
2 | ID: SAT1023
3 |
4 | ## Tactics
5 | * Persistence
6 | * Privilege Escalation
7 | * Defense Evasion
8 |
9 | ## Summary
10 | Common SaaS mail providers like Office365 and Gmail provide mail rule functionality that allows users to automate certain tasks on their mailboxes. This includes forwarding, moving emails, marking them as read and deleting them.
11 |
12 | This can be used maliciously for multiple purposes. Mail rules persist after account changes, such as password resets. So one obvious tactic is to use them to persist access to a compromised mailbox by setting up auto-forwarding rules for all emails (or ones with interesting keywords, like “password reset” or “invoice”) to an external address - this is typical in BEC-style attacks.
13 |
14 | By intercepting password or MFA reset emails through forwarding and auto-delete rules, mail rules can be used to move laterally to compromise accounts for other SaaS apps, while also avoiding alerting the user to the malicious activity.
15 |
16 | ## Examples
17 | * [Office 365](examples/office_365.md)
18 |
19 | ## References
20 | * [Malicious Outlook Rules - Technical blog post](https://www.netspi.com/blog/technical/adversary-simulation/malicious-outlook-rules/)
21 | * [Ruler - A tool to abuse Exchange services](https://github.com/sensepost/ruler)
22 | * [XRulez - A command line tool for creating malicious outlook rules](https://github.com/FSecureLABS/XRulez)
23 | * [MITRE ATT&CK - Email Forwarding Rule](https://attack.mitre.org/techniques/T1114/003/)
24 | * [Multi-account Office365 compromise using mail rules](https://darktrace.com/blog/breakdown-of-a-multi-account-compromise-within-office-365)
25 | * [Microsoft blog - Mail rules used to hide attacks](https://www.microsoft.com/en-us/security/blog/2023/12/12/threat-actors-misuse-oauth-applications-to-automate-financially-driven-attacks/)
26 |
--------------------------------------------------------------------------------
/techniques/malicious_mail_rules/examples/office_365.md:
--------------------------------------------------------------------------------
1 | # Creating a malicious mail rule in Office 365
2 |
3 | The screenshot below shows an example of configuring a forwarding rule in Office365.
4 |
5 | 
--------------------------------------------------------------------------------
/techniques/malicious_mail_rules/examples/office_365.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/malicious_mail_rules/examples/office_365.png
--------------------------------------------------------------------------------
/techniques/mfa_downgrade/description.md:
--------------------------------------------------------------------------------
1 | # MFA downgrade
2 | ID: SAT1045
3 |
4 | ## Tactics
5 | * Initial Access
6 |
7 | ## Summary
8 | Phishing-resistant MFA factors, such as passkeys or vendor-specific implementations like Okta Fastpass, have been introduced to deal with the problem of [AiTM phishing attacks](/techniques/aitm_phishing/description.md) and credential theft. An MFA downgrade attack can be used to prevent the use of a passkey in order to force the use of a vulnerable factor, such that an AiTM phishing attack is still successful.
9 |
10 | Traditional authentication factors, like passwords, push notifications and time-based one-time-passwords (TOTPs) are all vulnerable to phishing attacks as they can be either captured and replayed by an attacker or work without even needing to be replayed, as is the case with push notifications. Additionally, [MFA fatigue](/techniques/mfa_fatigue/description.md) attacks are often effective against push notification factors too, when an attacker has already compromised a password factor.
11 |
12 | Using a phishing-resistant factor, such as a passkey, prevents these attacks because they are cryptographically tied to the domain being accessed. Therefore, if a user accesses a AiTM phishing website on a malicious domain, it’s not possible for them to send a successful challenge/response to authenticate.
13 |
14 | However, just because a user has a phishing-resistant factor setup and may use them by default, it does not mean they are necessarily enforced. Often services support the use of multiple authentication options, particularly for second factors. In particular, passkeys are device-bound and so enforcing their use prevents logins from other devices and can cause recovery issues in a lost/broken device scenario. Therefore, it is common for the default case to be that passkey authentication is optional, rather than required.
15 |
16 | Attackers can exploit this by using an AiTM phishing attack to modify requests/responses so as to prevent the ability of passkeys to be selected as a login option and prompting the user to use vulnerable factors, such as passwords, TOTPs and push notifications instead. Since the server-side will support these authentication options in this case, if the user continues to enter other authentication factors then their authenticated session will be compromised despite the fact they usually use passkeys or similar.
17 |
18 |
19 | ## Examples
20 | * [Microsoft - Windows Hello for Business MFA downgrade attack](https://medium.com/@yudasm/bypassing-windows-hello-for-business-for-phishing-181f2271dc02#c32b)
21 |
22 | ## References
23 | * [FIDO Alliance - Passkeys 101](https://fidoalliance.org/passkeys/)
24 | * [X33fcon - Unraveling and Countering Adversary-in-the-Middle Phishing Attacks - MFA downgrade section](https://youtu.be/-W-LxcbUxI4?t=1541)
25 | * [Evilginx phishlet for WHfB MFA downgrade attack](https://github.com/yudasm/WHfB-o365-Phishlet)
26 |
--------------------------------------------------------------------------------
/techniques/mfa_fatigue/description.md:
--------------------------------------------------------------------------------
1 | # MFA fatigue
2 | ID: SAT1024
3 |
4 | ## Tactics
5 | * Initial Access
6 |
7 | ## Summary
8 | One of the most common implementations of MFA is using push notifications to a mobile device that allow the user to approve or deny the login request. This is generally the most user friendly approach as a user can authenticate with the push of a button from their phone lock screen, without needing to read a code from another app and type it in anywhere.
9 |
10 | An adversary can exploit this process by continually making login requests with compromised credentials at inconvenient times (e.g. the middle of the night) or generally with an annoying frequency. Even if the user initially rejects the push notifications initially it can quickly become infuriating to receive ongoing push notifications and lead to an assumption that perhaps something legitimate is continually failing to authenticate and just needs to be approved to make the problem go away.
11 |
12 | Eventually, the user only needs to click to approve the login once, whether through mistake or frustration, and the adversary will gain access to their account.
13 |
14 | ## Examples
15 |
16 |
17 | ## References
18 | * [Uber breach by Lapsus$](https://www.darkreading.com/attacks-breaches/uber-breach-external-contractor-mfa-bombing-attack)
19 | * [MITRE ATT&CK - MFA Request Generation](https://attack.mitre.org/techniques/T1621/)
20 |
--------------------------------------------------------------------------------
/techniques/noauth/description.md:
--------------------------------------------------------------------------------
1 | # nOAuth
2 | ID: SAT1025
3 |
4 | ## Tactics
5 | * Initial Access
6 |
7 | ## Summary
8 |
9 | SaaS apps that make use of OAuth integrations require an identifier to match accounts between the application and identity provider. The OAuth specification states that a user should be identified by the subject claim. The subject claim is an immutable identifier and not an attribute that a user can alter. However, apps can be configured to identify users via other claims (in other words account metadata/attributes), which can lead to unintended consequences.
10 |
11 | nOAuth is a common misconfiguration where apps use the 'email' claim to identify users instead of the subject claim.
12 |
13 | An adversary could create their own tenant and set the 'email' attribute on their account to match their target's email address. This would allow them to authenticate to any vulnerable SaaS app where the target has an account.
14 |
15 | ## Examples
16 | * [AzureAD](examples/azuread.md)
17 |
18 | ## References
19 |
20 | * [nOAuth: How Microsoft OAuth Misconfiguration Can Lead to Full Account Takeover](https://www.descope.com/blog/post/noauth)
--------------------------------------------------------------------------------
/techniques/noauth/examples/azuread.md:
--------------------------------------------------------------------------------
1 | # nOAuth attack on AzureAD
2 |
3 | Changing the email address of a user to one not belonging to the tenant is trivial in Microsoft Azure. The image below shows a spoofed email configured for the user account.
4 |
5 | 
--------------------------------------------------------------------------------
/techniques/noauth/examples/azuread.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/noauth/examples/azuread.png
--------------------------------------------------------------------------------
/techniques/oauth_token_enumeration/description.md:
--------------------------------------------------------------------------------
1 | # OAuth token enumeration
2 | ID: SAT1026
3 |
4 | ## Tactics
5 | * Discovery
6 |
7 | ## Summary
8 | SaaS app users may have authenticated using OIDC (social logins) or have created other OAuth integrations to share data and make better use of the app. If an adversary has compromised a user’s account, they can list out existing OAuth integrations to identify other SaaS apps in use.
9 |
10 | This may allow an adversary to target those apps for lateral movement or better target those apps for attack.
11 |
12 | ## Examples
13 | * [Google](examples/google.md)
14 | * [Microsoft](examples/microsoft.md)
15 |
16 | ## References
--------------------------------------------------------------------------------
/techniques/oauth_token_enumeration/examples/google.md:
--------------------------------------------------------------------------------
1 | # OAuth token lookup on Google
2 |
3 | Active OAuth tokens are visible for Google accounts on the account security dashboard at https://myaccount.google.com/:
4 |
5 | 
--------------------------------------------------------------------------------
/techniques/oauth_token_enumeration/examples/google.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/oauth_token_enumeration/examples/google.png
--------------------------------------------------------------------------------
/techniques/oauth_token_enumeration/examples/microsoft.md:
--------------------------------------------------------------------------------
1 | # OAuth token lookup on Microsoft
2 |
3 | Installed apps are visible on Microsoft by visiting https://myapps.microsoft.com/:
4 |
5 | 
6 |
--------------------------------------------------------------------------------
/techniques/oauth_token_enumeration/examples/microsoft.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/oauth_token_enumeration/examples/microsoft.png
--------------------------------------------------------------------------------
/techniques/oauth_tokens/description.md:
--------------------------------------------------------------------------------
1 | # OAuth tokens
2 | ID: SAT1027
3 |
4 | ## Tactics
5 | * Execution
6 | * Persistence
7 |
8 |
9 | ## Summary
10 | An adversary can use a malicious OAuth app or API development tool to create an OAuth token, using arbitrary permissions to maintain long-term programmatic access to a compromised user account.
11 |
12 | SaaS apps typically use OAuth tokens to grant access to app APIs, normally in the context of the user creating the token. Long term access is maintained through refresh tokens, which typically never expire. Refresh tokens can be used to generate short-lived access tokens, which are used to query the API. These tokens generally continue working after password changes and do not require MFA, resulting in a very effective way to maintain control over a compromised user account.
13 |
14 | To get access to a raw refresh token after compromising a SaaS account, an adversary could create an integration with a malicious app they control. Most SaaS apps that support OAuth integrations provide SDKs and examples for creating these apps, and many don’t require verification or any security checks before publishing OAuth apps. An alternative method of creating and accessing OAuth tokens is through the use of in-browser API test utilities.
15 |
16 | Because the app is controlled by the adversary, the requested scopes or permissions attached to the created token are chosen by the adversary, and are typically limited only by the scopes the app developer has made available.
17 |
18 | ## Examples
19 | * [Microsoft Graph Explorer](examples/graph_explorer.md)
20 | * [Slack API tester](examples/slack_api_tester.md)
21 |
22 | ## References
23 |
24 | * [Microsoft blog - Threat actors misuse OAuth applications to automate financially driven attacks](https://www.microsoft.com/en-us/security/blog/2023/12/12/threat-actors-misuse-oauth-applications-to-automate-financially-driven-attacks/)
25 | * [Microsoft blog - Midnight Blizzard using OAuth for persistence in attack against MS](https://www.microsoft.com/en-us/security/blog/2024/01/25/midnight-blizzard-guidance-for-responders-on-nation-state-attack/)
26 |
--------------------------------------------------------------------------------
/techniques/oauth_tokens/examples/graph_explorer.md:
--------------------------------------------------------------------------------
1 | # Create refresh token with Microsoft Graph Explorer
2 |
3 | Graph Explorer is typically used to test queries and Graph-related functionality within Azure tenants. If an adversary gained access to a user’s credentials, they could create a refresh token by signing into Graph Explorer and extracting the token from the browser’s local storage:
4 |
5 | 
6 |
7 | It would be equally simple to create a custom Graph API client using the Microsoft SDKs, but this method requires zero custom code and looks like a legitimate Microsoft app (because it is).
--------------------------------------------------------------------------------
/techniques/oauth_tokens/examples/graph_explorer.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/oauth_tokens/examples/graph_explorer.png
--------------------------------------------------------------------------------
/techniques/oauth_tokens/examples/slack_api_tester.md:
--------------------------------------------------------------------------------
1 | # Make API calls using the Slack API tester
2 |
3 | The Slack API Tester can be used to test different API calls, such as retrieving user listings, posting messages to channels or via DM, and even assigning administrator privileges to accounts, depending on the Slack tenant’s licensing level.
4 |
5 | A bot token is required, which can be created and installed to Slack instances by default by any user. With this in hand, any supported API call can be used without raising suspicion.
6 |
7 | 
--------------------------------------------------------------------------------
/techniques/oauth_tokens/examples/slack_api_tester.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/oauth_tokens/examples/slack_api_tester.png
--------------------------------------------------------------------------------
/techniques/password_scraping/description.md:
--------------------------------------------------------------------------------
1 | # Password scraping
2 | ID: SAT1028
3 |
4 | ## Tactics
5 | * Credential Access
6 |
7 | ## Summary
8 |
9 | While it may not be security good practice, many teams stored passwords in cleartext, especially shared or system credentials. This could be passwords stored in files that are hosted in SaaS file stores, passwords noted in wikis or ticketing systems or passwords sent in emails during registration processes or as a result of forgotten password functionality.
10 |
11 | One more modern example is that some SaaS apps allow passwordless email-based authentication, where a OTP is sent via email when a login is requested, rather than a user having a standard password.
12 |
13 | An adversary could search for passwords via compromised apps in order to discover passwords that may allow them to move laterally to other apps and potentially as different user accounts too.
14 |
15 | Additionally, cloud password managers are ripe targets for password scraping as compromising a cloud identity that allows direct access to a cloud password manager can enable large-scale password scraping.
16 |
17 |
18 | ## Examples
19 | * [Okta](examples/okta.md)
20 | * [Canva](examples/canva.md)
21 |
22 |
23 | ## References
24 | * [MITRE ATT&CK - Unsecured Credentials](https://attack.mitre.org/techniques/T1552/)
25 | * [Abusing Okta SWA - Technical blog post](https://pushsecurity.com/blog/okta-swa/)
26 | * [Can my admins steal my cloud password manager secrets? - Technical blog post](https://pushsecurity.com/blog/can-my-admins-steal-my-cloud-password-manager-secrets/)
27 |
--------------------------------------------------------------------------------
/techniques/password_scraping/examples/canva.md:
--------------------------------------------------------------------------------
1 | # Passwordless login in [Canva](https://canva.com)
2 |
3 | Canva is one modern example that defaults to email-based passwordless authentication for accounts. An adversary with email access would be able to move laterally to this system by triggering the login process and accessing the resultant email.
4 |
5 | 
6 | 
--------------------------------------------------------------------------------
/techniques/password_scraping/examples/canva_email.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/password_scraping/examples/canva_email.png
--------------------------------------------------------------------------------
/techniques/password_scraping/examples/canva_login.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/password_scraping/examples/canva_login.png
--------------------------------------------------------------------------------
/techniques/password_scraping/examples/okta.md:
--------------------------------------------------------------------------------
1 | # Okta SWA password scraping
2 |
3 | Okta supports true SSO mechanisms like SAML and OIDC but also has an authentication method called SWA that operates more like a password manager. Administrators can restrict users from seeing their underlying passwords by disabling the "password reveal" feature if they like. However, it's possible to bypass this even if it is configured.
4 |
5 | Consequently, an adversary compromising an Okta account can extract passwords to access all apps that have been configured using Okta SWA in order to maintain longer-term persistent access and potentially uncover passwords that are also shared with other accounts.
6 |
7 | Full details can be found in the following blog post:
8 |
9 | https://pushsecurity.com/blog/okta-swa/
10 |
--------------------------------------------------------------------------------
/techniques/passwordless_logins/description.md:
--------------------------------------------------------------------------------
1 | # Passwordless logins
2 | ID: SAT1029
3 |
4 | ## Tactics
5 | * Lateral Movement
6 |
7 | ## Summary
8 | Some SaaS apps allow passwordless email-based authentication, where an OTP is sent via email when a login is requested, rather than a user having a standard password.
9 |
10 | An adversary with email access could laterally move to other SaaS apps that support this login type. This technique has the added benefit of avoiding detection due to a user noticing that their credentials have been altered.
11 |
12 | ## Examples
13 | * [Canva](examples/canva.md)
14 | * [Slack](examples/slack.md)
15 | * [Expensify](examples/expensify.md)
16 | ## References
--------------------------------------------------------------------------------
/techniques/passwordless_logins/examples/canva.md:
--------------------------------------------------------------------------------
1 | # Canva
2 |
3 | Canva is one example of a popular SaaS app that defaults to email-based passwordless authentication for accounts. An adversary with email access would be able to move laterally to this system by triggering the login process and accessing the resultant email.
4 |
5 | 
6 | 
7 |
--------------------------------------------------------------------------------
/techniques/passwordless_logins/examples/canva_1.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/passwordless_logins/examples/canva_1.png
--------------------------------------------------------------------------------
/techniques/passwordless_logins/examples/canva_2.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/passwordless_logins/examples/canva_2.png
--------------------------------------------------------------------------------
/techniques/passwordless_logins/examples/expensify.md:
--------------------------------------------------------------------------------
1 | # Passwordless logins on [Expensify](https://www.expensify.com/)
2 |
3 | 
4 | 
--------------------------------------------------------------------------------
/techniques/passwordless_logins/examples/expensify1.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/passwordless_logins/examples/expensify1.png
--------------------------------------------------------------------------------
/techniques/passwordless_logins/examples/expensify2.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/passwordless_logins/examples/expensify2.png
--------------------------------------------------------------------------------
/techniques/passwordless_logins/examples/slack.md:
--------------------------------------------------------------------------------
1 | # Slack
2 |
3 | Slack is another example of a SaaS app that provides passwordless login via a code sent to a user’s email address.
4 |
5 | 
6 | 
--------------------------------------------------------------------------------
/techniques/passwordless_logins/examples/slack_1.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/passwordless_logins/examples/slack_1.png
--------------------------------------------------------------------------------
/techniques/passwordless_logins/examples/slack_2.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/passwordless_logins/examples/slack_2.png
--------------------------------------------------------------------------------
/techniques/poisoned_tenants/description.md:
--------------------------------------------------------------------------------
1 | # Poisoned tenants
2 | ID: SAT1030
3 |
4 | ## Tactics
5 | * Initial Access
6 |
7 | ## Summary
8 |
9 | An adversary can register a new tenant that it controls and administers with the intent of tricking users to join it, by convincing them it is owned by their organization.
10 |
11 | This often means the adversary will have access to all data within the SaaS tenant and may be able to abuse employee-created OAuth or API integrations with other SaaS apps. Targeting SaaS apps that require or encourage users to create integrations with sensitive assets (such as their mailbox) during signup are more likely to yield useful data for the adversary.
12 |
13 | In many cases, execution of such an attack will take careful social engineering. However, invite functionality and automatic account association features often found in SaaS apps can make this attack easier to perform. Some SaaS vendors even automatically prompt a user to join a tenant when they sign up to the app if an invite has previously been sent (even if they ignored the invitation itself) increasing the longevity and chance of a successful attack.
14 |
15 | Adversaries may use other techniques to make poisoned tenants appealing to users, such as upgrading the tenant to a higher license tier, unlocking useful features.
16 |
17 | A demo video of an attack chain combining a poisoned tenant with a [SAMLjacking](/techniques/samljacking/description.md) attack is given below:
18 |
19 | [](https://www.youtube.com/watch?v=4gAeSxbycXU)
20 |
21 | ## Examples
22 | * [Trello](examples/trello.md)
23 | * [Nuclino](examples/nuclino.md)
24 |
25 | ## References
26 | * [SAMLjacking a poisoned tenant - Technical blog post](https://pushsecurity.com/blog/samljacking-a-poisoned-tenant/)
27 |
--------------------------------------------------------------------------------
/techniques/poisoned_tenants/examples/nuclino.md:
--------------------------------------------------------------------------------
1 | # Poisoned tenant invite for Nuclino
2 |
3 | Nuclino lets you invite users by email or by sending sharing links. The invite emails Nuclino sends also do not show the email address of the adversary, only their display name, which is great for social engineering.
4 |
5 | 
6 | 
7 | 
8 |
9 |
--------------------------------------------------------------------------------
/techniques/poisoned_tenants/examples/nuclino_email.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/poisoned_tenants/examples/nuclino_email.png
--------------------------------------------------------------------------------
/techniques/poisoned_tenants/examples/nuclino_invite.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/poisoned_tenants/examples/nuclino_invite.png
--------------------------------------------------------------------------------
/techniques/poisoned_tenants/examples/nuclino_sharing.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/poisoned_tenants/examples/nuclino_sharing.png
--------------------------------------------------------------------------------
/techniques/poisoned_tenants/examples/trello.md:
--------------------------------------------------------------------------------
1 | # Poisoned tenant invite for Trello
2 |
3 | Trello lets you add a customized message to the invite and doesn’t show the email address of the adversary, which makes it ideal for social engineering.
4 |
5 | 
--------------------------------------------------------------------------------
/techniques/poisoned_tenants/examples/trello.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/poisoned_tenants/examples/trello.png
--------------------------------------------------------------------------------
/techniques/saml_enumeration/description.md:
--------------------------------------------------------------------------------
1 | # SAML enumeration
2 | ID: SAT1031
3 |
4 | ## Tactics
5 | * Reconnassiance
6 |
7 | ## Summary
8 |
9 | It’s often possible to determine if an organization is using a SaaS app by checking whether a SAML login IdP has been configured for the organization domain.
10 |
11 | Where a dedicated SAML IdP endpoint has been configured, a SaaS app usually needs to map certain logins to that endpoint under certain conditions. Commonly, this will be based on the email domain of the user account, or based on a subdomain or path-based tenant separation.
12 |
13 | If SAML is used, adversaries can discover whether a target organization is using a SaaS app and what their SAML provider is by making login attempts using their email domain, or by making login attempts via subdomains or path-based tenants based on the organization name.
14 |
15 |
16 | ## Examples
17 | * [Ramp](examples/ramp.md)
18 | * [Expensify](examples/expensify.md)
19 |
20 | ## References
--------------------------------------------------------------------------------
/techniques/saml_enumeration/examples/expensify.md:
--------------------------------------------------------------------------------
1 | # SAML enumeration on [Expensify](https://expensify.com)
2 |
3 | There are at least two places that you can enumerate SAML configuration within Expensify.
4 |
5 | ## SAML configured login page
6 |
7 | If you make a GET request to the SAML login callback method, the friendly error message will be different depending on if it is a domain that has SAML authentication configured or not.
8 |
9 | https://www.expensify.com/authentication/saml/loginCallback?domain=ctrlaltsecure.com
10 |
11 | ### Valid SAML domain
12 | 
13 |
14 | ### Invalid SAML domain
15 | 
16 |
17 | ## Login page
18 |
19 | When attempting an email based login, the details that come back indicate whether SAML is supported for the email domain, even if the specific email address is not in use.
20 |
21 | 
22 |
23 | 
24 |
25 | 
--------------------------------------------------------------------------------
/techniques/saml_enumeration/examples/expensify_saml1.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/saml_enumeration/examples/expensify_saml1.png
--------------------------------------------------------------------------------
/techniques/saml_enumeration/examples/expensify_saml2.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/saml_enumeration/examples/expensify_saml2.png
--------------------------------------------------------------------------------
/techniques/saml_enumeration/examples/expensify_saml3.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/saml_enumeration/examples/expensify_saml3.png
--------------------------------------------------------------------------------
/techniques/saml_enumeration/examples/expensify_saml4.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/saml_enumeration/examples/expensify_saml4.png
--------------------------------------------------------------------------------
/techniques/saml_enumeration/examples/expensify_saml5.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/saml_enumeration/examples/expensify_saml5.png
--------------------------------------------------------------------------------
/techniques/saml_enumeration/examples/ramp.md:
--------------------------------------------------------------------------------
1 | # SAML enumeration on [Ramp](https://ramp.com)
2 |
3 | Ramp provides the ability to login via username/password, via Google social login or via SSO. If you login via SSO, the app will use the domain associated with the email in order to map to the correct SSO provider.
4 |
5 | In the instances below, note the difference between using a test domain that does not have SSO configured and using the domain for an organization that configured SSO authentication via Okta.
6 |
7 | 
8 | 
9 | 
10 | 
--------------------------------------------------------------------------------
/techniques/saml_enumeration/examples/ramp_no_saml.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/saml_enumeration/examples/ramp_no_saml.png
--------------------------------------------------------------------------------
/techniques/saml_enumeration/examples/ramp_saml.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/saml_enumeration/examples/ramp_saml.png
--------------------------------------------------------------------------------
/techniques/saml_enumeration/examples/ramp_saml_details.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/saml_enumeration/examples/ramp_saml_details.png
--------------------------------------------------------------------------------
/techniques/saml_enumeration/examples/ramp_sso_not_configured.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/saml_enumeration/examples/ramp_sso_not_configured.png
--------------------------------------------------------------------------------
/techniques/samljacking/description.md:
--------------------------------------------------------------------------------
1 | # SAMLjacking
2 | ID: SAT1032
3 |
4 | ## Tactics
5 | * Initial Access
6 | * Lateral Movement
7 |
8 | ## Summary
9 |
10 | When configuring SAML integrations for a SaaS app, you must provide a URL to an IdP service so the app can hand-off authentication during the SAML flow. Users expect to be redirected to common SSO login pages (e.g. Google or Microsoft login), and are unlikely to check that the login URL they are redirected to matches the official domain.
11 |
12 | An adversary could configure an app tenant with SAML and configure the URL to point to a credential phishing page that looks like or proxies a legitimate authentication service (e.g. Google or Microsoft).
13 |
14 | The adversary could target users by sending seemingly legitimate links to the app login page to the tenant. This attack can be made more effective by naming the tenant something familiar for the target (few apps restrict the names of tenants) and using in-app invite mechanisms to lure victims to the tenant.
15 |
16 | A demo video of an attack chain combining SAMLjacking with a [poisoned tenant](/techniques/poisoned_tenants/description.md) is given below:
17 |
18 | [](https://www.youtube.com/watch?v=4gAeSxbycXU)
19 |
20 | ## Examples
21 | * [Nuclino](examples/nuclino.md)
22 | * [Datadog](examples/datadog.md)
23 |
24 | ## References
25 | * [Evilginx - MITM framework for phishing login credentials](https://github.com/kgretzky/evilginx2)
26 | * [SAMLjacking a poisoned tenant - Technical blog post](https://pushsecurity.com/blog/samljacking-a-poisoned-tenant/)
--------------------------------------------------------------------------------
/techniques/samljacking/examples/datadog.md:
--------------------------------------------------------------------------------
1 | # SAMLjacking on [Datadog](https://https://www.datadoghq.com/)
2 |
3 | Datadog allows SAML integrations even on their free tier, so makes a great test case.
4 |
5 | 
6 |
7 | Datadog requires you to upload a metadata XML file, rather than fill in individual field. This is available as a download option for common SAML providers like Google.
8 |
9 | 
10 |
11 | Any redirection URLs can be given in this file to direct a target to whatever phishing URL the adversary would like. In this case, we are just showing a test of directing a target to the wikipedia page for phishing.
12 |
13 | 
14 |
15 | A unique organization login URL will be given by Datadog that then immediately redirects to the configured URL when visited.
16 |
17 | https://app.datadoghq.eu/account/login/id/3286e9ee-385f-11ee-9ba0-da7ad0900005
18 |
--------------------------------------------------------------------------------
/techniques/samljacking/examples/datadog1.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/samljacking/examples/datadog1.png
--------------------------------------------------------------------------------
/techniques/samljacking/examples/datadog2.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/samljacking/examples/datadog2.png
--------------------------------------------------------------------------------
/techniques/samljacking/examples/datadog3.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/samljacking/examples/datadog3.png
--------------------------------------------------------------------------------
/techniques/samljacking/examples/nuclino.md:
--------------------------------------------------------------------------------
1 | # SAMLjacking on [Nuclino](https://nuclino.com/)
2 |
3 | Nuclino allows SAML integrations even on their free tier, so makes a great test case. This is the SAML configuration page (showing the SSO URL):
4 |
5 | 
6 |
7 | The adversary could set the tenant name to match the target (e.g “Ctrlaltsecure” targeting ctrlaltsecure.com):
8 | https://app.nuclino.com/Ctrlaltsecure
9 |
10 | The target would then see this legitimate login page:
11 |
12 | 
13 |
14 | When clicking login, the user would be redirected to a legitimate-looking phishing page:
15 |
16 | 
17 |
18 | A demo video of an attack chain combining SAMLjacking with a poisoned tenant using Nuclino is given below:
19 |
20 | [](https://www.youtube.com/watch?v=4gAeSxbycXU)
--------------------------------------------------------------------------------
/techniques/samljacking/examples/nuclino_login.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/samljacking/examples/nuclino_login.png
--------------------------------------------------------------------------------
/techniques/samljacking/examples/nuclino_phishing.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/samljacking/examples/nuclino_phishing.png
--------------------------------------------------------------------------------
/techniques/samljacking/examples/nuclino_saml.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/samljacking/examples/nuclino_saml.png
--------------------------------------------------------------------------------
/techniques/session_cookie_theft/description.md:
--------------------------------------------------------------------------------
1 | # Session cookie theft
2 | ID: SAT1044
3 |
4 | ## Tactics
5 | * Lateral Movement
6 | * Defense Evasion
7 |
8 | ## Summary
9 |
10 | Due to increasing use of SaaS apps, core identity providers acting as SSO gateways to them, and the widespread adoption of MFA, hybrid attacks involving the theft of valid browser session cookies from compromised endpoints using infostealing malware are becoming more common. These session cookies are then used to pivot from an endpoint compromise and laterally move to downstream SaaS applications. They are typically imported into an adversary's own browser and then used to resume access to the authenticated session without re-authenticating.
11 |
12 | Previously, endpoint compromises would have often involved credential dumping and been focused on lateral movement to other endpoints or internal servers. Now there is an increasing drive to move to SaaS applications instead. Widespread MFA use makes captured passwords less useful alone and so stealing authenticated session cookies is a valid method to circumvent MFA. This can even potentially circumvent modern phishing-resistant MFA factors such as passkeys as it can circumvent the requirement to re-authenticate entirely.
13 |
14 | Session cookies for any SaaS application are useful but when valid sessions for core IdPs are compromised then adversaries will typically be able to laterally move to a large number of downstream SaaS applications by abusing SSO mechanisms like SAML and OIDC. Vendor-specific technologies like Okta SWA will also allow direct credential compromise for other downstream SaaS applications.
15 |
16 | While adversaries may steal cookies directly using compromised endpoints, stolen cookies have also become available for sale in the criminal world from infostealing malware, therefore it may be possible to directly purchase cookies for use. More information of the criminal ecosystem can be found in this [blog post](https://blog.sekoia.io/traffers-a-deep-dive-into-the-information-stealer-ecosystem/) and more information on a variety of stealer malware families can be found in this [threat report](https://news.sophos.com/en-us/2024/03/12/2024-sophos-threat-report/).
17 |
18 | This technique is related to, but distinct from, [AitM Phishing](/techniques/aitm_phishing/description.md), which seeks to compromise sessions to circumvent MFA as an initial access vector.
19 |
20 | ## References
21 |
22 | * [MITRE ATT&CK - Browser Session Hijacking](https://attack.mitre.org/techniques/T1185/)
23 | * [2024 Sophos Threat Report](https://news.sophos.com/en-us/2024/03/12/2024-sophos-threat-report/)
24 | * [Traffers - a deep dive into the information stealer ecosystem](https://blog.sekoia.io/traffers-a-deep-dive-into-the-information-stealer-ecosystem/)
25 |
--------------------------------------------------------------------------------
/techniques/shadow_workflows/description.md:
--------------------------------------------------------------------------------
1 | # Shadow workflows
2 | ID: SAT1033
3 |
4 | ## Tactics
5 | * Execution
6 | * Exfiltration
7 |
8 | ## Summary
9 |
10 | The SaaS world is, by design, largely abstracted away from operating systems and application binaries. There isn’t always a generic equivalent of gaining code execution as you might during an endpoint compromise.
11 |
12 | The closest approximation to this in the SaaS world may be low- or no-code automation apps. These are SaaS apps that are focused on integrating with a variety of other SaaS apps and allow the user to automate common tasks. In no-code apps this is done using easy-to-learn UI components that abstract code, where low-code flavors provide scaffolding to minimize code. The user created functions are often called automations, workflows or playbooks.
13 |
14 | An adversary with access to a target SaaS account can configure a workflow automation to execute a wide range of malicious actions against the breached account. This could be a daily export of files from shared cloud drives, automatic forwarding and deleting of emails, cloning instant messages, exporting user directories. Basically anything that is possible using the target app’s API.
15 |
16 | While the graphical interface is useful for non-technical users, many of these automation platforms allow advanced users to craft direct API calls (often called low-code), which unlocks enormous flexibility for adversaries.
17 |
18 | Akin to traditional endpoint “Living Off The Land” (LOTL) techniques such as PowerShell, an adversary may use these legitimate, well-known SaaS automation apps rather than custom OAuth integrations to avoid detection.
19 |
20 | A demo video of an attack chain combining a shadow workflow with an [evil twin integration](/techniques/evil_twin_integrations/description.md) is given below:
21 |
22 | [](https://www.youtube.com/watch?v=g2EITjjJH1s)
23 |
24 | ## Examples
25 | * [Zapier](examples/zapier.md)
26 | * Microsoft Power Automate
27 |
28 | ## References
29 |
30 | * [Living off the Cloud. Cloudy with a Chance of Exfiltration](https://www.pentestpartners.com/security-blog/living-off-the-cloud-cloudy-with-a-chance-of-exfiltration/)
31 | * [MITRE ATT&CK - Automated Exfiltration](https://attack.mitre.org/techniques/T1020/)
32 | * [The shadow workflow's evil twin - Technical blog post](https://pushsecurity.com/blog/nearly-invisible-attack-chain/)
33 | * [Slack Attack: A phisher's guide to persistence and lateral movement](https://pushsecurity.com/blog/phishing-slack-persistence/)
34 | * [Octo Tempest use FiveTran to steal SalesForce and ZenDesk databases](https://www.microsoft.com/en-us/security/blog/2023/10/25/octo-tempest-crosses-boundaries-to-facilitate-extortion-encryption-and-destruction/)
35 |
--------------------------------------------------------------------------------
/techniques/shadow_workflows/examples/zapier.md:
--------------------------------------------------------------------------------
1 | # Shadow workflow with Zapier to forward and delete account recovery emails
2 |
3 | While the possibilities are nearly endless, one example would be replicating malicious mail rules via an automation app. The screenshots below show how an adversary could use Zapier automations to capture emails and delete them if they contain keywords such as “password reset”.
4 |
5 |
6 | 
7 | 
8 |
--------------------------------------------------------------------------------
/techniques/shadow_workflows/examples/zapier1.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/shadow_workflows/examples/zapier1.png
--------------------------------------------------------------------------------
/techniques/shadow_workflows/examples/zapier2.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/shadow_workflows/examples/zapier2.png
--------------------------------------------------------------------------------
/techniques/slug_tenant_enumeration/description.md:
--------------------------------------------------------------------------------
1 | # Slug tenant enumeration
2 | ID: SAT1034
3 |
4 | ## Tactics
5 | * Reconnassiance
6 |
7 | ## Summary
8 | SaaS vendors make use of different strategies to separate tenants from one another. Often, this is based on the creation of a “slug” chosen by the user during tenant creation. This is used as either a path separator, query parameter, or subdomain to separate tenants.
9 |
10 | There are often methods within a SaaS app that allow existing slugs to be enumerated, for example, when attempting to create a new tenant the app may error stating that a tenant with that slug already exists.
11 |
12 | It is common for the organization name itself to be used, or something very close to it, so querying a number of variations of the organization name is often a method for discovering if a SaaS app is in use and what the tenant name is.
13 |
14 |
15 | ## Examples
16 | * [BambooHR](examples/bamboohr.md)
17 |
18 | ## References
19 | * [MITRE ATT&CK - Wordlist Scanning](https://attack.mitre.org/techniques/T1595/003/)
20 |
--------------------------------------------------------------------------------
/techniques/slug_tenant_enumeration/examples/bamboohr.md:
--------------------------------------------------------------------------------
1 | # Slug tenant enumeration on [BambooHR](https://www.bamboohr.com/)
2 |
3 | This issue is present within the login process where it asks for the BambooHR tenant name in order to direct to the correct login page. This results in background requests that can be used to determine if a name is already taken or not:
4 |
5 | ```
6 | % curl -XGET "https://app.bamboohr.com/ajax/domain.php?test=invalidcustomer"
7 | {"taken":false}%
8 | % curl -XGET "https://app.bamboohr.com/ajax/domain.php?test=soundcloud"
9 | {"taken":true}%
10 | ```
11 |
12 | 
13 | 
14 | 
15 |
--------------------------------------------------------------------------------
/techniques/slug_tenant_enumeration/examples/bamboohr_invalid_slug.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/slug_tenant_enumeration/examples/bamboohr_invalid_slug.png
--------------------------------------------------------------------------------
/techniques/slug_tenant_enumeration/examples/bamboohr_successful_redirect.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/slug_tenant_enumeration/examples/bamboohr_successful_redirect.png
--------------------------------------------------------------------------------
/techniques/slug_tenant_enumeration/examples/bamboohr_valid_slug.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/slug_tenant_enumeration/examples/bamboohr_valid_slug.png
--------------------------------------------------------------------------------
/techniques/subdomain_tenant_discovery/description.md:
--------------------------------------------------------------------------------
1 | # Subdomain tenant discovery
2 | ID: SAT1035
3 |
4 | ## Tactics
5 | * Reconnassiance
6 |
7 | ## Summary
8 | SaaS vendors make use of different strategies to separate different tenants from one another. One of these methods is the use of a unique subdomain, which is often picked during the creation of a new tenant.
9 |
10 | Consequently, DNS enumeration techniques to discover valid subdomains can give an insight into who uses a given SaaS app. For example, adversaries can use DNS brute forcing or passive DNS enumeration to discover this information.
11 |
12 | It’s common for the organization name itself to be used, making it easy to discover these tenant names or subdomains.
13 |
14 | ## Examples
15 | * [BambooHR](examples/bamboohr.md)
16 |
17 | ## References
18 | * [MITRE ATT&CK - Wordlist Scanning](https://attack.mitre.org/techniques/T1595/003/)
19 |
--------------------------------------------------------------------------------
/techniques/subdomain_tenant_discovery/examples/bamboohr.md:
--------------------------------------------------------------------------------
1 | # Subdomain discovery on [BambooHR](https://www.bamboohr.com/)
2 |
3 | Using passive DNS discovery tools we can see valid subdomains, many of which correspond to BambooHR tenants. The screenshot below shows a small fraction of approximately 15,000 subdomains observed in one passive DNS source:
4 |
5 | 
--------------------------------------------------------------------------------
/techniques/subdomain_tenant_discovery/examples/bamboohr.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/subdomain_tenant_discovery/examples/bamboohr.png
--------------------------------------------------------------------------------
/techniques/system_integrations/description.md:
--------------------------------------------------------------------------------
1 | # System integrations
2 | ID: SAT1036
3 |
4 | ## Tactics
5 | * Persistence
6 | * Defense Evasion
7 |
8 | ## Summary
9 | Some SaaS apps allow OAuth integrations that are not tied to a user account, but to the app tenant, or a machine account instead. Since the integration is not tied to a specific user, persistence can be maintained after a user account has been disabled or deleted.
10 |
11 | It can also frustrate forensics by obfuscating which user account is responsible for actions taken by the integration, particularly when that relates to a user account that has since been deleted. This is somewhat equivalent to migrating to a system process in an endpoint attack.
12 |
13 | In some cases, app-level integrations require administrative permissions but in others a standard user can do this, resulting in a more significant threat.
14 |
15 | ## Examples
16 | * [Slack](examples/slack.md)
17 |
18 | ## References
19 | * [Slack Attack: A phisher's guide to persistence and lateral movement](https://pushsecurity.com/blog/phishing-slack-persistence/)
20 | * [Slack Jack - A tool for Slack bot token abuse](https://github.com/adelapazborrero/slack_jack?tab=readme-ov-file)
21 |
--------------------------------------------------------------------------------
/techniques/system_integrations/examples/slack.md:
--------------------------------------------------------------------------------
1 | # Slack
2 |
3 | * [Slack Attack: A phisher's guide to persistence and lateral movement](https://pushsecurity.com/blog/phishing-slack-persistence/)
4 |
5 | Slack is a great example of this as it permits standard users to add app integrations by default. Worse, it also separates OAuth tokens for apps into user tokens and bot tokens. User tokens are tied to the user account and become invalidated when a user account is disabled. However, bot tokens are tied to the app, so they persist even when the original user account is disabled.
6 |
7 | For example, the automation app Make.com can be integrated with Slack by a standard user, which then provides access to the user and bot tokens separately. This means that Make.com can be used to perform actions on Slack – such as messaging users with phishing links. These actions are detached from the original user account and continue to operate after the account is disabled.
8 |
9 | Make.com, like many automation apps, also allows you to fully customize the name and icon for the bot when messaging, making it useful for impersonation. The only giveaway is the “APP” tag after the account and if you click on the user it takes you to the Make.com bot account instead (Integromat, from a former merger).
10 |
11 | 
12 | 
13 | 
--------------------------------------------------------------------------------
/techniques/system_integrations/examples/slack_app_info.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/system_integrations/examples/slack_app_info.png
--------------------------------------------------------------------------------
/techniques/system_integrations/examples/slack_integration.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/system_integrations/examples/slack_integration.png
--------------------------------------------------------------------------------
/techniques/system_integrations/examples/slack_message.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/system_integrations/examples/slack_message.png
--------------------------------------------------------------------------------
/techniques/takeout_services/description.md:
--------------------------------------------------------------------------------
1 | # Takeout services
2 | ID: SAT1037
3 |
4 | ## Tactics
5 | * Exfiltration
6 |
7 | ## Summary
8 | Takeout services allow users to export all of their data from a SaaS app into a downloadable format. This is often used to satisfy compliance with GDPR which requires that data subjects maintain ownership of their data.
9 |
10 | An adversary can make use of this functionality to quickly and easily exfiltrate a very complete set of data from a SaaS app.
11 |
12 | ## Examples
13 | * [Google](examples/google.md)
14 |
15 | ## References
--------------------------------------------------------------------------------
/techniques/takeout_services/examples/google.md:
--------------------------------------------------------------------------------
1 | # Google
2 |
3 | Google Takeout is one of the most well-known examples of this:
4 |
5 | 
6 |
--------------------------------------------------------------------------------
/techniques/takeout_services/examples/google.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/takeout_services/examples/google.png
--------------------------------------------------------------------------------
/techniques/ui_redressing/description.md:
--------------------------------------------------------------------------------
1 | # UI redressing
2 | ID: SAT1049
3 |
4 | ## Tactics
5 | * Initial access
6 |
7 | ## Summary
8 | UI redressing attacks can be used to trick a user into performing an action on a legitimate application that is different to what they perceived. The classic example is Clickjacking, that operates by overlaying an invisible iframe over a malicious website. The user thinks they are clicking buttons or other elements on the visible malicious site but are actually clicking buttons in the invislbe iframe that perform actions on the target website.
9 |
10 | While Clickjacking is generally blocked by default due to modern browser controls, the discovery of [DoubleClickjacking](https://www.paulosyibelo.com/2024/12/doubleclickjacking-what.html) has increased the risk of this class of attack again. DoubleClickjacking is not protected against by default and has additionally been shown to be highly effective for performaning malicious OAuth consent grants, similar to a [consent phishing attack](/techniques/consent_phishing/description.md).
11 |
12 | ## Examples
13 | * [Salesforce](https://youtu.be/4rGvRRMrD18)
14 | * [Slack](https://youtu.be/r7qpY74jtTw)
15 | * [Shopify](https://youtu.be/DTdyvzfVPcI)
16 |
17 | ## References
18 |
19 | * [OWASP - Clickjacking](https://owasp.org/www-community/attacks/Clickjacking)
20 | * [Technical blog - DoubleClickjacking: A New Era of UI Redressing](https://www.paulosyibelo.com/2024/12/doubleclickjacking-what.html)
21 |
--------------------------------------------------------------------------------
/techniques/username_enumeration/description.md:
--------------------------------------------------------------------------------
1 | # Username enumeration
2 | ID: SAT1038
3 |
4 | ## Tactics
5 | * Reconnassiance
6 |
7 | ## Summary
8 | When attempting to authenticate to a SaaS app, the login mechanism itself may disclose whether the username/email address is a known/valid account, even if the provided password is incorrect.
9 | Since email addresses are commonly used during the authentication process and the domain associated will often give away the organization, checking known valid email address combinations for the target organization will often reveal whether the target organization is using the SaaS app, and could lead to the discovery of valid user accounts.
10 |
11 | ## Examples
12 | * [Ramp](examples/ramp.md)
13 | * [Expensify](examples/expensify.md)
14 |
15 | ## References
16 | * [MITRE ATT&CK - Account Discovery](https://attack.mitre.org/techniques/T1087/)
17 | * [Holehe - OSINT tool for finding registered accounts](https://github.com/megadose/holehe)
--------------------------------------------------------------------------------
/techniques/username_enumeration/examples/expensify.md:
--------------------------------------------------------------------------------
1 | # Username enumeration on [Expensify](https://www.expensify.com/)
2 |
3 | When attempting to authenticate to Expensify, a request to validate the account is made. This is also linked to the default authentication mechanism being passwordless logins via email. Consequently, whether the account is valid or not is indicated.
4 |
5 | 
6 | 
7 |
--------------------------------------------------------------------------------
/techniques/username_enumeration/examples/expensify1.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/username_enumeration/examples/expensify1.png
--------------------------------------------------------------------------------
/techniques/username_enumeration/examples/expensify2.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/username_enumeration/examples/expensify2.png
--------------------------------------------------------------------------------
/techniques/username_enumeration/examples/ramp.md:
--------------------------------------------------------------------------------
1 | # User enumeration on [Ramp](https://ramp.com)
2 |
3 | When attempting to authenticate to Ramp, a request is made on the backend using Google’s Identity Toolkit, which indicates whether the email address is a valid account:
4 |
5 | 
6 | 
7 | 
--------------------------------------------------------------------------------
/techniques/username_enumeration/examples/ramp_no_user.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/username_enumeration/examples/ramp_no_user.png
--------------------------------------------------------------------------------
/techniques/username_enumeration/examples/ramp_request.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/username_enumeration/examples/ramp_request.png
--------------------------------------------------------------------------------
/techniques/username_enumeration/examples/ramp_valid_user.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/pushsecurity/saas-attacks/0c63f96dac6d303bf9e2c0fcfc7fe685e2400c84/techniques/username_enumeration/examples/ramp_valid_user.png
--------------------------------------------------------------------------------
/techniques/verification_phishing/description.md:
--------------------------------------------------------------------------------
1 | # Verification phishing
2 | ID: SAT1048
3 |
4 | ## Tactics
5 | * Initial access
6 |
7 | ## Summary
8 | Email verification is sometimes used as a control, such as when registering new accounts. This is typically implemented by emailing the target user with either a clickable link for them to verify or a verification code that that they need to enter.
9 |
10 | Verification phishing is when an adversary uses phishing, or some other type of social engineering, to convince a user to click a verification link or pass them the verification code in order to defeat this control. This is most relevant when combined with [cross-idp impersonation](/techniques/cross-idp_impersonation/description.md) in order to circumvent strong SSO authentication to gain direct control of downstream SaaS applications.
11 |
12 | ## References
13 | * [Technical blog post - Verification phishing and cross-idp impersonation](https://pushsecurity.com/blog/a-new-class-of-phishing-verification-phishing-and-cross-idp-impersonation/)
--------------------------------------------------------------------------------
/techniques/webhooks/description.md:
--------------------------------------------------------------------------------
1 | # Webhooks
2 | ID: SAT1039
3 |
4 | ## Tactics
5 | * Defense Evasion
6 | * Exfiltration
7 |
8 | ## Summary
9 | Some SaaS apps allow webhooks to be configured so callbacks are made when certain events are triggered. For example, a webmail platform may allow a webhook callback when a new email is received.
10 |
11 | This is useful to an adversary looking to extract new data as it is created from that API. This could be new emails, new files, a real-time view into channels in instant messaging apps, etc.
12 |
13 | Adversaries using this technique may also evade detection controls as these are not requests made to the SaaS app (showing in logs) but rather requests to an attacker app made from the app.
14 |
15 | ## Examples
16 | * [Microsoft 365](examples/microsoft_365.md)
17 |
18 | ## References
19 | * [MITRE ATT&CK - Exfiltration Over Web Service](https://attack.mitre.org/techniques/T1567/)
20 |
--------------------------------------------------------------------------------
/techniques/webhooks/examples/microsoft_365.md:
--------------------------------------------------------------------------------
1 | # Microsoft 365
2 |
3 | Microsoft’s Graph API can be used to configure webhooks to receive change notifications for a range of different events. This could be new Outlook mail, new OneDrive files, new Teams chat messages and many more. This is a very powerful example of webhooks that could be used for ongoing data exfiltration for many different sensitive data types.
4 |
5 |
6 | https://learn.microsoft.com/en-us/graph/api/resources/webhooks?view=graph-rest-1.0
7 |
--------------------------------------------------------------------------------