29:null 2a:["$","title",null,{"children":"GPT Honeypot: Finding the Needle in the Haystack | Coalition Research's Workspace | Observable"}] 2f:T1480,## Why? Over time as computers have gotten faster and internet speeds have skyrocketed, threat actors have changed their methods. Sending a single request to every public IPv4 address used to be completely impractical for anyone besides big corporations like Google. A threat actor would, instead, pick a target and go to work finding a weak spot in their network that they could exploit. But with the incredible advancements in technology the world has made, attacks have shifted to a lazier method. It's completely feasible for a threat actor with an exploit script for a critical vulnerability (and there are plenty available nowadays) to hit every public IPv4 address, even on multiple ports. Without much programming or network knowledge, they can throw an exploit at the wall and see what sticks. In general, this is more advantageous for the threat actors; one critical vulnerability discovered in a service or product used by a few thousand organizations and all of the sudden they've got huge payout potential. The downside to this method, however, is they don't often pay close attention to the things that didn't stick to the wall. This is where honeypots come in. A honeypot is a system or service sitting on a publicly accessible IP address that pretends to be a vulnerable technology. Every connection, payload and packet sent to it will get logged for observation and analysis. A typical part of this analysis is applying predefined rules and tags to the honeypot traffic. If the request or payload matches a certain criteria, or rule, tag it. Tags can be a variety of things, most commonly the name of the technology being targeted by the traffic and sometimes even a specific vulnerability the sender is attempting to exploit. With proper rules and tags on a honeypot, two key insights are gained. First, you're able to see, in realtime, what products/services/technologies are being actively targeted. This could lead to early awareness of a zero-day vulnerability. Second, you can learn more information about already publicized vulnerabilities, potentially zero-days, that aren't widely known. Say security organization X publishes a security advisory alerting the world of a critical vulnerability in product Y. This advisory includes information on which versions are affected, how to install a patch, and that it's exploited by sending a HTTP POST request on the `/Y/login` path. This could be a common request you'd see every time a user logs into the system. But it's only normal to see that request when it's sent to an IP belonging to an organization that uses product Y. No one should be sending that to a random IP address that's hosting a honeypot unless there's something suspicious happening. So analyzing traffic on that path to a honeypot may show some interesting information in the payload such as a specific header being set that's required to exploit the vulnerability or the same authentication token being sent to every endpoint which could be evidence of auth bypass. This is important information that could be used by an organization using product Y to identify malicious traffic on their network. ### What we could have known Coalition deploys a wide array of honeypots across the globe. These honeypots capture nearly 1 billion events each day, most of which go untagged and unnoticed. Much of this traffic is just noise. There are numerous organizations, like Google, that scan the entire public IPv4 space (we do it too!) without attempting anything malicious. While this noise makes up a meaningless haystack that is the internet, there exists among the soft, harmless hay some potentially very dangerous needles. Let's look at an example. At the end of May 2023, Progress Software publicly disclosed a vulnerability in their MOVEit Transfer web application that allowed for RCE (remote code execution) via SQL injection. Immediately upon becoming aware of the disclosure, Coalition Security Labs got to work on identifying the vulnerability (details were scarce at the time) so we could notify our policyholders who were exposed. Read the full write up here. We found during this process two interesting HTTP request paths: `/human.aspx` and `/human2.aspx`. We soon learned that `/human.aspx` is the default path for the login panel of MOVEit transfer and `/human2.aspx` was an IoC (indicator of compromise) used by the cl0p ransomware group to exploit this zero-day. Why does this matter? Through this process, we discovered that we had seen `/human.aspx` before on our honeypots. And not just in the days leading up to disclosure, but going as far back as November 2022. More than 6 months before widespread exploitation, we had data indicating reconnaissance being done to identify instances of MOVEit on the public internet. This begged the question "How do we find these needles in such a massive haystack?". Initially we created an anomaly detection system to identify, among other things, HTTP events on our honeypots requesting a path we haven't yet seen. The results were enormous. Too much for a human researcher to sift through each day trying to identify what's noise and what's potentially malicious. 30:T959, mermaid` flowchart TB classDef orange fill:#ff5f21,stroke:#333,stroke-width:2px; classDef pink fill:#e2a5ee,stroke:#333,stroke-width:2px; classDef blue fill:#2b70d7,stroke:#333,stroke-width:2px; classDef yellow fill:#ffbb3c,stroke:#333,stroke-width:2px; A[Create CSV of Daily \nHoneypot HTTP Payload Anomalies] --> B([Detect Anomalies \nGCP Composer DAG]) B -- Write anomalies to CSV --> C[(\nAnomalies Bucket \nGoogle Cloud Storage)] C -- Read anomalies CSV --> D((Cleanse Anomalies\n of 'random' strings\n GCP Cloud Run)) D -- Write cleansed anomalies to CSV --> E[(\nGPT HP Bucket \nGoogle Cloud Storage)] E --> F[Generate Rules and Tags] F -- Read cleansed anomalies CSV --> G([GCP Composer DAG]) G --> H(Apply Regex Filters) H --> I{Use SerpApi to \nsearch Google for exploits\n on packetstormsecurity.com\n and exploit-db.com} I -- No results --> K{Use SerpApi to search\n for exploits in \nGitHub Advisories} I -- Got results --> J{Check for CVE\n in results} K -- No results --> KB{User SerpAPI to search\n for exploits in \nGitHub repositories} K -- Got results --> J KB -- No results --> MB(Use SerpAPI to search\n Google with entire \npayload and return snippets\n from top 10 results) KB -- Got results --> J J -- CVE Not Present --> M[Use SerpApi to \nsearch Google with\n entire payload] J -- CVE Present --> L(Extract code and CVEs) L --> M(Query CVE table in\n BigQuery for description) M --> N(Ask LLM to identify\n affected technology \nnames in CVE description) N --> O(Ask LLM to create \nrules with provided \nexamples and formatting) MB --> O O -- Write rules and tags to JSON --> P[(\nGPT HP Bucket \nGoogle Cloud Storage)] P --> Q[Review GPT HP Rules and Tags] Q -- Read GPT HP rules and tags --> R([Tag Honeypot Shadow\n Table DAG]) R --> S[(Shadow Honeypot\n Table BigQuery)] S -- Query HTTP Events --> T(Add GPT HP tags\n to HTTP events \nbased on matching rules) T -- Write HTTP Events --> U[(Shadow Honeypot\n Table BigQuery)] U -- Query HTTP Events --> V[Observe GPT tags,\n trends, and events \nGCP Looker Studio Report] V --> W[Search GPT HP\n rules and production \nhoneypot events based on\n Promoter app Streamlit] class A,B,C orange; class D,E,F,G,H,I,J,K,KB,L,M,MB,N,O,P,S,U blue; class Q,R,T,V,W yellow; `31:T2540,### Leveraging LLMs While "ask ChatGPT" was a great idea for many things at the time, you recognize an immediate issue if you know anything about these large language models: they're still models. Models are trained on a specific dataset and released in versions. For our goals, we can't rely on a newly trained model with all the information about everything every hour of every day. This is where LangChain comes in. LangChain is a framework for developing applications powered by language models. It provides two key things to applications: context and reason. The early stages of the GPT HP project utilized LangChain Agents and Tools. In order to get more accurate answers to questions about our strange HTTP paths, we used a Google Search Tool and gave it to an Agent. The Agent was able to utilize the Search Tool, the LLM and a given HTTP path to determine what to Google, perform the search, parse the results and feed relevant information to the LLM to use as context when answering questions. While this process seemed promising given it's accuracy when testing with our `/human.aspx` example, it proved to be unreliable and, frankly, slow at scale. Remember, at a billion events per day we need this to be fast. While we couldn't control the reasoning and use of tools by the Agent, the general idea was great: search Google, feed the results to an LLM, and get answers. This workflow follows the behaviour and reasoning of a human instead of an LLM, all at a much slower pace. So we decided to take a programmatic/LLM hybrid approach with speed and autonomy in mind. ### Google We start out by using the Google Search tool in a programmatic way instead of relying on Agent/LLM reasoning. Reading in our anomalous HTTP payloads, we extract specific parts to feed into our Google Search query, utilizing SerpAPI. Our initial query targets existing exploit PoCs (proof of concepts). Why? A lot of the payloads we see on our honeypots fall in two categories: 1. Older vulnerabilities with existing PoCs and CVE details that just haven't gained traction yet, or 2. They're targeting technologies that have been exploited before and the similarities may give us clues to what the related technology is. One thing LLMs like that behind ChatGPT are really good at is understanding code, especially Python. So if we can feed our LLM exploit code and a HTTP payload, there's a good chance it can answer the questions we're asking, and do so with accuracy. To accomplish this, we employ a hierarchy of trust in sources of exploit code. Our initial SerpAPI query looks for results specifically from exploit-db.com and packetstormsecurity.com. When we see exploit code on these sites, they tend to be more trustworthy than places like GitHub where anyone can create a repo and put whatever files they want. Exploits for a CVE on these sites are typically added to the references section on the NVD page for that CVE, giving them added credibility. Sometimes we get no results from our initial query. That's when we turn to GitHub advisories. These, again seem to be more reliable than just any GitHub repo. If we still haven't got any hits, then we turn to general GitHub repos. After all, it's not uncommon to see legitimate exploits show up there before anywhere else. ### Creating a Prompt from Exploits Assuming we've gotten results from one of our exploit code queries, we load the page, extract the code, and feed it to the LLM. This has evolved as LLMs have evolved, allowing us to include multiple exploits (if multiple found) to better inform the analysis. Since we're trying to automate a lengthy process, we want the output to require as little human intervention as possible. So rather than just asking for related technologies and CVEs, we want it to generate the rules and tags in the format we use on our honeypots. That way we can feed the results directly to our honeypots without adding any extra steps in the pipeline. Let's dive into how we accomplish that. Our prompt starts with the same instruction. ```Analyze the code from the given vulnerability exploits and HTTP payload to generate rules that will match similar payloads to the given exploits. Only consider exploits that could have produced the the payload. The rules should focus only on the static portions (not dynamic values like IPs and dates) that are specific to the considered exploits.``` Then we include 4 key pieces: The exploit code we found, the original payload that hit our honeypots and was deemed an anomaly, formatting instructions, and examples. Those last two are important for solving one of the biggest hurdles when first implementing LLMs programmatically: expected output. If you go "ask ChatGPT" something, and then ask it the same thing again, you'll noticed the results, while similar in substance, can vary drastically in format. This is easy for a human to look past, but not for a programming language. We need to trust that it will respond in the exact format that we want. To do this, we leverage Pydantic. First we create Pydantic models with clearly define fields (expected types and description of the field is to help the LLM know where to put things). Then we use LangChain's built-in Pydantic Output Parser. Given a Pydantic model, the parser is able to create instructions for the LLM that clearly describe what the output should look like. Now we just need to combine these instructions with examples. These examples include existing rules and tags from our honeypots in the exact JSON schema we use, as well as a payload that matches. Putting all this together and invoking the LLM, we've gone from a strange new HTTP payload to properly formatted rules tagged with product/service name and sometimes even CVE, all in seconds. For a security researcher, this process can take over an hour. This is vital time saving as we see thousands of anomalous payloads every day. ### What if we don't find an exploit? Ideally we can stop there, but in reality we don't find exploits for everything, especially if we're looking at a zero-day vulnerability. But our goal is still the same. We need to identify these needles in our massive haystack. So, we return to our trusty friend Google. Again leveraging the SerpAPI, we form a new query, but now we're just looking to identify the product/service our HTTP payload was intended for. The benefits to our exploit code methodology were that we could 1. extract the code from the page, significantly limiting our token usage with the LLM, and 2. we only needed to build parsers for 3 different websites. So if we're going to expand our search, it's not feasible to be able to parse all the possible websites we'll hit or to send that much text to the LLM, especially since we don't want to just look at the first result in our search. Fortunately, Google and SerpAPI solve this for us. Similar to when you use Google in your browser, SerpAPI will return "snippets" in the initial results, rather than entire websites. These "snippets" are the few-sentence summaries that show up under the links when you make a Google search. Sending a set of these snippets to the LLM is much more practical and useful than entire webpages. Now that we've got information on our payload, we create a prompt very similarly to how we initially did with our exploits. ```Analyze the given HTTP payload and (if present) snippets from Google search results to determine what technology the payload is likely intended for. Then generate rules based on the static portions of the payload that will always be present only in payloads intended for the identified technology and add tags for the technology. If the payload is attempting to do something malicious, include MALICIOUS in the tags list.``` ### What if we can't identify the tech? Part of trying to find a needle in a haystack is, well, dealing with a lot of hay. The reality is most of the traffic we see on our honeypots, even the anomalies, is just noise. Sometimes it's randomly generated strings. This noise will ultimately yield no results in our GPT HP process. Using LLMs is not cheap and while they are getting steadily faster, they can still be quite slow. It may take hours to process all the anomalies from just one day using this process. At this point, we realized we needed to implement a layer of filtering before we start the whole process in order to reduce the amount of resources we're using that lead to no results. To cut down on cost and times, we employ two types of filtering. The first is simple: regex. It was fairly easy to identify some things that can be matched with a regex that were clearly unwanted noise just by looking at the data. This also allows us to cut down on "almost duplicates", where we see very similar payloads, just with a different value for fields like the date header or a timestamp in the path. However, one thing regex does not do well is "random" strings. Using quotes here because with computers, nothing is truly random. Implementing a combination of DGA Intel, Tensorflow, Natural Language Toolkit, and IT words lists, we're able to identify HTTP paths that are "random" strings with tremendous accuracy. The biggest concern here is false positives, we don't want to get rid of things that aren't actually random, but it's okay if we let a few randoms through the door. Our initial tests were showing <3% false positive rate, many of which still appear to be noise, just not "random" strings. 32:Td5e,## GPT HP in use Once we had a pipeline of new rules and tags in our desired format, we wanted to continue automating as much as possible to get things to production and see real results. Right away, however, we recognized there needed to be a human review layer. As powerful and "cool" as these LLMs and their capabilities are, they still have flaws and inconsistencies. To address this, we built a review application using Streamlit, a Python framework for quickly developing and deploying web applications. The plan was to load our GPT rules and tags, along with the payloads they were based on, into this app for researchers to quickly analyze and approve or reject. This also gave us a dataset of rules that GPT missed on, which we could use down the road to identify where the mistakes are happening and make improvements to the process. Then with the push of a button, we'd export the approved rules and create a pull request to our production honeypots. ### Not the expected results Initially, this process was very promising. We were able to increase our total distinct tags by 25% in a fraction of the time it would normally take. But it soon became clear that this was not sustainable. The backlog of things to review quickly skyrocketed and it was no longer feasible to have researchers review everything. Going back to the drawing board, we needed a way to deliver results at a much faster pace. The way the research team observes production honeypot data and trends is through Google Looker Studio (formerly Data Studio). This service contains prebuilt connectors to a number of GCP (Google Cloud Platform) data sources such as GCS buckets, BigQuery, PostgreSQL, and many more. These connectors allow you to load data into a report where you can create charts and graphs. This makes Looker Studio a powerful tool for visualizing data without requiring any programming, front-end or back-end. Considering our existing approach for observing our honeypot data, we decided to do the same with our GPT HP data. In order to prevent our verified production honeypot data from being clouded with potentially false GPT HP data, we maintain a separate BigQuery table that includes both production honeypot tags and GPT HP tags. This approach allows us to view trends side-by-side without interfering with the reports that we use for key security insights on a daily basis. ### How this new approach differs The benefits that come with putting our GPT HP data straight into their own visualizations stem from one key component. Instead of going through each new rule and tag one-by-one and approving or rejecting, now we can see the larger impact of this data at full scale and choose what to "approve" without the time consumption of rejecting the rest. Since our visualizations are only showing the HP traffic and tags, we need a way to quickly "promote" our GPT HP rules and tags to the production honeypots. So we repurposed our review app built with Streamlit into a "Promote" app. It allows researchers to input tags created by GPT and deemed to be legitimate and get back two things. First, all the rules GPT generated that include those tags so they can be quickly copied and added to the production honeypots. And second, it will retrieve any existing production rules that include those tags so the user can verify we don't already have similar rules for that tag.33:T63e,## The results are in Developing new AI-driven tools and services is exciting, with seemingly endless possibilities. But to avoid getting too caught up in the excitement, we need to see real impact from the things we build with AI. To commit precious resources over a long period of time, GPT HP needed to be worth it. ### Time saved One of our biggest pain points in adding new tags to our honeypots is the time it takes. Typically this process, now partially automated by GPT HP, could take an hour or more. Initial use of GPT HP is showing a 6-7x improvement at minimum. As we take the lessons we've learned along the way and LLMs continue to make improvements, we're confident GPT HP can become fully automated with no need for human review or supervision. ### The needle in the haystack We started off on this journey with the hope of accomplishing a task that used to seem nearly impossible. Billions of honeypot events. Thousands of new things every day. All it took was one needle in this massive haystack to indicate millions in losses to the victims of the MOVEit vulnerability. The chart below shows how many distinct tags we see in our honeypot data from our existing production set vs distinct tags added to our honeypot data by GPT HP. The results are promising. We're seeing real things surfaced. We believe it's only a matter of time before one of these needles is found before it causes any damage. All it takes is one. At the end of the day, we're still a cyber insurance company. We have policyholders that we care deeply about. Our mission remains to protect the unprotected.34:T4ec,tag_graph2 = { const tags_data = await FileAttachment("gpt_hp_distinct_tags@3.csv").csv(); tags_data.sort((a, b) => new Date(a.date) - new Date(b.date)); // sort by date in ascending order // Converts data // from: { date: "YYYY-MM-DD", verified_count: "100", unverified_count: "100" } // to: { date: "YYYY-MM-DD", count: 100, type: "Verified|Unverified" } const data = [ ...tags_data.map(({ date, verified_count }) => ({ date, type: "Production", count: parseInt(verified_count, 10), })), ...tags_data.map(({ date, unverified_count }) => ({ date, type: "GPT HP", count: parseInt(unverified_count, 10), })), ]; const ybuffer = 100; const ymax = Math.max(...data.map(({count}) => count)); return Plot.plot({ x: { label: null, grid: true, domain: data.map(d=>d.date), padding: 0.4, tickRotate: -45 }, y: { grid: true, label: "Distinct Tag Count", domain: [0, ymax + ybuffer], }, color: { legend: true, range: ["#FFBB3C", "#2B70D7"] }, marginBottom: 90, marginLeft: 50, marks: [ Plot.line(data, { x: "date", y: "count", stroke: "type" }), Plot.ruleY([0]) ] }) }35:[{"id":"a12f76d576628a7e501a43af1312fafc8a98be4f9b93c2d6e63cfda00502e75f08b175faa6d72c556e6795a47d94384f4a58f4086dda82345f7538538405adc9","href":"https://static.observableusercontent.com/files/a12f76d576628a7e501a43af1312fafc8a98be4f9b93c2d6e63cfda00502e75f08b175faa6d72c556e6795a47d94384f4a58f4086dda82345f7538538405adc9","name":"human_counts.csv","type":"text/csv","lastModified":1712588988038.721,"size":1222},{"id":"98f0498c531cec26447aedbcb969a408e71518cfb6361bf36bf00b0ebe0afc94ed8cc1eb7b8ecaace6b6a2390ad6f79395fd35dc106d4ba1217d9cf52f91edd6","href":"https://static.observableusercontent.com/files/98f0498c531cec26447aedbcb969a408e71518cfb6361bf36bf00b0ebe0afc94ed8cc1eb7b8ecaace6b6a2390ad6f79395fd35dc106d4ba1217d9cf52f91edd6","name":"human2_counts.csv","type":"text/csv","lastModified":1712595656953.22,"size":82},{"id":"4847c0e8580090e19ab105d9ad1ca9fcae66df6c1b0df97dda2f3105a0b3cce8d9637527851b960f9403d584b82fa95061ebbdf6a37635c04950a417ab71eff6","href":"https://static.observableusercontent.com/files/4847c0e8580090e19ab105d9ad1ca9fcae66df6c1b0df97dda2f3105a0b3cce8d9637527851b960f9403d584b82fa95061ebbdf6a37635c04950a417ab71eff6","name":"gpt_hp_distinct_tags@3.csv","type":"text/csv","lastModified":1713544357215.021,"size":580},{"id":"af06abca265145e1d4612cef125c296009b34b5425784b8c0a2cd7147f6df63a73a477df96e4af547430a22209d3ddbca2a03c2845de36b2d90f9aeec3a98a08","href":"https://static.observableusercontent.com/files/af06abca265145e1d4612cef125c296009b34b5425784b8c0a2cd7147f6df63a73a477df96e4af547430a22209d3ddbca2a03c2845de36b2d90f9aeec3a98a08","name":"human_current_counts.csv","type":"text/csv","lastModified":1712597094945.528,"size":527}] 2d:{"id":"5bc92c1a5929771a","slug":"gpt-honeypot-finding-the-needle-in-the-haystack","title":"GPT Honeypot: Finding the Needle in the Haystack","thumbnail":"ef32ce350d27880418dde0bac78e8a31d63caa6081df1309671f94539d5a4fd9","access_level":"public","create_time":"$D2024-04-02T19:52:13.960Z","update_time":"$D2024-05-01T20:28:09.111Z","view_time":null,"first_public_time":"$D2024-05-01T20:38:58.229Z","has_unpublished_edits":null,"fork":false,"stars":0,"starred":false,"owner":{"type":"team","id":"5ec40b2e0ec46003","login":"coalition-research-ws","name":"Coalition Research's Workspace","avatar_url":"https://avatars-next.observableusercontent.com/3b1325f1169c0e8de44164dc94d1939f5ad283e167296e044081e2dd9c0b41c7","tier":"starter_2024"},"version":699,"publish_version":null,"role":null,"authored":false,"authors":[{"type":"individual","id":"399376b5ec6d3fad","login":"coalition-research","name":"Coalition Research","avatar_url":"https://avatars-next.observableusercontent.com/652745f40b1c829228148400a46263cdda4fc70addd5a4e7e92004d7298afe17","tier":null}],"members":[{"type":"individual","id":"399376b5ec6d3fad","login":"coalition-research","name":"Coalition Research","avatar_url":"https://avatars-next.observableusercontent.com/652745f40b1c829228148400a46263cdda4fc70addd5a4e7e92004d7298afe17","tier":null,"role":"editor"},{"type":"team","id":"5ec40b2e0ec46003","login":"coalition-research-ws","name":"Coalition Research's Workspace","avatar_url":"https://avatars-next.observableusercontent.com/3b1325f1169c0e8de44164dc94d1939f5ad283e167296e044081e2dd9c0b41c7","tier":"starter_2024","role":"editor"}],"comments":[],"custom_thumbnail":true,"trashed":false,"lapsed":null,"subscribed":null,"forks":0,"collection":null,"type":"notebook","body":{"title":"GPT Honeypot: Finding the Needle in the Haystack","cells":[{"id":0,"value":"# GPT Honeypot: Finding the Needle in the Haystack","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","output":"","database":"$undefined"},{"id":5,"value":"Over the past 9 months, the research team at Coalition has been developing a process to streamline our identification of vulnerabilities being exploited in the wild. This blog post will take you on a deeply technical journey exploring why and how we built this, how we use it, and the results we're seeing in our mission to protect the unprotected.","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","output":"","database":"$undefined"},{"id":10,"value":"$2f","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","output":"","database":"$undefined"},{"id":122,"value":"### Honeypot Traffic on `/human.aspx` Path","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","output":"","database":"$undefined"},{"id":57,"value":"graph = {\n const human_data = await FileAttachment(\"human_counts.csv\").csv();\n let filtered_data = human_data.filter(d => new Date(d.clmn100001_) <= new Date('2023-05-22'));\n filtered_data.sort((a, b) => new Date(a.clmn100001_) - new Date(b.clmn100001_)); // sort by date in ascending order\n return Plot.plot({\n x: {\n label: \"Event Count\",\n },\n y: {\n label: \"Date\",\n domain: filtered_data.map(d=>d.clmn100001_),\n padding: 0.2\n },\n marginLeft: 90,\n marks: [\n Plot.barX(filtered_data, {y: \"clmn100001_\", x: \"clmn100002_\", fill: '#2B70D7'}),\n Plot.ruleX([0])\n ]\n })\n}","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","output":"$undefined","database":"$undefined"},{"id":124,"value":"### Honeypot Traffic on `/human2.aspx` Path","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","output":"","database":"$undefined"},{"id":128,"value":"human2_graph = {\n const human2_data = await FileAttachment(\"human2_counts.csv\").csv();\n human2_data.sort((a, b) => new Date(a.clmn100001_) - new Date(b.clmn100001_)); // sort by date in ascending order\n return Plot.plot({\n x: {\n label: \"Event Count\",\n },\n y: {\n label: \"Date\",\n domain: human2_data.map(d=>d.clmn100001_),\n padding: 0.2\n },\n marginLeft: 90,\n marks: [\n Plot.barX(human2_data, {y: \"clmn100001_\", x: \"clmn100002_\", fill: '#2B70D7'}),\n Plot.ruleX([0])\n ]\n })\n}","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","output":"$undefined","database":"$undefined"},{"id":137,"value":"### Recent Honeypot Traffic on `/human.aspx` Path","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","output":"","database":"$undefined"},{"id":141,"value":"graph_current = {\n const human_current_data = await FileAttachment(\"human_current_counts.csv\").csv();\n human_current_data.forEach(d => {\n let date = new Date(d.clmn100001_);\n d.clmn100001_ = `${date.getFullYear()}-${('0' + (date.getMonth() + 1)).slice(-2)}`; // format date as 'year-month'\n });\n human_current_data.sort((a, b) => new Date(a.clmn100001_) - new Date(b.clmn100001_)); // sort by date in ascending order\n return Plot.plot({\n x: {\n label: \"Event Count\",\n },\n y: {\n label: \"Date\",\n domain: human_current_data.map(d=>d.clmn100001_),\n padding: 0.2\n },\n marginLeft: 90,\n marks: [\n Plot.barX(human_current_data, {y: \"clmn100001_\", x: \"clmn100002_\", fill: '#2B70D7'}),\n Plot.ruleX([0])\n ]\n })\n}","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","output":"$undefined","database":"$undefined"},{"id":55,"value":"If you recall around the same time, large language models (LLMs) were making a number of headlines, mainly in the form of ChatGPT. And rightfully so. It's capabilities became an incredibly powerful tool to accelerate many day-to-day processes across all industries. So what if it could take, for instance, a strange HTTP path and quickly identify what service/product it's related to? Let's find out.","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","output":"","database":"$undefined"},{"id":182,"value":"## How? \nIn this section, we're going to show how the system works behind the scenes. Again, it will be deeply technical, but covers the challenges of using new technologies and even limitations of these trendy LLMs.","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","output":"","database":"$undefined"},{"id":186,"value":"viewof mermaidContainer = html`

