{"id":1543,"date":"2017-07-06T01:33:45","date_gmt":"2017-07-06T01:33:45","guid":{"rendered":"https:\/\/www.bsk-consulting.de\/?p=1543"},"modified":"2022-10-04T18:11:47","modified_gmt":"2022-10-04T16:11:47","slug":"the-best-possible-monitoring-with-sigma-rules","status":"publish","type":"post","link":"https:\/\/www.nextron-systems.com\/2017\/07\/06\/the-best-possible-monitoring-with-sigma-rules\/","title":{"rendered":"The Best Possible Monitoring with Sigma Rules"},"content":{"rendered":"<p>[et_pb_section fb_built=&#8221;1&#8243; admin_label=&#8221;section&#8221; _builder_version=&#8221;4.16&#8243; global_colors_info=&#8221;{}&#8221; da_is_popup=&#8221;off&#8221; da_exit_intent=&#8221;off&#8221; da_has_close=&#8221;on&#8221; da_alt_close=&#8221;off&#8221; da_dark_close=&#8221;off&#8221; da_not_modal=&#8221;on&#8221; da_is_singular=&#8221;off&#8221; da_with_loader=&#8221;off&#8221; da_has_shadow=&#8221;on&#8221; da_disable_devices=&#8221;off|off|off&#8221;][et_pb_row admin_label=&#8221;row&#8221; _builder_version=&#8221;4.16&#8243; background_size=&#8221;initial&#8221; background_position=&#8221;top_left&#8221; background_repeat=&#8221;repeat&#8221; global_colors_info=&#8221;{}&#8221;][et_pb_column type=&#8221;4_4&#8243; _builder_version=&#8221;4.16&#8243; custom_padding=&#8221;|||&#8221; global_colors_info=&#8221;{}&#8221; custom_padding__hover=&#8221;|||&#8221;][et_pb_text admin_label=&#8221;Text&#8221; _builder_version=&#8221;4.18.0&#8243; background_size=&#8221;initial&#8221; background_position=&#8221;top_left&#8221; background_repeat=&#8221;repeat&#8221; hover_enabled=&#8221;0&#8243; global_colors_info=&#8221;{}&#8221; sticky_enabled=&#8221;0&#8243;]Some of you may already have heard of <a href=\"https:\/\/github.com\/Neo23x0\/sigma\" target=\"_blank\" rel=\"noopener noreferrer\">Sigma<\/a>, a generic approach for signatures used in <a href=\"https:\/\/en.wikipedia.org\/wiki\/Security_information_and_event_management\">SIEM<\/a> systems. Its main purpose is to provide a structured form in which researchers or analysts can describe their once developed detection methods and make them shareable with others.<br \/>\nToday I would like to describe another use case that helps us build the best possible signatures for any application.<br \/>\nIn typical security monitoring projects, people integrate different log sources and threats\/use cases they want to monitor in these logs. The selection of the log sources is determined by importance, availability and operational requirements. The central question is:<\/p>\n<blockquote><p>&#8220;What do I want to detect?&#8221;<\/p><\/blockquote>\n<p>There are several white papers and guides for the most common log sources like the Windows Eventlog. What you have to do is to read the documents, extract the interesting detection methods and define searches, panels and dashboards in your SIEM system. One of the main purposes of Sigma is to relieve you from this time consuming process. These public descriptions of detection methods are already part of Sigma or will be integrated by one of the contributors.<br \/>\nBut today I&#8217;d like to point out a different use case that is less obvious but very useful.<\/p>\n<h1>The Best Possible Monitoring<\/h1>\n<p>Security analysts try to define useful searches and statistical analyses on the log data from all different log sources. They typically follow the public guides and create many different &#8220;failed logon&#8221; rules for all kinds of operating systems and applications.<br \/>\nBut what happens when start integrating log sources and types that are not covered by public guidelines?<br \/>\nThere are different approaches to this problem:<\/p>\n<ul>\n<li>Cover failed authentication attempts<\/li>\n<li>Monitor any failure event (with a base-lining)<\/li>\n<li>Use statistic deviations (many new events of a certain type)<\/li>\n<li>Look through the log data and select interesting messages<\/li>\n<li>Talk to the application owners \/ administrators (often rather disappointing)<\/li>\n<li>Talk with the application developers (in case of inhouse development)<\/li>\n<\/ul>\n<p>All of these methods are valid and can help you setup useful searches on the available data. However, in order to create the best possible signatures we have to consider the following:<\/p>\n<ul>\n<li>The most interesting and relevant fault conditions do not happen under normal conditions and therefore do not appear in everyday log data (the log data we have to select interesting events from)<\/li>\n<li>Developers know the rarest or most relevant error conditions and the corresponding error IDs and messages<\/li>\n<li>All possible error messages of that application appear in its source code<\/li>\n<\/ul>\n<p>Imagine that we can extract the most interesting messages that the application is able to generate and define rules for these conditions. Imagine that this process is an easy task that any developer is able to perform.<br \/>\nWell, we have at our fingertips all the tools that are needed.<\/p>\n<h1>An Example: vsftpd<\/h1>\n<p>Let&#8217;s make this approach clearer. Under optimal conditions we ask the developers to extract the most relevant or abnormal error messages that the applications produces under conditions that indicate a manipulation or attack. Alternatively, we can do it ourselves and cross-check the results with the available log data to avoid false positives.<br \/>\nI checked the source code of the FTP server &#8216;vsftpd&#8217; for error messages that indicate rare error conditions and fatal failures.<br \/>\n<img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-large wp-image-1549\" src=\"\/wp-content\/uploads\/2017\/07\/Screen-Shot-2017-07-05-at-18.00.05.png\" alt=\"\" width=\"620\" height=\"196\" srcset=\"\/wp-content\/uploads\/2017\/07\/Screen-Shot-2017-07-05-at-18.00.05.png 620w, \/wp-content\/uploads\/2017\/07\/Screen-Shot-2017-07-05-at-18.00.05-480x151.png 480w\" sizes=\"(min-width: 0px) and (max-width: 480px) 480px, (min-width: 481px) 620px, 100vw\" \/><br \/>\nThe resulting Sigma rule looks like this:<\/p>\n<pre>\ntitle: Suspicious VSFTPD error messages\ndescription: Detects suspicious VSFTPD error messages that indicate a fatal or suspicious error that could be caused by exploiting attempts\nreference: https:\/\/github.com\/dagwieers\/vsftpd\/\nauthor: Florian Roth\ndate: 2017\/07\/05\nlogsource:\n    product: linux\n    service: vsftpd\ndetection:\n    keywords:\n        - 'Connection refused: too many sessions for this address.'\n        - 'Connection refused: tcp_wrappers denial.'\n        - 'Bad HTTP verb.'\n        - 'port and pasv both active'\n        - 'pasv and port both active'\n        - 'Transfer done (but failed to open directory).'\n        - 'Could not set file modification time.'\n        - 'bug: pid active in ptrace_sandbox_free'\n        - 'PTRACE_SETOPTIONS failure'\n        - 'weird status:'\n        - \"couldn't handle sandbox event\"\n        - 'syscall * out of bounds'\n        - 'syscall not permitted:'\n        - 'syscall validate failed:'\n        - 'Input line too long.'\n        - 'poor buffer accounting in str_netfd_alloc'\n        - 'vsf_sysutil_read_loop'\n    condition: keywords\nfalsepositives:\n    - Unknown\nlevel: medium\n<\/pre>\n<p>After some testing we can now <a href=\"https:\/\/github.com\/Neo23x0\/sigma\/blob\/master\/rules\/linux\/lnx_susp_vsftp.yml\" target=\"_blank\" rel=\"noopener noreferrer\">share the rule<\/a> with the world in order to build a large signature database for the all different types of applications and services.<br \/>\nWe could also try to convince developers to provide Sigma rules with their applications to help organisations establish the best possible monitoring of their software. I was thinking about an error message extractor that would parse a software project and extract error message strings that contain certain keywords like &#8220;failure&#8221;, &#8220;fatal&#8221;, &#8220;permission denied&#8221;, &#8220;refused&#8221; and others to facilitate this process for the rule writer.<br \/>\nIf you want to support the project, create a pull request or send me your rules as <a href=\"https:\/\/gist.github.com\/\" target=\"_blank\" rel=\"noopener noreferrer\">gists<\/a> or via\u00a0<a href=\"https:\/\/pastebin.com\/\" target=\"_blank\" rel=\"noopener noreferrer\">pastebin<\/a> to <a href=\"http:\/\/www.twitter.com\/cyb3rops\" target=\"_blank\" rel=\"noopener noreferrer\">@cyb3ops<\/a>. You could also become a contributor by providing a new backend for the rule converter &#8220;<a href=\"https:\/\/github.com\/Neo23x0\/sigma\/wiki\/Converter-Tool-Sigmac\" target=\"_blank\" rel=\"noopener noreferrer\">Sigmac<\/a>&#8221; or become a member of our Slack team for threat hunters (references required).[\/et_pb_text][\/et_pb_column][\/et_pb_row][\/et_pb_section]<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Some of you may already have heard of Sigma, a generic approach for signatures used in SIEM systems. Its main purpose is to provide a structured form in which researchers or analysts can describe their once developed detection methods and make them shareable with others. Today I would like to describe another use case that helps us build the best possible signatures for any application. In typical security monitoring projects, people integrate different log sources and threats\/use cases they want to monitor in these logs. The selection of the log sources is determined by importance, availability and operational requirements. The central question is: &#8220;What do I want to detect?&#8221; There are several white papers and guides for the most common log sources like the Windows Eventlog. What you have to do is to read the documents, extract the interesting detection methods and define searches, panels and dashboards in your SIEM system. One of the main purposes of Sigma is to relieve you from this time consuming process. These public descriptions of detection methods are already part of Sigma or will be integrated by one of the contributors. But today I&#8217;d like to point out a different use case that is [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_et_pb_use_builder":"on","_et_pb_old_content":"Some of you may already have heard of <a href=\"https:\/\/github.com\/Neo23x0\/sigma\" target=\"_blank\" rel=\"noopener noreferrer\">Sigma<\/a>, a generic approach for signatures used in <a href=\"https:\/\/en.wikipedia.org\/wiki\/Security_information_and_event_management\">SIEM<\/a> systems. Its main purpose is to provide a structured form in which researchers or analysts can describe their once developed detection methods and make them shareable with others.\r\nToday I would like to describe another use case that helps us build the best possible signatures for any application.\r\nIn typical security monitoring projects, people integrate different log sources and threats\/use cases they want to monitor in these logs. The selection of the log sources is determined by importance, availability and operational requirements. The central question is:\r\n<blockquote>\"What do I want to detect?\"<\/blockquote>\r\nThere are several white papers and guides for the most common log sources like the Windows Eventlog. What you have to do is to read the documents, extract the interesting detection methods and define searches, panels and dashboards in your SIEM system. One of the main purposes of Sigma is to relieve you from this time consuming process. These public descriptions of detection methods are already part of Sigma or will be integrated by one of the contributors.\r\nBut today I'd like to point out a different use case that is less obvious but very useful.\r\n<h1>The Best Possible Monitoring<\/h1>\r\nSecurity analysts try to define useful searches and statistical analyses on the log data from all different log sources. They typically follow the public guides and create many different \"failed logon\" rules for all kinds of operating systems and applications.\r\nBut what happens when start integrating log sources and types that are not covered by public guidelines?\r\nThere are different approaches to this problem:\r\n<ul>\r\n \t<li>Cover failed authentication attempts<\/li>\r\n \t<li>Monitor any failure event (with a base-lining)<\/li>\r\n \t<li>Use statistic deviations (many new events of a certain type)<\/li>\r\n \t<li>Look through the log data and select interesting messages<\/li>\r\n \t<li>Talk to the application owners \/ administrators (often rather disappointing)<\/li>\r\n \t<li>Talk with the application developers (in case of inhouse development)<\/li>\r\n<\/ul>\r\nAll of these methods are valid and can help you setup useful searches on the available data. However, in order to create the best possible signatures we have to consider the following:\r\n<ul>\r\n \t<li>The most interesting and relevant fault conditions do not happen under normal conditions and therefore do not appear in everyday log data (the log data we have to select interesting events from)<\/li>\r\n \t<li>Developers know the rarest or most relevant error conditions and the corresponding error IDs and messages<\/li>\r\n \t<li>All possible error messages of that application appear in its source code<\/li>\r\n<\/ul>\r\nImagine that we can extract the most interesting messages that the application is able to generate and define rules for these conditions. Imagine that this process is an easy task that any developer is able to perform.\r\nWell, we have at our fingertips all the tools that are needed.\r\n<h1>An Example: vsftpd<\/h1>\r\nLet's make this approach clearer. Under optimal conditions we ask the developers to extract the most relevant or abnormal error messages that the applications produces under conditions that indicate a manipulation or attack. Alternatively, we can do it ourselves and cross-check the results with the available log data to avoid false positives.\r\nI checked the source code of the FTP server 'vsftpd' for error messages that indicate rare error conditions and fatal failures.\r\n<a href=\"https:\/\/www.nextron-systems.com\/wp-content\/uploads\/2017\/07\/Screen-Shot-2017-07-05-at-18.00.05.png\"><img class=\"alignnone size-large wp-image-1549\" src=\"https:\/\/www.nextron-systems.com\/wp-content\/uploads\/2017\/07\/Screen-Shot-2017-07-05-at-18.00.05-620x196.png\" alt=\"\" width=\"620\" height=\"196\" \/><\/a>\r\nThe resulting Sigma rule looks like this:\r\n[cc lang=\"yaml\"]\r\ntitle: Suspicious VSFTPD error messages\r\ndescription: Detects suspicious VSFTPD error messages that indicate a fatal or suspicious error that could be caused by exploiting attempts\r\nreference: https:\/\/github.com\/dagwieers\/vsftpd\/\r\nauthor: Florian Roth\r\ndate: 2017\/07\/05\r\nlogsource:\r\n    product: linux\r\n    service: vsftpd\r\ndetection:\r\n    keywords:\r\n        - 'Connection refused: too many sessions for this address.'\r\n        - 'Connection refused: tcp_wrappers denial.'\r\n        - 'Bad HTTP verb.'\r\n        - 'port and pasv both active'\r\n        - 'pasv and port both active'\r\n        - 'Transfer done (but failed to open directory).'\r\n        - 'Could not set file modification time.'\r\n        - 'bug: pid active in ptrace_sandbox_free'\r\n        - 'PTRACE_SETOPTIONS failure'\r\n        - 'weird status:'\r\n        - \"couldn't handle sandbox event\"\r\n        - 'syscall * out of bounds'\r\n        - 'syscall not permitted:'\r\n        - 'syscall validate failed:'\r\n        - 'Input line too long.'\r\n        - 'poor buffer accounting in str_netfd_alloc'\r\n        - 'vsf_sysutil_read_loop'\r\n    condition: keywords\r\nfalsepositives:\r\n    - Unknown\r\nlevel: medium\r\n[\/cc]\r\nAfter some testing we can now <a href=\"https:\/\/github.com\/Neo23x0\/sigma\/blob\/master\/rules\/linux\/lnx_susp_vsftp.yml\" target=\"_blank\" rel=\"noopener noreferrer\">share the rule<\/a> with the world in order to build a large signature database for the all different types of applications and services.\r\nWe could also try to convince developers to provide Sigma rules with their applications to help organisations establish the best possible monitoring of their software. I was thinking about an error message extractor that would parse a software project and extract error message strings that contain certain keywords like \"failure\", \"fatal\", \"permission denied\", \"refused\" and others to facilitate this process for the rule writer.\r\nIf you want to support the project, create a pull request or send me your rules as <a href=\"https:\/\/gist.github.com\/\" target=\"_blank\" rel=\"noopener noreferrer\">gists<\/a> or via\u00a0<a href=\"https:\/\/pastebin.com\/\" target=\"_blank\" rel=\"noopener noreferrer\">pastebin<\/a> to <a href=\"http:\/\/www.twitter.com\/cyb3rops\" target=\"_blank\" rel=\"noopener noreferrer\">@cyb3ops<\/a>. You could also become a contributor by providing a new backend for the rule converter \"<a href=\"https:\/\/github.com\/Neo23x0\/sigma\/wiki\/Converter-Tool-Sigmac\" target=\"_blank\" rel=\"noopener noreferrer\">Sigmac<\/a>\" or become a member of our Slack team for threat hunters (references required).","_et_gb_content_width":"","footnotes":""},"categories":[87,549],"tags":[311,278,60,59],"class_list":["post-1543","post","type-post","status-publish","format-standard","hentry","category-security-monitoring","category-sigma","tag-monitoring","tag-security","tag-siem","tag-sigma"],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v24.9 - https:\/\/yoast.com\/wordpress\/plugins\/seo\/ -->\n<title>The Best Possible Monitoring with Sigma Rules - Nextron Systems<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.nextron-systems.com\/2017\/07\/06\/the-best-possible-monitoring-with-sigma-rules\/\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\/\/www.nextron-systems.com\/2017\/07\/06\/the-best-possible-monitoring-with-sigma-rules\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/www.nextron-systems.com\/2017\/07\/06\/the-best-possible-monitoring-with-sigma-rules\/\"},\"author\":{\"name\":\"Florian Roth\",\"@id\":\"https:\/\/www.nextron-systems.com\/#\/schema\/person\/4fd503007d60aabaf1ae747502f36919\"},\"headline\":\"The Best Possible Monitoring with Sigma Rules\",\"datePublished\":\"2017-07-06T01:33:45+00:00\",\"dateModified\":\"2022-10-04T16:11:47+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/www.nextron-systems.com\/2017\/07\/06\/the-best-possible-monitoring-with-sigma-rules\/\"},\"wordCount\":829,\"publisher\":{\"@id\":\"https:\/\/www.nextron-systems.com\/#organization\"},\"keywords\":[\"monitoring\",\"security\",\"SIEM\",\"Sigma\"],\"articleSection\":[\"Security Monitoring\",\"Sigma\"],\"inLanguage\":\"en-US\"},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.nextron-systems.com\/2017\/07\/06\/the-best-possible-monitoring-with-sigma-rules\/\",\"url\":\"https:\/\/www.nextron-systems.com\/2017\/07\/06\/the-best-possible-monitoring-with-sigma-rules\/\",\"name\":\"The Best Possible Monitoring with Sigma Rules - Nextron Systems\",\"isPartOf\":{\"@id\":\"https:\/\/www.nextron-systems.com\/#website\"},\"datePublished\":\"2017-07-06T01:33:45+00:00\",\"dateModified\":\"2022-10-04T16:11:47+00:00\",\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/www.nextron-systems.com\/2017\/07\/06\/the-best-possible-monitoring-with-sigma-rules\/\"]}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/www.nextron-systems.com\/#website\",\"url\":\"https:\/\/www.nextron-systems.com\/\",\"name\":\"Nextron Systems\",\"description\":\"We Detect Hackers\",\"publisher\":{\"@id\":\"https:\/\/www.nextron-systems.com\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/www.nextron-systems.com\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Organization\",\"@id\":\"https:\/\/www.nextron-systems.com\/#organization\",\"name\":\"Nextron Systems GmbH\",\"url\":\"https:\/\/www.nextron-systems.com\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/www.nextron-systems.com\/#\/schema\/logo\/image\/\",\"url\":\"https:\/\/www.nextron-systems.com\/wp-content\/uploads\/2017\/11\/Nextron_0.2s_inv_symbol_only.png\",\"contentUrl\":\"https:\/\/www.nextron-systems.com\/wp-content\/uploads\/2017\/11\/Nextron_0.2s_inv_symbol_only.png\",\"width\":260,\"height\":260,\"caption\":\"Nextron Systems GmbH\"},\"image\":{\"@id\":\"https:\/\/www.nextron-systems.com\/#\/schema\/logo\/image\/\"}},{\"@type\":\"Person\",\"@id\":\"https:\/\/www.nextron-systems.com\/#\/schema\/person\/4fd503007d60aabaf1ae747502f36919\",\"name\":\"Florian Roth\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/www.nextron-systems.com\/#\/schema\/person\/image\/\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/0dfaa838ce5d82e2e7bfa75ed3f43ae5?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/0dfaa838ce5d82e2e7bfa75ed3f43ae5?s=96&d=mm&r=g\",\"caption\":\"Florian Roth\"},\"description\":\"Florian Roth serves as the Head of Research and Development at Nextron Systems. With a background in IT security since 2000, he has delved deep into nation-state cyber attacks since 2012. Florian has developed the THOR Scanner and actively engages with the community via his Twitter handle @cyb3rops. He has contributed to open-source projects, including 'Sigma', a generic SIEM rule format, and 'LOKI', an open-source scanner. Additionally, he has shared valuable resources like a mapping of APT groups and operations and an Antivirus Event Analysis Cheat Sheet.\",\"url\":\"https:\/\/www.nextron-systems.com\/author\/florian\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"The Best Possible Monitoring with Sigma Rules - Nextron Systems","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.nextron-systems.com\/2017\/07\/06\/the-best-possible-monitoring-with-sigma-rules\/","schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.nextron-systems.com\/2017\/07\/06\/the-best-possible-monitoring-with-sigma-rules\/#article","isPartOf":{"@id":"https:\/\/www.nextron-systems.com\/2017\/07\/06\/the-best-possible-monitoring-with-sigma-rules\/"},"author":{"name":"Florian Roth","@id":"https:\/\/www.nextron-systems.com\/#\/schema\/person\/4fd503007d60aabaf1ae747502f36919"},"headline":"The Best Possible Monitoring with Sigma Rules","datePublished":"2017-07-06T01:33:45+00:00","dateModified":"2022-10-04T16:11:47+00:00","mainEntityOfPage":{"@id":"https:\/\/www.nextron-systems.com\/2017\/07\/06\/the-best-possible-monitoring-with-sigma-rules\/"},"wordCount":829,"publisher":{"@id":"https:\/\/www.nextron-systems.com\/#organization"},"keywords":["monitoring","security","SIEM","Sigma"],"articleSection":["Security Monitoring","Sigma"],"inLanguage":"en-US"},{"@type":"WebPage","@id":"https:\/\/www.nextron-systems.com\/2017\/07\/06\/the-best-possible-monitoring-with-sigma-rules\/","url":"https:\/\/www.nextron-systems.com\/2017\/07\/06\/the-best-possible-monitoring-with-sigma-rules\/","name":"The Best Possible Monitoring with Sigma Rules - Nextron Systems","isPartOf":{"@id":"https:\/\/www.nextron-systems.com\/#website"},"datePublished":"2017-07-06T01:33:45+00:00","dateModified":"2022-10-04T16:11:47+00:00","inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.nextron-systems.com\/2017\/07\/06\/the-best-possible-monitoring-with-sigma-rules\/"]}]},{"@type":"WebSite","@id":"https:\/\/www.nextron-systems.com\/#website","url":"https:\/\/www.nextron-systems.com\/","name":"Nextron Systems","description":"We Detect Hackers","publisher":{"@id":"https:\/\/www.nextron-systems.com\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.nextron-systems.com\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Organization","@id":"https:\/\/www.nextron-systems.com\/#organization","name":"Nextron Systems GmbH","url":"https:\/\/www.nextron-systems.com\/","logo":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.nextron-systems.com\/#\/schema\/logo\/image\/","url":"https:\/\/www.nextron-systems.com\/wp-content\/uploads\/2017\/11\/Nextron_0.2s_inv_symbol_only.png","contentUrl":"https:\/\/www.nextron-systems.com\/wp-content\/uploads\/2017\/11\/Nextron_0.2s_inv_symbol_only.png","width":260,"height":260,"caption":"Nextron Systems GmbH"},"image":{"@id":"https:\/\/www.nextron-systems.com\/#\/schema\/logo\/image\/"}},{"@type":"Person","@id":"https:\/\/www.nextron-systems.com\/#\/schema\/person\/4fd503007d60aabaf1ae747502f36919","name":"Florian Roth","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.nextron-systems.com\/#\/schema\/person\/image\/","url":"https:\/\/secure.gravatar.com\/avatar\/0dfaa838ce5d82e2e7bfa75ed3f43ae5?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/0dfaa838ce5d82e2e7bfa75ed3f43ae5?s=96&d=mm&r=g","caption":"Florian Roth"},"description":"Florian Roth serves as the Head of Research and Development at Nextron Systems. With a background in IT security since 2000, he has delved deep into nation-state cyber attacks since 2012. Florian has developed the THOR Scanner and actively engages with the community via his Twitter handle @cyb3rops. He has contributed to open-source projects, including 'Sigma', a generic SIEM rule format, and 'LOKI', an open-source scanner. Additionally, he has shared valuable resources like a mapping of APT groups and operations and an Antivirus Event Analysis Cheat Sheet.","url":"https:\/\/www.nextron-systems.com\/author\/florian\/"}]}},"_links":{"self":[{"href":"https:\/\/www.nextron-systems.com\/wp-json\/wp\/v2\/posts\/1543","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.nextron-systems.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.nextron-systems.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.nextron-systems.com\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.nextron-systems.com\/wp-json\/wp\/v2\/comments?post=1543"}],"version-history":[{"count":6,"href":"https:\/\/www.nextron-systems.com\/wp-json\/wp\/v2\/posts\/1543\/revisions"}],"predecessor-version":[{"id":14691,"href":"https:\/\/www.nextron-systems.com\/wp-json\/wp\/v2\/posts\/1543\/revisions\/14691"}],"wp:attachment":[{"href":"https:\/\/www.nextron-systems.com\/wp-json\/wp\/v2\/media?parent=1543"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.nextron-systems.com\/wp-json\/wp\/v2\/categories?post=1543"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.nextron-systems.com\/wp-json\/wp\/v2\/tags?post=1543"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}