来源：https://www.cnblogs.com/maybe2030/p/4781555.html#_label6
TCP/IP(transmission control protocol/internet protocol)协议是Internet最基本的协议、Internet国际互联网络的基础，由网络层的IP协议和传输层的TCP协议组成。通俗而言：TCP负责发现传输的问题，一有问题就发出信号，要求重新传输，直到所有数据安全正确地传输到目的地。而IP是给因特网的每一台联网设备规定一个地址。
TCP是面向连接的通信协议，通过三次握手建立连接，通讯完成时要拆除连接，由于TCP是面向连接的所以只能用于端到端的通讯。TCP提供的是一种可靠的数据流服务，采用“带重传的肯定确认”技术来实现传输的可靠性。TCP还采用一种称为“滑动窗口”的方式进行流量控制，所谓窗口实际表示接收能力，用以限制发送方的发送速度。
TCP协议的三次握手和四次挥手：
注：seq:"sequance"序列号；ack:"acknowledge"确认号；SYN:"synchronize"请求同步标志；；ACK:"acknowledge"确认标志"；FIN："Finally"结束标志。
TCP连接建立过程：首先Client端发送连接请求报文，Server段接受连接后回复ACK报文，并为这次连接分配资源。Client端接收到ACK报文后也向Server段发生ACK报文，并分配资源，这样TCP连接就建立了。
TCP连接断开过程：假设Client端发起中断连接请求，也就是发送FIN报文。Server端接到FIN报文后，意思是说"我Client端没有数据要发给你了"，但是如果你还有数据没有发送完成，则不必急着关闭Socket，可以继续发送数据。所以你先发送ACK，"告诉Client端，你的请求我收到了，但是我还没准备好，请继续你等我的消息"。这个时候Client端就进入FIN_WAIT状态，继续等待Server端的FIN报文。当Server端确定数据已发送完成，则向Client端发送FIN报文，"告诉Client端，好了，我这边数据发完了，准备好关闭连接了"。Client端收到FIN报文后，"就知道可以关闭连接了，但是他还是不相信网络，怕Server端不知道要关闭，所以发送ACK后进入TIME_WAIT状态，如果Server端没有收到ACK则可以重传。“，Server端收到ACK后，"就知道可以断开连接了"。Client端等待了2MSL后依然没有收到回复，则证明Server端已正常关闭，那好，我Client端也可以关闭连接了。Ok，TCP连接就这样关闭了！
作者：sunset journey
链接：https://juejin.cn/post/6844903796707950600
来源：稀土掘金
分析包
| no | Time | Source | Destination | protocal | Length | info |
|---|---|---|---|---|---|---|
| 3 | 0.000278 | 192.168.137.28 | 192.168.1.102 | TCP | 58 | 49155 → 5000 [SYN] Seq=0 Win=8196 Len=0 MSS=1460 |
| 4 | 0.000408 | 192.168.1.102 | 192.168.137.28 | TCP | 58 | 5000 → 49155 [SYN, ACK] Seq=0 Ack=1 Win=64240 Len=0 MSS=1460 |
| 5 | 0.000794 | 192.168.137.28 | 192.168.1.102 | TCP | 54 | 49155 → 5000 [ACK] Seq=1 Ack=1 Win=8196 Len=0 |
客户端请求服务端连接的包 3号包
SYN Flag,由客户端到服务端。Seq = 0(其实Seq应该是一个随机数。毕竟随机保密好一点。这里为0是巧合) MSS = Maximum Segment Size，最大分段长度。TCP建立连接时每一个报文段所能承载的最大数据长度。
服务器收到请求后发送给客户端的包 4号包
SYN Flag，ACK Flag，服务器端到客户端。Seq=0。这里看到AcK为1。其实是应答3号包的Seq。若是3号包Seq = n；那么4号包
if len==0
AcK = n+1；
else
Ack = n+len;
这4号包既是应答3号包又是请求连接包。所以也会有MSS信号。
客户端回应服务端 4号包 的 5号包
AcK = 1 客户端发送给服务端的包 AcK = 1。是因为4号包的Seq = 0。
若是4号包Seq = n；那么5号包
if len==0
AcK = n+1；
else
Ack = n+len;
可以看到5号包只有一个ACK Flag。没有SYN Flag。也就是说这里是一个应答包。不是请求连接包。
pcap/cap 文件格式 - 知乎 (zhihu.com)
https://zhuanlan.zhihu.com/p/394946101
Pcap Header
文件头，每一个 pcap 文件只有一个文件头，共占 24 字节，包含 7 个字段。
- Magic（4B）：标记文件开始，并用来识别文件和字节顺序。值可以是 0xa1b2c3d4 或者 0x4dc3b2a1，如果是 0xa1b2c3d4 表示是大端模式，按照原来的顺序一个字节一个字节的读，如果是 0x4dc3b2a1 表示小端模式，下面的字节要交换顺序。现在电脑大部分是小端模式
- 大端模式：即是内存的低地址空间存储数据的高位，高地址空间存储数据的低位；内存由低到高访问时，首先碰到的是数据的高位，类似于嫁给你数据当作字符串。而小端模式刚好相反；
- 0x12345678，在大端模式中，高位为 0x12，在小端模式中，高位为 0x78；注意均为 1 个字节
- Major（2B）：当前文件的主要版本，一般为 0x0200
- Minor（2B）： 当前文件的次要版本号，一般为 0x0400
- ThisZone（4B）： 当地的标准事件，如果用的是 GMT 则全零，一般全零
- SigFigs（4B）： 时间戳的精度，一般为全零
- SnapLen（4B）： 最大的存储长度，设置所抓获的数据包的最大长度，如果所有数据包都要抓获，将值设置为 65535
- LinkType（4B）： 链路类型。解析数据包首先要判断它的 LinkType，所以这个值很重要。一般的值为1，即以太网常用的 LinkType（链路类型）
Modbus总结
来源：Modbus总结 - iluzhiyong - 博客园 (cnblogs.com)
1.概念
①Coil和Register
Modbus中定义的两种数据类型。Coil是位（bit）变量；Register是整型（Word，即16-bit）变量。
②Slave和Master与Server和Client
同一种设备在不同领域的不同叫法。
Slave： 工业自动化用语；响应请求；
Master：工业自动化用语；发送请求；
Server：IT用语；响应请求；
Client：IT用语；发送请求；
在Modbus中，Slave和Server意思相同，Master和Client意思相同。
2.Modbus数据模型
Modbus中，数据可以分为两大类，分别为Coil和Register，每一种数据，根据读写方式的不同，又可细分为两种（只读，读写）。
Modbus四种数据类型：
Discretes Input 位变量 只读
Coils 位变量 读写
Input Registers 16-bit整型 只读
Holding Registers 16-bit整型 读写
通常，在Slave端中，定义四张表来实现四种数据。
3.Modbus地址范围对应表
设备地址 Modbus地址 描述 功能 R/W
1~10000 address-1 Coils（Output） 0 R/W
10001~20000 address-10001 Discrete Inputs 01 R
30001~40000 address-30001 Input Registers 04 R
40001~50000 address-40001 Holding Registers 03 R/W
4.Modbus变量地址
映射地址 Function Code 地址类型 R/W 描述
0xxxx 01,05,15 Coil R/W -
1xxxx 02 离散输入 R -
2xxxx 03,04,06,16 浮点寄存器 R/W 两个连续16-bit寄存器表示一个浮点数（IEEE754）
3xxxx 04 输入寄存器 R 每个寄存器表示一个16-bit无符号整数（0~65535）
4xxxx 03,06,16 保持寄存器 R/W -
5xxxx 03,04,06,16 ASCII字符 R/W 每个寄存器表示两个ASCII字符
来源：MODBUS协议中的功能代码都有哪些？都有什么作用。_百度知道 (baidu.com)
MODBUS协议中的功能代码都有哪些？都有什么作用。
01 READ COIL STATUS 读线圈寄存器
02 READ INPUT STATUS 读状态寄存器
03 READ HOLDING REGISTER 读保持寄存器
04 READ INPUT REGISTER 读输入寄存器
05 WRITE SINGLE COIL 写单线圈寄存器
06 WRITE SINGLE REGISTER 写单保持寄存器
15 WRITE MULTIPLE COIL 写多线圈寄存器
16 WRITE MULTIPLE REGISTER 写多保持寄存器
https://www.dragos.com/blog/industry-news/threat-analytics-and-activity-groups/
Threat Analytics and Activity Groups 威胁分析和活跃组织
Computer and network defense has typically focused on ‘indicators of compromise’ (IOCs) to drive investigations and response. Anomaly detection and modeling (e.g., machine learning approaches) are also increasingly used for alerting purposes, but due to the lack of context of adversary activity, they are of limited utility in tracking threats or informing investigations – thus, they will not be discussed in-depth here. Returning to IOCs, while they have value, the name indicates that such value is generally backward-looking: an IOC is indicative of a compromise by a known and observed threat vector. As a result, an IOC-based approach to defense has limited value in forward-leaning, hunting-oriented defense, and is of almost no value whatsoever in catching ‘new’, not previously observed intrusions.
计算机和网络防御关注在IOCs（Indicators of compromise (IOCs) 妥协指标serve as forensic evidence 法医数据 of potential intrusions on a host system or network主机系统或者网络潜在的入侵）来推动调查和响应。异常检测和建模（例如机器学习）的使用也日益增长出于预警的目的，但是因为缺少对手活动的内容，他们它们在追踪威胁或者通知调查方面的效用有限-故不在此深入探讨。回到IOCs，尽管他们有价值，但这一名字意味着这样的价值用于回溯：一个……不会翻。作为结果，基于IOC的方法防御在前向学习、狩猎导向的防御中价值不大，在捕捉任何新的，不是之前已知的入侵时几乎没有价值。
关注：异常检测在威胁追踪方面用处有限
The majority of IOCs captured after an observed intrusion are target specific – they are unique or limited to that specific event. An adversary will either change or utilize different technical items, with corresponding different IOCs, for any future or different intrusions. Furthermore, IOCs are, by definition, unitary or ‘atomic’ in nature; they refer to a single observable piece of information: an IP address, a domain name, or a file hash value. While these have value, on their own, IOCs only capture one very specific aspect of any activity and must be combined with other data points to yield ‘information’, let alone intelligence. Thus, an IOC-dependent approach will find itself in perpetual data refinement to identify follow-on details from the single alerting point, so as to gain knowledge or understanding of an event.
尽管这些对于他们自身有价值，IOCs只是捕捉了一个活动非常明确的一个方面并且必须结合其他数据点来产生“信息”，更不用说是情报。因此，独立的IOC方法将会发现其自身在持续的进行数据精细改进来识别接下来的来自单个警报点的细节，这样来获取知识或者理解一个活动。
Transitioning from defense by IOCs, a threat behavioral analytic approach attempts to leverage commonalities in adversary behaviors to create more complex threat identification methods by incorporating multiple data points into a single, robust analytic. An analytic is designed to target an adversary behavior, especially one that is an operational requirement (e.g., nearly all intrusions will require some form of command and control) and not trivially changed. For example, a specific command and control domain can be changed, but the method of communication (especially if a custom protocol or implementation is employed) is not so easily shifted.
从基于IOCs防御的过渡，一个威胁行为分析方法试着利用对抗行为的共同点来创建更复杂的威胁识别方法，通过将多个数据点合并成一个单个的、具有鲁棒性的分析。聚焦于一个对手行为设计解析，尤其是对操作要求（例如几乎所有的入侵需要一些命令和控制）并且不会频繁变动一类的解析。举例，一个指定的命令控制域可以变化，但是通信的方法（尤其是如果一个客户协议或者实现）不会轻易改变。
In developing an analytic, the resulting detection methodology should not focus on a specific implementation of a behavior, but rather seek to cover multiple implementations of the behavior type. Threat analytics focus on adversary tactics, techniques, and procedures (TTPs) and behaviors – also referred to as ‘tradecraft’ – instead of static and atomic data points. Threat analytics can, therefore, be forward-looking and flexible. For the former, an analyst may not identify a specific instantiation of command and control but he or she can identify general command and control behaviors to track and alert on. With respect to the latter, flexibility comes from the ability to capture mutations in specific examples of behaviors over time. A critical advantage to this approach is providing alerting criteria with context. Even in those cases where a general threat analytic fires, the analyst has the advantage of knowing the corresponding alert relates to an instantiation of a type of malicious activity, aliging to a portion of the relevant attack path or kill chain, yielding context and nuance to the investigation’s start. This contrasts with an IOC approach, where a single IOC detection – for example, a hash value – must then be manually oriented by the analyst to determine its relevance, use, and associated activity.
When focusing on adversary behaviors, an alternative means of tracking and identifying adversaries themselves emerges that is complementary with an analytics-based approach for threat identification. Specifically, the Diamond Model of Intrusion Analysis identifies threats not by ‘who’ they are, but rather ‘how’ they operate. This transition may seem trivial at first, but this transition represents a dramatic difference from typical threat attribution techniques, which seek to group observed data points (IOCs) as part of an identified, labeled object associated with some publicly-recognized and known entity. For example, “advanced persistent threat FOZZYBEAR is associated with the country Ruritania” provides attribution for FOZZYBEAR activity to an entity, but lacks any definitive connection to how FOZZYBEAR operates or what it looks like to a defender in practice outside of the atomic data points which were collected under the FOZZYBEAR banner.
Contrary to the FOZZYBEAR example, the concept of activity groups, derived via the Diamond Model, focuses on behaviors and actions displayed by an entity. Specific observables include: an adversary’s methods of operation, infrastructure used to execute actions, and what targets they focus on (either specific targets or more general verticals, such as industry type). The goal, as defined by the Diamond Model of Intrusion Analysis, is to delineate an adversary as defined by their observed actions, capabilities, and demonstrated – not implied or assumed – intentions. These attributes then combine to create a construct around which defensive plans can be built. Ultimately, the desired end-state is to empower network defenders by providing a model of adversary activity that documents and forecasts likely adversary actions based upon observed behavioral and targeting traits.
Returning to the topic of analytics, threat behavioral analytics are an obvious extension of defining an activity group; behaviors, targets, and infrastructure of a malicious actor are documented and identified. Based upon this information, an analyst can define identifying or alerting criteria corresponding to the attributes classified within the Diamond Model representation of that activity group. However, at this stage, an important decision-point is reached with respect to the construction of analytics:
- Building threat analytics tuned to specific threat activity group behavior
- Designing a threat analytic to capture a general malicious TTP
The former is likely to be more accurate and focused, but at the cost of breadth and the ability to capture alterations of the underlying tactic. The latter is, in general, more sustainable and actionable, as analytics need not be redefined or recreated for each permutation of the technique, but at the potential cost of initial fidelity and detail when analyzing a triggered analytic.
To expound upon the latter point, if we were to define a threat analytic based around known adversary behavior – for example, taking a human machine interface (HMI) screenshot and exfiltrating this from the ICS environment for system reconnaissance, a DYMALLOY observed behavior1 – we can construct this in such a fashion as to abstract the precise method as to how this screenshot is created (likely tuned to a specific type of malware or other technique), and instead focus on simply that a screenshot was generated and moved out of the ICS environment. In the former case, where the specifics of how are taken into consideration, we have likely generated a high-confidence DYMALLOY threat analytic. But in the latter case, we have instead produced an all-encompassing threat behavior analytic that will identify any observation of screenshot migration out of the ICS network. This is more robust in detecting the general technique – but at the cost of losing some level of context as to who might be responsible for the action.
This point becomes most salient when framing threat analytics within the broader context of response planning and investigation playbooks. If we are to chain our analytics with specific response plans (such as investigation playbooks, which will be covered in a future Dragos blog post), such plans can become more refined and specific in action and detail the closer they are to a specific activity group. In this case, narrower analytics are beneficial. For more general threat analytics, response plans must, by necessity, be more broadly focused and prescribe less detailed, more general response actions. Additionally, while a specific threat-focused analytic can lead an analyst to hypothesize likely next-step actions by the specific adversary for investigation and pursuit, the more general threat behavior analytic leaves a much larger field of possibilities open.
Building a threat-focused defensive mindset around both of these approaches – specific threats and generalized threat behaviors – becomes the ideal end-state for an intelligence-driven network defensive posture. In this manner, complementary defensive approaches are built:
- General threat behavior analytics are designed to catch categories of malicious activity based upon adversary dependencies and ‘required actions’ for intrusion events.
- Where appropriate, implement specific instantiations of general behavior analytics tuned to precise adversary actions
The goal of the above ‘tiered’ alerts is to catch the general type of malicious activity, and where sufficient information exists, create higher confidence analytics tuned to a specific implementation of that behavior. The latter enables a more precise response to ‘known threat actors’, while the former ensures that variations of the technique or behavior are observed.
Returning to the earlier example of screenshot exfiltration from an ICS environment, our general threat behavior analytic will consist of the following data points:
- Image file identified in network traffic FROM the ICS environment.
- Image file metadata matches characteristics of a system screenshot.
The above will capture any permutation of the screenshot exfiltration technique, at least depending upon how condition 2 is defined. While categorizing a general behavior, the analyst receiving a notification that such activity has occurred is then left with the task of identifying further specifics of how this traffic was generated and what the adversary’s next steps would be.
From the above general analytic, we can derive a specific, activity group-focused variation:
- General threat behavior analytic for screenshot exfiltration identified.
- Additional observable data points captured indicative of DYMALLOY activity – e.g., command and control techniques identified in network traffic; or malware variants associated with the group identified in host data.
This approach takes the existing, generalized behavior and utilizes additional data to refine it to a notification of activity correlated with a known activity group. The benefit of this approach is that the analyst now has a (potentially) more limited, narrower scope set of questions to answer: assuming the DYMALLOY detections are correct, the screenshot activity identified can be correlated with other observations to initiate a more focused investigation. Based upon other elements of the DYMALLOY activity group definition – tools, targets, and infrastructure – the analyst can focus on most-likely actions leading to the observed activity and produce more specific hypotheses to initiate the investigation.
Examining another activity group tracked by Dragos, ELECTRUM – the group responsible for CRASHOVERRIDE – utilizes ‘living off the land’ techniques to accomplish network pivoting and further intrusion in observed events. Many of the behaviors exhibited by ELECTRUM for follow-on network compromise can be captured by the general threat analytics below:
- New use of PSExec between network endpoints.
- A single host executing PSExec on multiple network endpoints.
- A single host attempting to connect to many hosts via ‘net use’ commands.
The above abstracts some details, but provides a general conception of capturing intrusion pivoting via ‘living off the land’ methods. This would capture ELECTRUM uses, as well as other malicious (or suspicious) activity with the same behaviors. When triggered, the analyst is alerted to the suspect activity and can begin an investigation, but as with the screenshot example above, this initial investigation is hampered due to the initial large numbers of follow-on questions to scope and investigate. While still useful, the general behavior requires additional work
However, when sufficient detail is captured on preceding and likely follow-on activity through an understanding of the behaviors, infrastructure, and targets or intentions of a specific entity, such as ELECTRUM, the analyst is presented with a much narrower list of high-confidence next steps to investigate. In this case, if the behavioral analytic above is further enriched by observables specific to ELECTRUM (specific malware identified with the group, or examples of how ‘net use’ or PSExec are actually employed), the analyst now has a concrete path to follow for subsequent investigation.
One potential misconception that might emerge from the previous discussion is that threat analytics, when not enriched with specific activity group information, can be cumbersome or difficult for defenders to utilize. While specific behavioral patterns will obviously yield to specific follow-on response actions due to their refinement, the network defender must take the more generalized threat behavior analytics in the context of the typic alert, signature, or IOC that forms the starting point for most security incidents at present. In these cases, the analyst is presented with nothing more than a single data point – this packet header, that IP address, this MD5 hash sum – as the start for an investigation. The number of potential hypotheses for further exploration from a single alerting point such as this are vast, disadvantaging the responding analyst.
Meanwhile, a general threat behavior analytic – while by definition ‘general’ – is both more specific than alerting off of an IOC and more general in that it captures adversary actions rather than atomic (and replaceable) portions of those actions. For the former, analytics are more specific in that the combination of data points ensures that, due to a greater corpus of initial information, the analyst will have higher confidence that the detected behavior is ‘bad’ or worth investigating, compared to alerting on one-off uses of software (such as PSExec), which may very well be legitimate. In the latter case, the analytics are also more ‘general’ in that, instead of being founded on a single, immutable piece of information (such as an IP address), these take a totality of actions (with their attendant behavioral permutations) into consideration and track a less-easily altered technique.
Transitioning from atomic, fleeting, and backward-looking IOCs as the foundation of security response and visibility is vital in transitioning network defense – not just ICS defense – into a more responsive, flexible, and active position. By identifying threat behaviors and designing behavioral analytics to capture these, analysts can begin shifting detection and response solidly to the defender’s advantage, while further refinement to track specific activity groups through instantiations of more general analytics can increase accuracy, confidence, and efficacy in specific response instances. Above all, developing an understanding of network security events through a behavioral perspective rather than a single observation point (atomic IOC view) ensures analysts are better positioned to understand and respond to malicious events as they are identified.