{
	"id": "634728ec-acc1-404c-bfc3-d96ef28413a4",
	"created_at": "2026-04-06T00:17:36.998476Z",
	"updated_at": "2026-04-10T13:12:37.440986Z",
	"deleted_at": null,
	"sha1_hash": "586147392ed0df9eb8188d524d3348bbe95cd142",
	"title": "Oops, I Leaked It Again — How Mitiga Found PII in Exposed Amazon RDS Snapshots",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1068875,
	"plain_text": "Oops, I Leaked It Again — How Mitiga Found PII in Exposed\r\nAmazon RDS Snapshots\r\nBy Tim Boutin\r\nPublished: 2026-03-05 · Archived: 2026-04-05 21:24:13 UTC\r\nTL; DR:\r\nThe Mitiga Research Team recently discovered hundreds of databases being exposed monthly, with extensive\r\nPersonally Identifiable Information (PII) leakage. Leaking PII in this manner provides a potential treasure trove\r\nfor threat actors — either during the reconnaissance phase of the cyber kill chain or extortionware/ ransomware\r\ncampaigns\r\nThis Mitiga Research Team blog goes into the tactics used, insights determined, and recommendations on how\r\norganizations relying on Amazon RDS can take precautions against this scenario inadvertently happening in their\r\nenvironments.\r\nBackground\r\nThe Amazon Relational Database Service (Amazon RDS) is a Platform-as-a-Service (PaaS) that provides a\r\ndatabase platform based on a few optional engines (e.g., MySQL, PostgreSQL, etc.). Released in October 2009,\r\nAmazon RDS is very popular in today’s cloud world. In 2018, Stackoverflow’s annual survey included a\r\npublished a report with the non-ambiguous name The Incredible Growth of Amazon RDS, which contained some\r\neye-opening figures about RDS distribution. For example, the following report graph shows the popularity of the\r\nservice (in comparison to other managed databases) across several industry sectors.\r\nhttps://www.mitiga.io/blog/how-mitiga-found-pii-in-exposed-amazon-rds-snapshots\r\nPage 1 of 16\n\nWhen using RDS service in AWS, you can employ RDS snapshots — a storage volume snapshot of your DB\r\ninstance, backing up the entire DB instance and not just individual databases. These snapshots can be shared\r\nacross different AWS accounts — in or out of the on-premises organization, as well as AWS accounts that make\r\nthe RDS snapshots publicly available. \r\nWith that, one might unintentionally leak sensitive data to the world, even if you use highly secure network\r\nconfiguration.\r\nWhat is a Public RDS Snapshot, and Why Is it Interesting?\r\nAn RDS snapshot is an intuitive feature that helps you to back up your database. A Public RDS snapshot is a\r\nuseful feature that allows a user to share public data or a template database to an application. Additionally, a\r\nPublic RDS snapshot is a valuable feature when a user wants to share a snapshot with colleagues, while not\r\nhaving to deal with roles and policies. In this manner, the user can share the snapshot publicly for just a few\r\nminutes... What could possibly happen? 🙂\r\nWell… obviously, leaked snapshots might potentially be very valuable asset for a threat actor — either during the\r\nreconnaissance phase of the cyber kill chain (databases can include sensitive technical data that can be used for\r\nexploitation, like API keys) or for extortion or ransomware campaigns.\r\nDue to the potential of unintentional data leakage of the RDS service, we decided to investigate if this potential\r\nreally has a foothold in the real-world.\r\nhttps://www.mitiga.io/blog/how-mitiga-found-pii-in-exposed-amazon-rds-snapshots\r\nPage 2 of 16\n\nSurprisingly, or not, we found a lot of snapshots that were shared publicly for few hours, days, and even\r\nweeks — either intentionally or by mistake.\r\nIt’s important to note that making a snapshot public, even for a very short amount of time, can have unwanted\r\noutcomes. Our research shows how a threat actor might take advantage of snapshots that are shared for even a\r\nshort timeframe.\r\nIn this blog post, we describe our research process and associated findings. We will also explain the forensics\r\nvisibility in the relevant logs and share best-practices to detect and mitigate the potential risk related to public\r\nRDS snapshots.\r\nWhile investigating the relevant log records, we found that the information in the logs was not as intuitive as we\r\nwould have wanted — both in terms of the visibility and of the events we were expecting to see. We elaborate on\r\nthis topic in the Detection and Mitigation section.\r\nHow Attackers Can Abuse It\r\nAttackers are always looking for new ways to put their hands on confidential information of organizations, mostly\r\nfor financial gain. Some cloud services that allow sharing of cloud resources widely to the world expose a new\r\nthreat to organizations – unintentional sharing of information through resources like Disk snapshots (EBS), or in\r\nour case DB snapshots (RDS). \r\nIn adopting a cyber attacker’s mindset, the Mitiga Research Team discovered there was a significant problem, and\r\nwe developed a way to massively exploit that issue – just as attackers would.\r\nAs described in this blog, this lack of visibility prevents organizations from knowing whether a shared publicly\r\nRDS snapshot was ever accessed by an unauthorized third party and if actions should be taken immediately to\r\nmitigate any risk that could be derived from the information being public.\r\nIn our research, we developed an AWS-native technique, using AWS Lambda Step Function and boto3, to scan,\r\nclone, and extract potentially sensitive information from RDS snapshots in scale, as follows:\r\nScan — Hourly scan for DB snapshots that have been marked as public from all regions (except the\r\nregions not enabled by default: af-south-1, ap-east-1, ap-southeast-3, eu-south-1, eu-central-2, me-south-1\r\nand me-central-1.)\r\nClone — Clone the snapshot to our own AWS account and maintain a state file to make sure we are not\r\ncloning duplicates.\r\nList — Create a list of cloned RDS snapshot to extract, making sure we are not creating a DB instance\r\nfrom a snapshot that was examined in the past.\r\nPrepare — Get a list of snapshot ARNs and create a DB instance out of it. To do so we reset the master\r\npassword so we can create and access the restored DB instance.\r\nExtract — Automatically extract DB schema (particularly the table names and column names) as well as\r\nthe table's content (limit 10,000 lines per table) to S3 for further analysis.\r\nCleanup — Delete the DB instances to cut charges.\r\nhttps://www.mitiga.io/blog/how-mitiga-found-pii-in-exposed-amazon-rds-snapshots\r\nPage 3 of 16\n\nWhat We Discovered: Main Insights\r\nWe decided to focus on a specific timeframe for our research. We chose one month as a timeframe we think is\r\nenough to clean the noise of optional peaks or desert days. Our data is from 21/09/2022 to 20/10/2022.\r\nOMG, Is That Personally Identifiable Information!?\r\nOne of our main questions in this research was how much sensitive data was exposed during this month, if at all.\r\nBefore we show the statistics and insights, we want to share some (anonymized) examples of personally\r\nidentifiable information (PII) we found.\r\nThe first example is a MySQL database that was exposed all the research month. This DB was created on\r\n03/03/22, and the snapshot was taken on 31/08/22. This DB looks like a car rental agency database. One of the\r\ninteresting tables appears to summarize car rental transactions. This table contains 51 columns and approximately\r\n10,000 rows. The data in this table is updated — there is a created date time with dates from 15/06/22 to 31/08/22.\r\nHere are some examples of the most interesting columns:\r\nPersonal Identifiable Information\r\n- first_name, last_name, phone, email, marital_status (married/single)\r\n- occasion — such as birthday, special day, or anniversary\r\n- sales_consultant — full names of company employees, quite likely\r\nBusiness knowledge\r\n- enquiry_segment — the options we see for this column are: Personal, Company, Commercial, Captive,\r\nFleet Owner, Hire, Individual, Institutional.\r\n- organization_id — there is another table with the correlation between organizations’ IDs and names.\r\n- customer category type — B2B/B2C\r\nRental information\r\n- model — model of the car\r\n- expected_delivery_date\r\nThe second example is a MySQL database that was exposed for less than four hours. This DB was created on\r\n14/04/16, and the snapshot was taken more than 6 years later — on 02/10/22. This database appears related to a\r\ndating application. It seems that this app is not in use anymore, but it worked until at least 2020. The users table\r\ncontains approximately 2,200 users. This table contains emails, password hashes, birthdates, links to personal\r\nhttps://www.mitiga.io/blog/how-mitiga-found-pii-in-exposed-amazon-rds-snapshots\r\nPage 4 of 16\n\nimages links, and a lot more. This table contains data between 08/01/15 to 15/07/20. Another table in this DB\r\ncontains the private messages. \r\nThe third example is a MySQL database that was exposed for an entire month. This DB was created on\r\n22/07/15, and the snapshot was taken more than 7 years later (!) - on 12/09/22. This DB looks like a telephone\r\napplications company database. One of the tables summarizes all the logins to the company applications. This\r\ntable has 17 columns and approximately 7,500 rows. The data in this table is from 10/08/15 to 12/09/22.\r\nIn this table, for example, we have user ID (that equal to email addresses), phone device models, mac addresses,\r\nclient access tokens and application ID of the app this user uses.\r\nStatistics\r\nWe were convinced this was a really interesting situation, but the important follow-up question here was: “How\r\nprevalent is this issue?”. \r\nLooking for answers, we collected some interesting statistics:\r\nThe total number of snapshots seen in this month was 2,783\r\nOf those 2,783 snapshots, 810 snapshots were exposed during the analyzed timeframe\r\nAdditionally, 1,859 snapshots of the 2,783 were exposed for just 1-to-2 days\r\nhttps://www.mitiga.io/blog/how-mitiga-found-pii-in-exposed-amazon-rds-snapshots\r\nPage 5 of 16\n\nHere are two graphs that illustrate the prevalence of this issue: Public Snapshots Per Region and Public Snapshots\r\nPer Database Engine.\r\nPublic Snapshots Per Region\r\nIn terms of these regional snapshots, it makes sense that in us-east-1 there are the most of them. But it’s interesting\r\nto see snapshots created across most regions — so, as expected, this is a worldwide phenomenon.\r\nhttps://www.mitiga.io/blog/how-mitiga-found-pii-in-exposed-amazon-rds-snapshots\r\nPage 6 of 16\n\nOK, so we saw the amount and the regional distribution of the snapshots. But it’s not a big deal if all of them are\r\nsupposed to be public, right?\r\nTo pass this barrier of noise and skepticism, we decided to err on the side of caution and sanitize the data in two\r\nways:\r\nWe saw some account IDs that published a lot of snapshots, changing daily or remaining consistent through\r\nthe month, probably as part of their product. According to that, we checked how many snapshots there\r\nwere per account and filtered out the big ones to clean the few accounts that published a lot.\r\n*\r\n We filtered out any account that had more than five monthly snapshots. There were 2,059 snapshots of 36\r\naccounts. That is a lot of snapshots created by just a few accounts.\r\nAfter that, we filtered out snapshots that contained in their name one of these keywords: “test”, “tst”,\r\n“public”. We assumed stringently that if snapshot name contained one of those keywords, it may not\r\ncontain interesting data.\r\n* We found 74 snapshots with these keywords after the previous filter — not much.\r\nNow, we have 650 snapshots that were published by accounts that published a few more public snapshots (if at\r\nall), and without a keyword in their name that hints on the possibility it may be just a test and doesn't contain\r\ninteresting information. We call the remaining snapshots — the interesting snapshots. Let's take a deep dive into\r\nthe interesting snapshots.\r\nInsights Based on Metadata Only\r\nhttps://www.mitiga.io/blog/how-mitiga-found-pii-in-exposed-amazon-rds-snapshots\r\nPage 7 of 16\n\nThis graph shows how many different interesting snapshots were active every day in our month:\r\nActive Snapshots by Day\r\nWe can see a change, of course, but the range is 287-335 (i.e., it’s not a unique peak but a stable phenomenon).\r\nThis graph shows the distribution of how many days in the analyzed timeframe the interesting snapshots were\r\nexposed:\r\nhttps://www.mitiga.io/blog/how-mitiga-found-pii-in-exposed-amazon-rds-snapshots\r\nPage 8 of 16\n\nExposed Snapshots by Day\r\nIt’s a great graph — we can see that most of the snapshots were exposed just for a few hours or were forgotten /\r\nsupposed to be public. Snapshots left exposed for just a few hours are most likely exposed unintentionally, and\r\nmay contain data that should not be available, even for a short time, to the public.\r\nEvery snapshot was taken from an RDS instance. This graph shows the instances creation time per month:\r\nhttps://www.mitiga.io/blog/how-mitiga-found-pii-in-exposed-amazon-rds-snapshots\r\nPage 9 of 16\n\nInstances Creation Time Per Month\r\nMost of them appeared last September and October, of course — 348 snapshots. But it’s exciting to see how many\r\nsnapshots based on RDS instances were basically launched before that timeframe! It means there are many public\r\nsnapshots that aren't based on a new database for a check, test, template, or just empty database, but they are based\r\non exist-for-a-long-time database.\r\nInsights Based on the Content\r\nAnother approach to explore the cloned DB instances is by analyzing the content of the tables. To do so we have\r\nbuilt an automated process to highlight tables that contain, in high probability, confidential PII or other interesting\r\npieces of information. \r\nWe decided to focus on MySQL snapshots as the most common engine. Throughout the analyzed timeframe, we\r\nsaw 469 MySQL snapshots from the 650 special snapshots, those who may include real data (i.e., not test or\r\nintently public). To spot DB tables that had more potential of containing the juicy stuff, we extracted all columns\r\nnames from the tables and searched for a list of indicative keys:\r\n'address', 'admin', 'password', 'card', 'credit', 'secret', 'fax', 'ip', 'mac', 'account', 'hash', 'pass', 'token',\r\n'phone', 'billing', 'contact', 'document', 'tax', 'passport'.\r\nAfter filtering for the keys, we found 5,766 columns that are more likely to have interesting information by their\r\nname. We then filtered for tables that contained content by the number of rows and table size, which left 3,491\r\ncolumns to examine. That comprised 171 MySQL DB instances that potentially contained sensitive information\r\nwhich should not be exposed publicly.\r\nBelow you can find the breakdown of matching keys: \r\nhttps://www.mitiga.io/blog/how-mitiga-found-pii-in-exposed-amazon-rds-snapshots\r\nPage 10 of 16\n\nMy Snapshot Doesn’t Contain Any PII — Why Should I Worry?\r\nhttps://www.mitiga.io/blog/how-mitiga-found-pii-in-exposed-amazon-rds-snapshots\r\nPage 11 of 16\n\nThat is a good question. Let’s assume you are very responsible, and there is no way you go and expose database\r\nwith PII publicly, not even for one second. Is there anything else you need to worry about when you expose your\r\nsnapshot to anyone?\r\nThe answer is YES!\r\nToday, there is no native way to correlate between account ID and the company that owns this account. It’s not an\r\nofficial secret, but AWS doesn’t publish an API or a big table with this correlation, and not without a reason —\r\nthreat actors in many situations will pay a lot for this. There are attack vectors that a successful correlation means\r\na successful attack. Let’s take an example case of exposed RDS snapshot with PII. Unfortunately for the attacker,\r\nthere is no way to understand from the content of the DB which company this data belongs to. If the attacker had a\r\nway to find out the company based on account ID, they could commit their precious blackmail and get a lot of\r\nmoney.\r\nBack to reality: You are a professional employee, so your public snapshot doesn’t contain any PII and a way to\r\nattribute the content to your company. But you have to ask yourself — “Is there a way to find which company this\r\naccount ID belongs to, based on metadata only?”.\r\nActually, in our research, we succeeded in understanding who owned account IDs for many snapshots. The simple\r\nway is to look at the snapshot name and see the company name in it. Thank you, nice man who created this\r\nsnapshot and chose the name. But there is a more cool and fun way. Every snapshot metadata contains a field\r\ncalled MasterUsername — the main DB username. In most cases, this field contains something boring, such as:\r\nadmin, root, master, prod, db_user, myrds, and so on. \r\nBut, in many cases, we saw interesting things in this field — company names fully spelled, in acronyms, or\r\nshortcuts. But the crowning glory — names of people. We searched for these people on LinkedIn and ascertained\r\nwhere they work. A little creepy, but useful and widely employed by threat actors.\r\nDetection and Mitigation\r\nIt is important to note that after you share a snapshot publicly, you should get an email from AWS that warns you\r\nabout a public snapshot in your account — Amazon sends this notification to ensure that the public snapshot in\r\nyour account was indeed intended to be publicly available.\r\nIn our lab environment, we received the following email notification 23 minutes after sharing the snapshot. The\r\nemail subject was:\r\n“RDS Identified Public Snapshots In AWS Account ************” \r\nGreat feature from Amazon. Nevertheless, the email might be overlooked. Even if it doesn't, it might be already\r\ntoo late, because the leak might have been exploited by someone.\r\nIn addition, there is a tool called AWS Trusted Advisor that advises recommended steps to improve the\r\nenvironment in aspects of costs, performance, and security. In the dashboard, there is a “Trusted Advisor” widget\r\nwith an overview of recommendations state. When you have public snapshots, this widget presents an “Action\r\nrecommended” that warns you about your public snapshots with exact snapshots (in the details). Same feedback\r\nhttps://www.mitiga.io/blog/how-mitiga-found-pii-in-exposed-amazon-rds-snapshots\r\nPage 12 of 16\n\nhere: it is a nice feature, but there is no guarantee you will notice it, especially in a short time. For more\r\ninformation, please see additional context provided in the fifth hyperlink in the references section of this blog.\r\nAWS Trusted Advisor Tool\r\nHow Do I Know If I Have Any Public Snapshots?\r\nTo check for public snapshots in your environment, we suggest taking the following steps:\r\nFirst Step: Historical Check Using CloudTrail Logs — Did I Create a Public\r\nSnapshot or Share an Existing Snapshot?\r\nThere is no way to create a public snapshot — you should create a snapshot and then share it. It makes sense —\r\nthis separation helps to avoid configuration mistakes.\r\nWhen you share a snapshot publicly, there is an event with the event name: \r\n          ModifyDBSnapshotAttribute.\r\nThe requestParameters field looks like this:\r\n{\r\nhttps://www.mitiga.io/blog/how-mitiga-found-pii-in-exposed-amazon-rds-snapshots\r\nPage 13 of 16\n\n\"dBSnapshotIdentifier\": \"our-super-duper-sensitive-snapshot\",\r\n        \"attributeName\": \"restore\",\r\n        \"valuesToAdd\": [\r\n            \"all\"\r\n        ],\r\n        \"valuesToRemove\": []\r\n    }\r\n(If you configure sharing to an account, you will see the account IDs you add / remove under valuesToAdd /\r\nvaluesToRemove, respectively.)\r\nIt’s nice to see in AWS ModifyDBSnapshotAttribute API call documentation the following recommendation:\r\n            Do not add the all value for any manual DB snapshots that contain private information that you don't want available to all\r\nAmazon Web Services accounts.\r\nSecond step: Current-State Check of Your Organizational RDS Snapshots\r\nAd-hoc Check\r\n1. Use describe-db-snapshots API call to get a list of all available RDS DB snapshots:\r\naws rds describe-db-snapshots\r\n--region us-east-1\r\n--snapshot-type manual\r\n          --query 'DBSnapshots[*].DBSnapshotIdentifier'\r\n2. Use describe-db-snapshot-attributes against the list of DBsnapshotIdentifier returned from the last call,\r\nto get the DB snapshot attribute DBSnapshotAttributes\r\naws rds describe-db-snapshot-attributes\r\n--region us-east-1\r\n   --db-snapshot-identifier \u003c\u003e\r\n--query 'DBSnapshotAttributesResult.DBSnapshotAttributes'\r\nThis call would return the DBSnapshotAttributes for the given DBSnapshotIdentifier, if the AttributeValues\r\nfield is set to all, the selected RDS snapshot is publicly available for any AWS account to restore.\r\nContinuous Check — AWS Config\r\nYou can use AWS Config to get visibility of your environment. This tool allows you to manage rules and get your\r\nenvironment state based on these rules. In our case, we recommend adding rds-snapshots-public-prohibited rule\r\nhttps://www.mitiga.io/blog/how-mitiga-found-pii-in-exposed-amazon-rds-snapshots\r\nPage 14 of 16\n\nwhich checks if there are RDS snapshots that are public. The rule is NON_COMPLIANT if any snapshot is public.\r\nFor more information, please see the AWS Config Developer Guide extract hyperlink provided in the References\r\nsection of this blog.\r\nIn this example we have one public snapshot in our environment, so we see this in AWS Config dashboard:\r\nAWS Config Dashboard\r\nHow Can I See if Someone Copied My Public Snapshot?\r\nUnfortunately, you can’t.\r\nWe were surprised to find out there is no log event on copying public snapshot to another account or restoring a\r\nDB instance from another account, in the snapshot’s owner account.\r\nIn the foreign account, we did saw CopyDBSnapshot and RestoreDBInstanceFromDBSnapshot, respectively.\r\nIn EC2 service, unlike RDS, there are events indicating the copy and restore operation on an EC2 snapshot:\r\nSharedSnapshotCopyInitiated — “A shared snapshot is being copied” in AWS documentation words,\r\nand SharedSnapshotVolumeCreated — “A shared snapshot is being used to create a volume”. \r\nTo complete this gap and create a greater visibility into the operation taken on RDS snapshots, we approached\r\nAWS. According to AWS, logging on RDS copy and restore operation is currently unavailable, and a feature\r\nrequest was created to support that.\r\nHow Do I Prevent Sharing Snapshots Publicly?\r\nManage Permissions Well\r\nThe basic but the most important recommendation – Don't give unnecessary permissions. This best-practice is known as “least-privilege permissions.”\r\nEncrypt Your Snapshot\r\nhttps://www.mitiga.io/blog/how-mitiga-found-pii-in-exposed-amazon-rds-snapshots\r\nPage 15 of 16\n\nAWS enables you to encrypt a snapshot with a KMS key. During our research we wanted to investigate the\r\nbehavior of a public encrypted snapshot with a shared KMS key, and we determined it’s not possible to share\r\npublicly an encrypted snapshot.\r\nSummary\r\nIn the last decade, it’s obvious that when you publish a new service that is exposed to the internet, your IP and port\r\nscanned in a few minutes. These days, it’s naive to think the situations with public RDS snapshots are any\r\ndifferent. \r\nWe think it’s not an overstatement to assume the worst-case scenario — when you are making a snapshot public\r\nfor a short time, someone might get that snapshot’s metadata and content. So, for your company and, more\r\nimportantly, your customers' privacy — don’t do that if you are not 100% percent sure there is no sensitive data in\r\nthe content or in the metadata of your snapshot.\r\nReferences\r\n1. https://aws.amazon.com/rds/stack-overflow-incredible-growth-amazon-rds-report/\r\n2. https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html \r\n3. https://docs.aws.amazon.com/config/latest/developerguide/rds-snapshots-public-prohibited.html \r\n4. https://www.techtarget.com/searchaws/tip/Public-snapshots-pose-significant-Amazon-EBS-security-risks\r\n5. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.LoggingAndMonitoring.html\r\n6. https://sysdig.com/blog/aws-rds-security-events-sysdig/\r\nSource: https://www.mitiga.io/blog/how-mitiga-found-pii-in-exposed-amazon-rds-snapshots\r\nhttps://www.mitiga.io/blog/how-mitiga-found-pii-in-exposed-amazon-rds-snapshots\r\nPage 16 of 16\n\n- expected_delivery_date The second example is a MySQL database that was exposed for less than four hours. This DB was created on\n14/04/16, and the snapshot was taken more than 6 years later -on 02/10/22. This database appears related to a\ndating application. It seems that this app is not in use anymore, but it worked until at least 2020. The users table\ncontains approximately 2,200 users. This table contains emails, password hashes, birthdates, links to personal\n   Page 4 of 16",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.mitiga.io/blog/how-mitiga-found-pii-in-exposed-amazon-rds-snapshots"
	],
	"report_names": [
		"how-mitiga-found-pii-in-exposed-amazon-rds-snapshots"
	],
	"threat_actors": [],
	"ts_created_at": 1775434656,
	"ts_updated_at": 1775826757,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/586147392ed0df9eb8188d524d3348bbe95cd142.pdf",
		"text": "https://archive.orkl.eu/586147392ed0df9eb8188d524d3348bbe95cd142.txt",
		"img": "https://archive.orkl.eu/586147392ed0df9eb8188d524d3348bbe95cd142.jpg"
	}
}