{"id":15161,"date":"2025-04-25T05:16:55","date_gmt":"2025-04-25T05:16:55","guid":{"rendered":"https:\/\/dmsretail.com\/RetailNews\/black-hat-asia-2025-innovation-in-the-soc\/"},"modified":"2025-04-25T05:16:55","modified_gmt":"2025-04-25T05:16:55","slug":"black-hat-asia-2025-innovation-in-the-soc","status":"publish","type":"post","link":"https:\/\/dmsretail.com\/RetailNews\/black-hat-asia-2025-innovation-in-the-soc\/","title":{"rendered":"Black Hat Asia 2025: Innovation in the SOC"},"content":{"rendered":"

\"Retail<\/a><\/p>
\n<\/p>\n

\n

Cisco is honored to be a partner of the Black Hat NOC (Network Operations Center), as the Official Security Cloud Provider. This was our 9th year supporting Black Hat Asia.<\/p>\n

We work with other official providers to bring the hardware, software and engineers to build and secure the Black Hat network: Arista, Corelight, MyRepublic and Palo Alto Networks.<\/p>\n

The primary mission in the NOC is network resilience. The partners also provide integrated security, visibility and automation, a SOC (Security Operations Center) inside the NOC.<\/p>\n

\n
\"Black
Fig. 1<\/strong>: Presenting the Black Hat Asia Dashboards<\/figcaption><\/figure>\n<\/div>\n

On screens outside the NOC, partner dashboards gave attendees a chance to view the volume and security of the network traffic.<\/p>\n

\n
\"Black
Fig. 2:<\/strong> Black Hat dashboards on display outside of the NOC<\/figcaption><\/figure>\n<\/div>\n

From Malware to Security Cloud<\/h2>\n

Cisco joined the Black Hat NOC in 2016, as a partner to provide automated malware analysis with Threat Grid. The Cisco contributions to the network and security operations evolved, with the needs of the Black Hat conference, to include more components of the Cisco Security Cloud.<\/p>\n

Cisco Breach Protection Suite<\/strong><\/p>\n

Cisco User Protection Suite<\/strong><\/p>\n

Cisco Cloud Protection Suite<\/strong><\/p>\n

When the partners deploy to each conference, we set up a world-class network and security operations center in three days. Our primary mission is network uptime, with better integrated visibility and automation. Black Hat has the pick of the security industry tools and no company can sponsor\/buy their way into the NOC. It is invitation only, with the intention of diversity in partners, and an expectation of full collaboration.<\/p>\n

As a NOC team comprised of many technologies and companies, we are continuously innovating and integrating, to provide an overall SOC cybersecurity architecture solution.<\/p>\n

\n
\"Black
Fig. 3<\/strong> Diagram showing different companies and solutions present in the NOC<\/figcaption><\/figure>\n<\/div>\n

The integration with Corelight NDR and both Secure Malware Analytics and Splunk Attack Analyzer is a core SOC function. At each conference, we see plain text data on the network. For example, a training student accessed a Synology NAS over the internet to access SMB shares, as observed by Corelight NDR. The document was downloaded in plain text and contained API keys & cloud infrastructure links. This was highlighted in the NOC Report as an example of how to employ better security posture.<\/p>\n

\n
\"Exported
Fig. 4:<\/strong> Exported report from Secure Malware Analytics<\/figcaption><\/figure>\n<\/div>\n

As the malware analysis provider, we also deployed Splunk Attack Analyzer as the engine of engines, with files from Corelight and integrated it with Splunk Enterprise Security.<\/p>\n

\n
\"Splunk
Fig. 5<\/strong>: Splunk Cloud Executive Order dashboard<\/figcaption><\/figure>\n<\/div>\n

The NOC leaders allowed Cisco (and the other NOC partners) to bring in additional software and hardware to make our internal work more efficient and have greater visibility. However, Cisco is not the official provider for Extended Detection & Response (XDR), Security Event and Incident Management (SEIM), Firewall, Network Detection & Response (NDR) or Collaboration.<\/p>\n

Breach Protection Suite<\/strong><\/p>\n

    \n
  • Cisco XDR: Threat Hunting, Threat Intelligence Enrichment, Executive Dashboards, Automation with Webex<\/li>\n
  • Cisco XDR Analytics (formerly Secure Cloud Analytics\/Stealthwatch Cloud): Network traffic visibility and threat detection<\/li>\n<\/ul>\n

    Splunk Cloud Platform<\/strong>: Integrations and dashboards<\/p>\n

    Cisco Webex<\/strong>: Incident notification and team collaboration<\/p>\n

    In addition, we deployed proof of value tenants for security:<\/p>\n

    The Cisco XDR Command Center dashboard tiles made it easy to see the status of each of the connected Cisco Security technologies.<\/p>\n

    \n
    \"XDR
    Fig. 6<\/strong>: Cisco XDR dashboard tiles at Black Hat Asia 2025<\/figcaption><\/figure>\n<\/div>\n

    Below are the Cisco XDR integrations for Black Hat Asia, empowering analysts to investigate Indicators of Compromise (IOC) very quickly, with one search.<\/p>\n

    We appreciate alphaMountain.ai and Pulsedive donating full licenses to Cisco, for use in the Black Hat Asia 2025 NOC.<\/p>\n

    \n

    The view in the Cisco XDR integrations page:<\/p>\n

    \n
    \"XDR
    Fig. 7<\/strong> Cisco XDR integrations page for Black Hat Asia<\/figcaption><\/figure>\n<\/div>\n
    \n
    \"XDR
    Fig. 8<\/strong>: Cisco XDR integrations page for Black Hat Asia<\/figcaption><\/figure>\n<\/div>\n

    SOC of the Future: XDR + Splunk Cloud<\/h2>\n

    Authored by<\/strong>: Ivan Berlinson, Aditya Raghavan<\/em><\/p>\n

    As the technical landscape evolves, automation stands as a cornerstone in achieving XDR outcomes. It\u2019s a testament to the prowess of Cisco XDR that it boasts a fully integrated, robust automation engine.<\/p>\n

    Cisco XDR Automation embodies a user-friendly, no-to-low code platform with a drag-and-drop workflow editor. This innovative feature empowers your SOC to speed up its investigative and response capabilities. You can tap into this potential by importing workflows within the XDR Automate Exchange from Cisco, or by flexing your creative muscles and crafting your own.<\/p>\n

    Remember from our past Black Hat blogs, we used automation for creating incidents in Cisco XDR from Palo Alto Networks and Corelight.<\/p>\n

    The following automation workflows were built specifically for Black Hat use cases:<\/p>\n

    Category: Create or update an XDR incident<\/strong><\/p>\n

      \n
    • Via Splunk Search API \u2014 XDR incident from Palo Alto Networks NGFW Threats Logs<\/li>\n
    • Via Splunk Search API \u2014 XDR incident from Corelight Notice and Suricata logs<\/li>\n
    • Via Splunk Search API \u2014 XDR incident from Cisco Secure Firewall Intrusion logs<\/li>\n
    • Via Splunk Search API \u2014 XDR Incident from ThousandEyes Alert<\/li>\n
    • Via Umbrella Reporting API \u2014 XDR Incident from Umbrella Security Events<\/li>\n
    • Via Secure Malware Analytics API \u2014 XDR Incident on samples submitted and convicted as malicious<\/li>\n<\/ul>\n

      Category: Notify\/Collaborate\/Reporting<\/strong><\/p>\n

        \n
      • Webex Notification on new Incident<\/li>\n
      • Last 6 hours reports to Webex<\/li>\n
      • Last 24 hours reports to Webex<\/li>\n<\/ul>\n

        Category: Investigate<\/strong><\/p>\n

          \n
        • Via Splunk Search API and Global Variables (Table) \u2014 Identify Room and Location (incident rules on status new)<\/li>\n
        • Identify Room and Location (incident playbook)<\/li>\n
        • Identify Room and Location (Pivot Menu on IP)<\/li>\n
        • Webex Interactive Bot: Deliberate Observable<\/li>\n
        • Webex Interactive Bot: Search in Splunk<\/li>\n
        • Webex Interactive Bot: Identify Room and Location<\/li>\n<\/ul>\n

          Category: Report<\/strong><\/p>\n

            \n
          • XDR incident statistics to Splunk<\/li>\n<\/ul>\n

            Category: Correlation<\/strong><\/p>\n

            \n
            \"XDR
            Fig. 9<\/strong>: Black Hat automations screen<\/figcaption><\/figure>\n<\/div>\n
            \n
            \"XDR
            Fig. 10<\/strong>: Black Hat automations screen<\/figcaption><\/figure>\n<\/div>\n

            Workflows Description<\/h3>\n

            Via Splunk Search API<\/strong>: Create or Update XDR Incident<\/p>\n

            \n
            \"Workflows
            Fig. 11<\/strong>: Workflows for XDR incident creation from Splunk<\/figcaption><\/figure>\n<\/div>\n

            These workflows are designed to run every five minutes and search the Splunk Cloud instance for new logs matching certain predefined criteria. If new logs are found since the last run, the following actions are performed for each of them:<\/p>\n

              \n
            1. Create a sighting in XDR private intelligence, including several pieces of information useful for analysis during an incident investigation (e.g., source IP, destination IP and\/or domain, destination port, authorized or blocked action, packet payload, etc.). These alerts can then be used to create or update an incident (see next steps), but also to enrich the analyst\u2019s investigation (XDR Investigate) like other integrated modules.<\/li>\n
            2. Link the sighting to an existing or a new threat indicator<\/li>\n
            3. Create a new XDR incident or update an existing incident with the new sighting and MITRE TTP.\n
                \n
              • To update an existing incident, the workflow uses the method described below, enabling the analyst to have a complete view of the different stages of an incident, and to identify whether it could potentially be part of a Training Lab (several Assets performing the same actions):\n
                  \n
                • If there is an XDR incident with the same observables related to the same indicator, then update the incident<\/li>\n
                • If not, check if there is an XDR incident with the same observables and only if the observable type is IP or Domain then update the incident<\/li>\n
                • If not, check if an XDR incident exists with the same target asset, then update the incident<\/li>\n
                • If not, create a new incident<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n
                  \n
                  \"Incident
                  Fig. 12<\/strong>: Incident sample created by the workflow<\/figcaption><\/figure>\n<\/div>\n
                  \n
                  \"Incident
                  Fig. 13<\/strong>: Sightings\/Detections part of the incident<\/figcaption><\/figure>\n<\/div>\n
                  \n
                  \"Get
                  Fig. 14<\/strong>: Workflow: Create XDR Incident from Splunk, high level view<\/figcaption><\/figure>\n<\/div>\n

                  Identify Room and Location<\/h3>\n

                  It was important for the analysts to obtain as much information as possible to help them understand whether the malicious behavior detected as part of an incident was a true security incident with an impact on the event (a True Positive), or whether it was legitimate in the context of a Black Hat demo, lab and training (a Black Hat Positive).<\/p>\n

                  One of the methods we used was a workflow to find out the location of the assets involved and the purpose of it. The workflow is designed to run:<\/p>\n

                    \n
                  • Automatically on new XDR incident and add the result in a note<\/li>\n
                  • On demand via a task in the XDR incident playbook<\/li>\n
                  • On demand via the XR pivot menu<\/li>\n
                  • On demand via the Webex interactive bot<\/li>\n<\/ul>\n

                    The workflow uses one or more IP addresses as input, and for each of them:<\/p>\n

                      \n
                    • Queries an array (global variable XDR), including the network address of each room\/area of the event and purpose (Lab XYZ, Registration, Genera Wi-Fi, etc.)<\/li>\n
                    • Runs a search in Splunk on Palo Alto Networks NGFW Traffic Logs to get the Ingress Interface of the given IP<\/li>\n
                    • Run a search in Splunk on Umbrella Reporting Logs to get to the Umbrella Network Identities<\/li>\n<\/ul>\n
                      \n
                      \"Automation
                      Fig. 15<\/strong>: Note added to the incident<\/figcaption><\/figure>\n<\/div>\n
                      \n
                      \"Black
                      Fig. 16<\/strong>: Execution via Incident Playbook<\/figcaption><\/figure>\n<\/div>\n
                      \n
                      \"Black
                      Fig. 17<\/strong>: Execution via the Cisco Webex Interactive Bot<\/figcaption><\/figure>\n<\/div>\n
                      \n
                      \"Search
                      Fig. 18<\/strong>: High level overview of the workflow<\/figcaption><\/figure>\n<\/div>\n

                      Webex Notification and Interactive Bot<\/h3>\n

                      Proper communication and notification are key to ensure no incident is ignored.<\/p>\n

                      In addition to Slack, we were leveraging Cisco Webex to receive a notification when a new incident was raised in Cisco XDR and an interactive Bot to retrieve additional information and help in the first step of the investigation.<\/p>\n

                      Notification<\/strong><\/p>\n

                      On new incident an automation was triggering a workflow to grab a summary of the incident, trigger the enrichment of the location and purpose of the room (see previous workflow) and send a Notification in our collaborative room with details about the incident and a direct link to it in XDR.<\/p>\n

                      \n
                      \"Cisco
                      Fig. 19<\/strong>: Cisco Webex Notification on a new XDR Incident<\/figcaption><\/figure>\n<\/div>\n
                      \n
                      \"High-level
                      Fig. 20<\/strong>: High level view of workflow<\/figcaption><\/figure>\n<\/div>\n

                      Interactive Bot<\/strong><\/p>\n

                      An interactive Webex Bot tool was also used to help the analyst. Four commands were available to trigger a workflow in Cisco XDR via a Webhook and display the result as a message in Cisco Webex.<\/p>\n

                        \n
                      1. locate [ip]<\/em><\/strong> \u2014 Search for location and purpose for a given IP<\/li>\n
                      2. deliberate [observable]<\/em><\/strong> \u2014 Obtain verdicts for a given observable (IP, domain, hash, URL, etc.) from the various threat intelligence sources available in Cisco XDR (native and integrated module)<\/li>\n
                      3. splunk <\/strong><\/em> \u2014 Perform a Splunk search of all indexes for a given keyword and display the last two logs<\/li>\n
                      4. csplunk [custom search query]<\/em><\/strong> \u2014 Search Splunk with a custom search query<\/li>\n<\/ol>\n
                        \n
                        \"Webex
                        Fig. 21<\/strong>: Webex Bot, help options<\/figcaption><\/figure>\n<\/div>\n
                        \n
                        \"Webex
                        Fig. 22<\/strong>: Deliberate via the Webex Bot<\/figcaption><\/figure>\n<\/div>\n
                        \n
                        \"Search
                        Fig. 23<\/strong>: Search Splunk via the Webex bot<\/figcaption><\/figure>\n<\/div>\n

                        Last 6\/24 hours reports to Webex<\/strong><\/p>\n

                        Both workflows run every 6 hours and every 24 hours to generate and push to our Webex collaboration rooms a report including the Top 5 assets, domains and target IPs in the security event logs collected by Splunk from Palo Alto Networks Firewall, Corelight NDR and Cisco Umbrella (search [\u2026] | stats count by [\u2026]).<\/p>\n

                        \n
                        \"Last
                        Fig. 24<\/strong>: Last 24 Hours Report from Splunk data<\/figcaption><\/figure>\n<\/div>\n
                        \n
                        \"High
                        Fig. 25<\/strong>: High level overview of the workflow<\/figcaption><\/figure>\n<\/div>\n

                        Merge XDR Incident<\/h3>\n

                        Cisco XDR uses several advanced techniques to identify a chain of attack and correlate various related security detections together in a single incident. However, sometimes only the analyst\u2019s own investigation can reveal the link between the two. It was important for analysts to have the option, when they discover this link, of merging several incidents into one and closing the previously generated incidents.<\/p>\n

                        We\u2019ve designed this workflow with that in mind.<\/p>\n

                        During the identification phase, the analyst can run it from the \u201cmerge incident\u201d task in the Incident playbook of any of them.<\/p>\n

                        \n
                        \"Initial
                        Fig. 26<\/strong>: Initial Incident before the merge action<\/figcaption><\/figure>\n<\/div>\n
                        \n
                        \"Playbook
                        Fig. 27<\/strong>: Playbook action<\/figcaption><\/figure>\n<\/div>\n

                        At runtime, analysts will be prompted to select the observables that are part of the current incident that they wish to search for in other incidents that include them.<\/p>\n

                        \n
                        \"Select
                        Fig. 28<\/strong>: Select observables upon task execution<\/figcaption><\/figure>\n<\/div>\n

                        The workflow will then search in XDR for other incidents involving the same observables and report incidents found in the current incident notes.<\/p>\n

                        \n
                        \"Incidents
                        Fig. 29<\/strong>: Incidents found<\/figcaption><\/figure>\n<\/div>\n

                        Analysts are then invited via a prompt to decide and indicate the criteria on which they would like the merger to be based.<\/p>\n

                        \n
                        \"Prompt\"
                        Fig. 30<\/strong>: Prompt example<\/figcaption><\/figure>\n<\/div>\n

                        The prompts include:<\/p>\n

                          \n
                        • All incidents<\/strong> \u2014 Accept the list of incidents found and merge them all<\/li>\n
                        • Manual lists of incidents<\/strong> \u2014 Manually enter the identifier of the incidents you wish to merge; the list may include the identifier of an incident discovered by the workflow or another discovered by the analyst<\/li>\n
                        • Merge in a new incident<\/strong> or In the most recent one<\/strong><\/li>\n
                        • Close other incidents<\/strong> \u2014 Yes\/No<\/li>\n<\/ul>\n

                          The workflow then extracts all the information from the selected incident and creates a new one with all this information (or updates the most recent incident).<\/p>\n

                          \n
                          \"New
                          Fig. 31<\/strong>: New incident after the merge<\/figcaption><\/figure>\n<\/div>\n

                          To make our threat hunters\u2019 lives richer with more context from ours and our partners\u2019 tools, we brought in Splunk Enterprise Security Cloud at the last Black Hat Europe 2024 event to ingest detections from Cisco XDR, Secure Malware Analytics, Umbrella, ThousandEyes, Corelight OpenNDR and Palo Alto Networks Panorama and visualize them into functional dashboards for executive reporting. The Splunk Cloud instance was configured with the following integrations:<\/p>\n

                            \n
                          1. Cisco XDR and Cisco Secure Malware Analytics, using the Cisco Security Cloud app<\/li>\n
                          2. Cisco Umbrella, using the Cisco Cloud Security App for Splunk<\/li>\n
                          3. ThousandEyes, using the Splunk HTTP Event Collector (HEC)<\/li>\n
                          4. Corelight, using Splunk HTTP Event Collector (HEC)<\/li>\n
                          5. Palo Alto Networks, using the Splunk HTTP Event Collector (HEC)<\/li>\n<\/ol>\n

                            The ingested data for each integrated platform was deposited into their respective indexes. That made data searches for our threat hunters cleaner. Searching for data is where Splunk shines! And to showcase all of that, key metrics from this dataset were converted into various dashboards in Splunk Dashboard Studio. The team used the SOC dashboard from the last Black Hat Europe 2024 as the base and enhanced it. The additional work brought more insightful widgets needing the SOC dashboard broken into the following 4 areas for streamlined reporting:<\/p>\n

                            1. Incidents<\/strong><\/p>\n

                            \n
                            \"Splunk
                            Fig. 32<\/strong>: Incidents dashboard<\/figcaption><\/figure>\n<\/div>\n

                            2. DNS<\/strong><\/p>\n

                            \n
                            \"Splunk
                            Fig. 33<\/strong>: DNS dashboard<\/figcaption><\/figure>\n<\/div>\n

                            3. Network Intrusion<\/strong><\/p>\n

                            \n
                            \"Splunk
                            Fig. 34<\/strong>: Network Intrusion dashboard<\/figcaption><\/figure>\n<\/div>\n

                            4. Network Metrics<\/strong><\/p>\n

                            \n
                            \"Splunk
                            Fig. 35<\/strong>: Network Metrics dashboard<\/figcaption><\/figure>\n<\/div>\n

                            With the charter for us at Black Hat being a \u2018SOC within a NOC\u2019, the executive dashboards were reflective of bringing networking and security reporting together. This is quite powerful and will be expanded in future Black Hat events, to add more functionality and expand its usage as one of the primary consoles for our threat hunters as well as reporting dashboards on the large screens in the NOC.<\/p>\n

                            Threat Hunter\u2019s Corner<\/h2>\n

                            Authored by:<\/strong> Aditya Raghavan and Shaun Coulter<\/p>\n

                            In the Black Hat Asia 2025 NOC, Shaun staffed the morning shifts, and Aditya the afternoon shifts as usual. Unlike the earlier years, both hunters had plenty of rabbit holes to down into leading to a place of \u201cinvolved joy\u201d for both.<\/p>\n

                            Activities involving malware what would be blocked on a corporate network must be allowed, within the confines of Black Hat Code of Conduct.<\/p>\n

                            Fishing With Malware: Who Caught the Fish?<\/h3>\n

                            It all started with unusual network activity originating from a device in a lab class. Doesn\u2019t it always?<\/p>\n

                            \n
                            \n

                            \u201cLook beyond the endpoint.\u201d<\/p>\n

                            A saying that comes to life daily at Black Hat<\/cite><\/p><\/blockquote>\n<\/figure>\n

                            That said, a device was found connecting to a website flagged as suspicious by threat intelligence systems. Next, this website was being accessed via a direct IP address which is quite unusual. And to top it all off, the device exchanged credentials in clear text.<\/p>\n

                            Sounds like your typical phishing incident, and it raised our hunters\u2019 eyebrows. The initial hypothesis was that a device had been compromised in a phishing attack. Given the nature of the traffic \u2014 bi-directional communication with a known suspicious website \u2014 this seemed like a classic case of a phishing exploit. We utilized Cisco XDR to correlate these detections into an incident and visualize the connections involved.<\/p>\n

                            \n
                            \"Possible
                            Fig. 36<\/strong>: Possible successful phish screen<\/figcaption><\/figure>\n<\/div>\n

                            As is evident from the screenshot below, a detection from Corelight OpenNDR for possible phishing kicked this off. Further investigation revealed similar traffic patterns from other devices within the conference hall, this time on General Wi-Fi network as well.<\/p>\n

                            \n
                            \"Corelight
                            Fig. 37<\/strong>: Corelight OpenNDR detections<\/figcaption><\/figure>\n<\/div>\n

                            The destination for all of them, 139.59.108.141, had been marked with a suspicious disposition by alphaMountain.ai threat intelligence.<\/p>\n

                            \n
                            \"Corelight
                            Fig. 38<\/strong>: Suspicious flags<\/figcaption><\/figure>\n<\/div>\n

                            Thanks to the automation implemented to query Umbrella Identities, the device\u2019s location was quickly confirmed to be within the Advanced Malware Traffic Analysis<\/strong> class. The hunters\u2019 used this function every single time to such effect that it was decided to automate this workflow to be run and response obtained for every incident so that the hunters\u2019 have this data ready at hand as the first step while investigating the incident.<\/p>\n

                            \n
                            \"Automated
                            Fig. 39<\/strong>: Automated workflow to identify the device\u2019s location<\/figcaption><\/figure>\n<\/div>\n

                            Next step, our threat hunters as expected dived into Cisco Splunk Cloud to investigate the logs for any additional context. This investigation revealed important insights such as the traffic from the device being in clear text, allowing the payload to be extracted. This discovery was key because it revealed that this was not a typical phishing attack but part of a training exercise.<\/p>\n

                            Additionally, it was discovered several other devices from the same subnet were also communicating with the same suspicious destination. These devices exhibited nearly identical traffic patterns, further supporting the theory that this was part of a lab exercise.<\/p>\n

                            \n
                            \"Traffic
                            Fig. 40<\/strong>: Traffic patterns<\/figcaption><\/figure>\n<\/div>\n

                            The variation in the traffic volume from the different devices suggested that various students were at different stages of the lab.<\/p>\n

                            Lessons Learned: The Lost Last Part of PICERL<\/h3>\n

                            Being able to adjust what is presented to an analyst on the fly is one of the most fun parts of working events. In many organizations, \u201clessons learned\u201d from an incident or cluster of events are reviewed much later if at all, and recommendations enacted even later.<\/p>\n

                            In the Black Hat event environment, we are consistently looking for improvements and trying new things; to test the limits of the tools we have on hand.<\/p>\n

                            At Black Hat our mandate is to maintain a permissive environment, which results in a very tough job in determining actual malicious activity. Because there is so much activity, time is at a premium. Anything to reduce the noise and reduce the amount of time in triage is of benefit.<\/p>\n

                            Repeated activity was seen, such as UPNP traffic causing false positives. Fine, easy to spot but still it clogs up the work queue, as each event was at first creating a single incident.<\/p>\n

                            Noise such as this causes frustration and that in turn can cause errors of judgement in the analyst. Therefore, sharpening the analysts\u2019 tools is of premium importance.<\/p>\n

                            The entire BH team is always open to suggestions for improvement to the processes and automation routines that we run on XDR.<\/p>\n

                            One of these was to place the Corelight NDR event payload directly into the description of an event entry in XDR.<\/p>\n

                            This simple change provided the details needed directly in the XDR dashboard, without any pivot into other tools, shortening the triage process.<\/p>\n

                            \n
                            \"Corelight
                            Fig. 41<\/strong>: Corelight NDR event payload, displayed in a description of an event entry<\/figcaption><\/figure>\n<\/div>\n

                            The above example shows activity in the Business Hall from demonstrator booths. It is clear to see what appears to be repeated beaconing of a vendor device and was therefore easy and quick to close. Previously this required pivoting to the Splunk search to query for the event(s) and if the information was not apparent, then again pivot to the submitting platform. Here is the review of lesson learned, and the application of recommendations, considered my process of investigation and automated those two steps.<\/p>\n

                            Again, In the following example shows interesting traffic which looks like external scanning using ZDI tools.<\/p>\n

                            \n
                            \"Traffic
                            Fig. 42<\/strong>: Traffic scanned using ZDI tools<\/figcaption><\/figure>\n<\/div>\n

                            Through having the payload form Corelight present in the event sequence in the XDR \u201cAnalyst workbench\u201d, I was able to see: \/autodiscover\/autodiscover.json<\/strong> which is commonly used by Microsoft Exchange servers to provide autodiscovery information to clients like Outlook.<\/p>\n

                            The presence of this path suggested a probing for Exchange services.<\/p>\n

                              \n
                            • @zdi\/Powershell Query Param<\/strong> \u2014 @zdi may refer to the Zero Day Initiative, a known vulnerability research program. This could indicate a test probe from a researcher, or a scan that mimics or checks for vulnerable Exchange endpoints.<\/li>\n
                            • User-Agent: zgrab\/0.x<\/strong> \u2014 zgrab is an open-source, application-layer scanner, often used for internet-wide surveys (e.g., by researchers or threat actors).<\/li>\n<\/ul>\n

                              The tool is likely part of the ZMap ecosystem, which more than likely means that it is someone performing scanning or reconnaissance operation on the Public IP for the event, making it worthy to continue monitoring.<\/p>\n

                              The Event Name was \u201cWEB APPLICATION ATTACK\u201d not very descriptive but with our fine tuning by providing the detail directly in the incident findings, the information was quite literally at my fingertips.<\/p>\n

                              Scareware, Video Streaming and Whatnot!<\/h3>\n

                              On 2nd April, one of the devices on the network reached out to a website flagged as \u201cPhishing\u201d by Umbrella.<\/p>\n

                              \n
                              \"Umbrella-generated
                              Fig. 43<\/strong>: Umbrella-generated phishing flag<\/figcaption><\/figure>\n<\/div>\n

                              At first, it was suspected that the queries were related to a training class because of the timing of the domain activity. For example, some of the domains were registered as recently as a month ago, with Umbrella showing activity beginning only on April 1st, coinciding with the start of the conference.<\/p>\n

                              But if that were the case, we would expect to see many other attendees making the same requests from the training Wi-Fi SSID. This was not the case \u2014 in fact, across the event only a total of five IPs making these DNS queries and\/or web connections were seen, and only one of those was connected to the training SSID. One of those five devices was that of an Informa sales employee. A NOC leader contacted them, and they acknowledged accidentally clicking on a suspicious link.<\/p>\n

                              \n
                              \"DNS
                              Fig. 44<\/strong>: DNS query volume to the suspicious domain<\/figcaption><\/figure>\n<\/div>\n

                              Christian Clasen expanded the search beyond the \u201cPhishing\u201d category and found heaps of searches for domains in a short window of time for questionable categories of adware, malware and adult sites.<\/p>\n

                              \n
                              \"Domain
                              Fig. 45<\/strong>: Domain searches<\/figcaption><\/figure>\n<\/div>\n

                              On this device, this was followed by a detour to a pirated video streaming website (potentially an accidental click). This website then kicked off a chain of pops-up to various websites across the board including over 700 DNS queries to adult sites. We used Secure Malware Analytics to review the website, without getting infected ourselves.<\/p>\n

                              \n
                              \"The
                              Fig. 46<\/strong>: The suspicious site<\/figcaption><\/figure>\n<\/div>\n

                              Considering this potential chain of actions on that device, the same observable was detonated in Splunk Attack Analyzer for dynamic interaction and analysis. The report for the video streaming site shows the site reputation being questionable along with indicators for phish kits and crypto payments present.<\/p>\n

                              \n
                              \"The
                              Fig. 47<\/strong>: The attack analyzer<\/figcaption><\/figure>\n<\/div>\n
                              \n
                              \"The
                              Fig. 48<\/strong>: The attack analyzer<\/figcaption><\/figure>\n<\/div>\n

                              So, back to the question: Are these all connected? Looking at the various instances of such spurious DNS queries, Christian collated such websites queried and the IPs they were hosted at. DNS queries to:<\/p>\n

                                \n
                              • adherencemineralgravely[.]com<\/li>\n
                              • cannonkit[.]com<\/li>\n
                              • cessationhamster[.]com<\/li>\n
                              • pl24999848[.]profitablecpmrate[.]com<\/li>\n
                              • pl24999853[.]profitablecpmrate[.]com<\/li>\n
                              • playsnourishbag[.]com<\/li>\n
                              • resurrectionincomplete[.]com<\/li>\n
                              • settlementstandingdread[.]com<\/li>\n
                              • wearychallengeraise[.]com<\/li>\n
                              • alarmenvious[.]com<\/li>\n
                              • congratulationswhine[.]com<\/li>\n
                              • markshospitalitymoist[.]com<\/li>\n
                              • nannyirrationalacquainted[.]com<\/li>\n
                              • pl24999984[.]profitablecpmrate[.]com<\/li>\n
                              • pl25876700[.]effectiveratecpm[.]com<\/li>\n
                              • quickerapparently[.]com<\/li>\n
                              • suspectplainrevulsion[.]com<\/li>\n<\/ul>\n

                                Which resolved to common infrastructure IPs:<\/p>\n

                                  \n
                                • 172[.]240[.]108[.]68<\/li>\n
                                • 172[.]240[.]108[.]84<\/li>\n
                                • 172[.]240[.]127[.]234<\/li>\n
                                • 192[.]243[.]59[.]13<\/li>\n
                                • 192[.]243[.]59[.]20<\/li>\n
                                • 192[.]243[.]61[.]225<\/li>\n
                                • 192[.]243[.]61[.]227<\/li>\n
                                • 172[.]240[.]108[.]76<\/li>\n
                                • 172[.]240[.]253[.]132<\/li>\n
                                • 192[.]243[.]59[.]12<\/li>\n<\/ul>\n

                                  Which are known to be associated with the ApateWeb scareware\/adware campaign. The nameservers for these domains are:<\/p>\n

                                    \n
                                  • ns1.publicdnsservice[.]com<\/li>\n
                                  • ns2.publicdnsservice[.]com<\/li>\n
                                  • ns3.publicdnsservice[.]com<\/li>\n
                                  • ns4.publicdnsservice[.]com<\/li>\n<\/ul>\n

                                    Which are authoritative for hundreds of known malvertising domains:<\/p>\n

                                    \n
                                    \"Nameserver
                                    Fig. 49<\/strong>: Nameserver list<\/figcaption><\/figure>\n<\/div>\n

                                    Given that one affected person acknowledged that they had clicked on a suspicious link, resulting in one of the events, we believe that these are unrelated to training and in fact unrelated to each other. A Unit42 blog can be referenced for the list of IOCs related to this campaign. Unit42\u2019s post notes, \u201cThe impact of this campaign on internet users could be large, since several hundred attacker-controlled websites have remained in Tranco\u2019s top 1 million website ranking list.\u201d Well, that is a true positive in the SOC here.<\/p>\n

                                    Trufflehunter Monero Mining Attacks<\/h3>\n

                                    Authored by:<\/strong> Ryan MacLennan<\/p>\n

                                    As part of doing some additional testing and providing better efficacy for our XDR product, we deployed a proof-of-value Firepower Threat Defense (FTD) and Firepower Management Center (FMC). It was receiving the same SPAN traffic that our sensor received for XDR Analytics, but it is providing a completely different set of capabilities, those being the Intrusion Detection capabilities.<\/p>\n

                                    Below we can see multiple triggers, from a single host, on the FTD about a Trufflehunter<\/strong> Snort signature. The requests are going out to multiple external IP addresses using the same destination port.<\/p>\n

                                    \n
                                    \"Requests
                                    Fig. 50<\/strong>: Requests going to external IP addresses<\/figcaption><\/figure>\n<\/div>\n

                                    This was interesting because it looks as if this user on the network was attempting to attack these external servers. The question was, what is trufflehunter<\/strong>, are these servers malicious, is the attack on purpose, or is it legitimate traffic here at Black Hat for a training session or demo?<\/p>\n

                                    Taking one of the IP addresses in the list, I entered it into VirusTotal and it returned that it was not malicious. But it did return multiple subdomains related to that IP. Taking the top-level domain of those subdomains, we can do a further search using Umbrella.<\/p>\n

                                    \n
                                    \"Umbrella
                                    Fig. 51<\/strong>: Umbrella Investigation screen<\/figcaption><\/figure>\n<\/div>\n

                                    Umbrella Investigate says this domain is a low risk and freeware\/shareware. At this point we can say that Command and Control is not in play. So why are we seeing hits to this random IP\/domain?<\/p>\n

                                    \n
                                    \"Hits
                                    Fig. 52<\/strong>: Hits on the domain<\/figcaption><\/figure>\n<\/div>\n

                                    Taking the domain for this investigation and popping it into Splunk Attack Analyzer (SAA), we can explore the site. Basically, the owner of this domain is an avid explorer of knowledge and loves to tinker with tech, the main domain was used to host their blog. The many subdomains they had listed were for the different services they host for themselves on their site. They had an email service, Grafana<\/strong>, admin login and many other services hosted here. They even had an about section so you could get to know the owner better. For the privacy of the domain owner, I will omit their website and other information.<\/p>\n

                                    Now that we know this IP and domain are most likely not malicious, the question remained of why they were being targeted. Looking at their IP address in Shodan, it listed their IP as having port 18010<\/strong> open.<\/p>\n

                                    \n
                                    \"Shodan
                                    Fig. 53<\/strong>: Shodan IP address display<\/figcaption><\/figure>\n<\/div>\n

                                    Looking at a few other IPs that were being targeted, they all had that same port open. So, what is that port used for and what CVE is the Snort signature referencing?<\/p>\n

                                    \n
                                    \"Shodan
                                    Fig. 54<\/strong>: Shodan display of IPs being targeted<\/figcaption><\/figure>\n<\/div>\n

                                    We see below that the trufflehunter<\/strong> signature is related to CVE-2018-3972. It is a vulnerability that allows code execution if a specific version of the Epee library is used on the host. In this case, the vulnerable library is commonly used in the Monero mining application.<\/p>\n

                                    \n
                                    \"CVE
                                    Fig. 55<\/strong>: CVE display<\/figcaption><\/figure>\n<\/div>\n

                                    Doing a search on Google showed that port 18080<\/strong> is commonly used for Monero peer-to-peer connections in a mining pool. But that is based off the AI summary. Can we truly trust that?<\/p>\n

                                    Going down the results, we find the official Monero docs and they certainly do say to open port 18080<\/strong> to the world if you want to be a part of a mining pool.<\/p>\n

                                    \n
                                    \"Official
                                    Fig. 56<\/strong>: Official Monero docs<\/figcaption><\/figure>\n<\/div>\n

                                    We can see that there were attempts to get into these services, but they were not successful as there were no responses back to the attacker? How is an attacker able to find servers around the world to perform these attacks on?<\/p>\n

                                    The answer is fairly simple. In Shodan, you can search for IPs with port 18080<\/strong> open. The attacker can then curate their list and perform attacks, hoping some will hit. They probably have it automated, so there is less work for them in this process. How can we, as defenders and the everyday person, prevent ourselves from showing up on a list like this?<\/p>\n

                                    \n
                                    \"Shodan
                                    Fig. 57<\/strong>: Shodan display<\/figcaption><\/figure>\n<\/div>\n

                                    If you are hosting your own services and need to open ports to the internet, you should try to limit your exposure as much as possible.<\/p>\n

                                    To alleviate this type of fingerprinting\/scanning you should block Shodan scanners (if you can). They have a distributed system, and IPs change all the time. You can block scanning activities in general if you have a firewall, but there is no guarantee that it will prevent everything.<\/p>\n

                                    If you have an application, you developed or are hosting, there are other options like fail2ban<\/strong>, security groups in the cloud, or iptables that can be used to block these types of scans. These options can allow you to block all traffic to the service except from the IPs you want to access it.<\/p>\n

                                    Alternatives to opening the port to the Internet would be to setup up tunnels from one site to another or use a service that doesn\u2019t expose the port but allows remote access to it via a subdomain.<\/p>\n

                                    Snort ML Triggered Investigation<\/h2>\n

                                    Authored by<\/strong>: Ryan MacLennan<\/p>\n

                                    During our time at Black Hat Asia, we made sure Snort ML (machine learning) was enabled. And it was definitely worth it. We had multiple triggers of the new Snort feature where it was able to detect a potential threat in the http parameters of an HTTP request. Let us dive into this new detection and see what it found!<\/p>\n

                                    \n
                                    \"Snort
                                    Fig. 58<\/strong>: Snort events<\/figcaption><\/figure>\n<\/div>\n

                                    Looking at the events, we can see multiple different IPs from a training class and one on the General Wi-Fi network triggering these events.<\/p>\n

                                    \n
                                    \"Events
                                    Fig. 59<\/strong>: Events by priority and classification screen<\/figcaption><\/figure>\n<\/div>\n

                                    Investigating the event with the 192<\/strong> address, we can see what it alerted on specifically. Here we can see that it alerted on the \u2018HTTP URI<\/strong>\u2019 field having the parameter of \u2018?ip=%3Bifconfig<\/strong>\u2019. This looks like an attempt to run the ifconfig<\/strong> command on a remote server. This is usually done after a webshell has been uploaded to a site and it is then used to enumerate the host it is on or to do other tasks like get a reverse shell for a more interactive shell.<\/p>\n

                                    \n
                                    \"Investigation
                                    Fig. 60<\/strong>: Investigation data<\/figcaption><\/figure>\n<\/div>\n

                                    In the packet data we can see the full request that was made.<\/p>\n

                                    \n
                                    \"Packet
                                    Fig. 61<\/strong>: Packet data<\/figcaption><\/figure>\n<\/div>\n

                                    Looking at another host that was in a training we can see that the Snort ML signature fired on another command as well. This is exactly what we want to see, we know now that the signature is able to detect different http parameters and determine if they are a threat. In this example we see the attacker trying to get a file output using the command \u2018cat\u2019 and then the file path.<\/p>\n

                                    \n
                                    \"Investigation
                                    Fig. 62<\/strong>: Investigation data<\/figcaption><\/figure>\n<\/div>\n
                                    \n
                                    \"Packet
                                    Fig. 63<\/strong>: Packet data<\/figcaption><\/figure>\n<\/div>\n

                                    With this investigation, I was able to determine the general Wi-Fi user was a part of the class as they were using the same IP addresses to attack as the rest of the class. This was interesting because it was a class on pwning Kubernetes cluster applications. We were able to ignore this specific instance as it is normal in this context (we call this a \u2018Black Hat\u2019 positive event) but we never would have seen these attacks without Snort ML enabled. If I had seen this come up in my environment, I would consider it a high priority for investigation.<\/p>\n

                                    Some extras for you, we have some dashboard data for you to peruse and see the stats of the FTD. Below is the Security Cloud Control dashboard.<\/p>\n

                                    \n
                                    \"Security
                                    Fig. 64<\/strong>: Security Cloud Control dashboard<\/figcaption><\/figure>\n<\/div>\n

                                    Next, we have the FMC overview. You can see how high the SSL client application was and what our encrypted visibility engine (EVE) was able to identify.<\/p>\n

                                    \n
                                    \"FMC
                                    Fig. 65<\/strong>: FMC overview<\/figcaption><\/figure>\n<\/div>\n

                                    Lastly, we have a dashboard on the top countries by IDS events.<\/p>\n

                                    \n
                                    \"Top
                                    Fig. 66<\/strong>: Top countries by IDS events<\/figcaption><\/figure>\n<\/div>\n

                                    Identity Intelligence<\/h2>\n

                                    Authored by<\/strong>: Ryan MacLennan<\/p>\n

                                    Last year, Black Hat asked Cisco Security if we could be the Single Sign-On (SSO) provider for all the partners in the Black Hat NOC. The idea is to centralize our user base, make access to products easier, provide easier user management, and to show role-based access. We started the proof-of-value at Black Hat Asia 2024 and partially deployed at Black Hat Europe 2024. We have successfully integrated with the partners in the Black Hat NOC to enable this idea started a year ago. Below is a screenshot of all the products we have integrated with from our partners and from Cisco.<\/p>\n

                                    \n
                                    \"Products
                                    Fig. 67<\/strong>: Products integrated from partners and from Cisco<\/figcaption><\/figure>\n<\/div>\n

                                    In this screenshot above, we have the idea of the product owners having administrative access to their own products and everyone else being a viewer or analyst for that product. Allowing each partner to access each other\u2019s tools for threat hunting. Below, you can see the logins of various users to different products.<\/p>\n

                                    \n
                                    \"Logins
                                    Fig. 68<\/strong>: Logins of various users to different products<\/figcaption><\/figure>\n<\/div>\n

                                    As a part of this, we also provide Identity Intelligence, we use Identity Intelligence to determine the trust worthiness of our users and notify us when there is an issue. We do have a problem though. Most of the users are not at every Black Hat conference and the location of the conference changes each time. This affects our users\u2019 trust scores as you can see below.<\/p>\n

                                    \n
                                    \"User
                                    Fig. 69<\/strong>: User trust scores<\/figcaption><\/figure>\n<\/div>\n

                                    Looking at the screenshot below, we can see some of the reasons for the trust score differences. As the administrators of the products start to get ready for the conference, we can see the logins start to rise in February, March, and finally April. Many of the February and March logins are done from countries not in Singapore.<\/p>\n

                                    \n
                                    \"Monthly
                                    Fig. 70<\/strong>: Monthly sign-in data<\/figcaption><\/figure>\n<\/div>\n

                                    Below, we can see users with their trust level, how many checks are failing, last login, and many other details. This is a quick glance at a user\u2019s posture to see if we need to take any action. Luckily most of these are the same issue mentioned before.<\/p>\n

                                    \n
                                    \"User
                                    Fig. 71<\/strong>: User posture data<\/figcaption><\/figure>\n<\/div>\n

                                    At the end of each show and after the partners can get the data, they need from their products, we move all non admin users from an active state to a disabled group, ensuring the Black Hat standard of zero-trust.<\/p>\n

                                    Cisco Unveils New DNS Tunneling Analysis Techniques<\/h2>\n

                                    Authored by<\/strong>: Christian Clasen<\/p>\n

                                    Cisco recently announced a new AI-driven Domain Generation Algorithm (DGA) detection capability integrated into Secure Access and Umbrella. DGAs are used by malware to generate numerous domains for command and control (C2) communications, making them a critical threat vector via DNS. Traditional reputation-based systems struggle with the high volume of new domains and the evolving nature of DGAs. This new solution leverages insights from AI-driven DNS tunneling detection and the Talos threat research team to identify unique lexical characteristics of DGAs. The result is a 30% increase in real detections and a 50% improvement in accuracy, reducing both false positives and negatives. Enhanced detection is automatically enabled for Secure Access and Umbrella users with the Malware Threat category active.<\/p>\n

                                    Engineers from Cisco presented the technical details of this novel approach at the recent DNS OARC conference. The presentation discusses a method for detecting and classifying Domain Generation Algorithm (DGA) domains in real-world network traffic using Passive DNS and Deep Learning. DGAs and botnets are introduced, along with the fundamentals of Passive DNS and the tools employed. The core of the presentation highlights a monitoring panel that integrates Deep Learning models with Passive DNS data to identify and classify malicious domains within the S\u00e3o Paulo State University network traffic. The detector and classifier models, detailed in recently published scientific articles by the authors, are a key component of this system.<\/p>\n

                                    This is a key capability in environments like the Black Hat conference network where we need to be creative when interrogating network traffic. Below is an example of the detection we observed at Black Hat Asia.<\/p>\n

                                    \n
                                    \"Detections
                                    Fig. 72<\/strong>: Detection at Black Hat Asia<\/figcaption><\/figure>\n<\/div>\n

                                    Domain Name Service Statistics<\/h2>\n

                                    Authored by<\/strong>: Christian Clasen and Justin Murphy<\/p>\n

                                    We install virtual appliances as critical infrastructure of the Black Hat network, with cloud redundancy.<\/p>\n

                                    \n
                                    \"Black
                                    Fig. 73<\/strong>: Black Hat USA team<\/figcaption><\/figure>\n<\/div>\n

                                    Since 2018, we have been tracking DNS stats at the Black Hat Asia conferences. The historical DNS requests are in the chart below.<\/p>\n

                                    \n
                                    \"DNS
                                    Fig. 74<\/strong>: DNS queries volume<\/figcaption><\/figure>\n<\/div>\n
                                    \n
                                    \"DNS
                                    Fig. 75<\/strong>: DNS queries<\/figcaption><\/figure>\n<\/div>\n

                                    The Activity volume view from Umbrella gives a top-level level glance of activities by category, which we can drill into for deeper threat hunting. On trend with the previous Black Hat Asia events, the top Security categories were Malware and Newly Seen Domains.<\/p>\n

                                    In a real-world environment, of the 15M requests that Umbrella saw, over 200 of them would have been blocked by our default security policies. However, since this is a place for learning, we typically let everything fly. We did block the category of Encrypted DNS Query, as discussed in the Black Hat Europe 2024 blog.<\/p>\n

                                    We also track the Apps using DNS, using App Discovery.<\/p>\n

                                      \n
                                    • 2025: 4,625 apps<\/li>\n
                                    • 2024: 4,327 apps<\/li>\n
                                    • 2023: 1,162 apps<\/li>\n
                                    • 2022: 2,286 apps<\/li>\n<\/ul>\n
                                      \n
                                      \"DNS
                                      Fig. 76<\/strong>: DNS app discovery<\/figcaption><\/figure>\n<\/div>\n

                                      App Discovery in Umbrella gives us a quick snapshot of the cloud apps in use at the show. Not surprisingly, Generative AI (Artificial Intelligence) has continued to increase with a 100% increase year-over-year.<\/p>\n

                                      \n
                                      \"Cloud
                                      Fig. 77<\/strong>: Cloud apps used at Black Hat Asia<\/figcaption><\/figure>\n<\/div>\n

                                      Umbrella also identifies risky cloud applications. Should the need arise, we can block any application via DNS, such as Generative AI apps, Wi-Fi Analyzers, or anything else that has suspicious undertones.<\/p>\n

                                      \n
                                      \"Umbrella
                                      Fig. 78<\/strong>: Umbrella identification of risky cloud applications<\/figcaption><\/figure>\n<\/div>\n
                                      \n
                                      \"Umbrella
                                      Fig. 79<\/strong>: Umbrella identification of risky cloud applications<\/figcaption><\/figure>\n<\/div>\n

                                      Again, this is not something we would normally do on our General Wi-Fi network, but there are exceptions. For example, every so often, an attendee will learn a cool hack in one of the Black Hat courses or in the Arsenal lounge AND try to use said hack at the conference itself. That is obviously a \u2018no-no\u2019 and, in many cases, very illegal. If things go too far, we will take the appropriate action.<\/p>\n

                                      During the conference NOC Report, the NOC leaders also report of the Top Categories seen at Black Hat.<\/p>\n

                                      \n
                                      \"DNS
                                      Fig. 80<\/strong>: DNS categories chart<\/figcaption><\/figure>\n<\/div>\n

                                      Overall, we are immensely proud of the collaborative efforts made here at Black Hat Asia, by both the Cisco team and all the partners in the NOC.<\/p>\n

                                      \n
                                      \"Black
                                      Fig. 81<\/strong>: Black Hat Asia team<\/figcaption><\/figure>\n<\/div>\n

                                      We are already planning for more innovation at Black Hat USA, held in Las Vegas the first week of August 2025.<\/p>\n

                                      Acknowledgments<\/h2>\n

                                      Thank you to the Cisco NOC team:<\/p>\n

                                        \n
                                      • Cisco Security<\/strong>: Christian Clasen, Shaun Coulter, Aditya Raghavan, Justin Murphy, Ivan Berlinson and Ryan Maclennan<\/li>\n
                                      • Meraki Systems Manager<\/strong>: Paul Fidler, with Connor Loughlin supporting<\/li>\n
                                      • ThousandEyes<\/strong>: Shimei Cridlig and Patrick Yong<\/li>\n
                                      • Additional Support and Expertise<\/strong>: Tony Iacobelli and Adi Sankar<\/li>\n<\/ul>\n
                                        \n
                                        \"Black
                                        Fig. 82<\/strong>: Black Hat Asia NOC<\/figcaption><\/figure>\n<\/div>\n

                                        Also, to our NOC partners Palo Alto Networks<\/strong> (especially James Holland and Jason Reverri), Corelight<\/strong> (especially Mark Overholser and Eldon Koyle), Arista Networks<\/strong> (especially Jonathan Smith), MyRepublic<\/strong> and the entire Black Hat \/ Informa Tech staff<\/strong> (especially Grifter \u2018Neil Wyler\u2019, Bart Stump, Steve Fink, James Pope, Michael Spicer, Jess Jung and Steve Oldenbourg).<\/p>\n

                                        \n
                                        \"Black
                                        Fig. 83<\/strong>: Black Hat Asia team<\/figcaption><\/figure>\n<\/div>\n

                                        About Black Hat<\/h2>\n

                                        Black Hat is the cybersecurity industry\u2019s most established and in-depth security event series. Founded in 1997, these annual, multi-day events provide attendees with the latest in cybersecurity research, development, and trends. Driven by the needs of the community, Black Hat events showcase content directly from the community through Briefings presentations, Trainings courses, Summits, and more. As the event series where all career levels and academic disciplines convene to collaborate, network, and discuss the cybersecurity topics that matter most to them, attendees can find Black Hat events in the United States, Canada, Europe, Middle East and Africa, and Asia. For more information, please visit the Black Hat website.<\/p>\n

                                        \n

                                        We\u2019d love to hear what you think. Ask a Question, Comment Below, and Stay Connected with Cisco Security on social!<\/p>\n

                                        Cisco Security Social Channels<\/strong><\/mark><\/p>\n

                                        LinkedIn
                                        Facebook
                                        Instagram
                                        X<\/p>\n

                                        Share:<\/p>\n

                                        \n \t<\/div>\n