Sul piano lavorativo sono d'accordissimo sul fatto che usare tools salvi del tempo, dico solo che, quando possibile, è sempre meglio espandere le proprie conoscenze, soprattutto se si è alle prime armi e si sta facendo dei test in locale per capire come funzionano le cose.Aggiungo qualcosa legata all'esperienza lavorativa, visto che avete tutti detto cose molto giuste:
dipende spesso dal tipo di engagement con cui si ha a che fare. L'approccio utilizzato per un white box di un applicativo web è totalmente differente da un black-box pentesting di un'architettura infrastrutturale o da un semplice vulnerability assessment. Lo scope detta l'approccio; nel primo caso, l'analisi meticolosa è d'obbligo, perchè tool automatici possono generare falsi positivi o, ancora peggio, falsi negativi. Inoltre, ci sarebbe tutto un discorso da fare legato alla logica dell'applicativo, che non può essere analizzata con dei tool automatici.
Detto questo, le tipologie di encoding, evasion, injection e chi più ne ha più ne metta sono davvero troppe e non a caso nei team in cui mi è capitato di lavorare avevano persone dedicate ad ogni tipo di tecnologia / analisi; se non ho a disposizione tali persone e la mole di lavoro diventa troppa, oltre ad esserci un grosso problema di business, i tool automatici salvano tempo, cattivo sangue e denaro, in un certo senso.
Diciamo che, finchè ti approcci al mondo del pentesting in modo didattico, è sempre meglio non usare tools, in quanto si imparano ad usare in molto meno tempo rispetto a quello che ci si mette a capire come funzionano davvero le cose, altro motivo per cui purtroppo (e per certi versi per fortuna) non può esistere un manuale ne un corso che ti insegna ad "hackerare", questo soprattutto per l'immensa vastità di tecnologie, linguaggi, strutture di dati, protocolli, algoritmi di crittografia eccetera, non conoscendo in modo avanzato ciascuno di questi non si può pensare di trovare una vulnerabilità nel processo/implementazione del codice. Per esempio se uno non conosce come funziona un include su php, come funzionano i filter per l'include e come funziona in generale la gestione delle cartelle, non potrà mai capire come effettuare un LFI, o comunque come poter leggere il codice di un file php dove c'è l'input di un include in mano all'utente, allo stesso modo in cui non si può capire come funziona una SQLi se non si sa come funziona un server SQL e come fa php/python/C/qualsiasi linguaggio a collegarcisi.
Appunto per questi motivi a parer mio finchè non si entra nel mondo del lavoro non ha senso affidarsi ai tools, eccetto per alcuni casi tipo il wifi hacking e il port scanning, dove il tool effettivamente velocizza processi lunghi o, come nel primo caso, abbastanza complicati da fare a mano, senza generare falsi positivi/negativi, in quel caso invece do il pieno appoggio ad usare aircrack/nmap in quanto usandoli non ottenete nulla di possibilmente diverso o discordante da quello che potreste fare a mano (eccetto magari per il riconoscimento dell'OS).
In sostanza reputo che esista una sottospecie di "processo logico" per capire se conviene usare un tool nel processo didattico o fare le cose a mano, la prima domanda da farsi è sicuramente "Posso ottenere risultati diversi facendo le cose a mano?", se la risposta è sì dobbiamo capire quanto degli ipotetici risultati trovati senza tool discostano da quelli trovabili col tool, per poi domandarci "Lo so fare a mano?", se entrambe le risposte sono positive è meglio farlo a mano, se lo è solo la prima bisogna a quel punto studiare per capire come fare (se si è in un ambiente puramente didattico e non lavorativo, o comunque in un ambiente lavorativo dove l'idea di studiare è accettata e non si hanno scadenze "brevi"). Riassumo in una breve scaletta
Codice:
(Scaletta pensata per un processo didattico)
Posso ottenere risultati diversi facendo le cose a mano?
No --> Usa un tool
Sì --> Lo so fare?
Sì --> Fallo a mano
No --> Studia come si fa