{ "id": "c88d9440-59af-4974-abe5-7f27ab9ea006", "created_at": "2026-04-06T03:37:45.668366Z", "updated_at": "2026-04-10T13:12:50.185845Z", "deleted_at": null, "sha1_hash": "33ccaf117a5754d53945824d60cba356f8816f6c", "title": "I am AD FS and so can you: Attacking Active Directory Federated Services", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 46519, "plain_text": "I am AD FS and so can you: Attacking Active Directory Federated\r\nServices\r\nArchived: 2026-04-06 03:18:13 UTC\r\nGo back\r\nWith the rise in popularity of enterprise cloud applications - email, data processing, and data warehousing for\r\nexample - organizations find themselves contending with the need to securely share identity information with their\r\ncloud service providers. This talk explores one common model for this, Active Directory Federated Services, and\r\nhow it can be exploited by attackers to access cloud applications as any user, without knowing their password and\r\nwithout MFA.\r\nDESCRIPTION\r\nThis talk will take attendees on a tour of one of the most popular federated authentication solutions, Active\r\nDirectory Federated Services (AD FS). We will cover AD FS basics, reconnaissance (both pre and post-exploitation), various post-exploitation attacks, and lastly defense.\r\nThis work was inspired by CyberArk’s “Golden SAML” research blog. It expands on the work by giving a more\r\ndetailed view of AD FS, how an attacker might reconnoiter and attack AD FS, and a more service provider\r\nagnostic tooling to forge SAML tickets.\r\nIntroduction\r\nIn the last few years we have witnessed a paradigm shift in how enterprises think of the cloud. Hailed for its low-cost and low-complexity, organizations have moved a large amount of enterprise functions into the cloud. This\r\ndecentralized approach required a new model for authentication and authorization - organizations needed a way to\r\nsecurely share identity information with cloud-based partners.\r\nWe begin by giving an overview of Microsoft’s solution to this problem, Active Directory Federated Services\r\n(AD FS). Throughout the talk we will use one of the most common use-cases for AD FS, authenticating users to\r\nOffice 365 as a teaching example; however, our tooling and techniques can be applied to any federated\r\napplication.\r\nReconnaissance\r\nFirst, we will talk about some common ways you can identify if an organization is using AD FS, and some key\r\ninformation to extract from it once identified. This reconnaissance phase is from the point-of-view of an external\r\nattacker with no credentials:\r\nIdentification of external AD FS proxies (using the Office 365 portal and/or DNS is usually enough)\r\nInternal hostnames and AD names that the AD FS proxies expose\r\nhttps://www.troopers.de/troopers19/agenda/fpxwmn/\r\nPage 1 of 3\n\nMFA providers that the organization may use\r\nAuthentication methods accepted by AD FS (by requesting special metadata XML files)\r\nAttacks\r\nWe now move on to attacks against AD FS in particular. All of these attacks are from a post-exploitation\r\nstandpoint. That is we assume the attacker has already compromised the victim’s internal network, and is seeking\r\nto move into one or more of an organization’s cloud applications. Notably, none of these attacks require Domain\r\nAdministrator rights, yet could give an attacker access to any application as any user and bypass MFA! We begin\r\nby talking about identifying the internal AD FS servers:\r\nUsing DNS to identify the AD FS farm internally\r\nUsing Active Directory to identify the AD FS farm\r\nUsing Active Directory to identify the AD FS account\r\nOnce we have identified the AD FS farm we must compromise a server and pull key information from it:\r\nAcquiring and decrypting the AD FS signing material\r\nListing relying trusts (i.e. applications that trust AD FS to share identity information)\r\nObtaining the access policies and AD FS claims that a service (cloud app) is expecting\r\nFinally we will demonstrate our new tool in action. Using the extracted information, our tool will generate a\r\nforged SAML token as an arbitrary user that can then be used to authenticate to Office 365 without knowledge of\r\nthat user’s password. This attack also bypasses any MFA requirements. We will show how the tool can be used to\r\ncreate SAML tokens for arbitrary apps, given a template.\r\nBonus!\r\nWe will also demonstrate how an attacker could implant a persistent backdoor into AD FS to bypass\r\nauthentication for specific users. This attack will demonstrate code that can be placed on the AD FS server to\r\nbypass authentication and/or the two-factor step of an AD FS server using Duo’s AD FS plugin. Essentially the\r\ncode looks for specific username/password combinations and, when present authenticates the user regardless of\r\npassword or MFA validity.\r\nDefense and Detection\r\nWe will wrap up the talk by going over some ways organizations can better defend their AD FS environment. The\r\nconcepts here are fairly simple:\r\nAD FS farms should be treated with the same level of concern as your domain controllers (i.e. they should\r\nbe tier 0 devices)\r\nSome additional steps you can take with policies and claims to make tokens harder to forge (this will\r\ndepend a lot on the relying party, but we will use Office 365 as an example)\r\nIf you really want, use an HSM to store your signing keys\r\nhttps://www.troopers.de/troopers19/agenda/fpxwmn/\r\nPage 2 of 3\n\nSource: https://www.troopers.de/troopers19/agenda/fpxwmn/\r\nhttps://www.troopers.de/troopers19/agenda/fpxwmn/\r\nPage 3 of 3", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "origins": [ "web" ], "references": [ "https://www.troopers.de/troopers19/agenda/fpxwmn/" ], "report_names": [ "fpxwmn" ], "threat_actors": [], "ts_created_at": 1775446665, "ts_updated_at": 1775826770, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/33ccaf117a5754d53945824d60cba356f8816f6c.pdf", "text": "https://archive.orkl.eu/33ccaf117a5754d53945824d60cba356f8816f6c.txt", "img": "https://archive.orkl.eu/33ccaf117a5754d53945824d60cba356f8816f6c.jpg" } }