17th IEEE Workshop on Offensive Technologies
May 25, 2023, co-located with IEEE S&PFollow us on Twitter Follow us on Mastodon
The Workshop on Offensive Technologies (WOOT) aims to present a broad picture of offense and its contributions, bringing together researchers and practitioners across all areas of computer security. Offensive security has changed from a hobby to an industry. No longer an exercise for isolated enthusiasts, offensive security is today a large-scale operation managed by organized, capitalized actors. Meanwhile, the landscape has shifted: software used by millions is built by startups less than a year old, delivered on mobile phones and surveilled by national signals intelligence agencies. In the field's infancy, offensive security research was conducted separately by industry, independent hackers, or in academia. Collaboration between these groups was difficult. Since 2007, the Workshop on Offensive Technologies (WOOT) has been bringing those communities together.
Call for Papers
Computer security exposes the differences between the actual mechanisms of everyday trusted technologies and their models used by developers, architects, academic researchers, owners, operators, and end users. While being inherently focused on practice, security also poses questions such as "what kind of computations are and aren't trusted systems capable of?" which harken back to fundamentals of computability. State-of-the-art offense explores these questions pragmatically, gathering material for generalizations that lead to better models and more trustworthy systems.
WOOT provides a forum for high-quality, peer-reviewed work discussing tools and techniques for attacks. Submissions should reflect the state of the art in offensive computer security technology, exposing poorly understood mechanisms, presenting novel attacks, highlighting the limitations of published attacks and defenses, or surveying the state of offensive operations at scale. WOOT '23 accepts papers in both an academic security context and more applied work that informs the field about the state of security practice in offensive techniques. The goal for these submissions is to produce published works that will guide future work in the field. Submissions will be peer-reviewed and shepherded as appropriate. Submission topics include, but are not limited to, attacks on and offensive research into:
- Hardware, including software-based exploitation of hardware vulnerabilities
- Virtualization and the cloud
- Network and distributed systems
- Operating systems
- Web security
- Browser and general client-side security (runtimes, JITs, sandboxing)
- Application security
- Analysis of mitigations and automating how they can be bypassed
- Automating software testing such as fuzzing for novel targets
- Internet of Things
- Machine Learning
- Cyber-physical systems
- Cryptographic systems (practical attacks on deployed systems)
- Malware design, implementation and analysis
- Offensive applications of formal methods (solvers, symbolic execution)
The presenters will be authors of accepted papers. There will also be a keynote speaker and a selection of invited speakers.
Note that WOOT'23 and other IEEE S&P workshops are planned to be held in person, see the IEEE S&P website for details and updates.
WOOT '23 welcomes submissions without restrictions of origin. Submissions from academia, independent researchers, students, hackers, and industry are welcome. Are you planning to give a cool talk at Black Hat in August? Got something interesting planned for other non-academic venues later this year? This is exactly the type of work we'd like to see at WOOT '23. Please submit—it will also give you a chance to have your work reviewed and to receive suggestions and comments from some of the best researchers in the world. More formal academic offensive security papers are also very welcome.
Systematization of Knowledge
Continuing the tradition of past years, WOOT '23 will be accepting "Systematization of Knowledge" (SoK) papers. The goal of an SoK paper is to encourage work that evaluates, systematizes, and contextualizes existing knowledge. These papers will prove highly valuable to our community but would not be accepted as refereed papers because they lack novel research contributions. Suitable papers include survey papers that provide useful perspectives on major research areas, papers that support or challenge long-held beliefs with compelling evidence, or papers that provide an extensive and realistic evaluation of competing approaches to solving specific problems. Be sure to select "Systematization of Knowledge paper" in the submissions system to distinguish it from other paper submissions.
- Paper submission deadline (extended!):
Friday, January 27, 2023Friday, February 10th, 2023, 23:59:59 AoE (Anywhere on Earth) (firm!)
- Notification date: Tuesday, March 7th, 2023
- Camera-ready paper deadline: Friday, March 31st, 2023
- Workshop date: Thursday, May 25, 2023
Please submit your paper at: https://hotcrp.eurecom.fr/woot23
What to Submit
Submissions must be in PDF format. Papers should be succinct but thorough in presenting the work. The contribution needs to be well motivated, clearly exposed, and compared to the state of the art. Typical research papers are at least 4 pages, and maximum 10 pages long (not counting bibliography and appendix). Yet, papers whose lengths are incommensurate with their contributions will be rejected.
The submission should be formatted in 2-columns, using 10-point Times Roman type on 12-point leading, in a text block of 6.5” x 9”. Please number the pages. Authors must use the IEEE templates, for LaTeX papers this is IEEETran.cls version 1.8b.
Note that paper format rules may be clarified. Stay tuned.
Submissions are double blind: submissions should be anonymized and avoid obvious self-references (authors are allowed to release technical reports and present their work elsewhere such as at DefCon or BlackHat). Submit papers using the submission form.
Authors of accepted papers will have to provide a paper for the proceedings following the above guidelines. A shepherd may be assigned to ensure the quality of the proceedings version of the paper.
If your paper should not be published prior to the event, please notify the chairs. Submissions accompanied by non-disclosure agreement forms will not be considered. Accepted submissions will be treated as confidential prior to publication on the WOOT '23 website; rejected submissions will be permanently treated as confidential.
Policies and Contact Information
Simultaneous submission of the same work to multiple competing academic venues, submission of previously published work without substantial novel contributions, or plagiarism constitutes dishonesty or fraud. Note: Work presented by the authors at industry conferences, such as Black Hat, is not considered to have been "previously published" for the purposes of WOOT '23. We strongly encourage the submission of such work to WOOT '23, particularly work that is well suited to a more formal and complete treatment in a published, peer-reviewed setting. In your submission, please do note any previous presentations of the work.
Ethical ConsiderationsNote: WOOT '23 ethical guidelines are aligned with the guidelines discussed in the IEEE S&P '23 CFP. For convenience, we report them here verbatim.
Ethical Considerations for Vulnerability Disclosure
Where research identifies a vulnerability (e.g., software vulnerabilities in a given program, design weaknesses in a hardware system, or any other kind of vulnerability in deployed systems), we expect that researchers act in a way that avoids gratuitous harm to affected users and, where possible, affirmatively protects those users. In nearly every case, disclosing the vulnerability to vendors of affected systems, and other stakeholders, will help protect users. It is the committee’s sense that a disclosure window of 45 days https://vuls.cert.org/confluence/display/Wiki/Vulnerability+Disclosure+Policy to 90 days https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-faq.html ahead of publication is consistent with authors’ ethical obligations.
Longer disclosure windows (which may keep vulnerabilities from the public for extended periods of time) should only be considered in exceptional situations, e.g., if the affected parties have provided convincing evidence the vulnerabilities were previously unknown and the full rollout of mitigations requires additional time. The authors are encouraged to consult with the PC chairs in case of questions or concerns.
The version of the paper submitted for review must discuss in detail the steps the authors have taken or plan to take to address these vulnerabilities; but, consistent with the timelines above, the authors do not have to disclose vulnerabilities ahead of submission. If a paper raises significant ethical and/or legal concerns, it will be checked by the chairs and it might be rejected based on these concerns. The PC chairs will be happy to consult with authors about how this policy applies to their submissions.
Ethical Considerations for Human Subjects Research
Submissions that describe experiments that could be viewed as involving human subjects, that analyze data derived from human subjects (even anonymized data), or that otherwise may put humans at risk should:
- Disclose whether the research received an approval or waiver from each of the authors' institutional ethics review boards (IRB) if applicable.
- Discuss steps taken to ensure that participants and others who might have been affected by an experiment were treated ethically and with respect.
If a submission deals with any kind of personal identifiable information (PII) or other kinds of sensitive data, the version of the paper submitted for review must discuss in detail the steps the authors have taken to mitigate harms to the persons identified. If a paper raises significant ethical and/or legal concerns, it will be checked by the chairs and it might be rejected based on these concerns. The PC chairs will be happy to consult with authors about how this policy applies to their submissions.
Registration for Authors
At least one author per paper has to register and present the paper.
We seek to include a broad cross-section of the WOOT community in the AEC. If you are interested in joining the AEC, or supervising PhD students who might be, please send your application using this form by February 12th, 2023.
Authors of accepted papers are expected to submit the following:
- A PDF with an abstract for the artifact. The abstract should specify the core idea, the focus of the artifact, and what the evaluation should check
- A PDF of the most recent version of the accepted paper
- Documentation about the artifact (what to test and/or how to reproduce the contributions of the paper)
- A link to the artifact, accessible via a stable reference or DOI. For this purpose, we recommend Zenodo. Since the artifact can evolve during the evaluation to address feedback from the reviewers, another (potentially different) stable reference will be later collected for the final version of the artifact.
A scientific paper consists of a constellation of artifacts that extend beyond the document itself: software, hardware, evaluation data and documentation, raw survey results, mechanized proofs, models, test suites, benchmarks, and so on. In some cases, the quality of these artifacts is as important as that of the document itself, yet many of our conferences offer no formal means to submit and evaluate anything but the paper itself. To address this shortcoming, WOOT organizes an optional artifact evaluation process, inspired by similar efforts in software engineering and security conferences.
We believe the dissemination of artifacts benefits our science and engineering as a whole, as well as the authors submitting them. Their availability improves replicability and reproducibility and enables authors to build on top of each other's work. It can also help more unambiguously resolve questions about cases not considered by the original authors. The authors receive recognition, leading to higher-impact papers, and also benefit themselves from making code reusable.
Authors can choose to have their artifact evaluated against the following badges:
- Open Research Objects (ORO): this badge indicates that the artifact is permanently archived in a public repository that assigns a global identifier and guarantees persistence, and is made available via standard open licenses that maximize artifact availability.
- Research Objects Reviewed (ROR): this badge indicates that all relevant artifacts used in the research (including data and code) were reviewed and conformed to the expectations set by the paper.
We expect artifacts to be:
- consistent with the paper
- as complete as possible
- documented well
- easy to reuse, facilitating further research
Notice that the two badges can be issued independently.
Artifact evaluation is a separate process from paper reviews, and authors will be asked to submit their artifacts only after their papers have been (conditionally) accepted for publication at WOOT. After the artifact submission, at least one member of the AEC will download and install the artifact (where relevant) and evaluate it. Since we anticipate minor glitches with installation and usage, reviewers may communicate with authors to help resolve glitches while preserving reviewer anonymity. The AEC will complete its evaluation and notify the authors of the outcome.
For the camera-ready version, authors who have successfully passed the evaluation process will receive the awarded badges on their papers.
To avoid excluding some papers, the AEC will try to accept any artifact that authors wish to submit. These can be software, hardware, data sets, survey results, test suites, mechanized proofs, etc. Given the experience in other communities, we decided to not accept paper proofs in the artifact evaluation process. The AEC lacks the time and often the expertise to carefully review paper proofs. Obviously, the better the artifact is packaged, the more likely the AEC can actually work with it during the evaluation process.
While we encourage open research, submission of an artifact does not contain tacit permission to make its content public. All AEC members will be instructed not to publicize any part of your artifact during or after the evaluation, nor retain any part after evaluation. Thus, you are free to include, e.g., models, data files, or proprietary binaries in your artifact. Also, note that participating in the AEC experiment does not require you to publish your artifacts unless you apply for the Open Research Objects (ORO) badge. Still, we strongly encourage you to do so.
We recognize that some artifacts may attempt to perform malicious operations by design. These cases should be boldly and explicitly flagged in detail in the readme so AEC members can take appropriate precautions before installing and running these artifacts. The evaluation of exploits and similar results might lead to additional hurdles where we still need to collect experience on how to handle this best. Please contact us at firstname.lastname@example.org if you have concerns, for example when evaluating bug-finding tools or other types of artifacts that need special requirements.
Program co-chairs (email: email@example.com)
- Sara Rampazzi, University of Florida
- Yanick Fratantonio, Google
- Adrian Dabrowski, CISPA Helmholtz Center for Information Security
- Andrea Continella, University of Twente
- Andrea Possemato
- Aravind Machiry, Purdue University
- Ben Nassi, Ben-Gurion University of the Negev
- Clémentine Maurice, CNRS, IRISA
- Collin Mulliner
- Daniel Andriesse, Intel Corporation
- Daniele Antonioli, EURECOM
- Dave (Jing) Tian, Purdue University
- Fabio Pagani, UC Santa Barbara
- Fangfei Liu, Intel Corporation
- Federico Maggi, AWS
- Kyle Zeng, Arizona State University
- Lucas Davi, University of Duisburg-Essen
- Manuel Egele, Boston University
- Marco Squarcina, TU Wien
- Mariano Graziano, JPMorgan Chase
- Marius Muench, Vrije Universiteit Amsterdam
- Mathias Payer, EPFL
- Mathy Vanhoef, imec-DistriNet, KU Leuven
- Michael Schwarz, CISPA Helmholtz Center for Information Security
- Natalie Silvanovich, Google
- Sofia Celi, Brave
- Takeshi Sugawara, The University of Electro-Communications
- Thomas Ptacek, Fly.io
- Thomas Roth, Leveldown Security
- Travis Goodspeed
- Victor van der Veen, Qualcomm
- Xiali (Sharon) Hei, University of Louisiana at Lafayette
- Yongdae Kim, KAIST
- Yuval Yarom, University of Adelaide
- Zhenpeng Lin, Northwestern University
Artifact Evaluation chair
- Marco Squarcina, TU Wien
Artifact Evaluation committee
To be announced.
- Aurélien Francillon, EURECOM
- Yuval Yarom, University of Adelaide and Data61
- Clémentine Maurice, CNRS
- Sarah Zennou, Airbus
- Collin Mulliner, Cruise
- Fangfei Liu, Intel
- Mathias Payer, EPFL
- Colin O'Flynn, NewAE Technology and Dalhousie University
- Martina Lindorfer, TU Wien