BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//pretalx//pretalx.hackglasgow.live//hack-glasgow-2026//speaker//FK
 8R38
BEGIN:VTIMEZONE
TZID:GMT
BEGIN:STANDARD
DTSTART:20001029T030000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZNAME:GMT
TZOFFSETFROM:+0100
TZOFFSETTO:+0000
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20000326T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
TZNAME:BST
TZOFFSETFROM:+0000
TZOFFSETTO:+0100
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:pretalx-hack-glasgow-2026-7AYQRW@pretalx.hackglasgow.live
DTSTART;TZID=GMT:20260815T103000
DTEND;TZID=GMT:20260815T112500
DESCRIPTION:After six long years\, I'll (hopefully) have submitted my PhD t
 hesis looking at IPv6 scanning. I'd love to share a few highlights of stuf
 f I've learnt in that time\, focusing on these themes:\n- 'Ethical scannin
 g of IPv6 scanning is difficult (but important!)': a short tour of my expe
 rimental setup I used to run IPv6 scans (rough around the edges\, but lovi
 ngly crafted)\, and a few papers which were very important to my work over
  the past few years. Very happy to bring my printed copies of these to the
  talk as props\, they're covered in all sorts of post-it notes and handwri
 tten notes at this point.\n- 'Rate-limiting is vital': sounds like obvious
  advice\, but IPv6 defences are often not up to the standard of IPv4. Rate
 -limiting at the recipient end of unsolicited IPv6 scans does a lot to lim
 it reconnaissance - it's no longer enough to assume we're safe because it'
 s a large address space\, it's a niche protocol\, we have network address 
 translation (NAT)\, etc. I have some scans that show how we can detect rat
 e-limiting thresholds and address allocation patterns in different network
 s with no prior info.\n- 'IoT devices are IPv6 capable\, but at what cost?
 ': this is a more detailed look at one of the papers in the first section 
 ('One Bad Apple Can Spoil Your IPv6 Privacy' - Saidi et al.\, 2022)\, plus
  additional work I did for address analysis (and\, hopefully\, some actual
  IoT scans). IPv6-enabled IoT devices can be a hazard in terms of user pri
 vacy from IPv6 addresses alone - some big name brands still embed MAC addr
 esses in public IPv6 addresses\, which can be used to track users across d
 ifferent networks even if every other device on their network uses IPv6 pr
 ivacy addresses.\n- 'One loudmouth can expose the entire operation': this 
 section is original work\, building on the previous section. An unexpected
  side-effect of insecure MAC-derived IPv6 addresses is that a single sign-
 in attempt from a suspected IoT IPv6 address can reveal botnet-like sign-i
 n activity - we can use info from this one sign-in attempt to see many oth
 er IPv4 and IPv6 addresses attempting similar sign-ins across large number
 s of accounts.\n- 'IPv6 should be part of the blue team toolbox': it's no 
 longer a niche\, hobbyist protocol\, (un)fortunately - it's really importa
 nt for fellow blue teamers to understand that malicious behaviour is happe
 ning over IPv6\, how to analyse it in logs\, and how to handle IPv6 IoCs e
 ffectively. It might also be useful for red teamers to know there's probab
 ly gaps in the IPv6 fence...\n- 'Conclusions': IPv6 scans are hard to run\
 , but there's a lot of us doing them. IPv6 is still not implemented secure
 ly in IoT devices\, which has positives and negatives. Evil over IPv6 is n
 o longer theoretical and needs to be defended against.
DTSTAMP:20260611T141046Z
LOCATION:Stage 2
SUMMARY:Six Years of IPv6 - Vi
URL:https://pretalx.hackglasgow.live/hack-glasgow-2026/talk/7AYQRW/
END:VEVENT
END:VCALENDAR