해당 글은 CIC DATASET에 대한 저의 뇌피셜이 가득한 글입니다. 필요한 부분만 골라서 보시길!!! 바랍다!
1. delay 공격
빨간색으로 뜨는건 내가 공격에 대한 파싱을 진행한 후, modbus 패킷만 모으다 보니 TCP 3-way가 사라져서 빨간색으로 표시되는 것 뿐이다.
해당 공격에 대해서 timestamp를 보면 Req-response 쌍인데도 시간 차이가 거의 30초가 나는 것을 확인할 수 있다. 이것을 제외해서는 아예 공격에 관한 정보가 없다. 그래서 내가 생각한 것은 똑같은 TID를 가진 REQ, RES 쌍을 잡아서 해당 패킷의 요청, 응답시간을 계산하여 그것이 5초 이상이면 따로 pcap파일에 저장하는 코드를 만들었다. 코드에 대한 내용은 맨 마지막에 github링크 첨부.. 물론 GPT와 GEMINI의 힘을 많이 많이 빌렸ㄷ.
2. Chage_payload 공격
CIC dataset에서 지정해준 이름과 상관없이 내가 입에 붙은 이름으로 붙이는 중이데. 뜻은 동일한 의미로 붙였다 그래도
해당 CIC에서는 data 값을 바꿀 때 항상 "cd"의 값으로 바꾼 것을 확인하였다.
근데 여기서 재밌는 점은, data의 값이 좀 높을 때 16진수값으로 실제 01 cd <- 이렇게 값이 들어갈 때도 있는 것.. 그래서 데이터를 분석을 했을 때 data를 악성으로 변조시키는 공격 중, "cd" 값이 딱 00 cd로 바뀌는지 그리고 01 cd 처럼 실제 값이 컸을 때 공격인지 아닌지를 확인하기 위하여 해당 Function code와 Reg값에 맞는 데이터의 평균을 조사해봤다.어짜피 공격이 아닌 이상 OT 특성상 값들은 항상 평균값을 크게 벗어나지 않는다.
2가지의 검증 과정을 거쳐서 공격을 시도할 때는 항상 적은 값의 평균을 가진 data들을 cd의 값까지 올리는 것을 확인하였고 그에 맞는 코드를 작성하였다.
3. Dos 공격 & query Flooding 공격
해당 공격들은 dos류의 공격으로, 그냥 짧은 시간 내에 많은 패킷들을 보내는 공격이다.
2개의 차이점이 있다면 Functio code의 번호 차이이다.
4. injection payload vs stacked
해당 공격을 쉽게 생각하고 그냥 길이 파라미터에 있는 값에, 넘는 모든 패킷들을 파싱했더니 stacked modbus Frame 공격과 같이 파싱이 되는 바람에 조금 애를 먹었다. 그래서 생각한 방법은 단 하나의 modbus 프레임만 가지고 있냐는 로직을 생성했다. 만약에 길이 파라미터 보다 더 많은 값들이 있으며, modbus 프레임이 여러 개면, Stacked modbus attack이고 그것이 아니면 injection payload..
5. 정찰 공격
해당 정찰 공격은 찾기도 쉽고 코드도 쉬웠다. 그냥 Fucntion code에서 사용하는 Reg값의 최댓값을 집어넣어서 response조차 안오게 만드는 공격이다.. 말은 정찰인데 사실 오류가 나서 response가 안 온 것..인가 싶기도 하다.
9가지의 공격이 있는데 해당 글에는 8개뿐이다. Baseline reply는 식별은 했지만 tcp도 똑같고, modbus 패킷이 달라진 것도 아니고 정상적으로 TID도 증가한다. 그래서 파싱 로직을 따로 구현하지는 못했다. 해당 패킷들을 분석하는데 대략 1주일 정도를 소모한 것 같다. 물론 초기 2일은 이거를 어떻게 매칭하는지도 몰랐으며, 매칭을 했을 때 시간대 설정이 달라서 분명 똑같은 시간에 맞는 패킷을분석을 해도 공격 패킷 처럼 안보였다는.. 슬픈 소식도 있다.
한 3일째 해보니 실제로 패킷 캡쳐를 한 시간이랑 다르다는 것을 깨달았고, 그 이후에는 하나하나 파싱을 해나가는데 하루에 1~2개씩 많으면 3개씩 진행했다.