{ "id": "5df66022-bf4c-4770-b2a0-707cba191672", "created_at": "2026-04-06T00:10:16.478732Z", "updated_at": "2026-04-10T03:31:44.487619Z", "deleted_at": null, "sha1_hash": "f4704923a83ecb07278438059a98c17af2db46dd", "title": "Catching \"EC2 Grouper\"- No Indicators Required! | FortiGuard Labs", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 54513, "plain_text": "Catching \"EC2 Grouper\"- No Indicators Required! | FortiGuard\r\nLabs\r\nBy Chris Hall\r\nPublished: 2024-12-30 · Archived: 2026-04-05 13:33:05 UTC\r\nThrough the years of analyzing identity compromises in the cloud, we’ve seen the same attackers pop up\r\nregularly, some more frequently than others. Among the more prolific ones we’ve come to know is one we’ve\r\ndubbed “EC2 Grouper”. Over the past couple of years, we’ve seen this actor in several dozen customer\r\nenvironments, making them one of the more active groups we’ve tracked. This usual suspect is attributed by their\r\npenchant for using similar user agents and the same security group naming convention in their attacks. \r\nWhile indicators such as user agents and even security group names can assist in attribution and hunting, we have\r\nfound them unreliable for comprehensive threat detection. In this blog, we’ll detail tactics associated with EC2\r\nGrouper and how Lacework FortiCNAPP can be leveraged to detect this threat, among others. More importantly,\r\nwe will showcase how this is achieved without relying on actor-specific indicators, which can be transient in\r\nnature.\r\nTactics and Techniques\r\nEC2 Grouper is characterized by their usage of AWS tools for PowerShell to carry out attacks. This is presumed\r\nby their user agent, which was consistent for a number of years:\r\n \r\nAWSPowerShell.Common/4.1.90.0 .NET_Core/6.0.5 OS/Microsoft_Windows_10.0.17763 PowerShellCore/7.-1\r\nClientAsync\r\n \r\nIn recent attacks, they have updated their UA, which now contains new versioning and unusual # characters,\r\nwhich could indicate a possible detection countermeasure.\r\n \r\nAWSPowerShell.Common/4.1.534.0 ua/2.0 .NET_Core#6.0.5 OS/windows#10.0.17763.0 md/ARCH#X64\r\nPowerShellCore/7.-1 cfg/retry-mode#legacy md/ClientAsync\r\n \r\nA more consistent indicator has emerged with a security group naming convention. Attacks in the cloud often\r\nleverage the CreateSecurityGroup API (T1098)  to enable remote access and lateral movement in the cloud\r\nenvironment. EC2 Grouper will typically attempt to create multiple groups using the same naming convention of\r\nec2group suffixed with a sequential combination of 1-5. Example request parameters:\r\n \r\nhttps://www.fortinet.com/blog/threat-research/catching-ec2-grouper-no-indicators-required\r\nPage 1 of 3\n\n{\"groupDescription\":\"ec2group\",\"groupName\":\"ec2group\"}\r\n{\"groupDescription\":\"ec2group1\",\"groupName\":\"ec2group1\"}\r\n{\"groupDescription\":\"ec2group12\",\"groupName\":\"ec2group12\"}\r\n{\"groupDescription\":\"ec2group123\",\"groupName\":\"ec2group123\"}\r\n{\"groupDescription\":\"ec2group1234\",\"groupName\":\"ec2group1234\"}\r\n{\"groupDescription\":\"ec2group12345\",\"groupName\":\"ec2group12345\"}\r\n \r\nIn all instances of EC2 Grouper attacks, cloud activity appears to be largely automated. The attacker will initially\r\nmake calls to DescribeInstanceTypes to inventory EC2 types within the environment and then DescribeRegions to\r\nretrieve information about regions available for resources. Upon acquiring available regions, the following API\r\ncalls are iteratively executed for every available region:\r\nDescribeVpcs: Requesting information about VPCs (Virtual Private Clouds) in a given region. (T1580)\r\nCreateSecurityGroup: Creation of a new security group called \"ec2group.\" (T1098 \u0026 T1021)\r\nDescribeSecurityGroups: Querying the security groups available in the account.\r\nDescribeAccountAttributes: Acquiring account attributes, perhaps for quotas related to resources. (T1580)\r\nGetServiceQuota: Checking service quotas, possibly to identify limits on resource usage. (T1580)\r\nDescribeInstances: Gathering information about existing EC2 instances that may be running, pending, or\r\nshutting down. (T1580)\r\nRunInstances: Attempting to launch new EC2 instances using the ec2group security group. (T1496)\r\nInterestingly, we have never observed calls to AuthorizeSecurityGroupIngress, which is ultimately required to\r\nconfigure inbound access to any EC2 launched with the security group. However, on several occasions, we have\r\nobserved CreateInternetGateway and CreateVpc, which are required for remote access. To date, we have not\r\nobserved what could be classified as actions based on objectives or manual activity in a compromised cloud\r\nenvironment. It could be either that EC2 Grouper is selective in their escalation or compromised accounts were\r\ndetected and quarantined before they had the opportunity to escalate. Despite this, resource hijacking (T1496) is\r\nlikely the general objective. However, to what end is currently unconfirmed.\r\nDetection\r\nIn every attack involving valid accounts, the credentials must originate from somewhere. One of the more\r\ncommon sources for compromised keys remains code repositories. Developers often mistakenly commit cloud\r\naccess keys to public repositories. Once this occurs, the clock starts ticking until the credentials fall into the hands\r\nof attackers, are discovered by secret scanners, or both. This is believed to be the primary method of credential\r\nacquisition for EC2 Grouper, as their cloud attacks are frequently accompanied by attacks from other threat actors.\r\nEC2 Grouper, however, is by far the most prolific actor allegedly using this vector.\r\nGiven the popularity of obtaining credentials in code repositories, it can be prudent to look for legitimate secret\r\nscanning services as part of your detection strategy. These include GitGuardian and Github’s secret scanning\r\nhttps://www.fortinet.com/blog/threat-research/catching-ec2-grouper-no-indicators-required\r\nPage 2 of 3\n\nservice. In our composite alerts, we have included secret scanning as a signal, as it is frequently seen in\r\nconjunction with illicit credential usage.\r\nOf course, credential checking alone does not indicate a compromise, so other signals need to be correlated to\r\nreduce false positives. When alerting on EC2 Grouper, our composite alerts have evaluated other techniques, such\r\nas using specific APIs known to be leveraged in attacks. These are effectively mapped to the respective techniques\r\nwith the assistance of the open-source TDiscover project.\r\nFinally, we evaluate anomalies as part of the composite alert. An alleged attack may exhibit characteristics\r\nindicative of malicious reconnaissance or privilege escalation. However, it's crucial to confirm this through\r\nanomaly detection. \r\nConclusion\r\nIdentifying illicit usage of valid credentials in the cloud can be a nuanced and difficult task. This poses a\r\nconsiderable challenge when it comes to detection, as the vast majority of attacks in the cloud involve\r\ncompromised credentials. While the attack detailed in this blog had various atomic indicators specific to the\r\nactors’ tactics and techniques, most attacks do not exhibit these unique characteristics. To achieve higher accuracy,\r\nit becomes more critical to correlate weaker signals involving aspects that attackers cannot control. For example,\r\nwhile attackers can easily control their source IP and user agent, they cannot control whether it is anomalous to\r\nthe environment. Similarly, they cannot control the APIs or sequence of APIs needed to carry out their objectives.\r\nBy leveraging these as signals to a composite alerting mechanism, one can achieve a much higher level of\r\ndetection efficacy. \r\nHow Can Lacework FortiCNAPP help?\r\nCloud detection and response (CDR) is a crucial component in addressing cloud identity compromises such as the\r\none documented here. With over 80% of attacks in the cloud involving compromised credentials, the effectiveness\r\nof your CDR solution can directly dictate the severity of a cloud attack. Lacework FortiCNAPP offers\r\ncomprehensive CDR protection with our innovative composite alerting technology. Cloud identity compromises\r\ncan be difficult to isolate as they often blend in with legitimate activity. Lacework FortiCNAPP can evaluate\r\nnumerous weak signals together through composite alerting, culminating in a much higher detection efficacy than\r\npoint detection alone. Lacework FortiCNAPP also integrates other essential components, such as CIEM for\r\ninforming the blast-radius of a compromised identity.\r\nRead more about how Lacework FortiCNAPP can secure your cloud environment.\r\nSource: https://www.fortinet.com/blog/threat-research/catching-ec2-grouper-no-indicators-required\r\nhttps://www.fortinet.com/blog/threat-research/catching-ec2-grouper-no-indicators-required\r\nPage 3 of 3", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia", "MISPGALAXY" ], "references": [ "https://www.fortinet.com/blog/threat-research/catching-ec2-grouper-no-indicators-required" ], "report_names": [ "catching-ec2-grouper-no-indicators-required" ], "threat_actors": [ { "id": "6f6e50fc-007c-47f0-b4a4-50c67e34e8b6", "created_at": "2025-01-10T02:00:03.153373Z", "updated_at": "2026-04-10T02:00:03.801512Z", "deleted_at": null, "main_name": "EC2 Grouper", "aliases": [], "source_name": "MISPGALAXY:EC2 Grouper", "tools": [], "source_id": "MISPGALAXY", "reports": null } ], "ts_created_at": 1775434216, "ts_updated_at": 1775791904, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/f4704923a83ecb07278438059a98c17af2db46dd.pdf", "text": "https://archive.orkl.eu/f4704923a83ecb07278438059a98c17af2db46dd.txt", "img": "https://archive.orkl.eu/f4704923a83ecb07278438059a98c17af2db46dd.jpg" } }