`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","output":"$undefined","database":"$undefined"},{"id":277,"value":"mermaidJs = require('mermaid@8.7/dist/mermaid.min.js');","pinned":true,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","output":"$undefined","database":"$undefined"},{"id":190,"value":"$30","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","output":"$undefined","database":"$undefined"},{"id":15,"value":"$31","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","output":"","database":"$undefined"},{"id":23,"value":"$32","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","output":"","database":"$undefined"},{"id":27,"value":"$33","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","output":"","database":"$undefined"},{"id":618,"value":"$34","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined","output":"$undefined","database":"$undefined"},{"id":689,"value":"

This blog post is designed to provide general information on the topic presented and is not intended to construe or the rendering of legal or other professional services of any kind. If legal or other professional advice is required, the services of a professional should be sought. The views and opinions expressed as part of this blog post do not necessarily state or reflect those of Coalition. Neither Coalition nor any of its employees make any warranty of any kind, express or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, product or process disclosed. The blog post may include links to other third-party websites. These links are provided as a convenience only. Coalition does not endorse, have control over nor assumes responsibility or liability for the content, privacy policy or practices of any such third-party websites.

","pinned":false,"hidden":false,"mode":"md","author":"$undefined","summary":"$undefined","output":"","database":"$undefined"}],"files":"$W35","stdlib":"1","titling":"auto"}} 2e:"$2d:body"