From g.pippi at certego.net Thu Sep 19 09:10:11 2019 From: g.pippi at certego.net (Gabriele Pippi) Date: Thu, 19 Sep 2019 18:10:11 +0200 Subject: [Zeek-Dev] Zeek DCE-RPC Analyzer Update Message-ID: Zeek-Dev Group, hi i'm Gabriele from purple team of Certego. We are trying to rely on zeek to increase the detection of our platform in the *moving** through the internal network sc*enario ( *credential access*, *discovery* and specially *lateral movement* ATT&CK Matrix phases). In the case of dcerpc for the moment we are correlating the information generated by *bro_dce_rpc *parser with data coming from endpoint agents. In order to reduce the number of false positives and to gather more detailed information for a possible analysis, we thought it would be really interesting "to get extensive parsing in place for DCE-RPC messages by parsing the IDL files [...]" or to implement a "byte string containing the stub data itself" in case it is not encrypted. In our case we would like to give priority to all those operations that allow to directly carry out an entire attack or a code execution, restricting the scope to those with stub data in cleartext (for example in the case of dcerpc over smb named_pipe or in the case of dcom, at least for the operations observed until now ). I found the following BINPAC *zeek/src/analyzer/protocol/dce-rpc/endpoint-atsvc.pac*, and I ended up to this discussion https://bro-dev.bro-ids.narkive.com/jq0Ofe6L/bro-dce-rpc-analyzer-questions . *Have there been any updates regarding this topic? Do you have any advice on how to proceed?* Once we have assessed the feasibility, we could be willing to contribute to achieve this goal. In this work we would also like to insert a series of endpoints and operations that currently are not mapped by zeek, among those observed for example there are several in DCOM. Once the tests are completed, if you are interested, we could also provide you with an exhaustive list or integrate it directly with a possible merge. At the moment we do not know of the existence of technologies that allow to do alerting on some types of *Windows APIs*, we therefore believe that being able to do it at the network level through DCERPC is an important added value to zeek. Thanks, Gabriele. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/zeek-dev/attachments/20190919/1e522e04/attachment.html From mfernandez at mitre.org Fri Sep 20 04:19:04 2019 From: mfernandez at mitre.org (Fernandez, Mark I) Date: Fri, 20 Sep 2019 11:19:04 +0000 Subject: [Zeek-Dev] [EXT] Zeek DCE-RPC Analyzer Update In-Reply-To: <7076_1568909469_5D83A89C_7076_194_6_CADNS-sOP=MQRZ6RDy0TvvjUFN57wDebuyQ=x9JLDUoJwBpG92A@mail.gmail.com> References: <7076_1568909469_5D83A89C_7076_194_6_CADNS-sOP=MQRZ6RDy0TvvjUFN57wDebuyQ=x9JLDUoJwBpG92A@mail.gmail.com> Message-ID: Hi Gabriele, Last year I did a deep-dive into the Zeek DCE-RPC protocol analyzer. I found the same un-used binpac file endpoint-atsvc.pac, and I had similar thoughts about developing analyzers for specific RPC data stubs. Unfortunately, so many RPC data stubs are encrypted by default now. Also, I realized I was able to make useful decisions from just knowing the RPC interface and method and then mapping that function to a threat model. Please see the github repository at the URL below. Also, I am giving a talk on it at ZeekWeek next month. https://github.com/mitre-attack/bzar Thanks, Mark From: zeek-dev-bounces at zeek.org On Behalf Of Gabriele Pippi Sent: Thursday, September 19, 2019 12:10 PM To: zeek-dev at zeek.org Subject: [EXT] [Zeek-Dev] Zeek DCE-RPC Analyzer Update Zeek-Dev Group, hi i'm Gabriele from purple team of Certego. We are trying to rely on zeek to increase the detection of our platform in the moving through the internal network scenario ( credential access, discovery and specially lateral movement ATT&CK Matrix phases). In the case of dcerpc for the moment we are correlating the information generated by bro_dce_rpc parser with data coming from endpoint agents. In order to reduce the number of false positives and to gather more detailed information for a possible analysis, we thought it would be really interesting "to get extensive parsing in place for DCE-RPC messages by parsing the IDL files [...]" or to implement a "byte string containing the stub data itself" in case it is not encrypted. In our case we would like to give priority to all those operations that allow to directly carry out an entire attack or a code execution, restricting the scope to those with stub data in cleartext (for example in the case of dcerpc over smb named_pipe or in the case of dcom, at least for the operations observed until now ). I found the following BINPAC zeek/src/analyzer/protocol/dce-rpc/endpoint-atsvc.pac, and I ended up to this discussion https://bro-dev.bro-ids.narkive.com/jq0Ofe6L/bro-dce-rpc-analyzer-questions . Have there been any updates regarding this topic? Do you have any advice on how to proceed? Once we have assessed the feasibility, we could be willing to contribute to achieve this goal. In this work we would also like to insert a series of endpoints and operations that currently are not mapped by zeek, among those observed for example there are several in DCOM. Once the tests are completed, if you are interested, we could also provide you with an exhaustive list or integrate it directly with a possible merge. At the moment we do not know of the existence of technologies that allow to do alerting on some types of Windows APIs, we therefore believe that being able to do it at the network level through DCERPC is an important added value to zeek. Thanks, Gabriele. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/zeek-dev/attachments/20190920/0872d111/attachment.html From g.pippi at certego.net Mon Sep 23 03:19:13 2019 From: g.pippi at certego.net (Gabriele Pippi) Date: Mon, 23 Sep 2019 12:19:13 +0200 Subject: [Zeek-Dev] [EXT] Zeek DCE-RPC Analyzer Update In-Reply-To: References: <7076_1568909469_5D83A89C_7076_194_6_CADNS-sOP=MQRZ6RDy0TvvjUFN57wDebuyQ=x9JLDUoJwBpG92A@mail.gmail.com> Message-ID: Hi Mark, I have already analyzed your project and I thank you for the excellent work. The reasons why we are looking for something more are these: 1. Currently analyzing the new techniques with DCOM we have noticed that neither the endpoints nor the operations have been included in the project. 2. We have also noticed in the observed cases that the data stub is encrypted using ntlmssp authlevel packet privacy, this happened in the cases where dcerpc passed over pure through a specific rule on the local windows firewall. However this does not happen neither for the observed cases of DCOM (*authlevel packet integrity*), nor for the classic code execution dcerpc traffic passed through named pipes (atsvc, svcctl, winreg , [...]) (*authlevel connect*), which are the easiest techniques to exploit with basic AD configuration. This type of traffic is legitimate and widely used in our networks, the content of the stub data in cleartext would help us both to filter the normal uses from the malicious ones and to greatly increase the quality of our analyzes. Thanks, Gabriele. Il giorno ven 20 set 2019 alle ore 13:19 Fernandez, Mark I < mfernandez at mitre.org> ha scritto: > Hi Gabriele, > > > > Last year I did a deep-dive into the Zeek DCE-RPC protocol analyzer. I > found the same un-used binpac file *endpoint-atsvc.pac,* and I had > similar thoughts about developing analyzers for specific RPC data stubs. > Unfortunately, so many RPC data stubs are encrypted by default now. Also, > I realized I was able to make useful decisions from just knowing the RPC > interface and method and then mapping that function to a threat model. > Please see the github repository at the URL below. Also, I am giving a > talk on it at ZeekWeek next month. > > > > https://github.com/mitre-attack/bzar > > > > Thanks, > > Mark > > > > *From:* zeek-dev-bounces at zeek.org *On Behalf > Of *Gabriele Pippi > *Sent:* Thursday, September 19, 2019 12:10 PM > *To:* zeek-dev at zeek.org > *Subject:* [EXT] [Zeek-Dev] Zeek DCE-RPC Analyzer Update > > > > Zeek-Dev Group, > > > > hi i'm Gabriele from purple team of Certego. We are trying to rely on zeek > to increase the detection of our platform in the *moving through the > internal network sc*enario ( *credential access*, * discovery* and > specially *lateral movement* ATT&CK Matrix phases). > > In the case of dcerpc for the moment we are correlating the information > generated by *bro_dce_rpc *parser with data coming from endpoint agents. > > In order to reduce the number of false positives and to gather more > detailed information for a possible analysis, we thought it would be really > interesting "to get extensive parsing in place for DCE-RPC messages by > parsing the IDL files [...]" or to implement a "byte string containing the > stub data itself" in case it is not encrypted. In our case we would like to > give priority to all those operations that allow to directly carry out an > entire attack or a code execution, restricting the scope to those with stub > data in cleartext (for example in the case of dcerpc over smb named_pipe or > in the case of dcom, at least for the operations observed until now ). I > found the following BINPAC > *zeek/src/analyzer/protocol/dce-rpc/endpoint-atsvc.pac*, and I ended up > to this discussion > https://bro-dev.bro-ids.narkive.com/jq0Ofe6L/bro-dce-rpc-analyzer-questions > . > > *Have there been any updates regarding this topic? Do you have any advice > on how to proceed?* > > Once we have assessed the feasibility, we could be willing to contribute > to achieve this goal. In this work we would also like to insert a series of > endpoints and operations that currently are not mapped by zeek, among those > observed for example there are several in DCOM. Once the tests are > completed, if you are interested, we could also provide you with an > exhaustive list or integrate it directly with a possible merge. > > At the moment we do not know of the existence of technologies that allow > to do alerting on some types of *Windows APIs*, we therefore believe that > being able to do it at the network level through DCERPC is an important > added value to zeek. > > Thanks, > > > > Gabriele. > -- Gabriele Pippi Incident Response Team, Certego <+39-059-7353333> +39 0543 1908084 <+39-059-7353333> | +39-3386735301 <+39-3333333333> Use of the information within this document constitutes acceptance for use in an "as is" condition. There are no warranties with regard to this information; Certego has verified the data as thoroughly as possible. Any use of this information lies within the user's responsibility. In no event shall Certego be liable for any consequences or damages, including direct, indirect, incidental, consequential, loss of business profits or special damages, arising out of or in connection with the use or spread of this information. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/zeek-dev/attachments/20190923/f71dd3db/attachment.html From mfernandez at mitre.org Mon Sep 23 06:35:37 2019 From: mfernandez at mitre.org (Fernandez, Mark I) Date: Mon, 23 Sep 2019 13:35:37 +0000 Subject: [Zeek-Dev] [EXT] Zeek DCE-RPC Analyzer Update In-Reply-To: References: <7076_1568909469_5D83A89C_7076_194_6_CADNS-sOP=MQRZ6RDy0TvvjUFN57wDebuyQ=x9JLDUoJwBpG92A@mail.gmail.com> Message-ID: Hi Gabriele, Thank you for the compliment on BZAR. I think it would be great if you were to create a parser for those data stubs. That would add a lot of value. >> ...nor for the classic code execution dcerpc traffic passed through >> named pipes (atsvc, svcctl, winreg , [...]) (authlevel connect), which >> are the easiest techniques to exploit with basic AD configuration. I am surprised those RPC interfaces are not encrypted. For example, the current MSDN documentation states the RPC authentication should be Level 6 (authlevel packet privacy) for atsvc, svcctl, and winreg, which would mean the data stubs would be encrypted. I didn?t investigate further to verify if that is true or not, or to find cases when it is not encrypted. Thanks, Mark From: Gabriele Pippi Sent: Monday, September 23, 2019 6:19 AM To: Fernandez, Mark I Cc: zeek-dev at zeek.org Subject: Re: [EXT] [Zeek-Dev] Zeek DCE-RPC Analyzer Update Hi Mark, I have already analyzed your project and I thank you for the excellent work. The reasons why we are looking for something more are these: 1. Currently analyzing the new techniques with DCOM we have noticed that neither the endpoints nor the operations have been included in the project. 2. We have also noticed in the observed cases that the data stub is encrypted using ntlmssp authlevel packet privacy, this happened in the cases where dcerpc passed over pure through a specific rule on the local windows firewall. However this does not happen neither for the observed cases of DCOM (authlevel packet integrity), nor for the classic code execution dcerpc traffic passed through named pipes (atsvc, svcctl, winreg , [...]) (authlevel connect), which are the easiest techniques to exploit with basic AD configuration. This type of traffic is legitimate and widely used in our networks, the content of the stub data in cleartext would help us both to filter the normal uses from the malicious ones and to greatly increase the quality of our analyzes. Thanks, Gabriele. Il giorno ven 20 set 2019 alle ore 13:19 Fernandez, Mark I > ha scritto: Hi Gabriele, Last year I did a deep-dive into the Zeek DCE-RPC protocol analyzer. I found the same un-used binpac file endpoint-atsvc.pac, and I had similar thoughts about developing analyzers for specific RPC data stubs. Unfortunately, so many RPC data stubs are encrypted by default now. Also, I realized I was able to make useful decisions from just knowing the RPC interface and method and then mapping that function to a threat model. Please see the github repository at the URL below. Also, I am giving a talk on it at ZeekWeek next month. https://github.com/mitre-attack/bzar Thanks, Mark From: zeek-dev-bounces at zeek.org > On Behalf Of Gabriele Pippi Sent: Thursday, September 19, 2019 12:10 PM To: zeek-dev at zeek.org Subject: [EXT] [Zeek-Dev] Zeek DCE-RPC Analyzer Update Zeek-Dev Group, hi i'm Gabriele from purple team of Certego. We are trying to rely on zeek to increase the detection of our platform in the moving through the internal network scenario ( credential access, discovery and specially lateral movement ATT&CK Matrix phases). In the case of dcerpc for the moment we are correlating the information generated by bro_dce_rpc parser with data coming from endpoint agents. In order to reduce the number of false positives and to gather more detailed information for a possible analysis, we thought it would be really interesting "to get extensive parsing in place for DCE-RPC messages by parsing the IDL files [...]" or to implement a "byte string containing the stub data itself" in case it is not encrypted. In our case we would like to give priority to all those operations that allow to directly carry out an entire attack or a code execution, restricting the scope to those with stub data in cleartext (for example in the case of dcerpc over smb named_pipe or in the case of dcom, at least for the operations observed until now ). I found the following BINPAC zeek/src/analyzer/protocol/dce-rpc/endpoint-atsvc.pac, and I ended up to this discussion https://bro-dev.bro-ids.narkive.com/jq0Ofe6L/bro-dce-rpc-analyzer-questions . Have there been any updates regarding this topic? Do you have any advice on how to proceed? Once we have assessed the feasibility, we could be willing to contribute to achieve this goal. In this work we would also like to insert a series of endpoints and operations that currently are not mapped by zeek, among those observed for example there are several in DCOM. Once the tests are completed, if you are interested, we could also provide you with an exhaustive list or integrate it directly with a possible merge. At the moment we do not know of the existence of technologies that allow to do alerting on some types of Windows APIs, we therefore believe that being able to do it at the network level through DCERPC is an important added value to zeek. Thanks, Gabriele. -- Gabriele Pippi Incident Response Team, Certego +39 0543 1908084 | +39-3386735301 Use of the information within this document constitutes acceptance for use in an "as is" condition. There are no warranties with regard to this information; Certego has verified the data as thoroughly as possible. Any use of this information lies within the user's responsibility. In no event shall Certego be liable for any consequences or damages, including direct, indirect, incidental, consequential, loss of business profits or special damages, arising out of or in connection with the use or spread of this information. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/zeek-dev/attachments/20190923/975f0e6c/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 823 bytes Desc: not available Url : http://mailman.icsi.berkeley.edu/pipermail/zeek-dev/attachments/20190923/975f0e6c/attachment-0002.jpe -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 338 bytes Desc: not available Url : http://mailman.icsi.berkeley.edu/pipermail/zeek-dev/attachments/20190923/975f0e6c/attachment-0003.jpe -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5063 bytes Desc: not available Url : http://mailman.icsi.berkeley.edu/pipermail/zeek-dev/attachments/20190923/975f0e6c/attachment-0001.bin From joblake at amazon.com Mon Sep 30 13:49:46 2019 From: joblake at amazon.com (Johnson, Blake) Date: Mon, 30 Sep 2019 20:49:46 +0000 Subject: [Zeek-Dev] Additional Industrial Control Systems Protocols Message-ID: Hi Team - As part of our work on the Customer Fulfillment Technology Security team at Amazon.com we've developed a set of protocol parsers for industrial control systems devices that we use in our production Zeek deployment. At this stage we're approved to release several of them as open source and would like to understand both if the Zeek team would be interested in taking these as contributions to upstream and, if you are, how best to coordinate the process of merging the contributions in. The five plugins we're approved to share now are: * BACnet * Ethernet/IP & Common Industrial Protocol (one plugin) * Profinet * S7comm * MS-TDS Tabular Data Stream Protocol (not strictly ICS but used by some SCADA historians) If the team is interested in this upstream we can submit as pull requests on GitHub, for example as one pull request per plugin, or via another workflow. If they're not a fit for upstream we can pursue an independent release. I'm really excited to make this available to the community either way! The two main authors, my colleague Tri and myself, will be at ZeekWeek here in Seattle next month to discuss these and a few others we have coming down the pipe. Let us know what works, Blake Johnson Security Engineer Control Systems Security Amazon.com From akgraner at corelight.com Mon Sep 30 17:45:30 2019 From: akgraner at corelight.com (Amber Graner) Date: Mon, 30 Sep 2019 19:45:30 -0500 Subject: [Zeek-Dev] Additional Industrial Control Systems Protocols In-Reply-To: References: Message-ID: Hi Blake, Thank you so much for reaching out to the list. YES, please open these through our package manager. We would be delighted, but more importantly, the community of Zeek users will be. Thank you and your team for extending the capabilities of Zeek. I'll be reaching out off-list to set up some time to meet with you and your colleagues at ZeekWeek. Please let me know if you have any questions. ~Amber On Mon, Sep 30, 2019 at 3:50 PM Johnson, Blake wrote: > Hi Team - > > As part of our work on the Customer Fulfillment Technology Security team > at Amazon.com we've developed a set of protocol parsers for industrial > control systems devices that we use in our production Zeek deployment. At > this stage we're approved to release several of them as open source and > would like to understand both if the Zeek team would be interested in > taking these as contributions to upstream and, if you are, how best to > coordinate the process of merging the contributions in. The five plugins > we're approved to share now are: > > * BACnet > * Ethernet/IP & Common Industrial Protocol (one plugin) > * Profinet > * S7comm > * MS-TDS Tabular Data Stream Protocol (not strictly ICS but used by some > SCADA historians) > > If the team is interested in this upstream we can submit as pull requests > on GitHub, for example as one pull request per plugin, or via another > workflow. If they're not a fit for upstream we can pursue an independent > release. I'm really excited to make this available to the community either > way! The two main authors, my colleague Tri and myself, will be at > ZeekWeek here in Seattle next month to discuss these and a few others we > have coming down the pipe. > > Let us know what works, > > Blake Johnson > Security Engineer > Control Systems Security > Amazon.com > > _______________________________________________ > zeek-dev mailing list > zeek-dev at zeek.org > http://mailman.icsi.berkeley.edu/mailman/listinfo/zeek-dev > -- *Amber Graner* Director of Community Corelight, Inc 828.582.9469 * Ask me about how you can participate in the Zeek (formerly Bro) community. * Remember - ZEEK AND YOU SHALL FIND!! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/zeek-dev/attachments/20190930/1fd101f4/attachment.html