{
	"id": "89f12fbe-99d5-49bf-a524-e1ff2785b5ff",
	"created_at": "2026-04-06T00:11:12.232015Z",
	"updated_at": "2026-04-10T03:22:39.286745Z",
	"deleted_at": null,
	"sha1_hash": "41ba7fe5a99190ab56577dd75d5d60f3d532665f",
	"title": "How to analyze metadata and hide it from hackers",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1051030,
	"plain_text": "How to analyze metadata and hide it from hackers\r\nBy Stijn Vande Casteele Founder of Sweepatic , Outpost24\r\nPublished: 2017-07-25 · Archived: 2026-04-05 19:41:05 UTC\r\nEASM Last updated: 10 Nov 2025\r\nIn this post, we’re going to explore the dangers and risks of the tip of a very huge iceberg of sensitive information\r\ncompanies are exposing: the metadata of a document. “What is it and why is it such a juicy source of information\r\nfor advanced attackers?” you might ask. Well, a document’s metadata allows to collect various high-sensitive data\r\nsuch as usernames, software used in a company, location of file shares, and so on.\r\nHackers often exploit document metadata to gather sensitive information about individuals or organizations.\r\nMetadata, which includes details like the author’s name, creation date, and file path, can reveal a lot about the\r\ndocument’s origin and content. By accessing this information, hackers can identify potential targets, understand\r\ninternal processes, or even uncover security vulnerabilities.\r\nFor example, metadata might disclose the use of specific software versions, which could be prone to known\r\nexploits. Additionally, metadata can provide clues about the structure and hierarchy of an organization, aiding in\r\nsocial engineering attacks. To mitigate these risks, it’s crucial to sanitize documents before sharing them\r\nexternally.\r\nAs part of a practical exercise, we can even show you how you can find what metadata your company is leaking.\r\nCollecting this metadata for analysis and creating a nice Splunk dashboard gives you a completely new type of\r\nThreat Intelligence and situational awareness about your company’s attack surface for a very low cost.\r\nhttps://outpost24.com/blog/metadata-hackers-best-friend/\r\nPage 1 of 15\n\nIf you already know what metadata is and what it contains, you may want to skip to the section “Mapping your\r\nattack surface”.\r\nEvery organization is producing files on a daily basis with content that is approved for publishing. There’s a catch\r\nto that: You as a company are in fact publishing more data than you think. Every time a document is created,\r\nsoftware that was used to create that document inserts so called metadata which can be described as data about\r\ndata.\r\nWhat does it ‘data about data‘ mean? It’s not the content of the file but rather:\r\nWhat software has been used to create this file? (e.g. Microsoft Word 2007)\r\nWhat user created this file? (e.g. john.doe, u12345)\r\nWhat is the computer name where it was created? (e.g. Super Secret Lab PC N203)\r\nWhen the file was created?\r\nWhen the file was last modified?\r\nWhen the file was printed?\r\nFile path on the disk/share from which the file was exported (e.g.\r\n\\\\DOC_SERVER\\DOCS\\PATENTS\\Wormhole_travel_engine.docx)\r\nAnd much more…\r\nHere’s an example of document metadata:\r\nhttps://outpost24.com/blog/metadata-hackers-best-friend/\r\nPage 2 of 15\n\nThis information is automatically inserted into the document by the software you use to create/modify the\r\ndocument. The amount and type of information inserted depends on the used software and its configuration. It’s\r\nrarely seen that organizations try to limit the spread of this information. As a result, this sensitive information is\r\nexposed and adversaries may invest time in analyzing this exposed information about your business.\r\nGenerally, there are three types of attackers that your organization is most likely to face:\r\nScript kiddies\r\nAdvanced attackers/APTs\r\nInsiders\r\nInsiders are out of the scope of this article. The remaining two have several interesting differences. One of the\r\nbiggest distinctions between a script kiddie and an advanced attacker is how much time they spent on the\r\nreconnaissance phase in the cyber kill chain.\r\nThe reconnaissance phase of a hack\r\nhttps://outpost24.com/blog/metadata-hackers-best-friend/\r\nPage 3 of 15\n\nReconnaissance is one of the most important phases of a hack, often determining whether the attack will be\r\nsuccessful or not. A threat actor is mapping the battleground, looking for targets and all the available surrounding\r\ninformation to increase the success of the planned attack. The threat actor is commonly looking for either an asset\r\n(an unpatched server connected to the Internet) or an individual (Jane Doe from the finance department running on\r\nWindows XP that was never updated) to be compromised.\r\nFinding vulnerable assets is done by doing subdomain enumeration, discovering internet exposed devices in your\r\ncompany’s IP range and running a vulnerability scan on top of it. It’s a little bit more complicated when it comes\r\nto finding an individual to compromise. This requires doing online OSINT (Open Source Intelligence), using for\r\ninstance LinkedIn. OSINT often reveals a list of employees or even full organizational charts. How does an\r\nattacker find who is the most vulnerable person from the target’s organization? That’s the tricky part.\r\nWe’re all bombarded with industry reports about how phishing attacks made it to become the #1 vector to\r\ncompromise a company. This can be done by sending an innocent looking email, attaching a Microsoft Word\r\ndocument with a nifty VBA macro which drops custom PowerShell RAT. With a good pretext and preparation, the\r\ntarget is very likely to open the attachment.\r\nWould this attack be successful? Maybe. The attacker wants to increase the success of the attack, but not by\r\nsending hundreds of those emails which will raise a red flag for the security team monitoring your company. How\r\nto do that? Here’s a brief list of what can increase the chances for a compromise and in the post-exploitation\r\nphase:\r\nWhat software is the target using? If he/she uses LibreOffice rather than Microsoft Word, sending a VBA\r\nmacro wouldn’t work in that case.\r\nWhat is the operating system of the target? Exploit leveraging a vulnerability in how Windows parses TTF\r\nfonts wouldn’t work on Mac OS.\r\nWhat’s the target’s username \u0026 e-mail address? This helps with getting a foothold in the post-exploitation\r\nphase while staying under the radar.\r\nWhat is the file share where most of the company documents are stored? An attacker can plan a lateral\r\nmovement once the target is compromised or just blow it off with a targeted ransomware attack.\r\nWhich contractors are working for the target’s company? It’s known that advanced attackers sometimes\r\nchoose contractors because of less strict security measurements.\r\nNow, would you publish all this sensitive information on the websites of your company for anyone to download\r\nand use in their interest? No? Well… Allow us to tell you that this is exactly what you are doing by publishing\r\nfiles on your websites without removing the metadata. All of this information can be found there and many\r\norganizations don’t even know it’s there (we call it dark data).\r\nDark data shouldn’t be published and poses a huge security risk to your company. Also, you may be aware some\r\nregulations such as the GDPR (General Data Protection Regulation) require you to build and maintain an\r\ninventory of your files/data. Have you included also all your publicly exposed files and this sensitive data that you\r\nare publishing? Below picture shows a contextualization of sensitive information found in the form of a\r\nrelationships graph (this feature is available in the Outpost24 External Attack Surface Management Platform).\r\nhttps://outpost24.com/blog/metadata-hackers-best-friend/\r\nPage 4 of 15\n\nCollecting valuable information around metadata\r\nThis is the type of threat intelligence that your security team should be collecting. Buying TI from vendors about\r\nall the APT actors with their IOCs is cool, but it costs tons of money and most of it will never appear in your\r\nenvironment anyway. We recommend that you focus first on understanding how you are perceived by your\r\nadversaries, what the attack surface of your company is, so you know at least what you need to protect and keep a\r\nvery close eye on.\r\nAvoiding situations where your company’s attack surface is leaking a list of sensitive usernames screaming “I’m\r\nrunning on Windows XP ’cause service desk is too lazy to upgrade my laptop to something more secure.” Well,\r\nhow do you do that? Read on, we will show you our secret methods!\r\nMapping your attack surface\r\nAs an example, we’re going to pretend that we are security analysts taking care of the whitehouse.gov and\r\nusa.gov seed domains, which will be used to map the attack surface of the leaking metadata and contextualize the\r\nfindings. We encourage you to do the same for your company afterwards. You might be surprised how much you\r\nwill find and how much of it you don’t want to be exposed to the outside world!\r\nThe first part is obtaining the documents published on the websites of our interest. There are various techniques\r\nfor this:\r\nCrawl/mirror the website, downloading all the content.\r\nUse Google/Bing dorking to find public files.\r\nAsk the responsible team in your company to give you a dump of published files if possible.\r\nThe easiest and dirty way is to just mirror the website by downloading everything published there to local disk\r\nusing wget:\r\nwget -mk https://www.example.com/\r\nhttps://outpost24.com/blog/metadata-hackers-best-friend/\r\nPage 5 of 15\n\nThe most obvious downside is that this approach is going to download also HTML and other content which we are\r\nnot interested in. However, this content can be filtered later on using a bash script.\r\nUsing Google or Bing\r\nA more targeted way is to use Google or Bing dorks to find documents indexed by those search engines. This is\r\nalso what some other tools such as FOCA use to find documents (works in both Google \u0026 Bing):\r\nsite:example.com filetype:pdf\r\nPro tip: For these types of dorks (filetype), Bing tends to find more than Google.\r\nfiletype part of the dork can be further adjusted/changed to look also for office files, pictures, etc. This\r\napproach avoids downloading unnecessary content from the target website and covers subdomains (searching\r\nunder site:example.com covers blog.example.com in most search engines) and thus increases the intel\r\ncoverage. On the other hand, it relies on a search engine and what files it indexed which may exclude some\r\ninteresting parts due to robots.txt file.\r\nIt’s also more a manual job to download those files or a little bit harder to script if you wish to do it automatically.\r\nIf you are looking for a tool to collect the dorking results for you, rather than manually compiling a list of\r\nthousands of URL’s, then take a look at snitch. Snitch is a little bit of an older tool, but still serves its purpose (you\r\ncan search GitHub for keyword dork to find similar tools). You can obtain the list of exposed documents by\r\nrunning snitch with following arguments:\r\npython2 snitch.py -C \"site:whitehouse.gov filetype:pdf\" -P 100\r\nA more comprehensive attack surface map\r\nIf you want a complete attack surface overview, it’s recommended to combine both approaches: crawl/mirror your\r\nwebsites and enrich it with documents via search engine dorking techniques afterwards.\r\nOnce we have the files, we will use a popular tool called exiftool to extract the metadata from it with a\r\ncombination of CLI switch -j . The output will be in JSON format which we can pipe to Splunk where we can\r\nanalyze all the data with the up-most beautiful (and scary) dashboard.\r\nDownload the bash script that the Outpost24 tech team prepared for you to process the metadata.\r\nThis script can be used in two ways:\r\nYou can run it by giving a location to the folder where website content is downloaded. It will then run\r\nexiftool to extract the metadata into the metadata.json file in the current working directory and filter out\r\nuninteresting files (such as HTML \u0026 text files).\r\nYou can pass it a second argument which is a location of the file containing a list of URLs which will be\r\ndownloaded and then analyzed for metadata (for example a list of documents you obtained through Google\r\ndorking).\r\nhttps://outpost24.com/blog/metadata-hackers-best-friend/\r\nPage 6 of 15\n\nOnce you have your metadata.json file, we are going to import it into Splunk running in a Docker container.\r\nFirst, pull a Docker Splunk image from the official Docker repository:\r\ndocker pull splunk/splunk\r\nAnd then start it:\r\ndocker run -d -e \"SPLUNK_START_ARGS=--accept-license\" -e \"SPLUNK_USER=root\" -p \"8000:8000\" splunk/splunk\r\nOnce you have Splunk running on port 8000 locally, access localhost:8000 with your web browser and go through\r\ninitial setup (changing default admin password). When completed, import your metadata for analysis:\r\n1. Click Add Data on the main dashboard or from settings panel in menu.\r\n2. Click Upload .\r\n3. Go next to setup source file. You can leave these settings as they are by default, Splunk should\r\nautomatically detect that it’s a JSON file and parse it automatically.\r\n4. Go to the next page and in the Index section create a new index named document_metadata (just give it\r\na name, leave other settings unchanged), we will be using this index in search queries described further in\r\nthe article. If you are going to use a different index then don’t forget to adjust the queries accordingly.\r\n5. Confirm the changes in the Review section and finish the import of data.\r\nYou now have everything ready from the data side so let’s jump to the more interesting part and analyze the data\r\nwe just collected.\r\nSoftware that embeds the metadata is commonly doing it by using a key-value scheme. The precise format\r\ndepends on the file format. Luckily, exiftool extracts it for us into a JSON dictionary that is automatically parsed\r\nwhen imported into the Splunk instance. Key here is the metadata name and it’s value that we are interested in\r\nsuch as who created the document, what software was used, etc. We need to know these metadata field names to\r\nfilter out the data we want.\r\nUnfortunately, those field names are not standardized, different software can use different field names with the\r\nsame meaning. For example, there is a field called “Creator” which contains the information about the software\r\nused to produce the file. Some software use field “Producer” to store the same information and there’s also a\r\nsoftware using both fields where “Creator” is the main software and “Producer” is a plugin used to export the\r\ndocument.\r\nSplunk analysis\r\nSince we now started talking about the software used to produce these files, why don’t you actually now take a\r\nlook at it and see for yourself what has been found in the metadata?\r\nCopy-paste the following query into your Splunk search:\r\nhttps://outpost24.com/blog/metadata-hackers-best-friend/\r\nPage 7 of 15\n\nindex=\"document_metadata\"\r\n| eval software=mvappend(Creator, Producer)\r\n| mvexpand software\r\n| where NOT match(software, \"^\\W+$\")\r\n| stats dc(FileName) as count by software\r\n| sort -count\r\nWhich will produce a table like this:\r\nSee that Word 2013 at the bottom? You think it should be there? No? Then send an e-mail to your service desk to\r\nfix it. We can also see that some values aren’t actually software names/version but rather company names. It is a\r\ngood practice of configuring the software used in the company to put the company name instead of the software\r\ndetails itself. Software in your company should be configured to do the same.\r\nThe query above can be extended using regex to hunt for specific old versions of the software. This field can also\r\nbe used to search for what kind of printers the company is using (Hint: search for keyword xerox). One day a\r\nmysterious technician from Xerox can appear at the front reception delivering a replacement part for that Xerox\r\nWorkCentre 7970 you have on the second floor at the financial department Mark Sandy is using… or use it as an\r\n“Advanced Persistent Printer”\r\nAnalyzing user/author metadata\r\nLet’s now explore various users who created published documents with this query:\r\nindex=\"document_metadata\" Author=\"*\"\r\n| stats count(FileName) as count by Author\r\n| sort -count\r\nhttps://outpost24.com/blog/metadata-hackers-best-friend/\r\nPage 8 of 15\n\nThe Author field commonly contains the name of the person as it’s set in the OS or software license that\r\nproduced the file. In the case of corporations, it very often contains the username. The attacker can hunt for those\r\nusernames which are often something like u12345, john.doe or a similar format. These can be filtered by using a\r\nregex in Splunk query such as ^[a-z]{1,3}\\d{3,}$ , the other username formats can be found similarly also with\r\nregex.\r\nAdditional usernames can be extracted by tweaking the file path regex showcased later on or using the field\r\nLastModifiedBy which include the same type of information as the Author field.\r\nAs we briefly touched the topic of personal information found in metadata, what about e-mail addresses? Regex,\r\nonce again, comes to our rescue. To be more specific, this Splunk query:\r\nindex=\"document_metadata\"\r\n| rex field=_raw \"(?\u0026lt;email\u0026gt;[-\\w._]+@[-\\w._]+)\"\r\n| search email!=\"\"\r\n| table FileName, email\r\nSearching for keywords in metadata\r\nWhen creating documents, the creator sometimes puts keywords to it. This is used to help to search for a specific\r\ndocument inside the enterprise file share (where’s that super secret excel sheet with the SOC budget for next\r\nyear?). As you may have guessed, it’s a part of the metadata that is a little bit more complicated to retrieve.\r\nThe difficulty is that some software embeds an array of values, another software embeds it into the metadata as a\r\nlong string with , (comma with space) as delimiter and so on. So loads of variations here. Luckily for us, it’s not\r\na big deal for Splunk and this query can do it for us:\r\nindex=\"document_metadata\" Keywords!=\"\"\r\n| eval keyword=case(\r\nhttps://outpost24.com/blog/metadata-hackers-best-friend/\r\nPage 9 of 15\n\nisstr(Keywords) and like(Keywords, \"%, %\"), split(Keywords, \", \"),\r\n isstr(Keywords), split(Keywords, \" \"),\r\n 1=1, Keywords\r\n)\r\n| mvexpand keyword\r\n| regex keyword!=\"^\\W+$\"\r\n| stats count as kw_count by keyword\r\n| sort 20 -kw_count\r\nIn general, keywords aren’t the most interesting metadata out there, but in some cases, it can be used to find\r\nsomething very interesting, that’s when you go looking/filtering on keywords such as confidential, restricted and\r\nso on. We have seen it several times that documents marked as confidential have been published by accident on a\r\ncompany website. Hunt for them and take them down.\r\nOf course, it also depends on how your organization is marking document levels. Some software can put it into a\r\nseparate metadata field rather than keywords, or it might not be in metadata at all. You can also index a whole\r\ndocument’s content by Splunk to search inside it for these confidential keywords. This part would need to be\r\nadjusted per company as it often varies.\r\nSimilarly to keywords, documents also contain comments left by the author when writing, for example, a draft\r\nbefore publishing the final revision or personal opinions/notes. It’s not unusual that the author forgets to delete\r\nthose comments before publishing the document. It can be painful to a company’s reputation to leak confidential\r\ninformation especially in the case of lawyers… Let’s check your footprint for comments:\r\nindex=\"document_metadata\" Comments!=\"\"\r\n| table FileName, Comments\r\nDiving into the more scary part: file paths. These paths often contain either a path on a local disk of the person\r\nproducing the document or a file share location on a network, although there can be also other interesting\r\nlocations exposed just as the file structure on a web server. How is it possible that such artifacts are even\r\ncontained in metadata? The most common case is exporting a document or conversion between formats.\r\nhttps://outpost24.com/blog/metadata-hackers-best-friend/\r\nPage 10 of 15\n\nLet’s say that you prepared a Word document for publication on the website when the final version is approved,\r\nyou export it to PDF and then publish online. Most of the software that takes care of exporting the document in an\r\nother format (or better say a plugin within the software for converting it into other formats) embeds the\r\ninformation about a file which was used for conversion into the target format as it can be often seen that an MS\r\nWord docx file was used to produce the PDF report.\r\nOther less common cases which results in this artifact is importing the file and another one is when a file is printed\r\nalthough this one is rarely seen but if so, it then often contains also some kind of printer identification (name \u0026\r\nmodel, IP address on network etc…). Extracting file paths from metadata is a little bit more complicated as we are\r\ngoing to use regex to find either /unix/style/paths or \\\\windows\\file\\share\\paths :\r\nindex=\"document_metadata\"\r\n| rex field=_raw \"\\\"(?\u003cfile_path\u003e(([A-Z]:)?\\\\\\\\\\\\\\\\|/)([-a-zA-Z _\\.]+(/|\\\\\\\\)){2,}[^\\\"]+)\\\"\"\r\n| where file_path!=\"*\"\r\n| table FileName, file_path\r\nAnalyzing metadata timestamps\r\nUntil now, we’ve been mostly playing with metadata having values as a string, however, there are also various\r\nmetadata that contains timestamps allowing us to parse it in Splunk into a format that is understood as a date and\r\ntime and plotting it into the charts. One of those timestamps that are very often inside the document metadata is\r\nthe time of creation of the document which can be extracted with this query:\r\nindex=\"document_metadata\" CreateDate=\"*\"\r\n| eval document_created=case(\r\n match(CreateDate, \"^\\d{4}:\\d{2}:\\d{2} \\d{2}:\\d{2}:\\d{2}[-\\+]\\d{2}:\\d{2}\"), strptime(CreateDate, \"%Y:%m:%d %H:%\r\n)\r\n| eval _time=document_created\r\n| bucket _time span=1d\r\n| timechart span=1d dc(FileName) as documents\r\nAnd similarly it can be also be done to extract when the document was modified the last time:\r\nhttps://outpost24.com/blog/metadata-hackers-best-friend/\r\nPage 11 of 15\n\nindex=\"document_metadata\" ModifyDate=\"*\"\r\n| eval document_modified=case(\r\n match(ModifyDate, \"^\\d{4}:\\d{2}:\\d{2} \\d{2}:\\d{2}:\\d{2}[-\\+]\\d{2}:\\d{2}\"), strptime(ModifyDate, \"%Y:%m:%d %H:%\r\n)\r\n| eval _time=document_modified\r\n| bucket _time span=1d\r\n| timechart span=1d dc(FileName) as documents\r\nWhen parsing the time in Splunk, we need to take care that different software can put timestamps in different\r\nformats into the metadata. Increasing the coverage of parsing those additional formats can be easily done by\r\nextending the case clause in the query. From the picture, we can see that we are able to track files from many\r\nyears ago! At first this timeline might not seem to provide a lot of information however it can be used in several\r\nways.\r\nBy analyzing the spikes in a monthly drill down, one can see the company activity that they produce and update\r\npublic content the second week around Tuesday every month. This is not such a big deal although it provides\r\nsome intel when the adversary is planning the attack.\r\nWhat’s most interesting for the attacker is to filter out what documents have been recently created. Using the\r\nqueries above we can find out that someone was using MS Word 2007 which we all know is very outdated these\r\ndays and provide a very good target to be compromised, however, combining it with timestamps, we can learn that\r\nthe last time we saw it being used in a company was December 2007. With this additional insight, our perfect\r\ntarget is suddenly not that perfect anymore.\r\nOn the other hand, if we see that it was created using MS Word 2007 just a week ago, guess what the odds are that\r\nthe poor soon-to-be-compromised-guy-if-not-already is still using it today…? Those are the employees you want\r\nto hunt for from the security perspective, they’ve been slipping under your radar for many years, or the service\r\ndesk was not doing a good job or perhaps in the case we’ve just seen is that they have friends at the service desk\r\nto arrange not to update their office suite because they hate the new Office 365 interface that is standard at your\r\ncompany… Either way: you need to fix that.\r\nWrap it all together in a user-friendly dashboard\r\nIn the section above, we covered some of the basic queries that can be used for threat hunting in the metadata and\r\nit’s just a tip of the iceberg (it’s a really huge one). By now, you should have a good starting point to know where\r\nto look next and dig more into the data as it’s not possible to cover everything in this article. We might be working\r\non a book in that case.\r\nhttps://outpost24.com/blog/metadata-hackers-best-friend/\r\nPage 12 of 15\n\nNext, we suggest you step on our path to this wonderland of metadata and put those queries into a nice Splunk\r\ndashboard, providing you with the situational awareness of your company’s attack surface. The graphs are nice\r\nand even better in case if you need to get some extra budget from your direct manager, as we all know the SOC\r\ndepartment is not usually the first one to receive it.\r\nFor you and scared managers, you can import into the splunk this dashboard (click to download) which we created\r\nby compiling some basic queries discussed earlier giving you a very good starting point:\r\nA good practice is to regularly update Splunk about the data your organization is producing and exposing with a\r\ncombination of saved searches that will alert you that Jane Doe is still using Word 2007 to create confidential\r\ninformation which somehow by pure mistake ended up on the company’s website…\r\nThe Outpost24 Solution\r\nIt’s vital to frequently monitor the evolution of files and the dark data that are published by your company,\r\nenabling you with a completely new type of threat intelligence of your company’s security posture. It’s not about\r\nthe TI of the attackers of which 99% are never going to attack you, it’s about your own company and how it’s\r\nperceived by threat actors.Your security team has an inside view of the company, the processes there, your list of\r\nhigh value targets (HVT’s), and list of (sub)domains, however our experience shows that it’s always incomplete\r\ne.g. the vulnerability management team maintains a list of websites to scan that’s most of the time incomplete\r\ncompared to the reality of what is actually exposed to the internet because it’s managed in some outdated Excel\r\nsheet. This view is very different from how the attacker sees your company from the outside and exploits the web\r\nassets that are not on your protection list hence not maintained and secured over time.\r\nhttps://outpost24.com/blog/metadata-hackers-best-friend/\r\nPage 13 of 15\n\nOutpost24 offer solutions and expert services in the area of reconnaissance, counterintelligence, and OSINT.\r\nThrough our EASM platform we are able to provide you with a near real-time view of your attack surface in the\r\nsame way threat actors see you from the outside. In this article we just touched the tip of a very huge iceberg of\r\nsensitive information companies are exposing.\r\nThrough our platform, we provide a flexible next step to address the danger of this problem. Request your free\r\npersonalized attack surface analysis with one of our Outpost24 experts.\r\nAbout the Author\r\nhttps://outpost24.com/blog/metadata-hackers-best-friend/\r\nPage 14 of 15\n\nWith over 20 years of experience, Stijn is a seasoned entrepreneur and cyber security leader. He has worked with\r\nstartups and enterprise organizations in both the private and public sectors, leveraging his industry knowledge and\r\ntechnical expertise to benefit all levels of the organization. Stijn holds the NATO/EU SECRET security clearance\r\nand is fluent in Dutch, French, and English.\r\nSource: https://outpost24.com/blog/metadata-hackers-best-friend/\r\nhttps://outpost24.com/blog/metadata-hackers-best-friend/\r\nPage 15 of 15",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://outpost24.com/blog/metadata-hackers-best-friend/"
	],
	"report_names": [
		"metadata-hackers-best-friend"
	],
	"threat_actors": [
		{
			"id": "08c8f238-1df5-4e75-b4d8-276ebead502d",
			"created_at": "2023-01-06T13:46:39.344081Z",
			"updated_at": "2026-04-10T02:00:03.294222Z",
			"deleted_at": null,
			"main_name": "Copy-Paste",
			"aliases": [],
			"source_name": "MISPGALAXY:Copy-Paste",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		}
	],
	"ts_created_at": 1775434272,
	"ts_updated_at": 1775791359,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/41ba7fe5a99190ab56577dd75d5d60f3d532665f.pdf",
		"text": "https://archive.orkl.eu/41ba7fe5a99190ab56577dd75d5d60f3d532665f.txt",
		"img": "https://archive.orkl.eu/41ba7fe5a99190ab56577dd75d5d60f3d532665f.jpg"
	}
}