{ "id": "97063975-0d70-43c9-8939-faff71b403c8", "created_at": "2026-04-06T01:31:50.187359Z", "updated_at": "2026-04-10T13:12:11.286286Z", "deleted_at": null, "sha1_hash": "3db0bfd15f44f52ffdd7e08c254635221620753b", "title": "Observing Atlas Lion (part one): Why take control when you can enroll?", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 485849, "plain_text": "Observing Atlas Lion (part one): Why take control when you can\r\nenroll?\r\nBy Ben Nahorney, Jenni Maynard\r\nPublished: 2025-04-10 · Archived: 2026-04-06 01:28:22 UTC\r\nTL;DR\r\nAtlas Lion is a cybercrime group based out of Morocco that targets organizations issuing gift cards.\r\nWe’ve observed the group using stolen credentials to enroll attacker-controlled VMs into an organization’s\r\ndomain.\r\nThe incident highlights the importance of having automated device enrollment processes in place to set up\r\nnew devices securely.\r\nWe’ve recently observed an unusual attack technique that, while discussed in cybersecurity circles, we haven’t\r\npreviously seen put into practice in the wild. This technique could go unnoticed under the right circumstances,\r\nallowing an attacker to stay undetected for longer, simply by hiding in plain sight. This is done by using stolen\r\ncredentials to enroll new systems they control—mimicking normal workstations and servers within the targeted\r\nnetwork’s infrastructure.\r\nThe threat actor behind the attack appears to be Atlas Lion, based on indicators of compromise (IOCs) our SOC\r\nobserved during the incident. Atlas Lion is a cybercrime group based out of Morocco targeting organizations that\r\nhttps://expel.com/blog/observing-atlas-lion-part-one/\r\nPage 1 of 4\n\nissue gift cards—big-box retailers, apparel companies, restaurants, etc. The group’s primary goal appears to be\r\nredeeming or reselling the stolen gift cards they obtain during their attack campaigns.\r\nAtlas Lion is also known for having an extensive understanding of the cloud, often leveraging such infrastructure\r\nin their attacks. The group uses this knowledge to carry out reconnaissance, often reviewing internal\r\ndocumentation to learn more about the processes involved in gift card issuance. The group is also known to utilize\r\nfree cloud service trials to set up their attack infrastructure, which also allows them to easily dispose of it when the\r\ntrial expires or it’s identified as malicious.\r\nIn like an Atlas Lion…\r\nThe attack began with an SMS phishing campaign. Based on public information about this stage of the attack,\r\nAtlas Lion’s SMS messages often appear as though they come from internal resources, such as a notification that a\r\nhelpdesk ticket has been opened for the user. These messages include a malicious link designed to look similar to\r\nthe target organization’s domain. \r\nIf the recipient clicks the link, they are brought to a phishing site designed to mimic the look and feel of the\r\norganization’s legitimate pages. If they input their credentials—username, password, and MFA code—the\r\nattackers automatically send the credentials to the company’s official login page behind the scenes. A session\r\ncookie is generated by the legitimate service and sent to the attackers as they log in, allowing them to bypass MFA\r\nrequirements as they move the attack forward. \r\nNew device, who this?\r\nThe fact that the attacker managed to successfully log into an MFA-protected account is concerning. But those\r\nsessions will eventually expire, logging the attackers out of these compromised accounts.\r\nTo prepare for this eventuality, Atlas Lion faced the challenge of not having another MFA code or session cookie\r\nto maintain access. Without either, they faced a limited window during which they could carry out their attack, or\r\nhad to come up with another approach.\r\nSo if MFA is required, why not enroll a new MFA device under the attacker’s control? \r\nThis is exactly what the attackers did. Since they had access to a user’s account, they simply enrolled an MFA\r\nauthentication app of their own. Then to shore up their control of the account, they changed the user’s password. \r\nThey were now poised to attempt a bolder strategy of device enrollment. \r\nA lion in sheep’s clothing\r\nOnce an attacker gains initial access to a system in a network, frequently, the next step is to elevate privileges and\r\ngain persistence on that system. The risk attackers face in these cases is this activity often deviates from normal,\r\nday-to-day activity. And if these systems are monitored, it makes it easy to detect, investigate, and mitigate the\r\nmalicious activity.\r\nhttps://expel.com/blog/observing-atlas-lion-part-one/\r\nPage 2 of 4\n\nAtlas Lion didn’t take this well-trodden path. Instead, they started by creating a Windows virtual machine (VM) in\r\ntheir own Microsoft Azure cloud tenant. Since the compromised user was already registered in Entra ID, the\r\nattackers simply entered the stolen credentials they had obtained and, when prompted, the MFA code from the\r\nnewly registered authentication application.\r\nThis successfully validated the user, and the attacker’s VM was connected to the organization’s domain and\r\nenrolled. This happens as part of the normal Windows device setup, as it offers to join the device to a corporate\r\ndomain if an account is provided.\r\nThis effectively took a VM mimicking a brand new system within the corporate environment and onboarded it as\r\na new system, bypassing requirements put in place to keep unauthorized devices off of the corporate network.\r\n…out like an atlas lamb\r\nThe fact that an attacker was able to leverage an organization’s cloud infrastructure to enroll a system they control\r\nis concerning, but fortunately the same brazen attempt is what led to its downfall. \r\nWhile enrolling a new system into the network, the target organization required several software applications to be\r\ninstalled for the new device to meet compliance requirements. One of these applications was Microsoft Defender.\r\nSo as the attacker’s device was enrolled into the organization, the endpoint security software was installed on the\r\nattacker’s VM. And Defender recognized something wasn’t right.\r\nInterestingly, it wasn’t the actual activity that brought attention to this attack. It turned out the bad actor was using\r\na previously flagged IP address with a history of malicious activity.\r\nThis IOC immediately led to an alert in the Expel queue, which a SOC agent picked up shortly thereafter. Fifteen\r\nminutes later, the analyst suggested kicking the host off the network, along with other remediation steps to expel\r\nhttps://expel.com/blog/observing-atlas-lion-part-one/\r\nPage 3 of 4\n\nthe malicious actor, such as resetting the users credentials.\r\nAn event worth taking note of\r\nIt’s mildly ironic that the enrollment of a malicious, attacker-controlled system was brought down by the same\r\nenrollment process the attackers were attempting to take advantage of. \r\nBut what’s more concerning is that it could be argued that the attackers were careless. If they had simply used an\r\nIP address that wasn’t known for malicious activity, it’s difficult to say if the malicious device enrollment would\r\nhave been noticed as quickly.\r\nThis highlights the importance of having automated device enrollment processes in place to set up new devices\r\nsecurely. In this case, it was the endpoint security tools installation after device authentication that stopped the\r\nattack.\r\nIt’s also important to have network access control policies in place that require specific configurations to connect\r\nto the environment. This would include ensuring the user is connecting from a geographic location and an IP\r\naddress space matching where they reside.\r\nThere should also be policies in place to prevent the arbitrary enrollment of devices without prior authorization.\r\nIt’s rare that an employee will need to authenticate new devices, so putting guardrails on this process will also\r\nhelp block these types of attacks.\r\nIs this the end?\r\nIt’s important to note that while this may appear to be a happy ending, Atlas Lion did not just throw up their hands\r\nand give up on attacking this organization. With Expel’s help, the organization won the battle, but the war was far\r\nfrom over. More to come in part two.\r\nSource: https://expel.com/blog/observing-atlas-lion-part-one/\r\nhttps://expel.com/blog/observing-atlas-lion-part-one/\r\nPage 4 of 4", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "origins": [ "web" ], "references": [ "https://expel.com/blog/observing-atlas-lion-part-one/" ], "report_names": [ "observing-atlas-lion-part-one" ], "threat_actors": [ { "id": "dfee8b2e-d6b9-4143-a0d9-ca39396dd3bf", "created_at": "2022-10-25T16:07:24.467088Z", "updated_at": "2026-04-10T02:00:05.000485Z", "deleted_at": null, "main_name": "Circles", "aliases": [], "source_name": "ETDA:Circles", "tools": [], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775439110, "ts_updated_at": 1775826731, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/3db0bfd15f44f52ffdd7e08c254635221620753b.pdf", "text": "https://archive.orkl.eu/3db0bfd15f44f52ffdd7e08c254635221620753b.txt", "img": "https://archive.orkl.eu/3db0bfd15f44f52ffdd7e08c254635221620753b.jpg" } }