{
	"id": "5995b406-066e-48d9-bfc3-8dfe23f40795",
	"created_at": "2026-04-06T00:15:53.976961Z",
	"updated_at": "2026-04-10T03:20:15.936896Z",
	"deleted_at": null,
	"sha1_hash": "b831aab05de583d12a94cb46a7409c42de5f5ab7",
	"title": "Generate Strong Security Signals with Sumo Logic \u0026 AWS Cloudtrail",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 507390,
	"plain_text": "Generate Strong Security Signals with Sumo Logic \u0026 AWS\r\nCloudtrail\r\nBy Dan Whalen\r\nPublished: 2019-09-10 · Archived: 2026-04-05 21:57:26 UTC\r\nAs orgs increasingly shift some of their workloads to cloud providers like Amazon Web Services (AWS), it’s often\r\nchallenging to get the right level of visibility into these new environments for security monitoring purposes. Sure,\r\nsecurity professionals have had decades of experience monitoring traditional enterprise networks, but services like\r\nAWS, Microsoft Azure and Google Cloud Platform come with additional sources of valuable data — which is\r\nfrustratingly unfamiliar if you’re used to racking and stacking your own servers. Combine that uncertainty with an\r\nalready long laundry list and the result is this: Most organizations using cloud platforms are not taking full\r\nadvantage of the signals available to them.\r\nBut there’s some good news: There are lots of great technology solutions we can use to help us get a better handle\r\non those signals. In this post, I’ll show you how Expel uses a SIEM (in this example, we’ll take a look at Sumo\r\nLogic) to generate security leads from AWS signals. Regardless of what SIEM you use, I’ll share some detection\r\nuse cases (with examples!) that you can try out in your own environment.\r\nHow does a SIEM help?\r\nAnyone who works in security knows that there are two high-level problems that need to be solved to effectively\r\nmonitor an environment:\r\n1. Collecting the data you need; and\r\n2. Drawing actionable insights from the data\r\nhttps://expel.io/blog/following-cloudtrail-generating-aws-security-signals-sumo-logic/\r\nPage 1 of 7\n\nA log management (aka SIEM) solution like Sumo Logic does all of the heavy lifting, connecting up to your\r\nsources of data and providing an intuitive search interface that lets you generate alerts and perform investigations.\r\nFor example, you can easily onboard Amazon CloudTrail data from AWS with the built-in connector (more on\r\nCloudTrail in a moment). In a few easy steps, you can create a trail and get data flowing by granting Sumo Logic\r\naccess to the S3 bucket containing the logs. This can be done right in the AWS console with a few button clicks or\r\nvia the CloudTrail API and takes about five minutes.\r\nOnce you’ve hooked up Sumo Logic, you can validate data flow by issuing queries against the CloudTrail data\r\nlike so:\r\nNow that you’ve got data flowing, the next step is making sense of it.\r\nBuilding a detection strategy for Amazon CloudTrail\r\nWhy Amazon CloudTrail is useful\r\nIf you aren’t familiar with Amazon CloudTrail, think of it as an audit log of all AWS activities that happen in your\r\naccount. By default, AWS enables a default CloudTrail for every account — it records the most essential events\r\nand retains them for 90 days.\r\nhttps://expel.io/blog/following-cloudtrail-generating-aws-security-signals-sumo-logic/\r\nPage 2 of 7\n\nThis is helpful as a default, but as a best practice it’s important to create your own CloudTrail that sends events to\r\na S3 bucket of your choosing. This allows you to control the granularity of the events that get logged and the\r\nlength of time those logs are retained. You can also use AWS Organizations to enforce a global CloudTrail that\r\nsends audit data from all of your AWS accounts (including all regions) to one master S3 bucket. This ensures that\r\nyou never end up in a situation where you’re missing audit data needed for a compliance requirement (or — oh\r\nnoes! — an active security investigation).\r\nMaking sense of CloudTrail data\r\nGetting data flowing is relatively easy, but making sense of it all can be overwhelming (especially if it’s the first\r\ntime you’re working with it).\r\nAt Expel, we maintain a detection and response strategy for AWS that defines what signals we look for and how\r\nour team responds. To build a detection strategy, we consider the attack lifecycle and make sure we have layered\r\nsignals in place to detect attacker or risky behaviors. We think about signal in terms of these three categories,\r\nwhich helps us identify areas of risk and brainstorm detection use cases. Access (how does someone enter the\r\nenvironment), Movement (how does data move around), and Storage (where does data live). Below are a few\r\nexamples that show what some of these use cases look like:\r\nBrainstorming at a high level where your areas of risk are and what compensating controls (including detection\r\nuse cases) you have in place is a healthy exercise that orgs should do routinely (We do this!).\r\nGenerating valuable AWS signals\r\nNow I’ll move on to the fun part. Let’s dig into a few examples of CloudTrail-based signals that we’ve found\r\nvaluable that might be helpful to you and your team (if you’re lucky enough to have one) as well.\r\nhttps://expel.io/blog/following-cloudtrail-generating-aws-security-signals-sumo-logic/\r\nPage 3 of 7\n\nSuspicious logins\r\nCredential theft isn’t a new attack vector by any means, but it’s still an issue for orgs of all shapes and sizes.\r\nParticularly as orgs start to use AWS, managing developer credentials gets challenging. As a result, a compromise\r\nof a developer workstation can quickly lead to a greater compromise of an AWS environment if you don’t have the\r\nright controls and signals in place.\r\nSo how can you use CloudTrail logs to help zero in on this problem? Check out the query below as a starting\r\npoint:\r\n_sourceCategory = {{sourceCategory}}\r\n| parse regex \"(?\u003craw\u003e{.*)\"\r\n| json field=raw \"eventName\", \"sourceIPAddress\", \"userAgent\", \"userIdentity.type\", \"userIdentity.arn\",\r\n\"userIdentity.userName\", \"additionalEventData.MFAUsed\" as event_name, src_ip, user_agent, user_type,\r\nuser_arn, user_name, mfa nodrop\r\n| lookup country_code from geo://location on ip = src_ip\r\n| where event_name = \"ConsoleLogin\" and mfa != \"Yes\" and country_code not in (\"US\")\r\n| count by country_code, mfa, user_type, user_arn, src_ip, user_agent\r\nWhat we’re looking for:\r\nAWS console logins where MFA wasn’t used\r\nUnusual geo-location for the source IP address (customizable for your org)\r\nTips and tricks:\r\nConsider time of day/day of week as a condition. Should anyone be logging in on the weekend?\r\nAccount discovery\r\nLet’s assume that an attacker gets authenticated access to an environment. What happens next? In our experience,\r\nan attacker usually starts to enumerate the AWS account, listing IAM Users, Groups and Roles, and generally\r\npoking around the account to understand it. One common side effect is a burst in API failures as the attacker may\r\nnot have the necessary permissions to green light all of their attempted actions.\r\nUsing this as a hypothesis, let’s build a signal to alert when this happens:\r\n_sourceCategory = {{sourceCategory}}\r\n| parse regex \"(?\u003craw\u003e{.*)\"\r\n| json field=raw \"eventName\", \"errorCode\", \"errorMessage\", \"sourceIPAddress\", \"userIdentity.userName\",\r\n\"userIdentity.type\", \"eventSource\" as event_name, error_code, error_msg, src_ip, user_name, user_type,\r\nevent_source nodrop\r\n| where error_code = \"AccessDenied\"\r\n| timeslice 1h\r\n| count as failures, count_distinct(event_name) as methods, count_distinct(event_source) as sources by\r\nhttps://expel.io/blog/following-cloudtrail-generating-aws-security-signals-sumo-logic/\r\nPage 4 of 7\n\n_timeslice, user_type, user_name, event_source, error_msg, src_ip\r\n| where failures \u003e 5 and methods \u003e 1 and sources \u003e 1\r\nWhat we’re looking for:\r\nA burst in AccessDenied errors over a period of one hour\r\nMultiple unique failed API calls\r\nMultiple unique AWS services generating failures\r\nTips and tricks:\r\nYou may find some noisy service accounts when first implementing this signal. This is a good opportunity\r\nto fix any broken policy documents or exclude specific accounts that you expect to generate failures.\r\nMaintaining access\r\nIf an attacker gains an initial foothold in an environment, the attack’s next objective is to figure out a way to\r\nmaintain that access. In a traditional enterprise, that might look like installing a service, setting up a scheduled\r\ntask or creating a backdoor user account.\r\nWhat does this look like in AWS? It turns out there are some parallels – Rhino Security Labs has done a great job\r\nwith Pacu, an open-source AWS exploitation toolkit (think Metasploit for AWS) that illustrates some of these\r\nbehaviors.\r\nAs an example, AWS Lambda can be used as a persistence mechanism:\r\n_sourceCategory = {{sourceCategory}}\r\n| parse regex \"(?\u003craw\u003e{.*)\"\r\n| json field=raw \"eventName\", \"userIdentity.invokedBy\" as event_name, invoked_by nodrop\r\n| where invoked_by = \"lambda.amazonaws.com\" and event_name in (\"CreateAccessKey\",\r\n\"AuthorizeSecurityGroupIngress\", \"UpdateAssumeRolePolicy\")\r\nWhat we’re looking for:\r\nA lambda function executing a suspicious action by:\r\nCreating an access key to backdoor an IAM user\r\nUpdating a security group to allow ingress on a port\r\nUpdating an assume role policy to allow external access\r\nTips and tricks:\r\nImplement least privilege to prevent these persistence mechanisms. Don’t grant users access to services\r\nthey don’t need.\r\nEvading defenses\r\nhttps://expel.io/blog/following-cloudtrail-generating-aws-security-signals-sumo-logic/\r\nPage 5 of 7\n\nAs a final example, determined attackers attempt to evade detection. Since CloudTrail logs nearly everything an\r\nattacker might want to do in an environment, CloudTrail is also an attack target. If an attacker has the right\r\npermissions, he or she can stop and/or delete a CloudTrail, making it more difficult for an organization to identify\r\nthreats and respond.\r\nYou can identify this activity by looking for the following API calls:\r\n_sourceCategory = {{sourceCategory}}\r\n| parse regex \"(?\u003craw\u003e{.*)\"\r\n| json field=raw \"eventName\", \"sourceIPAddress\", \"userIdentity.arn\", \"userIdentity.type\",\r\n\"eventSource\" as event_name, src_ip, user_arn, user_type, event_source nodrop\r\n| where event_name in (\"DeleteTrail\", \"StopLogging\", \"DeleteLogGroup\", \"DeleteLogStream\",\r\n\"DeleteDestination\")\r\nWhat we’re looking for:\r\nAn attacker deleting audit data by:\r\nStopping or deleting a CloudTrail\r\nDeleting a log group or stream from CloudWatch\r\nDeleting a CloudWatch destination\r\nTips and tricks:\r\nUsing AWS Organization trails are a huge help here. An attacker can’t stop or delete a trail that is enforced\r\nby the master account. He or she also can’t disable the default EventHistory trail that exists for each AWS\r\naccount.\r\nBringing it all together\r\nGetting all of this set up is a large step forward if you’re just getting started with AWS monitoring, but I’d be\r\nremiss if I didn’t mention one last piece of this puzzle: operationalizing these alerts. All of this work would go to\r\nwaste without a well thought-out process for alert triage and investigation (we’ll dive deeper into that topic in a\r\nfuture blog post).\r\nGenerating alerts is great, but you’ve got to make sure they’re getting in front of the right people. Sumo Logic\r\n(and most SIEM technologies) have multiple options including dashboards, in-console workflows and other ways\r\nto send notifications to external services via email or webhooks. You may decide, for example, that you’d like to\r\nsend a Slack message to a team of developers for activity that occurs in your development account.\r\nAlternatively, if you and/or your team is bogged down already with a million other to-dos and you simply don’t\r\nhave the bandwidth to develop and respond to alerts, consider working with a third party. Yes, we’re biased, but\r\nwe’d love to chat if you think we might be able to help.\r\nGetting a handle on your cloud infrastructure isn’t always easy. Collecting and making use of audit data that these\r\nplatforms generate — like AWS CloudTrail — is an important part of that mission and a good place to start.\r\nhttps://expel.io/blog/following-cloudtrail-generating-aws-security-signals-sumo-logic/\r\nPage 6 of 7\n\nSource: https://expel.io/blog/following-cloudtrail-generating-aws-security-signals-sumo-logic/\r\nhttps://expel.io/blog/following-cloudtrail-generating-aws-security-signals-sumo-logic/\r\nPage 7 of 7",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://expel.io/blog/following-cloudtrail-generating-aws-security-signals-sumo-logic/"
	],
	"report_names": [
		"following-cloudtrail-generating-aws-security-signals-sumo-logic"
	],
	"threat_actors": [],
	"ts_created_at": 1775434553,
	"ts_updated_at": 1775791215,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/b831aab05de583d12a94cb46a7409c42de5f5ab7.pdf",
		"text": "https://archive.orkl.eu/b831aab05de583d12a94cb46a7409c42de5f5ab7.txt",
		"img": "https://archive.orkl.eu/b831aab05de583d12a94cb46a7409c42de5f5ab7.jpg"
	}
}